|
锁定老帖子 主题：3亿数据快速检索实现
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-05-25
neora 写道 caiceclb 写道 考虑使用LDAP怎么样。。。。
LDAP不适合模糊查询，如果是根据固定的号码精确的查出一条是非常快的，当然要看你的BackEnd是什么？如果BackEnd就是Oracle或者Mysql那么查询的速度自然跟数据库表的查询速度一样喽。 但致命的问题是update，如果update的量大，速度非常非常慢。 肯定不会是一个线程在update啦，当然是好几个在疯狂的update |
| 返回顶楼 | |
|
发表时间：2009-05-25
0.2秒
在点下那个 V v - 按钮呢 |
| 返回顶楼 | |
|
发表时间：2009-05-25
关系数据库？那你等4吧
|
| 返回顶楼 | |
|
发表时间：2009-05-25
楼主您的手机资料是哪里买的？
|
| 返回顶楼 | |
|
发表时间：2009-05-25
楼主是央视的吧？
这样的DB设计，要根据业务流程定。3亿条放到一个表里，还要select+update是有点不现实。 1. 每条数据有20几个属性：把这些属性再分成小表吧。 2. 3亿条数据，可以根据号段（省属/运营商）放到不同的表中。 3. 发送后更新，还有一个中间状态，就是等状态报结ing；可以分成三种表：待发表，等回复表，己收到状态报告表。这样就可以用多线程+消息队列处理不同的表。 4. 多个产品线一起要发：每个产品线应有自己的业务表。 5. 真正的问题可能是：你接什么样的通信接口能短时（一天内）发3亿个手机号的信息？先看你通信的峰值再确定瓶颈是否在DB上? 6.实在不行，整内存DB吧。 |
| 返回顶楼 | |
|
发表时间：2009-05-25
这种需求在移动BOSS里很常见，解决无非2种
1 分表，按号段分，比如百万或者千万号段一个表 2 文件操作 楼主的需求不是很复杂，建议存在文件里面，存取都很快，文件也可以按号段来分多个小文件。 |
| 返回顶楼 | |
|
发表时间：2009-05-25
3亿条 方到文件里面会不会很大？
|
| 返回顶楼 | |
|
发表时间：2009-05-25
一般说来是文件快 还是数据库快？有大侠做过实验没？
|
| 返回顶楼 | |
|
发表时间：2009-05-25
要启用特殊的索引吧？
|
| 返回顶楼 | |
|
发表时间：2009-05-25
天机老人 写道 上周有个需求，就是要做一个检索库：
１ ３亿个手机号码，并且每个号码２０个左右的属性例：地区，订阅等信息。 ２ 在最短的时候内select出来（５分钟，１０分钟）[最重要] ３ 允许更新。对这些号码进行发送信息后，状态改变。[可以让他慢慢更新] 和几个同事讨论了一下，具体要注意以下几点： １ 如果发送下去状态改变，但是只发送一半，但状态改变了如何办？ ２ 如果多个产品线一起下发，状态会不会混乱。 解决以上第二个问题，决定采用，队列等待的方式。第一个问题没想到好的解决办法，回滚也想过了，但感觉不是很现实！ 解决方案： 经过实验500w条的数据在用plsql直接select，只需要０.２秒，所以总体采用分表的方式，每500w条分一个表，然后同时查询！ 但总感觉不是很好，抛砖引玉（真的很砖  ）。不知道大家有没有更好的解决方案！先垂直切分、再水平切分 |
| 返回顶楼 | |
