「RDBMS」と「NoSQL」の比較

【１】「RDBMS」- ACID特性

RDBMS(リレーショナルデータベース管理システム)は、ACID特性という概念に基づいて設計されている。
ACID特性とは、トランザクション処理において必要とされる4つの要素、Atomicity（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（永続性）を頭字語で表したもの。

■ACID特性
要素 説明
A:原子性
(Atomicity)		 トランザクションに含まれるタスクが全て実行されるか、あるいは全く実行されないことを保証する性質。
C:一貫性
(Consistency)		 トランザクション開始と終了時に予め与えられた整合性を満たすことを保証する性質 。
Consistencyは日本語では「一貫性」あるいは「整合性」とも呼ばれる。
I:独立性
(Isolation)		 トランザクション中に行われる操作の過程が他の操作から隠蔽されることを指し、日本語では分離性、独立性または隔離性ともいう。より形式的には、独立性とはトランザクション履歴が直列化されていることと言える。この性質と性能はトレードオフの関係にあるため、一般的にはこの性質の一部を緩和して実装される場合が多い。
D:永続性
(Durability)		 トランザクション操作の完了通知をユーザが受けた時点で、その操作は永続的となり、結果が失われないことを指す。

【２】「NoSQL」 - BASE特性とCAP定理

NoSQLはBASE特性という概念に基づいて設計されている。
クラウド、ビッグデータ処理において、中心的な概念となるのが「BASE特性」と「CAP定理」。

BASE特性とは、「基本的には常に利用可能で、常に整合性を保っている必要はなく、一時的に一貫性のない状態を許容して、結果的には整合性が取れている状態に至る」という特性。
インクトミの創業者、カリフォルニア大学バークレー校の計算機科学の教授エリック・ブリュワー氏が、
「ACID」とは対照的に、可用性や性能を重視した特性を持つ分散システムの特性を「BASE」という文字で表した。

CAP定理はブリュワーの定理とも呼ばれる。分散コンピュータシステムのマシン間の情報複製に関する定理。
ウェブサービスを想定して作られた定理。
2000年にエリック・ブリュワー氏によって提案され、その後、2002年にマサチューセッツ工科大学のセス・ギルバート氏、ナンシー・リンチ氏によって証明されており、定理として確立されている。(CAP定理 - Wikipedia)

■NoSQLのデータモデル
①Key-Valueストア ②Key-Valueストア ③ドキュメントDB
データ
モデル		 Key-Value カラム指向(ワイドカラム) ドキュメント指向(JSON)
特徴 ・データアクセスが高速　
・小さい多数のデータの
　蓄積が得意		 ・一部のものは
　スキーマ定義が必要
・カラム指定での範囲検索、
　集計処理が得意		 ・ドキュメント毎に
　異なるデータ構造を持てる
・属性に対する検索・集計が可能
活用例 ・キャッシュサーバ
・ログ蓄積		 ・大規模データ処理
・ログ蓄積
・ログ分析		 ・ログ分析
・Webシステム
・オンラインゲーム
OSS例 ・memcached
・Redis		 ・Cassandra
・HBase		 ・MongoDB
■BASE特性
要素 説明
(BA)
Basically Available 		基本的にいつでも利用できる。
(S)
Soft-State		 常に整合性を保っている必要はない。
(E)
Eventual Consistency		 結果的には整合性が保証される。

NoSQLの特徴を表している概念として覚えておきたいところ。上記３つの工夫をして、性能をスケールさせていることにより、ビッグデータを扱えるようになっている。

■CAP定理

定義：ノード間のデータ複製において、同時に次の3つの保証を提供することはできない。

保証 説明
C:一貫性
(Consistency)		 全てのノードで同時に同じデータが見える。
A:可用性
(Availability)		 単一障害など一部のノードで障害が起きても処理の継続性が失われない。
P:分断耐性
(Partition-tolerance)		 任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。

CAP定理によると、
分散システムは「C」「A」「P」の3つの保証のうち、同時に2つの保証を満たすことはできるが、
同時に3つの保証すべてを満たすことはできないとされている。

CAP定理により、
データベース管理システムは「CA型」「CP型」「AP型」のいずれかのタイプに分類できる。
RDBMSは「CA型」、NoSQLは主に「CP型」または「AP型」となる。

■CAP定理によってデータベース管理システムのタイプを分類

タイプ 説明
CA型
(C:一貫性とA:可用性を重視)		 データはいつでも利用可能で一貫している。
→単一データベースサーバ
CP型
(C:一貫性とP:分断耐性を重視)		 データを分散しつつも整合性を保持する。
→整合性保持のため、複製中は全てのノードでデータ更新されるまで
　ロックをかけて不整合を阻止する。
→ロックがかかっている最中はAvailableではない。
AP型
(A:可用性とP:分断耐性を重視)		 データは分散され、いつでもデータにアクセスできる
→データ複製中は不整合な状態になり得る。
→Cはある程度妥協する。（Eventual consistency）

■各タイプ別にデータベース管理システムを分類

タイプ データベース管理システム
CA型
(C:一貫性とA:可用性を重視)		 リレーショナル型：Oracle、MySQL、PostgreSQL、SQLServer
カラム指向：Vertica
CP型
(C:一貫性とP:分断耐性を重視)		 Key-Value：Redis、memcached、Scalaris
カラム指向：BigTable、HBase
ドキュメント指向：MongoDB
AP型
(A:可用性とP:分断耐性を重視)		 Key-Value：TokyoTyrant/Cabinet、Dynamo、Voldemort
カラム指向：Cassandra
ドキュメント指向：SimpleDB、CouchDB、Riak

f:id:masawan-guitar:20160814153239p:plain

(参考文献)
『RDB技術者のためのNoSQLガイド』秀和システム

(参考URL)
RDBMSとNoSQLの周辺技術や考え方の整理
http://tanakakns.hatenablog.com/entry/20140502/1399019336
NoSQL、CAP定理、BASE、Eventual Consistencyについて深く考えてみた
http://shunichi-arai.blogspot.jp/2012/09/nosqlcapbaseeventual-consistency.html
IoTに適したNoSQL・分散Key-Valueストア
https://thinkit.co.jp/story/2014/09/25/5280?page=0%2C1
Visual Guide to NoSQL Systems
http://blog.nahurst.com/visual-guide-to-nosql-systems
CAP定理-wikipedia
https://ja.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86
NoSQL登場の背景、CAP定理、データモデルの分類
http://www.publickey1.jp/blog/10/nosqlcap.html
12年後のCAP定理: "法則"はどのように変わったか
https://www.infoq.com/jp/articles/cap-twelve-years-later-how-the-rules-have-changed
CAP定理
http://namihira.hatenablog.com/entry/2013/12/19/233853
クラウドでの新しいACID、そしてBASEトランザクションとCAP定理
http://jyukutyo.hatenablog.com/entry/20090430/1241174854

データベースを分類する２つの軸、４つのエリア

f:id:masawan-guitar:20160812225135p:plain

【１】重視する性能による分類軸

　①ターンアラウンドタイム重視
　　→クエリの応答速度を重視
　②スループット重視
　　→単位時間あたりのデータ処理量を重視

【２】性能拡張モデルによる分類軸

　①「スケールアウト」によって性能拡張できるもの（「スケールアップ」でも性能拡張できる）
　②「スケールアウト」によって性能拡張できないもの（「スケールアップ」でのみ性能拡張できる）

　※「スケールアウト（水平スケール）」とは
　　サーバーの数を増やすことで、サーバー群全体のパフォーマンスを向上させること。
　※「スケールアップ（垂直スケール）」とは
　　性能の高いマシンへと入れ替えたり、メモリやハードディスクを増設したり、
　　CPUをより上位スペックに交換（スペックアップ）したりして、
　　サーバーそのもののパフォーマンスを向上させること。


（参考文献）
　①『RDB技術者のためのNoSQLガイド』秀和システム
www.shuwasystem.co.jp

「分散KVS（Key-Value Store）」と「可視化」 その２

で、今のところの情報を整理してみる。

KVSとはKeyとValueの組み合わせでデータを管理する仕組み。
RDBのデータ構造と比較して、「単純なデータ構造」であるために高速化を実現する。
KVSは、大きく分けて①「揮発性KVS」と②「永続性KVS」がある。

①「揮発性KVS」
オンメモリでデータを扱うデータベース。分散キャッシュサーバ等に使用される。
高速ではあるが、データが一定量を超えた場合や、データベースやOSの再起動などでデータが消去されるものもある。

②「永続性KVS」
オンディスクストレージでデータを扱うデータベース。
揮発性KVSと比較して速度は落ちる。データの記憶容量と永続性の高さが特徴的。

①と②はもちろん用途によって選ぶ。

KVSはRDBよりも安価に大量のデータを保管できるため、データ同士に関連性がないため、分散化のコストが安い。サーバー複数台に分散して保存できるためスケールアウトしやすい。
「スケールアウト」とは、サーバーやネットワークといったインフラの性能を上げる方法の１つ、
「サーバの数を増やすことで、サーバ群全体のパフォーマンスを向上させること」。

・大量のサーバーにKVSを分散させて
　「単純なデータ構造」、「オンメモリ」または「データの記憶容量と永続性」の威力を発揮させる。

・サーバーの数を増やせば増やすほど、①「揮発性KVS」を使いこなせば使いこなすほど
　「単純なデータ構造」と「オンメモリ」の威力を発揮する。
・サーバーの数を増やせば増やすほど、②「永続性KVS」を使用すればするほど
　「単純なデータ構造」と「データの記憶容量と永続性」の威力を発揮する。
・サーバーの数を増やせば増やすほど、「負荷分散」になる。
・サーバーの数を増やせば増やすほど、大量のデータであっても爆速データ処理を実現できる。

上記のようにKVSを分散させた仕組みを「分散KVS」と呼ぶ。ということだろう。たぶん。

今日は可視化の話は無し。

「分散KVS（Key-Value Store）」と「可視化」

データベースにも得意・不得意がある。
KVS(Key-Valueストア)は、RDB（リレーショナルデータベース）と比較して分散化のコストが安く、負荷分散に強く、可用性が高いそうだ。RDBが得意なものはRDBを使う、KVSが得意なものはKVSを使う。そうして、RDBとKVSの両方を使い、そして２つを適材適所で使い分けることにより、補完しあうことで、高速レスポンスを実現できるということになるらしい。

KVSにも弱点はあるが、高速である主なポイントとしてはインメモリ(オンメモリ)であることが挙げられる。
メモリのアクセス速度はHDDの10万~100万倍。そのためRDBの値をKVSに保持して使う。保持する方法は「RDBのレコードをそのままセット」「RDBのレコードを結合または加工してセット」等がある。要するに、データをメモリ内に読み込み、それを使いまわすことで、高速なデータアクセスを実現することが可能らしい。
他にも特徴はあるが今日はここまで調べたという事で。いったんKVSの特徴についての調査は終わりにする。
以下はKVSの活用事例まとめ。

Googleはどのようにして巨大なデータからの検索結果を返しているのか？
分散Key-Valueストアの本命「Bigtable」。
分散Key-Valueストアの本命「Bigtable」 - ＠IT

株式会社ミクシィでは、
RDBMSはMySQL、自社開発のKVS「Tokyo Tyrant」を使用している。
自社開発のKVS「Tokyo Tyrant」は高負荷なログイン処理の実装に使用しているそうだ。
分散Key-Valueストアの本命「Bigtable」（1）：もう1つの、DBのかたち、分散Key-Valueストアとは (1/3) - ＠IT

株式会社フリークアウトでは、
RDBMSはMySQL、KVSはHadoop hBase、Tokyo/Kyoto Product(Tokyo Cabinet、Kyoto Cabinet)、memcached などを使用している。しかも、クラウド全盛の中「自作サーバー」でRTBのシステムを構築・運用しているようだ（ただし海外事業ではAWS（アマゾン ウェブ サービス）も利用している様子）。
「20ms台への挑戦、Webエンジニアがアドテクノロジに惹かれた理由とは」フリークアウト 大窪 聡 氏 | ギークアカデミー ｜IT・Web業界の転職ならDODAエンジニア IT

(以下は引用)
本質的な仕組みは、人間を対象にしたWebサービスのシステムと同じです。ただ、RTBのシステムは非常に時間にシビアな点が違います。Webサービスでシステムが人間を相手にレスポンスを返す場合、1.5～2秒の猶予はあります。ところがRTBでは必ず100ms以内に収めないといけません。私たちのシステムでは平均して20ms程度のレスポンスを実現しています。これだけ短いとMySQLのようなDBMS（データベース管理システム）に接続する時間も取れませんから、KVSの使いこなしが重要になってきます。

www.slideshare.net

ログの可視化関連は多くの企業が
Fluentd、Norikra、Elasticserch、Kibanaを使ってると見受けられた。
以下①~④は概要説明。

①ログ収集「Fluentd」：
　ログの収集、中継ツール、ElasticsearchやNorikraへデータを転送する。
②ログ解析「Norikra」：
　SQLストリーミングを解析する。
③ログ検索「Elasticsearch」：
　大人気の全文検索エンジン。
④ログ可視化「Kibana」：
　Elasticsearchへ格納されたデータを可視化する。

01. CoreOS を使用して Docker を動作させる 『CoreOS インストール』

CoreOS - Docker 実践

f:id:masawan-guitar:20160726191422p:plain

(1) CoreOSのISOファイルをダウンロード

「Booting CoreOS from an ISO 」

    URL) https://coreos.com/os/docs/latest/booting-with-iso.html

    [Download Stable ISO]ボタンを押下し、coreos_production_iso_image.iso をダウンロードします。

    物理サーバーのDVDドライブにCoreOSのISOイメージを焼いたDVDメディアをセットして

    DVDブートします。その後、core ユーザーのコマンド入力画面が表示されます。

(2)暗号化されたパスワードを生成

cloud-config.ymlに(CoreOS) core ユーザー用のパスワードを記述するために生成します。

(例）Mac端末の場合

1.ターミナルで以下を実施します。[ ] でパスワードを入力します。

# openssl passwd -1 > /Users/(UserName)/Desktop/passwd
Password: [ ]
Verifying - Password: [ ]

2.passwdをテキストで開くと 1. で入力したパスワードが暗号化された文字が出力されています。この文字列は後述(4)で使用します。

$1$ClPD0vzI$xKfPvDi3Ey7JvEgqicymo1

(3)SSH認証のための公開鍵と秘密鍵を生成

cloud-config.ymlに公開鍵を記述するために生成します。

・参考

「MacでSSH認証のための公開鍵と秘密鍵を生成する。」

    URL)http://d.hatena.ne.jp/crosshope/20110509/ssh_keygen

(4)cloud-config.ymlを作成

(例)cloud-config.ymlの記述内容

#cloud-config
hostname: coreosDev
coreos:
  update:
    reboot-strategy: best-effort
  units:
  - name: etcd.service
    command: start
  - name: fleet.service
    command: start
  - name: docker.service
    drop-ins:
        - name: "50-insecure-registry.conf"
          content: |
            [Service]
            Environment='DOCKER_OPTS=--insecure-registry="host:port"'
    command: start
  - name: timezone.service
    command: start
    content: |
      [Unit]
      Description=timezone
      [Service]
      Type=oneshot
      RemainAfterExit=yes
      ExecStart=/usr/bin/ln -sf ../usr/share/zoneinfo/Japan /etc/localtime
  - name: 00-eno1.network
    runtime: no
    content: |
      [Match]
      Name=eno1
      [Network]
      DHCP=yes
      [DHCP]
      UseDNS=true
users:
  - name: core
    passwd: *****(※(2)ユーザー用の暗号化されたパスワード)*****  
    groups:
    - sudo
    - docker
    ssh-authorized-keys:
    - ssh-rsa ******(※(3)SSH認証のための公開鍵)*****

(5)core ユーザーのパスワードを追加

$ sudo su -
# whoami
root
# passwd core

(6)cloud-config.yml を CoreOS上へコピー

(例）Mac端末(IP 192.168.1.26)、CoreOS端末(IP 192.168.1.22)の場合

sshでCoreOS端末に接続します。その際、(5)で追加したcoreユーザーのパスワードを入力します。

その後、scp で ファイルをCoreOS上にコピーします。

$ ssh core@192.168.1.22
$ whoami
core
$ scp (Mac端末ユーザー名)@192.168.1.26:/Users/(Mac端末ユーザー名)/Desktop/cloud-config.yml ./cloud-config.yml
$ ls
cloud-config.yml

(7)/dev/sda にCoreOSをインストール

$ whoami
core
$ sudo coreos-install -d /dev/sda -C stable -c ./cloud-config.yml

(8)CoreOS の再起動

$ whoami
core
$ sudo systemctl reboot

 

-- バージョン情報 --
CoreOS(1068.6.0)
$ cat /etc/os-release
NAME=CoreOS
ID=coreos
VERSION=1068.6.0
VERSION_ID=1068.6.0
BUILD_ID=2016-07-12-1826
PRETTY_NAME="CoreOS 1068.6.0 (MoreOS)"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

Docker(1.10.3)

$ docker version
Client:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.4
 Git commit:   3cd164c
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.4
 Git commit:   3cd164c
 Built:
 OS/Arch:      linux/amd64