【データベースのパフォーマンス】1億件近いデータベースに対して分析処理をするのに、個人レベルで最速の処理をしようとすると、どのようなソリューションが適切ですか？

Question

sakata0819

31

30もっと見る

440pt

コンピュータ科学・統計資料

【データベースのパフォーマンス】1億件近いデータベースに対して分析処理をするのに、個人レベルで最速の処理をしようとすると、どのようなソリューションが適切ですか？

1億件(40GB以上)が入っているテーブルに対して、参照及び更新の処理をしようと考えています。
現状、MySQL5.1＋SATA HDD(7200rpm)をRAID0+1で構築＋Windows XP＋3GB memoryの構成で処理しています。

現状、処理を実行すると、相当遅くなります。インデックスが効かない処理もありますので、莫大な時間が掛かります。

多角的に分析したいので、なるべく短時間に1億件の分析が終わると大変助かります。
個人レベル(コストは30万以下、最大でも50万以下)で、もっとも早く処理ができる方法論をアドバイス頂けると大変助かります。

ちなみに、Windows以外ではLinuxとFreeBSDが使えます。

宜しくお願いします。

回答の条件

1人2回まで

登録：2009/05/25 10:20:02
終了：2009/06/01 01:44:47

※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

No.1

kn196729153012009/05/25 22:30:25

150pt

■ＯＳ

WindowsXPのままであれば実質、ファイルキャッシュの調整くらいしか出来ないので

Linux or FreeBSDでMySQLを動作させるのに必要最低限の構成でセットアップする。

32bit よりも 64bitのほうが望ましい。

セキュリティソフトやネットワークも邪魔になるのでスタンドアローンで動作させるのが望ましい。

■ＭｙＳＱＬ

テーブルは出来るだけ分けたい所。理想はファイルキャッシュに収まるサイズ。

インデックスが効かない処理に合わせられないか、非正規化はどうかなど再考。

エンジンはトランザクション不要であるならばMyISAMを選択。

InnoDBよりもMyISAMのほうがデータ容量を半減できるのでディスクアクセスの面でも有利。

あとはファイルキャッシュやソートキャッシュなどは極力大きく取り、ログは最低限だけ出力。

etc・・・細かくは下記などを参照。

MySQL :: MySQL 5.1 リファレンスマニュアル :: 6 最適化

■ハードディスク

OS用HDD１台　＋ DB用高速SSD１台

（PCI-Express接続の超高速SSDもあるけど高価なのでSATA接続のSSD）

■CPU、メモリ、ビデオカード

Core i7

メモリはトリプルチャネルで詰めるだけ

メモリのパフォーマンスを確保したいのでチップセット内臓ビデオではなく別付けとする。

以上、とりあえず費用は最小限。最初の回答として、たたき台としてお使いください。

※ コメント欄開いていれば、コメント欄に書いたのだけど開いてなかったので回答で失礼。

詳しいご説明どうもありがとうございます。

昔は、パソコン雑誌を頻繁に買っていたのですが、今仕事が忙しくて最近の技術情報に疎くなっていますので助かります。

>32bit よりも 64bitのほうが望ましい。

メモリーの上限が実質ないので64bitを検討したいのですが、何があったときに切り分けが難しいので躊躇しています。

> InnoDBよりもMyISAMのほうがデータ容量を半減できるのでディスクアクセスの面でも有利。

> あとはファイルキャッシュやソートキャッシュなどは極力大きく取り、ログは最低限だけ出力。

データ容量を半減できるのは知りませんでした。どうもありがとうございます。

> OS用HDD１台　＋ DB用高速SSD１台

SSDとSAS(15000rpm)だとどちらが速いでしょうか？

SSDでRAIDを組んで4台くらいストライピングするというのもいいですね。

多分、自分の処理は、ディスクアクセスがネックになるので、それが一番速くする方法でしょうか。

>Core i7

申し遅れました。現在、それを積んでいます。

とても、参考になりました。ありがとうございます。

2009/05/26 00:02:35

No.3

kempe202009/05/27 08:29:26

30pt

1台でやろうとせず、複数台で構成された Hadoop と HBase に移して処理してみてはいかがでしょうか？

http://codezine.jp/article/detail/2448?p=1

ありがとうございますた。ただ、少し大がかりのような気がします。

2009/06/01 01:43:29

No.4

我意亜922009/05/28 00:55:10

30pt

これからアプリを組むのならこんなのもアリでしょうか。

amazonが提供するクラウドを利用するものです。

使ったCPU時間分の課金になります。

なので、解析処理をする頻度によっては割高になってしまうと思います。

http://kzk9.net/blog/2009/04/reviewing_amazon_elastic_map_reduce...

面白そうですね。個人でもこのようなシステムが使えるようになったのですね。参考になります。

2009/06/01 01:43:00

No.5

QuestR2435132009/05/30 18:14:17

30pt

＞1億件(40GB以上)が入っているテーブル

１テーブルになってるものを10テーブルに単純に分ける。

これに伴い、現状の処理を書き換えないと駄目ですが、

確実に早くなります。

予算があるのなら、MySQL5.1からORACLEに変えたほうがやっぱり早いです。

ありがとうございます。

2009/06/01 01:44:09

kn1967 2009/05/25 23:53:17

IMEのユーザー辞書機能切ってた・・・汗;

詰める　→　積める
内臓　→　内蔵

ついでに　SSDの価格
OCZ
http://kakaku.com/pc/ssd/ma_1781/
http://kakaku.com/item/K0000032747/
　　OCZSSDPCIE-1ZDRV250G \188,469 これはさすがにねぇ。
http://kakaku.com/spec/K0000030168/
　　OCZSSD2-1VTXA120G ¥66,800 このあたりが限度かな。

PhotoFast　価格は似たようなものだけど入手性ならコッチかな？
http://kakaku.com/pc/ssd/ma_2268/
kn1967 2009/05/26 00:50:13

SSD と SAS の比較は難しいと思う。
実績として、既存の技術の延長であるSASに軍配をあげたいところだけれども
SSD の発展スピードのほうが速そうなので、こちらに期待。

他の見解もあることでしょうから、ひとまず引っ込みます。
きあ 2009/05/26 13:33:47

ソリューションについてではないのでコメントにします。

ハード面での強化って限度がありますし、いっそのことプログラムからテーブル作ってはどうですか？

多角的に解析するとありますが、それぞれの分析に対して必要なデータというのは限られるはず。
日・月・年ごとにまとめたデータを別テーブルに書き込むするプログラムを用意すれば分析を行う際に使用するレコード数が減りますよね。

例
10年間を年度毎に取得する場合、年毎まとめテーブルを使用する。
→処理するレコード数は10
上記を日毎まとめテーブルから出す。
→処理するレコード数は3650ぐらいになる。
上記を入力した元データから行うとなるとかなり違いが出るわけです。

自動で行うにしても手動で行うにしても、この作業を挟めるのならば分析時の効率は非常に高くなります。

元のテーブルを更新したのち、必ずまとめテーブルに書き込む必要ありますけど。
売上など、過去データの更新が基本的にないテーブルには有効な手段です。
常に変化する顧客情報のテーブルなどではちょっと難しいです。

すでにやってるかもしれませんが。
kn1967 2009/05/27 14:07:54

＞Hadoop と HBase

今件はデータ分析のためのシステムのようなのですが
Web系から生まれてきた分散処理システムがどのように有用なのか興味ありますね。

分散処理のために発生する動作コストを加味しても処理時間短縮になるのでしょうか。
個人レベルですから多くてもパソコンは数台ですし
そもそも分散処理できるようなデータであれば最初から処理を分けて各パソコンで実行し
最後にマージするのが一番早いと思いますしね。

どのような利点があるのか知りたいですね。

お教えいただければ、後ほど私からもポイント送らせていただきます。
hijk07 2009/05/27 16:01:54

（はてなにより削除しました）
kn1967 2009/05/27 16:56:02

MySQL のマルチコア対応ねぇ。そこだけ見るか？
ランダムアクセスってランダムライトの事でもいいたいのかな？
内臓・・・確かに気色悪い（苦笑）

ツッコミなら、もっとしっかりツッコンで欲しいところだが残念。
hijk07 2009/05/28 15:10:34

（はてなにより削除しました）
kempe 2009/05/29 01:07:35

>どのような利点があるのか知りたいですね。
データが存在しているその場所で処理し、マージ可能な計算結果だけをネットワーク上で送るということが、現在の分散処理の流行と言えます。データを一箇所に集める速度と1つの処理の計算速度を追い求めるのではなく、できるだけ並列に、かつ通信(やり取り)は最小限にすることで、大量データを処理します。
Java のオンメモリ・グリッドなら Coherence とかが該当しますし、データベース専用ストレージのお化け(Where句を解釈するストレージ・マネージャ)で実現しているのが Exadata になります(両方オラクルで有償だから回答には直接役には立たず・・・すいません)。

人力検索はてなコメントに、言い訳や、質問者や回答者の批.. 2009-05-27 18:46:07
人力検索はてな pahooが異なるidを使って荒らしを続けてい.. 2009-09-02 19:46:49

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

リクエスト送信済

回答リクエストを送信したユーザーはいません

karla · Accepted Answer · 2009-05-26T12:17:00+09:00

まず重要なのは何がボトルネックになっているのか？です。

これが明確にならないと最小の投資で最大の効果は得られません。

過去に似たような事を試した時には、ディスクと解析処理がボトルネックになったため下記の対策をしました。

一時的な処理向けですので日々の運用には向いていません。

OSはLinuxを使用
64bit版のOSを使い搭載メモリを増やす
RAMDISKにデータを全て載せHDDへのアクセスを減らす
解析処理自体の見直し（それなりに効果あり）
ログ出力停止
ext3にnoatimeの設定

また、プライオリティは下がりますが

HDDのストライピング
WriteCacheが使えるHDD,RAIDカードを利用

といった対応も考えられます。

最後に解析処理の見直しは効果がありました。

具体的には

処理の順番変更（A-B-CをA-C-Bなど）
クエリーの見直し（Explainを見ながらボトルネックを削減）
前処理の実施（スクリプト等で事前にデータを加工）

といったような内容です。

karla · Accepted Answer · 2009-05-26T12:17:00+09:00

まず重要なのは何がボトルネックになっているのか？です。

これが明確にならないと最小の投資で最大の効果は得られません。

過去に似たような事を試した時には、ディスクと解析処理がボトルネックになったため下記の対策をしました。

一時的な処理向けですので日々の運用には向いていません。

OSはLinuxを使用
64bit版のOSを使い搭載メモリを増やす
RAMDISKにデータを全て載せHDDへのアクセスを減らす
解析処理自体の見直し（それなりに効果あり）
ログ出力停止
ext3にnoatimeの設定

また、プライオリティは下がりますが

HDDのストライピング
WriteCacheが使えるHDD,RAIDカードを利用

といった対応も考えられます。

最後に解析処理の見直しは効果がありました。

具体的には

処理の順番変更（A-B-CをA-C-Bなど）
クエリーの見直し（Explainを見ながらボトルネックを削減）
前処理の実施（スクリプト等で事前にデータを加工）

といったような内容です。

【データベースのパフォーマンス】1億件近いデータベースに対して分析処理をするのに、個人レベルで最速の処理をしようとすると、どのようなソリューションが適切ですか？

ベストアンサー

karla13042009/05/26 12:17:00

その他の回答（4件）

kn196729153012009/05/25 22:30:25

karla13042009/05/26 12:17:00ここでベストアンサー

kempe202009/05/27 08:29:26

我意亜922009/05/28 00:55:10

QuestR2435132009/05/30 18:14:17

コメント（8件)

この質問への反応（ブックマークコメント）

トラックバック