Elasticsearch
Verschil tussen indices en typen

Het is gemakkelijk om type als een tabel in een SQL-database te zien, waarbij de index de SQL-database is. Dat is echter geen goede manier om type s te benaderen.

Alles over typen

Typen zijn letterlijk slechts een metagegevensveld dat door Elasticsearch aan elk document is toegevoegd: _type . De bovenstaande voorbeelden hebben twee typen gemaakt: my_type en my_other_type . Dat betekent dat elk document dat aan de typen is gekoppeld, een extra veld heeft dat automatisch wordt gedefinieerd als "_type": "my_type" ; dit wordt geïndexeerd met het document, waardoor het een doorzoekbaar of filterbaar veld wordt , maar het heeft geen invloed op het onbewerkte document zelf, dus uw toepassing hoeft zich er geen zorgen over te maken.

Alle typen leven in dezelfde index en dus in dezelfde collectieve scherven van de index. Zelfs op schijfniveau leven ze in dezelfde bestanden. De enige scheiding die het maken van een tweede type biedt, is logisch. Elk type, of het nu uniek is of niet, moet bestaan in de toewijzingen en al die toewijzingen moeten in uw clusterstatus bestaan. Dit verbruikt geheugen en, als elk type dynamisch wordt bijgewerkt, eet het prestaties op als de toewijzingen veranderen.

Daarom is het een goede gewoonte om slechts één type te definiëren, tenzij u daadwerkelijk andere typen nodig hebt. Het is gebruikelijk om scenario's te zien waarbij meerdere typen wenselijk zijn. Stel je bijvoorbeeld voor dat je een auto-index had. Het kan handig zijn om het op te splitsen in meerdere typen:

• BMW
• chevy
• honda
• mazda
• mercedes
• nissan
• RangeRover
• toyota
• ...

Op deze manier kunt u naar alle auto's zoeken of deze op aanvraag door de fabrikant beperken. Het verschil tussen deze twee zoekopdrachten is zo eenvoudig als:

GET /cars/_search

en

GET /cars/bmw/_search

Wat niet voor de hand ligt voor nieuwe gebruikers van Elasticsearch is dat de tweede vorm een specialisatie van de eerste vorm is. Het wordt letterlijk herschreven om:

GET /cars/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "term" : {
            "_type": "bmw"
          }
        }
      ]
    }
  }
}

Het filtert eenvoudig elk document uit dat niet is geïndexeerd met een veld _type waarvan de waarde bmw . Aangezien elk document wordt geïndexeerd met het type als het veld _type , dient dit als een vrij eenvoudig filter. Als in beide voorbeelden daadwerkelijk was gezocht, dan zou het filter worden toegevoegd aan de volledige zoekopdracht.

Daarom is het veel beter om, als de typen identiek zijn, een enkel type te leveren (bijvoorbeeld de manufacturer in dit voorbeeld) en dit effectief te negeren. Geef vervolgens binnen elk document expliciet een veld op met de naam make of een andere naam die u verkiest en filter er handmatig op wanneer u het wilt beperken. Dit verkleint de grootte van uw toewijzingen tot 1/n waarbij n het aantal afzonderlijke typen is. Het voegt nog een veld toe aan elk document, ten voordele van een overigens vereenvoudigde afbeelding.

In Elasticsearch 1.x en 2.x moet een dergelijk veld worden gedefinieerd als

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "string",
        "index": "not_analyzed"
      }
    }
  }
}

1. De naam is willekeurig.
2. De naam is willekeurig en kan overeenkomen met de typenaam als u deze ook wilde.

In Elasticsearch 5.x werkt het bovenstaande nog steeds (het is verouderd), maar de betere manier is om te gebruiken:

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "keyword"
      }
    }
  }
}

1. De naam is willekeurig.
2. De naam is willekeurig en kan overeenkomen met de typenaam als u deze ook wilde.

Typen moeten spaarzaam worden gebruikt binnen uw indices omdat het de index-mappings opzwelt, meestal zonder veel voordeel. Je moet er minstens één hebben, maar er is niets dat zegt dat je er meer dan één moet hebben.

Algemene vragen

• Wat als ik twee (of meer) typen heb die grotendeels identiek zijn, maar die een paar unieke velden per type hebben?

Op indexniveau is er geen verschil tussen het ene type dat wordt gebruikt met een paar velden die schaars worden gebruikt en tussen meerdere typen die een aantal niet-schaarse velden delen met een paar niet-gedeelde (wat betekent dat het andere type het veld zelfs niet gebruikt (s)).

Anders gezegd: een dun gebruikt veld is schaars over de index, ongeacht de typen . De schaarsheid komt de index niet ten goede, of doet deze ook echt geen pijn, alleen maar omdat deze in een apart type is gedefinieerd.

U moet deze typen gewoon combineren en een apart typeveld toevoegen.

• Waarom moeten afzonderlijke typen velden op exact dezelfde manier definiëren?

Omdat elk veld eigenlijk maar één keer wordt gedefinieerd op Lucene-niveau, ongeacht hoeveel typen er zijn. Het feit dat typen überhaupt bestaan is een kenmerk van Elasticsearch en het is slechts een logische scheiding.

• Kan ik afzonderlijke typen definiëren met hetzelfde veld anders gedefinieerd?

Nee. Als u erin slaagt om een manier te vinden om dit te doen in ES 2.x of hoger, moet u een bugrapport openen . Zoals opgemerkt in de vorige vraag, ziet Lucene ze allemaal als een enkel veld, dus er is geen manier om dit op de juiste manier te laten werken.

ES 1.x liet dit achter als een impliciete vereiste, waardoor gebruikers voorwaarden konden creëren waarbij de toewijzingen van een scherf in een index feitelijk verschilden van een andere scherf in dezelfde index. Dit was in feite een race-situatie en het kon tot onverwachte problemen leiden.

Uitzonderingen op de regel

• Bovenliggende / onderliggende documenten vereisen dat afzonderlijke typen binnen dezelfde index worden gebruikt.
  • De ouder leeft in één type.
  • Het kind leeft in een apart type (maar elk kind leeft in dezelfde scherf als zijn ouder).
• Extreem niche use cases waarbij het creëren van tonnen indices ongewenst is en de impact van schaarse velden te verkiezen is boven het alternatief.
  • Bijvoorbeeld, de Elasticsearch monitoring plugin, Marvel (1.x en 2.x) of X-Pack Monitoring (5.x +), controleert Elasticsearch zelf op veranderingen in het cluster, knooppunten, indices, specifieke indices (het indexniveau), en zelfs scherven. Het zou elke dag 5+ indices kunnen maken om die documenten met unieke toewijzingen te isoleren of het zou in strijd kunnen zijn met best practices om de clusterbelasting te verminderen door een index te delen (let op: het aantal gedefinieerde toewijzingen is in feite hetzelfde, maar het aantal gecreëerde indices wordt gereduceerd van n tot 1).
  • Dit is een geavanceerd scenario, maar u moet rekening houden met de definities van gedeelde velden voor verschillende typen!