惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

S
Security Affairs
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Jina AI
Jina AI
P
Palo Alto Networks Blog
GbyAI
GbyAI
大猫的无限游戏
大猫的无限游戏
A
Arctic Wolf
Hugging Face - Blog
Hugging Face - Blog
小众软件
小众软件
Y
Y Combinator Blog
T
The Blog of Author Tim Ferriss
Blog — PlanetScale
Blog — PlanetScale
S
Schneier on Security
V
Vulnerabilities – Threatpost
C
Cybersecurity and Infrastructure Security Agency CISA
雷峰网
雷峰网
T
Tenable Blog
人人都是产品经理
人人都是产品经理
T
Tor Project blog
C
Cyber Attacks, Cyber Crime and Cyber Security
AWS News Blog
AWS News Blog
Microsoft Security Blog
Microsoft Security Blog
J
Java Code Geeks
Scott Helme
Scott Helme
SecWiki News
SecWiki News
C
CERT Recently Published Vulnerability Notes
Recorded Future
Recorded Future
I
InfoQ
Security Archives - TechRepublic
Security Archives - TechRepublic
Help Net Security
Help Net Security
Cloudbric
Cloudbric
C
Check Point Blog
Engineering at Meta
Engineering at Meta
TaoSecurity Blog
TaoSecurity Blog
B
Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
博客园_首页
N
News and Events Feed by Topic
云风的 BLOG
云风的 BLOG
MyScale Blog
MyScale Blog
腾讯CDC
量子位
Application and Cybersecurity Blog
Application and Cybersecurity Blog
K
Kaspersky official blog
Vercel News
Vercel News
F
Full Disclosure
T
Troy Hunt's Blog
Forbes - Security
Forbes - Security
S
Security @ Cisco Blogs

博客园 - 三颗纽扣

windows下安装redmine-2.1 try-cache-finally 在线程被杀掉时还有作用吗? Hibernate乐观锁真的会抛出异常吗? 并非文学化编程,在VS环境下的折中方案 快速复制NuGet引用 语义版本规范 基础框架的基础组件 在 IIS 6 上架设 NuGet Server DotNet开发利器之MyEclipseShortcuts 通过 POI 获取图片在 Excel 表格中的位置 我们是原始生物 没有别的,只有天使 灯是用来照亮的,而不是引路的 戒了,过去完成时 我送给你们的,没有别的——只有天使。 Builder 链——另类一点的Builder模式 多线程JUnit单元测试:GroboUtils and ConTest 控制内存的使用之二:对象缓存 pool and cache 控制内存的使用
使用InfoBright实现20-100亿条原始话单记录的检索
三颗纽扣 · 2012-10-19 · via 博客园 - 三颗纽扣

Oracle虽然很强大,但是遇到在20-100亿条原始话单记录中根据电话号码以及日期进行记录检索这样简单的查询需求时,依然由于数据量巨大而不得不退居二线了。当然在这个应用场景中,显然都不是Oracle等传统关系数据库的强项——数据量数十亿条以上,每天增量数TB,数据都是百万条为单位导入而不是一条条插入,不需要对数据进行任何的修改,数据完整性、事务性需求基本没有,而这些,恰恰是 InfoBright 这种列数据库的强项。

以前应用采用的ORACLE方案,在2亿条记录的情况下,即使数据分表再分区的情况下,要检索一个电话号码也需要十秒的查询时间,在验证了把前台迁移到InfoBright的可行性以后,看看具体在大数据量下 IB 的表现如何,结果让人很是意外和兴奋。

导入 27 亿条记录(相当于10天的话单):费时 2.5小时

执行通常的前端展现查询:select * from t where imsi=xxxxxxx and dt >xxxx and dt<xxxxx limit 30 offset 60; 费时 0.1-0.6 秒

执行全部记录提取:select count(*) from t where imsi=xxxxxxx and dt >xxxx and dt<xxxxx;统计出有 300万记录时,也不过 6-10秒