Каковы хорошие подходы к миграции формата данных в бессхемных базах данных?

Как и все, есть много разных способов справиться с этим. При разработке без схемы вы, как правило, осведомлены о данных, которые храните. Дело не в том, что схема отсутствует, все данные имеют неявную схему, поэтому мы действительно говорим, что база данных не обеспечивает соблюдение схемы. Если у меня есть пользовательский объект с 10 переменными экземпляра, которые я храню в json, там ЕСТЬ схема!

Случай 1: значения могут иметь разные возможности, одно значение, массив или вложенную структуру.

Случай 2: значение необходимо изменить с одного формата на другой, например. от одного значения до массива значений

Случай 3: наличие или отсутствие ключа json, это довольно просто

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

Для случая 2: один из подходов может заключаться в том, чтобы обработать это как «по запросу» или «по запросу», чтобы вы включили логику преобразования в методы своего класса, чтобы данные преобразовывались из одного формата. в другой формат. Это означает, что вы преобразуете данные из одного формата в другой при их извлечении. Вы также можете пометить его, чтобы указать, что вы его преобразовали. Поскольку это по запросу, у вас могут быть данные, которые не «преобразовываются» в вашем хранилище документов, но если они все же будут запрошены, они будут преобразованы.

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

>>>> Когда я выполняю преобразования, я обычно преобразую один json k / v в другой json k / v неразрушающим способом, чтобы в случае ошибки в своем процессе я не изменяю исходные данные. Затем я могу на более позднем этапе удалить старый json k / v «On Demand», если я даже чувствую, что это необходимо. Это более безопасный подход к операциям такого типа.

Добавлен

Варианты 1 и 2: преобразование данных

Исходный документ JSON

user::101        
{ 
  "uid": 1234,
  "type": user,
  "my_comment": "the quick brown fox jumped over the lazy dog"
  "version": 1.00
}

Теперь предположим, что я хочу изменить его неразрушающим образом, я легко могу просто добавить новый ключ json с преобразованными данными:

user::101        
{ 
  "uid": 1234,
  "type": user,
  "my_new_comment": ["the quick brown fox jumped over the lazy dog", "comment2"]
  "my_comment": "the quick brown fox jumped over the lazy dog",
  "version": 1.01

}

Обратите внимание, что он неразрушающий, старый ключ json все еще там, в качестве альтернативы я могу сделать это, сохранить старые данные как новый ключ и вместо этого изменить ожидаемый ключ json на новый формат (массив) строки:

user::101        
{ 
  "uid": 1234,
  "type": user,
  "my_comment": ["the quick brown fox jumped over the lazy dog", "comment2"],
  "my_comment_v1.00": "the quick brown fox jumped over the lazy dog",
  "version": 1.01
}

Очевидно, что существует множество различных схем, которые вы можете использовать в зависимости от ваших предпочтений.