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

时间:2012-11-20 12:21:21

标签: nosql data-migration couchbase document-oriented-db schemaless

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

1 个答案:

答案 0 :(得分:7)

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

案例1 :值可能有不同的可能性,单值,数组或嵌套结构

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

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

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

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

案例2的替代方法:通过工作流程迭代并转换数据。因此,不是等待它被请求,而是实际创建一个工作来根据需要更改数据,将转换逻辑烘焙到工作者本身(可以在应用程序代码中使用相同的类定义)。在Couchbase中,您可以创建视图(二级索引)或使用弹性搜索来迭代特定类型的文档。如果您创建了一个工作流程系统,您可以与许多工作人员并行完成大量工作。

<强>&GT;&GT;&GT;&GT; 当我进行转换时,我通常以非破坏性方式将一个json k / v转换为另一个json k / v,这样如果我在我的进程中出错,我就不会改变原始数据。如果我觉得有必要,我可以稍后再删除旧的json k / v“On Demand”。对于这种类型的操作,这是一种更安全的方法。

<强>追加

案例1&amp; 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密钥更改为新格式( array)而不是字符串:

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
}

显然,您可以使用多种不同的方案,具体取决于您的偏好。