从MySQL到MongoDB——视觉中国的NoSQL之路.pdfVIP

MySQL~qMongoDB 一 视觉中国的NoSQL之路 ■ 文 ，潘凡 起 因 维护量，如何有效监控和管理这些节点又成了新的问题。虽 视觉中国网站(www．chinavisua1．com)是国内最大的创意 然虚拟化可以解决部分问题，但还是不能令人满意； 人群的专业网站。2009年以前，同很多公司一样，我们的 除了MySQL，能否找到一个更为简单、轻便的瑞士军 CMS~I：]社区产品都构建于PHP+Nginx+MySQL之上；MySQL 刀呢?我们的目光投向了NoSQL的方案。 使用7Master+Master的部署方案；前端使用自己的pHp)fli架 进行开发；Memcached作为缓存；Nginx进行WebfiE务和负 候选方案 载均衡；Gearman进行异步任务处理。在传统的基于静态内 最初，对于NoSQL的候选方案，我依据关注和熟悉程 容 (如文章，资讯，帖子)的产品，这个体系运行 良好。通 度，并且在甄别和选择合适的方案时特别制定了一些原则： 过分级的缓存，数据库端实际负载很轻。2009年初，我们进 是否节省系统资源，对于CPU等资源是否消耗过大；客户 行了新产品的开发。此时，我们遇到了如下一些问题。 端／AP1支持，这直接影响应用开发的效率；文档是否齐全， 用户数据激增：我们I~MySQL某个信息表上线1个月的 社区是否活跃；部署是否简单；未来扩展能力。按以上几点 数据就达到千万。我们之前忽略的很多数据，在新形势下需 经过一段测试后，我们候选名单中剩下Redis、MongoDB和 要跟踪记录，这也导致了数据量的激增； Flare。 用户对于信息的实时性要求更高：对信息的响应速度 Redis对丰富数据类型的操作很吸引人，可以轻松解决 和更新频度就要求更高。简单通过缓存解决的灵丹妙药不 一 些应用场景，其读写性能也相当高，唯一缺点就是存储能 复存在； 力和内存挂钩，这样如果存储大量的数据需要消耗太多的内 对于Scale．out的要求更高：有些创新产品的增长速度 存 (最新的版本已经不存在这个问题)。 是惊人的。因此要求能够无痛的升级扩展，否则一旦停机， Flare的集群管理能力令人印象深刻，它可 以支持节 那么用户流失的速度也是惊人的； 点的动态部署 ，支持节点 的基于权重 的负载均衡 ，支持 大量文件的备份工作：我们面向的是创意人群，产生的 数据分 区。同时允许存储大的数据，其key的长度也不受 内容是以图片为主。需要能够对这些图片及不同尺寸的缩略 Memcached的限制。而这些对于客户端是透明的，客户端 图进行有效的备份管理。我们之前使用的Linuxinotify+rsync 使用Memcached协议链接到FIare的proxy节点就可以了。由 的增量备份方案效果不佳； 于使用集群，Flare支持fail--over，当某个数据节点宕掉， 需求变化频繁：开发要更加敏捷，开发成本和维护成本 对于这个节点的访问都会 自动被proxy节点forward~0对应的 要更低，要能够快速地更新进化，新功能要在最短的周期内 后备节点，恢复后还可以自动同步。Flare的缺点是实际应用 上线。 案例较少，文档较为简单，目前只在Geek使用。 最初，我们试图完全通过优化现有的技术架构来解决 以上方案都打算作为一个优化方案，我从未想过完全放 以上问题：对数据时效性进一步分级分层缓存，减小缓存 弃MySQL。然而，用MongoDB做产品的设计原型后，我彻 粒度；改进缓存更新机制 (线上实时和线下异步更新)提 底被征服了，决定全面从MySQL迁移到MongoDB。 高缓存命 中率；尝试对业务数据的特点按照水平和垂直进 行分表；使用MogileFS进行分布存储；进一步优化Mysql 为什么MongoDB可以替代MySQL? 的性能，同时增加MySQL节点等。但很快发现 ，即便实 MongoDB