新データベースの新しい技術導入にちょいとためらいが…。
今日から3日間、都内で研修。
いつもより30分早く家を出たら、
開始1時間前に着いてしまいました(-_-
そして16時半に終了して帰宅…っと
途中で人身事故で電車がストップ(-_-#
結局いつもと同じ時間に帰宅。
最近また人身事故多いなぁ。
困ったものです。
-----
さて。
帰宅後、夕飯を食べて風呂に入り
新しいサーバのデータベース導入を進めております。
が。
技術はどんどん進歩しますねぇ。
新しいデータベースは、その技術を取り入れるかどうか
現在検討しています。
具体的には…
(専門的な話になるので、興味ない方は飛ばしてください)
---
当「The Sunday Breeze」は
MySQLというデータベースサーバを利用しています。
これは開設当時から。そのころはまだヴァージョン3.2とかそれくらい。
MySQLの中で使えるデータベースエンジンは
MyISAMというのが主流でした。(というかそれしかなかったという記憶)
ヴァージョン4くらいからでしたかね(曖昧)。
InnoBase(現在のInnoDB)という新しいエンジンが導入されましたが
当時はまあ…使えるものではありませんでした。
(遅い、メモリ食う、メンテナンスが大変、など)
なので、InnoDBエンジンが新たに組み込まれても
「The Sunday Breeze」では、MyISAMエンジンを継続して使用してきました。
が。
最新版のMySQLはリリース版ヴァージョン5.6。
今ではInnoDBがデフォルトのデータベースエンジンとなり
そして巷の評判ではかなりの改善が図られた模様。
メモリもだいぶ少量で稼動が可能らしいし
スピードもMyISAMエンジンと遜色ないくらいまで向上した…らしいと。
新たに64ビットサーバを導入するにあたり
これまで使用してきたMyISAMエンジンからInnoDBエンジンへ
切り替えようかどうしようか…。
管理人が一番気にしている部分は
トランザクションの遅延がどの程度なのか(即時コミットってあるんだっけ？)ってのと
テーブルごとに物理ファイル管理ができないこと。
万が一サーバが突然停止して、バックアップからリカバリしなくてはならない場合に
これまでだとバックアップファイルをコピーすればよかっただけですが
InnoDBではどうなるんだろう？
トランザクションログから戻すってどうやるんだろう？
まだまだ勉強不足で
新しくInnoDBを導入するメリットが見つからずにいます。
---
ということで、
新しい技術を導入する準備は整っているんですが
管理人の気持ちで導入をためらっております。
…かといって
長いこと考えている時間はありませぬ。
早めに結論を出して
土曜の夜か日曜の夜にはデータベースを切り替える予定でいます。
明日・明後日あたりも
このネタが続くと思います。
[コメント読む(0)]
もう年の瀬。(今週の進捗状況)
ここ１週間のサーバ作業の進捗状況でございます。
> > 血統データの取り込み
> > 相変わらず地味な作業をしています。
> > ちっとも埋まらねぇ…。
>
> あいかわらず地味です。
> ですが、素敵なツールを作ったので、
> 先週よりペースアップ！
> 今年中にはかなりの頭数の血統が埋まる予定。
> 最終的には14万頭くらいの規模になる予定。
14万頭なんて余裕だったりする・・・。
現時点でうちのでーたベースには
競走馬・種牡馬・繁殖牝馬が合計140,409頭登録されてます。
血統は
種牡馬：全7,206頭のうち、約15パーセント
繁殖牝馬：全54,775頭のうち、約10パーセント
の馬が未登録です。
現在も随時登録中。
今年中には種牡馬・繁殖牝馬とも
5パーセントくらいまでになるように、登録したいですな。
> > 南関競馬のその後
> > 前日の昼12時半に出馬表を取り込むようにしました。
> > というより血統取り込みがメイン。
> > だけど、ちゃんと取り込めてないので、毎日手作業発生中。
> > なんとかしたい。
>
> 相変わらず手作業発生中。
> だけど、素敵なツールのおかげで
> 1日10分〜15分程度で作業終了。
> まあまあいい感じ。
12時半だったのを11時に変更。
手作業は相変わらず発生中。
まあでもそんなに苦じゃない。
> > もうちょっとデータが増えたら、ちゃんとした出馬表(過去データもある)にしたい。
>
> 過去データを取り込むかなぁ、と思案中。
一応、出馬表を更新するようにしたけど、
データが少なすぎて、見れたもんじゃない。
もうちょっと時間かかるかな。
> > 払戻金を取り込みたい、と思案中。
> > だけど、テーブルの拡張など、意外とインパクトがでかいので、
> > ちょっとためらっている。
>
> テーブルの拡張は意外とすんなり。
> 後はデータをどう取得するか、を考えてます。
> 意外とあっさりできちゃうかもしれない。
>
> 払戻金を取り込めるようになったら、
> 今年分の南関競馬の全結果と払戻金を取り込みたいな、と。
特に進捗なし。
でも、今日午後ヒマなので、払戻金を取り込むように
今動いているやつを直すか、新しく取り込むプログラムを作るか、検討中。
どちらの場合も、PHPのバッチプログラム。
もうこなれたもんですわ。
> > 新しく作りたいもの(頭の中)
> > ケータイ版Sunday Breeze。
> > ケータイから競走馬検索とかレース情報とか見れたら最高でしょ。
>
> なーんもやってない。
進捗なし。
なーんもやってない。
それより、今のケータイ、910SH。
バッテリーが膨張してきてるんだけど、大丈夫かしら？
今夜やわらか銀行ショップ立ち寄り予定。
> > 南関競馬は別サイトに。
> > デザイン一緒のまま、データは地方のみのサイトを1つ作るかなぁ。
>
> 考えてはいるものの、何一つ進まず。
これねぇ。
このままでもいいか・・・と思い始めてる。
というのも、プライオリティ(優先順位)の低い希望なので。
とりあえず、血統登録とか、南関競馬のこととか、ケータイ版Sunday Breezeとか
片付いてからかなぁ。
> > そろそろサーバルームくらいはリニューアル？
> > でもいいデザイン案は浮かばず。最近Web関係も勉強を怠っているから…。
>
> やばいね。相変わらず勉強不足。
勉強不足・・・すぐには解消されないわな。
最近って、どんな技術が流行ってるんですかね？
CMSとか、既製のものを全く使わない(ポリシー)ですので、
まあ他ではない、というか、独自の何かをやりたいんですけどね。
最近、アンテナが低いので。
さて、先週末。
(最近進捗報告と併せて、週末の出来事書いてるなぁ)
特に何もしてません。
土日両日とも、家にいました。
外に出たのは、
近所の神社に行ったのと、
スーパーへ買い物に行ったのと、
タバコを買いにコンビニへ行ったくらい？
家にいて、不要PCを解体したり、
それに伴って、軽く掃除したり、
テレビ見てたり、
酒飲んでたり、
まあそんな感じでしたかね。
先週は平日、比較的忙しかったので
まあゆっくり出来てよかったかと。
あったかかったし。
中央競馬もあと2週。
有馬記念の特別登録も発表になってます。
ああ、もう年の瀬ですなぁ。
[コメント読む(0)]
テーブルの分割(昨日の続き)。
MySQLのMERGEテーブルには
primary keyが定義できないということで。
一応パフォーマンス測定はしてみたものの、
そりゃ、一意にできないんだもの。遅くなるわな。
という結果でした。
MERGEテーブル案、却下。
別な方法として、ビューを使ってみました。
分割したテーブルは昨日のまま。
結果1996〜結果2006です。
で、
create (or replace) view 結果 as
select * from 結果1996
union
select * from 結果1997
…
union
select * from 結果2006
という感じ。
「こりゃ、unionだから遅いだろ」
というのは重々承知。
実際にパフォーマンスを測ってみたら
何十倍？何百倍の違いが出ました。
しかも、
分割テーブルのcharがビューだとすべてvarcharになってるし。
intがすべて11バイトになってるし。
doubleがすべて22,1になってるし。
show create view を見たら、大変なことになってるし。
ビューはもっと賢い使い方しましょう(失)
-------------
とりあえず、今のところ
テーブルを分割することによるパフォーマンス向上は
期待できませんという結論で。
元テーブルがもっとでかかったりすれば
多少は期待できるのではないでしょうか。
ちなみに、MySQL5.1では
パーティショニングの機能が搭載されています。
が、まだ5.1系はベータ版。
実際に導入するのはもう少し時間がいるかと思われます。
[コメント読む(0)]
テーブルの分割。
「どの馬が何のレースで何着だったか」というデータを
持っているテーブルがあります。
ちょろっとみたら、50万件のデータが入ってました。
パフォーマンスも落ちてきたので、そろそろ
テーブルを分割してみようと思います。
MySQLではMERGEテーブルというのがありますので、
これを使ってみます。
元のテーブルは「結果」というテーブル。
これを
「結果1996」〜「結果2006」
という具合に、年単位で分けます。
create table 結果1996 select * from 結果 where 日付 like '1996%';
create table 結果1997 select * from 結果 where 日付 like '1997%';
…
create table 結果2006 select * from 結果 where 日付 like '2006%';
という具合に。
そして、古いテーブルは削除。
drop table 結果;
MERGEテーブルを作ります。
create table 結果 (各列の定義)
type=MERGE UNION=(結果1996,結果1997,…結果2006)
INSERT_METHOD=LAST;
これで一応完了です。
パフォーマンスを測定してみます。
…と思ったのですが。
エラーが出ちゃって、select できませんね。
Got error 124 from storage engineこれじゃわからんって。
あれこれ調べていますが、
Bug #6853とか
Bug #8053あたりが怪しそう。
英語が読めずに困っています(失)
わかり次第、ここにも書きます。
-----
意外とあっさりわかった。
MERGEテーブルのcreate table分から
primary key、indexに関する記述を抜いたら、selectできた。
そのあと、create indexを使って、INDEXを作る分には問題なし。
そのあと、alter table でprimary keyを追加したあとだと、同じエラーが出てselect できない。
要するに、
MERGEテーブルに対して、データが一意になるような設定(primary key とか unique index)をすると
Got error 124 from storage engineが返ってくる。
MySQLのマニュアルには、これしか書いていない。
--------
MERGE テーブルでは、テーブル全体で UNIQUE 制約を保持できない。
(中略)
このような方法で MERGE をテーブルを使用していると、高い確率で未知の問題が発生する。
--------
なので、今までprimary keyにしていた部分については、
indexに変更して代用するしかない？
何言ってるかわかんない？わかんないねぇ。
[コメント読む(0)]
mysql4.1と5.0でimportの時間測定。
6月21日の記事とリンクしてます。
mysql4.1にてmysqldumpで取得したファイルを
mysql5.0にimportしたときに、えらく時間がかかっていた件。
ちょっと調べてみました。
同じサーバ上で、(ほぼ)同じコンフィグオプションを使って
コンフィグ→makeしたmysqlの4.1.21と5.0.24a。
別サーバ上にある4.1.20からmysqldumpで取得したファイル(およそ65M)を
mysql -uユーザ DB名 < ファイル名
としてimport。
4.1.21では38秒。
5.0.24aでは48秒。
まあおよそ1.25倍程度でしょうか。
サーバ再構築前、
4.1.11でおよそ3分だったわけですから、
5.0系にすれば4分弱で終わるはず。。。
だったのですが。
コンフィグオプションか？ってか、5.0インストールした時に
mysql_install_dbってやったっけか？
もうちょっと調べた上で、
近日実施予定のマシンリプレースでは
5.0系を採用予定。
マシンリプレースか。
またOSから入れなおすのか。
めんどくさいな。
話は変わりますが、最近
「MySQLは有償のEnterpriseと無償のCommunity Serverに分かれる」---MySQL社長というのが発表されています。
動向に注目です。
[コメント読む(0)]
原付生活(3)