>>199
生成時に圧縮してbinaryで格納すると、select するフィールドが複数ある場合は、それぞれ decompress することになる訳ですね。
それでもいいけれど、できればDBサーバとの通信線自体を圧縮する方法がないものかと…。
そうすれば、今使っている諸ルーチンは一切書き替えず、データベースもそのままで使えそうなので。

>>198
いちおう、圧縮プロトコルがあります。
http://www.mysqlperformanceblog.com/2007/12/20/large-result-sets-vs-compression-protocol/

あとはSSHで圧縮かけてフォワーディングするとか。

おおお、早速有難うございます。php ではないけど、関連で探して早速テストしています。
教えて頂いたページでは giga-bit ether だと圧縮のオーバヘッドの方が上回るとあるけど、
うちのはCPUが暇してるせいか、giga-bit でも少し速くなっている気が… w
有難うございました。

MySQLの認定資格を受けようと考えているのですが、
参考書が原書（英語）しかないようです。
試験対策になりそうな日本語の書籍がありましたら教えてくれませんか。

データベースのハンドリングって何ですか？

>>207です。自己解決しました。どうもお騒がせしました。

実データでやってみないとわからないが、全然パフォーマンスが出ない場合もあるだろう。

おそらくあらゆる引き方でインデックスが使われるように
あらゆる複合インデックスを張っておこうという魂胆だろうが、
それでうまくいく場合もあれば、行かない場合もある。
この場合は12通りのインデックスになる。

しかし、無闇にインデックスを増やすことで
MySQLが使用するインデックスの決定に失敗して効率が落ちる場合もあるし、
分散が少ないフィールドは変にインデックスを使わないほうが速い場合もある。
あるいはテンポラリを避けるため、問い合わせを複数に分けなければならないかも知れない。
書き込みパフォーマンスも悪化する。

一つ一つのクエリについて、論理的に考え、テストしながら張り方を考えるべきです。
考え方が逆なんだ。

>>212
どうもありがとうございます。

「あらゆる引き方でインデックスが使われるように」というより、値段以外のフィールドの
組み合わせは一意じゃなきゃいけないので、複合プライマリーキーにしようと思ったんですけど、
UNIQUEインデックスとかの方がいいんですか？

検索は銘柄ID・時刻の組み合わせ＋フェーズ値が最大、というクエリーがメインだと思います。
通常は最新のデータしか興味がないので。

>>216
あ、他にif文とかがあるのです。
何が間違ってるんだろう…

MySQLを最大5億件のレコードを扱うことを予定しているのですが、
こんな大量のレコードを扱っている人いますか？
インデックス付けても、検索が遅くて使い物にならないか懸念しています。

Googleなどが、MySQLを使っているのは知っていますが、
Googleの場合はMySQLの内部コードをいじっていると聞いています。
私の場合、そこまでの技術力はないので、そのまま使います。

ちなみに、InnoDBです。アドバイスよろしくお願いします。

恐らく無理。というか、データ捏造してやってみれ。
差し支えなければ、何を扱ってそんなデータ量になるのかちょっとｋｗｓｋ

ああ、ちなみに、無理っていうか、MySQLだけの問題じゃ済まない規模だから
難しいという意味に修正してくだしあ。色々と検証すべきポイントがあると思う。

>>221>>222
アドバイスありがとうございます。

>差し支えなければ、何を扱ってそんなデータ量になるのかちょっとｋｗｓｋ
クライアントが某研究機関(といってもスパコンを使うような規模じゃなくて、規模は中小)で、
実験データを処理するために使うとのこと。

そのための支援プログラムを作っているのですが、
5億件入ったデータにUPDATEをガリガリ掛ける処理です。

本当はメモリー上でやりたいのですが、さすがにメモリーオーバーです。
で、DBを使ってというところなのですが・・・

難しいというのは、例えばMySQLでtmporaryテーブルを作られてしまった時に、
メモリーオーバーになるとかそういうことでしょうか？

>>223
処理時間をあまり気にしなくていいローカルアプリケーションなんでしょ？
だったら実装次第でなんとかなるんじゃないかな？
まさかWEBアプリのリアルタイム処理の話じゃないよね？

>>224
そんな感じっぽいですな。十分なメモリ（2GBもあれば）と、
高速なディスクがあれば行けるような希ガス。

DBぶん回しつつバックアップどうすんだとかそういう
余計なことまで考えてしまったｗ

何時間以内にどれだけのデータ処理を必要としてるのかとか、
そこら辺の要件を詰めてサイジングすればいいのでわ・・・

>>224>>225
レス色々ありがとうございます。
そうですローカルです。バッチ処理みたいなイメージです。
なので、一度動かしたら、結果が数日後になるようなイメージです。

以前の話ですが、innoDBで700万件が入ったテーブルにUPDATEやらINSERT処理やら
やっていたところ、突然クラッシュしてデータを持って行かれました。

なので、今回も5億件が入ったテーブルでクラッシュされたり、
インデックスを張っているにも関わらず遅すぎると困るかなぁと思っています。

とりあえず、アドバイス通りダミーの5億件を作ってやってみます。
ただ、もし5億程度の件数を処理した経験がある方がいらっしゃいましたら、
クラッシュの経験とか教えて下さると助かります。
5億とまでいかなくても1億件でもいいです。

処理時間は、ある程度待ってもらえるそうです。
パソコンは数台用意して下さるそうなので、
計算している間に他の計算をしていたりするそうです。

そのクラッシュの原因がMySQLのせいなのか
ファイルシステムの問題だったのかわからないけど，
念のため一方向レプリケーションしておくとかで
バックアップ代りにならないかな？

バックアップ目的ではないけど，
Facebook では巨大なデータベースを
西海岸側と東海岸側でレプリケーションしているみたいだよ．
http://www.sqlplex.com/articles/mysql/announcements/keeping-up-facebook-scaling-and-replication-with-mysql.html
ちょっと作りこみは入ってるみたいだけど．

>>227
レプリケーションいいね。ちょっと、それも組んでみる。

ちなみに、以前クラッシュした時のログが残っているから、一応貼っときます。
自分にとっては意味がないけど・・・。突然クラッシュして、起動にも失敗するようになり、
セーフモードで起動して、そのテーブルをdropして回復した。結局700万件のデータはパーになった。
InnoDBだから、テーブルの安全性には信頼を置いていたんだが。
趣味だからよかったけど(バックアップもあったし)、業務なら辛い。数時間停止したらクレーム対応が辛い。

071102 9:58:29 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
071102 9:58:30 InnoDB: ERROR: We were only able to scan the log up to
InnoDB: 12 1142088704, but a checkpoint was at 12 1142088979.
InnoDB: It is possible that the database is now corrupt!
071102 9:58:31 InnoDB: Error: page 2 log sequence number 12 1167329819
InnoDB: is in the future! Current system log sequence number 12 1142088979.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB:http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: for more information.

原因わかります？

ローカルならロック機構とかいらねぇし、大抵MyISAMのほうがいいんじゃないの？
インデックスをきちんと張って、メモリが足りてれば捌ける。問題なし。

うちの会社ではMySQL4を改造してパラレル化してン100億レコード突っ込んでるけど、
ディスクエラーが出るなんつーことはない。他に原因があるはずだ。

億単位のレコードのレプリケーションはお勧めしない。
時間がかかるし、レプリケーションが壊れたときの復旧や増築が大変すぎる。
全部ダンプする羽目になるんだぜ？
MyISAMにしてファイルコピーのほうが楽。

がりがりアップデートするのにMyISAM?

>>231
だめな理由をどうぞ

バッチなら問題ないかも。すまん。
ユーザのアクションに対して書き込むようなのだと、待ちが頻発して面倒だったんだ。
あと、concurrent_insertsがfixedじゃないと駄目な気がしてた。違ったけど。
dynamicだとoptimizeが大変だなーとか、そんな程度。

すいません。

リレーションを組む必要ってあるのでしょうか。
JOINで対応することは設計する上では煩雑となるのでしょうか。

>>237 要件に合わせて好きにしれ。拡張性、保守性なんかも考えてね。

ヒント
・使われるインデックスは1テーブルにつき1つだけ
・一対多の結合
・矛盾の判定

>>246
有り難う御座います。英語のマニュアルは読んでいません。
日本語のマニュアルはWebのは見ました。
tableを触らないものでは更新されないよ、という意味でしょうか？

ただ、解決しました。大変申し訳ありません。
プログラムが漏れてました。ホントすみません m(_ _)m