fengchang 发布的文章

ElasticSearch: Index 和 Type 的区别

原文: Index vs. Type By Adrien Grand
译者: fengchang

对于 ES 的新用户来说,有一个常见的问题:要存储一批新的数据时,应该在已有 index 里新建一个 type,还是给它新建一个 index?要想回答这个问题,我们必须先理解这两者是怎么实现的。

过去,我们为了让 ES 更容易理解,经常用关系型数据库做一个比喻: index 就像关系型数据库里的 database, type 就像 database 里的 table。但是这并不正确。由于两种数据库存储数据的方式是如此不同,任何比喻都是没有意义的。这种比喻往往会导致对 type 的滥用。

Index 是什么

Index 存储在多个分片中,其中每一个分片都是一个独立的 Lucene Index。这就应该能提醒你,添加新 index 应该有个限度:每个 Lucene Index 都需要消耗一些磁盘,内存和文件描述符。因此,一个大的 index 比多个小 index 效率更高:Lucene Index 的固定开销被摊分到更多文档上了。

另一个重要因素是你准备怎么搜索你的数据。在搜索时,每个分片都需要搜索一次, 然后 ES 会合并来自所有分片的结果。例如,你要搜索 10 个 index,每个 index 有 5 个分片,那么协调这次搜索的节点就需要合并 5x10=50 个分片的结果。这也是一个你需要注意的地方:如果有太多分片的结果需要合并,或者你发起了一个结果巨大的搜索请求,合并任务会需要大量 CPU 和内存资源。这是第二个让 index 少一些的理由。

Type 是什么

使用 type 允许我们在一个 index 里存储多种类型的数据,这样就可以减少 index 的数量了。在使用时,向每个文档加入 _type 字段,在指定 type 搜索时就会被用于过滤。使用 type 的一个好处是,搜索一个 index 下的多个 type,和只搜索一个 type 相比没有额外的开销 —— 需要合并结果的分片数量是一样的。

但是,这也是有限制的:

  • 不同 type 里的字段需要保持一致。例如,一个 index 下的不同 type 里有两个名字相同的字段,他们的类型(string, date 等等)和配置也必须相同。
  • 只在某个 type 里存在的字段,在其他没有该字段的 type 中也会消耗资源。这是 Lucene Index 带来的常见问题:它不喜欢稀疏。由于连续文档之间的差异太大,稀疏的 posting list 的压缩效率不高。这个问题在 doc value 上更为严重:为了提高速度,doc value 通常会为每个文档预留一个固定大小的空间,以便文档可以被高速检索。这意味着,如果 Lucene 确定它需要一个字节来存储某个数字类型的字段,它同样会给没有这个字段的文档预留一个字节。未来版本的 ES 会在这方面做一些改进,但是我仍然建议你在建模的时候尽量避免稀疏。[1]
  • 得分是由 index 内的统计数据来决定的。也就是说,一个 type 中的文档会影响另一个 type 中的文档的得分。

这意味着,只有同一个 index 的中的 type 都有类似的映射 (mapping) 时,才应该使用 type。否则,使用多个 type 可能比使用多个 index 消耗的资源更多。

我应该用哪个

这是个困难的问题,它的答案取决于你用的硬件、数据和用例。首先你要明白 type 是有用的,因为它能减少 ES 需要管理的 Lucene Index 的数量。但是也有另外一种方式可以减少这个数量:创建 index 的时候让它的分片少一些。例如,与其在一个 index 里塞上 5 个 type,不如创建 5 个只有一个分片的 index。

在你做决定的时候可以问自己下面几个问题:

  • 你需要使用父子文档吗?如果需要,只能在一个 index 里建立多个 type。
  • 你的文档的映射是否相似?如果不相似,使用多个 index。
  • 如果你的每个 type 都有足够多的文档,Lucene Index 的开销可以被分摊掉,你就可以安全的使用多个 index 了。如果有必要的话,可以把分片数量设小一点。
  • 如果文档不够多,你可以考虑把文档放进一个 index 里的多个 type 里,甚至放进一个 type 里。

总之,你可能有点惊讶,因为 type 的使用场景没有你想象的多,这是正确的。由于我们上面提到原因,在一个 index 中使用多个 type 的情景其实很少。如果你的数据有不同的映射,那就给他们分配不同的 index。但是请记住,如果不需要很高的写入吞吐量,或者存储的文档数量不多,你可以通过减少 index 的分片来使集群中的分片数量保持合理。


[1] posting list 和 doc value 都是 Lucene 的压缩技术,原理是保存后一个文档和前一个文档的差异,而不是完整的文档。

API自动化测试利器——Postman

自从开始做API开发之后,我就在寻找合适的API测试工具。一开始不是很想用Chrome扩展,用的WizTools的工具,后来试过一次Postman之后就停不下来了,还买了付费的Jetpacks。推出Team Sync Beta之后我又把这个工具推广给团队,作为API文档使用。看到中文网络上关于这个工具的文章并不多,于是决定写一篇小文介绍一下。

一、基本功能

Postman的功能在文档中有介绍。不过文档略啰嗦,这里简单介绍一下主界面,入门功能就都提到了。
postman_mark.png

- 阅读剩余部分 -

PHP:设置Location导致状态码被修改为302

最近在试着做RESTful API,学了很多平时用不到的HTTP知识。在一个API上,我想用409 Conflict表示要创建的资源已经存在。这是一个挺冷门的状态码,在B/S结构中基本上用不到。RFC 2616对它的解释是:

409 Conflict

The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict and
resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem; however, that might not be
possible and is not required.

《RESTful Web APIs》这本书在409 Conflict的解释中写到:

响应报头:如果该冲突是由于某些其他资源的存在(比如,客户端尝试创建的某个特定的资源已经存在了)而造成的话,那么Location报头应该链接到该资源的URL:也就是说,冲突的来源。

- 阅读剩余部分 -

微信内Web App自动登录

最初是在Tower.im的公众号里见到了WebApp自动登录,想做一个同样效果的。那时候对公众号开发不熟悉,问了一些人也说的稀里糊涂的,文档又乱,最后花了好长时间才实现。这个功能需要的接口是「网页授权获取用户基本信息」,需要认证企业号才能使用。如果没有权限的话可以试一下微信之门,我也只是知道这个东西,从来没试过。

基本的思路是通过公众号OAuth API获取用户微信的openid。第一次使用的时候让用户登录,然后在数据库里把openid和自己应用的userid对应起来。以后获得用户的openid之后就可以自动登录到对应的用户上。

我的Web App是用AngularJS实现的SPA,登录之后获取一个token放在localStorage,给后端发请求的时候,把token写在Header的Authorization里。

这个过程中不需要使用Cookie,但是为了减少跳转次数,还是用了Cookie。我把和微信登录相关的功能写在了几个PHP单页里,用一个redirect.php做入口,把要跳转的页面放在参数里,由redirect.php检查用户是否已经获得了token,在获取到token之后跳转到目标页面。

登录流程图如下:

- 阅读剩余部分 -

从一行JavaScript代码生成随机字符串说起

今天在写JS的时候,要生成一个随机字符串,JavaScript中没有PHP的uniqid()方法,我Google了一下,在Stack Overflow上看到了一个很漂亮的函数,只有一行:

function generateUIDNotMoreThan1million() {
    return ("0000" + (Math.random()*Math.pow(36,4) << 0).toString(36)).slice(-4)
}

这种代码以前都copy来直接用,不过今天读到一篇《从一行CSS调试代码中学到的JavaScript知识》,觉得还蛮有意思的,我也试着来解读一下这行代码。

- 阅读剩余部分 -