关系型、非关系型数据库存储选型盘点大全工作中总是遇到数据存储相关

工作中总是遇到数据存储相关的Bug工单，新需求开发设计中也多多少少会有数据模型设计和存储相关的问题。经过几次存储方案设计选型和讨论后发现需要有更全面的思考框架。日常开发中常用的存储方案选型很多都是“拿来主义”的，凭借着经验、习惯选用，但对它们的细节特性或约束少有研究。除了手边会用的存储方案，也应该关注市面上更合适的存储方案。一定的技术预研和储备能够帮助未来更好的技术方案设计。
故写了这篇文章，抛出我的观察和思考，希望日后可以将一些更先进(合适)的技术引入公司业务，助力业务发展。
存储选型的考虑要素
存储选型的目的还是为了我们的使用场景和用户服务，因此在选型前需要回答一些业务指标&技术指标方面的问题，以便于我们清楚存储选型的应用环境。用户量：用户量预估多少？几百几万还是几亿？数据量：数据量预估多少？日均增量能有多少？读写偏好：数据是读多一些还是写多一些？数据场景：强事务型还是分析型需求？运行性能要求：并发量是多少？高峰、平均、低谷分别预估是多少？
存储引擎分类及特性
数据库的分类方式非常多样，因参考维度不同而存在较大差异，下面是常见的一些分类。

文章图片
先拿我们最熟悉的关系数据库来说，它的优点非常多，我们选用关系数据库的理由可简单概括为以下几点：容易理解
可由二维表结构来逻辑表达，相对网状、层次等其他模型更加容易被理解。严格遵循数据格式与长度规范，数据以行为单位，一行数据表示一个实体信息，每一行数据的属性都是相同的。事务特性
支持ACID特性，可以维护数据之间的一致性，这是使用关系数据库非常重要的一个理由。操作方便
通用的SQL语言使得操作关系型数据库非常方便，支持join等复杂查询， Sql+二维关系是关系型数据库最无可比拟的优点，这种易用性非常贴近开发者。数据稳定
数据持久化到磁盘，没有丢失数据风险。服务稳定
最常用的关系型数据库产品MySql、Oracle服务器性能卓越，服务稳定，通常很少出现宕机异常。
然而，在享受关系数据库带来的便利的同时，我们也不得不面临很多麻烦的问题：高并发下数据库瓶颈明显
数据按行存储，即使只针对某一列进行运算，也会将整行数据从存储设备中读入内存，导致IO较高。写入更新频繁的情况下，数据库往往会出现CPU飙高、Sql执行慢、客户端报数据库连接池不够等异常情况，且性能瓶颈通过加CPU、换固态硬盘、继续买服务器加数据库做分库等方式处理ROI不高，受限于其本身的特点，可能花了很多钱都未必能达到想要的效果。因此例如万人秒杀这种场景，我们绝对不可能通过数据库直接去扣减库存，需要做好流量漏斗。为维护数据一致性付出的代价大
数据一致性是关系型数据库的核心，但是同样为了维护数据一致性的代价也非常大。 SQL标准为事务定义了不同的隔离级别，从低到高依次是读未提交、读已提交、可重复度、串行化，事务隔离级别越低，可能导致的并发异常越多，但是能提供的并发能力越强。那么为了保证事务一致性，数据库就需要提供并发控制与故障恢复两种技术，前者用于减少并发异常，后者可以在系统异常的时候保证事务与数据库状态不会被破坏。对于并发控制，其核心思想就是加锁，无论是乐观锁还是悲观锁，只要提供的隔离级别越高，那么读写性能必然会受影响。为维护索引付出的代价大