Carpe Diem

備忘録

ACID

MongoDB Causal Consistency Session

概要 MongoDB Write Concern - Carpe Diem MongoDB Read Concern - Carpe Diem でデータの耐久性・一貫性・分離性・最新性などを保証する方法について説明しました。 しかし、これらの設定だけでは Causal Consistency - Carpe Diem で紹介した因果関係の一…

Causal Consistency

概要 Eventual Consistency(結果整合性)はレプリケーションラグにより「自分が書き込んだデータが読めない」といったような因果関係がおかしくなるケースがあります。 そこでより一貫性の強いものとしてCausal Consistency(因果一貫性)があります。 ※Cas…

MongoDB Read Concern

概要 前回 MongoDB Write Concern - Carpe Diem にてWrite Concernについて説明しました。 今回はRead Concernについて説明します。Read Concernはデータの分離性・一貫性・最新性を考慮する際に気をつけるべき設定です。 環境 MongoDB 3.6+ 前提知識 Point-…

MongoDB Write Concern

概要 MongoDBはデータがどこまで書き込まれたらクライアントにackを返すかという設定ができます。 その設定をWrite Concernといい、メモリまで保存されたのかディスクまで保存されたのか・何台のデータノードにデータが書き込まれたらといった指定が可能です…

Bigtableで複数クラスタ構成におけるデータ整合性の保証

背景 Bigtableはレプリケーションを有効にしたマルチクラスタ構成にすることで負荷分散、高可用性を保証することが可能です。 一方でマルチクラスタにすることで 単一行のトランザクションが効かなくなる 書き込み後読み取り操作でレプリケーション遅延によ…

トランザクション分離レベルのケースと対応方法

背景 トランザクションの分離レベルで出てくる用語がぱっと頭に浮かぶようまとめます。 起きうる問題 基本的にどのDBも単一オブジェクトの原子性と分離性は保証します。 つまりデータ送信の途中でネットワーク接続が切れたら断片のみ保存するのではなく、全…

etcdを使った分散ロック

概要 前回のRedisを使った分散ロックでは、正確なロックを取るためにはZookeeperやetcdを使うと良い、とまとめていました。 なので今回はetcdを用いて分散ロックを実現します。 環境 etcd v3.4.15 pkg.go.dev/go.etcd.io/etcd v3.5.0 go 1.16.0 事前知識 分…

Redisを使った分散ロック (SETNX, Redlock)

概要 分散システムにおいて同じリソースにアクセスする際にロック(排他制御)する仕組みを分散ロックといいます。 ロックを用いる背景としては主に2つあり、 目的 説明 具体例 効率 同じ作業を不必要に複数回行わないため キャッシュのOriginへのリクエス…

Consulを支える技術

概要 ConsulではSWIMやRaftといった技術を使っています。 今回はそれらを説明します。 環境 Consul 1.1.0 SWIM Gossip Protocol SWIMはGossip Protocolの一種で、主に クラスタのメンバ管理機能 メンバの障害検出機能 イベント伝播 で使われています。