#dbltokyo 第3回はGMOで開催!DBの事をなんでも発表するDatabase Lounge Tokyo #3 に参加してきたまとめ

公開日: 

データベース技術に関する内容をなんでも発表する勉強会のDatabase Lounge Tokyo #3に参加してきました。

今回はGMOインターネットグループ シナジーカフェにて開催されました。

イカまとめです。

sponcer link

使い慣れたSQLに潜む実装依存

Differences in SQL Statement from Noriyoshi Shinoda
  • 大体同じような動きをするSQL。誰もが使っている関数や演算子だが、特定の演算子になるとDBによって挙動が違うものを紹介。
  • MOD(3,0)
    • 0でわるとOracleはエラーにならない
    • MySQLはNULL
    • その他はエラー
  • GREATEST(1, 2, NULL):パラメータをとって一番大きい値を返す
    • ポスグレだけ2になるが、他は殆どNULL
  • LENGTH:バイト数や文字数によって変わったりする
    • CHAR(10)にシングルバイトをいれてLENGTHを取ってみてもどのDBも一致はしなかった
    • char型の列に文字を入れるとスペースをいれるが、それをカウントするものとしないものとで分かれる
  • CURRENT_TIMESTAMP
    • ポスグレとVerticaはトランザクションの開始時刻になる

データ型と演算子

  • NULLと文字列を結合すると、SQLServerとOracleはNULLを無視して結合するがそれ以外はNULLになる
  • CHAR型とVARCHARでテーブルを作って定義した型に空白を入れてサイズが合わないデータをいれると、Oracleだけは入らないとエラーになるが、他のDBは後ろの空白を取って入れてくれる
  • 暗黙の型変換として、文字列と数値でSELECTをやってみたが、DBによって挙動はかなりバラバラ

構文とトランザクション

  • 予約語の数はDBによって違い、MySQLとDB2はとくに多め
  • ORDER BYの挙動はNULLの順番が違う
  • UPDATEで主キーが入れ替わるのを比較すると、Oracle以外はエラーになったりする

まとめ

  • NULL,0, “”などの境界値や例外値に注意
  • バイト数、文字数なのか、単位に注意

初心者が解説するSQLServer

  • インストールとアンインストールは簡単
    • 異なるバージョンのDBが同居できる
    • アンインストールはプログラムと機能から簡単に削除
  • DBの移行
    • 管理ツールで、新しいところと古いのにつなぎ、古いのからデタッチして、新しいサーバにコピーし、ファイルを指定してアタッチしてあげれば移行ができる
    • 互換性が心配な方はAssessmentというツールで診断をしてくれる
      • ちなみにこのツールで移行もできます
  • DBのチューニング
    • エンジンチューニングアドバイザーというツールで助言がもらえます
  • バックアップ・リストア
    • バックアップが終了した時点でのデータがリストアされます
    • リストアも簡単で、好きな時間を選んでリストアできる
  • クラスタリング
    • クラスタ作ってインストールするだけでソフトウェアインストールなども自動でやってくれます
  • 操作した履歴をSQL文でも生成可能
  • 2016からDevEssentialsに登録することでDeveloperEditionが無料で使えるようになります

Oracleでモテる実行計画を固定させる2つの方法

Oracleでモテる実行計画を固定させる2つの方法 from Daiki Mogmet Ito

小生の発表。

DBMS_STATS.LOCK_TABLE_STATSで統計情報をロックするのではなく、統計情報の保留とSPMを使えばいい感じに実行計画をロックできてモテモテになれるというお話です。

HANAのハナシの基本のき

  • HANAとはIN-Memory DBをひとつの箱で出来てしまう
    • アプライアンスだけで最初提供していたが、TDIというHWを調達して自分でインストールするという形もサポートはじめました
    • DWHだけでなく、OLTPも処理できます
  • TDIだからといって、自分で好きなHWを買っていいわけではなく、パフォーマンステストを受けたHWを買わないといけない
    • ハードウェアベンダーがドイツのSAPにHWをもっていって、ベンチマークに通れば承認される
  • 技術的バックグラウンド
    • HANAのストレージ部分はMaxDB
    • 分散やカラムベースはTREX
    • オプティマイザーがP * TIME
    • HANAはDBだけじゃなくてETLみたいな機能もついている
  • In-memoryでいろんなエンジン(テキストマイニングや時系列、地理情報など)をのっけようという思想でつくられたのでいろんなプロセシングサービスがあります
  • HANAはインメモリーDBだが、データの永続性を担保するためにディスクに書き込みをしている
    • HANAはメモリー上のデータと永続されたデータの2つのレイヤーがあり、バックアップを取る時にはディスク上のデータをdisk to diskでバックアップするので、リカバリもディスクからディスクにロードしてメモリにロードする形になる
    • ディスクには定常的にI/Oが発生しています
  • メモリを増やす手段としてはスケールアップもしくはスケールアウトが考えられるがHANAはどちらもサポートしている
    • HANAのエンジンにメモリ(HANA)とディスクベースのエンジン(DynamicTiring)がある
    • システムデータをIQに変更ができる
    • HADOOPにためて連携もできる
    • テーブルを作るときはcreate table as memory, create table as diskなどで明示的に指示できる
    • ただし、オブジェクトはそれぞれ管理されてしまうという問題があるが、HANA2.0でIn-MemoryやDiskのパーティションを透過的にアクセス可能なMultistoreTableがサポートされる
  • 値段は高いらしいが、無償で32Gまで使えるeXpress Editionが使えるようになりました
    • 認定HW・認定インストール職人不要、ユーザ自身のPCで動かせ、AWSなどにものっけられる
    • 2日で3〜4万DLされているらしい
    • OSの縛りとしてはSUZEとRedhatのみです

FAQ

  • HANAの真の性能をいかすにはsql scriptで書いてくれといわれたが、今はどうなっているか?
    • いろんなDBのテクノロジーを集めたものになるので、エンジンがたくさんあるためSQLScriptを書いて最善のものを使わせていたが、今は普通にSQLを書けば速いはずです
    • ただ、エンジンによる得手不得手を吸収するためにSQLScriptを使ったりする逃げ道はあります
  • 2.0のリリースはいつごろか?
    • 明日です!!!(書いた当時の明日なのでもう公開されてます)
  • HAはN:1か?
    • スケールアウトの環境ができるが、HAの形になる
    • マスターN台、スレーブN台、スタンバイN台などができる
    • クラスタウェアがまったくなくても一応運用することはできます

トランザクションの並行処理制御

トランザクションの並行処理制御 from Takashi Hoshino

※勉強不足であまり理解できなかったため本当にメモだけの内容となっているため資料を直接見ることを推奨します

トランザクションとserializability

  • トランザクション実行の流れ
    • multiple read/write → pre-commit → commit proc → reply
  • Isolationは分離性、独立性といわれ、複数のトランザクションが混ざるのを避けるために、Serializabilityをする
  • Transaction operations
    • 複数のdata itemに対するread / writeと最後にコミットかabortで終了するoperation列
  • History
    • トランザクションの操作は順序をもっている
  • Serial history
    • 全てのトランザクションが直列化されたhistory
  • Serializabilityはserial historyと同等のhistory集合
    • 例えば最終結果が同じなのか、ある状態が同じなのかといろいろ論点がある
  • CSR(Conflict Serializability)
    • 競合の仕方が同じhistory集合

Concurrency Control Algorithms

  • Concurency Controlの目的としてはできるだけ平行に処理してSerializableに実行すること
  • Two phase locking protocol
  • Recoverability
    • crash recoveryできる
    • cascading aborts含み、abortするときに他のTxを巻き込みたくない
  • Strict 2PL
    • ロックをどんどんとっていき、write lockは最後に一気にやるというのをみたせばS2PLになる
  • Deadlock
    • ロックするとデッドロックの問題がおこる。素の2PLやS2PLはアプリケーション側で気をつけないと簡単にDeadlockする
  • Deadlock avoidance
    • Native : タイムアウトに任せる
    • Deadlock detection: wait-for graphのcycleを発見し、切断する
    • Deadlock prevention: cycleが発生する可能性を無にするプロトコル
  • Deadlock prevension
    • no-wait: lock-waitせずtrylock失敗したら即abort
    • wait-die: 優先順位が高いTxはwait, それ以外はabort
      • 実装が簡単
    • wound-wait: 優先順位が高いTxが低いTxのlockを奪い、それ以外はwait
    • Leis2015: relockすることで無理やりlock orderを揃える
      • リソースのトータルオーダを決めてしまえばロックしないという考え方があるが、ワークロードでやったらabortしまくる
  • Serializabilityの緩和
    • Read committed: writeはS2PLに従う
    • Repeatable read: ファントムリード対策をしない
  • Snapshot Isolation
    • Multiversion(OracleだとUNDOログなど)が前提
    • 2行で書くとTx開始時点での最新comitted versionをよまないといけない制約がついている
    • writeはTx毎に分割して書かないと行けない
    • Serializableではない
  • Snapshot Isolationをserializableに
    • Serializable snapshot isolation
    • SSN(Serial safety net)
  • Optimistic Concucrrency Control
    • Siloでmany-core向けにrefine
    • ロックするはずのものをロックせずにリードして、あとでverifyする
    • invisible readが可能なので速い
  • Silo-OCC
    • Scalabeなversion決定機構
    • write lockしかしないのでデッドロックしない
    • verifyした結果リードしたときと変わらなければよしとする
    • SIではない
  • Silo-OCC性能
    • GlobalTIDだとスケールしない
  • Tic-toc
    • 結果的にtimestampがきまるのでcommit時の順序とtx依存関係が前後する
    • optimistic readするがversion更新のため必ずしもinvisible readではない
  • OCCのメリット
    • invisible readによりキャッシュを汚さないのでリードが速い
    • トータルオーダーでできるのでデッドロックフリー
  • OCCのデメリット
    • 競合が激しいとabortリグが高くなる
    • long txだと厳しくなる
  • MOCC
    • 効率的な温度管理によりpessimistic lockingとoptimistic readをadaptiveに選択
    • deadlock prevensionを装備
    • ロングtxを考えなければ最強に見える

@mogmetの所感

今回もいろんなDBの話がきけて勉強になりました。最後の締めとしてとてもゆるふわな勉強会でしたねとの感想がありましたが、小生の勉強不足でしょうか、かなりガチめの発表もちらほらあり、ゆるふわの定義を再定義せざるを得ない状況となっております。

  • このエントリーをはてなブックマークに追加
  • Pocket
PAGE TOP ↑