Ivan, 5) You're right, two different routing values may has to the same shard.
8) About ES filters, this might help: http://www.elasticsearch.org/blog/all-about-elasticsearch-filter-bitsets/ About your mapping question, the put mapping api will allow you to update existing mappings. It can merge, if your new mapping does not conflict with the old one, otherwise, you'll probably need to rebuild the index if there is a conflict. On Monday, January 20, 2014 8:43:41 PM UTC-5, Ivan Ji wrote: > > Hi Bing, > > First, really thanks for your reply. According to the replies, I have few > questions about it below. > > Binh Ly於 2014年1月21日星期二UTC+8上午5時10分10秒寫道： >> >> Ivan, >> > >> 1) The multi_field type allows you to define different ways that a >> *single field value* will be indexed. Your example below will work and will >> index a single value as string/not_analyzed, and then as an int (use >> "integer" for int) >> >> 2) The document coming in will contain a field named "name" with a single >> value. When it goes into the index, it will be indexed 2 different ways. >> >> 3) A mapping is not required to index data. There is an implied default >> mapping that will parse your JSON content and dynamically update the schema >> if you don't specify one up-front. >> >> 4) You cannot change the shard count after the index is created. You can >> change the replica count anytime. The PUT mapping API allows you to change >> the replica count. >> >> 5) You can specify a single routing value for all documents that you want >> to go to a specific shard/location. >> > > Yes, but can I control the two sets of document must be store in > *different* shards? Because if I use different routing values, does it > means it can be stored in different shard? I guest not, right? Although the > hash value of these two values are different, I am not sure what the range > that the routing value belong to a single shard. And I want ti store these > documents in different shard. > > >> >> 6) The number of shards will allow you to scale your content later. So if >> your data volume increases, you can add more nodes later and distribute the >> shards around. If you only have a single shard and you run out of space, >> then you cannot scale out unless you increase storage, or increase the >> shard count. >> >> 7) Scroll is used to do a snapshot type of search - i.e., results you get >> back will not be affected by updates to the index after you start >> scrolling. From/size are useful if you want to do paging of search results >> (or infinite scrolling but paged at a time). >> >> 8) Filters execute fast and yes can be cached. >> > > About filters, I want to know the underlying algorithm. If I create an > alias which represent about half the index, does it increase the index > size? I mean if I create aliases, does it operate and store some really > data about it into the storage? or it just remember the condition and > process like some predefined adapter which cannot store something stored > data inside the storage? > > > Another question: > What's the suggestion if I need to modify the mapping of some index, such > as from store="no" to "yes", or remove some field ? > Because after I read these days, it seems hard to change a existed mapping > and there are much limitation of it. > > Again, thanks for your replies. > > Cheers, > > Ivan > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/a750c783-4e1e-444a-ab8a-9180cb86303f%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
