互联网存储选型推荐

推荐分析

业界常用场景 推荐场景 推荐分析 注意事项
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

测试报告

存储 常规指标 性能测试报告
redis get/set:写:7w+/s;读:9w+/s
mysql 20张表,200万数据:tps:3000+;qps:50000+
tair get/put:写:1w+/s;读:3w+/s
Clickhouse 参见测试报告 https://clickhouse.tech/benchmark/dbms/
tidb 参见测试报告 https://docs.pingcap.com/zh/tidb/dev/benchmark-tidb-using-sysbench
Elasticsearch 参见测试报告

选型对比

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 关键字,按照普通表创建