1. Да, вы правы, конфигурация кластера должна быть такой же, но по памяти и CPU не обязательно. На тестовом кластере такое не развернуть. Для создания тестовой зоны мы используем XDCR с фильтрацией.
2. Да, +gracefull то, что сервер можно обновлять сразу. а не после завершения ребаланса. То есть небольшой выигрыш по времени.
3. Не совсем понял ваш вопрос. По работе у нас так, если у нас выходят больше 3 серверов, то приложения в автоматическом режиме переключаются на резерв.
Мониторинг реализован через API Couchbase, snmp и самописный миб + визуализация
1. Бекап у нас реализован средствами СХД. Но фактически при факторе репликации 2 и резерва маловероятна физическая потеря данных. А вот логическая порча данных заставит откатываться на бекап или же пролить кеш с нуля.
Вы делаете полный бекап?
2. Мы не выводим основной кластер из эксплуатации(простоя нет). Зависит от фактора репликации, у нас он установлен в 2, то есть мы можем вывести 2 сервера единовременно. Но при обновлении всего кластера фактически мы проводим две больших ребалансировки при отсутствии буферного сервера, и одну если есть.
Алгоритм при факторе репликации 1
а. выводим сервер через gracefull, и делаем ребаланс (получаем кластер -1 сервер) и обновляем сервер
б. Далее делаем добавление обновленного сервера и удаление следующего через add/remove, главное это сделать одновременно. после запускаем ребаланс, в этом случае будет просто переливка данных между этими серверами. на 3.5 TB у нас занимал до 10 минут. И так пока не прогоним все сервера.
г. Добавление последнего сервера в кластер, «большой» ребаланс
3. С прогревом сталкивались только при падении нод, при не правильной конфигурации ОС. А так как на отдельном взятом сервере не так много данных, так что то прогрев у нас проходил достаточно быстро.
Пока не могу ответить на Ваш вопрос. Напишу коллегам из CouchBase, но скорость их ответа не гарантирую.
Вариантов реализации множество. В некоторых случаях скорость определяет многое. Так как это потребность наших клиентов. Клиент не будет ждать, когда же разблокируется счёт по балансу, очень многим важно положить денег и сразу быть на связи.
Потом надо изучать что и как шардировать, в биллинге может очень много перекосов. Какой софт использовать, его стоимость. Стоимость разработки софта для него и поддержки.
Это дополнительные сложности в эксплуатации и дополнительные архитектурные решения. Опять же большой риск получить перекос данных.
Опять же от разработчика требуется усложнить приложения.
Под каждую задачу надо рассматривать индивидуальное решение.
Основной плюс использования In-Memory, это быстрый доступ к данным. В Couchbase есть два варианта кеша, с записью на диск(для старта с диска) или полностью в памяти. Но в последнем случае при проблемах по тому же питанию, кеш мы будем вынуждено проливать с нуля.
В другом кластере, с онлайн обновлением из промышленной.
То есть нам нужно получить актуальную бизнес копию для тестирования. Причем, копия должна обновляться регулярно. Делать полный импорт/экспорт (полтора терабайта в сутки) затратно
шардить можно, не спорю, а как шардить данные из одной таблицы с высокой нагрузкой на запись и изменение? На оракле возникает конкуренция и в целом падает производительность.
Но помимо этого мы можем упереться в производительность СХД. NoSQL позволяет использовать локальные диски, или же отдельные массивы для каждого сервера.
Тот же RAC от Oracle, на определенных этапах спасает. Пока можно разделить потоки и пока хватает производительности СХД.
Для примера, генерация редо на некоторых наших таблицах может достигать до 200 MB/s
У нас собственно две БД сражаются за пальму первенства. С точки зрения разработки Tarantool сложнее. Да и Tarantool не сколько сыроват, но совместно с Mail.ru, МФ его дорабатывает.
почему не скачанное с магазина приложений? с 4PDA, там то оно может быть изменено уже.
А что есть что отменять? там же было взаимодействие двух ведомств и ни где не фиксировали указами. Там вроде было только постановление.
Помимо того что при подаче через госуслуги было указано что до 31.12.2022
Активных 3
Про открытый доступ не думали, в теории можно. Но это надо обсуждать с коллегами можно или нет. Возможно отдельная статья под это дело будет.
2. Да, +gracefull то, что сервер можно обновлять сразу. а не после завершения ребаланса. То есть небольшой выигрыш по времени.
3. Не совсем понял ваш вопрос. По работе у нас так, если у нас выходят больше 3 серверов, то приложения в автоматическом режиме переключаются на резерв.
Мониторинг реализован через API Couchbase, snmp и самописный миб + визуализация
Вы делаете полный бекап?
2. Мы не выводим основной кластер из эксплуатации(простоя нет). Зависит от фактора репликации, у нас он установлен в 2, то есть мы можем вывести 2 сервера единовременно. Но при обновлении всего кластера фактически мы проводим две больших ребалансировки при отсутствии буферного сервера, и одну если есть.
Алгоритм при факторе репликации 1
а. выводим сервер через gracefull, и делаем ребаланс (получаем кластер -1 сервер) и обновляем сервер
б. Далее делаем добавление обновленного сервера и удаление следующего через add/remove, главное это сделать одновременно. после запускаем ребаланс, в этом случае будет просто переливка данных между этими серверами. на 3.5 TB у нас занимал до 10 минут. И так пока не прогоним все сервера.
г. Добавление последнего сервера в кластер, «большой» ребаланс
3. С прогревом сталкивались только при падении нод, при не правильной конфигурации ОС. А так как на отдельном взятом сервере не так много данных, так что то прогрев у нас проходил достаточно быстро.
Пока не могу ответить на Ваш вопрос. Напишу коллегам из CouchBase, но скорость их ответа не гарантирую.
Вариантов реализации множество. В некоторых случаях скорость определяет многое. Так как это потребность наших клиентов. Клиент не будет ждать, когда же разблокируется счёт по балансу, очень многим важно положить денег и сразу быть на связи.
Потом надо изучать что и как шардировать, в биллинге может очень много перекосов. Какой софт использовать, его стоимость. Стоимость разработки софта для него и поддержки.
А вообще интересная дискуссия.
Всю архитектуру раскрыть не могу, но скажем так, в нашем случае это было менее трудозатратно. Тем более что трансформация ещё идёт.
Опять же от разработчика требуется усложнить приложения.
Под каждую задачу надо рассматривать индивидуальное решение.
Основной плюс использования In-Memory, это быстрый доступ к данным. В Couchbase есть два варианта кеша, с записью на диск(для старта с диска) или полностью в памяти. Но в последнем случае при проблемах по тому же питанию, кеш мы будем вынуждено проливать с нуля.
То есть нам нужно получить актуальную бизнес копию для тестирования. Причем, копия должна обновляться регулярно. Делать полный импорт/экспорт (полтора терабайта в сутки) затратно
Опять же это надо продумывать, иначе можно получить перекос данных и нагрузки. На пример тот же Mongo
Но помимо этого мы можем упереться в производительность СХД. NoSQL позволяет использовать локальные диски, или же отдельные массивы для каждого сервера.
Тот же RAC от Oracle, на определенных этапах спасает. Пока можно разделить потоки и пока хватает производительности СХД.
Для примера, генерация редо на некоторых наших таблицах может достигать до 200 MB/s
Кейс применения — адресный справочник (КЛАДР)
Не пробовали в ТП писать? И них очень много недокументируемых «фич»
Кассандра то же хорошая БД. Но просто сделать копию БД без полного бекапа проблематично. Вот пытаемся изобрести. Если уже есть способы подскажите