これみるDB開発記

テクノロジー解説

これみるDBのテクノロジ

これみるDBでは技術の習得がもう一つの目的です。そのため実務で役立つ、以下のキーワードに沿ったテクノロジーを選定しています。

● クラウド● NO-SQL（＋キャッシュ）● モバイル（Jquery×Boostrap）● WEB-API（Json）● Java最新フレームワーク

各テクノロジーを複数回に分けて解説しま

す。

第1回　クラウド×NO-SQL（＋キャッシュ）

第2回　モバイル（Jquery×Boostrap）第3回　WEB-API（Json）第4回　Java最新フレームワーク

第１章　クラウドおさらい

クラウド

これみる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

第２章　NO-SQL

これみるDB×クラウド

これみるDBはGAEを利用しています。

理由は・今後の潮流であるNO-SQLの学習ができる

・無料枠がある・後から知ったのですが（BigData解析ができたりしてもう一つのバズワードBigDataについてが勉強できる）

GAE　NO-SQL

GAEではRDBは利用出来ず、Datastoreという列NO-SQLDBを利用する必要があります。

そもそもNO-SQLはRDBに対応する概念です。

通常のアプリケーション３層構造では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

第３章　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業務利用に関してその２現時点では使いづらい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すると１件当たりで課金に効いてきます。（レコードが１万件あって、それをjavaでカウントすると、Dataread１万になり、いきなり無料枠Over）

GAE Insertがんばる

PVカウンタなど更新が激しいものは、１レコードに対してインクリメントにするとア、ロック解除待ちが発生します。そんな時はシャーディング

カウンタ　A カウンタ　B カウンタ　C カウンタ　D

　リードの時は全部読んで合算（リード件数シャードが４の場合 4件）

書き込みの時にはどれか一つをインクリメント（ロックが 1/4）

同じ項目についてのカウンタを複数作成する（シャードを作成する）

GAE　キャッシュを使う

キャッシュを使う基本３原則です。1.キャッシュを探し、あればキャッシュを使う

2.なければｄｂからとってきてキャシュに詰める

3.有効期限は設定する。

DBアクセスはコストがかかるので、極力キャッシュを使います。GAEではmemcachedに似たmemcacheが用意されています。

GAE　キャッシュを使う

キャッシュを利用する際は、キャッシュの更新忘れに注意！データが修正されたり、追加されるときはキャッシュを削除する。

わざわざ消すの面倒な場合、キャッシュの有効期限を設定して、自動的に消されるようにすれば、OK。キャッシュの有効期限は重要です。

GAE　キャッシュを使う

キャッシュはどんなアプリでも有効な手段です。・参照/更新頻度が高い

・DBやファイルアクセスが発生する

といった場合キャッシュ化でレスポンス改善が可能です。

たとえば、画面参照のたびにログイン情報を逐一DB参照する場合などはキャッシュ化することで性能改善が図れると思われます。

GAE

GAE説明（OFFICIAL　超わかりやすい）

https://developers.google.com/appengine/?hl=ja

作ればわかるGoogle APP Engine