[個人的]データベースゆく年くる年 2024
2024年もおわり。 今年はいろいろと落ち着いた、と言えば聞こえが良いですが、飾らずに言えば個人的に停滞の1年でした。 それでもデータベース業界は前に進んでいます。遅れずに付いていければ良いですね。 データベース業界を振り返って 昨年の今ごろはマネージドシャーディング（参考）が話題でしたが、今年はいろいろとクラウドの垣根を超えるようなブレイクスルーが多く見られた1年でした。 大きなニュースの1つはOracle Database@AWS/Google Cloudでしょう。 Oracle Databaseのフル機能をクラウド上でどう使うかと言うのは、特にSIerにとって大きな課題で、これを解消する見込みがたち、クラウド移行計画を書き換えたPM諸氏も居たかもしれません。 もう1つのニュースは年末に登場したAurora DSQLです。 マネージドシャーディングを超えて、真のハイパースケールなRDB
![[個人的]データベースゆく年くる年 2024](https://cdn-ak-scissors.b.st-hatena.com/image/square/788b54c135316608c564be9574b66edff0a682a5/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--v4ZFRosy--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255B%2525E5%252580%25258B%2525E4%2525BA%2525BA%2525E7%25259A%252584%25255D%2525E3%252583%252587%2525E3%252583%2525BC%2525E3%252582%2525BF%2525E3%252583%252599%2525E3%252583%2525BC%2525E3%252582%2525B9%2525E3%252582%252586%2525E3%252581%25258F%2525E5%2525B9%2525B4%2525E3%252581%25258F%2525E3%252582%25258B%2525E5%2525B9%2525B4%2525202024%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3A%2525E3%252581%252593%2525E3%252581%2525B0%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzVmM2YwZjM3ZjguanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
データベースアップグレード後の性能劣化、イヤですよね。 去る2023年某日、弊社ではAmazon Aurora MySQL 互換エディション 2 (MySQL 5.7 互換) から Aurora MySQL 互換エディション 3 (MySQL 8.0 互換) にアップグレードしました。当時の背景やアップグレードに関する知見は以下の記事をぜひ読んでみてください。 blog.smartbank.co.jp ソフトウェアバージョンアップをするとき、旧バージョンが抱えていた問題の解決などの恩恵を我々は期待します。しかし時には予期せぬデグレーションに遭遇することもあります。我々のMySQL 8.0へのアップグレード前後においてもいくつかの問題に遭遇しました。 本記事ではそんな問題の一つ、MySQL 8.0のオプティマイザが選択したセミジョイン最適化が性能劣化を引き起こした事例と解決方法について紹介し
はじめに Goで自作RDBMSに挑戦してみたログです。自作、といっても大部分は参考にした書籍の移植です。 ここ1年くらいRDBに向き合う機会が多く、その内部実装を手を動かしながら身を持って理解してみたいというモチベーションから始めてみました。ちょうど会社の『内部構造から学ぶPostgreSQL』読書会に参加したこともモチベーション上げるきっかけとなりました。 (他の方の記事ですが、読書会の記録はこちら↓) 『内部構造から学ぶPostgreSQL』読書会を完走した感想 ［改訂3版］内部構造から学ぶPostgreSQLの社内読書会振り返り データベースをデータの箱としか思っていなかった私の『内部構造から学ぶPostgreSQL』を読んだ感想 普段何気なく使ってるRDBMSですが、ACID特性を守るため・大量の読み書きを捌くため、非常に緻密に設計されております。 これを完全再現といかなくとも自分
PostgreSQL Row Level Security (RLS) を使って顧客データ保護の安全性を高めている件 - Techouse Developers Blog
はじめに 初めまして、株式会社Techouseエンジニアインターンの sakaidubz と申します。本日は私の携わっているプロダクトであるクラウドハウス労務で利用している RLS (Row Level Security) の技術について紹介します。 Techouse では、重要技術として RLS を多用しています。 通常 PostgreSQL の運用時には利用しないものであるため Techouse の開発メンバーとしてジョインしたみなさんが手慣れるまでに少し苦労をされているようです。 そこでこの場を借りて解説してみようと思い立ちました。 クラウドハウス労務について RLS について紹介する前に、私が開発しているクラウドハウス労務について紹介します。 クラウドハウス労務は人事労務における複雑な業務の電子化を推進するセミオーダー型・クラウド業務支援サービスです。各種手続きや年末調整といった法
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 趣味でWebサービスを作ったはいいものの、サーバーの運用にコストがかかり結局停止してしまった経験、ありませんか？ これらの趣味で作ったサービスはアクセス数が少なく、数日に1人程度しかアクセスがないことも多いため、収益がない場合がほとんどです。 しかし、せっかく開発したのだから動かし続けたい気持ちはあると思いますし、運用し続けることで機能追加などをしてさらに楽しめることもあると思います。 このような運用コストに悩みがちな趣味開発Webアプリケーションですが、自分は趣味で現在いくつかのWebアプリケーションを月当たり2円というほぼ無料と言っ
PostgreSQL環境における、DB定義変更を伴う無停止リリース「概要と計画」編 - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは。 株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。 ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。 このプロジェクトで「PostgreSQL環境における、DB定義変更を伴う無停止リリース」にまつわる検証を進めているので、その中間報告を共有しようかと思います。 ※本記事はタイトルに「概要と計画」編とあるように、通年で行う調査の前半時点の中間報告となります。 実際の検証結果については3月末に予定している後編をお待ち下さい。 課題の経緯、前提条件 課題の経緯 無停止リリース実現のモチベーション 前提条件 実現手法 候補に上
PostgreSQL開発チームは先月（2025年5月）にリリースした「PostgreSQL 18 Beta 1」で非同期I/O処理を実装したことを明らかにしています。 同チームのテストによると、シーケンシャルスキャンやビットマップヒープスキャン、バキュームといった処理において2～3倍の性能向上が見られたとのことです。 同期処理はシンプルだが待ち時間が発生する これまでのPostgreSQLは同期I/O処理を採用していました。これは例えばOSにファイルリードのようなI/O処理を依頼すると、処理が終了して結果が返ってくるまで、すべてのPostgreSQLの内部処理が一時停止することを意味します。 同期I/O処理の利点はすべてのI/O処理が同期的に行われるため、実装が比較的シンプルで容易だというメリットがあります。これはバグを引き起こしにくいとも言えます。 一方で、ひとつひとつのI/O処理が完了
こんにちは。LINEヤフー株式会社でデータベースエンジニアをしている、松浦、中園、大塚、曽根、笠井です。 データベースはLINEヤフーのさまざまなサービスを支える重要なソフトウエアですが、その安定的な運用やトラブルシューティングには、データベースに関する専門的な知識が必要です。 一方で、データベース部門に配属される新卒のエンジニアは、全員が学生時代にデータベースを専門的に勉強しているわけではありません。このような新卒エンジニアは、データベース部門へ配属後、OJTや実際のデータベースの運用業務に携わりながら、データベースに関する専門知識を深めていきます。 今回のブログ記事では、データベースエンジニアとしての専門性を高めるために、部門内で実施している専門書の輪読会、そして、MySQLを題材としたデータベースカーネルのモブプログラミング（以下、モブプロ）の取り組みについてご紹介します。 1. 輪
マルチテナントなWebサービスでデータベースをBigQueryからPostgreSQLに移行してRow Level Securityを導入した - エムスリーテックブログ
こんにちは。AI・機械学習チームの高田です。 マルチテナント構成のWebサービスでは、データの分離とセキュリティを確保することが非常に重要です。マルチテナント構成とは、1つのシステムやアプリケーションを複数の顧客（テナント）で共有する設計アプローチを指します。 今回は、当社のあるプロダクトで行った2つの改善施策について紹介します。 BigQueryからPostgreSQLへの移行: より効率的なデータアクセスとコスト削減 Row Level Security（RLS）の導入: データベースレベルでのセキュリティ強化 これらの施策により、セキュリティ向上とコスト削減の両方を実現できた事例を解説していきます。 なぜ移行したのか テナントID分離型を採用 移行前のアーキテクチャ 移行後のアーキテクチャ PostgreSQLテーブル構築のためのバッチ処理の実装 PostgreSQLクエリの最適化
500万人が利用する「友達と遊べるたまり場アプリ パラレル」におけるデータベース基盤の継続的改善
SRE NEXT 2024 の発表資料です。 https://sre-next.dev/2024/schedule/#jp041 『友達と遊べるたまり場アプリ パラレル』では、クラウドベンダーによる不定期メンテナンスや季節イベントによるアクセス急増によってデータベースが不安定になり、最終的にサー…
kaigi on rails 2024の発表資料です https://kaigionrails.org/2024/talks/willnet/
AWSがMySQLのODBCドライバを開発、オープンソースで公開。純正ドライバ互換、Amazon Auroraでの高速なフェイルオーバー、AWSのシークレットやIAMのサポートなど
AWSがMySQLのODBCドライバを開発、オープンソースで公開。純正ドライバ互換、Amazon Auroraでの高速なフェイルオーバー、AWSのシークレットやIAMのサポートなど AWS ODBC Driver for MySQLは、MySQLコミュニティが配布している純正のMySQL用ODBCドライバと置き換えて使える互換性を備えつつ、AWSでMySQLを利用する際により優れた機能と性能を実現できるように実装されています。 具体的には、Amazon Auroraにおけるフェイルオーバー時の再接続の高速化です。AWS ODBC Driver for MySQLはクラスタのトポロジーと各 データベースインスタンスがプライマリなのかレプリカなのかの役割のキャッシュを保持することで、接続先のデータベースインスタンスに障害が発生し、別のデータベースインスタンスへのフェイルオーバーが発生したときに
はじめに こんにちは。コンシューマ事業部バックエンドエンジニアの高橋です。 今回は食事メニュー検索機能にOpenSearchを導入したことについて、お話しさせて頂こうと思います。 あすけんメニュー検索画面 なぜ導入しようと思ったのか あるデイリースクラムにて「『”水羊羹 とらや”』では検索できるのに、『”水ようかん とらや” 』では検索できない」という指摘がでてきました。確かにそれはユーザーにとって検索できない理由がわからず、ユーザビリティが低いと感じました。また、以前から「探したい食品がなかなか検索でヒットしない」という改善要望もありました。それらが今回の導入のきっかけです。 以前のメニュー検索 以前の検索ではデータベースに対しSQLの部分一致検索を行っていました。 OpenSearchで検索を行える状態にするためにはデータベースからOpenSearchへデータを同期する必要があり、また
はじめに 過去の古いMySQLのバージョンでは、テーブル定義の変更を伴うようなDDLを実行する際には、元のテーブルとは別に新しいテーブルを作成し、元のテーブルデータを新テーブルにコピーした後に元のテーブルと入れ替えるといった手法で行われていました。 また、その間の対象テーブルへの更新はブロックされるといった挙動であった為、アプリケーションサービスを稼働中にDDLを実行するというのが、かなり敷居が高いものでした。 それが、MySQL5.5 より Fast Index Creation が採用され、InnoDBのセカンダリインデックスの作成、削除にはテーブルコピーを伴わないで実行できるようになり、処理の高速化が図られています。 その後、MySQL5.6 ではオンラインDDLが使用できるようになり一部のDDLでは、テーブルコピーを伴わずに、更新もブロックしないということが可能となり、更に MyS
Your connected workspace for wiki, docs & projects | Notion
A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team
Announcing a new IDE for PostgreSQL in VS Code from Microsoft | Microsoft Community Hub
Announcing a new IDE for PostgreSQL in VS Code from Microsoft We are excited to announce the public preview of the brand-new PostgreSQL extension for Visual Studio Code (VS Code), designed to simplify PostgreSQL database management and development workflows. With this extension, you can now manage database objects, draft queries with intelligent assistance from context-aware IntelliSense and our ‘
この記事は MySQL Advent Calendar 2023 2日目の記事です。 (ちょっとフライング。。) 今回は僕がマジか、と思ってしまった MySQL の挙動について共有させていただきます。 BEGIN 中に BEGIN をすると COMMIT される 結論から言うとこれだけです ^^;; アプリエンジニアの方からお問い合わせをいただいた時にはこのことを意識したことすらなかったのでトランザクションの終了は COMMIT or ROLLBACK にてされるのだという先入観で動いていました。 ざっくりと言うとこんな感じ BEGIN; INSERT INTO testtable VALUES (1); BEGIN; このタイミングで別のターミナルを立ち上げて中身を確認するとなんと testtable には 1 という値が入っています。 個人的にはまじかーー、な挙動だったのでもしかしたら
はじめに Postgres には JSON/JSONB というデータ型がありますが，JSONB はデータをバイナリ形式で格納するためインサート時に変換のオーバーヘッドがあるものの，その後の処理が非常に高速である上に，インデックスを貼ることができるため，実用上は JSONB を使うのが一般的です． 一方で，そもそも RDB のようなスキーマの厳格な型付けをしているシステムで半構造化データである JSON を扱うこと自体がアンチパターンであるという指摘もあります． しかしながら，適切に設計，運用することで厳格な RDB で柔軟なデータを扱うことができ，アプリケーションの表現の幅を広げることができます． 本記事では，JSONB を可能な限り安全に扱うための実践的な工夫を紹介します． JSON Schema を使ったバリデーションを Check Constraint にする Postgres では
Webブラウザ上のWASM版PostgreSQLをサーバとし、PostgreSQLクライアントから接続可能になる「dabase.build:Live Share」、Supabaseが発表
Webブラウザ上のWASM版PostgreSQLをサーバとし、PostgreSQLクライアントから接続可能になる「dabase.build:Live Share」、Supabaseが発表 PostgreSQLをベースにしたBaaS（Backend as a Service）の「Supabase」を開発し提供しているSupabase社は、Webブラウザ上で実行中のWebAssembly版PostgreSQLをサーバとし、別のマシンからPostgreSQLのクライアントで接続できる新機能「dabase.build:Live Share」を発表しました。 Supabaseは今年（2024年）8月、Webブラウザ上でWebAssembly版PostgreSQLの「PGLite」を実行するサービス「database.build」（旧称：Postgres.new）の提供を開始しました。 これによりWe
DMMがMySQLのリプレース先としてGoogle Cloud SpannerとTiDBを比較、採用したのはTiDB。比較内容や結果を語る［PR］
DMMがMySQLのリプレース先としてGoogle Cloud SpannerとTiDBを比較、採用したのはTiDB。比較内容や結果を語る［PR］ オンラインゲーム、電子書籍、動画配信を始めとする60以上のサービスを提供しているDMM。同社の共通基盤を提供する組織「DMMプラットフォーム」は、オンプレミス上で稼働していたMySQLのリプレース先の検討過程でNewSQLのGoogle Cloud SpannerとTiDB/TiDB Cloudを比較しました。 その比較の結果、採用されたのはTiDB Cloudでした。 比較検討の結果として完成度はSpannerの方が高いとしながらも、なぜ同社はTiDB Cloudを採用したのか、そして実際に運用してどうだったのか。その内容が2024年7月3日に都内で行われたイベント「TiDB User Day 2024」のセッションで語られました。 本記事で
PostgreSQLをWebAssemblyとしてビルドした「PGlite」がPostgreSQL 17対応にバージョンアップ
PostgreSQLをWebAssemblyとしてビルドした「PGlite」がPostgreSQL 17対応にバージョンアップ PostgreSQLのソースコードをWebAssemblyバイナリとしてビルドしたことで、Node.jsなどのJavaScriptランタイムやWebブラウザ上でほぼフル機能のPostgreSQLを実行可能にした「PGlite」がバージョンアップして「PGlite 0.3」になり、PostgreSQL 17.4対応となりました。これまではPostgreSQL 16に対応していました。 PGliteはPostgreSQLのコードをWebAssembly化 PGliteはPostgreSQLのCのソースコードをEmscriptenコンパイラを用いてWebAssemblyバイナリとして出力、JavaScript/TypeScriptからライブラリとして呼び出せるようにした
Go の ORM はどのようにして AUTO INCREMENT で採番された値を取得しているのか？ - MySQL 編 - カミナシ エンジニアブログ
こんにちは。カミナシで「カミナシレポート」の開発を担当しているソフトウェアエンジニアの佐藤です。 カミナシレポートのバックエンドは Go で開発しており、データベースには Amazon Aurora MySQL を使用しています。また、データベースアクセスには ORM ライブラリの GORM を採用しています。 ほとんどのテーブルでは、プライマリキー（ID列）に AUTO INCREMENT を利用しています。これらのテーブルに GORM の Create メソッドなどを使って新しいレコードを挿入すると、AUTO INCREMENT で採番された値が自動的に対応する Struct のフィールドに反映されます。 AUTO INCREMENT による値の採番は MySQL 側で実行されているため、Go 側の Struct のフィールドに反映させるためには、Go アプリケーション側が何らかの方法
PostgreSQL 17正式リリース。WALの改善で書き込み性能が最大2倍に、本体付属のバックアップツールで増分バックアップ対応など新機能
PostgreSQL 17正式リリース。WALの改善で書き込み性能が最大2倍に、本体付属のバックアップツールで増分バックアップ対応など新機能 PostgreSQLは今年（2024年）に発表されたStack Overflowの調査でMySQLを抜いて最も使われているデータベースとなっているなど、人気が高まっているデータベースです。 参考：Stack Overflowが世界6万人以上のITエンジニアにアンケート。最も使われている言語はJavaScript、データベースはPostgreSQLが1位に定着。Stack Overflow 2024 Developer Survey WALの改善で書き込み性能が最大で2倍に PostgreSQL 17では、先行書き込みログ（WAL）処理の改善が行われました。 WALとは、トランザクション処理が確実に行われるためにトランザクション処理に先立ってつねに記録
MySQLのロックの種類とその競合
2024/06/20 GMOペパボ
PostgreSQLのRow Level Securityが有効でポリシーが付いているのかを調べるリンター postgrls を作った - 風に吹かれても
3行まとめ PostgreSQLのRLSはテーブル定義と共にポリシー定義をする必要があるが、別に定義する必要があるので忘れがち 人間が気をつけるのは不可能なので仕組みで解決するべくリンターを作った Cline + Claude 3.7 sonnetですぐ作れたけど楽しくなかった GitHub - Azuki-bar/postgrls: PostgreSQL RLS linter 背景 PostgreSQLのRow Level Security(以下RLS)を使ったことがありますか。 PostgreSQLではテーブル定義と共にAlter TableをしてRLSを有効にする必要があります。しかもこれだけではまだ不十分でそこからポリシーを有効にする必要があります。 -- https://www.postgresql.jp/document/16/html/ddl-rowsecurity.html
目的別データベースの実践: PostgreSQL 行レベルセキュリティと DynamoDB Outboxパターン - KAKEHASHI Tech Blog
カケハシのプラットフォームチームのテックリードとして組織管理サービスと認証基盤を開発している kosui (id:kosui_me) です。今回は、目的別データベースをプラットフォームチームではどのように実践しているかご紹介します。 この記事は秋の技術特集 2024の 13 記事目です。 背景 目的 事例1: PostgreSQL の行レベルセキュリティを活用する組織管理サービス 組織管理サービスとは PostgreSQL の行レベルセキュリティ 行レベルセキュリティを用いたトランザクションマネージャー 行レベルセキュリティの運用上の注意点 事例2: DynamoDB を活用する認証基盤と Outbox パターンの活用 カケハシの認証基盤刷新 DynamoDB で実現する高稼働率の認証基盤 DynamoDB の特性を考慮する CDC と Outbox パターン まとめ 背景 医療の分野で様
MySQLのDDLを安全に使うための全て
これはなに ども、LT開発部のもりたです。 今回はMySQLのスキーマ変更（DDL）について調べました。 DDLってなんとなく使うことは可能なんですが、データ量が増えていくにつれて障害の要因になったりもしますよね。もりたも障害が起きてDDLを調べたクチなんですが、調べれば調べるほどDDLに関する断片知識が絡まり合い、整理をつけるのが大変でした。今回はその断片を撚り合わせ、綺麗に縫合することで、この１記事だけで大体全てがわかるようにしました。もしDDLでお困りの方がいらっしゃいましたら、この記事（と、そこから辿れる諸記事）を足がかりに基礎と応用を身につけていただければと思います。 また、有識者の方々は是非まさかりを構えながら読んでください。技術的な間違いや現場的にはこうだよという事項がありましたら、コメント欄に記載いただけると幸いです。 構成 構成 まず構成ですが、以下の通り進めます。 前提
インデックスの"正解"を探せ！決済レスポンスタイムを改善したパフォーマンスチューニング - inSmartBank
はじめに サーバーサイドエンジニアの kurisu(ryomak) です。 普段は、カード決済やあとばらいチャージに関連する機能の開発・運用を行っております。 本記事でお話しすること 本記事では、インデックス追加によって決済レスポンスタイムを改善した事例をご紹介します。具体的なインデックス設計の検討や実行計画の見直しを通じて、どのようにレスポンスタイムを最適化したのか、その裏側を詳しく解説します。インデックス追加によるパフォーマンスチューニングの際の参考になれば幸いです。 はじめに 本記事でお話しすること 決済処理の遅延の検知 事の発端 実行環境 原因調査 遅くなったクエリの特定 対応検討 方針 検証項目 インデックスの「アタリ」をつける ① オーソリゼーション履歴：(オーソリゼーションID, 承認番号,受信日時) ② オーソリゼーション：(カードID, 初回受信日時) ③ オーソリゼーシ
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
AmebaのAurora MySQLをI/O Optimizedに切り替えたらコストが半額になりました - CyberAgent SRG #ca_srg
本記事は、CyberAgent Group SRE Advent Calendar 2024の5日目の記事です。 メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断
RDBでのツリー表現入門2024 | ドクセル
「楽しく楽にcoolにsmartに」を理想とするprogrammer/philosopher/liberalist/realist。 好きな言語はClojure, Haskell, Elixir, English, français, русский。 読書、プログラミング、語学、法学、数学が大好き! イルカと海も大好き🐬
いろいろありますが、今後のことを考える前にまずは、バージョン8.0.xの現状を一旦整理・理解してから決めようと思います。 念を押しておきますが、このブログの「内容は個人の考えであって、所属組織とは方針が異なる」と考えてください。 MySQL内部の人は、クラウドとか最新のサーバーとかしか利用していないのかも知れず、MySQL 8.0 が日に日に遅くなっていることに気づいていない人しかいないのでしょう。しかし、数年前のローカルPCで動かすと年々動作が鈍くなっているのを感じます。マイナーバージョンアップで単スレッド性能が下がり続けるなんて商用システムではリスキーです。 証明が難しく、ずっと放置せざるを得なかったのですが、非常に重要な事柄ですので今一度、オープンになっているソースを基に分析をしてみます。 まず、測るモノサシを決めましょう。以前のエントリ「MySQLバージョンアップによるInnoDB
導入 実行環境 テーブル定義 レコード作成 テーブルサイズ 検索速度 結論 We are hiring! 導入 みなさん、RDBのテーブル設計はしていますでしょうか。 テーブル設計時の大きな関心事の1つとして、主キー設計があります。 主キー設計では、「自然キー vs サロゲートキー」や「連番 vs 乱数」が主題になることが多いですが、今回はカラムサイズに注目して、主キーのサイズが検索性能に与える影響について調査してみたいと思います。 インデックスを使った検索が高速であることはRDBの常識中の常識ですが、その時もディスクやメモリからインデックスの値を読み取ってCPUを使って比較を行う操作が発生するわけで、値のサイズが小さいことは理屈上ではCPUキャッシュの利用やその他IO処理などにおいて有利に働くはずです。 今回は主キーを指定した単体取得のクエリにおいて、その影響がどの程度なのかを実際に計測
マイクロソフト、NoSQL標準の策定を目指し、Cosmos DBで使われている「DocumentDB」をオープンソースで公開。PostgreSQLをベースに
マイクロソフト、NoSQL標準の策定を目指し、Cosmos DBで使われている「DocumentDB」をオープンソースで公開。PostgreSQLをベースに マイクロソフトはNoSQLデータベースの実装として「DocumentDB」をオープンソースで公開したことを発表しました。 DocumentDBは、Microsoft Azure上のvCore-based Azure Cosmos DB for MongoDBとして提供されているNoSQLデータベースのオープンソース実装です（AWSもMongoDB互換の「Amazon DocumentDB」と呼ばれるサービスを提供していますが、別の実装です）（追記：当初、「Azure DocumentDB」のオープンソース実装と記述していましたが、間違いでしたので記述を改めました。お詫びして訂正します）。 Announcing DocumentDB,
DuckDB雑紹介
DuckDBを触っていて特に興味を持った機能を中心に雑解説します。
PGlite
PGliteEmbeddable Postgres Run a full Postgres database locally in WASM with reactivity and live sync.
SRE の鈴木 (id:eagletmt) です。先日、この開発者ブログで赤松から One Experience プロジェクトについての紹介がありました。 自分もこの One Experiene プロジェクトに携わっており、このプロジェクトが始まったちょうど1年くらい前にはイギリスにあるオフィスに行き、グローバル版のシステムを開発・運用しているメンバーと直接顔を合わせたりもしていました。自分は One Experience プロジェクトにおいて主にデータ移行について担当していました。データ移行に必要な作業はいくつかありますが、この記事ではその中から日本版のシステムのデータベースで発生したデータの変更をどのようにしてグローバル版のシステムのデータベースに継続的に反映したかの部分について紹介します。 One Experience でのデータ移行 赤松の記事にも書かれていたように、日本版とグロー
MySQLではレプリケーションがよく利用されます。また、アプリケーションは負荷分散のために、ソースだけでなくレプリカを参照系として利用することも多いです。しかし、レプリケーションは遅延するリスクがあります。そのため、アプリケーションは高負荷やロングトランザクションによる想定外の遅延が起こることを考慮して、設計や実装を検討しなければなりません。 MySQLでは遅延レプリケーションをサポートしています。遅延レプリケーションとは、ソースよりもレプリカへの適用を指定した時間だけ意図的に遅らせることができる仕組みです。ステートメント単位ではなく、トランザクション単位で遅延を発生させます。ソースへのトランザクション実行から指定した時間後に、レプリカに対してそのトランザクションを適用することになります。トランザクション内の各ステートメントは待機時間なく実行されます。 今回はこの遅延レプリケーションの設定
DMM.com が Amazon Aurora MySQL に移行して、最大 70% のパフォーマンス向上と運用コストの大幅削減を実現 | Amazon Web Services
Amazon Web Services ブログ DMM.com が Amazon Aurora MySQL に移行して、最大 70% のパフォーマンス向上と運用コストの大幅削減を実現 DMM.com は動画配信事業とオンラインゲーム事業、FX 等の金融サービスを主力として、オンライン英会話サービスなど 60 以上のサービスを展開している企業です。DMM.com では、オンプレミスの MySQL で稼働していたユーザーレビュー機能を、Aurora MySQL に移行しています。データの移行は AWS Database Migration Service (DMS) を使用してダウンタイムを最小限に抑えつつ、移行元への逆同期や SageMaker を使用したデータ検証の仕組みなど、様々な工夫をしながら移行を成功させることができました。本ブログでは、DMM.com でオンプレミスの MySQL
Postgresqlのltreeを活用した階層構造の便利な利用法 - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに ltreeとは ltree型 ltreeの操作 活用法 1. 承認フローの構築 事前準備 テーブル作成 データ追加 2. テーブルに細かくアクセス制御をかける 事前準備 ltreeの有効化 テーブル作成 ポリシー作成 行セキュリティポリシーの有効化 ポリシーの設定 データを追加 ユーザー作成 試す まとめ はじめに こんにちは！ エンジニア2年目のTKDSです！ 今回はltreeについて調べ、その活用法を考えてみました。 ltreeについて、ltreeの活用法の2段構成です。 ltreeとは 階層ツリー構造を模した構造を格納する機能を提供する拡張機能です。 詳しくはドキュメントをみてください。 ltree型 階層ツリー構造を表す型です。 例）`Company.Department.Team1 ドット区切りで大文字小文字は区別しないようです。 各データはラベルと呼びます（上記でのC
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL 8.0アップグレード後に性能劣化したクエリ: セミジョイン編 - inSmartBank
Goで自作RDBMS - abekoh's tech note
趣味開発Webアプリケーションのほぼ0円インフラ構成 - Qiita
次期PostgreSQL 18では非同期I/Oの採用により性能が2～3倍向上する見通し
データベースエンジニアのスキルアップ 専門書輪読会とMySQLモブプロの取り組み
Sidekiq vs Solid Queue
あすけんメニュー検索にOpenSearchを導入した話 - asken テックブログ
MySQLでオンラインでDDLを実行する際の注意点について | スマートスタイル TECH BLOG
BEGIN 中に BEGIN をすると COMMIT される
【PostgreSQL】いかにして JSONB を安全に扱うか
MySQL8.0で低速になったSELECT COUNTを高速化する - CyberAgent SRG #ca_srg
MySQL 8.0 は遅くなってきてる？何故？（１）
主キーサイズの違いによるPostgreSQLの検索性能の違いを比較する - ドワンゴ教育サービス開発者ブログ
DMS を利用した継続的なデータ変更検知 - クックパッド開発者ブログ
第230回 MySQLの遅延レプリケーションについて | gihyo.jp