開発者のためのSQLパフォーマンスの全て
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
timestamp with time zone型はタイムゾーン情報を持っていない - Qiita
絶対時刻と概念時刻 2015年1月1日00:00:00 という時刻表記は、地球上のどこで読んだかによって意味が変わってしまいます。このような時刻のことを 概念時刻 と呼ぶことにしましょう。ボジョレー・ヌーボーの解禁時刻、11月第3木曜日00:00:00も概念時刻だからこそ世界各地で解禁時刻が違い、バブル期は日本が世界で最初に解禁されるって盛り上がったものです。 2015年1月1日00:00:00（日本時間）、これなら 絶対時刻 です。世界のどこで読もうと、ある一瞬を意味します。これは2014年12月31日15:00:00（グリニッジ時間）と同じ瞬間を表しており、前者と後者は同じ瞬間の別表記に過ぎません。 OracleおよびPostgreSQLのtimestamp with time zone型が格納する値はその名前に反し、絶対時刻です。 タイムゾーン情報はまったく含まれていません。 具体的
イミュータブルデータモデル(入門編)
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
日立のデータベースはいかにしてTPCベンチマークの「世界初」をとったのか
TPCベンチマークの「世界初」を目指す！ 「TPC」って言葉、ある程度IT業界が長い人や、データベース関連お仕事に携わってる人なら、詳しいことはともかく、一度や二度は聞いたことあるのでは。TPCは“Transaction Processing Performance Council”の略で、日本語では「トランザクション処理性能評議会」とか呼ぶらしい。つまり、コンピュータシステムのトランザクション処理のパフォーマンスをベンチマークテストで測定して、その結果を審査・登録・公表しているところ。 よく目にする「TPCベンチマークで世界最高性能を記録！」とかいう謳い文句はこのことで、特にデータベース製品に関して言えば、このTPCベンチマークの結果がある意味「鑑定書」や「保証書」みたいな役割を果たしている。 ちなみに、TPCベンチマークテストは幾つかのカテゴリに分かれていて、特に有名なのが「TPC-C
PostgreSQLスキルアップノート
日付/時刻関連のデータ型【一覧に戻る】マニュアルへのリンクは/9.2/としています。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■■■■ PostgreSQL スキルアップノート ■■■■ ■◆■■ 日付/時刻関連のデータ型 ■■■■ ■■■■ ■■■■ 2013/03/04 ■■■■ 使用環境：PostgreSQL9.1.7 (CentOS6.2) (C) 2013 ohdb ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【マニュアル】 第8章データ型／日付/時刻データ型→●[マニュアル] 第9章関数と演算子／データ型書式設定関数→●[マニュアル] 第9章関数と演算子／日付/時刻関数と演算子→●[マニュアル] 第18章サーバの設定／クライアント接続デフォルト→●[マニュアル] 【マニュアル参考】 SQLコマンドリ
［新春特別放談］ニッポンのPostgreSQLコミュニティ生みの親、石井達夫氏が語るPostgreSQLの現在・過去・未来（2） | gihyo.jp
新春特別企画 ［新春特別放談］ニッポンのPostgreSQLコミュニティ生みの親、石井達夫氏が語るPostgreSQLの現在・過去・未来（2） 2014年を迎えるにあたり、PostgreSQLの現役コミッターで、黎明期から日本のPostgreSQLコミュニティを支えてきたSRA OSS, Inc. 日本支社 支社長 石井達夫氏にPostgreSQLを語っていただきます。続いては、PostgreSQLの次のバージョンとこれからについて伺いました。 石井達夫氏 「クラウド、ビッグデータ時代」にデータベースが果たす役割 ──次バージョンのPostgreSQL 9.4について、すこしお話を聞かせてください。2014年秋ごろのリリースと伺っていますが、石井さんが9.4で最も注目する新機能はどれになるでしょうか。 石井：まずロジカルレプリケーションですね。これまでも精度の高いレプリケーションは可能だ
Oracle/MySQL/PostgreSQLにおけるサブクエリを含むDMLの非互換性 - SH2の日記
JPOUG Advent Calendar 2013の23日目です。比較的簡単なDMLでもRDBMS間の非互換性が出てしまうという怖い話をします。 +----+------+ | id | data | +----+------+ | 1 | a | | 2 | b | | 3 | c | +----+------+BEGIN; -- IDが最も小さいレコードをロックする SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE; (何らかの処理) -- 処理が終わったので削除する DELETE FROM q WHERE id = (1つ目のSQLで取得したID); COMMIT;IDが最も小さいレコードをロックし、何らかの処理を行って、最後にそのレコードを削除します。IDが最も小さいレコードを取得するというの
第3回 テーブル設計のグレーゾーン～毒と薬は紙一重 （4）サロゲートキーVSナチュラルキー | gihyo.jp
サロゲートキーVSナチュラルキー DBエンジニアの方なら、サロゲートキー（代理キー）という言葉をご存じでしょう。これは、テーブルへの入力データにある列を主キーとせずに、システム側で独自に割り当てるキーのことです（一般的には連番が使われます）。これに対して、入力データ自体の列を主キーにする場合はナチュラルキー（自然キー）と呼びます。 サロゲートキーは、基本的には不要なものです。入力データに一意なキーが存在していればそれを主キーとして使うことで、普通は問題ありませんし、オートナンバリングの機能も長らく標準SQLには存在していなかったからです（そのため、今でも実装ごとにやり方はバラバラです）。しかし、以下のような業務要件の場合には、サロゲートキーを使うことを考えます。 ① そもそも入力データに主キーにできる項目がなく、データが重複している場合 ② 主キーの値が使いまわされる場合 ③ 主キ
DB-Engines Ranking
This is the June 2024 issue of the monthly DB-Engines Ranking of database management systems. You can find the complete and most up-to-date ranking at DB-Engines.com. RankDBMSScoreChanges1.Oracle1244.08+ 7.792.MySQL1061.34-22.393.Microsoft SQL Server821.56-2.734.PostgreSQL636.25-9.305.MongoDB421.08-0.586.Redis155.94-1.866.Redis155.94-1.867.Elasticsearch132.83-2.528.Snowflake130.36+ 9.039.IBM Db212
DBエンジニアのための技術勉強会で発表したスライドを公開しました。
DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと
PostgreSQL 9.3正式版が公開。1秒以下の高速フェイルオーバー、データチェックサムによる高信頼性、マテリアライズドビューなどの新機能
PostgreSQL 9.3正式版が公開。1秒以下の高速フェイルオーバー、データチェックサムによる高信頼性、マテリアライズドビューなどの新機能 「What's new in PostgreSQL 9.3」のページに並んだ項目から、主な新機能を抜き出してみました。 バルクロードの高速化のためのCOPY FREEZE カスタムバックグラウンドワーカー データチェックサム JSON機能の拡張 ラテラルジョイン イベントトリガー マテリアライズドビュー アップデータブルビュー 書き込み可能な外部テーブル 高速フェイルオーバー 過去のバージョンとの基本的な互換性は維持されています。 1秒以内でレプリカがマスターに昇格 高速フェイルオーバー機能では、レプリカデータベースがマスターへ昇格するのに1秒以内になるとのこと。 データチェックサムはページごとにデータのチェックサムを確認し、ストレージの障害などに
CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった
分散システムにおいては以下の3つの要素のうち2つしか同時に満たすことができない、というCAP定理を提唱したのは、Eric Brewer氏でした。 C：Consistency（一貫性） A：Availability（可用性） P：Tolerance to network Paritions（ネットワーク分断への耐性） 一般にリレーショナルデータベースでは、一貫性（C）と可用性（A）をできるだけ保証する代わりに、ネットワーク分断への耐性（P）を犠牲にしています。ネットワークが途中で切れたり大きく遅延した場合、動作が保証されなくなってしまうわけです。 一方でNoSQLでは一貫性（C）よりも可用性（A）とネットワーク分断への耐性（P）を優先させるものが多く、分散システムでの動作に向いていると説明されます。このようにNoSQLの説明にこのCAP定理がしばしば引用されることになり、NoSQLの普及とと
「5年後はPostgreSQLがOracleを上回る」、LPI-Japanのイベントから
Linux関連の技術者認定試験を実施するLPI-Japanは2013年3月5日、ビジネスにおけるOSS活用を促す活動の一環として、「新たなビジネスを切り開くオープンソース」と題するイベントを開催した。仮想化やOSSデータベース、サポートなどをテーマに、セミナーに4人が登壇した。 講演に先立ち、LPI-Japanの成井弦氏（理事長、写真1）がOSSのビジネスモデルについて現状を分析。典型的なモデルは「貢献の競争に勝つ」「サポートで稼ぐ」「自社ソフトウエア（あるいは自社製品をサポートするソフトウエア）のオープンソース化」の三つがあるとした。 特に一つ目の「貢献の競争に勝つ」では、Android OSの改善において世界最大の貢献をしている韓国サムソン電子の取り組みに注目すべきという。「サムソンは大きな貢献をすることで、Android OSを自社にとって都合がいいように改変しつつある」（同氏）。一
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
EnterpriseDBに訊いた、PostgreSQLコミュニティとEnterpriseDBの共存共栄の関係
データベース技術の羅針盤
組み込みデータベースのめくるめく世界へようこそ
PostgreSQL9.3 開発と運用を支える新機能
MySQL vs PostgreSQL: Which Open Source Database to Choose? Which one is best?
openprinting:database:databaseintro [Wiki]
Devsの常識、DBAは非常識
