实际技术选型的考虑因素
最近在工作中我需要把数据从公共的Data Warehouse(数据仓库)导出来,放到属于我们team自己账号的云端存储资源中去,然后再在我们的应用中查询这样的资源。需要导出数据是因为直接从Data Warehouse查询数据是一个缓慢而且异步的过程,而我们的应用数据查询需要实时性。现在要解决这个问题有一些AWS的服务可供我们可以选择,基本上分成了两大类:
第一类是存储和内容分发(Storage & Content Delivery):
选择文件存储不能提供数据库的条件查询等功能,目前我的场景下并不需要,我只需要根据不同的区域和数据唯一键来获取数据集就可以了,否则,我需要考虑数据库服务:
在这里还可以找到这几个AWS上数据库服务的不同,用一表以蔽之:
If You NeedConsider Using?A relational database service with minimal administrationAmazon 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 serviceAmazon DynamoDB, a fully managed service that offers extremely fast performance, seamless scalability and reliability, low cost and more.
?A NoSQL database service for smaller datasetsAmazon SimpleDB, a fully managed service that provides a schemaless database, reliability and more.
?A relational database you can manage on your ownYour 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。
以下摘选自《Jetty VS Tomcat Performance Comparison》的二者比较:
Jetty Features and Powered:
Tomcat Features and Powered:
在选择实现技术的时候经常会遇到这样或那样的选择题,上面的两个例子,都是相对理性地分析和比较的例子。我们考虑的内容往往包括功能、性能、社区支持、扩展性和定制性、已知问题和约束等等。
但是,具有讽刺意味的是,仔细想想,实际上我们选择某一项技术的最重要的原因,却远远不是那些“理智的分析”,而是下面这些:
工程师总会在技术选型的时候寻找某种平衡,纸面上未必会写这三条理由,但是心里面,有意识无意识地,一定会给向着这三条理由倾斜。
现在让我们退一步,倘若我们都非常理性地评估了类似技术的优缺点,但是在真正使用技术实现的时候,却发现,实际上这几条类似的技术都可以实现,选哪个关系并不大。因为数据规模、问题大小,都不足以到了非得区分类似技术优劣的地步。举例来说,持久层使用MyBatis还是Hibernate,优秀的程序员可以说出二者各自的好处是什么,也许对于大型项目至关重要;但是也有程序员会吐槽,其实用哪个都可以啊,好处坏处的差异并没有那么明显,因为我的项目那么小,需要的数据库读写如此简单……
有人说,小项目可以帮助拓宽技术视野,但是只做小项目无法深入了解技术本身,因为你无从比较并理解类似技术的优劣。这也是“玩具代码”在学新东西的时候有成就感,也很适合技术分享的胶片之用,却无法带来工程师持续成长的原因。
你觉得是不是这样呢?
文章系本人原创,转载请保持完整性并注明出自《四火的唠叨》