Amazon AWS 上的 I/O 密集型 MySql 伺服器

我們最近從傳統的數據中心轉移到 AWS 上的雲計算。我們正在與另一家公司合作開發產品，我們需要為我們將發布的產品創建一個數據庫伺服器。

過去 3 年我一直在使用 Amazon Web Services，但這是我第一次收到具有這種非常具體的硬體配置的規格。

我知道需要權衡取捨，真正的硬體總是比虛擬機快，並且知道這一事實，你會推薦什麼？

1）亞馬遜EC2？2）亞馬遜RDS？3) 別的？4) 算了，寶貝，堅持真正的硬體

這是硬體要求

該伺服器將專注於 I/O 和 MySQL，用於圖像託管的統計資訊、記憶體大小和磁碟空間。

伺服器 1

I/O 這台伺服器的主要部分將是 I/O 處理，FusionIO 卡已經證明自己非常高效，這是目前該領域中最好的。o Fusion ioDrive2 MLC 365GB ( http://www.fusionio.com/load/-media-/1m66wu/docsLibrary/FIO_ioDrive2_Datasheet.pdf )

CPU MySQL 將使用比 Apache 更少的 CPU 核心，但它會非常努力地使用它們，E7 系列有 30M 記憶體 L3 可以提供提升性能：o 1x Intel E7-2870 就可以了。

儲存 SAS 在性能方面已經足夠好，尤其是考慮到所需的空間。o 4 x SAS 10k 或 15k 的 RAID 10，總可用空間為 512 GB。

考慮到統計數據庫的大小，此伺服器至少需要 64 GB 的**記憶體。**警告：統計數據庫將快速增長，如果可能考慮直接從 128 GB 開始，它會有所幫助。該伺服器將專注於 I/O 和 MySQL，用於圖像託管的統計資訊、記憶體大小和磁碟空間。

伺服器 2

I/O 這台伺服器的主要部分將是 I/O 處理，FusionIO 卡已經證明自己非常高效，這是目前該領域中最好的。o Fusion ioDrive2 MLC 365GB ( http://www.fusionio.com/load/-media-/1m66wu/docsLibrary/FIO_ioDrive2_Datasheet.pdf )

CPU MySQL 將使用比 Apache 更少的 CPU 核心，但它會非常努力地使用它們，E7 系列有 30M 記憶體 L3 可以提供提升性能：o 1x Intel E7-2870 就可以了。

儲存 SAS 在性能方面已經足夠好，尤其是考慮到所需的空間。o 4 x SAS 10k 或 15k 的 RAID 10，總可用空間為 512 GB。

考慮到統計數據庫的大小，此伺服器至少需要 64 GB 的**記憶體。**警告：統計數據庫將快速增長，如果可能考慮直接從 128 GB 開始，它會有所幫助。

提前致謝。

最好的，

問題：

• 您上面列出的兩台伺服器是完全相同的。
• 您談論 FusionIO，但您也談論在同一個機器上執行 MySQL 和 Apache。
• 您沒有提到 Apache 文件或 MySQL 數據庫（或其中的一部分，例如ib_logfile）是否會在 FusionIO 驅動器上。

誤解：

“真正的硬體總是比虛擬機快”並不一定是真的。確實，在相同的硬體上，相同的應用程序如果不在虛擬機中會表現得更好，但由於您無法訪問亞馬遜的硬體，因此這種比較是沒有實際意義的。

雲的關鍵在於它是水平擴展的，所以如果你可以用一台伺服器同時服務 100 個訪問者，你可以用 10 個伺服器同時服務 1000 個訪問者，並且每個訪問者都會收到相同的響應速度，無論你有多少訪問者.

雲端：

與託管相比，雲提供商存在一些關鍵差異。如果您能夠利用它們，它們將使雲託管成為明顯的贏家。

1. 您可以非常快速地啟動和關閉實例。 如果您的流量非常突發（例如，您執行一個售票網站），那麼您可以在 Justin Bieber 門票開始銷售前一小時非常輕鬆地將您的 Web 層、數據庫層和/或儲存層複製到數百個虛擬機，並且一小時後將它們全部關閉以節省資金。基於硬體的解決方案通常需要數週時間來增加您的容量，並且當它們沒有被充分利用時，它們會繼續花錢。
2. 前期成本可以低得多。 除了您的其他託管成本外，您提到的硬體可能還要花費數万美元。我的亞馬遜伺服器每月花費我大約 15 美元，但我可以輕鬆地將其擴展到更強大的虛擬機，並在幾個小時內將其擴展到數十個負載平衡實例。
3. 他們為你做了很多工作。 亞馬遜還有其他服務，例如 DynamoDB，它可以自動擴展或擴展到您給它的工作負載或儲存要求。它們在 SSD 中執行以提高速度，並複製到多個位置，為您提供冗餘和可用性。

也就是說，您的應用程序必須能夠水平擴展。您不能簡單地將其放入雲中並期望它永遠擴展。例如，預設的 PHP 會話有兩個問題：

1. 它們儲存在本地磁碟上，這意味著您需要使用粘性會話或共享磁碟，這將成為瓶頸。
2. 它們打開時使用flock()的是獨占的阻塞文件鎖。一次只能有一個 PHP 程序使用會話文件。當您開始觸發大量 AJAX 呼叫時，這可能是一個嚴重的問題。

這只是一個例子，但沒有考慮到水平擴展的應用程序通常充滿了類似的專有資源。

如果您正在執行分佈式數據庫（Amazon 的數據庫服務就是），那麼您的應用程序還需要能夠處理**CAP**定理中固有的權衡。這表明您可以獲得三個方面中的兩個：一致性、可用性、分區容限。您將需要知道您沒有這三個中的哪一個，並讓您的應用程序對其進行補償。

如果您的應用程序適合硬體，請選擇硬體。如果它適合雲，請選擇雲。

注意：我在這里以亞馬遜為例，但還有其他雲託管服務提供商具有類似的快速啟動和關閉實例的能力，並且只對您實際使用的內容收費。

引用自：https://serverfault.com/questions/374583