Узел координатора и его влияние на производительность

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

2) Запись буферизуется, и в зависимости от вашего уровня согласованности вы не получите подтверждение записи, пока она не будет принята на нескольких узлах. Например, с первым уровнем согласованности вы получите ACK, как только запись будет принята одним узлом. Для других узлов записи будут поставлены в очередь и доставлены, но вы не получите никакой информации о них. В случае, если одна из этих операций записи завершается сбоем или не может быть доставлена, на координаторе будет храниться подсказка, которая будет доставлена, когда реплика вернется в оперативный режим. Очевидно, что существует ограничение на количество сохраняемых подсказок, поэтому после длительного простоя вам следует запустить восстановление.

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

3) Производительность должна расти вместе с общим количеством операций записи. Если кластер может поддерживать чистую скорость записи 10 000 операций записи в секунду, но имеет RF = 2. Скорее всего, вы можете выполнять только 5 000 операций записи в секунду, поскольку каждая операция записи на самом деле равна 2. Это произойдет независимо от вашего уровня согласованности, поскольку эти записи отправляются, даже если вы не ждут их признания.

4) Координацию никак не обойти. Стратегия осведомленности о токенах выберет хорошего координатора, который, по сути, является лучшим, что вы можете сделать. Если вы попытаетесь вручную записать в каждую реплику, ваша запись все равно будет реплицирована каждым узлом, получившим запрос, поэтому вместо одного события координации вы получите N. Это также, скорее всего, плохая идея, поскольку я предполагаю, что у вас есть лучший сети между вашими узлами C*, чем от вашего клиента к узлам c*.

У меня нет ответов на 2 и 3, но что касается 1 и 4.

1) Да, это может вызвать дополнительный переход

4) Да, ну вроде. Драйвер Datastax, а также драйвер Netflix Astynax можно настроить как Token Aware, что означает, что он будет слушать сплетни кольца, чтобы узнать, какие узлы имеют какие диапазоны токенов, и отправлять вставку координатору на узле, на котором он будет храниться. Устранение дополнительного сетевого прыжка.

Чтобы добавить к ответу Эндрю, не предполагайте, что прыжок координатора вызовет значительную задержку. Сделайте ваши запросы и измерения. Думайте об уровнях консистенции больше, чем о дополнительном прыжке. Настройте согласованность для более высокой скорости чтения или более высокой скорости записи или баланса между ними. Затем ИЗМЕРЯЙТЕ. Если вы обнаружите, что задержки неприемлемы, вам может потребоваться настроить уровни согласованности и/или изменить модель данных.