вторник, 19 января 2010 г.

Время собирать базы

У нас на работе настоящее SOA. Нет одной огромной базы данных, а есть штук 15 узкоспециализированных сервисов. Как правило, у каждого из них своя база данных. Это, конечно, очень удобно для тестирования, но немного неудобно для админов. Ведь для каждой базы нужно делать бэкапы, а также нужно иметь зеркала, копии для построения отчетов, для разработчиков, для функционального и стресс-тестирования. Итого получаем сотню баз.

Дальше - больше. В какой-то момент решили разбить всё по странам. Не потому, что базы очень большие; и не потому, что в базе нет флага "код страны". А просто так, чтобы было спокойнее. Типа что можно было для разных стран накатывать патчи не одновременно; чтобы если ломать, то не всё сразу. Итак, количество баз пришлось умножить ещё на количество стран, в которых мы ведем бизнес.

А потом у нашей компании появился ещё один сайт. Т.е. совсем другой сайт, но работающий на том же движке. И опять решили для этого нового сайта сделать отдельные копии большинства баз. Ну, просто так, чтобы было спокойнее. И баз стало ещё в два раза больше.

Теперь у нас несколько сотен баз. Админы, наконец, взвыли и решили их объединить. Чтобы на один сервис была одна база, как, вообщем-то, архитекторы изначально и задумали. Конечно, оказалось, что всё out-of-sync, хотя как бы не должно было быть. Так что мучаемся.

Что сделать нашу жизнь ещё веселее, админы ввели правило: запрещено делать breaking changes хранимых процедур. Т.е. если ты добавил новый параметер, или хранимая процедура стала возвращать новое поле, то нельзя делать ALTER. Вместо этого надо создать новую версию: CREATE PROCEDURE MyProc_Version02. Кроме того, запрещено добавлять поля NOT NULL в существующие таблицы (иначе INSERT может не пройти).

Если соблюдать эти правила, то необязательно одновременно менять приложение и базу: старое приложение может работать с новой базой, или наоборот. Другое дело, будет ли оно работать так, как ожидалось? Я лично считаю, что админы просто хотят замаскировать возможные проблемы. Лучше бы ночью на выходных на полчаса просто вырубать всё сайты и менять одновременно и код, и базу. Но, видимо, никому неохота работать по ночам...

P.S. Ещё одно правило, которое мне не нравится: мало того, что нельзя обращаться к таблицам напрямую, но даже через view нельзя. Если я сделал view, то надо создать хранимую процедуру, которая будет его возвращать в приложение. Это загадка для меня. Ну, я понимаю, что напрямую к таблицам обращаться небезопасно, но почему нельзя через view?

3 комментария:

Igor Korkhov комментирует...

Господи, жесть какая!

Лучше бы ночью на выходных на полчаса просто вырубать всё сайты и менять одновременно и код, и базу. Но, видимо, никому неохота работать по ночам...

Как бы при таком подходе не пришлось вашим админам вскорости работать по ночам 7 дней в неделю.

ITC-exp комментирует...

А почему бы это дело не автоматизировать и не за schedulить...так и по ночам не надо работать – пусть компы работают – они из железа и пластмассы – им до лампочки – они не потеют . . . Одноклассников, например, с 5 до 6 утра патчат (GMT +2)

Z комментирует...

Если у вас MS SQL то даже через view можно оставить блокировку на продуктивной БД. Я ни разу не сталкивался с подобной проблемой у Oracle. Собственно, это единственное, чем мне так сильно не нравится MS SQL.
У нас, в свою очередь, биллинговая информация разбита на события (содержит информацию о звонке) и списания (содержит информацию о стоимости) и на ту часть, которую по каким либо причинам, распознать не удалось (неуспешные транзакции и т.п.). События и Списания - отдельные таблицы. На каждый день по 4 таблицы (разбиты по временному признаку). Для систем отчётности построены аггрегаты, но не физические, а view. В случае, если пытаешься объединить все дневные view в месяц, то вываливается ошибка, сообщающая о том, что такое больше число вложенных view объединять нельзя. Приходится объединять в цикле в динамическом SQL. Каждый новый месяц - новая БД. Подобных серверов - несколько. Недавно чистил старые данные и за 2008 год я удалил много тысяч аггрегатов-view. Удалял полдня..
Так что проблема знакома. И её нужно решать.
На предыдущем месте было наоборот. Все системы были собраны в одно хранилище БД. Информация хранилась невероятно красиво. Все изменения делались только ночью. Однако пропал контроль над корректностью информации и, с увеличением числа одновременных пользователей >500 очень сильно падала производительность..
Да, забыл сказать, у хранилища не было полного бэкапа.. :)

Ratings by outbrain