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

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

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

es? 做宽表

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

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

查的时候都是建立索引的，两个方法应该都很快。
当然个人偏好 key-value 数据库，比较清晰。
用传统关系数据库的好处，是配套工具挺多的。

bigtable 或者上 Cassandra

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

MongoDB 可以 做好索引


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

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

好的，感谢

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

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

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

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

海量数据，统计，mongodb 能用

关键词
"爬抖音"
"老板"
"同事"
感觉又是监狱风云系列啊
没人建议离职保平安么?

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

昨天看了个 腾讯开源的 tendis ， 简单来说，就是 把 RockDB 使用 Redis 的协议暴漏出来 ， 同时支持集群(扩容)。
貌似 你的需求可以用这个 试试， 具体你可以自己看看 。

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

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

不不不，企查查之类的不一样，企查查 /天眼查 /启信宝之类的，都有 gov 相关的投资，你可以认为他们都是靠红色关系获得了免死金牌获取工商信息
针对抖音之类的爬虫，抖音肯定也清楚，就看是不是有哪一天抖音觉得这些流量以及在此至上诞生的服务对自己的利益产生了严重的负面影响，那时候它就会去起诉了。暂时来说还没到这一步

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

NewSQL
fdb-record-layer

tidb yugabyte cockroachdb

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