比如: 电影资源有 10 亿级别,电影标签有 1000 个( eg:武侠,言情,剧情,悬疑, 90 年代...), 每个电影有不确定个标签
用户检索的时候,可能会点选不确定个标签,这样的场景在实际生产中如何处理
1
murmur 2018-02-16 20:35:28 +08:00
有十亿部电影那么多么
|
4
l30n 2018-02-16 20:43:34 +08:00 via Android
有类似如何进行取样,模糊处理后在小规模数据上进行操作的论文。
|
5
gouchaoer 2018-02-16 20:46:21 +08:00 via Android
电影本身真有 10 亿可以分表,后期流量太大上 tidb,检索上 es 吧,用数据库不现实。。。因为一个标签对应很多电影,你肯定要按照某一规则排序
|
6
thomaswang OP @murmur 你这么较真,那我把电影改成文章吧
|
7
murmur 2018-02-16 20:49:39 +08:00 2
@thomaswang 不 这种大数据肯定要具体分析的
比如你没提到的: 1、精确度如何,可以漏数据么 2、并发,不谈并发谈大数据都是耍流氓 3、数据更新速度如何,要求某些数据实时刷新么 4、每条数据的数据量如何 就你那个电影的例子,热 tag 缓存 新 tag 人工审核(放你大天朝带审核才是合理业务设计) 再加上电影爱好者的维护 tag 能命中老高的缓存了 |
8
wqzjk393 2018-02-16 20:52:25 +08:00 via iPhone
加大服务器集群配置…我千万级别的数据,查询时候只要带个 where 就要几分钟了,加一点运算就要几个小时了。觉得表再怎么设计,对付大数据量都是没啥用
|
9
thomaswang OP 各位老铁,我想表达的是,数据量大一点的,不定个标签搜索,表怎么设计,外加什么软件(es)来提高搜索速度, 这是多年以前的一个面试题目,当时面的是 web 开发,那家公司给了 15k,没有去,我不知道这个题目好一点的答案
|
10
guoer 2018-02-16 21:02:17 +08:00
10 亿也不多呀。es 多个节点即可。说到底还是得看具体需求。
|
11
murmur 2018-02-16 21:04:17 +08:00 1
@thomaswang 这还真不好回答
刚才我去时光网看了一下 时光网 2017 年电影的主键才到 2x xxxx 导演多一点 到 100 多 w 了 虽然不知道是不是乱编或者漏了多少数据 但是用电影做例子显然还不够大数据的考点 所以才要求你具体的场景 另外很聪明的时光网貌似没自定义 tag 音乐的量大一点但是网易云也没 tag 所以似乎大家都很聪明的回避了这个问题 |
12
nandaye 2018-02-16 21:13:44 +08:00 via Android 2
以 oracle 为例,先对标签分类放不同列很有必要,大多数数据库做模糊搜索效率都比较差,比如年代 tag1,类型 tag2,国家 tag3 等等,然后 tag 加位图索引,必选的 tag 可以直接 partition 分区,问题不大应该。我 3 亿多数据加唯一索引查询零点几秒出结果
|
13
ebony0319 2018-02-16 21:21:48 +08:00 via Android
电影信息主表,便签主表,另外一个表记录便签与电影信息的关系。分表加索引,查询肯定是分页的。一页二十条应该也很快的。
|
15
sagaxu 2018-02-16 21:30:20 +08:00
@thomaswang 才 15K ?这个问题解决好了,至少值 50K 以上。
|
16
izhangzhihao 2018-02-16 21:40:55 +08:00 via Android
图数据库
|
17
3a3Mp112 2018-02-16 21:44:51 +08:00
其实这不是单纯的表设计问题了, 是大数据的问题。
|
18
doubleflower 2018-02-16 21:56:31 +08:00 via Android
@wqzjk393 你没做索引而已
|
19
feverzsj 2018-02-16 21:59:43 +08:00
10 亿单表还是能处理的,用 clustered index,或者升级下硬件吧
|
20
alcarl 2018-02-16 22:17:18 +08:00 via Android
应该需要 elastic 了,传统 sql 数据库玩不转
|
23
bzzhou 2018-02-16 22:21:45 +08:00 1
如果仅仅是满足各种标签的组合的检索,而不考虑 ranking 的情况
那么直接利用 bitmap 倒排拉链即可 10 亿电影,每个电影从 0 自增分配 id ;然后每个标签,用一个包含 10 亿个 bit 的 bitmap 来表示是否包含某部电影。 每个标签的存储开支:1,000,000,000bit,大概 120M 的存储空间 那么 1000 个标签,理论上需要 120G 的存储空间 至于检索的性能,如果数据可以全部落入到内存中,那么几个标签的过滤,基本都是 10ms 级别 如果要落入磁盘,那么多准备几块 SSD 也可以 PS:估计 ES 在这个场景下,哪怕单节点,性能也不会差(前提是关闭 ranking ) |
24
lance6716276 2018-02-16 22:31:35 +08:00 via Android
一年前 tidb 的学长给过我们一个某软件的 alpha 版,已经记不清了,做复杂运算测试的时候千万行还是秒级,估计现在 tidb 也可以了吧
|
27
nandaye 2018-02-16 22:49:34 +08:00 via Android
@alcarl 传统数据库比你想的可能还是强不少的,where 条件多个没问题的,电影标签的分类没多少可分的
|
28
cnbattle 2018-02-16 22:52:56 +08:00 via Android
@thomaswang 一般这个得具体自身实际业务场景设计,不管数据库还是代码都得量身设计,V 友们要么根据你举得例子的理解说说,要么就是一个同通用的想法,别想着有怎样一个完整通用的方法,还是得根据具体自身实际业务场景来
|
31
Daming 2018-02-17 08:24:01 +08:00
做好分区+索引
|
32
ycz0926 2018-02-17 14:52:20 +08:00
@thomaswang 倒让我想起了一次面试,面我的人问的也是一个类似的问题,我回答说,分库、分表、缓存、再不然上集群……
可最后,他说我得考虑业务方面 这种问题,似乎不如问算法、cs 领域的理论来的贴切,这种问题不管你怎么答,都是每个准的,这个收敛的结果,只把握在问你的人手里 |
33
ycz0926 2018-02-17 14:53:53 +08:00
还有一个就是,看面的岗位吧,你说要是一个 php 的 dev,问这种问题,是去做 TL、做架构么?还是让我兼职 DBA 呢 。。。😅
|
34
cjyang1128 2018-02-17 17:14:00 +08:00
列一下方案:
1、自己做分库分表 2、分布式数据库:Tidb 或者阿里云的某些产品比如 DRDS 或者 Petadata ;或者也可以调研一下 Greenplum,分布式的 pgsql 3、搜索引擎:Solr 或者 ES 4、NoSQL 类型比如 HBase 1、2 数据可以平滑迁移,但是 3、4 需要较多的重构。我感觉你这个场景 HBase 应该可以完美 hold。如果公司没有 HBase 运维经验的话,可以考虑采购 HBase 的云产品。 另外比较好奇的是,如果你这个是按标签的搜索场景的话,你们目前通过一张 tag_id_to_movie_id 这张关系表来 select 吗? |