書評 | 写真 | 自転車 | 音楽 | 映画 | Web | スマートフォン | 拡張現実 | 育児 | 自分

スポンサーサイト このエントリーを含むはてなブックマーク

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告
  3. |

オープンソースカンファレンス2007 .DB(OSC2007.DB)のまとめ このエントリーを含むはてなブックマーク

オープンソースカンファレンス2007 .DBへ行ったので
内容を簡単に纏めた。

内容が誤っている場合は指摘していただけると嬉しいです。

////////////////////////////////////////////////////////

日時:2006年6月24日(土) 10:00-17:50(実際は19:00くらいまでやった)
会場:PIO 大田区産業プラザ 小展示ホール

############# 性能比較 #############

■ストアドプロシージャ

●MySQL:
・カラム数がスピードに影響する(MySQLに限らない)
・データ長はあまり影響しない(MySQLに限らない)
●PostgreSQL(PG):
・SELECTが早い
・MySQLの4倍
・ストアドはデータを取得しない
・updateは遅い
・deleteが早い(フラグを立てるだけ)
●Firebird
・全部早い(INSERT,SELECT,UPDATE,DELETE)
・SELECTはPGのほうが早い

■C API

INSERT
・早い順(Firebird,MySQL,PG)
SELECT
・MySQLが断然遅い(外部からネットワーク越しに呼び出すとPGとMySQLとの差が縮まる)
UPDATE
・PGが遅い
DELETE
・あまりかわらないがMySQLが遅い

■設定ファイル

●MySQL
・パラメータを操作しても殆どパフォーマンスが変化しない
・InnoDBの性能は最近上がっている(場合によって差がある)
・悩んだInnoDB

●PG
・パラメータに大きく影響する
・shared_buffers
・wal_buffers
・checkpoing_segmentes(大きくする)

■PHP
・Postgresはプリペアの方が早い(pg_propere)
・Firebirdはネットワーク越しだと劇的に遅くなる
(基本的にPHPは遅い)

■その他
・MySQLのJoinはそんなに遅くない
・SELECTで2,3テーブルの結合はMySQLが早い 4つだとPG

■まとめ

●Firebird
・ストアドは超早い
・PHPは微妙(ネットワーク接続)
・ストアドを叩くと早い

●MySQL
・InnoDBは早い
・JOINも早い
・SELECTのネットワーク接続は早い
・PHP,Javeでもネットワーク接続でも早い
・限界性能を引き出すならutf8

●PG
・実はかなり早い(SELECTがシンプル)
・同時接続数が増えても性能が下がらない
・PGはプリペアを使うと早くなる。MySQLはあまり恩恵なし。
・PGはテーブルが汚れると遅くなるので、バキュームは必要 autoVACUUM

●その他
・MySQL,PGは同時接続500でもいける
・ストアド、シングルならFirebird
・更新はMySQL
・SELECTはPG

############# PostgreSQL8.3 #############

■PGの特徴
・tsearch(全文検索)→日本語はNG
・追記型→UPDATEはゴミがでる
(忙しいときは無視。暇な時にゴミ処理)

■PostgresSQL8.3の目玉

●更新が早い(新機能"HOT")→更新領域が再利用される

●性能が安定する
・チェックポイント(全ての変更ページを書き出す。同期する)
8.2:全力でやる
8.3スリープを挟む

●データロードが早い
・WALをスキップすることでI/Oが1/2
※既存のテーブル(インデックス)は苦手

●VACUUMが手間いらず
・autovaccumによるvacuumが柔軟
8.2:VACUUMの不足がある(1プロセス)
8.3:複数プロセス

■まとめ
・8.3は更新が早い
・チューニングと運用の手間が軽減
・その他(SQL/XML,実行フラグアドバイザ、遅延コミット)
・8.4もそろそろ。。。


############# Firebird #############

・Firebirdは大規模化を考えない(50GBを超えない程度)
・より小さくより軽く
・アプリに便利
・SQLite的なモデル
・Windowsと相性がいい。
・Delphiと相性がいい。
・PHPと相性が悪い。
・IntelMac対応


############# MySQL日本語化問題 #############

・Shift-JIS \5c問題
・変換テーブルの欠落
・my.cnfがいじれない
・コード変換が起こる場合と起こらない場合がある

■解決策

・コード変換で抑制
charset=laten1,binany,ascii
charset=utf8(積極的に利用)

・コード変換を積極的に利用
SETNAMES=utf8(クエリー)・・・クエリーを強制的にコントロールする
(副作用;サーバーだけでクライアントは変わらない)

クライアント サーバー
utf8 → utf8
utf8に存在しない文字コードを利用すると、それ以降文字が消える

クライアント サーバー
euc → euc
utf8の変換が入り文字化けする場合がある
アプリ側で文字セットを定義する

・サーバーをクライアントもutf8とすると早くなる
スポンサーサイト
  1. 2007/06/24(日) 20:38:34|
  2. Web
  3. | トラックバック:0
  4. | コメント:0|
<<【書評】iPhone 衝撃のビジネスモデル | ホーム | こだわりから離れてみる>>

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://kenshi0815.blog108.fc2.com/tb.php/21-5d6c959b
この記事にトラックバックする(FC2ブログユーザー)
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。