DBMS一般

DBMSの世界はもうとっくに変革の嵐?

古い記事ですが、知らない方のブログを見てふーんと思って↓
DBMSの世界はもうとっくに変革の嵐
リンクされているページを見るとなんと自分の記事でした。。。

びっくりするほどがっかり、という記載ではじまっているので何ががっかりしたのか考えてみたのですが、よくわかりませんでした。まあ、改めて自分の書き方を見てみるとRDBをDBと一括りにしていたので、良くなかったなあと思うものの、やっぱりがっかりした理由がわからず。がっかり、それもびっくりするほどがっかりということは、何らかの形で私に期待していて、それが裏切られたことなんだと思うんですけど、一体なんだったのでしょう。

まあそれは本人にしかわからないでしょうし、私は知らない人なので置いておいて、記載されている記事はある目線でみれば正しいと思うます。が、住む世界が違うというか、全ての面で正解ではありません。海外では、という主張もあるかもしれませんが、私のフィールドの海外の環境では日本と多少違うものの、大きくは変わらないです。まあ、あんまり書くことができないので歯切れの悪い内容になりますし、最近記事を書かないのもその辺に理由があったりするのですが。。。

まあ、今の仕事はやりがいありますし楽しいのですが、ブログネタにするつもりはないので、そろそろタイトル変えるか閉鎖したほうがいいかもなあと思う出来事でした。
スポンサーサイト

データガバナンスの実践

今はシステムのインフラに携わっているけども、アプリ寄りの経験も長かったので今日はデータモデル、データガバナンスの話について聞かれました。どうすれば実現できるか、です。

はっきり言って難問ですが、課題は大きく分けると以下の3点に分類できます。
1)DBAの世界(物理設計を中心とする世界)
2)DAの世界(論理設計を中心とする世界)
3)ガバナンスの世界(運営に重きを置く世界)
経験的に1つ目が一番簡単です。次いで3つ目が楽で一番難しいのが2つ目です。

まず、1つ目ですがこれはある程度の規模の現場なら必ず出来てくる役割です。多分そういう経験をした人も多いのではないかと思います。これはこれで専門的なスキルが要求されて大変なタスクですが、必要に迫られてできるタスクでもあるので実現は比較的容易です。

次に2つ目を飛ばして3つ目ですが、これはトップの承認を得られるかどうかです。それが一番難しいという人もいるでしょうが、基本的に全体最適と個別最適とのせめぎ合いになるので必ずトップの承認が必要です。毎回コストを含めた比較をしては現場のスピードについていけません。また、個別最適(現場)の正解を否定してかかることにもなるのでこの手のタスクはストレスがかかり、損な役回りとも言えます(笑)

で、最後に一番難しい2つ目です。多分人格的に優れたスーパーモデラーがいれば、初めの数年はうまくいきます。ただ、それを継続するとなると困難を極めます。よくエースの抜けた組織が一気に弱体化するのも見かけます。また、このポジションは最低限のITスキルは必要ですが、それ以上にビジネスセンスが必要です。ともすれば企業のエンジンにもなるモデルをビジネスセンスのない人間が描くと悲惨です。そういう意味でこのタスクは最も難しいと思います。

ちなみにお前はどうなの?と思われる方もいらっしゃると思いますが、私は人格的にも劣り、センスもないので(笑)2つ目は達成できていません。

で、相談者にここまで話したところ、そうは言ってもそんな大風呂敷広げられないよ!と言われました。ごもっとも(笑)

もちろんそうくるのは想定内だったので、私なりの解は用意しておきました。そもそも、今までと発想の違うことをやろうとしたり、違う組織を作るにはある種の宣伝活動が欠かせません。宣伝活動は地味で疲れるのですが、こればかりは根気よくやるしかないんです。ただ、やり方にはコツがあります。

まず、宣伝用のドキュメントを作るのです。できれば、仕事仲間はもちろん、役員やユーザーにもわかりやすいものがいいです。人間はわかりにくいものを見るとそれだけでストレスになるので、作成にはわかりやすい一般的な広告やパンフレットを参考にします。そして、説明対象者それぞれにドキュメントを作るのではなく、1つだけにしてトークでカバーするのが合理的です。聞いている人はすんなり説明できると、さもよく考えられているように錯覚します(笑)さらにどうしても納得してもらえない時にやっと資料を作るようにします。

個人的にはドキュメント作成よりも説明の回数を増やすべきだと思っています。一回で納得してくれることなんてほとんどありませんし、そんなことでめげてはわかってもらえません。会って話すのは紙っぺらの何倍も説明効率がいいですし、宣伝は足で稼ぐものだと思います。

DBの世界に起こる変革



DBの世界に起きた大きな波

現在、どの製品を使ったとしてもRDBの性能問題は必ずといっていいほど発生する。理由は簡単で、CPU、ネットワークが高速化(CPUはマルチコア化、ネットワークは10G-Ethernetの一般化やInfiniBandなど)するのにディスク(ストレージ)が高速化に追いついていないからだ。その差を埋める役割として、RDBが担っているケースが多く、性能問題になるケースが散見される。

だが、そういう時代の流れに対して大きな変革が起きようとしている。SSDはかなりコモディティ化してきたので言うに及ばずといった感じだが、個人的には速いもののディスクの置き換えにすぎないと思っている。つまり、SSDは速いがDBのアーキテクチャに大きな変革をもたらすものではない。が、ここにきて事情が変わってきた。大きな変革の元となっているのが、不揮発性メモリの存在だ。不揮発性メモリと呼ばれるものにはPCM、ReRAM、STT-MARMなどがある。PCMが現在最も実用化が進んでいる。2011年にマイクロソフトとインテルの研究者が発表した論文「Rethinking Database Algorithms for Phase Change Memory」(http://www.cidrdb.org/cidr2011/Papers/CIDR11_Paper3.pdf)ではPCMの可能性について論じられている。興味深いのはTable1のスペックの比較だ(以下転載)。

DBの今後表1


いわゆるフラッシュと比較してスペックがいいのは一目瞭然だ。また、アイドル中の消費電力の低さや、高密度化の可能性はDRAM以上だ。つまり、この表はもはやPCMはディスクの領域の置き換えではなく、DRAMの置き換えを意味している。DRAMが不揮発になると言った時点でDBエンジニアならどうなるのかピンと来るはず。そう、今までオンメモリDBと言われていたものが、普通のDBになってしまうのだ。従来の常識では、オンメモリDBは高速だが揮発性がありそのケアが難しかった。さらに突っ込んで言うと、今後はオンメモリDBベースのアーキテクチャの製品が主役になる可能性もある。




ここに来て期待が高まるSST-MRAMの存在

先ほどの表でもわかるように、PCMは書き込みの上限があった。フラッシュと比べれば桁がだいぶ違うので、いわゆる今のSSDと比較しても安心できるレベルかもしれない。ただ、そうはいっても上限があることには変わりはなかった。ところが、SST-MRAMは実質的に書き込み上限がない。しかも東芝の「高速・低消費電力STT-MRAMキャッシュを用いたRyn-timeノーマリオフプロセッサ」(http://www.toshiba.co.jp/tech/review/2012/09/67_09pdf/f06.pdf)の図2を見る限りSST-MRAMはDRAMと比較しても速度に遜色がない(以下転載)。唯一消費電力の面で不利であったが、去年の年末に東芝からそれもクリアできたとされる発表があった(http://eetimes.jp/ee/articles/1212/10/news099.html)。つまり、DRAMと比べても同等レベルで高速、さらに書き込み上限もなく、消費電力もクリアというまさに夢のようなデバイスが生まれつつある。

DBの今後図2


これらを総合すると、SST-MRAMがDRAMに取って代わる時代は近い将来に来るだろう。現状ではこれらの技術をスマートフォンに導入させることが注目されているが、大きなシステムに関わることの多い私としてはRDBへの応用がとても気になっている。




ではRDBはどうなる?

DBエンジニア、及びストレージエンジニアやファイルシステムのスペシャリストには言わずもがなな話だが、データの永続性を担保するシステムは必ずジャーナルファイルとデータファイルの二重書きをしている。OracleでいえばREDOログファイルになるが、これがDBにとって生命線のファイルになる。データファイルの更新には時間がかかるため、ほとんどの製品ではジャーナルファイルへの書き込みを行った時点でACKを返し、性能を担保しようとする。個人的にはここの概念が覆るのではないか、と思っている。

つまり、ジャーナルファイルを更新せずとも、データ更新が高速になってしまえば直接データブロック(データファイル)を更新してしまうこともありえると思うのだ。もちろんあまりにも大量に更新がある場合は別のケアが必要になるが、大きく概念が変わることが考えられる。ちなみに、個人的にOracleDBで最も気に入っている機能でUNDOがあるが、これも不要になると思われる。もちろんOra-1555なんて過去の笑い話になってしまうだろう。

ここからは個人的な推測だが、現在最も選ばれているOralceDBのアーキテクチャが極めてオーバーヘッドが大きく非効率なものになる可能性がある。最も効率的なアーキテクチャで実装した製品が出てくる可能性があり、今後もそれに注目する必要があると思う。ちなみに、ジャーナルファイルを持たない場合、直接データを更新する他に、差分を書き込み続ける方法がある。現状実装されている製品としては、NetAPPのWAFLやPostgreSQLがある(誤解があると困るので補足すると、両者ともジャーナルファイルは存在する)。これらは書き込みの高速化やスナップショットの効率化をしやすい。デメリットとしてはガベージコレクションのような動作が必要になる(ちなみに、私の知る限りEMCに買収されたDataDomainも同じアーキテクチャになっている。DDを作ったメンバー自体がNetAPPからスピンアウトしたので、当然の流れかもしれない)。WAFLのような追記型は、ある意味直接データを更新するタイプとジャーナルファイルタイプの中間になるかもしれない。さらに、先ほど書いたように今のオンメモリDBの位置づけも重要になる。オンメモリDBはメモリ上にデータを保存できないので、そういうものと割り切ったアーキテクチャになっているが、これに追記型のように効率のいいアーキテクチャを加えた新しい製品が出てくるかもしれない。

最後に現状ではどうかということに触れると、これらの新しい不揮発性メモリはSSDに組み込まれたり一時キャッシュとして使われる流れのようである。理由はまだまだ価格面での問題があるからだろうが、少なくとも近い将来大きな変革が起こることは間違いないと思うし、エンジニアとしてはこの変革は楽しみで興味がつきない。

超高速データストア(RDB vs KVS vs etc・・・)

超高性能なデータストアが作りたい、と仮定した場合(の妄想をすると)様々なアーキテクチャが取れる。そもそも、脳みそを整理する意味で大きく分けると、超デカイ箱タイプ、分散Gridのようなタイプに分かれる。分散Gridでも、データストア用の専用ノードを構えるか、ビジネスロジック用のノードにぶち込むかでも大きく変わってくる。

そういう前提で、かつそこそこまともなサポートが得られそうな(ビジネスで使えそうな)ものをピックアップすると以下のものになる。どうしてもOSS中心になってしまう。

■RDB系
EXADATA Oracle
TimesTen Oracle
MySQL(MeMSQL) Oracle
VoltDB VoltDB

■NOSQL(KVS系)
Infinispan Redhat
Coherence Oracle
SimpleDB Amazon
ROMA 楽天
memcached Danga

■NOSQL(ドキュメント指向データベース)
MongoDB 10gen バイナリ保存
CouchDB Apache財団

■NOSQL(カラム指向データベース)
Cassandra Apache財団
HBase Apache財団
BigTable Google

■その他
Hadoop Apache財団
→+Hive or Impala

さて、超デカイ箱はEXAぐらいしかないので置いておいて、分散Gridを考える。いずれでもデータのサイズが増えると膨大な量のノード数が必要になる訳で、仮に10TBクラスまで拡張する専用ノードを構えるとすると、1枚のブレードに196GBくらい積んだとしても(もう少しいけるけど電源どうなるかな?)、52枚必要になる。ってことは、なんだかんだ言ってネットワーク機器も含めると、3筐体欲しい感じになるだろう。

ただ、それだけのデータストアを作っても、ネットワークネックになりかねない。特に全てオンメモリを想定するので明らかにボトルネックが移動する。ってことは発想を変えてビジネスロジックサーバに巨大なメモリを積み込んで、分散Gridをぶちこむしかない。でもその発想で行くと、途方もないライセンスが必要になる訳で、OS、MW全てOSSでいかないと厳しいかもしれない。もちろんネットワーク負荷もかなりのものになるから、10GBが4本で2本ずつでチーミングしないと。結構いいサーバが必要になる。

暴走した妄想は止まらない。。。要は速ければ言い訳で、何も全てオンメモリにする必要もない。サーバに全部SSDをぶち込んでしまい、容量さえ確保すればノード数は減らせる。ノード数が減ればライセンス数も減るわけで、いいに決まっている。が、今度はやはりネットワークネックになるか、そもそもSSDの値段がそこそこ高いかもしれない。

んー構成のバリエーションが多すぎて、いろいろ考えているうちにハードの値段が下がるわ、技術が進歩してしまわで、なかなかこれだ!って答えが出ないもんだ。。。でもこういう発想がうまくいけば、個人的には本当の意味でのマルチデータセンターが実現するようにも思う。CISCOやEMCに頼らないでやってみたいとも思う。でもVPLEXは好きだけどね。

GoogleのF1って???

最近少しずつ情報が出てきたGoogleのF1。でも未だにわからないところも多いです。ポイントとしては以下のような形で実現できているらしいです。
・SQLが使える
・RDBとしての機能がある
・データセンターをまたいで分散できる
・Spannerの発展(拡張)のようである
・Paxosを使用してDC間で同期している
・トランザクション管理はテーブル単位
・DC間の時刻同期はGPSや原子時計を利用

Googleのパワポで多少詳しいのがありますが(Building Spannerで検索するとPDFが出てきます)、核心はよくわかりません。少なくとも22ページあたりの仕組みを見ると、本当にDC間で同期できているように見えます。DC間の同期はシビアな速度が求められるので個人的にはかなり興味深いです。

とはいえ、どこまで使い勝手がいいのかイマイチわかりません。私の場合はオラクルで馴染んでいるので、ロックは行レベルでかけたいところですが、そこまで複雑なトランザクション管理はできないような気がします(速度の問題が大きいと思います)。ロックの単位が変わるということはアプリケーションに大きな影響を与え、性能もかなり意識して作る必要があると思います。DB2のロックエスカレーションのような動きにはならないと思いますが、トランザクションごとのロック範囲とデッドロックには気を使いそうです。

でも、現状オラクルの独占的なフィールドに対して新たな風が吹くことは単純に面白いです。今まではどの製品もオラクルの背中を追っていましたが、F1は利用者がやりたいことを純粋に追い求めている(DC間の同期で手軽に可用性向上を実現)気がします。
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。