Как масштабироваться путем перехода от разделов базы данных к шардингу? - PullRequest
Новая
       34

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

1 голос
/ 24 августа 2010

Скажем, у меня есть таблица 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 разделов на новый сервер - Сервер2.

Я бы хотел:

  • Сервер1 для хранения нечетных твитов: разделы 1, 3, 5, 7, 9, 11
  • Сервер2, содержащий твиты с четными номерами: разделы 2, 4, 6, 8, 10, 0

1) Как лучше всего переместить эти разделы с Сервера1 на Сервер2? Мне нужно убедиться, что значения автоинкремента tweet_id остаются неизменными во время миграции.

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

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

Ответы [ 2 ]

2 голосов
/ 27 августа 2010

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

С уважением,

Энди.

2 голосов
/ 25 августа 2010

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

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

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

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

...