Dgraphは、私が今まで使った中で最もエキサイティングな製品です❤️‍🔥. なぜですか

これは誇張のように聞こえるかもしれませんが、私は本当にDgraphは私が私のキャリアで見た中で最もエキサイティングなdevの製品であると信じています.私は絶え間なく小さく、しかし、私が発見し続ける狂った強力な機能によって吹き飛ばされます、しかし、私が話したいdgraphの最も刺激的な(メタ)機能はそれが完全にソフトウェア開発サイクル全体に革命をもたらしたということです.特に速く出荷しようとしているスタートアップのために.このポストでは2つのことに集中したい問い合わせ最適化とスキーマ設計

Beebyeクエリ最適化地獄
私はWeb開発者だった限り、アプリケーション開発ライフサイクルの不可避のボトルネックの一つは、あなたのMVPを構築するパフォーマンスの最適化であり、あなたはそれを出荷し、あなたのユーザーはそれをテストし、そして...エラーか悪いか、クラッシュ.私の経験では、データベース質問は通常これらの問題の中心にあります.
私は現在、interactive transcriptsに対応する製品に取り組んでいます.元々はPostgreresデータベースに問い合わせたリゾルバを使用したElixirを使ったGraphSQL APIを構築しました.製品の要件のために、転写物、段落、文章や単語は自分のテーブルが必要です.
文章に属する単語で、それは転写物に属する段落に属する.これは短い転写物のために細心の注意を払ったが、おそらく推測したように、非常に予測可能なN + 1クエリの問題につながった.私たちが1時間のトランスクリプトをアップロードした後に、そのトランスクリプトのページのどんな要求も、メモリオーバーロードのためにサーバを壊しました.
最良の技術的解決策は、クエリを最適化するのに時間を費やすことでしたが、最速の解決策(優先度)は、段落のバッチに対するクエリーをページ化するだけでした.しかし、この解決策はまだボイラー板のcraploadを書かなければならないことに関係していました.
私は私のベルトの下で失敗したスタートアップを持っています.私はその間違いを繰り返したくなかったので、私は解決策を探し始めて、Dgraphに起こりました.
当初はグラフデータベースには技術的なオーバーヘッドが入っています(複雑なクエリ言語を学ぶ必要があり、抽象的なグラフデータベースの概念を私の頭を得る必要があるということです).しかし、私の驚きと喜びには、実際にグラフのデータベースによってバックアップされるグラフィカルなAPIのジェネレータとしてdgraphを使用することが可能です.これによって、DGraphをGraphSQL APIとして使用することができます.これは、どのように格納し、データを永続化するかについて、自分自身を心配する必要がないことです.
理由は、GraphSQLがdgraphのネイティブの問い合わせ言語であるためです.

あなたのマシン

のDGraphを実行するスタンドアロンのDockerイメージをダウンロードして実行します

あなたのGraphSQLタイプが

にリストされている非常によく知られているschema.graphqlファイルを作成します

単純なCLIコマンド

を使用して、DGraphインスタンスにスキーマを追加します
そして、VilはあなたがあなたのJSアプリから質問を始めることができるAPIを持っています.ああ、そしてあなたはもはやN + 1クエリを心配する必要はありませんし、データのテラバイトやデータポイントの数十億を扱うことができます.何..実際🤯 テラバイト?何億?¹
Dgraphは、基本的にあなたのGraphSQLタイプファイルを越えてゼロのConfigの横でGoogleレベルパフォーマンスをあなたに与えます.たぶんあなたは懐疑的であり、どのようにあなたが聞いたことがない会社は、Googleレベルのパフォーマンスを達成することができるだろうか?さて、ここでは、DgraphがGoogleの上級捜索技術者のうちの1つによって"scale to serve Google’s Knowledge Graph via Search"に文字通り構築された理由です.
これは次のレベルのゲームの技術を変更され、ちょうど私は今リレーショナルデータベースに戻っている方法はありません.未来が到来した!

スキーマデザインの苦悩の終わり
必要な免責事項:これは本当にRailsに対する傾きではありません.なぜなら、この問題はリレーショナルデータベースによってバックアップされているすべてのMVC Webフレームワークに存在するからです.
ウェブアプリケーションを出荷するもう一つの避けられない技術的な挑戦は、スキーマ設計です.長い間Webアプリケーションを構築するための最も一般的なアプローチは、MVCフレームワークとORMを使用して、SQLクエリを生成することです.私のプロのキャリアのほとんどのために私はRuby on Railsのdevとして働いてきたし、多くの場合、ほとんどのdevの時間が焼けていたコードベースの領域は、データベースとアプリケーションの間のActiveRecord ORM layerにあります.あなたがブログのような単純なスキーマを持っていて、例えば、そのコメントによるブログ記事を照会する必要があるとき、それは素晴らしくうまく機能します、しかし、あなたがあなたの図式の中で適度に洗練された階層を持っているとすぐに、それはActiveRecord is a benefit or a costかどうかより明らかになりません.私は多くのRailsプロジェクトを見ました、開発者がマルチテーブルのORM質問を最適化しようとしていて、それらを使用して、ペーストする正しいSQL声明を見つけ出すことを選びました.しかし、どちらの方法でも、この時点では、多くのdevの時間は本当にあなたのビジネスロジックとはあまり関係ありません.起動時に、無駄な時間は短縮滑走路を意味します.

ほとんどの経験豊富なWeb開発者は、あなたのスキーマを設計しているときに注意深く考えて支払うことは難しい方法を学んだ.スタートアップとして、開発サイクルのこの部分はウエストの高い糖蜜を通してのように感じます.
DGraphで、開発サイクルのこの非常に本当の『コスト』は一見魔法のようなものでした🪄!
例を与えるために、しばらくの間、我々は我々のアプリでは、フラッシュカード機能を提供するという考えを実験していた.機能は、ユーザーがデッキにフラッシュカードを保存することができますし、他のデッキに巣のデッキ.
私はユーザーができるようにする必要がありますネストしたフラッシュカードのデッキとレビューカードのツリー内の任意のレベルで任意のレベルで任意のデッキを選択し、カードを表示されてから選択されたデッキだけではなく、定期的に、現在選択したデッキの下にネストしたすべてのデッキからカードを収集する.

私たちはすぐに、デッキがあまりに深くネストされている場合、これは危険なほど高価なクエリで、サーバーをクラッシュさせるでしょう.それで、これは私たちが思い付いた解決策の一部です.

  def deck_tree_depth_stats(parent_id, deck_id) do
    Deck
    |> recursive_ctes(true)
    |> with_cte(
      "roots", as: fragment("(
        SELECT id, parent_id, 1 AS depth
        FROM decks
        WHERE id = ?
        UNION ALL
        SELECT decks.id, decks.parent_id, roots.depth + 1 as depth
        FROM decks
        JOIN roots
        ON roots.parent_id = decks.id
      )", type(^parent_id, :id))
    )
    |> with_cte(
      "branches", as: fragment("(
        SELECT id, 1 AS depth
        FROM decks
        WHERE parent_id = ?
        UNION ALL
        SELECT decks.id, branches.depth + 1 as depth
        FROM decks
        JOIN branches
        ON decks.parent_id = branches.id
      )", type(^deck_id, :id))
    )
    |> join(:inner, [d], r in "roots")
    |> join(:inner, [d, r], b in "branches")
    |> select(
      [d, r, b], %{
        parent_depth: max(r.depth),
        node_depth: max(r.depth) + 1,
        tree_depth: max(r.depth) + 1 + max(b.depth)
      }
    )
    |> Repo.one()
  end

回顧録では、これは我々の時間のひどい使用でした.しかし、あなたが書く必要がないことを望む複雑なコードを書くのは簡単です.理由は、それは実際には、スキーマのデザインの決定とコーナーに自分自身を描くのを避けるのは難しいです.スキーマを間違った方法で設計すると、スキーマの構造から生じるパフォーマンスの問題に対して複雑な解決策を考え出す必要があります.
あなたが速く出荷しようとしている小さなスタートアップであるとき、あなたは適切に働いているように質問を得る方法を理解しようとしているドライSQLドキュメントを通して15時間の読書を費やす贅沢を持っていません.あなたの顧客のために価値を直接作成する機能についてイライラしていないときはいつでも、スタートアップの成功への直接の脅威です.
私たちは以来、いくつかの理由のためにこの機能をスクラップしましたが、振り返って、それは私がDGraph🔥NOS🔥 ベンチャーのために.
DGraphでは、この機能を実装するのはこれだけです.

query {
  queryDeck(slug: "korean-first-500-words"){
    flashcards {
      content
    }
    decks {
      flashcards {
        content
      }
      decks {
        flashcards {
          content
        }
      }
    }
  }
}

それです.🤯
うまくいけば、スタートアップ類推のためのNOSは現在明らかです.DGraphでは、スタートアップとしての我々の反復速度は、屋根を通してあります.だけでなく、全体のプロセスは、再び私たちは出荷機能に焦点を当てることができるし、すぐに私たちのスキーマによってコーナーに描画されるつもりであるかどうかのストレスの一定の状態になることなく、すぐに繰り返すことができるようになっている.

我々はもはや我々のデータベースによって人質を保持されていない、我々は現在、我々のクエリを爆破する可能性が低いスキーマではなく、理解しやすいスキーマを設計するために自由になっている.
NOSのアナロジーをより多くのものにするのは、DGraphは我々が潜在的な競争相手に対してそのような強力なエッジを感じているということです.それは秘密兵器です.
Click here to learn more about Dgraph
(株)あなたのラップトップがマルチテラバイトDGraphグラフと闘うかもしれない間、Dgraphはこの分散された性質を通してこれを成し遂げます、このパフォーマンスはDgraph Cloudを経た平らな料金で利用できます