[[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・分散Key-Valueストア | Think IT(シンクイット)~ https://thinkit.co.jp/story/2014/09/25/5280 **背景 [#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]