PostgreSQLでは、4つの標準トランザクション分離レベルを全て要求することができます。 しかし、内部的には、リードコミッティド、リピータブルリードおよびシリアライザブルに対応する3つの独立した分離レベルのみがあります。 リードアンコミッティドレベルを選択した時、実際にはリードコミッティドになり、リピータブルリードのPostgreSQLでの実装ではファントムリードの可能性はありません。 このように実際の分離レベルは選択したレベルより厳密になることがあります。 これは標準SQLでも許されています。 この4つの分離レベルについては、発生してはならない事象のみが定義され、発生しなければならない事象は定義されていません。 PostgreSQLが3つの分離レベルのみを提供している理由は、多版型同時実行制御という仕組みに標準の分離レベルを関連付ける実際的な方法がこれしかなかったことです。 利用可能
(1) PostgreSQLのダンプツールを利用したバックアップ pg_dumpコマンド DBを運用しながらでも使えるbackupコマンド 中ではトランザクションブロック内でSELECT文を発行し、取得したデータを出力形式に合わせて整形した腕標準出力に出力 するらしい。 pg_dumpの出力形式 スクリプト形式(デフォルト) アーカイブ形式 が選択できる。 スクリプト形式 スクリプト形式の出力は、リストアに必要なSQL文の羅列が出る。 ので、psqlコマンドでリストアする。 スクリプト形式の場合はプレーンテキストなので、リストアの際にエラーが出たら、中を見れるという利点がある。 アーカイブ形式 バイナリの形で出力される。リストアはpsqlコマンドでなくpg_restoreコマンドで行う。 アーカイブ形式の利点は、 **｢指定したtableのみを選択してリストアできる｣**ことらしい。 また
はじめに Uberの初期のアーキテクチャは、Pythonで書かれたモノリシックなバックエンドアプリで構成されており、データの永続性のために Postgres を使っていました。当時から比べて今のUberのアーキテクチャはかなり変わっており、 マイクロサービス のモデルや新しいデータプラットフォームになりました。特に、以前Postgresを使っていたケースの多くで、今は Schemaless 、つまりMySQLの上で構築された新しいデータベースのシャーディングレイヤを使います。今回の投稿では、私たちが見つけたPostgresの欠点を探り、MySQLの上でSchemalessと他のバックエンドサービスを構築するに至った経緯について説明していきます。 Postgresのアーキテクチャ 私たちはPostgresで以下のような多くの制約に直面しました。 書き込みでの非能率的なアーキテクチャ 非能率的
こんにちは。Cacooチームのイニエスタこと、とおのぶです。CacooはデータベースのPostgreSQLのバージョンアップを実施しました。基本的には公式のpg_upgradeの手順に従っています。ここではドキュメントには記載の少ない具体的な作業内容の流れを紹介したいと思います。 理由 ユーザアンケートからみる Cacoo のコア・バリューで記されたとおり、全体的なパフォーマンスの向上については重要度の高い課題の一つです。PostgreSQL 9.5ではソート性能の大幅な改善が強化点の一つで、パフォーマンスの改善が見込まれます。またフェイルオーバ後、新しいマスターに追従するスタンバイとして、古いマスターサーバをオンラインに戻すことができるpg_rewindも、PostgreSQL 9.5の魅力の一つです。 バージョンアップ前の構成 構成は、マスタとスレーブのストリーミング・レプリケーション
IT Cutting Edge ─世界を変えるテクノロジの最前線 第7回UberエンジニアがブログでPostgreSQLにダメ出し、PostgreSQLコミッター石井達夫氏に反論を聞く デジタルディスラプションを象徴する企業として、いまこの瞬間も破竹の勢いで成長を続け、交通サービスの世界を大胆に塗り替えているUber。未上場ながらすでに企業価値は6兆円を超えているとも言われており、世界最大のユニコーン企業として、その動向はつねに注目されつづけています。 クラウドやビッグデータ分析、オープンソースなど、最先端のITをフル活用し、ごく短期間で劇的にビジネスを拡大させたUberに対しては、やはり技術者からの強い関心があつまります。現在、1200名を超えると言われるUberのエンジニアたちは何をどんな環境で使い、どう動かしているのか ―Uberのエンジニアリングチームが公開している技術ブログ「Ub
弊社では、RDBMSにPostgreSQLを利用して数年間サービスを運営しています。 PostgreSQLはMySQLと違って、Webサービスでの運用事例をあまり見かけないので、今回は弊社サービスの「夜行バス比較なび 」でどのように運用しているかを紹介いたします。 システムの特徴 ユーザからのアクセスは、9割が参照処理。 データはバッチ処理で、随時 ( 毎分 ) 更新されている。 参照SQLの結果はmemcachedを利用してキャッシュをしているが、データの更新頻度が高いため長時間のキャッシュはしていない。 参照SQLは、集計処理が多いため比較的重いSQL。 参照対象となるテーブルのデータ量は、最大で数100万レコードと比較的少ない。 24/7で稼働。 構成 AWSのEC2上に、PostgreSQL 9.3を導入しています。c4系のインスタンスを使いたいので、RDSは使っていません。インス
NTT オープンソースソフトウェアセンタ 板垣 貴裕 パーティショニングとはデータを複数に分割して格納することです。データを分割することにより、性能や運用性が向上し、故障の影響を局所化することができます。巨大なデータを扱う場合にはパーティショニング機能を利用することも検討してみてください。 この記事ではパーティショニングの概要と用途について説明しています。PostgreSQL での具体的な使い方については『パーティショニング : 使い方』を参照してください。 パーティショニングの用途 パーティショニングには大きく分けて「テーブル間の分割」「ノード間の分割」の2つがあります。この記事では主にテーブル間の分割を扱います。 テーブル間の分割 巨大なテーブルを複数のテーブルに分割します。単純に複数のテーブルに分けて格納するだけでも効果はありますが、PostgreSQL は複数のパーティションを1つ
こんにちは。 プログラムがいつまでたっても直らないとおもったら、実は引数が間違っているような人間です。 PostgreSQLを5年使っていても、知らない関数というのはいっぱい出てくるものです。 LEAST/GREATEST (8.1以上) たとえば、表のような「5列あるカラムの最小値を使って」といわれた場合、1回取得したレコードをプログラム側で最小値をとることになるかと思いますが、クールにバチッとSQL1発で取得したいものです。 CASE文？いやいや、横にMINみたいなことできないの？ってときにこのLEAST。 examinationテーブル japanese mathematics english chemistry history 60 40 70 60 30 SQL SELECT LEAST(japanese, mathematics, english, chemistry, his
PostgreSQLアンチパターンの話をいっぱいしてきた。
見せてあげますよ、本当のPostgreSQLアンチパターンを。 とか言ってたわりに半分以上は削除フラグの話でした。 逆にそれが万人受けしたみたいでちょっとはてブいっぱい付いて承認欲求満たされました。 ということでスライドです。 190枚を超える超大作！！とか思ってたけど時間配分バッチシでした。 3回も実践すると3回目はアドリブ効かせたり出来て余裕がありました。 リハ大事ｗ で本題の伝えたいことですがあとがきツイートしてるのでまずそちらを。 なんか機能の資料みたら「PostgreSQLの便利な機能は使っちゃダメ」みたいな記事にいっぱいになるけどJSON型とマテビューはケースバイケースで積極的に使うもんじゃないよって話だし、ユニーク制約のWhere句とかは削除フラグ以外の時には便利ですよ。 — そーだい＠初代ALF (@soudai1025) 2015, 11月 29 .@soudai1025
37. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_flag = 0 WHERE blog.delete_flag = 0 38. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_flag = 0 WHERE blog.delete_flag = 0 ユーザの削除フラグを見る 39. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users
1. データベース技術の羅針盤 (db tech showcase 2013) Matsunobu Yoshinori (松信 嘉範) 2013.11.15 https://www.facebook.com/yoshinori.matsunobu 3. リレーショナル・データベース 最も基本となるデータベース技術 製品ラインアップも非常に豊富 商用：Oracle, SQL Server, DB2, Sybase, … オープンソース: MySQL, PostgreSQL, Firebird, … 設計理論はどの製品でもほぼ使い回し可能 テーブル設計/正規化, インデックス, SQL 製品特有のノウハウもある – パーティション、特殊SQL構文など 運用管理は製品によって大きく異なる どれか1つに詳しければ、2個目以降の学習はより簡単にできる 細かく見ていくとアーキテクチャはかなり違う その
外部キー便利!!! MackerelではPostgreSQLで外部キーあり そのレコードがあることが保証される 各テーブルのidにアプリケーションレベル(Mackerelの場合Scala)で型付けをするとなお便利 MemberID型、MonitorID型 → idで誤ったテーブルを引くとかがない 本日のスキーマ CREATE TABLE `member` ( `id` INTEGER unsigned NOT NULL auto_increment, `earned_item_count` INTEGER unsigned NOT NULL DEFAULT 0, `name` VARCHAR(191) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4; CREATE TABLE `item`
今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいましたが。。。 なかなかいい景色でした。（寒いけど） 「おおさんばし」って読むんですね。「だいさんばし」だと思ってた。。。 以下はいつもの、自分用メモです。 俺はどうしてそのデータストアを選択したのか 〜銀河と小宇宙を語る会〜 http://2015.cross-party.com/program/c1 遅れて入ったので、ちゃんと聴けてないです。 最近注目しているデータストアは？ Postgresql。JSON型が気になってる。 AiroSpike。データ型のあるデータストアが気になってる。 MongoDB。JSON使いたいなら、これじゃないの？ AWSのAurora。インスタンスタイプを選ばなくていい（選ばないといけないらしい）とか、勝手にスケールし
こんにちは、三苫です。 この記事はTECHSCORE Advent Calendar 2014、5日目の記事です。 近年、Rails複数DB Casual Talksが開催されるなど、Railsでも複数・異種データベース混在したシステム構成は何ら特別でなものではなく通常の開発でカジュアルに選択される構成だぞという機運が高まっています。 togetterで参加者の反応を見ても、「establish_connectionは基本」「前にも見たぞこのスライド」など、おおむね知見が業界全体に広まりつつある事がわかります。 本記事はRails複数DBがまだカジュアルではない時代、マルチテナントシステムのデータベースをMySQLからPostgreSQLに、各サブシステムは縮退しつつも、システム全体としては無停止で移行を行った記録を共有するためのものです。 移行したシステムの前提 マルチテナントシステム
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
