Treasure Data Service はどのようなケースに向いているか？
本記事は移転しました。新サイトにリダイレクトします。
*トレジャーデータはデータ収集、保存、分析のためのエンドツーエンドでサポートされたクラウドサービスです。
前回は Treasure Data Service が生データストレージにあげられているという前提（つまりTreasure Data Service を利用している前提）で，それとBIなどのフロントエンドをシームレスに繋ぐための中間データベースはどれが良いか，という観点でお話しました。そして TQAがどのようなものかを理解し，Redshiftとは立つレイヤーが違うことをわかって頂く事が目的でした。
Treasure Data Service はどのようなケースに向いているか？
ここでは視点を変えて，現在保持しているデータの性質を考慮した上で，どのサービス（データベース）を活用したらよいかを考えます。
上図は現在それぞれの企業が持っているデータに対して，
という3つを考慮し，どのデータベース（プラットフォーム）を利用すべきかをケース別に図示したものです。
データ規模が小さい場合は従来のRDBMSやNoSQLを採用したほうが適切です。後はデータベースをクラウドに置けるか（RDS, mongolab はともにクラウド上のホスティングサービスです）を考えるだけです。クラウドホスティングサービスを使えば運用コストは減りますが，データ量に応じてそれなりの額を払う必要があります。
データ規模が大きい場合は，それをローカル環境で運用する場合は，オンプレ商品またはHadoopサービスをローカルで運用する必要があり，これには多大な構築コストと運用費コストがかかります。一方でクラウド上で運用するとするなら，Treasure Data Service か Redshift ということになります。
ただRedshiftのみを使用する際はログを集める時点で集計軸が定まっていること，データ増加スピードが想定の範囲内である事が前提となります。
もちろん前回の内容で主張したように両者は排他的で無く， ベースのプラットフォームとして Treasure Data Serviceを，中間データサーバーとして Redshift となるハイブリッドアーキテクチャを構築できる」という共存ができます。
上図は中間データベースとしての Treasure Cloud Service と Redshift のハイブリッド構成です。
またスキーマがどれくらいの頻度で変更されるのかも，大きなポイントです。Redshiftは集計軸の定まった定型分析処理に向いていますが，試行錯誤の段階で集計軸が変わってしまう可能性のある者は，Treasure Data Service の TQA を活用していくことになります。
トレジャーデータに関するお問い合わせは support@treasure-data.com まで。ご意見ご感想などでも構いません，ご連絡お待ちしております。
