上百亿个键值对使用什么数据库好？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2036 天前的主题，其中的信息可能已经有所发展或是发生改变。

键和值都是不超过 70 个字符的字符串。读的速度要求不大，写的速度需要非常快，最好还能节省空间。
什么数据库合适呢？

字符

数据库

键值

速度

38 条回复 • 2019-04-18 19:06:16 +08:00

liuzhen

2019-04-17 22:48:18 +08:00

弄上百个普通的 kv 库

根据键的 hash 值或者其他策略决定放在哪个库？

misaka19000

2019-04-17 22:51:26 +08:00 via Android

redis

lhx2008

2019-04-17 22:52:04 +08:00

内存够的话，redis cluster

blackcurrant

2019-04-17 22:55:04 +08:00

@misaka19000 需要数据完全写在硬盘上，因为没有这么多的内存。

yidinghe

2019-04-17 22:56:10 +08:00 via Android

100 亿条 140 字节记录本身 1300GB 左右，你说的速度快是需要每秒写入多少 GB 呢？

cshlxm

2019-04-17 23:00:46 +08:00

redis 集群啊

feiyuanqiu

2019-04-17 23:01:54 +08:00 via Android

hbase

leeg810312

2019-04-17 23:04:45 +08:00 via Android

LevelDB RocksDB

sufaith

2019-04-17 23:07:01 +08:00

redis

blackcurrant

2019-04-17 23:08:52 +08:00

@yidinghe 起码要比 mysql 的写入速度快才行。

9hills

2019-04-17 23:14:55 +08:00 via iPhone

Redis 用到你的需求不合适

写多读少，单机版建议用 LevelDB
分布式可以试试 Cassandra

zycpp

2019-04-18 08:35:39 +08:00 via iPhone

leveldb +1
虽然没弄过这么大的…，我目前数据在亿级别，没啥问题

JimmyTinsley

2019-04-18 08:44:24 +08:00

试试 Cassandra?

reus

2019-04-18 08:44:41 +08:00

唯一选择就是 rocksdb，不少关系数据库都用它做后端

reus

2019-04-18 08:45:43 +08:00

不要用 leveldb，一个几年了的严重问题，最近才修复。同样的问题，rocksdb 早修复了。

wangxiyu191

2019-04-18 08:55:58 +08:00

要优化写的话，找个用 LSM-Tree 的就好。单机 Rocksdb，集群的话一堆了 Tair-LDB Cassandra Scylla TiKV 等等……

zhanwh9

2019-04-18 09:05:42 +08:00 via Android

hbase 感觉比较合适

geeti

2019-04-18 09:24:04 +08:00

没人推荐 dynamodb?

petelin

2019-04-18 09:36:37 +08:00 via iPhone

@geeti 推荐 dynamodb 不是开源项目懂得人少

haohappy

2019-04-18 09:48:56 +08:00

MongoDB 不行么

wbrobot

2019-04-18 09:53:23 +08:00

信得过豆瓣的话，beansdb

dremy

2019-04-18 10:02:44 +08:00 via iPhone

YY 的面试题吧，要真有这么大的数据量，还会连个数据库都选不定？

qianji201712

2019-04-18 10:06:42 +08:00

Instagram 有一篇介绍 Redis 的 Key 存储的文章，写得很详细，可以参考一下：

https://instagram-engineering.com/storing-hundreds-of-millions-of-simple-key-value-pairs-in-redis-1091ae80f74c

中文翻译： https://www.cnblogs.com/ajianbeyourself/p/4475172.html 不知道翻译是否准确，看英文最好

kex0916

2019-04-18 10:10:38 +08:00

hbase

qq976739120

2019-04-18 10:16:45 +08:00

目测又是哪个面试题

joesonw

2019-04-18 10:19:55 +08:00

TiKV?

gouchaoer

2019-04-18 11:47:50 +08:00 via Android

mysql 用 tokudb 引擎啥的？组个 8T 硬盘的 raid 足够存数据了。。。别的分布式方案运维挺麻烦的，用云服务又很贵

zorui

2019-04-18 11:55:27 +08:00

etcd

yuankui

2019-04-18 11:59:18 +08:00

HBase，go go go

abcbuzhiming

2019-04-18 12:01:01 +08:00

这种级别的数据必须考虑是写多还是读多的问题了，楼主你的场景是什么，是写多还是读多？

yanaraika

2019-04-18 12:03:56 +08:00

9 成 9 是面试题……实际中性能最高最简单的做法就是买台几百 G 内存的机子+压缩下元素+LSM Tree。不折腾多机

yanaraika

2019-04-18 12:05:25 +08:00

sap hana 解决 99%的数据问题

blueskea

2019-04-18 12:05:34 +08:00 via Android

hbase

txy3000

2019-04-18 12:07:08 +08:00

要求写快可以上分布式的内存数据库 zookeeper + redis + codis 可扩展可容灾可随机读取丰富的数据结构还可以异步持久化
如果读确实很少且一致性要求不高也可以用 Kafka 做个消息层把写的消息存起来后端接个 disk 的数据库慢慢处理写就行了

blless

2019-04-18 12:17:17 +08:00 via Android

问就是分片，redis 或者自己 hash 分都一样

luozic

2019-04-18 13:38:00 +08:00

有錢沒？有錢隨便；沒錢自己上 redis/postgresql

hoythan

2019-04-18 13:53:07 +08:00

推荐 redis 都是认真的吗，没有读的需求，只要写呀。

tenyears102

2019-04-18 19:06:16 +08:00

pika