為什麼新的資料庫會議還在不斷早開？

當一切都要歸結於語言編譯器的問題，就是要了解資料庫，從根本上說，每個計算機系統都與儲存、移動和轉換資料有關。作業系統、資料庫和程式語言之間的界限有些隨意——這是特定問題、可用硬體和歷史事故的產物。

但是今天問題和硬體發生了巨大變化，因此我們開始看到人們嘗試重新繪製線條。

以下是一些變化：

• 更便宜的記憶體、更快的儲存硬體和更好的 IO api。過去，將資料庫視為處理慢速塊可定址持久記憶體上的資料的事物，而將程式語言視為處理快速位元組可定址易失性儲存器上的資料的事物是有意義的。這兩種不同的硬體需要非常不同的技術。但在過去十年中，這種區別已經縮小，記憶體資料庫已經跨越到另一邊，隨著位元組可定址非易失性儲存器終於開始商業化，權衡將發生根本性的變化。

• 在儲存速度提高的同時，記憶體延遲和 CPU 速度停滯不前。充分利用當今的硬體需要了解資料區域性性、預取、流水線、分支預測等，更不用說利用增加的核心數量了。這需要以一種對大多數程式設計師來說非常陌生的風格編寫程式碼，並且大多數程式語言都沒有提供太多幫助。這就是為什麼例如現代分析資料庫中的 SQL 查詢通常會勝過手寫 C++ 程式的原因。

• 分散式系統已經變得更加普遍，這在很大程度上是由於一切都轉移到了網路上。在伺服器端，我們已經必須處理水平擴充套件，並且可能在未來處理伺服器的分解。在客戶端，大多數人現在擁有多個裝置，每個裝置都在朝著更加異構的硬體發展（例如arm 的 big.little）。我們現在比過去花費更多的時間來描述系統之間的資料移動，並且我們發現期望程式設計師能夠手動推理一致性是一場失敗的戰鬥（參見例如jepsen 打破一切，谷歌在全域性一致性的Spanner）。

• 面向使用者的應用程式和麵向開發的 api 的賭注都增加了——實時更新、協作編輯、跨裝置和雲伺服器同步、不同服務之間的互操作等。特別是分散式 web 應用程式和複雜應用程式的複雜性GUI 使變更管理具有吸引力（例如，反應hooks、領域的活動物件）。

• 伺服器端日益增加的運營負擔意味著人們對根本性的變化持開放態度，例如“無伺服器”計算。

• 大資料分析的價值不斷增長及其生態系統的碎片化導致需要能夠在許多不同語言之間和跨多臺機器（例如通過arrow）輕鬆共享資料。

以下是人們為應對這些變化而探索的一些方向：

• 將執行時狀態和邏輯推送到資料庫中，例如 facebook messenger將他們的大部分協調和快取邏輯移動到 sqlite 中，我們的機器將他們的整個執行時狀態儲存在自定義記憶體資料庫中，fossil將大部分邏輯寫入 SQL 中，unity 鼓勵儲存實體元件系統中的所有執行時狀態。

• 放棄全域性控制流，轉而支援理解資料流和依賴關係的排程系統，例如流系統如flink或kafka 流，增量系統如react , salsa或nix，並行執行系統如統一作業系統，事件觸發系統如aws lambda 函式或空中自動化。

• 將資料密集型程式碼移動到專用系統中，例如像numpy或gandiva這樣的向量化庫，像unity's burst、weld或futhark這樣的專用編譯器。

• 利用統一資料模型為難題提供通用解決方案，例如automerge提供離線協作，ultorg將資料庫轉換為 crud 應用程式，我們的機器資料庫提供撤消、線上協作和自動生成的編輯器 UI，matrix搭載所有其他功能他們的通用訊息同步協議。

• 將整體式資料庫伺服器拆分為單獨的工具，例如將資料庫翻過來，將資料庫變成一個工具包。

我不知道未來會是什麼樣子，但一個有益的實驗途徑是採用資料庫世界中開發的工具和技術，並以新的方式和新的問題重新組合它們——重新劃定作業系統之間的界限，資料庫和程式語言。

但是這些行仍然編碼在我們欄位的結構中。資料庫人員參加資料庫會議。程式語言的人去參加程式語言會議。遊戲引擎開發人員不會參加其中任何一個會議。

如果我們試圖讓所有這些人在同一個房間裡呢？