index->lock の競合について 〜ベンチマークはちゃんとチューニングして〜
他に忘れないうちに書きたいこともあったのですが、世に出るまで書けないので、ソースと関係ない一般的なこと（バージョン5.7以降）を書きます。（書かない方のことは書けるようになる頃には忘れてしまうかも…） index->lockの競合を直して欲しい。という人がいまだに居たりするのです。色々試しましたが、多分殆どの場合は理解不足・チューニング不足です。私自身はindex->lockの競合が不可避なベンチマークに結局会っていません。 特にMySQLとその他のRDBMSを比べる場合にはちゃんと最適化した負荷をかけないとMySQLが悪く見えるのでベンチマークをする際には気をつけて欲しいものです。 5.7で更新・参照並列性を高めるために導入された、index->lockのSXロック（Sロックは可能・SX/Xロックは不可）は、基本的にそのindexにpageを追加・削除するような処理をする際に保持されます
ISUCON10予選で12位になり本選進出を決めました - Gマイナー志向
TL;DR ISUCON10の本選出場が決定しました。わいわい。 予選12位、最終スコアは2837でした。 毎年素晴らしいコンテストを開催してくださる運営様には、本当に頭が下がります。いつもありがとうございます。 本選もがんばるぞ！ 体制 チーム名 ウー馬場ーイーツ あいこん なまえ やくわり matsuu バリバリ実装する前衛 netmarkjp 司令塔 ishikawa84g SELinuxAppArmorとレギュレーションやコードやDiscordを見るセキュリティ＆情報官 今回は3人が同じ場所に集まらずすべてリモート体制としました。 3人だけのDiscordサーバを用意し、Discord上で画面共有と音声チャットで進めています。 方針 毎年同じですが sshで接続してtmux上でvimで直接編集 isuumo配下でgit initを実行するが履歴保存用でbranchは作成しない 毎年
Linux Networking Tools: 101
Representation Learning for Scale-free Networks: スケールフリーネットワークに対する表現学習
Percona Playback で 本番 MySQLに流れているクエリを試験環境でリプレイする - mita2 database life
データベースのバージョンアップの際、アプリケーションの網羅的なテストが可能であれば良いのですが、どうしても難しいケースがあります。 そのような場合、リプレイツールで本番環境に流れているクエリを、試験環境でリプレイ（再現）し、動作確認を取る方法もあります。 リプレイツールを探す MySQL の クエリ リプレイができるツールを探してみました。 Percona Tookit に pt-log-player というツールが含まれていたのですが、いつのまにか、なくなってました。。。 2013年にリリースされた、percona tookit 2.2 で削除されてしまったようです。 We removed pt-query-advisor, pt-tcp-model, pt-trend, and pt-log-player. Granted, no tool is ever really gone: i
100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本 心 in せろ部屋
要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある
データベースのドキュメント管理を自動化した話 - estie inside blog
こんにちは、今回はデータ基盤構築を担当しているmarushoがお送りします。 今日はestieで実践しているデータベースのドキュメント管理方法をご紹介します。 はじめに 独自成長していくデータベースたち 失われたドキュメント どうすれば低コストなドキュメント管理ができるのか そして生まれた、schema collectorという自動化ツール SchemaSpy Mysql diff Priv Page ECS タスクスケジューラ ドキュメントを腐らせない おわりに はじめに estieはオフィスを中心とした不動産データを取り扱うスタートアップ企業です。 estie（オフィス探しサービス）とestie pro（不動産事業者向けデータプラットフォーム）の2つのサービスを運営しています。 詳しくは、こちらの記事をご覧ください。 inside.estie.co.jp estieでは、不動産に関する
Amazon Aurora レプリカ では metadata lock 待ちが発生しない - mita2 database life
Amazon Aurora のレプリカは Vanilla MySQL のレプリケーションとは違った仕組みで実現されている。 マスターとレプリカは同じディスクボリュームを参照しており、マスターでの更新はほぼ即時レプリカに反映される。 DB クラスターボリュームは DB クラスターのデータの複数のコピーで構成されます。ただし、クラスターボリュームのデータは、DB クラスターのプライマリインスタンスおよび Aurora レプリカの 1 つの論理ボリュームとして表されます。この結果、すべての Aurora レプリカは、最短のレプリカラグでクエリの結果として同じデータを返します。 レプリカラグは、通常はプライマリインスタンスが更新を書き込んだ後、100 ミリ秒未満です。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide
performance_schema.events_statements_historyを使って直近に実行されたクエリを見る - kenken0807_DBメモ
さくっと、直近で実行されたクエリの情報がみたいです。 それにはperformance_schema.events_statements_historyテーブルを使います。 performance_schema.events_statements_historyはスレッドごとにperformance_schema_events_statements_history_size(default 10)で指定した個数分のステートメントを格納します。 MySQL5.7以降であればデフォルトONです。 以下のようなSQLを実行すればいい感じみれる。 SELECT * FROM ( SELECT THREAD_ID,EVENT_ID, BaseDate - interval (BaseUptime-ROUND(TIMER_START/1000000000000)) second as QUERY_STA
HammerDB with PostgreSQLにおけるTPC-Cベンチマークの一部不具合について - 三流エンジニアの落書き帳
ようやくプロ野球が開幕して1プロ野球ファンとしてはうれしい限りです。 無観客試合や過密スケジュールで選手にとってはやりにくいところもあると思いますが、怪我しないよう頑張っていただきたいものです。 そして、今年こそ優勝したい！！ さて、本題へ… 長いのでさっさと結論が知りたい場合は下記目次から「解決策」へジャンプしてください。 TL;DR(3行で) 概要 問題が発生した関数 現状の把握 関数にメッセージを埋め込みデバッグ（もどき）する 原因の把握 解決策 修正の効果の確認 まとめ TL;DR(3行で) ベンチマークツールHammerDBにおいてPostgreSQLのTPC-Cベンチマークを行うと一部関数で無限ループが生じ正確なベンチマークスコアが出ない 対象の関数はnewordで特定の条件下でのみ問題が生じる 簡単な修正で問題を解決できる(解決策は目次の「解決策」を参照) 概要 Hammer
LambdaからRDS/RDBを利用する際に意識したいポイント5選 | DevelopersIO
こちらの記事はRDS ProxyがGAされる前に執筆した記事です。現在はLambdaからRDSを利用する場合、間にRDS Proxyを挟むという選択肢が増えているので、まずはRDS Proxyを使う/使わないの検討をお願いします。以後で紹介しているトピックの一部はRDS Proxy利用時は考え方が変わってきます。 CX事業本部@大阪の岩田です。私が現在関わっているプロジェクトではLambda × RDSというアーキテクチャを採用して開発を進めています。開発を進める中でLambda × RDS(RDB)という構成についてある程度ノウハウが貯まってきたので、注意したいポイントやオススメの設定をTIPS的に紹介していきます。 環境 以後の説明では以下の環境の一部もしくは組み合わせを利用しています。具体的なコードやSQLの例はプログラミング言語やDBエンジンに依存しますが、根底の考え方はどの言語、
AWS LambdaとDynamoDBがこんなにツライ時代ではない - めもおきば
ありがたいことに、3年前に#ssmjp 2017/06で話したスライド AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp をTwitterで紹介して頂いた*1 ようで、当時から大幅に改善しているところを振り返りたいと思います。あと、ついでに最近やっているAzureに関しても少し触れていきます。 サーバーレスアーキテクチャ #とは 当時はこう説明したのですが、今でもそんなに悪くない表現かなと思います。 書籍は現在「Serverlessを支える技術 第3版」まで出ていますので、BOOTHからどうぞ（隙あらばダイマしていく方針）。 サーバーレス三種の神器 今このスライドを作るなら、認証認可の話を入れるかなと思います。システム内のAWS IAMとクライアント側のCognitoどちらも重要です。 ちなみにAzureを含めておさらいすると、こんな感じの対応になります。 勝
MySQL max_connections は雑に設定しておけば良い - mita2 database life
MySQL 誕生25周年 らしいです。めでたい！ 25年、１つのソフトウェアが継続しているってすごい！ max_connections について データベースを使っている開発者から「最大までどれぐらいコネクション数を増やせるのか」という質問を良くもらいます。 最大コネクション数（max_connections) の設定値を超えてしまい、too many connections エラーが出る。 max_connections を見直すとして、「じゃあどこまで大きくしていいのか？」と不安になるのはわかる。 以下の話は、コネクションプールを使っている前提のお話。 単にコネクション数が増えるだけでは、負荷は増加しない 単にコネクション数が増えるだけでは、DBサーバの負荷はあまり変化しない。 特にMySQLはスレッドモデルで実装されており、（プロセスモデルのデータベースと比較して）大量にコネクション
FILLFACTORによる性能改善 - 夜は寝る
めっちゃ寒くてマジ冬かってかんじ。 今日はポスグレアンカンファレンスというイベント当日、行けなくて悲しい。行けてたら発表しようかなと思っていた内容をブログに書く。微妙に前回分の発展版となっているので、ご興味がある方は、合わせてどうぞ。 TL;DR FILLFACTORの値を設定するとブロック内に空き領域を持つ HOTの効果により更新系の性能が改善する クラスタの維持により参照系の性能が改善する テーブルサイズとのトレードオフを考慮して設定するべき FILLFACTORとは 以前にブログにも書いたように、Postgresにおいてテーブルのデータはブロックという単位に区切られて格納される。ブロックはデフォルトで8KBであり、例えば一行が1KBのレコードなら8行が入る。 FILLFACTORの値を設定すると、このブロックに空きスペースを設ける。デフォルトでは「100」になっていて、前述のようにレ
PostgreSQLのデータベース容量見積
テーブルサイズが64590という大きなテーブルがあります。 上記はtext形式が存在するテーブルで、流石に1Gで試算するわけにもいかない と思い、30000バイトとして試算しようと考えています。 そこで、テーブルの計算式に当てはめると、 行数:10000、fillfactor:100、行データ長:64590 [テーブルデータ量式] 8KB × ceil(行数 / floor(floor(8KB × fillfactor - 24) / (28 + 行データ長))) =>8192 x ceil (10000 / floor( floor(8192 x 100 / 100 -24) / (28+64590))) となりますが、行データ長が大きすぎるため、行数の前のfloorによって0となってしまいます。 8192 x ceil ( 10000 / 0 ) で0除算でエラーとなり、計算出来ません
PostgreSQLの見積もりについて調べてみた - Qiita
はじめに PostgreSQLの見積もりは、テーブル、インデックスの他にも、WALファイル、アーカイブログ等の様々なファイルを含めて実施する必要があります。 とは言え、容量の大部分を占めるのはテーブルとインデックスであることは他のRDBと変わりはありません。 今回はテーブル・インデックスの見積もりについて調べてみました。 （間違いがあったら教えてください) PostgreSQLの見積もりの基本（だと思うこと） PostgreSQLの見積もりについて基本と思われることを書いてみます。 ページ PostgreSQLでは、実ファイル中のデータはページという単位で分かれています。 1ページは8192bytesでその中にテーブル・インデックスのデータが格納されます。 ページに含まれるデータは下表のアイテムで構成されます。 （引用：- PostgreSQL 11.5文書 68.6. データベースページ
PostgreSQL は更新処理を ROLLBACK してもテーブルファイルに追記される - ぱと隊長日誌
概要 PostgreSQL はテーブルに対する更新処理 (INSERT / UPDATE / DELETE) を行うと、テーブルファイルに追記されます（追記型アーキテクチャ）。これは最終的に COMMIT した場合に限らず、ROLLBACK された場合でも同様となります。 本エントリではこの挙動を検証します。 なお、追記型アーキテクチャについて知りたい方は下記の記事を参照ください。 PostgreSQL Deep Dive: PostgreSQLのストレージアーキテクチャ（基本編） 検証 検証環境 PostgreSQL 12.1 contrib モジュールをインストールしました。 postgresql.conf で "autovacuum = off" に設定しました。 ROLLBACK とテーブルファイルサイズ 各ステップでテーブルファイルサイズがどのように変化するかを確認します。 テス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQLの概念図（データベースクラスタ/データベース/スキーマ/テーブル） - Qiita
Innodb Deep Talk #2 でお話したスライド
1日で基本が身につく! Python超入門
勝手に学習 OSS-DB GOLD