資料庫管理-第125期 融合vs專用（202301221）

最近參加的兩場活動，一次是11月的SACC上海站(《向量資料庫技術探索》專場)，一次是上週六的《國產資料庫共話未來趨勢》主題活動，雖然二者討論內容與範圍有很大區別，但是關於是否需要專用向量資料庫和時序資料量的討論，確是一致的，即在一個特定的資料領域是否需要獨立的專用型別資料庫。我認為這需要從好幾個方向考慮。

1 便捷性

其實很多時候吧，業務發展是需要資料庫快速跟上的，這一點使用專用資料庫的優勢就顯現出來了，資料庫的定製化開發與單一功能的實現是可以快速實現的，確實可以很快支撐相關業務的發展。在傳統資料庫融合新功能，往往需要付出很大的努力，往往需要耗費較多的時間，很難實現敏捷上線。

2 效能

這時候又得說出專用資料庫的另一個優勢了，因為專注於一件事情不需要考慮其他過多的東西，在這個專用場景下往往都能發揮出較好的效能。這一點如果使用傳統資料庫融合新功能，特別是比較複雜的新功能，資料庫沒有做好相關研發最佳化的情況下，往往不能很好的支撐新功能的高效能實現。
回到傳統資料庫融合的方式來，如果能做到多種型別資料的統一存放統一查詢，簡化業務研發難度而且效能能夠趕上專用資料庫（或者能夠快於使用專用資料庫的架構場景），從SACC的反饋來看，很多業務方會毫不猶豫使用融合資料庫。

3 架構

話又說回來，無論專用資料庫再怎麼厲害，有一件事情是繞不過去的，無論是向量資料還是時序資料抑或是其他型別的非關係型資料，最終產生價值都需要於傳統資料做關聯，使用專用資料庫就會出現資料的多次流轉的問題，多次在不同型別資料庫之間的分步查詢，會產生時間和網路上的更多損耗。另一方面，多一個資料層面的元件也會顯著增加了整體資料架構層的複雜度，增加研發和維護的難度。這一點又是傳統資料庫融合功能的一些優勢。

一些觀點

• 薛首席在SACC說過：“平時外出，沒有特別需求我會用手機拍照；但如果是婚紗照我會找影樓”。
• 熊燦燦上週在《國產資料庫共話未來趨勢》說：“把複雜留給資料庫，把簡單送給研發”
• AWS是針對每種資料型別和工作量執行單一用途的專有資料庫
• Oracle是針對多種資料型別和所有工作負載執行融合開放式資料庫
  等等

我認為吧，還是得從業務場景、上線週期要求、資料量、業務量、效能要求、研發能力、運維能力、雲上&雲下等維度出發（感覺又說了一堆廢話），來選擇使用專用資料庫還是融合資料庫。
老規矩，不知道寫了些啥。