大家要注意到去IOE当前本质已经是变化为解决数据库层面的问题，对于应用服务器和中间件，采用X86服务器和负载均衡，集群技术本身已经不存在太大的问题。包括起可靠性，可扩展性和性能等。当前我们看到的很多应用本身也是应用服务器层基本全部X86+虚拟化，而对于数据库往往还在使用小型机和集中存储。
现在的高性能的X86服务器性能已经赶上了3，4年前的中端小型机性能。比如现在的6到8C，8核高配的X86服务器性能能够达到80-100万TPMC，而3年前的中端小型机性能也就60万TPMC的样子。对于小型机的替代大家最关心的问题仍然是高可用性，小型机基本可以达到5个9的高可用性，而现在随着类似至强7500等X86服务器引入了大量在小型机中才使用到的RAS技术，基本达到4个9是没有太大问题的。
还有就是小型机的纵向扩展能力相当强，比如CPU可以最多扩展到24个，而对于X86服务器则是希望通过横向扩展来应对小型机的纵向扩展能力。而横向扩展自然带来的一个问题就是分布式的问题。
对于数据库层面，拿MySQL数据库来和Oracle数据库做一个比较，当前第三方的评测是在相同的硬件配置条件下两个数据库的性能和Benchmark数据库相当。而实际上对于数据库层面我们更加关心的还是在海量数据下的复杂事务处理能力。如果对于存储大表数据都在千万行级别一下，可以说两个数据库可能不会出现太明显的差距。而如果对于大于千万或上亿数据的海量数据OLTP处理上，Oracle估计还是具备有明显的优势。而对于这一个问题的解决，根据互联网企业的经验，仍然是通过数据库的水平拆分和垂直拆分来解决这个问题。
类似EMC提供的集中存储是另外一个重要的话题，可以看到在使用集中存储的时候，我们很容易去实现类似Oracle的RAC集群，同时本身集中SAN,NAS存储也具备更高的存储高可用性和高可靠性。类似互联网企业淘宝也曾经谈到过，在采用廉价的本地磁盘存储后，由于大量的IO磁盘读写也经常出现硬盘挂掉的情况。虽然这些可以通过RAID技术来避免单独故障，但是对于存储的高可靠性确实本地存储赶不上集中存储。
由于在去小型机，Oracle数据库和集中存储情况下，将直接转换为数据库层的构建成为一个share nothing的分布式数据库集群。而现在的MPP+Share nothing的New SQL数据库，类似Greenpulm，Vertica，Hive等更多的都是解决OLAP层面的问题。而对于去IOE首先需要解决的是联机事务处理层面的事情。
那么对于Share nothing的分布式数据库，当前也有类似Mysql Cluster技术来支撑，但是这种分布式数据库虽然做到了高可靠性，但是由于需要支撑CUD操作，导致这种集群很难达到满足实际应用需求的存储容量和业务高性能。在实际的业务应用场景下，除了少量的类似MDM主数据场景比较适合采用外，真正的核心的大量业务操作和逻辑处理场景往往并不适合。
基于这种情况，当前最常用的技术就变化为了对数据库进行水平拆分和垂直拆分，但是这种拆分我们希望的是对应用层透明，因此在数据库上面引入了一个核心的DaaS服务层。但是当前的DaaS服务层很难做到数据库的完全透明，同时对于上层的应用构建造成一定的约束。包括有些跨库的Sql语句，类似跨库聚合Group By等的语句不支持，这些都需要应用层自己去解决。
在跨库后带来的一个重要问题就是分布式事务的问题，对于DaaS来说可以解决部分分布式事务的问题，但是需要采用严格的XA两阶段提交来解决分布式事务，本身的高可靠性和一致性仍然需要进一步进行验证。而对于应用，仍然需要应用去解决一些分布式事务的问题，即通过事务补偿，BASE方法等去解决分布式事务的问题，这些本质上都是削弱了对高一致性的支持，这也是CAP定量经常说的，在一个分布式的系统中很难真正做到三者全部满足。在满足高可用性和分区容错性的基础上，往往需要牺牲一定的高一致性。
由于采用数据库拆分和DaaS层，对于应用层的应用构建将带来比较大的变化，特别是很多原来数据库没有拆分的时候一个SQL就搞定的问题，一个通过数据库层事务就能解决的问题，都会变成了分布式事务问题，或者多次调用服务操作才能够解决的问题。这往往才是说的去IOE的一个关键。
