Amazon OpenSearch-service ontgrendelt veilig realtime zoeken, monitoren en analyseren van zakelijke en operationele gegevens voor gebruiksscenario's zoals applicatiemonitoring, loganalyse, observatie en zoeken op websites.

In dit bericht onderzoeken we het OR1-instantietype, een voor OpenSearch geoptimaliseerd exemplaar geïntroduceerd op 29 november 2023.

OR1 is een instantietype voor Amazon OpenSearch-service dat een kosteneffectieve manier biedt om grote hoeveelheden gegevens op te slaan. Een domein met OR1-instanties gebruikt Amazon Elastic Block Store (Amazon EBS) volumes voor primaire opslag, waarbij de gegevens synchroon worden gekopieerd Eenvoudige opslagservice van Amazon (Amazon S3) zoals het aankomt. OR1-instanties bieden een hogere indexeringsdoorvoer met een hoge duurzaamheid.

Voor meer informatie over OR1, zie de inleidende blogpost.

Terwijl u actief naar een index schrijft, raden wij u aan één replica te behouden. U kunt echter na een rollover overschakelen naar nulreplica's en de index wordt niet langer actief geschreven.

Dit kan veilig worden gedaan omdat de gegevens voor duurzaamheid in Amazon S3 worden bewaard.

Houd er rekening mee dat in het geval van een defect en vervanging van een knooppunt uw gegevens automatisch worden hersteld vanuit Amazon S3, maar gedeeltelijk niet beschikbaar zullen zijn tijdens de reparatie. U moet dit dus niet overwegen in gevallen waarin zoekopdrachten op niet-actief geschreven indices een hoge beschikbaarheid vereisen. .

Doel

In deze blogpost onderzoeken we hoe OR1 de prestaties van OpenSearch-workloads beïnvloedt.

Door segmentreplicatie te bieden, besparen OR1-instanties CPU-cycli door alleen op de primaire shards te indexeren. Door dat te doen, kunnen de knooppunten meer gegevens indexeren met dezelfde hoeveelheid rekenkracht, of minder bronnen gebruiken voor indexering, waardoor er meer beschikbaar is voor zoek- en andere bewerkingen.

Voor dit bericht gaan we rekening houden met een werklast die zwaar is voor indexering en enkele prestatietests uitvoeren.

traditioneel, Amazon Elastic Compute Cloud (Amazon EC2) R6g-instanties zijn een goed presterende keuze voor zware werkbelastingen die indexeren en vertrouwen op Amazon EBS-opslag. Im4gn-instanties bieden lokale NVMe SSD voor schijfschrijfbewerkingen met hoge doorvoer en lage latentie.

We zullen de OR1-indexeringsprestaties vergelijken met betrekking tot deze twee instantietypen, waarbij we ons alleen op de indexeringsprestaties concentreren voor de reikwijdte van deze blog.

Setup

Voor onze prestatietests hebben we meerdere componenten opgezet, zoals weergegeven in de volgende afbeelding:

Voor het testproces:

De indextoewijzing, die deel uitmaakt van onze initialisatiestap, is als volgt:

{
  "index_patterns": [
    "logs-*"
  ],
  "data_stream": {
    "timestamp_field": {
      "name": "time"
    }
  },
  "template": {
    "settings": {
      "number_of_shards": <VARYING>,
      "number_of_replicas": 1,
      "refresh_interval": "20s"
    },
    "mappings": {
      "dynamic": false,
      "properties": {
        "traceId": {
          "type": "keyword"
        },
        "spanId": {
          "type": "keyword"
        },
        "severityText": {
          "type": "keyword"
        },
        "flags": {
          "type": "long"
        },
        "time": {
          "type": "date",
          "format": "date_time"
        },
        "severityNumber": {
          "type": "long"
        },
        "droppedAttributesCount": {
          "type": "long"
        },
        "serviceName": {
          "type": "keyword"
        },
        "body": {
          "type": "text"
        },
        "observedTime": {
          "type": "date",
          "format": "date_time"
        },
        "schemaUrl": {
          "type": "keyword"
        },
        "resource": {
          "type": "flat_object"
        },
        "instrumentationScope": {
          "type": "flat_object"
        }
      }
    }
  }
}

Zoals je kunt zien, gebruiken we een gegevensstroom om de rollover-configuratie te vereenvoudigen en de maximale primaire shardgrootte onder 50 GiB te houden, volgens 'best practices'.

We hebben de mapping geoptimaliseerd om onnodige indexeringsactiviteiten te voorkomen en de plat_object veldtype om te vermijden explosie van veldkartering.

Ter referentie, de Indexstatusbeheer (ISM) het beleid dat we hebben gebruikt is als volgt:

{
  "policy": {
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [
          {
            "rollover": {
              "min_primary_shard_size": "50gb"
            }
          }
        ],
        "transitions": []
      }
    ],
    "ism_template": [
      {
        "index_patterns": [
          "logs-*"
        ]
      }
    ]
  }
}

Onze gemiddelde documentgrootte is 1.6 KiB en de bulkgrootte is 4,000 documenten per bulk, wat neerkomt op ongeveer 6.26 MiB per bulk (ongecomprimeerd).

Testprotocol

De protocolparameters zijn als volgt:

• Aantal dataknooppunten: 6 of 12
• Parallellisme van banen: 75, 40
• Aantal primaire shards: 12, 48, 96 (voor 12 knooppunten)
• Aantal replica's: 1 (totaal 2 exemplaren)
• Instantietypen (elk met 16 vCPU's):
  • of1.4xgrote.zoekopdracht
  • r6g.4xlarge.zoeken
  • im4gn.4xlarge.search

Merk op dat het im4gn-cluster de helft van het geheugen heeft van de andere twee, maar dat elke omgeving nog steeds dezelfde JVM-heapgrootte heeft van ongeveer 32 GiB.

Resultaten van prestatietests

Voor de prestatietests zijn we begonnen met 75 parallelle opdrachten en 750 batches van 4,000 documenten per klant (in totaal 225 miljoen documenten). Vervolgens hebben we het aantal shards, dataknooppunten, replica's en taken aangepast.

Configuratie 1: 6 gegevensknooppunten, 12 primaire shards, 1 replica

Voor deze configuratie hebben we 6 gegevensknooppunten, 12 primaire shards en 1 replica gebruikt. We hebben de volgende prestaties waargenomen:

In deze tabel wordt benadrukt dat im4gn- en r6g-clusters een zeer hoog CPU-gebruik hebben, wat triggering veroorzaakt toelatingscontrole, dat het document afwijst.

De OR1 laat zien dat de CPU onder de 80 procent blijft, wat een zeer goed doelwit is.

Dingen om in gedachten te houden:

• Vergeet tijdens de productie niet opnieuw te indexeren met exponentiële uitstel om te voorkomen dat niet-geïndexeerde documenten verloren gaan vanwege periodieke afwijzingen.
• De bulkindexeringsbewerking retourneert 200 OK, maar kan gedeeltelijke fouten veroorzaken. De hoofdtekst van het antwoord moet worden gecontroleerd om te valideren dat alle documenten met succes zijn geïndexeerd.

Door het aantal parallelle opdrachten terug te brengen van 75 naar 40, terwijl we 750 batches van 4,000 documenten per klant behouden (totaal 120 miljoen documenten), krijgen we het volgende:

De doorvoer en het CPU-gebruik zijn afgenomen, maar de CPU blijft hoog op Im4gn en R6g, terwijl de OR1 meer CPU-capaciteit laat zien.

Configuratie 2: 6 gegevensknooppunten, 48 primaire shards, 1 replica

Voor deze configuratie hebben we het aantal primaire shards verhoogd van 12 naar 48, wat zorgt voor meer parallelliteit bij het indexeren:

De indexeringsdoorvoer nam toe voor de OR1, maar de Im4gn en R6g zagen geen verbetering omdat hun CPU-gebruik nog steeds erg hoog is.

Door de parallelle taken terug te brengen tot 40 en 48 primaire shards te behouden, kunnen we zien dat de OR1 iets meer druk krijgt naarmate de minimale CPU toeneemt van 12 primaire shards, en de CPU voor R6g ziet er veel beter uit. Voor de Im4gn is de CPU echter nog steeds hoog.

Configuratie 3: 12 gegevensknooppunten, 96 primaire shards, 1 replica

Voor deze configuratie zijn we begonnen met de oorspronkelijke configuratie en hebben we meer rekencapaciteit toegevoegd, van 6 knooppunten naar 12 en het aantal primaire shards verhoogd naar 96.

De OR1 en de R6g presteren goed met een CPU-gebruik van minder dan 80 procent, waarbij OR1 33 procent betere prestaties levert met 30 procent minder CPU-gebruik vergeleken met R6g.

De Im4gn zit nog steeds op 90 procent CPU, maar de prestaties zijn ook erg goed.

Als we het aantal parallelle banen terugbrengen van 75 naar 40, krijgen we:

Door het aantal parallelle taken terug te brengen van 40 naar 75, kwamen de OR1- en Im4gn-instanties op hetzelfde niveau en kwam de R6g heel dichtbij.

Interpretatie

De OR1-instanties versnellen de indexering omdat alleen de primaire shards hoeven te worden geschreven terwijl de replica wordt geproduceerd door segmenten te kopiëren. Hoewel ze beter presteren in vergelijking met Img4n- en R6g-instanties, is het CPU-gebruik ook lager, wat ruimte geeft voor extra belasting (zoeken) of vermindering van de clustergrootte.

We kunnen een OR6-cluster met 1 knooppunten met 48 primaire shards, indexerend met 178 documenten per seconde, vergelijken met een Im12gn-cluster met 4 knooppunten met 96 primaire shards, indexerend met 187 documenten per seconde, of met een R12g-cluster met 6 knooppunten met 96 primaire shards, indexerend met 156 documenten per seconde.

De OR1 presteert bijna net zo goed als het grotere Im4gn-cluster, en beter dan het grotere R6g-cluster.

Hoe u de grootte kunt aanpassen bij het gebruik van OR1-instanties

Zoals u in de resultaten kunt zien, kunnen OR1-instanties meer gegevens verwerken met hogere doorvoersnelheden. Wanneer u het aantal primaire shards vergroot, presteren ze echter niet zo goed vanwege de externe back-upopslag.

Om de beste doorvoer van het OR1-instantietype te verkrijgen, kunt u grotere batchgroottes gebruiken dan normaal, en een Index State Management (ISM)-beleid gebruiken om uw index op basis van grootte om te zetten, zodat u effectief het aantal primaire shards per bestand kunt beperken. inhoudsopgave. U kunt ook het aantal verbindingen vergroten, omdat het OR1-instantietype meer parallellisme aankan.

Voor zoeken heeft OR1 geen directe invloed op de zoekprestaties. Zoals u kunt zien, is het CPU-gebruik echter lager op OR1-instanties dan op Im4gn- en R6g-instanties. Dat maakt meer activiteit mogelijk (zoeken en opnemen), of de mogelijkheid om de instantiegrootte of het aantal te verkleinen, wat zou resulteren in een kostenbesparing.

Conclusie en aanbevelingen voor OR1

Het nieuwe OR1-instantietype geeft u meer indexeringskracht dan de andere instantietypen. Dit is belangrijk voor zware werkbelastingen, waarbij u elke dag batchgewijs indexeert of een hoge aanhoudende doorvoer heeft.

Het OR1-instantietype maakt ook kostenbesparing mogelijk omdat de prijs voor prestaties 30 procent beter is dan die van bestaande instantietypen. Wanneer u meer dan één replica toevoegt, zal de prijs voor prestaties afnemen omdat de CPU nauwelijks wordt beïnvloed door een OR1-instantie, terwijl bij andere instantietypen de indexeringsdoorvoer afneemt.

Bekijk de volledige instructies voor het optimaliseren van uw werklast voor indexering met behulp hiervan artikel opnieuw plaatsen.

Over de auteur

Cédric Pelvet is een Principal AWS Specialist Solutions Architect. Hij helpt klanten bij het ontwerpen van schaalbare oplossingen voor realtime gegevens en zoekworkloads. In zijn vrije tijd houdt hij zich bezig met het leren van nieuwe talen en het oefenen van de viool.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://aws.amazon.com/blogs/big-data/opensearch-optimized-instance-or1-is-game-changing-for-indexing-performance-and-cost/