旦開始使用 LakeFS，物件儲存上的檔案將形成新的表示形式。物件儲存上的檔案的名稱和路徑將不再相同。
本文提供了lakeFS 檔案表示的高級概述，以幫助您了解lakeFS 檔案表示以及它如何支援資料版本控制。
LakeFS 中資料版本控制的工作原理
LakeFS資料版本控制系統允許以下類似Git的操作：
手術 它的作用
分支 與其他分支和更改隔離的一致存儲庫副本。分支創建是元數據操作，不會重複數據
犯罪 提供完整儲存庫快照的不可變檢查點
合併 以原子方式合併更新一個分支與另一個分支的更改
恢復 此操作將儲存庫恢復到先前的提交狀態
標籤 A 指向一個具有有意義名稱的不可變提交
當您使用lakeFS時，物件儲存中的檔案將形成一個新的結構。其他系統，例如 Apache Iceberg，也創建了新的元資 馬來西亞 WhatsApp 號碼數據 料結構。
文件儲存格式
對於提交：SSTable
提交儲存為與 RocksDB 相容的SSTables。 SSTables 成為首選儲存格式的三個原因：
SSTables 在現代硬體上提供極高
的讀取吞吐量。使用代表 2 億個物件儲存庫的提交（根據我們設計合作夥伴之一的 S3 庫存建模），我們每秒實現了近 50 萬次隨機 GetObject 呼叫。這提供了非常高的吞吐量/成本比，與公有雲上可以實現的一樣高。
它是一種眾所周知的儲存格式，使其易於開發和使用。物件儲存使資料工程工具可以存取它進行分析和分散式計算，從而減少操作資料庫的孤島效應。
SSTable 格式支援鍵的增量編碼，這使得它們對於許多鍵共享相同公共前綴的資料湖來說非常節省空間。
每個 LakeFS 提交都表示為一組不重
疊的 SSTable，它們構成了該提交時儲存庫的整個鍵空間。
對於元資料：Graveler
LakeFS 元資料被編碼為 Graveler，這種格式提供了編碼內容可尋址鍵/值對的標準方法。
儲存格式要求
LakeFS對儲存格式有更多要求：
創建提交時保持空間和時間效率 –
假設一次提交更改了十億個對像中的單個對象，則無需編寫整個存儲庫的完整快照。理想情況下，使用者應該能夠重複使用一些未 9 個用於發送新聞通訊的電子郵件行銷工具 更改的資料文件，以使提交操作（在空間和時間上）與差異的大小（而不是總儲存庫大小）成比例。
允許提交之間有效的差異 –
這運行的時間與提交差異
的大小成正比，而不是它們的絕對大小。
為了支援這些要求，lakeFS 是基於 2 層Merkle 樹，其中包括：
一組葉節點（“範圍”），由其內容位址尋址，以及
“元範圍”，這是一個包含所有 馬來西亞數據 範圍的特殊範圍，代表鍵空間的整個一致視圖：
表示引用和未提交的元數據
LakeFS 始終將已提交和未提交的
物件資料保存在物件儲存的儲存命名空間中。但是，lakeFS 物件元資料可以儲存在鍵值或物件儲存中。
與已提交的元資料不同，未提交（或「暫存」）的元資料具有可塑性並且經常寫入。這也適用於「refs」——分支是指向底層提交的指針，在每次提交或合併操作時都會進行調整。
這兩種類型的元資料不
僅是可變的，而且需要強一致性保證，同時還要具有容錯性。如果我們無法存取主分支的目前指針，系統的很大一部分將會宕機。
幸運的是，這也比提交的元資料小得多。
引用和未提交的元資料目前儲存在鍵值儲存上以確保一致性。有關更多詳細信息，請參閱支援的資料庫列表。
了解lakeFS文件表示
讓我們看一下在物件儲存中使用 LakeFS 管理的檔案。