the5fire

前几天开始自己在做些日志的分析的小玩具，要分析手搜的用户访问情况，工具很简单，处理逻辑也很简单——从kafka拿nginx日志，然后处理完保存的数据库中，然后以易读的方式展现。

唯一的难点就是数据量比较大，实现依然使用熟悉的Django+xadmin，这个可以省去页面的开发时间，我只需要写脚本，转化数据就ok。前两天弄完跑了一下，结果比想象的差，虽然只是单线程的方式来消费kafka的数据，但是也确实太慢了。跑了一天才处理完50w日志。并且Django+MySql也有一个问题，数据量太大的话列表页加载就会比较慢。

一开始做之前有考虑用mongodb或者redis来写数据，但是还是考虑到实现成本（主要是懒），直接用最熟悉的。demo做完觉得不错，现在可以考虑写入速度的问题了。于是想到MongoEngine以及它对Django的支持，开始折腾，折腾良久发现确实不妥，定义好的Model要改，xadmin也不能用了，最后终于发现这个东西，那感觉跟当初用上xadmin一样一样滴。

就是这个东西：http://django-nonrel.org/

Making Django run on non-relational databases

简直不能再好，无痛迁移，最重要的是xadmin依然能用。有兴趣的可以去看看。

说到下午这通折腾，当时用了MongoEngine出品的Django-Mongoengine，说是支持admin，尝试下吧，发现有点坑，尤其是关于admin.site.registe的部分。另外还有一个就是PyDanny出品的一个django-mongonaut，这哥们就是之前做Django-Admin2的那个大牛。关于admin2的事可以看这个：http://www.the5fire.com/django-admin2-died-and-django-xadmin-continue.html. 不过说实话，这个mongonaut感觉也不好用。不过这哥们的那本关于Django的书还是挺好的。

一下午一通折腾，一通的看源码，发现这俩（mongonaut，MongoEngine）都做了太多的定制，model也改，admin也改，form也改。个人感觉，针对于这种典型的MVC结构的框架，尤其是对于Django来说，只需要保证Model层提供的接口就ok了。不是有句话吗，叫：不管是不是鸭子，只有能嘎嘎叫，那就是鸭子。对于这个理论上也是这样的，只要保证了model层返回的对象所具有上层的行为就ok，那整个框架就能跑的起来。

不过Django-nonrel的源码我还没看，不清楚实现逻辑是什么。不过思想是不变的，还是得说到MVC，这个最重要的就是上下层解耦，从而通过替换下层Model的实现达到使用不同类型的数据，比如这货。另外，这货是从Django上fork出来的一个项目，单独切出分支来做的开发。

最后补充一句：数据已经跑上了，速度很快，明天可以看看结果。