MongoDB在电子商务网站（Magento）中实际应用的设想之log表数据

        Magento系统原生自带了一批以"log_"为前缀的日志表，用来记录登录用户的网站访问信息，访客的网站访问信息和所有被访问页面的url信息等。

        

        利用Magento的事件(Event-Observer)机制,每次页面被访问，或者用户登录等等动作发生的时候，每一次的动作都会被记录进这些日志表，当网站流量到达一定规模后，会带来两个问题，第一，这几张日志表的体积会急剧膨胀，轻松突破G级别，给数据库的备份还原的操作带来麻烦。第二，网站的高流量意味着系统在不停的往数据库做插入操作，给数据库带来相当大的负载压力，而且这个压力会随着流量的继续升高而加大。针对第一个问题，Magento本身提供了日志清理的机制，可以设定日志保存的时间，实际的运作方式是利用Linux的Cron Job，定时来查找数据库中已经过期的数据，然后运行脚本删除。在NoSql流行的今天，这种处理过期数据的方式就显得相当笨拙了（Magento诞生于2007年，大多数人都不知NoSql为何物的年代）。针对第二个问题，我知道的情况是有一些Magento的使用者索性关闭了日志模块，这些就断绝了往日志表写入的过程。这种做法效果很好（这是废话），但在现在这个人人都谈“大数据”的时代，为了降低服务器压力就索性不记录日志的做法过于极端了，不记录数据，做数据分析也就无米下锅了。PS：关掉日志模块后受影响的系统功能反而影响倒不大。

        

        针对这个情况，我的设想就是用MongoDB来代替Mysql来存储这些数据，减轻（或者说分担）主数据库Mysql的压力，同时MongoDB相比于Mysql的写入速度优势，有助于提高网页的加载速度(这点估计作用很小，不过聊胜于无，实际效果要看具体实测)。另外， 关于处理过期数据，可以用MongoDB的固定集合（capped collection）来做日志数据的存放集合，限制集合大小或者集合中文档总数量，可以保证在无需额外干涉的情况下，日志数据也不会无限制的膨胀。要做到精确控制集合中的文档过期时间的话，给固定集合再加持TTL索引，就可以轻松搞定了。

        数据结构方面，既然准备用MongoDB代替Mysql来存储数据，设计方面自然也要利用MongoDB的特性了，Magento的原生log表，根据关系型数据库的范式，设计了一对多数据分表来存储，读取时通过表关联获取数据。比如log_url和log_url_info表。这种一对多的关系，在MongoDB中可以用内嵌子文档的方式（这个不绝对，实际还要具体情况具体分析）来存储，读取时不再需要做表连接（同时MongoDB也不支持），一个程序里的对象只对应MongoDB的一个文档。

        Magento原生系统功能中，需要用到这几张日志表的，只有后台用户的最后登录时间显示，后台在线用户数量和信息显示以及后台的REPORT报告（我暂时已知的，可能有遗漏）。再将日志转换成由MongoDB来保存以后，这些功能点的代码需要针对MongoDB做修改（也要看到时候设计的文档结构）。

        最后还有会受到影响的是数据分析师们，以前抓日志数据是用sql在mysql里获取，转换之后就变成要用MongoDB的查询语言来抓取了。我个人是觉得，做数据分析的要跟得上时代发展，学会MongoDB（以及其他的流行NoSql）是必须滴，死抱着sql不放必然被淘汰。

        以上同样还只是设想，希望自己年内能把这些设想全部实现。