LINUX.ORG.RU

О новомодных NoSQL

 , , , ,


0

3

Собсно, заставили нас Ответственные Лица пейсать один наш сервис с использованием риака.

Все было хорошо, за исключением хреновых док - ну ничо, разобрались. Использовали мы вначале риаковские индексы. Только вот разработчики как-то поленились написать, что использование индексов приводит к падению производительности на порядок и существенному падению скалируемости и дикому увеличению латентности при общении с кластером.

Ну ничо, вчера переделали логику на использование мультимап. В терминологии риака - bucket'ы с allow_mult=true. Ну т.е. когда на один ключ можно создавать много значений.

И тут мы получили странную картинку - под нагрузкой не то, что производительность просела на ДВА порядка, нет - риак просто стал выжирать всю память, крэшиться, выдавать 2-5 ответов за секунду при дичайшей латентности. Вот тут можно посмотреть на простой изолированный пример.

Вывод пока печальный. Похоже, что риак - это просто распределенная мапа - и ничего более. Может во второй версии и лучше, не знаю, пока тестировались на 1.4.2

К слову, это эрлангодерьмо даже не отпрофилировать по-человечески.

картинка по мотивам


Похоже, что риак - это просто распределенная мапа - и ничего более.

Ну да... А ты не знал? Огромное количество NoSQL баз типа ключ-значение. Даже всякие CouchDB, MongoDB и CouchBase.

ИЧСХ, требование присутствия всего индекса в памяти, как бы обязательное. Т.е. абы как индексы раздавать (даже первичные) не выйдет. В противном случае, внезапно, наступит катаклизм.

NoSQL — это прежде всего простота и вынос части логики хранения из СУБД в приложение.

Вот.

Macil ★★★★★ ()
Ответ на: комментарий от Macil

Нет, не знал. Кстати, в Basho тоже не знали, мы вчера с ними по скайпу общались, они, скажем так, сильно удивились. В 2.0 они вон кричат про пионерские разработки в области распределенных структур, про быстрые распределенные атомарные счетчики и т.п.

Я вот не вижу проблем вместо мапы сделать эффективную мультимапу хотя бы.

Насчет индексов - отдельная песня. Кстати, риаковские индексы вовсе целиком в памяти не хранятся. Они по сути и не отдельная сущность а хук на вставку, складывающий в риак же некую несложную структурку, полученную из блоба на входе. Но вот почему это приводит к десятикратному дропу производительности и не скалируется - я не знаю.

vsn ()
Ответ на: комментарий от vsn

вовсе целиком в памяти не хранятся

Тем хуже для вас. Прикинь, сколько стоит их «поднимать»...

Macil ★★★★★ ()

да, к сожалению новомодные nosql ничего не дают не только в производительности, но и еще и тону гемороя привносят.

Redis только ничего, но у него своя ниша, как основное хранилище данных я бы его не стал использовать.

В остальном стоит придерживаться высказывания «Да просто этим ребятам совсем нечего терять, они же все данные в монге хранят» ©

umren ★★★★★ ()

соболезную но http://ru.wikipedia.org/wiki/Теорема_CAP

про ключ-значение (мапы/хэши по простому) - вещь универсальная , особенно когда либо нет либо поплыла классификация гарантирующая , что у объекта Я вида А действительно ровно столько(не меньше(ну ок нуллы(н/а) выручат) и не больше(хм паразитная таблица в реляционной)) свойств сколько представителю вида А полагается по «метасхеме»

мапы(ну и мультимапы чё уж) вообще круты когда недостаточно инфы априорно для наложения той или иной «регулярной» структуры на возможные будущие связи в данных.

но вот плакатся глобально на ноускль только за косяк реализации это победа.

qulinxao ★★☆ ()

Для какой задачи вы риак юзаете?

SAA ★★★ ()
Ответ на: комментарий от SAA

Большое количество часто появляющихся мелких однотипных объектов, у которых есть пара меняющихся атрибутов.

vsn ()

Огласите тз на nosql. Зачем вам по одному ключу куча документов? На жабе пишите application? Посмотрите в сторону nosql решений на жабке, на C. Всякие ArangoDB есть, где движок V8.

menangen ★★★★★ ()
Ответ на: комментарий от menangen

Заставили, скажем так.

А по одному ключу куча документов - ну вот нужны связки 1-many, никуда без них по ТЗ.

vsn ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.