java - realtime - 在Firestore中構建此類數據的正確方法是什麼?



firestore query (1)

我從Google Firebase服務中看過視頻並閱讀了Cloud firestore的文檔,但我無法想像實時數據庫。

我想到了這個Web應用程序,我希望從不同類別的產品中存儲我的提供程序。 我希望通過我的所有產品執行搜索查詢,以查找我對此類產品的提供商,並最終訪問該提供商信息。

我打算為此目的使用這個結構:

Providers ( Collection )
   Provider 1 ( Document )
      Name
      City
      Categories
   Provider 2
      Name
      City

Products ( Collection )
   Product 1 ( Document )
      Name
      Description
      Category
      Provider ID
   Product 2
      Name
      Description
      Category
      Provider ID

所以我的問題是,一旦我得到我想要的產品,這種方法是否是訪問提供商信息的正確方法?

我知道在實時數據庫中這是可能的,使用我可以在提供者部分中搜索該提供者的提供者ID,但是使用Firestore我不確定它是否可行或者這是否正確。

https://code.i-harness.com


在firestore中構造此類數據的正確方法是什麼?

您需要知道構建Cloud Firestore數據庫 沒有 “完美”,“最佳”或“正確”的解決方案。 最佳和正確的解決方案是滿足您需求的解決方案,使您的工作更輕鬆。 請記住,NoSQL數據庫世界中也 沒有 單一的“正確的數據結構”。 所有數據都經過建模,以允許您的應用所需的用例。 這意味著適用於一個應用程序的內容可能不足以用於其他應用程序。 所以每個人都沒有一個正確的解決方案。 NoSQL類型數據庫的有效結構完全取決於您打算如何查詢它。

您構建數據的方式對我來說很好。 一般來說,有兩種方法可以實現同樣的目的。 第一個是在產品對像中保留提供者的引用(如您所做)或複制產品文檔中的整個提供者對象。 最後一個tehnique稱為 denormalization ,對於Firebase來說是一種非常普遍的做法。 因此,我們經常在nosql數據庫中復制數據,以適應其他情況下可能無法實現的查詢。 為了更好地理解,我建議您看到此視頻, 使用Firebase數據庫進行反規範化是正常的 。 它適用於Firebase實時數據庫,但同樣的原則適用於Cloud Firestore。

此外,當您複製數據時,有一件事需要記住。 與添加數據的方式相同,您需要對其進行維護。 換句話說,如果要更新/拒絕提供者對象,則需要在其存在的每個位置執行此操作。

你現在可能想知道,哪個tehnique是最好的。 從一般意義上講,在NoSQL數據庫中存儲引用或重複數據的最佳方法完全取決於項目的要求。

因此,您應該問自己一些關於要復制的數據的問題,或者只是將其作為參考:

  1. 是靜態的還是會隨著時間的推移而改變?
  2. 如果是,您是否需要更新每個重複的數據實例,以便它們保持同步? 這就是我之前也提到過的。
  3. 談到Firestore,您是在優化 performance 還是 cost

如果您的重複數據需要更改並在同一時間保持同步,那麼您將來可能很難將所有重複數據保持最新。 這也可能意味著您花費了大量資金保留所有這些文檔,因為每次更改都需要對每個文檔進行讀寫。 在這種情況下,僅持有參考將是獲勝變體。

在這種方法中,您編寫的重複數據非常少(幾乎只是 Provider ID )。 這意味著您編寫此數據的代碼將變得非常簡單且非常快。 但是在讀取數據時,您需要從兩個集合中加載數據,這意味著需要額外的數據庫調用。 對於合理數量的文檔,這通常不是一個大的性能問題,但肯定需要更多的代碼和更多的API調用。

如果您的查詢速度非常快,您可能希望復制更多數據,以便客戶端只需要查詢每個查詢的文檔,而不是多個文檔。 但您也可以依賴本地客戶端緩存使其更便宜,具體取決於客戶端必須讀取的數據。

在此方法中,您為每個 product 文檔複製 provider 所有數據。 這意味著編寫此數據的代碼更加複雜,您肯定會存儲更多數據,每個產品文檔還有一個提供程序對象。 而且您需要弄清楚是否以及如何使每個文檔保持最新。 但另一方面,閱讀 product 文檔現在可以在 一次 閱讀中為您提供有關 provider 文檔的所有信息。

這是NoSQL數據庫中的一個常見考慮因素:您通常必須考慮寫入性能和磁盤存儲與讀取性能和可伸縮性。

如果您選擇是否複製某些數據,則高度依賴於您的數據及其特徵。 你必鬚根據具體情況來考慮。

所以最後,請記住兩者都是有效的方法,並且它們都沒有比另一方更有針對性。 這一切都取決於您的用例是什麼以及您對這種重複數據的新方法的滿意程度。 數據複製是快速讀取的關鍵,不僅僅是在Cloud Firestore或Fireabase實時數據庫中,而且通常也是如此。 每次將相同數據添加到其他位置時,都會復制數據以支持更快的讀取性能。 不幸的是,作為回報,您有更複雜的更新和更高的存儲/內存使用率。 但是你需要注意Firebase實時數據庫中的額外調用,並不昂貴,在Firestore中。 多少數據複製數據與額外的數據庫調用最適合您,取決於您的需求以及您是否願意放棄“單點定義思維模式”,這可以稱為非常主觀。

完成幾個Firebase項目後,我發現如果我複制數據,我的閱讀代碼會變得非常簡單。 但當然,編寫代碼同時變得更加複雜。 這兩者之間的權衡和您的需求決定了應用程序的最佳解決方案。 此外,為了更加精確,您還可以使用現有工具衡量應用中發生的情況並做出相應決定。 我知道這不是具體的建議,但這是軟性的發展。 一切都是關於衡量事物的。

還要記住,某些數據庫結構更容易受到某些安全規則的保護。 因此,嘗試使用 Cloud Firestore安全規則 查找可以輕鬆保護的架構。

另請參閱我在這篇 post 中的回答,其中我已經解釋了有關Firestore中的 collectionsmapsarrays 更多信息。





google-cloud-firestore