Понятно, что затраты на CRC не сводятся только к расчету.
Задачка уточняется по ходу.
А решение (конечно, одно из возможных) было изложено мной еще в прошлом посте. Придется рассказать более подробно с азов.
Если у вас некая операция выполняется часто, но не быстро (выходит за временные рамки ТЗ), то один из способов разрешения ситуации заключается в разбиении операции на несколько этапов и выполнения части из них заранее. Если говорить конкретно относительно данной задачи, то решение может быть в сохранении CRC основных форм слов данного текста. Тогда вам не придется "шерстить" файл, да и считать CRC. Достаточно будет сравнивать CRC форм слов запроса с CRC форм слов данного текста. Уф, вроде бы все.
Хотя, отвлекаясь от постановки задачи, скажу, что и решение экономить память на 15Мб также мне не совсем понятно. А не пробовали память докупить? Если, конечно, сервер - ваш, если не ваш, то все-таки дешевле купить сервер и поставить у провайдера.
Игорь, Андрей, согласен, что не стоит, хотя и не экспериментировал напрямую со словообразованием при поиске.
Только, кажется, тема данного обсуждения все-таки чуть в стороне. Задача конкретна.
Есть словарь, преобразованный через CRC32 (кстати, может словообразование досталось "бесплатно" для экономии объема словаря?), есть слова запроса, также в виде CRC32. И есть тексты документов, где надо найти эти слова запроса. Расходы на CRC32 при этом чересчур велики.
Решение, по-моему, простое:
надо хранить копии текстов в CRC32-преобразованном виде.
Расходы - дополнительное место на диске - этим сегодня можно пренебречь. Расходы собственно на отметку при этом близки к 0.
Правда, нужно решить еще проблему с коллизиями.
Другой вопрос, зачем вообще идти по пути CRC32-преобразования словаря , но уже пройдено 2 года и назад вернуться, возможно, трудно.
Увы, согласен с Андреем. Кто-то из ваших пользователей обязательно наткнется на найденное "не то" слово.
Очень хорошо, только не понял, как это существенно сократит затраты на CRC32? Ведь объем словаря документа немногим меньше самого документа, даже с учетом сведения лексем.
Простите, а как вы собираетесь разрешать коллизии?
30 - число параллельных рабочих сегментов, обслуживающих запрос как устроен Яндекс. Совсем не обязательно, что эти сегменты совпадают с сегментами обновления (градациями частоты обновления):
"распределение документов по коллекциям случайно" (см.там же).
Цифра 4-10 таких градаций - моя оценка.
У нас (Галактика-Зум) тоже есть динамический индекс.
Долго мы сомневались, пока взялись за него, в оценке трудностей я с Игорем вполне согласен.
Сил и времени на него тоже ушло довольно много.
Но транзакции и откаты реализованы: у некоторых пользователей они являются элементами их технологии ведения базы. Да и надежность при этом намного выше: при любых сбоях система возвращается в предыдущее состояние и нужно повторить только последнюю операцию.
Самые большие из работающих баз у наших пользователей содержат до 60Гб данных (в переводе на чистый текст).
Практический лимит в нынешней реализации - примерно 0,5Тб на каждый сегмент. Относительно просто и больше сделать, но нет смысла при нынешней массовой технической базе.
Правда, и денег за такую систему мы берем немного больше, чем SiteMeta.
Поздравляю всех, а тебя, Грэй, особенно, как автора и бессменного ведущего этого неформального диалога. 2 года - это серьезно. Да не заглохнет голос, и не иссякнут твои силы в этом праведном деле.
Поздравляю, Виктор, с днем рождения.
Экслеру только дай повод позубоскалить. Надо же чем-то заполнять обзоры. А идеи Дмитрия мне напомнили Шурупчика из "Приключений Незнайки...", достаточно безумны и достаточно непрактичны.
А в целом, как полет мысли, производит неплохое впечатление.
Глядишь, что и выйдет из его синтаксического анализатора (осмысленного поиска). Но демку надо бы сделать более удобоваримой (см. xander), желательно, чтобы работала через HTTP аналогично АОТ (http://www.aot.ru).
Игорь, в данном случае зависит от задачи. Сразу заниматься полной матрицей нет необходимости. Начать можно с более частотных слов, даже со словоформ. Тогда матрица получится вполне обозримой. Однако, возникают задачи выделения "стартового" множества, а также сведения лексем (я и хотел выяснить, как msa хочет последннюю решать). Но решать их можно, поэтому ставить крест на матрице сочетаемости я бы не стал.
Несомненно, такие механизмы есть. Предположу, что переиндексация зависит как от обновления, так и от популярности сайта у посетителей Яндекса. А сама база Яндекса обновляется очень неравномерно - база разделена на 4-10 сегментов с разной частотой обновления. Причем, число сегментов определяется скорее аппаратными, нежели идеологическими ограничениями.
Повторюсь, все это - на уровне предположения, я бы сам так делал.
