fst

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前言 很多使用Elasticsearch的同学会关心数据存储在ES中的存储容量，会有这样的疑问：xxTB的数据入到ES会使用多少存储空间。这个问题其实很难直接回答的，只有数据写入ES后，才能观察到实际的存储空间。比如同样是1TB的数据，写入ES的存储空间可能差距会非常大，可能小到只有300~400GB，也可能多到6-7TB，为什么会造成这么大的差距呢？究其原因，我们来探究下Elasticsearch中的数据是如何存储。文章中我以Elasticsearch 2.3版本为示例，对应的lucene版本是5.5，Elasticsearch现在已经来到了6.5版本，数字类型、列存等存储结构有些变化，但基本的概念变化不多，文章中的内容依然适用。 Elasticsearch索引结构 Elasticsearch对外提供的是index的概念，可以类比为DB，用户查询是在index上完成的，每个index由若干个shard组成，以此来达到分布式可扩展的能力。比如下图是一个由10个shard组成的index。 shard是Elasticsearch数据存储的最小单位，index的存储容量为所有shard的存储容量之和。Elasticsearch集群的存储容量则为所有index存储容量之和。

一、概述 ​ 从源码中，我们可以看出来。目前，Dubbo 内部提供了 5 种序列化的方式，分别为 fastjson、Hessian2、Kryo、fst 及 Java原生支持的方式 。 ​ 针对不同的序列化方式，对比内容如下： 名称 优点 缺点 Hessian 性能较好，多语言支持（推荐使用） Hessian的各版本兼容性不好，可能和应用使用的Hessian冲突，Dubbo内嵌了hessian3.2.1的源码 fastjson 纯文本，可跨语言解析，缺省采用FastJson解析 性能较差 kryo 速度快，序列化后体积小 跨语言支持较复杂 fst 兼容JDK序列化协议；序列化速度快；体积小； jdk Java原生支持；无需引入第三方类库； 性能较差 ​ 从成熟度上来说，Hessian 和 Java 相对成熟一些，可用于生产环境。 二、Dubbo serialization 实现 ​ 整体的代码结构比较清晰，按照不同类型的序列化方式，划分成了多个子模块。根据模块的名称，想必你也能够知道该模块是什么序列化方式。接下来，我们一一进行解读： 2.1 API 模块 ​ 他们的依赖关系如 UML 图库直接看出来，DataInput 和 DataOutput 接口类，主要是针对基本类型数据进行序列化和反序列化。ObjectInput 和 ObjectOutput 分别继承 DataInput 和

学习目标 掌握词项、短语查询建议器的用法 掌握自动补全建议器的用法 查询建议介绍 查询建议是什么？ ES中查询建议的API 查询建议也是使用_search端点地址。在DSL中suggest节点来定义需要的建议查询。 POST twitter/_search { "query" : { "match": { "message": "tring out Elasticsearch" } }, //定义建议查询 "suggest" : { "my-suggestion" : { //一个建议查询名 "text" : "tring out Elasticsearch", //查询文本 "term" : { //使用词项建议器 "field" : "message" //指定在哪个字段上获取建议词 } } } } POST _search { "suggest": { "my-suggest-1" : { "text" : "tring out Elasticsearch", "term" : { "field" : "message" } }, "my-suggest-2" : { "text" : "kmichy", "term" : { "field" : "user" } } } } 多个建议查询可以使用全局的查询文本 POST _search { "suggest": {