3亿数据快速检索实现

　　上周有个需求，就是要做一个检索库：
　　１　３亿个手机号码，并且每个号码２０个左右的属性例：地区，订阅等信息。
　　２　在最短的时候内select出来（５分钟，１０分钟）[最重要]
　　３　允许更新。对这些号码进行发送信息后，状态改变。[可以让他慢慢更新]

　　和几个同事讨论了一下，具体要注意以下几点：
　　１　如果发送下去状态改变，但是只发送一半，但状态改变了如何办？
　　２　如果多个产品线一起下发，状态会不会混乱。
　　解决以上第二个问题，决定采用，队列等待的方式。第一个问题没想到好的解决办法，回滚也想过了，但感觉不是很现实！

　　解决方案：
　　经过实验500w条的数据在用plsql直接select，只需要０.２秒，所以总体采用分表的方式，每500w条分一个表，然后同时查询！

　　但总感觉不是很好，抛砖引玉（真的很砖 ）。不知道大家有没有更好的解决方案！



-----------------------------------------重新描述一下需求-------------------------------
很多人说需求不是很的清楚，这里重新整理了一下！
不过要注意的是数据库里已经有3亿个手机基数了！

一． 号码入库。
不定期会有新的号码需要入库，入库需要记录号码的常规属性，如：手机号，省份，城市，入库时间，手机卡类型，是否支持彩信，号码来源情况等。


二． 入库手机号源文件管理
入库手机号源文件要以文件形式保存在服务器上。

三． 按需要提取号码（最关键部分）
要按照需求提取所需的号码。

例如：
提号要求：
1.此号码非黑名单用户。
2.此号码为的订购和退订用户。
3.此号码2个月内没有活动。
4.省份要求：辽宁，云南，广东
5.号段要求：137和138和139号段
6.数量要求：每个省10w
7.是否支持彩信：是（是，否，忽略三种情况）
……

最后，符合条件的号码，按照固定格式（每个手机号占一行），形成文本文件，将此文件测试号码，是否需要状态报告等信息形成最终可发送文件并提供下载功能，同时记录本次提取信息（发送时间，发送标识等）
注：文件格式如下：
139***85185#09#0
139***71283
139***33190
第1列：手机号
第2列：产品类型（#09）
第3列：是否需要状态报告（#0）

四． 统计功能
一．号码情况统计
1.统计当前号码总量。
2.按照2个基本要求，统计现在库中可以使用的号码数量。
注：统计需要显示，全国总量，各省总量，各省省会总量，各省去除省会总量，各省7天未下发总量（省会与其他城市分开显示），各省可以发送总量（省会与其他城市分开显示，所以单独列出来）。

二．发送产品统计
1.按时间段、业务线等统计发送产品的情况，如：发送时间，最终发送文件等

五． 黑名单及特殊号码管理
1. 添加黑名单
2. 去除黑名单
3. 过滤黑名单
4. 查询黑名单

以上除黑名单外都是迫切需要的，黑名单功能可以以后完善。

评论

63 楼 dmewy 2009-05-26  

天机老人 写道

dmewy 写道

我敢说你们公司没有一个正规的DBA.
看看server的配置.建立数据加加index.看看跑多久.
你说了在PLSQL上跑的时间我只能说你很没经验.DB是oracle吗?
上线后的东西是放在什么环境?APP SERVER是什么?有没有会出现HTTP握手的情况?你有没有想到上线后网络连接的问题?这些都会再加慢速度.
第一条是DB的隔离级别.每个connection设置一下就好了.会牵扯到dead lock.
每个DB的隔离级别含义都不一样.
第二个业务不懂.不知什么意思.
其实.基本上你这种情况很少会出现,应该从需求上出发.避免大数据让用户区查.比如限制它查询的范围.半年前的数据就不显示之类的.你要搞清楚需求,看看用户到底想看到的是什么.不要老板说了什么你就傻去做.基本上正规来说.一些大数据的表每一年都会做一次备份.做成view去select.
分表的解决方案没考虑到数据量继续增大以后怎么维护和备份.按照什么切?这个标准以后再增加维护起来就痛苦了.

完了，难道是我表达问题很多人都没看懂！

的确是的.你要把整个需求说清楚.你这个问题最好是从需求入手.
不要你就是说放一个表里面3亿条数据.怎么查的快.我觉得做这种事情是没意义的.
你们是根据什么去查的?单表还是多表?
查找的时候根据业务需求的不同会有很多小技巧的.你写的太模糊了.
比如说.by user去查的话. user在你那个3亿表中肯定不是一对一的吧?
你那个3亿表放的你只说了放手机号码.结构是怎样的?是by 什么去查的?
SQL的写法上有很多技巧的.比如小表链接大表.index的加法? 多看看excution plan.
肯定有很多废资料.要定期清除的.
你不说清楚需求,这块去哪入手呢?
出发点是怎么避免大数据的查询.
你们这个玩意当初是谁设计的?
设计的时候考虑到了吗?

62 楼 GT07 2009-05-26  

jichongchong 写道

我们用了hash+文件+内存，没用关系数据库，用户属性都是动态的-_-！

这种方案之前我们都讨论过，你们是怎么实现复杂查询的？

61 楼 天机老人 2009-05-26  

dmewy 写道

我敢说你们公司没有一个正规的DBA.
看看server的配置.建立数据加加index.看看跑多久.
你说了在PLSQL上跑的时间我只能说你很没经验.DB是oracle吗?
上线后的东西是放在什么环境?APP SERVER是什么?有没有会出现HTTP握手的情况?你有没有想到上线后网络连接的问题?这些都会再加慢速度.
第一条是DB的隔离级别.每个connection设置一下就好了.会牵扯到dead lock.
每个DB的隔离级别含义都不一样.
第二个业务不懂.不知什么意思.
其实.基本上你这种情况很少会出现,应该从需求上出发.避免大数据让用户区查.比如限制它查询的范围.半年前的数据就不显示之类的.你要搞清楚需求,看看用户到底想看到的是什么.不要老板说了什么你就傻去做.基本上正规来说.一些大数据的表每一年都会做一次备份.做成view去select.
分表的解决方案没考虑到数据量继续增大以后怎么维护和备份.按照什么切?这个标准以后再增加维护起来就痛苦了.

完了，难道是我表达问题很多人都没看懂！

60 楼 dmewy 2009-05-26  

我敢说你们公司没有一个正规的DBA.
看看server的配置.建立数据加加index.看看跑多久.
你说了在PLSQL上跑的时间我只能说你很没经验.DB是oracle吗?
上线后的东西是放在什么环境?APP SERVER是什么?有没有会出现HTTP握手的情况?你有没有想到上线后网络连接的问题?这些都会再加慢速度.
第一条是DB的隔离级别.每个connection设置一下就好了.会牵扯到dead lock.
每个DB的隔离级别含义都不一样.
第二个业务不懂.不知什么意思.
其实.基本上你这种情况很少会出现,应该从需求上出发.避免大数据让用户区查.比如限制它查询的范围.半年前的数据就不显示之类的.你要搞清楚需求,看看用户到底想看到的是什么.不要老板说了什么你就傻去做.基本上正规来说.一些大数据的表每一年都会做一次备份.做成view去select.
分表的解决方案没考虑到数据量继续增大以后怎么维护和备份.按照什么切?这个标准以后再增加维护起来就痛苦了.

59 楼 抛出异常的爱 2009-05-26  

天机老人 写道

机器只会有一台。不用考虑多台机器的事情！
公司要的就是价值最大化！不然这个活也不会交到我们手里了！

放文件里吧....
不同的属性不同的文件夹.
规则成树状
大量的移动使用文件move
少量的移动把文件中对应的手机号删除新建.

58 楼 天机老人 2009-05-26  

机器只会有一台。不用考虑多台机器的事情！
公司要的就是价值最大化！不然这个活也不会交到我们手里了！

57 楼 LargeBean 2009-05-26  

按号段或号码的前几位分表，例如表名：t_139101,操作拼sql的时候，根据号码前几位，可以拼出表名。
可能会建的表多一些，看拆的粒度了

56 楼 hatedance 2009-05-26  

这种数量巨大的东西，我是一点概念都没有。
不管是3亿还是300亿。反正一台奔四是搞不定的。
所以出路是2条。一是买台深蓝。二是学google，买N台pc。
建议分布式，集群吧。用N台机器总是能解决的。N<=3亿。

55 楼 jichongchong 2009-05-26  

我们用了hash+文件+内存，没用关系数据库，用户属性都是动态的-_-！

54 楼 wlvfox 2009-05-25  

看的你的问题 我想到一个用CPU和内存 换取数据库速度的方法 不知道各位高人如何看？
方法是这样的。。。。
你把UPDATE分成100或者更多的条数一起更新，这个条数你要自己研究出一个效率与速度最合理的值了。在更新前是要发送数据吧？然后根据网关的回复挑选出没有执行成功的条，剔出UPDATE的集合中，放到另一个集合里去。如此UPDATE的内容将不会存在没有发送成功的，同时保存了需要重新发送信息的条目。但是由于可能出现如中途中断等情况，所以具体实施的时候需要考虑到这点问题的处理。额。。。不知道是否可行？大家讨论下吧 办法很笨 哈哈

53 楼 Xsen 2009-05-25  

不分表做的话性能肯定有问题
根据号段分表，根据业务逻辑分为字段不更新的表和字段要更新的表
查询时使用搜索引擎，更新时根据手机号这个索引更新

52 楼 天机老人 2009-05-25  

phpxer 写道

天机老人 写道

　　上周有个需求，就是要做一个检索库：
　　１　３亿个手机号码，并且每个号码２０个左右的属性例：地区，订阅等信息。
　　２　在最短的时候内select出来（５分钟，１０分钟）[最重要]
　　３　允许更新。对这些号码进行发送信息后，状态改变。[可以让他慢慢更新]

　　和几个同事讨论了一下，具体要注意以下几点：
　　１　如果发送下去状态改变，但是只发送一半，但状态改变了如何办？
　　２　如果多个产品线一起下发，状态会不会混乱。
　　解决以上第二个问题，决定采用，队列等待的方式。第一个问题没想到好的解决办法，回滚也想过了，但感觉不是很现实！

　　

select 到底 根据什么条件 select？ 如果只是手机号就好办了，时间可以限制在毫秒级。更新问题不大，直接用文件，按手机号做个一级索引就可以了。

当然不会那么简单！是用各种条件的组合！

51 楼 phpxer 2009-05-25  

laiseeme 写道

3亿条 方到文件里面会不会很大？

测试了下， 2亿条 大概是 12G。

50 楼 GT07 2009-05-25  

我之前处理过批数据跟楼主差不多，是2亿多个手机号码，跟楼主有点区别在于，我们的数据只需要查询，而不需要插入或修改数据，因此好办许多。在这里提出两个看法：
首先，分表是可行的，但是个人不赞成采用地区分表。原因在于，全国各省市的手机用户分布不均匀，用这个办法分表的话，会造成表与表之间数据不均匀，比如西部的省市的表会很小，而东部沿海省市的表会很大，甚至几千万，所以采用地区分表个人认为效率有限，达不到目的。如果是分表，还是建议hash的方式。
其次，如果只是查询，建议楼主采用一些如lucene，sphinx之类的全文检索的程序，我们的处理就是采用sphinx做索引，响应的时间很快，整个查询可以控制在毫秒。

49 楼 phpxer 2009-05-25  

天机老人 写道

　　上周有个需求，就是要做一个检索库：
　　１　３亿个手机号码，并且每个号码２０个左右的属性例：地区，订阅等信息。
　　２　在最短的时候内select出来（５分钟，１０分钟）[最重要]
　　３　允许更新。对这些号码进行发送信息后，状态改变。[可以让他慢慢更新]

　　和几个同事讨论了一下，具体要注意以下几点：
　　１　如果发送下去状态改变，但是只发送一半，但状态改变了如何办？
　　２　如果多个产品线一起下发，状态会不会混乱。
　　解决以上第二个问题，决定采用，队列等待的方式。第一个问题没想到好的解决办法，回滚也想过了，但感觉不是很现实！

　　

select 到底 根据什么条件 select？ 如果只是手机号就好办了，时间可以限制在毫秒级。更新问题不大，直接用文件，按手机号做个一级索引就可以了。

48 楼 cauherk 2009-05-25  

自始自终我没看懂需求。
１、３亿个手机号码，并且每个号码２０个左右的属性例：地区，订阅等信息。
3亿的数据量只能说还行，不是特别大，但是已经很大了。
２、在最短的时候内select出来（５分钟，１０分钟）[最重要]
这个是什么意思？是不是要对某些地区的用户，订购了某项产品的人，发送指定的信息？
还是其他意思？
３、允许更新。对这些号码进行发送信息后，状态改变。[可以让他慢慢更新]
这么多纪录发送一遍就完了？以后再想发送怎么办？再导入3亿条纪录？

我个人觉得，就这些数据，要干这些事。首先取决于你的业务需求，其次取决于设备，然后再取决于怎么做。如果就一台普通设备，无论怎么优化和设计都无计可施，分库更是瞎扯。还有好多如果，都是瞎猜，还是要列出相对细的业务需求和设备。

47 楼 kunee 2009-05-25  

LZ在 asiainfo 还是？

46 楼 天机老人 2009-05-25  

wangzy 写道

垃圾短信就是这么来的？

郁闷我们可不发垃圾短信的！
是定制用户信息更新！

45 楼 wangzy 2009-05-25  

垃圾短信就是这么来的？

44 楼 laiseeme 2009-05-25  

索引后也就是查询快了
但是人家还要更新呢