Какое key-value хранилище лучше?

Question

[kazmiruk]

Так как я не получил ни одного ответа на свой предыдущий конкретный вопрос попробую задать более обще (и немного холиварно). Надеюсь, это вызовет больший интерес и серди ответов я смогу найти подсказку.


Какое key-value хранилище лучше подходит для хранения данных сессий?

Какое key-value хранилище лучше для кеша данных?

Стоит ли использовать два различных key-value хранилища в одном проекте под разные типы данных?


Только если Вы будете говорить, что key-value %name% самое крутое, то обоснуйте пожалуйста.

Answer 1

[denver]

Нет лучшего NoSQL хранилища вообще, есть под задачи, у каждого плюсы и ограничения. Redis супербыстр когда оперативки больше чем данных, иначе он часто подгружает с диска и сводит на нет скорость (если это еще не переделали), хорош для очередей сообщений, списков (встроены сортировки), всякой мелкой инфы. memcache (не memcached) самый быстрый но не флашит на диск ничего (собсвенно оттого и). memcached простейший key-value с флашем (хорош для очередей сообщений и всяких счетчиков). У последних двух особенность multiget — взять много ключей за раз работает столько же сколько и один, так что хорош для хранения «превьюшек» данных по их id, когда сортированные списки хранятся где-то еще (в редис). MongoDB не просто key-value, в ней можно хранить целые документы (пост со всеми комментариями), некий компромисс между nosql и RDBMS. Hbase уже совсем замена RDBMS, один из самых быстрых когда речь идет о IO диска, соответственно эта NoSQL для постоянного хранения стопитцот миллиардов данных. Cassandra похоже конкурент Hbase, но аутсайдер, т.к. фейсбук/твиттер от нее отказываются ;) Про CouchDB и Riak я ничего особенного не слышал (может кто дополнит — мне интересно)

Comments

[kazmiruk]

О, спасибо ) Очень полезная инфа. А теперь более конкретный вопрос: как вы оцениваете такую связку MongoDb — как основное хранилище данных (пользователи, заказы, товары, комментарии и др.), Redis(отдельный сервер) — хранение сессий и счетчиков посещений + другой статистики, которая будет выбираться может раз в месяц, но ее будет много (на сколько я понимаю, сессии в редисе, как часто используемые данные будут хранится в оперативной памяти, а все что в нее не влезет из статистики на винте) и memcache (или memcached? после Вашего ответа стал сомневаться) для кеширования результатов запросов к mongodb + других данных, требующих кеширования. Еще очень интересно про Hbase. Пойду читать что это такое.

[denver]

В целом все верно рассуждаете, но дьявол в деталях и свою собаку я только надкусил, не могу предостеречь :) если из более опытных не подскажет, то определитесь пока с праймари хранилищем — побенчмаркайте MongoDB vs Hbase (если не испугает сложность настройки последнего), все остальное (если не подойдет) померять/поменять будет не так сложно.

[kazmiruk]

С Mongo уже определился. Hbase как бы не привлекал (не хочу начать сравнивать и расстраиваться )), но на монго уже часть проекта написано ) переделывать пока не хочется

[ToSHiC]

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

[kazmiruk]

Ну не прямых селектов. Аггрегаций. На сколько я понимаю быстрее залезть в хештаблицу и взять значение, чем вызывать мап\редьюс. Или я не прав? Все таки монго хоть и хранит все данные в памяти, но алгоритм их выборки не может быть быстрее O(1) (насколько помню из универского курса такой для хеш таблиц)

[denver]

ЗЫ. memcached не для очередей, это memcacheq для очередей.

[ToSHiC]

Вообще, хэш-таблица будет быстрее, но тут такой момент: если ваша агрегация занимает меньше 1мс (а если все данные влезут в память — то это вполне вероятная ситуация), то никакое кэширование не нужно.

[kazmiruk]

Хм. А если таких запросов будет миллион? Каждый раз считать и тратить на это 1 мс? Или один раз посчитать и кинуть в кеш, а потом брать оттуда. Или Mongo использует что-то для кеширования результатов?

[ToSHiC]

Так сходить в мемкэш — тоже не бесплатно, это несколько сисколов + сеть или иной rpc. Тестить надо на боевых данных и боевой нагрузке. Судя по документации, кеширования результатов в монге нету.

[kazmiruk]

Я просто исходил из того, что моного шардится и находится на другом сервере. По этому пункту они в с кешом в равных условиях. Но если кешу требуется O(1) как хеш таблице, то mongo явно больше, так как там используется b-tree (получается o(logN), поравьте если я ошибаюсь), а кеширования запросов вроде нет. Вот отсюда и возник вопрос кеширования результатов запросов к монго.

[ddosia]

Про Riak могу сказать, это очень легко масштабируемая система, практически линейно: вкинул ноду, получил 1/n. Реальные примеры: в воксере помоему около 100 нод в кластере. + можно тюнить некоторые параметры во премя запросов, типа таких: хочу что бы эти данные лежали минимум на 5ти нодах, или читались миним с трех. Некоторые вещи там сделать трудно или не возможно, т.к. там нет атомарных операций изменения части данных. Автоматический шардинг, данны размазываются по нодам на основании хэшей ключа. Есть мапредьюс по данным.

[kamiram]

riak крайне хорош

Answer 2

[Mikhail Osher]

Ходят слухи, что Redis очень даже неплох. Как минимум для сессий.

Comments

[kamiram]

плох. он весь в оперативе

Answer 3

[Malerok]

Сессии — SessionStorage;
Данные — LocalStorage;
Конечно разумно если есть специфические отличия в типах хранящихся данных.

Comments

[kazmiruk]

Я может чего-то не понимаю, но я говорил про nosql на стороне сервера, а не storage у клиента.

Answer 4

[Disasm]

Kyoto Cabinet, позволяет делать порядка 1 миллона операций записей в секунду, операций чтения ещё больше.

Comments

[kazmiruk]

Но о протухании данных надо будет заботиться самому, так как там, на сколько я знаю, нет механизма инвалидации по времени? Или я не прав? В итоге, при хранении сессии мне нужно будет заботиться о том, чтобы чистить от старых сессий, пользователи которых уже не заходят?

[ToSHiC]

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

[kazmiruk]

Да и если честно какие-то нереальные цифры… 1 000 000 операций в секунду. Можно где-то на бенчмарки посмотреть? Особенно интересует по чтению.

[ddosia]

Я бы тоже хотел поглядеть на бенчмарки. Интересно как сопоставить два коммента выше: Disasm пишет про 1m записей в секунду, а ToSHic что после 10m уже тупит => токи кабинет будет тупить через 10ть секунд работы?

Answer 5

[EugeneOZ]

1) Redis
2) Redis или MongoDB
что тут обосновывать — каждый кулик своё болото хвалит, всё субъективно :)

Comments

[kazmiruk]

Ну хотя бы объясните почему Вы его хвалите. Если первый пункт мне понятен и я в принципе согласен, то второй — не понятно совсем. Ладно редис, но почему монго? Разве это будет эффективно для кеша данных? Вы же когда разрабатывали такую архитектуру из чего-то исходили, а не просто сказали «А здесь мы будем использовать редис. потому что так прикольно». Вот именно эти рассуждения мне и интересны.

[EugeneOZ]

Конкретно для кэша я стараюсь использовать Redis, т.к. он быстрее Memcached, гораздо более функционален и не боится перезагрузки сервера. Разницы между сессиями и данными я не вижу — сессии это тоже вариант данных.
Для хранения (а не кэша) самих данных, если хочется именно NOSQL, мне нравится идея и детали реализации MongoDB.

[kazmiruk]

А есть ли какие-то бенчмарки надежные по скорости? Просто облазил все и везде результаты разные. Очень смущает то, что мемкешд простой как веник, но медленней, чем redis, у которого функциональных возможностей на порядок больше. Если действительно так, то именно такое решение и буду использовать.

[kazmiruk]

www.percona.com/live/mysql-conference-2012/sessions/caching-memcached-redis Вот кстати очень интересные результаты. Мемкешд медленней, но стабильней, а редис большую часть времени был быстрее, но периодами проседал ниже мемкешда. Правда потом был тест разных версий редиса. Там вроде ситуация улучшилась

[EugeneOZ]

Я использую Redis уже несколько лет и за это время не потерялось ни байта данных. Были и перезагрузки, и нагрузки с десятками запросов одновременно (не в секунду, а именно одновременно, в одной доле секунды).

[EugeneOZ]

Как я уже говорил, всё это субъективно. И memcached менее надёжен был в моих реальных использованиях, а не в синтетических тестах. Я не заставляю Redis дампить в append после каждой транзакции — это полнейшая глупость. Дамплю реже, зато не привязываю его к производительности диска. Memcached вообще не дампит на диск — как тут можно сравнивать их с Redis, настроив Redis так, чтобы он постоянно писал в append? (это последний тест по той ссылке, которую вы дали).

[kazmiruk]

А что сделает редис, если ему запретить писать на диск при нехватке памяти? Начнет вытеснять старые данные?

[EugeneOZ]

А редис не пишет на диск при недостатке памяти, он просто не сохраняет. Диск это лишь копия данных, все данные должны влезать в оперативку. Раньше была возможность виртуальной памяти, но они вовремя осознали, что этоо маразм и это убьёт их репутацию, и сейчас этот функционал deprecated, в новых версиях его не будет.

Answer 6

[Beholder]

Про BrekeleyDB (в том числе Java edition) почему никто не упоминает?

Comments

[ToSHiC]

А в контексте чего о нём упоминать? Киотский кабинет и то быстрее.

[kazmiruk]

Беркли ссудя по бенчмаркам мне вообще не подойдет. Какой-то медленный он.

[kamiram]

туповатая но вцелом порой крайне полезна .

Answer 7

[denver]

Стоит ли использовать два различных key-value хранилища в одном проекте под разные типы данных?

Обязательно, если под типом данных имеется в виду не картинки vs текст :) а время жизни данных, их количество, их актуальность, необходимость сортировок, фильтрации, поиска и т.п. Вон для кроме MySQL + Sphinx вроде и нет ничего лучше (готового).
И вообще, NOSQL — not only SQL, что намекает ;)

Comments

[denver]

«Вон для поиска...», пардон.

[kazmiruk]

Нет, не картинки и текст ) Все таки склоняюсь к связке как описал выше в ответе.

Answer 8

[xSkyFoXx]

Если Вас не беспокоит вендор лок — порекомендовал бы google datastore.

Comments

[kazmiruk]

Наверное все таки беспокоит. Люблю все контролировать )

Answer 9

[Sergey Lerg]

Посмотрите в сторону LevelDB, он имеет высокую производительность, но не имеет собственно сервера. Встраивается напрямую в приложение.

Comments

[kazmiruk]

Интересное решение, но уж слишком много нужно писать для его запуска, нет времени, чтобы разобраться досконально, а не разобравшись можно написать фигню ) Но спасибо )

Answer 10

[Алексей Акулович]

Вопрос в догонку :)
А как насчет выбора хранилища для сессий в режиме мастер-мастер, расположенных в разных европейских странах? MongoDB не справлялся.

Comments

[kazmiruk]

Ну сам еще не до конца определился, но вроде все сводится к тому, что идеальное хранилище для сессий — редис. Подводных камней по отзывам сильно не заметно + к концу года обещают первый стейбл кластера, что позволит не писать свою обертку с использованием консистивного хеша, а заюзать все из коробки для горизонтального масштабирования и высокой доступности.

[kazmiruk]

Ну и скорость работы у него — одна из самых высоких. По некоторым бенчмаркам его обходит только мемкеш (и то не по всем, поэтому сомневаюсь в их честности)

[Алексей Акулович]

В моем случае принципиально важна работа двух синхронных мастеров. Порядка 50-100 select/update в секунду на каждый. В свое время не вышло так сделать с Редисом. И кластер его был в какой-то совсем уж бете.

[ToSHiC]

Обычно, если вы хотите мастер-мастер, то что-то в вашей концепции неверно :) Какие конкретно у вас были требования к базе? Пробовали что нибудь из ребра AP теоремы CAP? Если отказаться от строгой консистенции то можно получить хорошие цифры в случае географически распределённых ДЦ.

[Алексей Акулович]

Нужны сессии на всех frontend'ах, разделенных на две пачки по геоположению. Делать двойные запросы на чтение/запись к двум независимым хранилищам не лучшее решение как-минимум в плане отказоустойчивости. В CAP интересует, если не ошибаюсь под конец рабочего дня, скорее сторона CA: данные должны быть одинаковые везде, либо отсутствовать там, где они могут быть некорректны/неактуальны.

Answer 11

[motl]

посмотрите также Tokyo Cabinet как альтернативу memcache.

Comments

[Nail]

Не наступите на мину.
tokyo cabinet:
— больше не поддерживается авторами
— на деле глючный (падает)
— на деле тормозной во время синков на диск
— тюнинг производительности практически не документирован

[kazmiruk]

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

Answer 12

[Nail]

На самом деле 2 реальных альтернативы:
1. Когда данные помещаются в память: Redis (мемкэш — вчерашний день, уступает по функциональности)
2. Когда не помещаются: обертка над handlersocket (у него нет автоматического expire, но если данные на диске, оно не нужно). Обертка, потому что в mysql 5.6 возможно будут лучше варианты.

Все остальное — либо экзотика, либо медленное, либо вообще из другой оперы.

Comments

[kazmiruk]

В принципе есть возможность все уместить в память для кеша. Если перестанет умещаться, то вертикальное масштабирование, а потом горизонтальное. А что Вы скажете про монго? Вроде как гибридное решение он вполне не плох. Часто используемые данные в памяти, остальные на диске + автошардинг из коробки (на прошлом проекте использовали самописный шардинг для mysql — это ад. Все дико неудобно, постоянно надо думать о том на какой шарде что находится. в монго тоже не стоит забывать, но для простых случаев даже не обязательно думать о том, что у нас несколько серверов)

[kamiram]

handlersocket - удивительная штука. когда первый раз замерил скорость тихо прифигел. главный бонус - можно с однимии теме же данными работать и в sql режиме и в nosql.