MongoDB、Redis、ElasticSearch、Hbase、Mysql热门数据库的场景选取

写在前面

本博客根据在实际场景开发中遇到的问题进行一些简单总结，目的是解决大数据问题中数据库的选取问题（公司都会有这些数据库提供使用）

MongoDB、Redis、ElasticSearch、Hbse均为非关系型数据库NoSQL(Not only sql)， 而Mysql属于关系型数据库

参考：https://blog.csdn.net/wx1528159409/article/details/88367159

1. MongoDB

1.1 发展历史

MongoDB是当今最火爆的NoSQL数据库。MongoDB最早在09年发布，算得上是早期大数据时代的数据库代表作了。随着MongoDB的火爆，研发MongoDB的团队还专门成立了MongoDB公司来对MongoDB进行维护和推广，现在这个公司已经在纳斯达克上市，市值达到十几亿美元，算得上是技术变现的典范了。

1.2 优点

表结构灵活可变，字段类型可以随时修改。

MongoDB中的每一行数据只是简单的被转化成Json格式后存储，因此MongoDB中压根没有MySQL中表结构这样的概念，你可以直接简单粗暴的将任意结构的数据塞入同一个表中，压根不必考虑表结构的限制，更不必像MySQL一样因为要修改数据表结构而大费周折。简而言之，往MySQL写数据像是在做填空题，你写入的数据必须与最早定义的表结构一致，而往MongoDB写数据就像是在做问答题，想怎么写就怎么写，这灵活度不要爽太多。

1.3 缺点

难以进行多表查询、复杂事务等高级操作。

MongoDB不需要定义表结构这个特点给表结构的修改带来了极大的方便，但是也给多表查询、复杂事务等高级操作带来了阻碍。因此，如果你的数据的逻辑结构非常复杂，经常需要进行复杂的多表查询或者事务操作，那显然还是MySQL这类关系型数据库更合适。

1.4 适用场景

表结构经常改变，数据的逻辑结构没又没那么复杂不需要多表查询操作，数据量又比较大的应用场景。

得益于MongoDB的这些特点，MongoDB很适合那些表结构经常改变，数据的逻辑结构没又没那么复杂不需要多表查询操作，数据量又比较大的应用场景。

例如，有一个游戏应用，需要存储每个用户的信息，用户分为法师、战士等具有不同属性的角色，还有装备、技能等很多结构复杂的信息，游戏每次更新还可能会引入很多新的用户属性，这时如果你使用MySQL，那么你可能需要建立很多个表，定义很多个表结构，并且游戏的每次更新也可能会给你带来重定义表结构等一堆麻烦事，而如果使用MongoDB则这些麻烦统统不存在，因为你可以定义只一张表便可以容纳所有的信息，而且可以随时根据新的需求增减字段。

2. Redis

2.1 发展历史

Redis是现在最热门的key-value数据库。它与MongoDB同在2009年发布，也同样是早期大数据时代的数据库代表作。

2.2 优点

key-value存储所带来的简单和高性能(查询非常快)。

Redis的最大特点当然就是key-value存储所带来的简单和高性能了。所谓key-value存储，就是每一条记录只包含一个用于查询数据的Key，以及与之对应的存储数据的value，就如同现实生活中的门牌号与住户，而没有诸如表、字段这些常规数据库中必需有的复杂概念，所有的查询都仅仅依赖于key值。因此，key-value数据库可谓是数据库中数据结构最简单的一种，也得益于这种简单的结构，再加上Redis会把所有数据加载到内存中的，Redis能得到远高于MongoDB这类常规数据库的读写性能。

当然，Redis的功能还不止key-value存储这么简单，相较它的key-value前辈Memcached，Redis还支持数据持久化，list、set等多种数据结构，主从复制备份等一些列功能，因此Redis绝对称得上是key-value数据库中功能最全面、最简单易用的款。

2.3 缺点

难以进行复杂查询。

Redis的key-valule存储带来了性能这个优势，但是也给复杂查询带来了很多局限。由于阉割掉了数据表、字段这样的重要特性，且所有的查询都依赖key，因此Redis无法提供常规数据库所具备的多列查询、区段查询等复杂查询功能。同时，由于Redis需要把数据存在内存中，这也大大限制了Redis可存储的数据量，这也决定了Redis难以用在数据规模很大的应用场景中。

2.4 适用场景

• 难以用在数据规模很大的应用场景中(亿级别)
  因为Redis需要把数据存在内存中

• Redis牺牲了常规数据库中的数据表、复杂查询等功能，换来了很大的性能提升，特别适合那些对读写性能要求极高，且数据表结构简单（key-value、list、set之类）、查询条件也同样简单的应用场景。如果你的数据表结构还挺复杂，你还经常需要做一些复杂查询操作，那你最好还是老老实实用MongoDB或者SQL吧。

3. ElasticSearch(ES)

常用在搜索引擎中，做搜索的小伙伴可以集中看一下

3.1 发展历史

相较于MongoDB和Redis，晚一年发布的ES可能知名度要低一些，但是ES在搜索引擎领域的名声绝对是是响当当的。相较于其他高大上的数据库产品，ES的出身要平凡很多。ES的创建者Shay Banon曾经是一个失业的程序员，在无事可干的时候为了方便老婆搜索食谱而创建了ES（当然，当时还不叫ES）。不料无心插柳柳成荫，成就了今天最热门的搜索引擎数据库。ES也专门成立了自己的Elastic公司已经获得数亿美金融资，当年的窘迫的程序员Shay Banon也早已逆袭成为CEO并走上人生巅峰。

3.2 优点

查询灵活且快(因为是搜索引擎)。

ES的特点，正如其名，那就是搜索。严格的说，ES不是一个数据库，而是一个搜索引擎，ES的方方面面也都是围绕搜索设计的。ES支持全文搜索，这里简单解释下什么是全文搜索：对于“我在北京的一家互联网公司工作”这样的数据，如果你搜索“北京”、“互联网”、“工作”这些关键词都能命中这条数据的话，这就是全文搜索，你每天都在用的百度、Google都属于全文搜索。值得一提的是，ES的全文搜索对中文也有很好的支持（单是中文分词器就有很多种），绝对能够满足国内大多数人的全文搜索需求。ES通过建立倒排索引实现全文搜索。具体来说，ES会建立一个覆盖表中所有文档、所有字段的庞大的倒排索引，以实现对存入ES中的所有数据进行快速检索。因此只要是存入ES的数据，无论再复杂的聚合查询也可以得到不错的性能，而且你再也不用为如何建立各种复杂索引而头痛了。

3.3 缺点

字段类型无法修改、写入性能较低和高硬件资源消耗。

前边讲到ES会自动的替你建立索引，尽管这能给全文搜索以及聚合查询带来很多好处还能替你省了建索引这一麻烦事，但是这个特性也会带来一堆问题。ES需要在创建字段前要预先建立Mapping，Mapping中包含每个字段的类型信息，ES需要根据Mapping为字段建立合适的索引。由于这个Mapping的存在，ES中的字段一但建立就不能再修改类型了。（例如，你建的数据表的某个字段忘了加全文搜索，你想临时加上，但是表已经建好并且已经有很多数据了，这时候该怎么办呢？不好意思，你只能把整个数据表删了再重建一遍！）因此，ES在数据结构灵活度上高于MySQL但远不如MongoDB。ES的缺点还不止这些，自动建立索引使得ES的写入性能也收到了影响，要明显低于MongoDB，并且ES的写入还有一个更要命的问题，那就是默认1S的写入延迟，也就是说你的数据在写入后要至少等1S才能被查询到。对于同样的数据ES占用的存储空间也要明显大于MongoDB（建那么复杂的索引能不占空间吗？），对硬件资源的消耗也是非常厉害，大数据量下64G内存+SSD基本是标配，算得上是数据库中的贵族服务了，因此如果你的老板很小气，对于ES的选用可要慎重喽！

3.4 适用场景

• 适合搜索场景
• 不适合用在那些数据价值不高、对写入性能有要求、数据量大而成本受限的场景

4. Hbase

原理参考教程
https://blog.csdn.net/tototuzuoquan/article/details/73649510
https://blog.csdn.net/m0_37659871/article/details/82384170

表的设计原则

https://blog.csdn.net/u013870094/article/details/80057788
https://blog.csdn.net/m0_37138008/article/details/78985946

操作

https://www.cnblogs.com/cxhzy/p/10557980.html （⭐️）

https://www.jianshu.com/p/62f687ba0c11

https://my.oschina.net/u/3710174/blog/4526944

4.1 发展历史

HBase是Hadoop项目的一部分，而且是当年谷歌大数据三驾马车之一的BigTable方案的实现，因此绝对算得上是大数据时代最有代表性的技术之一了。

4.2 优点

支持海量数据，以及极强的横向（存储容量）扩展能力。

和Redis类似，HBase也需要为每一行数据定义一个key，之后所有的查询都依赖这个key进行。但是不同的地方在于，HBase中的一行数据还可以有非常多的列项（类似MongoDB字段），数据会按照列进行分组和存储，同一列的数据存储在同一个地方，这也是HBase被称为列式存储数据库的原因。其实从本质上来说，HBase相当于是把逻辑上的一张大表按照列族分拆成若干张小表分别进行存储，不仅是列，数据的行数到达一定数量后表也会再被拆分。因此，HBase能够把巨大的表分布到很多台机器上，从而容纳规模近乎无限的数据。同时，对HBase进行横向扩展也非常方便，你基本只需要添加新的机器，而不用对数据做任何改动，就可以实现数据库容量线性的增长，这在其他SQL数据库中是难以做到的（尽管其他数据库也有诸如MongoDB分片集群之类的功能帮助你进行数据规模横向扩展，但是无论是在实施的难度上还是在对数据的影响方面这些都无法跟HBase相提并论。）

4.3 缺点

难以进行复杂查询。

HBase的列式存储特性带来了海量数据规模的支持和极强的扩展能力，但是也给数据的读取带来很大的局限。由于只有同一列族的数据才会被存放在一起，而且所有的查询都必须要依赖Key，这就使得很多复杂查询难以进行。例如，如果你的查询条件涉及多个列项，或者你无法获取要查询数据的key，那么查询效率将会非常低下。因此，HBase仅仅适合。

4.4 适用场景

难数据量极大，查询条件简单，列与列之间联系不大的轻查询应用场景。

HBase的列式存储特点带来了对海量数据的容纳能力，因此非常适合数据量极大，查询条件简单，列与列之间联系不大的轻查询应用场景。最典型的比如搜索引擎所使用的网页数据库。HBase不适合数据结构复杂，且需要复杂查询的应用场景。另外值得一提的是，HBase是很重的一款产品，需要依赖很多的Hadoop组件，因此如果你的数据规模不大，那就完全没必要杀鸡用牛刀，MongoDB这类产品完全可以更好的满足你的需求。

5. Mysql

5.1 发展历史

MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一

5.2 优点

• 体积小、速度快、总体拥有成本低，开源；

• 支持多种操作系统；

• 是开源数据库，提供的接口支持多种语言连接操作

• MySql的核心程序采用完全的多线程编程。线程是轻量级的进程，它可以灵活地为用户提供服务，而不过多的系统资源。用多线程和C语言实现的MySql能很容易充分利用CPU；

• MySql有一个非常灵活而且安全的权限和口令系统。当客户与MySql服务器连接时，他们之间所有的口令传送被加密，而且MySql支持主机认证；

• 支持ODBC for Windows， 支持所有的ODBC 2.5函数和其他许多函数， 可以用Access连接MySql服务器， 使得应用被扩展；

• 支持大型的数据库， 可以方便地支持上千万条记录的数据库。作为一个开放源代码的数据库，可以针对不同的应用进行相应的修改。

• 拥有一个非常快速而且稳定的基于线程的内存分配系统，可以持续使用面不必担心其稳定性；

• MySQL同时提供高度多样性，能够提供很多不同的使用者介面，包括命令行客户端操作，网页浏览器，以及各式各样的程序语言介面，例如C+，Perl，Java，PHP，以及Python。你可以使用事先包装好的客户端，或者干脆自己写一个合适的应用程序。MySQL可用于Unix，Windows，以及OS/2等平台，因此它可以用在个人电脑或者是服务器上；

5.3 缺点

• 不支持海量数据场景，存储压力太大

• 不支持热备份；

• MySQL最大的缺点是其安全系统，主要是复杂而非标准，另外只有到调用mysqladmin来重读用户权限时才发生改变；

• 没有一种存储过程(Stored Procedure)语言，这是对习惯于企业级数据库的程序员的最大限制；

• MySQL的价格随平台和安装方式变化。Linux的MySQL如果由用户自己或系统管理员而不是第三方安装则是免费的，第三方案则必须付许可费。Unix或Linux 自行安装 免费 、Unix或Linux 第三方安装 收费；

5.4 适用场景

复杂查询、数据量不是特别大(千万级别最多)、多表查询等场景