数据库选型

时间 2019-11-26

标签数据库选型栏目 SQL 繁體版

原文原文链接

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

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

主要对比mysql和hbase，mongodb没用过。mysql在小型数据上仍是表现的不错的，可是当数据一大，mysql扩展能力和以后的运维都是将面对的问题。目前500w左右数据，天天增量5w，一年就是1850w，固然短时间内，好比两三年几千万数据，是能够用mysql来处理的。可是以后数据累积到必定量后，mysql避免不了分表分库，一次多表联合查询的效率是很是低的。若是mysql没法扩展后须要迁移数据，也要耗费大量开销，人，物，时间。

而hbase是面向列的存储，全部文件以hdfs做为存储空间，读写文件在磁盘上是连续的，这样能够充分发挥io吞吐能力，所以在读写方面hbase是很是快的。使用hdfs为存储空间的一个好处是，能够经过增长廉价服务器来提升hbase的容量和计算能力。

还有一点，题主有大数据分析的需求，难道用几百台mysql就能够进行大数据分析？那，还用hadoop干啥？

hbase周边产品也不断发展和完善中，好比hive on hbase，phoenix on hbase等能够直接写sql语句来操做hbase，大大下降了hbase的学习成本。
最后，推荐题主去google下，hbase replace 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条左右的数据。想把这些数据存储起来，供往后的数据分析用？使用上面说的三种数据库中的哪中比较好？是否有必要创建集群？python

我的见解是：从长远角度看，因为单台机器的性能瓶颈，后期确定要作集群，单纯的作复制最终也没法缓解单台master上读的负担。所以，使用mysql的话会使用cluser。可是了解到mysql的cluser要用好的化还要作负载均衡，而mysql的均衡器是第三方的，没法很好的与mysql整合。使用mongodb的自动分片集群能很好的解决这个问题，并且它的读写性能也快。Hbase提供了大数据存储的解决方案。mysql

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

咱们的需求是作一个数据仓库，不是线上数据，便是OLAP。数据来源是不少的线上数据库（咱们用的是mysql），每隔一段时间会同步数据过来（大概是几天的样子）。这些数据将用于往后的数据分析。所以，对实时性要求不是很高。mongodb

答案：数据库

百万级的数据，不管侧重OLTP仍是OLAP，固然就是MySql了。json

过亿级的数据，侧重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。。

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是否是既能解决关系型数据库，也能够解决非关系型数据库呢？为何？
固然不能，互联网进修越是数据对象的特色愈来愈复杂，很难再靠一瓶万金油抹全身。

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。

6.对于数据中心而言，到底哪一个成为性能的最大瓶颈？是CPU利用率仍是数据库的性能？
我的见解数据库的性能仍是最大瓶颈。cpu利用率通常不高。

之前在几个公司用过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就是瓶颈