PostgreSQLのtext型のカラムに対してB-treeインデックスを作成した場合、そのカラムに大きな文字列がINSERTされるとエラーとなります。 (本記事はPostgreSQL 12.5 での確認結果を元に記載しています) たとえば下記のようなテーブルとインデックスを用意して

ウェブサイトやアプリケーションには、ユーザー名やメールアドレスといった小さなサイズのものからブログ本文といった大きなサイズのものまで多種多様なサイズのテキストが使われています。一般的にはテキストサイズによってデータベースを使い分けることはありませんが、データベースのPostgreSQLでは「中途半端なサイズ」のテキストデータを格納するとパフォーマンスの低下につながるという調査結果とその仕組みを、ソフトウェアエンジニアのHaki Benita氏が説明しています。 The Surprising Impact of Medium-Size Texts on PostgreSQL Performance | Haki Benita https://hakibenita.com/sql-medium-text-performance PostgreSQLの場合、データベースのインデックスとテーブルは
オープンソースのリレーショナルデータベース「PostgreSQL 13」の正式版がリリースされました(日本語プレスリリース。 PostgreSQLは、これまで2017年10月にPostgreSQL 10、2018年10月にPostgeSQL 11、2019年10月にPostgreSQL 12がリリースと、毎年この時期に順調にメジャーバージョンアップを続けています。 News: PostgreSQL 13 Released! https://t.co/krna5OWIq3 — PostgreSQL (@PostgreSQL) September 24, 2020 PostgreSQL 13では、標準インデックスであるB-Treeインデックスに重複排除(deduplication)機能が追加されたことで、重複したインデックスタプルをマージした効率の良い表現に変換しインデックスサイズを縮小。デー
要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある
(読みづらいタイトルだな) ことの発端はこのツイート。 MySQLは、以下を満たさないという理解でいいのか? エラーが出た時にPostgreSQLのようにロールバックを行わないので Atomicity(原子性)・・・トランザクションの実行結果は「全て成功」か「全て失敗」のいずれかでなければならない#mysql— imaharu (@imaharuTech) July 2, 2020 さすがの MySQL でもそこを破ってくることはないだろうと思いつつ、トランザクション野郎としてはちゃんと確かめねばならないと思い、早朝にも関わらず布団から出てラップトップを開いた(午前10時)。 実験1 以下のような docker-compose.yml と sql/script.sql を用意し、実験をする。 version: '3.3' services: db: image: mysql:8 envir
主要データベースを管理できる「DBeaver」開発チームは6月21日、最新版となる「DBeaver 7.1.1」を公開した。 DBeaverはマルチプラットフォーム対応のデータベース管理ツール。オープンソースのフレームワークをベースとし、プラグイン機構で機能機能できる。MySQL、PostgreSQL、SQLite、Oracleなど、JDBCドライバを持つ主要なデータベースをサポートする。Apache License 2.0の下で公開されている。 DBeaver 7.1.1は3月に公開したバージョン3の最新安定版。 データベースナビゲータでは接続タイプのハイライトのデザインが新しくなり、メインツールバーのインターフェイスを改善するなどの強化が加わった。データビューアも細かな強化や修正が加わった。 SQLエディタでは単一行での複数のSQLクエリパーサー、ソースコードからのペーストなどで不具合
Google、MySQL/PostgreSQLでクロスリージョンのレプリカを実現する「cross-region replica for Cloud SQL」発表 Googleは、MySQLとPostgreSQLなどのマネージドデータベースサービスを提供する「Google Cloud SQL」で、リージョンをまたいだレプリケーションを実現する新機能「cross-region replica for Cloud SQL」を発表しました。 cross-region replica for Cloud SQLは、マスターデータベースの内容を自動的に別のリージョンのデータベースに継続的に読み取り専用で複製する機能。Cloud SQLのMySQLとPostgreSQLで利用可能です。 これにより、万が一マスターデータベースのリージョンが丸ごと失われたとしても、別のリージョンに複製したデータは失われず、
データベース管理ツール「DBeaver」開発チームは3月2日、最新のメジャーリリースとなる「DBeaver 7.0」を発表した。無料のコミュニティ版をプロジェクトのWebサイトより入手できる。 DBeaverはMySQLやPostgreSQL、SQLite、Oracle、DB2などJDBCドライバーをサポートするデータベースに対応するデータベース管理ツール。開発者、データベース管理者などデータベースを扱うユーザーを対象としている。有料のEnterprise EditionではJDBCを利用しないMongoDB、Cassandra、Redisなどもサポートする。 DBeaver 7.0は、2019年3月に公開したバージョン6に続く最新のメジャーリリースとなる。タスク管理では、データ転送、バックアップと復旧、SQL実行などを強化した。CSVからのインポートの不具合を修正した。Git統合、SSH
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに データ分析とデータ品質改善に従事してきた筆者が、SQLを用いた分析の基本である「ウィンドウ関数」の使い方とデータ品質の調査改善を行う手法をまとめてみようと思います。 こちらの記事は、SQLの知識向上と振り返りを主題としているので、ABC分析、バスケット分析、RFM分析などの「データ分析の手法」について説明している記事ではありません。(反響やコメントによって別投稿するかもしれません) 背景 SQLはエンジニアの大多数が利用しており、多くの方はWebサービス開発などでデータの登録画面や検索画面を作る際にSQLを利用したり、またはシ
KotlinでWebアプリケーションを作るにあたり、SQLを直接記述できるタイプのO/Rマッパー(本稿ではSQLマッパーと呼びます)を探し求めました。 SQLマッパーに求める機能 SQLマッパーに求める機能はBindとMapです。この記事ではBindとMapを次のように定義します。 Bind SQLに埋め込んだプレースホルダー(名前付きが望ましい)に対応するパラメーター群を渡す機能。 例: SELECT ... WHERE price BETWEEN :minPrice AND :maxPrice のようなSQLに、minPriceとmaxPriceプロパティを持つオブジェクトを渡す。 Map 実行結果として得られた行をオブジェクトにマッピングする機能。 例: SELECT id, name, price FROM ... のようなSQLの実行結果を、id, name, price のプロ
NTT OSSセンタの澤田です。NTT OSSセンタでは、PostgreSQLをより便利で強力なデータベースにするために、PostgreSQLコミュニティと連携してさまざまな開発を行っています。 近年PostgreSQLの適用領域が広がってきおり、金融系システムや、個人情報を扱うシステムにも適用したいという要望が高まってきています。NTT OSSセンタでは、PCI-DSS(クレジットカードのセキュリティについて国際規約)等のよりセキュリティ要件の高い環境でもPostgreSQLを利用できるようにするために、セキュリティ機能の強化に取り組んでいます。その中でも、保存データの暗号化を行う「透過的暗号化機能」は最も注力して開発している機能の一つです。 本記事では、開発中の透過的暗号化機能の概要や特徴について解説します。 PostgreSQLの暗号化における課題PostgreSQLはPGP暗号化関
最近PostgreSQLでSQLチューニングや、DBが詰まった時の状況調査をいろいろやった。その時に便利だったクエリ達をまとめていく。PostgreSQLのバージョンは9.6系です。 SQLチューニングなどに便利だったクエリ達 それ以降に実行するSQLの実行時間を表示する。参考 https://morumoru00.wordpress.com/2011/05/08/postgresql-sql%E5%87%A6%E7%90%86%E6%99%82%E9%96%93%E3%82%92%E8%AA%BF%E3%81%B9%E3%82%8B%EF%BC%88timing/ \timing 実際にクエリを実行して実行計画や実行時間を表示する。クエリが実行されるので破壊的な操作も実行されてしまうことに注意。トランザクション張って最後にROLLBACKしましょう。参考 https://www.post
毎回わからなくなってググってるから今度からここに追記していく。 MySQL PostgreSQL SHOW DATABASES; \l USE dbname \c dbname SHOW TABLES; \dt SELECT * FROM tblname\G \x on SELECT * FROM tblname; SELECT * FROM information_schema.processlist; SELECT * FROM pg_stat_activity; KILL <pid>; SELECT pg_terminate_backend(pid); KILL QUERY <pid>; SELECT pg_cancel_backend(pid); table / column の情報 MySQL PostgreSQL SHOW TABLE STATUS FROM dbname; わ
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
https://mariadb.com/kb/en/optimizer-switch/にあるように、MariaDBのオプティマイザはかなり改良されている。 では、MariaDBのオプティマイザ/エクゼキュータはどの程度優秀か、4つのSELECT文の実行を通してMySQLと(ついでにPostgreSQLと)比較してみる。 (2014.12.3追記:オプティマイザについては省略してますが、こんな本がでます。) 結論を先にいえば「MySQLは検索が速い」というのは都市伝説。MariaDBはがんばってるけどPostgreSQLにはまだまだ及ばず。 *念のため。これはベンチマークじゃないよ、オプティマイザ/エクゼキュータの機能比較です。 自分で再確認したい場合はこちらにスクリプト群と実験のやり方を簡単に書いたので参照のこと。 調査環境 同一マシンにMySQL5.6.14、MariaDB10.0.4、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く