再谈集中和分布
- - 人月神话的BLOG上篇文章转载了关于mysql数据库的垂直和水平拆分的相关内容，本篇文章再谈下关于应用集中化后的集中和分布相关策略问题，以及最近关于完全去IOE思路的一些思考和回顾. 现在有一个问题我暂时还没得到比较明确的一些验证，如对于当前x86的pc
server服务器好的配置完全可以达到200万TPMC，对于磁盘阵列可以挂接到20T甚至更高的存储容量.
再谈集中和分布
标签：
随笔文章
| 发表时间：2013-05-11 20:56 | 作者：人月神话
出处：http://blog.sina.com.cn/cmmi
上篇文章转载了关于mysql数据库的垂直和水平拆分的相关内容，本篇文章再谈下关于应用集中化后的集中和分布相关策略问题，以及最近关于完全去IOE思路的一些思考和回顾。
现在有一个问题我暂时还没得到比较明确的一些验证，如对于当前x86的pc server服务器好的配置完全可以达到200万TPMC，对于磁盘阵列可以挂接到20T甚至更高的存储容量。那么在这种x86架构下的服务器如果仍然采用linux+oracle数据库，是否可以达到和常规小型机和集中存储相当的数据库性能。如果采用linux+mysql数据库，又能够达到多少相当的性能水平。对于mysql单点，如果采用innoDB引擎，在上述的服务器和存储配置情况下能够达到多大的能力？还有就是如果采用mysql的读写分离集群，在读写比例8:2左右的情况下，又能够达到如何的一个性能水平。
对于上述点的思考，主要还是基于能够不拆分尽量不拆分，能够只选择一种拆分尽量不同时使用两种拆分，在集中化的大数据架构规划下，当同时引入两种场景的拆分的时候，整个数据架构异常复杂，同时对应用设计和开发的限制也相当多（包括分布式事务，跨库操作，sql语句）等各个方面。
我们在思考基于云架构下的集中化，但是在集中化后由于本身单点存在的性能瓶颈问题，对于数据节点通过分区和分库后又变化为一个分布式的问题。不能做到对分布节点完全透明情况，也不能做到对分布节点自动化和智能化管理的大量分布就是潜在的大灾难。这种分布没有体现出云的优势，反而引入了大量的问题，将去IOE极端化再次说明只适合与互联网下的大并发弱一致性要求下的业务场景，对于大型企业信息化架构不能全盘采纳。
在集中化后如果大量的进行不合理的分片和分库，可以说是原来未集中前的问题仍然存在，原来不存在的问题也不断的新增加和抛出来。不合理的分区分库还不是简单的对一致性能力的牺牲，更多的是大量分区分库直接导致对复杂业务快速处理的能力的牺牲。
在前面《对数据库架构的再思考》我曾经谈到了关于共享数据库的问题，从现在的分析来看，比较可行的方案仍然是大型应用垂直拆分，同时对于垂直拆分后中各模块需要跨多个模块的数据实时同步到共享的可读库，可读库实时提供共享数据服务。在这种模式下可以大大减轻垂直切分的数据库的读压力，也建设对于垂直切分数据库中表索引的建立和维护。这种读写分离强调的不是单个应用模块的读写分离，而是多个应用模块对共享数据CRUD操作的读写分离。在这种情况下可以看到共享数据库已经变成一个准实时的ODS库，提供准实时的数据读能力。那么在这种情况下可以看到对于跨垂直库多个模块的查询统计和报表功能来说，就是相当简单易实现的了。
对于跨应用模块共享的共享数据查询功能而言，能够采用UI界面集成方式的尽量采用UI界面集成方式，UI界面集成将是垂直应用拆分后对共享数据查询使用的一个极好的复用模式，这种模式大大的降低了底层数据交换，也降低了业务服务的调用，属于一种数据实时查询不落地形成多份拷贝的重要思路。
写库采用IOE方案，而读库迁移为Mysql集群可能是一种在集中化过程中的一种折衷合理方案。对于不存在大量并发写的场景建议都可以采用这种方案。在这种模式下对于写库基本可以不用做任何拆分，或者说可以按大的应用模块做2-3个的垂直拆分就完全满足需要。由于写库全集中，也不进行进一步水平拆分操作，将解决掉大量的应用开发难度和对分布式事务处理和投入。
前面有文章我曾经谈到过应用本身的类型，包括了以数据为核心的应用，也包括了以流程工单为核心的应用。对于以流程为核心的应用而言进行垂直拆分相当简单。而对数据为核心的应用，底层是一个偏厚的全局数据模型，要进行垂直切分就相当困难，但是由于垂直切分困难，你会发现垂直切分的结果很难真正的做到松耦合，这是一个不可回避的问题。
在进行垂直和水平切分后，如果切分的不合理我们看到，对于切分的单数据节点，除了需要满足本应用模块的数据能力提供外，由于切分不合理将需要超外部提供大量的数据服务能力，对于不合理的数据切分，单数据节点的性能压力往往并没有真正降低下来，这个问题一开始我们很容易忽略掉。最后，如果已经进行了数据垂直和水平切分后，单点再出现性能瓶颈的情况下还能有什么方法解决？
青春就应该这样绽放 游戏测试：三国时期谁是你最好的兄弟！！ 你不得不信的星座秘密 
现在有一个问题我暂时还没得到比较明确的一些验证，如对于当前x86的pc server服务器好的配置完全可以达到200万TPMC，对于磁盘阵列可以挂接到20T甚至更高的存储容量。那么在这种x86架构下的服务器如果仍然采用linux+oracle数据库，是否可以达到和常规小型机和集中存储相当的数据库性能。如果采用linux+mysql数据库，又能够达到多少相当的性能水平。对于mysql单点，如果采用innoDB引擎，在上述的服务器和存储配置情况下能够达到多大的能力？还有就是如果采用mysql的读写分离集群，在读写比例8:2左右的情况下，又能够达到如何的一个性能水平。
对于上述点的思考，主要还是基于能够不拆分尽量不拆分，能够只选择一种拆分尽量不同时使用两种拆分，在集中化的大数据架构规划下，当同时引入两种场景的拆分的时候，整个数据架构异常复杂，同时对应用设计和开发的限制也相当多（包括分布式事务，跨库操作，sql语句）等各个方面。
我们在思考基于云架构下的集中化，但是在集中化后由于本身单点存在的性能瓶颈问题，对于数据节点通过分区和分库后又变化为一个分布式的问题。不能做到对分布节点完全透明情况，也不能做到对分布节点自动化和智能化管理的大量分布就是潜在的大灾难。这种分布没有体现出云的优势，反而引入了大量的问题，将去IOE极端化再次说明只适合与互联网下的大并发弱一致性要求下的业务场景，对于大型企业信息化架构不能全盘采纳。
在集中化后如果大量的进行不合理的分片和分库，可以说是原来未集中前的问题仍然存在，原来不存在的问题也不断的新增加和抛出来。不合理的分区分库还不是简单的对一致性能力的牺牲，更多的是大量分区分库直接导致对复杂业务快速处理的能力的牺牲。
在前面《对数据库架构的再思考》我曾经谈到了关于共享数据库的问题，从现在的分析来看，比较可行的方案仍然是大型应用垂直拆分，同时对于垂直拆分后中各模块需要跨多个模块的数据实时同步到共享的可读库，可读库实时提供共享数据服务。在这种模式下可以大大减轻垂直切分的数据库的读压力，也建设对于垂直切分数据库中表索引的建立和维护。这种读写分离强调的不是单个应用模块的读写分离，而是多个应用模块对共享数据CRUD操作的读写分离。在这种情况下可以看到共享数据库已经变成一个准实时的ODS库，提供准实时的数据读能力。那么在这种情况下可以看到对于跨垂直库多个模块的查询统计和报表功能来说，就是相当简单易实现的了。
对于跨应用模块共享的共享数据查询功能而言，能够采用UI界面集成方式的尽量采用UI界面集成方式，UI界面集成将是垂直应用拆分后对共享数据查询使用的一个极好的复用模式，这种模式大大的降低了底层数据交换，也降低了业务服务的调用，属于一种数据实时查询不落地形成多份拷贝的重要思路。
写库采用IOE方案，而读库迁移为Mysql集群可能是一种在集中化过程中的一种折衷合理方案。对于不存在大量并发写的场景建议都可以采用这种方案。在这种模式下对于写库基本可以不用做任何拆分，或者说可以按大的应用模块做2-3个的垂直拆分就完全满足需要。由于写库全集中，也不进行进一步水平拆分操作，将解决掉大量的应用开发难度和对分布式事务处理和投入。
前面有文章我曾经谈到过应用本身的类型，包括了以数据为核心的应用，也包括了以流程工单为核心的应用。对于以流程为核心的应用而言进行垂直拆分相当简单。而对数据为核心的应用，底层是一个偏厚的全局数据模型，要进行垂直切分就相当困难，但是由于垂直切分困难，你会发现垂直切分的结果很难真正的做到松耦合，这是一个不可回避的问题。
在进行垂直和水平切分后，如果切分的不合理我们看到，对于切分的单数据节点，除了需要满足本应用模块的数据能力提供外，由于切分不合理将需要超外部提供大量的数据服务能力，对于不合理的数据切分，单数据节点的性能压力往往并没有真正降低下来，这个问题一开始我们很容易忽略掉。最后，如果已经进行了数据垂直和水平切分后，单点再出现性能瓶颈的情况下还能有什么方法解决？
青春就应该这样绽放 游戏测试：三国时期谁是你最好的兄弟！！ 你不得不信的星座秘密 相关 [中和 分布] 推荐：
分布式日志
- - Java - 编程语言 - ITeye博客最近完成一个简单的日志管理系统，拿出来跟大家分享一下. 3、支持文件输出、habse输出、mongodb输出. 基于以上三点功能，我们下面详细说明. 说道支持这个功能，有个同事认为没有这个必要，他的观点是log4j的配置不需要经常变动，不需要支持这样的功能；本人的观点是“配置可以进行统一管理、而且正式机跟测试机的log4j的配置肯定会有一些差异的”，因此这个功能是必须的.
分布式事务简述
- If you are thinking one year ahead, you plant rice. If you are thinking twenty years ahead, you plant trees. If you are thinking a hundred years ahead, you educate people. - BlogJava-首页技术区 随着系统越来越大，不断的模块化和SOA化，你的系统可能被分散于不同的机器上，这时候，你原先的单机本地事务可能已经无法满足你的需求，你可能要跨系统跨资源的去使用事务. 具体就不多介绍了，相信大家都能明白ACID特性的基本含义. 而一个具体的事务需要涉及到的模型（无论哪种模型）一般由下面几部分组成：.
Hadoop与分布式计算
- 透明 - 丕子写本文由leftnoteasy发布于http://leftnoteasy.cnblogs.com 本文可以被全部或者部分的使用，但请注明出处，如果有问题，可以联系wheeleast (at) gmail.com, 也可以加作者的新浪微博：http://weibo.com/leftnoteasy. 很久没有写写博客了，之前主要是换工作，耽误了很多的时间，让人也变得懒散，不想花大时间来写东西.
分布式缓存-Memcached
- - 人月神话的BLOG分布式缓存出于如下考虑，首先是缓存本身的水平线性扩展问题，其次是缓存大并发下的本身的性能问题，再次避免缓存的单点故障问题(多副本和副本一致性). 分布式缓存的核心技术包括首先是内存本身的管理问题，包括了内存的分配，管理和回收机制. 其次是分布式管理和分布式算法，其次是缓存键值管理和路由. 原文： http://wenku.baidu.com/view/8686d46c7e21af45b307a8c3.html.
hadoop分布式配置
- - CSDN博客云计算推荐文章一、前面的部分见伪分布式配置. 二、实现SSH无密码登录远程主机（只在源主机上配置）. 注意：以上scp命令表示把authoriezd_keys远程复制到对应主机的相应目录下. slave2是目的主机的名字，需要在源主机的/etc/hosts下配置slave2以及对应的IP地址 192.168.0.5.
浅谈分布式缓存
- - CSDN博客推荐文章在前面的一些文章中，从实战的角度，讲解了有关 memcached的应用、容灾、监控等等. 但是缺乏对理论的讲解和原理性的剖析. 本文将从理论的角度去介绍，让大家从宏观上对“分布式缓存、nosql”等技术有所了解，以便进一步学习和使用. 在构建大规模的web应用时，缓存技术可以说是必备的，学习的必要性不言而喻.
关于分布式事务
- - Web前端 - ITeye博客Mysql当前分布式事务只支持Innodb存储引擎. 1个分布式事务由多个行为在不同的数据库上执行，1个分布式事务的执行成功意味着相关数据库上的行为执行均成功. 使用分布式事务的应用程序设计1个或多个资源管理器和一个事务管理器. 资源管理器(RM):用户提供通向事务的途径. 数据库服务器是一个种资源管理器.
BDRP分布式redis集群
- - 百度运维团队技术博客BDRP（baidu distributed redis platform）是包含 twemproxy， redis，redis-sentinel等多个模块开发的分布式redis平台. bdrp已经在github上进行了开源， bdrp的github项目点这里. 目前redis集群架构主要有以下几个组件：
twemproxy：redis的代理系统，可以选择多种数据分片算法
redis：集群的redis存储节点
sentinel：redis官方的集群高可用组件，可以监控redis主节点故障，并进行主备切换.
分布式搜索算法
- - 杨尚川的个人页面对于搜索引擎来说，索引存放在成千上万台机器上，如何进行分布式搜索呢. 假设搜索结果是以分页的方式显示，以PageNumber代表当前页，从1开始，以PageSize代表页面大小，默认为10，以N代表搜索服务器数量. 最简单的分布式搜索算法为：有一台 合并服务器负责接受用户的搜索请求，然后分别向N台机器获取前PageNumber*PageSize条结果，得到的结果数为N*PageNumber*PageSize，然后把这些数据重新进行排序，根据所要显示的页面PageNumber，获取从(PageNumber - 1) * PageSize + 1开始的PageSize条结果返回给用户.