Кассандровский подход к моделированию данных для интенсивного чтения / записи

Question

Я новичок в Кассандре и мне нужна помощь в моделировании данных по приведенному ниже сценарию. В оракуле у меня есть две таблицы, похожие на приведенные ниже, которые я собираюсь перенести на Кассандру.

Варианты использования для решения: 1. Тяжело читает и пишет. 2. Пользовательские данные сначала создаются, и мы можем продолжать добавлять или удалять учетные записи. 3. Также будет иметь частичное обновление одной из учетных записей пользователя, таких как обновление суммы или некоторые детали учетной записи. 4. User_data имеет поле для хранения количества активных присутствующих user_accounts. Поэтому всякий раз, когда мы добавляем или удаляем запись / строку в таблице user_account. это вызовет обновление в user_data.

По сути, мне не ясно, как моделировать эти сценарии. Независимо от того, чтобы иметь одну таблицу. Но с этим я не уверен в количестве счетов Если у меня есть одна таблица и user_accounts в качестве одного из столбцов с типом JSON. Затем я считаю, что не могу сделать частичное обновление в этом JSON.

Основная проблема при рассмотрении двух таблиц - управление транзакциями. Если я смог добавить в user_account, но не смог обновить user_data, то это будет сбой.

создать таблицу USER_DATA ( userId uuid ПЕРВИЧНЫЙ КЛЮЧ, имя varchar, noOfAccounts int,

..... # Еще несколько столбцов ...,

);

создать таблицу USER_ACCOUNTS ( userId uuid accountId uuid,
AMT INT, ..... # Еще несколько столбцов ...,

ПЕРВИЧНЫЙ КЛЮЧ (uuid, accountId) );

Я пытался использовать список FROZEN USER_ACCOUNTS, но при этом нам нужно читать весь список и записывать обратно при каждом добавлении / удалении или обновлении одной из его записей.

Я пытался использовать тип json, но безрезультатно.

Answer 1

Позвольте мне остановиться на важном моменте, прежде чем продолжить: Вы уверены, что вам нужен NoSQL и точная Cassandra для хранения пользователей и учетных записей?

Cassandra предназначена для крупномасштабных распределил данные и оптимизирован для очень быстрой записи.Если вы все еще думаете о выборе решения, я бы порекомендовал потратить некоторое время на изучение существующих решений и случаев, когда они эффективны / неэффективны.В интернете много статей.Например, https://www.infoworld.com/article/3268871/how-to-choose-the-right-type-of-database-for-your-enterprise.html

Кассандра.

Важные вопросы перед выбором структуры:

• Как часто пользователь добавляет новую учетную запись и удаляет существующую?
• Сколько пользователей делают это одновременно?
• Сколько учетных записей имеет обычный пользователь?

Настоятельно рекомендуется написать тесты производительности для всех ваших сценариев использования и проверить производительностьпрежде чем принимать какие-либо решения.

Оригинальная структура хранилища - это хорошо, чтобы начать играть с тестами производительности , но с небольшими улучшениями:

create table users.user_data (user_id uuid PRIMARY KEY, 
              name varchar, 
              account_count counter, 
              some_other_column varchar);

create table users.user_account (user_id uuid account_id uuid , amt int, 
PRIMARY KEY (user_id, account_id));

• Тип users.user_dataПоле .account_count counter
• Обе таблицы хранятся в keypace пользователей.Конфигурация пространства ключей важна для производительности.

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

Возможно, самая очевидная вещь - это многораздельные пакеты, но это медленно .Внимательно прочитайте: Док

Рекомендуется попробовать асинхронную запись с использованием кода драйвера .Выберите драйвер Cassandra DataStax для вашего языка программирования.Вот пример abstract на основе Java кода для понимания идеи:

session.executeAsync("insert into users.user_account ...");
Futures.addCallback(future,
    new FutureCallback<ResultSet>() {
        @Override public void onSuccess(ResultSet result) {
            // Run query for incrementing counter in users.user_data table
        }
        @Override public void onFailure(Throwable t) {}
    },
    MoreExecutors.sameThreadExecutor() );

Обновление (14 мая 2019 г.):

Альтернативное решение для игры: одиночная таблица и статические столбцы. Посмотрите на https://blog.ippon.tech/modeling-data-with-cassandra-what-cql-hides-away-from-you/

Кажется, вам могут помочь статические столбцы!

create table users.user_data (user_id uuid PRIMARY KEY, 
              name varchar static, 
              account_count counter static, 
              some_other_column varchar static,
              account_id uuid, 
              amt int, 
              PRIMARY KEY (user_id, account_id));

• Столбцы, которыеизначально не принадлежали user_account таблицы помечены как статические
• Статические столбцы сохраняются только один раз внутри
• user_id равен ключ раздела и account_id - ключ кластеризации . Пояснение

Столбец счетчика может быть статическим в соответствии с Допустим ли этот тип определения таблицы счетчиков?