1、入門建議
- 注重應用場景，圖數據庫擅長處理深度關聯的數據分析。
- 呆在有一定圖數據庫方面經驗的團隊
- 不要錯過neo4j培訓或者技術大會
- 不要死磕，多和同事或者社區的同志交流
- 采用關系數據庫的邏輯和思維來學習
2、模型設計的建議
- 屬性是建模成節點還是作為屬性是需要考慮的，主要看屬性的應用場景是否多，比如頻繁作為過濾條件。
- 由于neo4j支持字節和字節數組存儲，一個屬性可以存放達到數G的內容，但是一個屬性文件太大，在neo4j底層存儲時由于某屬性太大往往會打亂整個文件的存儲，導致讀寫性能急劇降低。
- 考慮數據的內在分類性質：比如將一個人的國家作為人的屬性，其實最終還是沒有利用好neo4j的標簽機制。
- 盡量不要用物理id
由于根據物理id刪除物理節點后，在下次生成新的節點時，會分配原來釋放的id空位，會導致一些意向不到的問題（舊id引用一些過期數據）
3、關于建立索引
（1）盡量使用shema index,
（2）索引是讀性能和寫性能的結合，盡量不要對無效字段進行索引，避免增加寫成本。
4、關于數據去重
merge是可以做到數據的去重，但是在多個并發請求時，并不能保證唯一性，還是用關鍵詞UNIQUE最好。
5、關于數據導入
- PERIODIC COMMIT 理論值為1000-10000行
- 盡量節點和關系分開導入，避免cypher出現饑餓加載模式，導致數據加載過多導致內存溢出
- 數據導入先導入部分數據，測試cypher的可用性及導入的速度。
- Merge會掃描所有的屬性
Merge需要先檢查是否有重復節點（掃描所有屬性），然后再創建新節點，因此添加數據的速度比CREATE慢，適合初次導入使用
（6）僅使用一次Merge語句，比如創建人的節點，不要給每個屬性分別Merge,然后就是Merge Key主鍵）
MERGE (company:Company {companyNumber:line1.CompanyNumber,
companyName:line1.CompanyName,
uri:line1.URI
})
改為
MERGE (company:Company {companyNumber: line1.CompanyNumber})
SET company.companyName = line1.CompanyName,
company.uri = line1.URI;
- 使用Constraint 和 index,來提高搜索速度
- 使用Distinct來過濾數據，避免后續可能的笛卡爾積
- 設置Periodic commit來批量提交，可以盡可能多提交數據，但是不要超過內
- 導入命令腳本化：通過neo4j-shell完成導入操作
- Apoc Load CSV 命令只適合導入中等規模數據（千萬級別）
- MERGE一般用于創建節點，對于關系要用CREATE
6、關于數據查詢
- 對于場景使用到節點集合N，需要N和N之間進行笛卡爾積，如果（n1,n2）和（n2,n1）是重復數據，可通過id在where語句進行過濾（如id(n1)>id(n2)）
