Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Forget about database analogies. There's no such thing as a table in elastic search and the analogies just break at multiple levels. A schema is not quite the same as an Index. A type has nothing to do with tables. Rows don't exist anywhere in Lucene, etc.</p> <p>It's better to think in terms of the number of shards, as @monkjack suggests. Indexes, types, and aliases are basically logical means to organize shards. A shard is a more or less independent group of lucene indexes (for each field) that is managed as a whole. Given a collection of documents that go in a type in an index, that collection will be broken into n shards that each have their own set of files (per field). </p> <p>The number of shards that your cluster has to juggle has consequences for memory, number of file handles, etc. A well balanced cluster allocates a small enough amount of shards to each node such that it can utilize its RAM efficiently. So if you have 10 indices, with 10 shards each, you have 100 shards. If they are replicated once, you have effectively 200 shards. So if you have 4 nodes, you have 50 shards per node. Depending how large the shards are that may or may not be a problem. Elastic search is pretty effective handling multiple shards and doing things like indexing concurrently on shards or searching across shards. So, 1 shard per node is probably not that great and a 1000 shards per node is probably going to cause a bit of overhead. More shards means that you can utilize more nodes. If you have only 2 shards and 10 nodes, you are going to have some machines idling. The other way around is probably a better idea. Etc.</p> <p>Index: group of shards. Has replication and shard settings. These are important. They can't be changed after you create the index. Solution if you have to: use aliases, create a new index, reindex the data, switch the alias over, delete the old index.</p> <p>Type: group of documents. Belongs to an index. An Index can have multiple types but they all share the same shards. The number of shards does not change when you create types. Types can occur in multiple indices and you can create queries that span multiple types and indices.</p> <p>Alias: alternative name for one or more indices. This is a very powerful feature that allows you to implement e.g. schema migrations or create a fresh index every day simply by changing the alias to point at the new index. </p> <p>So in your case having thousands of tenants each with their own index is going to result in a massive amount of shards. Probably not the best idea. You don't want a direct link between the number of shards and the number of tenants. You might get away with it only if if load per tenant is trivial, and the number of docs per tenant is insignificant.</p> <p>It's probably a better idea to give each tenant its own type under a single index or multiple indices if you want to have e.g. different quality of service per index. This way you can control the number of shards and keep the tenants isolated at the type level.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhat are the consequences of Elasticsearch various cardinality possibilities of Indexes and Types?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USJilles van Gurp
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhat are the consequences of Elasticsearch various cardinality possibilities of Indexes and Types?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COI really appreciate your great detail level. Would be great if elasticsearch hosted such Q&A for planning/sizing purposes.
      singulars
      1. PO
      1. USgextra
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload