代码之家  ›  专栏  ›  技术社区  ›  Ahmad

什么类型的情况适合同时使用关系数据库和NoSQL数据库?

  •  5
  • Ahmad  · 技术社区  · 14 年前

    这不是NoSQL对SQL类型的问题。我对可以使用RDBMS和NoSQL数据库以及 使用这种组合非常合适 . 总的来说,我理解“这取决于”手头的情况和任务,但我的想法是,一定有一些普遍的/共同的 这种组合非常有用的情况。

    上述每一种解决方案都有自己的优点和缺点——我追求的是能够充分利用和利用两者优点的情况/情景。

    在我看来,其中之一可能是电子商务。RDBMS上的付款、交易等(想想ACID )以及NoSQL数据库中的产品信息和目录。但是,它合适吗?

    作为另一个例子,日志记录等应用程序的横切关注点很可能非常适合NoSQL类型的解决方案。

    或者,为什么不同时使用这两种技术呢?

    编辑:重申一下,我理解SQL和NoSQL都有其固有的优点和缺点,并且某些类型的情况更适合于上述数据存储中的一种。

    我知道Facebook、Google等巨头可能会结合使用这些技术,但是 几乎全部 大多数情况下,我不认为大多数这样的成员将永远工作在如此巨大的解决方案。更典型的日常工作。

    RavenDB是一个支持ACID事务的NoSQL解决方案

    5 回复  |  直到 14 年前
        1
  •  1
  •   nvogel    14 年前

    一个很好的例子是,在多个节点上同时更新的任何分布式数据存储都需要支持潜在的复杂即席查询。节点将是“最终一致的”,这意味着任何特定的节点在任何时间点的数据图片中都可能有间隙。

    这很适合RDBMS,因为可以通过关系之间的“外部”连接非常简单地处理间隙。关系模型应该比基于图的模型更适合这种情况,因为图模型依赖于不同数据元素之间的导航路径。如果缺少一个元素,则该图将被分解为两个图,因此任何基于路径的查询都可能无效。在关系模型中不存在这个问题,因为关系数据库是非导航的——数据元素之间没有结构“链接”,因此对数据的查询的“形状”不需要仅仅因为数据丢失而改变。

        2
  •  1
  •   metdos    14 年前

    一个显而易见的答案是,在一个简单的应用程序中,报告一个比另一个更合适。

    例如,您可能希望在OLTP工作中使用像RavenDB或Couch这样的文档数据库,因为它为您提供了保存实体的方法,并将这些实体查询成跨文档的扁平投影(单个查询视图)。(拉文德比库奇德更厉害,但那既不在这里也不在那里;—))

    您还可以使用它进行简单的报告,使用Map/Reduce为您提供一些统计信息,以便在某些页面(流行产品、标记云等)上显示。

    但是,许多报表系统都是为查询关系存储而构建的,因此您可能希望将数据复制到报表数据库中。

    例如,在RavenDB中,您可以选择获取任何索引,并自动将该索引中的数据复制到关系存储中。

    这是有意义的,因为数据以关系格式表示您可以进行复杂的跨文档查询并与现有的报表产品集成,而不妨碍标准的OLTP工作或文档数据库设计。

    这只是众多答案中的一个,因为还有其他例子表明,一种特定类型的数据存储更适合于特定的目的,归根结底,这是无法回避的。(除非你相信沃尔特的人)

        3
  •  1
  •   Tom Clarkson    14 年前

    除非在关系数据库无法正常工作的情况下进行操作,否则NoSQL的最大优势是易于开发,比如不需要ORM或数据库升级脚本。一旦开始在系统的某个部分使用SQL,就只需花费很少的额外精力就可以在其他部分使用它。

    几乎在任何项目中,都会有更适合特定类型数据存储的组件。重要的问题是,这种差异是否足以证明使用多个数据存储的开销是合理的。一般来说,这意味着scale、即席报告和数据结构的组合,它们不能很好地映射到关系数据库。

        4
  •  1
  •   Marcus    12 年前

    NOSQL可能用于从SQL数据存储复制数据。在这个场景中,我希望从mobile SQLITE记录创建文档,并依赖couch或mongo将其复制到服务器上的nosql。然后,服务器SQL可以处理传入的文档。

        5
  •  0
  •   Sébastien VINCENT    14 年前

    这不是一个真正的编程问题,但我想是这样的。

    如果你考虑CAP定理 http://en.wikipedia.org/wiki/CAP_theorem 您可以假设关系数据库集中于一致性和可用性,而NoSQL则关注可用性和分区容忍度。 最终的 一致性)。

    如果您希望SQL查询真正一致,那么应该考虑使用RDBMS。如果不是先决条件,那么可以使用NoSQL数据库。

    这就是为什么大多数时候,最好的答案是两者兼用,两者兼得。