キャパシティプランニング 発表資料 | 外道父の匠
久々に社内向けに勉強会を行いました。 既に稼働しているサービスの、サーバの台数調整の考え方についてです。半分くらいは口頭で話したので資料だけでは物足りないかと思います。が、せっかくなので公開しておきます。 内容はインフラ管理についてですが、対象者はどちらかというとアプリケーションエンジニアとして作成・発表しました。資料と、ブログ用に補足を書いていきます。 作りやすくて頼りになるので、 もう、赤さんはテンプレでいいかな、とも思い始めました。 補足 勉強会をするに至った理由 いわゆるインフラエンジニアが、サーバの負荷状態を観測したり、台数を判断できるのはアタリマエですが、サービスを作成しているアプリケーションエンジニアにとってはアタリマエではなかったりします。 理想としては、WEBエンジニアたるもの、自宅サーバやレンタルサーバを１つは持っていて 総合的な知識を得ようとする環境・努力をして欲しい
第1回 大規模データではRDBMSのどこがボトルネックになるのか？ | gihyo.jp
RDBMSはオワコン？ 「右を向いても左を向いても“ビッグデータ”というキーワードが闊歩する時代に、いまさらRDBMSの話題？」 本連載のタイトルを見てそう思われたかもしれません。 「ディスクベースのRDBMSはオワコン、これからは○○（お好きなアーキテクチャを入れてください）の時代だ！」 とおっしゃる方もいるかと思います。 しかし、むしろ多くの企業がビッグデータに注目しているおかげで、RDBMS側でも大規模データを取り扱うニーズが増えています。 大規模データを取り扱う時にボトルネックとなる5つのポイント 数百ギガバイトといったレベルのRDBMSであれば、現場のエンジニアの方にとってはあたりまえの世界でしょう。しかし、テラバイトを大きく超えたデータを扱う場合には、ボトルネックの傾向が変化するのはご存じでしょうか。 次の図は、RDBMSにまつわるボトルネックを示したものです。 図1 大規
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
