不整合が起きてはならない場合、トランザクションはシリアライザブル

リレーショナルデータベースが優れている点はトランザクションをサポートしている点です。トランザクションは手続きが一貫性ある形で実行されることを保証してくれます。しかし、トランザクションを使えばOK、という物ではありません。

もしトランザクションさえ使っていればOKと思っていた方はトランザクション分離レベルを理解してください。

“不整合が起きてはならない場合、トランザクションはシリアライザブル” の続きを読む

PHP7で追加される整数型、浮動小数点型タイプヒントの問題点

PHP7では整数型、浮動小数点型、配列型のタイプヒントが追加されます。データ型をより厳格に取り扱うようになるのは良い事ですが、データ型を変換してしまうため問題となる場合もあります。

データ型は指定した型に変換すればよい、という単純な物ではありません。私はデータ型を変換しない方のRFCを支持していました。残念ながらこちらのRFCでなく、問題が多い方のRFCが採用されることになりました。

参考

“PHP7で追加される整数型、浮動小数点型タイプヒントの問題点” の続きを読む

Memcachedのプロトコル仕様とセキュリティ – Memcachedでもインジェクションが可能

Memcachedはテキストプロトコルとバイナリプロトコルの二種類を持っています。デフォルトはテキストプロトコルです。テキストプロトコルを利用している場合、テキストインターフェース処理の基本を理解した上で利用しないとセキュリティ問題が発生します。こういった処理のセキュリティ対策を行う、確認するには実は標準の方が簡単で明解 – セキュリティ対策の評価方法も参考になります。

Memcachedはキーバリュー型なのでSQLインジェクションのような脆弱性とは無縁、と思っていた方は是非読んでみてください。

“Memcachedのプロトコル仕様とセキュリティ – Memcachedでもインジェクションが可能” の続きを読む

速いアプリケーションの作り方

Phalcon Adventカレンダー18日目として書いています。

一台のアプリケーションサーバーで10リクエスト/秒で十分というサービスであれば、どんなプラットフォームを選んでも問題ありません。一台のサーバーが10リクエスト/秒しか処理できなくても、ページがキャッシュできるならリバースプロキシで簡単に数千リクエスト/秒以上でサービスできます。このようなサービスであればPhalconのようなフレーワムワークを使わなくても大丈夫です。

しかし、メッセージング系などリアルタイム性の高いサービス、つまりHTTPキャッシュがあまり有効に利用できないシステムでは速度が非常に重要です。

“速いアプリケーションの作り方” の続きを読む

PostgreSQLのJSONB型を利用してタグ検索を行う

遅れてしまいましたが、PostgreSQL Adventカレンダー2014の9日目です。昨年はタグ検索するならPostgreSQLで決まり!でPostgreSQLの特徴でもある配列型を使ったタグ検索を紹介しました。今年はJSONを使ってみたいと思います。

つい先程、PostgreSQL GitリポジトリからPostgreSQL 9.4のソースを取得&ビルドして記事を書いています。(記事を書くことを忘れていたので大急ぎで書きました)

“PostgreSQLのJSONB型を利用してタグ検索を行う” の続きを読む

SQLiteデータ型の仕様とセキュリティ問題

SQLiteはファイルベースのオープンソースRDBMSです。オープンソースとしては珍しいパブリックドメインライセンスを採用しています。SQLiteはファイルベースなのでデータベースサーバーが必要なく手軽に利用できます。SQLiteは組み込みデバイスで広く利用され、Android/iOSなどでは標準的なデータベースとして利用されています。モバイルデバイス以外での利用も広がっており例えば、Drupal8はSQLite3に対応しています。

普通のRDBMSのようにSQLクエリが利用できるのでとても便利ですが、SQLiteの仕様は他のRDBMSと異なるので注意が必要です。

追記:論理的・体系的セキュリティを構築していれば、ここに書かれているようなセキュリティ上問題となる事を自身で分析/対応できるようになります。

“SQLiteデータ型の仕様とセキュリティ問題” の続きを読む

安全なAPI過信症候群 – 普通のRDBMS編

昨日書いた安全なAPI過信症候群の処方箋 – execv/SQLite3編はSQLiteの仕様がRDBMSとしてエキゾチック過ぎて、さらっと書いたよくあるRDBMSでの「安全なAPI過信症候群」を全く理解して頂けなかったケースもあるようなのでもう一度書きます。

プリペアードクエリには色々問題もあり、セキュリティ対策としてそれだけ教えるのはNG、と考えている方はプリペアードクエリ過信症候群ではないので、このエントリを読む必要はありません。

“安全なAPI過信症候群 – 普通のRDBMS編” の続きを読む

第一回 中国地方DB勉強会の資料

第一回 中国地方DB勉強会の講師として参加させて頂きました。

MySQLも使っていますが奥野さんの発表は普段気にしていなかったことも多く、とても参考になりました。

私の資料もSlideShareにアップロードしました。

データベースセキュリティ

http://www.slideshare.net/yohgaki/ss-25042247

 PostgreSQL 9.3

http://www.slideshare.net/yohgaki/postgre-sql-93

知っているようで知らないプリペアードクエリ

PostgreSQL Advent Calender 2012用のエントリです。

PostgreSQLや他のDBMSを利用していてプリペアードクエリを知らない方は居ないと思いますが、プリペアードクエリを使いこなす為のTIPSです。役に立つかどうか、は多少疑問ですが、内部がどうなっているか知っているとなにかの役に立つかも知れません。時間的制約で多少端折っているところは勘弁してください。

完全なSQLインジェクション対策は以下を参照してください。

完全なSQLインジェクション対策

“知っているようで知らないプリペアードクエリ” の続きを読む

PostgreSQL 9.0から使える識別子とリテラルのエスケープ

PostgreSQL Advent Calender用のエントリです。

エスケープ処理が必要なのにエスケープ用のAPIが無い状態は良くありません。エスケープしないために動かないのはまだ良い方です。エスケープが必要なのにエ スケープをしなくても動いてしまい、セキュリティ上の問題となる場合もあります。全てのアプリケーション・ライブラリはエスケープが必要なデータに対するAPIを持っておくべき です。今回はPostgreSQL 9.0から追加されたエスケープ関数を紹介します。

PostgreSQL使い始めて最初の頃に気づくのはuserなどの予約語がフィールド名に使えない事かも知れません。例えば、

と失敗してしまいます。これはuserがPostgreSQLの予約語であるためSQL文の識別子として使用できないからです。MS Accessからデータベースに入った方には識別子に日本語を使う場合も多いので、PostgreSQLでは日本語のテーブル名やフィールド名はそのままでは使えない事に気が付いた方も多いのではないでしょうか? “PostgreSQL 9.0から使える識別子とリテラルのエスケープ” の続きを読む

Mac PortでApache/PostgreSQL/MySQL/PHPを使えるように設定する

OSX標準のApache/PHPでPostgreSQLやMySQLを使えるようにしても良いのですが、いろいろカスタマイズしたい場合はMacPortsの方が便利だったりします。インストール手順が古かったりするブログもあったので(手順が抜けているかも知れませんが)最初から書きます。
“Mac PortでApache/PostgreSQL/MySQL/PHPを使えるように設定する” の続きを読む

OSC Tokyo – 今更聞けないSQLインジェクションの現実と対策

明日のOSC東京Fallでは「SQLインジェクション”ゼロ”のPostgreSQL利用法 – 今更聞けないSQLインジェク ションの現実と対策」と題したセッションを日本PostgreSQLユーザ会の講師として話をさせて頂きます。

SQLインジェクションはとうの昔に枯れた話題と思われていますが、古くても今の問題です。何年か前、日本PostgreSQLユーザ会のセミナーで手作業でのブラインドSQLインジェクションのデモをした事がありますが今回はツールを使ったデモもあります。書いている間に当初作ろうと思っていたプレゼンとは異なる物なってしまいました。多少紹介から期待する内容とは異なっているかも知れません。既にSQLインジェクションについては十分知っている方でも、それなりに(?)楽しめる内容になっていると思います。おかげ様で満員だそうですが、飛び込みでも少しは入れるのかな?

45分なのに60枚もスライドがある上、デモもあります。かなりハイペースで話すことになります。ネットで直ぐに見つかるような基本的な事はあまり書かなかったのですが、無いようで書くとSQLインジェクションについて色々在る物です。多少スライドは飛ばす事になります。

ほぼ同じ内容でOSC高知でも話をさせて頂く予定です。
来たくても来れなかった方は是非高知でお会いしましょう。

PostgreSQLカンファレンス2008

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

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

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

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

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

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

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

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

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

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

./configure
make
make install

と実行するだけで全文検索機能が利用できるようになりました。
“PostgreSQL 8.3の全文検索機能(TSearch2)を日本語で利用する” の続きを読む

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

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

http://blog.ohgaki.net/media/users/yohgaki/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だとは思い
# ますがメールシステムによっては高い信頼性を期待できない場合
# もあります。

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

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

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

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

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

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

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

http://people.freebsd.org/~kris/scaling/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ならこれくらいの性能差は普通です。