大規模解析サービスのためのデータベース構成 ～BigTable／BigQueryの弱点をどう補うか？
大規模なデータを扱う解析サービスにおいて、データベースの性質の理解や選定、配置、活用方法などはクリティカルな問題であり、サービスとして大きく差をつくる要素にもなります。本稿では考慮すべきデータベースの性質の違いから始め、解析サービスにおける考え方や活用のテクニック、構成方法について紹介したいと思います。 解析サービスにおける重要な2つの仕事 ここでは大量のデータを収集する解析サービスの仕事の中でも、重要な2つの仕事についてフォーカスして話を進めていこうと思います。 一つ目は、データを単に収集し、スケーラビリティの高いデータベース（または分散ファイルシステム）に格納し、あとで（管理画面から、もしくはスケジュールバッチなどで）Aggregateするものです。こちらは解析サービスと言われるサービスの多くが行なっている仕事と考えられます。 二つ目は、データによって振る舞いを変える、リアクションする
Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita
DIを使わない状態ではUserRepositoryというインターフェースが定義されているのにもかかわらず、UserServiceはUserRepositoryImplの参照も持っていました。 これではせっかくインターフェースを分離した意味がありません。 UserServiceがUserRepositoryインターフェースだけを参照(依存)するようにすれば、具体的な実装であるUserRepositoryImplの変更に影響されることはありません。 この問題を解決するのがDIの目的です。 それではDIのインジェクタを加えて、上記のクラス図を修正しましょう。 謎のインジェクタの登場によりUserServiceからUserRepositoryImplへの参照がなくなりました。 おそらくインジェクタは何らかの手段でサービスであるUserRepositoryImpl(Dependency)をクライアン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【旧版】MongoDB入門 (全14回) - プログラミングならドットインストール
