paint-brush
DAG に Graphviz を使用すべきではない理由: 代わりに何を使用すべきか@s0l0ist
1,198 測定値
1,198 測定値

DAG に Graphviz を使用すべきではない理由: 代わりに何を使用すべきか

Nick Angelou5m2024/01/24
Read on Terminal Reader

長すぎる; 読むには

tl;dr: Vizdom.dev を使用して DOT 言語で書かれた DAG をレンダリングすると、最大 30 倍のスピードアップが実現します
featured image - DAG に Graphviz を使用すべきではない理由: 代わりに何を使用すべきか
Nick Angelou HackerNoon profile picture
0-item
1-item


ネタバレ: Vizdom.devを使用して DOT 言語で書かれた DAG をレンダリングする


ソフトウェア開発者として、私は時々 DAG を扱うことがありますが、そのほとんどは DAG の視覚化に関係しています。多くの場合、迅速なレンダリングが難しく、ツールを探していることに気づきました。


幸いなことに、信頼できる人がいますグラフビズDOT 言語で書かれたグラフをレンダリングできるツール — 完璧です!


を除外する…

  • ウェブではうまく機能しません*
  • インストールする必要があります
  • DOT/GV ファイルはオンラインでは管理されません

考慮事項

*OK、技術的にはGraphviz は WebAssembly にコンパイルでき、数人の才能ある人々が dreampuf のようないくつかのきちんとしたプロジェクトを構築することができました。編集者、ナイキのエドトルネット、そしてマグジャックの編集者— それぞれに独自の工夫が施されています。これらのレンダリングを SVG (または他のメディア) にエクスポートせずに埋め込むのにまだ苦労しています。


たとえば、グラフを次のように保存したいとします。 Notion.soリンクを貼り付けるだけで、グラフが自動的に表示されます。


使えるよマーメイドJSこれはグラフを非常にきれいにレンダリングし、驚くほどうまく機能します。これが、それが機能する多くの理由の 1 つです。 GitHubで 64k+ が開始。マークダウンを使用して、Notion/GitHub にグラフを埋め込むこともできます。


残念ながら、DOT を Mermaid が必要とするマークダウンのフレーバーに変換する必要があります。小さなテキスト表現の場合は、ChatGPT を使用して変換できますが、頻繁に文法上の間違いが発生し、グラフのレンダリングが拒否されるため、自動化のソースとしては信頼できません。


それから、 Terrastruct.comこれは、手作りの図を管理するには素晴らしいことですが、マーメイドの悩みと同様に、DOT を D2 に確実に変換することができません。図を手動で作成する場合、これは許容できる 1 回限りのコストだと思います。一般的に、これは素晴らしいツールです。称賛の声!

問題

  • プログラムで生成された DOT 出力をレンダリングしたいのですが、どのツールもその目標の達成に役立つとは思えません。


  • グラフをレンダリングするリンクを埋め込みたい。


  • 更新のためにレンダリングをオンラインで保存したり、他のグラフと視覚的に比較したりしたいと考えています。

ソリューション

はい、私はアプリそのために🎉


…そして、これは完全に Rust で構築されています 🦀 に感謝します。レプトス


tl;dr — DAG をオンラインで高速にレンダリングするためのシンプルな専用アプリ


NP 困難な課題として認識されているグラフ生成時のエッジ交差を最小限に抑えることが、視覚的に魅力的なグラフを作成するための鍵となります。 Terrastruct のチームは優れた成果物を発表しました。ブログ投稿このトピックを掘り下げます。 DagreJS レイアウト アルゴリズムと洞察力に富んだ論文「 有向グラフを描画するテクニック¹」から多大なインスピレーションを得て、私は Rust でバリアントを開発しました。


このバージョンは、この問題の複雑さを利用して、階層グラフのレンダリングに特に効果的です。


Graphviz では、大規模な DAG (500 以上のノード/エッジ) のレンダリングが多少遅くなる傾向があります。ダグレ + D3 ( d3-graphvizおよびその派生版) はかなり高速になり、優れたアニメーション/スタイルのカスタマイズが可能になります。しかし、私は、DOT 言語が提供する機能を見逃しているように感じました。つまり、スタイル属性は、Graphviz でレンダリングしている場合にのみ尊重されることがよくあります。


ビズダムDagre と非常によく似た結果が生成されますが、より DOT 仕様と Graphviz のスタイル動作に合わせたものになります。ただし、Graphviz と同等の機能はなく、サポートされていないステートメント/属性は単に無視されます。


これは、プログラムで生成された DOT が使用する属性の種類を考慮した、良い妥協案だと思います。


Vizdomの機能

  • 🚀 超高速レンダリング
  • 💾 グラフをリンクに保存
  • 0️⃣ 依存関係がなく、インストールは不要です

レンダリング速度

まあ、それはリンゴとオレンジの比較です。 Graphviz は引き続き優れたビジュアライゼーションを生成し、より多くの機能をサポートしますレイアウトエンジン, 主観的に比較しているので、ビズダムGraphviz の DOT エンジンに対して、対象を DAG のみに絞り込み、さらにDOT 言語の狭い機能のリストに絞り込みます。


はい、Graphviz の 30 年以上の実績と長年の経験とツールを比較するのはひどいことだとはわかっていますが、私の狭いユースケースでは、これは驚くほど高速です。私の M1 Macbook Pro でのレンダリングにかかった時間をいくつか示します。かなり大きなグラフ~400 ノードの場合:


  • ネイティブ Graphviz: ~30 秒
  • Chrome (WASM) Graphviz: クラッシュ*
  • Chrome (JavaScript) DagreJS: ~10 秒
  • クロム (WASM)ビズダム: ~1秒**


* emscripten フラグALLOW_MEMORY_GROWTH=1が設定されていないためクラッシュし、合計メモリが 16MB に制限されます。これは修正できますが、問題のグラフを処理できるオンライン プロジェクトが見つかりませんでした。


** グラフの例は、エディター ビューでExample 14を選択すると表示されます。グラフ内に保持される URI が大きすぎるため、ページを更新すると 414 が発生します。私は、より大きなグラフを保存するためのより良いソリューションに取り組んでいます。


例 14 の SVG レンダリング

グラフをリンクに保存する

DOT ファイルに変更を加えると、URL によっていくつかのクエリ パラメータが即座に更新され、グラフとレイアウトのオプションが保存されるため、リンクを保存するだけで常にデータのコピーを参照できるようになります。


落とし穴があります。グラフが大きいと、URI が AWS にとって大きすぎる傾向があります (ここで、ビズダムは現在ホストされています)および他のロードバランサー。


私は現在、より大きなグラフを処理するためのソリューションに取り組んでいますが、それまでの間、グラフを永続化して保存する方法をいくつか組み込みました。


  • グラフを最大化するビューを自動的にレンダリングする埋め込み可能なリンクをコピーします。


  • iframe スニペットをコピーして、レンダリングをサポートするアプリケーションに埋め込みます。


  • または、レンダリングされた SVG をダウンロードするだけです。


以下は、エディター ビューがどのように見えるかの例です。 deflate の pprof トレース:

エディター ビューに移動し、 Example 42をロードします。


差分ビュー

時々、自分で生成した 2 つのグラフを比較しようとしていることがあるので、そのついでに、差分ビューア2 つの異なるグラフ間の変化を視覚的に確認します。


色の凡例:

  • 赤: 削除済み
  • オレンジ: 変更済み
  • 緑色: 追加されました


ここにいくつかのスナップがあります:

Click me: ノード ID を「e」から「f」に変更します


クリックしてください: 「cluster=true」を追加


今後の方向性

ビズダムはまだ進行中の作業であり、進化し続けているため、このツールを完成させるまでの道のりは、グラフ視覚化の分野そのものと同じくらいダイナミックであることを私は認識しています。何を誇りに思いながらも、ビズダムこれまでのところ、その可能性についてはさらに興奮しています。そこで登場するのは、読者であり潜在的なユーザーであるあなたです。


ご意見がございましたら、お気軽にメッセージください。ギッターまたは不和


読んでいただきありがとうございます — この記事が気に入ったら、フォローしてください。


[1]: ER Gansner、E. Koutsofios、SC North、および K. -P. Vo、「有向グラフを描画するためのテクニック」、IEEE Transactions on Software Engineering、vol. 19、いいえ。 3、214–230ページ、1993年3月、土井:10.1109/32.221135。


ここでも公開されています