Максим Крамаренко (maximkr) wrote,
Максим Крамаренко
maximkr

Category:

NoSQL и Lucene

Я писал когда-то, что не очень рад использованию реляционных СУБД в TrackStudio. Если коротко, то мы используем из всего SQL разве что поиск по первичному ключу, испытываем большие сложности с обработкой кастом-полей в задачах, плюс очень много всего приходится кешировать, чтоб не тормозило.  Т.е. интерес ко всякой альтернативщине был давно, а тут довелось поковыряться с NoSQL-базами и возникло некоторое непонимание:

1) Cassandra. Базовая функциональность - т.е. запись/чтение данных и поиск по индексу работает замечательно. А вот с "наворотами" есть проблемы:
  • при добавлении сервера в кластер cassandra начинает копировать на него недостающие данные с других серверов. Если данных много - очень сложно понять что вообще происходит и когда закончится. В mailing list вообще советуют скопировать все с другого сервера ручками и запустить очистку лишнего, не полагаясь на streaming.
  • во время добавления/удаления сервера или compaction все тормозит так, что запросы начинают отваливаться по таймауту. Приходится отлавливать и повторять, что не очень хорошо. Поиск по интервалу ключей отваливается с timeout очень часто.
  • compaction во время выполнения может потребовать дополнительно 100% места, занимаемого column family. Способ борьбы - sharding column family на несколько кусков.
  • способа сделать hot backup всей БД не нашел.
  • в качестве внешнего API используется thrift, хотят заменить на Avro (и я их понимаю).
  • on-disk формат обещает скоро измениться, индексов по другим полям пока сделать нельзя.
2) CouchDB - смотрел существенно меньше, т.к. процесс инсталляции нетривиальный (особенно на Windows), шансов использовать в TrackStudio мало. Но в целом впечатление похожие:
  • базовая функциональность работает нормально
  • возможности организации данных в кластер существенно хуже чем в Cassandra, поддерживается только master/master и master/slave репликация.
  • для доступа к внешним данным используется REST, есть несколько Java-оберток, но, например, сделать bulk insert/update позволяет только 1 библиотека из 4.
3) MongoDB - даже не скачивал, забил после прочтения вот этого обзора: http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/ Если коротко, то при рестарте сервера нужно проводить восстановление БД и это может занять несколько часов. Плюс места на диске может сожрать минимум в 3 раза больше, чем размер данных.

Как мне кажется, из всех NoSQL СУБД самой перспективной является... Lucene :-)

В самом деле:
  • есть возможность хранения довольно сложных документов, с переменным числом полей
  • для каждого поля можно хранить только данные, можно только индекс, можно то и другое вместе, можно анализировать данные поля для полнотекстового поиска
  • та же самая append-only модель обновления базы, что и в NoSQL СУБД и дикая скорость создания новых записей (особенно если их предварительно индексировать в памяти, а потом мержить с индексом на диске).
  • поддержка не только текстовых, но и числовых полей с возможностью поиска по диапазону значений
  • кеширование на уровне lucene (через механизм фильтров)
  • вполне полноценный язык запросов, транзакции
  • накладные расходы минимальные: при хранении индексированного ключа + 5 кб неиндексированных данных накладные расходы меньше 1%
  • полный контроль над тем, когда сбросить индекс на диск, когда провести оптимизацию (и проводить ли вообще).
Да, Lucene называется индексом, а не СУБД, но этот "индекс" выглядит куда более зрелым и надежным, чем все перечисленные выше NoSQL СУБД. Кроме того, lucene не требует REST/thrift и сложной инсталляции и может встраиваться непосредственно в приложение.

Что же все в этих NoSQL нашли ?
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 28 comments