願碼slogan | 連線每個程式設計師的故事
** |
願碼願景 | 打造全學科it系統免費課程，助力小白使用者、初級工程師0成本免費系統學習、低成本高階，幫助bat一線資深工程師成長並利用自身優勢創造睡後收入。
可伸縮性是指軟體系統隨著使用它的業務增長而增長的能力。 postgresql提供了一些功能，可以幫助您構建可擴充套件的解決方案，但嚴格來說， postgresql本身是不可擴充套件的。它可以有效地利用單台機器的以下資源：
但是，當涉及將資料庫解決方案擴充套件到多台計算機時，它可能非常有問題，因為標準postgresql伺服器只能在單個計算機上執行。在本文中，我們將介紹postgresql中不同的擴充套件方案及其實現。
系統可擴充套件性的要求意味著現在支援業務的系統也應該能夠以與其增長相同的服務質量來支援相同的業務。
假設乙個資料庫可以儲存1 gb的資料，並且每秒有效地處理100個查詢。如果隨著業務的發展，處理的資料量會增長100倍？它能夠每秒支援10,000個查詢並處理100 gb的資料嗎？也許不是現在，不是在同乙個裝置中。但是，可以擴充套件可擴充套件的解決方案，以便能夠在需要時立即處理負載。
在需要獲得更好效能的場景中，設定更多伺服器以處理額外負載並從主伺服器將相同資料複製到它們是很常見的。在需要高可用性的情況下，這也是將資料連續複製到備用伺服器的典型解決方案，以便在主伺服器崩潰時它可以接管。
可擴充套件的postgresql解決方案
複製可用於許多擴充套件方案。其主要目的是在系統出現故障時建立和維護備份資料庫。對於物理複製尤其如此。但是，複製也可用於提高基於postgresql的解決方案的效能。有時，第三方工具可用於實現複雜的擴充套件方案。
擴充套件以進行大量查詢
想象一下，有乙個系統應該處理大量的讀取請求。例如，可能有乙個應用程式實現支援**上的自動完成功能的http api端點。每次使用者在web表單中輸入字元時，系統都會在資料庫中搜尋名稱以使用者輸入的字串開頭的物件。由於使用者數量眾多，查詢數量可能非常大，並且還因為每個使用者會話都處理了多個請求。為了處理大量請求，資料庫應該能夠使用多個cpu核心。如果同時請求的數量非常大，則處理它們所需的核心數量可能大於單個機器可能具有的核心數量。
這同樣適用於應該同時處理多個重度查詢的系統。您不需要大量查詢，但是當查詢本身很大時，使用盡可能多的cpu將提供效能優勢，尤其是在使用並行查詢時。
在這種情況下，乙個資料庫無法處理負載，可以設定多個資料庫，設定從乙個主資料庫到所有資料庫的複製，使每個資料庫作為熱備用，然後讓應用程式查詢不同的資料庫不同的要求。應用程式本身可以是智慧型的，每次都可以查詢不同的資料庫，但這需要應用程式的資料訪問元件的特殊實現，如下所示：
另乙個選擇是使用乙個名為pgpool-ii的工具，它可以作為幾個postgresql資料庫前面的負載均衡器。該工具公開了乙個sql介面，應用程式可以連線到那裡，就好像它是乙個真正的postgresql伺服器。然後pgpool-ii會將查詢重定向到當時執行最少查詢的資料庫; 換句話說，它將執行負載平衡：
另一種選擇是將應用程式與資料庫一起擴充套件，以便應用程式的乙個例項將連線到資料庫的乙個例項。在這種情況下，應用程式的使用者應該連線到許多例項中的乙個。這可以通過http負載平衡來實現：
資料分片
當問題不是併發查詢的數量，而是資料庫的大小和單個查詢的速度時，可以實現不同的方法。可以將資料分成多個伺服器，這些伺服器將並行查詢，然後將查詢結果合併到這些資料庫之外。這稱為資料分片。
postgresql提供了一種基於表分割槽實現分片的方法，其中分割槽位於不同的伺服器上，而另乙個分割槽（主伺服器）將它們用作外部表。在主伺服器上定義的父表上執行查詢時，具體取決於where子句和分割槽的定義，postgresql可以識別哪些分割槽包含所請求的資料，並且只查詢這些分割槽。根據查詢，有時可以在遠端伺服器上執行聯接，分組和聚合。postgresql可以並行查詢不同的分割槽，這將有效地利用多台機器的資源。完成所有這些後，可以在應用程式連線到單個資料庫時構建解決方案，該資料庫將根據要查詢的資料在不同的資料庫伺服器上物理執行查詢。
也可以在使用postgresql的應用程式中構建分片演算法。簡而言之，應用程式可能會知道哪些資料位於哪個資料庫中，只在那裡寫入，並且只能從那裡讀取資料。這會給應用程式增加很多複雜性。
另一種選擇是使用市場上可用的基於postgresql的分片解決方案或開源解決方案。它們有各自的優點和缺點，但常見的問題是它們基於postgresql的早期版本，並且不使用最新的功能（有時會提供自己的功能）。
·多個資料節點：儲存資料
·單個全域性事務監視器（gtm）：管理集群，提供全域性事務一致性
·多個協調器節點：支援使用者連線，構建查詢執行計畫，並與gtm和資料節點互動
postgres-xl實現與postgresql相同的api，因此應用程式不需要以任何特殊方式處理伺服器。它符合acid，這意味著它支援事務和完整性約束。該copy命令也受支援。
使用postgres-xl的主要好處如下：
postgres-xl是開源的，但可以獲得商業支援。
值得一提的另乙個解決方案是greenplum。它被定位為大規模並行處理資料庫的實現，專門為資料倉儲而設計。它有以下元件：
·主節點：管理使用者連線，構建查詢執行計畫，管理事務
·資料節點：儲存資料並執行查詢
greenplum還實現了postgresql api，應用程式可以連線到greenplum資料庫而無需任何更改。它支援事務，但對完整性約束的支援是有限的。該copy命令受支援。
greenplum的主要好處如下：
缺點如下：
greenplum有商業和開源版本。
擴充套件許多連線
與可伸縮性相關的另乙個用例是當資料庫連線的數量很大時。但是，當在具有大量微服務的環境中使用單個資料庫並且每個資料庫都有自己的連線池時，即使它們不執行太多查詢，也可能在資料庫中開啟數百甚至數千個連線。每個連線都消耗伺服器資源，只是處理大量連線的要求已經成為問題，甚至不執行任何查詢。
如果應用程式僅在需要查詢資料庫並在之後關閉它們時才使用連線池和開啟連線，則可能會出現另乙個問題。建立資料庫連線需要時間 - 而不是太多，但是當運算元量很大時，總開銷將是巨大的。
有乙個名為pgbouncer的工具可以實現連線池功能。它可以接受來自許多應用程式的連線，就像它是postgresql伺服器一樣，然後開啟有限數量的資料庫連線。它將為多個應用程式的連線重用相同的資料庫連線。建立從應用程式到pgbouncer的連線的過程比連線到真實資料庫要快得多，因為pgbouncer不需要初始化會話的資料庫後端程序。
pgbouncer可以建立多個連線池，它們可以在以下三種模式之一中工作：
·會話模式：與postgresql伺服器的連線用於與pgbouncer的客戶端連線的生命週期。這種設定可用於加速應用程式端的連線過程。這是預設模式。
·事務模式：與postgresql的連線用於客戶端執行的單個事務。當僅同時執行少量翻譯時，這可用於減少postgresql端的連線數。
·語句模式：資料庫連線用於單個語句。然後將它返回到池中，並為下乙個語句使用不同的連線。此模式類似於交易模式，但更具侵略性。請注意，使用語句模式時，無法進行多語句事務。
可以設定不同的池以在不同模式下工作。
可以讓pgbouncer連線到多個postgresql伺服器，從而起到反向**的作用。
可以使用pgbouncer的方式如下圖所示：
pgbouncer建立了與資料庫的多個連線。當應用程式連線到pgbouncer並啟動事務時，pgbouncer會為該應用程式分配現有資料庫連線，將所有sql命令**到資料庫，然後將結果傳回。交易完成後，pgbouncer將斷開連線，但不關閉它們。如果另乙個應用程式啟動事務，則可以使用相同的資料庫連線。這樣的設定需要配置pgbouncer以在事務模式下工作。
postgresql提供了幾種實現複製的方法，這種方法可以維護來自另乙個伺服器或伺服器上的資料庫的資料副本。這可以用作備份或備用解決方案，以便在主伺服器崩潰時接管。通過使負載可以分布在多個資料庫伺服器上，複製還可用於提高軟體系統的效能。
構建可擴充套件的Web站點（二）
五，拓展開發模型 當你的開發團隊變得越來越大的時候，你可能會需要以下 1 編碼規範 對同一小組的人而言，對一種編碼風格達成共識，遠比找到完美的風格更加重要。編碼規範通常包含的規則有 縮排，空白字元，括號，注釋，命名，檔案布局，行結束符。2 測試 一種是自動測試，其中重要部分就是回歸測試。第二種就是手...
《構建可擴充套件的 Web 站點》讀後隨感
對於構建 web 站點，構建可擴充套件的 web 站點 重點並不是講述 how to 的 講述 how to 的書已經很多了，卻很少有圖書願意分一部分篇幅講述 why 所以有的人可能認為 缺少細節 有的人則讀罷大呼過癮。我一般的建議是，如果你覺得這本書沒勁，那就再讀一下第二遍。為什麼我推薦這本書?主...
《構建可擴充套件的 Web 站點》讀後隨感
對於構建 web 站點，構建可擴充套件的 web 站點 重點並不是講述 how to 的 講述 how to 的書已經很多了，卻很少有圖書願意分一部分篇幅講述 why 所以有的人可能認為 缺少細節 有的人則讀罷大呼過癮。我一般的建議是，如果你覺得這本書沒勁，那就再讀一下第二遍。為什麼我推薦這本書?主...