國慶長假，老外在熱烈的討論這個話題，
原文地址： 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
