[草稿]数据库概述
[TOC]
数据库流行度排名
- 全球数据库排名：DB-Engines Ranking
- 国产数据库流行度排名：摩天轮
常见的数据库
| 数据库类型 | 数据库名称 | 是否开源 | 特点 | 适用场景 |
|---|---|---|---|---|
| 关系型数据库(传统型) | Oracle | 否 | 收费且贵 | 银行、期货等金融行业 |
| 关系型数据库(传统型) | MySQL | 开源(企业版收费) | 主流、免费、开源、支持事务 | 互联网Web应用 |
| 关系型数据库(传统型) | MariaDB | 开源 | 主流、免费、开源、支持事务 | 互联网Web应用 |
| 关系型数据库(传统型) | SQL Server | 否 | 收费且贵 | 外企、工厂等 |
| 关系型数据库(NewSQL) | PostgreSQL | 开源 | 支持事务、支持复杂查询 | - |
| 缓存服务 | Redis | 开源 | Key-Value键值、内存缓存、可持久化 | 内存数据库首选Redis |
| 分布式缓存系统 | MemCached | 开源 | Key-Value键值、纯内存 | - |
| 分布式缓存系统 | Couchbase | 开源(企业版收费) | Key-Value键值 + 面向文档 | - |
| 分布式文档数据库 | MongoDB | 开源 | 高性能、高可用、强大sharding、支持地理位置 | 文档数据库 |
| 分布式存储系统 | Hbase | 开源 | - | - |
| 搜索引擎 | ElasticSearch | 开源 | - | - |
| 搜索引擎 | Splunk | 开源 | - | - |
| 时序数据库 | InfluxDB | 开源 | - | - |
| 时序数据库 | Prometheus | 开源 | 适合监控 | - |
| 图数据库 | NEO4J | 开源 | 包含多种图算法(如路径查找、社区检测等) | 适合LinkedIn及Facebook |
NoSQL（Not only SQL）泛指非关系型数据库，没有约定俗成的定义。它与关系型数据库最大的区别是：NoSQL绝对不支持Join，这其实否定了关系数据库的第二索引和join（joins导致sharding无法实施），主要分类包括：
| NoSQL分类 | 结构化特点 | 数据库名称 |
|---|---|---|
| Key-value stores 面向键值 | 需要定义数据结构(半结构化) | Memcached、Redis、Couchbase(含MemBase) |
| Table-oriented 面向表列 | 需要定义数据结构(半结构化) | Google的BigTable和Cassandra |
| Document-oriented 面向文档 | 无需结构(非结构化) | MongoDB、Couchbase(含CouchDB) |
| Graph-oriented 面向图论 | - | Neo4J |
国产数据库
国产数据库可被分为4大派系：
- 学院派：南大通用Gbase、武汉达梦DM、人大金仓kingbase
- 互联网派：腾讯云TDSQL、阿里云OceanBase和polarDB
- 创业派：TiDB、SequoiaDB、HotDB、ArkDB、星环KunDB、青云RadonDB
- 企业派：华为GaussDB和OpenGaussDB、中兴通讯GoldenDB、亚信AntDB
| 数据库类型 | 数据库名称 | 是否开源 | 特点 |
|---|---|---|---|
| 集中式数据库 | 华为云TaurusDB | - | - |
| 集中式+分布式数据库 | 华为云GaussDB | - | - |
| 分布式数据库 | 南大通用Gbase | - | - |
| 分布式数据库 | 武汉达梦DM | - | - |
| 分布式数据库 | 人大金仓kingbase | - | - |
| 分布式数据库 | TiDB | 开源(企业版收费) | 分布式关系型、兼容MySQL、在线DDL |
| 分布式数据库 | 中兴通讯GoldenDB | - | - |
| 分布式数据库 | 亚信AntDB | - | - |
| 分布式数据库 | 腾讯云TDSQL | - | - |
| 分布式数据库 | 阿里云OceanBase | - | - |
| 分布式数据库 | 阿里云PolarDB | - | - |
附录：部分数据库的优缺点
PostgreSQL
1.优点
- PostgreSQL遵循的是BSD协议，完全开源免费且不会被任何商业公司控制；而MySQL被Oracle收购之后慢慢走向封闭。
- PostgreSQL源代码堪称C语言的规范，易读性比MySQL强很多。
- 可靠性是PostgreSQL的最高优先级。它完全支持ACID特性，对于数据库访问提供了强大的安全性保证。
- PostgreSQL是多进程的，而MySQL是多线程的。虽然并发不高时，MySQL处理速度快；但是当并发高时，对于现在的多核的单台机器上，MySQL的总体性能不如PostgreSQL，原因是MySQL的线程无法充分利用CPU的能力。
- PostgreSQL有很强大的查询优化器，支持很复杂的查询处理，而MySQL对复杂查询处理较弱，查询优化器不够成熟。
Tidb (企业版收费)
1.优点
- 活跃的开源社区，数据库领域顶尖的开源技术
- 兼容MySQL协议，几乎无需修改代码，提供数据迁移工具，迁移成本极低
- 分布式事务，把TiDB看做是一个单机RDBMS。跨多个机器启动事务，不影响一致性
- 故障自动恢复，无需人工干预，真正意义的Auto-Failover
- 在线DDL，按需更新TiDB Schema，添加新的列和索引，不影响当前业务
- 弹性扩展，加机器等于加性能
2.缺点
- 有热点写入问题，导致不使用分表方案的话，插入性能被限制为单台服务器性能，而不是线性扩容
- 相比mysql，性能差很多，读写延时很高，必须ssd
- 人力学习成本
3.典型的应用场景
- 原业务的 MySQL 的业务遇到单机容量或者性能瓶颈时
- 大数据量下，MySQL 复杂查询很慢
- 大数据量下，数据增长很快，接近单机处理的极限，不想分库分表或者使用数据库中间件等对业务侵入性较大、对业务有约束的 Sharding 方案
- 大数据量下，有高并发实时写入、实时查询、实时统计分析的需求
- 有分布式事务、多数据中心的数据 100% 强一致性、auto-failover 的高可用的需求
4.不适合的场景
- 单机 MySQL 能满足的场景也用不到 TiDB
- 数据条数少于 5000w 的场景下通常用不到 TiDB，TiDB 是为大规模的数据场景设计的
- 如果你的应用数据量小(所有数据千万级别行以下)，且没有高可用、强一致性或者多数据中心复制等要求，那么就不适合使用 TiDB。
HBase
优势
- 1、存储容量大，一个表可以容纳上亿行 x 上百万列；
- 2、可通过版本进行检索，能搜到所需的历史版本数据；
- 3、负载高时，可通过简单的添加机器来实现水平切分扩展，跟Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）；
- 4、在第3点的基础上可有效避免单点故障的发生。
缺点
- 1、基于Java语言实现及Hadoop架构意味着其API更适用于Java项目；
- 2、node开发环境下所需依赖项较多、配置麻烦（或不知如何配置，如持久化配置），缺乏文档；
- 3、占用内存很大，且鉴于建立在为批量分析而优化的HDFS上，导致读取性能不高；
- 4、API相比其它 NoSql 的相对笨拙。
适用场景
- 1、bigtable类型的数据存储
- 2、对数据有版本查询需求
- 3、应对超大数据量要求扩展简单的需求
- 4、随机实时的读写操作，高吞吐量写，随机访问大数据集
案例
- Facebook 消息数据库
Redis - 键值数据库
关键点
- 只有Redis有事务机制
- 通过定时snapshot快照和基于语句的aof追加，redis支持数据持久化
优势
- 1、非常丰富的数据结构；
- 2、Redis提供了事务的功能，可以保证一串命令的原子性，中间不会被任何操作打断；
- 3、数据存在内存中，读写非常的高速，可以达到10w/s的频率。
测试数据可参考《Redis千万级的数据量的性能测试》
缺点
- 1、Redis 3.0后才出来官方的集群方案，但仍存在一些架构上的问题；
- 2、持久化功能体验不佳——通过快照方法实现的话，需要每隔一段时间将整个数据库的数据写到磁盘上，代价非常高；而aof方法只追踪变化的数据，类似于mysql的binlog方法，但追加log可能过大，同时所有操作均要重新执行一遍，恢复速度慢；
- 3、由于是内存数据库，所以单台机器存储的数据量，跟机器本身的内存大小。虽然redis本身有key过期策略，但是还是需要提前预估和节约内存。如果内存增长过快，需要定期删除数据。
3.适用场景
适用于数据变化快且数据库大小可预见（适合内存容量）的应用程序。
- 在主页中显示最新的项目列表。因为Redis使用的是常驻内存的缓存，速度非常快。
- 删除和过滤。
- 排行榜及相关问题。
- 按照用户投票和时间排序。
MongoDB - 文档数据库
优势
- 1、强大的自动化 shading 功能；
- 2、全索引支持，查询非常高效；
- 3、面向文档（BSON）存储，数据模式简单而强大。
- 4、支持动态查询，查询指令也使用JSON形式的标记，可轻易查询文档中内嵌的对象及数组。
- 5、支持 javascript 表达式查询，可在服务器端执行任意的 javascript函数。
缺点
- 1、单个文档大小限制为16M，32位系统上，不支持大于2.5G的数据；
- 2、对内存要求比较大，至少要保证热数据（索引，数据及系统其它开销）都能装进内存，即数据集大于内存很慢；
- 3、非事务机制，无法保证事件的原子性。
适用场景
- 1、适用于实时的插入、更新与查询的需求，并具备应用程序实时数据存储所需的复制及高度伸缩性；
- 2、非常适合文档化格式的存储及查询；
- 3、高伸缩性的场景：MongoDB 非常适合由数十或者数百台服务器组成的数据库。
- 4、对性能的关注超过对功能的要求。
案例
- 适合90%所有MySQL等RDBM场合
Couchbase
本文之所以没有介绍 CouchDB 或 Membase，是因为它们合并了。合并之后的公司基于 Membase 与 CouchDB 开发了一款新产品，新产品的名字叫做 Couchbase。
Couchbase 可以说是集合众家之长，目前应该是最先进的Cache系统，其开发语言是 C/C++。
Couchbase Server 是个面向文档的数据库（其所用的技术来自于Apache CouchDB项目），能够实现水平伸缩，并且对于数据的读写来说都能提供低延迟的访问（这要归功于Membase技术）。
关键点
- 写操作不会阻塞读操作
优势
- 1、高并发性，高灵活性，高拓展性，容错性好；
- 2、以 vBucket 的概念实现更理想化的自动分片以及动态扩容；
缺点
- 1、Couchbase 的存储方式为 Key/Value，但 Value 的类型很为单一，不支持数组。另外也不会自动创建doc id，需要为每一文档指定一个用于存储的 Document Indentifer；
- 2、各种组件拼接而成，都是c++实现，导致复杂度过高，遇到奇怪的性能问题排查比较困难，（中文）文档比较欠缺；
- 3、采用缓存全部key的策略，需要大量内存。节点宕机时 failover 过程有不可用时间，并且有部分数据丢失的可能，在高负载系统上有假死现象；
- 4、逐渐倾向于闭源，社区版本（免费，但不提供官方维护升级）和商业版本之间差距比较大。
适用场景
- 1、适合对读写速度要求较高，但服务器负荷和内存花销可遇见的需求；
- 2、需要支持 memcached 协议的需求。