新浪广告共享计划>
广告共享计划
大数据服务集成
在Oracle SOA套件里面可以看到有类似于Oracle
ODI的大数据服务集成方案，其本质仍然是WS+ETL的能力组合，在我们自研的ESB中准备集成大数据服务能力，即考虑底层采用最新的DataX来进行集成。
其集成的核心思路仍然是将WS和ETL能力进一步结合，同时实现服务调用消息控制流和实际大数据传输数据流的分离。同时通过对服务的调用来实现ETL的实时按需触发和参数化服务调用。
其核心思路如下，在设计期：
1. 需要设计一个SOAP Web
Service服务，该服务的输入有标准的开始时间和截至时间段输入信息，输出有同步完成的数据量，同步Flag状态标准，日志异常信息字段。
2. 将设计完成的Web Service服务在大数据服务总线平台进行注册。
在底层通过DataX来实现TL作业任务，该作业任务使用参数化查询SQL语句对源数据库符合条件的数据进行查询。而具体的参数可以通过在服务调用的时候传入。
4. 具体设计详细的ETL作业任务，包括源和目标数据库的配置，数据映射。
5. 通过配置界面设计服务查询输入和参数化查询SQL之间的数据映射。
6. 通过配置界面设计ETL作业任务结果同服务输出字段之间的数据项映射。
在运行期的调用逻辑如下：
1. 服务消费方调用 ESB总线发布的Web Service服务，传入时间段条件。
2. ESB总线在接收到服务调用请求后，将服务的输入根据已经配置的数据映射传递给ETL作业的参数化查询中。
3. 在完成数据映射后实时启动ETL任务的执行，ESB服务调用过程处于等待状态。
ETL任务执行，将数据从源数据库抽取并同步到目标数据库,整个数据流的集成将在源数据库和目标数据库之间完成，即数据流不通过ESB服务总线以减少ESB总线压力。
5. 在ETL任务完成后获取ETL任务结果信息，并将结果信息返回给ESB服务的服务调用输出中。
6. ESB服务将服务调用输出返回给服务消费方。
整个设计过程我们通过前台可配置的界面来配置完成，即主要是配置服务的输入输出，数据源，数据目标，数据源和数据目标之间的映射关系。根据这些配置信息一方面是进行WS服务的封装和发布，另外一方面则是生成DataX需要的Json配置文件。
当然整个完成的DataX任务也可以通过CronTab来配置定时作业任务进行定时调度。
已投稿到：比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
实时大数据架构
　　数据架构正在成形，并且对快数据的处理与现在所说的处理方法是不同的。在本文中，笔者会阐释企业数据架构的设想，而此架构可以让企业实现对快速数据和大数据的整合。
　　企业大数据架构的基础是Data Lake(数据湖)，或称之为数据池、数据储备库或是其他。很明显，它是企业用来存放其所有数据的场所。此组件并不因为设计和功能上的原因而显得独特，但是它却因为要一切内容而成为一个有着巨大成本效益的系统。从本质上讲，它是一个在廉价商用机器上的分布式文件系统。
　　可能某项技术格外吸引眼球，比如说HDFS或是其他技术，但关键在于，这里汇集了所有数据。此平台将会：
　　1. 存储要发其他数据管理产品的数据
　　2. 支持可以对文件系统数据直接执行任务的框架
　　围绕在Data Lake周围的是一些补充技术，它们可以让人从那些存储在Data Lake中的数据获取认知和价值。它们包括：
　　报表：数据仓库可以出色的执行报告任务，并且可以持续提供此功能。一些数据会导出至那些系统并在那里临时存储，同时会以混合方式从Data Lake直接访问其他数据。这些数据仓库系统是专门设计来执行复杂报告分析的，而且它们也做的非常好。
　　SQL on：这里有着很多的创新。这些产品的目的是取代数据仓库。像Hawq和Impala这样的产品已经有所进步。但毫无疑问的是，对于这些系统要接近数据仓库的速度和效率还有很长的路要走，尤其那些有列式设计的系统。SQL-on-Hadoop系统的存在有两个重要原因：
　　1) SQL仍是在数据上所能取得的最佳方式
　　2) 进行处理并不需要移动大量的数据
　　挖掘分析：这是数据科学家的领域。这些工具为在数据中有所发现提供了某些功能：模式，模糊关系，统计规则等等。Mahout和R语言是此类中的流行工具。
　　MapReduce：通常Hadoop上所有要执行的任务和管理工作都是在MapReduce群组中进行的。如今很多的Hadoop用例都包括在使用上述分析工具之前进行预处理和数据清洗。这都是这些工具和接口所允许的情况。
　　企业应用程序的ETL：最后是ETL流程，它会协助从我们信任的企业应用程序将所有的遗留数据放入存储所有内容的数据池。这些应用程序会逐渐适时地迁移至成熟的快速+大数据应用程序。
　　好的，我们现在有了这些分析……然后呢？
　　我们为何要先做分析呢？很简单，我们想要：
　　● 更好的决策
　　● 更好的个性化
　　● 更好的检测
　　● 更好的交互
　　应用程序要负责交互，并且这是在你可以准确并实时做这些交互时最具价值的改进。这就引出了此架构的第二部分，在这里我们可以更好的处理快速数据，加快实时应用程序。
　　首先要注意的是，快速和大是紧耦合的，尽管它们是独立的系统。至少在规模上它们必是如此。系统是设计来在每秒钟处理数以百万计的事件决策的，这与那些设计用来保存千万亿字节数据并生成扩展报告的系统是截然不同的。
　　快速数据的实质就是产生一定数量的关键需求以最有效地使用它。这些包括的功能有：
　　● 数据种子提取与交互
　　● 对种子中的每个事件做出决策
　　● 利用实时分析为快速移动的数据提供可视性
　　● 无缝集成到设计用来存储大数据的系统中去
　　● 从大数据系统为用户和应用程序快速提供分析结果和知识，同时关闭数据环路。
　　没有比可操作的数据库更好的满足这些需求的技术了。我们过去所面临的挑战是，没有一个可操作的数据库能够管理这种吞吐量。结果，就有一些人用权宜之计来试图满足他们的需求，通常是放弃某些功能并且总是增加了复杂性。
[ 责任编辑：xc ]
去年，手机江湖里的竞争格局还是…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注Chinabyte查看:19128|回复：43
《大数据时代的IT架构设计》读一读，评一评。好书就是你的了
欢迎加入读书频道活动讨论群：这样有问题我们就可以及时沟通了哦
& && &&&既然路过了，就来看看我们的内容，做一下评价吧，也许获得图书的幸运儿就是你哦~~~~~~
图书介绍：
内容简介：
& && && &《大数据时代的IT架构设计》以大数据时代为背景，邀请著名企业中的一线架构师，结合工作中的实际案例展开与架构相关的讨论。《大数据时代的IT架构设计》作者来自互联网、教育、传统行业等领域，分享的案例极其实用，代表了该领域较先进的架构。无论你就职于哪一行业都可以从本书中找到相关的架构经验，对您在今后的架构设计工作中都能起到很好的帮助作用。《大数据时代的IT架构设计》适合具备一定架构基础和架构经验的人阅读。板板推荐：一书在手，架构无忧
　　 三十位一线架构师真知实践
　　 百位顶级架构师献计献策
　　 十万文字尽显架构精华试读链接：购买链接：活动简介：活动时间：日——日活动规则：完整的回答以下问题，就有机会获得图书1.&&Oracle、MySQL&还是NoSQL，作为一个架构师，面对如此众多选择的时候，到底应该依据什么来做出正确的决定呢？2.&面对一个大型复杂系统架构，历经哪几个重要阶段？3.&网站架构设计存在哪些误区？4.&说说读完试读章节后您的感想。&奖品寄送：
由于就最近部分获奖用户不能及时反馈奖品邮寄地址，导致奖品迟迟不能发出，影响了其他用户收奖品，所以我们将会采取以下措施：
活动结束后，我们会通过短消息与获奖用户确定寄送信息，请获奖用户到时注意查收与回复，过时将视为自动放弃获奖资格。晒感言/奖品：
欢迎获奖用户发博文或帖子，晒晒自己的获奖感言和礼物，和我们一起分享成功的喜悦！获奖用户：jimmy_lixw &kyle999 &forgaoqiang &maosdf &yuke198907
本帖最后由 读书频道 于
13:45 编辑
第一时间先支持下活动，然后晚上回去再读好书！
引用:原帖由 cym522 于
16:30 发表
第一时间先支持下活动，然后晚上回去再读好书！ 谢谢支持！！！&&哈哈
小微企业IT帮！我们没有什么不同~ ...
1. &Oracle、MySQL 还是NoSQL，作为一个架构师，面对如此众多选择的时候，到底应该依据什么来做出正确的决定呢？对此我目前还没有很好的方法来断定选择什么样的数据库，想必书中会有较好的判断依据，我平时的认知是大部分的数据可以用Mysql搞定，而海量数据Oracle是极好的，没有依据，算得上是道途听说吧！2. 面对一个大型复杂系统架构，历经哪几个重要阶段？前期评估-----设计----细部设计----安装设定-----功能测试----整合测试-----方能上线吧。3. 网站架构设计存在哪些误区？ 其实这个砖家说比较好，好久不见这个ID冒泡了。我觉得吧，从三点说：1.硬件：觉得越贵的设备性能越好，忽略了适用和扩展，浪费！2.技术：一味追求新颖先进的技术，或者效仿大公司的架构；3.优化：WEB这个东西，什么流量啊，什么数据了，都是有着增长性的特点，过早的优化是不必要的。4. 说说读完试读章节后您的感想。&Hadoop 技术是现在应用很广的技术，尤其在大数据方面处理应用中广泛应用，其自身在数据提取、变形和加载(ETL)方面上的天然优势。在此也是涨姿势了，现在虽然我是运维，但是还不曾接触大数据，只能是了解。唉~ & 一曲孤歌对酒吟，殇断意深处啊！
好活动，支持。引用:1. Oracle、MySQL 还是NoSQL，作为一个架构师，面对如此众多选择的时候，到底应该依据什么来做出正确的决定呢？这是个数据库选择问题，现在很多都在大规模去“O”运动。MySQL和NoSQL组合使用更普遍。创业型的公司不会采用Oracle，国企这些会采购Oracle数据库。为什么？这就是预算问题，大家都能猜到其中缘由。选择NoSQL存储来提高系统性能。例如NoSQL加上索引查询效率非常高，非结构化或半结构化的数据用NoSQL 数据库存储。有一个重要的选择依据就是看应用是否需要事务支持，需要哪就选择关系数据库组件做数据库存储。需求要有事务支持的话还是关系型数据库。目前的MySQL采用合理的技术架构，其实也能达到高性能和高可用来支持重要的数据库应用系统。对于Oracle和MySQL的选择，有两个方面：根据业务应用的重要性，依据你的投入项目预算。结合应用的类型、预算资金、数据量、重要程度、人力资源、商业支持需求、熟悉程度、技术需求来做出选择。每个产品都有自己的特性，每个数据库都有自己的优点与缺点，不是贵的就一定适合应用哦，用的恰当好处才是最合适的。所以根据需求来选择最合适的数据库。引用:2. 面对一个大型复杂系统架构，历经哪几个重要阶段？可以简单分作几个阶段：1.需求分析阶段，2.规划设计阶段，3.项目实施阶段，4.方案完善和升级更新。大型复杂系统设计，如果一开始是新项目，以前没有类似的项目实践。现在网站架构设计的技术比较成熟非常重要，也非常关键。因为新项目的设计阶段里面，不知道这个系统最终会有多大多复杂，首先需要评估。需要多少系统资源，预估硬件服务器，多少数据库存储等。然后到了投入使用阶段，随着业务量的增加，架构在不断扩容，同时出现各种问题，开始修复这些问题。再次，稳定系统后，到了最后的阶段，当架构稳定阶段，需要积累经验，问题记录和温度编写，完善文档。引用:3. 网站架构设计存在哪些误区？误区一、按照个人喜好，个人偏向去做选择，片面看待问题。误区二、技术方面上不一定要追求最新，追求时髦，不要认为新技术就是最好的，最新不一定最好，适用就好。新技术确实是一种进步，但有可能也意味着风险。新技术在生产环境下的验证未必完善，因此选择要慎重。误区三、架构设计不能盲从，不能跟风，不能人云亦云。互联网上的那些分享方案，大企业解决问题的经验，可以用作参考，更不要照搬。误区四、架构技术不能解决一切，关键是人为控制，把控好管理关键点。误区五、需求和成本没控制好，两者相互矛盾。引用:4. 说说读完试读章节后您的感想。试读了目录部分，发现书中案例比较多，这个非常好，实践的检验是读者最想了解的部分。书中的hadoop分析用户呼叫行为的案例，且是个非常不错的架构案例，这些都是广大读者很喜欢的。是Hadoop应用架构实践的方面的好书。试读完发现这是一本技术架构方案分享很有价值的书籍，书的内容很丰富，架构技术解决方案比较多。&
本帖最后由 jimmy_lixw 于
17:09 编辑
初级工程师
1.&&Oracle、MySQL 还是NoSQL，作为一个架构师，面对如此众多选择的时候，到底应该依据什么来做出正确的决定呢？
oracle是当前关系型数据库当中的王者，是大型的数据库，但是其并不开源，如果商用需要花钱购买。而MySQL是一个开源的主要面向中小型应用的RDBMS。而NoSQL是相对于关系型的数据库而言的，有很多种类的NoSQL数据库管理系统，比如MongoDB。
简单来讲，不考虑数据库设计的因素，只考虑单表数据量的前提下，我们说：在数据库的数据量非常大的情况下（海量数据），比如亿万级别的，则优先考虑NoSQL。数据量小于千万级别的MySQL完全可以胜任。而Oracle在数据量千万以上的话则更能体现它的价值。当然了如上这么说肯定非常草率，但是能够看出一些区别。
2. 面对一个大型复杂系统架构，历经哪几个重要阶段？
a、分析当前应用的定位，构建架构的概念。
b、确立系统架构的标准和基线。
c、分解大型系统为多个子系统并分别进行架构和设计
d、对子系统的构件单元进行设计
思路就是化复杂为简单，化大为小、逐步完善。
3. 网站架构设计存在哪些误区？
a、一味的追求最新技术、技巧，而忽视了网站的本身价值。
b、复制现有的成功模式，而没有根据实际项目的情况进行设计。
4. 说说读完试读章节后您的感想。
试读部分主要介绍了hadoop在电信、金融等行业的应用，尤其详细的讲解了其在优酷土豆、淘宝等公司的实践经验，让一般接触不到这些前沿技术的工程师了解了hadoop这个分布式文件系统在实践中的应用情况。在当前这个大数据异常火爆的今天，这本书尤其体现出它的阅读价值。
成功最大的敌人是虚度光阴、畏缩不前。
1.&&Oracle、MySQL 还是NoSQL，作为一个架构师，面对如此众多选择的时候，到底应该依据什么来做出正确的决定呢？
对于目前公司的情况一般是用Mysql主要是开源&&数据量大的用oracle&&商业版收费
2. 面对一个大型复杂系统架构，历经哪几个重要阶段？
整体的架构评估--系统的应用标准--分多少个子系统--子系统设计
3. 网站架构设计存在哪些误区？
忽视网站的本身价值
盲目的去优化
4. 说说读完试读章节后您的感想。
介绍了hadoop在一些行业的应用，让我这个接触不到前沿技术的小白了解其的应用情况，对我来说这本书体现出了他的阅读价值
1. &Oracle、MySQL 还是NoSQL，作为一个架构师，面对如此众多选择的时候，到底应该依据什么来做出正确的决定呢？首先，数据量因素：数据量的大小是决定采用哪种数据库的一个极为关键的因素。一般来说，处理数据达到100GB到TB级别的，NoSQL无疑是更好的选择。Oracle是一个商业型非开源数据库，在处理100GB以下数据量的时候，性能上则是绰绰有余。其次，需求因素：得要依据业务需求（比如数据存储类型、IO频率等）来决定。比如说，就算是NoSQL，也包含有诸如HBase、Cassandra、MongoDB、Redis等数据库需要进行选择。第三、成本因素：A、数据库成本：Oracle非开源，商业版收费；MySQL开源，免费；NoSQL大部分都是开源免费。B、项目成本：开发团队水平、运维人员水平，如果开发和运维人员都非常擅长于使用Oracle，就没有必要采用MySQL或者NoSQL。最后、安全可靠性。2. 面对一个大型复杂系统架构，历经哪几个重要阶段？在《程序员》2009年04期的杂志上有一篇文章《大型复杂系统的架构与设计》曾对这个话题进行了探讨。主要分为以下几个阶段：构建商业架构概念----构建应用架构概念----确立和稳定系统架构基线----子系统架构及设计----构件与单元设计但我认为，结合我们工作的实际，我们会以以下这几个阶段为主：A、需求评估（包含对商业架构的构建、以及系统业务需求的认知）B、整体架构设计（根据架构师认知范畴选择合适的技术）C、核心技术预研（确认所选择到的部分核心技术是否能达到系统功能及性能要求）D、子系统架构设计E、子系统技术预研（针对各子系统，视项目团队水平而定，并非所有子系统都需要）F、系统架构方案敲定3. 网站架构设计存在哪些误区？A、方案选择：追求最流行的、最新的技术，或者大公司的解决方案。却没有考虑网站的本质需求以及团队成员的水平素质。好的架构设计，更应该是合适自己的。B、性能要求：没有依据网站的实际情况去制定相应的性能指标，过早的陷入追求高效率强优化阶段。性能上应该根据业务需求而定，在数据量接近一定瓶颈，再考虑更进一步的优化。C、架构设计：所有架构内容都自己设计，没有很好地运用历史沉淀积累下来的一些优秀的基础构件。D、硬件选取：采用最新的硬件，认为硬件越新、配置越高越好。硬件的选择，必须要平衡当前网站的需求以及提供一定幅度的可扩展性。&4. 说说读完试读章节后您的感想。&大数据几乎是当前最火热的一个话题，随着大数据时代的到来，hadoop作为当前在大数据处理领域最优秀的解决方案，成为了时下最热门的新技术。我之前曾参与了一个电信领域的项目，在公司项目组中也属于首次引入了Hadoop。此后便开始从围绕hadoop打造自己的新的核心竞争力。对于Hadoop相关的诸如Hbase、hive等都有进行钻研。但是在围绕大数据架构设计上，始终还没有什么思路。最近准备做的项目是网络银行类型的大数据项目，目前还属于概念阶段，公司还在构思其架构的设计，因为是金融银行领域的，对安全性极其注重，打算采用hadoop，但仍然有不少顾虑。而读完试读章节后,正好给了我一定的启发。无论是从全局关注面，还是局部侧重点上，都让我有了一个新的认识。特别是试读章节有说到的一句话：“金融银行业对数据存储安全要求非常高，因此系统必须设计异地容灾备份存储。”我想，这也是易于其他领域的一个很大的不同点。当然，这本书也让我更另外一个角度温故了此前曾做的电信领域的项目。
1. &Oracle、MySQL 还是NoSQL，作为一个架构师，面对如此众多选择的时候，到底应该依据什么来做出正确的决定呢？& (1)根据项目需求类型& &分析项目面向的是数据流还是业务流处理模型，对数据实时性，安全性，并发性的要求，分析这三类数据库的选择优势和劣势，进行评估& (2)根据公司项目预算&& 如果前期项目预算不足，肯定要结合公司实际情况，选择性价比高的& (3)根据公司目前机房网络硬件的情况& 如果硬件条件不具备，选择某某数据库，架构也是不实际的& (4) 根据项目后期的可维护性& 项目上线后，后期运营维护的人力成本和硬件成本也要考虑，毕竟项目是要长期可持续发展的2. 面对一个大型复杂系统架构，历经哪几个重要阶段？&个人觉得 &(1) 前期调研，分析业务需求的关注点，特点，难点，对硬件的要求& & & & & & & & &(2) 确定方案后，反复进行评估和多方沟通& & & & & & & & &(3) 建立解决方案的评估指标和模型，对要架构的方案进行打分评估，确定得到公司高层的支持& & & & & & & & &(4) 方案通过后，组建项目团队，确定项目进度计划，项目的里程碑& & & & & & & & &(5) 开始技术架构实践，中途要反复进行沟通确认，直至项目完成3. 网站架构设计存在哪些误区？(1) 盲目追求新技术(2) 忽视用户的声音(3) 缺少评估新技术带来的风险和成本4. 说说读完试读章节后您的感想。&个人感觉(1)优点:案例很多，图形化讲解,直观& & & & & & & (2)缺点: 缺少总结和归类，对于什么类型的项目，进行什么样的架构选型，架构的优势在哪，不足在哪，继续改善的地方在哪，好像书中都没有提到，案例很多，如果不归类，看的人很眼花。
支持一下先 读完再回复~1.&&Oracle、MySQL&还是NoSQL，作为一个架构师，面对如此众多选择的时候，到底应该依据什么来做出正确的决定呢？三者作为各个领域的典型代表，先做一些对比：①功能上的一些差异Oracle是功能上最全面的一个，无论是OLTP还是OLAP场景，Oracle有着最好的技术职称；MySQL作为开源的代表，常用功能都有，相对来说NoSQL这方面就非常弱了，因此功能上肯定是 Oracle&MySQL&noSQL。②性能上没的说，noSQL在数据存储和日志方面的架构做了很好的优化，因此性能非常好，也就是性能上来说NoSQL&Oracle=MySQL这么一个噶虚拟③扩展上NoSQL良好的分布式扩展支持，相对来说MySQL的架构也比Oracle好一些，因此可扩展性上NoSQL&MySQL&Oracle④维护性和商业支持上这个不用说 Oracle&MySQL&NoSQL⑤一致性Oracle&MySQL&&NoSQL⑤并发和规模上NoSQL&Oracle&MySQL因此从多方面对比来看，各自有各自的优点，但是整体来说对于普通网站业务来说，NoSQL还是有些性能上的优势，但是到了对数据要求严格以及逻辑复杂的场景下，只能有Oracle和MySQL上了。所以来说，要根据实际的系统架构需求来规划数据库的选型。2.&面对一个大型复杂系统架构，历经哪几个重要阶段？大型系统架构的建设过程也是一个项目的建设过程，因此我个人从项目管理的角度分析，认为一个大型的信息系统构建过程应该有：①需求分析和整理（需要全面的了解要建设的系统的需求，从客户那里获取真实的需求信息，并进行整理）②整体架构设计（评估整体需求，类似项目的整体管理阶段，完成一个大框架的构建选择）③构架组件的设计（可以综合面向对象和面向过程的方法，将工程分解，既可以模块化分解，每个工作包采用合适的技术）④具体实施（项目进入实施阶段，开始实际编码系统）⑤测试上线（ 根据设计情况，完成开发并进行测试，推送系统上线）⑥维护阶段（对于架构内的问题进行修复）3.&网站架构设计存在哪些误区？网站架构设计存在不少的误区，比较显著的有：①一口吃个大胖子，无视实际需求，构架一个过于虚大的架构，并不能实际切合用户的需求。②采用过于新的先进的技术，技术团队过于追求新的技术，导致一些隐藏的问题。③过早优化，还没成型就开始做单元性的优化，反而导致问题出现。④购买最新最强大的硬件，超出实际需求。⑤死板应用各种模版架构，导致不够灵活。<b style="line-height: 22..&说说读完试读章节后您的感想。&& & & & 试读中的前言部分在说“架构和建筑在英文里面都是一个词，都叫做‘Architecture'，但是IT架构却还是婴儿”，看完这几段后突然想起来了，前言内容和《IT架构实录》的卷首语一样，都是洪钊峰大师的题词。& & & & 章节中首先提到的就是电信运营商在上网日志处理的现状，日志都是获取用户基础信息和上网日志信息，输入到集群HDFS文件系统和HBase数据库中，采用基于分布式Hadoop技术方案是基于分布式基础构架，并行处理大数据集。& & & & 然后提到Hadoop平台在金融行业的应用构架，关系型数据库处理速度优先，压力巨大，银行只好增加机器性能，备份数据，大量的投入资金。然后介绍了Hadoop应用的优势。& & & & 试读章节内容较少，但是从中了解到一些典型场景下应用，而且都是采用合理的架构减少投入，获得更好的结果，读后最大的感性就是，合理的架构太重了。
本帖最后由 forgaoqiang 于
14:49 编辑
1.&&Oracle、MySQL 还是NoSQL，作为一个架构师，面对如此众多选择的时候，到底应该依据什么来做出正确的决定呢？
一、 系统对比
? 功能差异
Oracle无疑是功能最为全面一个，无论是用于OLTP场景还是OLAP场景，都有很好的技术手段支撑；MySQL作为开源数据库软件的代表，对于关系型数据库常用的功能也都全面覆盖到了，但作为 OLAP场景所不可或缺的 Hash Join这一特性确实给 MySQL 的 OLAP之路造成了较大阻碍；而各 NoSQL 产品大多都不能进行非 K/V 式的数据存取，能支持多维度条件过滤的产品选择较少。
所以从功能角度来比较： Oracle > MySQL > NoSQL
? 性能强弱
根据过去的一些测试及实际应用场景的经验，基于同等硬件资源，可以从以下3个角度来对比性能：
? 写入：由于 NoSQL 在数据存储及日志记录方面的架构及实现优化，相对 Oracle 及MySQL来说都有不小的优势。而 MySQL 和 Oracle 二者差异并不是特别大，暂且认为二者并列吧。
所以从写入性能角度来比较：NoSQL > Oracle = MySQL
? 简单查询
关于简单查询性能的争议一直很大，有人测试出 Oracle 不如 MySQL 的结果，也有人测试出 MySQL 比 Oracle 差的结果。其实可能二者的测试都没有问题，真正的问题在于各自的测试场景的差异，尤其是并发数的差异可能会对测试结果造成非常大的影响。在高并量不断增加的时候（如到达128），MySQL就会逐渐显示出力不从心的状况了。至于 NoSQL，至少在笔者的测试场景下大部分时候都是比前面二者性能要差。当然肯定会有大量的 NoSQL 粉丝们会跳出来反对，但请记住我们要的不是一个 Cache 产品，也不是比较大规模集群下的能力。
所以从简单查询性能角度来比较：Oracle > MySQL > NoSQL
? 复杂查询（至少含有 Join）
NoSQL 产品不支持 Join，所以无疑垫底，MySQL 的查询优化器由于所基于的统计信息相对少很多，当Query 复杂度很高的时候容易出现执行计划不是最优选择的问题，而 Oracle 由于大量的统计信息支持，使得其查询优化器更为智能，对复杂查询有更优的表现。
所以复杂查询的性能角度：Oracle > MySQL > NoSQL
? 扩展能力
扩展能力或者说扩展方便程度，一直是影响架构师选型的一个重要因素，毕竟我们的数据产生速度越来越快，很多时候都难以通过单机来解决问题。
单纯从扩展便利性角度来看，大部分 NoSQL 产品都有较好的分布式支持方案，无疑是最佳选择，而 Oracle 由于其对数据一致性的严格要求，以及架构的一些限制，扩展便利程度较 MySQL 要稍微弱一些。
所以在扩展能力方面：NoSQL > MySQL > Oracle
? 可维护性
这一点一直是运维人最为关注的因素，毕竟任何一个软件系统都是需要后期维护的。
NoSQL 产品由于发展时间相对较短，对于可维护性角度的支持相对要少很多，虽然大多提供了一些相应的小工具，但总体来说都还是过于简单了些，所以这方面和相对成熟的 MySQL 以及Oracle相比较要弱。而Oracle为后期维护所做的工作无疑是最为全面，无论是运行状态的跟踪，还是基础的备份恢复等，都很完善。
所以在可维护性角度方面：Oracle > MySQL > NoSQL
? 商业支持
NoSQL 产品目前有商业支持的很少，MySQL 的本地化商业支持选择并不多，Oracle方面的商业支持无论是大型公司还是初创团队，选择性相对比较广泛
所以在商业支持方面：Oracle > MySQL > NoSQL
? 软件成本
这方面没有太多争议：Oracle > MySQL = NoSQL
? 人才环境
这是很多人会忽略的一个因素，但实际上可能会给后续的使用及维护带来非常大的影响。Oracle作为发展了多年的数据库领域的龙头，所以整个 Oracle DBA 行业相对比较成熟，人才体系也相对稳定。MySQL 数据库作为后起新秀，已经有不少人投入其怀抱，但总体来说无论从数量还是质量角度来看，都远不如 Oracle DBA 这一群体。NoSQL 方面的人才就更为匮乏了。
所以从人才环境角度：Oracle > MySQL > NoSQL
二、 场景分析
? 一致性要求
虽然无论你什么时候去问任何一个业务方，都会告诉你他系统的数据是不能有任何一条丢失的，任何时候都需要实时反馈变化。但实际上是当你换一个提问方式，告诉他们如果在极端情况下（比如断电）也要确保数据不会有任何丢失，会增加几十上百万的成本，那这个时候得到的回答可能就会完全不一样了。所以我们在了解业务方对数据一致性要求的需求时候，一定要明确厉害关系，分清数据级别，并且做到最大化的信息透明，才能挖出最清晰的需求。对于数据一致性的保护，Oracle 无疑是做的最可靠的一个。
? 并发规模
并发规模会考验我们的扩展能力，如果并发规模很大，那我们就需要很好的扩展能力以保证后续并发增长的需求。选用一个难以扩展的系统，会导致后续并发规模增长过程中无论是时间成本还是经济成本都很高。
? 逻辑复杂度
很显然，如果业务逻辑过于复杂，至少 NoSQL 肯定不是合适的选择，至于 MySQL 还是 Oracle，那就是考验二者功能及性能的时候了。
? 总容量规模
我们的系统数据容量规模自然也会影响到软件选型，规模非常大的，肯定要用分布式系统支持，至少也得分库分表吧，这时候的扩展能力就会充分显示出其优势。
三、 平衡决策
经过了第一步的“系统对比”，以及第二步的“场景分析”，我们已经为系统选型积累到相对充分的信息了，那是不是就可以比较明确的选择出合适的系统了呢？
这时候我们可能会发现我们的数量规模很大，但是又希望能够维护方便容易控制。这时候我们就面临如下问题：数据量规模大选NoSQL更合适，便于维护又是Oracle的优势，怎么办？ 又或者如果我们有这样一个场景：某交易系统，并发量很大，对于数据一致性要求很高，业务逻辑也并不简单，怎么办？Oracle可以为我们提供很好的数据保护，面对复杂逻辑的时候也能有最好的性能，但在扩展的时候会面临成本压力。MySQL可以提供较好的扩展方案，而且成本相对会较低，NoSQL 无法解决复杂逻辑的业务场景。
类似问题可能会频繁出现在我们的架构师面前，需要大家根据各种利弊进行权衡，做好平衡决策，在尽可能满足业务需求的前提下，选择一个更合适的系统。有些时候可能也不得不作出牺牲极少数业务需求来换取系统更大的发展，而不要为了保全某些极端场景的需求而影响整个选型。
数据存储软件的多样化趋势势不可当，不管是传统龙头的 Oracle，还是开源典范的 MySQL，以及 NoSQL 这一新秀，各有其特色，但同样也都有其短板。没有谁是万能的，同样也没有哪一种架构能应对所有问题。
作为一个架构师，我们的选型工作需要做到下面几点：
1. 在平时的工作中做好积累，以获得上面的第一步“系统对比”中的信息。
2. 在面对具体业务需求的时候，充分挖掘最真实的需求，并将各种利弊信息透明化
3. 在最终决策的时候做好平衡，从需求实现，成本控制以及维护管理多个角度权衡利弊
4. 对新技术学习的渴求不能影响选型结果，同样也不能对新技术的使用带有恐惧。
Oracle，MySQL 以及 NoSQL，都只是一个软件而已，实际使用效果更多的取决于使用者的能力。一个优秀的使用者能够充分利用其优势避开其软肋，最终获得最大化的价值。
2. 面对一个大型复杂系统架构，历经哪几个重要阶段？
大型系统架构的建设过程也是一个项目的建设过程，因此我个人从项目管理的角度分析，认为一个大型的信息系统构建过程应该有：
①需求分析和整理（需要全面的了解要建设的系统的需求，从客户那里获取真实的需求信息，并进行整理）
②整体架构设计（评估整体需求，类似项目的整体管理阶段，完成一个大框架的构建选择）
③构架组件的设计（可以综合面向对象和面向过程的方法，将工程分解，既可以模块化分解，每个工作包采用合适的技术）
④具体实施（项目进入实施阶段，开始实际编码系统）
⑤测试上线（ 根据设计情况，完成开发并进行测试，推送系统上线）
⑥维护阶段（对于架构内的问题进行修复）
3. 网站架构设计存在哪些误区？
网站架构设计存在不少的误区，比较显著的有：
①一口吃个大胖子，无视实际需求，构架一个过于虚大的架构，并不能实际切合用户的需求。
②采用过于新的先进的技术，技术团队过于追求新的技术，导致一些隐藏的问题。
③过早优化，还没成型就开始做单元性的优化，反而导致问题出现。
④购买最新最强大的硬件，超出实际需求
4. 说说读完试读章节后您的感想。
个人感觉(1)优点:案例很多，图形化讲解,直观
& && && && &&&(2)缺点: 缺少总结和归类，对于什么类型的项目，进行什么样的架构选型，架构的优势在哪，不足在哪，继续改善的地方在哪，好像书中都没有提到
引用:原帖由 maosdf 于
18:22 发表
1.&&Oracle、MySQL 还是NoSQL，作为一个架构师，面对如此众多选择的时候，到底应该依据什么来做出正确的决定呢？
一、 系统对比
? 功能差异
Oracle无疑是功能最为全面一个，无论是用于OLTP场景还是OLAP场景，都有很好的技术手段支 ... 谢谢您的支持！！！
引用:原帖由 forgaoqiang 于
20:36 发表
支持一下先 读完再回复~1.&&Oracle、MySQL&还是NoSQL，作为一个架构师，面对如此众多选择的时候，到底应该依据什么来做出正确的决定呢？三者作为各个领域的典型代表，先做一些对比：①功能上的一些差异Oracle是功 ... 谢谢您的支持！！！
呀 我来晚了 这本书好 我也要回答问题 and must get it~~
引用:原帖由 读书频道 于
11:13 发表
谢谢您的支持！！！ &&对于12#楼这种猥琐的粘贴复制别人劳动成功的行为表示谴责 直接拼凑别人的回复 太猥琐了~
版版，建议对12楼的maosdf的复制粘贴行为的惩罚，直接不予与评奖。。
引用:原帖由 wenskys 于
14:51 发表
版版，建议对12楼的maosdf的复制粘贴行为的惩罚，直接不予与评奖。。 恩 就是嘛 复制其他地方的就算了 居然直接复制楼上楼下的 这也太猖狂了吧~~
引用:原帖由 forgaoqiang 于
19:00 发表
恩 就是嘛 复制其他地方的就算了 居然直接复制楼上楼下的 这也太猖狂了吧~~
我是来顶帖子的。欢迎大家多多参与啊
大二天的，为什么木有人咱家活动呢