使用关系数据库/ ORM或文档数据库/ ODM的动机

Question

我已经很长时间没有从零开始创建一个项目，现在document-oriented databases（以及ODM）变得非常流行，所以我必须在盲目地走向关系路线之前考虑它们。

任何人都可以尝试列出可能导致一种选择或另一种选择的动机/项目标准吗？

Answer 1

ORM /关系数据库/ SQL

优点：

• 众所周知，标准方法
• 很好地映射到具有一致结构的数据
• 很好地映射到多个实体之间具有多种关系的数据
• 具有广泛的连接功能
• 有交易
• 每秒可扩展到大量事务（使用MySQL Cluster，Fusion-IO等）

缺点：

如果性能也是一个问题，
• 难以扩展到大量数据
• 不能很好地映射到具有可变结构（或半结构化）的数据
• 持久化对象需要胶水/翻译层，这可能是性能瓶颈（如果做错了也可能非常冗长）

ODM /文档数据库/ NoSQL

优点：

• 可扩展到大量数据，以及大量相对独立的查询
• 高可用性，分片，多主，......
• 很好地映射到半结构化数据
• 很好地映射到结构更具变量的数据
• 数据模型可以更灵活
• 查询不必转换为SQL（本机NoSQL查询样式可能或可能不适合某些用途，并且没有来自SQL驱动程序/解析等的开销）
• （对于对象数据库）直接映射到对象，不需要对象关系转换

缺点：

• 经常，没有加入（或加入的限制版本）
• 通常，没有事务（或事务一致性/原子性的有限版本）

如何决定

根据数据类型和使用模式：

• 数据是否具有统一的结构？ （关系）......或变量/不一致的结构？ （文件）
• 典型用法是读/写单一类型的实体吗？ （文件）......还是由多个实体的属性组成的视图？ （关系）
• 是否需要交易？ （关系）......还是不需要交易？ （文件）

基于扩展/性能要求：

• 巨大的数据+少量，缓慢，复杂的读/写？ （数据仓库类型场景）=＆gt;关系
• 巨大的数据+大量的简单读/写？ （craigslist后端类型场景）=＆gt;文件
• 巨大的数据+快速，复杂的读/写？ =＆GT;这是困难的;使用关系并尝试扩展，或使用文档并尝试简化查询
• 中等数据+快速事务写入？ （银行类型场景）=＆gt;关系
• 中等数据+适度读/写？ =＆GT;根据供应商/工具支持，熟悉程度等选择任何

参考

• When to use MongoDB or other document oriented database systems?
• Document-Oriented Databases vs. Relational Databases, Doctrine Blog
• NoSQL: If Only It Was That Easy, BJ Clark
• Relational vs. Non-Relational, Josh Berkus

（背景：我最近没有在这方面做过任何事情，但几年前我建立了一个使用复制MySQL + Sphinx的大型系统，即关系和文档混合）