SQLの実行パフォーマンスについて 2010


@IT エンジニアライフのコメンテータ(だった)生島さんのコラムhttp://el.jibun.atmarkit.co.jp/g1sys/2010/05/post-2d1b.htmlのコメント欄に参加しました。

生島さんのコラムですが、過去に度々炎上してきましたが、炎上するたびに、

『SQLはオブジェクト指向言語の数十倍の効率』

という、この手の話が出てきます。この手の呪文は他にも幾つかあるのですが、これを出せば議論が終結するというある種の必殺技みたいに使われます。
が、それどころか、毎回、毎回、明確な結論が出ずにさらにコメント欄が荒れます。
私としては、本来はどうでもよい話なのですが、いきがかり上、私も思わず、

「私は、過去にSQLが遅いのでSQLを崩して、C言語でJOINをやらせて高速化しました。OO言語ではないですが、今だったらC++を使うでしょう(なぜってハッシュクラス があるから)。」
と発言しました。恐らく、多くの方は、

『いやいや、いくらなんでも、それはウソでしょう。』
とか、
『売り言葉に買い言葉でしょうが、それは良くないでしょう。』
とか、
『幾らC++が好きって言ったって、原理的にDBMS内で処理が閉じるSQLの方が速いでしょう。』
とか思われたことでしょう。

私も、そういうツッコミが来ることは重々承知していたのですが、現実に私は10年以上前になりますが、上記のような最適化を行ったことがありました。
以来、別にわざわざSQLを崩してCでJOINなんて事はしませんでしたが、逆にその後、さまざまなプロジェクトを通して、DBMSの動作をみる限り上記の最終手段は、まだ有効だなというのも実感としてあったのですが、あまりの共感の得られ無さにものすごい孤独感に襲われ、また生島さんの煽りも受け、このあたりで白黒はっきり付けたいと思います。


では、どのように白黒つけるのかですが、やはりベンチマークテストを行ってみるしかないかと思います。

つまり、生島さんが件のコラムのコメント欄に書かれた

TABLE_A a
INNER JOIN TABLE_B b
    a.KEY = b.KEY

をもとにしたSQLをC++で書き実際に実行させてその実行時間をみてみましょう。


■実験の環境

 <追記>この記事のコメント欄の指摘(サーバーとクライアントマシンが分かれていない)および環境が変わったので再現できない関係で、新しく環境を構築してテストをやり直しました。
 今回実験したテスト環境を示します。

■実験するSQLとプログラムの概要


以下のSQLを実行させ、カンマをセパレーターとして標準出力へ出力させます。
CSVファイルへの出力を想定したSQL、JOINの部分は生島さんがコメント欄で指摘したSQLそのものになっています。このSQLをもとにJOIN部分をC++でやらせてみます。
SELECT Price.CODE, RDATE, OPEN, CLOSE, NAME
FROM Price INNER JOIN Company ON (Price.CODE = Company.CODE)

■実験1 素直にSQL側でJOINをさせたものを実行


 以下のコードのとおり、実験するSQLをそのまま実行してみました。

#include <iostream>
#include <time.h>
#include "../kz_odbc.h"

using namespace std;

int main(void)
{
    kz_odbc db("DSN=Trade",true);
    kz_stmt stmt(&db);

    time_t  t = time(NULL);

    // テーブルからデータの取得
    stmt, "SELECT Price.CODE, RDATE, OPEN, CLOSE, NAME "
          " FROM Price INNER JOIN Company ON (Price.CODE=Company.CODE)"
          , endsql;
    kz_string_array result = stmt.next();
    int             cnt = 0;
    while ( !result.empty() ) {
        cout << result[0] << "," << result[1] << ","
             << result[2] << ","  << result[3] << ","
             << result[4] << "\n";
        result = stmt.next();
        cnt++;
    }

    cerr << "Execute time is " << time(0) - t << "sec." << endl;
    cerr << "Record count is " << cnt << "." << endl;
    return 0;
}

コードですが、Wordpressに合わせて編集してますので、変なところで改行が入っていますが御勘弁を。
 若干ですが、コードの説明を、
 stmt, "SELECT ・・・・
 とか
 result.empty()
 stmt.next()
の部分が私が作成したライブラリになります。といってもODBC APIを呼び出しているだけになります。そう特異なものでもないかと思います。
 実行結果ですが、
Execute time is 131sec.
Record count is 4671568.  
 となりました。プログラムは標準出力に出力していますが、実行に際しては標準出力をファイルにリダイレクトしています。その方が実行速度は速くなります。
 比較元のデータが無いので何とも言えませんが、1秒間に約3万5千件のデータがCSVファイルへ落とされているのでマシンスペックを考えますとまずまずでしょう。
ちなみに、実行ブランを確認しましたが、CompanyテーブルへのアクセスのTYPEはeq_refでユニークキーによるJOIN(最速のテーブルアクセス)が実行されていることを確認しました。

■実験2 C++側でネステッドループでJOINさせてみる

 ループループといっていたものですが、いわゆるネステッドスープのことだと推測します。

#include <iostream>
#include <time.h>
#include "../kz_odbc.h"

using namespace std;

int main(void)
{
    kz_odbc db("DSN=Trade",true);
    kz_stmt stmt(&db);
    time_t  t = time(NULL);

    // テーブルからデータの取得
    stmt, "SELECT CODE,RDATE,OPEN,CLOSE FROM Price", endsql;

    kz_string_array result = stmt.next();
    int                cnt = 0;
    while ( !result.empty() ) {
        // JOINの実行(ネステッドループ)
        kz_stmt    stmt2(&db);
        stmt2, "SELECT NAME FROM Company WHERE CODE = ? "
             ,  result[0].c_str(), endsql;
        kz_string_array result2 = stmt2.next();

        cout << result[0] << "," << result[1]  << ","
             << result[2] << ","  << result[3] << ","
             << result2[0] << "\n";
        result = stmt.next();
        cnt++;
    }

    cerr << "Execute time is " << time(0) - t << "sec." << endl;
    cerr << "Record count is " << cnt << "." << endl;
    return 0;
}

実行結果は以下のとおりです。
Execute time is 1714sec.
Record count is 4671568.

 これはものすごく遅いですね。生島さんが、
『SQLにすると数十倍速くなる』
といっていたのは、実験1のコードと実験2のコードを比べて言っていたと思われます。
では、これ以上に速くさせる方法はないのでしょうか?
生島さんの言うとおり、OO言語はSQLと比べて何十倍も遅いのでしょうか?

■実験3 C++側でハッシュJOINさせてみる

 件のコメント欄で生島さんが難しいとおっしゃっていた、ハッシュJOINですが、実は特段、難しいものではありません。
 以下のようにすっきりと実装できます。
 ちなみにコード中に出てきますmapというのはバイナリサーチを行います。なので、正確にはハッシュJOINではありません。
 C++でハッシュ検索を行うには、Boost等のライブラリを使う必要があります。
 つまり今回のコードはある意味、最適化の余地を残しているのですが、ここではテストの再現性(環境設定)の手間を考えてmapを使います。

#include <iostream>
#include <time.h>
#include "../kz_odbc.h"

using namespace std;

int main(void)
{
    kz_odbc db("DSN=Trade",true);
    kz_stmt stmt(&db);

    time_t  t = time(NULL);

    // マスターの取得・マップの作成
    map< string, string>    company;
    stmt, "SELECT CODE, NAME FROM Company  ",  endsql;
    kz_string_array result = stmt.next();
    while ( !result.empty() ) {
        company.insert( pair< string, string>( result[0], result[1]) );
        result = stmt.next();
    }

    // テーブルからデータの取得
    stmt, "SELECT CODE,RDATE,OPEN,CLOSE FROM Price ", endsql;
    result = stmt.next();
    int                cnt = 0;
    while ( !result.empty() ) {
        cout << result[0] << "," << result[1] << ","
             << result[2] << ","  << result[3] << ","
             << company[ result[0] ] << "\n";
        result = stmt.next();
        cnt++;
    }

    cerr << "Execute time is " << time(0) - t << "sec." << endl;
    cerr << "Record count is " << cnt << "." << endl;
    return 0;
}


 結果ですが、以下のとおり、実験1のコードよりも早くなっております。
Execute time is 108sec.
Record count is 4671568.


■結果

実行結果を再度以下に掲載します。
 
実験1(SQL) 131秒
実験2(C++側でネステッドループ) 1714秒
実験3(C++側でハッシュ) 108秒


 明確に結果が出ているかと思います。こんなに単純なテストの結果からでも
 「SQLをばらしてJOINをC++で行えば速くなる場合がある」
ということは理解していただけれるかと思います。
また、
『SQLはオブジェクト指向言語の数十倍の効率』
というのは、単純に
 「OO言語側の最適化が不十分である可能性がある」
ということも言えるでしょう。

ただ、実験3では、高々十数%しか速くなっていません。
ということであれば、通常はやはり実験1のようなコードの方がトータル(開発効率と実行効率を考えると)としては良いと思われる。実験3のような事実はあくまでも知識としてしておきたいところです。

追記、コメント欄の議論を踏まえて再度記事をアップしました。
追記、コメント欄の指摘(ローカルマシンで動かしている)を受けまして再度環境を作成して実験しました。
追記、まとめ記事を作成しました。

2010-05-31 | コメント:14件
xerenより
2011-01-03 20:11:05
久々に昔のブックマークを漁ってたら、生島さんの@ITコラムが出てきたので辿ってきてみました。
半年も前のブログにコメントしてスミマセン…

予想した通りやっぱりWhere句が無かったw
でも、生島さんと同じ結論(実験1のようなコードの方がトータルとしては良い)になってますね。

実験3が速い理由はこんな感じでしょうか?
・Where句無しの全件出力(結合する前の時点で無駄データがほぼ取得されない)
・オプティマイザによる結合方法の判定自体が省かれる。(誤差?)

単位株数が2000株のものだけ抽出、とかになると、また話が変わってしまうわけです。

ご存知の通り、ハッシュJOIN等の機能が元々RDB側にあり、
これをCとかJavaとかの言語側で再開発するのは非効率です。(その分のドキュメントが要るため)
逆に、オプティマイザやRDBとのI/Fといったオーバーヘッドが足を引っ張ることもあります。(この記事の例)

後者がでかくなるのは、デカルト積でデータ増幅させる時のネットワーク負荷とかかな…
トータルでは後者は誤差だと思いますが、あのコラムは無駄な炎上とかするよりも
上記のトレードオフとかの議論に発展して欲しかった…
おおふじより
2011-01-04 15:45:39
xerenさん
はじめまして、それなりに手間隙かけて作った記事なのでコメントもらえてうれしいです。
もっとも、コメント自体は興味深いのですが、一部、誤解があるようなのでコメントします。
もともと、生島さんの意見である、
『SQLはオブジェクト指向言語の数十倍の効率』
を否定する為の例なので、本文では細かいことは書いていませんが、実験3が実験1より速い理由は誤差ではなく他にあります。
ここで書いてもよいのですが、先のコメントがいい線ついていますので、よろしければ再度コメントください。

また、結論が生島さんと同じだからと言っても途中の考え方がぜんぜん違います。
実験1のSQLのパフォーマンスを上げてほしいという要望があったときに生島さんは恐らく『できない』という結論になるでしょうが、私なら状況により実験3以上のコードを書くことができる可能性があります。
xerenさんが顧客ならどちらに仕事を依頼したいでしょうか?

もともとJoinの高速化の話なので、where句についての高速化云々についてはまた別の話ですが、そういう考察は嫌いではないので、よろしけれ単位株数が2000の場合のベンチマークについて具体的にどのようになるか教えて下さい。
xerenより
2011-01-07 16:16:46
こんばんは。

翌日にレスをいただけていたのですね…反応が遅くて申し訳無い…

> 実験3が実験1より速い理由
前レスにも書いていますが、
『より低級な言語で作った方がオーバーヘッドが少ない。』とは違う理由でしょうか?
だとすると私の見落としだと思いますが、誤差以上の何かをこの例からは読み取れませんでした。

> 結論が生島さんと同じだからと言っても途中の考え方がぜんぜん違います
私に読解力が無いせいかな?
実行効率と開発効率の考察順序が逆なだけにしか見えないです。

> 実験1のSQLのパフォーマンスを上げてほしいという要望~生島さんは恐らく『できない』
流石に『できない』と答える技術者社長は居ないと思います(笑)
そもそも、実験1のパフォーマンスが不満ならば、実験3程度では恐らく満足しないでしょう。

業務に依存しない手法に絞れば本記事のような方向性になりますが、
実践的には業務の特性からの見直し(例:Priceテーブルの非正規化)等の方が効果が見込めます。
(元が第三正規化済なので高確率で可能ではないかと。)

>単位株数が2000の場合~
ココは少しゴメンナサイ。比率を調べたら例として不適切でした…
(少ないとだけ知っていたのですが、日本に1社しか無いようです…)

この例は、要するに何が書きたかったのかというと、本文中の↓のところについて、
>「SQLをばらしてJOINをC++で行えば速くなる場合がある」

『SQLをばらしたせいでJOIN以外の性能劣化要素が発生する』ことを"話が変わってしまう"と表現しました。
【例】20社(約5万件)に絞られたと仮定すると、レコード41万件(*(10+8+4+4)byte≒1GB)以上の通信が余分に発生します。

SQL(DBサイド)で出来ることをC++(APサイド)に持ってくる事自体がロスになるわけです。

priceテーブルへのクエリの条件で20社分のCODEに絞れば良い、と思われるかもしれませんが、
1000社にしか絞れなかった場合のクエリが酷いことになるのは説明するまでもないと思います。

概要ベースですが説明になってますでしょうか?

P.S. 私のネット環境要因ですが、また遅レスになってしまった場合はご容赦ください。
おおふじより
2011-01-08 02:10:56
ご返信ありがとうございます。

じっくりと議論した方がよろしいかと思いますので、返信については遅くてもよろしいかと思います。
さらに興味深い論点が出てきましたが、記事では今回使用したDBとコードがダウンロードできるようになっています。のでお試し頂ければ話が早かったりします。もちろん、今までどおり自由にご意見を言って頂いても構いません。


>実験3が実験1より速い理由
>『より低級な言語で作った方がオーバーヘッドが少ない。』とは違う理由でしょうか?

joinの場合はインタフェース上の理由で原理的に実験3が速くなります。せっかくですので少し考えてみて下さい。
ちなみにNoSQLが発生した原因(というかそれが有効に使えるという原理)もこの点にあると考えています。

今回の実験をC++で行った理由は言語側のオーバーヘッドで結果が変わることを回避したかった為ですが、試しにC#でも実験を行いましたが実験3が実験1より速いという結果は変わりませんでした。

> 結論が生島さんと同じだからと言っても途中の考え方がぜんぜん違います
> 実験1のSQLのパフォーマンスを上げてほしいという要望

有意義な議論がしたいのでこの点はこれで最後にしますが、生島さんの意見である、
『SQLはオブジェクト指向言語の数十倍の効率』
について、xerenさんのご見解をお聞かせください。

>例:Priceテーブルの非正規化

生島さんの記事のコメント欄にも書きましたが、パフォーマンスについてシンプルに
『○○が速い』
とは言い切れない場合があります。ケースバイケースになります。ですので今回の記事は検証可能なようにDBとコードをダウンロードできるようにしています。
確かにテーブルの非正規化も手段としては有力です。もちろんですが今回の記事を作成する際に非正規化についても実験しましたが、実行時間は実験3より速くはなりませんでした。ここになぜ実験3が速いのかのヒントが隠されています。

>「SQLをばらしてJOINをC++で行えば速くなる場合がある」
>『SQLをばらしたせいでJOIN以外の性能劣化要素が発生する』ことを”話が変わってしまう”と表現しました。
状況が複雑になればなるほど問題の本質を見極め個々の要素を正確に認識して適切に対応する必要があります。今回の件は、まさにそれで、絞り込みに関してはきちんと対応すれば話が変わることはありません。

例えば単位株数が1000のデータを絞るとき、実験3の2つ目のSQLに以下のwhere句をつければ結果はどうなると思われますか?

WHERE [CODE] in (SELECT [CODE] FROM Company WHERE [UNIT] = 1000)

最適化というのは往々にしてトリッキーになりますが、ここが腕の見せ所になります。
xerenより
2011-01-10 04:10:28
おおふじさん、こんにちは。

今、自由に使える環境が無いため、また憶測での内容になります。ご容赦ください。

>joinの場合はインタフェース上の理由で原理的に実験3が速くなります。
ようやく分かりました…
実験1の方が実験3よりもAP⇔DB間のI/F量が (4671568-1950)*Byte 大きくなり、
複数回リクエストになること等のオーバーヘッドを上回ってしまう、と。
平均25Byteと仮定して100MB↑になりますもんね。

直積でなくとも、実質Companyデータを増幅させているのに…
我ながらぬけてました(笑)

>WHERE [CODE] in (SELECT [CODE] FROM Company WHERE [UNIT] = 1000)
これは目から鱗でした。(SQL文自体ではなく、敢えて同じクエリを投げる点)
それだけ、I/F量が大きいということですね…

>『SQLはオブジェクト指向言語の数十倍の効率』
「世の中の多くの基幹システムが実験2の形式になっている。」という前提の下で成り立つ話だと思ってます。
(現実問題として、実験2がマシに見えるものも少なくないですし…)
そもそも業界によっては適用できない、といった制約もありますが、そこはまた別の話かと。

認識違い等がありましたら、ご指摘いただけると幸いです。
おおふじより
2011-01-10 07:19:23
xerenさん

ご返信ありがとうございます。
こちらの検証内容を信用していただけるのなら、自由なご意見でぜんぜんOKです。

さらに面白い点をご指摘されたので、

>>『SQLはオブジェクト指向言語の数十倍の効率』
>「世の中の多くの基幹システムが実験2の形式になっている。」という前提の下で成り立つ話だと思ってます。

実は、私は実験2のコードを速くしたいという衝動に駆られているわけでして、まとめ記事ではないですがこのコメント欄を踏まえて記事を再度アップします(ちょいと時間がかかりますのでしばしお待ちを)。
もっとも使う言語は、C++ではなくて私が開発中のADPで行います(つまりADPの宣伝も含まれてます・・・)。

ちなみに、実験3に対する考え方は1月10日のコメントで間違いありません。最初にwhere句の話を出されたときに、この点にも気づくだろうと思いましたので、ちょっと回りくどい書き方をしました。

以降は、余分な議論になりますが、私を含めてあの記事を読んだ多くの方が感じたことを代弁しておきます。誤解の無いように前置きしておきますとあくまでも、先の生島さんの主張を否定しているだけでして、生島さんの技術力等について否定するつもりは毛頭ありません。

SQLに限らずプログラミング言語にはプログラマを引き付けるパワーを持っています。
技術者として、はじめて触った言語は特に思い入れが強くなります。私も含めて、プログラマなら誰しもそういう道をたどります、生島さんの

>『SQLはオブジェクト指向言語の数十倍の効率』

の主張からは、そのような思い入れしか見えません。
xerenさんはそう感じないかもしれませんが、ある程度技術者として経験年数を踏むと上記の主張からは、そのような不用意さを感じざるを得ないのです。

私はこの業界でプロとして20年目になりますが、RDBMSが一般的になってから15年ぐらいでしょうか?少なくとも私がプロになって間が無いときはRDBMSに対する上記のような妄信はありませんでした。
またその頃のRDBMSは特に実行性能が悪く、当時私が体験した例では、今回の実験で示したような性能差が、それこそ何倍のオーダーで、もっとはっきりと出ていました。
今でこそ今回の実験のような誤差と間違うような差になりますが、例えば「結合するテーブルの数が増えた場合どうなるか?」とかはエンジニアとして常に頭の片隅において置かなければなりません。以来、joinに限らずRDBMSのさまざまなパフォーマンスの問題には対応してきました。
そのような観点で見ると、

>『SQLはオブジェクト指向言語の数十倍の効率』

は、「あ~この人、知らないんだな~」としか受け取れないのです(繰り返しになりますが、この点1つをとって個人の技術力を否定するつもりは毛頭ありません。実験2のようなコードしかかけない技術者もいる事実からしたら、実験1のコードを書く技術者には立派に及第点が与えられます)。

SQLはすばらしいです。それは事実です。しかし過大評価はいけません。道具を使いこなすのはエンジニアの仕事です。技術に対しては常にニュートラルに対応したいものです。このような観点に立つと、自身の主張に対する否定的な意見を
『一般論に個別の事情は意味がない』
と一蹴するのではなく、
「多くの素人エンジニアがやってしまいがちな実験2のコードを速くするにはどうすればよいか?」
という前向きな考え方も生まれてくるようになります。もちろん、現段階では実験2より実験1の方が良いという評価になるのでしょうが、SQLに対する評価もそうであったようにパラダイムシフトがあるかもしれません。エンジニアたるもの技術革新に対しては常に貪欲であり続けたいものです。

長文失礼しました・・・
生島勘富より
2011-08-10 19:39:13
コメントどうも。

コメント欄は全部読んでません。

思ったより速いですが、これって同じマシンでやってるでしょう?
通常ではネットワーク通信が入りますから更に数倍遅くなります。

SQLServerはプライマリキーがクラスタードインデックスになります。
Company.codeとPrice.codeを繋ぐのはおかしく、Company.codeを主キーにするか
Company.codeをクラスタードインデックスにしないと条件は同じではありません。

後、イロイロ突っ込みどころはあるのですが、そもそも論として全件と全件
というレアな結合で、Companyマスタを全件取得してもロスがゼロという条件なら
そうなるでしょう。
ohfujiより
2011-08-10 20:02:25
コメントありがとうございます。

せっかくコメントいただいたのですが、もう少しちゃんと読んでください。
#というか意図的にやっているのでしょうか?

>そもそも論として全件と全件というレアな結合で

コメント欄に答えが書いてありますよ。

で、改めて質問しますが、

『SQLはオブジェクト指向言語の数十倍の効率』

という考えは変わりませんか?
先の記事ではニュアンスが変わっていますよね。
生島勘富より
2011-08-11 00:43:40
元記事にもあってRDBMSにもあるオプティマイザの機能が
どこにも実装されて折らず、人間がやっている様に
思えるのですが?

あなたのすばらしい実装のどこで実行前にハッシュジョインが
良いのか、ネスティッドループが良いのか判断しているのでしょう。

優秀な方でしょうから、ついうっかりの実装漏れでしょう。
実装し直してからパフォーマンスを測って、是非、公開して
下さい。

それでも、もしSQLより速いモノが作れるなら私もRDBMSを
二度と使いません。

出来ないなら文盲と判断しますので、二度と掛かってこないで。
時間の無駄です。
おおふじより
2011-08-11 09:10:30
残念ですね。

本当のエンジニアというのは、少なくとも技術面では真摯であるべきです。
貴方が、過去に
『SQLはオブジェクト指向言語の数十倍の効率』
という考えを持っていて、それに反する事実を見たとき、それを素直に受け入れるのがエンジニアというものです。
(例えばxerenさんのようにです)。

技術的な論争を行ったとき、その内容は素人には判断できないので、適当に言いがかりを付ければ議論が成立しているように見えるでしょう。ただそれは本来やってはいけないことであると思いますが?

>それでも、もしSQLより速いモノが作れるなら私もRDBMSを二度と使いません。
私はこれからもRDBMSを使います。道具は適材適所で使えばよいのです。なぜこのような見苦しい言いがかりをいうのでしょうか?

>出来ないなら文盲と判断しますので、二度と掛かってこないで。時間の無駄です。
これは私のブログなので別に私が自由に話しをするだけです。

こういう話をされるということは、
『SQLはオブジェクト指向言語の数十倍の効率』
は間違いであったとお認めになったと受け取ります。
おおふじより
2011-08-11 09:16:49
おお、追加で記事を書かれていますね。

記事の内容的には面倒くさいのでコメントしませんが、
『SQLはオブジェクト指向言語の数十倍の効率』
という話は出てきていないようですので、これについては不正確であるとお認めになったと受け取ります。
おおふじより
2011-08-11 12:29:48
http://d.hatena.ne.jp/Sikushima/20110809/1312871002
ここは出入り禁止になったので、こっちに書いておきましょう。

この記事はもともと、@ITの記事の
http://el.jibun.atmarkit.co.jp/g1sys/2010/05/post-2d1b.html
にありました、
『SQLはオブジェクト指向言語の数十倍の効率』
を否定するための反例で、@ITの記事のコメント欄で、JOINの例を出されたからJOINの反例としてあげたまでです。

しかし、1年が経過し(私のこの記事を読んだのか)生島さんはツイッターで、
>JOINをなくすならAPサーバでキャッシュする。 集計関数をなくすなら、ORDER BYを禁止する。 SQLがイヤならRDBMSは使わないこと。 何度も書いているけれど、SQLで出来ることをAPサーバでやっても、【絶対に】DBサーバの負荷は減らない。 ただし、下手糞を除く。

と書かれています。つまりJOINの場合で、SQLより速くなるとご自身で言っておられます。これは私がこの記事と次の記事
http://www.ohfuji.name/?p=813
で指摘していることです。

であれば素直に一言「ありがとう。そういう場合もあるよね。」で済ませればよいのです。

それを

>オマエのクソコードのどこにヒストグラムを測ってアクセスパスを決定して
いる部分があるのか?

と言ってしまうから話がおかしな方向に行くのと思うのですが?

まぁ、言っても仕方がないのですが、気になることがありますので記事をあげて見ます。

追記、http://www.ohfuji.name/?p=1462 記事をアップしました。

ちなみに、誤解する人がいるかもしれませんので生島さんの質問に回答しますと、

>オマエのクソコードのどこにヒストグラムを測ってアクセスパスを決定して
いる部分があるのか?

コメント欄をよく読めばわかりますがxerenさんとの議論で答えは出ています。
またSQL側でJOINしたものが遅い理由は生島さんが、『JOINをなくすならAPサーバでキャッシュする』といっていることと同じです。生島さん自身そのことを解っているかと思うのですが、このような質問をしてくることに疑問を感じています。

komaruより
2011-12-15 00:30:01
1000秒が100秒になろうが、どちらも使い物にならないと思うのですが。
ohfujiより
2012-02-24 11:32:09
スパムの整理をしていましたら発見しました。
スパムとマークされていたのですが、せっかくなので承認済みにします。

コメントの趣旨がわかりませんが、そもそもベンチマークテストなので、テストの差が出やすいように大量の行数を処理していますしマシンのパフォーマンスもあまり良くありません。
従いまして、時間の絶対的な数値にはあまり意味がないのですが?

コメントをどうぞ


『不適切なコメントへの対応』を一読下さい。
現在コメントは承認制となっております。

Previous Page | Next Page