SIOS "OSSよろず" ブログ出張所: PostgreSQL 9.3 の JSON データのインデックス
SIOS "OSSよろず"ブログ出張所はサイオスが新たにオープンしました「SIOS Tech.Lab」ブログに移設します。 新サイトのURLは下記となります。引き続きのご愛読をよろしくお願いします。 https://tech-lab.sios.jp/ こんにちは。渡辺です。 前回は PostgreSQL 9.2 で実装された JSON サポートの機能を振り返ってみましたが、今回は PostgreSQL 9.3 で強化された JSON サポートの機能が、どのように利用できるようになったか確認してみます。 PostgreSQL 9.3 から JSON データ型のサポートが強化され、JSON データ型のオペレータや関数が利用できる様になりました。 PostgreSQL 9.2 では JSON データにインデックスを利用するには PLV8 を利用する必要がありました。PostgreSQL 9.3
PostgreSQLのJSON型とhstore型のパフォーマンス - still deeper
概要 postgres 9.2で追加されたjson型に、今開発中の9.3で新たに演算子/関数が追加されることが予定されています。 この変更によって、JSON型の中の任意の値を取得することが可能になります。 ところで、postgresには以前からhstoreというキーバリューの形で構造化データを扱う拡張が存在します。 9.3で追加されたjson演算子と、hstoreでどの程度パフォーマンス差があるのか、極々簡単に計測してみました。 リファレンス json演算子/関数 PostgreSQL: Documentation: devel: JSON Functions and Operators hstore演算子/関数 PostgreSQL: Documentation: devel: hstore 準備 postgres 9.3のビルド まだリリースされてないのでmasterをビルド。hsto
F.17. hstore — hstore key/value datatype
This module implements the hstore data type for storing sets of key/value pairs within a single PostgreSQL value. This can be useful in various scenarios, such as rows with many attributes that are rarely examined, or semi-structured data. Keys and values are simply text strings. This module is considered “trusted”, that is, it can be installed by non-superusers who have CREATE privilege on the cu
9.16. JSON Functions and Operators
functions and operators for processing and creating JSON data the SQL/JSON path language the SQL/JSON query functions To provide native support for JSON data types within the SQL environment, PostgreSQL implements the SQL/JSON data model. This model comprises sequences of items. Each item can hold SQL scalar values, with an additional SQL/JSON null value, and composite data structures that use JSO
#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
HOTの効果 (1) — Let's Postgres
NTT オープンソースソフトウェアセンタ 笠原 辰仁 現在 (2009年1月) の最新版であるPostgreSQL8.3では、「HOT」と呼ばれる機能が追加されています。この「HOT」により、PostgreSQLの更新処理性能が劇的に向上し、ガベージ発生量が大幅に減少しました。本シリーズでは3回に分けて、この「HOT」の効果や仕組み、そして上手な使い方を詳しく解説していきたいと思います。 まず第1回は、HOTのおかげで何がどれくらい良くなったのか？ということを実感していただくため、「HOTの効果」についてベンチマーク測定を見ながら解説していきたいと思います。 HOTとは？ 具体的な効果を見る前に、もう少しHOTについて説明します。HOTという名前は「Heap Only Tuple」から来ています。「ヒープのみのタプル」という意味ですが、もう少し言葉を足すと「インデックスを持たない、ヒープの
HOTの仕組み (1) — Let's Postgres
NTT オープンソースソフトウェアセンタ 笠原 辰仁 HOTシリーズの第2回です。前回は、HOTの効果をベンチマークの結果を通じて見たところ、性能改善に大きく貢献していることが窺えました。今回はそれをどう実現しているのか、どういう仕組みでHOTが成り立っているのか、を解説していきたいと思います。 前回に見えたHOTの効果は、端的に言うと以下の2つでした。 更新処理が速くなった ガベージの発生量が減った では、この2点が実現できた理由を、従来のPostgreSQLと比較しながら見ていきます。 どうして更新処理が速くなったのか？ 答えは、「不要なインデックスの更新をスキップするようになったから」です。PostgreSQLは、更新処理が実施された場合に新規データを追加し、既存のデータをそのまま残す（削除されたという情報を付与する）、という処理を行います。この時、バージョン8.2以前のPostgr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Performance Price of Foreign Keys in PostgreSQL - DZone