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 <[email protected]> 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 <[email protected]> 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. 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.
