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
|