neo4j not cluing into the multiple labels












0















My DB consists of two node groups (labels) x and y. y nodes also have additional labels (colors: blue, red, green, etc).



My query is:
MATCH (n1:y)-->(n2:x)<--(n3:blue) RETURN n2.idx



The profile shows an expand for n3 without any reference to it being blue, resulting in 12,000 DB hits, pushing out 12,000 rows. The next stage is a filter for blue, resulting in nearly 24,000 DB hits returning 1,036 rows.



I have constraints on both idx and idy being unique, and I have the index on each of the colors.



I have tried using a color attribute on the y nodes, changing the query to the following, without any difference in the profile.
MATCH (n1:y)-->(n2:x)<--(n3:y {color:blue}) RETURN n2.idx



I've tried using index n3:blue(idy) before the RETURN statement, but that gives me a syntax error. I'm still trying to decypher that (pardon the pun).
How can I avoid the stage db hit bloat described above, and have it just start with only blue nodes?






neo4j







share|improve this question





























    0















    My DB consists of two node groups (labels) x and y. y nodes also have additional labels (colors: blue, red, green, etc).



    My query is:
    MATCH (n1:y)-->(n2:x)<--(n3:blue) RETURN n2.idx



    The profile shows an expand for n3 without any reference to it being blue, resulting in 12,000 DB hits, pushing out 12,000 rows. The next stage is a filter for blue, resulting in nearly 24,000 DB hits returning 1,036 rows.



    I have constraints on both idx and idy being unique, and I have the index on each of the colors.



    I have tried using a color attribute on the y nodes, changing the query to the following, without any difference in the profile.
    MATCH (n1:y)-->(n2:x)<--(n3:y {color:blue}) RETURN n2.idx



    I've tried using index n3:blue(idy) before the RETURN statement, but that gives me a syntax error. I'm still trying to decypher that (pardon the pun).
    How can I avoid the stage db hit bloat described above, and have it just start with only blue nodes?






    neo4j







    share|improve this question



























      0












      0








      0








      My DB consists of two node groups (labels) x and y. y nodes also have additional labels (colors: blue, red, green, etc).



      My query is:
      MATCH (n1:y)-->(n2:x)<--(n3:blue) RETURN n2.idx



      The profile shows an expand for n3 without any reference to it being blue, resulting in 12,000 DB hits, pushing out 12,000 rows. The next stage is a filter for blue, resulting in nearly 24,000 DB hits returning 1,036 rows.



      I have constraints on both idx and idy being unique, and I have the index on each of the colors.



      I have tried using a color attribute on the y nodes, changing the query to the following, without any difference in the profile.
      MATCH (n1:y)-->(n2:x)<--(n3:y {color:blue}) RETURN n2.idx



      I've tried using index n3:blue(idy) before the RETURN statement, but that gives me a syntax error. I'm still trying to decypher that (pardon the pun).
      How can I avoid the stage db hit bloat described above, and have it just start with only blue nodes?






      neo4j







      share|improve this question
















      My DB consists of two node groups (labels) x and y. y nodes also have additional labels (colors: blue, red, green, etc).



      My query is:
      MATCH (n1:y)-->(n2:x)<--(n3:blue) RETURN n2.idx



      The profile shows an expand for n3 without any reference to it being blue, resulting in 12,000 DB hits, pushing out 12,000 rows. The next stage is a filter for blue, resulting in nearly 24,000 DB hits returning 1,036 rows.



      I have constraints on both idx and idy being unique, and I have the index on each of the colors.



      I have tried using a color attribute on the y nodes, changing the query to the following, without any difference in the profile.
      MATCH (n1:y)-->(n2:x)<--(n3:y {color:blue}) RETURN n2.idx



      I've tried using index n3:blue(idy) before the RETURN statement, but that gives me a syntax error. I'm still trying to decypher that (pardon the pun).
      How can I avoid the stage db hit bloat described above, and have it just start with only blue nodes?






      neo4j




      neo4j






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 1 at 10:11









      Mohamad Armoon

      594825




      594825










      asked Jan 1 at 4:00









      ChiefChief

      1




      1
























          1 Answer
          1






          active

          oldest

          votes


















          0














          You can use a scan hint to start using a label scan on n3.



          MATCH (n1:y)-->(n2:x)<--(n3:blue) 
          
USING SCAN n3:blue
          
RETURN n2.idx


          Also, this may produce duplicates if :x nodes can have multiple relationships to :y nodes or :blue nodes. If you only want :x nodes that have a connection to a :y node, then you might try this instead:



          MATCH (n2:x)<--(n3:blue) 
          
USING SCAN n3:blue
          
WHERE (:y)-->(n2)
          
WITH DISTINCT n2
          
RETURN n2.idx





          share|improve this answer


























          • Thanks for the answer. Unfortunately, that causes many more hits to find all of the n3 nodes with label blue. There are a lot of them. Maybe I'm thinking about this wrong.

            – Chief
            Jan 3 at 0:51











          • First, we want all edges that exist from n3:blue to n2:x nodes that are first found by the (n1)-->(n2) relationship. So, for the performance issue of the (n2)<--(n3:blue), in the expand portion, It appears to be just gathering the relationship list getting 12000 hits, but what are those hits? I'm now thinking that is just building up the list of a (n3) ids from the relationship. The next 12000 hits in the filter is the db finding the labels of those first hits. So then there is no means to have the expand step only go to blue nodes unless I 1st do the huge blue lookup. right?

            – Chief
            Jan 3 at 1:08













          • From a starting node, there is no way to tell anything about the node it's connected to without expanding to it, then filtering in some way (such as to get only nodes with a certain label). However, if you use a specific relationship type just to nodes with those labels, then you can avoid the db hits and filtering since nodes know their relationship types and can only traverse the ones with that particular type.

            – InverseFalcon
            Jan 3 at 7:51











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53992921%2fneo4j-not-cluing-into-the-multiple-labels%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          You can use a scan hint to start using a label scan on n3.



          MATCH (n1:y)-->(n2:x)<--(n3:blue) 
          
USING SCAN n3:blue
          
RETURN n2.idx


          Also, this may produce duplicates if :x nodes can have multiple relationships to :y nodes or :blue nodes. If you only want :x nodes that have a connection to a :y node, then you might try this instead:



          MATCH (n2:x)<--(n3:blue) 
          
USING SCAN n3:blue
          
WHERE (:y)-->(n2)
          
WITH DISTINCT n2
          
RETURN n2.idx





          share|improve this answer


























          • Thanks for the answer. Unfortunately, that causes many more hits to find all of the n3 nodes with label blue. There are a lot of them. Maybe I'm thinking about this wrong.

            – Chief
            Jan 3 at 0:51











          • First, we want all edges that exist from n3:blue to n2:x nodes that are first found by the (n1)-->(n2) relationship. So, for the performance issue of the (n2)<--(n3:blue), in the expand portion, It appears to be just gathering the relationship list getting 12000 hits, but what are those hits? I'm now thinking that is just building up the list of a (n3) ids from the relationship. The next 12000 hits in the filter is the db finding the labels of those first hits. So then there is no means to have the expand step only go to blue nodes unless I 1st do the huge blue lookup. right?

            – Chief
            Jan 3 at 1:08













          • From a starting node, there is no way to tell anything about the node it's connected to without expanding to it, then filtering in some way (such as to get only nodes with a certain label). However, if you use a specific relationship type just to nodes with those labels, then you can avoid the db hits and filtering since nodes know their relationship types and can only traverse the ones with that particular type.

            – InverseFalcon
            Jan 3 at 7:51
















          0














          You can use a scan hint to start using a label scan on n3.



          MATCH (n1:y)-->(n2:x)<--(n3:blue) 
          
USING SCAN n3:blue
          
RETURN n2.idx


          Also, this may produce duplicates if :x nodes can have multiple relationships to :y nodes or :blue nodes. If you only want :x nodes that have a connection to a :y node, then you might try this instead:



          MATCH (n2:x)<--(n3:blue) 
          
USING SCAN n3:blue
          
WHERE (:y)-->(n2)
          
WITH DISTINCT n2
          
RETURN n2.idx





          share|improve this answer


























          • Thanks for the answer. Unfortunately, that causes many more hits to find all of the n3 nodes with label blue. There are a lot of them. Maybe I'm thinking about this wrong.

            – Chief
            Jan 3 at 0:51











          • First, we want all edges that exist from n3:blue to n2:x nodes that are first found by the (n1)-->(n2) relationship. So, for the performance issue of the (n2)<--(n3:blue), in the expand portion, It appears to be just gathering the relationship list getting 12000 hits, but what are those hits? I'm now thinking that is just building up the list of a (n3) ids from the relationship. The next 12000 hits in the filter is the db finding the labels of those first hits. So then there is no means to have the expand step only go to blue nodes unless I 1st do the huge blue lookup. right?

            – Chief
            Jan 3 at 1:08













          • From a starting node, there is no way to tell anything about the node it's connected to without expanding to it, then filtering in some way (such as to get only nodes with a certain label). However, if you use a specific relationship type just to nodes with those labels, then you can avoid the db hits and filtering since nodes know their relationship types and can only traverse the ones with that particular type.

            – InverseFalcon
            Jan 3 at 7:51














          0












          0








          0







          You can use a scan hint to start using a label scan on n3.



          MATCH (n1:y)-->(n2:x)<--(n3:blue) 
          
USING SCAN n3:blue
          
RETURN n2.idx


          Also, this may produce duplicates if :x nodes can have multiple relationships to :y nodes or :blue nodes. If you only want :x nodes that have a connection to a :y node, then you might try this instead:



          MATCH (n2:x)<--(n3:blue) 
          
USING SCAN n3:blue
          
WHERE (:y)-->(n2)
          
WITH DISTINCT n2
          
RETURN n2.idx





          share|improve this answer















          You can use a scan hint to start using a label scan on n3.



          MATCH (n1:y)-->(n2:x)<--(n3:blue) 
          
USING SCAN n3:blue
          
RETURN n2.idx


          Also, this may produce duplicates if :x nodes can have multiple relationships to :y nodes or :blue nodes. If you only want :x nodes that have a connection to a :y node, then you might try this instead:



          MATCH (n2:x)<--(n3:blue) 
          
USING SCAN n3:blue
          
WHERE (:y)-->(n2)
          
WITH DISTINCT n2
          
RETURN n2.idx






          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jan 2 at 2:02

























          answered Jan 1 at 8:51









          InverseFalconInverseFalcon

          19.3k31830




          19.3k31830













          • Thanks for the answer. Unfortunately, that causes many more hits to find all of the n3 nodes with label blue. There are a lot of them. Maybe I'm thinking about this wrong.

            – Chief
            Jan 3 at 0:51











          • First, we want all edges that exist from n3:blue to n2:x nodes that are first found by the (n1)-->(n2) relationship. So, for the performance issue of the (n2)<--(n3:blue), in the expand portion, It appears to be just gathering the relationship list getting 12000 hits, but what are those hits? I'm now thinking that is just building up the list of a (n3) ids from the relationship. The next 12000 hits in the filter is the db finding the labels of those first hits. So then there is no means to have the expand step only go to blue nodes unless I 1st do the huge blue lookup. right?

            – Chief
            Jan 3 at 1:08













          • From a starting node, there is no way to tell anything about the node it's connected to without expanding to it, then filtering in some way (such as to get only nodes with a certain label). However, if you use a specific relationship type just to nodes with those labels, then you can avoid the db hits and filtering since nodes know their relationship types and can only traverse the ones with that particular type.

            – InverseFalcon
            Jan 3 at 7:51



















          • Thanks for the answer. Unfortunately, that causes many more hits to find all of the n3 nodes with label blue. There are a lot of them. Maybe I'm thinking about this wrong.

            – Chief
            Jan 3 at 0:51











          • First, we want all edges that exist from n3:blue to n2:x nodes that are first found by the (n1)-->(n2) relationship. So, for the performance issue of the (n2)<--(n3:blue), in the expand portion, It appears to be just gathering the relationship list getting 12000 hits, but what are those hits? I'm now thinking that is just building up the list of a (n3) ids from the relationship. The next 12000 hits in the filter is the db finding the labels of those first hits. So then there is no means to have the expand step only go to blue nodes unless I 1st do the huge blue lookup. right?

            – Chief
            Jan 3 at 1:08













          • From a starting node, there is no way to tell anything about the node it's connected to without expanding to it, then filtering in some way (such as to get only nodes with a certain label). However, if you use a specific relationship type just to nodes with those labels, then you can avoid the db hits and filtering since nodes know their relationship types and can only traverse the ones with that particular type.

            – InverseFalcon
            Jan 3 at 7:51

















          Thanks for the answer. Unfortunately, that causes many more hits to find all of the n3 nodes with label blue. There are a lot of them. Maybe I'm thinking about this wrong.

          – Chief
          Jan 3 at 0:51





          Thanks for the answer. Unfortunately, that causes many more hits to find all of the n3 nodes with label blue. There are a lot of them. Maybe I'm thinking about this wrong.

          – Chief
          Jan 3 at 0:51













          First, we want all edges that exist from n3:blue to n2:x nodes that are first found by the (n1)-->(n2) relationship. So, for the performance issue of the (n2)<--(n3:blue), in the expand portion, It appears to be just gathering the relationship list getting 12000 hits, but what are those hits? I'm now thinking that is just building up the list of a (n3) ids from the relationship. The next 12000 hits in the filter is the db finding the labels of those first hits. So then there is no means to have the expand step only go to blue nodes unless I 1st do the huge blue lookup. right?

          – Chief
          Jan 3 at 1:08







          First, we want all edges that exist from n3:blue to n2:x nodes that are first found by the (n1)-->(n2) relationship. So, for the performance issue of the (n2)<--(n3:blue), in the expand portion, It appears to be just gathering the relationship list getting 12000 hits, but what are those hits? I'm now thinking that is just building up the list of a (n3) ids from the relationship. The next 12000 hits in the filter is the db finding the labels of those first hits. So then there is no means to have the expand step only go to blue nodes unless I 1st do the huge blue lookup. right?

          – Chief
          Jan 3 at 1:08















          From a starting node, there is no way to tell anything about the node it's connected to without expanding to it, then filtering in some way (such as to get only nodes with a certain label). However, if you use a specific relationship type just to nodes with those labels, then you can avoid the db hits and filtering since nodes know their relationship types and can only traverse the ones with that particular type.

          – InverseFalcon
          Jan 3 at 7:51





          From a starting node, there is no way to tell anything about the node it's connected to without expanding to it, then filtering in some way (such as to get only nodes with a certain label). However, if you use a specific relationship type just to nodes with those labels, then you can avoid the db hits and filtering since nodes know their relationship types and can only traverse the ones with that particular type.

          – InverseFalcon
          Jan 3 at 7:51




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid …



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53992921%2fneo4j-not-cluing-into-the-multiple-labels%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          -

          Popular posts from this blog

          Monofisismo

          Image
          Monofisismo (do grego: monos - "único, singular" e physis - "natureza") é o ponto de vista cristológico que defende que, depois da união do divino e do humano na encarnação histórica, Jesus Cristo, como encarnação do Filho ou Verbo ( Logos ) de Deus, teria apenas uma única "natureza", a divina, e não uma síntese de ambas. O monofisismo é contraposto pelo diofisismo (ou "diafisismo"), que defende que Jesus preservou em si as duas naturezas. Historicamente, o monofisismo se refere primordialmente à posição dos que (especialmente no Egito e, em menor grau, na Síria) rejeitaram as decisões do Concílio de Calcedônia em 451 (o quarto concílio ecumênico). Os membros mais moderados entre eles, porém, defendem a teologia "miafisita", que se tornou a oficial para as Igrejas Ortodoxas Orientais. Muitos ortodoxos orientais, porém, rejeitam essa classificação, mesmo como um termo genérico, mas ele é amplamente utilizado na literatura históri...
          Read more

          Angular Downloading a file using contenturl with Basic Authentication

          Image
          0 I have a contentUrl when user clicks on that,file should be downloaded. If I try to browse the contentUrl in the browser it asks for Userid and password.I believe this is Basic Authentication.I dont want user to enter UserId and Password so I am passing it Authorization(Please see below code). Url looks some thing like this: http://XXX.XXX.XX.XXX:8080/flowable-rest/service/runtime/tasks/90875/attachments/90555/content let username : string = 'admin'; let pwd : string = 'test'; let headers = new Headers(); headers.set('Accept', 'text/json'); headers.append('Content-Type', 'application/json'); headers.set('Access-Control-Allow-Origin', '*'); headers.set('Access-Control-Allow-Methods','POST, GET, OPTIONS, PUT, DELETE'); head...
          Read more

          Olmecas

          Image
          Monumento 1, uma das quatro cabeças colossais encontradas em La Venta, com altura aproximada de 3 metros Olmecas é a designação do povo e da civilização que estiveram na origem da antiga cultura pré-colombiana da Mesoamérica e que se desenvolveram nas regiões tropicais do centro-sul do atual México durante o pré-clássico, próximo de onde hoje estão localizados os estados mexicanos de Veracruz e Tabasco, no Istmo de Tehuantepec, numa zona designada área nuclear olmeca. A cultura olmeca floresceu nesta região aproximadamente entre 1500 e 400 a.C., [ 1 ] e crê-se que tenha sido a civilização-mãe de todas as civilizações mesoamericanas que se desenvolveram posteriormente. [ 2 ] No entanto, desconhece-se a sua exacta filiação étnica, ainda que existam numerosas hipóteses colocadas para tentar resolver esta questão. O etnónimo olmeca foi cunhado pelos arqueólogos do século XX, e não devem confundir-se com os muito posteriores olmecas-xicalancas que ocuparam vários locais do México...
          Read more