我正在設計一個多租戶系統，並且正在考慮租戶在應用程序層而不是數據庫進行分片。在應用程序級別分片
假設，這應該工作的方式是，對於傳入請求，路由器進程擁有包含主要屬性的全局租戶集合，以確定此請求的租戶以及虛擬分片ID。該虛擬碎片ID進一步映射到實際碎片。
實際分片包含應用程序的代碼以及此租戶的整個數據。這些碎片將是LNMP（Linux，Nginx，MySQL/MongoDB，PHP）服務器。
路由器進程應該充當代理。它應該能夠運行一些代碼來根據存儲在本地數據庫或文件中的集合來確定傳入請求的目標分片。爲了能夠更好地擴展這一點，我正在考慮使分片本身充當路由器，以便他們可以運行反向代理，將請求轉發到適當的分片。也許在shard上運行的nginx實例也可以充當反向代理。但是它將如何執行所需的應用程序邏輯以將請求與適當的分片進行匹配。
我將不勝感激任何有關此路由器實施的想法和建議。
感謝
除非你希望你的租戶產生大致相等的數據量，分片由租戶不會是非常有效的。
對於一般的應用水平分片，讓我分享我自己的經驗：在應用層面我們大批量的SaaS產品碎片化的
第1版。如果您在應用程序級別針對SQL類型解決方案進行分片，您將發現隨着您的增長重新分片將是一件非常頭疼的事情，否則您將不得不編寫重要的工具來自動化該過程。
我們轉而使用MongoDB（在考慮包括Cassandra在內的多種選擇之後），因爲隨着數據的增長，所有內置支持可用於重新分片/重新平衡。
如果您的應用程序不需要MySQL的關係功能，那麼我建議您將精力集中在MongoDB上（因爲您已經認識到這是一個可能的數據平臺），如果您期望的不僅僅是適度的數據增長。允許MongoDB處理數據分片。
另一種選擇是使用諸如dbShards的產品。 dbShards是在應用程序級別分片的唯一分片產品。這樣你就可以使用任何RDMS（Postgres，MySQL等），並且仍然能夠分割你的數據庫，而不必在其間插入某種代理。許多其他分片產品依靠代理將事務指向正確的分片，但dbShards知道去哪裏去，而不必「詢問」其他任何人。
偉大的產品。 dbshards
應用程序級別碎片可能潛在地是一個服務器場，其中有單個分區的MongoDB。我仍然希望建立將租戶分類出租的控制功能。我同意你對複雜工具的需求，以便能夠重新獲得。 – msingla 2011-03-31 20:52:24