主流存储数据库的选择

目前市场上充斥着各种开源也好，二次封装也好的可存储形工具，比如Mysql，Ordecel，Es。对于开发来说，各个框架的功能大同小异；况且在当今开源横行的时代，还有着许多的牛人在此之上设计各类的增强型插件可供我们使用。

但如果在开发一个项目之初，认真思考其规模、流量、流动量等因素，对这些主流存储工具的选择也需要认真的进行测量；

因此本篇将目前常用的各种可存储框架，进行区分和实际应用场景分析；

Mysql

首先是使用最高，大多程序员最熟悉的MysqlDB数据库，在当今与Oracle几乎平分企业级应用的市场。

不过有一个理由，让他在国内稳压Oracle一头：免费开源

mysql，oracle以及sql-server，同属于关系型数据库，因此在使用上大同小异，主要还是其对数据量大小、访问量大小的支撑程度。

总体的大小排序：mysql<sql-server<oracle

因此在选择关系型数据库时，往往是这样走：

1. 小公司，因为sql-server以及oracle都需要收费，考虑成本以及应用未来的并发和数据量问题，无脑选用Mysql
2. 大公司，从小公司起步，往往是在第一步之下，考虑是否需要进行数据库升级，但是这里的升级并不是指直接换成Oracle或者Sql-server，因为程序内部、表的设计、sql语句的兼容等等问题，都会造成不可挽回的风险
3. 大公司，数据库升级：因为Mysql开源这一特点，像阿里，腾讯等头部企业，用的最多的会是魔改版Mysql。并且从新来项目的角度考虑，从使用角度，查询效率，功能强大等考虑，可以优先sqlserver。

然后就是什么情况下会使用关系型数据库，这一点从已经是开发人员的我的角度上看，有一些片面。因为我认为不管是什么需求，都存在数据关联，数据事务的问题，那么如果不使用关系型数据库，直接将一个需求内的数据保存在一个json或字段中，与其说是存储，更像是图书馆式的目录数据读写；

所以目前不使用关系型数据库的场景，大多是需要进行倒叙结构搜索，数据快速读写的类型。

因此我的直接结论是：需要考虑成本，且项目非数据读写引擎型应用，无脑选用Mysql

MongoDB

上述先提到的关系型数据库，在过去很多年中可以满足绝大多数应用场景。但是，随着互联网应用的不断增多和数据的快速增长，关系型数据库因为数据存储在表 一个page 内的特殊性，在大数据频繁的读写中已经无法满足很多快速响应的需求，为了解决这个问题，出现了新型的数据库技术，如MongoDB。

mongoDB与mysql的不同，两者除了都是存数据的工具，概念上不是一种东西。主要的差异来自对数据的组织与查询形式上，这也是MongoDB的特点所在。

简单阐述，mongoDB采取文档目录式的数据存储方式，使用key-value，加上文档嵌套的方式去维护业务中的数据结构，因此mongoDB中的数据全都是类JSON的格式。

针对两者类型的数据库对比，可见针对这两代表的对比表格:

数据库	MongoDB	MySQL
数据库模型	非关系型	关系型
存储方式	以类JSON的文档的格式存储	不同引擎有不同的存储方式
查询语句	MongoDB查询方式（类似JavaScript的函数）	SQL语句
数据处理方式	基于内存，将热数据存放在物理内存中，从而达到高速读写	不同引擎有自己的特点
成熟度	新兴数据库，成熟度较低	成熟度高
广泛度	NoSQL数据库中，比较完善且开源，使用人数在不断增长	开源数据库，市场份额不断增长
事务性	仅支持单文档事务操作，弱一致性	支持事务操作
占用空间	占用空间大	占用空间小
join操作	MongoDB没有join	MySQL支持join

举个例子，订单表的设计，在关系型数据库中一定是：

订单表：
order_id int 
order_no varchar
.....

订单详情表:
order_detail_id int
order_id int
order_no varchar
....

因此在查询需求中，查询详情可通过join进行表与表的关系查询。

而mongoDB的存储方式则是：

{
    "order_id":1,
    "order_no":"111",
    "order_detail":{
        "order_detail_id":"2",
        "order_id":"1",
        "order_no":"111"
    }
}

以此可见，在一对一查询，一对多查询的场景下特别适合MongoDB的内嵌文档和数组来存储，读写效率都比较高。

然后是性能考虑，在大多读的条件下，mongDB一定比Mysql读写快；

这是因为：

1. 前者使用的是内存映射技术，直接通过一次IO流读写内存的缓存，极大的提高数据读取的并发量以及磁盘寻道的时间
2. 与Redis读取内存数据一样的设计

但是JSON数据存储的局限性，在数据存储中字段的设计以及大小的考虑对比关系型数据库针对表的设计是需要额外考虑，使数据读取速度与内存消耗达到平衡；

这也是mongoDB在一般应用中很少考虑的原因：因为数据是内存缓存，需要保证服务器有足够的内存支撑

所以我的最终结论是：在涉及到缓存数据冷存储，数据结构适宜JSON的需求时，可以考虑使用mongoDB的内存读取特性

Elasticsearch

先说一点，Elasticsearch并不能直接作为数据库存储方案

与上面两者都不同，Elasticsearch是作为一个已成熟的额外应用进行讨论。在开发中，很多时候是作为一种补强的“插件”引入；

因此Elasticsearch从定位选择上就与上述两种不同，当应用涉及到 搜索 、逐字搜索 、大数据搜索 ...等需要进行全文搜索功能时，Elasticsearch是目前市场上的最佳候选：开源、社区活跃

在这里作为存储数据库的选择来讨论是因为，真存在只使用Elasticsearch作为数据库存储使用的应用；

同样的简单阐述，Elasticsearch和MongoDB都属于NoSQL大家族, 且都属于文档型数据存储，因此两者的读写设计上高度重合；

但是Elasticsearch是作为独立的额外应用进行部署，因此他可以使用 数据库 工具无法做到的分布式功能：分布式的全文搜索能力

但是因为需服务器部署的原因，Elasticsearch能做到的也尽可能的局限在了提供数据检索服务, 也就是说我只管查, 不管写；

所以Elasticsearch只适用在以下几种类型的应用下：

• 监控信息/日志信息检索；
• 搜索引擎
• 数据统计
• ...

所以我的最终结论是：如果你觉得你的应用数据量足够，且遇到需要进行文字类型的全文检索，那么这时候需要考虑Elasticsearch，以及Elasticsearch额外部署所带来的成本影响