Amazon Neptune
https://gyazo.com/0f86b6d3e315ca6d77021f62d2172c3e
Claude Code.icon
グラフDBは普通どちらかに寄るのですが、Neptuneは両刀です。
code:_
┌─ property graph 系 → Gremlin / openCypher
Amazon Neptune ───┤
└─ RDF 系 → SPARQL
つまり「Neo4j的な使い方」も「Wikidata/SPARQL的な使い方」も、同じエンジンの上で選べる。
対応している3つのクエリ言語
ここがNeptuneを理解する一番のポイントです
グラフの世界は言語が分裂していて、Neptuneは主要なものを全部サポートしています。
table:_
言語 系統 出自 イメージ
Gremlin property graph Apache TinkerPop 「たどる」操作を手続き的に連ねる openCypher property graph Neo4r由来のオープン版 MATCH (a)-[:友達]->(b) の宣言的記法 SPARQL RDF W3C標準 トリプルをパターンマッチで問い合わせ 注意点として、property graphのデータとRDFのデータは内部的には別の世界で、「SPARQLでGremlinのデータを読む」みたいな相互乗り入れは基本できません。最初にどっちで設計するか決める話です。
どんなときに使うか(ユースケース)
グラフDB全般の典型例とほぼ同じで、「関係をたどる問いが主役」の領域です。
ソーシャルグラフ — 友達の友達、共通の知人レコメンド
不正検知 — 「同じ端末・住所・カードを共有する一見無関係なアカウント群」を関係から炙り出す
レコメンド — 「これを買った人が次に買うもの」
ナレッジグラフ — 企業内の用語・製品・人の関係を統合(RDF/SPARQLが活きる)
ネットワーク/IT資産管理 — 機器の依存関係、影響範囲分析
生命科学 — 遺伝子・タンパク質・疾患の関係(この分野はRDF文化が強い)
逆に「全文検索したい」「ログ集計したい」なら前回のOpenSearch、「単純な表とトランザクション」ならRDS/Auroraであって、Neptuneの出番ではありません。