2011-04-27 49 views
23

我知道這是一個比較寬泛的問題,但是Django足夠強大,足以構建社交網絡嗎?我主要關心性能/速度。例如,對於用戶基數小的網站(< 10,000個用戶),是否可以創建一個以類似Facebook的速度執行的支持Django的網站?用於社交網絡的Django

它有什麼潛在的弱點,以及爲了儘可能快地把重點放在哪些方面?

+6

首先得到的東西工作。其次,簡介找到瓶頸。第三個重點是分析結果,以儘可能快地完成。 – 2011-04-28 01:21:01

回答

25

「它有什麼潛在的弱點,還有一些需要關注的事情,以便儘可能快地實現它?」

的一件事,你可能會擔心之路越走越是,這取決於你如何建立你的模型,並將它們連接到彼此,你可能會遇到在一個單一的頁面產生很多很多的問題,許多查詢。

如果您使用的模型涉及generic relation,則尤其如此。

假設您使用django-activity-stream來創建近期事件列表(類似於Facebook的新聞提要)。 django-activity-stream基本上創建了一個通用關係列表。對於這些泛型關係中的每一個,您都必須運行查詢來獲取有關該對象的信息。而且,由於它是通用的(即,你不爲每種對象編寫自定義查詢),如果該對象有自己想要輸出的關係,則可能會看到類似於活動提要的40-100個查詢只有20-30件。

對單個請求運行40-100個查詢不是最佳行爲。

好消息是,Django實際上只是一堆用python編寫的類和函數。幾乎所有你用python編寫的東西都可以添加到Django中,這樣你就可以編寫自己的函數或代碼來優化給定的請求。

選擇另一個框架不會避免可伸縮性問題;這隻會在不同的領域呈現出不同的困難。

此外,您可以查看諸如caching之類的內容,以加快響應速度並防止服務器負載。

+0

我絕對同意這個答案。在Django中是可行的,我已經做到了,不幸的是這個項目自那時起就被殺死了,但是Django不是問題所在。 我們使用了一個單獨的搜索引擎來提高SQL調用的性能,並使用了大量的緩存。重要的是,並非所有事情都需要實時。 – 2011-05-04 11:51:41

0

This question談論與Django縮放。這可能會提高你試圖創建一個潛在的大型網站的信心。

4

把我的頭......

Pinax有一個社交網站的個人資料。

Convore和Disqus在其網站的某些部分使用Django。

關於Django的可擴展性 - Does Django Scale ?

編輯:發現這個,而我是谷歌搜索別的東西。

PyCon 2011: Django: Pitfalls I Encountered and How to Avoid Them

由盧克Sneeringer

提交你開始一箇中等大 尺寸Django項目?您是否需要提前計劃 並構建應用程序 ,這將對未預料的 需求做出反應?這次談話涵蓋了一些 技術和我遇到的問題 在寫我的第一個合理的大型 Django網站,我做了 第二次我開始 一個項目。

+0

根據他們最近的帖子,Disqus擁有5億獨立訪問者:http://blog.disqus.com/post/5192492910/the-numbers-of-disqus。他們也正在招聘django/python開發者:http://disqus.theresumator.com/apply/XFqhWa/Web-Engineer.html – zeekay 2011-05-04 18:36:10

2

Django當然可以用來構建一個社交網絡,它提供了很好的性能增強功能,如caching。看到這篇文章在scaling

主要的瓶頸將與你如何設計你的模型。根據我的經驗,創建深層嵌套的外部鏈接和許多聯接(許多關係)在運行復雜查詢時會變慢。對於這種情況,您應該嘗試listfields。您還可以調查Google在其appengine的大表上使用的鍵/值對,它比關係數據庫縮放更多。

你也應該很方便的頁面項目,你可能想要使用ajax仍然保持用戶體驗,並阻止用戶加載頁面只是爲了看到更多的帖子。

0

這不僅是對Django的或Python的問題,它是一個事雲和軟件工程。對於10,000個用戶,單獨一臺服務器可能會好,因爲它們不是併發的,還有位置,這些用戶是否在同一個城市?國家?

我相信Django非常好,我會在類似的項目中使用它,我的問題不是Django,而是IaaS,我將運行這個基礎架構。

如果你仍然擔心如果Python是答案,那麼你可以研究Ruby on Rails和asp.net,甚至perl,php等等。對我來說,Python絕對是答案。

11

這個問題在2011年被問到,從那以後Django已經走過了很長的一段路。我以前在Django上建立了一個擁有200萬用戶的社交網絡,並發現這個過程非常流暢。部分getstream.io的基礎設施也在Django上運行,我們對此非常滿意。以下是從Django安裝中獲得最大收益的一些提示。這個問題不太清楚,但我會假設你從一個完全未經優化的Django安裝開始。

靜態文件& CDN

開始通過託管在S3的靜態文件,並在它的前面粘的Cloudfront CDN。從您的Django實例託管靜態文件是一個可怕的想法,請不要這樣做。

數據庫& ORM:選擇與

2最常見的錯誤是沒有優化的ORM的使用。您需要查看關於選擇相關的文檔並根據需要應用它。在網站上的網頁應該只需要2-3查詢,而不是N次查詢,你通常會看到,如果你不使用正確的選擇有關: https://docs.djangoproject.com/en/1.11/ref/models/querysets/

數據庫:PGBouncer

創建一個新的連接到你的postgres數據庫是一個相當繁重的操作。您需要在本地主機上運行PGBouncer,以確保在創建數據庫連接時沒有任何不必要的開銷。 Django的舊版本對此更加迫切,但總的來說仍然是一個好主意。

基本監視&調試

接下來你要了解一些基本的監控和調試和運行。 django調試工具欄是你的第一個朋友: https://github.com/jazzband/django-debug-toolbar

之後,你會想看看NewRelic,Datadog,Sentry和StatsD/Graphite等工具,以獲得更多的見解。

分離關注

另一個第一步驟是分離出的擔憂。你需要在自己的服務器上運行你的數據庫,在自己的服務器上運行你的搜索服務器,在他們自己的服務器上運行web。如果你在一臺機器上運行所有的東西,很難看到是什麼導致你的應用程序崩潰。服務器很便宜,分開了一些東西。

負載平衡器

如果您以前從未使用過負載均衡器,從這裏開始: https://aws.amazon.com/elasticloadbalancing/

使用正確的工具

如果你正在做標籤雲,標籤搜索或搜索使用專用工具,例如Elastic。

如果你有一個計數器,頻繁改變或正在迅速發生變化,而不是你的數據庫使用Redis的緩存最新版本

芹菜列表和RabbitMQ的

使用任務隊列做任何不需要在後臺完成的事情。最廣泛使用的任務隊列是芹菜: http://www.celeryproject.org/

進行非標準化的一切

你不想計算計數,如喜歡和評論讀取。每次有人添加一個新的喜歡或評論時,簡單地更新喜歡的評論和評論。這使得寫入操作更重,但讀取更輕。由於你可能有很多讀取和很少的寫入,這正是你想要的。

新聞提要和活動流

如果你正在構建飼料看看這項服務building news feeds & activity streamsopen source Stream-Framework

2011年,你必須建立自己的飼料技術,如今這是不再是這種情況。 Build a social network with PHP

現在我們已經瞭解了基礎知識,讓我們回顧一些更高級的技巧。

CDN和2臺裝載

您已經使用的Cloudfront您的靜態文件。作爲下一步,您還需要將Cloudfront保持在您的網絡流量前。這使您可以緩存CDN上的某些頁面並減少服務器上的負載。

您甚至可以緩存CDN上登錄用戶的頁面。只需使用Javascript加載頁面由CDN提供後的所有頁面自定義和用戶特定的詳細信息。

數據庫:PGBadger

工具如PGBadger給你帶來很大的見解到你的數據庫實際上做。您需要針對部分日誌數據運行每日報告。

數據庫:索引

你要開始數據庫索引讀了。大多數早期的縮放問題可以通過應用正確的索引並優化數據庫來解決。如果你的索引正確,你會比大多數人做得更好。數據庫優化有更多的空間,第二象限人員的這些書很棒。 https://www.2ndquadrant.com/en/books/

數據庫:調整

如果你不使用RDS你要運行數據庫的快速PGTune檢查。默認情況下,Postgres的配置是相當緩慢的,PGTune告訴你正確的設置,使用: https://github.com/gregs1104/pgtune

緩存一切

縮放你的數據庫是一種痛苦。最終,您將開始擁有多個從屬數據庫,處理分片和分區等。擴展數據庫非常耗時,避免花費大量時間的最佳方法就是緩存。 Redis現在是你的緩存,但memcached也是一個不錯的選擇。基本上你會想要緩存一切。一頁顯示帖子列表:從Redis讀取,查找用戶配置文件?從Redis中讀取。你想用你的數據庫儘可能少,並把大部分負載的緩存層,因爲它是非常簡單的擴展緩存層

偏移

Postgres的不喜歡大的偏移。在通過大型結果集分頁時使用ID過濾。

死鎖

隨着大量的流量你最終會得到死鎖。當postgress上的多個事務嘗試鎖定一條信息並且A等待B而B等待C和C等待A時,會發生這種情況。顯而易見的解決方案是使用較小的事務。這減少了發生死鎖的機會。接下來,您需要批量更新最流行的數據。 IE瀏覽器。每當有人喜歡某篇文章時,不要更新計數,而要每隔5分鐘左右存儲一份變化列表並將其同步到計數中。

這些是一些基本的技巧,有興趣處理快速增長的社交網絡:)