Шаблоны для изменений схемы в базах данных документов

Question

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

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

Такими изменениями могут быть

• добавление новых полей
• пересчет значений полей (разделение брутто на нетто и НДС)
• удаление полей
• перемещение полей во внедренный документ

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

Другой связанный с этим вопрос - как обрабатывать изменения схемы изнутри используемой среды языка программирования.Обычно изменения схемы происходят путем изменения определения класса (я буду использовать Mongoid OR-Mapper для MongoDB и Ruby).Как мне обращаться со старыми версиями документов, которые больше не соответствуют моему последнему определению класса.

Answer 1

Это очень хороший вопрос.

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

Так что проблема, а также решение исходит из логики вашего приложения.

Допустим, у нас есть модель Person, и мы хотим добавитьполе.В настоящее время в базе данных сохранено 5.000.000 человек.Проблема в следующем: как добавить это поле и сократить время простоя?

Возможное решение:

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

2. Напишите задачу, которая добавляет это поле каждому человеку в базе данных.

3. Обновите производственное развертывание с помощью новой логики.

4. Запустите сценарий.

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

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

Теперь допустим, что мы хотим пересчитать поле, такое как значение НДС.Мы не можем сделать то же самое, что и раньше, потому что некоторые продукты с НДС А и другие с НДС Б. не имеют смысла.

Итак, возможное решение будет:

1. Измените логику приложения, чтобы оно показывало, что значения НДС обновляются, и отключите операции, которые могут его использовать, например, покупки.

2. Напишите скрипт для обновления всех значений НДС.

3. Повторно разверните с новым кодом.

4. Запустите скрипт.Когда он закончится:

5. Повторное развертывание с полным кодом операции.

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

Теперь допустим, что мы хотим опустить поле.Процесс будет примерно таким же, как и первый.

Теперь, перемещая поля в встраиваемые документы;это хорошо!Процесс будет похож на первый.Но вместо проверки существования поля нам нужно проверить, является ли это внедренным документом или полем.

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