Скажу в самом начале, что задача не относится ни к РНР, ни к MySQL. Предположим, что есть оцифрованная база данных словаря из нескольких миллионов слов, словосочетаний и словоформ без лексического анализа, т.е полные формы, инфинитивные формы глаголов (которые в процессе должны обрабатываться) и других частей речи. Над полной обработкой словарей работает лексикографическая группа, которая готовит примеры со словами, особенности использования и пр. В пример могу привести ABBYY Lingvo, в котором слова представлены карточками, и где каждое из слов имеет по несколько словарей, отображаемых на одной карточке. Задача состоит в правильной организации индекса словаря. Да, словарь будет всего один, в него входит несколько миллионов разных слов, которые имеют не просто прямой перевод, а ещё и склонение, спряжение, использование в наклонениях и другие вещи, но это уже при полном просмотре слова. Теперь, как будет правильней и рациональней организовать индекс словаря? Я пробовал сделать тестовый индекс, содержащий 1*10^6 строк разной длины и указатель на расположение (сдвиг) файла со словарем. Занял этот индекс 35 614 289 байт (35 Мб), и это только в случае миллиона слов, а ожидается, что будет их гораздо больше, приблизительно миллионов 6. Т.е предположить если, то размер будет около 210 Мб, тут уж речь не может идти ни о какой рациональности в плане загрузки индекса в память. Поэтому, вопрос: Как организовывать индексы? Как организовать их загрузку (целиком не катит, наверное) ? Использовать базы данных не предлагать. Ну предложить вы можете, только это во внимание принятно не будет, потому что задача в другом.
Если речь идет о веб-сервисе, то какая проблема хранить несколько сотен мегабайт в памяти? Хайлоады иногда даже шаблоны хранят в памяти. Затраты ресурсов на работу с файловой системой и памятью несравнимы. При чтении файла информация грузиться в оперативку. Если она уже там, ничего никуда грузить не надо.
Задача: как грамотно организовать индекс? [vs] Нет, речь идет об десктопном проекте. Писаться будет он на "чистом" С++, без баз данных и прочего. Т.е поставляться будет программа, в которой есть навигация по словаю (наподобии Lingvo), сам словарь и индекс словаря. Т.е это всё, меня интересует конкретно организация индекса, как было бы грамотней распределить всё, чтобы не грузить все сразу слова в память? Или загружать какой-то сегмент по первой букве?
Apple Теперь понятно. Надо найти слово по индексу. То есть у тебя есть индекс, например, 11232323232 - позиция в файле- ты читаешь слово с этой позиции то метки конца слова?
kostyl Всё верно. Вопрос только в том, что размер индекса может быть очень-очень большим, как с ним быть? Ведь не следует его загружать сразу целиом в память, надо как-то на кусочки разбивать, но как тогда будет определяться, какой индекс загрузить и какие временные задержки с выгрузкой + загрузкой другой части индекса? Или сделать ещё указатель индекса, который содержит метки букв, и при вводе определенной буквы читать этот блок?
Apple Тебе надо в памяти соответственно слову представить указатель на область в файле, где содержится куча слов типа? Ну попробуй хранить индекс в шестнадцатиричной системе. Так меньше занимать будет.
Apple, а что , если хранить индекс, который ссылается на массив слов , начинающийся с определенных букв? Не знаю, конечно, как там у тебя всё устроено и что требуется. Например: Код (Text): index('нав') { Наверное Навернуться Наверняка Навигация Наводнение } а в них уже поиск перебором по небольшому массиву. Индексы будут маленькие и их будет намного меньше. Даже если ты возьмёшь первых 3 буквы — их будет в два-три раза меньше, я думаю. Плюс — очень короткие. И потому все индексы с лёгкостью войдут в память. Плюс под-массив должен быть упорядочен по алфавиту — тогда поиск можно сделать быстрый
Возможно автору пригодится почитать про Хеширующие таблицы (есть юнит от дельфи, говорят он нубо-легкий, значит разобраться в нем не сложно http://www.torry.ru/authorsmore.php?id=3771 )
В реальном проекте я собирался использовать Firebird. Почему не предлагать БД? Потому что хочется разобраться. Да-да, именно не готовое решение использовать, а разобраться в реализации собственного более-менее приемлемого решения. Об использовании баз данных я и так с самого начала думал, а вот о том, как грамотно организовать быстрый и легкий индекс — это и есть задача. Кроме того, если решение задачи оказалось (окажется?) хорошим, именно его я и буду использовать =) Ага, сенкс, почитаю вечером. Вечером отвечу более подробно, сейчас времени нема.