View
170
Download
1
Category
Tags:
Preview:
DESCRIPTION
これみるDBの開発で利用したテクノロジーの紹介 第一回目はクラウド、Google App Engine、
Citation preview
これみるDB開発記
テクノロジー解説
これみるDBのテクノロジ
これみるDBでは技術の習得がもう一つの目的です。そのため実務で役立つ、以下のキーワードに沿ったテクノロジーを選定しています。
● クラウド● NO-SQL(+キャッシュ)● モバイル(Jquery×Boostrap)● WEB-API(Json)● Java最新フレームワーク
各テクノロジーを複数回に分けて解説しま
す。
第1回 クラウド×NO-SQL(+キャッシュ)
第2回 モバイル(Jquery×Boostrap)第3回 WEB-API(Json)第4回 Java最新フレームワーク
第1章 クラウドおさらい
クラウド
これみるDBの基盤はGoogle AppEngine(以降GAE)です。
クラウドおさらい現在あまたのクラウドサービスがある中で、世界的に名前が知られていて、エンタープライズでの実績を積み上げているのは以下の3社
Google AppEngine(GOOGLE)Amazon Web Service(AMAZON)
AZURE(Microsoft)
クラウド
また規模は小さいがスタートアップ企業で注目されているのは以下の2社 私の目についたもの
Heroku(実はAWSの上でサービス提供している)
さくらクラウド
クラウド
そもそもクラウドの定義はいろいろありますがもともとはIaaS(インフラアズアサービス)、PaaS(プラットホームアズアサービス)の登場以降バズワードとして流行った言葉。
今後クラウド=PaaSとして使いますが、定義は以下
・ハードとネットワーク・アプリケーションサーバとDBサーバー
を提供してくれてかつ・利用料に応じての課金・簡単なスケールアウトを用意してくれるサービスのこと
クラウド
クラウドの整理
出展
http://itpro.nikkeibp.co.jp/article/Keyword/20110216/357282/
クラウド
クラウドのメリット(一言で言うと)・アプリケーションの開発に専念できる ○ハードのEOSLがない
(ただし、PaaSの環境変化はあるはず。
たとえばJava基盤のバージョンアップとか)
○基盤費用考えずに使った分だけ課金
(基盤費用だけで言えば自前より安い) ○スケーラブルとか考えなくて良い
(動的でスケーラブルな基盤がクラウドの特徴) ○サーバー監視もいらない
○ハード障害を考えなくて良い
クラウド
クラウドのデメリット(二言で言うと) ・各環境独自の制約がある ・基盤のコントロールができない
特に後者についてGAEやAWSでは年に数回の頻度で数時間~半日程度の応答不可になる障害が発生しているその際・手も足も出ない・自分では是正も出来ないためエンタープライズ利用は顧客との握りが必要でそこがハードルが高い
クラウド
最近の各クラウド 大規模障害の原因と障害時間
ちなみに各クラウドのSLAはAWS(EC2),AZURE(インスタンス)、GAEいずれも 99.95%稼働(1年で4時間38分停止)を保障
これを守れない場合、ルールに基づき利用料一部返金。だけ
AWS GAE AZURE
2012年12月24日~25日
LB 1日2012年10月29日ルーター 半日
2012年7月26日ネット機器設定 2時間半
2012年10月22日
メモリリーク 半日2012年2月29日うるう年ロジック 半日
2012年06月29日
落雷停電に伴う電源障害
参考(2011年4月に4日間の障害) 参考(2010年2月24日 一日の障害) 参考(2011年9月9日 半日)
クラウド
各クラウドの趨勢エンタープライズ利用ではAWSが圧勝
GAE、AZUREは苦戦
各クラウドサービスを一言で言うと以下の通り
AWSはなんでもできる
(IaaSとして利用/RDB利用/No-SQLDB利用/専用線直結/他のPaaSのバックエン ドとして利用されていたりもする)
GAEは独自路線
RDBが利用出来ず、独自のNo-SQLDBを使う必要がある。
AZUREは出遅れ
当初Macrosoft製品ロックアップがあった/後発なので出遅れ
クラウド
参考※http://jp.techcrunch.com/archives/20121217forrester-report-shows-amazon-aws-reigns-supreme-with-developers-as-windows-azure-gains-momentum/
クラウド
その他、クラウドに関する読み物
http://www.atmarkit.co.jp/fjava/rensai4/devtool25/devtool25_1.htmlhttp://techtarget.itmedia.co.jp/tt/news/1204/26/news01.htmlhttp://d.hatena.ne.jp/arahk/20110608/1307517071
第2章 NO-SQL
これみるDB×クラウド
これみるDBはGAEを利用しています。
理由は・今後の潮流であるNO-SQLの学習ができる
・無料枠がある・後から知ったのですが(BigData解析ができたりしてもう一つのバズワードBigDataについてが勉強できる)
GAE NO-SQL
GAEではRDBは利用出来ず、Datastoreという列NO-SQLDBを利用する必要があります。
そもそもNO-SQLはRDBに対応する概念です。
通常のアプリケーション3層構造ではWEBは拡張できてもDBは拡張できないので、DBがボトルネックになります。
また往々にして、高性能な商業DBはハードソフトともに高価。
DBサーバー
WEBサーバー
WEBサーバー
スケールアウト可能
データの一元管理が必要なのでスケールアップしかできない(ほんとはパーティションとかあるけど)
GAE NO-SQL
またRDBの場合、データの肥大化により、検索速度の低下が発生します。
・・・・・・・
データを全件検索しないといけないので、データ量増=検索速度の低下
GAE NO-SQL
一方で、NO-SQLはRDBのリレーション機能を犠牲にしてスケーラブルで素早い検索を可能にします。例)memcached(分散メモリ)NO-SQLの一種のスケールアウト図
WEBサーバー
WEBサーバー
Memcached分散機構
GAE NO-SQLmemcachedの検索
そしてオープンソースのものが主流です。「memcached」mixiで利用。
「Apache Cassandra」 facebookで利用
パラレルに検索できるのでデータが増えても検索速度をスケールアウトできる
GAE NO-SQL
まとめると
・スケーラブル。スケーラブル。スケーラブル
・設定いらず(付随的に)
データが何億あっても大丈夫。
検索にかかる時間は同じ。ほんとです。
RDBと違いのキッティング、チューニング不要。すぐ使える。
スキーマレスなので、行ごとにテーブルレイアウト
変えても良い
GAE NO-SQL
もちろんデメリットもあります。
・SQLの標準機能がいろいろ使えない
JOIN/SUM/COUNT/UNION/(排他制御)/(部分検索)/not in/入子検索
GAE NO-SQL
・使って痛いのは。データの調査、修正を行うときにSQLが使えない。
※これは環境によってはSQLライクなものが用意されているかもしれませんが、結局JOINやNOT inなど使えません。
Datastoreからのデータ取り出し SQL
select * from TABLE WHERE A=B
package tutorial.controller.twitter;
import org.slim3.controller.Controller;import org.slim3.controller.Navigation;
public class IndexController extends Controller {
@Overridepublic Navigation run() throws Exception {
TableMeta e = TableMeta.get();List<Employee> list = Datastore.query(e) .filter(e.A.greaterEqural(B)) .sort(e.salary.asc) .asList();
requestScope("list", list); return forward("index.jsp");
}}
GAE NO-SQL
(SQLについての読み物)
詳細は以下に詳しくまとまってます。NO-SQLhttp://www.atmarkit.co.jp/flinux/rensai/noSQL/noSQL_01/01_1.html
GAE(Bigtableの詳しい内容)
http://d.hatena.ne.jp/kazunori_279/20090617/1245224939
第3章 GAE
GOOGLE APP ENGINEで無料開発でも苦労も多いよ
GAEGAEに話をもどします。
Datastore以外に関しても、GAEは独自の特徴があります。
代表的なものとして、・Socket通信不可(80番HTTP通信のみ)
・すべてのHTTPは30秒で完了させる必要がある
GAE
GAEの業務利用
制約が多いのでやめたほうがよい。
ほとんどすべてのアプリケーション、開発者はRDBを前提として
考えているので「イノベーティブ」な開発以外では使えない。
無料なので、R&Dとかお勉強とか部内ツールとかそういうのには便利。
GAE言い方を変えるとこんな場合にGAEを使う意味があります。
・スケーラブルな環境が必要(RDBを辞めてわざわざDatastoreを使う目的)
・データ量が億単位(RDBを辞めてわざわざDatastoreを使う目的)
・初期投資を抑えたい・少人数での開発(新しい技術に関して、密にコミュニケーション取りながら学習できて効率が良い)・SLAが比較的緩やか
(基盤障害があっても是正出来ないので) 例としてユーザーが大量にいる広告収入で稼ぐのBtoCサイトなど
GAE業務利用に関してその2現時点では使いづらいGAEですが、次々にサービスを増やしているので、今後の展開次第では良い物になっていくと思います。
注目は以下の機能追加・SQLサポート(GOOGE CLOUD SQL)・BigData解析機能(Bigquery api)・FullTextSerch機能
GAE NO-SQL
GAE NO-SQL環境を実装する上での
ベスト・プラクティスと呼ばれるものを紹介します。
1. でっかいテーブルを用意する
業務分析→正規化→使いやすい形に(画面に合わせでっかいテーブル)
2. Insert頑張る/Read頑張らない3. キャッシュを使う
GAE でっかいテーブルを用意する
RDBの世界では正規化が基本。
正規化の主目的は「重複なくデータを管理」する。
重複なく管理することで・更新は一回でいい。そのことによって・参照するときにデータの整合性が保証されていると安心していられる。※データが正規化されていないと、重複があるデータ全てに漏れ無く更新を使う必要があり、安心してられない。
GAE でっかいテーブルを用意する
NO-SQLの世界はリレーションが使えないので、「JOIN済みのでっかいテーブルを作る」が基本。
その時はデータ洗い出し⇛正規化⇛でっかいテーブルと設計する。一度正規化しておくことで、更新時に更新すべき対象がもれなく把握できる。
画像テーブル
GAE でっかいテーブルを用意する例
これみる映画テーブル(抜粋)
映画ID 米映画名 日本映画名 上映時間 米上映日 日上映日
上映時間 画像 画像評価 画像言語 ポスタ ポスタ評価 ポスタ言語
観客評価 評論家評価 スコア 更新日 バージョン番号
映画テーブル
映画ID 米映画名 上映時間 評論家評価 観客評価 スコア
映画ID 画像種 画像サイズ 画像言語 画像評価 画像データ
翻訳テーブル
映画ID 項目 言語 データ
正規化テーブル
でっかいテーブル
GAE でっかいテーブルを用意する
使うときはみんなででっかいテーブルを参照/更新する
GAE でっかいテーブルを用意する
注意しなくてはいけないのは、でっかすぎるテーブル。更新頻度に着目しよう
これみる映画テーブル(抜粋)
映画ID 米映画名 日本映画名 上映時間 米上映日 日上映日
上映時間 画像 画像評価 画像言語 ポスタ ポスタ評価 ポスタ言語
観客評価 評論家評価 like件数 スコア 更新日 バージョン番号
でっかいテーブル
[コメント配列 ] [評論配列] like件数
更新頻度が違うものを入れてはダメ
GAE でっかいテーブルを用意する
素直にテーブルを分けて、キーコード指定で別々に呼び出しましょう更新頻度が高いものをでっかいテーブルに入れるとロック待ちが発生し、レスポンス低下になります。
これみる映画テーブル(抜粋)
映画ID 米映画名 日本映画名 上映時間 米上映日 日上映日
上映時間 画像 画像評価 画像言語 ポスタ ポスタ評価 ポスタ言語
観客評価 評論家評価 like件数 スコア 更新日 バージョン番号
でっかいテーブル
Likeテーブル
映画ID Like件数
コメントテーブル
映画ID コメント
評論テーブル
映画ID 評論
GAE Insertがんばる
・count()が利用できないので、レコード件数がわかりません。Insertで頑張ります。
毎回カウントするのではなく、カウントテーブルを別に用意して、更新時に件数をインクリメントするのが正解。例えばコメント件数を画面に出したいときは、コメントが投稿されたときに、件数テーブルをインクリメント。
※しかもDatastoreからデータをreadすると1件当たりで課金に効いてきます。(レコードが1万件あって、それをjavaでカウントすると、Dataread1万になり、いきなり無料枠Over)
GAE Insertがんばる
PVカウンタなど更新が激しいものは、1レコードに対してインクリメントにするとア、ロック解除待ちが発生します。そんな時はシャーディング
カウンタ A カウンタ B カウンタ C カウンタ D
リードの時は全部読んで合算(リード件数シャードが4の場合 4件)
書き込みの時にはどれか一つをインクリメント(ロックが 1/4)
同じ項目についてのカウンタを複数作成する(シャードを作成する)
GAE キャッシュを使う
キャッシュを使う基本3原則です。1.キャッシュを探し、あればキャッシュを使う
2.なければdbからとってきてキャシュに詰める
3.有効期限は設定する。
DBアクセスはコストがかかるので、極力キャッシュを使います。GAEではmemcachedに似たmemcacheが用意されています。
GAE キャッシュを使う
キャッシュを利用する際は、キャッシュの更新忘れに注意!データが修正されたり、追加されるときはキャッシュを削除する。
わざわざ消すの面倒な場合、キャッシュの有効期限を設定して、自動的に消されるようにすれば、OK。キャッシュの有効期限は重要です。
GAE キャッシュを使う
キャッシュはどんなアプリでも有効な手段です。・参照/更新頻度が高い
・DBやファイルアクセスが発生する
といった場合キャッシュ化でレスポンス改善が可能です。
たとえば、画面参照のたびにログイン情報を逐一DB参照する場合などはキャッシュ化することで性能改善が図れると思われます。
GAE
GAE説明(OFFICIAL 超わかりやすい)
https://developers.google.com/appengine/?hl=ja
作ればわかるGoogle APP Engine
Recommended