Добавление дополнительных разделов HASH в уже разбитую таблицу HASH

Question

Привет, у меня сейчас таблица с 100 разделами HASH.Я решил, что теперь это необходимо увеличить до 1000 разделов из-за будущего масштабирования.

Нужно ли удалять разделы из таблицы, а затем добавлять 1000 разделов после или есть способ добавить дополнительный900 разделов к уже разбитой таблице?

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

ALTER TABLE t1
PARTITION BY HASH(venue_id)
PARTITIONS 100;

Есть ли способ получить оценку того, сколько времени потребуется для добавления1000 разделов к моему столу?Для этого я буду использовать один из инструментов perconas, который предотвратит блокировку таблицы.https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html

Answer 1

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

Просто ALTER TABLE и определите новую схему разбиения:

ALTER TABLE t1
PARTITION BY HASH(venue_id)
PARTITIONS 1000;

Или с помощьюpt-online-schema-change:

pt-online-schema-change h=myhost,D=mydatabase,t=t1 
  --alter "PARTITION BY HASH(venue_id) PARTITIONS 1000" 
  --execute

(я ставлю там разрывы строк, чтобы избежать переноса строк, но это одна команда.)

---

Я забыл прокомментироватьВаш другой вопрос о прогнозировании ETA для завершения.

Одним из преимуществ сценария Percona является то, что он сообщает о прогрессе, и по нему можно получить оценку завершения.Хотя в нашей среде мы находим, что это не очень точно.Иногда он может сообщить, что он выполнен на 99% в течение нескольких часов.

Также имейте в виду, что сценарий Percona не блокируется на 100%.Он нуждается в эксклюзивной блокировке метаданных на короткое время в начале и в конце своего запуска, потому что он должен создавать триггеры, а затем переименовывать таблицы и сбрасывать триггеры в конце.Любой запрос, даже доступный только для чтения SELECT, блокирует блокировку метаданных.Если у вас возникли проблемы с завершением сценария, убедитесь, что все запросы и транзакции, которые вы выполняете для своей таблицы, завершаются быстро (иначе вы должны убить их, если нет).

Answer 2

PARTITION BY HASH практически бесполезен.Я не ожидаю, что это поможет вам как с 100 разделами, так и с 1000.

Вы получаете больше отдачи от вложенных средств, если в качестве первого столбца в PRIMARY KEY.

получите venue_id.

Всегда ли в запросе указан один venue_id?(Если опции не запутываются.) На данный момент, я предполагаю, что у вас всегда есть WHERE venue_id = constant.

У вас проблема с многомерной индексацией.INDEXes - только одно измерение, поэтому все становится сложнее.Тем не менее, разделение можно использовать для сортировки, чтобы получить двумерный индекс.

Давайте выберем day_epoch в качестве ключа разделения и используем PARTITION BY RANGE(day_epoch).(Если вы измените его с 4-байтового INT на 3-байтовую DATE, тогда используйте PARTITION BY RANGE(TO_DAYS(day_epoch))).

Тогда давайте определимся с PRIMARY KEY.Примечание: при добавлении или удалении разметки ПК следует переосмыслить.Имейте в виду, что PK - это уникальный индекс.И данные кластеризованы на ПК.(Однако уникальность не гарантируется для всех разделов.)

Итак ...

PARTITION BY RANGE(day_epoch)

PRIMARY KEY(venue_id, zone_id, id)  -- in this order

Без разбиения я рекомендую

PRIMARY KEY(venue_id, zone_id, day_epoch, id)

В общем, любой индекс (включая PK) должен начинаться с любого столбца (столбцов), которые проверены с =.Затем IN, затем не более одного «диапазона».

Ради требования уникальности PK я поставил id last .

Таким образом, запрос выполняет что-то вроде этого:

1. "Обрезка раздела" - возможно, до одного раздела, основанного на дате.
2. Разверните PK непосредственно до последовательногостроки для одного venue_id в вопросе.
3. Hopscotch по данным, основанным на zone_ids.(В некоторых ситуациях это может быть сканирование диапазона вместо прыжка вокруг. Это зависит от версии, количества идентификаторов, значений идентификаторов и, возможно, фазы луны.
4. (Если это делаетэто так далеко) Затем получите желаемую дату.

При извлечении большого количества строк из огромной таблицы самое важное - минимизировать попадания на диск. То, что я только что описал, вероятно, делает работу лучше, чем другиеситуации. Разделение на venue_id помогает только с этим одним столбцом, но не помогает с остальными.