#dbts2015 #E16 #分散トランザクションの現在 - 分散トランザクションを中心として。あと #Spark の話を少しのメモ

分散 DB の文脈での話には関心があったので、db tech showcase 2015 初日、わたしは最後に @okachimachiorz1 さんのセッションに参加してきました。

分散DB本読書会、分散合意本読書会を主催している氏だけに、このトピックにおける氏の知見の蓄積は比類なきもので、セッション冒頭の「難しいです！マニアックです！」はまさに言葉通りとなったセッションでした。

This is the session truly be crazy about database technology! *1といったところでしょうか。参加できてよかったです！

嵐のような 50 分間、とりあえずとれる範囲内でメモをとってきました。

というわけで以降がわたしのメモです。

概要：
分散クラスターの現在～特にStrong Consistencyを巡って 'ずいぶんとダサい「ACID」トランザクションを使っているのね'

HadoopをはじめとするNoSQLでは、従前のEventually Consistencyからより現実の運用に耐える「強い一貫性」を採用しつつあります。この流れの中で、ある種の製品では分散ACIDトランザクションを売り文句にしているものをもあります。嘘800ですね。ビックでない「ビックデータ」、リアルでない「リアルタイム」、ACIDでない「ACIDトランザクション」の現状を解説するとともに、まったく関係ないAsakusaのSpark対応の話とかします。
株式会社ノーチラス・テクノロジーズ神林飛志氏

分散トランザクションの現在 - 分散トランザクションを中心として。あと Spark の話を少し
- 難しいです！マニアックです！
- CSR と聞いてどれだけの人が分かるか？
- 背景
  - Hadoop はだんだんとメジャーになりました
  - Web 系で Hadoop つかってないところはない
  - エンタープライズではまだまだ、何故か？
    - それが今日のテーマ
    - ようするにトランザクションがないから
  - 最近の流れ
    - 分析系以外の通常業務での利用を考えたい
      - そもそもクラスター維持のコストが高い
      - 業務系と分散クラスターの転送コストが高い
  - HEMS
- 結果としてどうなっているか
  - やれない
    - データの整合性が確保できない
      - Eventually Consistence ではそもそも更新データが正確かどうか不安になる
      - 基本的に低遅延なので問題はないが、 concurrent にやたらいっぱい処理が走った場合はさすがに整合性確認ができない
      - e.g. Cassandra で Transaction 実装とか無理なんでやめてください
    - Join が手間かかる（というか、かかった）
      - ただし現状では過去形に近い
      - ここは過去形に近い
      - 簡単にいうと最適化が効かない
        
        ハッシュジョインで全部ばらまけ戦略した現状はとれない
- そもそも Transaction 機能とはなにか？
  - ACID 属性
    - CI が一番大事
    - Concurrent に処理が走った時に整合性がとれること、が Transaction
    - NoSQL 系の ACID は全部ウソです！
  - AD について
    - AD の実装は簡単ではない、できない
    - 書いたものがすべて残ることではない
      - コミットされたもの「だけ」が残るということ
      - どう消すかという問題
      - 要するにリカバリーの問題
        
        消してる最中に失敗したらどうする？というものを解決する
        
        リカバリーの実行時間は短いよね？ (長いとやばい)
  - で、 C と I
    - ANSI SQL 92 が基本
      - ただしこれはあんまり正しくないてのが定説
      - その解説論文が遊泳で、そっちが基準になっている
        
        A Critique of ANSI SQL Isolation Level 再読
  - Correct の意味
    - 全部の Tx で意図したとおりになってればいいんじゃね？
    - 意図したとおり？なにその主観的判断
    - そもそも意図したとおりにならないとはどういう状況
    - 基本的には write
      - Lost update
      - ....
    - トランザクション業界では read は無視します
    - 書いたものがどのように残るのか、がポイント
    - ものすごく大雑把に言うと
      - いわゆる Serializable ということ
        
        Tx に困ったら普通に順序実行という手もあるということ
- 分散トランザクション（詳細は @kuenishi さんのブログを読みなはれ、とのこと）
  - 現状の普通のローカルのトランザクション処理はどうなているか
  - CSR は 2PL と理論的には同値であることが証明されている
  - というわけで、この CSR をグローバルに行えばよい
- 分散クラスターと分散トランザクションの関係
- 分散トランザクションのトラウマ
  - CORBA
  - じつは 2PC, 2PL だったが全然ダメ
  - SR 的なものに近かった
- 分散トランザクションの必要性
  - SNS/Cloud
    - Google, Amazon, FB, Twitter の環境
  - 大規模 SNS での必要要件
- 解決案の考え方
  - トランザクション処理＝各処理がコンフリクトを起こす場合にその調停を行う仕組みを定義しなおす
  - その上で調停しないでいいセマンティクスを見つけ出す
  - ex. RAMP Transaction
    - Read Atomic Multi-Partition Transaction
      - 2PC の変形
      - ただしロックはしないで　Multi-version する
    - それを汎用化できる仕組みがでてきていることが大事
    - RAMP だから Ok という話ではない
      - SNS の友だち申請の件は I-Conf なので Ok
  - より具体的な例
    一定の数学的なモデルを定義することが可能
    - invariant confluence
    - I-Conf の例
    - I-Conf ではない例
- 分散トランザクションの方向性を占う
  - 結論的には
    - 分散トランザクションはたぶんできる
    - これを分散クラスターにもってこれるか
      - CASSANDRA-7056 add RAMP transaction
      - HBase
        
        tephra Transactions for HBase
        
        Snapshot Isolation
- Snapshot Isolation
  - NoSQL 系で実装しやすい
  - ただこれができたから ACID 、ではない
  - 単純な SI は WriteSkew が発生する
    - 30 年以上前からわかってる
    - とくに Tx がオーバーラップして別々の値を更新する場合で、制約が更新データ群にかけられいる場合はあっさり破綻する
- 分散トランザクションの今後
  - 実装は来る
    - ただしパチもんが多い
  - I-Conf あたりも頭にいれておく
- 今のところの解決策
  - たいていのミドルは SI になる
    - WriteSkew がおきる
  - まず I-Conf かどうか確認
  - トランザクションの制御用の仕組みは層としてつくること
- で、ノーチラスは何をしているのか？
  - エンタープライズでの分散処理の実際
    - バッチについては特に違和感もない
    - クラウドの伸長で、分散処理自体は特別ではない
      - Hadoop のおかげ
  - で、最近考えていること
    - リアルタイム処理とバッチ処理の違い
      - 速ければリアルタイム、ではない
      - ゼロレイテンシーの文脈で、リアルタイムという言葉を使う人間は皆無に近い
    - ハゲの定義と同じ
  - 100 万件のデータで 100万 ms かかったものが 1 件 1ms で終わるのか？
    - 1 sec かかったりする
    - 1 件 1ms はスループットではなく、レイテンシー要求に近い
      - スループットとレイテンシー要求の同時解決
  - 業務系は細かいバッチの数が多い
  - 直面している課題
    - データサイズ・処理サイズの混在問題
      - ショートバッチの混在
        
        小さな処理が間にはいったりする
      - スモールデータの混在
        
        業務系では、例外処理は捨てるわけにはいかない
    - 課題への対応
      - Asakusa で全部処理できるようにしたいね
        
        スモールジョブの最適化を独自エンジンで
        
        さらに速く、を Spark で
        
        Better Hadoop として存在価値あり
        
        結論からいうと、速かった
        
        業務系処理、ほぼ例外なく Spark が速い「かもしれない」
        
        Spark で全部いいんじゃね、問題
        
        1.2 から 1.3 でデグレっtる
        
        ノーチラスのパッチをあてて改善, Pull req してるので取り込まれる予定
- Spark の特性
  - いわれているほど分散メモリクラスタではない
    - 全部メモリではない
    - 実は書いてる
    - 選択できるようにしてほしい
  - Spark は MR より速い、というわけでもない
    - MR だけの処理をするなら MR のほうが速い
  - ほとんどがローカルファイルシステムを利用
  - 全体的に、現状では数GB の入力で複雑なワークロードのものに対して強い
- Asakusa
  - 新しいコンパイラ
    - Spark 以外もカバーできる
    - 論理実行計画
    - 最適化エンジン
    - アルゴリズム選択
- Spark がわのあれこれ
  - スケジューリング
  - Spark の各処理は基本的に 1 出力
- Asakusa は下位の実行エンジンが高速なものがでてきても、ソースを変えることなく選択可能にしている
  - 次は Tez