Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 日本時間 2023/9/1(金)の深夜、AWSより以下のアップデートが発表されました！ 土曜の朝からXで早速話題になっています。 ニュースリリース ブログ ※全体的にまだ日本語ドキュメントに反映されていない情報が多いので、リンク先にRDS Extended Supportに関する言及が見られない場合は言語設定をEnglishに切り替えて再確認することをお勧めします。 3行でまとめると？ AWSはAuroraおよびRDSのDBエンジンの所定サポート終了後、最大3年の延長サポートを有償提供する 対象のDBエンジンはMySQL 5.7 & P
Developing a System to Investigate Lock Contention (Blocking) Causes in Aurora MySQL
Developing a System to Investigate Lock Contention (Blocking) Causes in Aurora MySQL Hello. I am @p2sk from the DBRE team. In the DBRE (Database Reliability Engineering) team, our cross-functional efforts are dedicated to addressing challenges such as resolving database-related issues and developing platforms that effectively balance governance with agility within our organization. DBRE is a relat
こんにちは、M-Yamashitaです。 今回の記事は、MySQLのAUTO_INCREMENTのidが戻ってしまう話です。 以前、RailsとMySQLを使うサービスにて、Mysql2::Error: Duplicate entry 'xxx' for keyが発生しました。このエラーの原因を調べたところ、テーブルでAUTO_INCREMENTとなっているカラムのidが戻って採番されており、その影響でエラーが発生していることがわかりました。当時の私の認識では、AUTO_INCREMENTとなっているidは、戻って採番されることはないと思っていたので非常に驚きました。 そのため、このidが戻る現象について調べて記事にしたいと思い、執筆しました。 なお、この記事ではMySQL 5.7を使用しています。 この記事で伝えたいこと MySQL再起動によりAUTO_INCREMENTのidが戻って採
![[MySQL]AUTO_INCREMENTのidが戻る](https://cdn-ak-scissors.b.st-hatena.com/image/square/0ab70d3892840fdc24c9655850acb7fa79a81c8b/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--VAbnYRNG--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BMySQL%25255DAUTO_INCREMENT%2525E3%252581%2525AEid%2525E3%252581%25258C%2525E6%252588%2525BB%2525E3%252582%25258B%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3AM-Yamashita%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2YyNjQ5YzE1YTAuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
こんにちは、ECプラットフォーム部の権守です。普段はID基盤やAPI Gatewayの開発を行い、ZOZOTOWNのリプレイスに携わっています。 本記事では、ID基盤で開発・導入したMySQL実行計画の簡易検査を行うツールを紹介します。 ツール開発の経緯 RDBにおけるテーブル設計は利用するクエリに応じて適切なインデックスを設定するなど専門的な知識を必要とし、設計できる人が限られてきます。しかし、アプリケーション上で利用されるクエリは機能の追加・改修に伴って日々変化していくため、それら全てに目を通し、漏れなく適切な設計することは困難です。そこで、専門的な知識がなくても設計に問題がないかの簡易的な検査を行えるツールを開発し、CIに組み込むことで自動的に問題を検出できるようにしました。 ツール開発のアプローチ ID基盤ではDBMSとしてAmazon Aurora MySQLを使用しています。そ
Ship faster with PostgresThe database developers trust, on a serverless platform designed to help you build reliable and scalable applications faster.
MySQLのDDLを安全に使うための全て
これはなに ども、LT開発部のもりたです。 今回はMySQLのスキーマ変更（DDL）について調べました。 DDLってなんとなく使うことは可能なんですが、データ量が増えていくにつれて障害の要因になったりもしますよね。もりたも障害が起きてDDLを調べたクチなんですが、調べれば調べるほどDDLに関する断片知識が絡まり合い、整理をつけるのが大変でした。今回はその断片を撚り合わせ、綺麗に縫合することで、この１記事だけで大体全てがわかるようにしました。もしDDLでお困りの方がいらっしゃいましたら、この記事（と、そこから辿れる諸記事）を足がかりに基礎と応用を身につけていただければと思います。 また、有識者の方々は是非まさかりを構えながら読んでください。技術的な間違いや現場的にはこうだよという事項がありましたら、コメント欄に記載いただけると幸いです。 構成 構成 まず構成ですが、以下の通り進めます。 前提
新サービス Aurora Serverless v2 の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering
2022.06.16 技術記事 新サービス Aurora Serverless v2 の検証とその評価 [DeNA インフラ SRE] by Keijun Kumagai #infrastructure #aurora #aws #database #technical-verification #game-infrastructure #infra-quality こんにちは！IT基盤部の k-jun です。IT基盤部にて大規模ゲームのインフラを見ているインフラエンジニアです。この記事では、2022/04/21 に GA となった AWS の新サービス Aurora Serverless v2 に対して行った技術検証とその調査結果をご紹介させて頂きます。 Aurora Serverless v2 とは Aurora Serverless v2 は Amazon Aurora のオンデマン
![新サービス Aurora Serverless v2 の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/edc2033bd2be270f3538bbd3e3b9bd2d546575d4/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2022%2F06%2Faurora-serverless-v2%2Fcover.png)
Amazon Web Services（AWS）は、オープンソースとして開発されているリレーショナルデータベース「MariaDB」の最上位スポンサーとなるダイアモンドスポンサーになったことを明らかにしました。 AWS is now the first diamond sponsor of the MariaDB Foundation @mariadb_org AWS engineers are significant contributors to the #opensource databases that our managed services are built on and that our customers depend on. Read more: https://t.co/VWzxIQzdPK #AWSCloud pic.twitter.com/97va28nHKl —
目的別データベースの実践: PostgreSQL 行レベルセキュリティと DynamoDB Outboxパターン - KAKEHASHI Tech Blog
カケハシのプラットフォームチームのテックリードとして組織管理サービスと認証基盤を開発している kosui (id:kosui_me) です。今回は、目的別データベースをプラットフォームチームではどのように実践しているかご紹介します。 この記事は秋の技術特集 2024の 13 記事目です。 背景 目的 事例1: PostgreSQL の行レベルセキュリティを活用する組織管理サービス 組織管理サービスとは PostgreSQL の行レベルセキュリティ 行レベルセキュリティを用いたトランザクションマネージャー 行レベルセキュリティの運用上の注意点 事例2: DynamoDB を活用する認証基盤と Outbox パターンの活用 カケハシの認証基盤刷新 DynamoDB で実現する高稼働率の認証基盤 DynamoDB の特性を考慮する CDC と Outbox パターン まとめ 背景 医療の分野で様
PostgreSQL Client から自作 DBMS に接続する - goropikariの備忘録
最近、Go の練習がてら書いていた自作 DBMS に PostgreSQL client で接続できるようになったので、そのやり方を残しておきます。(これから紹介するサンプルコードはすべて Python ですが) github.com psql --version psql (PostgreSQL) 13.2 pgcon の資料と PostgreSQL の公式 Document、加えて PostgreSQL server と client 間に流れるパケットを眺めると、自作DBMSは client から接続されたときにどういうパケットを返せばいいのかが見えてきます。 https://www.pgcon.org/2014/schedule/attachments/330_postgres-for-the-wire.pdf https://www.postgresql.org/docs/13/
Mirrativのバックエンド開発におけるMySQLとの向き合い方 - Mirrativ Tech Blog
こんにちは、バックエンドエンジニアのmakinoです。先日、LINE LIVEさんとの共催イベントにて「Mirrativを支えるバックエンド開発 ~MySQLとの向き合い方~」というテーマでLTをしました。 connpass.com speakerdeck.com 今回はLTの内容から一部抜粋して、Mirrativのバックエンド開発において遭遇したMySQLに関する問題と、その対策について紹介します。 問題 その1 データ量/QPSの増加に伴って、非効率なクエリが顕在化した サービス初期の段階ではデータ量が少なかったり、ユーザーのアクティビティが少ないために問題がなかったクエリも、サービスの成長に伴ってデータ量・QPSが増加したことによって、MySQLに負荷をかけてしまうことがありました。 具体例を以下にいくつか示します。 数千件レコードのfilesort 適切なindexが利用できればM
インデックスの"正解"を探せ！決済レスポンスタイムを改善したパフォーマンスチューニング - inSmartBank
はじめに サーバーサイドエンジニアの kurisu(ryomak) です。 普段は、カード決済やあとばらいチャージに関連する機能の開発・運用を行っております。 本記事でお話しすること 本記事では、インデックス追加によって決済レスポンスタイムを改善した事例をご紹介します。具体的なインデックス設計の検討や実行計画の見直しを通じて、どのようにレスポンスタイムを最適化したのか、その裏側を詳しく解説します。インデックス追加によるパフォーマンスチューニングの際の参考になれば幸いです。 はじめに 本記事でお話しすること 決済処理の遅延の検知 事の発端 実行環境 原因調査 遅くなったクエリの特定 対応検討 方針 検証項目 インデックスの「アタリ」をつける ① オーソリゼーション履歴：(オーソリゼーションID, 承認番号,受信日時) ② オーソリゼーション：(カードID, 初回受信日時) ③ オーソリゼーシ
RDS Proxyを用いたオンラインスイッチオーバーによるMySQLのアップグレードについて - freee Developers Hub
おはこんばんちは、DBREの橋本です。 今回は、Amazon RDS Proxy（以降RDS Proxyとよぶ）を用いたRDS for MySQLインスタンスおよびAurora MySQLクラスタのオンラインスイッチオーバーの手法について、ある程度社内での運用が確立してきましたので解説いたします。 従来のアップデート手法 AWS上でRDS for MySQLインスタンスやAurora MySQLクラスタ（以降これらをデータベースとしてまとめてよぶ）を運用している場合、それらのエンジンバージョンの更新を行ったり、OSバージョンの更新に伴う再起動を実施する必要があります。これらの更新を行う場合、以下のような方法が考えられます。 対象のデータベースに直接更新を適用する スナップショットを作成し、更新済みのデータベースとして復元する 更新済みの空のデータベースを新規作成し、そちらにデータを移行し、
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
tblsとGitHub Actionsを使ってDBマイグレーションを含むPRには自動更新したER図を追加する - BASEプロダクトチームブログ
BASEアドベントカレンダー2021 10日目の記事です。 BASEアドベントカレンダー2021 10日目 BASE BANKでエンジニアをしている @budougumi0617 です。 マイグレーションファイルが含まれたPull Request（PR）が作られたとき、自動更新したER図をPRに追加するGitHub Actionsを作りました。 本記事では紹介するGitHub Actionsを利用すると次のようなメリットが得られます。 マイグレーションファイルをPRに出すだけでPRに更新されたER図が追加される 開発者は面倒なER図の更新作業から開放される レビューアはマイグレーションファイルを含んだPRをER図を見ながらレビューできるようになる プロジェクト関係者は常にメインブランチのマイグレーションファイルの状態と一致したER図を確認できる サンプルPR 自動生成したER図 TL;DR
Google Cloud、高性能化したPostgreSQL互換「AlloyDB」のオンプレミス向けソフトウェア「AlloyDB Omni」発表。開発環境での利用は無料
Google Cloud、高性能化したPostgreSQL互換「AlloyDB」のオンプレミス向けソフトウェア「AlloyDB Omni」発表。開発環境での利用は無料 Google Cloudは、同社がPostgreSQL互換の高性能なマネージドデータベースサービスとして提供している「AlloyDB for PostgreSQL」と同じデータベースサーバを、オンプレミスやノートPCなどで実行できるソフトウェア「AlloyDB Omni」のテクニカルプレビュー版を発表しました。 Get a preview of AlloyDB Omni, a downloadable edition of #GoogleAlloyDB designed to run on premises, at the edge, across clouds, or even on developer laptops ↓
AmebaのAurora MySQLをI/O Optimizedに切り替えたらコストが半額になりました - CyberAgent SRG #ca_srg
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
PostgreSQL 18 Released!
The PostgreSQL Global Development Group today announced the release of PostgreSQL 18, the latest version of the world's most advanced open source database. Translations of this press release are available in the PostgreSQL 18 press kit. PostgreSQL 18 improves performance for workloads of all sizes through a new I/O subsystem that has demonstrated up to 3× performance improvements when reading from
AWS、追加料金なくAmazon RDS for PostgreSQLの性能を最大2倍に引き上げる「Amazon RDS Optimized Reads」のAmazon RDS for PostgreSQL対応を発表
AWSは、追加料金なしでAmazon RDS for PostgreSQLの性能を最大2倍に引き上げる「Amazon RDS Optimized Reads」のAmazon RDS for PostgreSQL対応を発表しました。 Amazon RDS Optimized Readsによる高速化の仕組み Amazon RDSは、データベースを格納するストレージとしてネットワーク上のElastic Block Storage（EBS）を利用しています。 今回リリースされたAmazon RDS Optimized Readsは、PostgreSQLがデータベース処理の際に生成する一時テーブルを、EBSの代わりにローカルのNVMeベースのSSDブロックレベルストレージに配置することで、ネットワーク上のEBSへのトラフィックを削減し、一時テーブルの処理を高速化、これによりクエリの高速処理を実現して
実際はどう？ 共通で言えること MySQL/Postgres とも，ファジーリードとファントムリードはセットで起こったり起こらなかったりするようになっているため， SQL 標準のように更新なのか新規・削除なのかを意識する機会は少ないです。 一貫性読み取りで参照するデータは，更新時に参照するデータ本体とは隔離された スナップショット になります。 文の種類 アクション 参照先 ロック
![[記事下書き] MySQL/Postgres におけるトランザクション分離レベルの実際](https://cdn-ak-scissors.b.st-hatena.com/image/square/be4a7bfbb640d53daec1dd96b5f2f8f4b120ea01/height=288;version=1;width=512/https%3A%2F%2Fstorage.googleapis.com%2Fzenn-user-upload%2Favatar%2F94ec78e846.jpeg){kind=avatar}
どこで手に入るの？ 何がはいってるの？ srcディレクトリを見てみる src/backendディレクトリにあるサーバ側のコードを見てみる ソースコードを読む際に知っておくと便利な関数 SQLを受け取り、処理する所 COPYやALTER TABLE等のDDLやSQLコマンドを実行する所 ソースコードを読む時に知っておくと便利な事(2020/12/15 追記) palloc()とpfree()関数 ereport()とelog()関数 先日のPostgreSQLアンカンファレンスでPostgreSQLのソースコードのディレクトリ構成や読み方について簡単に紹介しました。 ソースコードのディレクトリ構成は今後変わる予定があるので、ブログにまとめて今後も適宜アップデートしていこうと思います。 以下の説明はPostgreSQL 13をベースとしています。 どこで手に入るの？ 公式のgitリポジトリ g
MySQLの運用をコードで定義し大幅に自動化する「MySQL Operator for Kubernetes」がオープンソースで公開［PR］
MySQLの運用をコードで定義し大幅に自動化する「MySQL Operator for Kubernetes」がオープンソースで公開［PR］ Kubernetesのようなコンテナ環境では、MySQLデータベースのようなステートフルで高い安定性が求められるソフトウェアを運用することは難しいと、以前は考えられていました。 しかし現在ではステートフルセットのような機能もKubernetesは搭載し、実装も安定してきていることから、ステートフルなアプリケーションをKubernetesで実行できる状況が十分に揃ってきました。 それだけではありません。Kubernetesには運用自動化を支える「Operator」と呼ばれる拡張機能が登場しました。これを用いると、Kubernetes上でさまざまなアプリケーションでの運用作業の多くが人手を介することなく自動的に行えるようになります。 そしてこのOpera
PostgreSQL技術インデックス PostgreSQLインサイド PostgreSQLの活用技術について詳しく解説する記事が見つかる！ カテゴリーでの絞り込みができる「PostgreSQL技術インデックス」をご活用ください。
RDBでのツリー表現入門2024 | ドクセル
「楽しく楽にcoolにsmartに」を理想とするprogrammer/philosopher/liberalist/realist。 好きな言語はClojure, Haskell, Elixir, English, français, русский。 読書、プログラミング、語学、法学、数学が大好き! イルカと海も大好き🐬
マルチテナントにおけるRow Level Securityの具体的な実装と注意点 - そーだいなるらくがき帳
文脈、背景や問題点の説明 マルチテナントを実装するうえで企業情報（以下company）単位で最小限の情報を扱うようにしたいがcompany単位にTableを作ったりDatabaseを作るのはALTERなどの運用が大変。 そこでRLSを採用するために実際の技術検証をした上での注意点と実際の運用について必要な情報をまとめる。 PostgreSQL 14を前提としている 公式ドキュメント CREATE POLICY 必ず一読はすること。 困ったとき、わからないときはまずは公式ドキュメントを都度見ること。 このドキュメントのゴール RLSの概要をつかめる RLSの最低限の注意点を理解し、実装時に罠を踏まない 自分たちでRLSのポリシー自体をメンテナンスすることができ、デバッグできる テーブル構成 create table if not exists company ( id uuid defaul
Repro のサーバーサイド開発環境を M1 Mac に対応させるまでの道のり(再始動編) - Repro Tech Blog
こんにちは、@r_takaishi です。近所にスパイスカレーのお店ができてハッピーです。今回は、Reproのサーバーサイド開発環境におけるM1 Mac対応を改めて行ったので、やったことを紹介します。 なお、これまでの経緯は以下の通りです。 前回 Repro のサーバーサイド開発環境を M1 Mac に対応させるまでの道のり(撤退編) - Repro Tech Blog 前々回 Repro のサーバーサイド開発環境を M1 Mac に対応させるまでの道のり - Repro Tech Blog いつのまにかConfluent PlatformがM1 Mac上のDockerで動くようになっていた Repro のサーバーサイド開発環境を M1 Mac に対応させるまでの道のり(撤退編) - Repro Tech Blog ではConfluent Platformのコンテナイメージがx86_64の
はじめに SQLite3 くらい楽に扱えて、PostgreSQL みたいにネットワーク経由で使える物ないかなーなんて思ったりする事ないですか？ありますよね、あるんです。 postlite このニーズに答えてくれるのが postlite です。postlite を使うと SQLite3 で作られたデータベースファイルを、PostgreSQL の様に扱えます。 仕組みは至って簡単で、僕が開発している go-sqlite3 に PostgreSQL の通信プロトコルのガワと、仮想テーブルを使って PostgreSQL のスキーマを疑似しています。 インストール postlite は go-sqlite3 の vtable を使います。ですので、go install ではなく postlite の README.md に書かれた手順を使わなければなりません。
mysql:5.7 は ARM64 のコンテナイメージが提供されていないため、--platform linux/amd64 の指定が必須だった 指定しない場合 $ docker run --rm -it mysql:5.7 docker: no matching manifest for linux/arm64/v8 in the manifest list entries. See 'docker run --help'. $ docker run --rm -it --platform linux/amd64 mysql:5.7 2023-01-15 10:42:26+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.6.51-1debian9 started. 2023-01-15 10:42:26+00:
MySQL 8.0のクライアントでMySQL 5.7のサーバーに接続するとcharsetが設定されないかもしれない - かみぽわーる
mysql_options(mysql, MYSQL_SET_CHARSET_NAME, cs_name) だけして mysql_real_connect(mysql, ...) した後SHOW VARIABLESしてみたら接続のcharsetが設定済みの挙動をするんやけどmysql_real_connectからの一連のコード読んでもどこでそれが起きるのかわからん誰かたすけて🥲https://t.co/ZScoD3tIQ8— Ryuta Kamizono (@kamipo) February 20, 2021 MySQLのハンドシェイクパケットにcollation_idを1バイトだけ入れられるところがあって、charset name のデフォルトの collation_id を送っています。 クライアントとサーバーのバージョンが違うとデフォルトのcollation_idが違うことがあって
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog みなさん、こんにちは！ ヤフーでデータベースエンジニアをしている松浦です。 以前、不揮発性メモリに最適化したMySQLのストレージエンジン開発についてのブログ記事を執筆いたしました。 今回のブログ記事は、その続報です。不揮発性メモリ上のデータベースにおける、高可用性構成やその監視・運用に関わる研究開発成果をご紹介します。 前回記事の振り返り さて、本題に入る前に、まずは、前回のブログ記事の簡単な振り返りをさせてください。 前回のブログ記事では、DRAMのようにバイト単位でアクセスが可能だが、DRAMとは異なり、サーバの電源遮断後もデータが残り続け、また、NVMe SSDよりも高速な記憶デバイスである「不揮発性メモリ」の紹介をしまし
お知らせ 本記事をベースに新しい記事を公開しました。 PostgreSQL インデックス肥大化とインデックスコストへの影響（再モデル化） - ぱと隊長日誌 新しい記事ではインデックスコストモデルの正確性を向上させました。 新しい記事を参照いただけますと幸いです。 概要 PostgreSQL のインデックスサイズは一度大きくなると、その後小さくなるタイミングが限られています。 「［改訂新版］内部構造から学ぶPostgreSQL-設計・運用計画の鉄則」でインデックスファイルサイズが小さくなるのは以下のタイミングとしています。 DROP INDEX でインデックス自体を削除した場合 TRUNCATE TABLE でテーブル全体を空にした場合 REINDEX でインデックスを再構成した場合 [改訂新版]内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 (Software Design p
PGlite
PGliteEmbeddable Postgres Run a full Postgres database locally in WASM with reactivity and live sync.
Google Cloud、AI機能搭載のPostgreSQL互換ソフトウェア「AlloyDB Omni」正式版リリース
Google Cloud、AI機能搭載のPostgreSQL互換ソフトウェア「AlloyDB Omni」正式版リリース Google Cloudは独自に高性能化したPostgreSQL互換ソフトウェア「AlloyDB Omni」の正式版をリリースしたことを発表しました。 AlloyDB Omniは、Google CloudがPostgreSQL互換の高性能なマネージドデータベースサービスとして提供している「AlloyDB for PostgreSQL」と同じデータベースサーバを、オンプレミスやノートPCなどで実行できるソフトウェアとして開発が進められました。 参考：Google Cloud、高性能化したPostgreSQL互換「AlloyDB」のオンプレミス向けソフトウェア「AlloyDB Omni」発表。開発環境での利用は無料 トランザクション性能は2倍高速、分析的クエリは100倍高速に
いろいろありますが、今後のことを考える前にまずは、バージョン8.0.xの現状を一旦整理・理解してから決めようと思います。 念を押しておきますが、このブログの「内容は個人の考えであって、所属組織とは方針が異なる」と考えてください。 MySQL内部の人は、クラウドとか最新のサーバーとかしか利用していないのかも知れず、MySQL 8.0 が日に日に遅くなっていることに気づいていない人しかいないのでしょう。しかし、数年前のローカルPCで動かすと年々動作が鈍くなっているのを感じます。マイナーバージョンアップで単スレッド性能が下がり続けるなんて商用システムではリスキーです。 証明が難しく、ずっと放置せざるを得なかったのですが、非常に重要な事柄ですので今一度、オープンになっているソースを基に分析をしてみます。 まず、測るモノサシを決めましょう。以前のエントリ「MySQLバージョンアップによるInnoDB
一般論ですが、どんな基盤ソフトでもCPUスケールを上げようとすれば、何らかの排他制御を細かく行うことになるのでCPUのパイプライン処理にブレーキをかけるアトミックな処理が増えて、バージョンが上がるとある程度はシングルスレッドの処理は重くなっていきます。前エントリのような言語の高度化により遅くなる事情もあります。（中には、Redisのように並列を捨てて排他処理を完全排除する潔い逆振りプロダクトもありますが。） とはいえ、「これは（条件付きとはいえ）急に遅くなりすぎだろ！」と私も思うバージョン（回避策はある＆一開発者の一存ではどうにもできない）があるので遡って何点か挙げて注意喚起したいと思います。 これらはある程度限られた条件で発生するので世間では怪奇現象扱いされている可能性もあります。 何故こんなことになるのかというと、基盤となるmysqld側の変更に上手くついていけなくなってるか、性能上メ
変化の激しい現在のビジネス環境において、アプリケーションやサービスもその変化に素早く対応する必要がある。もちろん、それを支えるインフラについても同様だ。クラウドサービスやIaC（Infrastructure as Code）などを活用し、効率的にインフラを管理している企業も多いだろう。 ただ、ある意味でインフラは生き物だ。作った当初は問題なくても、管理する対象が増えたり、長期間運用していたりすると最初の方法ではうまくいかないことが増えてくる。ゲームビジネスで有名なスクウェア・エニックスにおいても、似たような課題があった。同社が提供するサービス（ゲーム）は種類も量もかなりの数で、気が付くと管理するサーバは「ちょっと手に余る台数」になっていたという。 大量のサーバを効率的に管理するためにはどのようなアプローチが有効なのか。「Cloud Operator Days Tokyo 2023」で発表さ
導入 実行環境 テーブル定義 レコード作成 テーブルサイズ 検索速度 結論 We are hiring! 導入 みなさん、RDBのテーブル設計はしていますでしょうか。 テーブル設計時の大きな関心事の1つとして、主キー設計があります。 主キー設計では、「自然キー vs サロゲートキー」や「連番 vs 乱数」が主題になることが多いですが、今回はカラムサイズに注目して、主キーのサイズが検索性能に与える影響について調査してみたいと思います。 インデックスを使った検索が高速であることはRDBの常識中の常識ですが、その時もディスクやメモリからインデックスの値を読み取ってCPUを使って比較を行う操作が発生するわけで、値のサイズが小さいことは理屈上ではCPUキャッシュの利用やその他IO処理などにおいて有利に働くはずです。 今回は主キーを指定した単体取得のクエリにおいて、その影響がどの程度なのかを実際に計測
オープンソースのリレーショナルデータベース「PostgreSQL 18」正式版のリリースが発表されました（日本語版のプレスリリース）。 PostgreSQLはITエンジニアのコミュニティであるStackoverflowの調査で2023年にMySQLを抜いて以来、3年連続でITエンジニアに最も人気のあるデータベースとなっています。 非同期I/O処理の採用による性能向上 PostgreSQL 18で最も注目すべき点は、非同期I/Oの導入による大幅な性能向上でしょう。 これまでのPostgreSQLでは同期I/O処理を採用していました。これは例えばOSにファイルリードのようなI/O処理を依頼すると、処理が終了して結果が返ってくるまで、同一プロセス（もしくはスレッド）の処理が一時停止することを意味します。 同期I/O処理の利点は実装が比較的シンプルで容易であり、バグが発生しにくい点にありますが、ひ
シンプルフォーム株式会社で SRE をしている守屋です。 本記事では Aurora MySQL の OOM(メモリ不足)エラーについて、原因となるクエリを特定するために役立つ Tips を弊社での実例を交えてご紹介します。 発端 突如 Slack に鳴り響く不吉な通知。 「パターン青！障害です！！」 どうやら本番環境の Aurora クラスターがフェイルオーバーしてアプリケーションが DB コネクションエラーを引き起こした模様です。幸いインスタンスは冗長化していて Aurora のフェイルオーバーは高速であるため、ユーザー目線では瞬断が発生した程度の比較的影響が小さめな障害に留まりました。しかし SRE としては捨ておけない状況です！早速原因の調査を始めました。 フェイルオーバーの原因 結論から言うとメモリ使用量がスパイクして OOM エラーが発生したことが原因でした。根拠としては Aur
Want to learn more about unlimited IOPS w/ Metal for Postgres and Vitess? Talk to Solutions By Matt Robenolt | January 4, 2023 Over here at PlanetScale, we offer you a MySQL database. As a part of this offering, it is critical that we offer you a MySQL protocol-compatible interface to access. This enables using mysql-client as well as any MySQL-compatible driver for your favorite language. But wha
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【塩漬けダメ絶対】AWSのAurora＆RDSがDBエンジンの延長サポートを有償提供！ - Qiita
[MySQL]AUTO_INCREMENTのidが戻る
MySQL実行計画の簡易検査ツールの開発とCIへの組み込み - ZOZO TECH BLOG
Neon Serverless Postgres — Ship faster
AWS、MariaDBの最上位スポンサーになったと発表。なぜMariaDBの大口スポンサーに？
MySQL8.0で低速になったSELECT COUNTを高速化する - CyberAgent SRG #ca_srg
[記事下書き] MySQL/Postgres におけるトランザクション分離レベルの実際
PostgreSQLのソースコードの構造
PostgreSQL技術インデックス｜PostgreSQLインサイド
SQLite3 を PostgreSQL にできるコマンド postlite
M1 Mac の Docker Desktop のアプデを mysql で確かめる
不揮発性メモリに最適化したMySQLの高可用性構成
PostgreSQL のインデックス肥大化と実行計画のコストへの影響 - ぱと隊長日誌
MySQL 8.0 は遅くなってきてる？何故？（１）
MySQLバージョンアップによるInnoDB性能劣化可能性事件簿
「ダブルチェックを頑張る」でごまかさない、スクウェア・エニックスのサーバ設定漏れ防止策
主キーサイズの違いによるPostgreSQLの検索性能の違いを比較する - ドワンゴ教育サービス開発者ブログ
PostgreSQL 18正式リリース。非同期I/Oによる最大3倍の性能向上、UUID v7対応など
Aurora MySQLのメモリ不足の原因を特定する
Faster MySQL with HTTP/3 — PlanetScale
www.chunichi.co.jp
japan.cnet.com
news.yahoo.co.jp
magazine.iis.u-tokyo.ac.jp
note.com/shibainu758
news.yahoo.co.jp