データベース

mysqldump でデータベースをダンプしようとしたら、こんなエラーが出て止まった経験はないでしょうか。 mysqldump: Got error: 1449: The user specified as a definer ('root'@'%') does not exist when using LOCK TABLES これは MySQL の DEFINER という仕組みに起因するエラーです。ビューやストアドプロシージャの作成時に記録された「定義者（DEFINER）」ユーザーが、現在のサーバー上に存在しない場合に発生します。 なぜ起きるのか MySQL のビュー、ストアドプロシージャ、トリガー、イベントには DEFINER 属性があります。これはそのオブジェクトを作成した MySQL ユーザーを記録したもので、SQL SECURITY DEFINER（デフォルト）の場合、オブジェクトの実行は DEFINER ユーザーの権限 で行われます。 mysqldump は LOCK TABLES を実行する際、ダンプ対象のビューなどの DEFINER ユーザーを参照します。このとき、DEFINER に設定されたユーザー（例: 'root'@'%'）がサーバー上に存在しなければ、エラー 1449 で処理が中断されます。 よくあるシナリオ: 本番環境から別環境にデータベースをコピーした際、元の環境にいた root@'%' が移行先に存在しない MySQL のユーザーを整理した際、ビューの DEFINER を更新し忘れた root@'localhost' しか存在しないのに、ビューが root@'%' で作成されていた DEFINER が問題のオブジェクトを特定する まず、どのオブジェクトが問題の原因かを information_schema で確認します。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 -- ビュー SELECT DEFINER, TABLE_SCHEMA, TABLE_NAME FROM information_schema.VIEWS WHERE DEFINER LIKE '%root@%'; -- ストアドプロシージャ / ファンクション SELECT DEFINER, ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE FROM information_schema.ROUTINES WHERE DEFINER LIKE '%root@%'; -- イベント SELECT EVENT_CATALOG, EVENT_SCHEMA, EVENT_NAME, DEFINER FROM information_schema.EVENTS WHERE DEFINER LIKE '%root@%'; -- トリガー SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER FROM information_schema.TRIGGERS WHERE DEFINER LIKE '%root@%'; 多くの場合、ビューが原因です。該当するオブジェクトが見つかったら、その定義を確認しましょう。 ...

Timee のプラットフォームエンジニアリングチームの徳富博氏による発表「急成長でぶつかったMySQLの罠とその向き合い方」から、Aurora MySQL 運用で遭遇した 7 つの重要な課題とその対策をまとめます。 サービスの急成長に伴い、小規模では問題にならなかった MySQL の挙動が本番環境で深刻な障害を引き起こすことがあります。この発表では、実際の運用経験に基づいた具体的な対策が共有されています。 1. DDL 実行の落とし穴 DDL（Data Definition Language: テーブル定義の変更操作）には「Online DDL」という仕組みがありますが、DDL 実行中もテーブルへのアクセスがブロックされないわけではありません。実際にはメタデータロック（MDL）が必ず発生します。 Aurora のレプリカでは DDL 実行時にコネクションが切断されるため、リトライロジックが必須 外部キー制約を追加する際は foreign_key_checks = 0 を設定すると、COPY アルゴリズムではなく INPLACE アルゴリズム（テーブルの再構築を伴わない方式）が使われ、影響を最小化できる 2. MDL ベースのデッドロック MDL デッドロックは SHOW ENGINE INNODB STATUS に表示されないため、標準的な監視では検知できません。 外部キーが存在すると、DROP/ALTER 操作時に親テーブルに対して広範な MDL が取得される 対策: DDL 操作の前に外部キー制約を削除する 3. レプリカがライターに影響を与える問題 Aurora ではレプリカとライターがストレージボリュームを共有しています。レプリカ上の長時間クエリが undo ログのクリーンアップを妨げ、ライターのパフォーマンスに影響します。 MySQL のデフォルトの分離レベルは REPEATABLE READ だが、分析用クエリには READ COMMITTED を使用することで、リードビューの保持期間を短縮し undo ログの蓄積を抑えられる 4. 同時リクエストによるデッドロック 高トラフィック環境では、確率的に発生する競合が確実に障害を引き起こすようになります。 ギャップロックパターン ギャップロック（インデックスレコード間の隙間に対するロック）同士は競合しませんが、複数のトランザクションが同時に INSERT を実行すると循環待ちが発生します。 ...

DuckDB は「SQLite の分析版」とも呼ばれるインプロセス OLAP データベースです。Apache Arrow、Apache Parquet と同じ列指向の思想を持ちますが、三者の役割はそれぞれ異なります。この記事では DuckDB のアーキテクチャ、Arrow・Parquet との関係、そして従来の行指向 DB との違いを整理します。 Parquet・Arrow・DuckDB の位置付け Parquet Arrow DuckDB 何か ディスク上の列指向ファイル形式 インメモリ列指向データフォーマット（仕様+ライブラリ） SQL データベースエンジン レイヤー ストレージ（ディスク） データ交換（メモリ） クエリ実行（エンジン） 目的 効率的な永続化・圧縮 アプリケーション間のゼロコピーデータ交換 SQL クエリの実行・最適化 三者は列指向エコシステムの異なるレイヤーを担っており、補完関係にあります。 [ディスク] Parquet ファイル（列指向・圧縮済み） ↓ 読み込み（必要な列だけ） [メモリ] Arrow フォーマット（列指向・ゼロコピー） ↓ クエリ実行 [エンジン] DuckDB（ベクトル化 SQL 実行） Parquet は「データの保存形式」、Arrow は「メモリ上のデータの並べ方の規格」、DuckDB は「SQL を実行するエンジン」です。三者とも列指向という共通思想を持つため、組み合わせるとデータ変換のオーバーヘッドがほぼ発生しません。 DuckDB の高速性を支える3つの柱 1. 列指向ストレージ 行単位ではなく列単位でデータを格納します。分析クエリ（SUM, AVG, GROUP BY など）で必要な列だけを読み込むため、I/O が効率的です。 2. ベクトル化実行エンジン 1行ずつではなく、列のチャンク（ベクトル）単位で処理します。これにより CPU キャッシュのヒット率が上がり、SIMD 命令も活用できます。 3. 自動並列化 マルチコアを自動的に活用し、クエリを並列実行します。ユーザー側で並列化の設定を意識する必要はありません。 ...

redis-py の Lock クラスは UUID ベースのトークンでロックの所有権を管理するが、フェンシングトークン（単調増加する数値）は提供しない。しかし、Lock クラスは do_acquire や Lua スクリプトをオーバーライドできる設計になっており、サブクラス化でフェンシングトークンを追加できる。 本記事では、redis-py の Lock を拡張してフェンシングトークンを発行する FencedLock クラスの実装例を紹介する。 前提知識：Redis の Lua スクリプティング Redis はバージョン 2.6 から Lua スクリプトの実行機能を内蔵している。EVAL コマンドで Lua スクリプトを Redis サーバー上で直接実行でき、複数の Redis コマンドをアトミック（不可分）に実行できる。 なぜ Lua スクリプトが必要か 通常、Redis コマンドは1つずつ実行される。例えば「キーが存在しなければセットし、同時にカウンターをインクリメントする」という処理を2つのコマンドで行うと、その間に他のクライアントが割り込む可能性がある： クライアント A: SET mykey value NX → 成功 ← クライアント B が割り込む余地 クライアント A: INCR counter → インクリメント Lua スクリプトを使えば、この2つの操作を1回のアトミックな呼び出しにまとめられる： 1 2 3 4 5 6 -- Redis サーバー上で実行される（他のコマンドは割り込めない） local ok = redis.call('SET', KEYS[1], ARGV[1], 'NX') if ok then return redis.call('INCR', KEYS[2]) end return nil Redis CLI での実行例 1 2 # EVAL "スクリプト" キーの数 キー1 キー2 ... 引数1 引数2 ... redis-cli EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey myvalue redis-py での実行例 1 2 3 4 5 6 7 8 9 10 import redis r = redis.Redis() # 方法1: eval で直接実行 r.eval("return redis.call('SET', KEYS[1], ARGV[1])", 1, "mykey", "myvalue") # 方法2: register_script で事前登録（推奨） # サーバー側に SHA1 でキャッシュされ、2回目以降はスクリプト本文の転送が不要 script = r.register_script("return redis.call('GET', KEYS[1])") result = script(keys=["mykey"]) セキュリティ上の注意 Lua スクリプトのパラメータは KEYS[] と ARGV[] で渡される。SQL のプリペアドステートメントと同様に、パラメータが文字列としてスクリプトに展開されることはないため、パラメータ経由でのインジェクションはできない。ただし、ユーザー入力でスクリプト文字列自体を動的に組み立てると危険なので、スクリプトは固定文字列として定義すること。 ...

Redis はキャッシュとして非常に優秀なツールだが、複数のチームやサービスが**共有状態（shared state）**として Redis を使い始めると、設計上の問題が発生しやすくなる。 キャッシュと共有状態の違い Redis をキャッシュとして使う場合、データは一時的なものであり、いつ消えても問題ない。元データは RDB などに存在し、キャッシュミス時に再構築できる。 一方、共有状態として使う場合は話が変わる。複数のサービスが同じ Redis キーを読み書きし、そのデータが「正」として扱われる。RDB のようなスキーマや制約がないため、以下の問題が起きやすい。 暗黙の契約に依存したデータ構造 RDB であればスキーマによってデータ構造が明示的に定義される。カラム名、型、制約、外部キーなどが設計書の役割を果たす。 Redis にはそのような仕組みがない。キーの命名規則やデータ形式は開発者間の「暗黙の契約」に依存する。チームが増えると、以下のような問題が顕在化する： キーの命名が衝突する — 異なるチームが同じプレフィックスを使ってしまう データ形式の不一致 — あるサービスは JSON、別のサービスは MessagePack で書き込む バージョン管理の欠如 — データ構造を変更しても、読み取り側が追従できない 「削除できないキー」問題 最も厄介な問題の一つが、誰が所有しているのか分からないキーが残り続けることだ。 本番環境で以下のような状況が発生する： # このキーは誰が作った？いつ expire する？削除していい？ GET user:session:abc123:metadata 作成したサービスがすでに廃止されている TTL が設定されていないため、永遠に残る 他のサービスが依存している可能性があり、安易に削除できない キーを「パブリック API」として扱う この問題に対する実践的なアプローチとして、Redis キーをパブリック API のように扱うという考え方がある： バージョニング — キー名にバージョンを含める（例: v2:user:session:{id}） ドキュメント化 — どのキーがどのサービスによって管理されているかを明文化する オーナーの明確化 — 各キーに責任を持つチーム・サービスを割り当てる TTL の必須化 — 共有キーには必ず TTL を設定し、期限切れを明示する 補足：分散ロック基盤としての Redis Redis を共有状態として使うもう一つの典型例が、トランザクション境界をまたぐ分散ロックだ。SET key value NX PX timeout を使ったロックや、Redlock アルゴリズムは広く利用されているが、ここにも落とし穴がある。 ...

技術評論社の Software Design 2026年4月号（2026年3月18日発売）の特集内容を紹介します。今号は PostgreSQL 18 のパフォーマンス最適化と、MCP サーバー開発という2つの注目特集が組まれています。 第1特集：PostgreSQL 18 に学ぶデータベース高速化機能 「アーキテクチャから見えてくる処理性能向上のヒント」と題した第1特集では、PostgreSQL 18 の新機能を軸にデータベース高速化のテクニックが解説されています。 章構成 第1章 データ処理メカニズムと高速化（三谷篤） 第2章 トランザクションとバックアップ（三谷篤） 第3章 クエリ最適化とオプティマイザー（篠田典良） 第4章 インデックス検索技法（篠田典良） 第5章 並列処理と JIT（寺内大輝） 第6章 PostgreSQL 互換クラウド DB 比較（小山哲志） 第7章 PostgreSQL 18 の新機能（寺内大輝） PostgreSQL のデータ処理メカニズムから始まり、クエリ最適化、インデックス活用、並列処理・JIT コンパイルまで、パフォーマンスチューニングの全体像をカバーする構成です。第6章では PostgreSQL 互換のクラウドデータベース（Amazon Aurora、AlloyDB など）の比較もあり、実務で選定する際の参考になります。 第2特集：MCP サーバー開発成功の秘訣 「事業戦略・品質・開発効率をふまえたアプローチ」と題した第2特集では、AI エージェントのツール連携で注目される MCP（Model Context Protocol）サーバーの開発について、実践的なアプローチが紹介されています。 章構成 第1章 MCP 設計ガイド（川崎庸市） 第2章 駅すぱあと API での事例（橋本あゆみ、平川瑞樹） 第3章 Sansan での事例（川瀬圭亮） MCP は Anthropic が提唱した AI モデルと外部ツールを接続するためのオープンプロトコルで、Claude Code をはじめ多くの AI ツールで採用が進んでいます。本特集では設計の基本方針に加え、駅すぱあと API や Sansan といった実サービスでの MCP サーバー構築事例が紹介されており、自社サービスに MCP を導入する際の具体的な指針が得られます。 ...

RuView × Wi-Fi電波で壁越し人体検知 — $48で心拍・姿勢を丸裸にする技術の実態 TL;DR: カメラなし・$48のESP32だけで壁の向こうの人間の心拍・呼吸・骨格17点を検知できるとするオープンソースプロジェクト「RuView」がSNSで話題に。原理はCMU発の査読済み研究に基づく実在技術だが、「28.5kスター」の裏には再現性への疑義とCSIハードウェアの壁がある。煽りと科学を分離して整理する。 話題の発端 @kosuke_agos氏のポスト（2026年3月5日、閲覧6.4万・ブックマーク456）が日本語圏で拡散。「市販Wi-Fiルーターだけで壁の向こう側の人間の心拍数や姿勢を完全に特定」「わずか48ドルで構築」という衝撃的な内容が注目を集めた。 https://x.com/kosuke_agos/status/2029392193325285521 RuView とは何か RuView（旧wifi-densepose）は、Wi-Fi信号のCSI（Channel State Information）を解析して、カメラなしで人体の姿勢推定・バイタルサイン検知を行うオープンソースプロジェクト。 GitHub: https://github.com/ruvnet/RuView スター: 28.5k / フォーク: 3.7k ライセンス: MIT 実装言語: Rust（Python比810倍の処理速度を主張） 主張されている性能 機能 スペック 骨格トラッキング 17箇所のキーポイント 呼吸検知 6-30 BPM 心拍検知 40-120 BPM 処理速度 54,000 fps（Rust実装） 壁越し検知距離 最大5m AIモデルサイズ 55KB（エッジ実行可能） ハードウェアコスト 〜$48（ESP32-S3 × 4-6台） 科学的な背景 — CMU「DensePose From WiFi」 RuView の理論的基盤は、カーネギーメロン大学（CMU）ロボティクス研究所が2022年に発表した査読済み論文「DensePose From WiFi」（arXiv: 2301.00250）。 論文の核心 Wi-Fiの**CSI（チャネル状態情報）**は、空間内の物体・人体による電波の反射・回折・散乱を数値化したもの CSI信号を画像的な2D特徴マップに変換するエンコーダ・デコーダネットワークを構築 修正版DensePose-RCNNで、2D特徴から人体表面のUV座標を推定 複数人の同時検知が可能で、カメラベースのアプローチに匹敵する性能を達成 この研究は実在し、査読を通過しており、Wi-Fi CSI による人体検知という原理自体は「嘘」ではない。 CSI の仕組み（簡略版） Wi-Fi ルーター → 電波送信（OFDM: 52サブキャリア） ↓ 人体が電波を反射・吸収・散乱 ↓ ESP32 受信 → 各サブキャリアの振幅・位相変化を記録（= CSI） ↓ AI が CSI パターンから人体の姿勢・バイタルを推定 呼吸は胸部の周期的な膨張・収縮（6-30回/分）、心拍は胸壁の微小振動（40-120回/分）として、CSIのFFT（高速フーリエ変換）解析で分離・抽出される。 ...

Redis Pub/Sub から Streams への移行で帯域 99% 削減 — 同時接続 30 万超チャットの実践記録 Keisuke Nishitani 氏(@Keisuke69)のポストで、LY Corp（旧 LINE）の技術ブログ記事が紹介されていました。同時接続数 30 万超の LINE 公式アカウント（OA）チャットが、メッセージ配信基盤を Redis Cluster の Pub/Sub から Redis Streams へ移行した事例です。ピーク時 1.5 Gbps だったノードあたりの帯域が 11 Mbps まで削減されたという結果は、大規模リアルタイムシステムを運用するエンジニアにとって示唆に富む内容です。 同時接続数30万超のチャットサービスのメッセージ配信基盤をRedis Pub/SubからRedis Streamsにした話 — @Keisuke69 背景 — Redis Cluster Pub/Sub のスケール限界 LINE 公式アカウントのチャット機能（OA チャット）は、ユーザーから送られたメッセージを OA オーナーにリアルタイムで配信する仕組みを持っています。この配信基盤として Redis Cluster の Pub/Sub を使用していました。 問題は Redis Cluster における Pub/Sub の仕様にあります。あるシャードに publish されたメッセージは、クラスター内の全シャードにブロードキャストされます。24 シャード構成であれば、1 メッセージが残り 23 シャードに伝搬するため、アウトバウンドトラフィックはインバウンドの 23 倍になります。 指標 値 クラスター構成 24 シャード / 48 ノード ノードあたり帯域（平常時） 500 Mbps ノードあたり帯域（ピーク時） 1.5 Gbps シャードを増やせばクラスター性能は上がりますが、同時にブロードキャストのトラフィックも増えるというジレンマがあり、スケールアウトが頭打ちになっていました。 ...

PolarDB for PostgreSQL PolarDB for PostgreSQL（以下、PolarDB）は、Alibaba Cloud が独自に開発したクラウドネイティブなデータベースサービスです。 このサービスは、PostgreSQL と 100%互換性があり、共有ストレージベースのアーキテクチャを採用しています。 これにより、計算とストレージが分離され、柔軟なスケーラビリティ、ミリ秒レベルの遅延、HTAP（Hybrid Transactional/Analytical Processing）機能を提供します ¹²。 主な特徴は以下の通りです： 柔軟なスケーラビリティ：ビジネス要件に応じて、計算クラスターやストレージクラスターをスケールアウトできます。 ミリ秒レベルの遅延：WAL（Write-Ahead Logging）ログが共有ストレージに保存され、メタデータのみがレプリケートされます。 HTAP 機能：OLTP（オンライントランザクション処理）と OLAP（オンライン分析処理）の両方をサポートするためのアーキテクチャを持っています ¹²³。 他に知りたいことがあれば教えてくださいね。 ソース: Copilot との会話、 2024/7/31 (1) GitHub - ApsaraDB/PolarDB-for-PostgreSQL: A cloud-native …. https://github.com/ApsaraDB/PolarDB-for-PostgreSQL. (2) PolarDB for PostgreSQL - Gitee. https://gitee.com/polardb/PolarDB-for-PostgreSQL. (3) PolarDB云原生数据库自研数据库_数据库-阿里云. https://polardbpg.com/. (4) PolarDB: 阿里云开源云原生数据库 PolarDB - Gitee. https://gitee.com/polardb. 記事 PolarDB for PostgreSQL 14 で pgvector と LangChain を使ってベクトル検索してみる

Redis キーの登録日時 Redis でキーを登録した時刻を取得するには、残念ながら直接的な方法はありません。Redis はキーの作成日時や更新日時を保存していないからです ¹。ただし、いくつかの回避策があります。 キーを登録するときに、別のキーにタイムスタンプを保存する。 例えば、SET foo barとするときに、SET foo:timestamp 1636106362というように、キーの名前に:timestampを付けて現在の UNIX 時間を値として保存する。 この方法では、キーの数が増えるとメモリの消費量も増えることに注意が必要です。 キーの値にタイムスタンプを含める。 例えば、SET foo bar:1636106362というように、値の末尾に:と現在の UNIX 時間を付ける。 この方法では、値の取得や操作において、タイムスタンプを除去する必要があることに注意が必要です。 キーに有効期限を設定する。 例えば、EXPIRE foo 3600とすると、キーfooは 1 時間後に削除される。 このとき、TTL fooとすると、キーの残りの有効期限が秒単位で返される。 この値から、キーの登録時刻を逆算することができる。この方法では、キーが削除されると時刻を取得できなくなることに注意が必要です。 以上の方法のいずれも完璧ではありませんが、Redis でキーの登録時刻を取得するための可能な解決策として参考にしてください。 ¹: Redis でキーの作成日時や更新日時を取得する方法はありますか？ - スタック・オーバーフロー. ソース: Bing との会話 2023/11/6 (1) redis-cli でよく使うコマンド 20 選 #Redis - Qiita. https://qiita.com/hatsu/items/a52817364160e0b6bb60. (2) redis-cli でよく使うコマンド 20 選 #Redis - Qiita. https://qiita.com/hatsu/items/a52817364160e0b6bb60. (3) 全データ型対応の操作 — redis 2.0.3 documentation - shibu.jp. http://redis.shibu.jp/commandreference/alldata.html. (4) 【2022 年最新版】【Redis メモ・3】キーに有効期限を付与し …. https://www.servernote.net/article.cgi?id=redis-note-3. (5) セッション管理として Redis を使用する - RAKUS Developers Blog …. https://tech-blog.rakus.co.jp/entry/2017/10/17/111828. (6) ja.wikipedia.org. https://ja.wikipedia.org/wiki/Redis.