古庄親方のコラム「RDBの拡張：レプリケーション」

私が鈴与シンワートで編集支援している古庄親方が連載しているコラムの最新号が掲載されました。

「RDBの拡張：レプリケーション」

興味がある方はお読みください。
###
みなさん、こんにちは。エンジニアの古庄道明です。
今回は「RDBのまま、重たい状況をどう打開するか」「大きくなってきたシステムで、RDBのまま、どうやってRDBをより拡張していくか」について、言及をしていきたいと思います。

RDBは、基本的には「一貫性と可用性を選択した結果として、分断耐性がない」設計になります。
そのため、本質的には「スケールアップ」が唯一の規模拡大の方向なのですが、スケールアップは比較的容易に限界がきてしまう、という問題があります。
しかし、運用の仕方によっては、RDBも「ある程度の」分断耐性を持たせることができます。

さて。
ゲーム業務問わず、Webアプリケーションを解析してみるとわかるのですが。
サイトの作りと構成にもよりますが、DBに対するwrite系動作(insert/update/delete)と比較して、read系動作(select)のほうが「多い」ケースが圧倒的に多数である、という事実があります。
仮に、writeとreadの比率を「1:4」である、と仮定します(これよりもreadに傾くサイト、も、少なからずありますが、一端仮の数値です)。

この場合「レプリケーション」という方法を使うことで、ある程度「１台のサーバでは難しい分量の処理を、複数台サーバを使ってこなす」事ができるようになります。
レプリケーションは「複製」と和訳される事があり、本来的な意味としては「同じ計算機を複数台横に並べることで性能の向上を目指す」といったところになります。
DBの場合、細かく言います「データレプリケーション」と呼ばれるもののひとつ、になります。

（この続きは以下をご覧ください）
https://s-port.shinwart.com/tech-column/game07/

追伸：こんな文章を書く、私はどんな生活をしているかと言うと、、、以下のFacebookアカウントを見てください。

https://www.facebook.com/tadashi.yoshimasa

※面識のない人からのお友達申請は原則NGです。お友達申請されるときはメッセージもお願いします。わりと情報公開しているので、フォローするだけで結構見えます。

Facebookアカウント＋とるに足らない情報を以下のTwitterアカウントで垂れ流しています。宜しければFollow下さい。

https://twitter.com/_yoshimasa

また私の近況は「吉政忠志」で検索されると大よそみえてきます。