在graphdb中批量加載的最佳設置

Question

我一直在閱讀文檔，但我無法確定批量加載的一般準則。

據我可以看到批量加載數據的最佳方式進graphdb是通過使用LoadRDF tool。

然而，適當設置的一般規則並不熟悉我。 首先，如果您有一臺帶SSD驅動器的「平均」服務器，哪種解析速度可以接受？ 1.000個報表/秒，10.000個報表/秒，還是更多或更少？

還有什麼好設置？例如，你可以設置默認200.000條語句的-Dpool.buffer.size，但是如果你有10g的RAM，那麼增加這個條件的經驗法則是什麼，如果你有100或300條RAM的演出呢？

另一種選擇是-Dinfer.pool.size因爲存在具有最小的4。因此1芯= 4個線程的CPU和32個核心是32個線程被設置爲最大的線程。我認爲這不需要任何額外的調整，或者只有在您想要減少CPU負載並且不會超調才能說64個線程的情況下（如果您有32個內核的話）。

也有CONFIGS提供額外的選項，通過與實例烏龜文件/模板其中或許owlim：緩存內存和owlim：元組索引內存可以加載過程中有用的，其它設置更多有用爲裝載後？

最終它也很重要，如果你有單獨的文件，而不是一個大烏龜文件100的和/或不壓縮文件提高加載速度還是它只是降低了初始磁盤使用情況？對於我個人而言，我目前已經設置了290GB RAM和32核心以及1.8T RAID 0 SSD驅動器（其將在加載後具有備份），並嘗試從SSD到30億三元組的初始負載相同的SSD，每秒鐘16.461條語句的全球速度將需要一段時間，但我不確定是否以及如何改進。

Answer 1

才能到標準的數據加載速度的參考的最佳地點是GraphDB benchmark page。

從計算的角度來看，數據加載過程包括爲所有RDF資源生成唯一的內部標識，併爲PSOC，POSC和CPSO（如果啓用上下文索引）等多個已排序集合中的所有語句建立索引。這個過程主要受：

• 推理複雜 - 數據庫集成了正向推理推理引擎。這意味着對於每個新添加的語句，遞歸地觸發一組預定義的規則。根據特定的數據集和配置的規則，物化隱式語句的數量可能會顯着增加。數據加載速度受索引語句數量的影響，但不會輸入顯式三元組。

• 數據集的大小 - 隨着每個集合中編號索引語句的增加，添加更多數據的時間也增加。主要的兩個因素是排序後的集合的對數複雜性以及由於至少一個集合中隨機出現ID而導致頁面拆分的次數。

只有推理時，CPU內核的數量纔會加速數據加載。每個新文件的導入都會產生很小的開銷，所以這不應該成爲一個問題，除非它們的大小相當大。對於堆大小，我們發現SSD和堆大小限制在30GB之間的組合效果最好。如果將堆大小限制爲30GB，那麼您可以從XX:+UseCompressedOops中受益，並且仍然具有合理的GC時間。

請注意，GraphDB 8.x還將爲不可變數據結構預留堆空間，如將RDF資源映射到內部ID！對於3B數據集，它可能會變大到15GB。這個設計決策背後的主要原因是爲了節省GC時間。