地方エンジニアの学習日記

興味ある技術の雑なメモだったりを書いてくブログ。たまに日記とガジェット紹介。

【データベース】楽観ロック

楽観ロックとは、「他のユーザーと同時にデータを更新する可能性は低い」という楽観的な前提に基づいた排他制御の方法です。データそのものにロックをかけず、更新処理時にデータが取得時と同じ状態であることを確認することで、データの整合性を保ちます。

例えば、図書館で本の貸出管理を行うシステムを考えましょう。本の在庫を示すカラムを持つ「書籍テーブル」があり、利用者が本を借りる際、この在庫カラムを更新するAPIが実行されます。

ある本の在庫が5冊ある状態で、利用者Aがこの本を2冊借りようとします。このとき、書籍テーブルの在庫は「3冊」になるべきです。しかし、同じタイミングで利用者Bも同じ本を3冊借りようとするとどうなるでしょう？

もし2つのリクエストが並行して処理されると、AとBがそれぞれ貸出処理を始めた時点で在庫は「5冊」と認識されます。結果として、Aが借りた後の在庫を「3冊」、Bが借りた後の在庫を「2冊」として計算してしまい、整合性が崩れる可能性があります。このような事態を避けるために、楽観ロックを用います。

具体的な楽観ロックの実装方法

楽観ロックを実装する方法としては、「更新前後でデータが変化していないかを確認する」ことが一般的です。

上記の例では、以下のような手順をとります：

  • APIが貸出処理を始める際、書籍テーブルの在庫カラムの現在の値（例えば「5冊」）を取得。
  • 本を借りるリクエストを受けた際、在庫カラムが取得時点と同じ値であることを確認。
  • 一致する場合、貸出処理を実行し、在庫を更新。
  • 一致しない場合（他の処理によって在庫が変更されていた場合）、エラーを返して処理を中止。

例えば、利用者AとBが同時に貸出リクエストを行った場合、Aが更新処理を完了した後、Bの処理では在庫の整合性が取れなくなるためエラーが返されます。その結果、1回のリクエストのみが成功し、データの整合性が保たれます。

【PostgreSQL】ユーザーを作成してテーブル作成権限を付与する

データベースを作成

create database test01

\l
                                                    List of databases
   Name    |  Owner   | Encoding | Locale Provider |  Collate   |   Ctype    | Locale | ICU Rules |   Access privileges
-----------+----------+----------+-----------------+------------+------------+--------+-----------+-----------------------
 postgres  | postgres | UTF8     | libc            | en_US.utf8 | en_US.utf8 |        |           |
 template0 | postgres | UTF8     | libc            | en_US.utf8 | en_US.utf8 |        |           | =c/postgres          +
           |          |          |                 |            |            |        |           | postgres=CTc/postgres
 template1 | postgres | UTF8     | libc            | en_US.utf8 | en_US.utf8 |        |           | =c/postgres          +
           |          |          |                 |            |            |        |           | postgres=CTc/postgres
 test01    | postgres | UTF8     | libc            | en_US.utf8 | en_US.utf8 |        |           |
(4 rows)

change

\c test01

ロールとユーザーを作成

test01=> create role test with login password 'test';

権限付与

test01=> GRANT CREATE ON SCHEMA public TO test;

【Aurora】Amazon Aurora DSQLのロマン

Amazon Aurora PostgreSQL Limitless Databaseでも十分ロマンがあると思っていましたがこのタイミングでDSQLが出てきて驚きです。Limitless DatabaseはNewSQLっぽいがマネージドでシャーディングをするというコンセプトがありました。一方でDSQLは純粋なNewSQLのように思えています。そもそもNewSQLの定義自体がどこかにあるわけでもないのでこれは感覚的な話なんだろうなとは思います...

ja.wikipedia.org

AuroraはDistributed SQLなのか？

これもWikipediaを見ると「複数のサーバー間でデータを複製する単一の リレーショナル データベース」と書いてあるのでAuoraも当てはまりそうというか一覧に入っていた。AuroraもLimitless DatabaseもDSQLもWikipediaの記載を見ると全部Distributed SQLになりそうです。今後この辺は厳密に定義されていくのかは気になるところです。

en.wikipedia.org

どこにロマンがあるのか

RDBとNoSQLのいいとこ取りで無限のスケール！って書いていくとあれすでにSpannerとかTiDBとかCosmoDBとかで実現できたきが...AWSで出すことにロマンがある..??AWSの参入によってこの辺の進化が早くなるのは楽しみです。

Amazon Time Sync

Spannerでは原子時計を使って正確な時刻を把握していましたがDSQLではまた違ったアプローチのようです。そういえば「Amazon Time Sync」というのがあったなと思うのですがこれ使われているのかな..??

aws.amazon.com

Distributed SQL Summit 2024

というのがあったらしい。YugabyteDBがめっちゃ取り上げられているがなんでだろ。

events.ringcentral.com

【Nginx】Upstream: re-resolvable servers

1.27.3で入ったアップデート。待望の機能じゃないでしょうか。有償版ではずっと前からあった機能でOSSの方にも欲しいなと思ったことが数年前くらいにありました。upstreamの名前解決 Nginxの再起動なしで行ってくれるというやつですね。

github.com

https://www.f5.com/company/blog/nginx/dns-service-discovery-nginx-plus

LB -> Nginx -> ドメイン指定のupstreamみたいな構成でupstreamのIPが変わってもNginxが名前解決をするのは起動時のみというやつで障害が起きてしまったりしました。それを解決することができます。

とはいえNginxのUpstreamは今だとlocalhostとかアプリの前に置いてるだけだったりするのであまり嬉しい場面がないかもな...となったりしました。使えるのは嬉しいのでいつかそういう場面が来たら活用しようと思います。