0%
推荐分析
|
业界常用场景 |
推荐场景 |
推荐分析 |
注意事项 |
| redis |
内存数据库、缓存、秒杀等高并发场景 |
1、需要支持高并发读写场景 |
|
主要特征依然是缓存数据，宕机存在短时间内的数据丢失，重要数据要先保证落库（mysql） |
| tair |
一种基于ssd降本考虑的替代redis的方案 |
1、同样支持高并发读写场景 |
理论上性能是略低于redis的 1、实测除非对于rt要求近乎变态的场景，否则可选tair 2、暂时数据结构支持的有限（k/v结构） |
|
| Elasticsearch |
1、日志查询 2、增强MySQL结构化查询 3、检索 4、比较小的聚合统计 |
1、全文检索 2、增强结构化查询的场景 |
1、近实时，写入后1s可见（默认） 2、统计聚合支持一般，数据量不能超过百万，聚合QPS支持不高 3、不支持事务 4、不支持联表，通过嵌套结构实现 |
|
| Clickhouse |
1、时序数据库 2、OLAP，海量数据统计聚合分析 |
1、监控 2、聚合分析 |
|
支持QPS不高 |
| hbase |
订单/账单存储、用户画像、时空/时序数据、对象存储、Cube分析、Feeds流等 |
1、大表及高并发场景 单表数据量超过千万或者十亿百亿的时候，并且伴有较高并发，可以考虑使用HBase 2、单条记录查询 Hbase对Rowkey做了索引优化，数据量庞大的情况下，根据行键的查询效率依然很高，非常适合根据行键做单条记录的查询 |
数据分析是HBase的弱项，如果主要的业务需求就是为了做数据分析，比如做报表，那么不建议直接使用HBase。 |
|
| tidb |
1 对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景 2 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 3 Real-time HTAP 场景（HTAP指oltp+olap） 4 数据汇聚、二次加工处理的场景 |
1、高并发海量数据的读写场景 |
1、分布式数据库对海量数据多个kv同时计算 2、集群扩展性很强 |
1、单条sql处理能力弱于mysql 2、tidb-server对大规模的聚合查询需求的内存比较高 |
基础特性
| 数据库 |
并发（读/写）参见存储选型标准测试报告 |
实时可见性 |
事务支持 |
高可用 |
并发一致性 |
动态扩缩 |
分片聚合查询 |
全文检索 |
存储结构 |
type |
语法 |
| mysql |
取决于：表结构大小，以及表关联的复杂度等 |
实时： 需关注事务级别 |
ACID |
主库和高可用备库是半同步，跟业务从库是异步 |
mvcc |
/ |
/ |
差 |
行 |
关系型 |
sql |
| mysql sharding |
依赖分片数 |
实时：需关注事务级别 |
默认本地事务 |
主库和高可用备库是半同步，跟业务从库是异步 |
mvcc |
/ |
/ |
差 |
行 |
关系型 |
对sql的特殊预发支持有限 |
| redis |
高读写： (如果特殊场景要用uc的集群版本需注意：集群版本支持的qps跟内存的大小有关系：1g 3000qps) |
实时 |
支持有限：不建议使用 |
高可用版本：1、异步同步 2、aof策略appendfsync=everysec |
支持部分原子性操作 |
支持：纵向扩容（最大64g） |
/ |
/ |
kv/list/hash.. |
内存数据库 |
|
| Tair |
高读写 |
实时 |
不支持 |
异步同步 |
支持：版本控制、原子性计数 |
支持：水平扩缩 |
/ |
/ |
k/v |
基于ssdkv存储 |
|
| Elasticsearch |
单台 QPS：千级 TPS：千级 依赖机器数和shard数 |
近实时（1s可见） |
不支持 |
同步写从：从必须写入成功 |
乐观锁 |
支持 |
支持：性能一般 聚合百万数据基本达到瓶颈，支持QPS较低 |
好 |
倒排索引 + 行 |
文档型 |
dsl |
| Clickhouse |
查询：100左右 写入：速度大约为50MB/s（必须批量） |
实时 |
不支持 |
高可用 |
|
/ |
分析性数据库：非常好 |
差 |
列 |
|
|
| hbase |
高读写 |
实时 |
支持 |
分布式高可用 |
使用行锁+MVCC机制实现一致性 |
支持：水平扩缩 |
支持 |
/ |
列 |
分布式数据库 |
Native Java API /Thrift Gateway/Rest Gateway |
| tidb |
取决于：分布式集群的大小，并发性总体好于mysql（相对） |
实时：但是简单sql的处理能力不好 |
ACID |
分布式高可用 |
mvcc |
支持 |
支持 |
/ |
行+列 |
关系型 |
sql |
测试报告
选型对比
ElasticSearch vs MongoDB
|
MongoDB |
ElasticSearch |
备注 |
| 定位 |
(文档型)数据库 |
(文档型)搜索引擎 |
一个管理数据,一个检索数据 Elasticsearch更倾向于数据的查询, 一般情况下elasticsearch仅作为数据检索服务和数据分析平台, 不直接作为源数据管理者 |
| 资源占用 |
一般 |
高 |
mongo使用c++, es使用Java开发 |
| 写入延迟 |
低 |
高 |
es的写入延迟默认1s, 可配置, 但是要牺牲非常大的性能 |
| 全文索引支持度 |
一般 |
非常好 |
es本来就是搜索引擎, 这个没啥可比性 |
| 有无Schema |
无 |
无 |
两者都是无Schema |
| 支持的数据量 |
PB+ |
TB+ ~ PB |
两者支持的量并不好说的太死, 都支持分片和横向扩展, 但是相对来说MongoDB的数据量支持要更大一点 |
| 性能 |
非常好 |
好 |
MongoDB在大部分场景性能比es强的多得多 |
| 索引结构 |
B树 |
LSM树 |
es追求写入吞吐量, MongoDB读写比较均衡 |
| 操作接口 |
TCP |
Restful(Http) |
|
| 是否支持分片 |
是 |
是 |
|
| 是否支持副本 |
是 |
是 |
|
| 选主算法 |
Bully(霸凌) |
Bully(霸凌) |
相比于Paxos和Raft算法实现更简单并有一定可靠性上的妥协，但是选举速度比较快 |
| 扩展难度 |
容易 |
非常容易 |
es是扩展最方便的存储系统之一 |
| 配置难度 |
难 |
非常容易 |
|
| 地理位置 |
支持 |
支持 |
|
| 运维工具 |
丰富 |
一般 |
|
Redis vs Tair
|
存储 |
同步 |
容量成本 |
性能 |
支持数据结构 |
场景 |
| redis |
主要内存，磁盘异步持久化数据 |
异步 |
|
强 |
kv/hash/list… |
缓存/抗并发 |
| tair |
磁盘主要ssd，内存提供二级缓存(可选) |
异步 |
|
稍微弱于redis |
目前支持kv和前缀kv |
可用于存储，提供多副本节点保证数据安全 |
MySQL vs TiDB
|
SQL语法 |
隔离级别 |
锁 |
存储过程/触发器/事件 |
外键约束 |
CREATE TABLE tblName AS SELECT |
CREATE TEMPORARY TABLE |
| mysql |
全支持 |
支持读未提交、读已提交、可重复读、串行化，默认为可重复读 |
悲观锁 |
支持 |
支持 |
支持 |
支持 |
| Tidb |
兼容绝大多数 |
乐观事务支持快照隔离，悲观事务支持快照隔离和读已提交 |
乐观锁、悲观锁 |
不支持 |
忽略外键约束 |
不支持 |
TiDB 忽略TEMPORARY 关键字，按照普通表创建 |