Каскадная балансировка нагрузки JDBCTap для MySQL

Я подумываю написать каскадное приложение, которое выдает операторы SELECT для баз данных MYSQL, где каждый запрос может возвращать миллионы строк.

Каждая база данных существует на N подчиненных устройствах и одном главном устройстве, как показано здесь: http://dev.mysql.com/doc/refman/5.0/en/replication-solutions-scaleout.html#figure_replication-scaleout

В JDBCTap я вижу, что мы можем передать только одно имя хоста: это означает, что все мои сопоставители будут пытаться подключиться к одному ведомому устройству (в то время как другие (N-1) ведомые устройства простаивают).

Предполагая, что перед подчиненными устройствами нет балансировщика нагрузки, существует ли пакет / модуль / прокси-сервер JAVA (или, лучше, индивидуальная реализация JDBCTap), который я могу использовать, который может распределить соединение картографов между N подчиненными устройствами?

Пример сценария, использующего аппаратный прокси-сервер, который, кажется, делает это, подробно описан здесь: http://blog.netoearth.com/html/201006/building-a-mysql-load-balancing-proxy-with-trafficscript.htm

Если такой вещи не существует, мне пришлось бы создать свой собственный JDBCTap (который распределяет соединение от картографов по N подчиненным устройствам), используя следующий алгоритм:

  1. Храните список N ведомых устройств во внешней базе данных (все, что хорошо поддерживает одновременную запись / обновление)
  2. Имейте счетчик картографов, которые подключились к каждому ведомому устройству.
  3. Каждый раз, когда сопоставителю необходимо подключиться к ведомому устройству, он запрашивает эту базу данных, чтобы определить ведомое устройство, которое наименее загружено (с минимальным количеством подключенных к нему сопоставителей). Случайный тай-брейк при столкновении.

Звучит как хорошая идея? Что может быть внешней базой данных, «хорошо поддерживающей параллельные записи / обновления», о которой я упоминал выше? (Cassandra, VoltDB и т. Д.)


person newToFlume    schedule 19.10.2012    source источник


Ответы (1)


JDBC в целом не поддерживает параллелизм, так что это является узким местом для крупномасштабных нагрузок.

В такой основной / резервной архитектуре, как насчет получения данных из резервных копий через резервные копии MySQL в TSV, а затем их параллельной загрузки в HDFS?

person Paco    schedule 18.11.2012