近在工作中我需要把數(shù)據(jù)從公共的Data Warehouse（數(shù)據(jù)倉庫）導出來，放到屬于我們team自己賬號的云端存儲資源中去，然后再在我們的應用中查詢這樣的資源。需要導出數(shù)據(jù)是因為直接 從Data Warehouse查詢數(shù)據(jù)是一個緩慢而且異步的過程，而我們的應用數(shù)據(jù)查詢需要實時性?，F(xiàn)在要解決這個問題有一些AWS的服務可供我們可以選擇，基本上 分成了兩大類：

[[88201]]

第一類是存儲和內(nèi)容分發(fā)（Storage & Content Delivery）：

• CloudFront：CloudFront是用于內(nèi)容分發(fā)給不同地區(qū)用戶的，它在全球設有數(shù)個“edge”，作為臨近網(wǎng)絡訪問數(shù)據(jù)的入口。就如同大網(wǎng)站建立的CDN設備一樣。這顯然不是我需要的。
• Glacier：Glacier非常用來適合存儲不常用的、壓縮的和備份的海量文件數(shù)據(jù)，在集中文件存儲的服務中，它是最便宜的。比如存儲日志、備案資料等等。當然，它犧牲了數(shù)據(jù)傳輸?shù)男阅芎鸵恢滦?。顯然它也不適合我的場景。
• S3：S3（Simple Storage Service）適合存儲原始數(shù)據(jù)、大對象（單個上限5Tb），費用比數(shù)據(jù)庫服務低。如果我最終決定使用文件系統(tǒng)來存儲數(shù)據(jù)，它是一個好的選擇。另外，無 論是Glacier還是S3，層級概念上最大的以及都是地區(qū)級別的（在Glacier里面叫做vault，在S3里面叫做bucket，每個這樣的單元都 位于某一個地區(qū)，例如Asin Pacific），因此如果需要全球多個節(jié)點訪問同一份數(shù)據(jù)，需要額外把數(shù)據(jù)分發(fā)到各個地區(qū)去。
• Storage Gateway：Storage Gateway是用于集成IT環(huán)境的內(nèi)部部署的，它支持基于網(wǎng)關緩存的優(yōu)化或者是網(wǎng)關存儲的優(yōu)化，便于本地和臨近網(wǎng)絡快速獲取數(shù)據(jù)。它可以用于公司內(nèi)部不同地理位置的文件共享、鏡像或者備份，也不適合我這里的場景。

選擇文件存儲不能提供數(shù)據(jù)庫的條件查詢等功能，目前我的場景下并不需要，我只需要根據(jù)不同的區(qū)域和數(shù)據(jù)唯一鍵來獲取數(shù)據(jù)集就可以了，否則，我需要考慮數(shù)據(jù)庫服務：

• DynamoDB：DynamoDB 是掛在云上的NoSQL數(shù)據(jù)庫服務，每一張表都需要指定一個hash的主鍵或者是hash加range兩層的主鍵，同時，它的數(shù)據(jù)讀取和存儲的最小單位是 4KB，也就是說，存取0.5KB和4KB的數(shù)據(jù)，性能表現(xiàn)是幾乎一樣的。從數(shù)據(jù)量來看，如果選擇數(shù)據(jù)庫服務，它是最適合解決我的問題。
• SimpleDB： 和DynamoDB相似，非關系型數(shù)據(jù)庫，結構可隨意變換，而且數(shù)據(jù)自動索引，所以查詢是非?？斓?。它的數(shù)據(jù)容量小得多，有一個典型用法是使用 SimpleDB來存儲S3的文件地址，就像“指針”一樣。但是它的容量限制需要考慮，每個domain只有10G的上限，可以建立多個domain，但 是那樣就需要應用自己來路由選擇domain了。關于一致性，它和DynamoDB一樣，可以選擇最終一致性和強一致性，當然，強一致性需要花費更多錢， 還會降低吞吐量。
• ElastiCache：把Memcached或者Redis搬到了云上，這顯然不是我需要的。
• RDS：RDS（Relational Database Service）相當于把關系型數(shù)據(jù)庫搬到了云上，它和DynamoDB或者SimpleDB的區(qū)別，主要就是RDB和NoSQL DB的區(qū)別。
• RedShift：RedShift是一個數(shù)據(jù)倉庫服務，利用列式存儲技術及節(jié)點間并行分布式查詢，對于上P的數(shù)據(jù)訪問做了優(yōu)化。

在這里還可以找到這幾個AWS上數(shù)據(jù)庫服務的不同，用一表以蔽之：

再有另一個技術選型的例子，在web容器中選擇Tomcat還是Jetty。Jetty結構簡單，容易定制其組件，也就是說，小和簡單（這也是當初Google選擇它作為app引擎的最重要原因）， 是它最大的優(yōu)勢。Jetty在同時處理大量連接并且需要長時間保持這些連接的時候，性能上更有優(yōu)勢，因為它是基于NIO，而不是Tomcat的BIO來處 理請求的；但是我們也能找到很多性能測試的數(shù)據(jù)，在對于連接生命周期非常短而且非常頻繁的請求，Tomcat的性能要優(yōu)于Jetty。

以下摘選自《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.

#p#

在選擇實現(xiàn)技術的時候經(jīng)常會遇到這樣或那樣的選擇題，上面的兩個例子，都是相對理性地分析和比較的例子。我們考慮的內(nèi)容往往包括功能、性能、社區(qū)支持、擴展性和定制性、已知問題和約束等等。

但是，具有諷刺意味的是，仔細想想，實際上我們選擇某一項技術的最重要的原因，卻遠遠不是那些“理智的分析”，而是下面這些：

• “因為大家都在用它啊”，比如項目用Java或者C++作為主要語言來實現(xiàn)，我想很多人和我一樣，經(jīng)常并沒有經(jīng)過太多思考，這似乎是一個思維慣性。
• “因為我沒有用過這項技術，我感興趣，我想學一下”，其實這也無可厚非，我以前也經(jīng)歷過一個項目組，大部分人（包括主管在內(nèi)），都排斥使用新技 術，原因是擔心風險。我原則上認同風險一說，但是適度范圍內(nèi)給程序員選擇技術的自由從長遠看是有好處的，尤其是技術也是需要進步的。把所有問題都讓“工程 商人”來解決，只會讓目光過于淺近。
• “因為我只知道它啊”，這種情況更多。你為什么選擇C3P0連接池？因為那時候我不知道還有哪些別的數(shù)據(jù)庫連接池……

工程師總會在技術選型的時候尋找某種平衡，紙面上未必會寫這三條理由，但是心里面，有意識無意識地，一定會給向著這三條理由傾斜。

現(xiàn)在讓我們退一步，倘若我們都非常理性地評估了類似技術的優(yōu)缺點，但是在真正使用技術實現(xiàn)的時候，卻發(fā)現(xiàn)，實際上這幾條類似的技術都可以實現(xiàn)，選哪 個關系并不大。因為數(shù)據(jù)規(guī)模、問題大小，都不足以到了非得區(qū)分類似技術優(yōu)劣的地步。舉例來說，持久層使用MyBatis還是Hibernate，優(yōu)秀的程 序員可以說出二者各自的好處是什么，也許對于大型項目至關重要；但是也有程序員會吐槽，其實用哪個都可以啊，好處壞處的差異并沒有那么明顯，因為我的項目 那么小，需要的數(shù)據(jù)庫讀寫如此簡單……

有人說，小項目可以幫助拓寬技術視野，但是只做小項目無法深入了解技術本身，因為你無從比較并理解類似技術的優(yōu)劣。這也是“玩具代碼”在學新東西的時候有成就感，也很適合技術分享的膠片之用，卻無法帶來工程師持續(xù)成長的原因。

你覺得是不是這樣呢？

原文鏈接：http://www.raychase.net/1638