[ideas] Full text search for mongodb
Пример.
Форум, коллекция posts — посты.
Каждый пост среди прочих имеет свойства: forum, afftar, create_time, visibility_type, access_type, text
В конфиге указываем, что по полю text надо строить полнотекстовый индекс.
Также указываем, что поле forum, XXX_type и поле afftar могут выступать фильтрами на поиск по точному значению.
Ещё указываем, что поле create_time может выступать фильтром по диапазону.
Таким образом, реализуется "из коробки" полнотекстовая искалка по Монгодб-коллекции.
Форум, коллекция posts — посты.
Каждый пост среди прочих имеет свойства: forum, afftar, create_time, visibility_type, access_type, text
В конфиге указываем, что по полю text надо строить полнотекстовый индекс.
Также указываем, что поле forum, XXX_type и поле afftar могут выступать фильтрами на поиск по точному значению.
Ещё указываем, что поле create_time может выступать фильтром по диапазону.
Таким образом, реализуется "из коробки" полнотекстовая искалка по Монгодб-коллекции.
такая штука есть, например, в elasticsearch: http://github.com/richardwilly98/elasticsearch-river-mongod...
только там не slave, а отдельный сервис, который выбирает обновления из oplog
только там не slave, а отдельный сервис, который выбирает обновления из oplog
Спасибо за ссылку.
На яве, что-то как-то не впечатлило с первого взгляда.
На яве, что-то как-то не впечатлило с первого взгляда.
а такой коннектор к Solr/ElasticSearch с последующей настройкой того же Solr`а не решит задачу?
Ссылочка битая, но восстанавливаемая.
Коннетор скорее всего задачу решит, в плане интеграции с Монгой.
Как я понял, в принципе задача плюс-минус решаемая тем, что есть сейчас.
Коннетор скорее всего задачу решит, в плане интеграции с Монгой.
Как я понял, в принципе задача плюс-минус решаемая тем, что есть сейчас.
Зачем все это, когда есть постгрес с полнотекстом из коробки?
О, кто-то прикрутил-таки сфинкс к монге? Когда монговцы приезжали в Москву, там был один товарищ (из бегуна, что ли который задавал кучу вопросов по поводу возможной интеграции сфинкса и монги и очень жаловался, что приходится делать кучу костылей и все равно работает хуево. Этот чувак удивительно много и удивительно хуево разговаривал на английском, но разработчик монги каким-то чудом его все-таки понимал 
Зачем все это, когда есть постгрес с полнотекстом из коробки?Потому что реляционные базы нужны только в 10% случаев их использования.
Просто раньше ничего другого не было дешевого, вот и хранили всё в реляционных базах.
Потому что реляционные базы нужны только в 10% случаев их использования.извините, я плохо понимаю о чем речь
вот пролистал вики: http://ru.wikipedia.org/wiki/MongoDB
внимание, вопрос:
поддерживает ли mongo db ограничения (constrains) ?
есть ли транзакции хотя бы в каком-то виде ?
или это настолько "другая" штука, что такие (как мне кажется) важные возможности не нужны?
настолько "другая" штукаДа, зовется NoSQL
поддерживает ли mongo db ограничения (constrains) ?unique есть
есть ли транзакции хотя бы в каком-то виде ?
есть атомарные операции
транзакции нет
Просто раньше ничего другого не было дешевого, вот и хранили всё в реляционных базах.Berkley DB была издавна.
А почему люди корпели над созданием постгреса или мускула, если можно было сделать намного более примитивную монгу и закрыть 90% потребностей?
поддерживает ли mongo db ограничения (constrains) ?Монго не поддерживает бэкап, что является нонсенсом для современной СУБД.
Да, зовется NoSQLэто слишком примитивная(слишком модная) классификация, т.к. NoSql база может быть и иерархической, и сетевой, и key/value, и объектно-ориентированной, и даже реляционной.
MongoDb ближе к key/value-базе, где value может являться сложным структурным типом (а не только простым).
Согласен, но учитывая удивление человека относительно отсутствия констрейнтов и транзакций - имхо само то =)
Согласен, но учитывая удивление человека относительно отсутствия констрейнтов и транзакций - имхо само то =)в целом, ни то, ни другое не связано с sql-ем.
ps
те же транзакации, например, NTFS держит
NoSQL родился и стал популярен для/из-за перформанса и скалабилити на больших массивах данных.
Перформанс и скалабилити там появились не из-за того, что внезапно была придумана какая-то более хорошая модель данных, а из-за того, что там отказались от большинства плюшек реляционных баз данных. То есть нету реляций, нету констрейнтов, как правило только eventual consistency, минимум транзакционной поддержки (обычно есть только атомарный доступ к отдельному элементу).
Соответственно, раз удивляется отсутствию этих вещей, я и посчитал разумным дать ссылку сразу на все направление, выросшее из идеи отказаться от этих вещей.
Что не нравится?
Перформанс и скалабилити там появились не из-за того, что внезапно была придумана какая-то более хорошая модель данных, а из-за того, что там отказались от большинства плюшек реляционных баз данных. То есть нету реляций, нету констрейнтов, как правило только eventual consistency, минимум транзакционной поддержки (обычно есть только атомарный доступ к отдельному элементу).
Соответственно, раз удивляется отсутствию этих вещей, я и посчитал разумным дать ссылку сразу на все направление, выросшее из идеи отказаться от этих вещей.
Что не нравится?
те же транзакации, например, NTFS держиттак держит, что лишь начиная с висты, и то Microsoft не рекомендует на них закладываться т.к. в будущих версиях вероятно всё переделают - http://msdn.microsoft.com/en-us/library/windows/desktop/hh80...
Потому что реляционные базы нужны только в 10% случаев их использования.
пианист такой пианист
Монго не поддерживает бэкап, что является нонсенсом для современной СУБДне понял
там есть утилита, чтобы дамп выгружать и загружать обратно — какой еще нужен бэкап?
не понялЭто не бэкап, а экспорт. В случае уничтожения дисковой системы или ошибки оператора будут потеряны все данные со времени последнего экспорта.
там есть утилита, чтобы дамп выгружать и загружать обратно — какой еще нужен бэкап?
При нормальном бэкапе в дополнение к полному бэкапу непрерывно архивируются логи повторного выполнения. В результате можно сделать point in time recovery к любому моменту (включая момент непосредственно предшествоваший катастрофе).
спасибо, теперь немного больше понимаю 
пианист такой пианистКстати , любителям NoSQL:
With PostgreSQL 9.2, query results can be returned as JSON data types. Combined with the new PL/V8 Javascript and PL/Coffee database programming extensions, and the optional HStore key-value store, users can now utilize PostgreSQL like a "NoSQL" document database, while retaining PostgreSQL's reliability, flexibility and performance.
"Native JSON support in PostgresSQL provides an efficient mechanism for creating and storing documents for web APIs. We use front-end libraries like jQuery to request tabular and tree-structured data; and the new features make it convenient and provide performance advantages in retrieving that data as JSON, " said Taras Mitran, Senior Architect, IVC Inc.
With PostgreSQL 9.2, query results can be returned as JSON data types.Это можно было всегда делать. В 9.2 сделали чуть удобнее и устроили по этому поводу пиар.
да, такую штуку у них часто спрашивают
но кто-то сам это сделал: http://github.com/wordnik/wordnik-oss/blob/master/modules/m...
но кто-то сам это сделал: http://github.com/wordnik/wordnik-oss/blob/master/modules/m...
Я не думаю что бэкап можно реализовать в виде сторонней тулзы. В противном случае такую тулзу приделали бы к MySQL.
он вычитывает оплог
mysqlbackup, скорее всего, так же делает — просто он уже есть в комплекте, а у монги нет
mysqlbackup, скорее всего, так же делает — просто он уже есть в комплекте, а у монги нет
Это можно было всегда делать. В 9.2 сделали чуть удобнее и устроили по этому поводу пиар.Стало удобнее и быстрее, вроде как.
поддерживает ли mongo db ограничения (constrains) ?Нет, в Монге скорее вложенные документы рулят, а ограничений в принципе нет.
есть ли транзакции хотя бы в каком-то виде ?
или это настолько "другая" штука, что такие (как мне кажется) важные возможности не нужны?
Транзакционности тоже нет. Единственное что точно известно — это атомарность записи или модификации одного документа (записи).
Это другого типа БД. Например, она абсолютно не годится для хранения информации финансового толка.
Berkley DB была издавна.Думаю, что те 10% задач куда важнее было решить системно РСУБД. Вот и делали Постгресы и Мускули.
А почему люди корпели над созданием постгреса или мускула, если можно было сделать намного более примитивную монгу и закрыть 90% потребностей?
Для многих их оставшихся 90% и эти задачи решались РСУБД. Худо-бедно, но решались. У кого не решались — писали самописные решения.
Ты думаешь Монгу написать это так просто было? Её придумать сложно было, архитектурно именно. Уверен, что она в черновиках уже сроком не меньше 10 лет писалась.
Монго не поддерживает бэкап, что является нонсенсом для современной СУБД.
Из коробки умеет.
С одной стороны ты можешь число реплик увеличивать, по сути это и есть бэкап.
Если тебе нужен бэкап именно одного сторейджа, то запросто решается и эта задача. Но если у тебя развёрнутая система с репликацией 3x, одна из реплик в другом ДЦ, то зачем?
Это не бэкап, а экспорт. В случае уничтожения дисковой системы или ошибки оператора будут потеряны все данные со времени последнего экспорта.Я уже тут написал, что твоя задача решается созданием N реплик.
При нормальном бэкапе в дополнение к полному бэкапу непрерывно архивируются логи повторного выполнения. В результате можно сделать point in time recovery к любому моменту (включая момент непосредственно предшествоваший катастрофе).
Делай реплики на разных континентах. Делай реплики на разных планетах. Делай реплики в разных галактиках.
Для многих их оставшихся 90% и эти задачи решались РСУБД. Худо-бедно, но решались. У кого не решались — писали самописные решения.Откуда такие цифры, из твоего опыта? Можешь рассказать в подробностях из своего опыта три провальных проекта по причине использования РСУБД (а монго в этих случаях всё разрулила бы)?
Потому что реляционные базы нужны только в 10% случаев их использования.
Имхо, базы без схемы не получат широкого применения. Я много где читал такую точку зрения, сейчас с ходу хорошие ссылки не нашел, но вот например http://citforum.ru/database/articles/mr_vs_dbms/2.shtml1
В противном случае такую тулзу приделали бы к MySQL.кстати, такое очень даже делают: на c++, например; на днях нашел похожую штуку, но на руби.
В смысле, можно слушать обновления и произвольно их обрабатывать, не только бэкапить.
В смысле, можно слушать обновления и произвольно их обрабатывать, не только бэкапить.Такими темпами глядишь скоро и репликацию изобретете
Делай реплики на разных континентах. Делай реплики на разных планетах. Делай реплики в разных галактиках.Во-первых, если в коде программы которая работает с базой будет ошибка (или человек случайно зайдет на продакшен базу вместо своей локальной и удалит таблицу, или ошибка будет в самой СУБД то неверная команда отреплицируется на все реплики и данные будут уничтожены.
Во-вторых, под репликацию нужна отдельная машина или несколько машин, способных накатывать лог без отставания, что является бесполезной тратой ресурсов.
Откуда такие цифры, из твоего опыта? Можешь рассказать в подробностях из своего опыта три провальных проекта по причине использования РСУБД (а монго в этих случаях всё разрулила бы)?У меня не было трёх провальных проектов.
Но вот держи пример. ЖЖ — типичный пример проекта, который дышит на ладан.
Если его перевести на Монгу, то станет хорошо.
Опять же, если это сделать прямыми руками, а не текущими суповцами.
Я не думаю что бэкап можно реализовать в виде сторонней тулзы.Это распространённая практика.
Ты думаешь Монгу написать это так просто было? Её придумать сложно было, архитектурно именно.А что такого сложного в архитектуре монги?
ЖЖ — типичный пример проекта, который дышит на ладан.По-моему довольно шустро работает.
пока ддосов нет
хотя это не совсем к базе
хотя это не совсем к базе
Во-первых, если в коде программы которая работает с базой будет ошибка (или человек случайно зайдет на продакшен базу вместо своей локальной и удалит таблицу, или ошибка будет в самой СУБД то неверная команда отреплицируется на все реплики и данные будут уничтожены.Боюсь представить что будет с пианистом, когда он обнаружит что у РСУБД есть И репликации И бэкап
Во-вторых, под репликацию нужна отдельная машина или несколько машин, способных накатывать лог без отставания, что является бесполезной тратой ресурсов.
Оставить комментарий
Werdna
Я предлагаю читателям раздела иногда писать какие-то свои интересные идеи, чтобы на форуме их обсуждать.Предлагаю обсудить такую штуку, насколько она интересна и нужна миру? Кратко опишу так.
Для понимания того что я пишу в принципе надо просто знать что такое mongodb, что там есть шардинг и репликации.
1. Программка притворяется slave-репликой для любого mongod, не фактически только выступает как backup. Возможно, что также выступает в роли арбитра при голосовании за нового мастера. не сильно важно, главное что она получает точную реплику всех коллекций базы.
2. В конфиге указывается, какие коллекции принимать для построения full text search index, какие поля играют какую роль.
3. При реалтаймовом получении обновлений, программа на лету перестраивает поисковый индекс.
На выходе — либо поисковый индекс реального времени вообще, либо регулярные дампы и диффы от предыдущих.
Таким образом получаем реализацию полнотекстового поиска для mongodb. Помимо собственно полнотекстового поиска можно ещё ставить фильтры по полям, которые тоже можно задавать в конфиге.
Ваши мысли? Нужна ли такая штука? Чем бы вы её дополнили?
Как комментарий я приведу пример.