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

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

                                                                                                                                                              • -

MySQLの優位性 SCSK 池田徹朗

                                                                                                                                                              • -

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

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

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

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

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

                                                                                                                                                                    • -

10の理由ネタ

                                                                                                                                                                    • -

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

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

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

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

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

 →SCSKによるMySQL拡張事例
   日本語全文検索
   audit_pluginインターフェースによる監査ログ出力(今は本体機能として実装済み)
   CP932文字コード対応。Ruby対応(MySQL/RubyRuby/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、RedmineMovable Typeなど。

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

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

                                                                                                                                                                    • -

・人気

                                                                                                                                                                    • -

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

                                                                                                                                                                    • -

・エコシステム

                                                                                                                                                                    • -

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

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

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

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

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

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

                                                                                                                                                                    • -

PostgreSQLDBMSとしての作り

                                                                                                                                                                    • -

  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完了したかなどを運用で監視すること。