Конвертировать ЛОТЫ идентичных таблиц MySQL в ОДИН и множество ВИДОВ, которые указывают на это? - PullRequest
Новая
       17

Конвертировать ЛОТЫ идентичных таблиц MySQL в ОДИН и множество ВИДОВ, которые указывают на это?

4 голосов
/ 08 сентября 2011

Я использую довольно большое развертывание WPMU (Wordpress Multi-User, Wordpress Multisite), которое использует 4096 баз данных и более 100 тыс. Таблиц (очевидно, с большим количеством совпадений в том, что касается схемы).

По сути, это одни и те же 20 таблиц, которые повторяются снова и снова для каждого блога, некоторые из них пустые, другие содержат от нескольких до нескольких сотен строк.

Мой план (который избавляет от множества головных болей, но может оказаться неэффективным) - объединить все таблицы с одной и той же схемой в несколько больших таблиц InnoDB и заменить старые на MySQL VIEW, которые указывают на них, переписав запросы так, чтобы возвращаются соответствующие строки (сохраните старое имя таблицы в новом столбце, а затем используйте представление для добавления столбца в предложение WHERE).

Вопрос в том, даст ли это ЛЮБОЕ улучшение в том, что касается производительности? (эффективность ключевого буфера, эффективность кэширования таблиц, индексирование) или это просто змеиный жир, и я должен прибегнуть к более радикальному подходу переписать приложение таким образом, чтобы мне не нужны VIEW, но запросы направляются прямо в большой InnoDB таблицы?

1 Ответ

3 голосов
/ 08 сентября 2011

Я бы рекомендовал не делать слияние таблиц, о котором вы думаете.

Рассмотрим некоторые недостатки объединения таблиц:

  • Структуры данных индекса для объединенных таблиц будут больше и глубже и, следовательно, менее эффективны.
  • Блоги, которые накапливают много данных, но затем простаивают, по-прежнему вносят вклад в общий размер таблиц и индексов и, следовательно, делают запросы более длительными.
  • Труднее создать резервную копию и восстановить отдельный блог.
  • Сложнее перенести отдельный блог на другой сервер базы данных, если вы хотите масштабировать его.
  • Сложнее использовать привилегии SQL для ограничения доступа к данному блогу (хотя вы можете применять привилегии SQL к представлениям).
  • Сложнее добавлять пользовательские функции, которые включают изменения схемы для данного блога.

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

Я однажды говорил с архитектором базы данных для Wordpress.com. Они содержат миллионы блогов Wordpress на десятках сотнях физических серверов. Вначале они начали с того, что данные по всем блогам были объединены в одни и те же таблицы, но они обнаружили, что эксплуатационные трудности становились слишком большими по мере их роста. Теперь они размещают каждый блог в отдельной базе данных.

...