it-swarm.cn

有人什么时候可以在关系型DBMS上使用MongoDB(或类似的产品)?

我对整个NoSQL之类的东西有些困惑。您何时选择在Oracle或MySQL上使用MongoDB之类的东西?就它们之间的用法而言,我并不真正理解“差异”。

从我的理解来看,NoSQL类型数据库不是要取代RDBMS,而是它们到底要做什么?

138
user6791

我之前将CouchDB用于三个宠物项目。

  • 微型博客系统。
  • 为了保存我做的一个小笔记应用程序的信息。
  • 通用头脑风暴应用程序。

我之所以选择它而不是诸如MSSQL或MySQL之类的主要原因是使用它时所获得的灵活性。没有严格的架构。如果下线三个月,您需要一个特定的表来拥有一个额外的字段,而仅此而已,只需对其进行更改,它便会不断地变化。

我使用Apress的 Beginning CouchDB 来学习如何使用它。

例如,CouchDB使用json与数据库进行通信。如果您的语言可以POST数据,则可以使用它与数据库进行通信。

另请阅读: 为什么我应该使用基于文档的数据库而不是关系数据库? 在StackOverflow上

34
Sergio

很抱歉添加另一个答案,但是这里没有一个答案令人满意。这个答案是针对MongoDB的(与非关系数据库之外的大量其他数据存储选项相对)。

优点:

  • MongoDB每个查询的等待时间较短,并且每个查询花费的CPU时间更少,因为它的工作量大大减少(例如,无联接,事务)。结果,它可以处理每秒更高的查询负载,因此,如果您有大量的用户,则经常使用它。
  • MongoDB 更易于分片(在集群中使用),因为它不必担心事务和一致性。
  • MongoDB具有更快的写入速度,因为它不必担心事务或回滚(因此不必担心锁定)。
  • MongoDB 没有架构,如果您有一个特殊的用例可以利用它。

缺点:

  • MongoDB 不支持交易。这就是它获得大部分收益的方式。
  • 通常,MongoDB为客户端服务器创建更多工作(例如,更多的CPU成本)。例如,要联接数据,必须发出多个查询并在客户端上进行联接。
  • 即使在2017年,MongoDB也比关系数据库提供了较少的工具支持,这仅仅是因为它是更新的。 与关系同行相比,MongoDB专家也更少

经常误解的要点:

  • MongoDB和关系数据库都支持索引。 在执行大型查询方面,它们的查询性能类似
  • MongoDB不会消除迁移需求或更具体地说,随着架构的发展而更新现有数据。例如:如果您有一个依赖用户表来包含某些数据的应用程序,并且修改了该表以包含其他数据(例如,您添加了个人资料图片字段),那么您仍然需要:
    • 编写应用程序以处理未定义此属性的对象,或者
    • 编写一次迁移以为此属性输入默认值,或者
    • 如果此字段不存在,请编写代码以在查询时提供默认值,或者
    • 以其他方式处理丢失的字段
26
Pace

要无耻地从 Renesis 中窃取(实际上我是在做这个答案CW):


使用RDBMS代替其他类型:

13
Matthew Read

当您的数据不相关时,使用NoSQL数据库会带来很多好处,例如性能和可伸缩性(当然,取决于环境)。某些设计模式(例如CQRS)使在通常要求SQL数据库专用的领域中利用非关系数据变得容易得多。

通常使用诸如mongo之类的数据库来缓存数据。例如,如果您需要生成报告,则可以执行一个复杂的SQL查询,该查询可以动态地连接和聚合一堆数据,或者您可以仅从mongo数据库中获取一个已经拥有生成所需内容的json文档。那个报告。这使得读取数据确实非常容易(且速度很快!),但会使写入数据变得非常复杂(这是CQRS的来历)。

9
Graeme Hill

当您通常知道数据在哪里(而不是需要编写多个复杂的查询)时,像MongoDB这样的数据库非常有用。使用Mongo,“相关”数据要么嵌套在父数据中,要么具有主键/外键。例如,如果您有帖子和评论,那就太好了;通常,您不会在帖子的上下文之外显示评论,因此将评论包含在帖子中是很有意义的(这样您就可以获取帖子的所有评论,而无需查询单独的表)。

MongoDB是无模式的。这意味着,在大多数情况下,它将采用您要扔给它的任何数据结构。

另一方面,如果您需要使用聚合函数并感到需要通过Mongo中的嵌入或简单关系无法实现的复杂方式查询数据,那就是时候该使用像MySQL或PostgreSQL这样的RDBMS了。

MongoDB并不是要取代SQL。它仅满足不同的需求,并且MongoDB和RDBMS可以结合使用。我认为,如果您不需要数据灵活或嵌入到父文档中,MongoDB并不需要所有。使用MongoDB进行开发非常有趣,因为启动和运行项目(例如在Rails中)涉及的步骤要少得多。需要改变吗?没问题。只需在模型中添加一个属性即可。做完了.

我不能说很多其他NoSQL数据库,尽管我知道它们通常是为满足RDBMS无法满足的特定需求而设计的。有些完全驻留在内存中,或者可以很容易地分片或扩展。我非常确定Cassandra)旨在在节点发生故障时继续运行而不会丢失数据。Redis本质上是驻留在内存中的键值存储(具有持久性的定期磁盘写操作),而且还可以存储数据类型(例如集合)并对其进行排序。

8
Ravenstine

主要胜利是当您想要分片数据或拥有多个主数据库时。您可以在MySQL中分片数据,但这会带来很大的麻烦。如果您要进行大量写入操作,则将数据分片到多个服务器上通常很有用,问题是,如果要在执行此操作时具有强引用一致性,则很难(即使不是不可能)查找CAP定理。

SQL数据库具有非常好的一致性,但分区支持却很差,NoSQL数据库则倾向于相反。易于分区,但通常称为最终一致性。如果您建立的消息站点还可以,那么对于银行来说可能就不行了。

优点是,现在有多个用于存储数据的模型,因此可以选择实现方式的方式,而以前只有SQL数据库。

SE Radio在这个问题上有一些不错的插曲。

6
Zachary K

当您写入大量数据并且查询需求不太复杂时,MongoDB可以很好地工作。因此,当您在Command端实现带有事件源的CQRS时,MongoDB非常适合-即您的事件存储是MongoDB数据库。

在查询方面,由于其灵活性,我们仍然使用SQL Server数据库,其视图和WCF数据服务位于顶部。我认为在大多数情况下,您确实需要关系数据库的功能来进行查询。

1
Roy Dictus

MongoDB和RDBMS之间的直接和根本区别是基础数据模型。关系数据库将数据结构化为表格和行,而MongoDB将数据结构化为JSON文档的集合。 JSON是一种自我描述的,人类可读的数据格式。它最初是为浏览器和服务器之间的轻量级交换而设计的,现已被许多类型的应用程序广泛接受。

出于多种原因,JSON文档对于数据管理特别有用。 JSON文档由一组字段组成,这些字段本身就是键值对。这意味着每个JSON文档随处携带其自己的可读模式设计,从而使文档可以轻松地在数据库和客户端应用程序之间移动而不会失去其含义。

JSON也是在应用程序层中使用的自然数据格式。与由列和行组成的表相比,JSON支持更丰富,更灵活的数据结构。除了支持数字,字符串,布尔值等字段类型外,JSON字段还可以是数组或嵌套的子对象。这意味着我们可以表示一组复杂的关系,这些关系可以更紧密地表示我们的应用程序所使用的对象。在我们的数据库中使用JSON文档意味着我们在数据库与其服务的应用程序之间不需要对象关系映射器。我们可以以正确的形式保存数据

1
Diwakar upadhyay

如果您的数据需要大量查询,则NoSQL解决方案不是很好,而当您需要事务支持(ACID)时,NoSql并不是最佳选择。我认为NoSQL会在您需要快速进行大量读取并且结构有点特殊时按文件或按页结构进行检索而发光。但是许多NoSQL解决方案的改进相当快,因此缺点很快就会消失。无论如何,我认为关系数据库仍然适合大多数应用程序。

1
marko