互联网存储选型推荐
推荐分析
业界常用场景 | 推荐场景 | 推荐分析 | 注意事项 | |
---|---|---|---|---|
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 关键字,按照普通表创建 |