Размер словаря

Я уже писал что задача сжатия словаря

отличается от задачи сжатия текста, ...

ну это вы загнули, я сейчас индексирую украину, это порядка 13 тысяч уникальных доменов (покачь то исключительно домены физически расположенные на украине) это порядка 350000 документов (я не претендую здесь на объективность, это лишь мои личные данные) объем обратного индекса составляет примерно 57% от общего объема данных, а вы говорите в память его, где ж найти сервер который столько оперативки будет поддерживать, и сколько при этом он будет стоить?

готов поспорить, я например для себя кое что вынес из этой темы

ну почему же загнул. во-первых, размер инвертированного (обратного индекса легко сделать в 40 процентов) во-вторых там не нужно кешировать все достаточно кешировать процентов 60-80. Ну и давайте посчитаем:

350 тыс страниц, каждая в среднем 4 кб чистого текста. Итого гиг с чем-то данных текстовых. 40 процентов - 400 мегабайт ОЗУ. А теперь представьте себе, что вы делаете обратный индекс несжатым получаете его размер в 100-200% размера текста и в гиг оперативки уже не влазите. То есть вместо одной машины придется поставить 3 или 4, чтобы искалось быстро.

а какой смысл при гиге обробатыаемых данных ставит несколько машин? это уже не рентабельно

насчет 40% процентов индекса от общего объема вполне согласен, но я только лиш учусь и тестирую знания полученные в этой области, оптимизацию данных на пзу я пока не ставил как задачу, нет проблем с местом под данные, при доступном объеме в 200Гб и имеющихся 1Гб согласитесь это не проблема, хотя реальный размер текстовых данных всеголиш 42 Мб, сжатие на пзу я всеже использую;-)

- нечто а-ля Хаффман ... с деталями, зависящими от требуемого ФУНКЦИОНАЛА словаря.

Какой, кстати, функционал-то обсуждаем? Спеллчекинг, например, или пораждение неупоряченного полного массива словоформ, или вычисление уникального порядкового номера (кода, идента) слова в упорядоченном (по алфавиту) полном списке - то ли слов, то ли словоформ?

Это же все разные задачи! И под каждую - оптимален свой метод хранения "словаря".

К вопросу о "целесообразности паковки": хранение словаря в виде список основ + правила пораждения словоформ - это есть, несомненно, паковка словаря (словоформ).

в точьку, с моей точьки зрения, можете к єтому что-то добавить?

Что сжимается и какой алгоритм используется?

Уважаемый Зодчий! Вы очень невнимательно читаете. Изначально был вопрос такой: какой смысл сжимать данные, если и так все хорошо. Я на него ответил, чтобы больше индекса влезало в кеш. При этом если в кеш влезает в три раза больше индекса, то и поисковых машин нужно натурально в три раза меньше. Надеюсь, что я ответил на первый вопрос.

Теперь вопрос следующий: зачем при гиге обрабатываемых данных ставить несколько машин. Отвечаю, потому что если не паковать индекс, то он не влезет в память машины, где оперативной памяти мало. А если индекс не влезет на одну машину, то прощай производительность в несколько запросов в секунду. Ну а вот на вопрос зачем производительность в несколько запросов в секунду я отвечать не буду. Предупреждаю заранее :-)

Я кажется понимаю о чем идет речь, но название точное забыл, кажется это что-то вроде ppc и связано с цепями Маркова. Помню, что алгоритм очень эффективный, а вот насколько быстро потом можно искать не знаю.

Задача стоит хотя бы просто этот весь массив словоформ закодировать. Ну и естественно иметь возможность чекать если словоформа в словаре.

Тема о плотной упаковке словаря словоформ

который уже представлен в этом виде, ...

сжимается исключительно текстовый контент страниц, покачьто, алгоритм обычьный гзип средствами пхп, на нем собственно сейчас и пишу, к другим языкам уже очень давно не прибегал, пока ставлю за цель лишь создание рабочего прототипа поисковой машины и не вижу смысла "заворачиваться" с ними, что касается индексов то они покачьто хранятся в базе данных а не в файлах, хотя сейчас хочу попробовать параллельно базу и файлы для сравнения скорости работы