随着数据存储技术的迅猛发展，随着各种 NoSQL 技术的产生，无论是我们同事之间还是整个互联网行业，都出现关于“分布式 数据 存储/处理 解决方案”方面的选择分歧。就我目前所了解到的主流意见主要有以下三种：
- 去关系型，NoSQL是王道
- NoSQL靠边站，关系型才是王道
- 以关系型为核心，NoSQL为补充
三种意见中前面两种观点较为极端，都是“非对即错”的选择，当然也有更为理性的第三种方案。
如果作为开发人员，从我目前所了解的信息来看，主要还是倾向于第一种思路。因为在他们看来，分布式的 NoSQL 系统是一个非常美的架构，不仅仅解决了扩展性的问题，同时也解决了可靠性问题，同时还可以让程序开发免去关系型模型的约束，不选择他才是傻子呢！
从我个人的角度来看，我目前更倾向于第三种思路，至少在现阶段是如此。
Why？
但是如果是从运维的角度出发，所考虑的风险点可能完全不一样。作为一个存储数据的核心组件，在需要对其数据进行人工订正维护的时候是否方便操作？在需要抽取其中某部分数据到线下给开发/测试部门使用的时候是否方便？最重要的是，当他整个 Crash 之后我们可以怎么恢复？当我们面对这些问题的时候，我们是否有合适便利的手段来避免或者解决？
确实，理念很完美，架构很完美，但目前的NoSQL产品的实现是不是真的也如此完美呢？我想没有哪个产品敢拍着自己的胸脯说他们的产品不会Crash，就像没有厂商向我们保证他们的硬件在达到标称的使用寿命之前不会损坏一样。既然存在整个 Crash 的可能，那就必须考虑如何应对。我们不能只是考虑这个听上去完美的分布式系统在某个节点 Crash 之后可以很好的”自愈”，不能只考虑当目前整个集群资源达到瓶颈之后仅仅只需要在线增加一个节点就可以”自我完成负载/数据重分布”。我们还需要考虑他的整体可靠性，还需要考虑更为恶劣的环境更为残酷的场景下，他是否还能生存。
关系型数据库在刚开始产生的时候，同样面临了各种各样的问题，同样受到过大量的质疑。但是，当他在风风雨雨中走过了这么多年之后，通过不断的完善和适应，不论在灾难恢复方面还是在可操作性和可维护性方面都做了大量的工作。当然，在这么多年的市场需求下，也培养出了大量的专业技术人员。但 NoSQL 发展到现在，才经历了很短的时间，缺少在恶劣环境下的磨炼，缺少复杂环境下的检验，更缺少有丰富经验的专业技术人员。在这种情况下，你还敢轻易决定将一个公司最为核心的资本（数据）轻易从关系型数据库中迁移出来吗？
当然，我们并不一定要一个完美的产品，就像我们无法让我们自己成为一个完美的人一样。但我们必须清楚一个产品的可能存在的风险和缺陷，并且清楚如何做能避免这些风险和缺陷，同时还要让我们自己有能力避免这些风险和缺陷。只有在这样的前提下，我们才会在比较重要的场景下使用。但要积累这些经验，积累这些信任，培养专业技术人员，都需要一定的时间。
所以在我个人看来，在近几年，NoSQL 暂时还不可能成为数据管理软件领域的主角，仍然只能作为特定场景下的数据存/取解决方案的补充，即使在互联网行业也是如此。至于在未来，比如五年十年以后会是什么样子，我就无法预测了。
注：文中观点仅代表个人，基于个人目前的认知，欢迎大家拍砖！
时常遇到一些希望从多个 MySQL 实例将数据复制到单个MySQL 实例上的需求场景，又苦于原生的 MySQL 并不支持这样的实现方案，开源社区中也没有哪位大拿提供解决这方面需求的插件。 有时候就想，要不公司里面组织力量修改一下 MySQL 代码来搞定这个问题得了。可转念一想，后面如果需要升级版本的时候怎么办呢？再修改一次代码？这样的成本有多大呢？如此的问题让人很是纠结。 最近突然想明白了：为啥非要在现在代码中来实现这个需求呢？为啥不能通过在外部想办法呢？我们需要的不是看上去的美，而是最终的结果。看上去漂亮完美的架构方案并不一定就是最好的。 如是就有了下面这样的想法：
- 通过在 Master 和 Slave 之间增加一层复制代理服务
- 多个线程连接上多个 Master 上请求 Binlog（完全模拟 Slave 上的IO线程）
- 多个线程连接上单个 Slave 实例，直接以类似于应用程序的方式并行应用 Binlog中的Event（部分模拟Slave 上的SQL线程）
- 由于很清楚业务场景，在应用线程方面可以在一些特定规则约束下实现并行应用以改善 Slave 端延时
由于 MySQL 开源的特性，实现上述功能其实很简单，还可以保持原生 MySQL 不会被动任何手术即可完成我们的需求，看来是该动手的时候了。
BTW： 我的需求中，各个 Master 中的数据是不会有任何重叠的。
前几天，受 Oracle 所遥，在 OOW 上的 OTN Lounge 分享了一下最近一年来在利用MySQL 在高可用可扩展架构方面的一些心得，这里贴上 PPT，供大家拍砖。
内容方面，前面的部分可能有不少朋友以前有看到过，可能是听我介绍过，也有可能本身自己就对这些架构很了解。无所谓，只要能对一少部分人有用，那也欣慰。不过，最后两页 PPT 的内容，我想肯定没有人在其他渠道见过，因为这两张图片是我第一次在公开场合展示。
废话少说，上 PPT 吧，呵呵！
今天，Oracle（甲骨文）公司的 Oracle Open World / Java One / Oracle Developer 北京大会今天开幕。
大会从13号到16号，共4天，今天上午主要是大会注册时间。由于参会人员众多，Oracle 安排了半天时间用于参会者注册报道。我较早就到达了现场，看到为排队准备的临时隔离绳早已准备好，还有十多个安检通道。看这阵式，等下的注册场面一定很火爆。
今年的大会上，OTN 组织了一次 Oracle ACE 大聚会（OTN Lounge），并有精彩演讲安排。我在里面也安排了一个主题演讲，安排在 15 号（周三）上午。此外还有 Oracle 数据库方面的很多专家如冯春培，盖国强，楼方鑫，张乐奕等，还包括阿里巴巴公司一位经常与我协作的高级 Java 工程师 贺贤懋。
OTN Lounge 的具体日程安排如下：
MySQL, OOW, oracle
最近一直在测试一款让我非常兴奋的存储介质： Fusion IO 的 ioDrive。他在随机小IO的方面的表现，实在是让我吃惊，可以轻松达到100k左右的单一读（或者写）（注意是写也可以达到这个数据） IOPS，读写混合也可以达到 50k～60k左右的IOPS，而且这个 IOPS 数据还是在响应时间低于5ms 的情况下的数据。而实际上，当 IOPS 达到50k 的时候，响应时间仍然低于1ms。
注：测试工具为 orion/fio/iometer
100K 的 IOPS 是一个什么概念？
假如我们使用 15k 转速的 SAS 磁盘来对比，每块磁盘的 IOPS 大概 150 左右，那么一块 ioDrive 的 IOPS 表现就相当于 100k/150=666.66 块 15k 转速的 SAS 磁盘并行的能力，而且每个 IOPS 的响应时间还得 5～7ms（机械原理决定） 。这样的 IOPS 能力，恐怕也只有 EMC ， HDS 等高端存储厂商们的顶级存储设备才能够达到如此高的 IOPS 性能了。
ioDrive 为啥能达到如此之高的 IOPS 而且还能保持极小的响应时间？
- SSD 设备
Fusion IO 的 ioDrive 产品其本质就是当前存储界炒的非常热的 SSD ，而非传统的机械磁盘。但其他厂商的 SSD 磁盘的性能和 ioDrive 相比，实在是还有一段不小的差距，这是为什么？那就要看下面这个原因了。
- 访问模式的革命性变化
常见的 SSD 设备大多是通过实现标准的 ATA 接口协议，连接在RAID/SAS 等磁盘控制器上，以传统的访问路径提供IO服务。但 Fusion IO 在这一点的处理上与其他人有很大的差异，他们通过在 Linux 内核中增加内核模块，与自己独有的驱动配合，绕过多道传统磁盘需要经由的路径，大大缩短了 IO 操作路径。
二者的IO访问路径可以简单表示如下：
传统的磁盘包括目前大部分的 SSD ： CPU —> 北桥 —> 南桥 —> SAS/RAID 控制器 —> 背板 —> 磁盘（SSD/机械盘）。
Fusion IO 的 ioDrive： CPU —> 北桥 —> PCIe 控制器 —> ioDrive
可以看出，ioDrive 减少了 “—> 南桥 —> SAS/RAID 控制器 —> 背板” 这一过程，所以在响应时间上肯定有较大优势。而且，这一过程上RAID/SAS 控制器可能造成的瓶颈也就不会对 ioDrive 造成任何影响了。
- 原理构造的差异
普通 SSD 磁盘大多包含有自己的芯片用于内部调度计算，但 ioDrive 却使用主机的CPU来进行调度，对于大多数 IO 密集型系统来说，CPU 资源总是会有较大富余，而 ioDrive 正是利用了这一点来更好的利用了主机资源，同时提高了自己的计算能力，因为主机 CPU 的计算能力肯定要比集成在 SSD 磁盘上中的那个小芯片要强很多。
此外其实还有在Firmware上的 IO 调度方面的一些多通道，并行等特殊优化，也给 ioDrive 的高 IOPS 表现带来了很大的帮助。
之前一直不明白为什么 Fusion IO 称他们的 ioDrive 为 ioMemory，当时还以为只是他们在玩概念忽悠人，不过在听了 Brad Pfefer 和 Jens Axboe (http://en.wikipedia.org/wiki/Jens_Axboe) 二人的相关介绍后，总算明白了，确实还是有点道理的。
从我个人的认知来说，ioDrive 确实可以说是一款具有革命性的存储介质产品，或许在不久的将来，io 访问模型都将是如 ioDrive 一样，先自己 YY 一下吧。
