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