オラクルが「10倍速い」DB専用機、「10年に一度の変革」と遠藤社長：ITpro.
比較的ひっそりというか、あまり知られないうちにOracle専用機、Oracle Exadataが登場した。かつてぶち上げたRaw Ironの流れだろうが、いつのまにやらひっそりと日の目を見ることなく消えていたと思っていた。まだやっていたのか。
しかし、興味深いことはいくつかある。現実問題どの程度OSが介在しているか分からないが、ストレージサーバーはiSCSIやNFSのような単純なものではないということだ。ITProの記事から引用すると
具体的には、従来はDB側だけで行っていたクエリー関連の処理をストレージ側にも担当させている。ストレージ側で該当するデータを特定、対象となる行列のみをDB側に伝送するものだ。この技術を「SmartScan」と呼んでいる。
これが意味することは、Sequential Scan(Index Scanも、かもしれない)の大部分をストレージ側で肩代わりしていることだ。ストレージ側に直接ブロックレベルのI/Oを要求せず、代わりにもっと高レベルの「スキャン」をさせることでストレージI/Oを軽減しようというのだ。物理ディスクレベルは、かねがうなるほどあるならRAID0+1の超巨大構成とかで、いくらでもスピードを上げられるようになった時代の、次のボトルネック退治である。
なお、このSmartScanが対応しているという処理はホワイトペーパーによると以下のような感じである。
- 単純なSeq Scan
- 条件絞り込み（Indexはたぶん効かない）
- カラム絞り込み
- ちょっとしたマスタテーブルのJOIN
- 差分バックアップ（たぶんsnapshot相当の処理がストレージ城のファイルシステムにあると思われる）
- テーブルスペースの作成（実ディスクのフォーマット処理などがストレージ任せに）
これにIndexとSortが加われば、相当なレベルになるだろう。ただ、現状のOracleがこれに対応するにはIndexとTableの関係を もっと密にする必要がある。また、ソートにはメモリが大量に必要なこととか、ストレージサーバーとDBノードの負荷のかねあいもあるのだろう。
実は、これに似たアプローチが一番良く行われているのはRDBMSのクラスタリングの一種、パラレルクエリ生成型である。こういうのはたいてい自前でプランを生成し、ばらしたSQL文を生成する。このときばらしたSQL文が単純スキャンしかしないようなシンプルなものになれば、たぶん近いレベルのアプローチになるだろう。
個人的には、RDBMSってのは性能二の次で複雑なクエリがかけるというのがより重要になってくると思う。が、なかなかどうして、まだまだデザインで改善できる部分はある。こういう「次世代デザイン」のRDBMSはこれからどんどん登場するのか、それとも衰退するのか？というのはこれまた興味深い。
なにしろ日本語情報がないせいで、相当に混乱している模様。他のblogサイトでもアクセス急増とかそういう話があったし。あまりにも引っかかって来るので、申し訳ないからちょっと情報をまとめておこうかと思う。
- HP2133に準ずるデザイン、キーボード含む。2133のキーボードは非常に広々していて使いやすく、素晴らしいと思ったが、あれを継承している。
- Atom N270+i945GCというごく普通のCPU/チップセット/グラフィックス。ベンチマークも予想の範疇。
- 1024×576という大きさであれば性能は十分。1366×768の場合ではちょっと性能不足か。LEDバックライトで、発色自体は綺麗と言う。
- バッテリーは6セルで7時間ぐらい持ったという報告も。まずまずスタミナがある。
- USBx2、Ether、ExpressCard/54、SDスロットと、あまり多くない。BTはオプション？
べた褒めのレビューとEngadgetに評された２つと、他に２つのレビューをgoogle先生から見つけてきた。ただし全部1024×576液晶+HDDモデルで、おそらく日本人に人気になるだろう（割高の）SSD+1366×768液晶モデルではない。
- http://computershopper.com/laptops/reviews/hp-mini-2140
- http://www.pcadvisor.co.uk/reviews/index.cfm?reviewid=109090
- http://www.notebookreview.com/default.asp?newsID=4796
- http://www.laptopmag.com/review/laptops/hp-mini-2140.aspx?page=1
ばっと見る限り一般的なネットブックに比べて優れているところは、キーボード、液晶ぐらいでそれほど無いと思われる。Type Pのような圧倒的な新提案はないが、ネットブックの部品に、比較的高級なノート向けパーツを使って外装強化したという程度だろうか。まあもちろん、ネットブックのかゆいところに手が届いている製品と言えよう。
それより問題はSSD+高精細液晶機がいつ出るか、だ。SSDに関しては本当に今すごいペースで進化しているので、買い時に困る。今HDD買って載せ替えればいいんだけど。
他のパーツ、例えばAtom-DPは当面ネットブック向けには登場しない（技術的な理由ではなく、政治的な理由 – これが売れると本当にCoreの市場を食ってしまう可能性がある）ので、しばらくバージョンアップも考えなくて良いだろう。
聞こえてきているのはGN40と呼ばれるチップセット(G45ベースと言われている）は弱点であるグラフィック性能を改善するだろうが、これも詳細は全然見えてこない。そうこうするうちに、グラフィック機能内蔵の新型Atomが登場してくるだろうと思われる。これは省電力だけど、性能はどうだろうなぁ。
某所のRDBMS書き物が停滞して久しいけれども、少しづつ書く気力も湧いてきたので頑張って書きためる意味でも草稿のような覚え書きからはじめてみる。
RDBMSというかSQLデータベースは多数の実装があり山のような機能差がある。が、実際には、比較すべき部分はそれほど無い。良く「どのRDBMSを採用すべきか」というので機能表を延々作って議論するようなのがあるが、どれもあまりにもたくさんの項目を雹に出来るため、一見仕事をしているように見せられるが、実は馬鹿げている。
主要部分のうち、自分の欲しい機能をピックアップして、それを備えているかどうか、あとは得意なOSやサポート体制、価格で決めればいい。SQLの書きやすさとかストアドプロシージャの、とかいうのは二の次である。どうせ、そのRDBMSに適したノウハウがあってそのノウハウに沿ったチューニングが必要になるという意味で、どれも同じなのだ。
ここではその「決め手になる機能」について具体的に言及したい。内容はあくまでL.starの偏見に基づいた何かであり、ブレインストーミングがてら書いているので、必ずしも完璧ではない。が、まあ参考になれば幸いである。
- ネットワーク接続
いわゆるスタンドアロン型かどうかの壁。通常、ネットワーク接続が必要ない場合は多数のロック競合とかマルチセッション向け機能が不要なため、わざわざネットワーク接続を前提としたサーバ型DBを使う必要はない。逆にシングルプロセスを前提にしたようなのは、ロックの競合とかで悩まされるため多数のユーザ向けにならない。
- ACID特性の初歩 – トランザクションとWAL等のロギング
次にポイントになるのはまじめにACIDをサポートする気があるかどうかである。はっきり言ってACIDはまじめに実装するとコストが高いので、必要でないなら使わないことが一番である。ここでのポイントはちゃんと一貫性を持ったトランザクション、そしてクラッシュリカバリ機構を持つかどうかである。
ここで落ちる代表者はMySQL-MyISAMである。ただし、ロック競合を気にせずやってしまうMyISAMの検索性能は非常に印象的である（少なくとも昔はそうだった）
ついでにいうと、WALを持つDBはたいていPITRとバイナリレベルのオンラインバックアップをサポートしている。ここがないと、データ巻き戻しが必要になるかもしれない、バックアップが必要になる中規模社内アプリケーションでは使いづらい。
- ACID特性の応用 – 行ロック あるいは MVCC
その次は、トランザクションにあわせてロックをどの程度に取るかである。テーブルロックしか取れないDBはここで脱落する。レコードレベルの書き換えを性能維持しつつ行えるため、更新に関する使いやすさが格段に増す。ここまでクリアするDBは、単一ノードによる汎用アプリケーション基盤に使える。意外なことに、スタンドアロンでも使えると言うのが売りのJava製DB、Apache Derbyはここまでクリアしている。
ちなみに個人的には読み-書きor書き-読みでロックしないMVCCは素晴らしいと思うが、一方でデータ管理が煩雑と言う欠点を抱える。これを完全に解決しているのは見たことがない。この管理がどの程度まで作り込まれているかは、メンテナンスフリーと真に言えるかどうかの分かれ目である。
さらに付け加えると、ロックの多寡はマルチCPU時の性能に顕著に効いてくる。つまり、ロックの少ないDBはCPUを増やすほど性能がリニアに向上する。この部分は、どの程度のマシンでどの程度の性能を要求するか、という決定のためには重要である。
- HA機構、パーティショニング、レプリケーション、あるいは何らかのクラスタリング
複数台数による分散の壁。数秒/数分レベルの障害検知切り替えが出来るかどうかは、高可用性を必要とするミッションクリティカルなアプリケーションの必須条件である。
またそれとも共通するが、分散による性能向上は、これがないと、巨大Webサイトなどを構築することはまず不可能だろう。また、どの程度の台数までスケールするか、という点が、サイトをどこまで簡単に巨大化できるか、という部分に直結してくる。
また、ここでロックの多寡も影響してくる。つまり、CPUに関するのと同じように、台数が増えるとどれだけスケールするかというデータが重要である。ちなみに、私個人としては、たいていのRDBMSクラスタはせいぜい４程度、という認識である。それ以上、たとえば数百クラスになると、最近ではBigTableやHadoop hbaseなどのRDBMSとは根本的に異なるタイプの提案がされている。
なお、クラスタリング等に関しては、現実に自分たちの欲しているものに合致しているか検討するのは非常に難しい。一つには機能要求が非常に多岐にわたること、そしてもう一つは実装が複雑なため、望む品質に達しているとは言い難いことが多いことである。システムは出来るだけシンプルにつとめよう。複数のアドオンをごちゃごちゃと詰め込んで一見要件リストを満たすようにしても、現実にはうまくいかないものである。その点も含めて、ノウハウが難しい。
どうだろう。ここに出てきた機能は数としては決して多くないが、そのDBをユニークたらしめる部分をかなり網羅出来ていると思う。ビジネス案件ではやはりACID＋HA必須、大規模Web案件では複数台動作必須、など、類型化しているのも確かであるが、プログラムとしての複雑さは上記で説明しきれると考えている。
あとはこれをどうまとめるかだが、そこは本番に取っておくと言うことで。
久々にプログラミングの勘を取り戻そうとかと思いつつ、wordpress2.7にアップデートしたところ動かなくなってしまったpublish To Mixiプラグインを修正してみた。
Read more »
TXTCache Index uniquely : ホーム.
JavaによるSuffix Array実装とか、Compressed Suffix array実装とか。興味深い。
char(n)のnをアプリケーションから取得する – 象と戯れ – postgresqlグループ.
不慣れな入力系を作っているのですが、char(n)なカラムの最大長チェックを行う場合、どうやるのが一般的なんでしょうか。
attypemodを直接読み解く方法を使っているけど、あれは内部表現であって、外から使うのは本来ダメでしょう。ここはやはり正当にinformation schemaを使えばいいわけで。
yutaka=# create table test4(a char(1),b varchar(2),c varchar(6));
CREATE TABLE
yutaka=# select table_name,column_name,data_type,character_maximum_length from information_schema.columns where table_name=’test4′;
table_name | column_name | data_type | character_maximum_length
————+————-+——————-+————————–
test4 | a | character | 1
test4 | c | character varying | 6
test4 | b | character varying | 2
(3 rows)
とまあ、こんな感じに求まります。これなら標準なので、他のDBにも応用が利くわけで。
どこまで行っても標準が参考以上の役に立つことのなさそうなSQLで標準にそったところでどの程度の価値があるかは問わない方向で。
Comments (0) 
