技术真的是日新月异，关系型数据库在数据库存储界称霸这么多年后，市面上各种数据库如雨后春笋蓬勃发展，似乎关系型数据库也地位不保，我前段时间和同事聊天，听到他们经常说的现在市面上的noSql数据库完全可以替代现有的关系型数据库，可是事实真的如此吗，我们一起就市面上现在比较流行的各类数据库，做一个对比：
真正业务开发中，绝对不是拍脑袋定下来使用那种数据库就使用那种数据库的，选择某种或者某几种数据库配合使用，一定是对该数据库有一个比较全面的认识。
关系型数据经过过这么多年的披荆斩棘，到现在依旧能够屹立不倒，他的优势一定是特别的显眼，关系型数据库优点表现在：
- 强大的SQL能力，应对各类复杂查询有时候一个join就搞定了。
- 支持完整的
ACID属性，这个属性其实也是数据库能够大行其道的根本原因。
- A(Atomicity)原子性: 一个事务的所有操作一起成功，一起失败。
- C(Consistency)一致性:在事务开始之前和事务结束以后数据库的完整性不被破坏。
- I(Isolation)隔离性:数据库允许多个并发事务，拥有同时对数据进行读写的能力，隔离性可以保证多个事务并发或者交叉执行是导致的数据不一致性事务的隔离级别为：读未提交、读已提交、可重复度、串行化。
- D(Durability)持久性：事务结束后对数据的修改就是永久的，即使系统故障也不会丢失。
- 容易理解，数据库的结构为二维表格结构，最符合和贴近逻辑社会的概念。
虽然关系型数据库拥有这么多的优势，但是为什么它的地位在有时也会被撼动呢？关系型数据拥有如此强大的功能的背后也有很多缺点主要表现在：
- 无法做数据结构的存储，例如在一个社交产品关注的功能中，一个人的关注列表是一个list集合形式的列表，但是关系型数据库只能表关联或者基于多次查询进行数据组装后返回！
- 表结构强约束，扩展不方便！关系型数据库是结构化存储，在进行数据存储时无法动态的增加列或者减少列，在更新表字段的时候往往会操作ddl语句。操作不存在的字段也会报错！
- 大数据量的查询中，读写性能低，IO开销大！因为关系型数据库是行式存储，所以在查询某几个字段时，关系型数据依旧会将整行存储到内存中，所以内存开销大！
- 关系型数据库，全文检索的更能较弱。
我们在业务开发中，一定要学会取长补短，取精华，去糟粕，针对以上缺点，我们来总结一下市面上比较好的开源实现的数据库吧！
缺点一：无法做数据结构存储：
以redis为例：它可以解决关系型数据库无法存储数据结构的问题，其优点体现在：
- 支持多种数据结构，例如:
String、set、Hash、sortedSet、hyperloglog、geo、pub/sub等 - 性能极高，内存型数据库，对于数据的读写极快。
- 原子性，所有的操作全部都是原子性，支持对多个操作的合并组装成原子操作。
当然人无完人，他也有缺点：
- 数据量受机器内存大小的影响，在海量数据存储中并不适用，但是适合小数据量下的快速查询和计算。
- 不支持完成的ACID事务属性，他提供的事务只保证一致性和隔离性。
因为其事务完整性无法保证，所以适用场景时都事务要求并没有那么高，且读写频率极高的场景！
缺点二：表结构强约束，扩展不方便：
以MongoDB为例：它可以解决表结构强约束，扩展不方便的问题，其优点表现在：
- 没有表结构的强约束，在使用时可以任意的增加或者减少字段，文档结构的存储方式，能够更便捷的获取数据。
- 支持大容量的存储，海量数据下性能优越。
- 内置自动分片，支持云级扩展。
- 支持复杂聚合
mongoDB缺点表现在：
- 不支持事务，不适合对事物要求严格的场景。
- 无法支持复杂查询，如关系型数据的join操作。
- 事实上mongoDB的效率存在一定的波动性。
适用场景：不怎么使用事务，数据相较而言不那么重要，数据字段不确定！
缺点三：大数据量的查询中，读写性能低，IO开销大：
以HBase为例：解决读写性能低，IO开销大的问题，其优点表现在：
- Hbase适合存储PB级别的海量数据，在PB级别的数据以及采用廉价PC存储的情况下，能在几十到百毫秒内返回数据。
- Hbase是根据列族来存储数据的。其实这个是减少IO开销的一个很重要的性能指标，因为数据会按照列存储，举一个场景，在一年内，淘宝购买电脑的价格阶梯是多少，如果使用行式存储，我们会统计整个购买电脑的记录，然后再筛选价格这个字段，事实上我们只需要一个价格字段；因为Hbase是基于列存储，查询时只需要查询这个类就OK，所以它的IO读写消耗小。
- 极易扩展Hbase的扩展性主要体现在两个方面，一个是基于上层处理能力（RegionServer）的扩展，一个是基于存储的扩展（HDFS）。
- 高并发：由于目前大部分使用Hbase的架构，都是采用的廉价PC，因此单个IO的延迟其实并不小，一般在几十到上百ms之间。这里说的高并发，主要是在并发的情况下，Hbase的单个IO延迟下降并不多。能获得高并发、低延迟的服务。
hbase缺点表现在：
- 读取多个列时，关系型数据库因为是按行存储，所以在磁盘上的位置是连续的所以读取速率较高，但是HBase是按照列存储，不同的列存储在磁盘上的不连续的空间，在读取多个列时速度较慢。
- 再更新数据的时候，因为行式存储所有的列的在磁盘空间上的连续性，故而可以一次更新，但是HBase会慢很多！其次HBase在更新时需要对字段进行 解压-更新-压缩 操作所以也会出现性能瓶颈！
- 它不支持SQL。必须依赖开发进行代码解决
- 权限，安全上存在隐患。只要知道ZK的IP和端口，你就能轻松访问HBASE，甚至不需要任何权限校验。
适用场景：离线大数据分析，这类场景一般都是对于单列操作且写入后无需更新！
缺点四：关系型数据库，全文检索的更能较弱。
Elasticsearch 优点表现在：
- 全文检索，基于分词、倒排索引进行索引，查询速度简直不不要太快！
- 负载再平衡和路由在大多数情况下自动完成。客户端发送请求到任意一个node，coordinate node对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡
- 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据
缺点：
- 在需要添加新数据与新字段的时候，如果elasticSearch进行搜索是可能需要重新修改格式。之前的数据需要重新同步，对数据的管理有很多困难
从关系型数据库的数据灌输，一般是将数据库内部数据转换成json来适应全文检索！
关于上述对于各类数据库的介绍，相信你对他们都有了一个大概的认识，具体的使用场景，还是要结合业务来使用！下面是关于使用场景的一点建议！
关系型和NoSQL数据库的选型。考虑几个指标，数据量、并发量、实时性、一致性要求、读写分布和类型、安全性、运维性等。根据这些指标，软件系统可分成几类。
- 管理型系统，如运营类系统，首选关系型。
- 大流量系统，如电商单品页的某个服务，后台选关系型，前台选内存型。
- 日志型系统，原始数据选列式，日志搜索选倒排索引。
- 搜索型系统，指站内搜索，非通用搜索，如商品搜索，后台选关系型，前台选倒排索引。
- 事务型系统，如库存、交易、记账，选关系型 缓存 一致性协议，或新型关系数据库。
- 离线计算，如大量数据分析，首选列式，关系型也可以。
- 实时计算，如实时监控，可以选时序数据库，或列式数据库。
