本来数据量小的时候用的就是 MySQL ，后来爬虫做过升级后，无论是广度和深度都有了改进，数据量慢慢已经来到了亿级，查询越来越慢，只能一直加索引来加快查询速度，但是这不是长久之计，准备从数据库上改善这个问题。
希望更换一个对于大数据量支持友好的数据库，奈何本人这方面了解的确实不多，希望各位 v 友给点建议。

谢谢大伙的建议，爬虫这边与数据库这边确实不太熟，半路做的东西，认真听取了各位朋友的建议，现在第一是优化 MySQL 现有的查询吧，其次我会好好去了解大家提出来的其余的方案，斟酌一个最适合的。感慨自己需要学的东西还有很多。

放 es 里面？

mongodb

tidb?

索引质量低导致查询慢，索引太多导致插入慢，换 DB 可能解决不了

不知道数据特性和数据结构，是否经常删改，经常聚合分析，使用场景也不清楚 不好推荐。我们在用 Clickhouse, 朋友在用 StarRocks 。可以了解对比一下

是数据量大—①—>查询慢—②—>加索引，这个逻辑链，现在想解决第一个传导逻辑。

数据量大查询慢，是因为索引质量低

图片和视频（均为链接）数据，使用场景目前最主要是就是下载和更新状态

＃7 那只需要建立高质量索引就不需要更换 db 了这个意思嘛，我一开始是认为 MySQL 对于大数据量的支持不是很友好才想要更换 db 的

考虑一下分库分表？

产品设计导致只能放在一张表里，哎

谢谢回答，我去调研一下

谢谢回答， 我去调研一下这个 db

我自己这边找的方案现在是在 mongodb 和 PostgreSQL 之间比较，那我先去看看 mongo

分布式数据库

老哥细说一下呢

这个场景不太适合，Clickhouse 和 StarRocks 。另外上亿数据量对于 mysql 还不算大数据。 我感觉也是先优化索引比较好。ES 也比较合适，可以等数据量再大的时候换 ES 。

＃17 谢谢解答，我这就去优化一下索引相关

才亿级别，直接 clickhouse 吧，百亿都没问题。

换 starrocks 1.兼容 mysql 协议，代码完全不用改2.才亿级数据，对 sr 来说就是毛毛雨，都不够热身缺点成本高很多

海量数据（上亿）的查询问题，用 clickhouse 、tidb 、aliyun 的 adb ，来自 [实际经验] 。

tidb ？

亿级就慢了吗?我用的阿里云的 rds mysql 的 1H1G 的入门款，有个表三四亿的数据量感觉也没啥影响。。不过我没啥联表的操作

clickhouse 吧

爬蟲數據庫理論上也不會有 join

ClickHouse

postgresql , 上亿够用...

才亿级，我的 mysql 单表几亿，一点都不慢。做好索引是关键。

无脑 es 吧，数据量大了 水平扩展起来也方便。或者 Cassandra 这种。

clickhouse 好用高效

mongo

hbase ？

ck

hbase(支持大数据的 mysql 替代)clickhouse(便宜高性能的 es 替代)

clickhouse, 爬虫为什么要更新数据，全部存起来，用 sql 过滤数据，上百亿都么有问题

表结构、索引、查询语句先提供出来，要看你的需求场景是否是 mysql 擅长的，任何数据库都有自己擅长的领域，如果实在是需求和数据不匹配的话，才需要去考虑换数据库，换数据库还会有数据迁移的问题，上亿数据的迁移方案你有考虑过吗？

什么查询场景？ mysql 做文本召回？ kv 查询直接 kv 存储不就行了

强推 starrocks ，组里落地效果非常好

只要不较劲，mongodb 就够了

"上亿"这个数据量太小了，哪需要专门考虑什么方案

greenplum 分布式数据库了解一下

我在数据公司待过，有专门的爬虫团队和数据开发团队，我们用的方案，最早是 Cassandra ，然后是 TiDB ，最后换成了 HBASE 。Cassandra 不说了，只是早期过渡方案。TiDB 的好处是我们和 PingCAP 有交情，技术支持比较到位，而且 MySQL 协议处理方便。缺点就是需要每天增量同步到 Hadoop 集群。HBASE 则是因为我们后来数据量上来了，用 HBASE 方便在 Hadoop 集群框架下进行处理。如果你有很多基于 SQL 的分析任务已经在运行了，选择 TiDB 是最好的，迁移成本极低。如果你有 Hadoop 集群了，MySQL 只用于临时存储爬虫，那可以换成 HBase

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

MySQL 单表上亿也不差的。如果换 No SQL ，比如 MongoDB 上亿走个 sharding / replica 也没啥问题。关键还是要看需要怎么新增，怎么查。

之前公司（爬虫公司），数据也是放在 Hbase 里面的流程和 类似的

我提一个 Doris 分布式数据库,之前公司用过 tidb 但是跟 mysql 还是有比较大的差距,迁移不过去....后来用了 Doris,总的来说还行,1T 数据量的表也能嗖嗖的出结果不过分布式数据库,重在分布式 成本也会上涨,这个事情也要考虑

redis

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

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

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

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

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

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

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

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

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

你从 mysql 迁移考虑一下 doris 吧

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

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

嘲讽一波 ...楼上大部分上来就让楼主换数据库的 对数据库 对大数据 完全是一点都不了解..建议 op 好好了解下瓶颈在哪里 .表设计表结构是不是有问题.. 查询方式是不是有问题. 这些才是问题的解决思路, 而不是上来就换个数据库 ..

上亿对 mysql 来说压力不算大，优化一下库结构，优化一下查询应该就能解决，或者直接加点硬件（加内存和 CPU 或者换更快的 SSD ），钱能解决的都不是问题。

加个 redis 做去重缓存，具体字段随便放哪个数据库

mongo 切到 syscylla 就行了。

kvrocks ，可以说是 redis 硬盘版，速度大概是 redis 的一半左右，如果 nvme 硬盘还有提升空间

异构数据迁移方案呢？是否支持平滑迁移？服务替换数据源的过度方案？这些都是要考虑的事情。看楼主的描述，基本可以确定对数据库是不怎么熟悉的，更不要说数据迁移要注意哪些事情了。如果你是非常熟悉各种数据库的，那对你来说当然算不上“方案”，因为你已经有过丰富的经验了，对于楼主来说就是完全陌生的领域，那我在回复楼主的时候指出要注意数据迁移方案，有什么问题呢？我又不是对那种有丰富数据库使用经验的人说的。

好强，看来是大企业，我们只是几十人的小公司，自己搭建和使用的而已。

亿级理论上 MySQL 也还好啊，是否是 SSD 硬盘？索引优化爬虫感觉更适合 MongoDB 这种文档型数据库，随时加个字段页无所谓，MongoDB 建好索引十来亿问题也不大，不过没索引就很慢

我之前公司用的 elasticsearch

点赞👍

其实 Mysql 也行

谢谢大伙的建议，爬虫这边与数据库这边确实不太熟，半路做的东西，认真听取了各位朋友的建议，现在第一是优化 MySQL 现有的查询吧，其次我会好好去了解大家提出来的其余的方案，斟酌一个最适合的。感慨自己需要学的东西还有很多。

＃36 感谢老哥的解答，我们已经在复盘了

＃43 谢谢！这个建议很实用！我们会把这个链路考虑进去的

mongo 或 es 比较省事

postgresql 自带的分表，逻辑上可以当成一张表用