🥇這個資料庫火了…| 專業主機

讓我講一個技術故事。

許多年前，我正在開發一個內建協作功能的應用程式。這是一個用戶友好的實驗堆疊，充分利用了早期 React 和 CouchDB 的潛力。透過JSON即時同步數據 OT。它在公司內部使用，但在其他領域的廣泛適用性和潛力是顯而易見的。

在嘗試向潛在客戶出售這項技術時，我們遇到了意想不到的障礙。在演示影片中，我們的技術看起來和工作都很好，沒有任何問題。該影片準確地展示了它的工作原理，並沒有模仿任何內容。我們提出並編寫了一個使用該程式的現實場景。

事實上，這就成了問題。我們的演示的工作方式與其他人模擬其應用程式的方式完全相同。具體來說，即使是大型媒體文件，資訊也會立即從 A 傳輸到 B。登入後，每個使用者都會看到新條目。使用該應用程序，即使村里某個地方的互聯網連接中斷，不同的用戶也可以清楚地合作完成同一項目。 After Effects 中的任何產品影片剪輯都隱含了這一點。

儘管每個人都知道「刷新」按鈕的用途，但沒有人真正了解他們要求我們建立的 Web 應用程式通常受到其自身的限制。如果不再需要它們，使用者體驗將完全不同。他們大多注意到他們可以透過給正在交談的人留下筆記來“聊天”，所以他們想知道這與 Slack 等有什麼不同。唷！

日常同步的設計

如果您有軟體開發經驗，那麼記住大多數人不能只看介面圖片並了解它在與之互動時會做什麼，這一定是令人傷腦筋的。更不用說程式本身內部發生的事情了。知識表明可以發生的情況很大程度上是因為知道什麼不能發生和什麼不應該發生。這需要心理模型不僅包括軟體的功能，還包括其各個部分如何協調和相互溝通。

一個典型的例子是使用者盯著 spinner.gif，想知道這項工作什麼時候才能完成。開發人員會意識到該過程可能會被卡住，並且 gif 永遠不會從螢幕上消失。此動畫模擬作業的執行，但與其狀態無關。在這種情況下，一些技術人員喜歡翻白眼，對使用者的困惑程度感到驚訝。然而，請注意其中有多少人指向旋轉的時鐘並說它實際上是靜止的？

這就是實時價值的本質。如今，即時資料庫仍然很少被使用，許多人對它們持懷疑態度。這些資料庫中的大多數都嚴重依賴 NoSQL 風格，這就是為什麼它們通常使用基於 Mongo 的解決方案，而這些解決方案最好被遺忘。然而，對我來說，這意味著能夠輕鬆地使用 CouchDB，以及學習設計結構，而不僅僅是一些官僚可以填充資料。我想我更好地利用了我的時間。

但這篇文章的真正主題是我今天使用的。不是出於選擇，而是因為公司政策的冷漠和盲目應用。因此，我將提供兩個密切相關的 Google 即時資料庫產品的完全公平和公正的比較。

兩人的名字中都有「火」這個字。我記得一件事。對我來說第二件事是不同類型的火。我並不急於說出他們的名字，因為一旦我說出了，我們就會遇到第一個大問題：名字。

第一個叫做 Firebase 即時資料庫和第二個- Firebase 雲端 Firestore。兩者都是來自 Firebase 套件 Google. 分別呼叫他們的API firebase.database(…) и firebase.firestore(…).

發生這種情況是因為 即時資料庫 - 這只是原來的 火力地堡 2014 年被Google收購之前。然後谷歌決定創建一個並行產品複製 Firebase是基於大數據公司，並稱之為Firestore with a cloud。我希望你還沒有感到困惑。如果你還是一頭霧水，別擔心，我自己把文章的這一部分重寫了十遍。

因為你需要表明 火力地堡 在 Firebase 問題中，以及火庫在一個關於 Firebase 的問題中，至少讓你了解幾年前在 Stack Overflow 上的情況。

如果要選出最差軟體命名體驗獎，那麼這絕對是競爭者之一。這些名稱之間的漢明距離是如此之小，以至於即使是經驗豐富的工程師也會感到困惑，因為他們的手指鍵入一個名稱，而他們的頭腦卻在思考另一個名稱。這些都是善意的計劃，但卻慘遭失敗。他們實現了資料庫將著火的預言。我根本不是在開玩笑。提出這個命名方案的人引起了血、汗和淚水。

代價高昂的勝利

人們可能會認為 Firestore 是更換 Firebase，它的下一代後代，但這會造成誤導。不保證 Firestore 是 Firebase 的合適替代品。看起來有人從中剔除了所有有趣的內容，並以各種方式混淆了其餘的大部分內容。

然而，快速瀏覽這兩個產品可能會讓您感到困惑：它們似乎透過基本上相同的 API，甚至在相同的資料庫會話中執行相同的操作。這些差異是微妙的，只有透過對大量文獻的仔細比較研究才能揭示出來。或者當您嘗試移植在 Firebase 上完美運行的程式碼以使其與 Firestore 相容時。即使如此，您也會發現，當您嘗試用滑鼠即時拖放時，資料庫介面就會亮起。我再說一遍，我不是開玩笑。

Firebase 用戶端是禮貌的，因為它會緩衝變更並自動重試優先於上次寫入作業的更新。但是，Firestore 限制每個使用者每秒每個文件 1 次寫入操作，且此限制由伺服器強制執行。使用它時，您需要找到解決方法並實現更新速率限制器，即使您只是嘗試建立應用程式也是如此。也就是說，Firestore 是一種沒有即時客戶端的即時資料庫，它使用 API 偽裝成即時資料庫。

在這裡，我們開始看到 Firestore 存在理由的初步跡象。我可能是錯的，但我懷疑 Google 管理層的某個高層在購買 Firebase 後查看了 Firebase，然後簡單地說：「不，天哪，不。這是無法接受的。只是不在我的領導下而已。”

他從他的房間出現並宣布：

「一個大的 JSON 文檔？不。您將把資料分割成單獨的文檔，每個文檔的大小不超過 1 兆位元組。”

似乎這樣的限制在第一次遇到任何有足夠積極性的用戶群時都不會存在。你知道是這樣。例如，在工作中，我們有超過一千個演示文稿，這是完全正常的。

由於這項限制，您將被迫接受這樣一個事實：資料庫中的一個「文件」與使用者可能稱為文件的任何物件都不相似。

「可以遞歸包含其他元素的陣列數組？不。正如上帝的意圖，數組將只包含固定長度的物件或數字。”

因此，如果您希望將 GeoJSON 放入 Firestore 中，您會發現這是不可能的。任何非一維的東西都是不可接受的。我希望您喜歡 JSON 中的 Base64 和/或 JSON。

「透過 HTTP、命令列工具或管理面板匯入和匯出 JSON？不。您只能將資料匯出和匯入到 Google Cloud Storage。我想現在就是這麼稱呼的。當我說「你」時，我只是針對那些擁有專案所有者憑證的人。其他人都可以去創建門票。”

如您所見，FireBase 資料模型很容易描述。它包含一個巨大的 JSON 文檔，將 JSON 鍵與 URL 路徑關聯起來。如果你寫的是 HTTP PUT в / FireBase 如下：

{
  "hello": "world"
}

然後 GET /hello 將返回 "world"。基本上它的工作原理完全符合您的預期。 FireBase 物件的集合 /my-collection/:id 相當於JSON字典 {"my-collection": {...}} 在根目錄中，其內容可在 /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

如果每個插入件都有一個無碰撞 ID（系統對此有一個標準解決方案），那麼這種方法就可以正常運作。

換句話說，該資料庫 100% JSON(*) 相容，並且與 HTTP 配合良好，例如 CouchDB。但基本上，您可以透過抽象化 Websocket、授權和訂閱的即時 API 使用它。管理面板具有這兩種功能，允許即時編輯和 JSON 匯入/匯出。如果您在程式碼中執行相同的操作，當您意識到 patch 和 diff JSON 解決了處理持久狀態的 90% 的常規任務時，您會驚訝地發現浪費了多少專門程式碼。

Firestore 資料模型與 JSON 類似，但在一些關鍵方面有所不同。我已經提到數組中缺少數組。子集合的模型是讓它們成為一流的概念，與包含它們的 JSON 文件分開。由於沒有現成的序列化，因此需要專門的程式碼路徑來檢索和寫入資料。要處理您自己的集合，您需要編寫自己的腳本和工具。管理面板僅允許您一次對一個欄位進行少量更改，且不具有匯入/匯出功能。

他們採用了即時 NoSQL 資料庫，並將其轉變為具有自動連接和單獨的非 JSON 列的慢速非 SQL。 類似 GraftQL 的東西.

這個數據庫火了……

日常同步的設計

代價高昂的勝利

熱門爪哇

論廣告的權利

添加評論取消回复

這個數據庫火了……

日常同步的設計

代價高昂的勝利

熱門爪哇

論廣告的權利

添加評論 取消回复

添加評論取消回复