Pixel Pedals of Tomakomai

北海道苫小牧市出身の初老の日常

OSC2007.DBに来ています

9:55

すでに会場入りしてます。適当にまとめます。

10:05 オープンソース DB 性能徹底比較! 〜Firebird / MySQL / PostgreSQL

データが多過ぎてあんまりわかりませんでした。しかも、ベンチマークの種類や時期やDBの種類によってバラバラのデータを使ってるし。もっと要点だけまとまってると嬉しかったです。。。

  • Firebird(木村さん)、MySQL(堤井さん)、PostgreSQL(片岡さん)
  • 客観性の高いベンチマークが少ないので、自分たちでやってみた
  • 単純なピーク性能テストから、徐々に複雑なテストにしていく
  • 再現性を重要視して行う。特別なことはせず、万人が手元で同じ結果を出せること。
  • DB性能測定を標準化・定型化し、別のDBに対しても同様のテストを可能とする
  • 性能測定検査の分析方法を確立する。
  • テスト項目
    • 単体テスト
      • 64byte×8、8byte×128、128byte×8
      • 10万レコード、insert, select, update
      • ストアド、c、javaphp
    • 1-1
    • 1-many
      • insert、select、update、delete をSuper Smackにて実行
      • 500 くらいまで同時
    • シナリオテスト
      • DBT-1もどき・・・オンラインンショッピングを想定したシナリオ
      • SELECT, INSERTまで
  • 検証するバージョンは、適時最新を利用する。マシンは普通の物(linux kernel 2.6)
  • データとログのディスクを分離
  • vmstat でリソースを監視する
  • MySQL = InnoDBPostgreSQL = vacuum & analyze、Firebird = SuperServer
  • MySQLのストアドによる単体試験の結果について
    • データ長は性能にあまり影響しない。カラム数の影響を受ける
    • SELECTはMyISAMが速いが、それ以外はInnoDBより速いとは言えない
    • ストアドは実装されたばかりで、安定していない
  • PostgreSQLのストアドによる単体試験の結果について
    • SELECTはストアドでデータを取得しない指定ができるため、高速*1
    • DELETEはDELETEフラグを立てるだけなので、高速
    • UPDATEはDELETE+INSERTなので、遅い
  • Firebirdのストアドによる単体試験の結果について
    • なんか圧倒的に速いぞ?
    • テーブルクリアをするプログラムなので、ほんとに処理してるかは不明
    • ストアドは実績が十二分にあるので、高速化されているのでは?
  • Cでの単体テスト
    • TCP/IPで通信させる。
    • Firebird はCのAPIが特殊なため、テスト不明
  • MySQLのCでの単体テスト
    • ストアドよりちょっと遅い
  • PostgreSQLのCでの単体テスト
    • SELECTがストアドより大分遅い(データを取ってくるため)
    • それでも、SELECTはMySQLより速い
  • JavaPHP APIでの比較
    • MySQLPostgreSQLPHPの方が割と速い感じ
    • ただ、PostgreSQLのSELECTではJAVAも速い。たまたま??
    • FirebirdJavaAPIPHPよりも優秀。ロシア人のおかげみたい。
    • カラム数が多いと通信料が増えるため、ストアドよりかなり遅くなる。
    • データ長は長くてもたいした遅くならない
    • 総合するとMySQLが検討しているように見える
  • InnoDBはどんどん高速化されており、MyISAMを使えば速いとは限らない
  • 同時セッションによるテスト
  • シナリオテスト
    • 接続数が50以下のSELECTでは、MySQLが速い
    • PostgreSQLは、複数テーブルをjoinをした方が速い可能性がある*2
  • まとめ

11:45 XQueryXPath 及び SQL / XML に関する標準化動向と今後の取組み状況 (土田さん)

XQueryの実装って、もう存在するんですかね?? XMLQUERY関数やらXMLTABLE関数の中で記述するって仕様は、あまり美しくないなあと思いました。

  • SQLは1992年から開発され、今も続いている
    • SQL:2006 でXMLストレージが定義された。
    • SQL:2008 を策定中
    • 2003年のパート14(SQL/XML)でSQLXMLの対応付けが書かれる
    • 2000年頃はORDBと言う思想があった(Java)。今の流れはXDB(XML型 + XQuery)
  • XMLの利点 → デファクトスタンダード。インフラやツールも多い。
    • データ(株情報の交換)、文書(カルテのオープン化)、コンテンツ(新聞のデジタル化)、システム(設定ファイルなど)で多く利用
    • 標準化されたもの(CBL, BML, BII/XML, G-XML, MML, JEPAX, VCML)
  • XMLの見方は、データ表現としてのXMLと文書表現としてのXMLのふたつに分かれる
  • XML-RDB マッピング ・・・ XMLRDB上のテーブル・カラムを、定義して対応させる
    • XMLの取り出しを、SQLで行いたい。次のステップへ。
  • XML問い合わせ 2000年から策定されている
  • 適応例 → XML文書の操作、DBMSXML処理、XMLメッセージ、統合化
  • XQuery 1.0の開発完了。2.0を開発中。
  • XML連携機能
    • XMLSQL (エスケープ、Null、型の取り扱い)
    • XML型を扱う
    • XMLを作る関数
  • XMLストレージ拡張機能
    • XMLQUERY関数、XMLTABLE関数
    • XQueryシンタックスは、全てXMLQUERY関数内で利用する *4
    • XMLEXISTS, CONTENT, DOCUMENT の述語の用意
  • XQueryデータモデル (ノードごとに分ける)
  • XQuery は FLWOR式 (For/Let/Where/OrderBy/Return) で記述できる
  • XPath構文で、条件を記述する
  • XQuery でgroup by は書けない。関数を使って似たようなことをやる
  • XMLQUERY関数の中には、定数値しか入れることはできない
  • クライアント言語からは、XML文字列として入出力する。SQL内でXDM化する。
  • 今後はセマンティクスやセキュリティを重視。でも、参画するベンダが減って来ている。*5

12:45 ランチ

去年YAPCで使ったガスト。

13:35 宣伝タイム

13:38 PostgreSQL Updates 板垣さん・笠原さん

  • CPUスケーラビリティの向上(8.1と8.2)
    • NUMA*6環境は対応が必要
  • 全文テキスト検索
    • GiST(更新向け)とGIN(参照向け)と言う2種類のインデックスがある。
    • 日本語サポートはまだ
  • VACUUM UPDATEを行った際のゴミを除去すること
  • 新機能 HOT
    • インデックス更新をスキップ
    • VACUUMをまたずにゴミ処理
  • HOT UPDATE (Heap Only Tuple)
    • UPDATE時の新旧の行を、同じページ上に書き出すことで、インデックス更新を抑止
    • 予めUPDATE用の隙間を作っておき、交互に利用する
    • インデックスの張られた列を更新するとNG
    • FillFactorを調整して、同一ページ上に空き領域を作る
  • チェックポイント時のスループットが安定した
    • チェックポイントをスリープしながらスケジューリングするようにしただけ
  • データロードが高速化した
    • truncateの後にcopy文を呼ぶとよい
  • VACUUM の手間がいらなくなった
    • autovacuumは8.2まではシングルプロセスだったのが、マルチになった。
  • 8.3には大きく期待できる
    • テスターはまだ必要
  • 8.4も・・・
    • HOTの最適化
    • autovacuumのクレバーなスケジューラ
    • ホットスタンバイ
  • PGCon2007 in Ottawa University
    • レプリケーションツールの注目度が高い
    • VACUUM中の性能、自動チューニング
    • 大規模環境でのパーティショニングへの注目
  • JPUG(日本)
    • 世界でも大きいコミュニティ。ビジネス色が強い
    • 開発者が少ない
    • ログ出力メッセージの体系が不明
    • 日本語問題
  • まとめ
    • 性能面の問題は払拭された
    • 大規模運用、安定性などに焦点
    • 開発者の増員が課題

14:33 Firebird の最新動向 加藤さん

  • Firebird2.0
    • 少し遅れ気味の機能を、随時搭載
  • Windowsを重視している
  • クラッシック=プロセスモデル、スーパーサーバー=スレッドモデル
  • SQL標準への準拠
    • 一時テーブルに対応
    • 再帰問い合わせに対応
    • 中国語サポート
    • Windows64bit サポート
  • 大規模化は目指していない
  • C/Sだけではなく、組み込み構成で利用することができる
  • ロシアが幅を利かせているみたい
  • Firebirdの開発環境はDelphiなどが必要で敷居が高い
  • 日本医師会で使われている
    • IntelMacに対応
    • 信頼性、OSS、組み込み、Java言語
  • Firebird日本ユーザ会
    • 日本語ドキュメント、日本語化をしている
  • 毎年集まります!!

15:48 続:MySQL の日本語問題と解決策

いい話聞けるのかと思ったら、MySQLにパッチ当てて解決だなんて・・・orz 業務じゃ使えないだろうし、本家に取り込まれるのを気長に待つしかないですね。

  • 日本語問題は、Ver4.1から起こり始めた
    • UNICODEサポート・・・utf8が基本
    • 内部的にutf8変換が起こる
  • mysql側で、自動変換が起こる
  • my.confで設定ができる
  • Shift_JISのバックスラッシュ(0x5c)問題
  • 変換テーブルの欠落問題
  • 変換の抑制
    • charset=latin1,binary,ascii
    • charset=utf8 ← おすすめ
  • 変換の推奨
    • サーバ側の文字コードを変更 SET NAMES=utf8 (my.cnfが利用できない場合)
      • サーバ側のcharsetは変えれるが、クライアントは変わらない
  • MoSQL (萌えすきゅーえる)
    • charsetを統一しても、UTF-8変換が通ってしまうのを避けられる
    • MYSQL_SET_CHARSET_NAME や、その他の設定を my.cnf だけでなく環境変数で設定できる
    • 日本語エラーメッセージに対応
    • MoSQL.jp
  • MoSQLのデモ
    • 不正な文字を、MySQLutf-8のテーブルに投入すると消えてしまう → MoSQLだと大丈夫
    • MoSQLなら、環境変数でクライアント側のcharset変更
    • (Trittonプロジェクト) Senna を組み込んでの全文検索 (MyISAMのみ) ←これはすばらぼい!!
    • エラーメッセージの日本語化
  • 速度のためには、DBをutf8で構築すべき
  • MySQLの日本のカンファレンスが、今年初めてあるそうです。

16:50 データベースとは何か 〜システム、コンテンツ、そして社会〜 増永さん

データベース=RDBMSって枠での議論ではなく、既存のRDBMSやWEBを単なる記憶装置としてみて、それらのデータを処理する新たなデータベースシステムを作り出すと言う話題でした。データ検索の手法やその見せ方までを"データベース"として捉えた見方です。


後半はGoogleの水面下の影響力の恐ろしさの話で、ちょっと論点ズレですね。

  • 地球丸ごとデータベース
  • システム開発コンテンツ系(データ中心、マルチメディア、スキーマレス、データマイニング) → WebもDBである
  • マルチメディアデータベース
    • 音・画像・TEXT (Everyting is object)
    • 3次元地図を活用したビデオデータベースシステム
      • 建物名で検索すると、その建物が映っている映像が得られるシステム
      • 撮影者の位置情報(GPS+ジャイロ)と3次元地図データをぶつけて、ビデオのどの部分になんて名前の建物が映っているかを求めてindexingする。
  • 仮想世界データベース
  • 仮装天文台
    • 年間1PB*7以上のデータを扱う
    • JVOQL
  • WEBマイニング
    • 1970年 RDMの発明 → 1991年 http://info.cern.ch 世界初のウェブサイト
    • WEBは、実世界をHTMLを利用して記述したもの。
    • "社会現象の分析手法としてのWebマイニング"
    • 共時的通時的な分析
    • ドメイン知識を持つ専門家が、システムを有用な物に育てる
  • Googleの信用性(表示順位)と透明性(PageRank)
    • 視認性(黄金のトライアングル)により、7位までに出さないと、意味がない。
    • Googleとその提供先で、表示順位が違う
  • 日本データベース学会の紹介

18:20 ライトニングトーク

  • DBDesigner 4 について (吉田さん http://iimp.jp)
  • 色々参加しよう (木村さん Firebird日本ユーザ会)
  • MySQL Users Conference Japan 2007 開催のご案内
    • 9/11と9/12 (ユーザ会主催じゃありません)
    • MySQLの開発者も海外から来るみたい。事前申し込みで無料です。
    • 無料でランチとかディナーつくみたいですよ??聞き違い?
  • インテリジェントディスクさん
    • DVD RAMに OSを焼いてあって、ReadWriteできるみたい。
  • PHPユーザ会から、カンファレンスのお知らせ

18:42 抽選会

あれ、またライトニングトーク??


ライトニングトークは、銅鑼鳴らさないと駄目だと思う。お疲れ様でした。

*1:これは比較として駄目では?

*2:PLANが変わるためだと思われる

*3:通説は逆なので、興味深い

*4:そうなんだ

*5:せっかくSQLの仕様自体は枯れてるんだから、駄目仕様は増やして欲しくないと切に思う

*6:メモりアクセスの方法??

*7:ペタバイト