开发者学堂课程【MongoDB 快速入门：MongoDB 最佳实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/49/detail/1006
MongoDB 快速入门-MongoDB 最佳实践（一）
内容介绍：
一、MongoDB 应用场景与选型
二、阿里云 MongoDB 产品特性及服务
一、MongoDB 最佳实践
1、MongoDB 数据库定位
数据库分两大类：
（1）. OLTP（Online Transaction Processing）指在线业务，交易时业务，即联机事务处理。
（2）. OLAP（On-Line Analytical Processing）联机分析处理。
OLTP 一般指手机应用、网页应用，与人打交道，特别是有交互式的。需要数据库能够提供毫秒级的响应。
OLAP 指一般在晚上可以跑一个P，做分析处理，跑完后把结果写到表里面，第二天来拿结果即可。
OLTP 和 OLAP 最大的区别就是时效性的区别，分析型和事物型的场景。
MongoDB 主要是 OLTP 型的数据库，跟 Oracle、MySQL、SQL Server 等 OLTP 型 数据库对标。
原则上Oracle和MySQL 可以做的事情，MongoDB 基本都能做（包括ACID事务），只是做法不太相同。甚至大家常说Mongo不支持事务，但从 MongoDB 4.0 也开始完全支持跟交易相关的强事务。
MongoDB 的三个优点：
（1）、横向扩展能力，数据量或并发量增加时候架构可以自动扩展。MongoDB 是原生的分布式数据库，通过它的分片技术，可以做到 TB 甚至 PB 级的数据量，以及数千数万数十万到百万级的并发，或者是连接数等等，这些都有很多案例遵循。MySQL 需要一些特定的分库分表，或者第三方的解决方案，不是原生，在很多地方仍旧存在瓶颈。
（2）、MongoDB一个非常强的特性是它的灵活模型，适合迭代开发，数据模型多变场景。现在的开发都是讲究快速迭代，往往在第一个版本出来的时候，需求是不完整的，要在过程中不断完善，这个时候有一个比较灵活的、不固定结构的数据库，非常有优势，在开发时间上会节省非常多，在现代化的开发上是有助的。
（3）、JSON 数据结构，适合微服务/REST API。REST API 的后面其实都是我们现在用的都是一种REST或者 JSON 的数据结构，而 MongoDB 是一种非常原生的支持。
2、选型考量
基于技术需求选择 MongoDB
第一个指标：数据量。这是最简单，最直观的。假设单表里面要保存的处理数据超过亿或者10亿的级别，而且使用挺频繁，这个时候就可以考虑使用 MongoDB。这种场景下如果用 MySQL 做分库分表，效率、稳定性、可靠性与专门设计运载大数据量的MongoDB 相比是远远不如的。
第二个指标，数据结构模型。如果数据模型非常稳定、结构、需求非常清楚，还不会有很大区别。但如果是很多时候我们做迭代开发，或者是做一些场景，我们知道这个数据还不明确， MongoDB是非常有优势的，因为它允许过程中快速迭代，不需要去修改它的 Schema，继续可以支持你的业务。
第三个指标，高并发读写，MongoDB 通过分片直接支持。比如线上应用，网上有可能是有很大很多的用户一起来使用，并发读写会非常高，这个时候考虑到 MongoDB 的分布式集群，分片，可以支撑非常大的并发。基于单机的，比如 Oracle、MySQL、SQL Server 可能都会有很大的瓶颈。
还有一些比如说你想做跨地区集群，甚至跨洋、跨国、跨地区，或者是做一些地理位置查询，像摩拜单车等等之类的，以及一些大宽表，我们经常要来做海量数据的这种分析，MongoDB 都是非常不错明显的优势。
基于场景选择 MongoDB
基于场景选择 MongoDB 常见的有：移动/小程序 APP、电商、内容管理、物联网、SaaS 应用、主机分流、实时分析、数据中台等。
接下来，根据一些具体的案例对以上加强理解。
1、移动应用: 对我们的用户，特别是对一些互联网公司来说，移动/小程序 APP 是必不可少的，它的特点是：它是基于REST API/JSON 进行交互，往往采用的是互联网公司的迭代式开发，两个星期一个迭代、一个版本。著名的互联网公司每天都会出版本，月月新、周周新、天天新。
手机移动的场景，会有非常多的地理位置。 成功的 APP 用户往往不只是几万几十万，甚至百万千万上亿， 像微信、字节、抖音等移动应用场景，这些都是一些技术需求。
MongoDB在这些方面都是不错的支撑。
字节跳动:
去年的一位工程师分享过，他们刚刚开始在大规模的把 MySQL的一些集群迁移到 MongoDB，去年时，他们已经有150多个 MongoDB的集群，大概已经有350 多个用户项目在使用 MongoDB。
他们在使用 MongoDB 主要的考量就是并发量和数据量达到一定地步以后，MySQL 集群的性能不能稳定工作，毛刺比较多。还有扩容困难，会花费大量时间，和业务迭代速度没法跟得上。他们每天要发布几十个版本，就算DBA 响应非常及时，效率也不会很高，总不如没有 DBA 的效率高。
MongoDB 就不需要 DBA 来操作。它们的一些应用大家可以参考，是很多一部分是在线 TP 业务，直接是他们一大堆的手机应用，后面可能就是用 MongoDB，然后还有一些跟地理位置相关的查询，是MongoDB来支撑的。有不少游戏的日志、运行、状态，都是通过 MongoDB支撑，还有一些就是中台系统，里面很多用MongoDB来做一些元数据管理。
主机分流/读写分离：
这个场景在金融行业比较常见。
金融行业的特点是业务系统、交易系统用的很多的都是IBM或者小型机或是主机，上面运行一些 DB2 或者比较老的关系数据库。有个特点是使用时按量付费的，它并不是买断的，当读一次写一次都有额外的计费，叫 MIPS。
最近几年，银行在做大量手机端的开发，把这些交易数据放到手机端，这时，手机端对交易数据的读的流量猛增。根据一个银行的统计，现在99%的流量都是读，这些读的流量对成本增加非常高，这是一个原因，还有其他原因就是对这种关系业务模型改动非常困难，想去创新，想去增加一些新的业务，需要非常高的成本。
所以有一个策略，就是把这些数据拿出来，做读写分离，用另外一种数据库来支持这种读。在这样的场景下，MongoDB 是非常好的选择。因为MongoDB有非常好的查询能力，性能非常高，相比关系数据库。
MongoDB 是基于内存的一种读写，它的分布式意味着可以把海量的数据、几年的历史数据拿过来放到热数据库里面，让其支撑手机端的交易查询。比如海外的花旗银行，Barclays国内的中国银行在近些年上新了这种业务系统。
实例场景：中国银行
首先业务需求是希望在手机银行里支撑历史交易数据的查询，也就是说，他们想跟支付宝一样。它们想查询三年的账单，但三年数据每天都有 6000 万，月末，还有几个亿，加上三年算下来有几百、几千亿的数据，是非常海量的数据量
中国银行希望能够在手机 APP 上能够让用户直接来查询历史的交易数据，还有一些其他金融日历等应用，那这些两个 APP 的需求，就是说需要把用户所有的或者最近几年的这种金融数据都能够放到一个快速查询的库里面来做这个事情。
数据还是比较大的，因为他们一天的这种交易都有6000万，多的时候有好几个亿，他们希望第一个阶段能够支撑三年的数据，算下来有600亿，这样的数据量放在一个库里面肯定是不可能，分库分表也非常麻烦，因此他们最终是选择了 MongoDB 分片集群来做这样的事情。
上图所示是架构图，首先它把借记卡系统和信用卡系统有的基于Oracle 的，使用 CDC 的技术，是实时数据库同步的机制，把数据从库里边“增删改”都拿出来，通过 Spark 进行计算处理，然后放到 MongoDB 的集群里面，再变成 JSON 文件的格式， 再通过 API 的后端，把这些数据暴露出去给手机 APP 的前端。
通过这种方式，首先，数据实时的从主机系统同步过来，其次，通过 API 的方式，可以提供非常高效率、高性能的查询给到手机 APP，保证用户的体验。这种场景是比较常见的金融数据的查询库，在很多银行都得到了使用。
数据中台：
数据中台是现在最热的名词之一。它的架构是把企业多个业务系统数据进行统一汇聚到一个中台，在上面通过治理，服务出去，这样可以快速的提高企业的业务的响应能力，形成大中台、小前端的方式。
1、场景特点：
多源系统数据汇聚场景，数据模型多样化。
存储量较大，需要能够分布式存储。
快速业务响应能力意味着快速数据建模和快速发布。
支持企业所有业务系统的数据需求，查询性能需要保证。
基于数据中台场景的特性，MongoDB 的结构非常适合多元数据的聚合。不同系统的数据结构，就算是同一类型，比如都是客户，它有非常大的差异性，字段的个数、属性的个数都是不一样的。这时，建一张新的 Schema结构是非常困难的。通过 JSON的这种动态模型，不需要考虑很多复杂的问题，很容易把它结合起来。
MongoDB 的横向扩展能力，可以让一套系统支撑多套业务系统的数据存储能力。
MongoDB 还有内存缓存的读写能力，或者是快速高并发的读能力， 可以支撑很多数据中台业务。
基于上述，MongoDB是个非常好的一个实时数据中台存储解决方案。
3、场景举例
（1）数据中台案例 – 周生生全渠道实时数据服务平台：
周生生珠宝商在中港台澳各地有数百家门店，建立数据服务平台的原因是，中广台澳各地有很多套业务系统，有销售、库存、商品、会员等等，数据散落在这些系统中间，并没有统一。
新业务他们想打造一套全渠道体验，去了解客户的所有信息或是订单、跨地或是想做业务，也需要完整的最新的库存信息。
基于上述构建了业务数据中台系统，使用 Tap data 实时同步功能，基于 Log miner 和 CDC 机制，把数据从 Oracle 里面把它抽出来，实时同步到 MongoDB。过程中并采用实时处理能力，把基于关系模型的各种多表合并成一个JSON，再实时的固化视图放在 MongoDB 里面。在MongoDB的价值就是能够存储数十亿笔资料，同时能够提供毫秒级的响应。
另外一点，它能够提供中港台跨地区分布，保证用户能够最快访问数据。然后结合 API 能力，让前端开发小程序、APP、需要API的时候，原先需要几个星期几个月，通过中台可以很快将API发表出来，全面提高效率。这些都依赖于 MongoDB 数据库非常强的整合能力和查询能力，也是中台所需要数据的特性。
实时分析：分析的话大部分时间是用大数据平台做的，比如说我们常说的个性化推荐，标签等系统的一般做法是晚上将全量的用户行为数据，整个的跑一遍结合其他数据跑出一些个性化的标签出来，例如用户喜欢什么样的内容等等，然后放到一个关系库里面，第二天当你去访问的时候，就会得到一些这样的结果。
但这种做法有两大缺陷：
一是效率很低，因为活跃用户比例很低，所以每天晚上都在跑100%的用户，对计算资源的需求非常大，其中90%的数据都是没用的。因为很多用户没有登陆使用。
二是数据的实时性，因为运算基于前一天的结果，所以有些实时的场景推进系统，比如看一个网页的时候，根据第一个网页点击的内容，给你推荐一些相关的信息，这个时候就没法做到了。所以一些实时推进系统是很有必要的，这些系统的特色是要求快速响应，这样的数据系统不仅需要相应海量数据，还要响应短时间内秒击进行快速计算。
MongoDB在此方面可以做快速的聚合性计算，做统计分析，得到这种结果，是否满足一些条件来推荐相应的信息。另外如果给足够的内存，也可以在内存里面计算。
世界顶级航旅服务商：亿级数据量实时分析：
世界级的这种航旅服务商除了国内一些企业，在海外基本可以支撑世界上大部分的航空公司的票务、查询、订票、选票、票价计算等等场景。
他们每天要处理 16 亿的预定等相关的请求与分析。所谓的分析是要根据用户在查询的目的地、时间段，推荐比较合适的路线，或者相应的航旅产品，酒店之类。
一种做法可以事先计算，那么用户量太大，根本没法计算。
另外一种场景，使用 MongoDB 实时计算能力，在几十台物理机上部署了很多的微分片，把数据打散在这些机器上，当有需求过来，可以通过并行机制，很快的把用户的数据基于 ID、目的地、时间段进行过滤，这样输入的分析数据就比全量数据少了几个数量级。
通过这种情况可以做到准时性的数据分析，得出一些推进的结果。
电商：
电商场景的特点是：商品信息特别多，而且不好管理。因为不同的商品有非常不同的属性，信息是包罗万象，无法用一张表表示信息，差异太大。数据库模式设计困难，关系一般采用EKB，但查询也是非常麻烦，查询维护也是很大痛点。当并发访问量大的时候，压力也是非常大。
MongoDB 在电商场景下有非常独特的优势，JSON 动态模型可以允许同一张商品表里面有非常不同的字段类型。也就是同一张表可以有自行车、衣服、电脑，电脑可能是有50个字段，自行车可能有 30个字段，衣服可能有20个字段都没问题。这种变化的模型，正是MongoDB非常好的优势。
世界顶级网络设备生产商：电商平台重构：
思科是一个做网络设备的公司，两年前把基于 Oracle 的电商系统，整个迁移到了MongoDB上面，这上面每天有几百亿美元的流水，这是非常好的一个业务场景。包括商品信息、订单、用户交互。
迁移过来以后，14个关系型表集合成到1个集合，非常高效，看上去一目了然。60个索引优化到7个，因为表的数量少，效率增加了非常多。代码量减少了12万。之前的 3~5 秒页面刷新时间降低到小于一秒，都是非常实际的价值呈现。
内容管理：
内容管理是 MongoDB 的强项，最开始是以博客系统为例，出现在大众视野。原因是博客、营销系统、内容管理系统，涉及到的都是一些非结构化、半结构化、多结构化的数据管理，传统数据库只能做结构化的数据。当有文本、配置文件、PDF、音频、视频需要统一管理时，关系数据库就吃力了。MongoDB则非常适合。
它JSON 可以支持各种结构的数据，甚至二进制的数据。一些文本、 日志更不在话下，它的分片结构可以支撑海量数据。所以Gartner魔力象限里面最顶上的两位 Adobe AEM 和 Sitecore 两个 CMS 文 档管理系统的软件，都是用的 MongoDB 来做数据管理和存储。
物联网：
物联网使用非常广泛。
它的技术特性是：首先它有非常多的传感器，每个传感器都是不同厂家提供的，它并没有标准的数据模型。如果要管理看上去是一个传感器，但实际上它有非常不同的数据类型和属性需要来支持和查询管理，这个时候有 JSON 模型就非常有优势。
另外传感器是机器数据，频繁的时候可以每秒都一次，5 秒一次，甚至每 100 毫秒 1 次，如此，数据不断的进到系统里面。如果没有能够支撑高并发海量数据的系统，是无法支撑数据库的，因为数据很快就增长了百亿、千亿级。因为这个原因，类似于华为 / Bosch / Mindsphere 这些著名的物联网平台，后面都是采用 MongoDB。 MongoDB 什么时候不太适用？
MongoDB 有一项需要关注的弱点，就是他的关联能力。
MongoDB 按照我们的最佳实践，设计不建议有太多的分表设计，那当你不能做到这一点的时候，表很多的时候，这个时候 MongoDB 就会有一些局限性，比如说我们做数仓的时候，往往是要建各种各样的维度表，通过复杂的关联联合起来，做一些复杂的计算，这些在 MongoDB 中很困难。
又比如说，ERP，ERP 其实里面的数据表、实体一级对象非常多，你很难把它实现成就少数的集成表，所以这种情况下你会发现，很多时候要用到多种关联的时候才能做事情的时候，也会有一些局限性。
如果有些场景的数据模型是非常固定的，就这10个字段，用了20年了，我现在只重写一遍 UI，改写体验，但是后台的数据结构、流程都是非常明确的，数据量不会太大，比如这个财务系统，内部的，那这个时候你用 APP 其实不是非常必要，因为它的弹性模型、分布完全没有意义。
