Comments 29
в МегаФон мы применяем Couchbase и Tarantool
А когда применяете Tarantool?
Для меня интересно, стоит ли использовать Tarantool для кэширования редко меняющихся данных или текущего решения с Couchbase более чем достаточно.
Странно. У нас в проекте couchbase вообще не прижился, пришлось отказаться в пользу кафки.
Проблема была в том, что couchbase lite периодически (достаточно часто) впадал в странное состояние, когда он должен синкаться с syncgateway, но по факту синхронизации не происходит. Помогал только рестарт клиента.
Танцы с бубнами не помогли, решили что дешевле отказаться от него
Не пробовали в ТП писать? И них очень много недокументируемых «фич»
У нас не мобильное приложение (хотя эти продукты, конечно, на них направлены), у нас сервера, базы которых (используемые только на чтение) должны синхронизироваться с другой базой (используемой на запись).
В техподдержку не обращались. Так как кафка уже использовалась в других наших системах, мы решили просто перейти на нее и в этом продукте.
Работал довольно плотно с Couchbase. Моё мнение — лютое УГ. Какое то нагромождение мемкеша, языка запросов N1QL приделанного сбоку и прочего.
При не очень сложных запросах сжирал всю память на Query нодах и падал.
Может, конечно, мы его неправильно готовили, но всё делалось в соответствии с бест практис.
Уехали на Кассандру и довольны.
Кассандра то же хорошая БД. Но просто сделать копию БД без полного бекапа проблематично. Вот пытаемся изобрести. Если уже есть способы подскажите
Но просто сделать копию БД без полного бекапа проблематично. Вот пытаемся изобрести. Если уже есть способы подскажите
Не совсем понял что вы пытаетесь сделать. Просто создать копию БД в том же кластере под другим именем? Или в другом кластере?
Можно почитать www.datastax.com/dev/blog/simple-data-importing-and-exporting-with-cassandra
И посмотреть на github.com/gianlucaborello/cassandradump
Уточните, пожалуйста, это среднее арифметическое или медиана?
Но помимо этого мы можем упереться в производительность СХД. NoSQL позволяет использовать локальные диски, или же отдельные массивы для каждого сервера.
Тот же RAC от Oracle, на определенных этапах спасает. Пока можно разделить потоки и пока хватает производительности СХД.
Для примера, генерация редо на некоторых наших таблицах может достигать до 200 MB/s
а как шардить данные из одной таблицы с высокой нагрузкой на запись и изменение?Я думаю товарищ тут имел в виду application-level шардинг, а не partitioning — когда, например, все user-id разбиваются на бакеты\токены по какому-то алгоритму (хешу) и бакеты эти раскидываются по независимым кластерам SQL. Маппинг бакет -> кластер хранится где-то в быстродоступном месте вроде memcache\redis\просто в SQL отдельном.
Примерно таким же образом работает и Кассандра под капотом, но это абстрагировано от клиента.
Опять же это надо продумывать, иначе можно получить перекос данных и нагрузки. На пример тот же Mongo
Опять же от разработчика требуется усложнить приложения.
Под каждую задачу надо рассматривать индивидуальное решение.
Основной плюс использования In-Memory, это быстрый доступ к данным. В Couchbase есть два варианта кеша, с записью на диск(для старта с диска) или полностью в памяти. Но в последнем случае при проблемах по тому же питанию, кеш мы будем вынуждено проливать с нуля.
Всю архитектуру раскрыть не могу, но скажем так, в нашем случае это было менее трудозатратно. Тем более что трансформация ещё идёт.
Вариантов реализации множество. В некоторых случаях скорость определяет многое. Так как это потребность наших клиентов. Клиент не будет ждать, когда же разблокируется счёт по балансу, очень многим важно положить денег и сразу быть на связи.
Потом надо изучать что и как шардировать, в биллинге может очень много перекосов. Какой софт использовать, его стоимость. Стоимость разработки софта для него и поддержки.
А вообще интересная дискуссия.
1. Как именно у вас реализован бекап? Утилитами
cbbackup/cbbackupmgr
непосредственно на серверах кластера? На мастер или слейв кластере? Или как-то ещё? В моем эксперементе с помощью cbbackup
удалось достичь скокрость всего в 5-7 МБ/с, что безусловно медленно для больших баз.2. Как производится обновление серверов кластера? Ведь при отключении одной ноды, статус кластера меняется на unhealthy, а ребалансировка требует времени. На этот период используется только слейв кластер в режиме RO?
3. Можно ли как-то форсировать «прогрев» бакет в боевом кластере без перезапуска ноды? Иногда случается превышение high watermark и данные выгружаются из памяти, что недопустимо для некоторых бакетов в нашей архитектуре.
Вы делаете полный бекап?
2. Мы не выводим основной кластер из эксплуатации(простоя нет). Зависит от фактора репликации, у нас он установлен в 2, то есть мы можем вывести 2 сервера единовременно. Но при обновлении всего кластера фактически мы проводим две больших ребалансировки при отсутствии буферного сервера, и одну если есть.
Алгоритм при факторе репликации 1
а. выводим сервер через gracefull, и делаем ребаланс (получаем кластер -1 сервер) и обновляем сервер
б. Далее делаем добавление обновленного сервера и удаление следующего через add/remove, главное это сделать одновременно. после запускаем ребаланс, в этом случае будет просто переливка данных между этими серверами. на 3.5 TB у нас занимал до 10 минут. И так пока не прогоним все сервера.
г. Добавление последнего сервера в кластер, «большой» ребаланс
3. С прогревом сталкивались только при падении нод, при не правильной конфигурации ОС. А так как на отдельном взятом сервере не так много данных, так что то прогрев у нас проходил достаточно быстро.
Пока не могу ответить на Ваш вопрос. Напишу коллегам из CouchBase, но скорость их ответа не гарантирую.
1. Бекап у нас реализован средствами СХД
Если я правильно понимаю, то в этом случае возможно восстановить только строго такую же конфигурацию кластера с ровно таким же кол-вом нод, а объем памяти серверов должен быть не меньше чем в исходном кластере. Т.е. не получится развернуть эти данные, например, на упрощенном тестовом кластере? (Вы, похоже, в т.ч. для этих целей используете XDCR)
2. Мы не выводим основной кластер из эксплуатации(простоя нет)
Ясно, спасибо за развернутый ответ.
выводим сервер через gracefull, и делаем ребаланс
Похоже, на этом шаге операцию gracefull можно заменить на remove с тем же эффектом.
3. С прогревом сталкивались только при падении нод
Ваша схема бакетов допускает падение active docs resident ниже 100%?
Напишу коллегам из CouchBase
Спасибо!
А как мониторинг метрик couchbase у вас реализован?
2. Да, +gracefull то, что сервер можно обновлять сразу. а не после завершения ребаланса. То есть небольшой выигрыш по времени.
3. Не совсем понял ваш вопрос. По работе у нас так, если у нас выходят больше 3 серверов, то приложения в автоматическом режиме переключаются на резерв.
Мониторинг реализован через API Couchbase, snmp и самописный миб + визуализация
Кстати, какое общее кол-во бакетов?
Мониторинг реализован через API Couchbase, snmp и самописный миб
Интересное решение. В открытый доступ не планировали выложить?
Активных 3
Про открытый доступ не думали, в теории можно. Но это надо обсуждать с коллегами можно или нет. Возможно отдельная статья под это дело будет.
Couchbase в телекоме