Categories: Database勉強会

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

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

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

イカまとめです。

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

https://twitter.com/nori_shinoda - Twitter

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

https://twitter.com/hammer_1104 - Twitter

2016/11/29 Database Lounge Tokyo #3 https://database-lounge-tokyo.connpass.com/event/42723/
初心者が説明するMicrosoft SQL Server - www.slideshare.net

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

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

https://twitter.com/mogmet - Twitter

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

小生の発表。

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

HANAのハナシの基本のき

https://twitter.com/kouji_s_0808 - Twitter

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台などができる
- クラスタウェアがまったくなくても一応運用することはできます

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

https://twitter.com/starpoz - Twitter

トランザクションの並行処理制御 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を考えなければ最強に見える