PostgreSQLのJSONB型カラム内のキーにユニーク制約をつけてUPSERTする方法 - ほんじゃらねっと
Node.jsとPostgreSQLを使ってるなら、 もうデータは全部JSON形式で管理した方が楽なんじゃないの、 ということでPostgreSQLのJSON型カラムについて色々調べている。 JSON/JSONB型カラムの基本的な使い方についてはちょっと前に書いた。 blog.honjala.net 今回はJSONB型カラムに一意制約をつけたり、 それを利用してUPSERT処理を行う方法について調べたことを書く。 準備 前回書いたUPSERT記事と同じようなことがしたいので、 blog.honjala.net 下記のような商品データ用テーブルを用意する。 id列以外の情報はJSONB型カラムに入れちゃう想定。 drop table if exists upsert_products_js; create table upsert_products_js( id serial ,jsdoc
PostgreSQLでのUPSERT(INSERT or UPDATE)処理を検証する - ほんじゃらねっと
PostgreSQLでUPSERT（データがあればUPDATEしてなければINSERT）する 方法について調べたところ、いくつか書き方があるようだ。 UPSERT処理で気になるのは同時実行された際に 重複登録されたり重複エラーが発生しないかどうかなので、 その観点で下記の4パターンの方法を検証してみる。 UPDATEしてNOT FOUNDならINSERT CTEでUPDATEしてNOT EXISTSならINSERT INSERT ON CONFLICT DO UPDATE INSERTしてUNIQUE_VIOLATION EXCEPTIONならUPDATE 準備 下記の様な商品テーブルを用意する： drop table if exists upsert_products; create table upsert_products( id serial ,item_cd varchar(10
PostgreSQLでpg_bigmを使って中間一致like検索を高速化する - ほんじゃらねっと
昨日書いた下記記事の続き。 blog.honjala.net 全角半角大文字小文字ひらがなカタカナを区別せず高速検索できるようには なったのだけど、肝心のlike検索でインデックスが使えず 遅いままだったので、pg_bigmを導入してこれを解決する。 pg_bigmは簡単に言うと日本語の中間一致like検索でインデックスを 使えるようにしてくれるPostgreSQL用モジュール。 本家サイトはこちら： pg_bigm pg_bigmの導入方法と使い方についてはこちらのSlideShareを参考にした： PostgreSQLでpg_bigmを使って日本語全文検索 （MySQLとPostgreSQLの日本語全文検索勉強会 発表資料） from NTT DATA OSS Professional Services www.slideshare.net pg_bigmを導入する pg_bigmはR
PostgreSQLで全角半角大文字小文字ひらがなカタカナを区別せず検索したい！というよくあるわがままに応える - ほんじゃらねっと
したいしたい！絶対したい！と駄々をこねられたので調査してみた。 こういった区別なし検索を実装する方法としてパッと思いつくのは、 あらかじめ検索対象となるカラムの検索用カラムを用意して、 データ変更時にトリガーで 元カラムの内容を半角小文字英数字カタカナに変換したデータが入るようにしておき、 検索時はその検索用カラムを使用する、という方法。 これはめんどくさそうだ。 SQL Serverは照合順序の設定で制御できるらしい。 照合順序と Unicode のサポート PostgreSQLも同じことができないかと調べてみたけど、対応してなさそう。 第22章 多言語対応 他に方法がないか調べてみると、 「式インデックス」を使って、自作の変換用関数で変換したデータを インデックスに登録しておく方法を試しているページがあった。 PostgreSQLで全角半角を区別しない問い合わせ この方法なら少なくとも
PostgreSQLでテスト用組み合わせパターンデータを一括生成する - ほんじゃらねっと
先日書いたgenerate_series関数を使用したテストデータ生成の続き。 blog.honjala.net どうせテストデータを作成するなら、 連番だけでなく、必要なパターンの組み合わせデータを生成したい。 ちょっと前にPythonやClojureを使った組み合わせデータ作成のスクリプトを 作成した時は専用のライブラリを使用したのだけど、 blog.honjala.net PostgreSQLのgenerate_series関数とjoinを組み合わせたら ぐっと簡単に実現できた。 サンプル まずはシンプルに値の組み合わせデータを作成してみる。 select x ,y ,z from generate_series(1, 3) as x ,generate_series(0, 1) as y ,generate_series(1, 2) as z ; 結果はこうなる。 x | y |
JSONB型カラムでPostgreSQLをNoSQL風にスキーマレスに使う方法 - ほんじゃーねっと
PostgreSQL9.2以降のバージョンではjson型/jsonb型カラムが使える。 ちょっと特殊な記法を使うけど、 json/jsonbデータ内のキーをDBのカラムと同様に使えるようになるので、 スキーマレスDBのように同じテーブル内のレコードで 異なるデータ構成を持たせることができるようになる。 役に立ちそうなので触ってみた。 環境はPostgreSQL9.5。 公式ドキュメントのjson/jsonb型カラムに関する情報は下記のページに記載されている。 8.14. JSONデータ型 9.15. JSON関数と演算子 9.20. 集約関数 JSONB型カラムを持つテーブルを作成する サンプルとして商品情報を登録するテーブルを作成してみる。 JSON系のカラム型はJSON型とJSONB型カラムがあるけど、 公式ドキュメントによると、登録するJSONデータのマップキーの順序を どうしても守
PostgreSQLのgenerate_series関数でテスト用データを作成する - ほんじゃーねっと
これまでテスト用にたくさんデータを作成する時は、 PythonやらNode.jsやらでプログラムを書いてた。 blog.honjala.net PostgreSQLならgenerate_seriesという連続値生成関数を利用することで SQLだけで手軽にデータ生成できる、ということを発見したので、 今回は上記の記事と同じようなテストデータをSQLで作成してみる。 環境はPostgreSQL 9.5。 下記のようなテーブルを作成する。 drop table if exists bulk_test_items; create table bulk_test_items( id serial not null, item_cd varchar(100), name varchar(100), created timestamp default current_timestamp, primary
PostgresqlのSELECT句での関数呼び出し順序を確認した - ほんじゃらねっと
チーム内の雑談で、 Delete-Insert処理を1つのSQL文で行うとしたら、 SELECT文のSELECT句でDELETE用SPとINSERT用SPを呼び出す方法もあるよね、 SELECT句って記述順に実行してくれるのかな？ みたいな話になったので、検証してみた。 検証してみる 検証環境はCentOS環境上のPostgreSQL 9.5。 SPを使うのはちょっと面倒なので、 タイムスタンプを取得する関数で試してみる。 current_timestampやnow()は何度呼び出してもトランザクション開始時の時刻を 返してくれちゃうので、実際の現在時刻を返すclock_timestamp()を使う。 9.9. 日付/時刻関数と演算子 select clock_timestamp() as x, clock_timestamp() as y; 結果： x | y -------------
CakePHP SQLをログに記録
CakePHPで発行したSQLをログに記録する方法です。 DEBUG>=2にすれば画面下に表示されるSQL文ですが、DB処理後にリダイレクト等で遷移すると消えてしまいます。さらに本番稼働時は画面に表示するわけにはいかないのでやはりログに出力したいところです。 フレームワークに手を入れるのが一番簡単なのですが、バージョンが上がると面倒なので既存のDboSourceを継承したクラスにログ記録を追加します。 1. DboSourceを継承 dboはフレームワークで用意されているものだけでなく、app/model/dboにあるものもフレームワークで利用する事ができます。 ここではPostgreSQLを使うとしてDboPostgresを継承したDboPostgresLogを作ります。 ログ出力をON/OFFする定数LOG_SQLは後でcore.phpで定義します。 [app/model/dbo/db
ManyToMany？
2008/02/01 00:12 ※ 商品のリンクをクリックして何かを購入すると私に少額の報酬が入ることがあります【広告表示】 monologista がオープンソース化されようとしています。 monologistaは、昨年の5月にpateoさんが作って運用しているつぶやき系のwebアプリケーションです。pateoさんはプログラムも書きますが、本 職はデザイナさんなのでデザインも素敵です。 Djangoのtrunkで動くようにしてからオープンソース化するとのことで、Djangoのサンプルとしても、社内とかで使うつぶやきWebアプリとしても、期 待大なのです。 今、コードを直しつつブログでノウハウを公開されているところですが、丁度拙作の Tracka でも気になっているタイムライン（自分と、自分がフォローしている人の投稿が一覧されるもの）部分について言及されていたので、少し考えてみました。
ウノウラボ Unoh Labs: RDBで階層構造を扱うには？
yukiです。ダイエットを始めて3kg減ったと思ったら、風邪を引いて見事に1kg増量。 運動しないと駄目ですね。あと残り20kg、道のりは遠いです。 さて今回は、「RDBで階層構造を扱うには？」です。 あるサイトを構築中に階層構造をもったカテゴリ構造にすることになり、どのようにDBで扱うか悩みました。 DBはMySQLを採用していたので、この時点でぱっと頭に浮かんだ選択肢は以下のようなものでした。 XML-DBを利用する 親カテゴリレコードのプライマリIDを子カテゴリレコードに持たせる 親を含めた『絶対パス』を名称として扱い、取り出した後にパース ファイルシステムに同様のディレクトリ構造を作り、毎回パースする (1)のXMLDBはオープンソースのeXistやXindice、Yggdrasillなど様々な選択肢がありましたが、カテゴリのみの利用な割にメンテナンスコストが高すぎるので見送りま
Camelot – Trac
Camelot A python GUI framework on top of Elixir / Sqlalchemy inspired by the Django admin interface. Start building applications at warp speed, simply by adding some additional information to you Elixir model as demonstrated here source:trunk/example/model.py. Development targets : Responsiveness : applications build with Camelot should be able to handle large datasets The framework should care of
複合UNIQUEキーでも「INSERT ... ON DUPLICATE KEY UPDATE」構文は使える - 岩本隆史の日記帳（アーカイブ）
MySQLには「INSERT ... ON DUPLICATE KEY UPDATE」という便利な構文がある。INSERTの内容がUNIQUE制約に引っかかる場合に指定カラムの値をUPDATEしてくれるものだ。 この構文について「複合UNIQUEキーの場合には使えない」とする記事を見た。 注意点としては、複合UNIQUEキーを指定しているテーブルでは（column2とcolumn1の組でUNIQUEなど）、 UPDATE文が複数レコードにマッチする可能性がありますので、UNIQUEキー制約が単一カラムにしかないテーブルでのみ使用します。内部的に実行されるUPDATE文のWHERE節がUNIQUEキーのORで判定するためです。（WHERE column1=’’ OR column2=’’）複合UNIQUEキー制約があるテーブルに対しては、次のREPLACE構文が使えます。 http://ww
ビジネス - SQLチューニング -
ということで 今回はSQLチューニングを書いてみよう。 というのも、割と検索されてる。 確かに書いてあるけど まずみて、なんだここは！ とか思う人多数だと思われます（笑 だって元々FFブログなんだもんここ。 ゲーム系ブログにもう全然関係ない事書き連ねるような 邪道なことしてますからね（笑 さてさて、この前はINDEXのチューニングまで書きました。 このほかにもチューニングのやり方は何個かありますが ・ダイレクトロードインサート ・バルクフェッチ、バルクインサート ・ヒント句 などがあります。 ただし、チューニングに共通することですが 処理がシンプルであるものでしか通用しないのと よく理解しないまま利用すると、ますます遅くなる というのが弊害としてあるので そこは注意しましょう。 超苦労して作ったチューニングソースが 以前よりも遅い。しょぼぼぼぼーんで もうやだ！こんな会社辞めてやる！みたい
ビジネス - SQLチューニングそのさん -
さて、大きな課題にもう一つ インサート方法を早くする手段があります。 バルクフェッチ、バルクインサートです。 カーソル FOR ループってPL/SQLではたびたび登場します。 私はあんまり使わないですけど。 私はフェッチするときはこれ使います。 OPEN カーソル; LOOP FETCH カーソル INTO カーソル%ROWTYPEで作成した構造体; EXIT WHEN カーソル%NOTFOUND; /* 処理 */ END LOOP; まあでも、 FOR 構造体 IN カーソル LOOP でもおんなじですね。 でですね、じゃあバルクフェッチ、バルクインサートってなによって話しになるわけですけども この FOR の箇所が FORALL になります。 カーソル内にある情報を全部ぶん回すって感じ。 取り出すところと、INSERTするところとで 大量のデータを一度に処理するのにむいています。 こ
ビジネス - SQLチューニングそのに -
第二弾です。 前回はダイレクトロードインサートについて書きました。 あと残ってるのは ヒント句と、バルクフェッチバルクインサートですね。 ORACLE DBをターゲットにしてます。 ORACLEは確実にチューニングを行わないと 動かなくなるんで、チューニングは大事なプロセスですけども 観点としては ・ORACLEのDBがチューニングされているか ・発行するSQLにチューニングが施されているか が勝負どころとなります。 テンポラリに空きがない場合はハードウェア的なチューニングが必要ですしね。 絶対的にメモリが足りないとか、いくらでもハードウェア的要素は存在します。 SQLいっくら直しても、だめなものはだめになる。 でも、ハードに余裕あっても、おかしな結合ばっかしてるSQLはやっぱり遅いわけですけどもね。 まあ、今回は、ヒント句を書きます。 確か前回、バルクフェッチとか書こうと書いた記憶がある
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
はてなブログ | 無料ブログを作成しよう
Google Code Archive - Long-term storage for Google Code Project Hosting.
IDEA * IDEA
