元従業員が内部事情を暴露: 10年経っても、なぜGoogleはナレッジグラフを解明できないのか?

[[258183]]

この記事はWeChatの公開アカウント「AI Front」（ID: ai-front）によって作成されたものであり、許可なく複製することはできません。

Dgraph Labs での業務について説明すると、以前 Facebook で働いていたのか、あるいは私たちの業務は Facebook からインスピレーションを得たものなのかとよく聞かれます。 Facebook がグラフ インフラストラクチャの構築方法に関する論文をいくつか公開しているため、ソーシャル グラフ サービスに関して多くの作業を行ってきたことは多くの人が知っています。

Google について話すとき、人々は通常、そのナレッジ グラフ サービスに限定しますが、その内部インフラストラクチャがどのようなものであるかについては誰も言及しません。実際、Google にはナレッジ グラフを提供するために特別に設計されたシステムがあります。実際、私たちは（Google にいた頃）グラフ サービング システムにも多くの取り組みを行っていました。 2010 年に、私はチャンスをつかみ、何ができるか試すために 2 回の試みをしました。

Google は、ナレッジ グラフ データ内の複雑な関係を処理できるだけでなく、構造化データにアクセスできるすべての OneBox も処理できるグラフ サービス システムを構築する必要があります。サービス システムは、大量の Web 検索を処理できるほど高いスループットと低いレイテンシでファクト データを走査する必要があります。しかし、これら 3 つの要件をすべて同時に満たすシステムやデータベースはすぐには入手できません。

Google がグラフ サービング システムを構築する理由についての質問に答えました。この記事の残りの部分では、グラフ サービング システムを構築するまでの過程を説明します。

なぜ私がこれを知っているかと言うと、自己紹介をさせてください。私は 2006 年から 2013 年まで Google で働いていました。最初はインターンとして、その後はウェブ検索インフラストラクチャのソフトウェア エンジニアとして働きました。 2010 年に Google が Metaweb を買収し、私のチームはちょうど Caffeine を立ち上げたところでした。何か違うことをしたかったので、Metaweb の人たち (サンフランシスコ) と一緒に働き始めました。私の目標は、ナレッジグラフを使用して Web 検索を改善する方法を見つけることでした。

Metaweb の物語は以前にも語られてきました。Google は 2010 年に Metaweb を買収しました。 Metaweb は、Wikipedia のクロールや解析など、さまざまな手法を使用して高品質のナレッジ グラフを構築しました。これらすべては、同社が社内で構築したグラフ データベース「Graphd」（グラフ デーモン、GitHub で入手可能: https://github.com/google/graphd）によって駆動されています。

Graphd には非常に典型的な特性がいくつかあります。デーモンと同様に、単一のサーバー上で実行され、すべてのデータはメモリ内に保持されます。 Freebase の Web サイトは Graphd を圧倒しており、買収後に Google が直面した課題の 1 つは Freebase の運営をどのように継続するかでした。

Google は、汎用ハードウェアと分散ソフトウェアの帝国を築き上げました。単一のサーバー データベースでは、検索に関連するクロール、インデックス作成、およびサービス提供のワークロードをサポートすることはできません。 Google はまず SSTable をリリースし、次に Bigtable をリリースしました。これは、数百、あるいは数千のマシンに水平方向に拡張でき、ペタバイト単位のデータ処理能力を提供できます。彼らは、マシンの構成に Borg (K8s の前身) を使用し、通信に Stubby (gRPC の前身) を使用し、Borg Name Service (K8s に統合されている BNS) を通じて IP アドレスを解決し、Google File System (GFS) にデータを保存しました。プロセスが停止したり、マシンがクラッシュしたりする可能性がありますが、システムは常に機能します。

Graphd は当時そのような環境にありました。単一のサーバー上で実行されている Web サイトを単一のデータベースを使用して提供するというアイデアは、Google (私自身も含む) のスタイルとは一致しません。特に、Graphd を実行するには 64GB 以上のメモリが必要です。これらのメモリ要件がおかしいと思うなら、それが 2010 年だったことを思い出してください。当時、ほとんどの Google サーバーの最大メモリは 32​​ GB だったため、Google は Graphd をサポートするために十分なメモリを搭載した特別なマシンを購入する必要がありました。

Graphd の置き換え Graphd を置き換えたり書き直したりして分散コンピューティングをサポートするというアイデアが出始めていますが、これはグラフ データベースでは非常に難しいことです。これらは、データのチャンクを別のサーバーに移動し、クエリ時にキーを指定できるキー値データベースとは異なります。グラフ データベースの利点は、効率的な結合とトラバーサルですが、これは特定の方法で実装する必要があります。

1 つのアイデアは、MindMeld (IIRC) と呼ばれるプロジェクトを使用することです。このプロジェクトは、ネットワーク ハードウェアを介して別のサーバーのメモリに高速にアクセスすることを約束します。これは通常の RPC よりも高速で、メモリ内データベースに必要な直接メモリ アクセスを擬似的に複製できるほど高速です。しかし、そのアイデアはあまり実現しませんでした。

もう 1 つのアイデア (実際にはプロジェクト) は、Graphd を置き換えるだけでなく、将来的にすべての知識を提供できる、真に分散されたグラフ サービング システムを構築することです。それは分散グラフデーモンである Dgraph です。

Dgraph Lab とオープンソース プロジェクト Dgraph は、こ​​の Google プロジェクトにちなんで名付けられました。

この記事で Dgraph について言及する場合、それは Google の社内プロジェクトを指しており、後に構築したオープンソース プロジェクトを指しているわけではありません。

Cerebro のストーリー: ナレッジ エンジン Dgraph の目標は Graphd を置き換えることだとわかっていましたが、私の目標は Web 検索を改善する何かを構築することでした。私はMetawebでCubed (https://blog.dgraph.io/refs/freebase-cubed.pdf) を開発した研究エンジニアのDHを見つけました。

Google のニューヨーク オフィスのエンジニアが Squared (https://en.wikipedia.org/wiki/Google_Squared) を開発しました。 DH はさらに一歩進んで、Cubed を開発しました。 Squared は役に立たないが、Cubed は印象的だ。 Google にはすでに活用できる既成のものがあったので、Google でこのようなものを開発する方法について考え始めました。

1 つ目は、どの単語が一緒に使われるべきかを高い精度で判断する方法を提供する検索プロジェクトです。たとえば、[tom hanks movies] のようなフレーズの場合、[tom] と [hanks] が一緒に使われることがわかります。同様に、[san francisco weather] というフレーズでは、[san] と [francisco] を組み合わせる必要があります。これらは人間にとっては明らかなことですが、機械にとってはそうではありません。

2つ目は文法を理解することです。 [フランス人作家の本] を検索すると、マシンはそれを [フランス人作家] によって書かれた [本] と解釈します。しかし、それは[著者]によって書かれた[フランスの本]と解釈することもできます。文法をより深く理解するためにスタンフォードの品詞 (POS) タグ付けツールを使用し、構文ツリーを構築しました。

3 番目はエンティティを理解することです。 [french] にはさまざまな意味があります。国 (地域)、国籍 (フランス語)、料理 (食べ物)、言語などを指します。別のプロジェクトを使用して、単語またはフレーズに対応するエンティティのリストを取得しました。

4 番目は、エンティティ間の関係を理解することです。単語をフレーズに関連付ける方法、フレーズが実行される順序、つまり文法、およびフレーズが対応するエンティティがわかったので、機械による説明を作成するために、これらのエンティティ間の関係を見つける方法も必要でした。たとえば、クエリ [フランス人作家の本] の場合、POS は [フランス人作家] によって書かれた [本] を指していることを示します。いくつかの [フランス語] エンティティといくつかの [著者] エンティティがあり、アルゴリズムはそれらをどのように接続するかを判断する必要があります。これらは出生地によって結び付けられることがあります。つまり、フランス生まれの作家（ただし、英語で執筆する場合もあります）、フランス国籍の作家、フランス語で話したり執筆したりする作家（ただし、フランスとは何の関係もない場合もあります）、または単にフランス料理が好きな作家などです。

グラフベースの検索インデックス 特定のエンティティが接続されているかどうか、またどのように接続されているかを判断するには、グラフ システムが必要です。ナレッジ グラフ データはトリプル形式を使用します。つまり、各ファクトは、主語 (エンティティ)、述語 (関係)、およびオブジェクト (別のエンティティ) の 3 つの部分で表されます。クエリは [SP]→[O]、[PO]→[S]、場合によっては [SO]→[P] である必要があります。

私は Google の検索インデックス システムを使用し、各トリプルに docid を割り当て、S、P、O の 3 つのインデックスを構築しました。さらに、インデックスでは添付ファイルが許可されているため、各エンティティのタイプ情報を含めました。

このグラフ サービング システムを構築したとき、結合深度の問題 (以下で説明) があり、複雑なグラフ クエリには適していないことがわかっていました。実際、Metaweb チームの誰かがシステム アクセスを開放するように依頼したとき、私は拒否しました。

ここで、関係性を判断するために、いくつかのクエリを実行し、どのような結果が生成されるかを確認します。 [french] と [author] で何か結果が生成されますか? それらの結果を選択し、[books] とどのように関連しているかを確認します。これにより、複数の機械解釈が生成されます。たとえば、[トム ハンクスの映画] とクエリすると、[トム ハンクスが監督した映画]、[トム ハンクスが主演した映画]、[トム ハンクスがプロデュースした映画] などの解釈が生成され、[トム ハンクスという名前の映画] などの解釈は自動的に拒否されます。

それぞれの解釈について、結果のリスト (グラフ内の有効なエンティティ) が生成され、エンティティのタイプ (添付ファイル内に存在するもの) も返されます。これは、結果の種類がわかれば、それをフィルタリング、並べ替え、またはさらに拡張できるため、非常に強力です。映画のジャンルの結果では、公開年、映画の長さ（短編、長編）、言語、受賞歴などで映画を並べ替えることができます。

このプロジェクトはスマートに見えるので、私たち (このプロジェクトのナレッジ グラフの専門家である DH) はこれを「X-Men」に登場するデバイスと同じ名前である Cerebro と名付けました。

Cerebro は、人々が当初検索していなかった非常に興味深い事実をしばしば明らかにします。たとえば、[us presidents] を検索すると、Cerebro は大統領が人間であり、人間には身長があることを認識しているので、大統領を身長順に並べ替えることができ、エイブラハム リンカーンが米国で最も背の高い大統領だったことがわかります。国籍別に検索結果をフィルタリングすることもできます。この場合、米国には英国人の大統領であるジョージ・ワシントンがいるため、米国と英国が表示されます。 （免責事項：この結果は、当時のKGステータスに基づいているため、これらの結果が正しいことを保証するものではありません。）

青いリンクとナレッジグラフ Cerebro により、実際にユーザーのクエリを真に理解することが可能になります。グラフにデータがあれば、クエリに対する機械的な説明や結果リストを生成したり、結果の理解に基づいてさらに探索を進めたりすることが可能になります。上で述べたように、映画、人間、本のどれを扱っているかがわかれば、特定のフィルタリング機能と並べ替え機能を有効にすることができます。また、グラフの端をトラバースして、[米国大統領] から [大統領が通った学校] や [大統領が父親となった子供] までの接続データを表示することもできます。 DH は、Parallax (https://vimeo.com/1513562) と呼ばれる別のプロジェクトで、ある結果リストから別の結果リストにジャンプする機能を実演しました。

Cerebro は印象的で、Metaweb のリーダーシップも協力的でした。グラフ サービス部分でも優れたパフォーマンスと機能性が提供されます。私はそれをナレッジ エンジン (検索エンジンのアップグレード) と呼びましたが、Google の経営陣 (私のマネージャーを含む) は興味を示しませんでした。その後、この件について誰に相談すればよいか教えてくれた人がいて、検索業界の上級者にこの件を紹介する機会がありました。

しかし、その反応は私が期待していたものではなかった。担当者は、Google で [フランス人作家の本] を検索すると青いリンクが 10 個表示されることを示し、Google でも同じことができると主張しました。また、彼らは自分のウェブサイトからトラフィックが奪われることを望んでいません。なぜなら、そうなれば、それらのウェブサイトの所有者は間違いなく怒るからです。

彼の言うことが正しいと思うなら、次のことを考えてみてください。Google 検索は実際にはユーザーが何を検索しているのか理解していません。適切な相対位置にある適切なキーワードを探し、それに応じてページをランク付けします。非常に複雑なシステムであるにもかかわらず、検索や検索結果が何を意味するのかをまだ十分に理解していません。最後に、ユーザーは自分で結果を確認し、そこから必要な情報を解析して抽出し、さらに検索を実行して、完全な結果をまとめる必要があります。

たとえば、[フランス人作家の本]を検索する場合、ユーザーは最初に結果リストを組み合わせる必要があり、結果が同じページに表示されない可能性があります。これらの書籍は、出版年で並べ替えたり、出版社などでフィルタリングしたりできますが、これには多くのリンクをたどり、さらに検索し、手動で集約する必要がありました。 Cerebro は、この作業負荷を軽減し、ユーザー操作をシンプルかつ効率的にする可能性があります。

しかし、これは当時の典型的な知識獲得方法でした。経営陣は、ナレッジグラフが実際に役立つかどうか、またそれを検索でどのように使用すればよいか確信が持てませんでした。ユーザーにハイパーリンクを大量に提供することですでに成功を収めていた企業にとって、知識を獲得するこの新しい方法は理解しにくいものでした。

経営陣と1年間働いた後、私は続けることに興味がありませんでした。 2011 年 6 月、Google の上海オフィスのマネージャーが私に連絡し、私は彼にプロジェクトを引き継ぎました。彼はそのプロジェクトのために15人のエンジニアのチームを編成した。私は上海に1週間滞在し、このチームのエンジニアに関係するすべてのものを引き継ぎました。 DH もこのプロジェクトに参加し、長い間チームを指導してきました。

結合深度の問題 Cerebro 用に開発したグラフ サービング システムには、結合深度の問題がありました。クエリの後続部分で前の部分の結果が必要な場合は、結合が実行されます。典型的な結合には通常、SELECT 操作、共通データ セットのフィルター処理、特定の結果の取得、そしてその結果を使用したデータ セットの別の部分のフィルター処理が含まれます。これを例で説明します。

たとえば、サンフランシスコで寿司を食べる人について知りたいと思っていて、人々が、誰がどの都市に住んでいるか、どんな食べ物が好きなのかといった情報を含むデータを共有しているとします。

上記のクエリは単一レベルの結合です。データベース外部のアプリケーションがこの結合を実行する場合、1 つのクエリを実行し、次に複数のクエリ (結果ごとに 1 つ) を実行して各人が何を食べるかを調べ、寿司を食べる人を選び出します。

2 番目のステップではファンアウトの問題があります。最初のステップで 100 万件の結果 (サンフランシスコの人口に基づく) があった場合、2 番目のステップでは各結果をクエリに入力し、食習慣を調べてフィルタリングする必要があります。

分散システムエンジニアは通常、ブロードキャストを使用してこの問題を解決します。シャーディング機能に基づいて結果をバッチに分割し、クラスター内の各サーバーにクエリを実行します。この方法で結合を実現できますが、クエリの待ち時間が大幅に増加します。

分散システムでブロードキャストを使用するのは良い考えではありません。 Google の第一人者 Jeff Dean 氏は、この問題を「大規模オンライン サービスで迅速な応答時間を実現する」という講演でわかりやすく説明しています (ビデオ: https://www.youtube.com/watch?v=1-3Ahy7Fxsc、スライド: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44875.pdf)。クエリの合計レイテンシは、常に最も遅いコンポーネントのレイテンシよりも大きくなります。単一のマシンでのわずかなレイテンシでも、マシンの数が増えるにつれてクエリの合計レイテンシが大幅に増加する可能性があります。

50 パーセンタイルのレイテンシが 1 ミリ秒、99 パーセンタイルのレイテンシが 1 秒のサーバーを想像してください。クエリに 1 つのサーバーのみが関係する場合、リクエストの 1% のみが 1 秒かかります。しかし、クエリに 100 台のサーバーが関係する場合、リクエストの 63% に 1 秒かかります。

したがって、ブロードキャストはクエリのレイテンシに悪影響を及ぼす可能性があります。 2 つ、3 つ、またはそれ以上の結合が必要な場合、リアルタイム (OLTP) 実行は遅くなります。

Janus Graph、Twitter の FlockDB、Facebook の TAO など、ほとんどの非ネイティブ グラフ データベースは、この高ファンアウト ブロードキャストの問題に悩まされています。

分散接続は大きな問題です。既存のネイティブ グラフ データベースでは、共通のデータセットを 1 台のマシン (スタンドアロン データベース) に保持し、接続時に Neo4j などの他のサーバーにアクセスしないことで、この問題を回避します。

Dgraph: 任意の深い接続 Cerebro を終えた後、グラフ サービング システムの構築を経験しました。その後、私は Dgraph プロジェクトに参加し、プロジェクトの 3 人の技術リーダーの 1 人になりました。 Dgraph の設計コンセプトは非常に斬新で、接続深度の問題を解決します。

Dgraph は、結合を単一のマシンで実行できる非常にユニークな方法でグラフ データを分割します。 SPO の問題に戻ると、Dgraph の各インスタンスは、そのインスタンス内の各述語に対応するすべての主語と目的語を保存します。 Dgraph インスタンスは複数の述語と完全な述語を保持します。

これにより、ファンアウト ブロードキャストの問題を回避しながら、任意の深さの結合を実行できるようになります。 [サンフランシスコで寿司を食べる人々] を例に挙げてみましょう。クラスターのサイズに関係なく、このクエリには最大 2 回のネットワーク呼び出しが必要です。最初の呼び出しでは、サンフランシスコに住んでいるすべての人を検索し、2 番目の呼び出しでは、このリストと寿司を食べるすべての人を検索します。その後、さらに制約や拡張機能を追加できますが、各ステップには最大 1 つのネットワーク呼び出しが含まれます。

これにより、単一サーバー上の述語が非常に大きくなりますが、述語サーバーをさらに分割することでこの問題は解決できます。ただし、すべてのデータが 1 つの述語にのみ対応する極端なケースでは、クラスター全体に基づいて述語を分割することは最悪の動作になります。しかし、他の場合には、述語に基づいてデータを分割する設計により、実際のシステムでクエリのレイテンシを短縮できます。

シャーディングは Dgraph の唯一の革新ではありません。すべてのオブジェクトには整数 ID が割り当てられ、並べ替えられて逆リストに格納されます。この逆リストは、他の逆リストと簡単に交差できます。これにより、結合時のフィルタリング、共通参照の検索などの操作が高速化されます。ここでは、Google の Web サービス システムのアイデアもいくつか使用されています。

Google の Dgraph は、Plasma を介して OneBox と組み合わせると、データベースではなく、Google の Web 検索サービス システムに相当するサービス システムになります。さらに、リアルタイムの更新に応答できる必要があります。リアルタイム更新サービスシステムとして、リアルタイムグラフインデックスシステムが必要です。以前、Caffeine (https://googleblog.blogspot.com/2010/06/our-new-search-index-caffeine.html) に携わっていたため、リアルタイムの増分インデックス作成システムについても豊富な経験があります。

その後、私はこのグラフ インデックス システムに基づいて、天気、フライト、イベントなどを含む Google のすべての OneBox を統合する新しいプロジェクトを開始しました。 OneBox が何であるかは知らないかもしれませんが、見たことがあるはずです。 OneBox は、特定の種類の検索を実行したときに表示される個別の表示ボックスで、Google はここに詳細情報を表示できます。

このプロジェクトを開始する前は、各 OneBox は個別のバックエンドによって実行され、異なるチームによって保守されていました。構造化されたデータセットは豊富ですが、このデータは表示ボックス間で共有されません。これらのバックエンドの維持には膨大な作業が必要だっただけでなく、知識の共有が不足していたため、Google が応答できるクエリの種類が制限されていました。

たとえば、[SF のイベント] はイベントを表示し、[SF の天気] は天気を表示できますが、[SF のイベント] は雨が降っていること、イベントが屋内か屋外かを認識している場合は、天気に基づいてイベントをフィルタリング (または並べ替え) できます (大雨の場合は、映画を観たり交響曲を聴いたりするのが最適な選択肢かもしれません)。

Metaweb チームの協力を得て、すべてのデータを SPO 形式に変換し、1 つのシステムにインデックスを付けました。私はこのシステムを、Dgraph のリアルタイム グラフ インデックス システムである Plasma と名付けました。

経営陣の変更 Cerebro と同様に、Plasma も資金が不足しているものの、成長を続けているプロジェクトです。 ***、経営陣は、OneBoxe がこのプロジェクトを使用することに気付いたとき、この側面を担当する「適切な人物」を見つける必要がありました。この政治的駆け引きの中で、私たちは3人の経営陣の交代を経験しましたが、そのうちの誰もこの分野での経験を持っていませんでした。

この経営陣の交代中、Spanner (グローバルな一貫性を確保するために GPS クロックを必要とするグローバルに分散された SQL データベース) をサポートしていた経営陣は、Dgraph が複雑すぎると考えていました。

***、Dgraph プロジェクトはキャンセルされましたが、Plasma は存続しました。新しいチームがプロジェクトを引き継ぎ、このチームの責任者は CEO に直接報告することになります。この新しいチーム（グラフ関連の問題についてはほとんど理解していなかった）は、Google の既存の検索インデックス上にサービス システムを構築することを決定しました（Cerebro で私が行ったのと同じように）。私はCerebro用に開発したシステムの使用を提案しましたが、拒否されました。私は、システムがそれを Web ドキュメントとして扱えるように、各ナレッジ トピックを複数のレベルでクロールおよび拡張するように Plasma を変更しました。彼らはそれを TS と呼んでいます (単なる頭字語です)。

つまり、新しいサービス システムではディープ接続を実行できなくなります。多くの企業のエンジニアが、最初は「グラフは実は非常に単純な問題であり、別のシステムの上にレイヤーを構築することで解決できる」と誤解しているのを目にします。

私は、約 2 年間 Dgraph/Plasma プロジェクトに取り組んだ後、数か月後の 2013 年 5 月に Google を退職しました。

背景 数年後、「Web 検索インフラストラクチャ」は「Web 検索およびナレッジ グラフ インフラストラクチャ」に名前が変更され、私が Cerebro のデモを行った人物がその取り組みを主導することになりました。彼らは、青いリンクの代わりにナレッジグラフを使用して、ユーザーのクエリに対して可能な限り直接的な回答を提供するつもりです。

上海の Cerebro チームがプロジェクトを本番環境に展開しようとしたとき、プロジェクトは Google のニューヨーク オフィスに奪われました。 ***、それは「ナレッジストリップ」に変わりました。 [トム・ハンクス 映画]を検索すると、一番上に表示されます。リリース以来、多少は改善されていますが、Cerebro が提供できるフィルタリングと並べ替えのレベルにはまだ達していません。

Dgraph に携わっていた 3 人のテクニカル リーダー全員 (私を含む) は、最終的に Google を退職しました。私の知る限り、他の2人の幹部は現在、MicrosoftとLinkedInで働いています。

私はシニア ソフトウェア エンジニアとして Google を辞めたときから数えれば、2 回、いや 3 回昇進しました。

TS の現在のバージョンは、実際には Cerebro の設計に非常に近く、主語、述語、目的語ごとにインデックスが付いています。したがって、接続深度の問題は依然として残ります。

それ以来、Plasma は書き直され、名前も変更されましたが、TS をサポートするリアルタイム グラフ インデックス システムのままです。彼らは、ナレッジグラフを含む Google の構造化データをすべて引き続きホストします。

Google がディープ コネクションを実現できないことは、さまざまな場所で確認できます。まず、OneBox 間のデータ連携はまだ確認されていません。天気と KG データが利用可能であるにもかかわらず、[アジアで最も雨が多い都市] では都市のリストが生成されません。 [サンフランシスコの出来事] は天気でフィルタリングできず、[米国大統領] の結果はさらに並べ替え、フィルタリング、または拡張できません。これが Freebase の使用をやめた理由の 1 つではないかと考えています。

Dgraph: Phoenix Nirvana Google を退職してから 2 年後、私は Dgraph (https://github.com/dgraph-io/dgraph) からやり直すことにしました。 Google 以外でも、同様の動きが見られます。この分野には、リレーショナル データベースや NoSQL データベースの上に急いでレイヤーを追加したり、マルチモデル データベースの多くの機能の 1 つとしてレイヤーを追加したりした、未熟なカスタム ソリューションが数多く存在します。ネイティブ ソリューションが存在する場合、スケーラビリティの問題が発生します。

私の意見では、高性能かつスケーラブルな設計を完全に実現できた人は誰もいません。水平方向にスケーラブルで、レイテンシが低く、任意の深さの接続が可能なグラフ データベースを構築するのは非常に困難です。 Dgraph の構築が正しい方向に進んでいることを願っています。

過去 3 年間、私の経験に加えて、Dgraph チームは多くの独自の研究を設計に取り入れ、この最新のグラフ データベースを開発してきました。他の企業は、別の未熟なソリューションの代わりに、この強力でスケーラブルな高性能ソリューションを選択できます。

オリジナルの英語:

https://blog.dgraph.io/post/why-google-needed-graph-serving-system/