если я вас правильно понял то не совсем так, на выходе, данные которые ищутся уже по индексу, должен быть идентификатор базового слова, и к нему идентификаторы дополнений к оному которые и формируют само искомое слово соответственно и желательно все допустимые для него словоформы
прокомментируйте пожалуйста, возможно я что-то упустил? но мне кажется что первоначальный вопросы был как минимизировать объем данных для размещения их в ОЗУ без упоминания о сжатии оных
насчет кеша, хотелосьбы тоже услышат более подробное объяснение
остальное и так оопнятно даже такому новичьку как я ;-)
сжимается исключительно текстовый контент страниц, покачьто, алгоритм обычьный гзип средствами пхп, на нем собственно сейчас и пишу, к другим языкам уже очень давно не прибегал, пока ставлю за цель лишь создание рабочего прототипа поисковой машины и не вижу смысла "заворачиваться" с ними, что касается индексов то они покачьто хранятся в базе данных а не в файлах, хотя сейчас хочу попробовать параллельно базу и файлы для сравнения скорости работы
в точьку, с моей точьки зрения, можете к єтому что-то добавить?
а какой смысл при гиге обробатыаемых данных ставит несколько машин? это уже не рентабельно
насчет 40% процентов индекса от общего объема вполне согласен, но я только лиш учусь и тестирую знания полученные в этой области, оптимизацию данных на пзу я пока не ставил как задачу, нет проблем с местом под данные, при доступном объеме в 200Гб и имеющихся 1Гб согласитесь это не проблема, хотя реальный размер текстовых данных всеголиш 42 Мб, сжатие на пзу я всеже использую;-)
боюсь что каждый фрейм воспринимается поисковиком как отдельный документ, поэтому вероятность нулевая
з.ы. почему не откажитесь от фреймов, это технология устарела, в крайнем случае используйте дивы, что-то вроде <div style="overflow: auto;"> такая конструкиця воспринимается как единый с родителем документ и дает почьти все тежи возможност и что и фрейм
ну это вы загнули, я сейчас индексирую украину, это порядка 13 тысяч уникальных доменов (покачь то исключительно домены физически расположенные на украине) это порядка 350000 документов (я не претендую здесь на объективность, это лишь мои личные данные) объем обратного индекса составляет примерно 57% от общего объема данных, а вы говорите в память его, где ж найти сервер который столько оперативки будет поддерживать, и сколько при этом он будет стоить?
готов поспорить, я например для себя кое что вынес из этой темы
но речь то идет именно о сейчас, не о вчера и не о завтра, к тому же вчера считался каждый байт ОЗУ и грузит туда лишние данные было просто глупостью, поэтому даже с оглядкой на вчера я остаюсь при своем мнение, запакованным данным нечего делать в ОЗУ, загрузив туда запакованные данные вам также надо будет загрузить и алгоритм компресии/декомпресии или юзать его с жесткого диска, ваш выигрыш в производительности и в том и в ином случае стремится к нулю
еще раз повторюсь, ПОЖАЛУЙСТА, не можете обосновать свои слова, не бросайтесь ими
ребята, давайте жить дружно, еще раз повторюсь, в первоначальной постановке вопроса речь шла о загрузке словаря в ОЗУ, я со совей колокольни, не вижу смысла загружать в ОЗУ запакованные данные, и по прежнему думаю что все упирается в алгоритм формирования слов из некоего абстрактного списка основ, то что я вижу на данный момент лишь подтверждает мою уверенность в том что эти данные можно втиснуть в пресловутые 300Кб
itman,
любая дискуссия это своего рода спарринг, если я кому-то где-то нахамил, или кого-то где-то обидел, укажите мне на это и я извинюсь, если был не прав, покато я прошу лишь прошу обоснованные ответы, не словами по типу "я это сделал", я много чего сделал в свои 27, но это мало кого интересует, я прошу лишь обосновывать свои ответы
