mysqlで演算処理をさせるべきかAP側でやるべきか

Question

あくまで一般論としてお聞きしますが、mysqlで演算処理をさせるべきかAP側でやるべきかを伺いたいです。

mysql側で複雑な計算処理（特定の条件に符号するテストの平均点や偏差値などの計算処理）をさせるべきか否かです。

mysql側でさせると、クエリはjoinやlike句、IN句、where句の演算子、サブクエリなどで複雑化し、開発効率は落ちる気がするのですが、反面AP側で返ってくるデータがすっきりしていてAP側の処理が簡潔に済むかなと思うのですが、みなさんは普段どのようなクエリを書いていますか。

Answer 1

実際に直面しているわけではない架空の状況であることと、架空の状況も具体的に考えられていない、極めて抽象的な質問なので回答も抽象的になりますが、「ケースバイケース」としかいえませんね。

初心者の方とのことなので、そういう質問になるのかもしれませんが、複数の方法が選べる場合は多くのケースでは、最適な方法は「こうすればいい」という単純な方法があるわけではない場合が多い、と言えます。なのでそれぞれのケースにおいて、経験・知識などから個別に判断するしかないでしょう。

少し具体的にいえば、データが1000万レコード以上、「社内向けもしくは個人向け」のシステムでは無く、不特定多数の人が使用するWebシステムならば、まずは「速いと思う方」で実装すべきです。

そして1000万件以上の大量のデータを投入しパフォーマンステストを行い、処理速度に問題があればDBをチューニングしたり、SQLで処理をしていたのならアプリケーションで処理をするようにさせてみたり、あるいはアプリケーションで処理をさせていたのならSQLで処理をするように変更したり、いろいろ試して速度差を比較し最適な方法を選択する、と言うようなアプローチになると思います。

逆に、社内もしくは個人で使用するシステムで、データも10万件以下の小規模システムなら、「どうだっていい」と思います。SQLが得意な人ならSQLで書けばいいし、SQLが苦手ならアプリケーションで書けばいい、と言うように、好き嫌い・得意不得意の要素で決めて問題ないと思います。

あとさらに言えば、どこで処理をするか変わる可能性があるとはじめからわかっているのなら、最終的な結果を返す関数・メソッドを作っておき、その関数・メソッドの中で実装の差を埋められるようにしておけば、他に影響せずにロジックの変更が行えます。

あと「特定の条件に符号するテストの平均点」は、私にとっては極めて単純な計算処理だし、それを行ってもSQLを複雑にせずに書けると思うので、特に悩まずSQLで処理してしまうことが多いと思います。偏差値になると若干複雑になるので、一旦SQLで書こうと試みて、複雑になるようであればアプリケーションで実装と言うことになると思います。

Comments

[imamoto_browser]

長文で回答いただいておりますが、もう私の質問に回答しないでください。
私はあなたの自慢話が聞きたいわけはないし、実際の案件の話を質問として採用できるわけないですよね？

それに抽象的な質問だから抽象的な答えしかできないというのはおかしいと思います。あなたがこの質問のテーマを「どうだっていい」と思う以上に、私はあなたの回答を「どうだっていい」と思います。

[takotakot]

imamoto_browser 様
「一般論としてお聞きします」と聞いておいて、「抽象的な答えしかできないというのはおかしい」という意味が分からないです。
『少し具体的にいえば、データが1000万レコード以上』、『 データも10万件以下の小規模システムなら』と、レコード数をあげて具体的に、どう選択すべきか述べられておられます。

質問がどうだっていいとは一言もおっしゃっていません。『データも10万件以下の小規模システムなら、「どうだっていい」と思います。』という意見な訳ですよね。

「実際の案件の話を質問として採用できるわけないですよね？」というのも、案件詳細は伏せつつ、できるだけ具体的に質問するかどうかは、質問者のスキルだと思いますよ。
もちろん、一般論や抽象的な話に、具体的な話を混ぜて回答するのは、回答者の時間があるかと、スキルがあるかに依存するとは思います。

皆さんの答えは、「ケースバイケース」で一致しています。

おかしいのはどちらでしょうか？？

[miu_ras]

takotakotさんやめて下さい。そういうことを伝えようとしても、どうせ彼の耳には届かないでしょうし。

実際に問題に直面し困っているわけでもなく、架空の状況に対し抽象的な質問をしている時点で少しおかしな人だとうすうす感ずいていたのに、無視せずに回答してしまった私が悪いのです。

Answer 2

処理の負荷はほとんどの場合、

ソート >> 四則演算

となります。

JOINを避けてもDBサーバの負荷は下がらないどころか、負荷が上がります。
ただし、MySQLにないOLAP関数などの処理をサブクエリを使って無理に使ったりすると、MySQLはハッシュジョインがないため不要なループが発生して非効率になることがあります。

四則演算をするためのCPUリソースを使うことを嫌って、ソートまで行って、演算に必要な元データをAPサーバなどに転送するということは、

転送中にキープされるメモリ
ネットワークのリソース
転送に必要なCPU(知れてますが……)

などを消費します。
APサーバで処理させるならば、「DBサーバでソートさせない」ぐらいでないとDBサーバの負荷は下がりません。

MySQLはOLAP関数がないのと、ハッシュジョインがないのとで、APサーバで処理した方がDBサーバの負荷が下がることはあります。
そもそも、OLAP関数を使わないと行けないような処理があるなら、MySQLを選択すべきではないでしょう。

ネットワークを通じてデータをコピーしてから処理するというのは、DBサーバ、APサーバ共に、大変なコストが掛かります。それを相殺できるほどDBサーバの負荷を下げることは、基本的には難しいです。

スケールアウトのためにJOINを避けるより、マスター類をコピーしてマルチフェーズコミットする方がマシです(ケースバイケースですけどね)。

「艦これ」から、ソーシャル系のサーバ構成を考える

Comments

[kantomi]

偏差値はOLAP関数(Window関数・分析関数)になるので、MySQLではちょっと面倒になります。
MySQLでは標準偏差までしか出せませんから、そこから先を、APサーバで行うかは微妙なところです。
OracleやSQLServerなら一発です。

Answer 3

こんにちは。
開発効率というより、どこに負荷をかけて集中処理させるかを決めるのが良いのではないでしょうか。
また、それはアプリケーションの性能要件によるので一概に言えるものではないと思います。

MySQLで行えばDBサーバの負荷があがりますし、
Webシステムの場合はサーバAPで行えばWebサーバの負荷があがり、
クライアントAPで行えばクライアントの負荷があがります。

非力なクライアントであればサーバで行うべきかもしれませんし、一方私が以前行っていたプロジェクトではサーバでの負荷を下げるという方向性が既に決まっていたため、SQL上での複雑な演算は禁止されていました。
一概に言えるものではないのではないかと私は思っています。

ただ、本来こうするべきだよというガイドライン的なものはもしかしたら存在するかもしれませんね。
私も少し興味があります。

Answer 4

上の方々が意見されているとおり、ケースバイケースですが、
わたしの場合はソースの可読性が高いものを選びます。

しばらくたった後でも、自分で見てわかりやすいコード構成を心がけるのが一番と考えます。
後々のメンテナンスや、改良のことを考えて、です。

実際に速度云々に関しては、対処法は選択できますし、その場合は周辺の状況(スケールアウト、スケールアップなど)で変わってきます。
また、実際のところボトルネックがどこにあるのかはベンチを取るのが一番間違いない(想定されている対処法がベストとは限らない)のですから。

APサーバー側の言語もわかりませんしね。