db tech showcase2014 3日目

ということで、db tech showcase 3日目へ行ってきましたよ。
欲を言えば1,2日目にも行きたかったとこだけど、さすがにそこまで休めるほど進捗に余裕はない・・・

もちろん事前登録はしておいたんだけど、受講票忘れた(ﾉ∀`)
まあ、名刺を提示したら問題なく入場できたけど。

超要約

A31 あなたが知らないリレーショナルモデル

  • リレーショナルモデル≒SQL
  • リレーショナルモデルを守れば論理矛盾は起きない設計ができる。やれ！

D32 MongoDBのバックアップとリカバリ

  • レプリカセットを使って簡単バックアップ＆リカバリ！
D33 Prestoで実現するインタラクティブクエリ」
  • 分散SQLエンジンだよ！PrestoはCPU使用効率、レスポンスタイム重視だよ！
  • PrestogrestというPostgreSQL連携もできるよ！
L34 そのデータべス 5年後大丈夫ですか
  • ハードが超進化したら、標準SQLだけでいいんじゃね？
A35 COUCHBASE SERVER 3.0で広がるNoSQL採用事例
  • COUCHBASEはスループットもレイテンシも良いし、スケールもきちんとするよ！
  • 導入事例もたくさんあるよ！
C36 GPGPUがPostgreSQLを加速する 〜"超"メニーコアによる検索高速化〜
  • いっぱいあるGPUを使って並列処理できるPostgreSQLだよ！
  • PG-Strom開発を通じて、PostgreSQLコミュニティにもいろいろ貢献できたよ！
C37 MongoDBで実際に大きなデータを扱うとどうなるのか？

A31 あなたが知らないリレーショナルモデル

  • リレーショナルモデル≒SQL
  • リレーショナルモデルを守れば論理矛盾は起きない設計ができる。
    • 超絶なクエリやストアド・プロシージャなんかいらない。
  • リレーショナルモデルでカバーできない領域はある。
    • その場合はSQL固有機能, NoSQLでカバーする。
    • 領域の見極めは必要。
  • 複雑さに立ち向かうには。
    • スキーマにとらわれがちだが、データの整合性も重要。
    • スキーマレスは救いにならない？スキーマ整合性が担保できない、データ整合性を担保できない。
  • 本の宣伝キター！「リレーショナルデータベース実践入門」

※ホントは一杯書きたいことがあるけど、大幅に省略した・・・本を買えば読めると思うし。

D32 MongoDBのバックアップとリカバリ

  • MongoDBのいいところ。
  • バックアップの3つの方法
    • ファイルレベルのバックアップ
    • MongoDBツールによるダンプ/リストア
    • レプリカセット
  • レプリカセットとシャーディング
    • レプリカセットは読み込みパフォーマンス向上と、耐障害性の向上が目的。
    • シャーディングは書き込みパフォーマンス向上
      • シャーディングを使うと、耐障害性自体は落ちる。
      • レプリカ併用が推奨。そんかしサーバ台数も倍に・・・
      • シャード毎のバックアップ/リストアといった手順の難易度がアップ！
  • デモ
    • デモ１：レプリカセットの1つを停止させ、再起動⇒徐々にレプリケーションが追いつく
    • デモ２：レプリカセットのプライマリを停止してもレプリカマネージャに接続していれば、ダウンタイムは極わずか。
    • デモ３：レプリカセットのなかの１つのデータベース自体も消えてしまった状態からの復旧(full sync)。

D33 Prestoで実現するインタラクティブクエリ

Prestoの概要・特徴
  • 分散SQL演算。Facebookが開発。
    • CPU使用効率とスピード重視
    • インメモリ
    • Java実装
    • 教科書的なRDBMS実装
    • ANSI SQLベース
    • PrestoはGithub上で開発。
HiveとPresto
  • Hiveはスループット重視、耐障害性。
  • PrestoはCPU使用効率、レスポンスタイム重視
    • トレジャーデータで独自にリトライ機構を追加
    • Facebookでの利用ケースでは10倍程度速い？
Prestoの構成
  • HDFS＋Presto＋Dashboad等
  • 中間ストレージ(PostgreSQL等)を経由しない。
  • Presto自体はSQLレイヤ
  • トレジャーデータではHDFSではなく、PlazmaDBというカラムナーDBをバックエンドで使っている。
  • バッチ処理はHive、アドホック検索はPrestoという使い分け。⇒ただし、最近の版だと境界が薄れつつある？
事例
  • Pioneerの車載センサデータの蓄積
  • 無印良品の利用。アクションログや購入データの集取して、クーポン・レコメンド等
  • GREEでの利用。2000代以上のサーバからFluentdでゲームのログの収集、ユーザ行動の可視化など

−pebbleでの利用。ウェアラブルデバイス＋センサデータ

Prestogres
  • PostgreSQLを経由してPrestoにクエリを送信
  • pgpool-IIベースで開発
PlazmaDB
  • スキーマレス・列指向ストレージ
  • JSON形式(実際はmsgpack形式)でデータ入力
  • 新たな項目が増えたら列を追加。
  • 列単位での圧縮で効率的な圧縮を行なう。
Prestoのアーキテクチャ
  • コーディネータと複数のワーカ、ワーカがコネクタプラウグインに接続。
  • 列指向のクエリプラン
    • Logical query planとDistributeed query plan
    • Distributed query planは複数のワーカで並列処理
  • コーディネータがワーカをどう見つけるか？
    • Discovery Serviceに登録されている。
  • clientとコーディネータ間はRESTインタフェース
    • コーディネータが使うワーカ群を決める
    • ワーカはコネクタプラグイン経由でストレージにアクセス
    • 最終的にどれか1つのワーカに集約されクライアントに返却される。これが弱点でもある。
Prestoの運用
  • クエリの実行履歴はTDで保存
  • コーディネータやワーカをJSON形式で取得できる。
  • Presto-metrics＋Fluentdで動作状況を収集してTDに送信
  • Librato Metricsによるサービス状況の監視
QA
  • Presto以外のインメモリ分散SQLもあると思うが、Prestoの優位性は？
    • 速度的にはインパラ最強説？
    • ただ、インパラのクローズドな開発体制だった。
    • インパラがC++実装でクラッシュ時の解析がツラい。PrestoはJava実装なので解析が楽。
  • データ量がメモリに乗り切らないときは？
    • クエリが失敗する。タスク数を増やすなどで対応する。
  • メモリ乗り切らないときにはリトライするの？
    • その場合はリトライはしない？
  • Apache Drillとの優位性
    • SQLのレベルで機能制限をしているのがある意味使いやすい。

L34 そのデータべス 5年後大丈夫ですか

60年変化のないコンピュータの仕組み
  • CPU、メモリ、ディスクという構成は変わらない。
  • 今はディスクの性能問題が多い
  • ちょっと先なら、CPUと不揮発性メモリだけの世界にならないか？(Memristorなど)
HPにおけるハードウェアの再定義
  • アプリに最適化された効率を津旧したサーバ(Moonshot)
  • 電子から光子へ
  • ユニバーサル・メインメモリ(Memrister)

⇒メモリとHDDの位置づけが変わる！？

次世代の記憶装置

アプリケーションはどうつくるべきか

  • インフラを問わない設計/RDBMSに依存しない設計へ？
  • 目指すものは下回りが変わっても変わらないアプリケーション
    • AP側は標準的なアプリケーション、標準的なアクセス
    • HW/DBMSベンダは頑張る・・・
  • 標準SQLだけで性能が満たせれば、それに越したことはないのでは？
    • だが、現実には各DBMSベンダが性能を上げるための独自構文があったりする。
    • 構文によるチューニングはやめよう。
    • SQLの標準化に関する作業の話。
  • 動くという話の次は、性能の担保。
    • このフェーズになるとデータベース・HWの選択肢が出てくる。
HP製品の紹介
  • アプリケーション用途別に製品を作っていこうとしている。
  • 汎用コンピュート
  • ミッションクリティカルコンピュート
    • x86プロセッサをベースにした製品など

⇒240コア/24TBメモリ・・・(白目)

  • NonStop Server on x86
    • マシンが自律的に高可用、スケールアウト容易、運用負荷軽減(TCO削減)、サポート体制
  • ハイパースケールアウトコンピュート
  • 仮想化/クラウドコンピュート
データベースに期待すること
  • コスト削減、リスク削減、サービス品質向上、俊敏性の向上、コンペリングイベント


A35 COUCHBASE SERVER 3.0で広がるNoSQL採用事例

COUCHBASEの特徴
COUCHBASEの利用動機
  • 高速
  • 何が起きても稼働しつづける
  • フォーマットの異なるデータの収集・蓄積
  • オフライン動機
COUCHBASEがなぜ高速化
  • READバッファ・高性能ストレージ
    • COUCHBASEはインメモリでなくても大丈夫と。
  • COUCHBASE内部でキャッシュ管理をしている。
  • Webアプリ側の工夫
    • REACTIVE PROGRAMING
    • 非同期にリクエストを投げて揃ったらレンダリング
    • COUCHBASEにもREACTIVE PROGRAMING機構を取り込む？
COUCHBASEのアーキテクチャ
  • CONSISTENT HASH/レプリカ/リバランス/フェイルオーバ
  • Bucktは1024個のブロックに分割。これを複数サーバにほぼ同数配置。
  • AppからCOUCHBASE SDK経由でアクセス。
  • レプリカ
  • リバランス
    • サーバを増やして「リバランス」ボタン？を押すと、CBでバケットの再配置を行なう。
    • SDKもそれを検知しCluster MapをDLする。
  • フェイルオーバ
    • オートフェールオーバ
    • ノード間で監視して自動フェールオーバ
HAウルトラ
  • クラスタ内レプリカ・フェイルオーバの構成では対応できないケースもある。
  • ディスク破壊のケース
  • 複数のAZにまたがるレプリカ構成
さらなるHAウルトラ
  • 世界中の拠点にクラスタを配置する。
  • XDCRという仕組みで、別リージョン間の同期をとる。
WRITEバッファ⇒分析用データストレージとしての利用
  • 3.0からTunable Memoryによって、キーとメタデータの制限がなくなった。
  • COUCHBASEに蓄積したものをXDCR経由でElasticsearch+Kibanaで分析
  • Hadoop連携
  • N1QL＋xDBCを経由してExcelなどでも使えるように？
COUCHBASEへのクエリ
  • VIEW　集計用途
  • Map　任意項目による二次インデックス
  • Reduceで集計
  • リアルタイム性を求める場合、二次インデックス用途で使う場合はインデックス用のドキュメント生成という使い方もある。
    • より柔軟な検索をしたければ？⇒Elasticseach連携
      • なぜElasticseach単体ではダメなの？
      • そもそもElasticseachは検索エンジンであり、データベースではない・・・。
      • COUCHBASEのほうが検索性能は10倍くらい速い。
  • 他の検索エンジン。
    • LUCID WORKS
    • Apache SolrベースのEnterprise
  • N1QL
    • ほぼSQLライクなクエリがかける。
    • UNNESTキーワードとかが独自(配列展開か？)
    • 結果はJSONで返却される。
    • 今後はCRUDもサポート？
  • N1QLパイプライン
    • パース⇒実行計画作成⇒インデクシングによるサーチ、そしてプラガブルアーキテクチャ。
  • N1QL XDBCドライバ
    • Simba社開発
    • 現在、ドライバを開発中。
    • JDBCドライバ経由で使えるようになる。
利用事例
  • VIBER(メッセージング)
    • 自作の内製インメモリ
    • MongoDB cluster＋Redis cluster構成のとき：250台のサーバ
    • COUCHBASE構成のとき：120台のサーバ
  • EBAY
    • 適材適所的な使い方。ACIDが必要なところはRDBMSを使うなど。
    • 低コストで高いスケーラビリティ
    • 商品のカタログデータを管理
    • 双方向XDCRによる同期
    • AuthトークンをCOUCHBASEにも保存。
    • 認証情報、セッション情報の管理など。
  • LINKED IN
    • 一旦、hadoopで軽い集約を行ったデータを管理
    • 体制としてCOUCHBASE専任チームを持つ
  • SALTを使ったCOUCHBASEの管理
  • HIPPO
    • 花屋のジレンマ
    • データのパーソナライズ⇒動的なWebサイトの生成
    • 数ミリ秒で大量の計算が必要。
  • MOBILEソリューションとして、COUCHBASE Liteがある。
  • モバイル端末ローカルにあるデータをオフライン時に使える。
  • COUCHBASE CONNECT APP
    • 写真の情報をJSONに含めることができる？
  • 国内の利用事例は？
    • KDDI
    • CYBIRD
    • SCSK(日本の代理店)


C36 GPGPUがPostgreSQLを加速する 〜"超"メニーコアによる検索高速化〜

処理向上のアプローチ
  • スケールアップ、スケールアウト
  • スケールアップ内の分類
    • ホモジニアススケールアップ、ヘテロジニアススケールアップ。
  • GPU(Graphic　Processor Unit)の特徴
    • とにかくコア数が多い！
    • CPU 12くらい⇒2688個！
  • GPUはチップ内の演算ユニット比率が高い
  • ピーク性能
    • GPU：4T FLOPS, CPU GBオーダ
  • GPU活用による縮約アルゴリズム⇒log2Nステップ
  • ヘテロジニアス化は半導体技術トレンドになっている。
    • マルチコアCPUから、CPU/GPU統合型アーキテクチャへ
    • GPU部分が増えてきても、SWが能力を引き出せない
  • ダークシリコン問題
    • トランジスタあたりの消費電力削減が追いつかない。排熱が追いつかない問題。
    • 同じチップ上に特性の異なる回路を実装して、ピーク電力消費を抑える
RDBMSのボトルネック
  • 以前は、データはストレージに置くもの。
  • 最近はRAM容量がデータより大きいケースもある。つまり、RAM上のデータをどう処理するかが今後のボトルネックになる。
  • 今後のボトルネックの世界
    • 計算ロジックがボトルネックに？
    • Join/Aggrigate/Sort/Projection・・・
    • そういう場合は並列計算アルゴリズム
    • RAMにデータが乗ってるからといって安心してはいけない。キャッシュに乗らないときの数十番遅くなる。
PG-Stromの概要
  • 現状はPostgreSQLにパッチを当てる必要がある。
  • 現在対応しているのはFull-Scan/Hash-Join/Aggregate
  • GPU＋OSSの組み合わせで低コストで性能改善
  • でも、現時点ではインメモリデータストアが前提。
PG-Stromの仕組み
  • GPUのネイティブ命令を動的生成してJITコンパイル。
  • CPU/GPU強調による、非同期並列実行
  • CUSTOM PLAN API
  • APIからメッセージ・キューでデータをGPUに渡す。
PG-Strom技術キーワード
    • OpenCL/行指向データ構造/Custom-Plan API
  • 共有バッファをDMA転送先にする。列⇔行変換がコスト高なので、行指向のまま。
  • CUSTOM PLAN APIは9.5でコミット！？
ベンチマーク結果
  • JOIN：2億 * 10万件 * 10万件 * ・・・
    • テーブル数9個11753秒 vs 60秒
  • 2億 * 10万件 * 10万件 * ・・・⇒aggregate(group by)
    • テーブル数9個829秒 vs 67秒
歴史
  • 暇つぶしに作ったのがPG-Stromの始まりｗ
  • 初期バージョンで使ったFDWの話。
  • Writeble FDWの話もBackgroud WorkerもPG-Strom起因
  • Backgroud WorkerもPG-Strom起因
  • そしてCustom Plan APIの実装の話へ。
  • CPAのポイント
    • 外部テーブルを使わなくても良い。
  • GPUから列⇒行変換のコストが7割かかってしまう！
    • なので、行のまま処理することにした。
  • 対応データ型(整数/浮動小数点/文字列/NUMERIC)
  • 四則演算オペレータ
  • 大小比較オペレータ・・・
今後の展開
  • 対応ロジック(Outer Join, Sort)拡大
  • 利用シーンはOLTP/OLAP連携など。
  • AWSで楽々デプロイもできる！


C37 MongoDBで実際に大きなデータを扱うとどうなるのか？

特徴と適用領域
  • MongoDBは数百TBの領域を扱うのは難しいかも。
  • でも、普通の企業が扱う程度(数十GB〜数十TB)ならMongoDBで扱えるはず。
  • Aggregate FWを使えば集計も高速に可能。
アグリゲーションフレームワーク
  • SQLのGROUP BY＆サブクエリに相当する。
  • MapReduceで扱うような問題も扱える。
  • 大量データOK
  • Pipelineの可読性
メモリ管理
  • MongoDBはメモリ管理がとにかく重要
  • インデックスがメモリに乗ってないとアウトー！
  • データが乗らないのはさほど問題ではない。
  • インデックスがメモリに乗り切るようにシャーディングなども検討。