Как реализовать изменения схемы в системе хранения NOSQL

Question

Как вы управляете серьезным изменением схемы, когда вы используете хранилище Nosql, такое как SimpleDB?

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

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

• не имеет эквивалента оператора обновления SQL.
• Из-за распределенной природы SimpleDB нет никакого способа узнать, когда внесенные вами изменения в базу данных «отфильтровываются» во все узлы, на которых работает ваше клиентское программное обеспечение.

Вот некоторые решения, о которых я подумал:

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

• Каждый элемент имеет атрибут версии, который указывает формат, использованный при его сохранении.Клиент использует этот атрибут при загрузке объекта в память.Затем объект может быть преобразован в последний формат при обратной записи в SimpleDB.Проблема заключается в том, что новое программное обеспечение необходимо развернуть на всех серверах, прежде чем произойдет какая-либо запись в новом формате, или клиенты, использующие старое программное обеспечение, не будут знать, как читать новый формат.

Все это довольно сложно, и мне интересно, если я что-то упустил?

Спасибо

Ричард

Answer 1

Я использую что-то похожее на ваш второй вариант, но без атрибута версии.

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

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

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

Изменение поля - это просто комбинация этих двух операций.

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

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

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

Answer 2

RavenDB, другая база данных NoSQL использует миграцию для достижения этой целиизменяет схему на более новую при загрузке версии X и преобразовании в версию Y с сохранением