エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
Lazyレプリケーションはpush型とpull型のどちらが良いのか - sdyuki-devel
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
Lazyレプリケーションはpush型とpull型のどちらが良いのか - sdyuki-devel
更新ログをマスタからスレーブに送ることでデータをレプリケーションする、いわゆるログシッピングを、... 更新ログをマスタからスレーブに送ることでデータをレプリケーションする、いわゆるログシッピングを、分散データストアに実装する方法について。 ログシッピングは、操作を同時に複数箇所に送信するレプリケーションと比べると、次のような実装上の利点がある: オリジナルに対する変更とレプリカに対する変更の適用順序が一致する オリジナルとレプリカの整合性を維持しやすくなる。設計が簡単になるので嬉しい。 ダブってレプリケーションされない at-most-once。どこまで更新ログを受け取ったかをスレーブ側で管理している前提。 CPUにやさしい バースト的に更新クエリが発生した時でも、レプリケーションクエリの数は(激しくは)増えない。その代わりログに溜まって一度に送信される。バッチ処理はCPUにやさしく、スループットが高い。 一方、更新ログを管理しなければならない欠点があるが、ストレージのデータ構造自体がログ