Понимаю вашу позицию и благодарен за комментарии. Все что хотел сказать: если зменения структуры происходят часто — механизм (который так или иначе базируется на инструментарии базы данных, ALTER TABLE и т.д.) начнет отравлять жизнь, требуя дополнительных затрат ресурсов. Эту проблему нужно решать заранее.
Liquibase не является панацеей, не обладает магическими свойствами и не сможет обойти ограничения СУБД.
С системой работали продолжая развивать — характерная ситуация для многих современных проектов. Касательно вышего примера: если данные/структура БД не меняется во время обновления ПО — обновления можно проводить хоть каждый час.
Что делать если во время обновления вам необходимо изменить структуру базы или трансформировать данные, делая их совместимыми с новой версией ПО? В этом случае процесс перехода/преобразования будет занимать значительное время. Именно такая ситуация описывается в статье.
Касательно «вредности»: предупрежден — вооружен. Никто не призывал реализовать описываемый метод, наоборот, статья демонстрирует реальные проблемы из жизни реального продукта и призывает не делать ошибок на самых ранних стадия проектирования.
Описываема история реальна и вполне определенно намекает на большое число проблем как с процессом разработки (набор инкреметальных изменений, затрагивающих структуру базы данных) так и с последующим обновлением реальных баз данных.
Коротко: если production база имеет значительный размер и вы захотите менять ее структуру часто и кардинально — потери времени, нервов и волос, в разных пропорциях, неизбежны.
Материал обязательно подготовлю. Кратко: использую Hudson (стоит обратить внимание на Jenkins после раскола) и набор плагинов под конкретного заказчика.
Основная идея: выделить функционал, модули и т.д., с которым можно работать как с черным ящиком. Затем достаточно определить значения которые подаются на вход, получить результат, проверить его и использовать в дальнейшем как эталонный. При должной настойчивости база тестов даже на ранних этапах позволяет идентифицировать нежелательные отклонения, на выявление которых тестерам нужна как минимум неделя.
Пара хитростей:
1. тестами в первую очередь становятся реальные проблемы
2. тесты, по времени выполнения, делятся на три категории: до 60 секунд, до 5 минут, до 10 минут. Стараюсь поддерживать соотношение 80% 15% 5%. Первый тип запускается после каждого комита.
Да, вы правы, документо-ориентированные базы являются вполне естественным и очень рациональным решением.
Идею, кстати, можно развить и попытаться абстрагироваться от хранилища как такового. Если вам близка экосистема Java неплохим ответом может стать Content repository API for Java и ModeShape в качестве реализации.
MySQL — наследие предков (еще раньше оракл был), но вы правы, желание избавиться от реляционной базы данных появилось сразу после анализа системы. Но мешало этому следующее:
1. заказчик с огромным нежеланием соглашался на какие-либо серьезные изменения (очень часто заказчик создает больше проблем, чем сам продукт)
2. остается проблема существующих клиентов, их нужно опять «мигрировать» (кстати, изначально на выбор хранилища повлияло наличие у потенциальных клиентов баз данных и MySQL, в частности, хотя даже встраиваемый вариант, BerkeleyDB например, был бы в разы лучше)
3. заметил в корпоративной среде наличие некоторых предубеждений, яркий пример: «вы используете хранилище название которого я не знаю? тогда я не могу купить вашу систему», а знают обычно oracle, продвинутые еще mysql
то что скопилось в базе — почистили все что можно было почистит, затем пожали
касательно комитов — на самом деле их не так много, учитывая использование централизованного репозитория и наличие соответсвующих(стоит сказать очень уродливых) ограничений
Ну а с XSLT — да, многим вариант покажется ужасным. Нам он не совсем подошел.
Такой подход уменьшит размер хранимых данных еще на порядок. По сути вы предлагаете хранить изменения в инкрементальном виде.
Я все еще не отсавляю идею описать другой проект, в котором переход базы с несколькими миллионами пользовательских профайлов (структуры с пользовательскими настройками средней сложности) не требовал ни какого-либо времени бездействия ни дополнительных операций. Редеплой приложение — все что реально было нужно.
Никаких проблем. Проект пришел в компанию таким каким пришел. Предполагаю, опыт в любом случае интересен. Любая компания, занимающаяся аутсорсингом, может получить нечто похожее.
Проблема в том что универсального решения не существует и я все еще надеюсь кто-нибудь поделится своим опытом, буквально в двух словах.
Вы правы, версионность осталась на месте. Но, сравните ресурсоемкость добавление/удаления 100 полей в таблицу с измеенением структуры XML представления.
Касательно второй части вопроса: при переходе к scheme-less базе потери и ограничения очевидны. В описываемом случае специфика продукта позволяла выполнить такой переход практически без боли. Пожалуйста, не воспринимайте написанное как абсолютный рецепт счастья. Говорить о применимости того или иного подхода имеет смысл исключительно в контексе конкретной проблем/продукта.
На всякий случай: система интенсивно использующая SQL с частотой изменений базы 2-3 обновления в год вполне нормально будет переносить ALTER TABLE. Система с 30-100 новыми параметрами в месяц и достаточно сложными структурами данных при аналогичном подходе покажется адом.
Liquibase не является панацеей, не обладает магическими свойствами и не сможет обойти ограничения СУБД.
Content Repository API for Java (JCR)
Modeshape
How FriendFeed uses MySQL to store schema-less data
Последний пример очень показателен.
Что делать если во время обновления вам необходимо изменить структуру базы или трансформировать данные, делая их совместимыми с новой версией ПО? В этом случае процесс перехода/преобразования будет занимать значительное время. Именно такая ситуация описывается в статье.
Касательно «вредности»: предупрежден — вооружен. Никто не призывал реализовать описываемый метод, наоборот, статья демонстрирует реальные проблемы из жизни реального продукта и призывает не делать ошибок на самых ранних стадия проектирования.
Коротко: если production база имеет значительный размер и вы захотите менять ее структуру часто и кардинально — потери времени, нервов и волос, в разных пропорциях, неизбежны.
Основная идея: выделить функционал, модули и т.д., с которым можно работать как с черным ящиком. Затем достаточно определить значения которые подаются на вход, получить результат, проверить его и использовать в дальнейшем как эталонный. При должной настойчивости база тестов даже на ранних этапах позволяет идентифицировать нежелательные отклонения, на выявление которых тестерам нужна как минимум неделя.
Пара хитростей:
1. тестами в первую очередь становятся реальные проблемы
2. тесты, по времени выполнения, делятся на три категории: до 60 секунд, до 5 минут, до 10 минут. Стараюсь поддерживать соотношение 80% 15% 5%. Первый тип запускается после каждого комита.
Идею, кстати, можно развить и попытаться абстрагироваться от хранилища как такового. Если вам близка экосистема Java неплохим ответом может стать Content repository API for Java и
ModeShape в качестве реализации.
1. заказчик с огромным нежеланием соглашался на какие-либо серьезные изменения (очень часто заказчик создает больше проблем, чем сам продукт)
2. остается проблема существующих клиентов, их нужно опять «мигрировать» (кстати, изначально на выбор хранилища повлияло наличие у потенциальных клиентов баз данных и MySQL, в частности, хотя даже встраиваемый вариант, BerkeleyDB например, был бы в разы лучше)
3. заметил в корпоративной среде наличие некоторых предубеждений, яркий пример: «вы используете хранилище название которого я не знаю? тогда я не могу купить вашу систему», а знают обычно oracle, продвинутые еще mysql
Признаюсь, я собирался заменить базу key-value хранилищем. Напримре: project-voldemort
касательно комитов — на самом деле их не так много, учитывая использование централизованного репозитория и наличие соответсвующих(стоит сказать очень уродливых) ограничений
Ну а с XSLT — да, многим вариант покажется ужасным. Нам он не совсем подошел.
Я все еще не отсавляю идею описать другой проект, в котором переход базы с несколькими миллионами пользовательских профайлов (структуры с пользовательскими настройками средней сложности) не требовал ни какого-либо времени бездействия ни дополнительных операций. Редеплой приложение — все что реально было нужно.
Проблема в том что универсального решения не существует и я все еще надеюсь кто-нибудь поделится своим опытом, буквально в двух словах.
Касательно второй части вопроса: при переходе к scheme-less базе потери и ограничения очевидны. В описываемом случае специфика продукта позволяла выполнить такой переход практически без боли. Пожалуйста, не воспринимайте написанное как абсолютный рецепт счастья. Говорить о применимости того или иного подхода имеет смысл исключительно в контексе конкретной проблем/продукта.
На всякий случай: система интенсивно использующая SQL с частотой изменений базы 2-3 обновления в год вполне нормально будет переносить ALTER TABLE. Система с 30-100 новыми параметрами в месяц и достаточно сложными структурами данных при аналогичном подходе покажется адом.