Без базы данных, даже без нескольких кардинально разных, такой проект невозможен.
Поэтому я уделю этому вопросу немного времени.
Итак, как минимум, вам понадобится база данных, которая обслуживает обычные «плоские» («2D») данные – т. е.
полю данных присвоен определенный идентификатор ID. Почему поле данных, которое я рассматриваю, является таковым? Потому что:
- выбор осуществляется только по полю ID – поиск данных не производится.
Для этого существуют специализированные индексы - иначе от таких объёмов информации толку будет мало
- любое количество полей можно упаковать в одно, для этого я на коленках создал набор небольших прикладных библиотек, в частности при упаковке сохраняется CRC данных, чтобы не использовать битые
И в случае столь высоких требований к оптимальности и скорости, на мой взгляд, это вполне оправдано.
Основными операциями для таких таблиц базы данных являются:
- выбор по ID
- прочитать всю базу данных последовательно (в память или хэш)
- обновить запись по идентификатору
- вставьте новый в конце, получите идентификатор
Каждая страница имеет фиксированное количество записей.
Все довольно просто, если я заранее знаю фиксированный размер записи — тогда таблица будет работать еще быстрее, однако даже в случае изменения размера записи при обработке ничего существенно не меняется.
Обновления и дополнения в конец производятся внутри страницы в памяти, затем страница записывается на диск.
В табличном файле страницы хранятся последовательно.
Возникает вопрос: как обновить записи в середине таблицы при изменении их размера - ведь если вся таблица больше 10-20-200 ГБ, то копирование половины таблицы во временный файл, а затем обратно будет занять часы? Я перенес этот вопрос на файловую систему, разбив все страницы на блоки.
Один блок – один файл на диске, количество файлов в одной таблице не ограничено.
В каждом файле хранится последовательно ограниченное фиксированное количество страниц.
Тогда если мне нужно обновить запись в середине таблицы, то мне нужно изменить только 1 файл гораздо меньшего и зачастую ограниченного размера.
Я взял на себя ответственность за то, чтобы не заставлять файловую систему делать глупости типа сначала писать в начало, потом в конец, потом снова в начало.
Просто чтобы не напрягать сервер, всегда пишу пакетно, соответствующий функционал максимально оптимизирован, все происходит в памяти.
Ну и конечно вся система модулей поисковой системы построена исходя из того, что записать 1000 записей в конец быстрее, чем 1 в начало - поэтому при записи в начало иногда проще сделать копию стол.
Хорошо, мы решили это с помощью обычных таблиц.
Сейчас описанная база данных очень хороша, в частности, она обрабатывает в процессе поиска 35 ГБ текстовых фрагментов, со случайной выборкой.
Но есть и ограничения - хранить соответствие в такой таблице: для каждого слова список документов, в которых это слово было найдено (вместе с дополнительной информацией), практически невозможно - для каждого слова будет очень много документов, и соответственно объем будет огромным.
Итак, какие операции следует проделать с такой базой данных:
- последовательный выбор от начала списка по нужному произвольному слову и до тех пор, пока не надоест
- Хорошо бы под слово поменять список документов, но тут можно сделать финт - просто вставить в конец базы
Причем, записывать или нет физически отдельные блоки для каждого слова — отдельно на диске — дело разработчика — в обоих случаях можно просто запомнить: где закончился следующий блок и его длину, сохранить в простом списке.
Тогда процедура последовательного чтения будет следующей: перемещаемся в файле в начало списка по нужному слову и читаем последовательно, пока не начнется список для следующего слова: 1 ищем, а минимально необходимое количество чтений - win (здесь я специально не считаю операции самой файловой системы — их можно отдельно оптимизировать) Теперь, очевидно, когда мы хотим добавить в индекс информацию о вновь проиндексированных страницах, мы можем аккумулировать новую информацию отдельно, открыть текущий индекс для чтения, а новый, создаваемый для записи, и читать-записывать последовательно сливаясь с информацией.
что нужно добавить, начиная с первого слова и заканчивая последним.
Вопрос о том, в каком порядке добавлять документы в список, я рассмотрю чуть позже, когда буду говорить о построении индекса.
Полный контент и список моих статей в поисковике будут обновляться здесь: http://habrahabr.ru/blogs/search_engines/123671/ Теги: #БД #собственная база данных #Поисковые технологии
-
Подумайте О Жизни, Лишенной Печати
19 Oct, 24 -
Идеальный Тихий Убийца – Хамелеон
19 Oct, 24 -
Изучение Ладьи (Часть 1)
19 Oct, 24 -
Вам Нужно Уйти Стильно...
19 Oct, 24 -
Последняя Дорожная Карта Intel
19 Oct, 24
