tags: 系統架構

以下的原文取自 scalability for dummies 系列，並附上對照翻譯。

Scalability for Dummies - Part 2: Database

After following Part 1 of this series, 延續這個系列的 Part 1，

your servers can now horizontally scale 現在你的伺服器可以橫向擴展了，

and you can already serve thousands of concurrent requests. 並已經有辦法處理上千則並發的請求了。

But somewhere down the road 但在未來

your application gets slower and slower and finally breaks down. 你的應用程式可能會變的越來越慢，直到最終崩潰。

The reason: your database. It's MySQL, isn't it? 原因：你的資料庫。就是那個 MySQL 不是嗎？

Now the required changes are more radical than just adding more cloned servers and may even require some boldness. 現在，這個需求異動會比原本只是增加更多克隆伺服器，還要更加根本且需要一些膽量。

In the end, you can choose from 2 paths: 最終，你可以選擇兩條路線：

Path #1 is to stick with MySQL and keep the "beast" running. 路線 #1 繼續使用 MySQL。

Hire a database administrator (DBA), 雇用一個資料庫管理人 (DBA)，

tell him to do master-slave replication (read from slaves, write to master) 請他做 主從複製(master-slave replication) (次資料庫負責資料讀取，主資料庫負責資料寫入)

and upgrade your master server by adding RAM, RAM and more RAM. 並加大你的主伺服器的 RAM，以及更多的 RAM。

In some months, your DBA will come up with words like 然後會在某一天，你的 DBA 會冒出一些單字像是

"sharding", "denormalization" and "SQL tuning" "分片化(sharding)"，"去正歸化(denormalization)" 跟 "SQL優化(SQL tuning)"

and will look worried about the necessary overtime during the next weeks. 並且看起來很擔心下週是否必須加班。

At that point every new action to keep your database running will be more expensive and time consuming than the previous one. 到了這個階段，相較於之前，現在我們每項試圖讓資料庫維持正常運行的動作都會變的非常的昂貴且耗時。

You might have been better off if you had chosen Path #2 while your dataset was still small and easy to migrate. 如果在你的資料量還不大且轉移還很容易的階段，選擇 Path #2 可能會比較好過一點，

Path #2 means to denormalize right from the beginning and include no more Joins in any database query. Path #2 就是在一開始就正確的去正規化，並且不要透過 query 做 Join。

You can stay with MySQL, and use it like a NoSQL database, 你可以繼續使用 MySQL 並把它用得像是 NoSQL，

or you can switch to a better and easier to scale NoSQL database like MongoDB or CouchDB. 或是乾脆直接換成更好且更容易擴展的 NoSQL 資料庫，像是 MongoDB 或是 CouchDB。

Joins will now need to be done in your application code. 而現在 Join 則需要在應用程式的程式碼中處理。

The sooner you do this step the less code you will have to change in the future. 越早進行這個動作，往後需要改動的程式碼就越少。

But even if you successfully switch to the latest and greatest NoSQL database 但即使你成功的切換到最新最潮的 NoSQL 資料庫

and let your app do the dataset-joins, 並且改成在你的應用程式中做資料 Join，

soon your database requests will again be slower and slower. 你的資料庫請求還是依然變的越來越慢時，

You will need to introduce a cache. 你就需要用到快取。