LevelDB. Апокалиписис

Ты уже купил садомазо костюмчик?

Что это делает в моих толксах и как из этого сотворить годный хохлосрач?

любители nosql и жаба-скрипта должны страдать :)

MultiMaster в Redis есть только в RedisCluster, который не готов для продакшена. Или что-то изменилось за последнее время?

да

а альтернативы?

хипстеры должны страдать :)

Обобщил.

MySQL/Galera (:
А что, мультиастер есть, а в галере он даже довольно надёжный.

cassandra

Я вообще не разработчик, и сильно отстал от моды... Для меня есть две БД - postgresql когда нет денег и Oracle когда есть денег. Если нужно очень много данных с высокой скоростью и мало логики, то MySQL с патчами для raw доступа к таблицам мимо SQL (сам не пробовал, но решение выглядит просто и элегантно).

Всё годами проверено и идеологически масштабируется куда угодно.

ты решил каждый спринт в свой жж на лоре документировать или помощи ищешь?

чувак, твои посты полны боли и отчаяния. надеюсь, ты будешь жить

А зачем тебе мульти-мастер?

Если не важна консистентность и устроят простои при перераспределении ключей при вылете машин.

Абаснуй откуда простои и зачем перераспределять ключи? При выпадении реплики чтение происходит с других реплик (ну или не происходит вообще, если режим чтения уберпараноидальный).

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

Маладец, все правильно написал.

не знаю, мне так сказали

и то, и другое.

Зы. А еще лучше daily standups на Лоре делать

Node.JS

Автоматически не нужно.

Riak

Хрень, а не хранилище в плане тормозов, логов и административного юзабилити. riak обычно относят на помойку ещё задолго до первого продакшена. Не нужно. Если нужно dynamo, то осиль кассанду.

LevelDB

Это быстрое *локальное* KV-хранилище, ни о какой репликации там речи не идёт by-design.

Redis

Осиль уже наконец elasticsearch, а не эти пионерские поделки с блобиками вместо значений.

я еще не вышел за рамки спринта

Абаснуй откуда простои и зачем перераспределять ключи?

В случае dynamo-шардинга: множество ключей кластера формирует замкнутое кольцо, отрезки этого кольца закреплены за конкретными узлами, равно как и их реплики. Очевидно, что в случае выпадания узла, кластер станет работать неоптимально:
1. Скорость исполнения части операций снизится.
2. Некоторые данные могут оказаться незарезервированными в кластере. Т.е. было две копии, осталась одна.
При добавлении новой ноды в кластер — всё тоже вполне очевидно.

Но откуда у Reset появились простои при перераспределении ключей — загадка.

Это быстрое *локальное* KV-хранилище, ни о какой репликации там речи не идёт by-design.

а чем я занимался в рамках этого спринта?

LevelDB has a small set of primitives. This allows more complex features such as replication, map-reduce, pub-sub, etc. to be published as modules on package management systems such as npm or clibs . Competition leads to innovation!

а чем я занимался в рамках этого спринта?

Ты делал троллейбус из буханки.

OK. А как мне тогда создавать реплицируемое хранилище?

Выше ведь уже упомянули и про postgre и про oracle и про mysql. А вообще мультимастер не нужен.

А чем оракул круче постгреса?

Абаснуй откуда простои и зачем перераспределять ключи?

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

При выпадении реплики чтение происходит с других реплик

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

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

Консистентность есть только на момент записи.

Но откуда у Reset появились простои при перераспределении ключей — загадка.

Снижение времени ответа на порядки я считаю за простой. У тебя было 10000rps, а становится 100. Только 1% клиентов получает ответ. Если это не простой, то что это?

Смотря что ты собрался хранить. Можно посмотреть на hdfs или hbase.

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

а что нужно? Master-Slave?

Ну я как минимум понимаю для чего нужен мастер-слейв. Какой прок от мультимастера - загадка.

10000 и 100 это реальные цифры, или с потолка? Кажется ты драматизируешь.

Реальные цифры, поэтому мы в своем проекте не смогли это использовать. Я вообще сейчас не очень понимаю для каких use-case можно использовать hash-ring'based nosql решения.

Что-то уж очень круто. Может где-то что-то недокрутили?

Видать дело в руках, у меня ниче такого не наблюдается, ни при добавлении новых хостов, ни при «компактификации».

А как мне тогда создавать реплицируемое хранилище?

Лучше скажи, что именно хранить собрался и как с этим работать. Какие данные (мелкие/крупные), чтение по random-access или сверсткой, и т.д.

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

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

Скорее всего нагрузка маленькая. У hash-ring физика работы такая, что по другому там быть просто не может. Система уходит в диски и всё стоит колом.

А RAMы сколько было? Касандре для адекватной работы нужно очень много памяти. Может какие-то индексы (помнится их там много всяких разных) в память не влезали?

Какая разница? Данных всё равно больше и их надо физически двигать на диске.

Много памяти нужно касандре не для того что-бы хранить в ней данные, а для того что-бы хранить в неё индексы позволяющие меньше дёргать HDD.
Вообще работа с диском в касандре сильно оптимизирована. При миграции блоков ключей «физически двигать на диске» ничего не надо, надо линейно прочесть файл с диска и залить его в сеть (ну и на другом конце принять его из сети и линейно записать на диск). Это дёшево.

Нагрузка вполне Ок, по 30 террабайт в день записываем. Ринг архитектура очевидно к дискам отношение имеет опосредственное, а внутренняя архитектура кассандры наоборот заточена для облегчения доступа на диск.