?

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 Август, 15, 2010 19:35 (UTC)
Про Cassandra пишут, что The largest production cluster has over 100 TB of data in over 150 machines.
Т.е. меньше терабайта на машину. Сам я cassandra на таких объемах не тестировал, но lucene на терабайте работал довольно резво, думаю, еще раза 3 по столько и никто бы не заметил.

По поводу MongoDB - вот обсуждение от июля этого года, обещают single server durability в 1.8, но как делать - пока не решили
http://groups.google.com/group/mongodb-user/browse_thread/thread/afed1f6ba6811c1f#
Максим Крамаренкоmaximkr on Август, 15, 2010 21:23 (UTC)
А, вот еще ужас-ужасы про MongoDB:
http://www.mikealrogers.com/2010/07/mongodb-performance-durability/

1) Возврат из запроса на запись вовсе не означает, что эти данные можно читать.
2) формат файла БД не append-only, лога нет, fsync они делают редко (1 минута) и когда хотят.

10gen’s sizable marketing effort promotes MongoDB as the new M in your LAMP stack, or Ruby/Python equivalent, without addressing their differences in durability with your existing M and almost any alternative “NoSQL” database.

Teoteo_bon on Август, 16, 2010 05:32 (UTC)
В пух и прах. Как у Lucene с надежностью? Всё-таки, "индекс", а не "СУБД".
Максим Крамаренкоmaximkr on Август, 16, 2010 06:38 (UTC)
А вот не знаю. В принципе, я разрушенные базы Lucene видел, но это была старая версия 2.3 и они с тех пор много data corruption багов поправили.

Если исходить из того, что разработчики lucene не воспринимают data corruption как нормальное явление, правят такие баги и сам по себе продукт, видимо, более зрелый и популярный чем NoSQL базы - вряд ли там должно быть хуже.
(Анонимно) on Август, 17, 2010 08:43 (UTC)
Нужно еще исходить из того, что разработчики не воспринимают dbms как целевое использование Lucene...
Также есть вопрос - как к Lucene будет относиться Hibernate?
Максим Крамаренкоmaximkr on Август, 17, 2010 09:56 (UTC)
Да, не воспринимают. К Hibernate будет относится плохо, но и (мне) не очень хочется.
Teoteo_bon on Август, 18, 2010 10:06 (UTC)
Уж если искать embedded решение, то тогда neo4j или его аналог, чтоб сразу и persistent framework, и nosql dbms.
(Анонимно) on Август, 17, 2010 08:53 (UTC)
И так как Lucene всё же является библиотекой (http://www.grok.in/notes/full-text-search/), может, стоит говорить о чём-то более standalone, типа Solr? http://lucene.apache.org/solr/
Максим Крамаренкоmaximkr on Август, 17, 2010 09:58 (UTC)
Логично, но если писать приложение на Java, то использование в виде библиотеки будет даже удобнее и никаких заморочек с вызовом.
Teoteo_bon on Август, 18, 2010 08:30 (UTC)
Тут тогда я не очень понимаю, в качестве чего будет работать Lucene. Как я понял из поста, идет выбор NoSQL альтернативы для основной БД - и в этом случае имхо эта альтернатива должна быть отдельным законченным продуктом, а не частью TS. Со своей поддержкой, со своими решениями вопросов отказоустойчивости и масштабирования.
Максим Крамаренкоmaximkr on Август, 18, 2010 08:33 (UTC)
Тут возможны варианты. Скажем, сейчас HSQLDB работает как встроенная база, в том же самом процессе.
Teoteo_bon on Август, 18, 2010 08:42 (UTC)
Но и роль HSQLDB сейчас неполноценная - для evaluation использования. В случае production - любая другая база заведомо лучше по многим параметрам. Также достаточно важен момент разделения ответственности между TS и системой хранения данных.
Максим Крамаренкоmaximkr on Август, 17, 2010 10:23 (UTC)
Кстати, похоже Guardian как раз использует Solr в качестве СУБД

http://www.enterpriseirregulars.com/16687/the-guardian-nosql-eu-don%E2%80%99t-melt-the-database/
“Apache Solr is like a database, it works like one for us"

А вот тут презентация
http://www.lucidimagination.com/blog/2010/04/29/for-the-guardian-solr-is-the-new-database/
Teoteo_bon on Август, 18, 2010 08:25 (UTC)
Всё таки "is like a database", и в Guardian Solr работает как индекс, вместе с Oracle в качестве основной БД и Memcached на выходе для скорости. В качестве NoSQL БД они рассматривают CouchDB, так что это плюс CouchDB, а не Solr.