Как работает секционирование Cassandra, когда коэффициент репликации == размер кластера?

Действительно ли у меня есть кольцо из одного раздела, в котором все возможные значения, сгенерированные разделителем, поступают в один раздел?

Считается ли, что каждый узел отвечает за каждую строку данных?

Если все мои узлы отвечают за каждый фрагмент данных независимо от значения хеш-функции, вычисленного секционером, могу ли я иметь только кольцо из одного ключа раздела?

Не совсем так, узлы C * по-прежнему имеют диапазоны токенов, а c * по-прежнему назначает первичную реплику ответственному узлу. Но все узлы также будут иметь копию с RF = N (где N - количество узлов). Таким образом, по сути, подразумевается то же, что вы описали.

Есть ли у этого типа развертывания Cassandra огромные недостатки? Есть ли другие недостатки этой стратегии, о которых я не знаю?

Не то, чтобы я мог придумать, я полагаю, что вы можете быть более восприимчивыми, чем в среднем, к несогласованным данным, поэтому используйте антиэнтропийные механизмы C *, чтобы противостоять этому (исправление, восстановление чтения, передача с подсказками).

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

Является ли коэффициент репликации == размер кластера общей (или даже разумной) стратегией развертывания, если не считать очевидного случая кластера из одного?

Это не обычное дело, я думаю, вы ищете сверхвысокую доступность, и все ваши данные умещаются в одном корпусе. Не думаю, что когда-либо видел развертывание c * с RF ›5. Дальний и широкий RF = 3.

Если бы я использовал согласованность записи, равную единице, всегда ли Cassandra записывает данные на узел, с которым связывается клиент?

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

Основным недостатком будет увеличение затрат на запись на уровне координатора по мере добавления узлов. Максимальное количество записанных реплик, которые я видел, составляет около 8 (5 для других центров обработки данных и 3 для локальных реплик).

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

Основное преимущество в том, что вы можете делать много вещей, которые обычно были бы ужасными и невозможными. Хотите использовать вторичные индексы? вероятно, будет работать достаточно хорошо (при условии, что мощность и размер раздела не станут вашим узким местом). Хотите добавить пользовательский UDF, который выполняет GroupBy, или использовать очень большие запросы IN, это, вероятно, сработает.

Это похоже на то, что @Phact упоминает не общий шаблон использования, и я в первую очередь видел, что он используется с DSE Search в случаях использования с низкой пропускной способностью записи, в которых были требования к функциям `` одного узла '' от Solr, но для тех же вариантов использования с чистой Cassandra вы бы получить некоторые преимущества на стороне чтения и иметь возможность выполнять дорогостоящие запросы, которые обычно невозможны в более распределенном кластере.