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