Mysql 'Partitioning' vs Разделение данных в разные таблицы

Question

У нас есть таблица mysql с именем posts_content.

Структура выглядит следующим образом:

CREATE TABLE IF NOT EXISTS `posts_content` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `post_id` int(11) NOT NULL,
  `forum_id` int(11) NOT NULL,
  `content` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=79850 ;

Проблема в том, что таблица становится довольно большой.Много гигабайт данных (у нас есть механизм сканирования).

Мы ежедневно вставляем данные в таблицу, но редко получаем данные.Теперь, когда стол становится довольно огромным, становится трудно справиться со столом.

Мы обсудили две возможности

1. Использование функции разделения MySQL для разделения таблицы с использованием forum_id (существует около 50 forum_ids, поэтому будет около 50 разделов. Обратите внимание, что даже каждый раздел, еслисделанное так, в конечном итоге вырастет до большого количества гигабайт данных, возможно, даже когда-нибудь понадобится собственный диск
2. Создайте отдельные таблицы для каждого forum_id и разделите данные следующим образом.Я четко объяснил проблему. Что мне нужно знать, так это то, что из двух приведенных выше будет лучшим решением в долгосрочной перспективе. Каковы рекомендации обоих случаев.

   Благодарю вас

Answer 1

Разница в том, что в первом случае вы оставляете MySQL для выполнения шардинга, а во втором случае вы делаете это самостоятельно. MySQL не будет сканировать любые фрагменты, которые не содержат данных, однако если у вас есть запрос WHERE forum_id IN(...), возможно, потребуется сканировать несколько сегментов. Насколько я помню, в этом случае операция является синхронной, например, MySQL запрашивает один раздел за раз, и вы можете захотеть реализовать его асинхронно. Как правило, если вы делаете разделение самостоятельно, вы более гибки, но для простого разбиения на основе forum_id, если вы запрашиваете только 1 forum_id за раз, разделение MySQL в порядке.

Мой совет - прочитать документацию MySQL по разделам, особенно раздел ограничения и ограничения , а затем принять решение.

Answer 2

Быстрое решение для 3-кратного сокращения пространства (и, возможно, ускорения) состоит в том, чтобы сжать content и поместить его в MEDIUMBLOB. Делайте сжатие на клиенте, а не на сервере; это экономит полосу пропускания и позволяет распределять вычисления среди множества клиентских серверов, которые у вас есть (или будут).

«Sharding» разделяет данные между несколькими серверами. Смотрите MariaDB и Spider. Это позволяет увеличить размер и, возможно, увеличить производительность. Если вы в конечном итоге осколок, forum_id может быть лучшим. Но это предполагает, что ни один форум не слишком велик для размещения на одном сервере.

«Разделение» разделяет данные, но только на одном сервере; не похоже, что в вашем случае есть какое-либо преимущество. Разделение по forum_id не обеспечит никакой производительности.

Удалить FOREIGN KEYs; вместо этого отладьте ваше приложение.

Answer 3

здесь у вас есть хороший ответ на ваш вопрос: https://dba.stackexchange.com/a/24705/15243

По сути, позвольте вашей системе расти, и, пока вы знакомы с разбиением на разделы, и когда ваша система действительно должна быть «разрезана на части», делайте это с разделением.