これは[朝信共同計算センター（開発2課）]様が[02/07/03 13:47:44]に送信された、
　[[mysql 05713] ２億レコード以上のデータ検索の可・不可について]への返信です。
〆￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
どもです。kitajimaです。
うちでは6000万〜1億レコードの検索をOracleでしています。DBは30GB程度ですが。
研究としてフリーのRDBMSでも運用可能かとMySQLもテストしてみましたが、
相変わらずMySQLは一瞬〜数秒で検索できました。
まぁ、クエリーの内容とキャッシュメモリー量によるんでしょうけど。
パフォーマンスチューニングをしっかりやれば大丈夫かと…。っていっても、
MySQLはOracleほどチューニングするところ無いですけどね。

あとは工夫次第です。例えば年単位でテーブルを分けるなどすると、
一度に数億のレコードを検索する必要がなくなります。（年をまたいだ検索が
めんどうになるけど）ニーズ的には東北・関東・関西などでテーブルを分ける
方がいいかも？でも関東ばかり太りそう。要はDB設計です。

私の経験ですが、DBファイルサイズが4Gを超えたあたりで、なんか検索スピードが
落ちた気がします。
ファイルを4GB単位で分割するようにするとスピードが回復しました。
OSと関係があるのかな？


経験不足なのに、でかい仕事任されましたね。頑張ってください。
私もRDBMSって何？って所から初めた頃を思い出します。


朝信共同計算センター（開発2課）> 　先ほどは、メールリスト本体にコマンドを送ってしまい、ご迷惑をお掛けしまし
朝信共同計算センター（開発2課）> た。メーリングリストは初めてなもので＾＾；
朝信共同計算センター（開発2課）> 　以後、気を付けます。
朝信共同計算センター（開発2課）> 
朝信共同計算センター（開発2課）> 　自分は、銀行のオンラインシステム管理の仕事を任されている松田　高志と申しま
朝信共同計算センター（開発2課）> す。
朝信共同計算センター（開発2課）> 　この都度、顧客の取引履歴を検索するシステムを専用線のオンラインから、ＶＰＮ
朝信共同計算センター（開発2課）> を利用してＷｅｂ上で展開する仕事を任される事になりました。
朝信共同計算センター（開発2課）> 　そこで、膨大な取引履歴データを照会するのに利用するデータベースアプリケー
朝信共同計算センター（開発2課）> ションの検証が必要になり、とにかく資料を集める事と相成りました。
朝信共同計算センター（開発2課）> 　（それまでは、MS-ACCESSしか利用した事がありませんでした。）
朝信共同計算センター（開発2課）> 　高速な検索が出来るMySQLの話を聞き、ぜひ質問がしたく、今回メールを送らせて
朝信共同計算センター（開発2課）> いただきました。
朝信共同計算センター（開発2課）> 　短刀直入に言いますと、ざっと２億レコード以上（１レコード４５０バイト）、大
朝信共同計算センター（開発2課）> 体１００ＧＢ以上のデータを扱えるのかと、またそのデータの検索に掛かる時間が知
朝信共同計算センター（開発2課）> りたいのです。
朝信共同計算センター（開発2課）> 　検索条件としては、「”松田　高志”の１９８０年４月１日から１９８１年３月３
朝信共同計算センター（開発2課）> １日までの取引履歴」みたいな感じで、特に複雑な条件式は用いりません。
朝信共同計算センター（開発2課）> 　もちろん、自身の手で検証は行う予定ですが、後１ヶ月後に方針の決定を行わなけ
朝信共同計算センター（開発2課）> ればならず、それまでに利用方法を学習し、検証を行うのは難しいと感じ、質問をし
朝信共同計算センター（開発2課）> た次第です。
朝信共同計算センター（開発2課）> 　経験上からくる大体の概算で構いません。
朝信共同計算センター（開発2課）> 　どうかよろしくお願いいたします。


Kitajima. kitajima@xxxxxxxxxx
━━━━────────────────────────────