結果整合性（Eventual Consistency）についての分かりやすいプレゼン資料
クラウドとキーバリュー型データベースなどの登場によって注目を集め始めたのが、これら分散システムの基礎的な理論ともいうべきCAP定理と結果整合性（Eventual Consistency）です。それぞれがどういうのものなのか？ を分かりやすく解説したプレゼンテーションの資料がSlideshareで公開されています。 作成者はRESTエバンジェリストの山本陽平氏。4月17日に行われたyokohama.pm（横浜Perlモンガーズのテクニカルトーク）で行われたプレゼンテーションの資料です。
クラウドとキーバリュー型データベースなどの登場によって注目を集め始めたのが、これら分散システムの基礎的な理論ともいうべきCAP定理と結果整合性（Eventual Consistency）です。それぞれがどういうのものなのか？ を分かりやすく解説したプレゼンテーションの資料がSlideshareで公開されています。 作成者はRESTエバンジェリストの山本陽平氏。4月17日に行われたyokohama.pm（横浜Perlモンガーズのテクニカルトーク）で行われたプレゼンテーションの資料です。
Raft は Byzantine 障害に対する耐性がなく、論文を一見して恒久的なリーダーの乗っ取りからのログの改ざん、リーダー選挙の妨害などが可能であるところを見ても、P2P ではなく完全に管理されたネットワーク向けの合意アルゴリズム (CFT; Crash Fault-Tolerance) です。Byzantine 障害耐性が必要であれば Raft ではなくパフォーマンスを犠牲にして pBFT などを使う必要があるでしょう。 論文では Crash-Recovery より深刻な障害耐性には言及していないが (論説の範囲を外れるため当然だが)、もし実際に Raft を実装するなら現実的に想定される障害に対して工夫できる余地もいくつか存在します。例えば「テスト環境で使用していたノードの 1 つが事故で本番クラスタに『も』参加してしまった」といったような運用事故で起きうる障害は (大抵そのような
SQL Serverのスナップショット分離レベル導入によるデータ基盤連携の課題解決 - ZOZO TECH BLOG
こんにちは。アーキテクト部の廣瀬です。 弊社ではサービスの一部にSQL Serverを使用しており、BigQuery上のデータ基盤へテーブルを連携しています。連携の仕組みは非常によくできているものの、データ不整合や遅延が発生し得るという課題を抱えていました。しかし、SQL Serverのスナップショット分離レベルを導入することでそれらを解決できました。本記事では、抱えていた課題および解決までの流れと、スナップショット分離レベルを導入する際に気を付ける点を紹介します。 データ基盤連携の方法と課題 データ基盤との連携方法は、日次連携とリアルタイム連携の2種類です。それぞれの連携方法と抱えていた課題について説明します。 日次連携 1日1回、SQL Server専用の一括コピーツールである「bcp」を使用してテーブル全体のデータを取得する連携方法です。データ取得時のSQLのイメージは以下の通りです
[方式設計編]性能要件はユーザーが決めると思ってはいけない
「ユーザーが要件を決めてくれないので…」「性能要件を出していただかないと機器が見積もれません，早く要件を出してください！」。要件定義フェーズのみならず，プロジェクトの様々な工程でよく耳にする言葉である。 非機能要件はユーザーにヒアリングして洗い出すのが，インフラ設計における一般的な手法だ。だが，インフラ設計者はヒアリングによって得られたユーザーの「要望」を絶対的な「要件」としてとらえてはいけない。非機能要件を洗い出すに際しては，要望の裏にあるリスクやそこから派生する制約を先読みすることが重要である。その思考を停止してしまうと，後工程で様々な問題が発生する。 今回は，非機能要件の中でも読者にとって最も身近だと思われる「（オンラインの）性能要件」を例に解説する。なお，現在のシステム構築では，現行システムが存在せずゼロから開発することはほとんどない。従って，ここでは現行システムで何らかの稼働統計
![[方式設計編]性能要件はユーザーが決めると思ってはいけない](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed39b5962a5d552c95b6d796db8f55e72d32943/height=288;version=1;width=512/https%3A%2F%2Fxtech.nikkei.com%2Fimages%2Fn%2Fxtech%2F2020%2Fogp_nikkeixtech_hexagon.jpg%3F20220512)
メモ開放。InnoDBの行ロック関連について、それぞれの項目が必ずしも並列関係にあるわけではないが、以下のようにまとめていく。 排他ロックと共有ロック SELECT ~ FOR UPDATE SELECT ~ LOCK IN SHARE MODE 排他ロックと共有ロック 読み取りを許すかどうかの違い。排他ロックは対象行を全てのクエリからロックするため、UPDATEやDELETEなどの更新クエリはもちろん、SELECTなどの読み取りクエリも通さない。共有ロックは更新クエリを通さないが、読み取りクエリは通す。 （追記：排他ロックは分離レベルによってはSELECTを通すとのこと。 公式 ） 排他ロックは全てのクエリを通さず、共有ロックは排他ロックを伴うクエリを通さない、と言い換えたほうがいいかもしれない。 公式では共有ロックは同トランザクション内のselectを許し、排他ロックは同トランザクショ
db tech showcase 2016 Tokyo で発表した資料です。MySQL 5.7の新機能のうち、InnoDBについてまとめてあります。
MySQL InnoDBの行レベルロック
この機能はMyISAMにはなかったものなので、自分用のメモを書きました。 行レベル・ロックとは 行レベル・ロックは「レコード単位のロック機能」のことです。1レコードだけロックされるわけではなく、対象となる複数レコードがロックされます。 innoDBテーブル・タイプでは、レコード更新時とSELECT文（ロック・オプション付き）で行レベル・ロックが行われます。 読み取り時のロック 通常の「SELECT .. FROM ..」というステートメントでは、いっさいロックされません。また、読み取り一貫性機能によって、こういったクエリーを実行した後に、他でロックしても読み取りを続行することは可能です。 読み取り時にロックしたい場合、明示的にロック方法を指定する必要があります。 ロック方法 SQL 共有モードでは、まだ残っている更新トランザクションが存在したら、まず、そのトランザクションが終了するまで待機
排他制御のあれこれ - Qiita
この記事は、システムエンジニア Advent Calendar 2016 - Qiita の２３日目の記事です。 昨日は @yy_yank さんの 気負わず普通にテストしよう でした。 明日は @koduki さんです。 はじめに 複数ユーザが触るアプリケーションを作る場合、同時にデータが更新された場合の制御は避けては通れません。 この制御はスレッドセーフとか同時更新とか色々な観点で考えないといけないのですが、いまいちそのあたり自分自身の中できれいに整理できていませんでした。 なので、この機会に同時に更新される場合の排他制御について、自分なりに整理してみました。 まえおき 説明に使用する言語は Java です。 説明のためにシーケンス図っぽいものを使っていますが、 UML の厳密な定義には従っていません。図が描きやすいからシーケンス図を利用している、ってだけなので厳密な記法ルールに従ってい
MySQL/Aurora/TiDBロック入門 – 第３回ロック読取りも SELECT は止められない【解説動画付】｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL/Aurora/TiDBロック入門 – 第３回ロック読取りも SELECT は止められない【解説動画付】 MySQL とその互換 DB のロックの挙動を紹介する入門シリーズ、第３回は第２回で紹介したロックモニターを使って、業務ではよく使われているロック読取りについて解説します。 ロック読取りは、ゲームのバックエンドサーバーなど「同時に多数の処理をこなすけど、データとしての一貫性も重要」な場合に必須となるテクニックです。既に使っているという方も復習を兼ねてぜひご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロックモニターの読み方 ★ 第３回 ロック読取りも SELECT は止められない ★ 第４回 INSERT を止めるインテンションロック ★ 第５回 WHERE 条件と違うロック読取り ★ 第６回 performance_schema ★ 第７回ギャップロック
@t_wadaさんが、データベース設計の素晴らしい資料をリンクしていたのでメモ。 下記の資料は、MySQLでソーシャルゲームのDB設計のお話らしいが、データモデリングの設計ノウハウが秀逸。 気になった点をメモしておく。 理解できたことをラフなメモ書き。 【元ネタ】 Twitter / Takuto Wada: 素晴らしい資料。"「スキーマ」「トランザクション」「インデックス」はもっと評価されるべき" / ソーシャルゲームのためのデータベース設計 http://htn.to/PzrnbR 【1】可用性や整合性に関する要求が意外と多い たとえ、SNSやゲームであろうが、課金体系になるとお金が絡むため、ユーザの要求のレベルも上がるし、事業者の責任も大きくなる。 データモデリングはアーキテクチャ設計につながる。 【2】派生関係 データベース設計(DOA)でも、派生関係(継承関係）はオブジェクト指向
はじめに こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。この記事は、Merpay Advent Calendar 2019 の21日目の記事です。 3年前、ソーシャルゲーム業界からメルカリに転職してから、幸運なことにゼロイチで決済サービスの開発に関わることができて、エンジニアとしても人生としてもとても充実の3年間を送りました。 そして、今、日本ではすでにキャッシュレスブームが始まっていて、これからFinTechの領域で様々な革命が起きていくと思っています。この記事では私がエンジニアとしてこれまでに決済サービスの開発に関わってきたことを振り返り、これからFinTechに関わりたい方への参考になればと思います。 社内向け決済基盤の検討 メルカリに入社してすぐ、当時社内ID基盤を開発していたPlat
IBM Developer
IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
Kyoto Cabinet 1.0登場、C++以外の主要言語に対応 | エンタープライズ | マイコミジャーナル
Kyoto Cabinet: a straightforward implementation of DBM Kyoto Cabinetの初の安定版リリースとなるKyoto Cabinet 1.0が公開された。Kyoto CabinetはC++で開発されたキーバリュー型のデータベース。GPL3のもとで提供されている。高い並列性と移植性があり、利便性が高い。ハッシュデータベース使用時はO(1)、ツリーデータベース使用時はO(log N)の計算時間量を実現。マルチスレッドセーフでレコード単位/ページ単位での読み書きロックが可能。Kyoto Cabinet 1.0における主な特徴は次のとおり。 更新能力100万qps以上 レコードあたりのフットプリントがハッシュデータベースで8-16バイト、ツリーデータベースで2-4バイトと軽量 自動リカバリ機能 自動/手動トランザクション機能 C, Java、
※ InnoDBはREPEATABLE READでもファントムリードが発生しません。 MySQLで実際に試す MySQL(InnoDB)でトランザクション分離レベルを実際に試してみます。 準備 プレイヤーのコイン数を表す簡単なテーブルを作ります。 テーブル構造は次のようになります。 テーブルにplayer1とplayer2のデータを追加します。 2つのターミナルからMySQLに接続します。クライアントAとクライアントBとします(以下はAとBと呼ぶ)。 これで準備は完了です。 READ UNCOMMITTED READ UNCOMMITTEDは一番低いレベルです。 コミットされていない変更を他のトランザクションから参照できる設定です。 ① Aで現在接続中のセッションのトランザクション分離レベルをREAD UNCOMMITTEDに設定して、テーブルを検索します。 ② BでREAD COMMIT
MySQL トランザクション - とみぞーノート
トランザクションを使うと複数のクエリをまとめて１つの処理として扱うことができる。処理の途中でエラーになって処理を取り消したいような場合はROLLBACKをすることで変更内容を元に戻すことができる。 トランザクションはデフォルトのMyISAM形式のテーブルでは使用できない。トランザクションが使用できるテーブルにはInnoDB,BDBなどがある。以下ではInnoDBを使って説明する。 1.InnoDBテーブルの作成 新規に作るテーブルをInnoDBにするには、以下のようにする。 mysql> CREATE TABLE friends (id SERIAL, name VARCHAR(30) NOT NULL, address VARCHAR(100), birthday DATETIME) TYPE=InnoDB; 既存のテーブルをInnoDBに変更する場合は以下のとおり。 mysql> AL
豊富なメモリやマルチコアCPUを備えたシステムに最適化された次世代型の高速SQLデータベース「VoltDB」がリリースされた。メモリは4Gバイト以上が推奨されるなど利用環境は限定されるが、トランザクション性能はほかのDBMSを圧倒する性能を示しており、今後が注目される。 ベンチャー企業の米VoltDBは5月25日（現地時間）、オープンソースのデータベースシステム「VoltDB 1.0.1」をリリースした。高速、拡張性、ACID順守などを特長とする次世代DBMSとしている。 VoltDBは「Postgres」「Ingres」などのデータベースプロジェクトを共同で創始したマイケル・ストーンブレイカー氏が設計したもので、同氏が非常勤教授を務めるマサチューセッツ工科大（MIT）、ブラウン大学、イェール大学、HP Labsの共同研究「H-Store」がベースとなっている。 VoltDBは豊富なメモリ
データのクエリーを実行してから、同じトランザクション内で関連データを挿入または更新する場合は、通常の SELECT ステートメントで十分な保護が提供されません。 ほかのトランザクションは、クエリーが実行されたばかりの同じ行を更新または削除できます。 InnoDB では、追加の安全性が提供される 2 つのタイプのロック読み取りがサポートされています。 SELECT ... FOR SHARE 読み取られる行に共有モードロックを設定します。 ほかのセッションもその行を読み取ることができますが、トランザクションがコミットするまで変更することはできません。 これらの行のいずれかがコミットされていない別のトランザクションによって変更された場合、クエリーはそのトランザクションが終了するまで待機してから、最新の値を使用します。 SELECT ... FOR SHARE は SELECT ... LOCK
発表者として参加させていただきました。 発表資料はこちらです（自分でも忘れそうなのでブログにリンク貼っておく） 外部キー制約に伴うロックの小話 from ichirin2501 外部キー制約に伴うロックの小話 追記: 2015/08/22 ブログでも補足したほうが良いかな、と思ったので今更追記することにしました。 どういう資料？ 外部キー制約で発生するロックのお話です。前提として、MySQL(5.5.28)のInnoDBストレージエンジン、トランザクション分離レベルはREPEATABLE-READ, READ-COMMITEDです。上記は検証環境ですが、MySQL5.1 ~ 5.7でも変化していない挙動のはずです。また、InnoDBのロックはインデックスレコードロックなので、インデックスに対する理解が必要不可欠です。発表時間も20分程度ということもあって、その辺りをある程度理解されてる方が
「もう従来DBかNoSQLか悩まずに済む」、Googleが基幹用RDB「Cloud Spanner」を発表 米Googleは現地時間2017年2月14日、ミッションクリティカルなアプリケーション向けの分散リレーショナルデータベース（RDB）「Cloud Spanner」を発表した。現在、公開ベータ版を提供している。 Googleによると、Cloud SpannerはACIDトランザクションとSQLセマンティックをサポートし、トランザクションの一貫性を保証する一方、水平スケーリングと高可用性を実現する。「一貫したトランザクションの従来データベースか、拡張性とデータ分散のNoSQLかで悩む必要がなくなる」とGoogleは述べている。 GoogleはCloud Spannerの利点として、シャーディングやクラスタリングを行わずにRDB管理システムをスケールアウトし、NoSQLデータベースに移行す
第3回 AOPでプログラムをシンプルにする
株式会社DTS ネットワーク事業本部所属。Struts/Springベースのフレームワーク開発，プロジェクト支援に携わる。 今回は，Springで提供されているAOP機能（以下，SpringAOP）について説明します。最初にAOPとは何なのか，どんなメリットがあるのかを簡単に説明します。次に，AOPの基本的な使い方を，サンプルを使って説明します。あなたが普通の業務開発者であるならば，このAOPの使い方を覚えるだけで十分でしょう。 最後に，AOPを自分で作る（正確には「アドバイス」というものを作ります）という，少し高度なことに挑戦します。こちらはAOPを自作する必要が出たときに読めばよいと思います。それでは，さっそく始めましょう。 AOPとは AOPとは，アスペクト指向プログラミング（Aspect-Oriented Programming）のことで，オブジェクトが本来するべき処理と，本来する
WEB開発で必ずついて回るのが、Submitボタン二度押しや戻るボタンを押されるなど、勝手な画面遷移をされないような配慮です。Strutsでは同期トークンという機能でこれらの考慮をサポートしてくれます。 実際にサンプルで、ある画面でSubmitを二度押ししたとき、それを検知して二つ目のリクエストをエラーではじくという事を考えてみます。 同期トークンとは † 同期トークンの機能とは以下の通りです。 あるアクションで、サーバ上でユニークなID(以下、トークン)を生成し、返却するhtmlにhidden等で仕込んでおく そのアクションで、トークンはSessionにも格納しておく 次のリクエストにはhidden内のトークンが飛んでくる 次のアクションで、hiddenパラメタ内のトークンとSessionのトークンが等しいことを確認する 等しければ、正しいリクエストということで処理する。Session内
CakePHPで複数テーブルに対するトランザクションを使う場合 - takami_hiroki’s blog
CakePHPでトランザクションを使用する必要があったのですが、一般的に用いられている方法だと、複数のテーブルを1つのトランザクションとして更新したい場合、コントローラ内での実装がとても分かりにくくなると感じ、異なる実装方法をとってみたので、ご紹介します。 一般的な実装方法とその課題 一般的な実装方法としては、app/models/app_model.phpに、下記のようなトランザクション管理用のメソッドを追加することが多いと思います。基本的に、各モデルクラスは、AppModelクラスを継承しているため、これらのメソッドをどのモデルからも利用可能になります。 function begin() { $db = & ConnectionManager::getDataSource($this->useDbConfig); $db->begin($this); } function commit
20140711 MySQL Casual Talks vol.6 / 続・Amazon RDS Casual Talks This document discusses N:1 replication, which allows multiple master databases to replicate to a single slave database. It describes how N:1 replication works and some limitations, like inability to keep up with schema changes or restarting easily. The document then introduces MHA (Master High Availability), a tool that can automate fa
今月から社内勉強会は、社員が持ち回りで講師を担当することになりました。 初回のテーマは「MySQLのトランザクション」です。 MySQLにほぼ限定した形でトランザクションについて発表をしました。 資料は以下の5章立てになっています。 1.トランザクションとは 2.ストレージエンジン 3.トランザクションの開始と終了 4.ACID特性 5.オートコミット 日頃の業務では、実行したSQLの動作確認をした際に、意図した結果が得られない場合に処理を戻せるように、「begin」で書き始めてトランザクションを開始するようにしています。 しかし、そもそもトランザクションは「失敗した時に戻すための機能」ではありません。 普段から使ってはいるけれど深くは知らなかったトランザクションについてちょっとだけ知識を深めるよい機会になったと思います。 なお、「2.ストレージエンジン」の中で、MySQLで利用できるスト
Part1 トランザクション管理とは何か
日頃，システム構築の開発現場において「トランザクション」という言葉をたびたび耳にします。Part1では，トランザクションの初歩の初歩から分散トランザクション技術までを解説していきましょう。 企業における業務処理の多くは，「確実に遂行されること」が求められます。例えば，「本日の取引は10件で，たぶんすべて成功したと思います」という報告ではなく，「本日は10件の取引を行い，すべて成功裏に完了しました」という報告が必要なわけです。 業務はITを活用することにより効率的に進められますので，ITの世界ではそれぞれの取引が確実に「成功する」ことを保証する仕組みが必要になります。この取引のことを「トランザクション」と言います。具体的には，データベースにアクセスする処理を処理1，処理2，処理3のようにつなげて呼び出す「一連の処理」（処理の固まり）です（図1）。 トランザクションは，次の4つの特性をすべて保
こちらはブロックチェーンアドベントカレンダー12日目の記事です。 https://qiita.com/advent-calendar/2017/blockchain 今年は価格の暴騰以外にも色々と話題を事欠かないBitcoinですが、その中でもSegwit、Segwit2Xは記憶に新しいのではないでしょうか。 Bitcoinにかぎらず、多くの暗号通貨はそのスケーラビリティに上限があり、それらに対して幾つかの解決策を見出そうとしているのが現状となります。今回はそのスケーラビリティに対する現状について、特にパブリックなチェーンに対するものを中心にまとめてみようと思います。 そもそもBlockchainのスケーラビリティとはVISAカードなどが対処しているトランザクションは秒間4000~6000と言われていますが、Blockchainはその仕組み上、マイナー（PoSではバリデーター）の数が増えて
(解決済み) DBIx::TransactionManager + File::RotateLogsで意図せずトランザクションが終了してしまう件 - Hateburo: kazeburo hatenablog
DBIx::TransactionManager 1.13で子プロセスでrollbackを実行しないような変更が入っています。 https://metacpan.org/release/NEKOKAK/DBIx-TransactionManager-1.13 TengやDBIx::Sunnyなどでトランザクションを使用し、File::RotateLogsでログを書き出している場合はバージョンアップをお勧めします。 経緯など 某サービスにおいて、DBIx::TransactionManagerを使ってトランザクションを実行している箇所で9時にトランザクションが意図せず終了するという問題がありました。 コードにするとこんな感じ my $rotatelogs = File::RotateLogs->new( logfile => '/path/to/access_log.%Y%m%d%H%M',
この手の「俺は今からこれを読んでログを残すぜー！」的宣言は過去に何度かやって当然失敗してきたのでそんなに期待しないで頂きたい。 Principles of Distributed Database Systems これは御徒町と名乗るトランザクションおじさんが主導して僕も便乗させていただいている本。分散データベースの歴史をANSIの頃からちょいちょい触れながら、どういう風に最適なクエリを実行できるかにフォーカスしている感じの本。SQLとかクエリプランニングとか最適配置とか集合の分割とかそういう話が多く、CAP定理とかトランザクションとかはあまり出てこない。途中までしか読んでないのでそんな印象だけど、今後どうなるかな…？！ 860p Principles of Distributed Database Systems 作者: M. Tamer Oezsu,Patrick Valduriez出
基礎から理解するデータベースのしくみ（11）
表1●トランザクション処理の分離レベルと，それぞれで発生する可能性がある現象。分離レベルは下に行くほど高くなります マルチユーザー環境では新たな問題が発生 ここまでの説明は基本的に，一人のユーザーがデータベースにアクセスしていることを前提にしていました。しかし実際には，複数のユーザーが同時にデータベースにアクセスすることはよくあります。むしろ，受発注システムや座席予約システムなど，実用データベース・アプリケーションのほとんどは，複数のユーザーが同時に使うことを前提にしていると言ってよいでしょう。こうしたマルチユーザー環境では，ユーザーが一人のときには無かったさまざまな問題が起こります。 例えば，ユーザー1がトランザクションの途中で特定のレコードの内容を変更したあとで，別のユーザー2がそのレコードを読み込んだとしましょう。そのあとでユーザー1がトランザクションをロールバックしたら，ユーザー2
米Google（グーグル）は2022年5月に開催した年次カンファレンス「Google I/O 2022」で、新しいデータベース（DB）サービスである「AlloyDB for PostgreSQL」を発表した。 グーグルが2022年5月12日（米国時間）に発表したAlloyDB for PostgreSQLは、同社が独自に開発したDBのサービスで、オープンソースソフトウエア（OSS）のリレーショナルDB（RDB）である「PostgreSQL」と互換性がある。ユーザーはPostgreSQL用のSQLクエリーや拡張機能がそのまま利用できる。 AlloyDB for PostgreSQLの特徴は、トランザクション処理（OLTP）性能とデータ分析（OLAP）性能を両立した点だ。グーグルによればAlloyDB for PostgreSQLは標準的なPostgreSQLに比べて、同じ数のCPUを使用する
MySQL の Repeatable Read と RocksDB の楽観的トランザクション解説｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL の Repeatable Read と RocksDB の楽観的トランザクション解説 こんにちは技術研究グループ・テクニカルディレクターの波多野です！ 普段は社内のインフラ、特にデータベース関連の技術的な問題を解決するのを仕事にしています。 弊社ではリレーショナル・データベースとしてはオープンソースの MySQL をとてもよく使っていますが、そんなオープンソースのデータベース界隈で最近よく目にするようになって来たのが 楽観的トランザクション(Optimistic Transaction) という技術です。今回はトランザクション処理の歴史的なところに触れながら、RocksDB に代表される楽観的トランザクションについて簡単に解説したいと思います はじめに MySQL を使っているとデフォルトでは REPEATABLE READ のトランザクション分離レベルになっていて、トランザク
<Insert Picture Here> MySQLパフォーマンスチューニング概要 日本オラクル MySQL Global Business Unit Copyright© 2011, Oracle. All rights reserved. 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。 また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことは できません。以下の事項は、マテリアルやコード、機能を提供することをコミットメン ト（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さ い。オラクル製品に関して記載されている機能の開発、リリースおよび時期につい ては、弊社の裁量により決定されます。 OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文
DDDにおいて、なぜ複数の集約にまたがってトランザクションをかけてはいけないのか（multiple aggregates in one transaction） - pospomeのプログラミング日記
DDDでは 集約 = トランザクション境界 でなければならないので、 複数の集約をまたがるデータの永続化処理は結果整合性になる。 なぜ集約をまたいでトランザクションをかけてはいけないのかというと、 集約で「データの一貫性の境界」を表現するため。 なので、集約同士はデータの一貫性を保証しない = 結果整合性 ということになる。 集約がトランザクション境界ではない場合はどうなるのかというと、「データの一貫性の境界」がドメインレイヤで表現できなくなる。 あるときは 集約A, 集約B が一緒のトランザクションで登録され、 あるときは 集約A, 集約B, 集約C が一緒のトランザクションで登録される、というケースがあると、 「データの一貫性の境界」はアプリケーションレイヤのトランザクション開始から終了までのコードで表現されてしまうので、 それぞれの集約がどの粒度で一貫性を保たれるのかが分からなくなる
開始コマンドがDBMSによってバラバラなのは、標準SQLで明確に決まっていないためです。中にはOracleやDB2のように、データベースへ接続したら自動的にトランザクションが始まることになっているため、開始コマンドのないDBMSもあります。確かに、最初に暗黙に開始されれば、そのあとは終了文だけあれば区切りはわかる（終了文が次のトランザクションの開始文も兼ねる）ので、合理的といえば合理的です。 構造的な単位としてのトランザクション 一方でDBMSの側から見ると、トランザクションは2つの重要な機能に関係しています。それが、「データの復旧」と「同時実行制御」です。まずは、前者から見ていきましょう。 トランザクションは復旧の単位 障害発生前に終了したトランザクション データベースに限らず、システムというのは使い続けていればどこかのタイミングで障害に見舞われます。なるべく障害に遭遇しない堅固なシス
スレッドプールのサイズを調整する
この他にも "サービスを受けるのを待つ人が，キューの中に立っている平均時間はどれくらいか？" といったような疑問に，Littleの法則で答をだすといった内容のゲームは，他にもたくさんあります。 図１. Littleの法則 同じようにLittleの法則は，スレッドプールサイズの決定にも使うことができます。私たちがしなければならないのは，リクエストの到着率と，サービスに必要な平均時間を測定することです。そうすれば，これらの値をLittleの法則に挿入して，システムの平均要求数が計算されます。その数値がスレッドプールのサイズよりも小さければ，その結果に従ってプールのサイズを小さくすることが可能なのです。逆に計算結果がスレッドプールのサイズよりも大きい時には，問題はもう少し複雑になります。 実行中のリクエストより待ち状態のリクエストの数が多い場合，まず最初に判断しなければならないのは，もっと大きな
D は durability 日本語だと永続性です。 トランザクション処理結果は永続的であることを保証します。 永続的（失われない） = システム障害に耐えろということです。 いきなり泥臭いです。 RDBMSはトランザクションログを取っていてますよね。 ORACLEならREDOログ、MySQLならバイナリログとかいうやつです。 ※実際はもう少しアレではあるが、そこは割愛 何かあっても、ログから障害発生前に戻れるようにしています。 あくまで製品の仕様であって、開発者・運用者のミスによって余裕で飛びますし、どうしょうもない障害もあります。 おまけ ACIDについて簡単にまとめました。 以上の特性があるので、RDBMSはいつでも安心して最新のデータを使って処理を行えます。（ここらへんを細かく話すと超めんどいのでサクッと言いました。） ECサイトや銀行とか値がズレたりデータが飛んでしまった等が仮に
multiversionの基礎 自分用のMulti Version Concurrency Controlのまとめ MVCCの基礎理論をまとめておく。今後はここを参照する。 基本的にTX本とCC本から必要な部分をまとめている。 （一回まとめてるけど、Multi-version Conflict Serializability - 急がば回れ、選ぶなら近道 前回はそもそもCSRとの混線を防ぐという意味だったので、今回はもっと基本的なところからさらに。今回はCSRとの関係はガン無視。） 前置き：自分の考えを記録的に 基本的にMulti Version Concurrency Control （以下MVCC）は理論先行だった。これはMVCCのオーバへードがsingle-versionのパフォーマンスを凌駕できなかったことによる。以下の理由によりMVCCが今後は伸張すると考えている。 1.メモリー
Microservices の裏で動く Microservices を Go で開発している話 | メルカリエンジニアリング
Mercari Advent Calendar 2018 の 25 日目はメルカリ JP の Microservices Development Team の @codehex がお送りします。 これまで私達は Microservices を開発している旨を様々なテックイベントやカンファレンスで話してきました。中でも Mercari Tech Conf 2018 で Monolith なアプリケーションから Microservices へ移行するために、私達がどうしているかという話が目立っていたと思います。 そのうちの一つである Listing Service という出品機能の Microservice の話がありました。 資料の内容をまだ知らない方のために、本記事を理解するために補足します。 メルカリでは Microservices を基本的に Google Cloud Platform
モデルでbegin()とかやってはいけない気がする。 Overloadableを継承してるので、メソッドが定義されていない場合は call__()がコールされる。 ベヘイビアとか登録してたらそっちが呼ばれるけど、通常は使わないと思うので データソースのquery()が呼ばれる。 query()内では、メソッドをテンプレートとして引数をバインドしてSQLとして呼ぶと思うので、 begin()とかやると、"BEGIN"というSQLがコールされる。 PostgreSQLだとまさにこれはトランザクション開始のコマンドなので 動作してるように見えると思われる。 でもね。データソースにはちゃんと begin() commit() rollback() っていうメソッドがあるからこっちを使うはず。 モデルのsaveAll()内でもそうしてる。 ということで、モデルにメソッドがないのが困ったけど、以下で解
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分散合意アルゴリズム Raft を理解する - Qiita
MySQL - InnoDBのロック関連まとめ - Qiita
データベース12 - トランザクションと同時実行制御
データベース設計で派生関係は難しい - プログラマの思索
メルペイ立ち上げの裏側 – 決済サービス開発のゼロイチ話 | メルカリエンジニアリング
トランザクション分離レベルについてのまとめ - Qiita
「NoSQL」を上回る性能を目指す次世代型高速SQLデータベース「VoltDB」登場
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.7.2.4 読取りのロック
「外部キー Night」に参加してきた - ichirin2501's diary
「もう従来DBかNoSQLか悩まずに済む」、Googleが基幹用RDB「Cloud Spanner」を発表
Struts/同期トークンで二度押しなどをチェックする - きのさいと
mysqlcasual6-next-key-lock
社内勉強会(1) – MySQLのトランザクション | アロハ技術者ブログ
暗号通貨のスケーラビリティについて考える
技術書を読む読む詐欺 - kuenishi's blog
グーグルのHTAP対応PostgreSQL互換DB「AlloyDB」、データ分析性能は最大100倍
先進事例に見る経営とIT 〈攻める〉 ANA、脱メインフレームで70億円削減へ
(pdf) MySQLパフォーマンスチューニング概要 - Oracle
第2回 トランザクションを知ればデータベースがわかる―「データ復旧」「同時実行制御」を行う“不完全な”しくみ（1） | gihyo.jp
おっさんがACIDとかBASEとかまとめておく。 - Qiita
multi-versionの基礎 - 急がば回れ、選ぶなら近道
CakePHP 1.2 でトランザクション - bobchinの日記