nosql2,

Проектирование любой системы хранения начинается с запросов, которые будут к системе.

Например если тебе нужно только получать по слову все документы, где встречается слово, то прекрасно подойдет trie, где в листах будут лежать ссылки на документы. И займет как раз около 50 мб.

Но реляционная схема позволяет, например, практически бесплатно сделать запрос виде - "сколько уникальных слов в документе" или более сложные - вроде расчета TF\IDF (на основе которого считается релевантность).

Как думаешь почему поисковый индекс занимает около трети объема текста? Наверное они просто неправильно хранилища выбирают?

Приведи код с расчетом релевантности на основе NoSQL хранилища и на основе SQL и результаты замеров.

nosql2,

И не забудь страничное сжатие в SQL Server включить.

BoobenComМодель простая - Многие ко многим. Запрос простой - под слову получить список документов.
реляционная схема позволяет не только этот запрос выполнить, но и много других, например расчет tf\idf.

BoobenComgandjustasНапример если тебе нужно только получать по слову все документы, где встречается слово, то прекрасно подойдет trie, где в листах будут лежать ссылки на документы. И займет как раз около 50 мб.

Причем здесь Трие ? В моей статье сам по себе словарь занимает 9 мегабайт, а связи между Словарем и Документами занимает 800 мегабайт. Зачем экономить на словаре ?

При том что trie полностью покроет запрос, который ты озвучил, но вызовет страшный геморрой для реализации других запросов.

При том, что в SQL Server можно прямо в таблицу терминов записать строковым полем все id документов и применить страничное сжатие, получится те же 50 мб и получить ровно тот же эффект.


BoobenComgandjustasНо реляционная схема позволяет, например, практически бесплатно сделать запрос виде - "сколько уникальных слов в документе" или более сложные - вроде расчета TF\IDF (на основе которого считается релевантность).


Такой запрос не бесплатный, а требует кучу индексов.


Нужно будет только хранить количество слов в документе, что увеличит таблицу документов на целую одну колонку в 4 байта. То есть менее чем на 100кб.

BoobenComНо это не важно, запрос такой не требуется.
Так с этого и надо было начинать. Определяешь запросы - проектируешь хранилище. Если надо только доставать список документов по слову, то вполне подойдет одна таблица терминов, где в поле записаны все ссылки + сжатие страниц.

А еще лучше - filetable+FTS в SQL Server, если выложишь тестовые данные я специально для тебя сделаю тест на SQL Server



BoobenComНе трети, а сжатие в 100 раз вполне реально.
Это если не требуется tf-idf, уточнения, сниппеты и много других полезных фишек.


BoobenComgandjustasНаверное они просто неправильно хранилища выбирают?


Кто они ? Те, кто делают поисковые движки. Например lucene и SharePoint.


BoobenComВ статье есть. Запросы на http://booben.com выдаются с учетом релевантности, или о чем вопрос ?
В какой статье? Ты дал ссылку где ни одной строчки нет.
Как считается релевантность? Особенно интересно на больших текстовых документах и слабоселективных выборках (пример "социальная сеть"), которые выдают более 1000 документов.

BoobenCom http://booben.com/Stat?q=nosql&s=sql.ru

Он отрабатывает моментально.
Правда база вся находится в ОЗУ, но само по себе сжатие это позволяет сделать.
Он отрабатывает 3 секунды (потом кешируется). Выдает абсолютно нерелелевантный результат, по запросу nosql не выдал ни одной темы по nosql :)

Кроме того запрос делается только по одному слову. Когда понадобится делать запрос по нескольким словам, то появится TF-IDF, который потребует таки дополнительных индексов и база резко перестанет влезать в оперативку.

Так что твои попытки - предварительная и практически бесполезная оптимизация.

BoobenComА можно с этого места по-подробней ? Мне до сих пор не понятно причем тут Трие и как с экономией на спичках получить 50 мб.
Сам trie поможет быстро делать запросы (менее 3 секунд), а листы можно жать, причем очень круто. Кроме того полностью отпадает необходимость держать все листы в памяти. По запросу можно будет с диска отдавать результаты. У тебя же проблема с объемом индекса из-за того, что индекс должен вмещаться в память. А с trie такой необходимости нет.

BoobenComКак не странно но в NoSQL тоже можно добавить колонку. Ну в смысле в ту таблицу которая хранит имена\урлы документов.
И как это поможет посчитать TF-IDF?


BoobenComА то что одна таблица денормализирована и вместо 800 мб будет занимать несколько гигабайт, вас не смущает ?
После сжатия? Сомневаюсь.
Да и что мешает пожать сами ссылки?


BoobenComВсе тестовые данные есть в блоге. Но я бы не рекомендовал в это ввязываться, лучше вам не спешить и немножко глубже подумать почему для РДБМС эта задача, мягко говоря, неудачная.
Еще раз: если нужно только получить документы по слову - то РСУБД не подойдет. Как только появится необходимость считать TF-IDF, то реляционная база резко станет нормальным решением.

BoobenComЭто немножко другая история. Но релевантность конечно есть, ее не может не быть. Например так:
http://booben.com/?q=nosql&s=habrahabr.ru
Дык там всего 671 ссылок в индексе http://booben.com/stat?q=nosql&s=habrahabr.ru

На 2000 результатов уже нерелевантные результаты валятся. И это только по одному слову. А когда будет более одного слова в запросе, особенно с разной селективностью, то без TF-IDF никуда.

Опубликуй статью про хранилища и объемы индекса когда TF-IDF появится.

BoobenComgandjustasОн отрабатывает 3 секунды (потом кешируется). Выдает абсолютно нерелелевантный результат, по запросу nosql не выдал ни одной темы по nosql :)


Он не может отрабатывать 3 секунды.
Три секунды отрабатывает ассоциативный поиск. Но там один поиск состоит из сотен тысяч микропоисков.
На этом форуме слово nosql к сожалению проассоциировалось с альбомом известного мембера, потому резульаты неочень.
Другое дело на хабре или любом другом айтишном форуме.

На хабре проиндексировано в 10 раз меньше страниц, чем на sql.ru
Чем больше страниц в индексе, тем больше будет проблем, что не то и не с тем "проассоциировалось".
Когда начнешь делать поиск фраз, то непременно столкнешься с необходимостью TF-IDF и структура индекса поменяется значительно.