こういうの結構多いよね。Helix DBと比べてどうなの？それに、GraphQLでデータベースをクエリする理由って何？そもそもその目的で作られたわけじゃないのに。

AI/LLM駆動のサイクルで、同じようなグラフデータベースが25個も出てきてるよ。Rustで書くとHNで目立つからね。LadybugDBではそれをやらない理由があるんだ。もっと段階的なアプローチを探りたいし、クエリ言語も強く型付けされたサイファーだけに集中したい。 https://github.com/LadybugDB/ladybug/discussions/141

このDB使ったことある人いる？どこから来たのか背景も知りたいな。コミット履歴を見ると、これはAIがコードしたプロジェクトだって明らかだよ。数ヶ月前に始まって、99%のコミットが1人の貢献者からで、その人は週に10万行のコードをコミットすることもあるみたい。（追記：最初の週には20万行のコード）LLMに反対ってわけじゃないけど、1人が週に10万行もコードを提出してるのを見ると、AIの出力に対して深く考えたりレビューしたりしてるとは思えない。経験上、AIに複雑なプロジェクトの大部分をコードさせると、非常に脆弱で、過剰に複雑で、考えが浅いものになりがちだって知ってる。磨かれたランディングページを持つAIのゴミプロジェクトを調査して痛い目にあったこともあるし、主張されているベンチマークが不適切に実行されたり、AIによって幻覚されたりすることもある。実際にこれを使ってる人いるの？それとも、AIを使って数ヶ月間問題に取り組むことで履歴書のポートフォリオプロジェクトを作ろうとしてるだけの個人的な実験なの？

グラフデータベースの数に圧倒されてる？今週、新しいサイトを公開したよ。そこではグラフデータベースをリストアップしてカテゴライズしてるんだ。 https://gdb-engines.com

真面目な質問なんだけど、実際に信頼できるグラフデータベースってある？生産環境で合理的な規模で使えるもので、ベンダーとしてもオープンソースとしても手に入るやつ。例えば、MetaのTAOみたいなやつじゃなくて。

Grafeoを使って1時間過ごしたんだけど、関連するライブラリのgrafeo_langchainをローカルのOllamaモデルで動かそうとしてた。結果はまちまちだったよ。PythonのKuzuグラフデータベースがすごく気に入ってるけど、開発者がもうサポートしてないのに今でも使ってる。

埋め込み可能なものについてだけど、gfqlのサイファー構文を発表したばかりだよ。これで、データフレーム上で使える初のOSS CPU/GPUサイファークエリエンジンができた。通常、databricksやsplunkのようなスケールアウトDBと一緒に使われて、セキュリティや詐欺、イベント、ソーシャルデータ分析パイプライン、ML+AIの埋め込みや強化パイプラインなどに使われるんだ。元々は、Graphistryのユーザーが埋め込み可能なインタラクティブなGPUグラフ可視化アプリやダッシュボードを作るために、外部のグラフDBを追加せずにインタラクティブな分析フローを実現するために作ったんだ。単一のGPUで1B以上のエッジ/sが処理できて、DBのインストールも不要。データフレームやApache Arrow、Parquetに直接働きかけることができるよ。https://pygraphistry.readthedocs.io/en/latest/gfql/benchmark... GPUとベクトル化の加速にはマルチレイヤーアプローチを採用していて、より並列処理に優しいコアアルゴリズムを含んでる。これにより、ほとんどのカラムエンジンが抱える問題を解決しつつ、便利な機能を使いたい時だけ支払う形にできるんだ。私たちのベクトル化されたコアは、すでにTCKの半分以上に準拠していて、フローが確立された今、異なるレイヤーでより複雑な部分を追加する作業を進めているよ。コアのGFQLエンジンは、世界中の多くのアナリストチーム（NATO、銀行、アメリカ政府など）に使われていて、もう1年か2年の間に本番環境で運用されているんだ。オープンソースのサイファーサポートは、他の人たちが直接使いやすくするための第一歩だよ、LLMも含めてね :)

「graph-benchでLDBCソーシャルネットワークベンチマークをテストしました」というのが、あなたが作ったベンチマークかどうかは不明だね。「私たちはDBとベンチマークツールを作って、そのツールが私たちが一番だと言っている」よりも、もっと信頼性があるように見える。注意が必要な点だよ。自分たちのツールだと明言して、他のプロジェクトが最良の形で比較されるようにフィードバックを歓迎するって言った方がいいかも。そんな感じが役立つかもしれないけど、難しい問題だね。

グラフデータベースを見るたびに、何の問題を解決しているのか全然分からないんだ。特にLLMの世界では。グラフには面白い特性があって、動的でオープンエンドなクエリには魅力があるけど、グラフDBを使って人々がどんな機能や製品、顧客体験を作っているのかが分からない。探ってみても、結局「うん、でも標準的なDBなら90%は10%の労力でできるよね」って思っちゃう。

jandrewrogersが言ってるグラフトラバーサルにおけるキャッシュ置換の病理については、実際にハードウェアサイクルを消費して初めて学ぶことができることだね。Neo4jを使ってナレッジグラフのクエリを行っていた時も似たような問題に直面したよ。トラバーサルの深さが4-5ホップを超えると、データサイズに関係なくレイテンシが予測不可能になった。埋め込み可能なアプローチは面白いけどね。小規模から中規模のグラフ（< 10Mエッジ）が単一プロセス内で動作する場合、スケーラビリティの懸念はあまり重要ではなくて、「依存関係を追加するだけ」で済む開発者体験が、別のデータベースサーバーを運用するよりも優れているんだ。