文天的自留地儿

        很早就知道nosql这个概念，不过一直没太在意。个人感觉在存储方面mysql+memcache只要进行合理的NB的设计，是可以搞定一切的，BUT，这次真的是碰到难题了。不是说mysql搞不定，只是没有达到我心目中的目标。做系统设计和开发也有几年，在查询上，一直的目标就是无联合查询，全部是简单查询，所有查询有索引可用。
        上周四的事了。说说这次需求，因为设计公司方面，所以不具体透露细节。通俗一点吧，就是某个子功能和京东商城的列表有点相的一个玩意，管理员，可以对某个类别商品的自定义参数，任意个数的参数。在列表页中，需要对这些参数进行过滤显示。看似简单，实际比较郁闷。经过几个小时的思考，最终由两种方案，第一是搞定修正产品规则，自定义参数有不可任意，例如，只能在6个以内，其实，6个也真足够了，然后，商品列表对这个几个默认参数全加上索引。很恶心的方案，我自己很不太认同这种方式。第二，就是列表存储基本信息，自定义信息，另外一张表存。过滤的时候，联合查询，这种方式，我也不能接受。因为将来数据量大到一定程度，这种联合查询肯定不现实。我需要的是简单查询，简单，快速，必须的。
        很郁闷的一天，没有想到好的方案。地铁，回家。地铁中，忽然，nosql5个字母闪现。
        第二天到公司，查询了一些资料，对一些nosql产品进行了对比。最终确定MongoDB，文档清晰，使用简单，安装简单，确实的说不需要安装，解压，运行mongod就行。并发、复制，都很不错。先这样，回头进行一些详细的关于MongoDB的使用情况。
==========================PS===============================
                 经过后期多次测试，最终决定放弃使用MongoDB,原因有2，一时我的困难主要在多参数过滤列表查询，但是进过测试mongodb在千万级数据情况下，无索引列表查询性能不够好。二是mongodb占用磁盘空间过高。最终，决定用lucene搭建一套内部搜索引擎，同事解决搜索需求和多条件列表查询。但是，mongodb作为一个分布式的nosql类数据库，各方面还是很优秀的。