最適なパフォーマンスを得るために、Neo4jモデル/クエリのパフォーマンス/構成に関するアドバイスが必要

リレーショナルデータをT-SQLからGraphDBに（Neo4jを使用して）シフトできるかどうかをテストするために、GraphDBの実験に取り組んでいます。グラフ構造をクエリするとメリットが得られる大量のデータを処理することを検討しています。現時点では、いくつかの単純なwhere句と集計手順でも、クエリのパフォーマンスが非常に低くなっています。Neo4jは数十億のノードで動作すると主張しているので、パフォーマンスを向上させる方法についてアドバイスを得るとよいでしょう。これが私たちが試したすべてです。

それでは、データについて説明します。オンラインで訪問/購入した国（地理）と製品（SKU）に関する顧客データがあります。顧客がWebサイトにアクセスするたびに、そのビュー/購入は、30分後に変更される一意のセッションIDの一部として追跡されます。個別のセッションIDを計算することにより、ユーザーがWebサイトにアクセスした回数を正確に計算しようとしています。

ウェブサイトにアクセスしたときに行われた顧客の訪問/購入に関連する約2600万行のデータがあります。SQLのデータは次の形式です。

----------------------------------------------------------------------------
|    Date|   SessionId|   Geography|   SKU|   OrderId|    Revenue|   Units||
|--------|------------|------------|------|----------|-----------|--------||
|20160101|         111|         USA|     A|      null|          0|       0||
|20160101|         111|         USA|     B|         1|         50|       1||
|20160101|         222|          UK|     A|         2|         10|       1||
----------------------------------------------------------------------------

問題：顧客がサイトにアクセスした回数を正確に計算する必要があります。訪問は個別のセッションIDとして計算されます。

訪問計算ロジックの説明：上記のモデルで、「A」という名前のSKUを探している人がサイトにアクセスした訪問を表示すると、答えは2になります。セッション111の最初のビューとセッション222の2番目のビュー。 SKU「A」または「B」を探してサイトにアクセスしたユーザーの訪問数を知りたい場合、回答も2になります。これは、セッション111で両方の製品が表示されたが、合計訪問数であるためです。 1つだけです。セッション111には2つの製品ビューがありますが、訪問は1つだけです。したがって、222からの他の訪問を数えると、まだ合計2回の訪問があります。

構築したモデルは次のとおりです。データに存在する行ごとに1つずつ、ファクトノードがあります。それぞれ400と4000の異なる地理ノードと製品ノードを作成しました。これらの各ノードは、複数のファクトと関係があります。同様に、Datesには個別のノードがあります。

セッションIDと注文IDにも個別のノードを作成しました。これらは両方とも事実を示しています。したがって、基本的に、次のプロパティを持つ個別のノードがあります。

1) Geography  {Locale, Country}
2) SKU {SKU, ProductName}
3) Date {Date}
4) Sessions {SessionIds}
5) Orders {OrderIds}
6) Facts {Locale, Country, SKU, ProductName, Date, SessionIds, OrderIds}

関係スキーマは、一致するプロパティ値に基づいており、次のようになります。

(:Geography)-[:FactGeo]->(:Facts)
(:SKU)-[:FactSKU]->(:Facts]
(:Date)-[:FactDate]->(:Facts)
(:SessionId)-[:FactSessions]->(:Facts)
(:OrderId)-[:FactOrders]->(:Facts)

スキーマのスナップショットは次のとおりです。

インデックスがないことが問題の原因である可能性があると述べた方もいらっしゃると思いますが、必要なインデックスはすべてあります。私がほとんどクエリを実行しない余分なインデックスを追加しても、パフォーマンスがそれほど大幅に低下することはないと思います。

合計4,400万のノードがあり、それらのほとんどはFactsノードとSessionIdノード用です。1億3100万の関係があります。

約20か国に属する人々と約20の製品の個別の訪問を特定するためにクエリを実行しようとすると、回答を得るのに約44秒かかります。同じ場合（Neo4jでインデックスが作成されている場合）、SQLは約47秒（インデックスなし）かかります。SQLでインデックスを作成するとパフォーマンスが向上すると思うので、これはNeo4jを使用して得たいと思っていた例外的な改善ではありません。

私が書いたクエリは次のようなものでした：

(geo: Geography)-[:FactGeo]->(fct: Facts)<-(sku: SKU)
WHERE geo.Country IN ["US", "India", "UK"...]
AND sku.SKU IN ["A","B","C".....]
MATCH (ssn: Sessions)-[:FactSessions]->(fct)
RETURN COUNT(DISTINCT ssn.SessionId);

PROFILEを使用すると、約69Mのdbヒットが発生します。

Q1) Is there a way I can improve this model to have a better performing query? For example i can change the above model by removing the Session nodes and just counting the SessionIds present on Fact nodes as in the query below:

(geo: Geography)-[:FactGeo]->(fct: Facts)<-(sku: SKU)
WHERE geo.Country IN ["US", "India", "UK"...]
AND sku.SKU IN ["A","B","C".....]
RETURN COUNT(DISTINCT fct.SessionId);

Which happens because of the huge number of nodes and relationships between Facts and Sessions. So it seems that i would rather benefit from having SessionIds as a Property of Facts nodes.

When i use PROFILE, this results in approx 50M db hits:

Also, can someone help me understand the tipping point where it becomes difficult to scan nodes on the basis of properties as I increase the number of properties the nodes have?

Q2) Is there something wrong with my Neo4j configurations as it is taking 44 seconds? I have a 114GB ram for the java heap, but no SSD. I have not tweaked around with other configurations and would like to know if those could be the bottleneck over here as I was told that Neo4j could run on billions of nodes?

My Machine's Total RAM: 140GB RAM dedicated to Java heap: 114GB (From what I recollect, there was almost negligible performance increase as i moved from 64GB RAM to 114GB) Page Cache Size: 4GB Approximate GraphDB size: 45GB Neo4j Version i am using: 3.0.4 Enterprise Edition

Q3) Is there any better way to formulate a query which performs better? I tried the following query:

(geo: Geography)-[:FactGeo]->(fct: Facts)
WHERE geo.Country IN ["US", "India", "UK"...]
MATCH (sku: SKU)-[:FactSKU]->(fct)
WHERE sku.SKU IN ["A","B","C".....]
RETURN COUNT(DISTINCT fct.SessionId);

But it gives around the same performance and records the same number of DBhits as the slightly improved query in Q1.

When i use PROFILE, this results in approx 50M db hits, exactly same as the query in Q1:

Q4) If i modify my query from Q3 to as below, instead of seeing an improvement i see a major decrease in performance:

MATCH (geo: Geography)
WHERE geo.Country IN ["US", "India", "UK"...]
WITH geo
MATCH (sku: SKU)
WHERE sku.SKU IN ["A","B","C".....]
WITH geo, sku
MATCH (geo)-[:FactGeo]->(fct: Facts)<-[:FactSKU]-(sku)
RETURN COUNT(DISTINCT fct.SessionId);

This appears to be creating a cross join between the 400 Geography nodes and the 4000 sku nodes, and then testing each relationship to possible exist between one of those 1,600,000 possible relationship combinations. Am i understanding this correctly?

I know these are long questions and a very long post. But I have tried tirelessly for more than a week to work these things out on my own and i have shared some of my findings over here. Hopefully the community will be able to guide me with some of these queries. Thanks in advance for even reading the post!

EDIT-01: Tore, Inverse and Frank, Thanks a lot for trying to help me out guys, I hope we can figure out the root cause here.

A) I have added some more details, regarding my PROFILE results and also my SCHEMA and Machine/Neo4j config stats.

B) As i consider the model that @InverseFalcon suggested, and try to keep in mind the facts about relationships being a better choice and limiting the number of relationships.

I am tweaking Inverse's model a bit because I think we might be able to reduce it a bit. How is this for as a model:

(:Session)-[:ON]->(:Date)
(:Session)-[:IN]->(:Geography)
(:Session)-[:Viewed]->(:SKU)
(:Session)-[:Bought]->(:SKU)

OR

(:Session)-[:ON]->(:Date)
(:Session)-[:IN {SKU: "A", HasViewedOrBought: 1}]->(:Geography)

Now both of the models can have advantages. In the first one I maintain SKUs as distinct nodes and have different relationships between them to determine if it was a purchase or a view.

In the second one, i completely remove the SKU nodes adding them as relationships. I understand that this will lead to many relationships, but the number of relationships will still be small as we are also discarding all the nodes and relationships of SKU nodes which we are removing. We will have to test the Relationship by comparing the SKU strings, and that is an intensive operation and perhaps could be avoided by keeping only Session and Geography nodes and removing the Date nodes and adding Date property to the SKU relationships. As below:

(:Session)-[:ON]->(:Date)
(:Session)-[:IN {Date: {"2016-01-01"}, SKU: "A", HasViewedOrBought: 1}]->(:Geography)

But then I would be testing the relationships between the Geography and SKU nodes on the basis of two properties, both of which are strings. (Arguably date can be converted to integer, but still i see we have another face-off between alternate models)

C) @Tore, thanks for explaining and confirming my understanding of Q4. But if the GraphDB does a calculation like that, in which it joins and compares every relation with that join, isn't it actually working in the same manner an RDBMS should? It is ineffective in utilizing the graph traversals that it should easily be able to do by finding direct paths between the two set of Geography and Product nodes. This seems to be a bad implementation to me?