「MongoDB 4.0」正式リリース。マルチドキュメントに対するACIDトランザクションをサポート
MongoDBはオープンソースとして開発されているドキュメント指向データベース、いわゆるNoSQLデータベースのひとつです。データの形式として柔軟にデータを格納できるJSONライクな形式を採用し、1つのJSONライクな形式のデータを1つのドキュメントとして保存します。 MongoDBの開発元であるMongoDB社は6月27日、ニューヨークで開催された同社のイベント「MongoDB World'18」において、最新のMongoDBとなる「MongoDB 4.0」の正式リリースを発表しました。 MongoDB 4.0の最大の特徴は、マルチドキュメントの操作に対してACIDトランザクションがサポートされたことです。 マルチドキュメントのトランザクションでは、「start_transaction」によりトランザクションの開始を宣言したあとで、複数のドキュメントに対する操作を行い、そのいずれかが失敗
ブロックチェーンを巡る動向について | NTT Communications Developer Portal
ここ半年くらいで一気に注目が集まっている技術ワードがブロックチェーンです。BitCoinで使われている技術として知っている人も多いかと思いますが、ブロックチェーンを限られたネットワーク内で利用する方法が取り上げられています。 ここ最近の動きやブロックチェーン実装についてまとめてみました。 オープンソースによるブロックチェーン実装 オープンソースでブロックチェーンを体感する最も早い方法はBitCoinを使うことでしょう。現在、それ以外でも実装がはじまっています。Linux Foundation Unites Industry Leaders to Advance Blockchain TechnologyとしてIBM、アクセンチュア、シスコなどを集めて実装を開始しています。このプロジェクトはLinux Foundationの監督下にあります。また、R3コンソーシアムもオープンソースのブロック
分散ロックという名の過ち - Software Transactional Memo
 TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて本当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
Ether を送金した人だけコンテンツを閲覧できる Ðapp を書いた - 詩と創作・思索のひろば
Ethereum はブロックチェーン上でアプリケーションを動かせる（スマートコントラクト）ってので興味を惹かれて、どんなことができるのか調べてたんだけど、感じを掴むために一つ書いてみた。 やりたいことは、ウェブページに送金ボタンがあって、そこから特定のアドレスに Ether を送金し、送金が確認されたら秘密のコンテンツをページ上に表示する、てなもの。送金の確認はスマートコントラクトで行えるが、秘密の情報をブロックチェーン上に記録するわけにはいかないのでこれはウェブサーバに秘匿することになる。とすると、ウェブサーバに私はこの Ethereum アドレスです、とセキュアに伝えてやる必要がある。後で書くけど、あまりいい解法ではない。 知識ゼロの状態から分からないことを潰しつつなんとか動くところまでこれたので、ウェブアプリケーション開発者がつまづいたところをメモっとく。 デモ MetaMask W
コインチェックから流出した580億円相当のNEM、匿名暗号通貨「DASH」で資金洗浄される可能性 | 匿名ブログ
引用: http://d.hatena.ne.jp/Kango/20180126/1517012654 そのアドレス、また上記の関連するアドレスに関する取引記録を監視している中で私が気になった取引記録が、あるメッセージを含んだ2月2日の犯人のアドレスへの送金記録でした。 犯人への入金1 ID: dd50841ba593359383475b056ffa0c6547799a8b21bc4e0d869caec5697332ad こんにちは。すみませんお詫びがあります。。匿名ネットワークで取引所を経由している最中に、メッセージを暗号化して送ってしまい、着金に送れが発生してしまいました。少し時間がかかるかもしれません。。ただ洗浄のルートは確立できましたので、次回からはスムーズに行えるかと思います。取り急ぎ、DASHの送金確認をするために、こちらのアドレス(Xr6maJSptxgD6NRBRqnv4Y
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として扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
暗号通貨のスケーラビリティについて考える
こちらはブロックチェーンアドベントカレンダー12日目の記事です。 https://qiita.com/advent-calendar/2017/blockchain 今年は価格の暴騰以外にも色々と話題を事欠かないBitcoinですが、その中でもSegwit、Segwit2Xは記憶に新しいのではないでしょうか。 Bitcoinにかぎらず、多くの暗号通貨はそのスケーラビリティに上限があり、それらに対して幾つかの解決策を見出そうとしているのが現状となります。今回はそのスケーラビリティに対する現状について、特にパブリックなチェーンに対するものを中心にまとめてみようと思います。 そもそもBlockchainのスケーラビリティとはVISAカードなどが対処しているトランザクションは秒間4000~6000と言われていますが、Blockchainはその仕組み上、マイナー（PoSではバリデーター）の数が増えて
主要データベースの増え続けるdisk容量の対応事例
こんにちは、SRE の @masartzです。 今回は最近取り組んだ、メルカリの主要データベースの容量削減のお話をしようと思います。 TL;DR 主要データベースの容量を20%以上削減しました どういう状況だったか？ 何をしたか？ メルカリでは2017年11月現在、出品数は1日100万件を超えています。 なので、単純に日々多くのデータが増えていっています。 そのためデータベースのスケーリングは常に検討し、取り組まなければならない課題です。 今回扱ったデータベースはいくつかあるデータベースの中で商品テーブルを持つ、メルカリの主要データベースになります。 増え続けるデータに対応するための、テーブル分割を変則的な形で対応したのでその過程を紹介します。 前提：データベース分割方法 メルカリのデータベースには 会員情報や商品情報など、基本要素となるデータから、通知やお知らせメッセージなど付加的な機能
DDDにおいてリポジトリとDBのトランザクションは切り離せないのか? - pospomeのプログラミング日記
DDDではリポジトリに対してDIPを利用し、インターフェースと実装を切り離す傾向にある。 これはいわゆる「抽象に依存せよ」ってやつなので、 DDDというよりは既存のプログラミングテクニックになる。 で、これを実現するためにリポジトリを以下のようにインターフェースで実装する。 コードはTypeScriptです。 interface UserRepo { insert(user: User, master: DbMasterConnection): Promise<User>; findByName(name: string, con: DbConnection): Promise<User>; findById(id: number, con: DbConnection): Promise<User>; }リポジトリの実装自体はインフラレイヤに置く。 「データを取得する」ということなので、個
[システム間連携]接続方向を逆転させるとうまくいく - Qiita
システムAの更新内容を、別のサーバにあるシステムBにも反映させるためにデータ送る、というケースを考えます。 主流はWeb APIかMOMを使う方法かと思います。(俯瞰的な話は、20日目のこざけさんが書いてくれる、はず) しかし、A,B間で同時に一貫性を保たなくても良いケースは、企業間システム連携ではよくあります。 CAP定理でいうところの可用性＋分断耐性をとりにいくパターンです。が、最大数秒程度で結果整合性は保ちにいきます。 システム間の接続 非同期ながら、ほぼリアルタイムでデータを反映していくので、応答性の高い接続手段が求められます。だが中間経路をHTTPでないプロトコルを通すハードルが高かったり、ファイヤーウォールなどで長時間接続を切られたりする問題があるので、私はよくWebSocketを使います。 だいたいの構成は以下のようになります。同期エージェント間をWebSocketでつなぎ、
![[システム間連携]接続方向を逆転させるとうまくいく - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/9e6b26bad6ab3b6b40219c713c4e519da8866144/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUUzJTgyJUI3JUUzJTgyJUI5JUUzJTgzJTg2JUUzJTgzJUEwJUU5JTk2JTkzJUU5JTgwJUEzJUU2JTkwJUJBJTVEJUU2JThFJUE1JUU3JUI2JTlBJUU2JTk2JUI5JUU1JTkwJTkxJUUzJTgyJTkyJUU5JTgwJTg2JUU4JUJCJUEyJUUzJTgxJTk1JUUzJTgxJTlCJUUzJTgyJThCJUUzJTgxJUE4JUUzJTgxJTg2JUUzJTgxJUJFJUUzJTgxJThGJUUzJTgxJTg0JUUzJTgxJThGJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz02OWE5YmIzM2YxNTIyZTQ3YmNiYTczN2E1NmZlZTlhMQ%26mark-x%3D120%26mark-y%3D96%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDBrYXdhc2ltYSZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ODAyNDk1Y2IwNTFhMTYzMTFhM2NkYWE5OWU2NmJlYzQ%26blend-x%3D120%26blend-y%3D500%26blend-mode%3Dnormal%26s%3D8943a150f1c778f23b4d782e0d1d1e40)
Googleアナリティクスの仕様に関する豆知識 - Qiita
はじめに Google Analytics Advent Calender 4日目の記事です この記事では、Googleアナリティクスの公式ヘルプページに書かれているにもかかわらず知らない人が多い豆知識を3つ解説します。 Googleアナリティクスは多通貨にデフォルトで対応している 多通貨で、世界中をターゲットにECサイトを運用しているサイトにおける豆知識です。 購入金額: 10,000円のトランザクション 購入金額: 900.50$のトランザクション 購入金額: 980元のトランザクション が1日で発生した時、この日の売上金額はどのように表示されるの？と疑問に思う方もいると思います。 自分も先月、このような状況が発生して、どうすればいいのか悩みました。JavaScriptで為替レートを取得してきて、単一通貨に変換して送信しなきゃいけない？本気で？といった感じです。 答えは、 Google
世界の何処かで MySQL（InnoDB）の REPEATABLE READ に嵌る人を1人でも減らすために - KAYAC engineers' blog
tech.kayac.com Advent Calendar 2015 8日目担当の @m0t0k1ch1 です。 今年は MySQL さんにいろいろ泣かされた1年でした。特に、あの夏、幾夜をともにした実行計画のゆらぎは一生忘れな(ry さて。。。今回は、そんな中でも誰もが一度は嵌るであろう（？）MySQL（InnoDB）の REPEATABLE READ の嵌りどころについて自分なりにまとめてみようと思います。 この記事が目指すこと MySQL の各トランザクション分離レベルの嵌りどころについては、現状でも種々のブログ記事などでまとめられており、そんなに真新しい話ではないと思います。が、過去の自分のように、嵌ったことがない人間からすると、 話としてはなんとなく理解できる が、抽象的でいまいち身につかない というのが現実でした。嵌りどころに実際に嵌った今読み返してみると、「あーーー、、、そ
【ScalaMatsuriセッション当選御礼】ドワンゴ秘伝のトランザクションモナドを解説！ - Qiita
このたびはScalaMatsuriのセッションに投票していただき、ありがとうございました。 今回はそのScalaMatsuriのセッションで発表予定の内容の一つであるドワンゴ秘蔵のトランザクションモナドについて解説したいと思います。 このトランザクションモナドは基本的な機能だけなら30行ほどの短いコードで記述できてしまうのですが、なかなか説明が難しい代物でして、 ScalaMatsuriの自分の発表時間内に聴衆のみなさんに理解していただくのは難しいだろうということで、先に解説記事を書くことにしました。 このトランザクションモナドは作者の名前から通称Fujitaskと呼ばれているのですが、作者の方は周りから「天才」と言われてまして、彼は常人が思いつかないようなコードを書かれるんですね。 Fujitaskは短いながらも、モナドと、サブタイピング(変位指定)と、アドホックポリモーフィズムの三つの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソーシャルゲーム案件におけるDB分割のPHP実装
TechCrunch
https://engineering.mercari.com/entry/2017/12/18/deadlock
トランザクションの設計と進化