Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応

Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応 SQL文を直接書かなくとも、自動的にSQL文を生成、実行してくれるORM（Object-Relational Mapper）は、プログラミングを容易にしてくれる技術としてRailsやHibernate、Springなどさまざまなフレームワークなどで活用されています。 一方で、ORMが生成するSQL文はときに複雑に、あるいは非効率なものとなり、データベース処理の遅さにつながることもあります。 このとき、SQL文の生成と実行を明示的にコードとして記述する必要がないというORMの特徴が、なぜデータベース処理が遅くなったのか、どのようなSQL文が生成され、そのどこに原因があるのか、といった調査を難しくている面があり

[Songmu]

これを最近Goでできるようにして本番投入していました。 https://songmu.jp/riji/entry/2021-02-03-go-sql-embed-comment.html

[circled]

LaravelはオフィシャルのTelescopeパッケージかLaravel Debugbar( https://github.com/barryvdh/laravel-debugbar )がおすすめ。表示されるページ毎のModel数やSQL処理時間、生SQLが事細かに分かるので、チューニングが快適＆爆速に行える。

[xlc]

ORM自体が愚か者の手法。SQLをOO化したがるのに何故正規表現はOO化したがらないのか。問題解決にはそれに適した表現方法がある。OOが万能ではない。

[jiro68]

どのSQLが遅いか分かったからといって、それを早くする方法があるとは限らない。RDBMSのスキルとORMの内部構造の知見が無ければ早く出来ない。

[karupanerura]

PerlだとDBIx::SunnyとかDBIx::HandlerとかTengとかでやってくれるやつじゃん。6,7年くらい前からあるぞ

[tarao]

ORMではないけど、Scalaで前から当然のようにやっていたやつだ https://github.com/tarao/slick-jdbc-extension-scala#the-default-translators

[cl-gaku]

MyBatisで優勝してるので大丈夫

[sasasin_net]

Googleが再び未来技術を下々に！と期待したらずっこけた。もはや「Googleですらこれしか無いと匙を投げた」ということなのか

[daichirata]

OpenCensus (Stackdriver) と連携できるところが今っぽくて良さそう。というかこれはそういう事がしたかったのでは。

[yarimoku]

PHPとLaravelはないのか…

[earu]

そもそも複雑なクエリは素で書くようにしてます

[tmatsuu]

わいわい

[rryu]

ORM側でSQLをロギングするのではなく、発行するSQLに元の操作をコメントで入れることでMySQLのslow queryなどのDBMS側のログから追いやすくするというものっぽい。

[koriym]

"ORMはコンピュータ・サ イエンスにとってのベトナム戦争" (2004) http://blogs.tedneward.com/post/the-vietnam-of-computer-science/

[matsubobo]

ORMにはシンプルなクエリーしか発行させないようにしているからほとんど問題は発生しないです。複雑なクエリーを書く場合は集計用途なのでDWHに任せるか、redashなどのグラフ描画ツールにまかせてます。

[asa_ca3]

コメントがログに出てれば抽出しやすい

[fujiten3]

自分が使ったことあるORMでの雑感だとActiveRecordはクエリ打った場所の行数とかかった時間はデフォルトで表示したと思うので、それ以上が欲しい人向けなのかなという感じ。SQLAlchemyはどうだったけなあ…。

[dlive1]

sqlcommenterはORMが生成するSQL文にコメントを追加することで、データベース処理が遅くなった時などの切り分けをしやすくする

[n_231]

ORM嫌われすぎてて草。あれ解決する問題と同程度以上の問題を別の箇所に生み出しがちなので気持ちは分かる。

[umasioaji]

ORマッパーことORMはボトルネックの原因になる箇所。どのスキルレベルでもパフォーマンスを意識した開発が容易になるというのは良いことだと思う。

[phoope]

おー！これはいい！

[Soraneko]

ステキ

[minamishinji]

気になる。そして、これをGoogleがつくってる理由も気になる。

[hisaichi5518]

昔にRails用に同じようなの書いてたの思い出した

[owxy-tan]

お役立ち／諦めるという選択肢は…人類にORMはそんなに必要無い気がしているけど。結局SQLの方が再利用、メンテナンスしやすいと思うことが多いけど

[nmcli]

抽象化のための技術と高速化は両立させづらいよなぁ……

[h_taiji]

これは使える！

[morita_non]

oracleない？

[vuy]

ORM使うのやめてほしい。2waySQLこそ最高だと思っている。

[metatrading]

かんたんに使えるなら…。そもそもORM側の問題では。仮に調査の結果重いSQLがある場合、結局ORMで解決する方向性にならない気がする。それにDB自体にも重いSQLを検知する仕組みはある。

[daishi_n]

ORMは便利そうで微妙だよね。RDBMSを使うノーコード系の裏はORMだろうけど、未だに問題が解決しない

[raimon49]

無難で良いアプローチに見えるけど同じコンセプトのツールが既にたくさんありそう。