这是一个创建于 1640 天前的主题，其中的信息可能已经有所发展或是发生改变。
每个抖音作者都会有数条视频，而每条视频下又会有数条评论。估计会有数百个抖音作者，千万条评论，读写会比较频繁，可能会日增几万条或者十万条数据，老板想把这些评论信息都存到数据库（评论者抖音号、评论内容，评论时间，对应的视频 id ）。
我目前想到的是存到 MongoDB，每一个作者抖音号是一个集合名字，集合里就是这个作者下所有视频的评论（每条评论里会包含对应的视频 id ）；
同事建议用关系型数据库，把表分细一点，然后设置外键，查询的时候联合查询，如果数据量大的话，哪种方式会更好一些呢？是应该选用关系型数据库还是非关系型呢？烦请赐教。
我目前想到的是存到 MongoDB，每一个作者抖音号是一个集合名字，集合里就是这个作者下所有视频的评论（每条评论里会包含对应的视频 id ）；
同事建议用关系型数据库，把表分细一点，然后设置外键，查询的时候联合查询，如果数据量大的话，哪种方式会更好一些呢？是应该选用关系型数据库还是非关系型呢？烦请赐教。
 | 1 jr55475f112iz2tu 2021-06-03 10:02:01 +08:00 查询频繁就用 ES ? |
 | 2 vhysug01 2021-06-03 10:02:25 +08:00 es? 做宽表 |
 | 3 murmur 2021-06-03 10:03:53 +08:00  3 你们存这些东西是干嘛，需求都不说么，都有能力爬抖音了还没能力存，这啥爬虫公司 |
 | 4 rexyan 2021-06-03 10:12:30 +08:00 抖音号和视频关系数据放 mongo，评论数据放 es 。关系型的特点你这里用不到吧，强 schema，事务... 对你来说都没用 |
 | 5 3dwelcome 2021-06-03 10:13:54 +08:00 查的时候都是建立索引的，两个方法应该都很快。 当然个人偏好 key-value 数据库，比较清晰。 用传统关系数据库的好处，是配套工具挺多的。 |
| 6 py88pQ2hZ7PJw0v4 2021-06-03 10:15:21 +08:00 bigtable 或者上 Cassandra |
 | 7 Mithril 2021-06-03 10:47:38 +08:00 评论需要检索吗？不检索你直接存文件也行。 |
 | 8 leafre 2021-06-03 11:29:37 +08:00 MongoDB 可以 做好索引 |
 | 9 iiq2000 OP @czfy @vhysug01 好的，谢谢提供思路，但是不一定能用上，因为公司比较小而本人又比较菜 @murmur 老板是想从特定类型账号的视频评论里找出意向客户的，所以需要存评论然后检索，公司是个小公司，加上老板总共五个人，我和另外一个同事搞技术的，比较菜，确实对于怎么存没有什么好主意 @rexyan 确实不知道 es 还能存数据，只知道能搜索，我再搜索下用法 @3dwelcome 好的，感谢 @DollarKiller 感谢回复，但是大概率不会用 @Mithril 需要，之前的方案是每个视频的评论存 excel 表，然后通过 excel 自带筛选功能去检索，但是老板嫌弃 excel 界面太丑，让存数据库然后做个好看的页面展示并检索 |
| 10 iiq2000 OP @leafre 这样的话，每个集合对应一个抖音作者所有的视频评论信息，每个集合又包含好多评论，可能会有几千几万个集合，每个集合又包含几十万或者上百万条评论信息，结构是不是不太合理啊 |
 | 11 lasuar 2021-06-03 13:45:44 +08:00 涉及海量数据表查询，用外键是作死 |
| 12 lasuar 2021-06-03 13:47:55 +08:00 海量数据，统计，mongodb 能用 |
 | 13 westoy 2021-06-03 13:48:20 +08:00 7 关键词 "爬抖音" "老板" "同事" 感觉又是监狱风云系列啊 没人建议离职保平安么? |
 | 14 ebingtel 2021-06-03 13:49:35 +08:00 最简单的存就行了……涉及到分表问题，按照抖音号存分表就可以了 没啥难度吧？ |
 | 15 flyingfz 2021-06-03 14:42:09 +08:00 昨天看了个 腾讯开源的 tendis ， 简单来说，就是 把 RockDB 使用 Redis 的协议暴漏出来 ， 同时支持集群(扩容)。 貌似 你的需求可以用这个 试试， 具体你可以自己看看 。 |
| 16 jr55475f112iz2tu 2021-06-03 14:50:02 +08:00 @westoy 这确实是灰色地带，主要看风向 像飞瓜、x 瓜这种多平台爬虫做得这么成熟的，如果哪一天这类爬虫真的不合法了，这种全集团就一锅端了 |
 | 17 rust 2021-06-03 14:55:07 +08:00 @czfy 不用等到"哪一天这类爬虫真的不合法",它现在就是不合法的,不过这种事情都是"民不举官不究"的. 那些个企查查什么的,爬工商系统都没人管. |
| 18 jr55475f112iz2tu 2021-06-03 15:00:08 +08:00 @rust 不不不，企查查之类的不一样，企查查 /天眼查 /启信宝之类的，都有 gov 相关的投资，你可以认为他们都是靠红色关系获得了免死金牌获取工商信息 针对抖音之类的爬虫，抖音肯定也清楚，就看是不是有哪一天抖音觉得这些流量以及在此至上诞生的服务对自己的利益产生了严重的负面影响，那时候它就会去起诉了。暂时来说还没到这一步 |
 | 19 james2013 2021-06-03 15:11:31 +08:00 使用 mysql 作者表 视频表 评论表(根据视频 id 进行分表,比如分 1024 张表) |
 | 20 luoqeng 2021-06-03 15:16:29 +08:00 NewSQL fdb-record-layer |
| 21 luoqeng 2021-06-03 15:27:53 +08:00 tidb yugabyte cockroachdb |
 | 22 realpg PRO 这点数据量 而且模型简单 任何关系数据库都没问题 |
 | 23 felixcode 2021-06-03 16:46:01 +08:00 这点数据关系型完全没问题，哪来什么海量数据啊 |
 | 24 qiayue PRO 我们有个 mysql 表，现在六千万行数据了，每天新增一两百万条，用的就是最简单的方案，暂时没遇到瓶颈。 我的建议是，先做先实现，后面遇到瓶颈了，再来考虑优化。 |
 | 25 lululau 2021-06-03 16:55:33 +08:00 这个量级，MySQL 就行了 |
 | 27 moen 2021-06-03 17:09:36 +08:00 推荐用 timescaledb，既有关系型数据库本身的优点（本身就是 pg ），又能处理像这样的海量时序型数据（可以自动分表和压缩旧数据） |
 | 28 ipwx 2021-06-03 17:13:48 +08:00 es 不就干这种事么，而且还能做全文检索。。。多好 |
 | 29 wzq001 2021-06-03 17:25:59 +08:00 抖音 才可能会日增几万条或者十万条数据？？？ |
| 30 wzq001 2021-06-03 17:26:29 +08:00 MySQL：你是不是看不起我？？？ |
| 31 jr55475f112iz2tu 2021-06-03 17:32:56 +08:00 @yogogo 啊哈哈哈，走一步算一步吧 |
 | 32 winnerczwx 2021-06-03 17:58:33 +08:00 |
 | 33 Valid 2021-06-03 18:00:59 +08:00 你们会被律师含的 |
| 34 jr55475f112iz2tu 2021-06-03 18:12:59 +08:00 @winnerczwx 有没有裁判文书可以参考一下？ |
 | 35 anexplore 2021-06-03 18:32:37 +08:00 然儿~执~法~ 部门也需要爬虫收集数据 |
 | 36 ijustdo 2021-06-03 18:38:53 +08:00 clickhouse |
 | 37 whahuzhihao 2021-06-03 18:44:01 +08:00 千万级别直接 mysql 可以啊。或者找个 clickhouse 之类的。如果要分析关系啥的，还可以上图数据库 |
 | 38 iluckypig 2021-06-03 21:34:55 +08:00 没有更新需求的话，看看能不能处理成宽表存 clickhouse |
 | 39 ByteMind 2021-06-04 00:02:13 +08:00 只有我想知道这抖音是怎么爬下来的么？千万级？还只有 5 个人？ 能分享一下技术思路么 |
 | 40 winglight2016 2021-06-04 09:05:09 +08:00 几千万数据量，不算大数据，不需要从这个角度考虑特别的技术架构。人-作品-评论，这种关系用 mongodb 或者 mysql 都没什么问题，查询统计可能 mongodb 支持 mapreduce 会更快一些，但是这个千万数量级做一下索引优化就够了，实在用不着针对性的设计。 另外，如果老板希望交互界面好看，你又不想自己开发，那么 es 的确最适合你。但是，仍然推荐先存到 mongodb 或 mysql，再做另外的同步程序推送到 es 。 |
 | 41 raptor 2021-06-04 09:19:12 +08:00 大数据量用外键……贵同事看来毕业以后就没处理过大数据量吧…… |
 | 42 penll 2021-06-04 10:09:17 +08:00 ES 是否更新不会立刻生效？ 如果开启强制立刻生效的话，是否插入更新性能会下降导致堵塞？ 为了实现评论立即生效，或者采用 redis 暂时缓存新增的评论？ |
 | 44 liuidetmks 2021-06-04 22:00:55 +08:00 |
Select Language