索引大文件的數據結構

Question

我需要為一個非常大的 (50GB+) ASCII 文本文件建立一個索引，這將使我能夠提供對文件的快速隨機讀取訪問（獲取第 n 行，獲取第 n 行中的第 n 個單詞）。 我決定使用List<List<long>> map ，其中map[i][j]元素是文件中第 i 行的第 j 個單詞的位置。

我將按順序構建索引，即讀取整個文件並使用map.Add(new List<long>()) （新行）和map[i].Add(position) （新詞）填充索引。 然后我將使用map[i][j]檢索特定的單詞位置。

我看到的唯一問題是我無法預測行/字的總數，所以我會在每次List重新分配時遇到 O(n)，不知道如何避免這種情況。

我為任務選擇的數據結構還有其他問題嗎？ 哪種結構可能更好？

UPD ：文件不會在運行時更改。 除了我列出的內容之外，沒有其他方法可以檢索內容。

Answer 1

1. 增加大型列表的大小非常昂貴。 因此，最好在開始時保留列表大小。
2. 我建議使用2個列表。 第一個包含文件中單詞的索引，第二個包含第一個列表中的索引（相應行中第一個單詞的索引）。
3. 您很可能超出了所有可用的RAM。 並且，當系統開始對由GC管理的RAM進行分頁輸入/分頁時，該程序的性能將被完全破壞。 我建議您將數據存儲在內存映射文件中，而不要存儲在托管內存中。 http://msdn.microsoft.com/zh-CN/library/dd997372.aspx

當您需要處理RAM中不適合的大量數據時，UPD內存映射文件是有效的。 基本上，如果索引大於可用的RAM，這是您唯一的選擇。

Answer 2

我認為將如此龐大的數據保存在內存中不是一個好主意。 std::map 或 std::list 不適用於這種情況，無論是內存方面還是性能方面。 您將需要二級存儲。 搜索外部排序和搜索技術。 如果您想自己實現某些東西，請查看 B-tree 和 trie/B-tie。 但很可能，您不想發明輪子。 尋找一些可以為您完成的庫。 例如，LevelDB 是一種基於文件的鍵值對存儲。 與 std::map 相同，但將數據保存在物理文件中。 還有更多這樣的。