のた犬のうまい猫めし

どら猫が作る、のた犬のための飯、略称、どら飯について語りつつ、各種技術、経済系セミナーに参加した報告、OSSいじってみた等のネタを入れていきます。更新情報はtwitterの@nota_inuにて。

db tech showcase 2014 Tokyo「インメモリデータベース徹底比較」 hp プリセールス統括本部 小森博之氏

  • データベースとハードウェアに関する提案活動。まとめ内容はWeb記事に執筆ありby著者。
  • 行指向→列指向 (行指向はOLTP性能、列指向は検索性能、圧縮率が高い。列ごとのほうがとってくる量を減らせる)、ディスク依存→インメモリ。
  • メモリ最適化列ストア:SQLServer2014の機能。列指向でデータが持たれる。DWH用途。10倍以上高速。IO量が大幅に減少(9.23GB→0.22GB)
  • インメモリデータベース:フラッシュメモリを従来型データベースで使用するのはインメモリデータベースではない。従来型データベースでメモリキャッシュにデータすべてを乗せてもインメモリデータベースではない。データストレージをおもにメインメモリ上で行うデータベース管理システム。
  • データの永続性は?:データは常にメモリ上で読み書きされるが、変更ログはディスクに記録される。ログの書き込み速度を早くすることが重要。あらゆる変更はログでキャプチャされ、処理コミット時にディスクに書き込まれ、定期的なセーブポイントでバックグラウンドでディスクに自動保存される。
  • インメモリデータベースは1990後半のTimesTenが最初くらい。SAPのHANAがインパクトがあった。SQLServer2014でインメモリ(インメモリOLTPエンジン)。Oracleは12CでIn-MemoryOption(2014/7)。(ようやくだったのか!)
  • 下記に記載した通り三者三様。特性を見極めて使うこと。
  • 共通実装:データは常にメモリ。ログは永続化ストレージ、列指向、高い圧縮率(列指向のため)、Tuple Mover(など)で列指向更新速度高速化。(行指向のほうが更新は早いが、特殊な仕組みを使う。)
  • Tuple Mover(たぷるむーばーとよむ):データの更新はメモリ上の行指向DeltaStoreにいったん書き込まれる。(いったんメモリ上に受ける。)ある程度たまるか時間がたつと移す。その後領域の解放。(Reoranize→Rebuild。)Oracleは変更ログをもとに。
  • 可用性:これまではPrimary、Secondary、共有ディスク。これだとディスクからメモリへの読み込みが時間がかかる。そのためインメモリDBのクラスタ構成では、DBレプリケーション機能を利用してメモリの状態まで同期して切り替える。ディスクも共有ディスクにする必要はない。HANAはHP Serviceguard。常に同じ状態へ。ソフトが検知し自動的にセカンダリを立ち上げる。


 SAP HANA、SQLServer2014、Oracle12c

 

  • SAP HANA(えすえーぴーはなとよむ):ネイティブなインメモリデータベースを列指向で。ネイティブでインメモリだけで作っている。データはすべてインメモリ。行、列指向両方持てるが基本は列指向。コミット時にログ書き込み。ログはフラッシュストレージなど高速なところへ。起動時にデータファイルからメモリに読み込み。カラム単位とパーティショニング単位で並列処理(一つのノードで複数のコアに割り当てて並列処理)。カラム単位の圧縮(列指向だと圧縮しやすい。同じような性質のデータが固まる)、集計テーブル不要で工数削減。Intel Xeon E7プロセッサに最適化。CPU Cashe有効に使う仕組み。Cashe line size64mbに合わせる。(メモリよりキャッシュのほうが早い。メモリ100ns、CPU15ns。SIMD(Single Instruction Multiple Data しむでぃーとよむ)による並列演算。OSはLinuxSUSE(すぜーとよむ)、RedHatで使える。
  • SQLServer2014:OLTP高速化(更新処理高速化)重視。どのテーブルをメモリ最適化テーブルにするか、Create Table時に指定。一つのDBに共存できる。メモリ最適化テーブルにすると起動時にデータをメモリに読み込みインデックスを毎回作成。インデックスに対する変更はトランザクションログに書かない。ディスク上に存在しない。起動時に毎回生成して書き込まないので高速化。テーブルの情報も書かない指定をすることもできる。(一時テーブルとして使う。完全にメモリ上。シャットダウンすると消える。)ログもデータも書かれないこともできる。すべて新しく実装。SQLServerへの完全統合。更新を早くするためには行の形で持っておくほうがよいので行指向。検索高速化したい場合にはメモリ最適化列ストア、列指向。使い分ける必要がある! 早くなる仕組みとしてロック、ラッチをやめている(変わった実装)、ストアドプロシージャはインタプリタ的に実行されるが、オーバヘッド減らすためにコンパイルした形でも動かせる。インデックスはインメモリ特化のものも。新しく実装されているので、既存のものがすべてそのまま動くとは限らない。若干制限があるので十分検討の上で。(コマンドが使えないとか。ロックの仕方とか。)
  • Oracle:検索重視。既存環境との互換性重視。(既存ユーザが簡単に使えるように。)データの更新部分は変えていない。インメモリで持つものをテーブル、パーティションごとに指定。列指向で並行してデータを持つ。(データ二重もち。)selectが来た場合には自動的にインメモリ側が使われる。追加でお金が必要。(SAP、SQLServerは追加いらない。)