首页 > 代码库 > 数据库选型
数据库选型
我觉得首先来看一看今天企业里面经常谈的一个问题就是整合的问题。为什么会谈到整合的问题，因为整合就是你现在有很多没有被整合的东西，所以是信息孤岛，因为有信息孤岛的存在，所以需要整合。反过来讲为什么信息孤岛会存在，谁都没有希望在建系统的时候要把它做成一个孤岛。原因在于很多时候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：数据库并发写入性能比拼
最近听说了很多关于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就是瓶颈
数据库选型