[[Open棟梁Project>http://opentouryo.osscons.jp/]] - [[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]

* 目次 [#sb8dcf9e]
#contents

*概要 [#m59dcae8]
NoSQLに関する情報をまとめる。

**参考 [#a251706d]
-データベース部会 設立セミナー~
NoSQLの必要性と主要プロダクト比較~
http://openstandia.jp/event/pdf/20150828oss_con_report.pdf?osscon0828

-知らないなんて言えないNoSQLまとめ - @IT~
http://www.atmarkit.co.jp/ait/series/928/
--(1) KVS系NoSQLのまとめ(Hibari、Dynamo、Voldemort、Riak編)~
http://www.atmarkit.co.jp/ait/articles/1211/05/news007.html
--(2) イネーブラ型NoSQLのまとめ(Memcached、Redis、Scalaris、Tokyo Cabinet/Tyrant編)~
http://www.atmarkit.co.jp/ait/articles/1211/19/news020.html
--(3) カラム指向型データベース(HBase、Hypertable、Cassandra)編~
http://www.atmarkit.co.jp/ait/articles/1301/11/news012.html
--(4) グラフ型NoSQLデータベース(Neo4j、InfiniteGraph)編~
http://www.atmarkit.co.jp/ait/articles/1302/08/news001.html
--(5) ドキュメント指向のNoSQLデータベース(CouchDB、MongoDB)編~
http://www.atmarkit.co.jp/ait/articles/1303/27/news019.html

-IoT時代のデータストア・NoSQLの実力は? 書き込み性能から見る活用ポイント 記事一覧 | Think IT(シンクイット)~
https://thinkit.co.jp/series/5171
--IoTに適したNoSQL・分散Key-Valueストア~
https://thinkit.co.jp/story/2014/09/25/5280
--センサーデータ蓄積を想定したKVS性能検証・観点と方法~
https://thinkit.co.jp/story/2014/12/03/5458
--Riak、okuyamaのデータ書き込み性能を検証する~
https://thinkit.co.jp/story/2014/12/17/5488

**背景 [#ya76316d]
登場の背景はRDBでは解決困難な問題がでてきたから。

***3V [#gfa4775f]
データの
-量(Volume)の増加
-処理速度(Velocity)の増加
-多様性(Variety)の増加

・・・への対応がRDBで限界に達した。

***Volume & Velocity [#mfacfc80]
RDBで、大量データの高速処理を行う場合の課題として、
-[[スケールアウトが困難>大量データの処理方式3#u1ee768f]]
-スケールアップしか無い

という点があげられる。

***Variety [#h5276ccd]
-非定型なメタデータの管理が困難
-RDBに格納困難な[[非構造化データ>https://ja.wikipedia.org/wiki/%E9%9D%9E%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%87%E3%83%BC%E3%82%BF]]が増加しているらしい(主にはJSON)。

*利用事例 [#ec214165]
***非構造化データ [#d2c12f43]
-非構造化データの例
--商品情報
--物件情報
--デバイスの生成するデータ
--最近、非構造化データが急増している。

-非構造化データの増加に伴う影響
--スキーマ変更の影響が大きい(多分、主に列を足す作業)
---時間がかかる
---オフライン

***大量データの高速処理 [#v3a2f69c]
-原因
--モバイル端末からのアクセス数の増加。

-対応~
RDBでは、
--スケールアップが限界を迎える(若しくは高価過ぎる)。
--しかし、スケールアウトにも課題がある。
--そこで、スケールアウト可能なNoSQLが採用される。

*プロダクトの型 [#rf480bb4]
**KVS型 [#b2f6dc29]
***特徴 [#v1605cc4]
-データアクセスが高速
-小さい多数のデータの蓄積が得意
-ハードディスクにデータを永続化
-ノードを追加することでスケールアウト可能

***アーキテクチャ [#t8a5b8a9]
-マスタ型(Hibari)
--チェインレプリケーションという独自アーキテクチャにより「強い整合性」を保証
-P2P型
--Amazon Dynamoは、可用性を重視した「結果整合性」
--VoldemortとRiakは、Quorumにより整合性が調整可能

***用例 [#qdbef3fc]
-キャッシュサーバ
-ログ蓄積
-オブジェクトストレージ

**KVSイネーブラ型 [#f6928d0d]
***特徴 [#f2999cc6]
-オンメモリなので高速だが永続化されない。
-他のNoSQLデータベースと組み合わせて永続化を可能にできる。

***アーキテクチャ [#wa180143]
-イネーブラ型オンメモリタイプ
-イネーブラ型オンディスクタイプ(TokyoCabinet/Tyrant)

**カラム指向型 [#a424896e]
***特徴 [#r95013b6]
-拡張性と永続性がある。
-カラムを動的に追加できるデータモデル
-一部のものはスキーマ定義が必要
-カラム指定での範囲検索・集計処理が得意
-データ構造(LSM-Tree)により高い書き込み性能を実現

***アーキテクチャ [#rf524d18]
-マスタ型
--「強い整合性」を保証
-P2P型
--「Quorumによる整合性の調整」が可能

***用例 [#v9a96cca]
-ログ蓄積
-ログ分析
-大規模データ処理

**ドキュメント指向型 [#j7b51bce]
***特徴 [#d92c62da]
-ドキュメント毎に異なるデータ構造を持てる
-属性に対する検索・集計が可能

-キーバリュー型やカラム指向型で紹介したような特性を有していない。
--ビッグデータ対応というよりは、使いやすさに優れたNoSQLデータベース

***用例 [#vcf34413]
-ログ分析
-Webシステム
-オンラインゲーム

**グラフ型 [#w65a27de]
***特徴 [#ad03338e]
-3つの基本構成要素
--ノード(頂点)
--リレーションシップ(エッジ)
--プロパティ(属性)

-データベース側で、データとデータの関係性(オブジェクトであるノード間の関係性)を表現する。
-「知人を探す」「知人の知人を探す」「最短経路を探す」といったクエリの答えを得るために最適化されている(RDBでは大量のJOINを行う)。

*プロダクトの種類 [#j911aa10]
**mongoDB [#v6ebb8f5]
***参考 [#nb2a66f9]

***特徴 [#qf33cb9f]

**Cassandra [#aeb5e96c]
***参考 [#h03badd6]
-Apache Cassandra - Wikipedia~
https://ja.wikipedia.org/wiki/Apache_Cassandra

***特徴 [#yc44cc90]


トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS