Как масштабировать, развиваясь из разделов базы данных до окопов?

Question

Скажем, у меня есть MySQL таблицы:

CREATE TABLE tweets (
tweet_id INT NOT NULL AUTO_INCREMENT, 
author_id INT NOT NULL, 
text CHAR(140) NOT NULL, 
PRIMARY KEY (tweet_id) 
) 
PARTITION BY HASH(tweet_id) 
PARTITIONS 12; 

Все это хорошо. Таблица работает на одном сервере - Server1. Но в конце концов я, возможно, захочу уменьшить масштаб. Поэтому я бы хотел очертить таблицу и переместить 6 из 12 разделов на новый сервер - Server2.

Я хочу:

• Сервер1 содержит нечетные твиты: перегородки 1, 3, 5, 7, 9, 11
• Server2 содержат четные твиты: перегородки 2, 4 , 6, 8, 10, 0

1) Каков наилучший способ перемещения этих разделов с Server1 на Server2? Мне нужно убедиться, что значения auto-increment tweet_id остаются неизменными во время миграции.

2) Теперь, когда у меня есть 2 сервера, как я могу убедиться, что auto-increment tweet_id, сгенерированный двумя серверами, не имеет того же значения? Мне также нужно убедиться, что tweet_id на каждом разделе остается согласованным, т. Е. На разделе k каждый модуль tweet_id 12 равен k.

3) В идеале я хотел бы продолжить этот процесс масштабирования. Поэтому позже я захочу добавить третий сервер - Server3. Я бы хотел перебалансировать разделы, чтобы на каждом сервере было 4 раздела. Опять же, как я могу убедиться, что auto-increment tweet_id, сгенерированный 3-мя серверами, различен и что по модулю 12 из tweet_id остаются согласованными в каждом разделе?

Answer 1

Прежде всего, я бы предложил не использовать AUTO_INCREMENT для tweet_id. API Twitter дает вам идентификатор с твитом, который уже гарантированно будет уникальным. Вы также можете использовать это для ссылки на tweet через API позже, если вы выберете. Однако, похоже, для этого может быть слишком поздно, если у вас уже собрано много собранных данных.

Просмотрите системные переменные auto_increment_offset и auto_increment_increment. Вы можете использовать их для обеспечения того, чтобы ваши идентификаторы автоинкремента не противоречили друг другу. В принципе, вы хотите установить auto_increment_offset на число, большее, чем все существующие идентификаторы, но установите его на более высокий уровень на втором сервере. Затем установите auto_increment_increment на 2. Это гарантирует, что один сервер генерирует все нечетные идентификаторы, а другой генерирует все четные идентификаторы. Чтобы сохранить масштабирование, просто отрегулируйте эти значения соответствующим образом.

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

Лучше всего разделить данные, чтобы выбрать диапазоны идентификаторов твитов для размещения на каждом сервере. В вашем случае, вероятно, имеет смысл захватить первую половину или около того идентификаторов твитов и поместить их на сервер 2. Затем сервер 1 может оставаться в живых до тех пор, пока сервер 2 (и ваша новая логика приложения) не будут готовы).

Answer 2

Возможно, вы захотите взглянуть на dbShards, который обрабатывает эти проблемы для вас. Автоматический прирост поддерживается с уникальными значениями по всем осколкам, и вы можете использовать модуль для привязки ключей к виртуальным осколкам, а не привязывать их непосредственно к физическим осколкам. Это облегчает добавление новых осколков. Вы можете прочитать больше на http://www.dbshards.com/dbshards/.

С уважением,

Andy.