Лучший способ осквернить базу данных MySQL - PullRequest
0 голосов
/ 08 мая 2019

У меня огромное количество пользователей, поэтому мне необходимо разделять базы данных на n сегментов. Итак, чтобы продолжить это, у меня есть следующие варианты -

  1. Разделите мои данные на n-ю ось на основе пользовательского идентификатора n. то есть, если у меня есть 10 шардов, то пользователь 1999 будет отправлен на 1999% 10 = 9-й шард
    Проблемно Проблема с этим подходом состоит в том, что количество осколков увеличивается в будущем, ссылка на предыдущий не будет сохранена.

  2. Я могу вести таблицу с UserId и ShardId
    Проблемно Если в будущем число моих пользователей увеличится до миллиардов, мне понадобится поделиться этой таблицей сопоставления, что не кажется хорошим решением.

  3. Я могу поддерживать статическое отображение в коде, подобном 0-10000 в Shard 1 и т. Д.
    Проблема -

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

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

1 Ответ

1 голос
/ 10 мая 2019

Я предпочитаю гибрид из 1 и 2:

  1. Хешируйте UserId, скажем, в 4096 значениях.
  2. Найдите это число в «словаре», в котором есть номера с осколками

Если осколок переполнен, перенесите всех пользователей с некоторым номером хеша в другой осколок.

Если вы добавили осколок, перенесите в него несколько хеш-номеров- предпочтительно из занятых осколков.

Это вынуждает вас написать скрипт для перемещающихся пользователей и сделать его устойчивым.После этого многие другие задачи администратора становятся «простыми»:

  • Отключение компьютера
  • Обновление ОС (одна за другой через шарды)
  • Обновите любое программное обеспечение, установленное на компьютерах.
  • Перенос большого хеш-номера, но не занятого, на старый медленный осколок с большим диском.Аналогичным образом перенесите небольшой и загруженный в сегмент с большим количеством ядер и более быстрых дисков.

Каждый сегмент может представлять собой кластер высокой доступности (Galera, групповая репликация и т. Д.) Серверов как для надежности, так и для масштабирования чтения.(Sharding дает вам масштабирование при записи.

Должен быть способ распространять словарь для всех клиентов "быстро".

Все это работает хорошо, если, скажем, каждыйхэш в 3 различных шардах для HA. Каждый из 3 будет в географических местоположениях для устойчивости. В словаре будет 4 столбца, чтобы указать, где находятся копии. 4-й будет использоваться во время миграции.

...