1. ホーム
  2. database

[解決済み] Graph-based Databases (http://neo4j.org/)のユースケースは?[クローズド]

2022-06-16 07:47:28

質問

私はリレーショナルDBをよく使っていますが、他のタイプにも挑戦してみることにしました。

この特定の製品は良さそうで、期待できそうです。 http://neo4j.org/

グラフベースのデータベースを使ったことがある方はいらっしゃいますか?ユーザビリティの観点から、どのような長所と短所がありますか?

実稼働環境でこれらを使用したことがありますか?それらを使用するようになった要件は何ですか?

どのように解決しましたか?

前職でグラフデータベースを使ったことがあります。neo4j を使っていたわけではなく、Berkeley DB の上に構築された社内のものでしたが、似たようなものでした。それは本番で使用されていました (現在もそうです)。

私たちがグラフ データベースを使用した理由は、システムによって保存されるデータと、システムがそのデータに対して行う操作が、まさにリレーショナル データベースの弱点であり、グラフ データベースの強味であったからです。システムは、固定スキーマを持たず、関係によって結ばれたオブジェクトの集合を保存する必要がありました。データについて推論するために、システムは、グラフ データベースでは数回のトラバーサルになるけれども、SQL では非常に複雑なクエリになるような多くのオペレーションを行う必要がありました。

グラフモデルの主な利点は、迅速な開発期間と柔軟性でした。既存のデプロイメントに影響を与えることなく、新しい機能をすばやく追加することができました。潜在的な顧客が独自のデータをインポートして、私たちのモデルの上に接ぎ木したい場合、通常、営業担当者がその場で行うことができます。柔軟性は、新しい機能を設計する際にも役立ち、硬直したデータモデルに新しいデータを押し込もうとする手間を省くことができました。

奇妙なデータベースを持つことで、他の多くの奇妙な技術を構築することができ、競合他社の製品との差別化を図るための秘密のソースがたくさん得られました。

主な欠点は、私たちが標準的なリレーショナル データベース技術を使用していないことで、これは顧客が企業である場合に問題となることがあります。当社の顧客は、なぜ当社のデータを自社の巨大な Oracle クラスターにホストできないのかと尋ねてきました (当社の顧客は通常、大規模なデータセンターを持っていました)。実際にチームの一人がデータベースレイヤーをOracle(またはPostgreSQL、MySQL)を使うように書き直しましたが、オリジナルより若干遅くなってしまったのです。少なくともある大企業では、Oracleオンリーのポリシーまでありましたが、幸運にもOracleがBerkeley DBを買収してくれました。また、私たちは多くの追加ツールを書かなければなりませんでした。たとえば、Crystal Reports をそのまま使用することはできませんでした。

グラフデータベースのもうひとつの欠点は、私たちが自分たちで構築したことで、問題 (通常はスケーラビリティ) にぶつかったとき、自分たちで解決しなければならなかったことです。もし私たちがリレーショナル データベースを使用していたら、ベンダーは 10 年前にすでにその問題を解決していたことでしょう。

もしあなたが企業顧客向けの製品を作っていて、あなたのデータがリレーショナル モデルに適合するならば、可能であればリレーショナル データベースを使いましょう。もし、アプリケーションがリレーショナルモデルには合わないが、グラフモデルには合うのであれば、グラフデータベースを使いましょう。もし、他のものにしか当てはまらないのであれば、それを使ってください。

もしアプリケーションが現在のblubアーキテクチャに適合する必要がなければ、グラフデータベース、CouchDB、BigTable、またはあなたのアプリケーションに適合し、あなたがクールだと思うものを使ってください。それはあなたに利点を与えるかもしれませんし、新しいことを試すのは楽しいことです。

あなたが何を選んだとしても、データベースエンジンを構築するのが本当に好きでない限り、データベースエンジンを自分で構築しないようにしてください。