实际技术选型的考虑因素

标签: 技术 考虑 | 发表时间:2014-04-01 09:18 | 作者:andrewstz
出处:http://www.iteye.com

近在工作中我需要把数据从公共的Data Warehouse(数据仓库)导出来,放到属于我们team自己账号的云端存储资源中去,然后再在我们的应用中查询这样的资源。需要导出数据是因为直接 从Data Warehouse查询数据是一个缓慢而且异步的过程,而我们的应用数据查询需要实时性。现在要解决这个问题有一些AWS的服务可供我们可以选择,基本上 分成了两大类:

第一类是存储和内容分发(Storage & Content Delivery):

  • CloudFront:CloudFront是用于内容分发给不同地区用户的,它在全球设有数个“edge”,作为临近网络访问数据的入口。就如同大网站建立的CDN设备一样。这显然不是我需要的。
  • Glacier:Glacier非常用来适合存储不常用的、压缩的和备份的海量文件数据,在集中文件存储的服务中,它是最便宜的。比如存储日志、备案资料等等。当然,它牺牲了数据传输的性能和一致性。显然它也不适合我的场景。
  • S3:S3(Simple Storage Service)适合存储原始数据、大对象(单个上限5Tb),费用比数据库服务低。如果我最终决定使用文件系统来存储数据,它是一个好的选择。另外,无 论是Glacier还是S3,层级概念上最大的以及都是地区级别的(在Glacier里面叫做vault,在S3里面叫做bucket,每个这样的单元都 位于某一个地区,例如Asin Pacific),因此如果需要全球多个节点访问同一份数据,需要额外把数据分发到各个地区去。
  • Storage Gateway:Storage Gateway是用于集成IT环境的内部部署的,它支持基于网关缓存的优化或者是网关存储的优化,便于本地和临近网络快速获取数据。它可以用于公司内部不同地理位置的文件共享、镜像或者备份,也不适合我这里的场景。

选择文件存储不能提供数据库的条件查询等功能,目前我的场景下并不需要,我只需要根据不同的区域和数据唯一键来获取数据集就可以了,否则,我需要考虑数据库服务:

  • DynamoDB:DynamoDB 是挂在云上的NoSQL数据库服务,每一张表都需要指定一个hash的主键或者是hash加range两层的主键,同时,它的数据读取和存储的最小单位是 4KB,也就是说,存取0.5KB和4KB的数据,性能表现是几乎一样的。从数据量来看,如果选择数据库服务,它是最适合解决我的问题。
  • SimpleDB: 和DynamoDB相似,非关系型数据库,结构可随意变换,而且数据自动索引,所以查询是非常快的。它的数据容量小得多,有一个典型用法是使用 SimpleDB来存储S3的文件地址,就像“指针”一样。但是它的容量限制需要考虑,每个domain只有10G的上限,可以建立多个domain,但 是那样就需要应用自己来路由选择domain了。关于一致性,它和DynamoDB一样,可以选择最终一致性和强一致性,当然,强一致性需要花费更多钱, 还会降低吞吐量。
  • ElastiCache:把Memcached或者Redis搬到了云上,这显然不是我需要的。
  • RDS:RDS(Relational Database Service)相当于把关系型数据库搬到了云上,它和DynamoDB或者SimpleDB的区别,主要就是RDB和NoSQL DB的区别。
  • RedShift:RedShift是一个数据仓库服务,利用列式存储技术及节点间并行分布式查询,对于上P的数据访问做了优化。

在这里还可以找到这几个AWS上数据库服务的不同,用一表以蔽之:

If You Need Consider Using  
A relational database service with minimal administration Amazon RDS, a fully managed service that offers a choice of MySQL, Oracle or SQL Server database engines, scale compute & storage, Multi-AZ availability and more.  
A fast, highly scalable NoSQL database service Amazon DynamoDB, a fully managed service that offers extremely fast performance, seamless scalability and reliability, low cost and more.  
A NoSQL database service for smaller datasets Amazon SimpleDB, a fully managed service that provides a schemaless database, reliability and more.  
A relational database you can manage on your own Your choice of relational AMIs on Amazon EC2 and EBS that provide scale compute & storage, complete control over instances, and more.  

再有另一个技术选型的例子,在web容器中选择Tomcat还是Jetty。Jetty结构简单,容易定制其组件,也就是说,小和简单(这也是当初Google选择它作为app引擎的最重要原因), 是它最大的优势。Jetty在同时处理大量连接并且需要长时间保持这些连接的时候,性能上更有优势,因为它是基于NIO,而不是Tomcat的BIO来处 理请求的;但是我们也能找到很多性能测试的数据,在对于连接生命周期非常短而且非常频繁的请求,Tomcat的性能要优于Jetty。

620131028105220

以下摘选自《Jetty VS Tomcat Performance Comparison》的二者比较:

Jetty Features and Powered:

  • Full-featured and standards-based.
  • Embeddable and Asynchronous.
  • Open source and commercially usable.
  • Dual licensed under Apache and Eclipse.
  • Flexible and extensible, Enterprise scalable.
  • Strong Tools, Application, Devices and Cloud computing supported.
  • Low maintenance cost.
  • Small and Efficient.

Tomcat Features and Powered:

  • Famous open source under Apache.
  • Easier to embed Tomcat in your applications, e.g. in JBoss.
  • Implements the Servlet 3.0, JSP 2.2 and JSP-EL 2.2 support.
  • Strong and widely commercially usable and use.
  • Easy integrated with other application such as Spring.
  • Flexible and extensible, Enterprise scalable.
  • Faster JSP parsing.
  • Stable.

 

在选择实现技术的时候经常会遇到这样或那样的选择题,上面的两个例子,都是相对理性地分析和比较的例子。我们考虑的内容往往包括功能、性能、社区支持、扩展性和定制性、已知问题和约束等等。

但是,具有讽刺意味的是,仔细想想,实际上我们选择某一项技术的最重要的原因,却远远不是那些“理智的分析”,而是下面这些:

  • “因为大家都在用它啊”,比如项目用Java或者C++作为主要语言来实现,我想很多人和我一样,经常并没有经过太多思考,这似乎是一个思维惯性。
  • “因为我没有用过这项技术,我感兴趣,我想学一下”,其实这也无可厚非,我以前也经历过一个项目组,大部分人(包括主管在内),都排斥使用新技 术,原因是担心风险。我原则上认同风险一说,但是适度范围内给程序员选择技术的自由从长远看是有好处的,尤其是技术也是需要进步的。把所有问题都让“工程 商人”来解决,只会让目光过于浅近。
  • “因为我只知道它啊”,这种情况更多。你为什么选择C3P0连接池?因为那时候我不知道还有哪些别的数据库连接池……

工程师总会在技术选型的时候寻找某种平衡,纸面上未必会写这三条理由,但是心里面,有意识无意识地,一定会给向着这三条理由倾斜。

现在让我们退一步,倘若我们都非常理性地评估了类似技术的优缺点,但是在真正使用技术实现的时候,却发现,实际上这几条类似的技术都可以实现,选哪 个关系并不大。因为数据规模、问题大小,都不足以到了非得区分类似技术优劣的地步。举例来说,持久层使用MyBatis还是Hibernate,优秀的程 序员可以说出二者各自的好处是什么,也许对于大型项目至关重要;但是也有程序员会吐槽,其实用哪个都可以啊,好处坏处的差异并没有那么明显,因为我的项目 那么小,需要的数据库读写如此简单……

有人说,小项目可以帮助拓宽技术视野,但是只做小项目无法深入了解技术本身,因为你无从比较并理解类似技术的优劣。这也是“玩具代码”在学新东西的时候有成就感,也很适合技术分享的胶片之用,却无法带来工程师持续成长的原因。

你觉得是不是这样呢?

【stz总结:把握广度很深度的平衡。大项目做一个,深入理解某项技术+小项目多多扩展视野】

原文链接: http://www.raychase.net/1638



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [技术 考虑] 推荐:

实际技术选型的考虑因素

- - 研发管理 - ITeye博客
近在工作中我需要把数据从公共的Data Warehouse(数据仓库)导出来,放到属于我们team自己账号的云端存储资源中去,然后再在我们的应用中查询这样的资源. 需要导出数据是因为直接 从Data Warehouse查询数据是一个缓慢而且异步的过程,而我们的应用数据查询需要实时性. 现在要解决这个问题有一些AWS的服务可供我们可以选择,基本上 分成了两大类:.

雅虎考虑剥离Hadoop

- Zhifeng - Solidot
《华尔街日报》报导,雅虎正考虑剥离旗下知名的Hadoop工程部门,成立一家独立的公司,预计其价值将在10亿美元左右. 从2005年起,雅虎开始开发数据分析软件和分布式文件系统Hadoop. 今天,已经有数千家公司使用Hadoop分析大容量数据,其中包括了雅虎、eBay、Facebook、Twitter,以及Visa和IBM等.

Linus Torvalds考虑结束Linux 2.6系列

- xtypebee - Solidot
随着第40个Linux 2.6 kernel开发周期的到来,以及Linux诞生20周年, Linus Torvalds在Kernel邮件列表上表示,他觉得2.6.40这个版本数字太大了,他考虑结束Linux 2.6系列,改为开发Linux 2.8或3.0,他表示愿意倾听他人对此事的看法. 有人建议等到2.6.42后再换到新的内核系列,42这一典故出自《银河系漫游指南》,Linus拒绝了这项建议,认为40这个整数更好.

考虑关闭【树洞】回复功能

- SotongDJ - 树洞
一直在犹豫是不是应该关闭【树洞】的回复功能,因为它正在变成一个累赘. 从技术上来说,频繁的回复造成了沉重的系统负担. 如果一日内更新三篇【树洞】,并且在Twitter、饭否上做了推荐,那么系统注定进入假死状态,或者数据库无法连接. 从内容上来说,这里越来越多的得到垃圾广告留言的关注,Akimet的贝叶斯算法也无助于事.

惠普考虑解除CEO职务

- ArmadilloCommander - Solidot
《华尔街日报》引用知情人士的消息称,惠普董事会周三召开会议,考虑解除CEO李艾科(Leo Apotheker)的职务. eBay前CEO、现惠普董事惠特曼(Meg Whitman)为临时CEO人选之一,不过她可能对该职位不感兴趣. 李艾科从去年11月才开始担任惠普CEO,他为惠普规划了一条专注于扩大软件产品阵容的道路.

Mozilla考虑Firefox长期支持版本

- Tim - Solidot
Mozilla正在考虑发布Firefox的一个长期支持版本. Mozilla的Kev Needham称,自从采用快速发布模式之后,Mozilla对部分机构在受管理环境中部署Mozilla产品所面临的挑战心知肚明. 发布节奏越快,企业和机构验证和使用新版本的时间间隔越短. 缺少维护的旧版本会将让企业暴露在安全风险中.

使用Hadoop前十项重要考虑

- - 互联网 - ITeye博客
关键字:使用Hadoop前十项重要考虑. 摘要:Hadoop让大数据分析走向了大众化,然而它的部署仍需耗费大量的人力和物力. 在直奔Hadoop之前,是否已经将现有技术推向极限. 这里总结了对Hadoop投资前可以尝试的10个替代方案,省时、省钱、省力,何乐而不为. 让业务搭乘大数据技术确实是件非常有吸引力的事情,而Apache Hadoop让这个诱惑来的更加的猛烈.

交互设计需要考虑的一些事…

- DayuLu - 互联网的那点事
作为设计师,我们总是希望我们的用户获得更好的体验,试着让他们喜欢我们的网站,应用程序和启动界面. 设计的原型要一再考究鉴定,确实要这样设计,用户可以接受吗. 我们需要不停的假设与验证,不停的优化完善我们的设计,因此我们需要考虑一些方面:. 在执行一个新的产品设计时,首先与产品经理进行沟通,明确了解需求的定位.