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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Относительно того, сколько времени потребуется, чтобы полностью исправить плохо спроектированную базу данных, месяцы или годы. Часто худшая часть - это то, что имеет центральное значение для дизайна (например, таблица 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 3

Для ответа на вопрос название, я бы сказал, что это довольно легко настроить ваш DB после того, как развертывание в производство.

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

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

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

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

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

Answer 4

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

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

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