ARC-009_RDB 技術者のための NoSQL ガイド

RDB技術者のためのNoSQLガイド
NoSQLの必要性と位置づけ
2016/05/25
株式会社リクルートテクノロジーズ
渡部徹太郎

自己紹介
{"ID" ："fetaro"
"名前" ："渡部徹太郎"
"所属" ：株式会社リクルートテクノロジーズ
"研究" ："東京工業大学でデータベースと情報検索の研究
(@日本データベース学会)"
"仕事" ：["証券会社のオンライントレードシステムのWeb基盤",
"オープンソースなら何でも。主にMongoDB",
"リクルート各種サービスを横断的分析する基盤。主にHadoop"]
"エディタ"："emacs派"
"趣味"："自宅サーバ"
"属性" : ["ギーク","スーツ"]}
fetaro
RDB NoSQL技術者のためのガイド 4

書籍について
• ギーク向けではなく、一般のRDB技術者向け
• NoSQLの位置づけを明確化
(Hadoop, DWHとの違い)
• エンタープライズの課題を解決する視点
• NoSQL界のスペシャリスト達による最新情報
• 評価良好！4.3点→

NoSQLの必要性

背景：3つのVの増加
• Volume(データ量)の増加
• Googleは１日に24ペタバイトのデー
タを処理している
• facebookの写真は1.5ペタバイト
スケールアップスケールアウト
コントローラ
性能限界
高コスト＋構造上の限界限界有り
CPU↑
メモリ↑
ディスク↑ RDB
• Velocity(処理速度)の増加
• orange(大規模Web)サービス秒間11万アクセス
• マウスの軌跡を解析→秒間万単位の書き込み
• twitter 「バルス」で秒間14万つぶやき
[課題] RDBではビッグデータの扱いが困難

背景： 3つのVの増加
• Variety(多様性)の増加
社内社外
非リレー
ショナル
データ
非構造
半構造
リレーショ
ナルデータ
構造化
オフィス文章
システムロ
グ
テキスト・音声
(顧客対応履
歴)電子メール
経理・財務・
人事
営業・CRM
センサー
情報位置・地
図
SNS
マルチメ
ディア
他社が保
有する
データ
気象・交
通
健康・医療
各種統計行政金融取引
商品・在庫
決済・残高
口コミ文章
[課題] 半構造データはRDBでは格納が困難
Schema on Write < Schema on Read

RDBだと厳しい身近なケース
• 「Twitterのデータを分析して商品評判を知りたい。プロトを3日で作ってくれ」
TwitterのAPIが返却するデータ（JSON）
• この状況でこのデータをRDBMSにいれますか？？
{
"_id" : ObjectId("55b93f4bb427f0c12e080473"),
"created_at" : "Wed Jul 29 20:57:42 +0000 2015",
"id" : 626496848031690800,
"text" : "@mchris4duke and certainly not concious, for a f
moment, of their prejudices",
"source" : "<a href=¥"http://twitter.com¥" rel=¥"nofollow
Web Client</a>",
"truncated" : false,
"in_reply_to_status_id" : 626496667957751800,
"in_reply_to_screen_name" : "mchris4duke",
"user" : {
"id" : 772136,
"id_str" : "772136",
"name" : "Greg Smith",
"place" : null,
"contributors" : null,"retweet_count" : 0,
"favorite_count" : 0,
"entities" : {
"hashtags" : [ ],
"trends" : [ ],
"urls" : [ ],
"user_mentions" : [
{
"screen_name" : "mchris4duke",
"name" : "Chris Bourg",
"id" : 14093339,
"id_str" : "14093339",
"indices" : [0,12]
ここは一対多
これは何桁ある
んだろう？
なんか、前と変
わってるようなここも一対多
テーブルは３つに分けて、
JOINを２回するしかない

RDBの課題の一部を解決するDBが登場
スケールアウト
アプリ
性能限界
水平分散で性能向上
アプリ
大量データ処理
高速データ処理
半構造
データ処理
KVS／
ドキュメント
データベース
グラフ
データベース
課題解決するDB
事前に構造を定義する必要がない
「スキーマ・オン・リード」
CREATE TABLE
ALTER TABLEJSONが格納できる
RDB

NoSQLの位置づけ

DBを重視する性能で分類
• レスポンスを重視 →主にオペレーション用途
• スループットを重視 →主に分析用途
13
アプリケーションサーバ
オペレーション
用途
データベース登録画面
リクエスト参照
更新
挿入
参照画面
編集画面
即時応答
マスタ
データベース
ＢＩツール
集計
バッチで
ロード分析用途
データベース
レポート生成ジョ
ブ
抽出
ＣＳV
バッチで
ロード
レポート
２０分で全件集計
１０秒で全件取得
RDB NoSQL技術者のためのガイド

NoSQLの位置づけ
凡例
レスポンス重視
(オペレーション用途)
スループット重視
（分析用途)
スケールアウトできる
Hadoop
(HDFS+MapReduce)
・Cloudera
・MapR
・Hortonworks
RDB(OLTP)
・Oracle
・SQL Server
・MySQL
グラフDB
・Neo4j
RDB(DWH)
・Oracle Exadata
・Netezza
・RedShift 登場順
KVS
・Cassandra
・Redis
ドキュメントDB
・MongoDB
・Couchbase
NoSQL

RDB(OLTP)とKVS/ドキュメントDBの違い
• RDB(OLTP)とは違い、
以下の３つによりスケーラビリティを獲得
1. トランザクションを提供しない
2. 分散しやすいデータモデルと、分散しやすいクエリだけを提供
する
3. 「強い整合性」を犠牲にして、複製に対して読み書きを行う
「結果整合性」を採用

アプリケーションアプリケーション
スケールアウト構成
整合性は
保証される
②準備ＯＫ
④コミット
②準備ＯＫ
④コミット
②準備ＯＫ
④コミット
①コミット準備の確認
③コミット指示
アプリケーション
待たされる
ＡＢＣ
分散トランザクションで
ＡＢＣを一括更新
待たされる待たされる

スケールアウト構成
更新
一括更新はできないので
Ａ→Ｂ→Ｃの順番で更新
ＡＢＣ
更新
更新
更新
更新
待たない
更新更新
割り込まれて
整合性が
崩れる
可能性あり

KVS/ドキュメントDBとHadoopとの違い
分散ファイルシステム
(HDFS等)
分散処理フレームワーク
(MapReduce, Spark等)
ABC
A B C
クライアント
計算
ノード
計算
ノード
計算
ノード
コーディネータ
①データの配布
②提出
③計算
計算
結果
プログラム
プログラム
クライアント
プログラムプログラム
KVS/
ドキュメントDB
シャードシャードシャード
A
クエリルータ
B C
アプリアプリ
クエリ
クエリ

データベースは互いの領域に進出している
レスポンス重視
(オペレーション用途)
スループット重視
（分析用途)
スケールアップするしかない
スケールアウトできるKVS/ドキュメントDB
RDB(OLTP) RDB(DWH)
Hadoop
分析もできる
KVS/ドキュメントDB
・MongoDB ・Cassandra
JSONを格納する
RDB(OLTP)
・MySQL
・PostgreSQL
・IBM DB2
もできるDWH
・SAP HANA
応答が速くて
SQLが使えるHadoop
・Impala
・Presto
・Hive on Tez
スケールアウトも
できるDWH
・Oracle Exadata
・Teradata
・Neteeza
・Greenplum
・Vertica
SQLが使える
KVS/ドキュメントDB
・DocumentDB
・Cassandra

NoSQLの分類

NoSQLの分類
NoSQL ー NoSQL
プロダ
クト
KVS（キーバリューストア) ドキュメントDB RDB グラフDB
データ
モデル
キーバリューワイドカラムドキュメント(JSON) リレーショナ
ルモデル
グラフ
データ
構造
キー値
キー
値
array
hash
階層構造ノード
リレー
ション
ノード
ノード
リレー
ション
データの複雑度大小
処理の分散がしやすい複雑なデータ処理が可能
キー列

データ関連度とスケーラビリティ
グラフ
リレーショナル
キーバリュー
ワイドカラム
ドキュメント

NoSQLの主要プロダクト

NoSQL - NoSQL
DB KVS(キーバリューストア) ドキュメントDB RDB グラフDB
OSS
商用
製品
サー
ビス
NoSQLの主要プロダクト
ElastiCache
Microsoft Azure
Redis Cache

DB ENGINESによるランキング
25
以下の指標を総合的に判断
・ウェブでのシステム名称の登場回数
(Google, Bing)
・一般的な人気度
(Google Trends)
・技術的なディスカッションの頻度
(Stack Overflowなど)
・求人サイトにおける募集スキル
(Indeed, Simply Hired)
・プロフィール登場回数
(LinkedIn)
（出所）DB ENGINES
http://db-engines.com/en/ranking
RDB NoSQL技術者のためのガイド

ガートナー社のハイプサイクル
ドキュメントデータベース
キーバリューストア
グラフデータベース

その他、本書で説明していること

その他本書で紹介していること
• 統一した観点で、代表プロダクトの最新情報を説明
• 想定されるユースケース（多数掲載）
• RDBの課題を解決するNoSQLプロダクトの選び方
• データモデル
• API
• 性能拡張
• 高可用
• 運用
• セキュリティ
• 出来ないこと
• 主要バージョンと特徴
• 国内サポート体制

mongodプロセス
データベース
コレクション
ドキュメント
(JSON)
ドキュメント
(JSON)
コレクション
ドキュメント
(JSON)
ドキュメント
(JSON)
データ
ベース
コレク
ション
・・・・・・
・・・・・・

｛
ID ： 12345 ,
name ："渡部”,
address ： {
City ："東京”,
ZipNo ："045-3356”,
}
friendID ： [ 3134 , 10231 , 10974 , 11165 ] ,
hobbies ：
[
{ name ："自宅サーバ","year": 6 } ,
{ name ："プログラミング","year": 10 } ,
配列
サブドキュメントの配列
キーと値
サブドキュメント

{
id: 10
name: "マトリクス"
tag : ["SF", "キアヌ", "ハリウッド"]
}
id name
10 "マトリクス"
11 "天空の城ラピュタ"
JSON
id movie_id value
1 10 "SF"
2 10 "キアヌ"
3 10 "ハリウッド"
4 11 "ファンタジー"
5 11 "宮崎駿"
6 11 "ジブリ"
movieテーブル
tagテーブル
・全貌が分からない
・データ構造を事前に定義
する必要がある
・読みやすい
・全貌がわかる
・データ変更に対応できる
{
Id: 11
name: "天空の城ラピュタ"
tag : ["ファンタジー", "宮崎駿","ジブリ"]
}

{
id: 10
name: "マトリクス"
tag : ["SF", "キアヌ", "ハリウッド"]
}
JSON
・読みやすい
・全貌がわかる
・データ変更に対応できる
{
Id: 11
name: "天空の城ラピュタ"
tag : ["ファンタジー", "宮崎駿","ジブリ"]
}
キーバリュー
・複雑なデータ構造だと扱
いが困難
key value
10-name "マトリクス"
10-tag-0 "SF"
10-tag-1 "キアヌ"
10-tag-2 "ハリウッド"
11-name "天空の城ラピュ
タ"
11-tag-0 "ファンタジー"
11-tag-1 "宮崎駿"
11-tag-2 "ジブリ"

db.person.find( {"name":"watanabe","age": 30 } ).limit(3)

x ドキュメント
チャンク
シャードキーに基づ
いて
ルーティング
シャードキー
範囲 0-9 範囲10-19 範囲20-
mongosルータ
1 4 9 11 16 20 27
MongoDB
ドライバ
23
23
mongod mongod mongod
シャードキーで
分散
自動的に
再配置

プライマリ
1 4 9
セカンダリ
1 4 9
セカンダリ
1 4
MongoDBドライバ
9
書き
レプリカセット
読み
非同期
で複製
読み
プライマリ
1 4 9
プライマリ
1 4 9
セカンダリ
1 4 9
MongoDBドライバ
書き読み読み
自動フェイルオー
バ
書き込みは
プライマリの
み

マシン２
マシン３
マシン１プライマリデー
タ１
セカンダリ
データ１
セカンダリ
データ１
セカンダリ
データ２
プライマリ
データ２
セカンダリ
データ２
セカンダリ
データ３
セカンダリ
データ３
プライマリ
データ３
mongosルータ
負荷分散
冗
長
化
1
1
1
2
2
2
3
3
3

マシン２
マシン３
マシン１プライマリデー
タ１
セカンダリ
データ１
セカンダリ
データ１
プライマリ
プライマリ
データ２
セカンダリ
データ２
セカンダリ
データ３
セカンダリ
データ３
プライマリ
データ３
mongosルータ
負荷分散
冗
長
化
1
1
1
2
2
2
3
3
3

• ⇒ver 3.0で解決
• ⇒ ver 3.2で解決
ユーザ１
取引１
取引２
ユーザ１取引１
取引２
ドキュ
メント
参照
制約
結合
トランザクション

性能の拡張が難しい
現実的なコストで扱えない
app
Mongo
Mongoapp
Mongo
app Mongo
Mongo
Mongo
Mongo
Mongo
Mongo
急なユーザ増加にも、水平
分散で簡単に対応できる
課題選定理由・解決策結果
• MySQLがスケーラビリティの上限に達して性能要件を
達成できなくなった
• RBMSでは非定型なメタデータの管理が困難
• 性能とスケーラビリティに期待しMongoDBを導入
• 60億におよぶ属性情報データの代わりに、１コンテンツ
を１ドキュメントにする構造を導入
• 秒間11万件以上のクエリに対応
• ３年で200万ドル以上のコスト削減
• 新規機能の導入のスピードが著しく早くなった
• 新規プロジェクトでは全てMongoDBを利用する方針
となった
活用事例： orange(Webサービス事業）
７００万ユーザを超えるWebサービスのバックグラウンドDB

Mongo
app
カタログ
（JSON）
課金情報等
（リレーショナル）
既存
新規
トランザクションが必要な課金は
従来通りRDBMSで一貫性を担保
読みやすい。
項目追加も簡単。
カタログ管理
RDBMS
課題選定理由・解決策結果
• RDBMSベースの旧システムでは商品カタログのアップ
デートに12時間かかった
• JSONがスキーマレスでかつ複雑なデータ構造を格納で
きるので、商品データを入れるのには最適だった
• カタログのアップデートに要する時間が12時間から15
分になり、ビジネス環境の変化に応じて迅速にカタロ
グを変更できるようになった
活用事例： OTTO
毎日２００万人が利用する大手Eコマースサイトの商品カタログを管理

機能ユースケース
GridFS 大容量ファイルの管理
地理空間インデック
ス
地図アプリ
集計機能データの集計
旧データ自動削除ログ保管

©2015 DataStax Confidential. Do not distribute without consent.
DataStax
原沢滋
RDB技術者のための
「NoSQL ガイド」
〜Apache Cassandra〜
eBay、ソニー、APPLEも
大規模運用するNoSQL
Apache Cassandraの実力

ある企業における
Apache Cassandra
• 100,000+ ノード
• 数十ペタバイト
• 毎秒数百万件以上オペレーショ
ン
• 最大クラスタのノード数1,000+
• バージョンはv1.2 とv2.0を利用
写真は2014年に75,000+ノードと発表した時のもの

ソニーにおけるApache Cassandra
• Cassandraを6ヶ月でプロダクション
• リニアスケーラビリティ
• パフォーマンス
• ダウンタイムがない
• 運用が楽
• コスト
データスループット: Gigabytes/sec
トランザクション: >200,000/sec
データサイズ: Tens of terabytes

NetflixにおけるDataStax Enterprise(DSE)
(Apache Cassandra)
Netflix は映像ストリーミング配信会社
• Netflix の全データベースのち95%を DSE を利
用
• スループットは１千万トランザクション/秒
• １日１兆トランザクションをDSE で処理
• 世界各地にある６つのデータセンターの
Oracle を置き換え、100%クラウドで実現
• AWSの大規模の再起動の際も全く問題なく24
時間x365日のサービスをCassandraで提供

+
x
ではそのApache Cassandraとは？
Apache Cassandraとは分散データベース
Apache
Cassandra とは
Amazon Dynamo の分散ハッシュテーブ
ル（DHT）と、Google BigTable のKVS
の２つの特徴を併せ持つビッグデータ用
分散データベース
• Amazon DynamoとGoogle Bigtableの良い点を持つ
• 高速パフォーマンスとリニアな拡張
• SPOF（Single Point of Failure）がない、簡単に24時
間 x 365日ダウンさせないで運用が可能
• 完全な分散
• 柔軟なNoSQLデータモデル(スキーマーレス！）
• シンプルな運用管理
• SQL ライクな言語CQLをサポートしている
• 様々な無償ツールとドライバ/コネクタを持つ
• 様々な整合性を選ぶ事が可能(CAP定理, BASE)

繋がるネット時代の新技術
LAN/WAN
クライアント/サ
ーバー
DBMS(RDBMS)
SNA
階層DB
Terminal
NoSQL DBMS
オープンシステム時代
（Oracle,Informix,
Sybase等)
メインフレーム時代（
IMS,DB2等)
もののインターネット(IoT)時代（クラウド、ネットワーク、分散）
(Bigdata, Hadoop, Open Source)
1970 年代
1990 年代
2010年以降
IoT, コンテンツの時代
クラウド
アプリケーションの時代
大きなコンピューターの時代

OLTP
(RDBMS)
DWH
(RDBMS)
NoSQL
OLTP
(RDBMS)
DWH
(RDBMS)
Hadoop
分析・データベース
オペレーショナル
データベース
既存システム(RDB)
新システムへの要求
＊データ量
＊パフォマンス
＊柔軟性
＊可用性
＊値段
分析・データベース
オペレーショナル
データベース
既存システム(RDB)
新システム(NoSQL)
今までRDB では不可能、又は実現するのに
コストが膨大にかかった領域
NoSQLって何？位置付け

Cassandraの特徴
• Amazon DynamoとGoogle Bigtableの良い点を持つ
• 高速パフォーマンスとリニアな拡張
• SPOF（Single Point of Failure）がない
• マルチデータセンター
• 完全な分散
• 柔軟なNoSQLデータモデル
• シンプルな運用管理
• SQL ライクな言語CQLをサポートしている
• 様々な無償ツールとドライバ/コネクタを持つ
• 結果整合性を持つ(Eventual Consistency)、Strong Consistencyも可能

高速なパフォーマンスとリニアな拡張
「スケーラビリティの点では、我々の実験全体を通して明白な
勝者がいます。すべての実験において、Cassandra は最大のノ
ード数でリニアに増加する最高のスループットを達成しました
」
Solving Big Data Challenges for Enterprise Application Performance Management, Tilman Rable, et al., August
2013, p. 10. Benchmark paper presented at the Very Large Database Conference, 2013.
http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2013.pdf
http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html
最高のスループット・・・
最小のレイテンシ・・・
Netflix 社によるクラウド上でのベンチマーク・・・ End Point 社による第三者 NoSQL ベンチマーク

Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
1111: 原沢
2222: 山田
3333:鈴木
クラスター
データベース
各ノードがHashで決めら
れたKEYを元に分散され
たデータを持つ
＝
Cassandra のアーキテクチャ(完全な分散+KVS）
• Master, Slaveという関係がない
• Name node, gatekeeperといった特別なノードの機能を持つノードがない
• すべてのノード（マシン）が完全に同じ機能を持つ
この場合、６台で
１つのデータベースとなる

Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
1111: 原沢
2222: 山田
3333: 鈴木
x
一台のマシンが
死ぬとデータが
見えない？
Cassandra のアーキテクチャ(完全な分散+KVS）
• Master, Slaveという関係がない
• Name node, gatekeeperといった特別なノードの機能を持つノードがない
• すべてのノード（マシン）が完全に同じ機能を持つ

Cassandraとは？
• 分散でデータを保持するので、他のマシンの影響を受けない
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Data: 原沢
Data: 原沢
Data: 原沢
レプリケーション
（データのコピー）
は何台に持たせるかを決
められる
Replication factor=3
マシンが故障しても、
特定のマシンが特定の
機能を持っている訳で
はないので、他のデー
タのあるマシンが同じ
作業を全く問題なく処
理する事が可能

Cassandraとは？
• 分散でデータを保持するので、他のマシンの影響を受けない
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Data: 原沢
Data: 原沢
Data: 原沢
x
問題なし一台死んでも問題無し

Cassandraとは？
• すべてのノードは同等で、どのマシンでも処理を同等に受け付ける
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra

Cassandraとは？
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
• すべてのノードは同等で、どのマシンでも処理を同等に受け付ける

• 複数データセンター間でもレプリケーション可能
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandraとは
CassandraがETL不要で
自動にReplication東京大阪

Cassandra のアーキテクチャ(マルチデータセンター）
• 複数のデータセンター内でのレプリケーションも自動で行う事が可能
• 双方向のマルチデータセンターでのレプリケーションを行う
• どのデータセンターのどのノードを対象に対しても読み取り／書き込みが可能
• 故障時はドライバが判断して、接続できるノードに接続を行う
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
東京
クラウド
7369,原沢
7369,原沢
7369,原沢
7369,原沢
7369,原沢
7369,原沢
7369,原沢
7369,原沢
7369,原沢
大阪

Cassandra Query Language（CQL）
• RDBMS の SQL によく似た構文
• DDL を使用してオブジェクトを作成（例：CREATE…）
• GRANT/REVOKE によりセキュリティを確保
• 基本的な DML コマンドをサポート：INSERT、UPDATE、DELETE
• SELECT を使用してデータを検索
• コマンドラインツール、GUI ツール

Apache Cassandra

+
x
DataStax
Apache CassandraのDistribution
Apache
Cassandra とは
Amazon Dynamo の分散ハッシュテーブ
ル（DHT）と、Google BigTable のKVS
の２つの特徴を併せ持つビッグデータ用
分散データベース
セキュリティ分析検索ビジュアル
監視
管理サービスインメモリ
開発環境／
ドライバ
プロフェッショナ
ル・サービス
サポート／
トレーニング

セキュリティ
分析検索ビジュアル
監視
管理サービスインメモリ
開発環境／ドラ
イバ
プロフェッショナル・サ
ービス
サポート／
トレーニング
DataStax Enterprise(DSE)
• 保証されたCassandra
• Advanced Security
• 分析機能の追加
• Own Hadoopの外部バッチを利用可能
• Cassandraデータの全文検索が可能
• CassandraのIn Memory オプションを持つ
• Cassandraの運用管理を自動化
• 管理ツール(OpsCenter) のフルバージョン提供
• ETL不要で、オペレーショナルと分析環境を自動レプリケーション
• 24時間サポートを提供
DataStax社が販売しているCassandraを含んだSoftware

Gartner Magic Quadrant(MQ)でのDataStaxの位置
2013 2014 2015

インメモリ
Time Series
DataStax Enterprise (DSE)
DataStax社による商用版のCassandra 、
Apache Cassandraだけでなく、
Apache Solr (全文検索),
Apache Spark (リアルタイム分析),
Apache Hadoop (バッチ分析),
GraphDB(本年内予定）を統合したデータベース
上記以外にも、インメモリ、セキュリテー、GUI, 管理機能、チューニン
グパッケージ等も提供
ボトルネックの
ないリニアな
拡張性
マスターレス
でSPOFのな
い可用性
オープン
ソース
ベース
ミリ秒単位
での大量
Tx処理
稼働率
100%の信
頼性
GUIで簡単
な監視、
運用管理
セキュリティ管理ツール

DataStaxでは、オペレーショナル・分析・全文検索が可能
• ETLなしでレプリケーション（余計な設定、HW、SW必要なし）
• 別ワークロードを分離してパフォーマンス問題が発生しにくい
• 高可用性も提供
• マルチデータセンターも簡単に実現
• リニアにスケール
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
C*
Cassandra
(オペレーショナル)
Cassandra
(全文検索)
Spark(分析）

ありがとうございました！
Twitter account: @cassandrajapanで情報発信しています

SQL Server
データベースエンジン
Azure SQL Database
リレーショナル (SQL)非リレーショナル (NoSQL)
分析
Azure
マネージドサービス
Microsoft Analytics Platform System

高速で安定したパフォーマンス
構成可能な整合性レベル
エラスティックなスケーリング
セカンダリインデックスなしで
JSONをクエリ
ネイティブ JavaScript トランザク
ション処理
SQL ベースのクエリ言語
REST、JSON、JavaScript
簡単、フルマネージド
エンタープライズ対応の Azure

DocumentDB は
Web/モバイル
アプリで特に
よく使われている
カタログデータ
ユーザー設定、状態
イベントストア
UGC (ユーザー生成コンテンツ)
データ交換

コレクション
ドキュメント 1 ドキュメント 2
ドキュメント 3 ドキュメント 4
DocumentDB
Application
{
"name": "John",
"country": "Canada",
"age": 43,
"lastUse": "March 4, 2014"
}
{
"name": "Lou",
"country": "Australia",
"age": 51,
"firstUse": "May 8, 2013"
}
{
"docCount": 3,
"last": "May 1, 2014"
}
{
"name": "Eva",
"country": "Germany",
"age": 25
}
JSON

Azure ポータル Azure DocumentDB Studio
portal.azure.com github.com/mingaliu/DocumentDBStudio

アンケートにご協力ください。
●アンケートに上記の Session ID のブレイクアウトセッションに
チェックを入れて下さい。
●アンケートはお帰りの際に、受付でご提出ください。
マイクロソフトスペシャルグッズと引換えさせていただきます。

ROOM J
Ask the Speaker のご案内
●本セッションの詳細は、EXPO 会場内
『Ask the Speaker』コーナー
Room A カウンタにてご説明させて
いただきます。是非、お立ち寄りください。
Ask the Speaker
EXPO会場MAP

ARC-009_RDB 技術者のための NoSQL ガイド

More Related Content

What's hot

Similar to ARC-009_RDB 技術者のための NoSQL ガイド

More from decode2016

ARC-009_RDB 技術者のための NoSQL ガイド