今日は Oracle さんの主催による MySQL :: MySQL User Conference Tokyo 2015 に参加してきました。
この形式でのカンファレンスは 5 年以上ぶりだそうですが、 Wifi および各席に電源完備、お弁当提供に、空き時間にはデモをしてくれたりと至れり尽くせり。コンテンツも充実、とても有意義な一日を過ごすことができました。
続きを読む#ChugokuDB MyNA/JPUG 合同DB勉強会 in 東京 に行ってきた #メモ #レポート #MySQL #PostgreSQL
今回は PostgreSQL, MySQL それぞれの NoSQL 機能にフィーチャーした勉強会、「ニッチだな、これは！」ってことで、MyNA・JPUG合同DB勉強会 in 東京に参加してきました。
個人的に PostgreSQL には疎いので PostgreSQL の最新事情とか聞けたらくらいのつもりでいってみたんですが、いい意味で変態的な勉強会*1でしたｗ
*1:ドタキャン率が 5 割という主催者泣かせのイベントだったようでしたが、、、ドタキャンした人たちは間違いなく後悔したであろう濃い内容の勉強会
MariaDB/MySQL のお父さん、きたる！ 第2回 MariaDB/MySQL コミュニティ イベント in Tokyo にいってきた
今日は、第2回 MariaDB/MySQL コミュニティ イベント in Tokyo
InfiniDB と MariaDB 、そして喜連川先生の特別講演が聞きたくて Database One Day Seminar に参加してきました
、 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 はやることが少なく、非常にシンプルに終わる - 表作成して、ロードしているだけ
- ベンチマークの前準備に行った内容、 160GB のデータをロードするのに行った作業、および時間を比較
＊＊＊
- ここまでのまとめ
- 行志向と列志向のちがいはデータの格納の仕方
- 列志向は情報系 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 を標準に
- MariaDB にしかないストレージエンジン
＊＊＊
- 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 であることを強調することを前面に出すために、バージョンを大きく飛ばしてアピール
- 最新バージョンは 10.0.4 ALPHA
＊＊＊
- 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 は 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 のみ
- RDBMS 間でそれなりに違いがある (関数名、指定方法が同じものは全体の 30% ほど)
- プロシージャ : ストアドプロシージャもトリガーも基本的に使わないほうがいいと思っているので、移行もなにもないな、と
せいぜい使っても一回ぽっきりの大きな処理のときくらいだと思っている- 機能面と記述面の違い
- PostgreSQL にはプロシジャがない
- トリガー有無
- 配列の有無 : 基本的に配列なんて使ったらダメだろと思ってるんだが
- バルク配列 (Oracle のみ)
- 補足： Oracle から PostgreSQL へ移行を考えるなら PPAS がいいよ (Oracle 互換を高めているから)
- トランザクション
- デフォルトのトランザクション (MySQL, PostgreSQL は auto commit / Oracle は任意の単位のトランザクション)
- トランザクション中のエラーの対応 (PostgreSQL ではすべてを一回明示的に rollback してトランザクションを再実行する必要がある)
- SQL
＊＊＊
運用移行＊＊＊
- SQL チューニング
- チューニングは各 RDBMS 共通
- チューニングのステップ
- 高負荷 SQL 特定
- 実行計画取得
- 実行計画が最適になるようにチューニング
- 意図した実行計画になるか？
- 実際に SQL を実行し効果測定
- 効率、非効率な SQL のパターンはほぼ共通
- 索引列に計算式を入れてしまったりすると index が使われない where hoge*1.1 = 1500 みたいなパターン
- サポートしている実行計画 (単一表走査と結合)
- ヒントの有無 (PostgreSQL はヒント句なし)
＊＊＊＊＊
- ANSI 標準互換 SQL 使えっていう話で、基本的に方言使うなってことだとおもっているので、参加することなかったな、というセッションだった。
17:00〜17:50 【T-1】（特別講演）データベースに携わる事は人類に貢献するという事 〜ビッグデータとデータベース〜
最後に喜連川先生による特別講演が！こちらは、とても素晴らしい講演だったので、それだけで別のポストをたてます。
では、今回はこんなところで。
Oracle に敵愾心丸出しのトーク爆裂な MariaDB/MySQL コミュニティイベント in TOKYO #mariadbtokyo に行ってきた
最初に雑感を書いておくと、
- 面白かった！
- SkySQL の方々が Oracle に敵愾心丸出しだったから。
- 個人的にはそこがとても面白いポイントでしたががが…
- 片方の意見だけ聞くのはフェアじゃないので、 MySQL@Oracle の方もスピーカーとして呼んでガチンコバトルしてくれたらもっと面白かったんだろうな、なんて思いました。
- でも、通訳の方、訳を間違い過ぎっすよ、と。
- 英語なら通訳いらないでしょとまで言う気は、最近の自分にはないですが（やっぱり訳があった方が楽なんで）、今回は申し訳無いですが通訳がなかった方がよかったんじゃないか、と思ってしまいました。進行もない方が押さないで済んだ気がします。
ちなみに開催場所は富士ソフト秋葉原ビルで、アジェンダは以下のとおりでした。
【アジェンダ】
- 12：30- 受付開始
- 13：00- "挨拶" Michael Carney氏 SkySQL Vice President of Sales
- 13：10- Colin Charles氏： "MariaDB 10 & MariaDB Foundationについて"
- 14：40- 斯波 健徳氏： "Spider Storage Engineの最新情報""
- 15：30- Ivan Zoratti氏： "MariaDB Manager and MaxScale New tools for MariaDB and the MySQL ecosystem"
- 16：50- （株）アシスト 花谷 俊英氏: "SkySQLサポートの事例について"
以下より、いつもどおり、わたしがとってきたメモを公開しておきます。
MariaDB 5.5 からいきなり 10.0 にジャンプした話や、 XtraDB を default storage engine にしようとしているといったあたりが聴き応えあったなぁ、といったところかな、と。
13：00- "挨拶" Michael Carney氏 SkySQL Vice President of Sales
- セールスパーソンなので手短に。
＊＊＊＊＊
- Origin
- SkySQL & MariaDB
- MySQL 自体は 1995 年に生まれた (企業であり、製品であった)
- Community と企業が同時に始まった (Linux のケースとは違い)
- その後、 2007 に MySQL は Sun に買収
- 2009 どう MySQL を発展の方向性の違いから Monty 氏が MariaDB を Fork
- MariaDB の Goal はいついかなるときにも OSS
- Oracle に買収されることを予期していたのかもしれない
- そして 元 Sun の MySQL 担当者たちが独立し SkySQL を立ち上げた (Monty氏と David 氏も出資)
- そして今年 (2013年)、 MariaDB のエンジニアリングをする会社とサポートをする会社もひとつの SkySQL になった
＊＊＊＊＊
- mariadb.org
- mariadb.com - commercial support
- skysql.com - mysql and mariadb support
＊＊＊＊＊
- SkySQL: serving the ecosystem
- 日本の法人は spiral arms とアシスト
＊＊＊＊＊
- Why SkySQL?
- 2 つのセールスポイント
- 契約の継続率 93%
- 顧客満足 5 点満点で 4 以上
- 2 つのセールスポイント
＊＊＊＊＊
- SkySQL Enterprise には Standard と Enterprise
- Oracle では対応できていない部分で数多くのカバレッジがある
- OSS の Extension (Audit Plugin, etc...)
- 400+ Customers in 34 Countories (Google )
＊＊＊＊＊
- Q1. スライド中の SkySQL の顧客リストは MySQL と MariaDB どっちの顧客か？
- 両方込み、です。
- Google に関して言えば、 MariaDB 。 Google は MariaDB に移ったから。
- 顧客ニーズにあわせて、 MySQL/MariaDB のサポートを行う
13：10- Colin Charles氏： "MariaDB 10 & MariaDB Foundationについて"
- まだ 9 日目の SkySQL のエヴァンジェリスト
- 13年のキャリアはずっと MySQL
＊＊＊＊＊
- 44 months major server releases (5.1, 5.2, 5.3, 5.5, Galera Cluster) and 10.0 series
- LGPL で多言語に対応
＊＊＊＊＊
- What is MariaDB?
- Community developed branch of MySQL
- Feature enhanced
- Fully compatible & feature complete with MySQL (どんな MySQL の新しい機能もすぐにadaptするという自信満々の発言)
- under MariaDB Foundation management
＊＊＊＊＊
- Ownership
- MySQL owened by MySQL AB -> Sun -> Oracle
- SkySQL is a major sponsor of MariaDB
- MariaDB governed by MariaDB Foundation
- maria-captains contains community like Sphinxsearch, Linkedin, Taobao, Facebook, Percona, Codership, & more (コントリビューターがこんなにいるんやで、と)
＊＊＊＊＊
- Aims of MariaDB
- Compatible, drop-in replacement to MySQL
- data on disk & on the wire the same
- same file names, sockets, port
- Stable (bug-free) releases with no regressions (信頼性高いぞ、と)
- GPLv2 (完全な OSS)
- Compatible, drop-in replacement to MySQL
＊＊＊＊＊
- Why MariaDB 10.0?
- The 5.5 merge took about a year (かかりすぎだ、と)
- in MariaDB 5.5 we have over 1.5M lines of extra code - 61M diffs
- MySQL 5.6 refactored with huge losses in commit history (どうしてその変更をしたのか大事だと思っているのに、と)
- We're not a patch set against MySQL (Oracle には負けん、と)
- MariaDB clearly does not depends on MySQL for future development
- The 5.5 merge took about a year (かかりすぎだ、と)
＊＊＊＊＊
- MariaDB 10.0 in a nutshell
- Built i MariaDB 5.5
- Backported features from MySQL 5.6
＊＊＊＊＊
- MariaDB History
- MariaDB 5.1 (MySQL 5.1 base)
- pool of theads は MySQL に先んじて導入していた
- MariaDB 5.2 (MariaDB 5.1 base)
- MariaDB 5.3 (MariaDB 5.2 base)
- Biggest changes to optimizer (当時の MySQL 5.5 の Optimizer の性能をはるかに上回っていた faster subquery, join, etc...)
- Replication (group commit, checksum for binlog event, consistent snapshot between engines, etc) ここ自信ありよ、と
- MariaDB 5.5 (MariaDB 5.3 + MySQL 5.5)
- Google や facebook の貢献
- MariaDB 10.0 のリリーススケジュール
- ALPHA版だが Taobao や Tumblr では Multi-source replication を prod で使っている
- MariaDB 5.1 (MySQL 5.1 base)
＊＊＊＊＊
- Backported features for MySQL 5.6
- performance schema などを MySQL 5.6 に対して Backport している
- MariaDB では Replication 機能を重視していることもあって Parallel Replication なども Backport してる
＊＊＊＊＊
- Only in MariaDB 10.0
- Multi-source replication
- Works from Taobao
- Many users partition data across many masters -> get those into a single slave
- Great for analytical queries, etc...
- Devops 向け
- explain for a running statement
- faster alter table
- per-thead memory usage
- CassandraSE, LevelDB support
- MariaDB as a "data platform"
- Cassandra as a Storage engine
- combine data between Cassandra & MariaDB & Oracle (SQL 操作可能？)
- write to the HBase storage also possible (?)
- Dynamic Columns
- allow users to create virtual columns with dynamic content for each row in table
- can get output with JSON format
- Segmented MySQL keycache
- Solves major read bottlenecks for MySQL
- 多くの read が発生するときに強力だと
- Engine independent persistent statistics
- すべての storage engine で persistent な実行計画を取得できるようにしてしているという
- (InnoDB だけについては Oracle はやったけども MariaDB はすべての Storage engine についてやるぞ、と)
- Subquery materialize
- DBT3 Automation Scripts - MariaDB Knowledgebase の結果があきらかによいと
- Group commit in the binary log
- fsync をグループ化して実行することによってよりよくなったという例
- 実施したベンチマークは facebook のものとのこと
- Group commit for the binary log - MariaDB Knowledgebase
- Theadpool 5.5 vs 5.1
- よりスケールするようになったというベンチマークの結果
- LINE やカカオトークなどではそのパフォーマンスを高めるのに好まれてる (使われてる？)
- PAM Authetication
- Linux, authentication using /etc/shadow
- LDAP, SSH, Kerberos
- SphinxSE
- 日本では groonga というのがあると思うが。こういうのもあるよ、と。
- GIS Support
- MySQL Geometiric Type は上手く対応できてないが、 MariaDB はできるぜ
- GIS features in 5.3.3 - MariaDB Knowledgebase
- Multi-source replication
＊＊＊＊＊
- MariaDB 10.0.2
- Support for atomic writes on FusionIO DirectFS
＊＊＊＊＊
- MariaDB 10.0.4
- SPIDER storage engine for database sharding
- Audit plugin
- perfomance schema is now matched with MySQL 5.6
- online alter
＊＊＊＊＊
- RoadMap
- MariaDB is already a superset of features in MySQL
- LGPL Client Lib
- works with MariaDB/MySQL/Percona Server
- C, Java
- ODBC is in the works
- MariaDB Galera Cluster
- Read, Write scalable
- No lag or lost transaction
- But currently based on MariaDB 5.5
- TokuDB
- Uses Fractal treee indexes instead of B-Tree
- Connect Storage Engine
- Benchmarks
＊＊＊＊＊
- Continued commitments
- Security
- Regression を起こさない努力 (確実に動作することを確認してから新機能は公開する)
- care about backward compatibility and introduce features carefully
＊＊＊＊＊
- Community involvemet
- Community を大事にするという表明
- Knowledge base の豊富さをアピール (全部英語だしおまえら読めるだろぉ)
- 1M download を今年は達成したい (ダウンロードしてくれってことか)
- Google や facebook
＊＊＊＊＊
- MariaDB is gaining popularity
- Wikipedia running MariaDB 5.5
- Google made public commitment to move to MariaDB 10
- Fedora, OpenSUSE as a MariaDB default
＊＊＊＊＊
- MariaDB deployed
- nginxorg said they reduce their infra cost $12000/year by using MariaDB (why?)
- other Mozilla
＊＊＊＊＊
- MariaDB Foundation
- the Biggest differece of MySQL and MariaDB
- 買収リスクは低いと
- その目標の最たるものは MySQL と MariaDB の互換性は常に担保していきたいということ
- キーパーソン
- simon@mariadb.org
- Jeremy Zawodny (High performance MySQL), Mike Milinkovich(Eclipse Foundation)
＊＊＊＊＊
- Well supported
- Oracle を除く OSS 企業が MariaDB をサポートしてる
- 各 GA を最低 5 年間サポートするぜ
＊＊＊＊＊
- User stats plugin
＊＊＊＊＊
- Compatibility with MySQL
- No NDB Cluster
- 10.05 以降では XtraDB を default storage engine にする計画がある (この情報はでかいな…)
＊＊＊＊＊
- FAQ
- 自信がないので資料の公開を期待
- とりあえず、 MariaDB に MySQL から移行して、戻りたいといってる人はこれまでいなかったということを強調していた
- 自信がないので資料の公開を期待
＊＊＊＊＊
- Conclusion
- MariaDB is binary compatible with MySQL
- Open bug system (discussions are all open)
- Oracle have 2. (one for open, one for their customer)
- OSS, feature rich, no commercial extention
- Info
- bugs mariadb.org.jira
- twitter: @mariadb
- slides: slideshare.net/bytebot
＊＊＊＊＊
- Q1. Audit Plugin の bug のレポートがあがっているが QA の体制はどうなってるのでしょうか？
- まだALPHA版なのでどんどん FB を募集中の段階、むしろウェルカム
- QA の体制は、レポートを受け取ったものにたいしてオープンに対応していく
- Q2. ホスティングサービスについて聞きたい。 MariaDB を RDS がサポートする予定はあるか？
- working progress but still not
- SkySQL is now trying to build partnership with AWS (but still not realized)
- In this moment if you really want built MariaDB on AWS, use AMI, you can do the same as RDS.
- A3. The reason why choosing jump MariaDB 5.5 to 10.0.
- There were too much bugs on MySQL 5.6 and it became difficult to refactoring 5.6 (lost commit history was very serious)
- And gave up for refactoring 5.6.
- このへんのことを言ってたのだと思ってるんだけど違ってたらごめんなさい
14：40- 斯波 健徳氏： "Spider Storage Engineの最新情報"
- MySQL/MariaDB のストレージエンジン
- MariaDB 10.0.4 から標準のストレージエンジンに
＊＊＊＊＊
- DB Sharding をストレージエンジンで実現するもの
＊＊＊＊＊
- 使い方
- Spider が bundle された MySQL/MariaDB を install
- MySQL にログインして install_spider.sql を実行
- あとはテーブルつくるだけ
＊＊＊＊＊
- Hack:
- MariaDB だと Assist table discovery というのをつかって、元テーブルの情報さえあれば、カラムを省略して spider テーブルをつくることができるらしい
- Create Server 構文をつかって接続情報を別だしで定義することもできる
＊＊＊＊＊
- Spider その他の機能
- 冗長化機能: テーブルパーティションの単位で冗長度を設定可能
- 耐障害性: MySQLで利用可能なものは利用可能
- 全文検索機能
- NoSQL 対応機能 (Hundlersocket plugin)
- Oracle DB 接続: DN に Oracle も混在させられる
- パラレル検索機能: (MariaDB では未対応) 直近のリリースでの機能とのコンビネーションで高速な検索が可能に
＊＊＊＊＊
- Vertical Partitioning: カラムレベルでのテーブル分割
＊＊＊＊＊
- Handlersocket Plugin
- Spider との組み合わせて分散 MySQL に NoSQL アクセスを実現
＊＊＊＊＊
- Mroonga Storage Engine
- 特徴：
- 高速な全文検索
- 高速な位置情報検索
- 検索中でも高速に更新可能
- Spider と組み合わせると分散したデータへの全文検索、位置情報検索が可能になる
- 2013-11-29 に個別の mroonga のイベントがあるのでそこでより詳細を
- 特徴：
＊＊＊＊＊
- MariaDB への bundle
- 結構時間はかかったがやっとこさいれてもらうことができた
- Mroonga も bundle を目指している
- ※ bundle はできたが、 MariaDB そのものに変更をいれてもらわないと動かないというところはあるとのこと
＊＊＊＊＊
- 地味だけど重要な改善の紹介
- spider_bka_mode=2
- BatchedKeyAccess という join を最適化する機能、そのオプション指定
- RDS を利用するとレプリケーション遅延が起こる事象があって追加したオプション
- 集計関数が速くなりました
- join と集計関数のなかに distinct がない場合、 count, max, min, sum が高速化 (DN で個別処理できるようになっているらしい)
- log_result_errors, spider_log_result_errors, spider_geeral_log, spider_xa_failed_log
- Spider が実行している処理をログにはけるようにした、トラブルシューティング用
- spider_bka_mode=2
＊＊＊＊＊
- より快適にするために
- sharding 優先だったところがこれまではあったが、これからはユーザビリティを上げていこうと思っているとのこと
- 管理ツールのようなものを考えている
- 考えていることは、 (提供時期は未定：年内目標)
- 既存のスキーマ設計のツールが使えるといい
- すでに構築済みの環境にも使える
- 既存の管理ツールと連携できる
＊＊＊＊＊
- MariaDB Foundation について
- 現在の MariaDB 開発の母体
- コミュニティーと連携しながら運営しているが、まだまだ議論しないといけないことがある
- ユーザ側の参加ももっとあったほうがいいと思っている
- ML: maria-discuss@lists.launchpad.net
- ML に参加するためには login.launchpad.net/+new_account でアカウント作る必要あり
＊＊＊＊＊
- まとめ
- Spider storage engine ではひとつの DB に接続するだけで他の DB のテーブルを利用できるようになる
- Spider は分割構成の設計の自由度が高いのが特徴
15：30- Ivan Zoratti氏： "MariaDB Manager and MaxScale New tools for MariaDB and the MySQL ecosystem"
- MariaDB Manager と MaxScale についての説明
＊＊＊＊＊
- MariaDB Manager
- MariaDB Server(s) を管理するためのものという位置づけ
＊＊＊＊＊
- MariaDB Reference Architecture
- まず MariaDB Servers
- そして HA が求められることが大きいため 2 つの選択肢を提供している MHA (松信さんの) か Galera
- さらにその上に、 Maxscale
- そしてこの MariaDB Server(s), MHA, Galera, Maxscale の4つでもって MariaDB Cluster と呼んでいる
- MariaDB Manegaer としては
- Monitor, API(RESTfulなもの), GUI そして Configuration & Provisioning 機能も。
- （これらの環境をダウンロードしてから 15min で使えるようにできることを目指している。）
- これらすべて OSS だが、サポートがほしければ MariaDB Enterprise 契約が必要
＊＊＊＊＊
- What is MariaDB Manager?
- set of servers used to provision, admin, monitor mariaDB servers
- can be co-located with MariaDB
＊＊＊＊＊
- MariaDB Manager Architecture
- 各 MariaDB サーバ上に agent がうごいていてそれを monitor が見ていて RESTful API 経由で各 IF に monitoring 結果を返す
＊＊＊＊＊
- MariaDB Manager Components
- Server agent (shell script)
- Monitoring daemon (java)
- Admin scripts (shell)
- API server (PHP)
- Apache-based
- RESTful API
- GUI Server (java, tomcat, Vaadin): this is not mandatory (can use chef, puppet instead of this)
＊＊＊＊＊
- MariaDB Galera Cluster
- Provisioning: this is possible only 1 click from GUI server
- Monitoring: can get GLOBAL STATUS & VARIABLES, and customized SQL Queries also enable to use. API and GUI.
- Adminitstoration: Basic admin stuff is possible from API or GUI (e.g. start, stop, restart, retrieving MariaDBs status etc...)
＊＊＊＊＊
- MariaDB Manager Examples
＊＊＊＊＊
- Introducing MaxScale
- What is MaxScale
- middle layer server that stands between a client application and a database servers
- similar for mysql_proxy
- efficient event-based, IO dispatcher that can be used to capture .... (書ききれなかった)
- What is MaxScale
＊＊＊＊＊
- MaxScale Architecture
- Data Store
- <-> Backend
- <-> MaxScale: Server(-Monitor), Service(-Router, Auth), Listner
- <-> Frontend
- <-> Client App
＊＊＊＊＊
- Support and Availability
- Available on major linux distributions (RHEL, CentOS, debian, ubuntu...)
- Support for MySQL 5.5 & 5.6, MariaDB 5.5 & 10
- MySQL/MariaDB replication ....
＊＊＊＊＊
- Routing & Services 以下の4つにフォーカスして提供を検討しているらしい
- Connection load balancing
- Statement load balancing
- NoSQL like sharding
- Full sharding
＊＊＊＊＊
- Connection load balancing
- Advantage:
- local auth
- reduced number of idle connection (differenct from HA_Proxy)
- redirection only to the reachable nodes(slaves)
- Advantage:
＊＊＊＊＊
- Load balancing for multi-master
- Advantage
- local auth
- improved scalability
- reduced number of idle connections
- improved availability
- Advantage
＊＊＊＊＊
- Statement load balancing
- using TRC - Table Replication Consistency Argorithm keep consistency of the replications
- Seems MaxScale working like a GW.
＊＊＊＊＊
- NoSQL like sharding
- Each node have a lookup tables, and this case it is possible to write data data into each shards.
＊＊＊＊＊
- Authentication
- Local MySQL authentication
- External authetication (PAM, LDAP, Keystone)
- Mixed authetication
- MySQL authentication mapped to external authentication
＊＊＊＊＊
- Configuration & Membership
- can configure/reconfigure in real time
＊＊＊＊＊
- Auditing & Logging
- Logging at connection or statement level
＊＊＊＊＊
- Connection/Statement firewall
- Blacklist and whitelist operation based on rules (Some type of rules existing, like protocol, client, auth etc...)
＊＊＊＊＊
- For more info.
- mariadb.com
- downloads.skysql.com/archives
- bugs.skysql.com
- yum repository (みえないがあるってことで)
＊＊＊＊＊
- Q1. How to realize MaxScale HA?
- Stateless itself. In this moment if you want HA, you need to prepare active machine and standby machine. Pacemaker is one of the option.
16：50- （株）アシスト 花谷 俊英氏: "SkySQLサポートの事例について"
- SkySQL ってどうなんよ？という話。
＊＊＊＊＊
- SkySQL とアシストとの関係
- サポート仲介業 (Cloudera と NTT-data の関係みたいな感じ)
- 英語ができるならちょくで SkySQL と話せばいいと本人たちもいっていた。そりゃそうだ。
＊＊＊＊＊
- SkySQL サポートの強み
- MariaDB/MySQL ともに熟練のエクスパート
- 高品質なサポートスキルとスピーディーな対応
- グローバルに 24/7 対応
参考：
- GoogleがMySQLからMariaDBへ内部データベースを乗り換えか − Publickey
- #2013-10-10 追記
他の方のポスト
- Life with open mind: MariaDB / MySQL コミュニティイベント in Tokyoに参加しました
- #2013-10-11 6:34 追記
