2

很久没有从头开始创建项目了，现在面向文档的数据库（以及ODM）已经非常流行，所以在盲目走关系路线之前，我必须考虑它们。

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

4

1 回答 1

11

ORM/关系数据库/SQL

优点：

  • 易于理解的标准方法
  • 很好地映射到具有一致结构的数据
  • 很好地映射到具有多个实体之间的多种关系的数据
  • 具有广泛的加入能力
  • 有交易
  • 可扩展到每秒大量事务（使用 MySQL Cluster、Fusion-IO 等）

缺点：

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

ODM/文档数据库/NoSQL

优点：

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

缺点：

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

如何决定

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

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

基于扩展/性能要求：

  • 大量数据 + 少量、缓慢、复杂的读/写？（数据仓库类型场景）=> 关系
  • 庞大的数据 + 大量的简单读/写？（craigslist 后端类型场景）=> 文档
  • 海量数据 + 快速、复杂的读/写？=> 这很难；要么使用关系并尝试扩展它，要么使用文档并尝试简化查询
  • 中等数据 + 快速事务写入？（银行类型场景）=> 关系
  • 中等数据+中等读/写？=> 根据供应商/工具支持、熟悉程度等选择任何一个

参考

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

于 2012-11-28T07:16:17.640 回答