多語言持久性

2006 年，我的同事尼爾·福特創造了術語 多語言程式設計，表達應用程式應該使用多種語言編寫，以利用不同語言適合解決不同問題的事實。複雜的應用程式會結合不同類型的問題，因此選擇適合工作的語言可能會比嘗試將所有方面都塞進單一語言中更有效率。

在過去幾年中，對新語言（特別是函數式語言）的興趣爆炸性增長，我經常很想花時間深入研究 Clojure、Scala、Erlang 或類似的語言。但我的時間有限，我更優先考慮另一個更重要的轉變，也就是 DatabaseThaw。第一批客戶和其他聯絡人的訊息已經傳來，前景誘人。我敢肯定地說，如果你正在啟動一個新的策略性企業應用程式，你不應該再假設你的持久性應該是關聯式的。關聯式選項可能是正確的選擇，但你應該認真考慮其他替代方案。

這其中一個有趣的後果是，我們正在準備轉向多語言持久性 [1]，其中任何規模適中的企業都會有各種不同的資料儲存技術，用於儲存不同類型的資料。仍會有大量的資料在關聯式儲存中管理，但我們會越來越先詢問我們想要如何處理資料，然後才找出最適合它的技術。

這種多語言影響甚至會在單一應用程式中顯而易見[2]。複雜的企業應用程式使用不同類型的資料，而且通常已經整合來自不同來源的資訊。我們會愈來愈常看到此類應用程式使用不同的技術管理自己的資料，視資料的使用方式而定。這種趨勢將會與將應用程式程式碼分解成透過網路服務整合的個別元件的趨勢互補。元件邊界是包裝特定儲存技術的理想方式，該技術是根據其資料處理方式而選取的。

這將會帶來複雜性的代價。每種資料儲存機制都會引入一個需要學習的新介面。此外，資料儲存通常是效能瓶頸，因此您必須深入了解技術運作方式才能獲得良好的速度。使用正確的持久性技術會讓這件事變得更容易，但挑戰並不會消失。

許多這些 NoSQL 選項都涉及在大型叢集中執行。這不僅會引入不同的資料模型，還會帶來一系列關於一致性和可用性的新問題。交易單一真實點將不再具有影響力（儘管其作為此類角色通常是虛幻的）。

因此，多語言持久性將會帶來代價，但它會到來，因為其好處是值得的。當關聯式資料庫被不適當地使用時，它們會對應用程式開發造成顯著的阻礙。我最近與一個團隊交談，其應用程式基本上是撰寫和提供網頁。他們只透過 ID 查詢頁面元素，不需要交易，也不需要共用他們的資料庫。像這樣的問題非常適合使用鍵值儲存，而非他們必須使用的企業關聯式巨槌。善用正確的 NoSQL 選擇來執行工作的良好公開範例是 The Guardian，他們從使用 MongoDB 轉換為先前的關聯式選項後，確實感受到生產力提升。

另一個好處來自於在叢集上執行。透過垂直擴充來擴充到大量流量會愈來愈困難，這是一個我們已經知道很長一段時間的事實。許多 NoSQL 資料庫被設計為在叢集上執行，而且可以處理比單一伺服器更大量的流量和資料。隨著企業尋求更多地使用資料，這種擴充將變得愈來愈重要。在 gotoAarhus2011 中描述的丹麥藥物系統就是一個很好的範例。

所有這些都導致重大的改變，但這不會是快速的改變，因為公司在資料儲存方面天生保守。

更直接的問題是哪些類型的專案應該考慮替代的持久性模型？我的想法是，首先，您應該只考慮位於 UtilityVsStrategicDichotomy 的策略性終端的專案。這是因為實用性專案沒有足夠的好處來換取新技術。

針對策略性專案，您有兩個驅動程式會提出替代方案：減少開發阻力或處理密集資料需求。即使在此，我懷疑許多專案，可能大多數專案，最好還是堅持關係正統性。但少數不應堅持的專案卻很重要。

一個可能較不重要的因素是專案是新的，還是已經建立。Guardian 轉移到 MongoDB 的過程發生在過去一年左右，是在數年前開發的程式碼庫上進行。多語持久性是您可以在現有程式碼庫中導入的內容。

所有這些的意義在於，如果您在企業應用程式世界中工作，現在是開始熟悉替代資料儲存選項的時候了。這不會是一場快速的革命，但我相信在未來十年，資料庫的進展將會迅速解凍。