この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
トランザクションの設計と進化
2016年7月27日 Database Lounge Tokyoで話した内容。 タイトルは名ばかりでリカバリとIn-MemoryDBの話が主体Read less
Shiro Kawai on Twitter: "これはかなりすごいソーシャルハック。 「怪しいカードの利用がありました。マイアミで使いましたか?」 (いいえ) 「わかりました。このトランザクションはブロックします。本人確認のためメンバー番号を」 (メンバー番号自体は特に秘密でな… https://t.co/NHMlzcqkEj"
これはかなりすごいソーシャルハック。 「怪しいカードの利用がありました。マイアミで使いましたか?」 (いいえ) 「わかりました。このトランザクションはブロックします。本人確認のためメンバー番号を」 (メンバー番号自体は特に秘密でな… https://t.co/NHMlzcqkEj
(注：2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注：2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、本来、理解しておくべき基本的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ
この記事は DeNA 20 新卒 Advent Calendar 2020 19日目の記事です。 はじめに MySQLやPostgreSQLに代表されるRDBMSではトランザクションと呼ばれる仕組みが提供されています。多くのWebアプリケーションエンジニアはこのトランザクションを駆使してDBとやりとりをするロジックを組み立てることになります。 しかし不整合を起こしたくない処理があるからといって闇雲にトランザクションを張ったり、トランザクションが張られているからと安心してアプリケーション側で闇雲にロジックを組み立ててしまうと思わぬバグを生むことになってしまいます。 このエントリでは、「トランザクションを張っておけば大丈夫」という考え方は危険な場合もあるということを、ありがちな実装例を交えて紹介していきます。 並列に処理されるトランザクション そもそも、トランザクションは全て直列に処理されるわ
リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得られるということなのだと思うので、可能であればMVCCを採用したいのですが、あまり初学者向けの実装例も見当たらず、どうしたものかと悩んでおります。 SS2PL/S2PLとMVCCの実装の難易度・工数はどの程度違うものなのでしょうか？ また、初めてリレーショナルデータベースシステムを開発する者
トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス
トランザクション分離レベルの古典的論文 A Critique of ANSI SQL Isolation Levels を読む - Hatena Developer Blog
こんにちは、 id:alpicola です。今年4月に新卒入社してアプリケーションエンジニアとして働いています。 ウェブアプリケーションはその性質上、データベースに対して同時に大量の問い合わせを行います。そうした中でデータベースが個々の問い合わせを処理していくときに起こっていることは何か、どういう順序で処理が行われるのか、というのは興味深い話題かと思います。例えばデータベースに対して行った更新処理の結果が、更新を行ったクライアント以外のクライアントからも「見える」ようになるのはいつでしょうか。入社間もない頃、先輩エンジニア達にそうした疑問をぶつけてみたところ、「トランザクション分離レベル」というキーワードと、この分野の古典的な論文 A Critique of ANSI SQL Isolation Levels を教えてもらい、輪読会を社内で開催しました。この記事ではこの輪読会の模様をレポー
「Google Cloud Spanner」発表。地球規模の大規模分散環境で稼働するミッションクリティカルなリレーショナルDB。NoSQL並のスケーラビリティでSQL対応、トランザクション処理を実現
「Google Cloud Spanner」発表。地球規模の大規模分散環境で稼働するミッションクリティカルなリレーショナルDB。NoSQL並のスケーラビリティでSQL対応、トランザクション処理を実現 Googleは、クラウド上で高度なスケーラビリティを実現する、ミッションクリティカルな業務に対応したリレーショナルデータベースサービス「Google Cloud Spanner」を発表しました。 Google Cloud Spannerは、地球規模の大規模分散処理データベースとして、NoSQL並の非常に高いスケーラビリティと高い可用性、そして高速な処理を実現しつつ、SQLに対応。強い一貫性を持つトランザクション処理も実現。企業のミッションクリティカルな業務にも使えると説明されています。 地球規模に分散したリレーショナルデータベース 一般に、ミッションクリティカルな業務に対応したリレーショナルデ
DBの「トランザクション分離レベル」が必要な理由 （PostgreSQLで，ファントム・リードを防止すべきサンプル事例） - 主に言語とシステム開発に関して
データベースには，「トランザクション分離レベル」というものがある。 以下では，それが なぜ必要なのか？ デフォルトのレベルでは，どうして駄目なのか？ PostgreSQLでは，どうやってレベルを変更・確認するのか？ などを取り上げる。 トランザクション分離レベル トランザクション分離レベルとは： 複数のトランザクションが同時に実行された場合に、他のトランザクションからの影響がどのくらい「分離」するか，のレベル。 ANSI規格では，４つのレベルがある。 READ UNCOMMITTED （一番低い） READ COMMITTED REPEATABLE READ SERIALIZABLE（一番高い） 徹底比較!! PostgreSQL vs MySQL 第３回：トランザクションの比較 http://thinkit.co.jp/free/article/060... トランザクション処理に詳しく
トランザクションの実装にはRDB/NoSQLにかかわらず教科書的な定番がある～業務システムをRDBなしで作れるのか？（前編） エンジニアサポートCROSS 2016
トランザクションの実装にはRDB/NoSQLにかかわらず教科書的な定番がある～業務システムをRDBなしで作れるのか？（前編） エンジニアサポートCROSS 2016 数年前にNoSQLが登場した当時、NoSQLにはデータの一貫性を保証してくれるトランザクション機能などが十分に備わっていないため、業務システムのバックエンドとして使うのは容易ではないと考えられていました。 しかしその後、NoSQLをバックエンドにした業務アプリケーションは現実にはいくつか登場してきています。ワークスアプリケーションズが2014年に発表したERPの「HUE」もCassandraをバックエンドに採用した、本格的な業務アプリケーションです。 そのHUEの開発に関わるスタッフが、どういう実装ならばNoSQLが業務アプリケーションのバックエンドに使えるのか、それにはどういう意味があるのか、などについて議論したセッション「
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
AWS for Games Advent Calendar 2022 9日目の記事です。 Game Server Services(GS2) ではゲームに必要となるサーバー機能をマイクロサービス化し、皆さんに提供しています。 マイクロサービスには所持品の管理や、ゲーム内ストア、課金通貨の残高管理など30を超える機能を用意しており、これらを組み合わせながらゲーム内の仕様を実現できるようにしています。 さて、マイクロサービスの最も難しい課題はトランザクションにあると私は考えています。 今回は Game Server Services がどのようにこの課題に立ち向かい、そして問題を解決しているかお話ししたいと思います。 マイクロサービスとトランザクションの両立がなぜ難しいのか モノリシックなサーバーシステムは、大体の場合「所持品の所持数量」と「課金通貨の残高」は同じRDBに保存しています。 そし
MySQL/Aurora/TiDBロック入門 – 第１回トランザクション分離レベル｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL/Aurora/TiDBロック入門 – 第１回トランザクション分離レベル MySQL InnoDB および AWS Aurora や PingCAP TiDB におけるロックの仕組みやトランザクションの動作を全１１回のシリーズで解説します！ 最初はベースとして重要な MySQL 8.0 InnoDB 前提でユーザー視点でのロックの仕組みを学び、後半第１０回以降では MySQL 互換 DB として人気の高い AWS Aurora や PingCAP TiDB と MySQL InnoDB との違いについて学びます。 １回目の今回はロック機構と切っても切り離せないトランザクションとその分離レベルについて、実際に挙動を確かめながら解説します。ライブ感のある説明も理解に役立ちますので、解説動画も付けてみました。合わせてご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む） そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ
モジュラモノリスにおけるトランザクション設計の考え方 / transaction design on modular monolith
モジュラモノリスにおいてトランザクションはどうあるべきなのかについて整理している資料が少ない気付きがあったので「簡易的に」整理しました
DB外の副作用をトランザクションから分離しよう / Isolate out-of-DB side effects from transactions
gotanda.rb#52@オンライン "DB外の副作用をトランザクションから分離しよう"
一人トランザクション技術のカレンダー | Advent Calendar 2016 - Qiita
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
決済単位でのトランザクション管理モデルを用意すると調査にも開発にも役立つ - Quipper Product Team Blog
Web Engineer の @kachick です。 今回はスタディサプリのクレジットカード決済を堅牢化するために行っている工夫の一部を抜粋して紹介したいと思います。 前提 本記事で紹介する内容は、過去に我々が提供していたサービス（以下、サービスAとします）において直面した決済バグから学び、スタディサプリに導入したものです。 決済バグとは 決済というものはその性質上、セキュリティに次いでバグへの高い温度感を求められがちです。 サービスプロバイダの目線からは決済のバグを2つに大別出来ます。 本来よりも多く請求しまい、ユーザーからの信頼を損ねる。 決済の金額を増やしてしまった。 決済の時期を早めてしまった。 決済は通ったがサービスを提供できていなかった。 本来よりも少なく請求してしまい、事業運営に支障を来す。 決済の金額を少なくしてしまった。 決済の時期を遅くしてしまった。 実際には決済が通
一歩ずつ一歩ずつ前へ進んでいく、確実に。どうも、かわしんです。 到底 1 記事に収まるような内容ではなく長いので、トランザクションの作り方に興味のない方は途中の「なぜ Go なのか」まで読んでいただければ嬉しいです。 この記事は、Go2 Advent Calendar 2019 の 7 日目と セキュリティキャンプ 修了生進捗 #seccamp OB/OG Advent Calendar 2019 の 7 日目を兼用しています。 さて、僕の興味は必要になったライブラリやミドルウェアなどを自作して、作りたいプロダクトを完成させることです。必要なコンポーネントがないからといってプロダクトを作るのを諦めたり妥協したりはしたくありません。 多くのアプリケーションではデータベースは重要なコンポーネントです。大抵のアプリケーションは MySQL や Postgres、Redis など既存のデータベース
カラム型データベースはなぜ集計処理が高速で、トランザクションが苦手なのか。インメモリとカラム型データベースの可能性を調べる（その4）
カラム型データベースはなぜ集計処理が高速で、トランザクションが苦手なのか。インメモリとカラム型データベースの可能性を調べる（その4） 現在主流となっているOracle、SQL Server、DB2などのリレーショナルデータベースは事実上すべて、行（ロー）指向で内部の処理を行っています。一方で、最近急速に注目されているのが、列指向で内部処理を行い、大量データの集計や分析処理に優れた「カラム型データベース」（あるいはカラム指向データベース、カラムナーデータベース）です。 カラム型データベースはSybase IQやNetezza、Verticaなどデータウェアハウス専用のデータベースで主に採用されています。また、SQL Serverには「ColumnStore Index」、Oracle Exadataには「Hybrid Columnar Compression」と呼ばれるカラム型データベースの
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
みずほ銀行のトランザクション認証を試してみた
既に報道されているように、インターネットバンキングに対する不正送金事件が多発しています。 警察庁は2015年2月12日、2014年（平成26年）の1年間に発生した、インターネットバンキングでの不正送金事件の被害状況などに関するデータを発表した。 不正送金事件の発生件数は1876件となり、前年の1315件から500件以上増加。被害額については約29億1000万円となり、前年の14億600万円から2倍超の増加となった。 2014年のネットバンキング不正送金は約29億円で法人被害が激増、警察庁発表 より引用 このような状況を受けて、フィッシング対策協議会では、インターネットバンキングの不正送金にあわないためのガイドラインとして以下の「鉄則」を公開しています。 第一の鉄則：乱数表等（第二認証情報）の入力は慎重に！ 第二の鉄則：インターネット利用機器を最新の状態に保とう！ これらは確かに重要な施策で
トランザクション分離レベルについて極力分かりやすく解説してみた[SQL] - 明日になったら本気出せる
こっちに移動 qiita.com
![トランザクション分離レベルについて極力分かりやすく解説してみた[SQL] - 明日になったら本気出せる](https://cdn-ak-scissors.b.st-hatena.com/image/square/865d91d3f7d8bc0ecea2db1b383f8dd9abc67ed5/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12921228815712380847%2F12921228815712778346%2F1508923711)
読者対象 ANSI 定義の古典的なトランザクション分離レベルとアノマリーは概ね理解している MySQL/Postgres では理論的な部分がどうなっているのかを知りたい 理論面の前提知識 2022-08-19 追記: 社内勉強会向けのスライドを作成しました。先にスライドを見てから，引用文献およびこの記事を読むと理解が深まると思います。 まず ANSI 定義の古典的な定義を聞いたことが無い方は，以下のリンクを参照されたい。 ANSI 定義に対応する解説はこれらのサイト以外にもたくさんあるため，自分にとって読みやすいと感じる情報をあたってほしい。（既に熟知されている方は十分） 次点で読んでいただきたいのが， @kumagi さんの以下の記事。古典的には 4 つの分離レベルと 3 つのアノマリーだけで説明されていたものの，不十分であることが学術的に指摘され，解像度を上げようとする流れが後になって
App Engineで現実的な送金処理について考え中です。 ドラフト版なので、怪しい点があればご指摘いただければ幸いです。 コメントで情報いただきました。 Distributed Transactions on App Engineで紹介されてる方法と基本的に同じなので、おそらく問題なく動きそうです。ありがとうございました。 今回はこんな図を使います。 この図の読み方は、矢印の方向にユースケースの一連の処理(またはリクエストの処理)が流れていて、右に行くほど時間が経過しています。そして、矢印がくし刺しにしている四角形は、そのユースケース中で操作するエンティティを表しています。 また、左右の位置が同じ矢印は、基本的には同じ時刻に発生したイベントを表しています。上記の図では、A, B, Cがそれぞれの口座エンティティを同時に操作している感じです。 並行性制御(おさらい) 最初の図のように、それ
MySQL Casual Advent Calendar 2016 - Qiitaの5日目の記事です。 AdventCalendar自体初参加でドキドキ。 トランザクションの開始は、BEGINしたときじゃない！ MySQLでは、BEGIN（START TRANSACTION。長いので、以下、特筆すべき場合以外は「BEGIN」で）を宣言しても、内部的にはまだトランザクションを開始してません。 SQLを投げたタイミングで、トランザクション開始になります。 このとき、更新のない、FOR UPDATEもないSELECT文でも、トランザクションが開始されます。 なにそれきもい。 「AutoCommit=ON/OFF」による違い AutoCommit=ONのとき トランザクションはSQLを発行するたびにBEGIN/COMMITで完了し、ロールバックできません。 複数SQLを束ねて１つのトランザクション
クラウドでの新しいACID、そしてBASEトランザクションとCAP定理 - Fight the Future
クラウドではアーキテクチャやプログラミングモデルが今までと変わる。 QConでは複数の人からそういう話が出ていた。 ちょっと自分なりにまとめてみる。間違っているかもしれないので、見つけた人はご指摘ください。 新しいACID 従来のモデルでのACIDは、特にRDBMS関連でよく耳にすると思う。 Atomic(原子性) Consistent(一貫性) Isolated(独立性) Durable(永続性) だ。 QConでGoogleのGregor Hohpe氏は、クラウドにおいてACIDは次のような意味になると言っていた。 資料はここ。https://sites.google.com/site/gcodejp/slides/ProgrammingCloud_QCon.pdf?attredirects=0 Associative(結合の) Commutative(相互の) Idempotent(
MySQL/Postgres におけるトランザクション分離レベルと発生するアノマリーを整理する https://zenn.dev/mpyw/articles/rdb-transaction-isolations 上記のスライドの具体的な結論に至るまでの導入として，知識があまりない状態でも段階的に読み込んでいけるように心がけたスライドで，株式会社ゆめみの社内勉強会にて発表しました。 スライドの途中の URL などは PDF としてダウンロードするとクリックできると思います。 事前のレビュー協力者 - https://twitter.com/neko_han25 - https://twitter.com/KentarouTakeda
【ScalaMatsuriセッション当選御礼】ドワンゴ秘伝のトランザクションモナドを解説！ - Qiita
このたびはScalaMatsuriのセッションに投票していただき、ありがとうございました。 今回はそのScalaMatsuriのセッションで発表予定の内容の一つであるドワンゴ秘蔵のトランザクションモナドについて解説したいと思います。 このトランザクションモナドは基本的な機能だけなら30行ほどの短いコードで記述できてしまうのですが、なかなか説明が難しい代物でして、 ScalaMatsuriの自分の発表時間内に聴衆のみなさんに理解していただくのは難しいだろうということで、先に解説記事を書くことにしました。 このトランザクションモナドは作者の名前から通称Fujitaskと呼ばれているのですが、作者の方は周りから「天才」と言われてまして、彼は常人が思いつかないようなコードを書かれるんですね。 Fujitaskは短いながらも、モナドと、サブタイピング(変位指定)と、アドホックポリモーフィズムの三つの
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
トランザクションはACID特性を満たすと言われている。 そのうちA(Atomicity)はトランザクション内の操作をAll or Nothingとなるよう保証し、トランザクションが中途半端に実行されて(アプリケーションレベルから見た)データの整合性が失われることを防ぐ特性。またD(Durability)とはシステム運用中に起こる様々な障害からデータを守る(整合性を保つ)特性。 これらの特性を満たすためのDBMSの古典的なテクニックがすごく面白いので、それに関するMySQL(主にInnoDB)のパラメータ・パフォーマンスにどのような影響を及ぼすかを調べた(*'ω'*) なお紹介している技術は基本的に教科書に書かれていた技術で、実際にInnoDBに実装されているアルゴリズムとは異なることがある(とはいえベースにはなっている) 参考 障害の種類 DBMSの基本構成 データベースバッファ 概要 関
「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
2013年以降、マルウェア感染による不正送金被害が国内でも増加している。警察庁のまとめによると、ウイルスに感染してIDやパスワードを盗み取られ、他人の口座などに不正送金される被害は、2013年は前年の約14倍に当たる1325件に上った。2014年に入ってもその傾向は変わらず、2月末の時点で500件、約6億円に上る被害が生じているという。 不正送金で、最近増えているとされるのが「Man-in-the-Browser」（MITB）と呼ばれる手法だ。被害者のPCに侵入したマルウェアが、オンラインバンキングなど特定のページにアクセスしたときにだけ動作してWebページの表示に改ざんを加え（＝Webインジェクション）、IDやパスワード情報を盗み取ったり、送金先口座を変更してしまったりする。 産業技術総合研究所が2014年3月13日に開催した「第2回 セキュアシステムシンポジウム」において、同研究所の高
Please select the category that most closely reflects your concern about the presentation, so that we can review it and determine whether it violates our Terms of Use or isn't appropriate for all viewers.
大量トランザクションを処理するためには、アプリケーション・サーバを複数台並べて負荷分散する一方で、マルチプロセッサのDBサーバを採用しDB処理能力を確保するアーキテクチャが用いられることが多い。さらに高い処理能力が求められる場合には、DBの並列処理やオン・メモリ処理を併用するデザインもあるが、重要なことはスケーラビリティを確保するアーキテクチャ設計と、負荷を平準化する工夫である。
今週に入ってから、ようやく少し本気でGoogle App Engineでプログラムを書き始めている私だが、ようやく Entity Group の使い方が分かって来たので簡単に解説してみる。 Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。 イメージとしては、まず「一つのハノイの塔を三人で同時に遊んでいる姿」を思い浮かべると分かりやすいかも知れない。全くのルールなしで皆で同時に遊ぼうとすると、腕が交錯してぐちゃぐちゃになってしまう。 そこで、「ある時点でハノイの塔ボード（三つの棒を支えている水平に置かれた板）に触ることが出来る人は常に一人。一度ボードに触った人はすべての円盤をいずれかの棒の位置に置いた状態にしてからしか手を離してはいけない。もし自分がハノイの塔に触りたい時に、す
PostgreSQL 11が正式リリース。ハッシュパーティショニングやJITコンパイルによる高速化、ストアドプロシージャでのトランザクションサポートなど
PostgreSQL 11が正式リリース。ハッシュパーティショニングやJITコンパイルによる高速化、ストアドプロシージャでのトランザクションサポートなど 発表文ではPostgreSQL 11の主な新機能を次のように説明しています。 PostgreSQL 11 provides users with improvements to overall performance of the database system, with specific enhancements associated with very large databases and high computational workloads. Further, PostgreSQL 11 makes significant improvements to the table partitioning system, adds
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
SQLトランザクション分離 実践ガイド | POSTD
「トランザクション張っておけば大丈夫」と思ってませんか？ バグの温床になる、よくある実装パターン
リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得ら
MySQLでトランザクションの4つの分離レベルを試す - FAT47の底辺インフラ議事録
マイクロサービスとトランザクション - Qiita
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
どのレイヤー（層）でトランザクションを実装すべきか
Go でトランザクションをフルスクラッチで実装した - kawasin73のブログ
MySQL/Postgres におけるトランザクション分離レベルと発生するアノマリーを整理する
Song of Cloud: 送金のトランザクション処理パターン
MySQLのトランザクション制御がキモい話 - なからなLife
MySQL/Postgres におけるトランザクション分離レベル
トランザクション技術とリカバリとInnoDBパラメータを調べた - たにしきんぐダム
本格化するMITB攻撃に備え、マイナンバーカードにトランザクション署名を
分散キーバリューストア上でのトランザクションの実装
大量トランザクション処理に適したアーキテクチャ ― ＠IT
Google App Engine入門：Entity Groupとトランザクション処理