NoSQL误用和常见陷阱分析（转）

NoSQL误用和常见陷阱分析

去哪儿网（Qunar.Com）：孙立

被误用的NoSQL:非常容易出现的错误使用方法

循环网络调用：

Memcached的循环和批量GET对比

Redis的循环和批量GET对比

不压缩大数据:

外部client压缩(外部压缩，可以减小存储，提升IO性能，并且能够提升网络IO性能),

NoSQ存储压缩(NoSQL内部压缩，可以减小存储，提升IO性能，不能提升网络IO性能),

不压缩

跨语言交互：

序列化，压缩与多语言

NoSQL陷阱：NoSQL是一个新兴的话题，大量的NoSQL产品；也都是新出来的，难免出现各式各样的陷阱；不能避免陷阱，但是得掉进去可以爬出来。

官方数据很美好：

官方数据很少提到缺点

官方数据有默认条件：如数据大小

场景错误：

Redis做持久存储

单点、复制问题

数据超过内存性能急剧下降

扩容问题

Redis做Cache存储

性能极高

数据结构丰富

可以持久化、避免雪崩现象

细节描述不清楚：

Ttserver=>兼容memcached协议

不支持memcached的flag参数

早期版本increment与memcached不一致

Stats命令不一致

缓存重建：

系统重启后，大部分请求到磁盘

整个系统的性能可能出现抖动

出现连锁雪崩反应

NoSQL陷阱-32bit问题：

Ttserver-2GB（32bit）：Ttserver在32bit下，到达2g数据大小将出现无法启动的现象

Mongodb-2.5GB(32bit)

版本升级问题：

版本升级带来兼容问题（官方未声明的）

版本升级可能导致适用场景变化

NoSQL与MySQL：

不要犹豫该用MySQL还是NoSQL，在你还没有掌握NoSQL前，最好先在小项目尝试下。

选择NoSQL需要考虑

数据的安全性-是否久经考验，关键业务数据，如订单，支付

事务性的保障

数据的重要性（是否可从其他数据恢复过来）

是否有DBA运维

未来的业务需求变化

性能之争—差别在哪里？：

普通磁盘的IOPS(几百个)

寻道时间、延迟时间

顺序读和顺序写吞吐上百MB/S

NoSQL在普通磁盘的优化：

随机写变顺序写

内存索引-热数据cache

读写算法优化（场景化）

网络协议优化

NoSQL无处不在：

不管你信不信，你很可能早已在接触NoSQL了。

为什么要构建自己的NoSQL：

考察清楚场景和需求

现有产品满足需求成本高

针对特殊场景，也许比想象的简单

可掌控

构建自己的NoSQL：

IP查询：主键已排序的TreeMap<IPEntry,String>(开始IP,结束IP构造成Key)

NoSQL与运维：

并不像官方宣称的那样，NoSQL无需DBA运维

运维NoSQL并不容易：

文档齐全吗？

网上交流多嘛？

周边工具齐全吗？

出现意外问题你能搞定吗？出现意外问题，很难求助到人

监控-运维之本：除了操作系统最基本的监控，还应该监控

IO

CPU

延迟

QPS

抖动

数据量

备份很重要：

避免单点

定期数据库备份

开发前做好切换准备（定义好所有要使用方法的接口，以便达到可切换到其他产品来避免风险）