Как помогает разбиение таблиц?

Мне трудно понять идею плюсов и минусов разбиения таблиц. Я собираюсь начать работу над проектом, в котором будет 8 таблиц, и одна из них будет основной таблицей данных, которая будет содержать 180-260 миллионов записей. Поскольку это будет правильно проиндексированная таблица, я думаю об ограничении записей в таблице до 20 миллионов, таким образом, мне пришлось бы создавать 9-13 таблиц.

Но я не совсем уверен, как это улучшит производительность, потому что они будут сидеть на одной машине (32 ГБ ОЗУ)?

Я использую MySQL, и таблицы будут MyISAM, а большая таблица будет иметь индекс по полю id, и нет никаких дополнительных сложностей, таких как полнотекстовый поиск и т. Д.

Просьба также пролить свет на разделы таблиц и разделов баз данных.

Следующие просто безумные разглагольствования и бред ...

Если вы оставите все данные в одной таблице (без разделения), у вас будет O (log n) времени поиска с использованием ключа. Давайте возьмем худший индекс в мире, двоичное дерево. Каждый узел дерева имеет ровно один ключ. Идеально сбалансированное двоичное дерево с 268 435 455 (2 ^ 28 - 1) вершинами дерева будет иметь высоту 28. Если вы разбьете это двоичное дерево на 16 отдельных деревьев, вы получите 16 двоичных деревьев с 16 777 215 (2 ^ 24 - 1) узлы дерева для высоты 24. Путь поиска сокращен на 4 узла, что на 14,2857% меньше высоты. Если время поиска в микросекундах, сокращение времени поиска на 14,2857% практически невозможно.

Теперь в реальном мире индекс BTREE будет иметь триоды с несколькими ключами. Каждый поиск BTREE будет выполнять двоичный поиск на странице с возможным переходом на другую страницу. Например, если бы каждая страница BTREE содержала 1024 ключа, то высота дерева 3 или 4 была бы нормой, в действительности это была бы небольшая высота дерева.

Обратите внимание, что разделение стола не уменьшает высоту BTREE, которая уже мала. Учитывая разделение 260 миллиардных рядов, даже существует высокая вероятность наличия нескольких BTREE с одинаковой высотой. Поиск ключа может проходить по всем корневым страницам BTREE каждый раз. Только один будет выполнять путь необходимого диапазона поиска.

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

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

Разделение данных должно служить для группировки данных, которые логически и связно находятся в одном классе. Производительность поиска по каждому разделу не должна быть основным фактором, если данные правильно сгруппированы. Как только вы добились логического разбиения, сконцентрируйтесь на времени поиска. Если вы просто разделяете данные только по идентификатору, возможно, что многие строки данных никогда не будут доступны для чтения или записи. Теперь это должно быть главным соображением: найдите все идентификаторы, к которым чаще всего обращаются, и разделите их . Все менее часто используемые идентификаторы должны находиться в одной большой архивной таблице, которая все еще доступна при поиске по индексу для этого запроса «один раз в голубой луне».

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

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

• Простота очистки старых данных Если вам нужно очистить записи более чем (скажем) 6 месяцев, вы можете разбить таблицу по дате, а затем заменить старые разделы. Это намного быстрее, чем удаление данных из таблицы, и часто может быть сделано в реальной системе. В случае OP это может быть полезно для обслуживания системы.

• Разделение на несколько дисковых разделов Разбиение позволяет разделить данные для распределения дискового трафика по нескольким дисковым томам для увеличения скорости. С современным RAID-контроллером это вряд ли станет проблемой для OP.

• Более быстрое сканирование таблиц и диапазонов Действительно, операционная система не должна делать такого рода вещи, но хранилище данных или аналогичная система будет выполнять такого рода запросы по количеству. При сканировании таблиц используется в основном последовательный дисковый трафик, поэтому они обычно являются наиболее эффективным способом обработки запроса, который возвращает более нескольких процентов строк в таблице.
  
  Разделение с помощью общего фильтра (обычно на основе времени или периода) позволяет исключить из таких запросов большие фрагменты таблицы, если предикат можно разрешить для ключа разделения. Это также позволяет разбивать таблицу на несколько томов, что может значительно повысить производительность для больших наборов данных. Обычно это не проблема для операционных систем.

Для целей OP разделение вряд ли приведет к значительному повышению производительности для рабочих запросов, но может быть полезно для управления системой. Если есть какое-либо существенное требование сообщать об агрегатах по большим объемам данных, то в этом может помочь подходящая схема секционирования.

Секционирование позволяет выполнять параллельные перегруппировки по секциям, если все ваши индексы секционированы. Если нет, разделы все еще намного меньше и используют меньше рабочего пространства для повторной регистрации. И внутренне любая «хорошая» СУБД может делать вещи параллельно с секционированными таблицами. Это, вероятно, не включает MySQL или MyISAM, хотя ....