cypher中的where子句的效率vs匹配

我正在嘗試使用密碼找到10個用戶「mike」不喜歡的帖子。將where子句與NOT關係放在一起比使用可選關係進行匹配更有效，然後檢查where子句中該關係是否爲空？具體而言，我想確保它不會完成全表掃描，並確保這是一個可伸縮查詢。cypher中的where子句的效率vs匹配

下面是我使用

START user=node:node_auto_index(uname:"mike"), 
    posts=node:node_auto_index("postId:*") 
    WHERE not (user-[:LIKES]->posts) 
    RETURN posts SKIP 20 LIMIT 10;

或者，我可以做一些事情，我在MATCH可選的關係

START user=node:node_auto_index(uname="mike"), 
    posts=node:node_auto_index("postId:*") 
    MATCH user-[r?:LIKES]->posts 
    WHERE r IS NULL 
    RETURN posts SKIP 100 LIMIT 10;

在控制檯上的一些快速測試，篩選似乎表明在更快的性能是什麼第二種方法。我是否有權假定第二個查詢更快？如果是這樣，爲什麼？

來源

2013-01-12 MonkeyBonkey

你的第二個查詢是一樣的一日一個，除了SKIP 100值。不應該在某處存在MATCH子句？ – ulkas

Doh，是的，複製並粘貼錯誤。問題現在更新爲正確的第二個示例。 – MonkeyBonkey

我認爲在發動機通過所有postID節點上運行，並手動將第一查詢的檢查爲not (user-[:LIKES]->posts)每個柱ID 的條件，而在第二個例子中（假設使用至少v1.9.02）發動機僅拾取發佈節點，實際上並沒有連接到用戶。這只是最優化，其中引擎不通過所有postID節點。

如果可能的話，一定要使用MATCH子句中的查詢，而不是在哪裏，並儘量省略了星號在聲明START n=node:index('name:*')

來源

2013-01-14 15:45:50 ulkas

如果我在開始子句中省略了asterix，那麼替代語法是什麼？ – MonkeyBonkey

這是一個與你的圖形設計有關的問題 - 如果你必須經常實時查詢這個查詢，那麼重新設計圖表直到你可以在沒有asterix的情況下執行查詢會更好。但有時候這是無法完成的。你能否給我們提供你當前的數據庫設計和目標？ – ulkas

這是一張「用戶」和「帖子」的圖表。我使用「name」（對於用戶）和「postId」上的auto_index來區分節點類型。用戶可以喜歡帖子。每天，我都想讓用戶隨意瀏覽一組他們還不喜歡的帖子。爲了說明起見，假設每天會有數百萬個帖子被查看，而200,000個「喜歡」帖子，20,000個帖子和數千個用戶註冊。 – MonkeyBonkey

cypher中的where子句的效率vs匹配

回答

相關問題