Следует ли разбить большую таблицу mysql, использовать механизм слияния, master/slave или что-то еще?
Возможно, я слишком рано пошел по пути чрезмерной оптимизации и заблудился. Я записываю все возможные ходы в дереве настольной игры. У меня мало надежд на завершение дерева, так как оно станет таким большим (10^28), но я хочу получить хороший кусок, если это возможно. В ожидании медленных запросов я разбил таблицы на ~50 ветвей дерева с суффиксами, описывающими каждую ветвь.
К сожалению, в моем приложении много операций чтения, записи, обновлений и объединений, поэтому все быстро замедлилось, прежде чем я разделил их. С тех пор я также добавил несколько очень полезных индексов, которые могли бы решить начальную медлительность. Однако по мере развития приложения становится все сложнее переключаться между множеством таблиц с более сложными объединениями. Недавно я слышал об использовании главного подчиненного, а также механизма слияния, чтобы помочь с большими таблицами. Я выбрал неправильное решение своей проблемы или я должен просто выпустить его?
1 ответ
10^28 строк или что-то еще, прямо скажем, невозможно. Рассчитать стоимость такого большого дискового пространства; это должно вас напугать. Вы должны сосредоточиться на "обрезке" своих деревьев.
PARTITIONing выглядит заманчиво, но по своей сути не обеспечивает какого-либо выигрыша в производительности (за редким исключением). То же самое для ручного разбиения на 50 таблиц. MERGE это просто старый вариант PARTITION, Репликация может помочь для масштабирования чтения. Разделение (разделение данных на несколько машин) может помочь, но увеличивает стоимость и сложность - и все равно не даст вам 10^28 чего-либо.
Если вы предоставите SHOW CREATE TABLE и некоторые вопросы, мы можем обсудить методы оптимизации, бит, индексации и т. д. Это может вам помочь.
Используете ли вы 64-битный BIGINT UNSIGNED для отслеживания некоторых вещей на доске 8х8? И используя булеву арифметику для манипулирования ими? В некоторых ситуациях это может значительно уменьшить дисковое пространство, количество необходимых запросов и т. Д.