按文件夾名稱存儲的鍵值存儲

Question

我們有我們內部的noSQL db，它基本上將所有內容都存儲在一個緊湊的二進制文件中。現在，我需要一個類似於鍵值存儲或B +樹的數據結構。問題是在我的情況下，'價值'可以是不同的類型，並且大小非常不穩定，可能從1Kb到1Gb。通常，鍵是一個字符串，值是數據流，可以是int，string或自定義類型的流。

我在考慮實現一個B +樹，但這並不容易，因爲B +樹需要'值'是相同類型的，並且'值'的大小應該足夠小以便可以存儲在相對小塊。可能有一個變體，但我沒有找到一個關於如何實現B +樹的教程，其中的例子展示瞭如何在磁盤上存儲。我看到的大部分教程都只是內存中的B +樹。

然後我有了使用文件夾/文件名作爲關鍵的想法。然後該值可以是文件內的任何內容。然後值可以是任意大小，這真的是我想要的。所以我的問題是在這裏，在極端情況下，

• 數據不同日子是分開的文件夾商店
• 我可以有1M-50M鍵（實際上文件/文件夾）在磁盤上存儲的天
• 對文件的數據操作在白天通常是'只讀'和'追加'。歷史數據將永遠不會被修改。

我已經看到，我可以在現代操作系統上擁有大約40億個文件，所以我很高興用這種方法在一臺機器上進行〜2YR存儲。我只是擔心，如果這種實現鍵值存儲的方式非常糟糕？爲什麼？在處理文件系統時可以處理什麼問題？ （窗口上的框架磁盤，例如？）

所有在Windows/Linux中都以C++實現。

Answer 1

我認爲，如果你能確保和符合你的要求，它應該不是壞事。 我對嵌入式項目及其有限的一組數據做了類似的事情。

事情需要考慮

1. OS /文件系統應支持文件夾（鍵）和文件名（你如何選擇）
2. 它片段磁盤，可能會延遲磁盤訪問的所需長度巨大的目錄結構。這可能會影響整個系統過程。
3. 應用程序性能可能會降低，因爲讀取/寫入操作取決於文件操作 - 如果需要，您可能會在程序中添加緩存。
4. 不適合多線程應用程序，應該注意文件鎖定。
5. 安全性應該小心。

Answer 2

你爲什麼擔心價值的大小。你可以使用你現有的數據庫。值可以是以下格式的字符串「type | value_data」，其中「|」是一個分隔符。

在這裏，value_data可以是「實際值」或「文件的路徑包含值」

• 類型= LOCAL（在這種情況下value_data將是實際值，如果它可以容納在分貝）
• 類型= REMOTE（在這種情況下value_data將文件的路徑）

Answer 3

「數據不同日子被存儲在不同的文件夾」 - 如果你要搜索一個跨天，這不是方便。

此外，當每個文件夾的文件數超過文件系統限制時，您可能會遇到問題。磁盤上的40億個文件不是問題，單個文件夾中有50個文件。但是，當然，您不需要將所有內容都存儲在同一個文件夾中。 一個密鑰可以分割成一個文件夾部分和一個文件名部分。

如果您需要依靠查找密鑰的範圍的B樹屬性，情況確實會變得棘手。這意味着您需要一個訂單，並且不能使用散列函數將密鑰映射到文件夾/文件名對。在那種情況下，你有一個問題。最糟糕的情況是，你的密鑰連續從「1」到「999999999」，加上隨機設置的更大的密鑰。這意味着您不能使用最後4位數字作爲文件名（太多文件夾）或最後8位數字（太多文件）。