最近在工作中我需要把數據從公共的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。
以下摘選自《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，優秀的程序員可以說出二者各自的好處是什麼，也許對於大型項目至關重要；但是也有程序員會吐槽，其實用哪個都可以啊，好處壞處的差異並沒有那麼明顯，因爲我的項目那麼小，需要的數據庫讀寫如此簡單……
有人說，小項目可以幫助拓寬技術視野，但是隻做小項目無法深入瞭解技術本身，因爲你無從比較並理解類似技術的優劣。這也是“玩具代碼”在學新東西的時候有成就感，也很適合技術分享的膠片之用，卻無法帶來工程師持續成長的原因。
你覺得是不是這樣呢？
文章系本人原創，轉載請保持完整性並註明出自《四火的嘮叨》