3月のブログ「OSS-DBの分散トランザクション技術が熱いらしい」 https://nmizos.blogspot.com/2019/03/ossdb-distributed-transaction.html で記した「第3回オープンソースデータベース比較セミナー」を開催しました (OSSコンソーシアム主催)。
………………………………………………………………………………………………
定番のRDBMSから,メジャーなNoSQL,そして現在開発中の「次世代の」処理系について,この分野の第一線におられる4人の方に発表いただきました。
いずれの講演者にも共通することですが,
・トランザクションとは/一意性や並列性とは/シリアライズとは/などなどの本質を踏まえた上で (たいへん勉強になりました) …
・それぞれのDBMS製品が採用している基本的な考え方(アーキテクチャ)をまるでご本人が設計されたかのように代弁いただきつつ (次世代OLTPの神林氏は本当に設計されていますが) …
・どんなことが実現できるのか,逆に課題や実現できないことは何か,
・さらには,各製品がそれらをどのように実装しているのかという深い点まで
これらを,45分(+α)に折り込んでいただきました。
みなさん「この話を45分にするのは難しい」とおっしゃられていましたが,とても濃い45分に,魂を込めてまとめていただいたのだろうと感じます。
簡単にそれぞれの講演の内容を紹介します。ただし,下記の要約した紹介が,それぞれの講演者の主張点を正しく反映しているという自信は,まったくありません。あくまでも「私がどのように聞いたか?」という話です。また,仮に主旨にあった紹介ができたとしていても,このコラムごときの要約で,大事なポイントを説明は絶対にできてはいません。これらのことはご容赦ください。
……………
トップバッターの高塚氏は,PostgreSQLでのOLTPをお話しされる点に加えて,トランザクションについてのおさらい(復習)や,MVCC (Multi Version Concurrency Control) の概要を,聴講者にインプットするという役割も担っていただきました。高塚さんがトップバッターで本当によかったと思います。ただ,当然と言えば当然ですが,「OLTP入門」だけが高塚氏のテーマではありませんので,PostgreSQLでどのように実装されているのかについても,丁寧に説明いただきましたし,タイトルの「vs 大規模OLTP」に沿って,OLTP向けの高性能クラスタをPostgreSQLでどのように構成するのかまで折り込んでいただきました。
PostgreSQLがどんなDBMSかについては,ここでの紹介は不要と思いますので割愛します。高塚氏(PostgreSQL)の後の3つの講演につながる点について,ピックアップしてみます。(繰り返しですが,私が正しく要約できているかどうか,かなり自信がありません)。
「トランザクションの隔離(isolation)の分離レベル」がSQL標準で4段階に定義されています。よく使われるDBMSではトランザクションの隔離が完全に行われているものはなく,どの程度まで隔離できるのかという程度の違いになります。これは,トランザクションの本質というわけではなくて,実装レベルの問題です。第2レベルの「Read Committed」(他のTxがコミットされると異なるデータ内容が読み出される)が,PostgreSQLをはじめ多くのDBMSでは標準。第3レベル「Repeatable Read」は,PostgreSQLではSnapshot Isolation (SI)により実現。最高レベル(第4レベル)が「Serializable」になります。これを,PostgreSQLではSSI: Serializable SIで実装。しかし,高い隔離レベルでは直列化エラーが生じやすいし,(アプリが使用する)DBアクセスフレームワークがこのあたりに対応していないという課題があります。
さて,今や定番RDBMS,言い換えると歴史の長いPostgreSQLですが,大規模OLTPと戦うためにクラスタ構成(スケールアウト構成)もできるようになってきています。PostgreSQL標準のレプリケーションやAWS Auroraは,基本的には参照負荷分散が中心になります。BDR: Bi-Directional Replication というマルチマスタクラスタもありますが,書き込みに強いとまでは言えません。アプリケーションレベルでシャーディングやDBMS分割するという手法はあって,現実的にPostgreSQLで大規模OLTPに使われているのはこの形態が多いようです。
……………
MySQLもみなさんご存知のように定番中の定番のOSS-DBです。普通に「MySQL」と呼ぶときの「MySQL Server」と今回紹介いただいた「MySQL NDB Cluster (MySQL NDB Cluster)」は,コードベースもバージョン番号も異なる別製品とのことです。とはいえ,MySQL Clusterのフロントエンド(呼び出し側)にMySQL Serverを使うこともできるので,名前の頭だけが同じの無関係のものというわけではありません。MySQL Clusterのオリジナルは,携帯電話メーカのEricssonのエンジニアが開発したもの。携帯電話サービスの膨大なトランザクションを処理させるために作ったという背景は,納得感があります。その発端となった論文も紹介されていましたが,超なつかしいピザボックス型のSunがイラストに使われているなど,結構長い歴史があることがわかります。
前置きが長くなりましたが,分散環境(クラスタ構成)の性能特性も目を見張るものがあります。「これはベンダが出している性能ベンチマークの数字ですからね。わかってますよね」との一言には会場からも笑いが起こっていましたが,ン割引で見られたとしても自信があるということなんですね。
講演では,この他にMySQL NDB Clusterを構成するコンポーネントの説明や,内部での実装方法,データの持ち方などの深い部分にまで解説されました。梶山さんが,Gihyo.jpのOSSデータベース取り取り時報で解説をされていますので,そちらもご参照ください。
……………
Cassandraは代表的なNoSQL系のDBMSで,大規模ユーザを抱えたインターネットサービスの多数で採用実績があります。iTunes(Apple),Instagram,NETFLIXなどで数万台超?のクラスタ構成でペタバイト〜エクサバイト級の実績があり,日本国内でもコンシューマ向けの著名なネットサービスで多く採用されています(Yahoo! Japan,楽天,ぐるなび,など)。
冨田氏の講演は「Cassandraでトランザクションを語る」がテーマです。(1)一意性と不可分操作,(2)データ整合性の考え方,(3)トランザクション実装の3点を軸にして,Cassandraではどのように対応しているのかの解説でした。
一意性と不可分操作の観点では,全体として透過性のある分散データベースと分散トランザクションを「よしなにやる」ことを,恐ろしく複雑に実現していのがCassandra。なお,この際,トランザクションの考え方はRDBMSとは異なることを認識しないといけなさそうです。
データ整合性では,Cassandraの整合性(Consistency)は選択型になっています。そして,Consistencyが強い場合と弱い場合とでは,性能が3桁くらい違うことは知っておくべきでしょう。
講演後半の,Cassandraでトランザクションをどのように実装しているのか?の解説では,前半も高レベルになりました。そして冨田氏のお話しは,さらにギアを上げて,実装レベルの話が好きな方ならおそらく目を輝かせておられたであろう話に展開していきました。
……………
神林氏の講演も,後述するDBMSを前提としたものですが,それは前の3つと違い,今ダウンロードして使えるというものではありません。現在,全日本チームで絶賛開発中のものです。目標は「writeに強いDBを作る」こと。今回のタイトルでは「次世代OLTP」と呼んでいますが,プロジェクト『劒』(Tsurugi)と命名されようとしているそうです。この名称は一般向けには今回が初のお披露目でした。北アルプスの劔岳(つるぎだけ)に因んでいて,「標高2999mなので,人が頂上に立って3000mになるんです」というご説明。なんかいいですね。
以下に講演内容を紹介します。何回もしつこいですが,私が正しく要約できているという自信が無いままに書いています。
トランザクション処理は,並列処理を「よろしくやってくれる」ものでなければいけません。100個の処理要求があるときに,一切の並列無しでやれば,遅いけれど間違いは起こらずに処理出来ます。100並列でやれば早いかもしれないけれど,結果はたぶんデタラメになでしょう。望ましいトランザクション処理はこの中間のどこかにあります。並列処理をしない場合と同じ結果が得られるように,並列処理を「よろしくやってくれる」ようにするにはどうするか?それがserializableになります。
次世代のOLTPは次の様な特徴を持ちます。
・(前提として)serializableであること
・Multi-version
・lockの排除
… 意見が分かれる論点ですが,神林氏はwriteロックも不要だと考えているとのこと。
・計算リソースを上手に使い切って性能を出す
… 従来はCPUやメモリなどの計算リソースの制約の多い環境下ででどう動かすか?という観点が中心でしたが,これからは制約が少ない環境下でリソースを使い切って性能を出すにはどうしたらよいかが中心。
結果として,これからどうなるかというと,1ノードの性能がTPC-CベースでMillion(百万) tpsの桁に既に到達しているのがさらに向上していき,数年以内にBillion(十億) tpsの時代が到来するでしょう。TPC-Cではなく業務トランザクションで見てもMillion tpsが達成するのではないかとのこと。
さて,NEDOに採択された「劒(tsurugi)」プロジェクトの中身についても講演の最後に触れていましたが,ここでは割愛します。気になる方は,分散コンピューティング部会に参加されるなどして,次世代OLTP(劒)プロジェクトのユーザ会の情報が届くようにすることをお薦めします。
……………
そうはいっても,せっかく会員以外の方も大勢ご参加いただいているので,OSSコンソーシアムと,データベース部会,分散コンピューティング部会の簡単な紹介をさせていただきました。もしご関心があれば,紹介資料も一緒にご参照いただければ幸いです。
資料は,公開調整が済んだものから順次,こちらに掲載していきます。
https://www.osscons.jp/jobmm09yo-723/#_723
--
………………………………………………………………………………………………
概要
「データベース比較セミナー」 [ https://osscons-database.connpass.com/ ] は過去2回,複数のOSSデータベースを一緒に扱う内容のセミナーとして,データベース部会が開催してきました。また,分散コンピューティング部会リーダーのノーチラス・テクロノジーズがNEDO(新エネルギー・産業技術総合開発機構)が採択した次世代の大規模分散OLTPを実現する国家プロジェクト [ https://www.nedo.go.jp/koubo/IT3_100063.html ] に中心メンバとして関与することになりました。これを受けて,”分散”と”OLTP”をテーマとし,現在の技術がどこまで到達しているのかを識者に語ってもらう内容としました。定番のRDBMSから,メジャーなNoSQL,そして現在開発中の「次世代の」処理系について,この分野の第一線におられる4人の方に発表いただきました。
いずれの講演者にも共通することですが,
・トランザクションとは/一意性や並列性とは/シリアライズとは/などなどの本質を踏まえた上で (たいへん勉強になりました) …
・それぞれのDBMS製品が採用している基本的な考え方(アーキテクチャ)をまるでご本人が設計されたかのように代弁いただきつつ (次世代OLTPの神林氏は本当に設計されていますが) …
・どんなことが実現できるのか,逆に課題や実現できないことは何か,
・さらには,各製品がそれらをどのように実装しているのかという深い点まで
これらを,45分(+α)に折り込んでいただきました。
みなさん「この話を45分にするのは難しい」とおっしゃられていましたが,とても濃い45分に,魂を込めてまとめていただいたのだろうと感じます。
簡単にそれぞれの講演の内容を紹介します。ただし,下記の要約した紹介が,それぞれの講演者の主張点を正しく反映しているという自信は,まったくありません。あくまでも「私がどのように聞いたか?」という話です。また,仮に主旨にあった紹介ができたとしていても,このコラムごときの要約で,大事なポイントを説明は絶対にできてはいません。これらのことはご容赦ください。
……………
[session 1] 「PostgreSQL vs 大規模OLTP」,SRA OSS 高塚遙 氏
トップバッターの高塚氏は,PostgreSQLでのOLTPをお話しされる点に加えて,トランザクションについてのおさらい(復習)や,MVCC (Multi Version Concurrency Control) の概要を,聴講者にインプットするという役割も担っていただきました。高塚さんがトップバッターで本当によかったと思います。ただ,当然と言えば当然ですが,「OLTP入門」だけが高塚氏のテーマではありませんので,PostgreSQLでどのように実装されているのかについても,丁寧に説明いただきましたし,タイトルの「vs 大規模OLTP」に沿って,OLTP向けの高性能クラスタをPostgreSQLでどのように構成するのかまで折り込んでいただきました。
PostgreSQLがどんなDBMSかについては,ここでの紹介は不要と思いますので割愛します。高塚氏(PostgreSQL)の後の3つの講演につながる点について,ピックアップしてみます。(繰り返しですが,私が正しく要約できているかどうか,かなり自信がありません)。
「トランザクションの隔離(isolation)の分離レベル」がSQL標準で4段階に定義されています。よく使われるDBMSではトランザクションの隔離が完全に行われているものはなく,どの程度まで隔離できるのかという程度の違いになります。これは,トランザクションの本質というわけではなくて,実装レベルの問題です。第2レベルの「Read Committed」(他のTxがコミットされると異なるデータ内容が読み出される)が,PostgreSQLをはじめ多くのDBMSでは標準。第3レベル「Repeatable Read」は,PostgreSQLではSnapshot Isolation (SI)により実現。最高レベル(第4レベル)が「Serializable」になります。これを,PostgreSQLではSSI: Serializable SIで実装。しかし,高い隔離レベルでは直列化エラーが生じやすいし,(アプリが使用する)DBアクセスフレームワークがこのあたりに対応していないという課題があります。
さて,今や定番RDBMS,言い換えると歴史の長いPostgreSQLですが,大規模OLTPと戦うためにクラスタ構成(スケールアウト構成)もできるようになってきています。PostgreSQL標準のレプリケーションやAWS Auroraは,基本的には参照負荷分散が中心になります。BDR: Bi-Directional Replication というマルチマスタクラスタもありますが,書き込みに強いとまでは言えません。アプリケーションレベルでシャーディングやDBMS分割するという手法はあって,現実的にPostgreSQLで大規模OLTPに使われているのはこの形態が多いようです。
……………
[session 2] 「通信インフラや防衛システムを支える全ノードアクティブ型の分散データベース MySQL NDB Cluster」,日本オラクル 梶山隆輔 氏
MySQLもみなさんご存知のように定番中の定番のOSS-DBです。普通に「MySQL」と呼ぶときの「MySQL Server」と今回紹介いただいた「MySQL NDB Cluster (MySQL NDB Cluster)」は,コードベースもバージョン番号も異なる別製品とのことです。とはいえ,MySQL Clusterのフロントエンド(呼び出し側)にMySQL Serverを使うこともできるので,名前の頭だけが同じの無関係のものというわけではありません。MySQL Clusterのオリジナルは,携帯電話メーカのEricssonのエンジニアが開発したもの。携帯電話サービスの膨大なトランザクションを処理させるために作ったという背景は,納得感があります。その発端となった論文も紹介されていましたが,超なつかしいピザボックス型のSunがイラストに使われているなど,結構長い歴史があることがわかります。
前置きが長くなりましたが,分散環境(クラスタ構成)の性能特性も目を見張るものがあります。「これはベンダが出している性能ベンチマークの数字ですからね。わかってますよね」との一言には会場からも笑いが起こっていましたが,ン割引で見られたとしても自信があるということなんですね。
講演では,この他にMySQL NDB Clusterを構成するコンポーネントの説明や,内部での実装方法,データの持ち方などの深い部分にまで解説されました。梶山さんが,Gihyo.jpのOSSデータベース取り取り時報で解説をされていますので,そちらもご参照ください。
……………
[session 3] 「Cassandraにおけるトランザクションとは」,INTHEFOREST 冨田和孝 氏
Cassandraは代表的なNoSQL系のDBMSで,大規模ユーザを抱えたインターネットサービスの多数で採用実績があります。iTunes(Apple),Instagram,NETFLIXなどで数万台超?のクラスタ構成でペタバイト〜エクサバイト級の実績があり,日本国内でもコンシューマ向けの著名なネットサービスで多く採用されています(Yahoo! Japan,楽天,ぐるなび,など)。
冨田氏の講演は「Cassandraでトランザクションを語る」がテーマです。(1)一意性と不可分操作,(2)データ整合性の考え方,(3)トランザクション実装の3点を軸にして,Cassandraではどのように対応しているのかの解説でした。
一意性と不可分操作の観点では,全体として透過性のある分散データベースと分散トランザクションを「よしなにやる」ことを,恐ろしく複雑に実現していのがCassandra。なお,この際,トランザクションの考え方はRDBMSとは異なることを認識しないといけなさそうです。
データ整合性では,Cassandraの整合性(Consistency)は選択型になっています。そして,Consistencyが強い場合と弱い場合とでは,性能が3桁くらい違うことは知っておくべきでしょう。
講演後半の,Cassandraでトランザクションをどのように実装しているのか?の解説では,前半も高レベルになりました。そして冨田氏のお話しは,さらにギアを上げて,実装レベルの話が好きな方ならおそらく目を輝かせておられたであろう話に展開していきました。
……………
[session 4] 「既存のTxとこれからのTx 〜 次世代OLTPにおけるトランザクション処理の概要」,ノーチラス・テクノロジーズ 神林飛志 氏
神林氏の講演も,後述するDBMSを前提としたものですが,それは前の3つと違い,今ダウンロードして使えるというものではありません。現在,全日本チームで絶賛開発中のものです。目標は「writeに強いDBを作る」こと。今回のタイトルでは「次世代OLTP」と呼んでいますが,プロジェクト『劒』(Tsurugi)と命名されようとしているそうです。この名称は一般向けには今回が初のお披露目でした。北アルプスの劔岳(つるぎだけ)に因んでいて,「標高2999mなので,人が頂上に立って3000mになるんです」というご説明。なんかいいですね。
以下に講演内容を紹介します。何回もしつこいですが,私が正しく要約できているという自信が無いままに書いています。
トランザクション処理は,並列処理を「よろしくやってくれる」ものでなければいけません。100個の処理要求があるときに,一切の並列無しでやれば,遅いけれど間違いは起こらずに処理出来ます。100並列でやれば早いかもしれないけれど,結果はたぶんデタラメになでしょう。望ましいトランザクション処理はこの中間のどこかにあります。並列処理をしない場合と同じ結果が得られるように,並列処理を「よろしくやってくれる」ようにするにはどうするか?それがserializableになります。
次世代のOLTPは次の様な特徴を持ちます。
・(前提として)serializableであること
・Multi-version
・lockの排除
… 意見が分かれる論点ですが,神林氏はwriteロックも不要だと考えているとのこと。
・計算リソースを上手に使い切って性能を出す
… 従来はCPUやメモリなどの計算リソースの制約の多い環境下ででどう動かすか?という観点が中心でしたが,これからは制約が少ない環境下でリソースを使い切って性能を出すにはどうしたらよいかが中心。
結果として,これからどうなるかというと,1ノードの性能がTPC-CベースでMillion(百万) tpsの桁に既に到達しているのがさらに向上していき,数年以内にBillion(十億) tpsの時代が到来するでしょう。TPC-Cではなく業務トランザクションで見てもMillion tpsが達成するのではないかとのこと。
さて,NEDOに採択された「劒(tsurugi)」プロジェクトの中身についても講演の最後に触れていましたが,ここでは割愛します。気になる方は,分散コンピューティング部会に参加されるなどして,次世代OLTP(劒)プロジェクトのユーザ会の情報が届くようにすることをお薦めします。
……………
[おまけ] OSSコンソーシアムの紹介
当日もお話ししたことですが,今回のデータベース比較セミナーを含め,私たちの活動は「自分たちが知りたいこと/やりたいことをやる」のが中心です。でも,せっかくやるなら,聞きたいと思ってくれる方も多いだろうと推察するので,一般からも参加を募っています。聴講者が多い方が発表される方たちにとっても励みになると思いますので。そうはいっても,せっかく会員以外の方も大勢ご参加いただいているので,OSSコンソーシアムと,データベース部会,分散コンピューティング部会の簡単な紹介をさせていただきました。もしご関心があれば,紹介資料も一緒にご参照いただければ幸いです。
資料は,公開調整が済んだものから順次,こちらに掲載していきます。
https://www.osscons.jp/jobmm09yo-723/#_723
--
コメント
コメントを投稿