ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

DBTS2017「次世代DB / 分散OLTP(MVCC系)を可能な限り全力で解説」聴講メモ

前書き

db tech showcase Tokyo 2017 (db tech showcase Tokyo 2017 | db tech showcase)
C31:次世代分散OLTP
次世代DB / 分散OLTP(MVCC系)を可能な限り全力で解説
の聴講メモです。

スピーカーはノーチラステクノロジーズの神林さん(@)です。

原則として自分のメモをベースに、Twitterのつぶやきを参考にしながら見直しを行いました。メモしきれなかった内容がTwitterに記録されている場合もありましたので、併せてご参照ください。
#dbts2017 since:2017-09-07 until:2017-09-08 - Twitter Search
9:18~10:27あたり。並行したセッションがあるため、つぶやきは混在しています。

メモは口頭説明を中心にまとめています。私の理解不足でメモの内容に間違いが混入しないよう確認を行いましたが、おかしな箇所がありましたらご指摘ください。

今回の発表を理解するためには、トランザクション技術をある程度理解している必要があります。@さんがとてもわかりやすい記事を公開されていますので、ご参照ください。
一人トランザクション技術 Advent Calendar 2016 - Qiita

【参考】としている個所は私が挿入しています(補足や参考資料など)。登壇者の講演内容ではありませんので、その旨ご了承ください。

聴講メモ

講演資料(スライド)

背景:ムーアの法則の終焉とメニーコア化の進展

CPUは6コアがデフォルトになっている。今後、CPUソケット数も増えるだろう。100コア搭載のマシンも見えてきている。

背景:メモリーバイスの進化

メモリが安くなった。
インメモリデータベースが特別ではなくなった。データがメモリに全部乗る。

メモリデバイスの進化でデータベースのアーキテクチャが大きく変わる。WriteBehindLogging(WBL)。リカバリータイムが従来の1000倍ぐらい変わる。後で解説する。

背景:OLAPとOLTPの統合

OLAPとOLTPの統合では、データを持ってくることはできるが、戻すときにインデックスの更新がきつい。

DBの現状課題

従来のDBではメニーコアの対応ができていない。

メモリの取り扱いが多層的になる。CPUのコアレベルでまず違うし、CPUソケットのまたぎでも速度が違う。

NUMAでのデータのConsistencyの管理について論文は出ているが、結論としては最適解が出ていない。何がよいかは測定するしかない。ただ明確になっているのはハードではダメということ。

ARIESはログをだらだらと書いて、だめならそれを元に戻す。ARIESは実装が難しい。
不揮発性メモリーによって、このリカバリ処理が劇的に簡単になる。後で(WriteBehindLogging)解説する。

【参考】
ARIESについての@さんの解説です。
ARIES - Qiita

大規模OLTP

大規模OLTPの開発競争で一番進んでいるのはOracleで、SAP、MSと続いていると思う。

OSSは関係者が多すぎて進歩のスピードが遅い。

今年(2017年)の春先に Multi version が Single version の性能を抜いた。

RDBMSアーキテクチャの制約により、スケールアウトもスケールアップもできない。

1ノードで Billion TPS のような大きいトランザクションだと、GCが問題になる。トランザクションがabortすると、ゴミが大量に発生することになる。

SQL Server はエンジンにHekatonを採用している。

【参考】
ここでのGCとは、例えばJVMが行っているメモリ上の不要なオブジェクトに対するGCではなく、データベースが不要なデータを対象に行うGCを指しています。
データベースのGCについて適当な資料を見つけることができませんでしたが、例えばPostgreSQLのVACUUMコマンドの説明に"garbage-collect"との表現が出てくることから、その意図するところが想像できるのではないかと思います。

VACUUM -- garbage-collect and optionally analyze a database

PostgreSQL: Documentation: 9.6: VACUUM

【参考】
神林さんのブログでHekatonについての解説記事です。
セッションでお話しされていて、この聴講メモでは含めきれなかった内容も解説記事には書かれています。ぜひご一読ください。
SQLServer 2014 “Hekaton”再考 - 急がば回れ、選ぶなら近道

【参考】
神林さんのブログでSILOについての解説記事です。
SILO再考〜次世代DBのアーキテクチャとして - 急がば回れ、選ぶなら近道

OCC vs MVCC

OCC (Optimistic Concurrency Control)

OCCは楽観(optimistic)。
トランザクションの競合が性能のネックとなる。
これまでのノウハウがある分、今のところ早い。

MVCC (Multi-Version Concurrency Control)

タイムスタンプで管理する。OCCに比べて理論が難しい。

SSN (Serial Safty Net)

中国の方が考えた方式。これから台頭するかも。

【参考】
OCC/MVCCについての@さんの解説です。
Optimistic Concurrency Controlについて - Qiita
Multiversion Concurrency Control(MVCC) その1 - Qiita

【参考】
SSNの発案者の方の名前をメモできませんでしたが、
The Serial Safety Net
おそらくこの論文の Tianzheng Wang と思われます。

OCC

OCCはread-lockをとらない。更新の競合がないことを前提としている。Validation Phase で Consistency Check を行い、serializableでなければabortする。

Serialization空間(理論)

Serializableの種類はIsolationの種類よりもたくさんある。

OCCはCSRだ。

Serializableの枠の外にあるものはabortと判断する。つまり、このSerializable空間の枠を広げることができれば、abortを減らすことができる。

【参考】
神林さんのブログでの解説記事です。
Multi-version Conflict Serializability - 急がば回れ、選ぶなら近道
multi-versionの基礎 - 急がば回れ、選ぶなら近道

そんなにserializationは大事か?

移植を例に挙げる。
スライドの例で、患者Aと患者Bのどちらが選ばれてもserializableといえる。どちらが優先されるかは実装に依存する。例えば、2PLなら患者Aが選ばれる。これをアプリがコントロールするにはロックを取得するしかない。
この例を見てもわかるように、データベースエンジンを変えるだけで挙動が変わってしまうかもしれない。

【参考】
2PL(Two Phase Lock, 2相ロック)についての@さんの解説です。
Two Phase Lock - Qiita

OCCの弱点

MVCCなら追記だけなので、abortしたときの対応が楽だ。

abortしなけばOCCが速い。MV (Multi-Version) は勝てない。

Multi-Versionはversionのおかげでreadもwriteもlockが必要ない。

MVCC

分散処理は時間同期をとれない前提で設計する。これは処理効率が悪い。

時間同期をとれない例としては、ある国がビットコインで分断と再開をしたと仮定したケースが挙げられる。

【参考】
ビットコインの例は、以前に神林さんが自身のブログで挙げていた例を念頭に置いたものと思われます。
ビットコインとブロックチェーンと分散合意 - 急がば回れ、選ぶなら近道

MVCC(Cicada)の圧倒的なパフォーマンス

TPC-Cのスループットのグラフを見ての通り、Cicada(赤のグラフ)が圧倒的なパフォーマンスを出している。

TPC-Cのグラフはトランザクションの最も厳しいケースでの測定結果だが、もっと軽いYCSBでもパフォーマンスが出ている。

【参考】
グラフは以下の論文から引用しています。スライドでは見辛いと思いますので、こちらを参照ください。
https://www.cs.cmu.edu/~hl/papers/cicada-sigmod2017.pdf
なお、神林さんのブログでは、この論文についてのまとめを行っています。
Cicada:Dependably Fast Multi-Core In-Memory Transactions - 急がば回れ、選ぶなら近道

MVCCのserialization空間というか MVTOについて

MVTO (multiversion time ordering) でserialization空間はCSRより広くなる。パフォーマンスもでる。
実装も理屈も簡単。「readするときは必ず最新のversionを読んでいる」ということ「だけ」が保証されていればよい。でも、理論は難しい。証明が大変。

【参考】
神林さんのブログでのMVTOの解説。serializabilityの証明もまとめています。
MVTO (multi-version timestamp ordering) - 急がば回れ、選ぶなら近道

Cicada

※関連スライドの話をまとめてメモしています

Cicadaの全体処理はパフォーマンスのためによく考えられている。

論文はあるのに実装が出ていないところから見て、今後製品化するつもりではないか?

writeとreadのそれぞれでタイムスタンプを管理している。

One-sided synchronization で早いやつにあわせる。これによりバリアが不要となり、ロックフリーとなる。

Validation phase の上2つのブロック (Sort write set by contention, Pre-check version consistency) は早くするための仕組みで、validationの本体は下3つのブロック (Install pending versions, Update read timestamp, Check version consistency) となる。

WBL (WriteBehindLogging)

※関連スライドの話をまとめてメモしています

WBL (WriteBehindLogging) は Durable Storage に対し、Table Heap を書き込んでから Log を書き込む。

WBLは Volatile Storage が NVM (Non-volatile memory、不揮発性メモリ) という前提がある。キャッシュを横取りして Durable Storage の Table Heap に書き込む。Logにはコミットのタイミングで書き込む。

Logの対比の例において、WBLは右側に示すタイミング及びデータのみデータを書き込む。

WALとパフォーマンス(レイテンシースループット)を比較すると、WBLでもログを書いている以上、それほど改善しない。
でも、リカバリータイムは1,000倍以上速い。リカバリーはコミットログからどこまで戻せばよいかを判断するだけでよいからだ。これに対し、WALの場合はREDOも処理せねばならず、処理がややこしくなる。

【参考】
Write-Behind Logging の論文は以下にあるようです。
http://www.vldb.org/pvldb/vol10/p337-arulraj.pdf

【参考】
WBLはリカバリーでロールバックのみすればよい(REDOフェーズ不要)ことについて、論文では以下の説明をしています。

In a single-versioned DBMS with WBL, the system makes a copy of a tuple's before-image prior to updating it and propagating the new version to the database. This is necessary to support transaction rollbacks and to avoid torn writes. The DBMS stores the before-images in the table heap on durable storage. The DBMS's recovery process then only consists of an analysis phase; a redo phase is not needed because the modifications for all committed transactions are already present in the database. The DBMS, however, must roll back the changes made by uncommitted transactions using the before-images. As this undo process is done on demand, the DBMS starts handling transactions immediately after the analysis phase. Similar to the multi-versioned case, the DBMS uses the commit timestamps to determine the visibility of tuples and identify the effects of uncommitted transactions.

http://www.vldb.org/pvldb/vol10/p337-arulraj.pdf

参考

今回、まとめる際に参考にした資料のリンクです。

リレーショナルデータベースの仕組み (3/3) | コンピュータサイエンス | POSTD
リレーショナルデータベースのSQLクエリの処理について、基本の概念を解説しています。リンク先のページ(3/3)では今回のスライドで取り上げられている2フェーズロック(2PL)やARIESに関する説明もあります。ただし、テーマが幅広い分、個々の解説は浅めです。

@さんによる発表資料です。冒頭のQitta記事に全て目を通してから読むと理解しやすいです。

更新情報

2017/09/23

  • Hekatonの解説記事へのリンクを追加しました。

はてなブログ記事にTwitterアカウントのリンクを埋め込む

はてなブログの記事内にTwitterアカウントのリンクを埋め込みたい場合があります。例えば、@←こんな感じに。

Twitterアカウントのリンク埋め込みにアンカーリンク(a hrefタグ)を使う方法を紹介している記事がありますが、もっと簡単な記法があります。それは以下の記法です。

[twitter:@<ユーザー名>]
はてな記法モードで確認済み

記憶によれば、この記法ははてなの公式なページにも記載されていたのですが、今は見つかりません。よって、サポート対象外となっている可能性があることをご留意ください。
ただし、ヘルプページにはその名残が残っていました。

Twitterへのリプライを送信しない・・・[twitter:@〜〜]の記法を使ってもTwitter上でreplyが飛ばなくなります。

はてなダイアリーとTwitterを連携する - はてなダイアリーのヘルプ

DBTS2017 これからの”本命技術”はこう見つける! まとめ

前書き

db tech showcase Tokyo 2017 (db tech showcase Tokyo 2017 | db tech showcase)
A12 : KEYNOTE 2
これからの”本命技術”はこう見つける!~ポスト・リレーショナルデータベース時代を読み解くコツ~
のまとめ記事です。

本セッションはウルシステムズ社長 漆原さんと楽天執行役員 森さんの対談です。漆原さんは専らモデレータを務め、森さんによるお話がほとんどでした。

この前に行われていたKEYNOTEが前倒しになったようで、時刻通りに到着したタイミングではすでに始まっていました。よって、冒頭の部分は欠けていることをご容赦ください。

原則として自分のメモをベースに、Twitterのつぶやきを参考にしながら見直しを行いました。メモしきれなかった内容がTwitterに記録されている場合もありましたので、併せてご参照ください。
#dbts2017 since:2017-09-05 until:2017-09-06 - Twitter Search
10:23~11:28あたり。並行したセッションがないため、ほぼ本セッションに関する話題となっています。

【参考】としている個所は私が挿入しています(補足や参考資料など)。登壇者の講演内容ではありませんので、その旨ご了承ください。

DB技術のカンブリア爆発をどうみるか

単純なインサートだけならRDBである必要は無いという発想から、リレーショナルでないデータベースが増えた。
データの種類も量も増えるのに従い、データベースの種類も増えた。
非構造なデータが増えつつある。

一気にビジネスをスケールさせることを考えると、プラネットスケール(地球規模)で考える必要がある。BtoCのようなサービスで特にいえる。

マシンラーニングはトライアンドエラーの更新を繰り返すため、RDBと相性が合わない。これからはデータを時系列に見ることができるような、タイムアナリシスに向いたデータベースが出てくるのではないか。

これからの注目技術

マルチバンディットアルゴリズム。ABテストではAが全くダメだった場合にテスト期間が全て無駄になる。マルチバンディットはリアルタイムに反応を見ながら変化させられる。極端に言えば10万人に10万パターンを用意できる。まだ流行っていないが、これから伸びてくるかもしれない。

【参考】
バンディットアルゴリズムとは「複数の選択肢がある場合に、どのように選択を行うのが効率的なのか?という問題を解決するためのアルゴリズム」とのことです。

新しい技術ってどうやってみつける・知るの?

(新しい技術の情報をどうやって知るのかという問いかけに対し、)新しい技術はニュースになるが、それはみんなが知っている。相手の会社に行ってエンジニアと直接会い、営業抜きのトークをしたところにネタがある。
新しい技術を探すときはビジネスニーズから調べる。また、AIに関しては論文も調べる。

自社で技術開発するか、外部製品を導入するか?

インターネットサービスは基本的に成長し、データが増えていく。障害や保守体制も考える必要がある。自社だけでその体制を完璧に組むことはできないから、ミッションクリティカルなサービスでは自社も製品もベンダーも組み合わせて、どう進めていくかを考えないといけない。
ベンダーに入ってもらう以上、ベンダーには深く入り込んで欲しい。緊急時を考えると自社エンジニアも技術を理解していることが大切。その上で、バグを踏み抜いたときに一緒に協力して取り組めるかが大事。

クラウドサービスでは自分が作った数ヶ月後に同じようなサービスをGoogleが作ってしまったりする。これは起きるときは起こるし、どうしようもない。なので、考えるべきはどれだけ早く、自分たちの意味がある物にできるかということ。
やる気がある人にリソースをわたせば実現してくれることが多い。上から個人やチームに目標を与えてもイマイチ。やる気のある人が取り組んで成果を出せば、例え後発に追い抜かれたとしても、エンジニアが学んだことに価値がある。でも、それを実現してくれるようなエンジニアとアイデアが出るのは四半期に1回程度かな。

(新しい企画のジャッジはどこで決めるのか?という問いかけに対し、)大きなビジネスジャッジをすると規模が大きくなりすぎて、提案した人が中心になれないし、そのために集められたチームは上から言われたからやっているだけになってしまう。これをマネジメントするのが(森さんの)仕事だと考えている。

ベンダーロックインは構成管理といった周辺サービスとのつなぎや、ついてくるエンジニア次第では許容できる。
OSSでもコミュニティが見つけてないバグを踏み抜くことはあるし、そのときに対応できないと詰む。中のことをわかっているエンジニアか、中のエンジニアとつながっていないとベンダーロックインと変わらない。

外部APIは規約に注意する必要がある。データを流せるか?ユーザに承諾をとる必要がないか?社内で話題になっているAPIは事前にリーガルへ確認したりしている。

EOL(End Of Life)にどう対処するか?これはかなり大きい問題。計画した矢先にEOLを宣告されたり。相手と良好な関係を築いておくとこそっと教えてくれることも。コアなエンジニアと関係を作ることが大事。賞味期限(EOLの目安)は5年ぐらいか。
EOLがあってもデータへの影響は少ない。でも、データにロジックが入り込んでいると詰む。基幹系はカッチリ固めているので起こりにくいが、それ以外だとエンジニアが離れていくので起こりやすい。

本命技術の見極め方

過去10年でトランザクションのありかたが変わった。以前はER図を書ければ食っていけるといわれたが、今どきはER図を書けないエンジニアでも活躍している。つまり、それだけではないということ。

ラーニング(マシンラーニング、ディープラーニング)の欠点は戻せないこと。学習をロールバックできない。間違えた学習をやり直す必要がある。本来はこの時点からやりなおす、というのができないといけないし、これからはそういう用途が求められてくるはず。タイムラインで自由に戻せるというのが重用になるかもしれない。

(こない技術を見極めるために、その会社のリソース投資余力をみるか?という問いかけに対し)それは確かにある。参入障壁はデータや技術によるものだ。Googleはサービスを汎用の形で出してくる。そうではなく、ビジネスにマッチしたサービスを出すスタートアップは生き残れる可能性がある。

海外のエンジニアとリレーション(関係)を作るために、ディスカッションをできるかが重用。良いディスカッションパートナーになれないと、エンジニアが乗り気になってくれない。相手とクロスするポイントを作るために色んな事に深く興味を持っておかなければならない。

これからのエンジニアに期待することは?

サーバサイド、インフラサイドの知識が無いとスケールさせることができず、新しい技術に対応できない。データ系エンジニアであってもこうした分野を苦手とする方はいるし、一緒に協力し合えればよい。

バックアップの考え方が変わってきた。サービスレベルを考えれば、テープから戻さなくてもコピーから戻せば良いよね、みたいな発想もある。過去の常識がすでに陳腐化していないかを意識する必要がある。

最終的に大事なのは人だ。

QAタイム

Q.
データベースエンジニアの外国人比率はどのぐらいか?
A.
研究所だと8割が外国人だ。Hadoopは外国人、RDBは日本人が多い。外国では大学でHadoopを学ぶ機会が多いからかもしれない。