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 (32 bit)
版本升级问题：
版本升级带来兼容问题（官方未声明的）
版本升级可能导致适用场景变化

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
抖动
数据量
备份很重要：
避免单点
定期数据库备份
开发前做好切换准备（定义好所有要使用方法的接口，以便达到可切换到其他产品来避免风险）