前往Shuct.Net首页

Shudepb PB反编译专家长时间以来,为业内同类软件事实上的唯一选择.细节,彰显专业.态度,决定品质.

关于PB反编译的搜索

数据库SQL千万级数据规模处理概要 - chengg0769 来自四川,在东莞虚度十载 - 博客频道 - CSDN.NET chengg0769 来自四川,在东莞虚度十载 PB反编译_Powerbuilder DeCompiler_PB反编译器_PB混淆器_PB加密 目录视图 摘要视图 订阅 新年新气象------CSDN2014新版导航就要跟大家见面了 2014年1月微软MVP当选名单揭晓! “我的2013”年度征文获奖名单已公布 专访宋海涛:我们在做一款比Google Glass更酷的设备 数据库SQL千万级数据规模处理概要 2009-07-09 00:14 790人阅读 评论(0) 收藏 举报 数据库sql报表存储server数据挖掘 我在前年遇到过过亿条的数据。以至于一个处理过程要几个小时的。后面慢慢优化,查找一些经验文章。才学到了一些基本方法。综合叙之,与君探讨之。 1. 数据太多。放在一个表肯定不行。 比如月周期表。一个月1000万,一年就1.2亿,如此累计下去肯定不行的。所以都是基于一个周期数据一个表。甚至一个周期数据就要分几个分表。主要是考虑实际的数据量而定。当你创建一个新表时,可能这个表需要有索引,但是都要先取消索引,或者先建立表,导入数据后,再建立索引。 必要时处理完,统计完后,就备份到磁带或者其他介质。然后清掉。 从问题域来看,一个周期内的数据关联性最大。比如统计一个客户某个帐期的话单总额,同比上月增幅,还有就是零话费客户等。如此种种,参照的数据不外乎本周期,或者两个周期,甚至更多就是一个季度,或者半年的样子(类似三个月连续零话费,或者三个月连续欠费未交之类的,保存量之类的报表可能会要一年的数据)。而且这样的情况在数据挖掘或者高级管理报表中比较常见,一般营业部门使用的界面中,是不可能含有这样的统计的。 所以数据按表分开,甚至于可以按数据库分开,更便于管理。 大家要打消一种固有的思路,这些数据,跟环卫工人处理垃圾一样,是几乎有点带人工处置的多步骤方式,也就是不会作为常规数据(如客户基本资料等)长期存在和频繁使用的。所以我们可以改变思路,就是想尽办法,在需要的时候,做最佳处理,而在不需要时,清理掉它。也就是说,比如分表,你可以分100个表,1000个表都可以。只要方便统计和得到所需数据即可。 view只是说你能在写select语句时简单一点,对速度没有任何提高。 主要是,你的分表的方式能建立减少访问所有数据,就能提高速度。比如你做某个统计,那些数据恰好在某个分表内。举例说,你有10个分部,而你统计id=1这个分部时,你恰好把数据放在第一个分表里,你就可以在存储器内通过判断,只访问第一个分表,从而提高统计速度。如果你的统计需要统计全部分表内的数据,那处理速度还是一样慢。 2. 假设每个表的数据在数十万条,那统计起来是没有任何瓶颈的。常规的数据库都应该没任何问题。 3. 预处理的必要性。 有人问:我统计一千万条数据汇总,要多久多久,能否提高。。。试想你把中国人所有的存款加总,需要多长时间吧?看看这个问题的规模,其实再复杂的数据库dbms,我们说他都逃不过:找出符合条件的数据,一条一条的加总这个计算过程。暂且不提where条件了。预处理的必要性在于,如此规模的数据处理,本身就是一个非常耗时的过程,我们有必要提前,处理其结果到一个表内,或者多个表里面。用户查询时,再显示出来。比如说1000万数据分10个分部,要看每个分部的应收增长,那我们可以预先统计数据到分部费用表中,则用户端报表显示时,就非常快。如果任何数据汇总都要从原始数据去统计,那是不现实的。所以我们可以设置原始数据表,中间结果表,结果表,汇总表,月结表,期间表之类的东西。逐步统计归属。 另外要提的是,这样的动作肯定非常耗时,而且!这样的数据如果由服务器的存储过程定期定时执行的话,处理的规模就只有一次,任何客户端,都只从结果表里产生报表。如果不用此方法,任何客户端报表都从原始数据产生,理论上是可以,但是这样的千万条数据汇总的处理会做N次。而且时间上也是不容许的。 还有,这样的统计过程最好是分开db进行存放,而公用的数据比如客户基本资料,最好拷贝一份到这个新db中来处理。这样可以不干扰到正常的使用。 可以在晚上,或者另开db或者在另外的server上跑这个过程。处理完后,写一个标志告诉主db,则客户端可以统计这些报表了。 4. 对单行数据做计算字段。举个例子,比如一条记录的产生时间是2009-01-01 12:00:00.001,如果你的统计刚好需要对某个时段进行统计,那最好增加字段,比如hour字段,下一个批处理命令下去,取得小时数,然后再统计。 5. select语句中忌讳对column做函数。因为函数将导致查询条件不走索引,而改走遍历所有数据。这样你就是查一条数据,也会遍历所有数据,那岂不是可怜。 6. 条件尽量都是数字,也就是都用id,比如分部,镇区,业务种类,接入类型,客户地址,等等,都需要用到fk方式的编码,主表里只用数字id,请记住是数字型id。整数型数字是计算最快的数据类型。如果金额极大,可以用decimal(小数=0)。varchar类型是效率很低的,不过好像有sql的md5算法,我想可以尝试这个方法(我还没试过)。 7. 索引,这个是海量数据查询首要解决的问题。 没有索引,就是遍历。索引没有覆盖到,也会走遍历。 8. 复杂的统计,用存储器做分步处理,然后得到结果,同比一条select语句实现要轻松和明白得多。 而且对表的占用时间要短得多。当然,很复杂的统计可能要用到条件判断,循环等,一条select语句是无法处理的。多层的where中的子句也是效率低,容易占用表的写法。 原则上,这里我所讨论的问题都不是那种基于网站内容管理的小case,主要对企业运用而言。比如举例说查一个“存量客户增幅表”,问题都不是简单到直接对比两个月的话费总额这么简单,还得找出之前他的话费如何,比如超过多少钱的才列入统计对象。所以,我的理解:复杂的问题,必须存储过程。真正做过几个项目才会明白,写sql语句会比编程代码还要多。真正的程序,其实是sql。 最后说一句,如果经验足够丰富,写出的统计过程,其执行时间在数分钟甚至几个小时都是正常的。所以初学者应该明白,数据量是与处理时间成正比的。如果平时处理几条数据感觉很快,数据量猛然增加几个数量级,不要认为时间上还能优化到几秒钟。 ERP里的MRP展开计算,通常能到几个小时的。这都是正常的。(主要是物料多,bom多,计算步骤太多造成) 9. 补充一点。如果数据量超过我们标题的千万级,甚至几十亿数量级。那也不存在问题,还是分而治之的思路,就是把数据在多台服务器上并行运行。就好像为灾区捐款一样,靠一个人的力量是不行的。人多力量大。类似数据分拣之类的,只需要原始数据和基本资料,还有一些计费策略之类的。完全可以分布在多台server上同时处理,也是必要的。主要根据你的数据量和单台处理的速度以及你要求的总的处理时间而决定的。有人说select语句难道也需要分布?只能说,如果确实有必要,也能做到。比如你要返回所有话单异常的数据,那也可以从每台执行检索,然后汇合到一起,我想是可以的。 10.补充二点。数据提前分拣! 举例,电话的计费数据,有钟错误是计费时长超级大,比如通话3个小时。这种基本是错误的。有可能是数据错误。所以之前碰到客户说要把计费错误的提出来。如果每次查询都要从原始表去select当然不是个好办法。所以好办法就是做必要的分拣。这样的异常数据毕竟不多。比如一个月3000条,单独放入一个table中,这样客户检索和处理时,就非常快。 一句话:提前把需要的数据过滤出来放在规定位置。 /*-----------------------------------------------------------------------------*/ 总而言之: 一。合理设计表结构,使得统计汇总最高效(包括fk设计和用数字id,不用varchar,索引设计,计算字段); 二。合理分表,使得单表数据规模适当; 三。用存储器分多个步骤处理。 四。数据预先处理和数据分拣。 五。分布在多台server上同时处理。 也就是分而治之与预处理。 更多 上一篇:一个程序员的思考 下一篇:一文钱憋死英雄汉!给Unix-Center.Net 的建议 查看评论 * 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场 核心技术类目 全部主题 Java VPN Android iOS ERP IE10 Eclipse CRM JavaScript Ubuntu NFC WAP jQuery 数据库 BI HTML5 Spring Apache Hadoop .NET API HTML SDK IIS Fedora XML LBS Unity Splashtop UML components Windows Mobile Rails QEMU KDE Cassandra CloudStack FTC coremail OPhone CouchBase 云计算 iOS6 Rackspace Web App SpringSide Maemo Compuware 大数据 aptech Perl Tornado Ruby Hibernate ThinkPHP Spark HBase Pure Solr Angular Cloud Foundry Redis Scala Django Bootstrap 个人资料 chengg0769 访问:523094次 积分:8639分 排名:第424名 原创:268篇 转载:211篇 译文:0篇 评论:348条 文章搜索 文章分类 PB反编译与加密(12) IOS和安卓(9) PB与数据库(10) 网络相关(1) 搜索相关(0) 闲话扯起耍(1) 其他语言(4) 文章存档 2014年01月(1)2013年12月(2)2013年11月(2)2013年09月(1)2013年02月(1)2012年11月(1)2012年09月(1)2012年08月(6)2012年07月(1)2012年05月(3)2012年03月(4)2011年12月(2)2011年11月(2)2011年10月(9)2011年09月(6)2011年08月(11)2011年07月(2)2011年06月(4)2011年04月(3)2010年12月(1)2010年10月(2)2010年09月(8)2010年08月(1)2010年07月(8)2010年06月(17)2010年05月(2)2010年04月(2)2010年03月(4)2010年01月(1)2009年09月(8)2009年08月(5)2009年07月(8)2009年06月(8)2009年05月(16)2009年03月(2)2009年02月(7)2008年12月(2)2008年11月(4)2008年10月(5)2008年08月(1)2008年07月(2)2008年01月(12)2007年12月(29)2007年11月(7)2007年10月(4)2007年09月(20)2007年08月(55)2007年07月(176) 阅读排行 搜索引擎学习资源(作者:dongdonglang)(14659) 做代理网站最有效的4种宣传方法(admin9.com)(12125) 再谈powerbuilder程序防止破解的办法(终结篇,以后不再写这个问题)(8183) 程序员的SEO总结(7472) 浅谈Powerbuilder的未来和Powerbuilder使用者的未来(6083) PowerBuilder DeCompiler(PB DeCompiler) Demo download(PB反编译,支持5-12)(6030) 在一台联想3000G430 T1600笔记本上安装黑苹果(东皇v10.6.3)成功(6003) PB11.5,PB12 web项目初探(5695) 文件夹加密原理 [转](5682) powerbuilder反编译器开发-第一步:pbd结构分析和pbkiller分析(5566) 评论排行 浅谈Powerbuilder的未来和Powerbuilder使用者的未来(49) 程序员的SEO总结(32) 有关Powerbuilder的悲观论和乐观论(由郭贴引发的300多贴争辩想到的,也是很久就想秉明的一个观点)(22) Powerbuilder混淆,加密(powerbuilder防止反编译,pb混淆器,PB加壳,支持5-12) obfuscator for PowerBuilder(20) 戏说DataWindow的“移植”和“临摹”(19) 因为垄断形成,数据库市场将出现更多开源数据库(19) 免费软件模式之随想(18) PB11.5,PB12 web项目初探(15) 软件提交到国外的下载站的几点操作和想法(15) 关于对pbd反编译器的期待(11) 推荐文章 最新评论 安装两个BCB6控件SynEdit、mwEdit 0.92a的过程总结 jiduxiaozhang12345: 请问BCB6的第三方控件在哪下载啊?急求 Powershield一个疑似的BUG zhj149: 高手啊,看你的文章,感觉你玩pb已经到了极致的境界了,我自认为pb还不错,和你比起来,还是差了太多了 软件提交到国外的下载站的几点操作和想法 u012353953: 楼主在吗?有个问题请教,看到请加我QQ,谢谢。17493589 Lucene(Nutch)距离商业文本搜索引擎还有多远?(转载) koubi1986: 你好!请教一些问题:请问一下1。你是如何把nutch抓取到的二进制内容,在项目中读取的。2。nutc... 看一个商业共享软件是如何在下载站刷下载量来作弊的! u011506701: 您的判断是有误的,像我研究的刷量算法你就根本看不出来,出现的曲线图跟正常的一模一样的,附:刷量是最好... 垂直搜索引擎蜘蛛的基本解决方案(编程实例:所以推荐) gis101989: 你好,我正在写面向主题搜索引擎结合地理信息的论文,很多地方不懂,能加个扣扣吗?非常感谢你的帮助,我的... 浅谈Powerbuilder的未来和Powerbuilder使用者的未来 hosthelp: PB的最大缺点就是:(其实很简单)过时了。 服装过时就没人穿了, 电器过时就没人买了, 明星过时(过... 三岁小孩开发搜索引擎,搜索引擎白热化[原创] rongzi1987: 顶一个。先顶再看 再谈powerbuilder程序防止破解的办法(终结篇,以后不再写这个问题) hua2000: 顶顶更健康正在研究反向工程 有个傻B说破解了我的软件—哈哈!黄金屋手机MP3.MP4.3GP.电影.下载系统 ljx811216: 真有这事,看看 我的未来方向 pconline/asp.net周金桥老师的aspnet 友人Blog 旧博客在sina Bluesen的语音卡开发平台 JackXu的开源语音卡框架 经验丰富的好友:杨光的专栏 蓝星际语音平台,Koodoo语言 Lucene改造者-yuetiantian 西部.阿呆's blog manesking:全文检索c/c fullfocus研究lucene,nutch 黄国酬的博客 把“天轰穿”的asp.net 雨松.安卓