11gR2からGROUP_CONCAT（複数行をまとめて1列に）が可能に

以前にMySQLのGROUP_CONCAT関数についてのエントリーを書いていたのですが、あれから5年。

1対多の関係を持つ親子テーブルがあった場合、1つの主キーに対して結合結果が複数行になることはよくあると思いますが、
MySQLでは上記の関数を使うことで複数行内の列をひとつの文字列としてまとめることができます。
・
・
・Oracleでも出来なくはないんですが、かなり面倒なんですよねぇ。

Oracleでも11g R2から同様の集計関数 LISTAGGが追加されており、容易に対応が実施できるようになりました。

まず私の目を惹いたのは、LISTAGG（LIST AGGREGATE）です。簡単にいうと、グループ化された行に存在する値を集約し、1つのリストを生成します。
従業員のリストを例にとってみましょう。LISTAGGはCOUNTの機能のように、この表を集約し、すべての文字列を1つの大きな文字列に連結してくれます。

LISTAGG(集約対象の列名, セパレート文字列) WITHIN GROUP (order by 集約対象をソートする順番の列(指定なしの場合はnull))

日本MySQLユーザー会 2014年10月15日

先日、日本MySQLユーザー会10月に参加してきましたので、そのレポなど。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション１　MySQL Centralで発表された内容
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

MySQLの開発人員は買収後も増加している。
昨年も5.5から5.6へのバージョンアップを果たした。
現在、5.7.5（DevelopMent Release）を出している。
一部の機能追加はEnterprise版（商用版）のみ対象となる。
　→監査ログを取るEnterprise Audit機能や
　　マルチスレッドのEnterprise Scalabilityなど。

現在でも用途はWebサーバのバックエンドが多い。

事例：Facebook
　　　Twitter
　　　Dropbox
　　　Booking.com
　　　組込の分野→Ciscoの機器内のDB
　　　Adobeソフトウェア内のリポジトリDBなど

よく聞かれるが、Oracle Databaseに近づける、という思想はなく、
現在のまま、Webサーバのバックエンドとして活躍していく流れを想定している。

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

What’s New 5.7

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

●5.7の主な改良点

・InnoDB：トランザクション処理性能、可用性、IO性能向上
・Replication：性能と可用性の工場
・fabric：
・Optimizer：より詳細なExplain,パーサの改善
・GIS：InnoDBのSpatialインデックス、Boost.Geometryとの統合

　・バージョンが進むにつれ、高負荷時の性能改善が図られている。
　　→　Sysbenchの結果の向上の図
　・Linux/UNIX環境でのSyslogサポート
　・サーバーサイドでのSQL文タイムアウト（セッション単位でも変更可能。）
　・GISとの統合
　　・独自コードの置き換え（空間図形情報の計算、分析）
　　・WorkBencheで地図情報を参照可能
　・Windows環境の強化（MySQL for Excelなど）
　・コミュニティレポジトリも用意した。GitHubへソースの掲載も実施。
　・MySQLクラスタの起動時間改善
　・MySQL Enterprise Edition
　　→　MySQL Enterprise Encryption
　　　→　MySQLの暗号化ライブラリ
　　　　　（AES256による暗号化、公開暗号鍵による暗号化など）
　　　→　Oracle Enterprise Manager for MySQL
　　　　　（OracleのEMからMySQLの監視ができる）

【KKZ感想】
　　Syslogサポートは運用面でいいかも。fluentdとかと組み合わせる？
　　MySQL for Excelとか逆に闇しか感じないが、
　　その領域がMySQLの領域ともなってる気がする。
　　Workbenchは6.2でかなりフレンドリーになってるので、
　　DB専門じゃない人にも使ってもらいたいツール。
　　SQL Developerとかよりははるかに軽く、
　　PGAdminよりはわかりやすいし見やすい。
　　性能や可用性の向上の実感は仕事で使ってみないと何とも。
　　実行計画（オプティマイザ）がだんだんマシになってるのは感じる。

●実験版(Labs)での変更点

・オプティマイザの新コストモデルにより、ストレージエンジンでの処理を改善
　→　より正確で動的なコスト見積もりができるようになる。
　　　キー参照、テーブル、レンジスキャンなど
・FusionIOを使った場合のストレージIO性能を向上させている。
　（ページレベル圧縮など）
　→　InnoDBデータ、システム表領域、UNDOログ
・グループレプリケーション
・ネイティブパーティショニング
・32K 64Kページのサポート
・TABLESPACEのサポート
　→　複数テーブルをユーザーが定義した表領域に格納可能とする
・マルチソースレプリケーション
　→　複数のデータ元からレプリケーションする）
・スキーマ内マルチスレッドスレーブ
・グループレプリケーション
　→　共有ディスクをつか合わない擬似同期レプリケーション
・各種メタデータをデータディクショナリで一元管理する流れを導入する。
・HTTPプラグイン for MySQL
　→　REST APIから直接SQLを叩いて結果を取得できる

【KKZ感想】
　　実験版の中ではネイティブパーティショニングと
　　オプティマイザの新コストモデルが面白そう。
　　Oracleのオプティマイザにもある、動的統計が組み込まれるっぽい？
　　HTTPプラグインはURLにGETパラメータでSQLを渡すと、
　　結果をJSONで返してくれる模様。
　　ちょっとしたREST API試すだけならサーバ側アプリ書かなくて
　　済むかもしれない。要調査。
　　（http://blog.ulf-wendel.de/2014/mysql-5-7-http-plugin-mysql/　…

●性能について

・memcachedを使った場合の性能が5.7で改善されている。
　（高負荷時に6倍以上改善）
・秒間接続数による負荷も低下している。
・クエリリライトプラグイン（開発中）
・JSON形式でoptimizerの実行計画を出せる。
　Workbenchでグラフィカルに参照可能。
・5.6で強化したPERFORMANCE SCHEMAの情報を
　さらに詳細に取れるように機能追加している。
　上記スキーマの情報を整理・管理しやすくするため、
　SYSスキーマを導入。

【KKZ感想】
　　地味にWorkbenchでグラフィカルな実行計画見れるのは助かる。
　　リリースしてから放置して運用するというより、
　　できるだけDBAがきちんと性能もメンテする(拡張していく)のが
　　MySQLの使い方な気はするので、INFORMATIONスキーマや
　　PERFORMANCEスキーマ、SYSスキーマの導入はありがたくなりそう。

●MySQL Fabric 1.5

・OpenStackとの統合
　　・クラウド環境での運用効率化
　　・管理情報をOpenStackから取得してくる
・高可用性
・シャーディングによる拡張性

【KKZ感想】
　　高可用性とスケーラビリティ、クラウド対応の話。
　　現状その規模で触ったことないけど面白そう。

MySQL最新情報セミナー 2014秋にてこれらの詳細を発表する予定
（日本オラクルのページで参照）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション2.1　MySQL Central ユーザーレポート
　SCSK株式会社　池田さん
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

写真をベースに会場の様子の報告（レポート割愛）

Facebookは３０人くらいの運用チームで数万台のサーバーを管理している。
最近、5.6にアップデートを完了した。
その他、Facebook独自の機能拡張を行っており、その発表があった。

関連としてWebscale SQLのセッションもあり。
　※　WebScale SQLは、Facebook、Google、Twitterなどの
　　　MySQL利用企業によるソースの改造をMySQL側に還元するための
　　　コラボレーション。スケーラビリティやパフォーマンスの向上が主。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション2.2 MySQL Cluster Casual Talk
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

・InnoDB on Disk Strage with InnoDB Ruby
　→　InnoDBファイルフォーマットをパースするRubyスクリプト
　　　MySQLっぽい変態セッション

・現在のいろいろな機能改善はInnoDBメインで開発されていってる
　（反面、他のストレージエンジンはお察しください）

・Yahooは自前でMySQLのモニタリングシステム組んだらしい。へー。

・大量のMySQLサーバを利用するような運用では、
　MySQLのユーザー管理にユーザー管理にPuppet使ったりしている。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション2.3 MySQL Cluster 7.4.1 DMR
　櫻田さん @tsakurada
　http://www.slideshare.net/mobile/TakeshiSakurada/my-na201410…
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

MySQLクラスターのデータノードは起動時にメモリに全部読み込むので、
起動時のパフォーマンスが問題となっていた。

すべてがインメモリだと保存性・冗長性がないので、
ファイルに保存を行うローカルチェックポイントを使っている。
このローカルチェックポイントのファイルなどを利用して、
スピーディーに起動をかけるような仕組みか？

・1100万レコード存在するテーブルをmysqldumpで取り出して投入
（E5620 ×2　8GBの環境）

・サンプルテーブルは複合インデックスを含む

・コンカレーションエグゼキューションスレッド4と8で試してみた。

・結果：7.1→7.2では遅くなっている。
　7.3→7.4.1の比較で考えるとCXT=4の場合はいまいちだが、
　CXT=8の時はかなり早くなった。
　7.1の頃と同レベルのスピード。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション2.4
　市井さん　@ichii386
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

・MySQL FabricはOpenStackと連携できたらしい
　AWS、RackspaceもOK。
　（Openstackは一部は動くようになっている）

・Solaris 11.2がリリースされている（半年前）
　OpenStackが統合され、Solaris固有の仮想化に
　便利機能がDriverとして使えるようになった。

・SolarisとMySQL Fabric でHAにできるんじゃないか？
　→　実験中。

・ところでMyISAMどこ行ったの？（会場笑い）
　→　MyISAM is No Future - Sunny(MySQL開発者の偉い人？)

・仕事ではログ分析とかでMyISAMを使っている。
　InnoDBとはワークロードのかかり方が異なる。
　・MyISAMのメリット
　　・自分でBuffer管理するよりOSに任せたほうがよくね？
　　　→　innoDBでも性能向上の取り組みは大きな要素。
　　　　　今後のバージョンアップでどんどん変わっていく。
　　　・ibdのファイルサイズ大きい
　　・トランザクションとか別にいらないシステムもある。
　　　(ロックとかの)オーバーヘッドがない方がいい。
　　　→　innoDBでもRead Onlyトランザクション使えばよくね？
　　・MRG_MyISAMとかもある
　　　→　パーティショニングとか今後はNativeになっていくよ〜

・結論：MyISAM、ちょっと不安になってきた。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション2.4 InnoDB Adaptive Flushing
　瀬島貴則さん
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Oldest Pageについて
MySQLではバッファプールをページという単位で管理している。
そのページがダーティになった最初のイベントが
oldest_modificationというページの管理領域に書込まれている。
ダーティページをフラッシュしてディスクに同期させると、
そのページのoldest_modificationが0になる。

バッファプール上のページは2種類のリストで管理されている。
　・flush listは更新された順に管理
　・LRU listはすべてのページを対象に、参照された順に管理

ログ上に出力されるLast checkpoint atの進み方と
ディスクIOのワークロードは必ずしも同期しない。

Redoログの進み具合を管理するいくつかのパラメータ
　・innodb_adaptive_flushing_lwm
　・innodb_io_capacitiy
　・innodb_io_capacitiy_max

io_capacityは5.5と比較して意味合いが変わったと思う
dirty page のflushはこの値だけで決まってくるわけではない。

InnoDBでマスタースレッドと呼ばれるスレッドはこなすタスクが多かった
（ダーティページのフラッシュ、バッファの変更、パージ）
5.6ではそのへんの処理を複数のスレッドに分割した。

5.6からはinnodb_lru_scan_depthで指定されただけ、
フリーページを残すようになった。
Page Cleaner Threadがflush listを見て
dirtypageをフラッシュするときの挙動が5.6から賢くなった。
innodb_adaptive_flushing_lwmを超えない限りは
積極的には書かない（write combiningを狙う）。

transaction logの残量を見て、
1秒間にフラッシュするページの数をコントロールするようになった。
　→　SSDに書き込むときにこまめに書きすぎると性能に影響が出るため、
　　　ある程度まとめて書き込む挙動を狙っている。

　→　パラレルフラッシング：ダーティブロックの数が
　　　進んでいく数とかを見て可能ならまとめて書くように按分する。
　　　上記のような挙動に加え、
　　　5.7ではIOスループットが安定するように修正する方針。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション３　InnoDB Rubyの紹介
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

InnoDBのデータファイルを解析して、
情報を出力するRuby GEMパッケージ。

インストールはGEMで一発。
$ gem install innodb_ruby

$innodb_space -s ibdata1 space-page-type-summary
　→　テーブルスペースファイルを取得して情報表示するコマンド。
　　　UNDO_LOGやINDEX領域の使用率などが出力される。

$innodb_space -s ibdata data-dictionary-tables
　→　データディクショナリのファイル情報が出力される。

$innodb_space space-page-type-summary

$innodb_space -f d1/t1.ibd space-page-type-regions

$innodb_space page-illustlate
　→　ファイルの中身が一覧で色分けして見れる。
　　　(旧Windowsのデフラグみたいな出力。)

$innodb_space index-recurse
　→　インデックスの構造が直接見れる。（リーフの状態など）

$innodb_space record-dump
　→　レコードの中身を直接見る

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
セッション４　MySQL Security(Enterprise Encryption)
　　　　杉山真也　@RDBMS
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

・本題に入る前にHTTPプラグインのお試し
　　Curlから直接HTTPのURIにSQL文を入れてアクセスして、
　　JSONで値が返却される様子のデモ

Enterprise版ではない機能として、共通鍵暗号化の紹介。
　→　AES暗号化（AES_ENCRYPT、AES_DECRYPT）
　　　session.block_encryption_modeで
　　　AESの暗号化強度を変更可能。

Enterprise版独自機能として非対称暗号がある。
　create_asynmetric_priv_keyファンクションでPrivate鍵の発行
　create_asynmetric_pub_keyファンクションでPulic鍵の発行
　ASYNMETRIC_ENCRYPTファンクションと
　DECRYPTファンクションで非対称で暗号化
　より強度の高いRSA1024の暗号化なども可能

Android Studio 0.8.0のWindows環境での日本語化＆その他設定

最近仕事とは全く関係ないですが、ちょこちょことAndroidのアプリ作りに挑戦しております。

Eclipse使ったり、IntelliJ IDEA使ったりとあまり落ち着かない感じですが、
今後はGoogleさん的にもAndroid Studioに流れていきそうなので、
今後を考えるとAndroid Studioに慣れておいて損はないかなぁ、と思ってます。

で、思ったより設定に苦戦したのでメモ。

元ネタは以下のサイトです。(こちらはMac OS環境ですが)

IntelliJのIDEをある程度日本語化しよう(Android Studio, PhpStorm等)
http://qiita.com/tukiyo3/items/f245744c4c18259016f9

Android Studio 0.8.0のWindows環境での日本語化

0. 前提条件

Android Studioのバージョン： 0.8.0(0.8.2) インストール先： 『C:\android-studio』
Pleiadesのバージョン：1.5.2
OS：Windows 7 Professional (64bit)

1. Android Studio のフォント変更

『File』 ⇒ 『Settings』 ⇒ 『Appearance』 で外観設定ページを開きます。
『Override default fonts by (not recommended):』のチェックをONにし、
『メイリオ』、サイズ『11』を指定します。

とりあえずいったんAndroid Studio を終了してしまいましょう。

2. Pleiades.jarのダウンロード

Pleiades - Eclipse プラグイン日本語化プラグイン
http://mergedoc.sourceforge.jp/

Eclipse同梱版ではなく、pleiades.jar単体でダウンロードしてください。

3. ダウンロードファイルの展開

ダウンロードしたPleiades.jarファイルを展開します。
すると、以下のようなディレクトリが出来るはずです。

上記のフォルダの中から、『plugins』配下の『jp.sourceforge.mergedoc.pleiades』フォルダを
『C:\android-studio\plugins』にコピーします。

なお、Android Studioのデフォルトインストール先は『C:\Program Files(x86)』となっていますが、このフォルダ名だとAndroid Studio起動時にPleiades側でエラーになってしまうため、例のようにルート直下に配置した方が良いかと思います。

4. Android Studio起動時VMオプションの書換

Android Studioの起動VMオプションはEclipseと異なり、
『studio.exe.vmoptions』『studio64.exe.vmoptions』となります。

インストールしたOSが32bit系の場合は『studio.exe.vmoptions』、
64bit系の場合は『studio64.exe.vmoptions』の末尾に以下の文言を追加します。

-javaagent:../plugins/jp.sourceforge.mergedoc.pleiades/pleiades.jar

5. Android Studioの起動

これでAndroid Studioの一部のメニューが日本語化されているはずです。
(Eclipseに同名のメニューがある場合は日本語化され、そうでない時は英語のまま)

体感３〜４割くらいの日本語化ってところですかね？

で、ようやっと日本語化はできたんですが、やっぱり所々おかしな挙動をする事も多く、
ぶっちゃけある程度慣れたら外してしまった方が良さそうな感触(´・ω・｀)

その他Android Studioのいろいろな設定

SDKの設定

デフォルトでは、Android Studioのフォルダ配下にAndroid SDKが追加されますが、いろいろAPIバージョンに合わせたファイルを重複で入れていると2GBとか無駄な容量を食ってしまうため、出来れば統一したいところ。
『Platform Settings(プロジェクト構造)』 → 『Android SDK』の『SDK Location』からAndroid SDKのフォルダを別に指定します。
JDKの設定もこちらから出来るのでお好みに合わせてどうぞ。

コードフォーマッタの設定

Eclipseといろいろと異なる部分はあるのですが、Android Studioはコードフォーマッタの設定もかなり充実してます。かなり好みや文化に依るところは多そうですが、以下の記事を読んでおけばとりあえず困る事はなさそう。

Android Studio最速入門〜効率的にコーディングするための使い方
コードフォーマッタの設定
http://gihyo.jp/dev/serial/01/android_studio/0041

[Android Studio] 快適にコーディングできるように設定をカスタマイズしてみた
http://dev.classmethod.jp/smartphone/android/android-studio-customize-settings/

2015/4/15 OSSユーザーのための勉強会 #6 PostgreSQL と MySQL

に参加してきたのでざっくりメモ。

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

■ MySQLの優位性 SCSK 池田徹朗

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

SCSKでは2003年からMySQLを推進している。

Q1.ユーザ企業かITベンダ企業か
→A.会場内3割くらいはA。

Q2.どんな使い方か？
　自社システム選定→10名位？
　お客さまに製品提案販売→数名
　構築・開発→半分くらい？
　保守・運用→ぼちぼち

　→参加者の幅が広い事の確認

PostgreSQLとMySQLのどちらを採用すべきか？
　→全ての人にMySQLをお勧めする。

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

10の理由ネタ

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

・ソースコードの公開
　→ソース公開されているとgdbによる動的解析が出来るようになる。
　　(トランザクションログのfsyncを引っ掛けるなど)

　→DB起動処理の関数コールグラフを出す、など。

　→調査研究フェーズではドキュメントに無いことも把握できる。内部構造の解析もできる。

　→システム開発フェーズでは実装が気に入らない場所が治せる。不足部分も追加できる。

　→システム運用フェーズでは、バグの厳密な調査や修正パッチの提案が出来る。

　→SCSKによるMySQL拡張事例
　　　日本語全文検索、
　　　audit_pluginインターフェースによる監査ログ出力(今は本体機能として実装済み）
　　　CP932文字コード対応。Ruby対応（MySQL/Ruby、Ruby/MySQL)
　　　CPUスケーラビリティの改善。

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

・低コスト

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

　→TCOの差が大きい。
　　Airline Analogy 「座席のクラスに寄って乗りごこちは異なるが時間は同じ」
　→インストールの容易さやチューニングのわかりやすさ。
　→運用現場でも保守や解析で試験環境を作るのが容易で楽。
　　起案して稟議して資産管理して・・・エンジニアにはやりたくない仕事だらけ。

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

・製品レベルの進化

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

　→バージョンアップが早い。機能追加が多い。

　→ソフトウェアにおける破壊的イノベーション。
　　時間とともに要求性能が上がってくる。
　　商用ソフトはハイエンドで求められる性能を上回るスピードで性能拡充されていくが、
　　OSS DBも遅れて追いついていき、ローエンドなどに適用できるチャンスが広がっている。

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

・信頼性/安定性

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

　→mysqldが落ちるケースはあまりない。(HW障害等を除けば)
　　実運用でmysqldが落ちた例：
　　　CPUキャッシュ制御の不具合によるメモリエラー。
　　　32bit時代にメモリ空間不足。
　　　HAソフト誤検知による強制停止。

　→高信頼性のための機能。
　　・innoDB Drouble Write
　　・innoDB Read ThreadによるDiskからのPage読込時の破損チェック
　　・関数呼出時のAssertionによるメモリエラー検知。
　　　(関数起動時にパラメータチェックなどをしている)

　→信頼性に対する懸念。
　　(OSSだとOSの問題はあまり対策としてDB機能には追加しない考え方が多い？)

　→MySQL Cluster
　→MySQLの単体性能の高さ。バージョンの進化とともに性能も上がっている。
　→MySQLのレプリケーション機能。OracleのStandbyデータベースのようなもの。
　　これを利用して参照系負荷分散構成を組んだりする。(Facebookなど）
　　1秒あたり1120万行の更新。
　　1秒あたり6060万回のSELECT。
　　1秒あたり25億行の読み込み。
　　1秒あたり2420万回のDisk IO。

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

・豊富な製品群

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

　→PerconaやAmazon RDS for MySQL
　→MySQL Enterprise Monitor、Query Analyzer
　→MySQL Enterprise backup（オンラインバックアップ）
　→MySQL Utilities(各種スクリプト群、レプリケーションや自動フェールオーバーなど)

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

・MySQLの組み込み

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

　→デフォルトで対応してる製品が多い。
　　Adove Creative Suite、ガルーンやCloudstack、RedmineやMovable Typeなど。

　→大規模だとFacebook,Twitter,Paypal,LinkedIn,mixi

　→企業では新生銀行(CRM)、
　　楽天証券(オンライントレード)、
　　NTTコムウェア(コンビニ収納代行)など
　　政府系ではインドの国民総背番号制度のシステム、海軍のシステムなど。

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

・人気

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

　→DB Enginesサイトでの人気ではOracleに次ぐ２位。
　　PostgreSQLはSQLServerに次ぐ４位。
　→国内シェア(IPA調査 2009年)はPostgreSQLよりも高い。

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

・エコシステム

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

　→批判や懸念もあったが、Oracleを中心としたエコシステムができている。
　　Oracleの販売パートナーは2万社あるため、販路の拡大が大きい。
　　1000人近い開発者がいるという噂。昔は50人程度だった。

　→離脱した人もPerconaやMaria、SkySQLなどいろんな製品を出している。

================================================================================
■ PostgreSQLの優位性 アシスト 喜田 紘介
================================================================================

・直前のセッションを受けて
　→MySQLの人気が高いです、という話ですが、
　　インストール数は(MySQLの構成上)台数が多くなりやすいから、そのせいもあるのでは。
　→監査ログの機能はPostgreSQLはちょっと確かに弱い。

・クイズ「早いのはどれ」
　・1億件のデータ更新→PostgreSQL＞Oracle＞MySQL
　・1億件の集計処理→Oracle＞PostgreSQL＞MySQL
　・1億件のランダム一意検索→MySQL＞Oracle=PostgreSQL

　　Oracle 高い可用性、更新負荷分散、自動管理機能
　　PostgreSQL 質実剛健、 複雑なSQL、多彩な機能拡張
　　MySQL 軽量・高速、参照負荷分散、Webアプリケーション

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

・PostgreSQLのDBMSとしての作り

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

　　PostgreSQLは行単位ロック。エスカレーションのない行ロック。
　　読み取り一貫性は追記型なのでサポートしやすい。
　　(新しく追加された行は追記し、
　　 過去のデータを見てるトランザクションは前のレコードの物理配置を見ればよい)

　　表スキャンの種類
　　　Seq Scan、Index Scan、Bitmap Scan

　　結合の種類
　　　ネステッドループ結合、ソート・マージ結合、ハッシュ結合

　　特殊なデータの扱い
　　　GISシステム。地理情報システムといえばPostgreSQL+PostGIS。

　　他のデータとの連携。
　　　Foreign Data Wrapper。postgres_fdw、file_fdw, Oracle_fdw

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

・PostgreSQL都市伝説を追う

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

　→レプリケーション機能が毎バージョンごとに強化されていっている。
　　正副の入替え。

　→追記型のデメリットは8.xで改修された。
　　自動VACUUMやHOT、Visibility Map/Free Space Map、VACUUM FULLの仕様変更など。
　　悪名高きテーブルロックのVACUUM FULLは既に改善済。

　→追記型の弱点である索引の更新が必要になる点はHOTで対処。

　→パーティショニング機能、レプリケーションによる参照負荷分散機能、Materialized View(9.3〜)

　→パラレルクエリは開発中。

　→pgAdmin3、PostgreSQL Studio(Webベース)
　　監視ツール pg_monz
　　自動メンテナンス系のツールは開発中。

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

・イマドキ構成の紹介

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

　→シングル構成でもCPU性能が高い。DiskもRAMも潤沢に積んでいることが多い。
　　CPU 2CPU/8Core、RAM32GB、Disk2TBなど。
　→HA構成ではPacemakerによるHA構成や、共有ディスクとクラスタウェアを用いたHA構成など。
　→クラウド基盤に配置する。CPU課金のないOSSならではの構成。
　→レプリケーション構成。pgPool II for Pacemaker。
　　参照処理はスタンバイ側に振る、ということも可能。

================================================================================
質疑応答
================================================================================

　Q. MySQLでのOracleストアドプロシージャの移行てどうやるの？

　→A. MySQLではV5.0でストアドを実装しているが、
　　　 OracleではなくDB2を意識したフォーマット。
　　　 正直、あまり得意でない分野。

　→A. PostgreSQLはFunctionしかないので、基本書き直しになる。
　　　 逆にOracle側にプロシージャを持っていく、
　　　 という話なら12cからそういうツールが追加されたという噂。

　Q. PostgreSQLのVACUUMは、現在では完全に手動は不要になったのか？

　→完全に0ではない。
　　バッチなどで大量のデータを更新した後など、
　　VACUUM対象になっていても、
　　実際にAUTO VACUUMが行われるまで時間がかかることがある。
　　また、設定で指定したVACUUMのワーカープロセスの起動数が少ないと、
　　いつまでたっても順番が回ってこない事がある。
　　ちゃんとVACUUM完了したかなどを運用で監視すること。

黒魔術Byteman使ってみた

過去のエントリでも紹介したBytemanを実際に触ってみたのでとりまとめ。

参考サイト
公式：https://www.jboss.org/byteman
ダウンロード：https://www.jboss.org/byteman/downloads
バイトコード操作ツール、Bytemanを試す：http://d.hatena.ne.jp/Kazuhira/20131022/1382455739
Bytemanクイックリファレンス：http://d.hatena.ne.jp/nekop/20111226

この辺を読めば使い方はおおよそわかってくると思うので、実際のコードに入れてく使い方をつらつらと書いていきたいと思います。

Debian WheezyにLXCコンテナを設定する。

しばらく前にLXCのパッケージだけはインストールしていたものの、実際のコンテナ作成まで到達してなかった。
ぼちぼちお試ししてみようかなと、LXCコンテナの設定をしてみました。

apt-get install lxc

ちなみに環境はこんな感じです。

root@localhost:~# cat /proc/version
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2
root@localhost:/proc# apt-cache show lxc
Package: lxc
Version: 0.8.0~rc1-8+deb7u2
Architecture: amd64
Depends: debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.8), libcap2 (>= 2.10)

以降の手順はほぼこちらからの丸パクリです。
最後に違いが合った点をまとめてます。

概要
cookbook のテストとかでお手軽に試せる環境が欲しい
現在の環境では Virtual Box はちょっと重いので LXC でやってみる
余裕があれば Docker までやってみたい
ただし、結果として VirtualBox よりも手間は掛かってしまった..orz

Debian Wheezy で LXC 環境を作る - ようへいの日々精進XP

まずはLinuxコンテナが使うファイルシステムの設定。

root@localhost:~# vi /etc/fstab
以下の行を追加する。
cgroup        /sys/fs/cgroup        cgroup        defaults    0    0
mount /sys/fs/cgroup

/etc/network/interface を以下の通り変更

auto lxcbr0
iface lxcbr0 inet static
  address 192.168.1.1
  netmask 255.255.255.0
  post-up /usr/sbin/lxcbr0-up

/usr/bin/lxcbr0-up を以下の通り作成

#!/bin/sh
braddr=192.168.1.1
brrange=192.168.1.2,192.168.1.254
#
iptables -A FORWARD -i lxcbr0 -s ${braddr}/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -j MASQUERADE
#
dnsmasq --bind-interfaces --conf-file= --listen-address $braddr --except-interface lo --dhcp-range $brrange --dhcp-lease-max=253 --dhcp-no-override

作成したスクリプトの権限変更

sudo chmod 755 /usr/bin/lxcbr0-up

ここではたと気づく。このdnsmasqってコマンド、入ってるのか？？
whichしてみると入ってないので、改めてapt-get　installする。

root@localhost:~# apt-cache show dnsmasq
Package: dnsmasq
Version: 2.62-3+deb7u1
Depends: netbase, adduser, dnsmasq-base (>= 2.62-3+deb7u1)
Suggests: resolvconf
Conflicts: resolvconf (<< 1.15)

root@localhost:~# apt-get install dnsmasq
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
以下の特別パッケージがインストールされます:
  dnsmasq-base libnetfilter-conntrack3
提案パッケージ:
  resolvconf
以下のパッケージが新たにインストールされます:
  dnsmasq dnsmasq-base libnetfilter-conntrack3
アップグレード: 0 個、新規インストール: 3 個、削除: 0 個、保留: 6 個。
425 kB のアーカイブを取得する必要があります。
この操作後に追加で 1,054 kB のディスク容量が消費されます。
続行しますか [Y/n]? y
（中略）
[ ok ] Starting DNS forwarder and DHCP server: dnsmasq.

IPフォワーディングが出来るように設定する

sudo su -
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

lxc-create するときのネットワークテンプレート、/etc/lxc/interface.conf を作成する。

lxc.network.flags = up
lxc.network.type = veth
lxc.network.link = lxcbr0

ようやく、コンテの作成コマンドを発行。

root@localhost:~# lxc-create -t debian -n DevHub -f /etc/lxc/interface.conf
debootstrap は /usr/sbin/debootstrap です
Checking cache download in /var/cache/lxc/debian/rootfs-wheezy-amd64 ...
Copying rootfs to /var/lib/lxc/DevHub/rootfs...Generating locales (this might take a while)...
  ja_JP.UTF-8... done
Generation complete.
update-rc.d: using dependency based boot sequencing
update-rc.d: using dependency based boot sequencing
update-rc.d: using dependency based boot sequencing
update-rc.d: using dependency based boot sequencing

Current default time zone: 'Asia/Tokyo'
Local time is now:      Fri Feb 21 14:01:51 JST 2014.
Universal Time is now:  Fri Feb 21 05:01:51 UTC 2014.

Root password is 'root', please change !
'debian' template installed
'DevHub' created

以下のコマンドでLXCコンテナスタート。

root@localhost:~# lxc-start -n DevHub -d

無事起動したご様子。
起動しているかどうかはlxc-infoコマンドで確認できます。

root@localhost:~# lxc-info -n DevHub
state:   RUNNING
pid:     24719

とりあえず、ログインできるかどうかチェック。

lxc-console -n DevHub

Debian GNU/Linux 7 DevHub tty1

DevHub login: root
パスワード:
Linux DevHub 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@DevHub:~#

とりあえず使えるみたいですね。
ただ、いったんlxcbr0(仮想NWへのブリッジ)のIFを落として再起動しても、起動すると何やら怪しげなメッセージが。

root@localhost:~# ifconfig lxcbr0 down
root@localhost:~# ifconfig lxcbr0 up
root@localhost:~# sudo service networking restart
[warn] Running /etc/init.d/networking restart is deprecated because it may not re-enable some interfaces ... (warning).
[....] Reconfiguring network interfaces...RTNETLINK answers: File exists
Failed to bring up lxcbr0.
done.

エラーは来るものの、ホストOS側からコンテナ側にPingを打ってもちゃんと以下の通りかえってきます。

root@localhost:~# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_req=1 ttl=64 time=0.101 ms
64 bytes from 192.168.1.2: icmp_req=2 ttl=64 time=0.034 ms
64 bytes from 192.168.1.2: icmp_req=3 ttl=64 time=0.033 ms
64 bytes from 192.168.1.2: icmp_req=4 ttl=64 time=0.035 ms

他にいくつか引用元のサイトと違いがあったのは、

1. lxc-createコマンド発行時に、ウィザード形式での画面が出ない
2. 普通にコンテナを作成しただけでは正常に起動しないとあったが、ふつうに起動した。そのため、/var/lib/lxc/コンテナ名/configへのlxc.devttydirの追加や、/var/lib/lxc/コンテナ名/rootfs/etc/securetty の修正は行っていない。
3. /var/lib/lxc/コンテナ名/rootfs/etc/network/interfaceは最初から設定されていたため、この手順も不要だった

まあ、引用元が書かれてから半年くらい経ってますからね。
LXC側やDebian側に何らかの変更が加わったのかもしれず。

指定日付より古いファイルを検索して削除

一発ネタ。
指定日付より古いファイルを検索して削除したいときは、findの "-mtime +数字" オプションを使ってファイル名を検索して、パイプで rm に渡せば良い。

$ find ./ -mtime +20 -name "*.txt" | xargs rm

xargsはパイプで渡された値を次のコマンドの引数にするコマンド。rmじゃなくてechoだとこんな感じになります。

[root@localhost home]# find ./ -mtime +20 -name "*.txt" | xargs echo
./count.txt ./test/count2.txt 

findのmtimeでの時間の指定がやや分かりづらいんですが、こうなります。

find の -mtime +n のまとめ
find の -mtime +n の検索対象となるファイルは以下の通り。
mtime +0 今から24時間以上前のファイル
mtime +1 今から48時間以上前のファイル
mtime +2 今から72時間以上前のファイル
(n + 1) * 24 ってことだね。man にそう書いてあれば良かったのに。

find コマンドの -mtime は +1 でも2日前のファイルが対象