前几天上着班呢，一个过去的同事给我打电话过来，接起电话，就听那边机关枪似得一顿扫射，谈话内容是这样子的。
那个谁，我这里现在有个问题要请教下你，这边有个站，客户要加个需求，就是需要一个搜索的功能，大概搜索的属性差不多有50个左右，不多，没有淘宝那么复杂，比如，我一个冰箱，总有型号吧，根据型号这样子去查找，那么型号就算是一个属性，等等情况，我就想让你从技术角度来给我评估下这个东西难做不，是不是几条关联查询就能搞定？
我这朋友以前是敲代码的，不过代码敲不好，嘴上功夫到真不是盖的，能忽悠，哥们这一通说完，都不带喘气儿的，我这边大气都不敢喘，生怕漏听了一个字，以至一世英名尽毁（开玩笑~），其实听到一半我就知道他讲什么了，其实他还说了很多废话，以上并没有列举。
他讲完了我直接爆粗口，艹，50个属性还不多，惊得身边的同事一阵诧异的看着我…
然后稍微捋了捋思绪，毕竟参加工作加上实习也不过才2年半左右，呵呵..
OK，不就是个搜索技术吗，这还不简单…呵呵，哥还真没做过我说。
不过没吃过猪肉还没见过猪跑吗。
我稍微思索了下提出了第一个方案：
根据你刚才说的，如果只是50个分类的话，那么你这50个分类是否有规则，比如，型号，是数字和字母组合的，品牌呢是中文。。等等。
如果有规则，那么你可以写一套规则出来，比如我输入个123，然后用123去匹配所有的规则，看符合哪几个，然后去分别执行sql查询，通过业务逻辑去拆解他，这是最简单也是最廉价的方法。
这个方法操作起来确实简单些，但如果你们的数据量不大，而且规则能够很好的拆分开来，那么这个方案确实靠谱。
他没给我明确的回复我知道得多给他点时间想想，但我并没有多做等待，直接说了第二个方案：
如果从技术层面来讲就涉及到搜索引擎中的全文搜索技术，就我知道的应该要使用solr来搞，其实也简单不是特别复杂，就是不知道你那边的人能搞不。
他问我solr是什么鬼，什么叫全文搜索技术。
我讲其实全文搜索也就一个名头够吓人的，说白了也简单，但这都是我自己的理解啊，其实除了solr你也可以通过数据库的方式实现全文搜索，当然首先要确定你的数据量不大。
全文搜索顾名思义，就是把一个东西的一部分可供搜索的内容放到一个字段里面，然后搜索的话是模糊搜索这个字段，这是我个人的理解。
举个例子
一个商品：name：冰箱，color：白色，type：sss111，那么我可以搞一个字段keyword：冰箱白色sss111，ok那么你搜索的时候输入型号’sss111’，就可以对这个字段进行like查询，可以匹配到的就是你要查出来的商品。
如果你们数据不多的情况这个方案其实也可行的，毕竟solr的全文搜索就是使用的这个概念，只不过他好在查询速度是数据库中使用like的无数倍，而且他还有可以配置分词器，毕竟一大堆有效的东西拼接在一起搜索起来肯定不是我们想象的那么简单。
针对solr的全文搜索速度，我以前做过一个测试，使用solr做模糊查询300万数据，1秒内返回….数据库的话我就不敢想象了。
就上面我举的例子，按照我们的搜索习惯我们可能直接输入’冰箱sss11’这有就算你用like也查不出来的，而solr的分词器只要你使用的合理就可以完美解决这种问题。
当然你们也可以自己写一套简单的分词器，或者引用一用的分词器去在代码里处理，反正我能想到的方案就这样了。
如果是我的话，我会选择第一个方案结合第二个方案一起去用的，毕竟第一个方案如果一部分规则可以定义好，查询起来还是比全文检索要快不少。
后来挂了电话，他跟我讲他们那边的技术不高兴做第二个方案…我一阵无语…不高兴这个词用的真tm的好。
我问他这种问题怎么不跟他们自己公司的技术沟通，他跟我说他初来乍到，跟他们处的还不熟，得先从我这探探底再去跟他们谈，免得被忽悠。
ok，以上就是这样，这里没有详细的讲solr，之后我会写一套关于solr的基本教程，一方面是给自己做知识梳理，做记录笔记，以供日后查看，另一方面也是把自己知道的分享给大家。