在无模式数据库中迁移数据格式有哪些好方法?

Ale*_*xey 2 data-migration document-oriented-db schemaless nosql couchbase

如果您使用无模式数据库(特别是面向文档的数据库,如CouchDB,Couchbase,MongoDB)并希望更改特定对象的数据表示格式,则可以保留旧格式的现有记录并以新格式创建新记录.它被宣布为无模式数据库的主要优势之一(我认为因为你可以避免停机).另一方面,处理同类数据的许多格式是不方便和低效的.那么在无模式数据库中将数据从一种格式迁移到另一种格式的好方法/策略是什么?

sca*_*bl3 7

像所有事情一样,有许多不同的方法来处理这个 在无模式开发中,您通常会认识到要存储的数据.并不是缺少模式,所有数据都有一个隐式模式,所以我们真正说的是数据库没有强制执行模式.如果我有一个用户对象,其中包含我存储在json中的10个实例变量,那么就有一个模式!

情况1:值可能具有不同的可能性,单值,数组或嵌套结构

案例2:价值需要从一种格式改为另一种格式,例如.从单值到值数组

案例3:存在或不存在json密钥,这非常简单

对于案例1:如果您期望json值变化,则需要将特定值的多样性写入您的App Code逻辑,如果它是一个字符串,请执行此操作,如果它是一个数组,请执行此操作.

对于案例2:一种方法是将"处理请求"或"按需"处理此方法,以便将转换逻辑烘焙到类方法中,以便将数据从一种格式转换为另一种格式.这意味着在检索数据时将数据从一种格式转换为另一种格式.您还可以标记它以表明您已对其进行了转换.由于它是On Demand,您可能拥有未在文档存储中"转换"的数据,但如果它被请求,它将被转换.

案例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
}
Run Code Online (Sandbox Code Playgroud)

现在让我们说我想以非破坏性方式更改它,我可以轻松地添加一个具有转换数据的新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

}
Run Code Online (Sandbox Code Playgroud)

注意它是非破坏性的,旧的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
}
Run Code Online (Sandbox Code Playgroud)

显然,根据您的偏好,您可以使用各种不同的方案.