2013-11-07

InfiniDB と MariaDB 、そして喜連川先生の特別講演が聞きたくて Database One Day Seminar に参加してきました

今日は、午前中は Cloudera World Tokyo 2013 に行ってきましたが、午後からは、InfiniDB

、 MariaDB

、そして何より DB 界の権威、喜連川先生の講演が聞きたかったのでアシストさんが主催する Database One Day Seminar に参加してきました。

セミナーの開催概要は以下のとおりで、

日時：2013年11月7日（木） 13:00〜18:00（受付開始　12:00〜）

会場：TKP市ヶ谷カンファレンスセンター http://tkpichigaya.net/access.shtml

当日のプログラム内容：https://mp.ashisuto.jp/public/seminar/view/1160

わたしが参加してきたセッションは、以下の 5 セッションです。

13:00〜13:45 【C-1】汎用RDBMSとの徹底比較！

14:00〜14:45 【C-2】あなたのビジネスを変える InfiniDBケーススタディ 10選

15:00〜15:45 【B-3】MariaDB最新情報

16:00〜16:45 【B-4】SQLとプロシージャからみたRDBMSの違い

17:00〜17:50 【T-1】（特別講演）データベースに携わる事は人類に貢献するという事〜ビッグデータとデータベース〜

簡単に、所感を書いておくと

InfiniDB は想像以上によく見えたので、自分でも軽くためしてみたい（通常の MySQL 並に軽く試すことも可能な印象を強く受けた）
MariaDB については先日の Oracle に敵愾心丸出しのトーク爆裂な MariaDB/MySQL コミュニティイベント in TOKYO #mariadbtokyo に行ってきた - #garagekidztweetz から特に新しい情報はなかった
喜連川先生の特別講演はとてもよかった。このポストとは別にそのノートだけのポストを別途することにした。
参加者は資料ダウンロードできるみたいですが、 Slideshare などで広くシェアする気がなさそうなのはもったいないと感じた。
撮影録音を禁止している閉鎖的なのには好感を覚えなかった。その実、主催で断りを入れているとはいえ、アシストさんのスタッフが自己のレポートのためにフラッシュガンガン、音バシャバシャたてながら写真を撮ったりしていたので余計に。

といったところです。

では、以降よりそれぞれのセッションについてわたしがとってきたメモを公開しておきます。

13:00〜13:45 【C-1】汎用RDBMSとの徹底比較！〜列志向 DB の進化＆真価

列志向データベースの特徴を行志向と比較しながら理解することが目的
そして、 infiniDB の魅力を紹介

＊＊＊＊＊

列志向 DB とは？その実力は？
- ひとことでいうとデータの格納方法が違う (物理的にデータを格納する際に)
- データを行ごとに格納と列ごとに格納

＊＊＊

行志向 DB の優位点
- 少数行、複数列に対する処理が得意 (業務 DB)

＊＊＊

列志向 DB の優位点
- 大量行、少数列に対する処理が得意 (情報系 DB)
- 分析系 Query 、 Group by を用いた Summary 系関数など
- 必要列に対してのみ処理を行う

＊＊＊

情報系処理における列志向型 DB の実力
- Star Schema Benchmark を使用
- 160 GB のデータを load 、 13 の SQL を比較
- OLAP 系のクエリを実行した結果としてはあきらかに列志向のほうがすぐれている結果になっている
- 行志向 DB としては Oracle を使用している

＊＊＊

列志向 DB に都合のよいチューニングを行ったのでは？
- ベンチマークの前準備に行った内容、 160GB のデータをロードするのに行った作業、および時間を比較
  →列志向 DB はやることが少なく、非常にシンプルに終わる
- 表作成して、ロードしているだけ

＊＊＊

ここまでのまとめ
- 行志向と列志向のちがいはデータの格納の仕方
- 列志向は情報系 DB 用途に有利
- 実際に列志向を情報系処理に利用してみると、高速でシンプルに処理できる

＊＊＊＊＊

仕組みから理解する列志向 DB の魅力

＊＊＊

DWH / ビッグデータ基盤に対する期待と現実
- 要望は目的によって様々だが、行志向だとデータ量が増えると、遅い、高い、複雑
- Teradata, Netiza 初期投資としては高いよ、とか

＊＊＊

列志向 DB InfiniDB とは？
- 遅い→ディスクアクセス効率化 (列志向|自動パーティショニング)、 CPU リソース有効活用 (自動パラレル|超速バルクロード)
- 高い→1台構成から。スケールアウトも可能。
- 複雑

＊＊＊

ここからそれぞれの説明
ディスクアクセスの効率化
- データ圧縮と自動パーティショニングを実装
- 列単位でデータを圧縮
- 列単位の集合のため重複率が高く、圧縮が効かせやすい
- 対象列のみ圧縮/解凍するため、ムダなCPU負荷をオフロード
- メモリにロードするデータ容量を減らせる (より多く保持できる)
- データ圧縮率を行志向と比較 (160GB のオリジナルデータ)
- 行志向は index と data で 216GB
- 列志向は 70GB に

＊＊＊

垂直水平パーティション
- InfiniDB の特徴
- 列志向 (垂直パーティション)
- エクステントマップ (InfiniDB 特有の水平パーティション)
- 垂直水平パーティションによって必要なデータだけにアクセス

＊＊＊

エクステントマップとは？
- 列志向を進化させた InfiniDB の機能 (ディスクアクセスの最小化)
- 各列のエクステントに格納されているデータの最大、最小値を保持することでアクセス対象を絞込める
- 列データに対する索引の作成・見直し、メンテナンスが一切不要

＊＊＊

自動パラレル化 (CPU リソース有効活用)
- 完全に自動化されたマルチスレッド処理
- 自動パラレル化の検証
- データをメモリにキャッシュできている場合と、ない場合を実施
- できるだけ CPU をフル活用しようとしているのがみてとれる (すべての CPU が 100% 近い使用率)
- キャッシュで着てない場合は wait IO 分だけ CPU 使用率がさがっている

＊＊＊

超速バルクロード (CPU リソース有効活用)
- 160GB を 35min で
- : RDBMS よりは速いと思うが、 Hadoop とかと比べると全然遅いような気がする (規模にもよるのかも)

＊＊＊

開発・運用負荷軽減の観点から
索引・統計レス
- エクステントマップによって索引不要 (これは面白い...)
- オプティマイザ最適化のための統計情報も収集不要 (つまりインデックス最適化などを考える必要がない)
- ほとんどデフォルトのまま使えるらしい (ここは鵜呑みにしないほうがいいかなと)

＊＊＊

MySQL IF との融合
- MySQL アーキテクチャを踏襲した DWH なので MySQL の IF を使える
- InfiniDB は Storage Engine のひとつという位置づけ
- MySQL 5.1 がベース？
- UM と PM の2つで構成

＊＊＊

InfiniDB の投資計画
- 安価な IA サーバ1台からスタート可能
- 足りなくなったらスケールアウト (スケールアップも効果ある)
- 独立した SW によるメリット

＊＊＊

スケールアップの効果
- CPU リソースを追加することで、検索性能が向上し、期待通りの CPU スケールアップが可能

＊＊＊

80 core マシンでもスケールアップすることを実証
- 40core と 80core で比較し、性能向上していることを確認している
- DB online に検証した内容が書いてあるとのこと

＊＊＊

スケールアウトの効果
- PM node を追加することで各ノードにエクステントマップが分散されパラレル処理されるためスケールアウト効果を得られる

＊＊＊

ここまでの整理
- InfiniDB は高速、簡単、そしてスケーラブル

＊＊＊

検証に必要だった工数
- 環境準備にはほとんど時間がかかっていないとのこと

＊＊＊

更新処理の比較
- 列志向 DB は行志向と比べると delete, insert は苦手
- また列の数が多くなればなるほど insert は遅くなる

＊＊＊

システム構成における InfiniDB の位置づけ
- DWH : データを貯める場所として

＊＊＊

国内の利用者

＊＊＊

InfiniDB の進化の歴史
- 今年中に 4.0 をリリース予定
- 分析系の関数を多数追加予定 (windowing とか)
- データサイズ監視
- Hadoop 連携 (Sqoop)
- ネットワークトラフィック圧縮
- 半年ごとの major アップデートしてる感じ

＊＊＊

トライしてみようと
- OSS 版をインストールしたらいいんじゃないかな、と

14:00〜14:45 【C-2】あなたのビジネスを変える InfiniDBケーススタディ 10選

DWH 用途の DB という製品分野

＊＊＊

顧客から聞く DB 運用の課題
- DWH は構築と運用にコストと時間がかかる
- 汎用 RDBMS ではもはや期待するパフォーマンスがでない
- DWH アプライアンスは高すぎて手が出ない
- その中で
- DWH SW タイプは多様化が進んできている
- Cloud, SaaS/IaaS
- NoSQL, NewSQL
- そこで
- InfiniDB ってどうなのよ？という話

＊＊＊

市場動向
- ITR 社のレポート
- 大量データを素早く分析したいというニーズが高まる一方で、道具は多様化、選択肢が多くなっている
- Coud 上のサービス、擬似アプライアンス、従来型の RDBMS、 NoSQL 、 NewSQL 、 DWH アプライアンス、 OSS 、 InfiniDB

＊＊＊＊＊

InfiniDB の国内展開
- 2010 に U.S. で InfiniDB 販売開始
- 2012 に日本での正式販売、国内ユーザ 10 社
- 2013 : 3サーバ合計 24 core の大規模 DWH 運用開始、
- Public Cloud に対応 (AWS)

＊＊＊

具体例1. Cloud を使い尽くす
- 要件
  - 分析器版が必要
  - ツールもシステム資源も必要なときに必要な時だけ使いたい
  - 運用コストはかけたくない

＊

Cloud をつかうメリット、デメリット
- デメリット
  - オンプレとのデータ連携が大変
  - マシンリソース、 NW の不安定さ
  - 大規模で恒常的に使うと、高額請求される
- メリット
  - 定期的に最新化されるインフラ
  - 必要なときに必要なだけ
  - 運用負荷を最小化できる (バックアップなど)

＊

Nokia の InfiniDB 使用例 (InfiniDB 40core ライセンスをもってる)
- データ分析が必要になったら、必要な時だけ用意するという運用の仕方をしている (AWS 上で)
- また、 Hadoop との連携もやっている
- Hadoop から InfiniDB へ、 InfiniDB にたいして User が SQL 問い合わせという使い方

＊＊＊

国内の利用ユーザ (15 社 )
- YONEX, NOKIA, vodafone, いちよし証券 etc....

＊＊＊

InfiniDB 導入の実績
- 専門商社、通信、金融・証券、製薬、流通小売、宣伝広告
- とくにどの業態ということはない

＊＊＊

小規模から大規模まで
- 4GB から 1TB まで
- 4GB ... っていうのはどうなのか...
- ただ、システム構成の柔軟さが特徴という意味ではおもしろい実例
- シングルサーバ構成からマルチサーバ構成まで

＊＊＊

導入のきっかけ
- パターンA: 既存 DWH, DB の置き換え
- パターンB: 新規の DWH, DB の構築

＊

予算ない、 DBA いない、 Cloud 、性能でない、スモールスタートしたい、バッチ処理がおわらない、 Bigdata 試してみたい

＊＊＊＊＊

InfiniDB の導入事例
具体例2. DWH アプライアンスからの置き換え
- 要件：
  - 性能は同等以上を希望
  - 必要に応じて構成変更が容易か
  - コスト削減 (DWH アプライアンスは性能はでてもとにかく高い)

＊

進化した PC サーバが選択肢に変化をもたらしてきている
- SPEC のベンチマークを参照 : The Standard Perfomance Evaluation Corporation http://www.spec.org

＊

InfiniDB と数年前に買った DWH アプライアンスとの比較
3年前のアプライアンスなら InfiniDB が断然勝ったと

＊

最新の DWH アプライアンスと比較すると？
- コスト面での圧縮効果は、それほど大きくはないので、長期的視点が必要
- 移行費用があることを忘れないこと
- 性能面では十分な性能は出せる

＊

ランニングコストの比較
- 10年くらいをみるとアプライアンスは 5 年ほどで筐体ごと買い替えになるので、スケールアウトできる InfiniDB のほうが安くつく

＊＊＊

具体例3. Oracle Database との併用 (リーフレットにある内容)
- ランドスケイプ社の事例 : マーケティングシステム
- 更新は Oracle でこなし、検索は InfiniDB でこなすようなイメージ
- 一週間で導入し、本番利用開始したという驚異的な事例

＊＊＊

具体例4. システム担当者が不要？！
- 要件：
  - 全社規模の DWH 構築だが DBA はいない
  - 検索レスポンスは最速であるべし

＊

情報システムの担当者が少ない製造業の会社の例
- 構築はベンダーがはいるけど、運用をどうするのかという話だった

＊

InfiniDB では、開発・運用の妨げとなる DB チューニングが不要
- DB 内部の領域管理とデータ処理は自動的にチューニングされる
- : このへんは実際ためしてみないとなんともいえないだろうなぁ、と

＊＊＊＊＊

まとめ
- InfiniDB は廉価な PC サーバでも十分な性能
- 小規模から大規模まで汎用性高い
- Public Cloud でも使えるよ
- 評価のポイントは
  - 処理性能、初期コスト、運用コストの3つです。

15:00〜15:45 【B-3】MariaDB最新情報

MariaDB って今、どうなってるの？

＊＊＊＊＊

はじめに
- MySQL をめぐるあらたな歴史のはじまり
- Sun を Oracle が買収したことに端を発する (200904)
- 商用 DB デファクトの Orale が OSS MySQL をどうあつかっていくのか？が話題に
- Google Trend で MariaDB をみてみると面白い
- 2013 年終わりから特に伸び始めている
- 巨大企業が MySQL から MariaDB に乗り換え始めたのが大きな要因

＊

注目度が上がった要因
- Foundation の設立
- SkySQL が Monty Program AB と合併
- 最近だと Google が MySQL を MariaDB に置き換えたというニュースが大きかった (真偽はまだわからないが、少なくとも検討はしているということは事実であろうと)

＊

DB-Engines で DB 人気度、認知度ランキングでみると？
- 1 位 Oracle, 2 位 MySQL なんだが
- MariaDB はまだまだランキング低いがぐんぐんとランクをあげていっている
- MongoDB とかも同じような伸び率だそう

＊＊＊

MariaDB 関連セミナー集客状況
- OSC 東京において毎年、 120-130% の伸びで参加者が増えてる
- 2012 30 人が 2013 fall で 45 人 (そんなでもないのでわ…)

＊＊＊＊＊

MariaDB とは？
- MariaDB 誕生の背景
- 生みの親は MySQL の生みの親と同じ Monty 氏
- Save the People, Save the Product : MySQL に関わる人、 MySQL そのものを守りたいという意向表明

＊＊＊

MySQL/MariaDB をめぐる歴史
- 1995 に MySQL 登場
- 2008 Sun に MySQL AB 買収
- 2008 Sun から Monty 氏が抜けて Monty Program AB : MariaDB つくりはじめる
- 2010 Sun が Oracle に買収

＊＊＊

MariaDB とは
- MySQL の Branch となる OSS RDBMS
- 基本的には同じ、高い互換性
- MariaDB 固有の独自機能
- Community 版のみ (GPL v2)

＊＊＊

MySQL と MariaDB の互換性
- 最新の安定版は MariaDB 5.5.33a
- モジュールを入れ替えれば、 MySQL が MariaDB になる
- ファイル名、パス、ポート、ソケットなどは共通
- Client も同じものを使える

＊

非互換部分
- コンソールプロンプト
- 新たな SQL_MODE
- インストールパッケージ名
- Slowquery の表示内容 etc...

＊＊＊＊＊

MySQL と派生製品の系譜と最新状況
- 派生 DB : MariaDB & Percona Server
- 本家 MySQL 5.1/5.5/5.6 を軸に派生 DB が存在
- MySQL 5.1 をベースに MariaDB 5.1-5.3
- Percona Server はオリジナルの MySQL を踏襲、改善してリリースしている。
- そして、 MariaDB は 10.0 をだし、大きな方向転換をしようとしている

＊＊＊

MySQL/MariaDB のアーキテクチャ
- プラガブル・ストレージエンジン
  - MySQLは SQL エンジンと Storage エンジンの二段構成
  - e.g. MyISAM, InnoDB, InfiniDB, Spider

＊＊＊

ストレージエンジンの整理
- MariaDB にしかないストレージエンジン
  - Aria
  - FederatedX
  - CassandraSE
  - CONNECT (FederatedX 拡張)
  - Spider を標準に

＊＊＊

Aria
- MyISAM, MERGE, MEMORY の開発者中心に機能強化を推進中
- Select 性能はよいが耐障害性が低かったものを改善
- e.g. クラッシュセーフ、グループコミット、トランザクション、行コミット

＊＊＊

FederatedX
- Oracle でいうところのデータベースリンク
- MySQL 5.1.26 で開発ストップしていたものを修正、改善して世の中にだしている
- トランザクション、パーティション対応

＊＊＊

Open な開発基盤
- MySQL を常に Open な状態で保ちたいという志
- そのために Foundation の設立
- 外部ストレージエンジンの積極的なバンドル
- その結果として CassandraSE, Spider のバンドル

＊＊＊＊＊

Better MySQL
- MySQL よりももっといいものをつくるというのがコンセプト

＊＊＊

MariaDB はコミュニティとともに、を前面に
オープンな開発
- コミュニティサイトの充実
品質の追求
- code を読みやすく、コード記述、テストケース公開
JIRA で Issue 管理
- 対応更新が迅速、そして丁寧

＊＊＊

既存機能の強化
- 痒いところに手が届く機能拡張
- スロークエリに該当クエリの実行計画を同時出力 5.1-
- Information_schema にユーザ統計テーブルを追加 5.2-
- show processlist の拡張
- limit 句の拡張

＊＊＊

パフォーマンスへの追求
- オプティマイザ改良を中心に、より高速、大規模向けに
- Sub Query に対する改善は MySQL よりもはるかにはやく

＊＊＊

スレッドプール機能
- MySQL では Enterprise でないと使えない
- DB 内でのスレッド並列実行数を制御する

＊＊＊

MariaDB Galera Cluster
- 更新処理のスケーラビリティの向上
- 完全同期型レプリケーション
- マルチマスター Active-Active
- 全ノードで Read/Write 可能
- sysbench はノード追加すれば、リニアに性能向上する結果に

＊＊＊

LGPL クライアントライブラリ
- GPL を取り巻く問題＆リスク排除、より選択しやすくなっている
- 動的リンクしたアプリケーションのソース公開が不要に

＊＊＊＊＊

今後のロードマップ (10.0-)
- 最新バージョンは 10.0.4 ALPHA
  - コミュニティからのフィードバックを絶賛募集中
  - Open であることを強調することを前面に出すために、バージョンを大きく飛ばしてアピール

＊＊＊

CONNECT (10.0-)
- Federated エンジンのコンセプトを踏襲してさらに拡張
- MariaDB を Hub にして他の製品につなげるようにしよう
- ODBC で例えば　MS Access からつなげたり、と

＊＊＊

Cassandra (CassandraSE) (10.0.1-)
- Cassandra のデータを操作する View
- MariaDB から　Cassandra を操作可能

＊＊＊

Spider
- DB sharding を実現するストレージエンジン

＊＊＊

マルチソース・レプリケーション (10.0-)
- 複数のマスターを一つのスレーブにまとめる

＊＊＊

MariaDB Manager
- まだまだコンセプトベース

＊＊＊

MaxScale
- MySQL/MariaDB の効果を最大化する GW のようなもの

＊＊＊

MySQL/MariaDB の機能比較
- これは表になっている資料を参考にする

＊＊＊

MySQL (OSSDB) をとりまくユーザ動向
- ほとんどが Community Server を使ってる
- 基幹システムとしても使っている人がいる

＊＊＊

サポート問い合わせ内容の傾向
- パラメータ変更の影響調査を聞かれたり
- アップグレード時の注意点

＊＊＊

アシストのサポートについての宣伝
- MySQL, MariaDB どちらもできる
- 運用のコストをさげる手伝いができるということを強調

＊＊＊

アシストと SkySQL の Value
- 英語できるなら直接　SkySQL と契約したほうがいいっていう話

＊＊＊＊＊

MySQL も悪いといっているわけではないよ、そこは誤解しないでほしいとのこと
アシストはどっちもサポートしてるとさりげなくアピール

16:00〜16:45 【B-4】SQLとプロシージャからみたRDBMSの違い

スピーカーが著者の SQL 逆引き大全を執筆、その中から重要部分をピックアップ

SQL逆引き大全363の極意

posted with カエレバ

アシスト秀和システム 2013-07

Amazon

楽天市場

＊＊＊＊＊

はじめに
- なぜ、その書籍を執筆したのか？
- SQL は RDBMS 共通だが、それぞれの RDBMS 製品ごとに方言があったりする
- OSS DB も多岐にわたり、選択肢に多様化
- その RDBMS 間での違いをまとめてみようとおもった

＊＊＊

とりあつかってる RDBMS
- Oracle, PostgreSQL, PostgreSQL Plus Advanced Server, MySQL, MariaDB

＊＊＊

本資料の構成と目的
- DB の移行フローを題材
- 移行時に問題になりやすい SQL
- RDMBS 共通の標準　SQL や代替機能

＊＊＊＊＊

主な移行作業とフロー (5step)
- 定義移行
- データ移行
- アプリケーション移行
- 運用移行
- SQL チューニング

＊＊＊

定義移行
- 表作成時のデータ型指定
- 順序有無
- シノニム有無 (Oracle にしかないが)
- スキーマの概念 (PostgreSQL のみ扱いが違う)

＊＊＊

データ移行
- NULL と空文字の扱い (PostgreSQL と MySQL は NULL と空文字を別扱い, PPAS は制御可能)
- 日付書式の違い (MySQL は日付の書式が違う)
- Date 型での時刻が切り捨てされるか？ (PostgreSQL, MySQL は時刻は Date 型で切り捨て, 切り捨てたくないなら timestamp 型使え)

＊＊＊

アプリケーション移行
- SQL
  - 外部結合 ( (+) による外部結合は Oracle のみ)
  - MERGE (Oracle のみ)
  - LIMIT/OFFSET (PostgreSQL, MySQL のみ。 12c から Oracle も)
- 組み込み関数
  - RDBMS 間でそれなりに違いがある (関数名、指定方法が同じものは全体の 30% ほど)
    名前がちがったり、引数が違ったり、独自関数だったり
  - Dual 表は Oracle のみ
- プロシージャ : ストアドプロシージャもトリガーも基本的に使わないほうがいいと思っているので、移行もなにもないな、と
  せいぜい使っても一回ぽっきりの大きな処理のときくらいだと思っている
  - 機能面と記述面の違い
  - PostgreSQL にはプロシジャがない
  - トリガー有無
  - 配列の有無 : 基本的に配列なんて使ったらダメだろと思ってるんだが
  - バルク配列 (Oracle のみ)
  - 補足： Oracle から PostgreSQL へ移行を考えるなら PPAS がいいよ (Oracle 互換を高めているから)
- トランザクション
  - デフォルトのトランザクション (MySQL, PostgreSQL は auto commit / Oracle は任意の単位のトランザクション)
  - トランザクション中のエラーの対応 (PostgreSQL ではすべてを一回明示的に rollback してトランザクションを再実行する必要がある)

＊＊＊

運用移行

＊＊＊

SQL チューニング
- チューニングは各 RDBMS 共通
- チューニングのステップ
  - 高負荷 SQL 特定
  - 実行計画取得
  - 実行計画が最適になるようにチューニング
  - 意図した実行計画になるか？
  - 実際に SQL を実行し効果測定
- 効率、非効率な SQL のパターンはほぼ共通
  - 索引列に計算式を入れてしまったりすると index が使われない where hoge*1.1 = 1500 みたいなパターン
- サポートしている実行計画 (単一表走査と結合)
- ヒントの有無 (PostgreSQL はヒント句なし)