為什麼大多數大型網站不是用Java寫的

國慶長假，老外在熱烈的討論這個話題，

原文地址： http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-scalab.html

我摘錄部分觀點如下：

Most of these sites are using LAMP as the core runtime stack

Some develop their own file system (Google, GFS)

Some are using caching to solve the database bottleneck (memcached and the like)

--

introducing similar solutions for addressing the scalability challenges: 在解決伸縮性方面的嘗試：

On the Data Tier we see the following:

1. Adding a caching layer to take advantage of memory resources

availability and reduce I/O overhead
2. Moving from a database-centric approach to partitioning, aka shards

註：shards是google貢獻給hibernate的一個項目，他是hibernate的一個擴充，可以

透明的實現資料的分布儲存。至於如何分布儲存由你自己定義策略，例如典型的

RoundRobinShardSelectionStrategy

 

On the Business Logic Tier:

3. Adding parallelization semantics to the application tier (e.g.,

MapReduce)
註：MapReduce是Google開發的C++編程工具，用於大規模資料集（大於1TB）的並行運算。MapReduce通過把對資料集的大規模操作分發給網路上的每個節點實現可靠性；每個節點會周期性的把完成的工作和狀態的更新報告回來。MapReduce會產生大量的臨時檔案，為了提高效率，它利用Google檔案系統來管理和訪問這些檔案。

4. Moving to scale-out application models to achieve linear scalability
註：
scaling：the ability of an application to address growth in throughput,

usage, and capacity
有兩種策略：scale out 和 scale up
scale up vs scale out 的區別在於：
 1 Reliance on hardware versus reliance on software
 2 Equation with "first-class" hardware versus "commodity" hardware
 3 Massive versus incremental capacity increases
 4 Centralized versus partitioned application architectures
簡單的說就是一個靠提升單個硬體的配置，另一個靠用低端配置實現叢集

5. Moving away from the classic two-phase commit and XA for transaction

processing  (See: Lessons from Pat Helland: Life Beyond Distributed

Transactions)
註： 不使用傳統的分散式交易處理，例如EJB的事務，使用新的基於space的中介軟體平台 Space Based Architecture (SBA) and GigaSpaces XAP