精华内容
下载资源
问答
  • 数据库选型

    2016-08-31 17:14:00
    主要还是看后期数据分析的复杂度,如果需要做多表关联统计分析,mysql 上千万的数据分析起来就比较吃力了,此种场景甲骨文是最推荐的。mongodb 太消耗内存,其实不太适合olap 场景的,分析起来比较麻烦,简单事务...

     

    主要还是看后期数据分析的复杂度,如果需要做多表关联统计分析,mysql 上千万的数据分析起来就比较吃力了,此种场景甲骨文是最推荐的。
    mongodb 太消耗内存,其实不太适合olap 场景的,分析起来比较麻烦,简单事务处理还行。
    。未来如果数据量上去了,再考虑重型武器hbase ,但要知道它只是你ods的补充,别想它能完全取代你的ods。
    题主更多的应该是构建ods 短期内mysql 可以快速满足需求

     

    500w不大 也谈不上要到分布式
    建好索引 MySQL还能再战五百年

     


    500W级别,用infobright最合适,列式存储,如果列中重复数据多,压缩比还可以最高可以到10倍。
    另外,你的mysql同步的数据可以这么搞, 搞一个备库同步文件使用ROW的方式
    binlog_format="ROW"
    
    的方式,就是每一条记录对应着一行, 然后实时解析下,接入你的infobright. 当然如果数据量大,可以写个mapreduce将这部分增量数据与全量数据merge下形成快照。
    另外500W的数据,单条算1K,才5G,直接单机用python都可以搞定。如果需求简单,甚至可以用grep -F -mmap 来搞定

    个人觉得mysql足矣,按照每天5万的量计算,两年也不算很大,mysql还可以支持,而从成本来看,集群搭建至少超过5台机器(好寒酸 ),集群太小也没有意义。此外,hbase对key-value类型的场景支持较好,其他的效果没这么显著。有道是强扭的瓜不甜,适合的才是最好的

    现在需要做一个数据存储,500w左右的数据,日后每天大约产生5w条左右的数据。想把这些数据存储起来,供日后的数据分析用?使用上面说的三种数据库中的哪中比较好?是否有必要建立集群?

    个人看法是:从长远角度看,由于单台机器的性能瓶颈,后期肯定要做集群,单纯的做复制最终也无法缓解单台master上读的负担。因此,使用mysql的话会使用cluser。但是了解到mysql的cluser要用好的化还要做负载均衡,而mysql的均衡器是第三方的,无法很好的与mysql整合。使用mongodb的自动分片集群能很好的解决这个问题,而且它的读写性能也快。Hbase提供了大数据存储的解决方案。

    回到我问题,最终是要在大数据的基础上做数据分析,虽然mongodb也能与Mapreduce整合,但想必Hbase做这一块会更有优势。

    我们的需求是做一个数据仓库,不是线上数据,即是OLAP。数据来源是很多的线上数据库(我们用的是mysql),每隔一段时间会同步数据过来(大概是几天的样子)。这些数据将用于日后的数据分析。因此,对实时性要求不是很高。

    答案:

    百万级的数据,无论侧重OLTP还是OLAP,当然就是MySql了。

    过亿级的数据,侧重OLTP可以继续Mysql,侧重OLAP,就要分场景考虑了。

    实时计算场景:强调实时性,常用于实时性要求较高的地方,可以选择Storm;

    批处理计算场景:强调批处理,常用于数据挖掘、分析,可以选择Hadoop;

    实时查询场景:强调查询实时响应,常用于把DB里的数据转化索引文件,通过搜索引擎来查询,可以选择solr/elasticsearch;

    企业级ODS/EDW/数据集市场景:强调基于关系性数据库的大数据实时分析,常用于业务数据集成,可以选择Greenplum;

    数据库系统一般分为两种类型:

    一种是面向前台应用的,应用比较简单,但是重吞吐和高并发的OLTP类型;

    一种是重计算的,对大数据集进行统计分析的OLAP类型。

    传统数据库侧重交易处理,即OLTP,关注的是多用户的同时的双向操作,在保障即时性的要求下,系统通过内存来处理数据的分配、读写等操作,存在IO瓶颈。

    OLTP(On-Line Transaction Processing,联机事务处理)系统也称为生产系统,它是事件驱动的、面向应用的,比如电子商务网站的交易系统就是一个典型的OLTP系统。OLTP的基本特点是:

    数据在系统中产生;

    基于交易的处理系统(Transaction-Based);

    每次交易牵涉的数据量很小;

    对响应时间要求非常高;

    用户数量非常庞大,主要是操作人员;

    数据库的各种操作主要基于索引进行。

    分析型数据库是以实时多维分析技术作为基础,即侧重OLAP,对数据进行多角度的模拟和归纳,从而得出数据中所包含的信息和知识。

    OLAP(On-Line Analytical Processing,联机分析处理)是基于数据仓库的信息分析处理过程,是数据仓库的用户接口部分。OLAP系统是跨部门的、面向主题的,其基本特点是:

    本身不产生数据,其基础数据来源于生产系统中的操作数据(OperationalData);

    基于查询的分析系统;

    复杂查询经常使用多表联结、全表扫描等,牵涉的数据量往往十分庞大;

    响应时间与具体查询有很大关系;

    用户数量相对较小,其用户主要是业务人员与管理人员;

     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     


    1. 如果时间不是特别紧急,还是要想想这个架构选择是否能支撑两年的业务需求,如果业务数据量或者丰富度增长很快,大半年就要换架构,那就有点麻烦,不影响业务情况下换架构并不容易;
    2. 楼主每天新增5W,假设这个系统支持业务运行两年,业务线性增长,则整个系统的数据量为50K*730+5M =40M 数据; 实际上业务增长可能越来越快(老板也是这么希望的吧:),到时候没准有1亿条数据;
    3. 上面三个系统,HBase撑得起来1亿数据没任何问题,MySQL也有较成熟解决方案,MongoDB感觉也没问题(没实际用过,从一些技术文章介绍看,MongoDB第一版存储引擎是有些问题,对内存的依赖,碎片,现在WT引擎还需要时间稳定,周边工具、论坛的丰富程度也低于MySQL)。需要付出的精力个人认为MongoDB > MySQL >> HBase。正如楼主所言,HBase处理这点量没有压力,而且扩容方便。
    4. 不知道楼主是否考虑过使用云计算解决问题?也许能节约精力、节省成本。
    国内:
    阿里云 阿里云-全球领先的云计算服务平台,有MySQL托管、KV存储、类似HBase的OTS产品;
    百度云:百度云——云上的日子 你我共享 居然需要先登录才能看产品,我没有账号;
    金山云:金山云官网 有关系数据库服务,从产品技术文档看,后台应该是MySQL,使用了SSD提高性能来适应游戏的实时要求,估计价格不便宜;
    国外亚马逊、微软的云服务也非常完善,不过一时还用不上,原因大家都懂。

     

     

    我觉得首先来看一看今天企业里面经常谈的一个问题就是整合的问题。为什么会谈到整合的问题,因为整合就是你现在有很多没有被整合的东西,所以是信息孤岛,因为有信息孤岛的存在,所以需要整合。反过来讲为什么信息孤岛会存在,谁都没有希望在建系统的时候要把它做成一个孤岛。原因在于很多时候CIO在选择建一个整个企业的系统的时候,它是希望由应用来驱动。也就是说他在不断建一个一个应用,比如说我要建一个ERP的应用,比如说我需要建一个人事的应用,等等有各种各样的应用,有风险的应用。这样你会发现每一个应用他都建立起来了,但是当他建立了十个、二十个,比如说一个银行最少有七八十个应用,建了七八十个应用以后,他就发现原来应用和应用系统之间就开始有信息孤岛,然后他开始希望做整合。实际上如果说你选择的时候如果多考虑一下平台层的问题,你可以让信息孤岛的问题有很大程度在早期就能解决,而不是到事后解决。这个平台层,实际上最重要的一点首先就是应该考虑数据库。你数据的库的选择是非常非常重要的一点,所以说如果说我觉得我给CIO第一个建议,你首先要考虑建一个平台,而不仅仅是说根据你的业务需要建各种各样的应用,应用是需要的,但是平台也是非常重要的。这样在数据库的选择上,我觉得重要的一点在于你应该用一个数据库即云的服务这样一个概念来选择。

      大家可能会问,你今天来讲怎么样建数据库的云服务呢?大家知道现在有很多种数据库,甲骨文当然是其中最重要的一种关系型的数据库。甲骨文的市场份额也非常高,超过了50%。但是你会发现还有一些其他的数据库,甚至于还有一些开源的数据库。比如说甲骨文非常著名的MySQL当然还有一些其他的比如说非关系型的数据库,比如noSQL,这些东西怎么选择呢?你既然要建立一个database service的平台,你首先应该想清楚哪些你是关系型的,哪些是非关系型的,这个是最重要的一点。你今天来讲,你不可能用一个关系型的数据库来解决所有的非关系型和关系型的问题。这个世界不是一个只是非黑即白的世界,简单来讲,比如说大家知道非关系型里面很重要一点就是noSQL和Hadoop,这里面是最著名的技术,现在业界有一种思潮认为我可以用Hadoop解决所有的问题,不仅仅可以解决非关系型的问题,也可以解决关系型的问题。这个选择这个想法对不对呢?这个答案首先我可以告诉各位肯定是错误的,为什么这么讲?因为Hadoop实际上是谷歌发明的技术,但是今天即使在谷歌本身它关系型的数据库也是由关系型的数据库解决的,并不是用Hadoop解决的。

      第二个问题在于,我是不是可以用MySQL来解决这个问题呢?大家说既然我同意了我不用Hadoop来解决这个问题。我用MySQL来解决这个问题可以吗,MySQL也是一个关系型数据库,只是它开源而已。这里面首先应该有一个很明确的一点,不管是甲骨文所有的企业级数据库和甲骨文的MySQL数据库都是来自于同一家公司甲骨文。MySQL我们的定位它是解决一些简单的事物性工作,而企业级是用甲骨文的企业级数据库,大家说我是不是可以企业级的也是可以用MySQL解决,你到底希望你的投资是在数据库层面上还是在整个应用层面上。因为MySQL这样的原因它没有办法支撑数据量很大的情况,所以他就要求把数据库拆分。

      举个简单的例子,假如说你是一个厨师,你希望你的后面有各种各样的原料,你的原料里面有肉,有鱼,有蔬菜,可能还有一些其他的配料。你到底是用一个大冰箱来装,还是分成若干个小冰箱来装。如果说你分成若干个小冰箱装,你就要明确肉是装在1号冰箱的,鱼是装在2号冰箱的,你的蔬菜是3号冰箱。如果你还有各种各样的配料,你一定要非常非常清楚。因此在应用层面,你就要确定我要取肉一定是从1号冰箱,但是如果说甲骨文的关系型数据库,企业级数据库你就是放在一个大冰箱,整个就是一个一千立升的冰箱,所有的东西搁进去,只要在这个冰箱里面,就可以取到你想要的东西。这个实际上就是甲骨文的关系型数据库,这是一个简单的例子和MySQL的区别。

      也就说你选择甲骨文的企业级数据库,对你来讲,你在应用层相对来讲,你是不需要做太多的工作。反而如果说你选择了MySQL,你需要在应用层做很多的一些工作,确保你的分库可以满足你整个系统的要求。这点来讲你要做一个选择,不是说MySQL不能用,而在于你到底是需求什么。大家会说对CIO来讲,我就是希望在应用层做一些工作,然后我就把它拆成每个库,是不是可以呢?答案是可以的。但是有一个问题大家不要忘记,第一你的这个集成商你需要以后一直靠着它,这样你对集成商的需求性是很大的,依赖性很大。某种程度他是被集成商某种程度是绑定的,这是第一个问题。

      第二个问题,因为未来数据库很重要的一点不仅仅是这个数据库本身,很重要一点是它的很多选件。如果说大家是使用照相机会知道,照相机上面会配各种各样的镜头。照相机能拍出好多照片跟镜头是非常非常大的关系,MySQL上面相对的选件就会比较少,而甲骨文上面选件就会非常非常多,并不是这些功能不需要。比如说安全性,比如说数据的一致性等等这些方面,都是有各种各样的一些选件。因此来讲,当然你使用MySQL以后,这些选件你都需要找人来专门开发,这样你才能达到性能。所以你可以看到如果你选择MySQL,答案理论上是可以的,问题是你是不是愿意投入这么多的资源来做这样一件事情,我们实际上大家可以看到现在业界流行的方法,你把这些专业的事情留给专业的人做,其实作为一个企业来讲,数据库的开发,选件的开发并不是你的强项,你的强项是业务。

      因此你应该把数据库的事情给专业的数据库的人来做,这就是甲骨文来做。所以总体来讲我们给CIO的建议,第一在你选择你的应用的时候,在你选择整个系统的时候,不应该仅仅考虑应用层,一定要选择平台层,以减少你未来的信息孤岛的风险。再选择平台层的时候,最重要的是数据库,数据库的选择,今天用Hadoop来解决所有的问题是不可能的,反过来讲,用MySQL一种开源的数据库,和甲骨文来比,的的确确都可以解决关系型数据库的问题。但是问题是大家的价值取向不一样,如果按照总体拥有成本来说一定是甲骨文的企业级数据库拥有更好的TCO

     

    SQL vs NoSQL:数据库并发写入性能比拼

    来源: Observer专栏杂记  发布时间: 2010-03-20 11:50  阅读: 2704 次  推荐: 0   [收藏]  

         最近听说了很多关于NoSQL的新闻,比如之前Sourceforge改用MongoDB,Digg改用Cassandra等等。再加上之前做数据库比较时有人推荐我mongodb,所以也搜索了一下NoSQL,觉得NoSQL可能真的是未来的趋势。

      NoSQL vs SQL

      传统SQL数据库为了实现ACID(atomicity, consistency, isolation, durability),往往需要频繁应用文件锁,这使得其在现代的Web2.0应用中越来越捉襟见肘。现在SNS网站每一个点击都是一条/多条查询,对数据库写的并发要求非常之高,而传统数据库无法很好地应对这种需求。而仔细想来SNS中大部分需求并不要求ACID,比如Like/Unlike投票等等。

      NoSQL吸取了教训,比如有些NoSQL采用了eventually consistency的概念,在没有Update操作一段时间后,数据库将最终是consistency的,显然这样的数据库将能更好的支持高并发读写。

      SQL数据库是基于schema的,这对时时刻刻更新着的Web2.0应用开发者来说是个噩梦:随时随地有新的应用出现,旧的数据库无法适应新的应用,只能不停地更新schema,或者做补丁表,如此一来要么schema越发混乱,要么就是数据库频繁升级而耗时耗力耗钱。

      NoSQL一般就没有schema这种概念,大部分NoSQL都直接保存json类的Row,比如一个记录可以是{ id = 1, name = Bob, phone = 38492839 },这样扩展升级非常方便,比如需要地址信息直接加入 address=blahblah 即可。

      传统SQL很难进行分布式应用,即使可以也往往代价高昂。而NoSQL则很好地解决了这个问题:他们一般都直接从分布式系统中吸取了Map/Reduce方法,从而很容易就可以处理规模急速增加的问题。

      推荐robbin牛的NoSQL数据库探讨之一 - 为什么要用非关系数据库?一文,介绍了主流的一些NoSQL系统,还有这个站http://nosql-database.org/收集了基本上目前所有的NoSQL系统。

      总结一下我对NoSQL的看法,NoSQL出现的目的就是为了解决高并发读写的问题,而高并发应用往往需要分布式的数据库来实现高性能和高可靠性,所以NoSQL的关键字就是concurrency和scalability。

      我的瓶颈

      我之前主要关注数据库的select性能也就是read性能,在读性能方面SQL数据库并没有明显的劣势,应该说纯粹高并发读的性能的话往往要优于NoSQL数据库,然而一旦涉及写,事情就不一样了。

      我本来以为自己不会遇到大量写的问题,后来发现即使在simplecd这种简单的应用环境下也会产生大量的并发写:这就是爬VC用户评论的时候。事实上,sqlite3在处理这个问题上非常的力不从心,所以我产生了换个数据库的想法。

      既然我是要求能高并发读写,干脆就不用SQL了,但是同时我也想测试一下其他SQL的写性能。

      我的数据有180万条,总共350M,测试用了10个线程,每个线程做若干次100个数据的bulk写入,然后记录总共耗时。结果如下:

    innodb: 15.19
    myiasm: 14.34
    pgsql: 23.41
    sqlite3: 锁住了
    sqlite3(单线程): 300+
    mongodb: 3.82
    couchdb: 90
    couchdb(单线程):66

      作为一个MySQL黑,看到这组测试数据我表示压力很大。在SQL数据库中,mysql意外地取得了最佳的成绩,好于pgsql,远好于sqlite。更令人意外的是myisam居然优于号称insert比较快的innodb。不管如何,对我的应用来说,用mysql保存评论数据是一个更为明智的选择。我对mysql彻底改观了,我宣布我是mysql半黑。以后select-intensive的应用我还是会选择sqlite,但是insert/update-intensive的应用我就会改用mysql了。

      MongoDB和CouchDB同为NoSQL,表现却截然相反,MongoDB性能很高,CouchDB的并发性能我只能ORZ,这种性能实在太抱歉了。

      NoSQL的碎碎念

      其实我本来还打算测试cassandra的,可是cassandra用的是java,这首先让我眉头一皱,内存大户我养不起啊,其次看了cassandra的文档,立刻崩溃,这简直就是没有文档么。(BTW,CouchDB也好不到哪里去,我都是用python-couchdb然后help(couchdb.client)看用法的)

      至于CouchDB,可能是因为采用http方式发送请求,所以并发性能糟糕的一塌糊涂,很怀疑它是否有存在的理由。

      MongoDB是我用下来最讨人喜欢的一个NoSQL。不但文档丰富,使用简单,性能也非常好,它的Map/Reduce查询(很多NoSQL都有)让我惊叹,数据库可以非常简单地就扩大规模,完全不用理会什么分区分表之类繁琐的问题,可惜这方面我暂时没有需求。但是MongoDB有两大致命问题。

      第一是删除锁定问题,当批量删除记录时,数据库还是会锁定不让读写。这意味着进行数据清理时会让网站应用失去响应。见locking problems

      第二是内存占用问题,MongoDB用了操作系统的内存文件映射,这导致操作系统会把所有空闲内存都分配给MongoDB,当MongoDB有这个需要时。更可怕的是,MongoDB从来不主动释放已经霸占的内存,它只会滚雪球一样越滚越大,除非重启数据库。这样的上下文环境下,MongoDB只适合一台主机就一个数据库,而没有其他应用的环境,否则一会儿功夫MongoDB就会吃光内存,然后你都fork不出新进程,彻底悲剧。见memory limit

      总之NoSQL虽然让我眼前一亮,可是目前尝试的一些产品都让人望而生畏,现在的NoSQL都把目光放在了巨型网站上,而没有一个小型的,可以在VPS里面应用的高性能NoSQL,令我有点失望。NoSQL尚未成熟,很期待它的将来发展,目前来说MySQL还是更好的选择。

     

     

     

     


    1.Hadoop是不是既能解决关系型数据库,也可以解决非关系型数据库呢?为什么?
    答:我个人觉得hadoop侧重于非关系型数据库。hbase是基于hadoop的。虽然也支持将oracle这样的数据导入。但是天生还是处理非关系型的。
    2.您在购买数据库选型的时候,重点会考虑哪些因素?应用层与平台层哪个更重要?
    答:主要看应用和数量级。有事务要求和强一致性的用oracle的。数量级很小的用mysql。对事务无要求的用hbase。
    3.买了数据库是不是就一劳永逸了?后续哪些问题很棘手?
    答:俗话说,三分开发,七分运维。数据库是要维护的。定时监控,水平扩展,以及优化和灾备都是必须的。优化是永远的话题,宕机问题最棘手,所以灾备一定要有。
    5.数据库的选件到底是奢侈品还是必需品?您会考虑哪些常用的选件?
    答:如果对性能有要求,那么就是必需品。我会考虑内存计算等方面的数据库中间件来提高性能。
    6.对于数据中心而言,到底哪个成为性能的最大瓶颈?是CPU利用率还是数据库的性能?
    答:我觉得IO是最大瓶颈。如果1T的硬盘扫描一下1-2秒之内的话,那么所有问题都不是问题了。也不用内存计算和分布式了。
    7.国内用户47%的数据库选件投资,排在第一位的是RAC,RAC会不会出现滥用的现象?到底什么时候该用RAC?什么时候不该用RAC呢
    答:OLAP的时候选用rac是好的。OLTP的时候,最后别用RAC。DML的操作会使得栓锁比较严重。

     

    1.Hadoop是不是既能解决关系型数据库,也可以解决非关系型数据库呢?为什么?
    肯定不能了,hadoop的需求定位和就不是为了解决关系型数据库和非关系型数据库的使用。

    2.您在购买数据库选型的时候,重点会考虑哪些因素?应用层与平台层哪个更重要?
    会考虑业务需求、系统扩展、积极高可用性、维护成本以及总体成本等原因,平台服务于应用,所以为了满足应用需求我们才选择是用什么平台。

    3.买了数据库是不是就一劳永逸了?后续哪些问题很棘手?
    当然不是一劳永逸了,后期维护、需求变更、版本升级都是需要考虑的问题。
    最棘手的问题应该是数据库迁移,系统扩容和数据安全性了。

    4.甲骨文拥有企业级数据库Oracle和开源数据库MySQL,MySQL VS Oracle,到底各自用哪些应用场合?请举例说明。
    我个人觉得Oracle适合有一定数据库量和稳定性的企业,而mysql主要是从节约成本出发所选型的数据库。
    有一定规模的企业不会舍弃安全性、稳定性去使用mysql的。

    5.数据库的选件到底是奢侈品还是必需品?您会考虑哪些常用的选件?
    选件需要根据需求决定,比如说我有数据同步的需求就需要OGG,我有高可用需求就得使用RAC等等。
    我会按照业务重要性以及业务需求选用一些组件,常用的就是RAC ASM DG OGG等等。

    6.对于数据中心而言,到底哪个成为性能的最大瓶颈?是CPU利用率还是数据库的性能?
    数据中心最大的瓶颈在于规范化和监管上。只有具有一定规范化的流程体系,才能解决瓶颈问题。
    比如遇到cpu i/o 网络相关问题,没有好的体系流程和监管流程做什么都不能从根本解决问题。


    7.国内用户47%的数据库选件投资,排在第一位的是RAC,RAC会不会出现滥用的现象?到底什么时候该用RAC?什么时候不该用RAC呢?
    有时候很多企业一味的认为只要搭建了RAC就是高可用架构,这种理解非常愚昧。
    多数情况下根据业务数据量和安全性以及扩展性考虑是否选用RAC。
    一个数据量不大,访问不多的系统不建议使用RAC因为维护人员的成本也是成本。

     

    1.Hadoop是不是既能解决关系型数据库,也可以解决非关系型数据库呢?为什么?
    个人觉得应该不能,如果Hadoop既能解决关系型数据库,也可以解决非关系型数据库,那么其他的就没有必要发展了。这些技术很难达到两方面都俱全的。貌似雅虎的副总裁说过Hadoop在处理大量结构与非结构数据上是“非常有效的”。它适用于在传统数据仓库中对即时查询需求的支持,但不能取代针对有低潜在因素需求的传统商业智能(BI)功能的关系型数据库管理系统(RDBMS)的部署。从这就可以看出来。
    2.您在购买数据库选型的时候,重点会考虑哪些因素?应用层与平台层哪个更重要?
    数据库选型时,必须考虑以下五大因素: 1. 开发要求 2. 性能/成本 3. 数据库运行和管理 4. 可升级性 5. 总体拥有成本。其他的也会看数据库的特点和结构,以及数据库的设计、操作、监控各个层面都要有,应用层、平台层都要考虑。
    3.买了数据库是不是就一劳永逸了?后续哪些问题很棘手?
    当然不是。后续的问题还有很多的,数据库的部署以及升级,还有运维等等。
    4.甲骨文拥有企业级数据库Oracle和开源数据库MySQL,MySQL VS Oracle,到底各自用哪些应用场合?请举例说明。
    无论Linux还是Windows,低成本肯定用MySQL,需要高级支持的话,与其购买MS的只能运行于Windows的SQL Server(Windows Server也是一大笔费用),还不如买口碑更好的Oracle,盗版就不要用了。
    5.数据库的选件到底是奢侈品还是必需品?您会考虑哪些常用的选件?
    个人觉得应该算是必需品
    6.对于数据中心而言,到底哪个成为性能的最大瓶颈?是CPU利用率还是数据库的性能?
    对数据中心而言个人觉得是数据库的性能。
    7.国内用户47%的数据库选件投资,排在第一位的是RAC,RAC会不会出现滥用的现象?到底什么时候该用RAC?什么时候不该用RAC呢?
    应该不会出现滥用吧。高可用多节点时多采用RAC。事务量小,有别的简单办法可以替代时,就不需要RAC。。


    1.Hadoop是不是既能解决关系型数据库,也可以解决非关系型数据库呢?为什么?
    肯定不能了,hadoop的需求定位和就不是为了解决关系型数据库和非关系型数据库的使用。

    2.您在购买数据库选型的时候,重点会考虑哪些因素?应用层与平台层哪个更重要?
    会考虑业务需求、系统扩展、积极高可用性、维护成本以及总体成本等原因,平台服务于应用,所以为了满足应用需求我们才选择是用什么平台。

    3.买了数据库是不是就一劳永逸了?后续哪些问题很棘手?
    当然不是一劳永逸了,后期维护、需求变更、版本升级都是需要考虑的问题。
    最棘手的问题应该是数据库迁移,系统扩容和数据安全性了。

    4.甲骨文拥有企业级数据库Oracle和开源数据库MySQL,MySQL VS Oracle,到底各自用哪些应用场合?请举例说明。
    我个人觉得Oracle适合有一定数据库量和稳定性的企业,而mysql主要是从节约成本出发所选型的数据库。
    有一定规模的企业不会舍弃安全性、稳定性去使用mysql的。

    5.数据库的选件到底是奢侈品还是必需品?您会考虑哪些常用的选件?
    选件需要根据需求决定,比如说我有数据同步的需求就需要OGG,我有高可用需求就得使用RAC等等。
    我会按照业务重要性以及业务需求选用一些组件,常用的就是RAC ASM DG OGG等等。

    6.对于数据中心而言,到底哪个成为性能的最大瓶颈?是CPU利用率还是数据库的性能?
    数据中心最大的瓶颈在于规范化和监管上。只有具有一定规范化的流程体系,才能解决瓶颈问题。
    比如遇到cpu i/o 网络相关问题,没有好的体系流程和监管流程做什么都不能从根本解决问题。


    7.国内用户47%的数据库选件投资,排在第一位的是RAC,RAC会不会出现滥用的现象?到底什么时候该用RAC?什么时候不该用RAC呢?
    有时候很多企业一味的认为只要搭建了RAC就是高可用架构,这种理解非常愚昧。
    多数情况下根据业务数据量和安全性以及扩展性考虑是否选用RAC。
    一个数据量不大,访问不多的系统不建议使用RAC因为维护人员的成本也是成本。

     

    1.Hadoop是不是既能解决关系型数据库,也可以解决非关系型数据库呢?为什么?
    个人觉得应该不能,如果Hadoop既能解决关系型数据库,也可以解决非关系型数据库,那么其他的就没有必要发展了。这些技术很难达到两方面都俱全的。貌似雅虎的副总裁说过Hadoop在处理大量结构与非结构数据上是“非常有效的”。它适用于在传统数据仓库中对即时查询需求的支持,但不能取代针对有低潜在因素需求的传统商业智能(BI)功能的关系型数据库管理系统(RDBMS)的部署。从这就可以看出来。

    2.您在购买数据库选型的时候,重点会考虑哪些因素?应用层与平台层哪个更重要?

    数据库选型时,必须考虑以下五大因素: 1. 开发要求 2. 性能/成本 3. 数据库运行和管理 4. 可升级性 5. 总体拥有成本。其他的也会看数据库的特点和结构,以及数据库的设计、操作、监控各个层面都要有,应用层、平台层都要考虑。


    3.买了数据库是不是就一劳永逸了?后续哪些问题很棘手?
    当然不是。后续的问题还有很多的,数据库的部署以及升级,还有运维等等。

    4.甲骨文拥有企业级数据库Oracle和开源数据库MySQL,MySQL VS Oracle,到底各自用哪些应用场合?请举例说明。
    无论Linux还是Windows,低成本肯定用MySQL,需要高级支持的话,与其购买MS的只能运行于Windows的SQL Server(Windows Server也是一大笔费用),还不如买口碑更好的Oracle,盗版就不要用了。

    5.数据库的选件到底是奢侈品还是必需品?您会考虑哪些常用的选件?
    个人觉得应该算是必需品

    6.对于数据中心而言,到底哪个成为性能的最大瓶颈?是CPU利用率还是数据库的性能?
    对数据中心而言个人觉得是数据库的性能。

    7.国内用户47%的数据库选件投资,排在第一位的是RAC,RAC会不会出现滥用的现象?到底什么时候该用RAC?什么时候不该用RAC呢?
    应该不会出现滥用吧。高可用多节点时多采用RAC。事务量小,有别的简单办法可以替代时,就不需要RAC。。


    1.Hadoop是不是既能解决关系型数据库,也可以解决非关系型数据库呢?为什么?
    答:我个人觉得hadoop侧重于非关系型数据库。hbase是基于hadoop的。虽然也支持将oracle这样的数据导入。但是天生还是处理非关系型的。
    2.您在购买数据库选型的时候,重点会考虑哪些因素?应用层与平台层哪个更重要?
    答:主要看应用和数量级。有事务要求和强一致性的用oracle的。数量级很小的用mysql。对事务无要求的用hbase。
    3.买了数据库是不是就一劳永逸了?后续哪些问题很棘手?
    答:俗话说,三分开发,七分运维。数据库是要维护的。定时监控,水平扩展,以及优化和灾备都是必须的。优化是永远的话题,宕机问题最棘手,所以灾备一定要有。
    5.数据库的选件到底是奢侈品还是必需品?您会考虑哪些常用的选件?
    答:如果对性能有要求,那么就是必需品。我会考虑内存计算等方面的数据库中间件来提高性能。
    6.对于数据中心而言,到底哪个成为性能的最大瓶颈?是CPU利用率还是数据库的性能?
    答:我觉得IO是最大瓶颈。如果1T的硬盘扫描一下1-2秒之内的话,那么所有问题都不是问题了。也不用内存计算和分布式了。
    7.国内用户47%的数据库选件投资,排在第一位的是RAC,RAC会不会出现滥用的现象?到底什么时候该用RAC?什么时候不该用RAC呢
    答:OLAP的时候选用rac是好的。OLTP的时候,最后别用RAC。DML的操作会使得栓锁比较严重。

    1.Hadoop是不是既能解决关系型数据库,也可以解决非关系型数据库呢?为什么?
    当然不能,互联网进修越是数据对象的特点越来越复杂,很难再靠一瓶万金油抹全身。

    2.您在购买数据库选型的时候,重点会考虑哪些因素?应用层与平台层哪个更重要?
    大的方面看数据库的特点和结构,细到数据库的设计、操作、监控各个层面都要有,应用层、平台层都要考虑。

    3.买了数据库是不是就一劳永逸了?后续哪些问题很棘手?
    当然不是,看运维的需要,看商业化的售后服务,当然也看数据库的能不能有持续的完善,越是使用广泛,越升级越强大。

    4.甲骨文拥有企业级数据库Oracle和开源数据库MySQL,MySQL VS Oracle,到底各自用哪些应用场合?请举例说明。
    一般传统的商业应用,用ORACLE居多,一些数据生命周期短的,商业价值小一些的,又想少点费用的,用MySQ。L

    5.数据库的选件到底是奢侈品还是必需品?您会考虑哪些常用的选件?
    必需吧,比如RAC

    6.对于数据中心而言,到底哪个成为性能的最大瓶颈?是CPU利用率还是数据库的性能?
    对数据中心而言,CPU不担心,可以随时添加,磁盘IO也有办法规避,但数据库的本身性能可腾挪的余地比较少。

    7.国内用户47%的数据库选件投资,排在第一位的是RAC,RAC会不会出现滥用的现象?到底什么时候该用RAC?什么时候不该用RAC呢?
    高可用多节点时多采用。事务量小且有别的简单办法搞定时,就不要是RAC了

     

    1.Hadoop是不是既能解决关系型数据库,也可以解决非关系型数据库呢?为什么?
    这个是不能的,首先要了解hadoop是什么,hadoop是一个分布式系统基础架构,他的最核心设计是HDFS和MapReduce,HDFS为海量的数据提供了存储,MapReduce为海量的数据提供计算。

    2.您在购买数据库选型的时候,重点会考虑哪些因素?应用层与平台层哪个更重要?
    数据库选型时首要是考虑客户业务和业务涉及的数据形态,平台要比应用更重要。

    3.买了数据库是不是就一劳永逸了?后续哪些问题很棘手?
    没有一劳永逸的事情,就像天上不会掉馅饼。后续数据库参数调整、性能优化、备份恢复都是需要持续进行的事情。就像买了一台车一样,不能每天除了加油开车外其他都不做了,你还需要去做保养,换机油、加玻璃水、电池更换、轮胎保养等等。

    4.甲骨文拥有企业级数据库Oracle和开源数据库MySQL,MySQL VS Oracle,到底各自用哪些应用场合?请举例说明。
    应用场合我觉得并不能绝对,有时更需要从客户的需求来看,有的用户没有数据库的预算,你就需要使用mysql的免费版来使用;有的用户预算不足,你可以用mysql的收费版来使用;有充足的预算可以使用oracle。
    并不能绝对说那种场景,比如银行里有使用oracle,也有使用db2,informix。阿里也曾经从oracle转向了mysql。

    5.数据库的选件到底是奢侈品还是必需品?您会考虑哪些常用的选件?
    数据库的选件由业务或者客户的需求决定,倒不是奢侈品也不是必需品。使用oracle数据库时,一般考虑比较多的是RAC,Oracle Partitioning,高级分析和内存选件。其他每款收费数据库的选件都不同,但高可用性肯定是排第一的。

    6.对于数据中心而言,到底哪个成为性能的最大瓶颈?是CPU利用率还是数据库的性能?
    个人看法数据库的性能还是最大瓶颈。cpu利用率一般不高。

    7.国内用户47%的数据库选件投资,排在第一位的是RAC,RAC会不会出现滥用的现象?到底什么时候该用RAC?什么时候不该用RAC呢?
    选择RAC多的原因是大家都希望数据库有一个高可用性。数据库不可用时,其他选件再强大也发挥不了作用。
    目前不会滥用,对数据库的可用性要求很高时,比如要求系统的可用达到99.99%时,必不可少。
    如果数据对业务的影响很低,系统对用户的使用频率和依赖程度很低可以使用免费的开源版本mysql即可,可以不上RAC。

     

    1.Hadoop是不是既能解决关系型数据库,也可以解决非关系型数据库呢?为什么?
    这个是不能的,首先要了解hadoop是什么,hadoop是一个分布式系统基础架构,他的最核心设计是HDFS和MapReduce,HDFS为海量的数据提供了存储,MapReduce为海量的数据提供计算。

    2.您在购买数据库选型的时候,重点会考虑哪些因素?应用层与平台层哪个更重要?
    数据库选型时首要是考虑客户业务和业务涉及的数据形态,平台要比应用更重要。

    3.买了数据库是不是就一劳永逸了?后续哪些问题很棘手?
    没有一劳永逸的事情,就像天上不会掉馅饼。后续数据库参数调整、性能优化、备份恢复都是需要持续进行的事情。就像买了一台车一样,不能每天除了加油开车外其他都不做了,你还需要去做保养,换机油、加玻璃水、电池更换、轮胎保养等等。

    4.甲骨文拥有企业级数据库Oracle和开源数据库MySQL,MySQL VS Oracle,到底各自用哪些应用场合?请举例说明。
    应用场合我觉得并不能绝对,有时更需要从客户的需求来看,有的用户没有数据库的预算,你就需要使用mysql的免费版来使用;有的用户预算不足,你可以用mysql的收费版来使用;有充足的预算可以使用oracle。
    并不能绝对说那种场景,比如银行里有使用oracle,也有使用db2,informix。阿里也曾经从oracle转向了mysql。

    5.数据库的选件到底是奢侈品还是必需品?您会考虑哪些常用的选件?
    数据库的选件由业务或者客户的需求决定,倒不是奢侈品也不是必需品。使用oracle数据库时,一般考虑比较多的是RAC,Oracle Partitioning,高级分析和内存选件。其他每款收费数据库的选件都不同,但高可用性肯定是排第一的。

    6.对于数据中心而言,到底哪个成为性能的最大瓶颈?是CPU利用率还是数据库的性能?
    个人看法数据库的性能还是最大瓶颈。cpu利用率一般不高。

    7.国内用户47%的数据库选件投资,排在第一位的是RAC,RAC会不会出现滥用的现象?到底什么时候该用RAC?什么时候不该用RAC呢?
    选择RAC多的原因是大家都希望数据库有一个高可用性。数据库不可用时,其他选件再强大也发挥不了作用。
    目前不会滥用,对数据库的可用性要求很高时,比如要求系统的可用达到99.99%时,必不可少。
    如果数据对业务的影响很低,系统对用户的使用频率和依赖程度很低可以使用免费的开源版本mysql即可,可以不上RAC。


    以前在几个公司用过rac,不过现在觉得一般业务,用dataguard就挺好,当然两个节点的机器应该配置强一些。
    现在用的mysql主从,主库是8块800G的intel dc s3500 ssd 的raid10,io没什么wait,基本都是cpu在工作。24核cpu,128G内存,dell r720 pc server。

    反观机械硬盘的raid10的从库,就有较大比例的io wait,6块sas的15k的600G的raid10. raid5的老机器,那就更不用说了,io就是瓶颈

     

    展开全文
  • 简介:今天咱们聊聊针对统计数据的选项标准 具体 : 统计数据库你需要关注的几个指标 1 千万级别以上表的查询效率和压缩效率 2 数据类型与关系型数据库的差异性 3 标准SQL语法的支持程度和 数据库函数的支持程度 4 ...

    简介:今天咱们聊聊针对统计数据的选项标准

    具体 :

         统计数据库你需要关注的几个指标
           1 千万级别以上表的查询效率和压缩效率
           2 数据类型与关系型数据库的差异性
           3 标准SQL语法的支持程度和 数据库函数的支持程度
           4 集群架构的可扩展性和稳定性
           5 运维成本和程序适用性

    转载于:https://www.cnblogs.com/danhuangpai/p/9447532.html

    展开全文
  • 数据仓库方案选型

    万次阅读 2017-11-07 10:43:20
    底层的数据仓库服务器通常是一个关系数据库系统(各种表关联的sql统计会更方便一些,非关系型数据库目前在这方面还是有所区别)。 中间层OLAP服务器,典型实现为ROLAP模型或MOLAP模型。 顶层为前端客户端,用于数据...


    总体框架

    通常采用三层体系结构:前端工具(顶层)-OLAP服务器(中间层)-数据仓库服务器(底层)。

    底层的数据仓库服务器通常是一个关系数据库系统(各种表关联的sql统计会更方便一些,非关系型数据库目前在这方面还是有所区别)。
    中间层OLAP服务器,典型实现为ROLAP模型或MOLAP模型。
    顶层为前端客户端,用于数据分析和挖掘等(如趋势分析、预测)。
    当然现在很多成熟的BI工具都是集成了OLAP服务器的,所以我们只是需要选择ETL工具以及存储方案和 可视化BI方案即可。


    ETL工具

    1、KETL,由具有IBM和KPMG背景的Kinetic Networks公司开发,现在已经有三年多的产品应用历史,成功应用于一些产品中,在点击流(ClickStream)分析应用中表现出色。KETL采用Plug-in的架构,使用Java开发。
    2、KETTLE,为一个元数据驱动的ETL工具。已经加入Pentaho。
    3、Clover ETL,为一个基于Java的ETL Framework,可以用来开发自己的ETL应用。 (开源)
    4、Enhydra Octopus,为一个基于Java的ETL工具,使用JDBC来连接各种数据源,易于使用和部署。曾有人应用于电信网络资源分析系统中。
    5、Informatica Powercenter,oracle的ETL工具
    6、Datastage,IBM的Datastage工具
    7、oracle warehouse builder,oracle的ETL工具(OWB)
    8、Oracle Data Integrator,oracle的ETL工具(ODI)
    9、微软DTS
    10、Beeload(国内北京灵蜂纵横)
    11、微软DTS
    12、Talend
    13、DataSprider
    14、Spark自己写抽取保存
    15、Octupus(开源)

    对比

    Pentaho Data Integration (Kettle)是Pentaho生态系统中默认的ETL工具。通过非常直观的图形化编辑器(Spoon),您可以定义以XML格式储存的流程。在Kettle运行过程中,这些流程会以不同的方法编译。用到的工具包括命令行工具(Pan),小型服务器(Carte),数据库存储库(repository)(Kitchen)或者直接使用IDE(Spoon)。
    Talend Open Studio是 Talend 开发的ETL工具——Talend 是一家主营数据集成和数据管理解决方案的企业。Talend 采用用户友好型,综合性很强的IDE(类似于Pentaho Kettle 的 Spoon)来设计不同的流程。这些流程可以在IDE内部测试并编译成Java 代码。您可以随时查看并编辑生成的Java代码,同时实现强大的控制力和灵活性。
    两者都非常优秀,都属于用户友好型的交叉平台(基于Java的)工具。它们的主要差异在于Kettle 将 ELT 流程编译为 XML 格式,然而Talend Open Studio 则生成 Java 代码。
    易用性:
    Talend:有 GUI 图形界面但是以 Eclipse 的插件方式提供。
    Kettle:有非常容易使用的 GUI,出现问题可以到社区咨询。
    技术支持:
    Talend:主要在美国
    Kettle:在美国,欧洲(比利时,德国,法国,英国),亚洲(中国,日本,韩国)都可以找到相关技术支持人员。
    部署:
    Talend:创建 java 或perl 文件,并通过操作系统调度工具来运行
    Kettle:可以使用 job 作业方式或操作系统调度,来执行一个转换文件或作业文件,也可以通过集群的方式在多台机器上部署。
    速度:
    Talend:需要手工调整,对特定数据源有优化知识。
    Kettle:比 Talend 快,不过也需要手工调整,对 Oracle 和 PostGre 等数据源做了优化,同时也取决于转换任务的设计。
    数据质量:
    Talend:在 GUI 里有数据质量特性,可以手工写 SQL 语句。
    Kettle:在 GUI 里有数据质量特性,可以手工写 SQL 语句、java脚本、正则表达式来完成数据清洗。
    监控:
    Talend:有监控和日志工具
    Kettle:有监控和日志工具
    连接性:
    Talend:各种常用数据库,文件,web service。
    Kettle:非常广泛的数据库,文件,另外可以通过插件扩展

    Talend: 基于Eclipse,具有很好的扩展性、稳定性以及可定制化(可以自己开发eclipse插件),并且服从Eclipse标准(如文件目录结构都是程序员熟悉的结构)。Talend具有很好的嵌入性,因为它生成的是Java代码,这些代码可以很好的和其他系统结合在一起,这就要求使用者会java。如果不会Java的话,Talend的缺点是学习曲线将会非常陡峭,但是如果会java的话,Talend将是一个绝佳的选择。

    Penthao: 它是一个老牌的工具,在2001年就发布了第一个版本,Kettle是Penthao整个解决方案的一个组件,用来进行数据集成。它也是基于java开发的,但是它不要求用户会java,将底层实现细节都隐藏了。这样即使不会编程的用户也可以轻易的上手,学习曲线非常平缓。它主要的缺点是,和talend相比,它的扩展性较差。由于它很难扩展,所以在社区中可用的组件就比较少;同时,由于它是直接解析存放在xml中的任务信息,不直接生产java代码,使得它和现有的java开发的系统进行集成非常困难。

    CloverETL: 它是在talend和penthao之后发展起来的工具,使用的人数没有talend和penthao多,它主要的优点是,轻量级、容易嵌入、易于使用。但是它的功能远没有talend和kettle强大。

    性能:从clover的官网上,有如下两组性能测试报告(2009年),分别是1GB的文件大小和10GB的文件大小,从这两组系统报告可以看出,clover的性能是最好的,Talend的性能次之,Penthao的性能最差。

    从使用教程上来看,cloverETL百度查询条数是5W4,Tanlend是32W,Kettle是900多W。 所以Kettle是资料比较丰富的,如果时间紧迫建议选择Kettle。


    存储方案


    方案1:采用传统的关系型数据库,或经过功能扩展的MPP(massively paralle processing)数据库

    传统的关系型数据库
    oracle
    mysql

    大规模并行处理数据库
    Vertica
    Teradata(商业)
    Greenplum (开源)
    据了解,Greenplum数据库是业界最快和最高性价比的高端数据仓库解决方案。
    Greenplum是基于PostgreSQL的。于2015年开源。
    传说中四大行有3家在用,5大物流公司有4家在用,我还知道有国内航空业龙头顺利完成了Teradata到GP的迁移,去除人工后还省下了过千万费用。

    SequoiaDB
    广州巨杉软件专注新一代大数据技术研发,是国内唯一的原厂企业级分布式数据库公司。
    SequoiaDB巨杉数据库,是一款企业级分布式NewSQL数据库,自主研发并拥有完全自主知识产权,没有基于任何其他外部的开源数据库源代码。SequoiaDB支持标准SQL、事务操作、高并发、分布式、可扩展、与双引擎存储等特性,并已经作为商业化的数据库产品开源。


    方案2:Hadoop+Hive

    这样的组合:PG(TB级数据)、GP(百TB级数据)、Hadoop(PB级以上数据)的组合。


    sql查询引擎

    Impala
    Presto
    Drill
    Shark —>Spark sql


    OLAP服务器

    Mondrian


    报表展示工具

    目前较为知名的开源报表工具有
    JasperReports,一个优秀的Java报表工具,始于2001,现在JasperSoft公司持续开发和支持该工具。该工具类似于商业软件Crystal Report,支持PDF、HTML、XLS、CSV和XML文件输出格式,现在是Java开发者最常用的报表工具。
    OpenReports,提供基于web的灵活报表解决方案,通过浏览器自动生成动态PDF,XLS,HTMLCSV 和Chart报表,它是用Java开发的,使用JasperReports 作为报表引擎,利用到的开源技术有Hibernate,Veloctiy,Webwork。
    JFreeReport,现在是Pentaho的一部分,它是一个优秀的用来生成报表的Java类库。它为Java应用程序提供一个灵活的打印 功能并支持输出到打印机和PDF, Excel, HTML和XHTML, PlainText, XML和CSV文件中。
    Eclipse BIRT,是Eclipse下面的一个企业智能和报表 工具,能为J2EE的WEB应用程序创建漂亮醒目的PDF或者HTML格式的报表,它提供了核心的报表功能。
    Jpivot(一般与Mondrian配合使用)


    BI可视化分析工具(BI一般都集成了OLAP服务器和报表展示工具)

    SpotView
    FineBI(国内)
    Z-Suite(国内)
    SmartBI(国内)
    Power-BI(国内)
    QuickBI(国内阿里)
    QlikView
    SpagoBI(集成了Mondrain和JProvit)
    Pentaho
    Tableau
    Openi

    Openi是轻量级的。Openi的技术文档非常少,而且完全不支持中文,所以暂不采用。SpagoBI和Pentaho使用的开源技术很类似,技术都比较强大,属于重量级的开发工具。但是SpagoBI中文支持不太好。Pentaho的中文文档多,国际化做的比较好。所以选用Pentaho作为研究的开源数据仓库工具。


    其他公司的选型方案

    唯品会 Hadoop+Hive + Presto

    阿里 oracle —> Greenplum —> Hadoop+Hive —>飞天


    参考文献

    数据仓库是什么
    http://blog.csdn.net/zzq900503/article/details/78405958

    据了解,Greenplum数据库是业界最快和最高性价比的高端数据仓库解决方案。请问国内互联网行业,现在有哪些公司在使用它呢?
    https://www.zhihu.com/question/20249206

    聊聊Greenplum的那些事
    http://blog.csdn.net/paicmis/article/details/53576859

    唯品会海量实时OLAP分析技术升级之路
    http://blog.csdn.net/zzq900503/article/details/78436038

    阿里云大数据三次技术突围:Greenplum、Hadoop和飞天
    http://blog.csdn.net/zzq900503/article/details/78435281

    展开全文
  • PostgreSQL , PPAS , Greenplum , HybridDB for PostgreSQL , 性能 , 估算 , pgbench , 统计细信息 , explain算法 , 统计信息导入导出 背景 在提预算时必不可少的环境是评估需要多少硬件。 通常会要求...

    想不想知道是什么


    标签

    PostgreSQL , PPAS , Greenplum , HybridDB for PostgreSQL , 性能 , 估算 , pgbench , 统计细信息 , explain算法 , 统计信息导入导出


    背景

    在提预算时必不可少的环境是评估需要多少硬件。

    通常会要求业务方提供一些数据,例如用户数、PV、UV等。但是这种评估纯靠经验,方法非常的粗糙也不准确。

    那么到底如何评估需要多少硬件、或者说需要什么样规格的硬件来支撑你未来的业务呢?

    对于PostgreSQL这个数据库产品来说,我介绍一下三种评估方法:

    1、微观评估(相对来说比较准确)

    2、宏观评估(对选型有帮助,对规格帮助不大,略显粗糙)

    3、精准评估(最为准确,但是要求对业务非常熟悉,对未来的瓶颈把握准确)

    一、微观估算法

    我们在通过SQL与数据库交互时,数据库是如何执行SQL的呢?

    首先要PARSE SQL,然后生成执行路径,选择最优执行路径,执行SQL,最关键的是选择最优执行路径。PostgreSQL是CBO的优化器,根据成本选择。

    这里提到了成本,成本是怎么算出来的呢?成本是结合扫描方法、统计信息、估算需要扫描多少个数据块,扫描多少条记录,最后通过对应扫描方法的成本估算算法算出来的。

    一个 QUERY 有哪些成本

    1、成本包括:

    IO成本,CPU成本。

    2、IO成本包括:

    连续IO成本,离散IO层板。

    3、CPU成本包括:

    获取索引、TOAST索引、堆表、TOAST表的tuple或ITEM的成本;

    操作符、函数处理行的成本;

    处理JOIN的成本等等。

    一个 QUERY 如何执行和传递成本

    生成好执行计划后,QUERY的执行就会按执行树来执行

    pic

    执行树由若干个节点组成,从一个节点,跳到下一个节点,就好像接力赛一样。

    pic

    节点跟节点之间传递的是什么呢?

    Path数据结构,主要包含(rows, startup_cost, total_cost)。一个数据节点

    rows,表示这个节点有多少满足条件的行,输出到下一个节点。

    startup_cost,表示这个节点得到第一条符合条件的记录,需要多少成本。

    total_cost,表示这个节点得到所有符合条件的记录,需要多少成本。

    执行节点有哪些种类

    执行节点的种类很多,可以从成本计算的代码中得到:

    src/backend/optimizer/path/costsize.c

    /*  
     * cost_seqscan  
     *        Determines and returns the cost of scanning a relation sequentially.  
     *  
     * 'baserel' is the relation to be scanned  
     * 'param_info' is the ParamPathInfo if this is a parameterized path, else NULL  
     */  
    cost_seqscan(Path *path, PlannerInfo *root, RelOptInfo *baserel, ParamPathInfo *param_info)  
      
    /*  
     * cost_samplescan  
     *        Determines and returns the cost of scanning a relation using sampling.  
     *  
     * 'baserel' is the relation to be scanned  
     * 'param_info' is the ParamPathInfo if this is a parameterized path, else NULL  
     */  
    cost_samplescan(Path *path, PlannerInfo *root, RelOptInfo *baserel, ParamPathInfo *param_info)  
      
    /*  
     * cost_gather  
     *        Determines and returns the cost of gather path.  
     *  
     * 'rel' is the relation to be operated upon  
     * 'param_info' is the ParamPathInfo if this is a parameterized path, else NULL  
     * 'rows' may be used to point to a row estimate; if non-NULL, it overrides  
     * both 'rel' and 'param_info'.  This is useful when the path doesn't exactly  
     * correspond to any particular RelOptInfo.  
     */  
    cost_gather(GatherPath *path, PlannerInfo *root, RelOptInfo *rel,   
    ParamPathInfo *param_info, double *rows)  
      
    /*  
     * cost_gather_merge  
     *        Determines and returns the cost of gather merge path.  
     *  
     * GatherMerge merges several pre-sorted input streams, using a heap that at  
     * any given instant holds the next tuple from each stream. If there are N  
     * streams, we need about N*log2(N) tuple comparisons to construct the heap at  
     * startup, and then for each output tuple, about log2(N) comparisons to  
     * replace the top heap entry with the next tuple from the same stream.  
     */  
    cost_gather_merge(GatherMergePath *path, PlannerInfo *root, RelOptInfo *rel,   
    ParamPathInfo *param_info, Cost input_startup_cost, Cost input_total_cost, double *rows)  
      
      
    /*  
     * cost_index  
     *        Determines and returns the cost of scanning a relation using an index.  
     *  
     * 'path' describes the indexscan under consideration, and is complete  
     *              except for the fields to be set by this routine  
     * 'loop_count' is the number of repetitions of the indexscan to factor into  
     *              estimates of caching behavior  
     *  
     * In addition to rows, startup_cost and total_cost, cost_index() sets the  
     * path's indextotalcost and indexselectivity fields.  These values will be  
     * needed if the IndexPath is used in a BitmapIndexScan.  
     *  
     * NOTE: path->indexquals must contain only clauses usable as index  
     * restrictions.  Any additional quals evaluated as qpquals may reduce the  
     * number of returned tuples, but they won't reduce the number of tuples  
     * we have to fetch from the table, so they don't reduce the scan cost.  
     */  
    cost_index(IndexPath *path, PlannerInfo *root, double loop_count, bool partial_path)  
      
    /*  
     * cost_bitmap_heap_scan  
     *        Determines and returns the cost of scanning a relation using a bitmap  
     *        index-then-heap plan.  
     *  
     * 'baserel' is the relation to be scanned  
     * 'param_info' is the ParamPathInfo if this is a parameterized path, else NULL  
     * 'bitmapqual' is a tree of IndexPaths, BitmapAndPaths, and BitmapOrPaths  
     * 'loop_count' is the number of repetitions of the indexscan to factor into  
     *              estimates of caching behavior  
     *  
     * Note: the component IndexPaths in bitmapqual should have been costed  
     * using the same loop_count.  
     */  
    cost_bitmap_heap_scan(Path *path, PlannerInfo *root, RelOptInfo *baserel,   
    ParamPathInfo *param_info, Path *bitmapqual, double loop_count)  
      
    /*  
     * cost_bitmap_tree_node  
     *              Extract cost and selectivity from a bitmap tree node (index/and/or)  
     */  
    cost_bitmap_tree_node(Path *path, Cost *cost, Selectivity *selec)  
      
      
    /*  
     * cost_bitmap_and_node  
     *              Estimate the cost of a BitmapAnd node  
     *  
     * Note that this considers only the costs of index scanning and bitmap  
     * creation, not the eventual heap access.  In that sense the object isn't  
     * truly a Path, but it has enough path-like properties (costs in particular)  
     * to warrant treating it as one.  We don't bother to set the path rows field,  
     * however.  
     */  
    cost_bitmap_and_node(BitmapAndPath *path, PlannerInfo *root)  
      
      
    /*  
     * cost_bitmap_or_node  
     *              Estimate the cost of a BitmapOr node  
     *  
     * See comments for cost_bitmap_and_node.  
     */  
    cost_bitmap_or_node(BitmapOrPath *path, PlannerInfo *root)  
      
      
    /*  
     * cost_tidscan  
     *        Determines and returns the cost of scanning a relation using TIDs.  
     *  
     * 'baserel' is the relation to be scanned  
     * 'tidquals' is the list of TID-checkable quals  
     * 'param_info' is the ParamPathInfo if this is a parameterized path, else NULL  
     */  
    cost_tidscan(Path *path, PlannerInfo *root, RelOptInfo *baserel,   
    List *tidquals, ParamPathInfo *param_info)  
      
      
    /*  
     * cost_subqueryscan  
     *        Determines and returns the cost of scanning a subquery RTE.  
     *  
     * 'baserel' is the relation to be scanned  
     * 'param_info' is the ParamPathInfo if this is a parameterized path, else NULL  
     */  
    cost_subqueryscan(SubqueryScanPath *path, PlannerInfo *root,   
    RelOptInfo *baserel, ParamPathInfo *param_info)  
      
      
    /*  
     * cost_functionscan  
     *        Determines and returns the cost of scanning a function RTE.  
     *  
     * 'baserel' is the relation to be scanned  
     * 'param_info' is the ParamPathInfo if this is a parameterized path, else NULL  
     */  
    cost_functionscan(Path *path, PlannerInfo *root, RelOptInfo *baserel, ParamPathInfo *param_info)  
      
      
    /*  
     * cost_tablefuncscan  
     *        Determines and returns the cost of scanning a table function.  
     *  
     * 'baserel' is the relation to be scanned  
     * 'param_info' is the ParamPathInfo if this is a parameterized path, else NULL  
     */  
    cost_tablefuncscan(Path *path, PlannerInfo *root, RelOptInfo *baserel, ParamPathInfo *param_info)  
      
      
    /*  
     * cost_valuesscan  
     *        Determines and returns the cost of scanning a VALUES RTE.  
     *  
     * 'baserel' is the relation to be scanned  
     * 'param_info' is the ParamPathInfo if this is a parameterized path, else NULL  
     */  
    cost_valuesscan(Path *path, PlannerInfo *root, RelOptInfo *baserel, ParamPathInfo *param_info)  
      
      
    /*  
     * cost_ctescan  
     *        Determines and returns the cost of scanning a CTE RTE.  
     *  
     * Note: this is used for both self-reference and regular CTEs; the  
     * possible cost differences are below the threshold of what we could  
     * estimate accurately anyway.  Note that the costs of evaluating the  
     * referenced CTE query are added into the final plan as initplan costs,  
     * and should NOT be counted here.  
     */  
    cost_ctescan(Path *path, PlannerInfo *root, RelOptInfo *baserel, ParamPathInfo *param_info)  
    cost_namedtuplestorescan(Path *path, PlannerInfo *root,   
    RelOptInfo *baserel, ParamPathInfo *param_info)  
      
      
    /*  
     * cost_recursive_union  
     *        Determines and returns the cost of performing a recursive union,  
     *        and also the estimated output size.  
     *  
     * We are given Paths for the nonrecursive and recursive terms.  
     */  
    cost_recursive_union(Path *runion, Path *nrterm, Path *rterm)  
      
      
    /*  
     * cost_sort  
     *        Determines and returns the cost of sorting a relation, including  
     *        the cost of reading the input data.  
     *  
     * If the total volume of data to sort is less than sort_mem, we will do  
     * an in-memory sort, which requires no I/O and about t*log2(t) tuple  
     * comparisons for t tuples.  
     *  
     * If the total volume exceeds sort_mem, we switch to a tape-style merge  
     * algorithm.  There will still be about t*log2(t) tuple comparisons in  
     * total, but we will also need to write and read each tuple once per  
     * merge pass.  We expect about ceil(logM(r)) merge passes where r is the  
     * number of initial runs formed and M is the merge order used by tuplesort.c.  
     * Since the average initial run should be about sort_mem, we have  
     *              disk traffic = 2 * relsize * ceil(logM(p / sort_mem))  
     *              cpu = comparison_cost * t * log2(t)  
     *  
     * If the sort is bounded (i.e., only the first k result tuples are needed)  
     * and k tuples can fit into sort_mem, we use a heap method that keeps only  
     * k tuples in the heap; this will require about t*log2(k) tuple comparisons.  
     *  
     * The disk traffic is assumed to be 3/4ths sequential and 1/4th random  
     * accesses (XXX can't we refine that guess?)  
     *  
     * By default, we charge two operator evals per tuple comparison, which should  
     * be in the right ballpark in most cases.  The caller can tweak this by  
     * specifying nonzero comparison_cost; typically that's used for any extra  
     * work that has to be done to prepare the inputs to the comparison operators.  
     *  
     * 'pathkeys' is a list of sort keys  
     * 'input_cost' is the total cost for reading the input data  
     * 'tuples' is the number of tuples in the relation  
     * 'width' is the average tuple width in bytes  
     * 'comparison_cost' is the extra cost per comparison, if any  
     * 'sort_mem' is the number of kilobytes of work memory allowed for the sort  
     * 'limit_tuples' is the bound on the number of output tuples; -1 if no bound  
     *  
     * NOTE: some callers currently pass NIL for pathkeys because they  
     * can't conveniently supply the sort keys.  Since this routine doesn't  
     * currently do anything with pathkeys anyway, that doesn't matter...  
     * but if it ever does, it should react gracefully to lack of key data.  
     * (Actually, the thing we'd most likely be interested in is just the number  
     * of sort keys, which all callers *could* supply.)  
     */  
    cost_sort(Path *path, PlannerInfo *root, List *pathkeys,   
    Cost input_cost, double tuples, int width, Cost comparison_cost, int sort_mem, double limit_tuples)  
      
      
    /*  
     * cost_append  
     *        Determines and returns the cost of an Append node.  
     *  
     * We charge nothing extra for the Append itself, which perhaps is too  
     * optimistic, but since it doesn't do any selection or projection, it is a  
     * pretty cheap node.  
     */  
    cost_append(Path *path, List *subpaths, int num_nonpartial_subpaths)  
      
    /*  
     * cost_merge_append  
     *        Determines and returns the cost of a MergeAppend node.  
     *  
     * MergeAppend merges several pre-sorted input streams, using a heap that  
     * at any given instant holds the next tuple from each stream.  If there  
     * are N streams, we need about N*log2(N) tuple comparisons to construct  
     * the heap at startup, and then for each output tuple, about log2(N)  
     * comparisons to replace the top entry.  
     *  
     * (The effective value of N will drop once some of the input streams are  
     * exhausted, but it seems unlikely to be worth trying to account for that.)  
     *  
     * The heap is never spilled to disk, since we assume N is not very large.  
     * So this is much simpler than cost_sort.  
     *  
     * As in cost_sort, we charge two operator evals per tuple comparison.  
     *  
     * 'pathkeys' is a list of sort keys  
     * 'n_streams' is the number of input streams  
     * 'input_startup_cost' is the sum of the input streams' startup costs  
     * 'input_total_cost' is the sum of the input streams' total costs  
     * 'tuples' is the number of tuples in all the streams  
     */  
    cost_merge_append(Path *path, PlannerInfo *root, List *pathkeys,   
    int n_streams, Cost input_startup_cost, Cost input_total_cost, double tuples)  
      
      
    /*  
     * cost_material  
     *        Determines and returns the cost of materializing a relation, including  
     *        the cost of reading the input data.  
     *  
     * If the total volume of data to materialize exceeds work_mem, we will need  
     * to write it to disk, so the cost is much higher in that case.  
     *  
     * Note that here we are estimating the costs for the first scan of the  
     * relation, so the materialization is all overhead --- any savings will  
     * occur only on rescan, which is estimated in cost_rescan.  
     */  
    cost_material(Path *path, Cost input_startup_cost,   
    Cost input_total_cost, double tuples, int width)  
      
    /*  
     * cost_agg  
     *              Determines and returns the cost of performing an Agg plan node,  
     *              including the cost of its input.  
     *  
     * aggcosts can be NULL when there are no actual aggregate functions (i.e.,  
     * we are using a hashed Agg node just to do grouping).  
     *  
     * Note: when aggstrategy == AGG_SORTED, caller must ensure that input costs  
     * are for appropriately-sorted input.  
     */  
    cost_agg(Path *path, PlannerInfo *root, AggStrategy aggstrategy,   
    const AggClauseCosts *aggcosts, int numGroupCols, double numGroups, Cost input_startup_cost, Cost input_total_cost, double input_tuples)  
      
      
    /*  
     * cost_windowagg  
     *              Determines and returns the cost of performing a WindowAgg plan node,  
     *              including the cost of its input.  
     *  
     * Input is assumed already properly sorted.  
     */  
    cost_windowagg(Path *path, PlannerInfo *root, List *windowFuncs,   
    int numPartCols, int numOrderCols, Cost input_startup_cost, Cost input_total_cost, double input_tuples)  
      
      
    /*  
     * cost_group  
     *              Determines and returns the cost of performing a Group plan node,  
     *              including the cost of its input.  
     *  
     * Note: caller must ensure that input costs are for appropriately-sorted  
     * input.  
     */  
    cost_group(Path *path, PlannerInfo *root, int numGroupCols, double numGroups,  
                       Cost input_startup_cost, Cost input_total_cost,  
                       double input_tuples)  
      
      
    /*  
     * cost_subplan  
     *              Figure the costs for a SubPlan (or initplan).  
     *  
     * Note: we could dig the subplan's Plan out of the root list, but in practice  
     * all callers have it handy already, so we make them pass it.  
     */  
    cost_subplan(PlannerInfo *root, SubPlan *subplan, Plan *plan)  
      
      
    /*  
     * cost_rescan  
     *              Given a finished Path, estimate the costs of rescanning it after  
     *              having done so the first time.  For some Path types a rescan is  
     *              cheaper than an original scan (if no parameters change), and this  
     *              function embodies knowledge about that.  The default is to return  
     *              the same costs stored in the Path.  (Note that the cost estimates  
     *              actually stored in Paths are always for first scans.)  
     *  
     * This function is not currently intended to model effects such as rescans  
     * being cheaper due to disk block caching; what we are concerned with is  
     * plan types wherein the executor caches results explicitly, or doesn't  
     * redo startup calculations, etc.  
     */  
    cost_rescan(PlannerInfo *root, Path *path, Cost *rescan_startup_cost,      /* output parameters */  
                            Cost *rescan_total_cost)  
      
      
    /*  
     * cost_qual_eval  
     *              Estimate the CPU costs of evaluating a WHERE clause.  
     *              The input can be either an implicitly-ANDed list of boolean  
     *              expressions, or a list of RestrictInfo nodes.  (The latter is  
     *              preferred since it allows caching of the results.)  
     *              The result includes both a one-time (startup) component,  
     *              and a per-evaluation component.  
     */  
    cost_qual_eval(QualCost *cost, List *quals, PlannerInfo *root)  
      
      
    /*  
     * cost_qual_eval_node  
     *              As above, for a single RestrictInfo or expression.  
     */  
    cost_qual_eval_node(QualCost *cost, Node *qual, PlannerInfo *root)  
      
      
      
    cost_qual_eval_walker(Node *node, cost_qual_eval_context *context)  

    想不想知道是什么



    展开全文
  • 为了实现地质条件复杂多变情况下连采工作面设备选型的科学化、智能化和快速化,根据现场经验和统计数据提出了连采工作面设备选型评价准则,使连采工作面设备选型标准更加定量化,并借助LabVIEW设计了连采工作面设备选型...
  • 1.数据库选型 2.XCode组件分库技术 3.现有数据库的数据统计情况  本博客所有文章分类的总目录:【总目录】本博客博文总目录-实时更新 开源C#彩票数据资料库系列文章总目录:【目录】C#搭建足球赛事资料库与预测...
  • 主要记录迁移前期准备工具选型模型变更:开发环境程序对应修改sql语句准备sqlserver查询全表大字段: 工具选型 模型变更: 1.使用powerdesigner进行反向生成pdm...3.准备sqlsever把数据测试,使数据库脱敏 4.使用ETL
  • MySQL 基础建设之硬盘篇 随着业务的不断增长,之前的环境越来越乱,由此欲重建整个MySQL数据库基础环境 主要目的是要考虑 数据冗余、性能、平衡 目的是让机器的性能最大的发挥,同时比较好维护 一、硬件选型 1....
  • 为了能快速、准确地依据不同煤层地质条件选择适宜的连采设备,根据现场经验和统计数据总结出连采设备选型配套依据,使连采设备选型标准更加定量化,并借助Lab VIEW编程工具实现程序化设计,通过调用程序,从设备数据库中...
  • 但是最近发现某些表数据达到500W+以后查询统计性能严重下降,高峰时段出现了很多SQL阻塞的情况例如:这种阻塞带来的灾难是滚雪球的,由于越堆越多基本上把数据库已经拖死,所以我们就面临数据库切分的问题。技术选型 ...
  • mongoDB和mysql对比分析及选型

    千次阅读 2019-04-18 10:38:48
      下图是DB-Engines2017年8月数据库的排名统计,可以看到MongoDB总排名在第5,在Nosql数据库中排名第1。 优点: 1)社区活跃,用户较多,应用广泛。 2)MongoDB在内存充足的情况下数据都放入内存且有完整的索引...
  • 有一类“多KEY”特征的业务,典型代表是“订单中心”,业务查询维度会覆盖order_id/buyer_id/seller_id,这个业务场景,随着用户数据量越来越大,数据库性能显著降低,如何来对订单中心业务进行水平切分是本章的重点...
  • 我们知道,报表呈现的数据常常并不是直接从数据库(源)取出来的数据,而还要进行一些运算,报表工具通常也会提供一定的运算能力(如过滤、分组等)以应对这种需求。但是,情况复杂时,报表数据集上的运算可能要多个...
  • 我们知道,报表呈现的数据常常并不是直接从数据库(源)取出来的数据,而还要进行一些运算,报表工具通常也会提供一定的运算能力(如过滤、分组等)以应对这种需求。但是,情况复杂时,报表数据集上的运算可能要多个步骤...
  • 我们知道,报表呈现的数据常常并不是直接从数据库(源)取出来的数据,而还要进行一些运算,报表工具通常也会提供一定的运算能力(如过滤、分组等)以应对这种需求。但是,情况复杂时,报表数据集上的运算可能要多个...
  • 我们知道,报表呈现的数据常常并不是直接从数据库(源)取出来的数据,而还要进行一些运算,报表工具通常也会提供一定的运算能力(如过滤、分组等)以应对这种需求。但是,情况复杂时,报表数据集上的运算可能要多个步骤...
  • 我们知道,报表呈现的数据常常并不是直接从数据库(源)取出来的数据,而还要进行一些运算,报表工具通常也会提供一定的运算能力(如过滤、分组等)以应对这种需求。但是,情况复杂时,报表数据集上的运算可能要多个...
  • 我们知道,报表呈现的数据常常并不是直接从数据库(源)取出来的数据,而还要进行一些运算,报表工具通常也会提供一定的运算能力(如过滤、分组等)以应对这种需求。但是,情况复杂时,报表数据集上的运算可能要多个...
  • 我们知道,报表呈现的数据常常并不是直接从数据库(源)取出来的数据,而还要进行一些运算,报表工具通常也会提供一定的运算能力(如过滤、分组等)以应对这种需求。但是,情况复杂时,报表数据集上的运算可能要多个...

空空如也

空空如也

1 2 3 4
收藏数 71
精华内容 28
关键字:

数据库选型统计数据