元スレMySQL 総合 Part14
mysql覧 / PC版 / みんなの評価 : ☆
前へ
203 = :
>>198
いちおう、圧縮プロトコルがあります。
http://www.mysqlperformanceblog.com/2007/12/20/large-result-sets-vs-compression-protocol/
あとはSSHで圧縮かけてフォワーディングするとか。
205 = :
MySQLの認定資格を受けようと考えているのですが、
参考書が原書（英語）しかないようです。
試験対策になりそうな日本語の書籍がありましたら教えてくれませんか。
208 :
データベースのハンドリングって何ですか？
209 = :
>>207です。自己解決しました。どうもお騒がせしました。
212 = :
実データでやってみないとわからないが、全然パフォーマンスが出ない場合もあるだろう。
おそらくあらゆる引き方でインデックスが使われるように
あらゆる複合インデックスを張っておこうという魂胆だろうが、
それでうまくいく場合もあれば、行かない場合もある。
この場合は12通りのインデックスになる。
しかし、無闇にインデックスを増やすことで
MySQLが使用するインデックスの決定に失敗して効率が落ちる場合もあるし、
分散が少ないフィールドは変にインデックスを使わないほうが速い場合もある。
あるいはテンポラリを避けるため、問い合わせを複数に分けなければならないかも知れない。
書き込みパフォーマンスも悪化する。
一つ一つのクエリについて、論理的に考え、テストしながら張り方を考えるべきです。
考え方が逆なんだ。
213 = :
>>212
どうもありがとうございます。
「あらゆる引き方でインデックスが使われるように」というより、値段以外のフィールドの
組み合わせは一意じゃなきゃいけないので、複合プライマリーキーにしようと思ったんですけど、
UNIQUEインデックスとかの方がいいんですか？
検索は銘柄ID・時刻の組み合わせ＋フェーズ値が最大、というクエリーがメインだと思います。
通常は最新のデータしか興味がないので。
217 = :
>>216
あ、他にif文とかがあるのです。
何が間違ってるんだろう…
220 :
MySQLを最大5億件のレコードを扱うことを予定しているのですが、
こんな大量のレコードを扱っている人いますか？
インデックス付けても、検索が遅くて使い物にならないか懸念しています。
Googleなどが、MySQLを使っているのは知っていますが、
Googleの場合はMySQLの内部コードをいじっていると聞いています。
私の場合、そこまでの技術力はないので、そのまま使います。
ちなみに、InnoDBです。アドバイスよろしくお願いします。
221 = :
恐らく無理。というか、データ捏造してやってみれ。
差し支えなければ、何を扱ってそんなデータ量になるのかちょっとｋｗｓｋ
222 = :
ああ、ちなみに、無理っていうか、MySQLだけの問題じゃ済まない規模だから
難しいという意味に修正してくだしあ。色々と検証すべきポイントがあると思う。
223 = 220 :
>>221>>222
アドバイスありがとうございます。
>差し支えなければ、何を扱ってそんなデータ量になるのかちょっとｋｗｓｋ
クライアントが某研究機関(といってもスパコンを使うような規模じゃなくて、規模は中小)で、
実験データを処理するために使うとのこと。
そのための支援プログラムを作っているのですが、
5億件入ったデータにUPDATEをガリガリ掛ける処理です。
本当はメモリー上でやりたいのですが、さすがにメモリーオーバーです。
で、DBを使ってというところなのですが・・・
難しいというのは、例えばMySQLでtmporaryテーブルを作られてしまった時に、
メモリーオーバーになるとかそういうことでしょうか？
224 = :
>>223
処理時間をあまり気にしなくていいローカルアプリケーションなんでしょ？
だったら実装次第でなんとかなるんじゃないかな？
まさかWEBアプリのリアルタイム処理の話じゃないよね？
225 = :
>>224
そんな感じっぽいですな。十分なメモリ（2GBもあれば）と、
高速なディスクがあれば行けるような希ガス。
DBぶん回しつつバックアップどうすんだとかそういう
余計なことまで考えてしまったｗ
何時間以内にどれだけのデータ処理を必要としてるのかとか、
そこら辺の要件を詰めてサイジングすればいいのでわ・・・
226 = 220 :
>>224>>225
レス色々ありがとうございます。
そうですローカルです。バッチ処理みたいなイメージです。
なので、一度動かしたら、結果が数日後になるようなイメージです。
以前の話ですが、innoDBで700万件が入ったテーブルにUPDATEやらINSERT処理やら
やっていたところ、突然クラッシュしてデータを持って行かれました。
なので、今回も5億件が入ったテーブルでクラッシュされたり、
インデックスを張っているにも関わらず遅すぎると困るかなぁと思っています。
とりあえず、アドバイス通りダミーの5億件を作ってやってみます。
ただ、もし5億程度の件数を処理した経験がある方がいらっしゃいましたら、
クラッシュの経験とか教えて下さると助かります。
5億とまでいかなくても1億件でもいいです。
処理時間は、ある程度待ってもらえるそうです。
パソコンは数台用意して下さるそうなので、
計算している間に他の計算をしていたりするそうです。
227 :
そのクラッシュの原因がMySQLのせいなのか
ファイルシステムの問題だったのかわからないけど，
念のため一方向レプリケーションしておくとかで
バックアップ代りにならないかな？
バックアップ目的ではないけど，
Facebook では巨大なデータベースを
西海岸側と東海岸側でレプリケーションしているみたいだよ．
http://www.sqlplex.com/articles/mysql/announcements/keeping-up-facebook-scaling-and-replication-with-mysql.html
ちょっと作りこみは入ってるみたいだけど．
229 = :
ローカルならロック機構とかいらねぇし、大抵MyISAMのほうがいいんじゃないの？
インデックスをきちんと張って、メモリが足りてれば捌ける。問題なし。
うちの会社ではMySQL4を改造してパラレル化してン100億レコード突っ込んでるけど、
ディスクエラーが出るなんつーことはない。他に原因があるはずだ。
億単位のレコードのレプリケーションはお勧めしない。
時間がかかるし、レプリケーションが壊れたときの復旧や増築が大変すぎる。
全部ダンプする羽目になるんだぜ？
MyISAMにしてファイルコピーのほうが楽。
232 = :
>>231
だめな理由をどうぞ
237 :
すいません。
リレーションを組む必要ってあるのでしょうか。
JOINで対応することは設計する上では煩雑となるのでしょうか。
238 = :
>>237 要件に合わせて好きにしれ。拡張性、保守性なんかも考えてね。
239 = :
ヒント
・使われるインデックスは1テーブルにつき1つだけ
・一対多の結合
・矛盾の判定
みんなの評価 : ☆
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part24 (1010) - [94%] - 2015/2/14 4:46
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
- MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
- MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
- MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
- MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
- MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
- MySQL 総合 Part22 (1001) - [89%] - 2012/7/10 16:45
- MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について