Сохранение Akka: переход с jdbc (postgres) на cassandra

#postgresql #jdbc #cassandra #akka-persistence

#postgresql #jdbc #кассандра #akka-сохранение

Вопрос:

У меня есть запущенный проект с использованием плагина akka-persistence-jdbc и postgresql в качестве серверной части.

Теперь я хочу перейти на akka-persistence-cassandra. Но как я могу преобразовать существующие события (размером более 4 ГБ в postgres) в cassandra?

Должен ли я написать программу миграции вручную? Чтение из postgres и запись в правильный формат в cassandra?

Комментарии:

1. Что заставило вас отказаться от Postgres?

2. @DamianW потому что плагин postgres был в стадии бета-тестирования!

Ответ №1:

Это классическая проблема миграции. Для этого существует несколько решений.

  1. Spark SQL and Spark Cassandra Connector: API Spark JDBC (называемый Spark Dataframe, Spark SQL) позволяет вам читать из любого источника JDBC. Вы можете читать его по частям, сегментируя его, иначе вам не хватит памяти. Сегментация также делает миграцию параллельной. Затем запишите данные в Cassandra с помощью Cassandra Spark Connector. Это, безусловно, самый простой и эффективный способ, который я использовал в своих задачах.
  2. Java Agents: Агент Java может быть написан на основе обычного JDBC или других библиотек, а затем записан в Cassandra с драйвером Datastax. Программа Spark работает на нескольких машинах многопоточным способом и автоматически восстанавливается, если что-то пойдет не так. Но если вы пишете такой агент вручную, то ваш агент работает только на одной машине, и многопоточность также должна быть закодирована.
  3. Kafka Connectors : Kafka — это брокер обмена сообщениями. Его можно использовать косвенно для миграции. У Kafka есть коннектор, который может читать и записывать в разные базы данных. Вы можете использовать соединитель JDBC для чтения из PostGres и соединитель Cassandra для записи в Cassandra. Это не так просто настроить, но у него есть преимущество в том, что «не требуется кодирование».
  4. ETL Systems: Некоторые системы ETL поддерживают Cassandra, но я лично ничего не пробовал.

Я увидел некоторые преимущества в использовании Spark Cassandra и Spark SQL для миграции, некоторые из них:

  1. Код был кратким. Это было едва ли 40 строк
  2. Многомашинный (снова многопоточный на каждом компьютере)
  3. Ход выполнения заданий и статистика в Spark Master UI
  4. Отказоустойчивость — если узел spark не работает или поток / рабочий не удалось там, то задание автоматически запускается на другом узле — хорошо для очень длительных заданий

Если вы не знаете Spark, то пишущий агент подходит для данных объемом 4 ГБ.