初めに明確にして、テーマをしっかりと守りましょう。
今日私たちが議論したい質問は、あなた (私、彼、全員) が遭遇するグラフ データベースはなぜ信頼できないのかということです。宣伝されているほど強力ではありませんか？
この問題には 2 つのレベルがあります。
- 予想されるギャップ
- 慈悲を求めて慈悲を得る
期待のギャップについては、グラフ データベースが「高速で経済的」であることを望んでいますが、具体的には、無制限の量のデータを保存でき、信じられないほど高速で、使いやすく、コストがあまりかからないことを意味します。くだらないことを言う必要はありませんが、こんな美しいものが本当に存在すると思いますか？
無料のオープンソース (従来型、リレーショナル) データベースだけを考えているとしたら、MySQL や PostgreSQL など、非常に強力なものがたくさんあるのではないでしょうか?
次に、データベース開発の歴史について話さなければなりません。MySQL と PostgreSQL はいつ登場しましたか? 2000年頃って、遠い昔のことのように感じます。しかし、最も初期のリレーショナル データベースは 1970 年代に登場しました。オラクル（前身）は1972年に設立された会社です。オープンソース データベースが登場するまでには開発に 30 年かかりましたが、それ以前は商用バージョンが唯一の選択肢でした。
一方で、新しいテクノロジー、特に破壊的テクノロジー製品が意味を持つためには、初期段階で十分な利益率がなければなりません（新しい最先端のテクノロジーには料金プレミアムが必要です。そうでなければ誰がイノベーションを起こすのでしょうか？）。そうでなければ、市場は次のようなものになります。が深刻に関与しており、最終的には誰もお金を稼ぐことができません。これが今日の中国のテクノロジー産業の現状です - イノベーションはほとんどなく、すべてオープンソースを使用して無料のカスタム開発を行っています。コア技術は誰が所有しているのでしょうか?
新しいテクノロジーに本当に核となる価値があり、商業的価値を生み出すことができるのであれば、その作成者はオープンソース コミュニティを構築するのではなく、ずっと前にそれを商品化して販売して金儲けをしていたはずです。何かを想像してみてください。それを自分で商品化する方法がわかりません。オープンソース コミュニティはそれを商品化するのに役立ちますか? 冗談だ、大冗談だ。これは人間の本性に反することです。特に低レベル、ハードコア、ディープ テクノロジーの分野では、オープンソースの道を歩む人は全員、2 つの可能性のいずれか (または両方) を抱えています: 1. 詐欺、2. 大きな隠れた危険があります。
Linux (および Linus) は非常に強力ですが、隠れた危険は何ですか?
ハハ、Linus は隠れた最大の危険です。世界最大のオープンソース コミュニティの Linux カーネルが現在 Linus 自身によってレビューされていると想像できますか。彼が最大のボトルネックなのでしょうか? 彼が死んだら、Linux プロジェクトは今後どのように発展するのでしょうか (笑)。
別の言い方をすると、MongoDB は最も成功した NoSQL データベースですが、何が問題なのでしょうか?
はい、今日に至るまで巨額の損失を被っています。これは隠れた危険ではないでしょうか？いわゆるインターネット思考は本質的にはビジネス詐欺です。
慈悲を求め、慈悲を得る: これについては説明する必要はありません。より速く、より簡単で、より経済的なものなどありません。これは毎日空からパイが降ってくる夢を見るのと同じ論理で、その確率は空から小惑星が降ってくるのとほぼ同じです。私は甲として、毎日乙にタダで金を払い、乙を搾取し、搾取することばかり考えており、社会的責任は一切なく、このような経営環境ではイノベーションの必要はない。
次に、質問そのものに戻ってみましょう。なぜグラフ データベースは失敗するのでしょうか?
製品とテクノロジーの2つの側面から分析します。
現在市販されているグラフデータベースと呼ばれる製品の特徴をよく見てみると、それがオープンソースかどうかは関係ありません。製品の特徴について説明し、いくつかの例を挙げてみましょう。
- クエリ言語: Cypher と Gremlin がサポートされています。この観点から、このシステムは「4 つの異なる」ものであることがわかります。これは、複数のクエリ言語をサポートする中国のグラフ データベースにとっても「初」であり、いくつかの企業がこの機能を備えていると主張しています。互換性が高そうに見えますが、実は最下層には何の機能も無いことも分かります。自社開発の最下位層を持たないからこそ、上位層でどのようなクエリ言語をサポートするかは関係なく、誰でも実行できます。言い換えれば、このデータベースのパフォーマンスは非常に悪いはずです。
- 大規模なデータストレージとリアルタイムの深層掘削という「魚とケーキ」のバランスをどう取るか: この問題は実際には世界クラスの問題ですが、中国の「グラフデータベース」会社の前では「簡単に解決」されます。まず、NVidia の Lao Huang が数週間前にリリースした GPU+CPU スーパーコンピューティング プラットフォームを確認しましょう。まだ印象に残っている方は、そのカスケード アーキテクチャは本質的に HPC スーパーコンピューティング アーキテクチャです。簡単に言うと、それは、テラバイト単位のメモリを積み重ねること (はい、彼らのメモリはほとんどの企業の大規模な外部メモリよりも大きいです)、および GPU と CPU の同時実行性 (GPU の同時実行性は基本的に CPU の 10 倍以上です) によるものです。 GPU はより同時実行性が高くなりますが、CPU が得意とする一般的な数学演算を完了することはできません)。正確に言うと、Lao Huang のアーキテクチャは半世紀前のミニフレームと本質的に同じです。NVidia がオープンソースのビッグデータ分散フレームワークを理解していないのではないかと疑問に思いますか? 彼らはこの問題を研究していないと思いますか？現在、グラフ データベース メーカーのいわゆる大規模分散ストレージ アーキテクチャはすべて、保存のみ可能であり、計算はできません。ここで説明する計算は、関連する計算と分析です。保存できるかどうかを計算できるかどうかは、分散ストレージと集中コンピューティングを指します。ここには大きな罠があります。保存されたデータと計算の間には、データ移行プロセスまたはデータ マッピング プロセスが必要です。これは、Apache Spark の ETL に似ています。つまり、データがディスクに配置された後、特定のグラフ クエリまたはグラフ アルゴリズムを実行すると、データをどこか (おそらく大きなメモリを備えたサーバー) に移行またはマップする必要があります。このプロセスはデータ量に依存し、非常に時間がかかる場合があります。最も面白いのは、次の問題です。このアーキテクチャは、表面上はデータをグラフに入力（永続化）しているが、計算すると一台のマシンで集中処理するのと同等となり、この処理は「保存したまま計算する」ということは一切できない。 。この問題については三日三晩議論できますが、今要約できることは次のとおりです。すべての分散ストレージと集中コンピューティングにはシーンに大きな制限があり、リアルタイム コンピューティング リクエストを処理できず、一部のバッチ処理シナリオにのみ適しています。 ——グラフデータベースの意味に戻りますが、データウェアハウスやリレーショナルデータベースのバッチ処理をリアルタイムに高速化するためのものではないでしょうか？共同編集ですか、それともバッチ処理ですか? したがって、この種の構造に遭遇すると、間違いなくがっかりするでしょう。
- 精密計算ですか、サンプリング計算ですか？この質問は非常に広範囲にわたるため、図では両方のモードが存在する必要があります。例えば、グラフアルゴリズムの中には、もともと「推定、近似計算、サンプリング計算」では計算しきれなかった問題を解決するために設計されたものがあります。たとえば、グローバルな平均距離を計算する場合、計算の複雑さは一般に NP ハードです。はは、大きなグラフ (数千万または数十億のポイントやエッジなど) では、既存のハードウェアとソフトウェアでは不可能であると考えることができます。正確な測定。したがって、 HyperANP アルゴリズムの核となるのは ANF アルゴリズム (近似近傍関数) であり、大きなグラフのサンプリングを通じてグラフの平均距離を迅速に推定できるため、非常に実用的です。また、K 近傍クエリなど、正確かつ網羅的である必要があるグラフ クエリもいくつかあり、金融、医療、サプライ チェーンなどの幅広いシナリオで、頂点の近傍の完全な数を決定する必要があります。 3度または6度以上のデータ量を正確に計算する必要があります。しかし、国内メーカーに目を向けると、正確に測定できない（演算能力不足、データ構造の問題、アーキテクチャの問題）ため、サンプリング計算を行っているメーカーもありますが、このようなサンプリングにはどのような意味があるのでしょうか？完全に本末転倒です。
技術的な課題を再評価してみますと、国内のグラフデータベースメーカーの数は海外メーカーの2～3倍、現在40社あると言われており、大手模型メーカーに匹敵します。それは新しいテクノロジーのトレンドであり、中国企業にとって敷居はなく、少なくとも中国企業はそう主張している。実際、これらのメーカーはプロジェクトを構築するためのブロックを構築するいくつかの方法を持っています。
- Neo4j のコミュニティ バージョンを 1 つのパッケージで入手できます。たとえば、あるグラフ データベースですが、名前は付けずに忘れてください。ここで繰り返しますが、Neo4j はオープンソースのグラフ データベースではなく、グラフ エンジンなどのコア コードは 1 行もオープンソースではありません。なぜコミュニティ バージョンと呼ばれるのでしょうか? コア ソース コードは一度も漏洩していません - Neo4j を無料で使用する人は全員、基礎となるコードを 1 行も読んだり変更したりしたことがありません。そこでお聞きしたいのですが、なぜあなたは Neo4j を破壊したと言える神経を持っているのでしょうか? あなたがやったことは、おそらくアイコンを変更し、フロントエンド CSS をカスタマイズしたことでしょう。
- JanusGraph と ArangoDB を使用して魔法の変更を加えます - 前者は、オープン ソース コンポーネントで構築された典型的なアーキテクチャです。保存はできますが、カウントされません。後者は、過去 2 年間で消滅しつつあるように見える、ねじれたマルチモード データベースです。2 点間の最短経路のクエリなど、一部のグラフ クエリ シナリオでは、明らかなロジックと実装のエラーがあります。加速効果があります。モード(間違った実装)、行列演算で最短パスが 1 つだけ見つかりました。これは、BFS (幅優先) アルゴリズムの誤った理解が原因です。質問させてください。2 点間に 1,000 以上の最短パスがある場合は、確認してください。一つ、よろしいでしょうか？HDのXu Dada氏とBGYのYang Dada氏、この2人の間に1,000以上の株式保有関連のパスがある場合、その1つを監督に見せれば、冷酷になるだろう。
- グラフ アルゴリズムは、グラフ データベースの中核機能の 1 つです。グラフ データベースを測定するには、アルゴリズムの豊富さ、効率 (速度)、リソース消費、スケーラブルかどうか、使いやすさ、ドキュメントが健全かどうか、ホットプラグ可能かどうかなど、グラフ アルゴリズムのサポートに依存します。等 しかし、中国企業の「マイクロイノベーション」、つまり専有主義のマイクロイノベーションを止めることはできない。公式 Web サイトにグラフ アルゴリズムのドキュメントが 1 つも掲載されていないにもかかわらず、さまざまなアルゴリズムをサポートしていると主張しているメーカーがあります。
さて、たくさん言いました。スティーブ・ジョブズが若い頃に尋ねられた文を言い換えると、それは非常に古典的です。彼は、あなたがデザインする製品の特徴は何によって決まるのかと尋ねられました。数秒考えた後、彼はこう言いました。「私の好みです。」これが私が皆さんと共有したいことです。どのような種類のグラフ データベースに出会うかはあなたの好みによって決まります。
不明瞭な質問があり、尋ねる必要がある場合は、このシリーズで最も味わい深い回答が得られます。
このシリーズで探している答えが見つからない場合でも、それは私たちの心の中にあります。
最高のグラフがあなたとともにありますように、ウルティパより愛を込めて。