whybangbang的专栏

Shard Overallocation这节讲shard间的平衡问题，先假设你建了一个indexPUT /my_index{  "settings": {    "number_of_shards":   2,     "number_of_replicas": 0  }}这个index有两个shard 0个replicas官方把2 shard放 1 nod

13 One Big User（这里阐述了如何在已经有数据的情况转移数据了）数据量大，访问量大的index都是从小的开始的，一天，我们有个index非常大了，现在也许它需要自己的shard了aliase可以使得我们在应用透明的情况下悄无声息的把数据转移到单独的一个index中。（1）创建一个单独的index，设置主分片，根据数据情况设置PUT /baking_v1{  "s

shared index我们可以考虑采用一个大的集群来放这些数据，然后通过一个标记来filter这些数据PUT /forums{  "settings": {    "number_of_shards": 10   },  "mappings": {    "post": {      "properties": {        "forum_id": {

14-scale is not infinite（扩展不是无限的）虽然这这整个章节都在说scale的方法，但多数的scale问题都可以通过加入多个node解决，但是有个资源是非常有限的，必须慎重考虑：the cluster statethe cluster state 是一个数据结构，保存了如下信息：集群的设置信息每个node的信息indices，mappings analyz

Retiring Data在time-based中，数据关联性很小，maybe我们只关心我们现在的数据。最近3天 1周 1个月。。。你可以选择的办法是直接删除掉旧的index。。。DELETE /logs_2013*删除整个index会比删除一条条doc快很多也爽很多，但明显SB才这样做。。。所以下面的办法才是官方建议的migrate old indices 转移旧inde

User-Based Data人们开始使用es的原因一般都是因为现有应用需要加入全文检索了，然后他们创建了一个index来放他们的所有文档，逐渐的，公司的其他人也认识到了es的好处，他们也把他们的数据加了进来。幸运的是es支持多租户的操作，所以新的用户可以在cluster中拥有自己的index，有时候，有些用户需要对所有用户数据搜索，他们可以通过所有index搜索，但通常他们只对自己的in

这节开始抠我等的伤疤。。。这是所有刚用ES的user都头疼的问题：TMD，我该用几个shard好，，，、有土豪竟然想先建1000个shard在一台计算机上，你Y是银河N代吧多一个shard是有代价的一个shard是一个lucene的index，所以会消耗memory cpu and so on每个请求都会发送到每个shard上，你让一堆shard去找一个奶吃，可能吗？聚合方

Index Templates这节就说了index模版的使用，因为我们会因为数据量增大，新加index，虽然es会自动设置mapping，但我们总有一些定制化的东西，定义模版就能为后面的index服务。我们定义好一个模版然后使用即可，官方的例子PUT /_template/my_logs {  "template": "logstash-*",   "order":    1,

直到现在我们一直都在说shard的事情，不是还有replicas吗？现在开始讨论，replicas的作用是提高可用性，也就是做数据备份，防止丢失，如果有个shard挂掉了，它的replica就会顶替他的位置。在index过程中，replica和shard做了基本一样的事情，新文档进来先index进入shard，然后该shard的replica自动把数据备份到自己的索引中，记住：增加replic

容量计划1个太少，1000太多，咋办呢？作者回答是：i don’t know其实是由很多因素决定的，你使用的硬件，文档大小和复杂度，索引的方式，查询的方式，聚合的要求等等可以采用下面这种办法自己去计算一下吧：（1）创建一个cluster就一个机器，而且这个机器必须和生产用的配置相同（2）创建一个index，设置和分析器等都和生产相同，而且是1shard 0replicas（

多索引查询，理论的最后一节了，下节开始实例啦es没有规定说你只能用一个index的，其实在我们请求一个index的时候，es把请求重定向到了这个cluster中的所有shard和replicas中，当我们把请求发送给多个index道理其实也一样。可以这样说，查询一个有50个shard的索引和查询50个只有一个shard的索引的情况是一样的。这个性质的一个用处就是，如果哪天你觉得你的in

在Dynamically Updatable Indices 这节，我们说了在es中一个shard其实是lucene中的一个索引，所以在es中你们创建了一个索引其实是一堆shard的集合。你请求es，es则把请求交给相应的shard去处理。the unit of scale is shard,小规模数据其实一个shard就够，而且能放很多数据，但限制scale的能力假设创建一个这样的clu

前言总的来讲，这一章主要就是来给讲述es横向扩展方面的问题也就是scale out，对于需要了解es集群方面非常有帮助关注点：    es在横向扩展方面基本是可以平滑过度的painless    但当你从一个大点的集群到一个非常大的集群的时候，需要计划和设计，但相对而言是平滑过度的    es也有很多限制和要求，好刀用在刀刃上就好，否则也有很多问题    默认设置是可以让你

12faking index per user with Aliases为了保持我们的设计简单而且干净，我们更想让我们的应用相信我们给每个用户一个index，即使我们其实真的仅仅使用了一个index，我们需要一种办法隐藏routing和forum_idaliase可以做这件事PUT /forums/_alias/baking{  "routing": "baking",