MySQL體系結構優化 - MySQL集羣

我正在構建一個具有以下結構的Web應用程序：我們有「客戶」，每個客戶都有自己的「用戶」。每個客戶（包括他的用戶和其他數據）與其他客戶完全分開，並且他們之間沒有共享數據。
而且每個「客戶」有不同的子網站，並即將從那裏（無論是他還是他的用戶）將始終指單一customer.idMySQL體系結構優化 - MySQL集羣

的數據庫是建立在以下方式中的所有查詢：

CREATE TABLE `customer` ( 
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT 
) ENGINE=InnoDB; 

CREATE TABLE `user` ( 
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
    `customerID` int(11) unsigned 
) ENGINE=InnoDB; 

CREATE TABLE `blogPost` ( 
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
    `userID` int(11) unsigned 
) ENGINE=InnoDB;

我有很多像'blogPost'這樣的表通過用戶連接到客戶。

共同詢問將是類似的東西：

SELECT * 
FROM `blogPost` bp 
INNER JOIN `user` u 
ON bp.userID=u.id 
WHERE u.customerID = 324

值得注意的是，這些連接是昂貴的，實際上是不必要的 - 因爲我們進入一個子網站第二，我們只在數據感興趣，定連接到特定的客戶

所以問題是我該如何改進數據庫？我對這個主題的瞭解越多，我就越困惑 -
是NDB（MySQL Cluster）存儲引擎是否要走？
是否最好創建許多不同的數據庫 - 每個客戶一個？也許增加一個冗餘customerID字段到blogPost？其他一些想法？ MongoDB？！

來源

2013-03-21 gilad s

MySQL集羣不會解決這個問題，我想知道你是如何得出這個想法的？有一個「SELECT *」，表格看起來很基本，但是關於選擇特定的列而不是所有的東西？ – geertjanvdk 2013-03-21 07:35:50

表中有更多的字段 - 我只寫了主鍵和外鍵......通常我只選擇相關的列 - 這個查詢只是一個例子來顯示我試圖擺脫的連接...我認爲MySQL集羣創建的行集羣 - 以便每個客戶和相關數據可以在他自己的集羣中...也許這不是真的，雖然 - 我正在尋找任何解決方案，並不僅限於MySQL集羣 – 2013-03-21 08:18:02

首先讓我們清除NDB引擎，MySQL Cluster/NDB不是這裏的一種方式，它不僅不會提供任何有助於您實際情況的事情，而且會讓它更加複雜。不僅需要大量的資源和至少3臺數據庫服務器才能運行NDB，例如JOIN在NDB中仍然不是很好 - 只是不要去那裏。

連接表沒有任何問題，RDBMS被設計爲有效地完成此操作。如果你加入外鍵索引，這將是快速和高效的。你在這裏試圖做的是絕大多數Web數據庫每天都要處理的事情，其中大多數人一起加入信息。

你可以給每個客戶一個數據庫，但相信我，這將大量增加你的數據庫管理工作，如果你真的不需要爲了商業原因而去掉這條途徑，請不要。這是一個噩夢，當架構變化發生時，當客戶x有性能問題，但客戶y不 - 你最終會導致自己很多工作

來源

2013-03-21 08:54:23 Steve

謝謝..我看到你在說，但我擔心諸如消息（id，from_user，to_user，content）等表。我們假設我只有1000個客戶，每個客戶平均擁有200個用戶 - 我將每個用戶的消息數量限制爲100個。因此，我們擁有一個1000 * 200 * 100 = 20,000,000個記錄的單個表。Isn'還有更多可擴展的方法可行嗎？ [不同客戶的用戶無法將消息發送到彼此] – 2013-03-21 09:13:54

@gilads當您引入可伸縮性時，此問題開始擴展 - 您可以執行的操作包括分區/分片數據庫，存檔策略等。甚至可能有解決方案不涉及RDBMS - XML /無SQL等 – Steve 2013-03-21 15:29:46

所以問題是我該如何改進數據庫？

是的，聯接是昂貴的。特別是如果（如你的創建表語句所暗示的）你有沒有索引。如果真的如此，那麼你至少要在主鍵和外鍵上添加索引。（我也注意到，根據你的設計，你不存儲博客文章任何內容？真的嗎？

共同詢問會是這樣......

真的嗎？如果你的查詢沒有實現任何類型的過濾，那麼你的應用程序有一些非常錯誤的地方。如果篩選實現爲分頁，並且數據很少被刪除/更新，那麼每個外鍵序列號將比全局自增分號更有效。

是它最好創建多個不同的數據庫

絕對不是。

當然如果你有物理設備分佈在不同磁盤上的I/O會提高I/O性能（假設你的數據庫管理系統已經正確配置並且你的熱數據集太大而無法放入內存）在這種情況下，您應該考慮在不同的磁盤上交叉索引和數據填充，或者使用內置的MySQL支持跨文件系統進行分片。

也許添加冗餘客戶ID字段到博客帖子

也許。

集羣是可用性和性能的好主意的一個非常好的主意 - 但它帶來了設置和保持運行所需的技能和時間方面的開銷。您當然不應該在查看NDB - 在您調整單個實例的範圍之後，在同步和異步複製中擁有一席之地。

首先添加索引，然後調整DBMS配置，然後嘗試將customerID添加到blogpost中，然後查看文件在存儲中的分佈情況（這看起來像是SSD的一個很好的用例）。

來源

2013-03-21 09:11:55 symcbean

1.我不熟悉「查詢過濾」的概念 - 不管你是什麼意思？ 2.您談到了採用當前架構並用不同的方法進行調優 - 這很好，非常有用，但我擔心消息（id，from_user，to_user，content）等表。我們假設我只有1000個客戶，每個客戶平均有200個用戶 - 我將每個用戶的消息數量限制爲100個。因此，我們有一個包含1000 * 200 * 100 = 20,000,000個記錄的單個表。 Isn有沒有更多的可擴展的方式去？ [不同客戶的用戶不能發送消息給對方] – 2013-03-21 09:45:53

MySQL體系結構優化 - MySQL集羣

回答

相關問題