键值存储对比秘籍，速来围观！🔍🔍🔍

说实话，这堆玩意儿看着挺乱...但挑个适合自个儿的，得琢磨琢磨。

你看Redis啊，这玩意儿是跑内存的，所以贼快。
我之前做项目用Redis存缓存，那查询速度真不是盖的，几毫秒就搞定。
它还支持不止字符串，像列表啊、集合啊、哈希这些都能存。
不过要注意，它得用持久化，不然一重启数据全没了。
搞个RDB快照或者AOF日志，选哪个看你要恢复多少，RDB快但恢复慢点，AOF慢但数据新。
还有个发布订阅挺有用，搞消息队列啥的。
分布式这块，现在大厂都用主从复制加哨兵模式，搞得很稳。

再比如MongoDB，这属于文档存储，数据格式跟JSON差不多，挺方便。
我之前搞过个项目，数据结构一变，直接扔MongoDB里就行，不用改代码。
它支持索引，啥单键、复合、地理空间都能整。
还有聚合查询，虽然没SQL强，但也能跑点GROUP BY类似的操作。
复制和分片也是标配，分布式弄起来容易。

Cassandra呢，这玩意儿是分布式存储，特别适合要搞大数据量的。
我看过一个银行系统用Cassandra存交易数据，跨机房复制，一点不抖。
你要是数据量特别大，还老写，Cassandra很合适。
它支持宽列存储，就是数据结构可以搞复杂点。

DynamoDB是亚马逊出的云数据库，托管式，你不用管底层啥的。
它有个特点是单表设计，就是不用提前设计好表结构，跑起来快。
自动扩展也挺牛逼，负载一上来，它自己加机器。
全球复制也能整，跨区域数据同步。

Couchbase呢，这玩意儿是文档+键值存储，内存这块优化得不错。
我试过用它做用户会话缓存，挺顺。
还支持同步，比如你手机上改了数据，电脑上也能看到。
分布式架构也挺稳。

CosmosDB是微软的云数据库，支持更多种数据模型，文档、图形、键值这些都能存。
它全球分发做得挺溜，跨Azure区域复制，高可用也做得好。
弹性扩展这块，按需加机器，省心。

HBase是基于Hadoop的，适合那种数据量特别大的场景。
我看过一个电商用HBase存用户行为数据，几亿条都能跑。
它高吞吐量，适合读多写少的。
实时查询也能支持，但可能不如Redis快。

Firestore是谷歌的云数据库，实时同步做得不错，离线也能用。
数据模型很灵活，不用定义啥模式。
查询也强大，复杂点也能跑。
安全性这块，访问控制、加密都有。
适合那种用云的多。

ScyllaDB是Cassandra的加强版，性能比Cassandra好。
我用过测试环境，感觉写速度特别快。
它也支持分布式和水平扩展。

CouchDB是另一个文档存储，简单易用。
它支持多主复制，就是多个节点都能写。
冲突解决机制也挺有意思，数据一冲突，它给你提示。
模式也没要求，跑起来就完事。

Zookeeper不是典型的键值存储，但它是个分布式协调服务。
我搞微服务的时候，用它做配置管理，挺方便。
命名服务、分布式锁这些都有。
集群管理也能做，节点状态看着明白。

ETCD也是分布式键值存储，但主要用来共享配置和服务发现。
它高可用，支持多副本。
安全性这块做得挺细，SSL/TLS都有。
监控告警也支持，服务出问题能及时知道。

Riak是另一个分布式存储，高可用和容错性做得不错。
它支持多副本复制，自动故障转移。
数据模型也挺灵活，桶和键随便组合。
查询也支持二级索引，比较复杂。

FoundationDB性能也很强，基于C++写的。
跨平台支持得也好，啥系统都能跑。
API和工具也丰富，自定义数据模型、事务处理都能整。
分布式架构也是标配。

总结一下吧...你要是追求极致性能，比如做缓存啥的，Redis肯定要看看。
你要是数据结构复杂，文档存储MongoDB或者Couchbase可能更合适。
你要是搞大数据量、分布式，Cassandra或者HBase得考虑。
你要是用的云，DynamoDB或者CosmosDB省心。
你要是实时同步、离线访问要紧，Firestore可以考虑。
你要是跟Hadoop生态集成，HBase是老伙计了。
你要是追求简单，CouchDB不错。
你要是微服务协调，Zookeeper用得上。
你要是共享配置，ETCD是好选择。
你要是数据量特别大，Riak或者FoundationDB也可以看看。

恒讯科技介绍：NoSQL数据库的四种类型

昨天晚上，我试着用手机查附近咖啡店的优惠券，那App刷得飞快，一会儿就跳出来了。
等我想选一家试试，发现它用的就是键值存储，简单粗暴，找东西就是按名字搜，直接对上号，速度真不是盖的。
想想看，要是查个朋友电话，翻本小本子或者按字母顺序找，肯定没这么快。
这让我想起NoSQL里头那几种数据库。

比如键值（KV）存储，这就是最基本的那种。
你想想，手机里存联系人，一个名字就是一个键，对应的电话号码或者微信就是值。
这种数据库就是干这个的，存取都很快。
我上次用个做缓存的服务，就是把热门商品信息存成键值对，想看哪个商品，直接按名字去拿，嗖一下就有结果了。
它适合那种数据量大，但关系简单的场景，比如用户session啊，或者缓存啊。
但你要是想查查某个用户买了啥，又买了谁的东西，它就有点搞不定了，因为它不擅长处理那些关联关系。

再比如文档存储，这就好比给每个联系人不光存电话，还存了地址、备注这些，形成一个完整的资料，像Word文档那样。
我有个朋友做旅游的，他们就用这种，一个景点就是一个文档，里面有图片、描述、评价，都放一块儿了。
这种数据库没固定格式，想加个字段或者删个字段都挺方便的。
但你要是想查所有在北京的景点，它也得一个一个找，效率就不如键值存储了。
它适合那种数据结构复杂，但不需要强关联的场景。

还有列族存储，这就好比把所有联系人的信息都按类型分好类，比如电话号码放一块儿，地址放一块儿，备注放一块儿。
我看过一个做大数据分析的团队用这种，他们把用户的各种行为数据都按时间顺序存成列，想分析某个时间段用户都干了啥，就从这个列里查，效率很高。
这种数据库适合处理那种数据量大，但查询模式固定的场景，比如日志分析啊，时间序列数据啊。
但你要是想查某个用户的电话和地址，它就得去两个不同的列里找，稍微麻烦点。

最后是图数据库，这就好比把所有联系人之间的关系都画成一张网。
我看过一个做社交网络的用这种，你想找某个人的所有朋友，或者朋友的朋友，它直接从这张网上一通连，马上就找到了。
这种数据库特别擅长处理那种关系复杂的数据，比如社交网络、推荐系统。
但你要是数据量太大，这张网太复杂了，它扩展起来就有点费劲。

等等，还有个事，我上次看一个文章说，NoSQL数据库选型真是个技术活儿，得根据你的具体需求来。
比如你要是就存取键值对，那键值存储就够用了；你要是数据结构复杂，那文档存储可能更合适；你要是处理日志数据，列族存储可能就是最佳选择；你要是处理关系数据，那还得考虑是不是该用图数据库。
这事儿吧，还真不能一概而论。

我突然想到，现在很多公司都用混合型数据库，就是根据不同的需求，用不同的数据库。
比如用键值存储做缓存，用文档存储存用户信息，用列族存储存日志，用图数据库做社交推荐。
这样既发挥了各种数据库的优点，又避免了它们的缺点。
这倒是挺有意思的。

总的来说，NoSQL数据库这四种类型各有各的特点，用对了地方，都能发挥很大的作用。
但选型这事儿，真得看情况，不能光看数据库本身，还得看你的业务需求。
你要是业务需求变了，可能还得换数据库呢。
这倒是挺考验技术人员的眼力的。
等等，现在技术发展这么快，说不定过几年，又出什么新的数据库类型了呢？这事儿，还真不好说。

典型非关系型数据库包括

非关系型数据库种类多，各有专长。

键值存储最简单，Redis用得多，缓存常用。
Memcached内存快，没持久化，短期用。
DynamoDB自动扩，亚马逊出品，大场面。

列存储分列存，Cassandra抗造，日志常用。
HBase大数据，物联网数据行。
文档数据库灵活，MongoDB火，内容管理用。
CouchDB离线好，移动端常用。

图形数据库强，Neo4 j厉害，社交网络用。
ArangoDB多模型，架构简单明。

搜索引擎Elasticsearch，全文检索顶配。
时序数据库InfluxDB，监控数据王道。

自己掂量。