请问存储百万条或者千万条抖音评论应该选用什么数据库？怎么设计？

[iiq2000]

每个抖音作者都会有数条视频，而每条视频下又会有数条评论。估计会有数百个抖音作者，千万条评论，读写会比较频繁，可能会日增几万条或者十万条数据，老板想把这些评论信息都存到数据库（评论者抖音号、评论内容，评论时间，对应的视频 id ）。

我目前想到的是存到 MongoDB，每一个作者抖音号是一个集合名字，集合里就是这个作者下所有视频的评论（每条评论里会包含对应的视频 id ）；

同事建议用关系型数据库，把表分细一点，然后设置外键，查询的时候联合查询，如果数据量大的话，哪种方式会更好一些呢？是应该选用关系型数据库还是非关系型呢？烦请赐教。

[jr55475f112iz2tu]

查询频繁就用 ES ?

[vhysug01]

es? 做宽表

[murmur]

你们存这些东西是干嘛，需求都不说么，都有能力爬抖音了还没能力存，这啥爬虫公司

[rexyan]

抖音号和视频关系数据放 mongo，评论数据放 es 。关系型的特点你这里用不到吧，强 schema，事务... 对你来说都没用

[3dwelcome]

查的时候都是建立索引的，两个方法应该都很快。

当然个人偏好 key-value 数据库，比较清晰。

用传统关系数据库的好处，是配套工具挺多的。

[DollarKiller]

bigtable 或者上 Cassandra

[Mithril]

评论需要检索吗？不检索你直接存文件也行。

[leafre]

MongoDB 可以 做好索引

[iiq2000]

@czfy
@vhysug01 好的，谢谢提供思路，但是不一定能用上，因为公司比较小而本人又比较菜

@murmur 老板是想从特定类型账号的视频评论里找出意向客户的，所以需要存评论然后检索，公司是个小公司，加上老板总共五个人，我和另外一个同事搞技术的，比较菜，确实对于怎么存没有什么好主意


@rexyan 确实不知道 es 还能存数据，只知道能搜索，我再搜索下用法


@3dwelcome 好的，感谢


@DollarKiller 感谢回复，但是大概率不会用


@Mithril 需要，之前的方案是每个视频的评论存 excel 表，然后通过 excel 自带筛选功能去检索，但是老板嫌弃 excel 界面太丑，让存数据库然后做个好看的页面展示并检索

[iiq2000]

@leafre 这样的话，每个集合对应一个抖音作者所有的视频评论信息，每个集合又包含好多评论，可能会有几千几万个集合，每个集合又包含几十万或者上百万条评论信息，结构是不是不太合理啊

[lasuar]

涉及海量数据表查询，用外键是作死

[lasuar]

海量数据，统计，mongodb 能用

[westoy]

关键词
"爬抖音"
"老板"
"同事"

感觉又是监狱风云系列啊

没人建议离职保平安么?

[ebingtel]

最简单的存就行了……涉及到分表问题，按照抖音号存分表就可以了 没啥难度吧？

[flyingfz]

昨天看了个 腾讯开源的 tendis ， 简单来说，就是 把 RockDB 使用 Redis 的协议暴漏出来 ， 同时支持集群(扩容)。

貌似 你的需求可以用这个 试试， 具体你可以自己看看 。

[jr55475f112iz2tu]

@westoy 这确实是灰色地带，主要看风向
像飞瓜、x 瓜这种多平台爬虫做得这么成熟的，如果哪一天这类爬虫真的不合法了，这种全集团就一锅端了

[rust]

@czfy 不用等到"哪一天这类爬虫真的不合法",它现在就是不合法的,不过这种事情都是"民不举官不究"的.
那些个企查查什么的,爬工商系统都没人管.

[jr55475f112iz2tu]

@rust 不不不，企查查之类的不一样，企查查 /天眼查 /启信宝之类的，都有 gov 相关的投资，你可以认为他们都是靠红色关系获得了免死金牌获取工商信息

针对抖音之类的爬虫，抖音肯定也清楚，就看是不是有哪一天抖音觉得这些流量以及在此至上诞生的服务对自己的利益产生了严重的负面影响，那时候它就会去起诉了。暂时来说还没到这一步

[james2013]

使用 mysql
作者表
视频表
评论表(根据视频 id 进行分表,比如分 1024 张表)

[luoqeng]

NewSQL

fdb-record-layer

[luoqeng]

tidb yugabyte cockroachdb

[realpg]

这点数据量 而且模型简单 任何关系数据库都没问题

[felixcode]

这点数据关系型完全没问题，哪来什么海量数据啊

[qiayue]

我们有个 mysql 表，现在六千万行数据了，每天新增一两百万条，用的就是最简单的方案，暂时没遇到瓶颈。

我的建议是，先做先实现，后面遇到瓶颈了，再来考虑优化。

[lululau]

这个量级，MySQL 就行了

[yogogo]

@czfy
#18 灰产还是少做点，容易迷失方向。你现在这么说只是在安慰自己而已

[moen]

推荐用 timescaledb，既有关系型数据库本身的优点（本身就是 pg ），又能处理像这样的海量时序型数据（可以自动分表和压缩旧数据）

[ipwx]

es 不就干这种事么，而且还能做全文检索。。。多好

[wzq001]

抖音 才可能会日增几万条或者十万条数据？？？

[wzq001]

MySQL：你是不是看不起我？？？

[jr55475f112iz2tu]

@yogogo 啊哈哈哈，走一步算一步吧

[winnerczwx]

@czfy #16
这类爬虫本身就不合法, 所有绕过应用反爬措施的爬虫都是非法的(逆向, ip 代理等等)

甚至见过改 UA 都被判的案例

[Valid]

你们会被律师含的

[jr55475f112iz2tu]

@winnerczwx 有没有裁判文书可以参考一下？

[anexplore]

然儿~执~法~ 部门也需要爬虫收集数据

[ijustdo]

clickhouse

[whahuzhihao]

千万级别直接 mysql 可以啊。或者找个 clickhouse 之类的。如果要分析关系啥的，还可以上图数据库

[iluckypig]

没有更新需求的话，看看能不能处理成宽表存 clickhouse

[perpetually]

只有我想知道这抖音是怎么爬下来的么？千万级？还只有 5 个人？
能分享一下技术思路么

[winglight2016]

几千万数据量，不算大数据，不需要从这个角度考虑特别的技术架构。人-作品-评论，这种关系用 mongodb 或者 mysql 都没什么问题，查询统计可能 mongodb 支持 mapreduce 会更快一些，但是这个千万数量级做一下索引优化就够了，实在用不着针对性的设计。

另外，如果老板希望交互界面好看，你又不想自己开发，那么 es 的确最适合你。但是，仍然推荐先存到 mongodb 或 mysql，再做另外的同步程序推送到 es 。

[raptor]

大数据量用外键……贵同事看来毕业以后就没处理过大数据量吧……

[penll]

ES 是否更新不会立刻生效？
如果开启强制立刻生效的话，是否插入更新性能会下降导致堵塞？

为了实现评论立即生效，或者采用 redis 暂时缓存新增的评论？

[rust]

@czfy 企查查刚开始在苏州创立的时候有个屁投资,都是做起来之后才去找靠山的.
你现在去爬工商信息依旧没人管.

[liuidetmks]

@iiq2000 嫌弃 excel 太丑？你们这个工具是面向客户还是自己？
公司总共 5 人，2 个搞技术的
是你们公司业务太少工作量不饱和还是老板纯粹怕你们闲着？