Couchbase в телекоме

Цифровая трансформация является мировым трендом для крупного бизнеса и жизненно важна для адаптации  предприятия к современным потребностям клиента. Кроме обычной для крупных компаний проблематики централизации систем и объединения биллинговых систем и абонентских БД добавляются требования к высокой доступности и режиму работы в реальном времени к которому клиенты уже привыкли у лидеров индустрии (Google, Amazon, Netflix).


Новые вызовы требуют новых технологий и подходов, которые необходимы для сокращения времени внедрения удобных клиенту функций, персонализированных коммерческих предложений, быстрой реакции на предложения конкурентов, а так же контроля затрат на системы, ИТ инфраструктуру, датацентры  и квалифицированного персонала. Эти тенденции несут и большой минус: усложнение архитектуры и раздутые транзакционные базы данных, которые не справляются с потоком и обработкой информации. Технологии предыдущего поколения имеют потолок вертикального масштабирования. К примеру, экземпляр СУБД Oracle работает на пределе самого мощного сервера на процессорах x86 при нагрузке в миллиард транзакций в сутки.



Для того, чтобы выдержать подобную загрузку с которой уже давно сталкивается интернет индустрия используется новый стек технологий, таких как In-Memory кэши и NoSQL базы данных. Так, Apple применяет Cassandra, Сбербанк – Ignite (GridGain), в МегаФон мы применяем Couchbase и Tarantool.


В МегаФон используются разные архитектурные шаблоны для In-Memory СУБД:


  1. Простой кэш, обновляемый по расписанию или по событию из БД и приложений
  2. Все изменения в БД осуществляются через кэш (write-through сценарий), например, подключение Oracle клиента к DCP Couchbase

Для одной из наших систем принятия решений по жизненному циклу абонента мы используем первый шаблон, так как только одно приложение по совокупности данных принимает решение и отправляет его на все системы, в том числе и БД Oracle. Один из ярких кейсов использования жизненного цикла абонента – это блокировка и разблокировка по отрицательному балансу. Ведь все абоненты сотовых операторов после пополнения баланса хотят сразу быть на связи и совершать звонки.  Благодаря вынесенному отдельному приложению и Couchbase, мы смогли сократить время выхода из блокировки с 90 секунд до 30 и это еще не предел. В основную базу попадет только запись об изменении статуса абонента (рис. 1)



Рисунок 1 (Пример взаимодействия)

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


Почему мы остановили выбор именно на Couchbase? Для этого существует несколько причин.


Требование к производительности


  1. Обработка до 200000 запросов в секунду.
  2. Среднее время отклика (50%) — до 5 мс (в рамках одного ЦОД).
  3. Максимальное время отклика (99%) — до 15 мс (в рамках одного ЦОД).
  4. Максимальная производительность вставки 500 MB/sec
  5. Максимальное количество операций вставок 100000/с
  6. Максимальное количество операций изменений (обновлений документов) 100000/с
  7. Максимальная производительность изменений (обновлений документов) 500 MB/sec
  8. Максимальное количество операций чтений 100000/с
  9. Максимальная скорость чтения 500 MB/sec

Высокопроизводительный поиск по ключу и доступ к данным


В основе Couchbase лежит распределенное хранилище ключей (KV). Хранилище KV представляет собой чрезвычайно простой подход к управлению данными, который хранит уникальный идентификатор (ключ) вместе с частью произвольной информации. Само хранилище KV может принимать любые данные, будь то бинарный blob или JSON-документ. Благодаря простоте реализации KV доступ к данным обеспечивается с минимальной задержкой. Как показывает наш опыт, чаще задержки по сети в 2-3 раза выше, чем предоставление данных по ключу на стороне Couchbase.


Динамическая схема хранения(JSON)


Документы хранятся на сервере Couchbase в формате JSON. Формат поддерживает как базовые типы данных, такие как числа, строки и сложные типы, так и встроенные словари и массивы.


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


Высокая доступность


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



Рисунок 2 (Реплики сервера Couchbase)

Второй важной функцией для обеспечения высокой доступности является внутренний протокол DCP (Database Change Protocol). Он обеспечивает высокоскоростную передачу изменений во все копии данных, вторичные индексы (GSI), межкластерную репликацию (XDCR) и внешним потребителям.


Двунаправленная репликация


Правильной практикой в компаниях является использование резервирования всех бизнес-процессов и оборудования. В идеальном варианте это резервирование в режиме Active-Active, когда переключение между проблемными узлами происходит автоматически. Двунаправленная репликация в Couchbase позволяет обеспечить режим A-A. Но тестирование репликации показало, что она эффективна только в близко стоящих ЦОД. При разнесении более 100 км появляются конфликты. У Couchbase есть механизмы решения конфликтов: на основе Timestamp и Sequence Number. Однако, из-за временной задержки на сети, в базу попадают устаревшие данные. Мы отказались от использования двунаправленной репликации (cross-cluster consistency). Все изменения проводятся только на одном кластере. Доступность данных в режиме «чтение» обеспечивается во всех ЦОДах (A-A).


Горизонтальное масштабирование


Одной из важных характеристик большинства NoSQL БД является горизонтальное масштабирование (рис. 3). Основным отличием Couchbase является поддержка многомерного масштабирования, когда мы в кластере можем наращивать по производительности только нужную службу. Например, игра Pokemon GO использует разделение архитектуры. На старте проекта использовалось 5 серверов с совмещенными службами. После увеличения нагрузки ими была применена разнесенная архитектура: 5 серверов с данными и 55 серверов для обработки запросов и индексов. Одним из минусов масштабирования у Couchbase является возникновение проблем у оркестратора, при наличии в кластере свыше 50 дата нод.


 



Рисунок 3 MDS


Требования ИБ


Требования информационной безопасности влияли на наш выбор в меньшей степени, но их наличие у системы выступило дополнительным аргументом в пользу той или иной БД. Так как в кэше могут содержаться персональные данные, то в обязательном порядке мы должны соблюдать требования регулятора. Стоит определиться: будем ли мы использовать дополнительное оборудование или сможем это обеспечить самой базой данных?!


В энтерпрайз версии Couchbase поддерживает шифрование трафика, шифрование данных и персонализированный доступ.  Это позволяет сэкономить на оборудовании, например Cisco ASA.


Простота обновления


Одним из существенных плюсов Couchbase является прозрачный механизм обновления и поддержка API старых версий. На время обновления кластера, он работает в режиме совместимости. Новые механизмы заработают только после полного обновления кластера. Влияния на работающие приложения минимальны за счет поддержки старого API.


PS: Обновление/даунгрейд допускается только на соседних мажорных версиях


Дополнительная функциональность


Логическое распределение


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



Рисунок 4 Server Gropus

Резервное копирование и восстановление


Couchbase содержит в себе готовые инструменты для резервного копирования и восстановления. Процесс бекапа может работать в трёх режимах: полном, дифференциальном и накопительном. Это позволяет в некоторых случаях сэкономить место на дисках и процессорные ресурсы.



Couchbase vs Mongo


На вопрос выбора альтернативных NoSQL БД ответить сложно, и зачастую, лучший Unix – тот, который знает твой админ. Попытаемся сформулировать, почему мы отдали предпочтение Couchbase, а не другой очень популярной платформе – MongoDB.


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


Таблица 1 Сравнение


 


Couchbase


MongoDB


Масштабирование


Автоматическое для всего набора данных


Ручной выбор ключа


Распределение данных


Данные всегда равномерно распределены по всем дата нодам


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


Добавление/удаление узла или реплики


Добавляется в один шаг через GUI, с ребалансировкой


Довольно сложная задача с расчетами веса для каждой коллекции


Распределение реплик по стойкам/ЦОД


Реализовано через логические группы


Не реализовано


Автоматическое распределение нагрузки


Каждая нода имеет одинаковое количество активных записей доступных на чтение и запись


Не сбалансировано. Вторичные узлы не поддерживают запись


Масштабирование индексов


Гибкое, можно добавлять отдельные индекс ноды за счет разнесенной архитектуры


Жесткое, масштабирование индекса связано с масштабирование данных.


Метаданные кластера


Распределяются по всем узлам кластера


Требуются сервера конфигурации


Интегрированный поиск


N1LQ(SQL++)


JSON запрос



Таблица 2 Сравнение репликации


 


Couchbase


MongoDB


Архитектура


Межкластерная репликация не имеет зависимостей, кластера независимы друг от друга


Только внутрикластерное расширение


Гибкость настройки


Гибкая(настройка отдельных бакетов, фильтры, тюнинг)


Тюнинг скорости


Топология


Двунаправленая репликация, звезда, цепь и т.д.


Звезда


Режим Active-Active


Поддерживается


Не поддерживается



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


Опыт эксплуатации


Для начала нам бы хотелось привести цифры, с которыми сейчас оперирует система и кластер на Couchbase.


  1. Более 80 миллионов абонентов[i]
  2. 380 миллионов JSON документов с информацией о клиентах
  3. 3,5 ТБ HDD (мы используем memcached, информация на диске хранится для быстрого старта)
  4. 3 ТБ ОЗУ
  5. 50 тыс. операций в секунду (рис 5)
  6. 50 микросервисов, обрабатывающих весь поток сообщений

 



Рисунок 5 Нагрузка

Первые вехи трансформации мы начинали с третьей версией Couchbase. На первом этапе, на запуске проекта, все приложения работали стабильно. Но при переводе дополнительной логики на новый механизм, мы столкнулись с тем, что механизм вьюх (View) стал работать непредсказуемо. Т.е. в какой-то момент процесс зависал и данные вьюхи с такой ноды переставали возвращаться. При этом доступ к данным и их обработки не прерывался. Проблема исправлялась достаточно легко – перезапуском ноды, что в целом снижало доступность сервиса. В ходе общения с техподдержкой Couchbase нам предложили недокументируемую команду, перезапускающую только процесс вьюх


curl -s --data 'cb_couch_sup:restart_couch().' -u Administrator:pass http://127.0.0.1:8091/diag/eval[ii]


Команда действует только в версиях 3.x.


curl -s --data 'couch_server_sup:restart_core_server().' -u Administrator:Administrator http://127.0.0.1:8091/diag/eval


Команда действует только в версиях 4.x.


Еще одной проблемой третьей версии был ломающийся механизм сжатия данных (compaction). Его приходилось запускать вручную по сработавшим метрикам мониторинга. Обе проблемы держали в напряжении не только дежурную смену, но и функциональных инженеров.


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


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


После обновления у нас получилось исправить только одну проблему – сжатие. Оно стало работать исправно. С механизмом View проблема всё же осталась, хотя повторялась гораздо реже. Скорректировать её удалось только силами разработчиков Couchbase в версии 4.6.4.


В рамках решения проблем с техподдержкой выяснилось: механизм вьюх больше обновляться не будет. Сделано это было на основании того, что большинство клиентов Couchbase используют вьюхи не для тех целей, для которых создавались, а Couchbase сделал новый механизм N1QL. Выполнен он отдельным сервисом и теперь не зависит от нод с данными (рис. 7)


 



Рисунок 7 Роли нод

Все критичные проблемы мы закрыли версией 4.6.4. Но в связи с увеличением объема данных приняли решение о миграции на пятую версию, где добавили новую БД для индексов и на наших данных объем в памяти и дисках уменьшился в полтора раза. Но, к сожалению, уменьшения объема данных на дата-нодах мы не увидели.


Выводы


В целом, Couchbase показал себя зрелой системой, держащей высокую нагрузку, даже в неспецифичных кейсах (Viber – используется как БД). В рамках гибридной архитектуры МегаФона кластер можно легко адаптировать под любые цели без простоя оборудования и без серьезной реконфигурации серверов, что в целом дает возможность компании сократить затраты на персонал и сделать сервис для абонента максимально удобным.


ПАО МегаФон


2018 Ковальчук Егор


[i] Системой обрабатываются не только абоненты, но и устройства со встроенными симкартами, модемы и прочее


[ii] Перед употреблением проконсультируйтесь со специалистом

Поделиться публикацией

Комментарии 29

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

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

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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

            И посмотреть на github.com/gianlucaborello/cassandradump
              0
              В другом кластере, с онлайн обновлением из промышленной.
              То есть нам нужно получить актуальную бизнес копию для тестирования. Причем, копия должна обновляться регулярно. Делать полный импорт/экспорт (полтора терабайта в сутки) затратно
          0
          > Среднее время отклика (50%) — до 5 мс (в рамках одного ЦОД).
          Уточните, пожалуйста, это среднее арифметическое или медиана?
            0
            Скорее количественный показатель. Если брать медиану то она должна быть в районе 3.
            0
            Как бы можно шардить данные между SQL серверами и таким образом масштабироваться горизонтально.
              0
              шардить можно, не спорю, а как шардить данные из одной таблицы с высокой нагрузкой на запись и изменение? На оракле возникает конкуренция и в целом падает производительность.

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

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

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

                  Опять же это надо продумывать, иначе можно получить перекос данных и нагрузки. На пример тот же Mongo
                    0
                    Что-то типа того. Суть в том, что я не вижу прямого обоснования, зачем было деградировать до хранения всех данных в key-value storage.
                      0
                      Это кеш агрегатор, с быстрым доступом к данным. Если собирать данные по всем источникам то будет на порядки дольше, чем из кеша.
                    0
                    Также само, шардить эту таблицу по каким-то признакам. Все не связанные между собой напрямую данные можно раскидывать. Прям как в nosql вам относительно всё равно на какой ноде лежит документ, так и тут.
                      0
                      Это дополнительные сложности в эксплуатации и дополнительные архитектурные решения. Опять же большой риск получить перекос данных.
                      Опять же от разработчика требуется усложнить приложения.

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

                      Основной плюс использования In-Memory, это быстрый доступ к данным. В Couchbase есть два варианта кеша, с записью на диск(для старта с диска) или полностью в памяти. Но в последнем случае при проблемах по тому же питанию, кеш мы будем вынуждено проливать с нуля.
                        0
                        А менять всю архитектуру это не сложность и не дополнительное решение? Тот «долгий путь архитектурной трансформации» внезапно испарился из памяти? С SQL можно было попробовать поступить следующим образом: на входе кластер с набором stp, который уже под капотом шардит запросы и раскидывает дальше по linked servers. Т.е. для разработчиков единый интерфейс доступа и некоторое кол-во работы на sql стороне. Выглядит куда проще, чем полностью менять архитектуру и без урезания функциональности полноценного sql в угоду одной лишь скорости.
                          0

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

                            0

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


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


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

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

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

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

                    3. Можно ли как-то форсировать «прогрев» бакет в боевом кластере без перезапуска ноды? Иногда случается превышение high watermark и данные выгружаются из памяти, что недопустимо для некоторых бакетов в нашей архитектуре.
                      0
                      1. Бекап у нас реализован средствами СХД. Но фактически при факторе репликации 2 и резерва маловероятна физическая потеря данных. А вот логическая порча данных заставит откатываться на бекап или же пролить кеш с нуля.
                      Вы делаете полный бекап?

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

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

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

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

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

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

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

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

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

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

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

                        Спасибо!

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

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

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

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

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

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

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

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

                      Самое читаемое