这是一个创建于 986 天前的主题，其中的信息可能已经有所发展或是发生改变。
目的：根据唯一主键从数据库中查询一行数据，要求 50TPS，延迟在 200ms
数据库现状：每天新增数据 10 亿行，保留 15 天数据，即数据库基本上稳定在 150 亿行数据（后续会增长到每天新增 30 亿行，即 450 亿行数据）
对数据库的要求：写入 TPS 至少为 2W，并且可以扩展。读取要求不高，并且为简单的查询场景，只使用唯一主键进行查询，没有其它需要
使用场景：数据镜像保存，并在需要的时候取出数据
数据库现状：每天新增数据 10 亿行，保留 15 天数据，即数据库基本上稳定在 150 亿行数据（后续会增长到每天新增 30 亿行，即 450 亿行数据）
对数据库的要求：写入 TPS 至少为 2W，并且可以扩展。读取要求不高，并且为简单的查询场景，只使用唯一主键进行查询，没有其它需要
使用场景：数据镜像保存，并在需要的时候取出数据
 |
1
liprais 2021-08-05 11:48:46 +08:00 via iPhone
hbase 完事
|
 |
2
zoharSoul 2021-08-05 11:49:24 +08:00
我觉得 hbase 就很合适
|
 |
3
saytesnake 2021-08-05 11:55:25 +08:00
假设服务器配置不错的情况，hbase 集群完事 +1，写入很舒适。
|
 |
4
winnie2012 2021-08-05 11:56:15 +08:00
|
 |
5
zmxnv123 2021-08-05 12:42:05 +08:00
kv 存储吗，试试 tikv
|
 |
6
sanestays 2021-08-05 12:54:27 +08:00
doris clickhouse
|
 |
7
learningman 2021-08-05 12:56:07 +08:00 via Android
唯一主键找 kv 呗
|
 |
8
defage 2021-08-05 12:58:49 +08:00
hbase 吧，应该是最合适的了
|
 |
9
rekulas 2021-08-05 13:02:51 +08:00
纯 kv 数据库选择就多了 rocksdb 应该是入手最简单又能满足需求的
|
 |
10
blackshow 2021-08-05 13:12:45 +08:00
cassandra
|
 |
11
dusu 2021-08-05 13:17:53 +08:00 via iPhone
这个规模要并发、要简单 用 ssdb 多主就 ok 了，ssdb 的主从使用运维体验基本无敌，唯一就是注意业务上分 key 写节点，key 按日期前缀生成，直接扫前缀就能清理
|
|
13
dusu 2021-08-05 13:34:34 +08:00 via iPhone
@wzw （一年多前） pika 在生产环境下集群各种不稳定，也可能是我们 hold 不住，所以换回 ssdb 了，ssdb 虽然不更新但是够用，基本没蹦过
|
 |
15
eric96 OP |
 |
16
Jface 2021-08-05 14:19:47 +08:00
Hbase 吧 或者试试 TiDB?
|
 |
17
huangzxx 2021-08-05 14:25:08 +08:00
clickhouse
|
 |
18
dog82 2021-08-05 15:10:03 +08:00
传统数据库，做分区表，能撑住吗？
|
|
20
eric96 OP @dog82 我设想了一下，估计是撑不住的。
因为需要类似 ttl 的实现，所以如果使用时间作为分区键的构成之一，会导致写入的热区（所以基本上是撑不住 2WTPS 的写入），并且由于查询的时候，只有主键没有时间信息会导致查询上的性能问题（当然也可以修改目前主键的构成，加上时间信息，后续查询的时候解析出时间信息）。所以即使修改主键的构成，但是依旧无法解决写入的问题 如果不使用时间信息去做分区，将无法删除旧数据，会导致数据一直膨胀，而且传统的数据库删除数据并不会释放磁盘空间，只有删除库或分区才会释放空间 |
|
21
rekulas 2021-08-05 16:05:55 +08:00
@eric96 kv 写入是完全没有问题的(渣机都可以跑到 4w+)，不过一般的 kv 库都存字符串不支持字段(需要序列化存储)，要支持字段只能考虑楼上列的其他非 kv 数据库
|
|
22
dog82 2021-08-05 16:58:06 +08:00
你这种需求好像比较适合时序数据库
|
 |
23
azkaban 2021-08-05 17:21:32 +08:00
aerospike
|
 |
24
shot 2021-08-05 18:32:46 +08:00
> 目的：根据唯一主键从数据库中查询一行数据，要求 50TPS，延迟在 200ms
如果没有硬件资源限制的话，任何支持水平线性扩展的分布式数据库都能满足吧。 数据量再大，性能要求更高，加机器完事。 Cassandra 完美契合这一需求，参考 Discord 的经验：12 个节点，3 重复制，支撑日均过亿消息，写操作亚毫秒，读操作 5 毫秒。 https://blog.discord.com/how-discord-stores-billions-of-messages-7fa6ec7ee4c7 Discord 去年声称迁移到了性能更佳的 ScyllaDB，但是没有看到具体的性能指标。 https://www.scylladb.com/press-release/discord-chooses-scylla-core-storage-layer/ |
|
25
shot 2021-08-05 18:36:09 +08:00
@eric96
如果只评估传统的关系性数据库的话，那就尝试分区、分表、分库操作吧。 撑不住 20k tps 写入，可以考虑加一个消息队列做缓冲，批量处理批量写入。 在对读操作要求不高的场景下，问题应该不大。 |
 |
26
Samuelcc 2021-08-05 18:38:32 +08:00 via Android
正是 hbase 发挥武艺的地方
|
 |
27
Maxwe11 2021-08-05 19:40:28 +08:00
这需求简直就是按照 hbase 准备的。
|
 |
28
sagaxu 2021-08-05 19:48:46 +08:00 via Android
mysql 也扛得住，主键改成: 日期+db 实例+序列号，假设 100 个实例，每天 100 张独立的表，每张表 3000 万压力不大。清理的时候直接 drop 对应日期的表。
|
 |
29
ajaxfunction 2021-08-05 22:50:00 +08:00  1
真想看看这种大场面，
目前维护的数据库里最多的一张业务表也就几千万数据，一个普通索引就够了 |
 |
30
limbo0 2021-08-05 23:14:13 +08:00
主键查询省事很多, 直接 hbase
|
 |
31
shakoon 2021-08-06 10:25:00 +08:00
预算不说一下吗？费用充足 taradata，费用一般 greenplum，费用拮据 hbase
|
|
32
eric96 OP @shakoon 现在用的云服务，基本上每个月根据流量情况在 5000 刀-1W5 刀左右。想换掉的目的一个是想拜托对这个云厂商的依赖（其他云没有这个服务，也没有对应开源服务），另一个目的是能省钱最好，省不了钱也能接受
|
 |
33
hjosama200 2021-08-06 17:09:19 +08:00
@ajaxfunction 真想看看这种大场面呢呜呜呜，这话说的，几千万还不满足吗 QAQ，这边孩子最多的用户表数据 500 不到，咱也想看看大场面呢 QAQ，4 年 java 后端，月薪 4k，美名其曰技术总监... 呜呜呜呜
|
|
34
hjosama200 2021-08-06 17:09:44 +08:00
救救孩子吧 QAQ
|
|
35
ajaxfunction 2021-08-06 18:00:12 +08:00
@hjosama200 你这也太惨了吧，是不是 to b 的啊，要不 500 个用户咋养活公司呢？
我 to c 随便一场活动 新用户就新增 2000+啊， 但留存不到 15%。 |
 |
36
someonedeng 2021-08-06 23:31:45 +08:00
@hjosama200 该换工作了兄弟
|
 |
37
aru 2021-08-07 08:30:47 +08:00
greenplum 绝对满足，多开点硬盘，多搞分区
|
 |
38
makdon 2021-08-07 10:37:13 +08:00
@hjosama200 跑路吧孩子，这用户也太少了，每个用户得花多少钱才能养活这公司
|
 |
39
flyingfz 2021-08-07 12:04:53 +08:00
|
|
40
hjosama200 2021-08-09 09:28:58 +08:00
@ajaxfunction 辣鸡公司哪有 to b 那种大格局呀~ 显然是 to c 呀，用户上线率不到几十个，就是叫人充 vip 的辣鸡 app
|
Select Language