今日も突然TwitterでRDBMSとNoSQL周りの会話に若干巻き込まれたわけだけど、実際にどっちが勝つのかの帰結を予測するのは非常に難しい。
NoSQLのスケーラビリティと可用性は大変素晴らしいし、オブジェクト指向言語との相性もO/Rマッピングに比べれば抜群によい。しかし一方で、SQLと言う言語とその実装には癖があるとはいえ、RDBMSで実現できる柔軟性は捨てがたいし、ACIDが保証されているし、既存資産が流用できることも大きい。ポイントはそのACIDがどれだけ重要であるかということと、性能面だろうと思っている。つまりNoSQLでないとコストメリットが出ないほど大規模であればNoSQL優勢、そうでない部分はRDBMSで、ということだ。あまりに普通で失望した、と言われそうだが。
まあそれはおいておいて、最近RDBMSの性能を後押しするだろうと考えられている存在が、マルチコアCPUとSSDである。元々並列処理が多くCPU数の援護を受けやすいと言うメリットがある上、ランダム読み込み＝インデックス読みに強く、しかも書き込みパフォーマンスが良好なSSDは、組み合わせるとRDBMSの性能を爆発的に上げる可能性を秘めている。例えば今の数十万円で買えるハードウェア上でRDBMSのTPS性能が10倍になれば、わざわざ一般システムをNoSQL化する必要など無いわけだ。
まあそんな話をつらつらと考えているとタイムリーにもPublickeyで
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ
などという記事が出ている。RethinkDBの話はちらほらと聞こえてきていたけど、ようやくまとまった情報が出てきた感じである。
紹介されているReThinkDBのアーキテクチャはなかなか独創的なようなものに見えるかもしれないが、実は追記型ヒープストレージによってロックを削減する手法は、「トランザクション処理」（通称Gray本）にも載っているぐらい古いもので、今となってはそれほど目新しいものではない。ましてやTime Travel機能など、POSTGRESの時代にもう存在していたものである。むしろ当時理想論過ぎて現実にはどうにもならなかった完全追記を放棄した現代のRDBMS群から見れば、先祖返りと言っても良いぐらいである。
新しいのは完全追記型インデックスを持つ（これは目新しい）ことと、ReThinkDBは「ログがない」と主張しているところだ。しかし実際には、確かにログファイルは個別では存在しないが、ログにあたるものがないわけではなく、redo/undo両方のログにあたるものはヒープが全て統合されていることである。PostgreSQLではundoとヒープが統合されていて、Oracleではロールバックセグメントがundoログに当たるが、いずれもredoログは搭載している。このへんのログの話は「データベースにおけるデータ保護：ログの話」も参照していただけるとわかりやすいだろう。
結局、ロックフリーなキューを使って書き込みスレッドを直列化することによって、完全追記型を可能にしている、ということだろう。個人的にはコミット時ログ強制書き出しをどうやっているかが気になるが、それはあくまでウェイトであってロックじゃないですよ、と言う理解をすればいいのだろうか。
ただ、それが何故SSDに最適化？というと一見ぴんとこないかもしれない。実はその鍵は以下の部分にある。
これは実はSSDだけで考えるなら正しいが、本当はWrite Ahead Loggingで要求されている「ログを書き込む50%の同期書き込みとヒープを書き込む50%の非同期書き込み」のうち後者の非同期書き込みを削減しているわけである。
実は、例えば（ランダム同期書き込みしかしなかった）PostgreSQL7.0に比べてログを書く分50%もI/O量が増えたはずの7.1のほうが早かったように、一昔前の常識ではわざわざ無駄に５０％の書き込みを増やす以前の状態のほうが早い。それはHDDの場合遅い順に同期ランダム書き込み＞同期シーケンシャル＞＞＞非同期と言う特性があって、極論非同期I/Oなど無視してかまわないぐらい負荷が掛かるからだ。しかし、同期書き込みが高速なSSDではそうではなく、この削減はつまり50%の削減として直接響いてくる。ここがこのファイルシステムが「SSD専用」と銘打ったところである。たぶんHDDでは残念な性能しか出ないだろう。
個人的には、追記型はガベージコレクション（PostgreSQL用語で言うところのvacuum）が難しいのだが、そこをどうやっているかも興味がある。Time Travelができるというぐらいなのだから、全くやっていないのだろうか。キャッシュの部分も興味が無くはないが、実際にはロックフリーなバッファキャッシュアルゴリズムはそれなりに出てきているので、それほどのインパクトは感じられない。
30年前、データベースのボトルネックは間違いなくディスクI/Oだった。しかしハードウェア要件が変わり利用法も変わった。そして出てきたシステムがこのような先祖返りだったというのが実に興味深い。というか「HDDに最適化するための今までの手法」を全部取っ払い、マルチコア向けにロックフリーアルゴリズムを駆使した最新の技術で武装した、というのが正しいだろうか。コアが増え、SSDの価格性能比がどんどん落ちている間は、NoSQLが下層まで降りてくるのはまだまだ厳しそう、といえるかもしれない。
NoSQLのスケーラビリティと可用性は大変素晴らしいし、オブジェクト指向言語との相性もO/Rマッピングに比べれば抜群によい。しかし一方で、SQLと言う言語とその実装には癖があるとはいえ、RDBMSで実現できる柔軟性は捨てがたいし、ACIDが保証されているし、既存資産が流用できることも大きい。ポイントはそのACIDがどれだけ重要であるかということと、性能面だろうと思っている。つまりNoSQLでないとコストメリットが出ないほど大規模であればNoSQL優勢、そうでない部分はRDBMSで、ということだ。あまりに普通で失望した、と言われそうだが。
まあそれはおいておいて、最近RDBMSの性能を後押しするだろうと考えられている存在が、マルチコアCPUとSSDである。元々並列処理が多くCPU数の援護を受けやすいと言うメリットがある上、ランダム読み込み＝インデックス読みに強く、しかも書き込みパフォーマンスが良好なSSDは、組み合わせるとRDBMSの性能を爆発的に上げる可能性を秘めている。例えば今の数十万円で買えるハードウェア上でRDBMSのTPS性能が10倍になれば、わざわざ一般システムをNoSQL化する必要など無いわけだ。
まあそんな話をつらつらと考えているとタイムリーにもPublickeyで
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ
などという記事が出ている。RethinkDBの話はちらほらと聞こえてきていたけど、ようやくまとまった情報が出てきた感じである。
紹介されているReThinkDBのアーキテクチャはなかなか独創的なようなものに見えるかもしれないが、実は追記型ヒープストレージによってロックを削減する手法は、「トランザクション処理」（通称Gray本）にも載っているぐらい古いもので、今となってはそれほど目新しいものではない。ましてやTime Travel機能など、POSTGRESの時代にもう存在していたものである。むしろ当時理想論過ぎて現実にはどうにもならなかった完全追記を放棄した現代のRDBMS群から見れば、先祖返りと言っても良いぐらいである。
新しいのは完全追記型インデックスを持つ（これは目新しい）ことと、ReThinkDBは「ログがない」と主張しているところだ。しかし実際には、確かにログファイルは個別では存在しないが、ログにあたるものがないわけではなく、redo/undo両方のログにあたるものはヒープが全て統合されていることである。PostgreSQLではundoとヒープが統合されていて、Oracleではロールバックセグメントがundoログに当たるが、いずれもredoログは搭載している。このへんのログの話は「データベースにおけるデータ保護：ログの話」も参照していただけるとわかりやすいだろう。
結局、ロックフリーなキューを使って書き込みスレッドを直列化することによって、完全追記型を可能にしている、ということだろう。個人的にはコミット時ログ強制書き出しをどうやっているかが気になるが、それはあくまでウェイトであってロックじゃないですよ、と言う理解をすればいいのだろうか。
ただ、それが何故SSDに最適化？というと一見ぴんとこないかもしれない。実はその鍵は以下の部分にある。
ReThinkDBでは、データベース自身がログになっているため、ログのための別のディスクを確保する必要もない。ログを書く必要がないため書き込みが50％減少する。
これは実はSSDだけで考えるなら正しいが、本当はWrite Ahead Loggingで要求されている「ログを書き込む50%の同期書き込みとヒープを書き込む50%の非同期書き込み」のうち後者の非同期書き込みを削減しているわけである。
実は、例えば（ランダム同期書き込みしかしなかった）PostgreSQL7.0に比べてログを書く分50%もI/O量が増えたはずの7.1のほうが早かったように、一昔前の常識ではわざわざ無駄に５０％の書き込みを増やす以前の状態のほうが早い。それはHDDの場合遅い順に同期ランダム書き込み＞同期シーケンシャル＞＞＞非同期と言う特性があって、極論非同期I/Oなど無視してかまわないぐらい負荷が掛かるからだ。しかし、同期書き込みが高速なSSDではそうではなく、この削減はつまり50%の削減として直接響いてくる。ここがこのファイルシステムが「SSD専用」と銘打ったところである。たぶんHDDでは残念な性能しか出ないだろう。
個人的には、追記型はガベージコレクション（PostgreSQL用語で言うところのvacuum）が難しいのだが、そこをどうやっているかも興味がある。Time Travelができるというぐらいなのだから、全くやっていないのだろうか。キャッシュの部分も興味が無くはないが、実際にはロックフリーなバッファキャッシュアルゴリズムはそれなりに出てきているので、それほどのインパクトは感じられない。
30年前、データベースのボトルネックは間違いなくディスクI/Oだった。しかしハードウェア要件が変わり利用法も変わった。そして出てきたシステムがこのような先祖返りだったというのが実に興味深い。というか「HDDに最適化するための今までの手法」を全部取っ払い、マルチコア向けにロックフリーアルゴリズムを駆使した最新の技術で武装した、というのが正しいだろうか。コアが増え、SSDの価格性能比がどんどん落ちている間は、NoSQLが下層まで降りてくるのはまだまだ厳しそう、といえるかもしれない。
コメント