カテゴリー
Computer Database

PostgreSQLカンファレンス2008

PostgreSQLカンファレンス2008が今週金曜日(6/6)に開催されます。

http://www.postgresql.jp/events/postgresql-conference-2008

例年通り参加費が必要ですが懇親会費込みです。

参加費:
カンファレンス ならび に懇親会 4,000 円
チュートリアルも含むカンファレンス ならびに 懇親会 10,000 円

今回のカンファレンスの目玉は色々ありますが、その一つはチュートリアルセッションです。まだ、空席が残っているようなのでライセンスもBSDでMySQLよりも使いやすいPostgreSQLを始めてみたい方には良いチャンスだと思います。新人研修の一環としても良いと思います。

* MySQLユーザのためのPostgreSQL入門
(リナックスアカデミー 学校長 濱野 賢一朗 氏)

興味がある方は是非カンファレンスにお越し下さい。

カテゴリー
Computer Database

PostgreSQL 8.3の全文検索機能(TSearch2)を日本語で利用する

PostgreSQL 8.3.0から、ユーザから提供されている追加機能(contrib)として利用できた全文検索機能(TSearch2)が本体に取り込まれました。

本体に取り込まれたため、PostgreSQL 8.3.0以降ではソースから構築する場合に

./configure
make
make install

と実行するだけで全文検索機能が利用できるようになりました。

カテゴリー
Computer Database Development Misc Programming Security

JPUG北海道 RUBY札幌 合同セミナーの資料

2月16日に札幌で行われたJPUG北海道 RUBY札幌 合同セミナーの資料です。

クリックしてPostgreSQL-Performance.pdfにアクセス

セミナーの際には風邪の為、声がでず、非常に聞き辛かったと思います。聞きにお越しいただいた方には申し訳ないです。

fsync=falseなのでかなり速い事は理解していただけたと思います。(かなりのスピートダウンですがfsync=trueでも速いです)セッションをデータベースで管理した場合などにfsync=falseで運用しても問題ないでしょう。しかし、絶対にデータベース上のデータの不整合は困る場合にはfsync=trueに設定しなければなりません。

とは言ってもfsync=falseの速さは捨てがたいと言う方はUPSを利用すると良いでしょう。UPSを付ければリスクはかなり低減できるので、リスクとメリットのトレードオフで選択すれば良いと思います。

UPSを使っても防げないデータの不整合

  • カーネルがクラッシュした場合
  • HDDのケーブルが抜けたなど、物理的問題の場合
  • 電源が壊れた場合(これも物理的な問題ですが、2重化すればかなりリスク低減可能)
  • HDDの冗長化を行っていない場合(RAID組まずにデータ保護の為にUPS使っても….ですが念のため)

等が考えられます。

HDDの冗長化を行っていないサイトのデータベースであれば、fsync=falseが困る訳も無いでしょう。このような場合はfsync=falseでどんどん使ってよいでしょう。

fsync=falseはデータベースサーバ全体の設定なので結局は「ショッピングサイトなどでどんな場合でも受注済みデータが無くなると困る」のような要求があるとfsync=falseで運用できないのでは、とご意見も頂きました。このような場合でもログを別の方法で残す、例えば、メールで送信してしまう、別ディスクにジャーナルとして書き込む、など方法でデータ保存の方法を冗長化していればfsync=falseでも困らないサイトは少なくないと思います。そうは言っても、困る物は困る場合はfsync=trueで利用すると良いでしょう。

データベースに拘らずデータの冗長化を考えると、fsync=falseは強力な武器になります。

# PostgreSQL 8.3ならsynchronous_commit=offに設定してリスク
# を軽減する事も可能です。ところで、別ディスクにジャーナル
# として保存する場合はDBよりも先にジャーナルファイルに書き
# 込み、fsyncを忘れない様に注意してください。
# メール送信する場合はリモートのメールサーバが受け取った後
# にDBに書き込むように注意してください。つまりローカルのメー
# ルキューにいれるのみだとジャーナルのように使えない場合が
# あります。qmailならinjectが正常に終了すればOKだとは思い
# ますがメールシステムによっては高い信頼性を期待できない場合
# もあります。

カテゴリー
Computer Database Misc

日本PostgreSQLユーザ会北海道支部 / Ruby札幌 合同セミナーのお知らせ

2月16日(土)に、日本PostgreSQLユーザ会(JPUG)北海道支部とRuby札幌の合同セミナーが開催されます。

日本PostgreSQLユーザ会北海道支部 / Ruby札幌 合同セミナーのお知らせ

私も講師の一人として参加させて頂きます。PostgreSQLとMySQLのベンチマークについて話す予定です。ご都合がよい方はお越しください。

有料と聞いていないので無料セミナーだと思います。アナウンス文には無料と記載されていないので主催者に問い合わせてみます。

追記:
現在は無料であることがアナウンス文に追加されています。

カテゴリー
Computer Database Other

FreeBSD7はPostgreSQL, MySQLユーザにとって救いになるか?

クリックして7.0%20Preview.pdfにアクセス

にFreeBSD7上でのPostgreSQLとMySQLのベンチマークが載っています。

PostgreSQL 8.2.4 – 11ページ

ピーク性能でおよそ5400transactions/secほど。

MySQL 5.0.45 – 15ページ

ピーク性能でおよそ3800transactions/secほど。

Kernelの主要な部分すべてがパラレルに動作するようになったため、かなり高速(数値にして数倍)になったようです。

グラフからもPostgreSQLの方がかなり良い性能であることが分かりますが、PDFファイル(16ページ)によると

On this benchmark PostgreSQL is 35% – 45% faster thanMySQL at all loads

とPostgreSQLの方が全般的に良い性能だったそうです。PostgreSQL 8.3は確実に8.2よりもさらに良い性能を期待できると思います。MySQLも5.1や6.0を利用した方が良い性能が期待できるのかも知れません。

このPDFのベンチマークはデータベースの性能を計る為のベンチマークではなく、OSの性能を計る為のベンチマークです。データベースサーバ設定、SQL文やテーブル構成などが不明なのでデータベースの性能のベンチマークとしては参考値くらいでしかありません。MySQLのテストではMyISAMを使っていると思われますが、MyISAMならこれくらいの性能差は普通です。

カテゴリー
Computer Database

MySQL5.0.51では不十分

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5968

によるとMySQL 5.1.23には脆弱性ありその概要は以下とされています。

Overview
MySQL 5.1.x before 5.1.23 might allow attackers to gain privileges via unspecified use of the BINLOG statement in conjunction with the binlog filename, which is interpreted as an absolute path by some components of the product, and as a relative path by other components.

Impact
CVSS Severity (version 2.0):
CVSS v2 Base score: 10.0 (High) (AV:N/AC:L/Au:N/C:C/I:C/A:C) (legend)
Impact Subscore: 10.0
Exploitability Subscore: 10.0

Access Vector: Network exploitable
Access Complexity: Low
**NOTE: Access Complexity scored Low due to insufficient information
Authentication: Not required to exploit
Impact Type: Provides administrator access, Allows complete confidentiality, integrity, and availability violation , Allows unauthorized disclosure of information , Allows disruption of service

MySQL 5.0系の最新版は5.0.51ですが、これには上記の脆弱性の修正が含まれているか気になったので調べてみました。

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5969
これは同じ日付のMySQL 5.0.51のCVEエントリです。これにはBINLOGの脆弱性に関する記述がありませんでした。リリースノートのURLがあったので見てみましたが以下のリリースノートにの記述がありませんでした。(現時点で)

5.0.51のリリースノート
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-51.html

5.0.52のリリースノート(現時点では、Enterprise版のユーザしかダウンロード出来ない?)
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-es-5-0-52.html

5.0.54のリリースノート(現時点ではまだダウンロード出来ない)
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-es-5-0-54.html

5.0には影響ない?
5.0.51で修正?
5.0.52で修正?
5.0.54で修正?

どれなのかよく分かりません。分かったのはMySQLはコミュニティ版とエンタープライズ版でセキュリティパッチリリースを差別化している事です。5.0.52にもセキュリティフィックスが記載されています。つまり最新のコミュニティ版の5.0.51では不十分です。探せばダウンロードできるのか?アカウントを取ればダウンロードできるのか?いづれにせよどれが最新で安全なのか分かりづらいです。

リポジトリへのコミットを見ていればセキュリティパッチを見分けてインストールする事も可能ですが、とても一般向けとは言い難いです。

MySQL 6.0のバージョン管理にはBitKeeperを利用しているようです。5.1、5.0はsubversionのようなので今はまだよいですが、BitKeeperも障壁の一つになりそうです。リポジトリ自体にアクセスしてみよう、と思ったのですが少しググっただけではどこへアクセスすればよいのか分かりませんでした…

追記
しばらくしてからまた新しいMySQLのCVEが出ています。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5970
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6303
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6304

新しい方は明確にかいてあるので古い方はどうなの?と思わなくてもよいようになっています。

カテゴリー
Computer Database Programming Secure Coding

SET NAMESは禁止

MySQLには文字エンコーディングを変更する「SET NAMES」SQL文が用意されています。(PostgreSQLも同様のSQL文、SET CLIENT_ENCODINGがあります)この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。

Ruby on Railsの本を読んでいて、ActiveRecordを説明している部分にMySQLの文字エンコーディングを変更する場合の例としてSET NAMESが利用されていました。アプリケーションからはSET NAMESは使ってはならない事を周知させるのは結構時間が必要かなと思いました。

PHPも5.2の途中からMySQLモジュールにlibmysqlの文字エンコーディング設定APIのラッパー関数が追加されていたりするので、たまたま最近読んだRoRの本だけでなく、多くの開発向け情報ソースにSET NAMESを利用した例が載っていると思います。

ストアドプロシージャだけ使っていれば安全ですが、アプリケーションからDBMSの文字エンコーディングを設定する場合、SQL文ではなく必ず文字エンコーディング設定APIを利用するよう紹介しなければならないです。MySQL4はストアドプロシージャが使えないので、フレームワークなどではエミュレートしています。ストアドプロシージャだけ使って防御している「つもり」で防御になっていない場合もあります。これもフレームワークを使っていてもアプリケーションが脆弱になる良い例ですね。

脆弱性の説明は面倒ですが注意事項は簡単です。「DBMSをアプリケーションから利用する場合、文字エンコーディング設定は必ずAPIを利用する」つまり「SET NAMES(PostgreSQLのSET CLIENT_ENCODING等も)は禁止」です。

PHPのMySQL:

PHPのPostgreSQL:

PHPのPDO:

<?php
// MySQL
$pdo = new PDO(
    'mysql:host=yourhost;dbname=yourdb;charset=sjis',
    'user', 'password'
);

// PostgreSQL
$pdo = new PDO(
    "pgsql:host=yourhost;dbname=yourdb;options='--client_encoding=sjis'"
);

Rails:

config.encoding = 文字コード