Here are my 2 ¢
The type feature of an index was invented to allow cross-search over
document types without adding another whole Lucene index.
Imagine a library catalog. If you have books, you have fields like title,
author, publisher, subject, extent, identifier etc. So, you can create an
index "catalog" with a basic type "book". Then, you can add a type
"serials", which have a slightly changed mapping, consider ISSN, numbering,
issues/volumes etc. Then, you can add a type "CD", e.g. with field
length/duration of an audio book, or digital format information. And so on.
As a result, you can search with a single query in an index over types with
different document sizes, and this saves space regarding _source.
The advantage of types is that you can create a basic mapping and extend
this dynamically in the future without changing the docs that are already
indexed. You do not even have to know the final set of types that may have
to be added later when creating the index and this makes it very flexible.
The type feature is good for all use cases where you have to store document
types in a single collection, which might share fields with other types,
and you want to save the overhead of extra shards or index aliasing. The
_uid field (an internal field) provides special caching performance
features for filtering the types in an index.
Jörg
On Mon, Dec 15, 2014 at 4:40 PM, fye fyemaple@gmail.com wrote:
Appreciate it David!
Would love to hear more opinions form others. So far I have not seen
enough benefits (other than avoiding to have too many indexes) to justify
the complexity that adding the type level brings in.
feng
On Friday, December 12, 2014 3:00:58 PM UTC-5, David Pilato wrote:
Sometimes, people have to search accross multiple enterprise applications.
Each application write in a given index and can manage many type of
documents.
So it's more a convenient way to separate things. Have one index per type
in some cases could be strange if you indexed only a few docs.
That said, if you can have one single type per index, I think it's
better. You will avoid collisions between fields within the same index. I
mean a field X can belong to type1 and another field X to type2. But you
could imagine different rules for each (one is a String, the other a Date).
Here you can start having some troubles.
My 2 cents.
David
Le 12 déc. 2014 à 20:43, fye fyem...@gmail.com a écrit :
Gurus,
would you shed some lights for a newbie. What is the top benefits of
adding the level of 'type' beyond one level Lucene index? What are the top
use cases that requires multiple types (schemas) within one index?
thanks!
--
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 elasticsearc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/e99e4a35-4ee9-42b1-b619-63225cd315f5%
40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/e99e4a35-4ee9-42b1-b619-63225cd315f5%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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 elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/d99b0d8e-010f-401c-8514-23b3e5f219d1%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/d99b0d8e-010f-401c-8514-23b3e5f219d1%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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 elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFRA1z9xFmjvCH-99Hqg-_3CkrYNLbmStUD8KTuW8RR%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.