システムアーキテクト通訳案内士のブログ

台北旅行の続きです。 MRTの忠孝新生駅にある光華数位新天地に行ってまいりました。このあたりは台北の秋葉原といいた感じでパソコンショップが軒を連ねています。 　 　 光華数位新天地は、さしずめ秋葉原のヨドバシカメラのような感じの大きなビルですが、その中に小さなショップが入っています。 あいにく時間があまり無かったのでざっと回っただけになりましたが、値段は、円高の今をもってしても、残念ながらあまり安いという印象は無かったです。2GのSO-DIMMが1500円程度とかモノによっては安いものもありますが・・・。 それでも、せっかくなので低価格のノートPCとネットブックに焦点を当てて探してみました。メーカーは、Lenovo MSI ASUS 東芝が目に付きました。また意識してみていたわけではないので、一概にはいえないのですが、mac（ipad）があまり目に付かなかったので日本ほどブームになっていないのかもしれません。売れ筋はネットブックとそれより少し上のノートブックのようでした。 ちょっと戸惑ったのが商品に値札が貼っていなくお店に人に値段を聞くスタイルのお店が割と多かったです。特にネットブックに多かったのです。 どうやらそこから値引き交渉するようですが、私は20年程前に京都に暮らしていたときは、大阪の日本橋で値引きをしたのですが、17程前に東京へ来て秋葉原で値引きをして店員さんに嫌われて以来、値札で買うという習慣がついてしまったので、久しぶりのことで戸惑いました。それと言葉の壁もあいまってあまり買い物を楽しむということはできませんでした。まぁ次回にリベンジしたいです。 　 それでも、一応台北のパソコンショップをコンプリートしたく、台北駅にあるNOVA資訊広場にも寄ってみましたところ、GIGABYTE社のT1028が2Gバイトのメモリ付きで10,500元（約3万円ちょっと）で売っていたので買ってみました。日本ではもう終息したようですがPC Hotlineによると2009年6月で約6万円で売っていたようです。巷ではiPhoneやiPadが流行っておりネットブックは流行遅れになったので値崩れを起こしたのでしょうか、1年半で半額とは価格の下落が大きいです。 以下スペックを 　 ■スペック ATOM N280 1.66GHz メモリ 2GB HDD 250GB 解像度 1024×600 OS Windows7 Startar（32ビット） 　 液晶部が回転するので、タブレットPCにもなる。キーピッチが少し狭い程度でタイプはしやすい。好みもあるかと思うが、ASUSとかAcerとかのネットブックと比べてもキーボードの作りは良いかと思います。 残念なのがディスプレイの解像度が1024×600と低い点で、上位モデル（T1028X)で1366×768のものもあります。こちらを使ってみたい気もしますが、最近、眼精疲労に悩まされているので、私としてはこれ以上、ドットピッチが細かくなると目に悪いので、割り切って使う分にはよいかもしれない。実際、IEを全画面表示で使うとか工夫していますが、あまり不自由は感じていないです。 　 ■エクスペリエンスインデックス プロセッサ 2.4 メモリ 4.6 グラフィックス 2.4 ゲーム用グラフィックス 3.0 プライマリハードディスク 5.7 CPUとグラフィックのスコアが悪いがモバゲーのガンダムブラウザウォーズをする分には問題ない程度です（少し遅い程度）。もちろん普通にブラウザを使っている分にもあまり困らない。 キーボードは、中国語の刻印があり、来るべき時代に対応できそうです（って中国語はまったくできないのだが・・・）。キーボードの写真を載せますがパット見た感じ日本語のような雰囲気があります。 今まで使っていたノートPCはB5といえども大きくかつバッテリーが1時間持たなかったので持ち歩いていませんでしたが、T1028はバッテリーが4時間持つので、これと光ポータブルとイーモバイルに入り、外出先から会社のメールが受信できるようになり、遅ればせながら私のモバイル環境も充実してきました。 ちなみに、GIGABYTE自体は日本にも代理店があるようですが修理となると直接台湾のサポートにアクセスしないとダメなようで、値段のことを考えてもあまり海外でパソコンを買うのはお勧めしません。今回は、まぁ私の自己満足のレポートということで・・・

年明けからいろいろネタがあったので後回しになりましたが、最近ですが、ちょいと台北（台湾）へ行ってまいりました。 　 ブログをやっているのと一応通訳案内士を目指している関係で、旅行記事でも書いてみます（と命令されました）。まぁこういう記事は慣れていないので、その点はご了承下さいませ。 　 ■ 台北（台湾）

• 国　　中華民国
• 首都　台北
• 通貨　台湾元（2011年1月で、ざっくりしたレートは1台湾元=3円）
• 時差　1時間（日本の方が進んでいる）
• アクセス　羽田空港から台北（松山空港）へ行きは約4時間帰りは、約3時間
• 台北の交通　
• 国鉄以外にも、地下鉄（MRT)があり、乗り換えに気をつけないといけないが、市内を便利に行き来ができる

　 ■ 訪ねたところ

• 故宮博物館
• 九分と金瓜石黄金博物園
• 夜市（士林、饒河夜市）
• 光華数位新天地（パソコン関係のショップが集まるビル）

　 ■ 故宮博物館 　詳しくは他に譲りますが、世界四大博物館の１つといわれている博物館、台湾にあるが中国の各王朝の美術品が見られる。かなり大きな博物館で11:00～17:00とたっぷり６時間にわたって中国4千年の歴史を堪能しました。 行った時が悪かったのか、中国本土（？）の博物館なのであまりないのか不明ですが、台湾自体の展示物が少なかったのが残念でした。 博物館とは関係ないのですが、帰りにお茶屋さんに遭遇し『お茶を飲ませる。送って行く。』といわれてそのままお茶屋さんに行きました。そこで阿里山というお茶を試飲し、買いました。大変おいしかったので私にとっては買う価値があるかと思うのですが、それなりに高いお茶なので、こういう商法がおきにめさない方は最初のお誘いから断った方がよろしいかもしれません。（繰り返しになりますが、味は大変おいしいのとおそらく日本で買うよりも安い（100g 800元 - 2,400円）ので、買い物としては悪くはないかと思います。） 　 ■九分と金瓜石黄金博物園 　九分といえば、『千と千尋の神隠し』のモデルと言われている、確かにそんな雰囲気を持った町でした。長い商店街のある町でそれなりに楽しめそうでしたがあいにくの雨で残念でした。

金瓜石黄金博物園ですが、日本の統治時代から続いた金山の跡地で、日本の宿舎や鉱山を見物してきました。 これまた、金瓜石とは関係ないですが、トイレ休憩の時に大きな像が見えたので「あれは何？」とガイドさんに尋ねたら関羽さんとのことで、記念に一枚撮っときました。 　 ■夜市 　夕食は夜市で食べました。台北には夜市と呼ばれる屋台村のようなところがいくつかあり、士林と饒河夜市で食べました。士林の方は１箇所のフードセンターに各お店が入っており、饒河夜市の方は道路に露店が出ているようです。大雑把に言えば中華料理なのですが、私は士林の夜市のはずれのお店で食べたチャーハンが気に入りました。 ■その他 　台湾の方から見れば私は同族か中国本土の人のように見えるらしく、よく中国語で話かけられました。もっとも観光客は日本人より中国人の方が多いようなのでそのせいかもしれません。 あまりにも中国語で話しかけられるので、最後の方は『I am Japanese.』が口癖になりましたが、皆さん悲しそうな顔をされたので、次はもう少しなにかしゃべれるようにと（一瞬）思いました。

Windows7,2008R2に引き続き、これまた1年越しの作業になりましたが、我がohfuji.nameをホストするマシンをOpenBlockS 600（正確にはOpenBlockS 600D相当）に置き換えました。 　 OpenBlockS 600とは、ぷらっとホーム社さんが製造・販売しているマイクロサーバーで、こちらが製品情報になります。ちなみに2月現在キャンペーンをやっておられます。 　 OpenBlockS 600自体の解説はいろいろな場所で行われているので、そちらにおまかせしますが、特質すべきは、抜群の低消費電力で、私がエコワットで測定した結果は9Wでした。またファンレスでストレージはコンパクトフラッシュを使うので音が出なくてかつ障害に強く、商業利用はもちろん、自宅サーバーとしても重宝するかと思います。 　 OSですが、OpenBlockS 600はSSD Linuxがプリインストールされています。また600DはDebianがプリインストールされています。メモリは1GB積んでいますのでDNSサーバーやメールサーバーとしては申し分ないスペックです。 難点が、CPUにPOWER-PCを使用しているところで、私のようなプログラミングをする人間にとっては開発環境を別途用意しないといけないのと、さらにそのCPUの動作周波数が600MHzとお世辞にも速いと言えないところで、Apacheで静的なページを運用するならともかく動的なページは難があるかと思います。特に普通のサーバーでも重たいWordpressをOpenBlockS 600で運用するのは厳しいかと思います。 　 では、このブログ（Wordpressなんですが・・）はどうしているのかと言いますと、このページはADPで作成したブログビューアーで表示しています。我がADPもOpen BlockS 600Dに移植しまして、このとおり動作しておる次第です。このページを頻繁に訪問される方は気がついておられたかと思いますが、最近Wordpressが重くなっていたので、どげんかせんといかんと思っておったところです。このような厳しい条件を克服するのはソフトウェアエンジニアとしてロマンを感じたりします。 しばらく運用してみてOKであれば、OpenBlockS 600D版のADPと共にブログビューアー（Adp WorPdress bLOG viewer － AWPLOG)のソースを公開しようかと思っております。 2011/06/23 追記：節電の為、自宅サーバー類は仮想マシンとして別のサーバーに集約しましたので、現在このサーバーはOpenBlocks 600D上では動作していません。

Kernel-Power 41病というのは、Windows 7に特有の現象で、突然PCが再起動しイベントビューアにID:41の『システムは正常にシャットダウンする前に再起動しました。』というログがはかれる現象を指します。 　 私はWindows7を使いだしてから1年になるのですが、それまではKernel-Power 41病というのがあるとは知らなかった（つまりブルースクリーンやら突然のリセットを見ていなかった）。 社内のPCをWindows7に入れ替えた後、社長のPC（自作機）が、たまに（2，3日に一度）リセットがかかり、いろいろ調べた結果、結構有名であることを知る。 　 一応マイクロソフト社さんのWEBページでサポート情報が上がっています。 　 社長のPCは、当初、シナリオ１でグラフィックドライバの不具合のような振る舞いをみせましたが、グラフィックカードを換えると、今度はシナリオ３の現象が発生しました。 ネットを検索しますと省電力機能の不具合により電力不足が発生することが原因らしいとのことで、それならと電源を換えて、メモリとグラフィックカードの端子を接点復活剤を使って掃除したところ、それから1週間経ちますが Kernel-Power41は発生しなくなりました。 電源を安物から少し良いものに換えたのでこれがあやしいのですが、ただ、現在その電源は私が使っているPC（これも自作）で使用していますがKernel-Power41は発生していませんので、接点復活剤の可能性もあります。今まで接点復活剤は気休めに使っていてあまり効果を実感したことがないのですが、今回は役にたったかもしれません。 巷では、省電力設定を無効にする（プロセッサの電源管理、最小のプロセッサの状態を100%にする。USBの省電力設定を無効にするとか）が有効らしいですが、それでもダメな方や省電力設定を切りたくないかたは、成功したらラッキー程度にご参考にして頂ければと思います（もちろん自己責任で）。

以前に書いたこの記事に関してコメントをもらいちょうど記事にしようかと思っていたところでしたので、ADPのキャッシュ機能を使い、この記事の実験をADPでやったらどうなるかみてみます。 　 SQLでjoin（結合）と言えばSQLに慣れた方にとっては馴染み深いものですが、初心者にとっては一種の登竜門のようで、joinを避けたコードを見かけたりすることがあります（まぁ私も十数年前にはこのような理由でjoinを避けたコードを書いた記憶があります）。また、O/Rマッパーではテーブル毎にクラスを対応させる関係で、joinの取扱がややこしかったりします。 それ以外でも、私の場合になりますが、過去にパフォーマンス上の理由からjoinを行わなかったことがあります。 今回は、前回の実験と同様に ・SQLでjoinさせる。 ・ADPでjoinさせる。 でパフォーマンスの違いについていくつかの実験を行い計測します。

実験環境

JOINのパフォーマンス実験環境はこちらに記述しています。 　

実験１ 素直にSQL側でjoinをさせたものを実行

例により、SQLで素直にjoinさせてみます。以下のようなコードになります。

,$db = "DSN=Trade"
,$str = "SELECT Price.CODE, RDATE, OPEN, CLOSE, NAME FROM Price "
        "INNER JOIN Company ON (Price.CODE = Company.CODE)"
,sql@($db,$str,[]).csv.prtn,next;

　 少しコードの説明を、 1行目の、$db=～ の部分は、ODBCの接続文字列を指定します。上記のコードは、ODBCのデータソース名Tradeを指定している接続文字列になっています。 2,3行目の、$strの部分はSQL文を変数$strに代入しています。本来は1行で書けますが、wordpressで見やすいように2行で書いています。 4行目の ,sql@($db,$str,[]).csv.prtn,next; sqlは組み込みの述語で、「ODBC-APIを使いsqlを実行し、結果を配列(@)で受け取り、csvに変換し、prtnで画面に出力し、nextで全ての結果を出力する」というコードになります。 自画自賛になりますが、必要最低限の情報だけで簡単にSQLが発行できているので、ADPの開発目標の一つである「SQLとの親和性が高い言語を目指す」を具現している例だと思います。 　 実行時間ですが、

D:\>adp -t sql_test_1.p > sql_test1.txt
time is 119192ms.

　 で、約119秒となりました。 　

実験２-Ａ ADP側でjoin(ネステッドループ）

続いて、ADP側でネステッドループjoinさせてみましょう。 　

,$db = "DSN=Trade"
,$price = "SELECT CODE,RDATE,OPEN,CLOSE FROM Price"
,$company = "SELECT NAME FROM Company WHERE CODE = ?"
,sql( $db, $price, [], @rec)
 ,sql( $db,$company, [$rec[0]], $name)
  ,csv($rec,$name).prtn,next;

　 ADPのDBライブラリは、前に紹介しましたODBCライブラリがベースになっていますので、ODBCのパラメータクエリが使えます。 5行目のコードがパラメータクエリを使っています。 実行時間ですが、

D:\>adp -t sql_test_2.p > sql_test2.txt
time is 1717284ms.

　 で、約1717秒となりました。実験１と比べて約14倍の実行時間です。 　

実験２-Ｂ ADP側でjoin(ネステッドループ＆キャッシュ）

さらに続いて、ネステッドループjoinをADPのキャッシュ機能を使って高速化をはかります。 　

,$db = "DSN=Trade"
,$price = "SELECT CODE,RDATE,OPEN,CLOSE FROM Price"
,$company = "SELECT NAME FROM Company WHERE CODE = ?"
,sql( $db, $price, [], @rec)
 ,sql$( $db,$company, [$rec[0]], $name)
  ,csv($rec,$name).prtn,next;

　 呼び出し述語名の後ろに$をつければキャッシュ機能がONになります。上記のコードでは5行目の sql$ がキャッシュ機能を使用しています。 では、実行時間をみてみましょう。 　

D:\>adp -t sql_test_2.p > sql_test2.txt
time is 116770ms.

　 で、約117秒となりました。 実験２－Aと比べるとかなり高速化がはかられたかと思います。キャッシュのこのような使い方は、かなり有効だとうことが解るかと思います。繰り返しになりますが、ADPならお手軽にキャッシュ機能を使うことができます。

実験３ ADP側でjoin(事前にマップ作成）

ちなみに、ADPでも事前にマップを作成し、joinを行うことができます。 以下、コード例です。

,$db = "DSN=Trade"
,@tbl = {}
,sql($db, "SELECT CODE,NAME FROM Company",[], @r)
 ,@tbl = @tbl + [ $r["CODE"] | $r["NAME"] ]
 ,next
,sql($db, "SELECT CODE,RDATE,OPEN,CLOSE FROM Price",[],@rec)
 ,$key == $rec["CODE"].str
 ,csv($rec,$tbl[$key]).printn,next;

　 前回の記事ではC++でハッシュjoinを行うと書いたので『ハッシュJOINを言語で再開発するのは非効率』とコメントをもらいました。 コードを良く読んで頂ければ解るかと思いますが、実はC++の例でもjoin自体はプログラミング言語（ライブラリ）の機能を使っており、取り立てて複雑なことはしていません。　 やっていることを説明しますと、マスターテーブル用のマップを事前に作成し、それを使ってjoinを行っています。慣れていない人にとっては難しいかもしれませんが、古くはperlの連想記憶、最近（これも古いが）の例ではVBScriptのディクショナリに相当します。DBMSを使わないで日常的にファイル処理を行っている方にとっては日常的なコードかと思います。 　 ちなみに、ADPのコード例ですが非常にすっきりとしているかと思います。C++の例と比べると本来やろうとしていることが明確になっているかと思います。 実行時間は、 　

D:\>adp -t sql_test_3.p > test3.txt
time is 110988ms.

　 で、約111秒とやはり実験１より速くなっていることが解ります。 こうしてみると、実験２-Ｂが思いのほか速くなっていないと思わるでしょう。 これはSQLの実行回数に関係しています。 　 各実験のSQLの実行回数を見てみましょう。

SQLの実行回数

実験１	1回
実験２－Ａ	約470万回（Priceテーブルの行数+1）
実験２－Ｂ	約2000回（Companyテーブルの行数+1）
実験３	2回

　 になります。実験２のコードではテーブルの行数に比例した数だけSQLを実行することになります。実験２－Ｂが実験２－Ａより速いのは、Priceテーブルの行数よりComapnyテーブルの行数が圧倒的に少ないから、つまり1対nの結合を行っているからで、仮に1対1の結合では速くならないということになります。 　 実験３がなぜ実験１より速いかですが、DBMS側から転送されるデータ量が違います。 以下、CSVファイルの先頭5行を表示します。 　

1717,2005-05-10 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
1717,2005-05-11 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
1717,2005-05-12 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
1717,2005-05-13 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
1717,2005-05-16 00:00:00.000,21251,3522,明豊ファシリティワークス(株)

　 企業名の『明豊ファシリティワークス(株)』が重複して余分なデータとなっています。実験１のコードではDBMSから言語側にこのように重複したデータが来ます。各実験で転送されるデータ量を見てみましょう。 　

結果データの転送量(CSVファイルベース)

実験１	約256MB
実験２－Ａ	約256MB
実験２－Ｂ	約184MB
実験３	約184MB

　 実は、DBMSから言語側へ転送されるデータ量自体は、実験１より実験２－Ｂの方が少なくなります。そのような関係で、実験１より実験２の方が早くなっています。SQLの実行回数（実験１の方がよい）とデータ転送量（実験２の方がよい）になりますが、このあたりはハードウェアの環境やDBMSによって結果が変わってくるでしょう。 この２つのデータから実験３は、なるべく少ないSQLの実行回数で少ないデータ量を転送しているということが解るかと思います。 追記：コメント欄での指摘およびテスト再現性を考慮してテスト環境を整備して再度計測しています。