【重要発表】 シックス・アパートは2月1日に、新しい体制に生まれ変わります！ http://www.sixapart.jp/news/2011/01/21-1700.html 早い話が身売りである。WordPressなどの競合を排して独自に日本市場を切り開く体力も技術的優位もないのがはっきりしたということだろう。 日本におけるSixapartと僕らの愛すべきMovableTypeの命運が絶たれたことを記念して少しばかり回想をしよう。 00年代の前半。MovableType2.2が「ブログ」という聞き慣れない言葉とともに日本にそれとなく入ってきたとき、当時駆け出しだった私はもちろん、日本のWeb業界でMovableTypeに度肝を抜かれなかったものはいなかったと思う。 垢抜けたインターフェース 洗練されたCSSベースのデザインテーマ トラックバック、RSSといった後にWeb2.0と称される斬
WHERE 条件のフィールドを UPDATE するのって，明示的にロックしてなくても安全？全パターン調べてみました！ - Qiita
WHERE 条件のフィールドを UPDATE するのって，明示的にロックしてなくても安全？全パターン調べてみました！MySQLSQLPostgreSQLDatabaseQiitaEngineerFesta2022 TL; DR MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。トランザクション分離
MySQL 5.6からの機能であるGTIDを、Facebookの環境に適用した際の流れと主な不具合、そしてそれらの修正点について、Facebookのエンジニアによるまとめ。 by Evan Elias and Santosh Praneeth Banda Global Transaction ID (GTID)は、MySQL 5.6の新機能の中でも最も使わずにはいられない機能の一つだ。このおかげで、フェイルオーバやポイントインタイムリカバリ、階層を持ったレプリケーションなどに非常に有益だし、クラッシュセーフなマルチスレッドレプリケーションの必須条件にもなっている。この数ヶ月で、我々はFacebookの全ての本番用MySQLインスタンスで、GTIDを有効にした。その中で、この機能の適用方法や操作について、たくさんの知見が得られた。たくさんのサーバサイドの修正事項については、WebScaleS
モジュラモノリスにおけるトランザクション設計の考え方 / transaction design on modular monolith
モジュラモノリスにおいてトランザクションはどうあるべきなのかについて整理している資料が少ない気付きがあったので「簡易的に」整理しました
MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス
全IT関係者が知っておくべき「1-copy-snapshot isolation」 - 急がば回れ、選ぶなら近道
snapshot isolationを分散環境に適用する場合の「基本」の内容のまとめになります。（基本自分用のメモなので、間違っていたらすみません） まずワーディングの整理 ・snapshot isolation TXの分離レベルとしてのsnapshot isolation（以下SI）は、現在のRDBMSのTX管理では、ほぼ実装的にはデファクトと見ていいと思います。ただしANSIの規定のISOLATION_LEVELには定義がないので、どのあたりに位置づけるのかは、DB実装のそれぞれの取り扱いにより異なります。とはいえ、どのDBでもほぼSERIALIZABLEに近い位置づけにしているところが多いですね、というか、SI（特にSerializable SI）ぐらいでないとserializableに現実的には近づけないというのが実態かと思います。（勿論理論上はS2PLで実装は可能ですが、まぁパフ
DB外の副作用をトランザクションから分離しよう / Isolate out-of-DB side effects from transactions
gotanda.rb#52@オンライン "DB外の副作用をトランザクションから分離しよう"
2021/6/11 #InfraStudy 2nd Season
MySQL5.6のちょっとした話 - まめ畑
最近、とあるサービスの本番環境にMySQL5.6を導入していっています。社内だけの環境も含めて5システムに導入しました。 5.5からのアップデートや最初から5.6というものもあります。 今回、導入で変わった点いろいろありますが、メモ程度にまとめておきます。 間違いなどありましたら指摘していただけるとありがたいです。 Replicationエラー時 今までは、replicationのエラーが起こった場合は SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; とかでダメなクエリを確認しつつSKIP出来ればしていましたが、5.6でGTIDモードONの場合、これが使えなくなりました。 GTID便利なんですが、この点少し不便です。 以下のように直します。 まず、slaveでmaster server UUIDと最新のGTID、Retrieved_Gtid_Setを確認します
一人トランザクション技術のカレンダー | 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つに大別出来ます。 本来よりも多く請求しまい、ユーザーからの信頼を損ねる。 決済の金額を増やしてしまった。 決済の時期を早めてしまった。 決済は通ったがサービスを提供できていなかった。 本来よりも少なく請求してしまい、事業運営に支障を来す。 決済の金額を少なくしてしまった。 決済の時期を遅くしてしまった。 実際には決済が通
RESTに関する３つの間違い
楽観的排他制御を利用する非同期的なトランザクション実行であればスケーラビリティを損ねることなく2phase commitが可能である。これは、分散KVSにおけるスケーラビリティと一貫性の両立について で主張したように、同期的な2phase commitは密結合に誘導することになるため、矛盾するように思えるかもしれない。だがそんなことはない。 前半はまずこの話から入るが、後半ではRESTに関する間違いについて、３つほど思うところを述べたい。 楽観的排他制御と2phase commit reflexworksではFeedやEntry単位でatomicなトランザクション処理を行えるが2phase commitはサポートしていない。これを許すと密結合になってスケールしないからである。だが、これはあくまで同期的な処理の話であって、ネットワーク障害への耐性を考慮され、非同期処理やオフラインで使えるので
こんにちは。id:shallow1729です。先日はredo logを中心にストレージエンジンについて解説を行いましたが、今回は同時実行制御、特にMySQLなど多くのデータベースで採用されているMultiversion Concurrency Control(MVCC)という技術にフォーカスしようと思います。 今回の記事ではまず前半でMVCCというものがどういうものかについて解説をして、次にMVCCの実装方法についてInnoDBの実装を参考にしながら見ていこうと思います。前提知識はあまりいらないと思いますが、リレーショナルデータベースの操作経験はあったほうがいいかなと思います。また、前回のストレージエンジンの解説で述べた内容はあまり説明しないので、軽く目を通してもらえると頭に入りやすいかなと思います。 shallow1729.hatenablog.com トランザクションの原子性 まずトラ
ソリューションエンジニアチームに所属する筆者が、今では様々な手法が存在するレプリケーション機能について、改めて特徴や注意点を解説しつつ、レプリケーションのよくある「誤解」に対してもお答えしています。 このブログ記事では、MySQL（および Percona Server）環境におけるレプリケーション手法に関して改めて考察を行いたいと思います。あわせて、時折見受けられるレプリケーションの間違った考え方についても考えてみます。 私がソリューションエンジニアとして働き始めてからというもの、沢山の情報が公開されているにも関わらず、レプリケーションに対する「誤解」や「不完全な理解」が無くならないことを日々感じていました。 そもそもレプリケーションとは何か？ レプリケーションは、1つのデータベースにデータを蓄積するだけでなく、別のデータベースにデータを複製し、転送することを保証してくれる機能です （複製
こんにちは、SRE の @masartzです。 今回は最近取り組んだ、メルカリの主要データベースの容量削減のお話をしようと思います。 TL;DR 主要データベースの容量を20%以上削減しました どういう状況だったか？ 何をしたか？ メルカリでは2017年11月現在、出品数は1日100万件を超えています。 なので、単純に日々多くのデータが増えていっています。 そのためデータベースのスケーリングは常に検討し、取り組まなければならない課題です。 今回扱ったデータベースはいくつかあるデータベースの中で商品テーブルを持つ、メルカリの主要データベースになります。 増え続けるデータに対応するための、テーブル分割を変則的な形で対応したのでその過程を紹介します。 前提：データベース分割方法 メルカリのデータベースには 会員情報や商品情報など、基本要素となるデータから、通知やお知らせメッセージなど付加的な機能
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
一歩ずつ一歩ずつ前へ進んでいく、確実に。どうも、かわしんです。 到底 1 記事に収まるような内容ではなく長いので、トランザクションの作り方に興味のない方は途中の「なぜ Go なのか」まで読んでいただければ嬉しいです。 この記事は、Go2 Advent Calendar 2019 の 7 日目と セキュリティキャンプ 修了生進捗 #seccamp OB/OG Advent Calendar 2019 の 7 日目を兼用しています。 さて、僕の興味は必要になったライブラリやミドルウェアなどを自作して、作りたいプロダクトを完成させることです。必要なコンポーネントがないからといってプロダクトを作るのを諦めたり妥協したりはしたくありません。 多くのアプリケーションではデータベースは重要なコンポーネントです。大抵のアプリケーションは MySQL や Postgres、Redis など既存のデータベース
今回は、米Googleのクラウド環境に存在するデータベースBigtableとDatastoreサービスを紹介します。「巨大分散」という新たなデータベースの地平を切り開くためにどのような工夫をしているか、じっくり見ていきましょう。 「Bigtable」は、Googleの主要なサービスを支える独自の巨大分散データストアです＊1。Bigtableは、2005年4月から本格的な運用（プロダクション利用）が開始されたもので、Googleの検索サービスをはじめ、Gmail、YouTube、Google Maps、Google日本語入力、そしてApp Engineなど、70以上のプロジェクトで利用されています。その規模は、数P（ペタ）バイト～数十Pバイトに達しているでしょう。 Bigtableは、Google検索サービスにおける膨大なコンテンツやインデックスを保持し、高速に検索するための専用データストア
元ネタ: http://labs.unoh.net/2007/07/mysqltips.html あまり具体的じゃないので、僕の考えとか。 正しいかどうかは各自の状況だとか実際試すべきなんだけど、参考になれば。 MyISAM、InnoDBなどテーブルタイプ 僕は断然InnoDB派です。 ただ仰るとおり、ログるだけのテーブルとかならMyISAMでもいいとは思うけど。 トランザクションやロック処理などが必要ない場合など、MyISAM形式にも良いところはあるので検討してみる価値はあるかもしれません。 これだけの指摘だとちょっと微妙な気がするです。 MyISAMの使いどころってのは、 ピンで他とリレーションが無い単純追記系のテーブル リレーションがあり、同一トランザクション内での更新系クエリが存在する場合は、トランザクションが期待通りに動かないので、基本的にはInnoDBと混在させるべきではない
こんにちは、mixi開発部にてアプリケーション開発をしていますyouheiです。 今回は、MySQL-5.0.45のInnoDBで連番を管理するテーブルのパフォーマンス測定をしていたのですが、その際に少し変わったデッドロック問題に遭遇しましたので、そのあたりをネタとして書いてみたいと思います。 まずは、今回使用したデータベースのスキーマは下記のようなものです。 CREATE TABLE num ( id bigint unsigned NOT NULL default '0' ) Engine=InnoDB; AUTO_INCREMENTは使用していません。 そこに1レコードだけ登録します。 INSERT INTO num (id) values (1); そして実際連番を取得する際には、 UPDATE num SET id = LAST_INSERT_ID(id+1); といったクエリを
カラム型データベースはなぜ集計処理が高速で、トランザクションが苦手なのか。インメモリとカラム型データベースの可能性を調べる（その4）
カラム型データベースはなぜ集計処理が高速で、トランザクションが苦手なのか。インメモリとカラム型データベースの可能性を調べる（その4） 現在主流となっているOracle、SQL Server、DB2などのリレーショナルデータベースは事実上すべて、行（ロー）指向で内部の処理を行っています。一方で、最近急速に注目されているのが、列指向で内部処理を行い、大量データの集計や分析処理に優れた「カラム型データベース」（あるいはカラム指向データベース、カラムナーデータベース）です。 カラム型データベースはSybase IQやNetezza、Verticaなどデータウェアハウス専用のデータベースで主に採用されています。また、SQL Serverには「ColumnStore Index」、Oracle Exadataには「Hybrid Columnar Compression」と呼ばれるカラム型データベースの
『夢のデータベース？「Cloud Spanner」の実力は？』について - Software Transactional Memo
こんな記事が目に入った。 www.itmedia.co.jp 大雑把に完全に間違ったことを言っているわけでもないが、読んでいくといろいろ鼻につくところがあり、どのあたりから間違っているのかと自分に問いただすのは現時点での自分の知識を棚卸しするためにも有用かも知れないと思ったので一言一句漏らさず思うところを書いていこうと思う。 中には枝葉末節な難癖もあるので全部を真に受けない感じで読んで欲しい。 Cloud Spannerの特徴は、これまでリレーショナルデータベースで不可能とされていた「トランザクション処理の大規模分散処理」を実現したところにあります。 単一のトランザクション処理を分散して実行しているかというと、Spannerはトランザクションごとに担当のトランザクションマネージャがそのトランザクション処理全体を取り仕切って行う仕組みになっている。なので「トランザクション処理の大規模分散処理
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)
GCPでSagaパターン実装
概要 メディアやコミュニティ系のアプリケーション開発を中心に行っていたが、最近会社で決済系のシステムを扱うようになったこともあり、複数のサービス間がある中でどう結果整合性を担保するかについて学んでいた。 そこで学んだ複数サービス間での整合性を保つための手法として分散Sagaパターンがあり、実際にCloud RunとCloud PubSubで実装をしてみた。 複数サービスでの整合性 複数サービスでの整合性の問題 一般的にシステムを複数サービスに分けることによって、サービスを効率的に利用することや開発チームを分けることや小さくデプロイが可能など多くのメリットが挙げられる。 しかし、複数サービスにしたときの１つの問題として、データの整合性を取ることが難しくなることが挙げられる。 例えば、1つのDBのシステムに対してデータのWriteをアトミックに行う場合はDBのトランザクション等を使うことによっ
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design PatternAmazon Web Services Japan
読者対象 ANSI 定義の古典的なトランザクション分離レベルとアノマリーは概ね理解している MySQL/Postgres では理論的な部分がどうなっているのかを知りたい 理論面の前提知識 2022-08-19 追記: 社内勉強会向けのスライドを作成しました。先にスライドを見てから，引用文献およびこの記事を読むと理解が深まると思います。 まず ANSI 定義の古典的な定義を聞いたことが無い方は，以下のリンクを参照されたい。 ANSI 定義に対応する解説はこれらのサイト以外にもたくさんあるため，自分にとって読みやすいと感じる情報をあたってほしい。（既に熟知されている方は十分） 次点で読んでいただきたいのが， @kumagi さんの以下の記事。古典的には 4 つの分離レベルと 3 つのアノマリーだけで説明されていたものの，不十分であることが学術的に指摘され，解像度を上げようとする流れが後になって
Ether を送金した人だけコンテンツを閲覧できる Ðapp を書いた - 詩と創作・思索のひろば
Ethereum はブロックチェーン上でアプリケーションを動かせる（スマートコントラクト）ってので興味を惹かれて、どんなことができるのか調べてたんだけど、感じを掴むために一つ書いてみた。 やりたいことは、ウェブページに送金ボタンがあって、そこから特定のアドレスに Ether を送金し、送金が確認されたら秘密のコンテンツをページ上に表示する、てなもの。送金の確認はスマートコントラクトで行えるが、秘密の情報をブロックチェーン上に記録するわけにはいかないのでこれはウェブサーバに秘匿することになる。とすると、ウェブサーバに私はこの Ethereum アドレスです、とセキュアに伝えてやる必要がある。後で書くけど、あまりいい解法ではない。 知識ゼロの状態から分からないことを潰しつつなんとか動くところまでこれたので、ウェブアプリケーション開発者がつまづいたところをメモっとく。 デモ MetaMask W
App Engineで現実的な送金処理について考え中です。 ドラフト版なので、怪しい点があればご指摘いただければ幸いです。 コメントで情報いただきました。 Distributed Transactions on App Engineで紹介されてる方法と基本的に同じなので、おそらく問題なく動きそうです。ありがとうございました。 今回はこんな図を使います。 この図の読み方は、矢印の方向にユースケースの一連の処理(またはリクエストの処理)が流れていて、右に行くほど時間が経過しています。そして、矢印がくし刺しにしている四角形は、そのユースケース中で操作するエンティティを表しています。 また、左右の位置が同じ矢印は、基本的には同じ時刻に発生したイベントを表しています。上記の図では、A, B, Cがそれぞれの口座エンティティを同時に操作している感じです。 並行性制御(おさらい) 最初の図のように、それ
MySQLのINSERT/UPDATE時におこる不整合対策 - LukeSilvia’s diary
先日、作っているアプリケーションにバグが発生しました。バグの内容は次のようなものでした。 同時に存在してはいけないはずのデータが、DB に存在する 整合性のチェックはアプリケーションレベルで行っている 一意制約のような単純なものではないので、アプリケーションレベルで実装 整合性のチェックロジックは正しい これに対し、バグは次のような状況で発生したと仮説を立てました。 ユーザがレコードを一括登録しようとする 登録ボタンを押したがレスポンスが遅い この間、整合性チェックが走っている ユーザはもう一度登録ボタンを押した 2回目の登録の整合性チェックが走り始める 1回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックの間、DBにはまだ1回目の登録によるINSERTが実行されていないので、チェックを通過した 結
O/Rマッピングで緩和されるインピーダンスミスマッチには静的と動的の側面がある - 達人プログラマーを目指して
一般的な業務アプリケーションではデータを永続化するために、RDBMS（関係データベース管理システム）を利用します。RDBMSでは大量のデータを効率的に検索したり、集約してレポートを作ったりすることが得意ですし、一般的に業務システムで求められるトランザクションのACID特性*1を満たすことも容易です。また、適切にテーブル設計の正規化を行うことにより、運用面においてデータの管理コストを下げることもできます。最近ではスケーラビリティの問題などもあり、RDBMS以外のデータベースについても注目されるようになってきていますが、今後も業務アプリケーションの主流としてRDBMSは使われていくだろうと思われます。 従って、Javaなどのオブジェクト指向言語で開発を行い、DDDのようなオブジェクト指向の設計技法を利用する場合に必ず考えなくてはならない問題は、オブジェクト指向と関係モデルとのインピーダンスダン
builderscon tokyo 2019で登壇した際の資料です。 Kyash Directのアーキテクチャについて - スクラッチ開発を決めた経緯 - アーキテクチャ決定までの試行錯誤 - 関連トピック - Microservices - DDD - AsyncMessaging - Choreography - EventDriven - EventSourcing - SagaPattern
Webシステム開発において性能試験を行う場合、hp LoadRunnerやApache JMeterといったウェブブラウザをエミュレーションしてくれる負荷テストツールを用いるのが定番だと思います。そんななか、たまにデータベース単体での性能を測ってほしいと頼まれることがあるので、そうした便利なツールはあるのかなと思って調べてみました。 データベースに対する負荷テストツールは探すとたくさん出てくるのですが、案件で使用しているRDBMSに対応していなかったり、トランザクション仕様が希望と異なっていたり、微妙に作りが悪かったりと、ニーズに合致したツールはすぐには見つかりません。そんなときにこのエントリがツール探しの参考になればと思います。 pgbench 対応RDBMS：PostgreSQL 対応OS：Linuxなど 言語：C 作者：石井達夫氏 ライセンス：独自(BSDライセンスに近い) トランザ
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(
teespring.com 分散データベースというのは、それ単体でもとても難しい、データベースと、分散システム双方の技術の粋を結集して実現されるアプリケーションだ。これをサービスといったり、ミドルウェアといったりする場合もあるが、今回は技術を応用してつくったものという意図でアプリケーションと位置づけることにする。まあ古くて新しい問題で、死屍累々の世界でありながら、それでいて金の鉱脈でもある世界だ。イカのようなトピックを概説していくことで、近年の流れをメモしておきたい。 Pre-cloud era: クラウド以前の時代 BigTable, DynamoとCAP定理 MegaStore 研究: Calvin Jepsen: できたら☎してよ〜 Coordination free database Spanner: 何でもできるよ！！ Kudu+Impala Next? クラウド以前の時代 Sy
事前知識編 システム開発するプログラマも読んでおいたほうがいい資料とか。 今時のシステムならまず仕様や運用に反映される。されてなかったらむしろこっちから確認取りに行った方がいい。 JOGAガイドライン 昔ガチャとかが問題になったときに出てきた協会のガイドライン。 オンラインゲーム安心安全宣言 オンラインゲームにおけるビジネスモデルの企画設計および運用ガイドライン ランダム型アイテム提供方式を利用したアイテム販売における表示および運営ガイドライン オンラインゲームガイドライン 開発環境編 GitHubみたいなPullRequestを出せる環境 GitだけじゃなくてGitHub。必然的に規模が大きくなるのでプルリク出して進めることになります。 CIまで設定をする 最初のうちにCircleCIのようなテストの自動実行する仕組みまで揃えてしまっておいたほうが良いです。後からだとそもそも対応できなく
@ymmt2005 こと山本泰宇です。 今回は memcached 互換で冗長構成を簡単に組める自社製 KVS である yrmcds のリリースをご案内します。 ... この Redis 全盛なご時世になんで？とか、repcached や Kyoto Tycoon があるじゃない、といったツッコミの嵐が聞えてきそうです。わかってます、わかってますから物を投げないで！ 順を追って説明しますので、批判はそれからにしてください！ 何が欲しいのか 私は日頃 cybozu.com のインフラで動作するソフトウェアを開発しています。リリース後もうすぐ２年になりますが、お蔭様で 4,000 社以上にご利用いただくまでになりました。商売繁盛で嬉しいのですが、運用側は日々増えるデータとアクセスを捌くべく奮闘しています。 ここのところ問題になっていたのが、MySQL に保存しているセッション情報でした。アプリ
サルでもわかる 逆引きデザインパターン 第3章 逆引きカタログ J2EE編 DAO（Data Access Object）
イントロダクション 私たちが作るアプリケーションのほとんどは、どこかで永続的なデータを扱うことになります。 そのデータの保存先は、リレーショナルデータベースやテキストファイル、他システムなどになるでしょう。 そして保存されたデータへのアクセスで使用するAPIは、保存先によって変わっていきます。 例えば、リレーショナルデータベースだとJDBCを使用します。 ファイルだとjava.ioパッケージあたりを使用したりします。 また、リレーショナルデータベースのみに焦点を当ててみても、ベンダやバージョンによって発行するSQL文を変えなければなりません。 ファイルに永続的なデータを保存していて、その保存先がデータベースに変更されたときのことを想像してください。 ビジネスロジック（業務ロジック）の中にデータアクセスにまつわるコードを書いている場合、保存先の変更が容易ではありません（同様のことが、データベ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソースでわかるSixapart転落の歴史 - メガマウスの日記、自壊あるいは無差別テロに至る道筋
大規模環境でMySQLのGTIDを適用して得られた教訓 | Yakst
MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋
Cloud Native時代のデータベース
MVCCとInnoDBでの実装について - shallowな暮らし
MySQLのレプリケーション手法の違い | Yakst
主要データベースの増え続けるdisk容量の対応事例
InnoDBのREPEATABLE READにおけるLocking Readについての注意点
Go でトランザクションをフルスクラッチで実装した - kawasin73のブログ
Googleの巨大分散データストアBigtableとDatastoreを理解する
Re: MySQL最適化のミニtips - 日向夏特殊応援部隊
MySQLのInnoDBでのデッドロック - mixi engineer blog
そんなトランザクションマネージャで大丈夫か？
MySQL/Postgres におけるトランザクション分離レベルと発生するアノマリーを整理する
Song of Cloud: 送金のトランザクション処理パターン
ウォレットアプリKyashの先 〜 Kyash Directのアーキテクチャ
データベース負荷テストツールまとめ(1) - SH2の日記
MySQLのトランザクション制御がキモい話 - なからなLife
クラウド時代の分散データベースを支える技術の応用と進歩 - kuenishi's blog
ソシャゲサーバー開発するとき始めに考慮しておかないと死ぬポイント備忘録
yrmcds 0.9.0 リリース - Cybozu Inside Out | サイボウズエンジニアのブログ