V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
iiq2000
V2EX  ›  程序员

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

  •  
  •   iiq2000 · 184 天前 · 6056 次点击
    这是一个创建于 184 天前的主题,其中的信息可能已经有所发展或是发生改变。
    每个抖音作者都会有数条视频,而每条视频下又会有数条评论。估计会有数百个抖音作者,千万条评论,读写会比较频繁,可能会日增几万条或者十万条数据,老板想把这些评论信息都存到数据库(评论者抖音号、评论内容,评论时间,对应的视频 id )。

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

    同事建议用关系型数据库,把表分细一点,然后设置外键,查询的时候联合查询,如果数据量大的话,哪种方式会更好一些呢?是应该选用关系型数据库还是非关系型呢?烦请赐教。
    44 条回复    2021-06-04 22:00:55 +08:00
    czfy
        1
    czfy  
       184 天前
    查询频繁就用 ES ?
    vhysug01
        2
    vhysug01  
       184 天前
    es? 做宽表
    murmur
        3
    murmur  
       184 天前   ❤️ 3
    你们存这些东西是干嘛,需求都不说么,都有能力爬抖音了还没能力存,这啥爬虫公司
    rexyan
        4
    rexyan  
       184 天前
    抖音号和视频关系数据放 mongo,评论数据放 es 。关系型的特点你这里用不到吧,强 schema,事务... 对你来说都没用
    3dwelcome
        5
    3dwelcome  
       184 天前
    查的时候都是建立索引的,两个方法应该都很快。

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

    用传统关系数据库的好处,是配套工具挺多的。
    DollarKiller
        6
    DollarKiller  
       184 天前
    bigtable 或者上 Cassandra
    Mithril
        7
    Mithril  
       184 天前
    评论需要检索吗?不检索你直接存文件也行。
    leafre
        8
    leafre  
       184 天前
    MongoDB 可以 做好索引
    iiq2000
        9
    iiq2000  
    OP
       184 天前
    @czfy
    @vhysug01 好的,谢谢提供思路,但是不一定能用上,因为公司比较小而本人又比较菜

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


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


    @3dwelcome 好的,感谢


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


    @Mithril 需要,之前的方案是每个视频的评论存 excel 表,然后通过 excel 自带筛选功能去检索,但是老板嫌弃 excel 界面太丑,让存数据库然后做个好看的页面展示并检索
    iiq2000
        10
    iiq2000  
    OP
       184 天前
    @leafre 这样的话,每个集合对应一个抖音作者所有的视频评论信息,每个集合又包含好多评论,可能会有几千几万个集合,每个集合又包含几十万或者上百万条评论信息,结构是不是不太合理啊
    lasuar
        11
    lasuar  
       184 天前
    涉及海量数据表查询,用外键是作死
    lasuar
        12
    lasuar  
       184 天前
    海量数据,统计,mongodb 能用
    westoy
        13
    westoy  
       184 天前   ❤️ 7
    关键词
    "爬抖音"
    "老板"
    "同事"

    感觉又是监狱风云系列啊

    没人建议离职保平安么?
    ebingtel
        14
    ebingtel  
       184 天前
    最简单的存就行了……涉及到分表问题,按照抖音号存分表就可以了 没啥难度吧?
    flyingfz
        15
    flyingfz  
       184 天前
    昨天看了个 腾讯开源的 tendis , 简单来说,就是 把 RockDB 使用 Redis 的协议暴漏出来 , 同时支持集群(扩容)。

    貌似 你的需求可以用这个 试试, 具体你可以自己看看 。
    czfy
        16
    czfy  
       184 天前
    @westoy 这确实是灰色地带,主要看风向
    像飞瓜、x 瓜这种多平台爬虫做得这么成熟的,如果哪一天这类爬虫真的不合法了,这种全集团就一锅端了
    rust
        17
    rust  
       184 天前
    @czfy 不用等到"哪一天这类爬虫真的不合法",它现在就是不合法的,不过这种事情都是"民不举官不究"的.
    那些个企查查什么的,爬工商系统都没人管.
    czfy
        18
    czfy  
       184 天前
    @rust 不不不,企查查之类的不一样,企查查 /天眼查 /启信宝之类的,都有 gov 相关的投资,你可以认为他们都是靠红色关系获得了免死金牌获取工商信息

    针对抖音之类的爬虫,抖音肯定也清楚,就看是不是有哪一天抖音觉得这些流量以及在此至上诞生的服务对自己的利益产生了严重的负面影响,那时候它就会去起诉了。暂时来说还没到这一步
    james2013
        19
    james2013  
       184 天前
    使用 mysql
    作者表
    视频表
    评论表(根据视频 id 进行分表,比如分 1024 张表)
    luoqeng
        20
    luoqeng  
       184 天前
    NewSQL

    fdb-record-layer
    luoqeng
        21
    luoqeng  
       184 天前
    tidb yugabyte cockroachdb
    realpg
        22
    realpg  
       184 天前
    这点数据量 而且模型简单 任何关系数据库都没问题
    felixcode
        23
    felixcode  
       184 天前
    这点数据关系型完全没问题,哪来什么海量数据啊
    qiayue
        24
    qiayue  
       184 天前
    我们有个 mysql 表,现在六千万行数据了,每天新增一两百万条,用的就是最简单的方案,暂时没遇到瓶颈。

    我的建议是,先做先实现,后面遇到瓶颈了,再来考虑优化。
    lululau
        25
    lululau  
       184 天前
    这个量级,MySQL 就行了
    yogogo
        26
    yogogo  
       184 天前
    @czfy
    #18 灰产还是少做点,容易迷失方向。你现在这么说只是在安慰自己而已
    moen
        27
    moen  
       184 天前
    推荐用 timescaledb,既有关系型数据库本身的优点(本身就是 pg ),又能处理像这样的海量时序型数据(可以自动分表和压缩旧数据)
    ipwx
        28
    ipwx  
       184 天前
    es 不就干这种事么,而且还能做全文检索。。。多好
    wzq001
        29
    wzq001  
       184 天前
    抖音 才可能会日增几万条或者十万条数据???
    wzq001
        30
    wzq001  
       184 天前
    MySQL:你是不是看不起我???
    czfy
        31
    czfy  
       184 天前
    @yogogo 啊哈哈哈,走一步算一步吧
    winnerczwx
        32
    winnerczwx  
       184 天前
    @czfy #16
    这类爬虫本身就不合法, 所有绕过应用反爬措施的爬虫都是非法的(逆向, ip 代理等等)

    甚至见过改 UA 都被判的案例
    Valid
        33
    Valid  
       184 天前
    你们会被律师含的
    czfy
        34
    czfy  
       184 天前
    @winnerczwx 有没有裁判文书可以参考一下?
    anexplore
        35
    anexplore  
       184 天前
    然儿~执~法~ 部门也需要爬虫收集数据
    ijustdo
        36
    ijustdo  
       184 天前
    clickhouse
    whahuzhihao
        37
    whahuzhihao  
       184 天前
    千万级别直接 mysql 可以啊。或者找个 clickhouse 之类的。如果要分析关系啥的,还可以上图数据库
    iluckypig
        38
    iluckypig  
       183 天前
    没有更新需求的话,看看能不能处理成宽表存 clickhouse
    perpetually
        39
    perpetually  
       183 天前
    只有我想知道这抖音是怎么爬下来的么?千万级?还只有 5 个人?
    能分享一下技术思路么
    winglight2016
        40
    winglight2016  
       183 天前
    几千万数据量,不算大数据,不需要从这个角度考虑特别的技术架构。人-作品-评论,这种关系用 mongodb 或者 mysql 都没什么问题,查询统计可能 mongodb 支持 mapreduce 会更快一些,但是这个千万数量级做一下索引优化就够了,实在用不着针对性的设计。

    另外,如果老板希望交互界面好看,你又不想自己开发,那么 es 的确最适合你。但是,仍然推荐先存到 mongodb 或 mysql,再做另外的同步程序推送到 es 。
    raptor
        41
    raptor  
       183 天前
    大数据量用外键……贵同事看来毕业以后就没处理过大数据量吧……
    penll
        42
    penll  
       183 天前
    ES 是否更新不会立刻生效?
    如果开启强制立刻生效的话,是否插入更新性能会下降导致堵塞?

    为了实现评论立即生效,或者采用 redis 暂时缓存新增的评论?
    rust
        43
    rust  
       183 天前
    @czfy 企查查刚开始在苏州创立的时候有个屁投资,都是做起来之后才去找靠山的.
    你现在去爬工商信息依旧没人管.
    liuidetmks
        44
    liuidetmks  
       182 天前
    @iiq2000 嫌弃 excel 太丑?你们这个工具是面向客户还是自己?
    公司总共 5 人,2 个搞技术的
    是你们公司业务太少工作量不饱和还是老板纯粹怕你们闲着?
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2324 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 13:30 · PVG 21:30 · LAX 05:30 · JFK 08:30
    ♥ Do have faith in what you're doing.