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