?

Log in

No account? Create an account
 
 
14 Август 2010 @ 18:59
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 нашли ?
 
 
 
Максим Крамаренкоmaximkr on Январь, 8, 2011 09:01 (UTC)
Мы пробовали с кластеризацией играться, но в итоге в TS4 убрали ее. Главная причина - при работе в кластерном режиме приходится синхронизировать между серверами блокировки и кеши, в итоге тормозит оно еще больше. Думаю, как-то переделать чтоб минимизировать кол-во синхронизаций можно, но переделать на NoSQL будет проще, наверное.

Да и вообще у нас не так нагрузка, чтоб кластеры использовать. 95% всех используемых клиентами багобаз вмещаются в память сервера целиком (разве что без аттачей), какая-нибудь шустрая in-memory СУБД с persistence была бы оптимальным вариантом.