モデリングのアンチパターン ― 密結合ノード・過剰なプロパティ・向きの乱れ

導入

グラフのモデリングには自由度がある分、避けたほうがよい「よくある失敗パターン（アンチパターン）」もあります。代表的な3つを見ておきましょう。

説明

1. 密結合ノード（スーパーノード）問題 … 特定のノードに、極端に大量のリレーションシップが集まってしまうケースです。たとえば「日本」という国のノードに、日本に住む数百万人の Person ノードから直接リレーションシップを張ってしまうと、そのノードに関わるクエリが極端に遅くなります。

graph TB
    japan(("日本"))
    p1["人物1"] --> japan
    p2["人物2"] --> japan
    p3["人物3"] --> japan
    pn["... 数百万人"] --> japan

このような場合は、中間に「都道府県」や「市区町村」のノードを挟むなど、つながりを分散させる工夫が必要になります。

2. 過剰なプロパティ問題 … 本来別のノードとして表現すべき情報を、1つのノードのプロパティに詰め込みすぎるケースです。たとえば Person ノードに company1、company2、company3 のようなプロパティを並べてしまうと、「何社に勤めたか」が分からないうえに検索もしづらくなります。この場合は Company ノードを別に作り、[:WORKED_AT] のようなリレーションシップでつなぐべきです。

3. 向きの乱れ問題 … 同じ種類の関係なのに、あるところでは (a)-[:FOLLOWS]->(b)、別のところでは (b)-[:FOLLOWS]->(a) のように向きの基準がバラバラになってしまうケースです。向きが統一されていないと、クエリを書くたびに向きを気にしなければならず、バグの温床になります。リレーションシップの向きは、チーム内で早い段階から一貫したルールを決めておくことが大切です（例:「フォローする側→される側」で必ず統一する）。

これらのアンチパターンは、いずれも「後から直すコストが高い」という共通点があります。データを本格的に投入する前に、想定するクエリを紙に書き出し、モデルがそれに自然に応えられるかを確認しておくことが、遠回りのようで一番の近道です。