BOM SQL Server オプション Ver.72 第1章 システム構成 SQL Server オプションは、BOM 7.0 が導入済みのWindowsコンピューターにインストールし、SQL
Cassandra(no sql)によるシステム提案と開発
-
Upload
kishimotosc -
Category
Documents
-
view
1.472 -
download
0
description
Transcript of Cassandra(no sql)によるシステム提案と開発
Cassandra(NoSQL) による
システム提案と開発
株式会社エスキュービズム岸本 康二
前提事項などのご説明
■ NoSQL のよくある誤解・正解
■ 正解
○ 負荷分散に優れている
○ 耐障害性が高い
△ データ一貫性は弱い
■ NoSQL のよくある誤解・正解
■ 誤解
× データ一貫性がないCAP 定理自体は正しい。ただし、間違った解釈が異常に多い。
× トランザクション機能がないもう昔の話
× 業務系フロントシステムには向かないRDBMS を主役に据えた Not Only SQL …
→ なんて言ってるのはもう古い!
■ NoSQL と RDBMS との本当の関係
RDBMS での高速化(負荷分散)
1)レプリケーションで読み込み負荷分散→ 書き込み負荷は分散できず
■ NoSQL と RDBMS との本当の関係
RDBMS での高速化(負荷分散)
1)レプリケーションで読み込み負荷分散→ 書き込み負荷は分散できず
2)テーブル単位で複数サーバに分割 2 ' )テーブルを複数サーバに分割
→ 発想は NoSQL 系と同じ
■ NoSQL と RDBMS との本当の関係
RDBMS での高速化(負荷分散)
1)レプリケーションで読み込み負荷分散→ 書き込み負荷は分散できず
2)テーブル単位で複数サーバに分割 2 ' )テーブルを複数サーバに分割
→ 発想は NoSQL 系と同じ3)インデックスを張る
→ 発想は NoSQL 系と同じ
■ NoSQL と RDBMS との本当の関係
RDBMS での高速化(負荷分散)
1)レプリケーションで読み込み負荷分散→ 書き込み負荷は分散できず
2)テーブル単位で複数サーバに分割 2 ' )テーブルを複数サーバに分割
→ 発想は NoSQL 系と同じ3)インデックスを張る
→ 発想は NoSQL 系と同じ番外) SQL の解析を飛ばして直接ストレージ API の操作
→ もはや SQL では…
■ NoSQL と RDBMS との本当の関係
RDBMS でも NoSQL でも設計を深く突き詰めると同じ
そもそも CPU の処理量は DB に関係なく一定↓
CPU 処理量の配分の最適化が大切↓
NoSQL :フロント (オンライン)RDBMS :バックヤード (オフライン)
ログ解析など(← SQL が活きる!)↑「 Not Only SQL 」風の構成とは真逆が正解
■ NoSQL と RDBMS との本当の関係
WEB APP
WEB APP
WEB APP
WEB APP
WEB APP
RDBMS
RDBMS
● 従来型→DB に負荷集中
■ NoSQL と RDBMS との本当の関係
NoSQL
RDBMS
RDBMS
NoSQL
WEB APP
WEB APP
WEB APP
WEB APP
WEB APP
● 負荷を軽減しようと・・・→NoSQL でキャッシュ→DB の書き込み負荷は減らない
これが今の「 Not Only SQL 」の構成
■ NoSQL と RDBMS との本当の関係
NoSQL
RDBMS
RDBMS
NoSQL
WEB APP
WEB APP
WEB APP
WEB APP
WEB APP
● 負荷を軽減しようと・・・→NoSQL でキャッシュ→DB の書き込み負荷は減らない
現在の「 Not Only SQL 」の構成
ここを売るのは先が細い
■ NoSQL と RDBMS との本当の関係
NoSQL
RDBMS
RDBMS
NoSQL
WEB APP
WEB APP
WEB APP
WEB APP
WEB APP● ボトルネック部分を削ってみる
■ NoSQL と RDBMS との本当の関係
NoSQL
NoSQL
NoSQL
NoSQL
NoSQL
WEB APP
WEB APP
WEB APP
WEB APP
WEB APP
■ NoSQL と RDBMS との本当の関係
NoSQL
NoSQL
NoSQL
NoSQL
NoSQL
WEB APP
WEB APP
WEB APP
WEB APP
WEB APP
■ NoSQL と RDBMS との本当の関係
NoSQL
NoSQL
NoSQL
NoSQL
NoSQL
WEB APP
WEB APP
WEB APP
WEB APP
WEB APP
● 自然と NoSQL クラスタに行き着く
■ NoSQL と RDBMS との本当の関係
NoSQL
NoSQL
NoSQL
NoSQL
NoSQL
WEB APP
WEB APP
WEB APP
WEB APP
WEB APP
RDBMS
● 最適なシステム構成 →NoSQL はフロント → RDBMS はバックヤード
■ NoSQL と RDBMS との本当の関係
■NoSQL・書き込み負荷も容易に分散(スケールアウト)・障害・アクシデントに強い・データ分散自体がバックアップも兼ねるので効率的・経済的
→ フロントシステム向き
■RDBMS・ SQL が便利。思いつきの解析もすぐに実行できる・検索、ソートが効率的
→ バックヤードでの分析・統計向き→ 処理を定型に落として Hadoopを提案、が定石
では、数ある NoSQL の中で
何を選ぶべきなのか?
■ Apache Cassandra を選ぶ理由
MongoDB Redis
ボトルネック
ボトルネック
管理型 マスタ -スレーブ型
Cassandra
ボトルネックなし!
独立協調型
■ Apache Cassandra を選ぶ理由
「人」の単一障害点
→ 開発コミュニティの層が厚いことが重要
Cassandra は Apache ソフトウェア財団の「トップレベルプロジェクト」
実案件での例
■ 実案件での NoSQL
(公開に際して削除しました)
NoSQL はお金になるのか?
■ NoSQL で動くお金
(公開に際して削除しました)
■ NoSQL で動くお金
■金額の差の理由
・ NoSQL を意識する案件は比較的規模が大きめ
・システム全体を受けていること(↔ 「 Not Only SQL 」では一部のみ)
・ NoSQL はそもそもノードを増やす発想RDBMS はせいぜいマスタ -スレーブの2 台構成+WEB 数台
お金になるのは判った。
でも案件見込数は?
■ NoSQL でのターゲット
・「 Not Only SQL 」型提案では、 既存に+αするという型にはまってしまっていた。
→ 提案先も限られ、受託規模も小さい。
・従来 RDBMS で提案していた(大きめ)案件が 実は全て NoSQL でも提案ターゲットにできる。
→ なぜなら「トランザクション」が可能だから
・ RDBMS では難しいさらに大きな規模もターゲットにできる
・結果、実は大きな市場が眠っている!→ しかも、そのほとんどが手付かずの状態。
NoSQL で提案するメリット
■ NoSQL 提案のメリット
・目立つ。
・決裁者は結局システムは動けば OK→ スケーラビリティ、耐障害性の優位をアピール→ 実績もちゃんとある
・クラウドを利用するべき「合理的な理由がある」→ 担当者に納得感が生まれる
→ 選考が進む
・クラウド利用率が上がる→ インフラとセットにした商品開発にもなる
コンペでの提案ポイント
■ コンペでの提案ポイント
(公開に際して削除しました)
想定問答
■ 想定問答 ~コンペ編~
・「 RDBMS? NoSQL??」な顔→ スーパーマンの例え話
・実績あるの?→ 【ご説明済み】
・有償サポートはある?運用一式任せられる?→問題なし。本日のセミナーの内容通りです。
・クライアントにも説明したい。→ ご協力致します。
■ 想定問答 ~職場編~
・社長 :「 NoSQL って何 ?」→ 「あ、さすがですね !
これから伸びるクラウド時代の技術です」
・事業部長:「儲かるの?」→ 【すでに説明済み】
・エンジニア:「よく分からん」→ 「ちょうど良かった」と新人に振る。
→変に SQL にこだわりが無い人の方が伸びる→ 実は 40代以降の方には意外と抵抗感がない
→ エンジニア向けのレクチャーメニューもございます
NoSQL での設計パターン~ M2M編 ~
(公開に際して削除しました)
コンパクトなネットワーク構成も可能
機能に応じてクラスタを分離可能→ハードウェアレベルでチューニング可能→マルチデータセンターも可能
■ 開発ツール: パフォーマンスの可視化、チューニング
Compuware 社 「 dynaTrace 」 との連携による分散環境の性能分析・可視化
■ 開発ツール: パフォーマンスの可視化、チューニング
Compuware 社 「 dynaTrace 」 との連携による分散環境の性能分析・可視化
■ 開発ツール: パフォーマンスの可視化、チューニング
Compuware 社 「 dynaTrace 」 との連携による分散環境の性能分析・可視化
■ NanaHoshi の今後
RS MS
クラウドコンポーネントではじめるビジネス拡張 「 BlueRabbit 」クラウドコンポーネントではじめるビジネス拡張 「 BlueRabbit 」
監視と電話の融合
高速・安定なM2M基盤
RC
EC サイトPOS&倉庫連携
NH
業務向けNoSQL
RF
サイト横断O2O 分析
WC
完全従量制CDN
MM
完全従量制Map情報
RR
訪問時間枠予約サービス
RT
リアルタイム貨物追跡
DT
パフォーマンスチューニング
■ NanaHoshi の今後
■PaaS として組み合わせて土台にする ■SaaS としてパッケージを利用する
営業
開発
運用
・パッケージ(簡単・安定・規模)→ 「 NanaHoshi 」→ SIer様向けメニューあり
・実績・差別化・金額・利益率
・パッケージ・現場を経験したツール群・デバッグ、チューニング用ツール・カスタマイズ /連携を容易にする API群・納品用マニュアル類
・有償サポート・監視(クラウド環境向けノウハウあり)
全て Ready → 案件の提案に使って頂けます
■ NoSQL が熱い領域
・ M2M領域(広い意味で)→センサーデータ
→家電データも相当→ 業界大手はまだ Hadoopによる可視化を売っているのみ
→まだまだ巨大なニーズが残っている
・ PaaS領域→パッケージの機能一式をクラウドで提供
・既存領域でもシステムリニューアルは熱い→決裁者は DB で選ばない→ より良いシステムをより合理的なコストで
■ データベースの変遷
1970年頃
1990年頃
2010年頃
RDB の誕生
SQL の標準化
RDB黄金期
RDB黎明期
NoSQL の誕生
20年
20年
NoSQL黎明期
NoSQL はこれから大きく成長する領域です !
← RDB の処理限界 ・ネット人口の増加・デバイスの増加・ WEB サービスの増加