0

我的帖子

个人中心

设置

  发新话题

《大数据时代的IT架构设计》读一读,评一评。好书就是你的了


欢迎加入读书频道活动讨论群:342347198这样有问题我们就可以及时沟通了哦




        既然路过了,就来看看我们的内容,做一下评价吧,也许获得图书的幸运儿就是你哦~~~~~~







图书介绍:


内容简介:


         《大数据时代的IT架构设计》以大数据时代为背景,邀请著名企业中的一线架构师,结合工作中的实际案例展开与架构相关的讨论。《大数据时代的IT架构设计》作者来自互联网、教育、传统行业等领域,分享的案例极其实用,代表了该领域较先进的架构。无论你就职于哪一行业都可以从本书中找到相关的架构经验,对您在今后的架构设计工作中都能起到很好的帮助作用。《大数据时代的IT架构设计》适合具备一定架构基础和架构经验的人阅读。

板板推荐:

一书在手,架构无忧
   三十位一线架构师真知实践
   百位顶级架构师献计献策
   十万文字尽显架构精华

试读链接http://book.51cto.com/art/201404/434977.htm

购买链接:http://product.china-pub.com/3769768


活动简介:

活动时间:2014年5月15日——2014年6月10日

活动规则:完整的回答以下问题,就有机会获得图书

1.  Oracle、MySQL 还是NoSQL,作为一个架构师,面对如此众多选择的时候,到底应该依据什么来做出正确的决定呢?

2. 面对一个大型复杂系统架构,历经哪几个重要阶段?
3. 网站架构设计存在哪些误区?
4. 说说读完试读章节后您的感想。 

奖品寄送:
由于就最近部分获奖用户不能及时反馈奖品邮寄地址,导致奖品迟迟不能发出,影响了其他用户收奖品,所以我们将会采取以下措施:

活动结束后,我们会通过短消息与获奖用户确定寄送信息,请获奖用户到时注意查收与回复,过时将视为自动放弃获奖资格。

晒感言/奖品:
欢迎获奖用户发博文或帖子,晒晒自己的获奖感言和礼物,和我们一起分享成功的喜悦!

获奖用户:jimmy_lixw  kyle999  forgaoqiang  maosdf  yuke198907








本帖最后由 读书频道 于 2014-6-12 13:45 编辑
第一时间先支持下活动,然后晚上回去再读好书!



引用:
原帖由 cym522 于 2014-5-15 16:30 发表
第一时间先支持下活动,然后晚上回去再读好书!
谢谢支持!!!  哈哈



1.  Oracle、MySQL 还是NoSQL,作为一个架构师,面对如此众多选择的时候,到底应该依据什么来做出正确的决定呢?
对此我目前还没有很好的方法来断定选择什么样的数据库,想必书中会有较好的判断依据,我平时的认知是大部分的数据可以用Mysql搞定,而海量数据Oracle是极好的,没有依据,算得上是道途听说吧!

2. 面对一个大型复杂系统架构,历经哪几个重要阶段?
前期评估-----设计----细部设计----安装设定-----功能测试----整合测试-----方能上线吧。

3. 网站架构设计存在哪些误区?
@OH51888 其实这个砖家说比较好,好久不见这个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 于 2014-5-25 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. 网站架构设计存在哪些误区?

网站架构设计存在不少的误区,比较显著的有:
①一口吃个大胖子,无视实际需求,构架一个过于虚大的架构,并不能实际切合用户的需求。
②采用过于新的先进的技术,技术团队过于追求新的技术,导致一些隐藏的问题。
③过早优化,还没成型就开始做单元性的优化,反而导致问题出现。
④购买最新最强大的硬件,超出实际需求。
⑤死板应用各种模版架构,导致不够灵活。

4. 说说读完试读章节后您的感想。 
        试读中的前言部分在说“架构和建筑在英文里面都是一个词,都叫做‘Architecture',但是IT架构却还是婴儿”,看完这几段后突然想起来了,前言内容和《IT架构实录》的卷首语一样,都是洪钊峰大师的题词。
        章节中首先提到的就是电信运营商在上网日志处理的现状,日志都是获取用户基础信息和上网日志信息,输入到集群HDFS文件系统和HBase数据库中,采用基于分布式Hadoop技术方案是基于分布式基础构架,并行处理大数据集。
        然后提到Hadoop平台在金融行业的应用构架,关系型数据库处理速度优先,压力巨大,银行只好增加机器性能,备份数据,大量的投入资金。然后介绍了Hadoop应用的优势。
        试读章节内容较少,但是从中了解到一些典型场景下应用,而且都是采用合理的架构减少投入,获得更好的结果,读后最大的感性就是,合理的架构太重了。









本帖最后由 forgaoqiang 于 2014-5-17 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 于 2014-5-18 18:22 发表
1.  Oracle、MySQL 还是NoSQL,作为一个架构师,面对如此众多选择的时候,到底应该依据什么来做出正确的决定呢?
一、 系统对比
 功能差异
Oracle无疑是功能最为全面一个,无论是用于OLTP场景还是OLAP场景,都有很好的技术手段支 ...
谢谢您的支持!!!



引用:
原帖由 forgaoqiang 于 2014-5-16 20:36 发表
支持一下先 读完再回复~1.  Oracle、MySQL 还是NoSQL,作为一个架构师,面对如此众多选择的时候,到底应该依据什么来做出正确的决定呢?三者作为各个领域的典型代表,先做一些对比:①功能上的一些差异Oracle是功 ...
谢谢您的支持!!!



呀 我来晚了 这本书好 我也要回答问题 and must get it~~



引用:
原帖由 读书频道 于 2014-5-19 11:13 发表

谢谢您的支持!!!
@读书频道  对于12#楼这种猥琐的粘贴复制别人劳动成功的行为表示谴责 直接拼凑别人的回复 太猥琐了~



@读书频道 版版,建议对12楼的maosdf的复制粘贴行为的惩罚,直接不予与评奖。。



引用:
原帖由 wenskys 于 2014-5-22 14:51 发表
@读书频道 版版,建议对12楼的maosdf的复制粘贴行为的惩罚,直接不予与评奖。。
恩 就是嘛 复制其他地方的就算了 居然直接复制楼上楼下的 这也太猖狂了吧~~



引用:
原帖由 forgaoqiang 于 2014-5-24 19:00 发表

恩 就是嘛 复制其他地方的就算了 居然直接复制楼上楼下的 这也太猖狂了吧~~



我是来顶帖子的。欢迎大家多多参与啊



大二天的,为什么木有人咱家活动呢



‹‹ 上一贴:《微信公众平台应用开发实战(第2版)》教您更好的玩转微 ...   |   下一贴:【回复有礼】众说纷“云” 谈谈你心目中的惠普云 ... ››
  发新话题
快速回复主题
关于我们 | 诚聘英才 | 联系我们 | 网站大事 | 友情链接 |意见反馈 | 网站地图
Copyright©2005-2017 51CTO.COM
本论坛言论纯属发布者个人意见,不代表51CTO网站立场!如有疑义,请与管理员联系:bbs@51cto.com