自動部署多應用程序的數據庫結構

Question

我想創建一個類似於basecamp或mailchimp的應用程序。客戶自己註冊他，然後自動設置自己的應用程序。該應用程序將使用cakephp進行開發。

我的問題是什麼是最好的數據庫結構？

• 所有客戶由一個表中的客戶ID分隔。
• 每位客戶都擁有自己的DB + DB用戶。
• 每個人都使用他的文件夾中的SQLite文件。

Answer 1

可以有不同的方式來實現和每個取決於應用程序的性質，如提供給每個用戶什麼功能，什麼每個用戶的數據是參與和關係的數據保持，多少每用戶數據涉及等

方法1：單個應用程序數據庫;多個表按應用程序的功能/結構，但表適用於所有用戶的數據。例如，comments，permissions，categories等

利弊：結構簡單，方便，快捷的檢索和插入

缺點：如果表格生長在尺寸過大的數據庫操作可能會昂貴，或者涉及複雜的索引

方法2：單一的應用程序數據庫;根據應用程序的功能/結構提供多個表格;每個用戶都有自己的表集，這可能是由user_id標識的。例如，對於USER_ID = 1，表可能是comments_1，permissions_1，categories_1等

優點：再次簡單架構;很容易識別哪些表查詢特定用戶;因爲表只包含特定用戶的數據，所以至少有一個WHERE子句（其中user_id = xx）;更小的表格，因此更快的檢索;在繁忙時間鎖定衝突的機會較少

缺點：需要更多維護;添加需要添加新列或新表的新功能時，需要對所有用戶表進行架構更改;

方法3：每個用戶的多個應用程序數據庫

優點：用戶之間的數據的100％隔離;容易調整數據庫架構應定製功能是每個用戶需要;便於在多個服務器之間分割數據庫以實現負載平衡;

缺點：複雜的體系結構;需要更多的維護;更難以存儲共同或共享數據 - 數據可能會複製到每個用戶數據庫，或者可以維護一個通用數據庫。

我認爲如果模式的設計有效，以便在更快的SELECTs/INSERTs和每個表的數據量之間保持平衡，第一種方法應該適用於100-10000個用戶。但是，它需要大量的數據庫調整和智能索引。

從方法2和方法3都很好，但從我的角度來看，方法3更好，因爲它給你更多的靈活性。實現可能需要一些時間，但它並不難

此外，SQLite似乎不適合這樣的實現。我會建議像MySQL這樣的關係數據庫。

希望以上內容提供了一些有關實施的信息，並幫助您決定最適合您的應用程序的部分。

Answer 2

如果你要變大（可縮放），那麼SQLite可能不是你最好的選擇。真正的RDBMS效率更高。這就是說，如果你真的要擴大規模，Cake也許不是最有效的選擇。這些決定是基於您的商業模式制定的。有抱負是件好事，但很難成爲一個1萬磅的大猩猩......雙關語意。

我的公司有一個應用程序，它爲幾十個客戶做營銷自動化，這些客戶使用一個公共數據庫作爲常用功能，另一個數據庫作爲唯一數據。是的，它的工作原理，它實際上是非常有效的，並且做好分離數據的工作，因此數據庫不會失去控制......事實上，共享數據庫具有包含數百萬條記錄的表。這就是說，跟蹤你的連接STINKS並且往往不是我們錯誤的原因。只放一個會話或實例化錯誤和BOOM！這是烤麪包。我經常發現自己不得不完全限定我的疑問才能使事情發揮作用，這隻會增加壓力。我不認爲我會再這樣做。

另外，從純粹的數量角度來看，不得不在數千個數據庫中找到數據庫也不是我的下午下午的想法。我不喜歡跳過50找到我需要的故障排除數據。

對於單個數據庫，一個連接正常工作。從開發角度來看，它更容易。我很難說性能方面的好處是什麼，因爲我們的應用程序遭受的效率非常低下（傳統Symfony）

Answer 3

我們正在創建一個類似的結構應用程序，人們可以註冊並創建自己的內部應用程序。我們正在使用MySQL，所有數據都存儲在同一個數據庫中。我們已經以這樣的方式構建了這些表格，通過登錄憑證，可以在整個站點輕鬆識別所有數據，並在需要時進行提取。

Answer 4

我建議你看看一些新的創新類型的數據庫。對於龐大的數據集，隨着數據量超過特定點，正常的SQL DB開始不足。這就是爲什麼Google創建他們的BigTable項目（http://en.wikipedia.org/wiki/BigTable）。這也是NoSQL運動背後的原因（http://en.wikipedia.org/wiki/NoSQL）。

我特別推薦使用MongoDB（http://en.wikipedia.org/wiki/MongoDB）。它是一個NoSQL數據庫，以面向對象的方式將信息存儲在JSON類文檔的集合中。一開始它有點纏繞你的頭，但它有效，而且速度非常快。我有一個使用MongoDB和Zend Framework推出全新動漫網站的好友，他的網站速度與Google提供的速度一樣快（如果速度不是很快，並且他運行在一臺專用服務器上）。

您可以在http://www.mongodb.org/
這裏找到MongoDB是您的指南上使用它與CakePHP的：http://mark-story.com/posts/view/using-mongodb-with-cakephp
MongoDB的網站也有這方面的詳細信息：http://www.mongodb.org/display/DOCS/PHP+Libraries,+Frameworks,+and+Tools

Answer 5

我強烈建議你使用的NoSQL設計。 NonSQL意味着可伸縮非關係數據存儲，無需連接並具有輕量級語義。 NonSQL方法將通過獲得有關數據的新模型和觀點來改進您開發應用程序的方式。

NoSQL DB傾向於使用磁盤上的內存作爲第一級寫入位置：Redis和Memcached僅在內存中，甚至像Cassandra這樣的系統使用memtables進行異步刷新到磁盤的寫入，從而防止不一致的I/O性能從創建寫入速度瓶頸。而且由於NoSQL數據存儲通常通過分區強調橫向可伸縮性，這使得他們處於利用雲的彈性配置能力的優勢。 NoSQL和雲是天作之合。

你有什麼選擇？

的NoSQL可以給你某些情況下更好的性能：

-Frequently編寫的，很少看數據，如Web點擊計數器，或數據從記錄設備：Redis的| MongoDB

- 經常讀取，很少寫入/更新：用於瞬態數據緩存的Memcached，Cassandra |用於搜索的HBase以及用於數據分析的Hadoop和Hive

- 需要最少停機時間的高可用性應用可以很好地處理集羣冗餘數據存儲：Riak |卡桑德拉

在多個地點 - 數據同步：CouchDB的

-transient數據（Web會話&緩存）搞好短暫的鍵值數據存儲：Memcached的

從企業或網站分析所產生的數據 - 大這可能不會遵循任何明顯的架構：Hadoop

一個組合？

也許你的應用程序更適合不同數據存儲的明智組合。所以檢查這個主題並選擇。