Эффективное разделение данных в мультитенантном формате. - PullRequest
Новая
       11

Эффективное разделение данных в мультитенантном формате.

0 голосов
/ 29 мая 2018

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

На данный момент у меня есть таблица, похожая на эту. 

CREATE TABLE key.products (
    product_id UUID,
    account_id UUID,
    sku TEXT,
    other_details....,
    PRIMARY KEY (account_id, product_id, sku)
);

Эта таблица позволит мне использовать такие запросы довольно легко. 

SELECT product_id,sku,other_details FROM key.products WHERE account_id=@@@@;

Но если яполучить несколько учетных записей, которые имеют значительно больше продуктов, чем другие учетные записи, что компенсирует разделы в Cassandra;и у меня больше не будет хорошего и равномерного распределения данных между моими узлами.Данные по-прежнему будет относительно легко запрашивать по account_id, но это нормально?В какой момент я буду стрелять себе в ногу, чтобы не разделять что-то еще?И как я могу изменить свой подход, чтобы по-прежнему эффективно запрашивать продукты в учетной записи и минимизировать перекос данных?

Будет ли более эффективным разделение по product_id и наличие альтернативной таблицы для запроса по учетной записи?Что-то вроде. 

CREATE TABLE key.products (
    product_id UUID,
    sku TEXT,
    other_details....,
    PRIMARY KEY (product_id, sku)
);

CREATE TABLE key.products_by_account (
    account_id UUID,
    product_id UUID,
    PRIMARY KEY (account_id, product_id)
);

Данные будут по-прежнему искажены в таблице products_by_account, но размер данных будет намного меньше, поскольку он не содержит все данные в основной таблице продуктов.Это лучше?

1 Ответ

0 голосов
/ 29 мая 2018

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

В вашем случае хорошим распределением может быть составной ключ раздела, например (account_id, product_id).

Другой подход заключается в добавлении некоторого вида группирования к «большим» учетным записям - например, разбить данные учетной записи на N сегментов и использовать ключ, такой как (account_id, X), где X находится между 0 и N. В этом случаеЕсли вам когда-нибудь понадобится получить все продукты для данной учетной записи, вы можете выполнить N запросов параллельно, чтобы получить все.Вместо числа вы можете использовать категории товаров или что-то вроде этого с фиксированным и известным набором значений.

...