技術蔓延如何蔓延
假設您正在開發一款新產品或新功能。一開始，您的團隊會列出需要解決的技術問題。有些解決方案您將自行開發（您的秘訣），而其他解決方案您將使用現有技術（可能至少包括一個數據庫）來解決。
#PG培訓#PG考試#postgresql培訓#postgresql考試
除非您從事數據庫構建業務，否則自行開發數據庫通常是不明智的；它很復雜、風險很大，而且需要非常專業的技能。因此，您最終可能會采用各種現有數據庫：Postgres 用于事務數據，Elastic 用于全文搜索，Influx 用于時間序列，Pinecone 用于矢量操作，ClickHouse 用于分析。突然之間，您的技術堆棧變得龐大。
為什么堆棧蔓延是一個問題
添加的每個新數據庫都會帶來一系列挑戰：需要學習不同的語言、需要理解一致性模型，以及無法忽略的操作細節。這不僅增加了復雜性，還帶來了我所說的“虛線”復雜性，即數據在每對系統之間流動時產生的額外開銷。數據庫越多，虛線越多，推斷整個系統的狀態就越困難。
你擁有更多的數據庫，因此，你遇到的問題也更多。
崩潰的理由
那么還有什么替代方案呢？在我看來，這會讓你的堆棧崩潰。如果你用一個數據庫解決更多問題，那么你就可以移除多個復雜的軟件以及它們之間的虛線復雜性。在頭腦中保持數據流的心理模型以及推理不同時間的數據一致性要容易得多。你可以節省出原本花在操作這些新數據庫上的時間，并且可以將這些時間用于構建功能。
PostgreSQL 在堆棧折疊方面表現出色，因為它既通用又專用。它不僅是一個出色的關系數據庫，還通過其擴展框架支持廣泛的額外用例。PostgreSQL 可以輕松處理 全文搜索 、 時間序列數據、 AI 向量 和分析等工作負載。
PostgreSQL 不僅功能多樣，而且強大而成熟。人們已經在生產環境中使用 PostgreSQL 超過 20 年，隨著采用速度的加快，PostgreSQL 的發展沒有任何放緩的跡象。邊緣情況眾所周知，部署模式、恢復策略和高可用性定義明確，并且有許多公司和擁護者可以為您提供幫助。
正因為如此，我鼓勵您使用 PostgreSQL 解決盡可能多的問題，壓縮您的堆棧，降低復雜性，并讓您有時間專注于構建。
對位：最適合這項工作的工具？
有一個眾所周知的論點，即您應該選擇“最適合工作的工具”，但這個論點有時會被顛倒過來，即“如果您只有一把錘子，那么所有東西看起來都像釘子”。我認為“PostgreSQL 適用于一切”的原則并不與這些原則相矛盾，只要您確保著眼于大局即可。
您如何定義“最適合該工作的數據庫”？它是速度最快的嗎？最容易使用的嗎？最容錯的嗎？還是可以最無縫地集成到您現有的基礎架構中并且您知道如何使用的數據庫（也許是已經存在的數據庫）？最佳選擇通常介于這些標準之間。
您應該選擇數據庫 X 來獲得其速度，數據庫 Y 來獲得其效率，還是數據庫 Z 來獲得其云優化？如果老牌的 PostgreSQL 能夠滿足您現在的需求（具有久經考驗的有效性），并且可以進一步擴展（可能達到您當前需求的 10 倍），那么我認為您應該從已知數量開始。只有當 PostgreSQL 缺乏關鍵功能時才考慮添加其他數據庫，權衡其好處與管理多個系統的額外復雜性。或者，換一種說法， 選擇無聊的技術 （對不起 Postgres，我保證我仍然認為你很令人興奮）。
讓我們考慮兩種可能的情況：
- PostgreSQL 適用于一切 ：多年后，您的工作量超出了原有系統的能力。PostgreSQL
在某些方面表現不佳，但這是一個“好問題”——成功的標志，也是改進架構的提示。 - 過度設計，包含多個數據庫
：您已準備好處理龐大的規模，但系統卻很脆弱、充滿極端情況且難以維護。這不僅具有挑戰性，而且會威脅到您的運營穩定性。
考慮到這些情況，我認為以 PostgreSQL 為中心的系統在理論上的未來挑戰，要比目前過早選擇多數據庫架構的復雜性更可取。
最后的話
“PostgreSQL 適用于一切”并不意味著永遠不使用其他數據庫。老實說，它甚至不是說將 PostgreSQL 用于一切。它是反對過早過度設計解決方案的格言，也是倡導簡單性的好處的格言。請記住，世界上有很多公司和應用程序，在 Timescale 等公司的幫助下，PostgreSQL 將擴展以滿足他們的大多數需求。
)
