分解Django項目

我正在啓動一個Django項目，並且需要對多個表進行分片，這些表可能都是行數過多。我已經通過這裏和其他地方的線程看過，並且遵循了Django multi-db文檔，但我仍然不確定這些所有針腳是如何縫合在一起的。我的模型具有會被分片破壞的關係，所以它看起來像是要麼放棄forgo的外鍵來分割相應的模型。分解Django項目

出於參數的考慮，請考慮經典的Authot，Publisher和Book場景，但要投入可以擁有它們的書籍副本和用戶。說書和用戶必須被分解。你會怎麼做？用戶可能擁有不在同一數據庫中的圖書的副本。

一般來說，你用於路由和分片本身的最佳實踐是什麼？你使用Django數據庫路由器，根據你的分片邏輯在命令內手動選擇一個數據庫，還是重寫ORM的某些部分來達到目的？

我在Ubuntu上使用PostgreSQL，如果它很重要。

非常感謝。

來源

2012-11-29 amirey

似乎對我來說過早優化。你怎麼知道你的服務將會增長如此之多？ –

我不知道，但我必須爲此做好計劃。對於大於特定數字的表格，從中進行選擇會變得非常昂貴，甚至更新（特別是在編入索引時）。如果我從一開始就沒有碎片化，至少在邏輯上，以後再做它會更困難。你不同意嗎？ – amirey

在過去，我已經使用Postgresql Table Partitioning做了類似的事情，但是這只是將表格分割成相同的數據庫。這有助於縮短表格搜索時間。這也很好，因爲你不需要修改你的django代碼。（確保您使用您用於約束的字段執行查詢）。

但它不分片。

如果你還沒有看到它，你應該檢查出Sharding Postgres with Instagram.

來源

2012-11-29 08:06:10 monkut

謝謝，蒙庫特。分區將允許我擴展到某一點，但我需要超越。我知道Instagram上的人正在使用類似的堆棧，但還沒有看過這個視頻，所以我很高興你添加了這個註釋。謝謝。 – amirey

我@DanielRoseman同意。此外，有多少行是太多。如果您在編制索引時非常小心，則可以處理大量沒有性能問題的行。保持索引值小（整數）。我有超過4億行的表，即使在與其他數百萬行表連接時也會產生亞秒級響應。

將用戶分成多個表可能更有意義，以便用戶對象具有常用事物的核心，然後「profile」信息位於其他地方（std Django setup）。副本將是一個小型表格，涉及大量數據的書籍。考慮到現在你可以將多少內存放入數據庫服務器，在你看起來似乎錯誤之前進行分解。

來源

2012-11-30 05:25:10 boatcoder

嗨馬克。感謝您的詳細解答。我絕對同意在你需要之前進行優化是錯誤的。關於「副本」，我試圖說這也是一張大桌子，比「書籍」還大。 – amirey

分解Django項目

回答

相關問題