一、neo4j有什么缺點
1、社區(qū)版免費開源,但是企業(yè)級項目實用性不強,嵌入式模式相對于遠程連接模式效率較高,但僅支持java和基于jvm的語言,社區(qū)版不能使用集群。
2、企業(yè)版閉源且費用昂貴,集群也只是HA高可用,不能進行分布式存儲,想要提高性能和容量只能加大機器的硬盤、使用更高的內(nèi)存和SSD,硬件最終會達到瓶頸。
3、圖數(shù)據(jù)結構導致寫入性能差,實時性讀寫跟不上,大數(shù)據(jù)量導入麻煩,官方提供的load csv模式性能也不夠理想,neo4j-import倒是不錯,但是只能用于數(shù)據(jù)庫初始化局限太大。
4、社區(qū)不強大,資料不豐富,碰到問題需要慢慢爬坑。
延伸閱讀:
二、id的一些典型的類型
整型:整型通常來說是優(yōu)異的選擇,這是因為整型的運算和比較都很快,而且還可以設置 AUTO_INCREMENT 屬性自動遞增。ENUM 和 SET:通常不會選擇枚舉和集合作為 id,然后對于那些包含有“類型”、“狀態(tài)”、“性別”這類型的列來說是挺合適的。例如我們需要有一張表存儲下拉菜單時,通常會有一個值和一個名稱,這個時候值使用枚舉作為主鍵也是可以的。字符串:盡可能地避免使用字符串作為 id,一是字符串占據(jù)的空間更大,二是通常會比整型慢。選用字符串作為 id 時,還需要特別注意 MD5、SHA1和 UUID 這些函數(shù)。每個值是在很大范圍的隨機值,沒有次序,這會導致插入和查詢更慢:插入的時候,由于建立索引是隨機位置(會導致分頁、隨機磁盤訪問和聚集索引碎片),會降低插入速度。查詢的時候,相鄰的數(shù)據(jù)行在磁盤或內(nèi)存上上可能跨度很大,也會導致速度更慢。如果確實要使用 UUID 值,應當移除掉“-”字符,或者是使用 UNHEX 函數(shù)將其轉換為16字節(jié)數(shù)字,并使用 BINARY(16)存儲。然后可以使用 HEX 函數(shù)以十六進制的方式進行獲取。UUID 產(chǎn)生的方法有很多,有些是隨機分布的,有些是有序的,但是即便是有序的性能也不如整型。