この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
Shiro Kawai on Twitter: "これはかなりすごいソーシャルハック。 「怪しいカードの利用がありました。マイアミで使いましたか?」 (いいえ) 「わかりました。このトランザクションはブロックします。本人確認のためメンバー番号を」 (メンバー番号自体は特に秘密でな… https://t.co/NHMlzcqkEj"
これはかなりすごいソーシャルハック。 「怪しいカードの利用がありました。マイアミで使いましたか?」 (いいえ) 「わかりました。このトランザクションはブロックします。本人確認のためメンバー番号を」 (メンバー番号自体は特に秘密でな… https://t.co/NHMlzcqkEj
この記事は DeNA 20 新卒 Advent Calendar 2020 19日目の記事です。 はじめに MySQLやPostgreSQLに代表されるRDBMSではトランザクションと呼ばれる仕組みが提供されています。多くのWebアプリケーションエンジニアはこのトランザクションを駆使してDBとやりとりをするロジックを組み立てることになります。 しかし不整合を起こしたくない処理があるからといって闇雲にトランザクションを張ったり、トランザクションが張られているからと安心してアプリケーション側で闇雲にロジックを組み立ててしまうと思わぬバグを生むことになってしまいます。 このエントリでは、「トランザクションを張っておけば大丈夫」という考え方は危険な場合もあるということを、ありがちな実装例を交えて紹介していきます。 並列に処理されるトランザクション そもそも、トランザクションは全て直列に処理されるわ
リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得られるということなのだと思うので、可能であればMVCCを採用したいのですが、あまり初学者向けの実装例も見当たらず、どうしたものかと悩んでおります。 SS2PL/S2PLとMVCCの実装の難易度・工数はどの程度違うものなのでしょうか？ また、初めてリレーショナルデータベースシステムを開発する者
AWS for Games Advent Calendar 2022 9日目の記事です。 Game Server Services(GS2) ではゲームに必要となるサーバー機能をマイクロサービス化し、皆さんに提供しています。 マイクロサービスには所持品の管理や、ゲーム内ストア、課金通貨の残高管理など30を超える機能を用意しており、これらを組み合わせながらゲーム内の仕様を実現できるようにしています。 さて、マイクロサービスの最も難しい課題はトランザクションにあると私は考えています。 今回は Game Server Services がどのようにこの課題に立ち向かい、そして問題を解決しているかお話ししたいと思います。 マイクロサービスとトランザクションの両立がなぜ難しいのか モノリシックなサーバーシステムは、大体の場合「所持品の所持数量」と「課金通貨の残高」は同じRDBに保存しています。 そし
このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む） そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ
モジュラモノリスにおけるトランザクション設計の考え方 / transaction design on modular monolith
モジュラモノリスにおいてトランザクションはどうあるべきなのかについて整理している資料が少ない気付きがあったので「簡易的に」整理しました
DB外の副作用をトランザクションから分離しよう / Isolate out-of-DB side effects from transactions
gotanda.rb#52@オンライン "DB外の副作用をトランザクションから分離しよう"
一歩ずつ一歩ずつ前へ進んでいく、確実に。どうも、かわしんです。 到底 1 記事に収まるような内容ではなく長いので、トランザクションの作り方に興味のない方は途中の「なぜ Go なのか」まで読んでいただければ嬉しいです。 この記事は、Go2 Advent Calendar 2019 の 7 日目と セキュリティキャンプ 修了生進捗 #seccamp OB/OG Advent Calendar 2019 の 7 日目を兼用しています。 さて、僕の興味は必要になったライブラリやミドルウェアなどを自作して、作りたいプロダクトを完成させることです。必要なコンポーネントがないからといってプロダクトを作るのを諦めたり妥協したりはしたくありません。 多くのアプリケーションではデータベースは重要なコンポーネントです。大抵のアプリケーションは MySQL や Postgres、Redis など既存のデータベース
読者対象 ANSI 定義の古典的なトランザクション分離レベルとアノマリーは概ね理解している MySQL/Postgres では理論的な部分がどうなっているのかを知りたい 理論面の前提知識 2022-08-19 追記: 社内勉強会向けのスライドを作成しました。先にスライドを見てから，引用文献およびこの記事を読むと理解が深まると思います。 まず ANSI 定義の古典的な定義を聞いたことが無い方は，以下のリンクを参照されたい。 ANSI 定義に対応する解説はこれらのサイト以外にもたくさんあるため，自分にとって読みやすいと感じる情報をあたってほしい。（既に熟知されている方は十分） 次点で読んでいただきたいのが， @kumagi さんの以下の記事。古典的には 4 つの分離レベルと 3 つのアノマリーだけで説明されていたものの，不十分であることが学術的に指摘され，解像度を上げようとする流れが後になって
MySQL/Postgres におけるトランザクション分離レベルと発生するアノマリーを整理する https://zenn.dev/mpyw/articles/rdb-transaction-isolations 上記のスライドの具体的な結論に至るまでの導入として，知識があまりない状態でも段階的に読み込んでいけるように心がけたスライドで，株式会社ゆめみの社内勉強会にて発表しました。 スライドの途中の URL などは PDF としてダウンロードするとクリックできると思います。 事前のレビュー協力者 - https://twitter.com/neko_han25 - https://twitter.com/KentarouTakeda
Amazon RDS MySQL/PostgreSQLのトランザクション性能が2倍に、可用性とスケーラビリティも高める新「マルチAZ配置オプション」登場
Amazon RDS MySQL/PostgreSQLのトランザクション性能が2倍に、可用性とスケーラビリティも高める新「マルチAZ配置オプション」登場 Amazon Web Servicesは、Amazon RDSのトランザクションの処理速度を最大で2倍にし、3台のクラスタ構成で可用性を高め、リードのスケーラビリティも向上する、新たな「Multi-AZ Deployment Option」（マルチAZ配置オプション）を発表しました。 New AWS News post by @sebsto: New Amazon RDS for MySQL & PostgreSQL Multi-AZ Deployment Option: Improved Write Performance & Faster Failoverhttps://t.co/sffr5boYlU — AWS Blogs (@AW
「Amazon Aurora Serverless V2」正式版に。瞬時にスケールして数十万トランザクションに対応、データベース容量も自動管理
「Amazon Aurora Serverless V2」正式版に。瞬時にスケールして数十万トランザクションに対応、データベース容量も自動管理 Amazon Web Services（AWS）は、クラウド上でデータベースのマネージドサービスとして提供している「Amazon Aurora Serverless」の新バージョン「Amazon Aurora Serverless V2」の正式版としてのリリースを発表しました。 Instant scale ↔️ instant cost efficiency. Amazon Aurora Serverless v2 scales in a fraction of a second while eliminating database capacity management, so you only pay for what you use & sa
実際はどう？ 共通で言えること 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}
トランザクションを考慮した実装について考える
はじめに アプリケーションレイヤーでトランザクションを考慮した実装をどのようにすればいいのか悩んでいる人が多いことに気がつきました。オニオンアーキテクチャ等でアプリケーションコードを関心ごとのレイヤーに分離するときに、トランザクションを開始するためのDBとのコネクションの作成をどのレイヤーで実施するのか悩んでいる人が多いそうです。 本記事ではDDD+オニオンアーキテクチャ+Repositoryパターンを使う前提で、私がよく使うトランザクションを考慮した実装について説明しようと思います。 トランザクションを考慮した実装 私はトランザクションを開始するためのDBとのコネクションの作成はUsecase層で実施します。 私がよく書く実装ではDDDでいうEntityを定義します。そしてRepositoryではEntityのCRUDのみ行うように実装し、Repositoryをトランザクション境界にしま
モダンアプリケーションにおける分散トランザクションの動機と実装 @ AWS Dev Day 2023 Tokyo
AWS Dev Day 2023 Tokyo のE-1セッションのスライドです。 分散トランザクションの動機と実装について喋りました。
try! Swift Tokyo 2024 参加報告 / try! Swift Tokyo 2024 Report
決済トランザクションの監視におけるElastic Stackの活用 ~アプリケーションロギング／トレーシングの可視化~ / Elastic Stack for monitoring payment transactions - Speaker Deck
Transcript 決済トランザクションの監視における の活用 アプリケーションログ／トレースデータの可視化 ペイメントサービス株式会社 アプリケーション開発者 髙野 はいね 自己紹介 決済代行システム の開発に従事 年に ペイメントサービス株式会社に新卒入社 主な業務 ・決済代行システム開発 ・運用改善 ソフトバンク携帯ユーザー向けの 「ソフトバンクカード」のカード発行・ 運営をしています。 ソフトバンクカードは、 Visa加盟店 で利用できるプリペイドカードです。 ご利用金額に応じて Tポイントが貯 まります。 カード発行業務 決済代行 EC運営事業者さま向けにオンライン決済 事業を運営しています。豊富な決済手段 をまとめてご提供しています。 カード加盟店業務 Visa、Mastercard、UnionPay（銀聯）のメン バーシップライセンスを保有しており、各ブラ ンドのアクワイア
この記事は、Merpay Tech Openness Month 2023 の7日目の記事です。 はじめに こんにちは。メルコイン Payment Platform チームの @sapuri です。 メルコインではマイクロサービスアーキテクチャを採用しており、お客さまによりアプリの操作が行われると、それぞれのマイクロサービスを横断してリクエストが処理されます。 メルコインの Payment Platform は、お客さまの残高の管理や各種帳簿の作成などの決済事業のための基盤となる仕組みを提供しています。 そのなかで、Payment Service は決済トランザクションを管理するサービスとして、下位層のサービスが提供する各種決済手段を利用して、上位層のサービスが共通して利用できる決済 API を提供しています。 この記事ではマイクロサービスアーキテクチャにおける分散トランザクション管理の課
はじめに アドベントカレンダー16日目、aptpodのしがないサーバーサイドエンジニアがお届けします。 弊社ではサーバーサイドのプログラミング言語としてGoを利用しています。 Goでアプリケーションを実装していく中で特に頭を悩ませた、Go x クリーンアーキテクチャ x トランザクションについて、学んだこと、どうやって対処したかを書きたいと思います。 題材について 解説するにあたり、クリーンアーキテクチャ1を意識したサンプルアプリケーションを作りました。 機能自体はしょうもない、CRD（Update無し!）です。 意識はしていますが、クリーンアーキテクチャの厳密さを言われるとそうでもないです。 しかし、その部分の議論は本題とずれますので特に触れません。 まず全体の絵を。 ざっくりクラス関連図 ざっくりシーケンス図 ユースケースのアクティベートの部分はトランザクションを意味しています。そこだ
「PIXIV DEV MEETUP 2021」は、完全招待制のオンラインカンファレンスです。ライブセッションをはじめ、さまざまなイベントを通して、ピクシブのメンバーとピクシブのプロダクト開発における知見、組織文化を共有します。金川氏は、「BOOTH」で発生する決済スパイクに対する取り組みについて発表しました。 突然の決済スパイクに悩まされていた「BOOTH」 金川祐太郎氏（以下、金川）：「オンライン即売会を支えた技術」。BOOTH部の金川がお話します。よろしくお願いします。 「BOOTH」では、突然の決済スパイクに頭を抱えていました。決済スパイクは、例えば有名なクリエイターの期間限定販売や、「YouTube」などVTuberの配信中に商品が公開された時、あとは最近行われるエアコミケといったオンライン即売会などで発生します。 決済スパイクが起きる時、BOOTHでは同じ商品に注文が集中します。
(読みづらいタイトルだな) ことの発端はこのツイート。 MySQLは、以下を満たさないという理解でいいのか？ エラーが出た時にPostgreSQLのようにロールバックを行わないので Atomicity（原子性）・・・トランザクションの実行結果は「全て成功」か「全て失敗」のいずれかでなければならない#mysql— imaharu (@imaharuTech) July 2, 2020 さすがの MySQL でもそこを破ってくることはないだろうと思いつつ、トランザクション野郎としてはちゃんと確かめねばならないと思い、早朝にも関わらず布団から出てラップトップを開いた(午前10時)。 実験1 以下のような docker-compose.yml と sql/script.sql を用意し、実験をする。 version: '3.3' services: db: image: mysql:8 envir
DBMS複数利用時の問題とトランザクションの分離を学ぼう！（ダーティーリード、ファントムリード、READ COMMITTEDなど）
データベース DBMS複数利用時の問題とトランザクションの分離を学ぼう！（ダーティーリード、ファントムリード、READ COMMITTEDなど） データベースにおいてはデータを正確に保つためにトランザクションを使うことでデータの原子性（処理を全て完了するか全て戻すか）を保っています。 つまり、データが中途半端な状態にならないように、「コミット」や「ロールバック」という仕組みを使っています。 「それなら安心だね！」って思うところですが、DBMSで「複数のトランザクションが同時実行」された場合、タイミングによっては正しい処理が行えないことが発生してしまいます。 今回はこのDBMSにおいて複数トランザクションを同時実行する際に発生する問題と「トランザクション分離」という対策に関して解説します！ DBMSにおける複数同時利用の問題とは？ DBMS上で複数トランザクションが同時に実行されると、タイミ
［2019/05/27開催「IIJ Technical NIGHT vol.7」の講演資料です］ ISP が運用するメールシステムでは極めて大きな流量のメールを処理しています。 本セッションでは、メールシステムの“メール”という単語に囚われすぎることなく、汎用的な視点で大規模メールシステムの要件と特性を考察します。 また、この考察を踏まえて IIJ のメールシステムのアーキテクチャについて紹介します。 ▼講演者 ネットワーククラウド本部 アプリケーションサービス部 サービス開発課 鈴木 高彦
1つのトランザクションの中でINSERT、SELECTを連続で実行したところ、先にINSERTしたCOMMITされていないレコードも取得できました。 なぜ取得できるのか分からなかったので調査・検証してみました。 検証 SQLを実行 トランザクション前のテーブルの状態です。 mysql> SELECT * FROM animals; +----+------+ | id | name | +----+------+ | 1 | dog | +----+------+ 1 row in set (0.00 sec)
トランザクションを使用した Amazon DynamoDB の一意制約のシミュレーション | Amazon Web Services
Amazon Web Services ブログ トランザクションを使用した Amazon DynamoDB の一意制約のシミュレーション 大抵のリレーショナルデータベースシステム、そして一部の非リレーショナルデータベースシステムには、ユニークキーまたはユニーク制約として知られるコンストラクトがあります。この機能は、列またはフィールド内のすべての値が行全体で一意であることを確実にします。 たとえば、User テーブルがあるとします。それには、各ユーザーを一意に識別するプライマリキーとして UUID があるかもしれませんが、同じくユーザーにとって一意である必要があるユーザー名フィールドと E メールフィールド (DynamoDB 用語では「属性」) もあるかもしれません。このユースケースは、DynamoDB トランザクションに関する AWS Summit 2018 DAT374 セッションで言
MySQL の Repeatable Read と RocksDB の楽観的トランザクション解説｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL の Repeatable Read と RocksDB の楽観的トランザクション解説 こんにちは技術研究グループ・テクニカルディレクターの波多野です！ 普段は社内のインフラ、特にデータベース関連の技術的な問題を解決するのを仕事にしています。 弊社ではリレーショナル・データベースとしてはオープンソースの MySQL をとてもよく使っていますが、そんなオープンソースのデータベース界隈で最近よく目にするようになって来たのが 楽観的トランザクション(Optimistic Transaction) という技術です。今回はトランザクション処理の歴史的なところに触れながら、RocksDB に代表される楽観的トランザクションについて簡単に解説したいと思います はじめに MySQL を使っているとデフォルトでは REPEATABLE READ のトランザクション分離レベルになっていて、トランザク
Unreal Engineで有名なEpic Gamesが、現在開催中のGDC（Game Developer Conference)でVerseの詳細を解説しており、その動画が公開されています。 ドキュメントもすでに公開されています。 https://dev.epicgames.com/documentation/en-us/uefn/verse-language-reference 現在処理系は、Unreal Editor for Fortnite(UEFN)の中に組み込まれているようですが、Windowsにしか対応していません。ちょろっと動かした程度で、まだコードをしっかり書いてはなくて、プレゼンを見た感想で書いているので、いろいろ間違ったところとかもあるかもしれませんが、そういうのはご指摘いただいたり、Pull Request（ブログの上の鉛筆アイコンで送れます)を出してもらえれば、と
TiKVにおけるトランザクションとMVCCの話
はじめに PingCAPの小板橋です。はじめまして！ TiDBの入門記事から上級者編まで幅広く取り扱う本アカウント第5回目は「TiKVにおけるトランザクションとMVCCの話」についてをまとめていきたいと思います。 TiKVの仕組み まずは、TiKVの仕組みについてを見ていきましょう。 全体のTiDBクラスターのアーキテクチャについては、下記の記事をご覧ください。 TiDBクラスターにおけるデータレイヤーにあるストレージノードとしてTiKVと呼ばれるものがあります。 TiKVは、分散型のキーバリューデータベースになり、ACIDに準拠したトランザクションAPIを提供しています。このTiKVの裏には、RocksDBとRaftコンセンサスアルゴリズムによって動作しています。 Raftコンセンサスアルゴリズムについては、また別の記事で深ぼっていきます。(こちらはこちらでお楽しみに！) RocksDB
分析系とトランザクションのクエリの壁は消失する!? Google Cloudが予測する2025年までに実現するクラウドテクノロジの動向
Google Cloudの年次カンファレンス「Next 22」のデベロッパキーノートで発表された”10の予測”の中から、岩尾エマはるかさんが紹介した4つのトレンドをレポートします。 10月12日から14日にかけてオンラインで開催されたGoogle Cloudの年次カンファレンス「Google Cloud Next ’22」では、BigQueryによる非構造化データのサポート、LookerとGoogle Data Studioの統合、Intel Saphire Rapidsを搭載したハイパフォーマンスなC3インスタンス、最新セキュリティソリューションのChronicle Security Operationsなど、エンジニアにとっても非常にインパクトの大きいアップデートがいくつも発表されました。これらのプロダクトやサービスはユーザの現在のニーズを反映しているのはもちろんのこと、近い将来の技術
現在ポータブルな単一で動くDBを趣味で作っています。 分散DBもやろうってなったとして、レプリケーション機能などを実装するとき 同期する内容は恐らくトランザクションログだけだと思うけど他に何があるのか、 通信プロトコルは何が最適なのか、 マスターが死んだことはどうやってわかるのか、 死んだときマスターはどうやって決めるのか、 そもそも分散DBはインスタンス同士でそれぞれの存在を漏れなく認識できているのか、 色々疑問が大量に湧きます。ここらへんの知識をご教示ください。 熊崎 宏樹:良いですね。日曜大工でRDBMSを作るのはもっと市民権を獲得しうる趣味だと確信しています。 分散システムを作る際に気をつける事を語ると毎度長くなってしまうのですが、データ指向アプリケーションデザイン、通称イノシシ本に書いてある事をベースラインに説明すると明快であると気づきました。 * レプリケーションされるのはトラ
🙅♂️この記事の内容は実際のコードに適用しないでください！！ （2022-10-5追記） この記事の本文でトランザクションに joinable: false というオプションを付けることが推奨されていますが、 joinable: false は内部APIなので指定してはいけない、というのがRails開発チームの見解のようです。 https://github.com/rails/rails/issues/39912#issuecomment-665483779 https://github.com/rails/rails/issues/46182#issuecomment-1266550987 joinable: false を付けるとコミット実行前にafter_create_commitコールバックが呼ばれるなど（参考）、思いがけない別の問題を引き起こすことがあります。 というわけで、
Cloud Nativeなシステムを構築するにあたって手助けとなる、アプリケーション開発と運用のアジリティ、可用性、拡張性を支えるさまざまなデータベースを学ぶ「Cloud Native Database Meetup #1」。ここで「NewSQLへの誘い」をテーマに小林氏が登壇。NewSQLが登場するまでの流れと、NewSQLのストレージエンジンと分散トランザクションについて紹介します。 自己紹介とセッションのアジェンダ 小林隆浩氏（以下、小林）：では、さっそく本セッションに入っていきますが、まずは私のほうでイントロダクションをこのままやります。 イントロダクションのテーマは、「NewSQLへの誘い」というかたちで進めていきます。私は小林と言い、データベースに関する連載や、書籍の翻訳なんかをしているエンジニアです。 いろいろなデータベースをつまみ食いするのが好きで、評価したり検証したり。あ
AWS AppSyncキャッシングとAmazon DynamoDBトランザクションのサポートによりGraphQL APIのパフォーマンスと一貫性が更に向上します | Amazon Web Services
Amazon Web Services ブログ AWS AppSyncキャッシングとAmazon DynamoDBトランザクションのサポートによりGraphQL APIのパフォーマンスと一貫性が更に向上します AWS AppSyncはGraphQLのマネージドサービスで、単一または複数のデータソースのデータに安全にアクセスしたり、操作したり、結合するための柔軟なAPIを作成でき、アプリケーション開発をシンプルにすることができます。多くの場合、異なったデータソースは異なったユースケースに合わせて最適化され、データが配信されるスピードも異なっていることでしょう。その基になるGraphQLスキーマで定義されているデータフィールドもかなり多様です。 たとえば、eコマースアプリケーションでは、在庫量を表すデータフィールドは頻繁に更新されますが、顧客プロフィールの更新は時々です。トランザクションIDに
【20分で理解】小難しいインデックス・トランザクション・ロックを"サクッ"とMySQLでまとめてみた - Qiita
1. インデックス MySQLで利用可能なインデックスは一部を除き、B-Treeインデックスと呼ばれる構造でできてます。Bツリーインデックスは、ブランチノード(ブランチ), リーフノード(リーフ)で構成されており、ルートノードから数ステップで目的のデータに到達することができます。 データの格納とアクセス方法 クラスタインデックス MySQLのInnoDBストレージエンジンでは、すべてのテーブルは主キー（PRIMARY KEY）によるクラスタインデックスを持ちます。クラスタインデックスとは、データ行が主キーの値によって物理的に順序付けられた状態のことを指します。このため、主キーによる検索は非常に高速です。 セカンダリインデックス セカンダリインデックスは、クラスタインデックス以外のすべてのインデックスを指します。セカンダリインデックスのリーフページ（最下層のインデックスページ）には、インデッ
はじめに前回 は google-cloud-go/spanner のセッション管理について見てみました。セッション管理だけでも Session Pool や Session のライフサイクルの管理など、やっていることは非常に多岐に渡っていましたね。 今回はそのセッションの上でどのように Cloud Spanner のトランザクションが動くのか、クライアントライブラリの実装を元に見ていきたいと思います。 具体的には以下のような点について述べます。 トランザクションとはトランザクションの種類トランザクションを高速化する方法トランザクションのリトライトランザクションの冪等性トランザクションの終了処理前回と同じく google-cloud-go の v0.38.0 時点のものを参照して記述しています。実装に踏み込んだ話もしており、将来に渡って処理内容が変わらない保証はないため、気になる方は最新のバ
Django Congress2019 での資料です。 Djangoのtranasctionモジュールを中心にコードの話やトランザクション分離レベルの話などをします。
電子マネーサービスにおける二重引去りの発生について（楽天Edy、WAON、nanaco） | 最新情報 | 株式会社トランザクション・メディア・ネットワークス
弊社の電子マネーサービスの取扱機能が搭載されている決済端末をご利用の一部店舗様におきまして、システムの不具合を起因として、一部の電子マネー取引で二回重複して取引が実施されていた可能性があることが判明致しました。 本件につきまして、お客様ならびにお取扱店様に大変なご迷惑をおかけしたことを深くお詫び申し上げます。 本不具合の影響を受けたお客様に対して、二重にお支払いされた金額をご返金させて頂きます。ご返金にあたっては調査を実施し、記名式カードをお持ちのお客様へは可能な限りご連絡させて頂き、関係各社と連携して対応致します。
トランザクションスクリプトの何がダメなのか自分なりに考えてみた話をします。
更新APIの難しさ ネットワークの向こう側にあるリソースを更新するのは、単純なTCP/IPの仕組みでは難しい。その上に構成されたシンプルなプロトコルである単純なHTTPで実現しようとすると、以下に示すような箇所でエラーの発生可能性があり、双方で等しく検知することができないケースが存在し、同期的なリカバリが困難である。 エラーの発生箇所 1. クライアント→サーバの接続エラー 2. クライアントからリクエスト送信したがサーバに届かない。 3. サーバが不完全なメッセージを受信した。 4. メッセージがサーバの処理キューに入らない。 5. サーバで処理が正常に完了しない。 6. サーバからレスポンスを返そうとしたが接続が切れている。 7. サーバからレスポンスを返したが、クライアントに届かない table:エラー検知 クライアント サーバ ① コネクションタイムアウト,... 検知不能 ② ソ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
「トランザクション張っておけば大丈夫」と思ってませんか？ バグの温床になる、よくある実装パターン
リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得ら
マイクロサービスとトランザクション - Qiita
どのレイヤー（層）でトランザクションを実装すべきか
Go でトランザクションをフルスクラッチで実装した - kawasin73のブログ
MySQL/Postgres におけるトランザクション分離レベルと発生するアノマリーを整理する
MySQL/Postgres におけるトランザクション分離レベル
[記事下書き] MySQL/Postgres におけるトランザクション分離レベルの実際
設計ナイト2022 トランザクションスクリプト
メルコイン決済基盤における分散トランザクション管理 | メルカリエンジニアリング
Goとクリーンアーキテクチャとトランザクションと - Qiita
BOOTHの“決済スパイク”を防げ！ 創作物の総合マーケットを支えるトランザクション分割
トランザクション中の文の失敗の扱いの違い - Write and Run
高トランザクションシステムとしてのメールシステム
【MySQL】同一トランザクションの実行結果は次の処理にも反映される - Qiita
究極の？トランザクションスクリプト用言語Verse | フューチャー技術ブログ
現在ポータブルな単一で動くDBを趣味で作っています。 分散DBもやろうってなったとして、レプリケーション機能などを実装するとき 同期する内容は恐らくトランザクションログだけだと思うけど他に何があるのか、 通信プロトコルは何が最適なのか、 マスターが死んだことはどうやってわかるのか、 死んだときマスターはどうやって決めるのか、 そもそも分散DBはインスタンス同士でそれぞれの存在を漏れなく認識できているのか、 色々疑問が大量に湧きます。ここらへんの知識をご教示ください。 | Mond - 知の交流コミュニティ
【翻訳】ActiveRecordにおける、ネストしたトランザクションの落とし穴 - Qiita
Spannerの登場で急拡大したNewSQL 分散トランザクションの課題をどう解決したか
詳解 google-cloud-go/spanner — トランザクション編
どうなってるの？Djangoのトランザクション
トランザクションスクリプトは何がダメなのか？
Web APIのトランザクション - kawasima