Моделирование данных Cassandra менее 1000 записей для размещения в одной строке

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

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

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

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

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

Ранее в этом году я кратко рассмотрел этот тип решения для моделирования в своей статье: У нас Порядок! Это так называемый "фиктивный ключ", когда каждая строка имеет один и тот же ключ раздела. Это ярлык, который позволяет легко упорядочить все ваши строки (на несвязанном SELECT *) путем кластеризации столбцов.

Проблемы с этим решением:

• Cassandra допускает не более 2 миллиардов значений столбцов на ключ секции. При использовании фиктивного ключа раздела вы будете приближаться к этому пределу с каждым добавляемым значением.

• Все ваши данные будут храниться в одном разделе, что создаст «горячую точку» (большие группы данных) в вашем кластере. Это означает, что ваша модель данных немедленно лишит вас одного из основных преимуществ Cassandra... распределения данных. Это также усложнит балансировку нагрузки (одни и те же узлы и диапазоны будут продолжать обслуживать все ваши запросы).

• Я вижу, что ваша модель построена вокруг запроса SELECT *. Cassandra работает лучше всего, когда вы можете дать ей определенные ключи для запроса. Несвязанные запросы SELECT * (запросы без предложений WHERE) не рекомендуется выполнять с Cassandra, поскольку они могут привести к тайм-аутам (по мере роста ваших данных).

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

Тогда я должен задаться вопросом: почему вы используете Cassandra? Как Cassandra MVP, я не часто задаю этот вопрос. Но у вас нет особенно большого набора данных (для работы с которым предназначена Cassandra). Полагаться на этот факт как на причину для неправильного использования продукта — не лучшее решение.

Честно говоря, я собираюсь порекомендовать вам избавить себя от некоторых сложностей и вместо этого использовать СУБД. Это будет соответствовать вашему варианту использования значительно лучше, чем Cassandra. Затем вы можете обновлять и упорядочивать любые поля, которые вы хотите.