2015-06-26

#ChugokuDB MyNA/JPUG 合同DB勉強会 in 東京に行ってきた #メモ #レポート #MySQL #PostgreSQL

今回は PostgreSQL, MySQL それぞれの NoSQL 機能にフィーチャーした勉強会、「ニッチだな、これは！」ってことで、MyNA・JPUG合同DB勉強会 in 東京に参加してきました。

個人的に PostgreSQL には疎いので PostgreSQL の最新事情とか聞けたらくらいのつもりでいってみたんですが、いい意味で変態的な勉強会*1でしたｗ

ちなみに個人的に一番、変態的だなぁと今回思ったのは MySQL Lab の HTTP(s) Plugin for MySQL だったな、と*2。

主催者の方々および会場を提供してくださった DMM Lab 様、大変貴重で勉強になる勉強会を開催してくださりありがとうございました！！

では、ブログを書くまでが勉強会なので、わたしがとってきたメモをいつも通り公開しておこうと思います。

まず、当日の Agenda は以下のとおりでした。

Agenda:

13:15 - 13:30 開場・受付

13:30 - 13:40 オープニング(会場ご案内等)

13:40 - 14:20 データモデルについて知っておくべき7つのこと〜NoSQLに手を出す前に〜 / MyNA 奥野氏

14:30 - 15:00 PostgreSQLから見るNoSQL（FDWの話） / JPUG 曽根氏

15:05 - 15:45 JSONBはPostgreSQL9.5でいかに改善されたのか？今後の展望は？ / NTTデータ澤田氏、藤井氏

15:50 - 16:20 DynamoDBの話(仮) / ADSJ 森氏

16:30 - 16:55 MySQL JSON, HTTP Plugin for MySQLなど / MySQL 梶山氏

16:55 - 17:20 トランザクション対応NoSQLとしてのMySQL Cluster / MySQL 杉山氏

17:20 - 18:20 Handlerさんコンニチワ〜主にInnoDB memcached PluginとNDB memcached Engineの違いについて〜 / @yoku0825 氏

以降より、各セッションのメモです。

データモデルについて知っておくべき7つのこと〜NoSQLに手を出す前に〜 / MyNA 奥野氏

基調講演的な
MySQL も PostgreSQL も RDB なのに今日のトピックのメインは NoSQL みたいだぞ？！
言わずと知れた @nippondanji 氏
- 簡単にいうと GPL 万歳！
- リカンベント
その 1. データモデルとは？
- データの論理的な表現方法
- データを表現するためにどんな方法がつかえるか
- DB 設計のことではないよ
  - データモデルという言葉は二通りの意味で使われる
    - データの論理的な表現
    - データ設計
  - 意味は全く違う
    - 混同すると混乱する
その 2. データモデルと演算
- データは表現するだけでは終わらない
  - データの表現方法　格納方法
  - どのように出し入れするかが重要
- どんな演算が適用できるか
  - 用意された演算の種類が重要
    - 整数の四則演算、文字列の分解・連結
    - リレーショナルモデルの射影、制限、結合 etc...
  - 用意された演算を適切に使えば簡素に書ける
    - 反例: 文字列で整数の四則演算を実装するケースを考える
      - 遅い
      - 実装できてもバグだらけ
      - そもそも実装する意味が無い
- 自分で書けば何でもできる？
  - 論理的には正解だが、現実的ではない
    - なぜ一から OS をつくらないのか？とか
  - せっかくデータベースが使えるなら活用すべき
- データベースを単なる入れ物だと考えてはならない理由
  - データベースはデータモデルを意識して作られている
    - データモデルに沿った演算が用意されている
    - その特性を理解して使えばみんなが幸せになれると思う
その 3. 様々なデータモデル
- 代表的なデータモデル
  - リレーショナルモデル
  - グラフ
  - 階層型
  - KV
  - オブジェクト etc...
- その中から適切なデータモデルを選ぶ
  - 双方向で考える
    - そのデータモデルはどのような演算が得意か
    - アプリケーションが必要とする演算は何か
  - 最大公約数をとる
    - データモデルは万能ではないから
    - データモデルに合致しない部分はアプリケーションでつくりこむ
- 一つのデータモデルでは足りない？
  - 異なるデータモデルをもつ製品を組み合わせよう
    - データの同期が課題
      - 分散トランザクションがあれば理想
      - トランザクションがない製品はキャッシュとして
  - マルチモデル
    - ひとつの製品が複数のデータモデルをもつ
      - e.g. RDB + JSON
    - スケーラビリティが課題
その 4. データの正しさ
- 正しいデータを得られないデータベースは無価値
  - でたらめな答えでよいなら /dev/random でも使ったほうがマシ
- データの正しさとは一体何か？
- RDB 上でデータの正しさを保つ
  - トランザクション
    - 同時アクセスの整合性
    - クラッシュリカバリ
  - 正規化理論
    - 重複を排除することによる論理的な矛盾の回避
  - 制約
    - ビジネスロジック
- NoSQL 上でデータの正しさを保つ
  - データの正しさの保証はアプリケーションに委ねられる
    - データの正しさを保証するためコードを量産
    - バグはデータの不整合につながる
    - テストも必要
その 5. 実装について意識する
- データモデルは論理的な表現
  - 実装の例
    - データがテーブルスペースに格納される
    - データは高速化のためにメモリ上に
      - これらは実装であってデータモデルではない
- 実装について知ることの意義
  - コンピュータ上で仕事をするのはプログラムそのもの
  - 仕事量を見積もる
    - データモデルをつかって表現するだけでは片手落ち
      - 演算が具体的にどのように処理されるのか
    - ベンチマークするべし
- 実装と理論の混同はダメ、絶対
  - 実装はデータモデルの一部ではない
  - 論理データの背系はデータモデルに沿って行う
  - データモデルの欲求をみたせるように論理設計
  - 論理設計＞物理設計
その 6. 性能について考える
- マシンの能力には限界がある
  - 万物は物理法則を超えることはできない
  - しかしデータベースに求められる処理能力は青天井
  - 必然的に求められてくるのは分散処理
- 分散処理における課題
  - どのようにデータを分散するのか
    - シャーディング、コンシステントハッシュ
  - データモデルが保たれないケースをどうするか
  - どのようにデータ同期をするのか
- 分散処理は難しい
  - 考え得るアーキテクチャは無数
  - データモデルの組み合わせもたくさん
  - アーキテクチャが複雑に
その 7. システムへの要求は絶えず変化する
- 欲求は絶えず変化する
  - スモールスタート→ユーザ激増
  - etc...
- 道具も絶えず変化する
  - 新たなデータベース製品は次々登場
    - 特に NoSQL, 分散型の製品は盛ん
  - HW は常に進化
    - CPU
    - メモリ
    - ディスク
    - 仮想化
- 次の一手を持っておく
  - 次の手をうつ引き出しが必要
    - データモデルの垣根を超えるのは難しい
  - 常に手の内のカードはアップデートしておく
  - データモデル
  - 新しい SW 製品
  - HW の進化
  - 他社の事例 etc...
結論： NoSQL は必要か？
- Yes
  - 補足
    - 一つですべてを満たせるデータモデルは存在しない
    - 一方で RDB は優秀
      - より多くの要件をカバーできる
      - 足りない部分を開発する
      - 最終的には限界も
    - データモデルの特性を理解する
      - しっかりとした計画をもって NoSQL を利用しよう
まとめ
- NoSQL は必要
  だが、使うべきかどうかの判断は合理的に。
QA
- Q1. MySQL は window 関数がなかったりするが SQL 標準だが、、、RDBMS 製品がカバーする領域の責務の範囲はどこまでになるのか？
  - A1. アプリケーションにあった製品を選べばいいという話ではないだろうか？
    - Window 関数が最重要なら MySQL を候補から外せば良いという話なのではないだろうか
    - ニーズをすりあわせましょう
- Q2. NoSQL はどのへんのものを想定しておっしゃってますか？
  - A2. 非リレーショナルモデルを NoSQL として言っている
    - グラフ
    - 階層型
    - KV
    - オブジェクト
    - ドキュメント

大事なのは適材適所の使い分け。

PostgreSQLから見るNoSQL（FDWの話） / JPUG 曽根氏@まほろば工房

Today's talk
- RDB の限界を感じたことはありませんか？
  - 木構造を RDB に経路列挙でもたせるか、隣接リストで持たせるかの判断が難しい、とか
- PostgreSQL が新しい選択肢を提供します
  - 外部データラッパ
    - FDW の使い方と作り方の話
外部データラッパー (FDW) とは？
- 外部テーブルを作成するための機能
  - 外部のテーブルをテーブルにする
  - PostgreSQL 外のデータに SQL でアクセスできる
    - where や order by が使える
    - group by などの集合関数も使える
    - join など、他 table との関連付けができる
    - 更新や削除もできる (ただし 9.3 から)
  - 外部データとは？
    - DB, csv, JSON, WebAPI etc... 何でもよい (RDBMS, NoSQL は問わない)
  - よく使う例
    - PostgreSQL to PostgreSQL
  - MySQL to PostgreSQL もできる
    - Oracle も SQL Server も MongoDB, SQLite も。
    - Git
  - SQL Databases wrappers
    - couchdb
    - monetdb etc...
    - Others
      - git
      - ldap
      - IMAP
      - s3
      - www
      - OS
      - twitter
      - facebook,,,,,,
    - その他、多くの実装がある
Demo: mysql_fdw を使った例
- where は相手側でデータを選択してもってくる
- join, order by は持ってきてからやるので注意
- Demo 環境は Vagrant で
  - mysql-5.7
- 0xDBE というツールを使っている
FDW をつくる (Extension 部分をつくる)
- C がつらい
  - 出来る人の簡単は凡人には超えられない壁
- でも Python で作る方法がある
  - Multicorn
まとめ
- しかし、速くはない
- ガッツリなら C 、さくっと作りたいなら Python
- PostgreSQL は多様性を受け入れる
- 資料 :
  - PostgreSQL wiki
  - PGXN
  - PostgreSQL の日本語ドキュメント
  - Twitter: @s87 花田さんを watch しよう

FDW のような考え方、好きだ。

FDWはかなり好みな感じがする。複数のデータベースを使いたいとき、データの連携がやはり大きな鍵になるので、FDWはそれに対するひとつのアプローチになり得るから。 #ChugokuDB
— Mikiya Okuno (@nippondanji) 2015, 6月 26

JSONBはPostgreSQL9.5でいかに改善されたのか？今後の展望は？ / NTTデータ澤田氏、藤井氏

@fujii_masao
- PostgreSQL のコミッター
  - トランザクションログの圧縮
  - 全文検索のモジュール
PGCon (先週カナダで)で話題になった JSONB 型の新機能や今後の展望について紹介
PostgreSQL がサポートする NoSQL 機能の振り返り
- 様々な方法で PosgreSQL は半構造化データを取り扱い可能
  - XML (8.2-)
  - JSON (9.2-), JSONB (9.4-)
  - hstore (8.2-) : Key Value
  - FDW で連携 (8.4-)
- JSON データを専用データ型に格納可能
  - create table tbl (data JSON);
  - データ格納方法の例→資料
PostgreSQL における JSON の歴史
- 9.2 JSON 型サポート
  - TEXT 型 + 構文チェッカ
- 9.3 関数と演算子の充実化
- 9.4 JSONB 型サポート
  - バイナリ形式 + 構文チェッカ
  - GIN インデックス対応
- 9.5 !?
JSON 型と JSONB 型の比較（詳しくは資料
- 格納方式
  - TEXT:BINARY
- インデックス
  - B-tree:B-Tree, GIN
- 演算子
  - 要素抽出の演算子のみ:要素抽出 + 比較・包含
- 検索性能
  - 低速:高速
- 更新性能
  - 高速:低速
JSONB の GIN インデックス
- 2 種類
  - デフォルト
    - @>, ?, ?&, ?|
  - jsonb_path_ops
    - @> only 包含に特化
- JSONB + GIN による強力なインデックス検索
  - Bitmap Index Scan
  - すべてのキーに対してインデックス検索可能
  - 新規追加の Key に対してもインデックス検索可能
では、これから 9.5 ではどうなるのか？
- 9.4 まででは演算子があまり豊富ではなかった
  - キーによる値の取り出し
  - パスによるデータの取り出し
- 9.5 では JSONB を操作する関数が追加
  - jsonb_concat : 連結
  - jsonb_delete : 削除
  - jsonb_set : 置き換え
  - jsonb_pretty : 整形して表示
- 対応する演算子も追加された
  - -, -# : 削除
  - || : 追加
- JSONB の今後の開発展望について
  - 2 つの大きな流れ
    - JSONB 型自体の改善
      - 検索機能の向上
        
        JSONB 型をつかったクエリは書きにくい
        
        あたらしい syntax の追加
        
        ANY ELEMENTS OF ... AS ... SATISFIES
        
        データのサイズそのものが大きい
        
        JSONB 型の圧縮
    - JSONB の関数の拡充
      - 差集合
      - 積集合
      - Deep Merge とか。
QA
- Q1. PostgreSQL で JSON 使っている人はいるか？
  - A1. いる。だが、要素で検索とかっていうことはしない

個人的には RDBMS に JSON 形式でデータ持たせるのは、、、、だが。興味深い。

DynamoDBの話 / ADSJ 森氏

db tech showcase 2015 で話した話の要約です、とのこと
DynamoDB とは？
- Dynamo が祖先
- 結果整合性
- HW を追加することによりスケール
- 完全マネージド型の NoSQL データベースサービス
- はいスケーラブル、低レイテンシー
- 高可用性 - 3x レプリケーション
Table, API, Data Type
- Table
  - Items
    - Attributes
      - Hash key
      - Range key
- API
  - Table API
  - Streams API (in preview)
- SDKs and CLI
  - JS, Python, PHP, .NET, Ruby, nodeJS, JS, iOS, Android, etc...
- Data Types
  - Sring
  - Number
  - Binary
  - JSON etc...
- Hash Table
  - Hash Key は単体でプライマリキーとして利用
  - 順序を指定しないハッシュインデックスを構築するためのキー
  - データは 3 箇所に常にレプリケーション
- Hash-Range Table
  - Hash + Range でプライマリキーもできる
  - Hash key に該当する複数のデータの順序を保証するために Range Key
DynamoDB の整合性モデル
- Write
  - 少なくとも 2 つのレプリカで書き込みが確認とれたとき
- Read
  - default
    - 結果整合性のある読み込み
Index
- Local Secondary Index
  - Range Key 以外に絞込検索を行う key を持つことができる
  - Hash Key が同一で他のアイテムからの検索のために利用
  - すべての要素の合計サイズを各ハッシュキーごとに 10 GB のサイズ制限
- Global Secandary Index
  - Hash Key 属性の代わりになる
  - Hash Key をまたいで検索を行うためのインデックス
Scaling
- スループット
  - テーブル単位で読み書きのスループットを指定する必要がある
    - Read Capacity Units
      - 1sec あたりの読み込みの項目数 x 項目のサイズ (4KB ブロック)
      - 結果整合性のある読み込みをする場合はスループットが 2 倍
    - Write Capacity Units
      - 1sec あたりの読み込みの項目数 x 項目のサイズ (1KB ブロック)
      - 1KB を下回る場合は繰り上げ
  - 概算の見積もりから大きめに設定
- サイズ
  - ひとつの item の合計サイズは 400KB の制限
- パーティショニング
  - 算出方法、算出例は資料を
- DynamoDB のスループットを最大限に活用するためには
  - Space: キーアクセスはなるべく均等に
  - Time: リクエストはなるたけ均等に
料金体系
- プロビジョニングされたスループットで決まる時間料金
- ストレージ利用料
UseCase
- リアルタイム投票システムの例
  - DynamoDB Streams (in preview)
    - テーブルの更新情報を保持
    - 非同期に更新
    - シリアライズされたデータ
    - アイテムごとの厳密な管理 etc...
- KVS として
- 広告やゲームなどの行動履歴
  - AdRoIL
- ソーシャルアプリのバックエンドとして
- バッチ処理のロック管理
- フラッシュマーケティング
QA
- Q1. Dynamo に集約関数がないから Redshift にいれないといけない、そこは自己実装しないといけない大変。 IF を用意する予定はあるか？
  - A1. Lamda を中心に増やしていく予定。 nodeJS 。

みんながこぞって「使い分けが重要」って言ってるあとから現れて、「AWSは様々なDBをご用意しております :)」っていうの上手いｗ #ChugokuDB
— yoku0825 (@yoku0825) 2015, 6月 26

DynamoDB FDWもあるらしい https://t.co/haOUp1lIYz #ChugokuDB
— Fujii Masao (@fujii_masao) 2015, 6月 26

MySQL JSON, HTTP Plugin for MySQLなど / MySQL 梶山氏

A year of Anniversaries!
- 20 :
- 10 : Innobase が買われて
- 15 : MySQL ユーザ会のドメインがきられてから
- 5 : Sun が買われて
Community のレポジトリ
- Yum
- APT
- NuGET
Source code 管理は Git に引っ越し
- GitHub for MySQL Community
  - https://github.com/mysql
  - プルリクエストとバグデータベースは連携
日本語マニュアル 5.6 がとうとうできた
MySQL 製品ロードマップ
- これは資料をみたい
- 5.7
  - ついに InnoDB に日本語の全文検索をサポートされることに
    - MeCab
MySQL Labs からの話
- 先進的な機能や実験的な仕様をいち早く公開し、コミュニティから FB をもらう
- 将来的には MySQL Server や MySQL Cluster への統合を期待
- たとえば今は何をしてる？
  - Group Replication
本題： HTTP Plugin for MySQL
- MySQL サーバへの HTTP(s)エンドポイントを提供するプラグイン
- 結果を utf8 でエンコードされた JSON フォーマットでシリアライズ
- 3 種類のエンドポイント
  - SQL : http(s)://server:port/sql
  - CRUD : http(s)://server:port/crud : 主キーによる CRUD
  - JSON : http(s)://server:port/doc : 主キーによる CRUD
- Demo:
  - mysql -u hoge -P 8080 でつないで
  - ブラウザ (firefox) から
MySQL 5.7: JSON
- 参照が中心となる処理に最適化
- ネイティブ JSON データ型
- PostgreSQL でいう JSONB
- ビルトイン JSON 関数群
- Generated Colums (生成列) を使って新しいインデックスを作成する
  - Virtual Generated Column
  - Stored Generated Column
- insert は validation がちゃんときく
- 参照系は jsn_ prefix で始まる関数でアクセス
あくまでも複数のデータ構造を単一の RDBMS アプリケーションからアクセスできることを目指している機能
- MySQL はドキュメント DB を目指しているわけではない

個人的に今回の目玉的変態機能紹介セッション。

SQL インジェクションとは一体何だったのか？！でみんなクスッ

トランザクション対応NoSQLとしてのMySQL Cluster / MySQL 杉山氏

TwitterID: @RDBMS
- カカクコム役員 → Rakuten → Oracle (エンジニアに回帰したいってことで)
MySQL Cluster 概要
- != MySQL
- In memory DB
- Storage Engine に ndb
- Scalable
  - 48node まで DataNode を増やせる
  - NoSQL で 2 億クエリ外部リンク
- 共有 Disk を使わずに active-active のクラスタ構成が組める
- SQL + NoSQL
  - C++, nodeJS, Connector for Java(ClusterJ/JPA), REST etc...
MySQL Cluster への接続
- ClusterJ にフォーカス
  - Demo
    - トランザクション処理ももちろん可能。
    - SQL をつかわないで API 経由でデータ・アクセスする Demo
      - 管理情報にも API 経由でデータ取得できる
ツッコミは奥野 (@nippondanji) 氏へ

MySQL Cluster 始めるなら、 MySQL Cluster構築・運用バイブル　～仕組みからわかる基礎と実践のノウハウを読もう！

Handlerさんコンニチワ〜主にInnoDB memcached PluginとNDB memcached Engineの違いについて〜 / @yoku0825さん

基本的に資料をみたいｗ
MySQL de NoSQL
- (1) mysqld が MySQL プロトコル以外の何かをしゃべる
  - HandlerSocket Plugin
  - deamon Plugin の類
- (2) MySQL が NoSQL データベースをバックエンドにもってる
  - MySQL Cluster
  - Mroonga
  - CONNECT
  - Cassandra
  - Storage Engine Plugin の類
- (3) MySQL が JSON, BLOB, TEXT 型に JSON を入出力する関数をもってる
  - MariaDB の Dynamic Column
  - 他
- (4), (5) は書き取れぬかった、、、
- (6) MySQL じゃない何かが MySQL プロトコルじゃない何かをしゃべって MySQL じゃないところからデータをもってくる
  - MySQL Cluster で NoSQL っていったら基本これ
MySQL の仕組み
- 構成要素、上から
  - Connector
  - SQL Parsor
  - Optimizer
  - Executor
  - Handler
  - Storage Engine
各挙動を MySQL の仕組みを踏まえて説明
- Handler Socket
- InnoDB memcached Plugin
- MySQL HTTP Plugin
- HANDLER ステートメント
- クエリーキャシュ
- NDBCLUSTER
- memcached MySQL Engine
- Mroonga
- CONNECT ストレージエンジン
- redis ストレージエンジン
  - 作ってみたという話だそう
- partition ストレージエンジン
  - ストレージエンジン
- Binlog もストレージエンジン
  - おそらく 2 相コミットしたかったから
- Query Rewrite Plugin
- クエリーリライト
  - Demo
    - ls や cat をリライトするデモ
QA
- Q1. クエリーリライトができた背景は？
  - A1. アプリを書き換えないで、プラグインで直しちゃう、みたいな。

各 Plugin の挙動を MySQL の仕組みを踏まえて説明されていて大変わかりやすかったんですが、メモは追いつかなかったので、資料をゼヒ見られたい。~~（資料は公開されていたらリンクを貼らせていただく予定）~~
id:yoku_0825 さんご本人から連絡をいただいたので、資料を以降に貼らせていただきました。 id:yoku_0825 さん、ありがとうございます！ - 2015-06-29

というわけで、わたしのレポートは以上です。
では、今回はこんなところで。