1. 背景
JanusGraph的資料比較少，而且大家也都不願意將成果貢獻出來，所以打算將一些知識彙總，然後挖掘。現準備此帖，來收錄大家的遇到的問題。如果有沒收錄的，希望看到的同學能留言，經確認或解決後，均會更新。提供問題格式如下：
JanusGraph版本：0.4.0
JanusGraph部署模式：janusgraph-server * 1 + hbase * 3 （獨立環境） + elasticsearch * 3 (獨立環境)
jdk版本：jdk1.8
操作類型：環境搭建/數據錄入/查詢
具體問題：
2. 問題或缺陷
2.1 環境搭建
2.2 數據錄入
問題1: 在向janusgraph中導入節點的時候出現： java.util.concurrent.CompletionException: org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Vertex Label with given name does not exist: LawItem
這個問題是因爲禁用了自動創建schema，而圖中沒有對應的schema，所以報錯。檢查在properties配置文件中是否有：schema.default=none。
即使沒有配置這個配置項，如果你配置了storage.batch-loading=true，系統也會默認 禁用了自動創建schema
(持續更新中)
2.3 查詢
問題1:查詢節點或節點數量時出現如下錯： WARN org.janusgraph.graphdb.transaction.StandardJanusGraphTx - Query requires iterating over all vertices [()]. For better performance, use indexes
這個問題，是在進行gremlin查詢時，會遍歷所有的頂點，如下操作：
僅僅是查詢兩條邊的數據，也要等很長時間。
可以配置文件中在配置文件中配置強制使用索引，force-index=true，不過筆者在配置了之後，並沒有什麼卵用，還需要待驗證。
(持續更新中)
2.4 概念
缺陷1:並沒有實現事務，無論是hbase還是solr均不支持事務，janusGraph只是號稱說支持事務。
缺陷2:沒有發揮MPP思想，一個計算節點負責所有的圖遍歷。存儲層hbase分佈式化了，但自身計算節點並沒有分佈式化。janusGraph把hbase當做黑盒，純客戶端，圖遍歷拉取所有數據，沒有深入定製到表格存儲裏面，這也是可預見可修改的地方。
缺陷3：gremlin-server單機運算處理能力有限，勢必要水平擴展，但core包中使用了有很多cache,有狀態的，集羣模式下要考慮內存狀態一致性問題。
缺陷4：當後端存儲爲HBase時，導入性能還有待提升。
