Как запустить большое обновление для живой базы данных? - PullRequest
4 голосов
/ 08 декабря 2010

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

Да, это не очень хороший процесс, но есть веские причины, по которым этот подход был выбран вместо стандартного подхода "работа с фактическим дБ".

То, с чем я борюсь, - это лучший способ запустить этот процесс обновления, не причиняя слишком много неудобств пользователю. Помните несколько цифр:

1) Этот процесс должен проводиться регулярно, каждые несколько недель / раз в месяц
2) Конвертер БД в настоящее время занимает около часа и, вероятно, в будущем займет до 15 часов, по крайней мере, если прогнозы относительно роста базы данных верны (да, ой!)
3) Дамп sql полной базы данных в настоящее время занимает менее 20 МБ (что позволяет легко импортировать через phpmyadmin), но вскоре преодолеет этот барьер. Я думаю, это не должно быть проблемой, так как я могу просто использовать загрузку SSH.

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

Кто-нибудь делал что-то подобное? Я был бы признателен за превосходные альтернативы, если они есть или какие-либо отзывы о том, как их улучшить и стоит ли выбирать 1 или 3. Заранее спасибо:)

Alternative 1<br> 1) Set globalsettings_booleans_writeable to 0<br> 2) Download current DB (SQL dump)<br> 3) Import downloaded DB locally<br> 4) Run converter (in update mode) on local database<br> 5) Export local DB<br> 6) Set globalsettings_booleans_readable to 0<br> 7) Import exported DB online<br> 8) Set globalsettings_booleans_readable to 1<br> 9) Set globalsettings_booleans_writeable to 1

Alternative 2<br> 1) Set globalsettings_booleans_writeable to 0<br> 2) Set globalsettings_booleans_readable to 0<br> 3) Run converter (in update mode) on live database<br> 4) Set globalsettings_booleans_readable to 1<br> 5) Set globalsettings_booleans_writeable to 1

Alternative 3<br> 1) Set globalsettings_booleans_writeable to 0<br> 2) Create a remote copy of the database<br> 3) Run converter (in update mode) on remote copy<br> 4) Set globalsettings_booleans_readable to 0<br> 5) Replace remote original with remote copy (easy?)<br> 6) Set globalsettings_booleans_readable to 1<br> 7) Set globalsettings_booleans_writeable to 1

1 Ответ

1 голос
/ 08 декабря 2010

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

Если это так, записи CSV, которые не приводят ни к каким изменениям, могут игнорироваться, таблицы d / b не усекаются, а остальные записи CSV могут выполняться с использованием Альтернативы 2, что, предположительно, займет всего несколько минут.

Основным недостатком этого подхода является то, что записи удаляются в источнике, и нет никаких признаков того, что d / b должен удалять их локально.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...