NoSQLについてまとめてみる 〜後編〜
前回からの続きです。
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を比較しています。
Memcachedは非常にシンプルでメモリ効率が良い一方、メモリフラグメンテーション、LRU性能、監視しやすさといった点ではRedisに軍配があがるとのこと。
Redisは会社でもたまに耳にするので、今度触ってみたいです。
Column Store
列方向のaggregationが優秀らしい。（名前の通りか）
CassandraとHBaseの比較をしている以下のSlideShareがわかりやすかったです。
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の話も、後々まとめたいです。
Graph Store
Facebookのお友達つながりなんかを表現するのに向いてるグラフです。あまり馴染みがないのですが、以下のブログが具体的なイメージの参考になりました。
グラフDBのNeo4jを1日触ってみた - Wantedly Engineer Blog
こうした複雑な関係性をRDBMSで表現しようとすると骨が折れそう、というか無理ですね。
今回は、各モデルについてちょっとずつ言及する形で代表的なDBをまとめました。
実際に触ってみることで得られる知見もあると思うので、手を動かしていきたいですね。
