Geo-aware partioning in cassandra

Question

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

Более специальное свойство моего запланированного сервиса заключается в том, что данные будут связаны с определенным географическим местоположением - например, в 99,99% всех случаев данные, предназначенные для города в США, будут запрашиваться у , а не, из Европы (на самом деле даже данные, предназначенные для определенного города, вряд ли будут запрашиваться у города рядом с этим городом).

То, что я хочу, чтобы минимизировать это:

1. накладные расходы администрации
2. Сетевая задержка
3. Ненужные репликации данных (я не хочу, чтобы иметь полную репликацию данных, предназначенных для Европы, в США)

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

1. Используй полностью изолированную Кассандру кластер за гео-расположение в сочетании с вручную сконфигурированной службой маршрутизации, который выбирает правильный кластер за вставку/выберите запрос
2. Развертыванием глобальный кластер и определить несколько центров обработки данных для определенных геолокаций для обеспечения высокой доступности в этих регионах.
3. Развертывание глобального кластера без использования центров обработки данных
4. Развертывание глобального кластера без использования центров обработки данных и управление секционированием для геоинформации , Мой план состоит в том, чтобы манипулировать первыми тремя битами ключа раздела на основе геолокации (например, 000: Северная Америка, 001: Южная Америка, 010: Африка, 011: Юг/Западная Европа и т. Д.) И назначить Остальные бит с использованием алгоритма хеширования (аналогично случайному разделителю кассандр).

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

Поэтому, в теории, мне больше нравится решение 4. Здесь у меня будет довольно много административных накладных расходов, низкий объем ненужной репликации данных и приличная доступность. Однако для реализации этого (насколько мне известно) мне понадобится ByteOrderPartitioning, который крайне не рекомендуется из многих источников.

Есть ли способ, чтобы реализовать решение близко к решению 4 без использования ByteOrderPartitioning, или это тот случай, когда ByteOrderPartitioning мог имеет смысл или я упускаю очевидное пятое решение?

Answer 1

Пересмотрите вариант 2.

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

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