结合关系型和文档型电影数据库

Question

作为一个架构设计头脑风暴，我正在思考如何为电影数据库定义模式，其中大量的文本搜索委托给基于文档的数据库(例如。(弹性)而rdbms则保留关系，并通过ID查询。

想象一下有以下实体..。

• 演员(id，姓名，道布)
• 演播室(身份证，姓名，城市)
• 电影(id，标题，描述，studio_id)

..。有关系

• 演员N.N电影
• 工作室1.N电影

现在，我将这两种数据库类型结合起来的方式是：

• RDMBS具有上面描述的3个实体和N.N关系的联接表
• 弹性的具有以下特性的单一索引(电影)：
  • 标题txt
  • 描述txt
  • 工作室txt
  • 演员txt阵列
  • movie_id 整型

要回答的问题：

1. 弹性文档应该保留RDBMS条目的id吗？
2. 我应该在RDBMS中保留(从而复制)电影标题和描述吗？
3. 如果是#1 == true，我还应该保留演播室和演员的身份证吗？

Answer 1

选择一个记录系统.

当这两个数据库不一致时会发生什么？哪个是对的，哪个是需要纠正的。

如果你选择：

• 文档数据库作为记录系统，RDBMS应该跟踪文档id。
• RDBMS作为记录系统，则文档数据库应该跟踪RDBMS实体id。

一个数据存储可能是这些有界上下文的真理系统，而另一个数据存储系统则是这些有界上下文的真理系统。

请不要说两者都是给定数据集的记录系统。那条路是用鲜血铺成的。

无论你选择哪一个，另一个都是为了提供优化。在提供特性/属性X方面，它比其他数据存储区更快或更方便。

这意味着一种重复和去同步的措施。您需要考虑如何验证和维护数据的完整性。

此外，优化数据存储可能会落后于时代，略微过时。这可能只有几千秒，但可能更长.陈腐会影响你的业务流程吗？

您应该设计数据结构，以便与您使用它的方式保持一致。

如果您正在执行弹性搜索，存储行ID可能是有意义的。用这个身份：

• 可以更优化地执行RDBMS查找。
• 执行联接或记录过滤客户端的业务逻辑可以在较小的错误范围内这样做。
• 该id可以显示给客户，也可以显示为错误日志。

在这些情况下，数据在定义上是有用的。它甚至可以促进系统的健壮性或速度。

相反，如果你把id放在那里，说有一天它会很有用。它不仅毫无用处，而且还积极地减缓了系统的运行速度。

• 每个文档/记录都必须分配额外的存储空间，以及不确定的内容，因此降低了查询的整体性能。
• 数据传输必须移动额外的数据。这减少了可用于有用数据的带宽。
• 必须在客户端的内存中存储和操作这些数据(假设它已检索到)。这减少了用于执行实际有用工作的计算资源，甚至可能会使您开始达到容量限制时更难执行有用的工作。

如果您不确定该走哪条路，那么不为其编写代码通常是更好的选择。

不存在的部分不会抛出异常或行为不当，也不会导致您稍后再处理它。

唯一的例外是，如果零件太贵，以后再加。在这种情况下:你真的需要它吗？问两次这个问题。