SREチームの @kazeburo です。2016年4月23日(土曜日)に発売される WEB+DB PRESS Vol.92より、メルカリSREチームメンバーによる連載が開始されます。 gihyo.jp 連載1回目は @kazeburo が書かせていただきました。 連載タイトルは「大規模インフラ運用最前線 〜 増え続けるデータをどう処理し、活用するか」となります。ユーザからの大量のリクエストを受ける大規模Webサービスでは、そのレスポンスを構築する過程で膨大な量のデータを生み出し、処理しています。メルカリも例外ではなくサービスが急成長する中で増え続けるデータをどのように扱い、常にパフォーマンスよくリクエストに応えるかが常に課題となっています。さらに今では、大量のデータを分析したり、機械学習に活用することで新しい価値を生み出すことがWebサービスの発展に欠かせなくなってきています。 連載の1
先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く