?

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 нашли ?
 
 
 
vit_rvit_r on Август, 14, 2010 16:01 (UTC)
А как насчёт http://www.intersystems.com/cache/ ?
Правда, условия лицензирования у них очень очень странные.
Максим Крамаренкоmaximkr on Август, 14, 2010 17:32 (UTC)
Когда-то давно смотрел, смущает что это очень древняя штука и язык там своеобразный
http://ru.wikipedia.org/wiki/MUMPS
vit_rvit_r on Август, 14, 2010 18:45 (UTC)
Можно подумать NoSQL - это что-то новое...

А релиз у них последний этого года. Хотя, насчёт странности я не спорю.
Максим Крамаренкоmaximkr on Август, 14, 2010 18:49 (UTC)
пока самое интересное что видел - Neo4j: http://neo4j.org/
но у них AGPL, цена на коммерческую OEM лицензию пока не понятна, но похоже что будет не дешево.
vansickle on Август, 14, 2010 19:39 (UTC)
> Если коротко, то при рестарте сервера нужно проводить восстановление БД и это может занять несколько часов.

Ну это только при "неправильном завершении работы". Т.е. да, mongo не fault-tolerant, но вы совсем уж грубо написали.
Максим Крамаренкоmaximkr on Август, 14, 2010 20:44 (UTC)
Да, конечно, "при неправильном завершении работы". При этом в CouchDB специально подчеркивают, что никакого правильного завершения им не требуется
===
On-disk, CouchDB never overwrites committed data or associated structures, ensuring the database file is always in a consistent state. This is a “crash-only” design where the CouchDB server does not go through a shut down process, it’s simply terminated.
===

В Cassandra остановка сервера тоже делается через kill -9. Мы используем сейчас HSQLDB - тоже убиваем просто через kill -9.

Мне кажется, что требование "правильного" завершения работы - это очень серьезный шаг назад.

alll: шушпанчикalll on Август, 14, 2010 20:47 (UTC)
Ну как бы у нормального сервера количество рестартов после "неправильного завершения работы" вполне сравнимо с количеством рестартов после "правильного завершения".
Teoteo_bon on Август, 15, 2010 14:18 (UTC)
Я в этой теме совсем любитель, но, как я понимаю, основные бонусы NoSQL - простая расширяемость и высокая скорость работы при огромных кол-вах строк (фактически, почти постоянное время выборки вне зависимости от размера БД). Если я правильно понял, достоинства NoSQL баз проявятся при огромных кол-вах задач и сопуствующей информации, при которых СУБД упрётся в ресурсы физического сервера, и потребуется горизонтальное расширение. Это что касается замены СУРБД на NoSQL решения.

Не уверен, что этот класс СУБД позволит избавиться от локального кэширования, всё-таки внутрипрограммный кэш и СУБД, доступное по сети - это всё-таки разные с точки зрения времени отклика вещи. В любом случае, многое зависит от архитектуры самой TS.

Насчет MongoDB - некоторые люди (например, из подкаста Радио-Т) считают первой production-ready версией MongoDB 1.6 от 5 августа 2010 года. Упомянутый обзор - февральский, и, на мой взгляд, довольно устарел, поэтому я бы на вашем месте дал бы Mongo шанс и/или посмотрел обзоры по версии 1.6
Максим Крамаренко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.
Larionov "MOU" Andrewmou_ngaged on Сентябрь, 9, 2010 21:08 (UTC)
Кое-кто уже пошел по этому пути и свернуть не может, даже если хочет. Лучше взять BerkleyDB, это тоже не реляционная БД, тоже нечто вроде индекса, только мне кажется, что более надежная.
Максим Крамаренкоmaximkr on Сентябрь, 9, 2010 21:41 (UTC)
Да, я какое-то время ковырял BDB JE, там в целом все хорошо, там тоже log-based format. Скажем, есть secondary keys (в отличие от cassandra), скорость дикая (десятки тысяч обращений в секунду на базе в миллион задач при наличии кеша). Причем там хранить можно Java-объекты и оно нормально понимает ситуации, когда у этих объектов вдруг появляются новые поля.

Но есть одна сложность - лицензия. Использовать локально BDB можно без проблем, а вот чтоб можно было клиентам поставлять - нужна коммерческая лицензия, которая стоит дикие килобаксы.

PS. А что за проблемы и почему хочет свернуть ? У меня пока более-менее живой опыт разве что с lucene - где-то полгода использования сервера с терабайтным индексом-базой. Вроде все ok, хотя там структура данных сильно проще.
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 была бы оптимальным вариантом.