MongoDB应用从设计到实现 | 深度解读

本文由IT大咖说整理自MongoDB大中华区顾问 张耀星先生 在 MongoDB中文社区深圳用户组大会 上的演讲。你知道MongoDB吗？它到底是怎样的一个软件，和传统关系数据库有什么区别，在实际应用中又能做些什么事。本文带你走近MongoDB，了解它从设计到实现的全过程。 本文3216字，阅读时间预计15分钟。

张耀星，MongoDB大中华区顾问，加入IT行业10余年，从事过电商，手游及各类网站的设计制作工作。曾担任跨境电商网站http://dx.com架构师，Universal Orlando Resort前端总工程师等。现就职于MongoDB为国内各大企业提供MongoDB咨询服务。
嘉宾分享视频地址：http://t.cn/REywIJH

大家好，我是中文社区的张耀星，平时在社区的微信群里跟大家互动比较多。今天在线下跟大家做一些交流。今天我演讲的内容是关于MongoDB的应用，如何从设计到实现的全过程，该做什么事情，要避免怎样的问题，做一个经验上的介绍。

MongoDB的哲学

在座的朋友可能有些去参加过MongoDB的考试。目前在中国一共只有不到20位朋友通过了这个考试。在这个考试中有一个章节，叫做MongoDB的哲学。它需要我们去了解MongoDB背后设计的思想。

大家次看到MongoDB的时候肯定会有一些疑问，这是什么东西？和普通的数据库有什么区别？到底能干什么？

我们可以去网上看看用过的人怎么说。把大家的观点都看过之后，才能对MongoDB有一个更深入的了解。了解之后我们会发现，其实MongoDB和关系数据库本质的一个区别是，关系数据库是关系型的，而MongoDB是一个非关系型数据库。

在过去的几十年中，都是关系模型占领统治地位。在大家的心中已经根深蒂固地把数据库和关系模型画上了等号。所以使用的时候很多人在思维的转化方面非常困难，也直接导致了使用方式的不正确，以至于MongoDB在性能上的表现达不到期望的标准。

从实际上来说，关系模型只是一个理论，理论和现实还是有一定差距的。我们用理论只是为了更好的描述现实中的一些东西，让大家更容易理解。关系数据库和非关系数据库这两种理论同样是以前在用关系模型来描述现实中的东西。在这么多年后，我们要扭转一下之前的这种固有思维。

MongoDB要做的就是把数据变成一个应用，直接能够使用而不需要再进行额外处理的一个过程。而且它要非常快的把数据缓存在内存当中，它要能做各种各样的事情。这个其实就是我们常说的反范式。但是到目前为止，反范式不再是我们的选择。在范式的基础上，我们可以选择反范式的模型来设计数据库。这就是MongoDB背后的思想，跟关系数据库明显的一个区别。

如何使用MongoDB解决实际问题

首先我们应该去了解这个问题有什么特点，不同的特点会决定我们如何来选择一个合适的数据库。

如果我们决定用MongoDB来实现这个软件，我们的过程和传统过程不一样的地方就在于详细设计。在关系模型的应用当中，详细设计包含了数据库设计、数据结构设计。要把这个数据结构转换成一个关系模型，就需要设计数据库模型来做这个事情。主要区别就在于，用MongoDB来实现之后，我们要得到数据结构，并了解我们会怎样使用这个数据结构，然后才进行数据模型的设计。也就是说我们的数据模型没有一个固定的原则，而是根据我们怎样去使用这个数据，来决定怎样才是更好的数据模型。

关系模型是根据所需要的数据结构范式化得到一个关系模型，非关系模型同样是根据应用所需要的数据结构，根据不同的原则来决定这个数据终变成什么样子。

使用非关系数据库的关键点

个就是要转变思路。我们的原则是怎样方便应用更高效的去使用读取或者去写入。思路首先要转变过来，否则后面做的所有的工作都得推翻重来。不要按照关系数据库的思路来设计非关系数据的模型。

第二个就是要积累经验。只有在积累一定的经验之后，看到一些数据时就会知道，如果这个数据用非关系模型来设计应该是怎样的。

第三个就是重要的背后思想。在MongoDB的这个应用中，我们把数据看作是应用的一部分而不是独立的一个部分。以前进行软件迭代的时候，做完分析概要设计编码测试之后，要进行下一轮的迭代，要再具体做需求分析等等。以前我们的这个过程只是针对应用来做，但对MongoDB来说，这个过程不光要针对应用来做，还要针对数据来做。当需求改变之后，数据结构也需要相应的去改变。把数据和应用紧密地联系在一起，这样才能保证应用能够以高效的方式读取或者去写入数据。

实际应用

次接触MongoDB的时候，我当时想找个有一些关系数据库不能满足的特点的应用，而且这个系统要对现有的系统影响不大，它又要能用上MongoDB的一些特性。后我在12年的时候做了跟大家一样的选择，我用它来存日志。后来我把这个做成了一个开源的项目。

对MongoDB的需求

速度要快

记日志肯定不能影响现有系统的运行。日志的量非常大，但通常不必保存很久，也会要进行一些查询，记日志也就是这些基本的要求。如果没有这个系统，写到文件系统上，就要用记事本或者文件编辑工具去打开，然后搜索会很麻烦，当时我们考虑到这一点，所以做成了这样一个系统，大家随时都可以去查日志。

第二 写入

按照日志的范式化模型来做，系统会要求我们先写日志，再写一堆异常，导致效率非常低。用MongoDB来做的话，利用非关系数据库的一个目的，把它全部写在一起，节省更多的时间，能够让我们更高效的去写入。如果把设计成模型的话，那这些查询也都很容易地满足到。关系模型可以根据每一个innerException来查询，但是它要写入更多次会更慢，处理逻辑会更复杂，让应用的逻辑更复杂，这就是它的一个优势和一个劣势。

第三 方案

我们一直强调的就是没有好的方案，只有合理的方案，这是设计当中很重要的一个原则。

第四 模式演化

现在加入了一个新的需求，把一些自定义的数据加到日志里。对MongoDB来说反而是一件更容易的事情，我们把自定义的结构写在了原来的文档中，这样的话能够使扩展起来非常容易。模式的演化会造成数据结构有非常大的变化，因为数据结构是根据读写模式来决定的，所以如果当需求发生了很大变化的时候，可能读写的模式都已经改变了，这个时候就要重新做一个设计，数据要迁移，这都是有可能发生的。这也是我们前面所提到的一个很重要的思路——数据是应用的一部分，它会随着应用一起迭代。这也是MongoDB设计的过程中一个很重要的原则。

这就是今天分享的全部的内容，谢谢大家！