什么是行存储和列存储？

• 行存储：传统的关系型数据库，如 Oracle、DB2、MySQL、SQL SERVER 等采用行式存储法(Row-based，基于行)，在基于行式存储的数据库中， 数据是按照行数据为基础逻辑存储单元进行存储的，一行中的数据在存储介质中以连续存储形式存在。
• 列存储(Column-based,基于列)是相对于行存储来说的，新兴的 Hbase、HP Vertica、EMC Greenplum 等分布式数据库均采用列式存储。在基于列式存储的数据库中，数据是按照列为基础逻辑存储单元进行存储的，一列中的数据在存储介质中以连续存储形式存在。

什么是MongoDB（NoSQL）?

MongoDB是面向文档的NoSQL数据库，用于大量数据存储。
MongoDB是一个基于文档的存储，在其之上还具有一个基于图形的存储。MongoDB实际上并不存储JSON：它存储BSON(二进制JSON)，BSON扩展了JSON表示(字符串)以包括其他类型，例如int，long，date，浮点，decimal128和地理空间坐标。

OLTP和OLAP

在数据库中，数据处理可分为两类：联机事务处理OLTP（on-line transaction processing) 和 联机分析处理OLAP（On-Line Analytical Processing）

• OLTP是传统关系型数据库的主要应用，用来执行一些基本的、日常的事务处理，比如数据库增、删、改、查等等
• OLAP则是分布式数据库的主要应用，它对实时性要求不高，但处理的数据量大，通常应用于复杂的动态报表系统上。
  
  

什么是CAP定理？

CAP定理也称为Brewer定理。它指出，分布式数据存储不可能同时满足CAP，只能满足CAP其中的两部分。

• 一致性

  即在执行操作之后，数据也应保持一致。这意味着一旦写入数据，以后的任何读取请求都应包含该数据。例如，更新订单状态后，所有客户端都应该能够看到相同的数据。

• 可用性

  该数据库应始终可用且响应迅速。它不应有任何宕机时间。

• 分区容错性

  分区容限意味着即使服务器之间的通信不稳定，系统也应继续运行。例如，可以将服务器划分为可能无法相互通信的多个组。在此，如果数据库的一部分不可用，则其他部分始终不受影响。

使用场景

行存储的适用场景：

• 适合随机的增、删、改、查操作；
• 需要在行中选取所有属性的查询操作；
• 需要频繁插入或更新的操作，其操作与索引和行的大小更为相关。

列存储的适用场景：

• 查询过程中，可针对各列的运算并发执行，在内存中聚合完整记录集，降低查询响应时间；
• 在数据中高效查找数据，无需维护索引（任何列都能作为索引），查询过程中能够尽量减少无关IO，避免全表扫描；
• 因为各列独立存储，且数据类型已知，可以针对该列的数据类型、数据量大小等因素动态选择压缩算法，以提高物理存储利用率；如果某一行的某一列没有数据，在列存储时，就可以不存储该列的值，这将比行式存储更节省空间。

实际应用中我们会发现，行式数据库在读取数据时存在一个固有的缺陷，比如，所选择查询的目标即是只涉及少数几个字段，但由于这些目标数据埋藏在各行数据单元中，而行单元往往又特别大，应用程序必须读取每一条完整的行记录，从而使得读取效率大大较低，对此，行式数据库给出的优化方案是加索引，在OLTP类型的应用中，通过索引机制或给表分区等手段可以简化查询操作步骤，并提升查询效率。

针对海量数据背景的OLAP应用（例如分布式数据库、数据仓库等），行存储的数据库就有些力不从心了，行式数据库建立索引和物化视图需要花费大量时间和资源，因此还是不划算的，无法从根本上解决查询性能和维护成本的问题，也不适用于数据仓库等应用场景，所以后来出现了基于列式存储的数据库。

对于数据仓库和分布式数据库来说，大部分情况下它会从各个数据源汇总数据，然后进行分析和反馈，其大多数操作是围绕同一个字段（属性）进行的，而当查询某属性的数据记录时，列式数据库只需返回与列属性相关的值。在大数据量查询场景中，列式数据库可在内存中高效组装各列的值，最终形成关系记录集，因此可以显著减少IO消耗并降低查询响应时间，非常适合数据仓库和分布式的应用。

MongoDB相对于MySQL的优点

• MongoDB文档自然映射到现代的面向对象编程语言。使用MongoDB可以避免将代码中的对象转换为关系表的复杂对象关系映射（ORM）层
• MongoDB的灵活数据模型也意味着您的数据库模式可以随业务需求而发展。例如，在天气频道的MySQL数据库中花费数周时间的模式更改可能会在短短几个小时内由MongoDB完成。
• MongoDB还可以在多个分布式数据中心之间进行扩展，提供以前MySQL等关系数据库无法实现的新的可用性和可扩展性。随着在数据量和吞吐量方面的增长，MongoDB可轻松扩展，无需停机，无需更改应用程序。

更适用MySQL的场景

需要复杂的多行事务的应用程序

一个具体的例子是旅行预订系统背后的预订引擎，通常还涉及复杂的事务。虽然核心预订引擎可能在MySQL上运行，但是与用户互动的应用程序部分 – 提供内容，与社交网络集成，管理会话 – 将更好地放在MongoDB中

许多电子商务应用程序使用MongoDB和MySQL的组合。产品目录包括具有不同属性的多个产品，非常适合MongoDB的灵活数据模型。另一方面，需要复杂事务的结帐系统可能建立在MySQL或其他关系数据库技术上。

更适用MongoDB的场景

1. 更高的写入负载

   默认情况下，MongoDB更侧重高数据写入性能，而非事务安全，MongoDB很适合业务系统中有大量“低价值”数据的场景。但是应当避免在高事务安全性的系统中使用MongoDB，除非能从架构设计上保证事务安全。

2. 高可用性

   MongoDB的复副集(Master-Slave)配置非常简洁方便，此外，MongoDB可以快速响应的处理单节点故障，自动、安全的完成故障转移。这些特性使得MongoDB能在一个相对不稳定（如云主机）的环境中，保持高可用性。

3. 数据量很大或者未来会变得很大

   依赖数据库(MySQL)自身的特性，完成数据的扩展是较困难的事，在MySQL中，当一个单达表到5-10GB时会出现明显的性能降级，此时需要通过数据的水平和垂直拆分、库的拆分完成扩展，使用MySQL通常需要借助驱动层或代理层完成这类需求。而MongoDB内建了多种数据分片的特性，可以很好的适应大数据量的需求。

4. 基于位置的数据查询

   MongoDB支持二维空间索引，因此可以快速及精确的从指定位置获取数据。

5. 表结构不明确，且数据在不断变大

   在一些传统RDBMS中，增加一个字段会锁住整个数据库/表，或者在执行一个重负载的请求时会明显造成其它请求的性能降级。通常发生在数据表大于1G的时候（当大于1TB时更甚）。 因MongoDB是文档型数据库，为非结构货的文档增加一个新字段是很快速的操作，并且不会影响到已有数据另外一个好处当业务数据发生变化时，是将不在需要由DBA修改表结构。

6. 没有DBA(数据库管理员)支持

   如果没有专职的DBA，并且准备不使用标准的关系型思想（结构化、连接等）来处理数据，那么MongoDB将会是你的首选。MongoDB对于对像数据的存储非常方便，类可以直接序列化成JSON存储到MongoDB中。 但是需要先了解一些最佳实践，避免当数据变大后，由于文档设计问题而造成的性能缺陷。

个人理解

1. MySQL提供更强的事务保证，即更好的一致性，对一致性要求较高的场景（如：支付，订单等），MySQL更能胜任。但依赖数据库(MySQL)自身的特性，完成数据的扩展是较困难的事（难以实现水平扩展），同时规范化的数据模型导致更多表关联（降低性能），从而需要更多键和索引（占用内存）。随着数据库的增长，性能可能开始成为问题。
2. MongoDB数据具有灵活的架构，集合不会强制执行文档结构，同时很容易依赖其自带的特性（内建了多种数据分片的特性）实现水平扩展，适合业务系统中有大量“低价值”数据的场景。但是应当避免在高事务安全性的系统中使用MongoDB。

扩展

• 垂直扩展：提升单机处理能力。
• 水平扩展：只要增加服务器数量，就能线性扩充系统性能。

参考

• 基于行存储和列存储的数据库
• MongoDB和MySQL对比(译)
• NoSQL教程：了解NoSQL的功能，类型，含义，优势
• 对比mysql,什么场景更适用Mongodb