tikedaのめう

日頃得られた知見と気付きをdumpするところ

NoSQLについてまとめてみる 〜後編〜

前回からの続きです。

tikeda-meu.hatenablog.com

 

NoSQLは、モデルによって大きく4種類に分けられます。

それぞれの特徴をざっと表にしました。

?はケースバイケースです。

種類 スケーラビリティ 性能 柔軟性 (高い表現力) 簡易さ
Key-Value Store o o x o
Column Store o o x o
Document Store o ? o o
Graph Store ? ? o x

 

次に代表的なDBを取り上げてみます。

Key-Value Store (KVS)

以下の記事ではantirez氏が同じKVS型DBのMemcachedとRedisを比較しています。

yakst.com

Memcachedは非常にシンプルでメモリ効率が良い一方、メモリフラグメンテーション、LRU性能、監視しやすさといった点ではRedisに軍配があがるとのこと。

Redisは会社でもたまに耳にするので、今度触ってみたいです。

Column Store 

列方向のaggregationが優秀らしい。(名前の通りか)

CassandraとHBaseの比較をしている以下のSlideShareがわかりやすかったです。

www.slideshare.net

pp. 55~が比較スライドとなっている。耐障害性や性能、手動・自動の違いがあったりなど、Column Store型の中でも違いが大きいらしい。障害発生時の挙動が異なるようなので、ユースケースごとに使い分けるべき?

Document Store 

MongoDBやElasticsearchがこれにあたる。個人的には一番馴染みが深い。PostgreSQLもDocument orientedに分類される?のか...? (RDBかと思っていたが、要確認)

特にMongoDBは、性能をとる代わりに、結果の整合性やトランザクションがサポートされていないです。

Elasticsearchは高性能・高スケーラビリティな全文検索エンジンで、通常の検索だけでなく、集計処理やソート、スコアリングといった処理も高速に可能です。実態はLucene Indexが動いていて、裏でsegments mergingなど起こったりしています。

あと余談ですが、ElasticsearchはCAP定理でいうPを落としている(と思われます。)というのもnode全体の生存監視やshardsの管理をするMaster nodeと候補となりうるMaster eligible nodeがそれぞれ分断された場合、分断後のネットワークらはどちらも動作可能であるからです。

Elasticsearchの話も、後々まとめたいです。

qiita.com

Graph Store 

Facebookのお友達つながりなんかを表現するのに向いてるグラフです。あまり馴染みがないのですが、以下のブログが具体的なイメージの参考になりました。

グラフDBのNeo4jを1日触ってみた - Wantedly Engineer Blog

こうした複雑な関係性をRDBMSで表現しようとすると骨が折れそう、というか無理ですね。

 

今回は、各モデルについてちょっとずつ言及する形で代表的なDBをまとめました。

実際に触ってみることで得られる知見もあると思うので、手を動かしていきたいですね。