?

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 нашли ?
 
 
 
Larionov "MOU" Andrewmou_ngaged on Сентябрь, 9, 2010 21:47 (UTC)
В JIRA Lucene сейчас главный блокер для построения кластерного решения. Такой монолитный индекс сложно кластеризовать. Его сложно заменить другим, ввиду специичности языка запросов. Конечно OfBiz тоже не подарок, но для RDBMS есть более менее традиционные средства, вроде master-slave реплик.
Максим Крамаренкоmaximkr on Сентябрь, 9, 2010 21:58 (UTC)
1) Мы делали кластер в TS 3.0, в 4.0 удалили. Быстрее от кластера ничего не работает, даже тормозов больше т.к. нужно реплицировать блокировки и состояние кеша между машинами. Спроса на эту фичу тоже не было - вроде никто не расстроился что удалили.

2) скорости lucene более чем достаточно для обработки любой багобазы на 1 машине, как они заставили lucene тормозить для меня загадка :-) Когда экспериментировал на домашнем компе, то у lucene удалось добиться скорости индексации коротких записей (несколько сот байт, десяток полей) в 170 тысяч записей в секунду, причем все отлично параллелится. По мотивам этих экспериментов была даже идея держать индекс lucene в памяти и перестраивать при каждом запуске, чтоб не переживать про flush/sync. В итоге забили, т.к. доставание данных из СУБД и SCM - занятие довольно долгое.

Teoteo_bon on Январь, 7, 2011 21:16 (UTC)
Кластеризация (если доля обязательно синхронной части невелика) позволяет выйти за ограничения по ресурсам конкретного сервера + повысить отказоустойчивость всей системы. Если нагрузка такова, что встает вопрос о производительности - для нас будет проще добавить еще пару серверов, чем заниматься тюнингом конкретного сервера.
Максим Крамаренкоmaximkr on Январь, 8, 2011 09:01 (UTC)
Мы пробовали с кластеризацией играться, но в итоге в TS4 убрали ее. Главная причина - при работе в кластерном режиме приходится синхронизировать между серверами блокировки и кеши, в итоге тормозит оно еще больше. Думаю, как-то переделать чтоб минимизировать кол-во синхронизаций можно, но переделать на NoSQL будет проще, наверное.

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