Насколько легко (или иным образом) настроить базу данных ПОСЛЕ «ЖИЗНИ»?

Question

Все больше похоже на то, что мне придется начать работу, прежде чем у меня будет время настроить все запросы / таблицы и т. Д., Прежде чем я начну жить с веб-сайтом (уже 6 месяцев отстает от графика, так что все, хотя это не так) идеальный сценарий - так обстоят дела).

Теперь дело за прикусом пули. Это просто попытка понять, насколько велика будет эта пуля, когда мы начнем ее «кусать». Как только база данных будет запущена, очевидно, что мы не сможем изменить данные по прихоти, потому что это оперативные данные. Я довольно уверен в большинстве схем БД - например, таблицы представлены в большинстве 3-4-х нормальных форм, и для обеспечения целостности данных используются ограничения. Я также добавил в некоторые столбцы индексы, которые ( я думаю ) будут часто использоваться в запросах, хотя это было сделано довольно быстро и не проверялось - это то, о чем я беспокоюсь.

Чтобы уточнить, я не говорю об оптовом изменении структуры. Сами таблицы вряд ли изменятся (если вообще когда-либо), однако почти гарантировано, что мне придется настраивать таблицы на каком-то этапе (лично или нанять кого-то).

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

Предполагая, что 50% таблиц нуждаются в настройке в следующие несколько месяцев:

1. Сколько времени потребуется, чтобы выполнить настройку (я знаю, что это вопрос типа «как долго это кусок строки») - но каковы основные детерминанты требуемого усилия, поэтому я могу решить сколько времени это может занять?

2. Можно ли либо заблокировать разделы базы данных (или определенные таблицы) во время переработки индексов, либо всю базу данных необходимо отключить? (Я использую MySQL 5.x в качестве базы данных)

3. Является ли то, что я описываю (запускать до того, как ВСЕ таблицы будут полностью настроены), чрезвычайно рискованно / нежелательно? (Оправдывает ли это месяцы бессонных ночей, которые я до сих пор вызывал)?

Answer 1

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

Относительно того, сколько времени потребуется, чтобы полностью исправить плохо спроектированную базу данных, месяцы или годы. Часто худшая часть - это то, что занимает центральное место в дизайне (например, таблица EAV) и требует почти каждого запроса / sp / view. UDF должен быть скорректирован, чтобы перейти к лучшей структуре. Затем вы должны убедиться, что все записи перемещены в новую лучшую структуру. Чем раньше вы сможете исправить такую ​​ошибку, тем лучше. Гораздо лучше перенести пару тысяч записей в новую структуру, чем 100 000 000.

Если с вашей структурой все в порядке, но ваши запросы плохие, вам лучше, так как вы можете взять десятку худших показателей (выберите не только по общему времени выполнения, но и по времени X, а не по времени выполнения) и исправить, промыть и повторить.

Если вы пытаетесь исправить плохую базу данных, эта книга может пригодиться:

http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533/ref=sr_1_1?ie=UTF8&s=books&qid=1268158669&sr=8-1

Answer 2

1. Это зависит от того, что вы настраиваете. Допустим, вы добавляете индекс в пару таблиц или меняете тип таблицы с MyISAM на InnoDB или что-то в этом роде, а затем с достаточно большой таблицей эти действия можно выполнить за 5–10 минут в зависимости от вашего оборудования. Это не займет несколько часов. Тем не менее, по-прежнему лучше всего делать живую настройку БД в середине ночи.

2. Вы можете захватить блокировку чтения, позвонив по номеру FLUSH TABLES WITH READ LOCK, но, вероятно, лучше поместить сообщение «Мы занимаемся обслуживанием» в ваше приложение на 15–30 минут, которые вы делаете, просто чтобы быть в безопасности.

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

Answer 3

Чтобы ответить на заглавный вопрос, я бы сказал, что настроить вашу БД после развертывания в Production довольно просто.

Отличная идея - повысить производительность после развертывания в любой среде. Быть Производителем добавляет немного давления, наряду с графиком. Я бы посоветовал развернуть Prod и позволить ему работать так, как будет. Затем начните измерения:

• как долго запускать Отчет X в разное время (в пиковые и нерабочие часы, если в вашем приложении есть такая концепция).
• Каков опыт пользователя при использовании приложения для этих критических сценариев использования?

Затем сделайте резервную копию вашей среды Prod и создайте себе предварительную среду Prod. Там вы сможете запустить свои сценарии обновления, чтобы измерить тип вопросов «как долго». Создание индекса, время простоя обновления и т. Д. При настройке запросов и т. Д. У вас будет отличное представление о том, как он работает с производственными данными и объемами. Конечно, у вас не будет преимуществ от одновременного выполнения этих операций этими пользователями.

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

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

Answer 4

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

Возможно, вы захотите смоделировать (как можно больше автоматически) типичное использование базы данных из вашего приложения и проверить, сколько одновременных пользователей / сеансов / транзакций и т. Д. Она может обработать до того, как произойдет сбой. Это, по крайней мере, должно позволить вам решить проблему «бессонных ночей».

Что касается оригинального "Насколько это просто ...?" Вопрос, ответ, очевидно, зависит от многих факторов. Однако приведенный выше анализ, несомненно, поможет, поскольку, по крайней мере, вы сможете сказать, требует ли ваша база данных доработки или нет.