Методы работы с очень большими таблицами в высокодоступных системах

Question

У нас есть большая таблица из ~ 20 миллионов записей в MySql InnoDB (v5.0.85). Таблица записывает состояние для действий пользователя и используется несколькими серверами приложений. Иногда появляется новое требование, которое означает, что нам нужно добавить новый столбец в эту таблицу для хранения дополнительной информации. Выполнение команды alter занимает около 20 минут, в течение которых приложение не может выполнять свои обязанности, так как таблица заблокирована - это больше не приемлемо для нашей бизнес-модели, поскольку приложение должно оставаться максимально доступным с очень коротким перерывом в работе. нажмите новый код сервера.

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

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

Спасибо!

Answer 1

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

Answer 2

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

Answer 3

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

Вот несколько решений, которые приходят на ум:

• Используйте таблицы PropertyType / PropertyValue, где PropertyType - это перечисление, в которое можно добавлять новую запись всякий раз, когда требуется добавить новую информацию. Как отмечает HLGEM, такая схема имеет недостатки. EAV допускает очень динамичные модели, но ими трудно управлять, если запросы не генерируются выделенным слоем.

• Иметь полностью нормализованную схему, в которой вы создаете новую независимую таблицу для каждой новой информации.

• Вы ничего не говорите о статистике чтения / записи, но если приемлемо наличие 20-минутного окна только для чтения, вы можете иметь реплицированную версию только для чтения, которая будет обрабатывать загрузку запросов во время изменения. таблица.

Answer 4

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

Довольно много работы, но для 0 простоев ничего не будет легко.