Couchbase в телекоме

[wrmax]

в МегаФон мы применяем Couchbase и Tarantool

А когда применяете Tarantool?
Для меня интересно, стоит ли использовать Tarantool для кэширования редко меняющихся данных или текущего решения с Couchbase более чем достаточно.

[gorynko]

У нас собственно две БД сражаются за пальму первенства. С точки зрения разработки Tarantool сложнее. Да и Tarantool не сколько сыроват, но совместно с Mail.ru, МФ его дорабатывает.

Кейс применения — адресный справочник (КЛАДР)

[vadlit]

Странно. У нас в проекте couchbase вообще не прижился, пришлось отказаться в пользу кафки.
Проблема была в том, что couchbase lite периодически (достаточно часто) впадал в странное состояние, когда он должен синкаться с syncgateway, но по факту синхронизации не происходит. Помогал только рестарт клиента.
Танцы с бубнами не помогли, решили что дешевле отказаться от него

[gorynko]

Судя по описываемым продуктам, вы пытаетесь использовать для мобильных приложений. На таких кейсах к сожалению не проверяли.

Не пробовали в ТП писать? И них очень много недокументируемых «фич»

[vadlit]

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

[gorynko]

С этим вполне хорошо справляется XCDR, без использования syncgateway

[blind_oracle]

Работал довольно плотно с Couchbase. Моё мнение — лютое УГ. Какое то нагромождение мемкеша, языка запросов N1QL приделанного сбоку и прочего.

При не очень сложных запросах сжирал всю память на Query нодах и падал.

Может, конечно, мы его неправильно готовили, но всё делалось в соответствии с бест практис.

Уехали на Кассандру и довольны.

[gorynko]

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

Кассандра то же хорошая БД. Но просто сделать копию БД без полного бекапа проблематично. Вот пытаемся изобрести. Если уже есть способы подскажите

[blind_oracle]

Да, это было пару лет назад, версия была вроде 4.5 или что-то такое. Может все уже улучшилось…

Но просто сделать копию БД без полного бекапа проблематично. Вот пытаемся изобрести. Если уже есть способы подскажите

Не совсем понял что вы пытаетесь сделать. Просто создать копию БД в том же кластере под другим именем? Или в другом кластере?

Можно почитать www.datastax.com/dev/blog/simple-data-importing-and-exporting-with-cassandra

И посмотреть на github.com/gianlucaborello/cassandradump

[gorynko]

В другом кластере, с онлайн обновлением из промышленной.
То есть нам нужно получить актуальную бизнес копию для тестирования. Причем, копия должна обновляться регулярно. Делать полный импорт/экспорт (полтора терабайта в сутки) затратно

[avidcrawler]

> Среднее время отклика (50%) — до 5 мс (в рамках одного ЦОД).
Уточните, пожалуйста, это среднее арифметическое или медиана?

[gorynko]

Скорее количественный показатель. Если брать медиану то она должна быть в районе 3.

[gorynko]

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

Но помимо этого мы можем упереться в производительность СХД. NoSQL позволяет использовать локальные диски, или же отдельные массивы для каждого сервера.
Тот же RAC от Oracle, на определенных этапах спасает. Пока можно разделить потоки и пока хватает производительности СХД.

Для примера, генерация редо на некоторых наших таблицах может достигать до 200 MB/s

[blind_oracle]

а как шардить данные из одной таблицы с высокой нагрузкой на запись и изменение?

Я думаю товарищ тут имел в виду application-level шардинг, а не partitioning — когда, например, все user-id разбиваются на бакеты\токены по какому-то алгоритму (хешу) и бакеты эти раскидываются по независимым кластерам SQL. Маппинг бакет -> кластер хранится где-то в быстродоступном месте вроде memcache\redis\просто в SQL отдельном.

Примерно таким же образом работает и Кассандра под капотом, но это абстрагировано от клиента.

[gorynko]

Это уже не совсем классический SQL :), когда объединение таблиц можно проводить на БД, а не на стороне приложений.

Опять же это надо продумывать, иначе можно получить перекос данных и нагрузки. На пример тот же Mongo

[gorynko]

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

[gorynko]

Это дополнительные сложности в эксплуатации и дополнительные архитектурные решения. Опять же большой риск получить перекос данных.
Опять же от разработчика требуется усложнить приложения.

Под каждую задачу надо рассматривать индивидуальное решение.

Основной плюс использования In-Memory, это быстрый доступ к данным. В Couchbase есть два варианта кеша, с записью на диск(для старта с диска) или полностью в памяти. Но в последнем случае при проблемах по тому же питанию, кеш мы будем вынуждено проливать с нуля.

[gorynko]

Всю архитектуру раскрыть не могу, но скажем так, в нашем случае это было менее трудозатратно. Тем более что трансформация ещё идёт.

[gorynko]

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

Потом надо изучать что и как шардировать, в биллинге может очень много перекосов. Какой софт использовать, его стоимость. Стоимость разработки софта для него и поддержки.

А вообще интересная дискуссия.

[lexalex]

Спасибо за статью. Позвольте разузнать больше деталей.

1. Как именно у вас реализован бекап? Утилитами cbbackup/cbbackupmgr непосредственно на серверах кластера? На мастер или слейв кластере? Или как-то ещё? В моем эксперементе с помощью cbbackup удалось достичь скокрость всего в 5-7 МБ/с, что безусловно медленно для больших баз.

2. Как производится обновление серверов кластера? Ведь при отключении одной ноды, статус кластера меняется на unhealthy, а ребалансировка требует времени. На этот период используется только слейв кластер в режиме RO?

3. Можно ли как-то форсировать «прогрев» бакет в боевом кластере без перезапуска ноды? Иногда случается превышение high watermark и данные выгружаются из памяти, что недопустимо для некоторых бакетов в нашей архитектуре.

[gorynko]

1. Бекап у нас реализован средствами СХД. Но фактически при факторе репликации 2 и резерва маловероятна физическая потеря данных. А вот логическая порча данных заставит откатываться на бекап или же пролить кеш с нуля.
Вы делаете полный бекап?

2. Мы не выводим основной кластер из эксплуатации(простоя нет). Зависит от фактора репликации, у нас он установлен в 2, то есть мы можем вывести 2 сервера единовременно. Но при обновлении всего кластера фактически мы проводим две больших ребалансировки при отсутствии буферного сервера, и одну если есть.

Алгоритм при факторе репликации 1
а. выводим сервер через gracefull, и делаем ребаланс (получаем кластер -1 сервер) и обновляем сервер
б. Далее делаем добавление обновленного сервера и удаление следующего через add/remove, главное это сделать одновременно. после запускаем ребаланс, в этом случае будет просто переливка данных между этими серверами. на 3.5 TB у нас занимал до 10 минут. И так пока не прогоним все сервера.
г. Добавление последнего сервера в кластер, «большой» ребаланс

3. С прогревом сталкивались только при падении нод, при не правильной конфигурации ОС. А так как на отдельном взятом сервере не так много данных, так что то прогрев у нас проходил достаточно быстро.
Пока не могу ответить на Ваш вопрос. Напишу коллегам из CouchBase, но скорость их ответа не гарантирую.

[lexalex]

1. Бекап у нас реализован средствами СХД

Если я правильно понимаю, то в этом случае возможно восстановить только строго такую же конфигурацию кластера с ровно таким же кол-вом нод, а объем памяти серверов должен быть не меньше чем в исходном кластере. Т.е. не получится развернуть эти данные, например, на упрощенном тестовом кластере? (Вы, похоже, в т.ч. для этих целей используете XDCR)

2. Мы не выводим основной кластер из эксплуатации(простоя нет)

Ясно, спасибо за развернутый ответ.

выводим сервер через gracefull, и делаем ребаланс

Похоже, на этом шаге операцию gracefull можно заменить на remove с тем же эффектом.

3. С прогревом сталкивались только при падении нод

Ваша схема бакетов допускает падение active docs resident ниже 100%?

Напишу коллегам из CouchBase

Спасибо!

А как мониторинг метрик couchbase у вас реализован?

[gorynko]

1. Да, вы правы, конфигурация кластера должна быть такой же, но по памяти и CPU не обязательно. На тестовом кластере такое не развернуть. Для создания тестовой зоны мы используем XDCR с фильтрацией.
2. Да, +gracefull то, что сервер можно обновлять сразу. а не после завершения ребаланса. То есть небольшой выигрыш по времени.
3. Не совсем понял ваш вопрос. По работе у нас так, если у нас выходят больше 3 серверов, то приложения в автоматическом режиме переключаются на резерв.

Мониторинг реализован через API Couchbase, snmp и самописный миб + визуализация

[lexalex]

3. У нас, как я уже писал, рабочая схема предполагает храненние всех данных бакета в памяти, если происходит их выгрузка (например, при росте очереди записи на диск и нехватке выделенной бакету памяти), то это нештатная ситуация. В некоторых случаях достаточно хранения лишь части данных в памяти, и допускается, что некоторые запросы будут выполняться значительно дольше остальных, если запрошенные данные на диске. Интересно как у вас? Все данные бакета помещаются в памяти?

Кстати, какое общее кол-во бакетов?

Мониторинг реализован через API Couchbase, snmp и самописный миб

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

[gorynko]

У нас все данные могут помещаются в памяти, правда иногда используют swap, сейчас порядка 70% active docs resident, потихоньку увеличиваем.
Активных 3

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