トップバッターの高塚氏は，PostgreSQLでのOLTPをお話しされる点に加えて，トランザクションについてのおさらい(復習)や，MVCC (Multi Version Concurrency Control) の概要を，最初に聴講されるみなさんにインプットするという役割も担っていただきました。高塚さんがトップバッターで本当によかったと思います。ただ，当然と言えば当然ですが，「OLTP入門」だけが高塚氏のテーマではありませんので，PostgreSQLでどのように実装されているのかについても，丁寧に説明いただきましたし，タイトルの「vs 大規模OLTP」に沿って，OLTP向けの高性能クラスタをPostgreSQLでどのように構成するのかまで折り込んでいただきました。

「トランザクションの隔離(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でトランザクションをどのように実装しているのか？の解説では，前半よりも高レベルになりました。そして冨田氏のお話しは，さらにギアを上げて，実装レベルの話が好きな方ならおそらく目を輝かせておられたであろう話に展開していきました。ここの講演後半部分についての解説はここでは省略させてもらいます。

■[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コンソーシアムと，データベース部会，分散コンピューティング部会の簡単な紹介をさせていただきました。もしご関心があれば，紹介資料も一緒にご参照いただければ幸いです。

--