プログラミング初心者がアーキテクトっぽく語る

見苦しい記事も多数あるとは思いますが訂正しつつブログと共に成長していければと思います

NoSQLデータベースの種類

インフラ

以前、データベースの大半はRDBMSと言われているが、NoSQLデータベースを適材適所に配置する流れは続いている。NoSQLの種類とそれぞれの特徴、そして代表的な実装を知っておくことは重要である。

ここでは代表的なNoSQLデータベースを紹介する。

Key-Value Database

概要

実装例

特徴

  • シンプル
  • 高速

Valueの重複記載

  • RDBMSでは重複データはRelationで表現する
  • Key Value DBでは重複データは重複して記載する

ValueのAggregateあり/なし

  • 関連するデータを分割して保持することも、分割せずに保持することもできる
  • どちらにするかはユースケース次第
Aggregateなしのケース

例：

"Invoice:5:TotalSum" : "20 "
"Invoice:5:Date" : "17.08.2020"
"Invoice:5:VAT" : "10%"
"Invoice:5:Customer" : "Suzuki"
  • アプリケーションで個々のValueを処理したいときなどに適している
  • Invoice全体を取得したい場合は複数回、取得処理を繰り返す必要があるため非効率
  • サイズが小さいのでキャッシュとの相性がよい
Aggregateありのケース

例：

"Invoice:5" : { 
  totalSum: "20",
  date: "17.08.2020",
  VAT: "10%",
  customer: "Suzuki"
}
  • アプリケーションがInvoice全体を取得したい場合には1回で取得できるため効率的
  • 個々のデータを処理したいときは結果を解析して対象箇所を抽出する必要があるため非効率
  • Aggregateありのケースで個々のValueを処理する場合はアプリケーションではなくクライアントが実施することが多い
  • サイズが大きいのでキャッシュとの相性は良くない

インメモリデータベース

  • Key Value DBにはインメモリデータベースが多い。
  • memcachedもRedisもインメモリデータベースである。
  • インメモリとは言えスナップショットなどはディスクへ保存される。
  • インメモリデータベースはキャッシュとして利用されることが多い。
    • Session管理
    • DNSキャッシュ
    • Webページキャッシュ
    • ショッピングカート
    • オンラインゲームのランキングボード
    • DBの性能向上（RDBMSのキャッシュ）

Document-Based Database

概要

  • key value Databaseの一種
  • 半構造化データを保持するのに最適
    • 例：マルチメディアデータ等
  • document = object
  • collection = documentの集合
    • collectionはRDMBSのTableに相当
    • documentは１つのcollectionに属する
  • documentには管理用途のmetadataを付与する

実装例

MongoDB

Pros

  • Schema定義がないのでIterationや頻繁なコード変更に対応しやすい
  • 制約が少ないので書き込み処理が早い

Cons

  • Relationを利用したQueryやjoinができない
  • 構造化されていない
  • ACIDではない
  • RDBMSと比較して情報が少ない

Documentの多重化

  • documentにdocumentを含めることができる
  • 直接埋め込む方法と他のdocumentを参照する方法がある
  • 直接埋め込む方法は読み込み効率はよいが書き込み、変更の効率が悪い。
  • 加えてDisk効率やキャッシュHit率も悪くなる。
  • ユースケースに応じて判断する

Big Data

  • Document Based DBはBig Dataを溜めるために使われることがある。
  • 溜まったBig DataはElasticsearchやMapReduceで処理することが多い
  • Elasticsearchはドキュメントの保存と全文検索のためのエンジン
    • 大量のドキュメントから目的の単語を含むドキュメントを極めて高速に抽出することができる
  • MapReduceはBig Dataを高速に処理するための並列分散処理の仕組み
    • 実行できる処理はシンプルだがその背後にある並列処理や分散の仕組みが超絶技巧

Columnar-Based Database

概要

  • 全ユーザの平均年齢を計算したい場合、全ての行にアクセスして年齢データを取らなくてはいけいない
  • 1回で年齢の列を取れれば早いのにな、、、を実現したのがColumnar based Database
  • 行ではなく列ごとにデータを保持する
  • 逆にあるユーザの全Attributeを取得しようとすると遅い

実装

  • 実装はRDBMSがベースのものとNonSQLがベースのものの両方がある
  • Cassandra（Facebook）
  • HBase（Yahoo!）

Pros

  • range-based queriesには非常に強い
  • １行のデータを全て取得できるのでAVG、SUM、MINなどをすぐに計算できる

Cons

  • 全般的に遅い
  • INSERTやUPDATEは遅い
  • JOINも遅い（ユースケース自体ないが）

圧縮

  • Row内のデータが類似してるので圧縮効果が高い。
  • LZWやrun-length encodingなどを使う。
  • footprintは小さいが取得処理には時間がかかるようになる。

並列

  • Single Instruction Multiple Data (SIMD）やVector Processingで効率的に処理できる
    • 1つの命令でvector(複数のValue)を処理する

Graph-Based Database

概要

  • Relationが非常に重要なケースがある
  • 例えばSocial Media上でのメンバー同士のフォロー、コンテンツのCREATEやライクをどう表現できるか？
  • RDBMSだとEntity用のテーブルや関係用のテーブルがたくさんできてJoin処理が多発する
  • RDBMSだとRelationが効率的に表現できないときにGraph-Based Databaseを使う
  • Graph-Based DatabaseではNode、EdgeでRelationを表現する

実装

  • Graph Based DBの純粋な実装は存在しない
  • Document-base DBやRDBMS上に実装することが多い
  • 内部構造は既存のDBMSと変わらないが複雑性を隠蔽することはできる

Pros

  • 関係を追跡するためのJoinが不要
  • 関係はEdgeを見ればすぐ得られる
  • Scaleしやすい

Cons

  • 大量のTransaction処理苦手
    • よってData Warehouseでの使用や大量データのAnalyticsには適さない。
  • 単独の関係をQueryするのは効率的だが、沢山の関係をAnalyticsするのは苦手
  • 新しい技術なので情報が少ない

Node

  • RDBMSのrecordに相当
  • LabelとPropertyが含まれる
  • LabelはTypeを表し、metadataを含むこともある
  • Propertyはkey value pairのデータ

Edge

  • node間の関係を示す、矢印のようなもの
  • 方向性、Type、起点Nodeと終点Nodeがある

Graphの種類

Social graph

  • Social Relationsを表現し、Social networksをモデルする
  • 人物同士のlives with, married withh, friend withなどの関係を表現
  • 利用例：Facebook、Fraud detection

Intent graph

  • 人がなぜ、なにをするか表現する
  • 利用例：広告、Recommendation engine

Consumption graph

  • consumer-vendor関係や傾向を表現する
  • "has bought", "used daily"といった関係性を表現
  • 利用例：マーケティング

Interest graph

Time Series Database Concepts

概要

  • 時間によって変化するデータを時系列で保存する
  • 見かけはkey-value databases
  • keyが日付時刻を表す
  • valueは１つの値のことも複数の値のこともある
  • TrendやSeasonalityを抽出して、傾向分析や未来予測に利用する

実装例

  • 純粋なTMBSの実装は存在しない
  • TimescaleDB
    • Relational DB(PostgreDB)がベース
  • influxDB
    • NoSQL DBがベース

利用例

  • System monitoring:
    • telemetry
    • 温度、負荷、Disk IO、Memory使用率
  • Finances:
    • 株価、為替
  • IoT
    • センサーの温度、気圧、湿度、CO2レベル
  • Asset management:
    • Real-TimeデータやHistoricalデータの分析

Trend

  • データの変化

Seasonality

  • Trendの繰り返し

smoothing手法

  • trendやseasonalityを見つけやすくするためにfluctuationを除くことをsmoothingという
  • smoothingしてもoriginal dataは残す

valueの特徴

  • immutable、書き込んだvalueが変更されることはない
  • 時系列でSort済み
  • 多少、データが欠損していても問題ない
  • ACIDは不要なので使われていない

処理の特徴

  • 定期的なINSERTが処理のほとんど
  • UPDATEは使わない