Q&A服务引发的肝爆（一）-一一网

全程以问答的方式呈现给大家，为了尽量通俗易懂，尽量大白话描述，写作不易，童鞋们轻喷。

为什么要做QA问答服务？
难点是什么？
MongoDb和Mysql以及Elasticsearch选型对比？
Elasticsearch使用场景，特点，数据类型
项目中怎么使用Elasticsearch落地的？下篇待续。。

一、为什么要做QA问答服务？

荒腔走板
某年某月某日又是努(mo)力(yu)的一天，EIP-CM奖金系统需要增加一个功能，Q&A问答，在后台编辑好标题和答案，然后在小程序端通过标题可以搜索所有相关的文章，收到需求的我，暗中窃喜，作为刚到项目组的我终于可以一展强悍的CRUD功底，自信的独揽全活，并报上工时，2hour，正当我脑海自动生成crud的代码时，老板灵机一动，这个Q&A得做成单独服务通用起来,实现各个系统之间调用，满足各个服务动态表单的拓展，what？这种功能还要做成公用服务？心中一万个崇(bu)拜(fu)。

二、难点是什么？

言归正传
因为项目中很多服务有用到Q&A回答功能（类似于灵活表单），所以想把它抽离出来做成公用微服务，那么既然要做通用，就有以下几个痛点：

具备全文搜索，既能匹配小程序端搜索的分词功能，又要满足后台的模糊匹配和精确匹配。
满足通用化，字段必须保证是灵活可变的，字段层级是未知的。
字段嵌套怎么存储，怎么做查询。
普通关系型数据库是否能解决需求。
不只是QA服务，之后类似于这种内容服务都可以通用。
码字码累了，暂时就缓缓。。待续。

三、技术选型？

1)要搜索还不简单，来感受下几个数据库的内心独白？

Mysql：
搜索：
- like做模糊，match做全文索引不就行了吗。
字段灵活性：
- 我承认我是关系型数据库，抱歉打扰了
MongoDb:
搜索，字段灵活性：
- Mysql的搜索功能我都有，而且我是Nosql数据库，可以存储并且查询灵活字段和嵌套关系，并且支持，聚合，天然分布式，事务。
分词：
- 对不起，打扰了。
Elasticsearch：
- 人狠话不多，除了事务，你们有的我都有，选我选我。
- 我放佛听到了Elasticsearch最真挚的独白，后期是想用上ELK日志套件，所以决定再研究下。

四、Elasticsearch使用场景，特点，数据类型

Elasticsearch能干嘛？

分布式的实时文件存储，每个字段都被索引且可用于搜索。
分布式的实时分析搜索引擎，海量数据下近实时秒级响应。
简单的restful api，天生的兼容多语言开发。
易扩展，处理PB级结构化或非结构化数据。
大白话：ElasticSearch引入了Lucene的jar包，具备Lucene 功能，屏蔽了Lucene 复杂的底层逻辑，在此基础上又做了分布式，Restful等等一系列强大功能，具体怎么强大，我们来研究下呗。

Elasticsearch的适用场景？

站内搜索（电商，招聘，门户，等等）
)GitHub（开源代码管理），搜索上千亿行代码
BI系统，商业智能，Business
日志数据分析
商品价格监控网站

Elasticsearch的特点

可以作为一个大型分布式集群（数百台服务器）技术，处理PB级数据，服务大公司；也可以运行在单机上，服务小公司
Elasticsearch不是什么新技术，主要是将全文检索、数据分析以及分布式技术，合并在了一起，才形成了独一无二的ES；lucene（全文检索），商用的数据分析软件（也是有的）
对用户而言，是开箱即用的，非常简单，作为中小型的应用，直接几分钟部署一下ES，就可以作为生产环境的系统来使用了，数据量不大，操作不是太复杂
数据库的功能面对很多领域是不够用的（事务，还有各种联机事务型的操作）；特殊的功能，比如全文检索，同义词处理，相关度排名，复杂数据分析，海量数据的近实时处理；Elasticsearch作为传统数据库的一个补充，提供了数据库所不不能提供的很多功能

Elasticsearch 有关的主要可用字段数据类型？

字符串数据类型，包括支持全文检索的 text 类型和精准匹配的 keyword 类型。
数值数据类型，例如字节，短整数，长整数，浮点数，双精度数，half_float，scaled_float。
日期类型，日期纳秒Date nanoseconds，布尔值，二进制（Base64编码的字符串）等。
范围（整数范围 integer_range，长范围 long_range，双精度范围 double_range，浮动范围 float_range，日期范围 date_range）。
包含对象的复杂数据类型，nested 、Object。
GEO 地理位置相关类型。
特定类型如：数组（数组中的值应具有相同的数据类型）

再次分析下几个数据库的优缺点：

ES的特点，正如其名，那就是搜索。严格的说，ES不是一个数据库，而是一个搜索引擎，ES的方方面面也都是围绕搜索设计的。ES支持全文搜索，这里简单解释下什么是全文搜索：对于“我在北京的一家互联网公司工作”这样的数据，如果你搜索“北京”、“互联网”、“工作”这些关键词都能命中这条数据的话，这就是全文搜索，你每天都在用的百度、Google都属于全文搜索。值得一提的是，ES的全文搜索对中文也有很好的支持（单是中文分词器就有很多种），绝对能够满足国内大多数人的全文搜索需求。除了搜索之外，ES还会自动的替你对所有字段建立索引，以实现高性能的复杂聚合查询，因此只要是存入ES的数据，无论再复杂的聚合查询也可以得到不错的性能，而且你再也不用为如何建立各种复杂索引而头痛了。
说了这么多ES的优点，你是不是觉得ES简直万能了？
可惜不是的，ES也有很多的短处，最明显的就是字段类型无法修改、写入性能较低和高硬件资源消耗。前边讲到ES会自动的替你建立索引，尽管这能给全文搜索以及聚合查询带来很多好处还能替你省了建索引这一麻烦事，但是这个特性也会带来一堆问题。ES需要在创建字段前要预先建立Mapping，Mapping中包含每个字段的类型信息，ES需要根据Mapping为字段建立合适的索引。由于这个Mapping的存在，ES中的字段一但建立就不能再修改类型了。（例如，你建的数据表的某个字段忘了加全文搜索，你想临时加上，但是表已经建好并且已经有很多数据了，这时候该怎么办呢？不好意思，你只能把整个数据表删了再重建一遍！）因此，ES在数据结构灵活度上高于MySQL但远不如MongoDB。ES的缺点还不止这些，自动建立索引使得ES的写入性能也收到了影响，要明显低于MongoDB。对于同样的数据ES占用的存储空间也要明显大于MongoDB（建那么多索引能不占空间吗？），对硬件资源的消耗也是非常厉害，大数据量下64G内存+SSD基本是标配，算得上是数据库中的贵族服务了喽！
ES的全文搜索特性使它成为构建搜索引擎的利器。除此之外，ES很好的支持了复杂聚合查询这一特点还使得ES非常适合拿来作数据分析使用。其实，ES还专门做了与自己配套的ELK套装，给你提供从日志收集到数据可视化分析的一条龙服务，绝对是构建高大上数据分析平台的利器。但是，ES的高成本和低写入性能这些缺点也注定了它不适合用在那些数据价值不高、对写入性能有要求、数据量大而成本受限的场景中。