Yakstは、海外の役立つブログ記事などを人力で翻訳して公開するプロジェクトです。
2年弱前投稿

PostgreSQL 9.5でリリースされるUPSERT以外の注目機能

PostgreSQL 9.5のα版リリースに伴うUPSERT以外の注目機能(列のセキュリティー、ブロックレンジインデックス、JSONB、ソート高速化)についてのまとめ記事です。
原文 Beyond Upsert - Coming in PostgreSQL 9.5 (English)
翻訳者 B5aa4f809000b9147289650532e83932 taka-h


出典について

この記事はCOMPOSE内のDJ WALKER-MORGAN氏による「Beyond Upsert - Coming in PostgreSQL 9.5」(2015/7/2)を翻訳したものである。


PostgreSQL 9.5のα版がリリースされた(β版は8月)のに伴い、SQLデータベースの次のバージョンの新機能の一覧がより明らかになった。 我々は9.5へのUPSERT機能の追加について以前話してきたが、それはユーザーに見える機能の1つにすぎず、今年の後半に来るべき他の機能についてみてみる良いタイミングとなった。

列のセキュリティー

より興味深い追加機能の1つとして、少なくとも多くのユーザーが同じデータを参照するデータベースにとっては、列レベルのセキュリティーがある。 この機能により、テーブルに対して、あるユーザーが特定の列を閲覧できるかどうかのポリシを作ることができるようになる。 ポリシはテーブルと関連づけることができ、有効化した時に限りアクティブ化され、これはALTER TABLE tablename ENABLE ROW LEVEL SECURITYコマンドで有効化される。 ポリシは列が見えるべきときtrueとなるものである。

1つ例を挙げるとすれば、テーブルが「owner」列を持ち(owner == current_user)である場合、列は現在のユーザが列の所有者である場合のみ列を表示する。 (そしてcurrent_userが新しいものなら、PostgreSQLのシステム情報関数をよく調べたくなるだろう。これはランタイムおよびセッションの興味深い情報へのアクセスを提供する) スーパーユーザーは、BYPASSRLS属性がスーパーユーザーのロールに標準で設定されているため、全ての列を閲覧することができ、テーブルの所有者は自身のテーブルに対しては列レベルのセキュリティーをの制約をうけない。データフローの隔離をする必要があるならば素晴らしい機能である。 詳細は、DSHLのブログ投稿をご覧いただき、これをみれはこの機能が成熟するまでにどのくらいの期間を要したかついても分かるだろう。

ブロックレンジインデックス(BRIN)

非常に大きなテーブルおよびカラムがあり、ログ内のタイムスタンプのようにその列がテーブル内のどこにあるかに関連づいている場合、ブロックレンジインデックスはB-Treeインデックスを作成し、維持するコストなしにインデックスをはることができる可能性を提供する。 最も簡単な例では、ブロックレンジインデックスは、データをレンジに分割し、このレンジ内のページと、サマリ情報を格納することで機能を提供する。 (PostgreSQLのテーブルはページにより構成されており、ページはそれぞれ1つかそれ以上の列を含んでいる) ブロックのサマリ情報には一連のページの最小値および最大値の情報が含まれる。

ブロックレンジインデックスを利用したクエリがきたら、最初に候補外のインデックスの除外を行いそれによってクエリにマッチしないレコードを含むページが返される。 非常に大きなテーブルでは、クエリにマッチしない全てのページを高速でスキップすることができる。次のステップは、クエリのエグゼキューターが返されたページを、そこにある列が条件に合致するかどうかチェックする為にシークエンシャルに検査する。

ブロックレンジインデックスの有用性はトレードオフのバランスによる。 B-Treeインデックスは、レコードを高速に検索可能だが、より多くのディスク容量を消費し、維持コストがかかる。 ブロックレンジインデックスは、B-Treee検索より遅いが、ディスク容量を消費しないし、インデックスカラムが常識的な範囲のレンジに分割されていればインデックスの維持はうまくいく。 ブロックレンジインデックスに関しては、Michael Paquierのブロックレンジインデックスの概要およびDSHLのブログ投稿を参照して欲しい。

JSONB

列セキュリティーとブロックレンジインデックスはいくばくかの時間をかけてPostgresに機能追加されたが、JSONBの開発はもっと新しいもので9.4のリリースにおいて作成され、拡張機能もその前後で作成された。来るべきJSONB機能についてで述べたように、JSONBのデータを修正するのは、全てのドキュメントを抽出し、修正し、元に戻すという複雑な操作が伴う。9.5ではJSONBの修正が変更されている。||演算子で2つのJSONBの値を連結することができる。新しく導入された -演算子は、いくつかのモードを持っており、文字列が与えられた場合は最上位のフィールドを削除し、整数が与えられた場合は配列要素を削除することができる。-は最上位のキーのみを操作するが、#-演算子はネストされたパスに対して、ネストされたキーと値を削除する。

3つのJSONB関数も導入されている。jsonb_set()では、あるキーに対する値を更新でき、ネストされたパスがある場合、json_strip_nulls()で値がnullであるキーを削除することができ、jsonb_prettyでJSONBの値のpretty-printができる(長い文字列のdumpをとるよりずっと良い)

これはPostgreSQLでのJSON操作の問題にいくつかの解決方法を提供する。これは明らかにJSONに関するお粗末なスクリプトを減らすだろう。さらなる例については、Michael Paquirの新しいJSONBの機能に関する最近のブログ投稿を参照して欲しい。

ソートの高速化

PostgreSQLのソートに関する機能強化は9.5のソートを大幅に高速化するのにつながっている。機能強化は1月のコミットから始まり、この中では短縮キーに対するフレームワークによる拡張ソートのサポートがおこなわれている。 最初の利用はテキストフィールド向けであり、テキストフィールドの最初の8文字を使い、ソート可能な文字列を圧縮するstrxfrm()関数を使ってblobを作成する。 それからこのblogをテキストをソートし、等しい値を持つところに関しては古いスタイルの比較を行う。 コードは最悪のケース(全ての値の最初の8文字が同様である)をHyperLogLogで検知し、適切なアクションをとる。 このフレームワークは数値のソートに簡易キーを使うときに適用される。

様々なベンチマークに依ると、一般的で現実的なケースで、この変更によりインデクシングが3倍高速化される。 これはあらゆるデータベースの性能を大きく前進させるものであり、特にソート操作がデータベースの中で中核的である場合はその効果は顕著であろう。

その他

PostgreSQL 9.5にはいくつかの機能強化があり、ここで選ばれたものはComposeの(訳注:翻訳対象となった記事はComposeというサービスの記事である)PostgreSQLユーザーにとって一番目につくであろうという基準で選ばれている。 その他にも多数の機能強化があり、Composeではこれを楽しみにしている。これによって、我々がPostgreSQLをあなた方に提供する時にインフラを強化するのに助けとなるだろう。

次の記事
MySQL 5.7におけるCREATE USERコマンドの改善(MySQL Server Blogより)
前の記事
HerokuのPostgreSQLとAmazon RDSのPostgreSQL

Feed small 記事フィード