Планирование мощности MySQL

Question

В моей производственной среде у меня есть один экземпляр сервера MySQL, работающий на 16 гигабайтах памяти, который обрабатывает до 20 000 запросов в час. Размер одной моей таблицы растет со скоростью 2 миллиона в месяц. Ожидается, что оба эти числа будут расти с течением времени, но я не уверен, когда мне нужно улучшить архитектуру.

Как можно быть проактивным в отношении ситуации и заниматься проверкой системы на будущее?

Много ли выигрывает модернизация оборудования с точки зрения времени и эффективности использования капитала?

Какова будет обычная практика в этом случае, если мы удваиваем трафик каждые 3 месяца, будет ли шардинг естественным прогрессом? Или есть другие альтернативы?

Как мне узнать, достигает ли моя система своего пика, какие инструменты доступны для профилирования базы данных? И какие метрики я бы использовал для его измерения?

Answer 1

Очень сложно ответить на такой огромный вопрос о масштабируемости .

Во-первых, обновление оборудования на одной машине не является долгим - даже не краткосрочным вариантом,как вы, кажется, планируете экспоненциальный рост (x2 каждые 3 месяца большие, начиная с 2M строк в месяц).Таким образом, вам нужно найти распределенную масштабируемую аппаратную архитектуру.

Затем на ум приходят два основных варианта:

Придерживайтесь SQL

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

Здесь вы найдете очень интересную статью о Advanced MySQL ReplicationТехники .

Затем можно начать с разбиение или лучше, разбиение , как вы упоминали ранее.

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

Смешивать с NoSQL

Другой вариант, очевидно, предусматривает использование технологий NoSQL на ваших таблицах монстров.Распределенные системы хранения ключей и значений практически не требуют затрат с точки зрения масштабируемости, то есть, самое большее, линейного.

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