Односторонняя репликация между дата-центрами Cassandra

Question

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

Выбор Cassandra был основан на следующих факторах:

• Поддерживается большая пропускная способность для операций записи.- тысячи одновременных записей в секунду
• Пригодность для инженерных данных (в основном данных временных рядов)
• Высокая доступность для поддержки непрерывных операций телескопа
• Поддержка инструментов, например, Analytics, Reporting

Оценки данных

• 250 ТБ прироста в год (50 лет жизненного цикла Системы)

ИспользованиеКейс

У нас есть два центра обработки данных - DC операций и DC аналитики (для изоляции рабочих нагрузок чтения и записи).В конце этого поста приведена схема, изображающая предложенную архитектуру.Из-за ограничений хранилища мы не можем хранить данные, сгенерированные в течение срока службы, на Operations DC.Следовательно, мы планируем переместить данные из Operations DC в DC Analytics в соответствии с определенной политикой (скажем, через 1 неделю).

Вопросы

1. Isли иметь возможность односторонней репликации в Кассандре между центрами обработки данных?Данные из Operations DC перемещаются в Analytics DC.Но данные, хранящиеся после обработки в Analytics DC, не должны копироваться в Operations DC.
2. Обеспечивает ли Cassandra контроль над тем, что будет реплицировано?Мы не хотим, чтобы оба DC были синхронизированы.Мы хотим настроить то, что будет реплицировано (фактически перемещено) в DC Analytics.Возможно ли это по своей сути с Кассандрой?Если я хочу указать, что только данные за последнюю неделю должны реплицироваться из Центра обработки данных в Центр обработки данных Analytics.

3. Мы планируем использовать встроенную в Cassandra функцию «время жизни» для удаленияданные (только от операций DC).Данные, удаленные из Operations DC, не должны удаляться из Analytics DC.Как предотвратить репликацию удаленных данных?

4. Я прочитал, что один узел Cassandra может обрабатывать до 2-3 ТБ данных.Любая документированная ссылка на любые более крупные реализации Cassandra поможет.

5. Сколько узлов Cassandra должно быть развернуто для обработки такого роста?И какой должна быть рекомендованная стратегия развертывания?

6. Соображения производительности: хотя объем хранилища в Operations DC будет ограниченным (данные 3-7 дней, около 5-10 ТБ), хранилище данныхв аналитике DC накапливается и продолжает расти со временем.Повлияет ли рост базы данных в DC аналитики на репликацию и ухудшит производительность Operations DC.

Цель здесь - узнать, можно ли использовать встроенную функцию Cassandra для поддержки вышеуказанных требований.Я знаю о наиболее очевидном решении.Не иметь репликации между двумя DC.Извлеките данные за последнюю неделю из DC операций и переместите их в DC Analytics.

Предлагаемая диаграмма архитектуры

Answer 1

1. Нет

2. Да, репликация настроена для каждого пространства ключей.

3. Это не будет работать изкоробка, но ее можно заставить работать.Я могу придумать два относительно простых варианта.Самым простым является пакетная запись в оба пространства ключей / DC: одно с TTL, а другое без.Вы также можете создать пространство ключей в месяц / год, начать с его репликации на несколько контроллеров домена и при необходимости удалить «нормальный» контроллер домена.

4. Кластер Кассандры - плотность данных (размер данных на узел) - ищет обратную связь и дает советы

5. Кассандра все в порядкепримерно до 800-1000 экземпляров в кластере, но часто рекомендуется использовать сегменты меньшего размера, чем для вашей собственной простоты работы

6. DC могут быть асимметричными.

Answer 2

Я думаю, что в вашем случае имеет смысл «разделять» контроллеры домена - например, пространства ключей в одном контроллере не реплицируются в другой контроллер домена - просто создайте пространства ключей с необходимыми соответствующими настройками репликации.

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

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