Настройка нескольких баз данных MySQL с возможностью масштабирования - PullRequest
1 голос
/ 26 апреля 2009

Мне нужно настроить среду MySQL, которая будет поддерживать добавление множества уникальных баз данных с течением времени (на самом деле тысячи). Я предполагаю, что в какой-то момент мне нужно будет начать добавлять серверы MySQL, и я хотел бы, чтобы моя среда была подготовлена ​​к этому делу заранее, чтобы упростить переход на 2-й, 3-й, 100-й сервер.

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

Я провел некоторые исследования, и MySQL Proxy выдвигается в качестве основного кандидата, но я не смог найти ничего конкретного о том, как заставить его работать так, как описано выше.

Любой

Ответы [ 2 ]

5 голосов
/ 26 апреля 2009

Отличный вопрос. Я знаю несколько компаний, которые сделали это (Facebook выскочил как крупнейший). Никто не счастлив, но альтернативы отстой тоже.

Еще несколько вещей, которые вы должны рассмотреть - что произойдет, если произойдет сбой некоторых из этих баз данных или серверов? Что происходит, когда вам нужно выполнить кросс-запрос к базе данных (и вы это сделаете, даже если вы сейчас так не думаете).

Вот решение FriendFeed: http://bret.appspot.com/entry/how-friendfeed-uses-mysql

Это немного "задом наперед", поскольку они в основном используют MySQL в качестве прославленного хранилища значений ключей. Я не уверен, почему они не просто вырезали посредника и использовали что-то вроде BerkeleyDB для хранения своих объектов. Управление подключением, может быть? Похоже, что издержки MySQL были бы слишком высокими, чтобы платить за то, что можно было бы добавить довольно легко (известные последние слова).

То, что вы действительно ищете (я думаю), это распределенная база данных без совместного использования. Некоторые были построены на основе технологий с открытым исходным кодом, таких как MySQL и PostgreSQL, но ни одна не доступна бесплатно. Если вы в настроении для покупки, проверьте эти компании: Greenplum , AsterData , Netezza , Vertica .

Существует также большое количество различных распределенных решений хранения ключей-значений. Из-за отсутствия лучшей справки, вот отправная точка: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/.

2 голосов
/ 28 апреля 2009

Ваша проблема звучит аналогично той, с которой мы столкнулись - что вы выступаете в роли белого ярлыка и что у каждого клиента должна быть своя отдельная база данных. Предполагая, что эта концепция совпадает с вашей, мы использовали «основную» базу данных, в которой хранились имя хоста и имя базы данных для клиента (которые могли кэшироваться на уровне приложения). Сервер, к которому обращался клиент, мог затем динамически переместить свой источник данных в требуемую базу данных. Это позволило нам масштабировать до тысяч клиентских баз данных, разбросанных по серверам.

...