Каков рекомендуемый подход к мультитенантным базам данных в Кассандре? - PullRequest
0 голосов
/ 21 ноября 2018

Я думаю о создании мультитенантного приложения с использованием Apache Cassandra.

Я могу представить три стратегии:

  1. Все арендаторы в одном и том же пространстве ключей, использующие специфичные для арендатора поля для обеспечения безопасности
  2. таблица на каждого арендатора в одной общей БД
  3. Пространство ключей на одного арендатора

Голос в моей голове подсказывает, что я должен выбрать вариант 3.

Мысли и последствия, кто-нибудь?

Ответы [ 2 ]

0 голосов
/ 21 ноября 2018

Я делал это в течение нескольких лет в крупных магазинах.Таким образом, я считаю, что рекомендуемый способ обработки мультитенантности в Кассандре - это , а не до.Независимо от того, как вы это сделаете, арендаторы будут сталкиваться с проблемой «шумного соседа».Просто подождите, пока один арендатор запустит обновление BATCH с 60k записей, записанных в одну и ту же таблицу, и производительность всех остальных упадет.

Но большая проблема в том, что вы не можете гарантировать, что у каждого арендатора будет даже аналогичное отношение чтения к записи.На самом деле они, скорее всего, будут совсем другими.Это будет проблемой для вариантов № 1 и № 2, поскольку дисковые IOP будут перемещаться в один и тот же каталог.

Вариант № 3 действительно единственный способ, которым он реально работает.Но опять же, все, что нужно, - это одна необдуманная партия, чтобы сокрушить всех.Кроме того, хотите обновить свой кластер?Теперь вы должны согласовать это с несколькими командами, а не с одной.Используя SSL?Убедитесь, что несколько команд получают правильный сертификат, вместо одного.

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

0 голосов
/ 21 ноября 2018

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

Вариант 1. В чистом Кассандре этот параметр будет работать только в том случае, если доступ к базе данных будет всегда через «прокси» - например, API,это приведет к фильтрации на поле арендатора.В противном случае, если вы предоставите доступ к CQL, тогда каждый сможет прочитать все данные.В этом случае вам также необходимо тщательно создать модель данных, чтобы арендатор был частью составного ключа раздела.DataStax Enterprise (DSE) имеет дополнительную функциональность, называемую управление доступом на уровне строк (RLAC) , которая позволяет устанавливать разрешения на уровне таблицы.

Опции 2 и 3: очень похожи, за исключением того, чтоесли у вас есть пространство ключей на каждого арендатора, у вас есть возможность настроить другую стратегию репликации - это может быть полезно для хранения данных клиента в разных центрах обработки данных, привязанных к разным географическим регионам.Но в обоих случаях существуют ограничения на количество таблиц в кластере - разумное количество таблиц составляет около 200, с «жесткой остановкой» более чем на 500. Причина - вам нужны дополнительные ресурсы, такие как память, чтобы сохранить вспомогательностьструктуры данных (фильтр Блума и т. д.) для каждой таблицы, и это будет занимать как кучу, так и память вне кучи.

...