リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得ら
リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得られるということなのだと思うので、可能であればMVCCを採用したいのですが、あまり初学者向けの実装例も見当たらず、どうしたものかと悩んでおります。 SS2PL/S2PLとMVCCの実装の難易度・工数はどの程度違うものなのでしょうか？ また、初めてリレーショナルデータベースシステムを開発する者
データ変更を伴うバッチ処理を書く時に考慮していること - shallowな暮らし
こんにちは、id:shallow1729です。最近はインフラ寄りなお仕事をよくやっていますがこれまでにいくつかデータ移行やデータ基盤構築などのバッチ処理のお仕事をしてきました。以前にも一度そういった経験を元に記事を書いたのですが、MySQLやシステムに関する知識が以前よりも増えた今もう一度書き直したいなと思いました。 なので今回はバッチ処理を書く時のテクニック2022版という感じです。今の仕事の関係でMySQLやrailsを前提にしている話が多いですが、おそらく他のデータベースを使っている人にも役に立つ話が多いのではないかと思います。ただ、今回の記事は経験に基づくものが多く、あまりよくないアイデアもあるかもしれません。改善点や間違いなどあればご指摘ください。 冪等性を持つように 冪等性とは端的に言えばある操作を複数回実行しても一回しか実行しなかった時と同じ結果になる性質の事です。長時間かか
【連載 第1回】freeeカード Unlimited の開発の道のり - freee Developers Hub
金融チームでエンジニアをしているimamuraです。freeeカード Unlimited のβ版の提供が今年（2021年）の秋から開始されます。開発自体は半年以上かかっており、そこでの開発の裏側について連載を行います！ 連載は以下のようになります。 ※ 日程、タイトルは一部変更になる可能性があります 日程 タイトル 執筆者 9/9 freeeカード Unlimited の開発の道のり imamura 9/16 freeeカード Unlimited での非同期通信の設計と実装 imamura 9/23 EMから再度エンジニアに戻り新規プロダクト開発に挑戦して学んだこと tabachain 9/30 freeeカード Unlimitedでのクリーンアーキテクチャ実践 id:lvmingbei 10/7 新卒一年目からの新規プロダクト開発 sekky 10/14 新規プロダクト＆新造チーム＆フル
決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
On the Performance of User-Mode Threads and Coroutines – Inside.java
Discussions of coroutines and user-mode threads — like Project Loom’s virtual threads or Go’s goroutines — frequently turn to the subject of performance. The question I’ll try answering here is, how do user-mode threads offer better application performance than OS threads? One common assumption is that this has to do with task-switching costs, and that the performance benefit of user-mode threads
XTDB - the open database with temporal graph queries
Immutable Records XTDB contains a perfect, immutable record of every fact your system has ever known. See the entire history of your business, everywhere. Learn More Temporal Query Immutable records are incomplete without time-traveling queries. XTDB allows you to query the entire timeline. Make retroactive corrections, simplify data migrations, and get clarity on out-of-order events. Learn More R
プログラミング英語教本 | グローバリゼーションデザイン研究所
目次 はじめに 【第1部 ドキュメント・タイプ別解説】 第1章 ソースコード 1-1. ソースコードで使われる英語 1-2. サンプルと解説 1-3. ソースコード英語の特徴（1） − 名前 1-4. ソースコード英語の特徴（2） − コメント 1-5. ソースコード英語の特徴（3） − コミット・メッセージ 1-6. 例題 第2章 APIリファレンス 2-1. サンプルと解説 2-2. APIリファレンス英語の特徴 2-3. 例題 第3章 マニュアル／ヘルプ 3-1.サンプルと解説 3-2. マニュアル／ヘルプ英語の特徴 3-3. 使用許諾契約英語の特徴 3-4. 例題 第4章 ユーザー・インターフェイス（UI） 4-1. サンプルと解説 4-2. UI英語の特徴 4-3. 例題 【第2部 プログラミング必須英単語】 第5章 ベーシック300 第6章 アドバンスト300 第7章 その他の
ディープラーニングで翻訳プログラムを0から作った人がその仕組みを複雑な数式ではなく図で解説するとこうなる - GIGAZINE
テクノロジーが発達することで、専門家でなくてもニューラルネットワークを使って翻訳プログラムを作ることが可能になりました。とは言っても、全く知識がない人にその仕組みを理解するのは難しいもの。そこでライターのSamuel Lynn-Evansさんが自分で情報を調べつつ0から翻訳プログラムを作成し、その時に理解した仕組みを数式を使わずに説明しています。 Found in translation: Building a language translator from scratch with deep learning https://blog.floydhub.com/language-translator/ 言語は非常に複雑で、これまで機械翻訳を行うには何人もの専門家が必要でした。しかし、人工知能(AI)の発達により、もはや専門家でなくても機械翻訳を行うことが可能になりました。これまで専門家
Pythonでブロックチェーンを実装して採掘までやってみたので解説する - paiza times
Photo by Stock Catalog 秋山です。 皆さんは暗号通貨で遊んでいますか？ エンジニアの中には、ブロックチェーンなど暗号通貨で使われている技術に興味がある…という人も多いのではないでしょうか。最近は、ブロックチェーンを活用した新しいモノもどんどん増えていますね。 というわけで今回は、ブロックチェーンや採掘（≒Proof of Work）について、Pythonでコードを書きながら説明してみたいと思います。 ■ブロックチェーンをPythonで実装してみる 最も単純なブロックチェーンの場合、ブロック単位のデータにハッシュ値があり、そのハッシュ値は一つ前のブロックのハッシュ値を含んで計算されています。そのため、すべてのデータはチェーン上に繋がって前後関係のもとにある…という状態です。 ハッシュ値が何かわからない人はググったりして調べていただければと思いますが（ハッシュ値（ダイジェ
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
SQLトランザクション分離 実践ガイド | POSTD
(注：2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注：2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、本来、理解しておくべき基本的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ
Cicada：Dependably Fast Multi-Core In-Memory Transactions - 急がば回れ、選ぶなら近道
Cicada: Dependably Fast Multi-Core In-Memory Transactions https://www.cs.cmu.edu/~hl/papers/cicada-sigmod2017.pdf SIGMOD2017で発表されている。現状の分散OLTPのアーキテクチャをうまくまとめて、欠点をうまくカバーアップし、言って見れば次世代MVCCの一つの形を提示している。その上で、現在世界最高のパフォーマンスを叩き出している。現時点で世界最速DB（ただし自称）。 現状の分散OLTPは大きな流れは、SILO/Foedus/MOCC/等のOCC系、すなわち2PLをベースにした実装で理論上はmonoversionでのserializableの実現を行っている方式と、Hekaton/HyPer/Bohm/ERMIAといったMVCC系、すなわちMVTOの派生をベースにしてmu
トランザクション分離レベルの古典的論文 A Critique of ANSI SQL Isolation Levels を読む - Hatena Developer Blog
こんにちは、 id:alpicola です。今年4月に新卒入社してアプリケーションエンジニアとして働いています。 ウェブアプリケーションはその性質上、データベースに対して同時に大量の問い合わせを行います。そうした中でデータベースが個々の問い合わせを処理していくときに起こっていることは何か、どういう順序で処理が行われるのか、というのは興味深い話題かと思います。例えばデータベースに対して行った更新処理の結果が、更新を行ったクライアント以外のクライアントからも「見える」ようになるのはいつでしょうか。入社間もない頃、先輩エンジニア達にそうした疑問をぶつけてみたところ、「トランザクション分離レベル」というキーワードと、この分野の古典的な論文 A Critique of ANSI SQL Isolation Levels を教えてもらい、輪読会を社内で開催しました。この記事ではこの輪読会の模様をレポー
同時実行制御とSQLite3 - Qiita
Intro 同時実行制御とは, 共有リソースにアクセスする複数のトランザクションを, いかに並列処理しつつ競合によるデータ破壊を回避するかを扱う分野である. 昨今のアプリケーションではクライアントが複数いることは珍しくない. 同時アクセスを許容せず, クライアントからの要求を直列的に処理できれば同時実行制御の課題は解決されるが, アプリケーションのレスポンスは極端に低下し使い物にならない. パフォーマンスの低下を抑えるためにトランザクションを並列化し, かつリソースの整合性を保証しなければならないため, 同時実行制御を考える必要が出てくる. Conflict 並列処理されるトランザクションの競合を制御しなかった場合の問題は主に4種類ある. 基本的にデータの一貫性は保証されない. Dirty Read (w-r) コミットされていないデータを別のトランザクションから参照できてしまう問題. ト
Schedule - CMU 15-721 :: Advanced Database Systems (Spring 2017)
Course Introduction and History of Database Systems M. Stonebraker, et al., What Goes Around Comes Around, in Readings in Database Systems, 4th Edition, 2006 (Optional) A. Pavlo, et al., What's New with NewSQL?, in SIGMOD Record (vol. 45, iss. 2), 2016 (Optional) In-Memory Databases H. Garcia-Molina, et al., Main Memory Database Systems: An Overview, in IEEE Trans. on Knowl. and Data Eng., 1992 S.
RDBMSが強すぎる件 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
以前、「RDBMSを採用すると、無料で外部キー制約とかチェック制約とかトランザクションが付いてきてオトク！！！」という発言をしたことがあって、その考えは今もあまり変わっていない。 RDBMSは単なる便利な箱じゃなくて、データの整合性を守るための仕組みがたくさん備わっている。もちろん、これらの仕組みは「タダ」で使えるわけではなく、データモデリングを学んだり、データ構造を学んだりという「投資」の結果うまく使えるようになるものだけれど。 ところで問題（？）は、RDBMSは強すぎる、ということです。 たとえば、トランザクションの話。「本質的にはトランザクション整合性である必要がなく、遅延してあとから整合性が取れてればよいような処理（つまり、結果整合性でよいような処理）」というのは、意外と多い。 多くの開発の現場では、トランザクション整合性が必要とされるか結果整合性でよいのかについてあまり考えず、「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDBMS in Action
カーネギーメロンのデータベースの講義の資料・映像 - ablog
データベース13 - トランザクションと障害回復
データベース12 - トランザクションと同時実行制御
