虚心求教，数据量上亿的爬虫数据用什么该用什么数据库呢

[morost]

本来数据量小的时候用的就是 MySQL ，后来爬虫做过升级后，无论是广度和深度都有了改进，数据量慢慢已经来到了亿级，查询越来越慢，只能一直加索引来加快查询速度，但是这不是长久之计，准备从数据库上改善这个问题。

希望更换一个对于大数据量支持友好的数据库，奈何本人这方面了解的确实不多，希望各位 v 友给点建议。

[smallparking]

greenplum 分布式数据库了解一下

[user919lx]

我在数据公司待过，有专门的爬虫团队和数据开发团队，我们用的方案，最早是 Cassandra ，然后是 TiDB ，最后换成了 HBASE 。
Cassandra 不说了，只是早期过渡方案。
TiDB 的好处是我们和 PingCAP 有交情，技术支持比较到位，而且 MySQL 协议处理方便。缺点就是需要每天增量同步到 Hadoop 集群。
HBASE 则是因为我们后来数据量上来了，用 HBASE 方便在 Hadoop 集群框架下进行处理。

如果你有很多基于 SQL 的分析任务已经在运行了，选择 TiDB 是最好的，迁移成本极低。
如果你有 Hadoop 集群了，MySQL 只用于临时存储爬虫，那可以换成 HBase

[user919lx]

对了，如果十分追求分析性能，Clickhouse 是正确的选择。但是我们一般把 Clickhouse 用于最后使用的终端，与爬虫数据存储是隔离开的，我们的链路大致上是：爬虫原始数据存储（ HBase 或 TiDB) -> 数仓处理和存储(Hadoop 集群) -> 供各应用使用的数据集市(Clickhouse)，就算你不使用 Hadoop 来处理数据，读写分离也是很重要的。混在一起的话读写都会被拖慢

[wupher]

MySQL 单表上亿也不差的。

如果换 No SQL ，比如 MongoDB 上亿走个 sharding / replica 也没啥问题。

关键还是要看需要怎么新增，怎么查。

[feiniu]

之前公司（爬虫公司），数据也是放在 Hbase 里面的

流程和 @user919x 类似的

[chenfang]

我提一个 Doris 分布式数据库,之前公司用过 tidb 但是跟 mysql 还是有比较大的差距,迁移不过去....

后来用了 Doris,总的来说还行,1T 数据量的表也能嗖嗖的出结果

不过分布式数据库,重在分布式 成本也会上涨,这个事情也要考虑

[rockxsj]

redis

[iyaozhen]

得先看看公司预算

tidb 那玩意搭一个最小集群，都不是一个小公司能承受得了的

[janus77]

先做常规优化吧，索引、分库分表什么的，然后不知道你的业务细节，是否可以加 cache 层，冷热数据分离等方案，亿级别的话努努力是没必要换数据库的

[fengfisher3]

@yh7gdiaYW
@Jinnrry
请问你们的 starrocks 的版本是什么，是 2.x 还是 3.x ，我们的 3.1.x 我想升级一下，但不知道哪个版本更稳定，更好。

[rust]

我们以前爬过某音的视频 meta 数据,大概 6 亿多,放在 MongoDB 里边,跑数据库的机器的 RAM 大概 1T, 然后索引就有 700 多 G, 硬盘占用大概 7.2T 左右,固态阵列. 秒查~

[securityCoding]

clichhouse 吧 ,不过使用场景不同直接一份 kafka 分发出去分别落库吧

[wenxueywx]

现在 mysql 使用的磁盘都说 ssd ，亿级数据，只要使用姿势正确完全没有问题
建议先优化原 db
前面也有老哥说了，不清楚你的数据结构，使用场景是这些确实不好推荐

[likeman]

@morost 如果一定要是一张表，可以看看 postgres 的 table partition ，本质是一个大表，但是可以根据 partition 规则切分为若干个小表(显示还是一个大表)，这样索引数据也小了，插入查询也快得多

[phrack]

这点数据量如果不是数据结构很复杂的，mysql 不是瓶颈

[perpetually]

starrocks

之前公司 10 几亿的咨询数据都是放在这里面，查询速度还可以

[zhaopy4721]

你从 mysql 迁移考虑一下 doris 吧

[hangszhang]

我就好奇，你们这种说几亿条数据，mysql 也不慢的，是只用主键索引检索数据么？

[Jinnrry]

@fengfisher3 我们是 2.5.12 ，但是我们有自己的 SR 研发团队和运维团队，我只管存数据，查数据就行。其他的直接提工单摇人就行

[changdy]

嘲讽一波 ...
楼上大部分上来就让楼主换数据库的 对数据库 对大数据 完全是一点都不了解..

建议 op 好好了解下瓶颈在哪里 .表设计表结构是不是有问题.. 查询方式是不是有问题.

这些才是问题的解决思路, 而不是上来就换个数据库 ..