Delen via

Databasecursors

  • Artikel

Van toepassing op: ✅Azure Data Explorer-

Een databasecursor is een object op databaseniveau waarmee u meerdere keren een query kunt uitvoeren op een database. U krijgt consistente resultaten, zelfs als er data-append of data-retention bewerkingen parallel met de query's worden uitgevoerd.

Databasecursors zijn ontworpen om twee belangrijke scenario's aan te pakken:

  • De mogelijkheid om dezelfde query meerdere keren te herhalen en dezelfde resultaten te krijgen, zolang de query 'dezelfde gegevensset' aangeeft.

  • De mogelijkheid om een query 'exact één keer' te maken. Met deze query worden alleen de gegevens weergegeven die niet door een vorige query zijn weergegeven, omdat de gegevens toen niet beschikbaar waren. Met de query kunt u bijvoorbeeld alle zojuist aangekomen gegevens in een tabel herhalen zonder dat u bang bent voor het tweemaal verwerken van dezelfde record of het per ongeluk overslaan van records.

De databasecursor wordt in de querytaal weergegeven als een scalaire waarde van het type string. De werkelijke waarde moet als ondoorzichtig worden beschouwd en er is geen ondersteuning voor een andere bewerking dan de waarde ervan op te slaan of de volgende cursorfuncties te gebruiken.

Cursorfuncties

Kusto biedt drie functies om de twee bovenstaande scenario's te implementeren:

  • cursor_current(): gebruik deze functie om de huidige waarde van de databasecursor op te halen. U kunt deze waarde gebruiken als argument voor de twee andere functies.

  • cursor_after(rhs:string): deze speciale functie kan worden gebruikt voor tabelrecords waarvoor het IngestionTime-beleid is ingeschakeld. Het retourneert een scalaire waarde van het type bool die aangeeft of de ingestion_time() databasecursorwaarde van de record na de rhs databasecursorwaarde komt.

  • cursor_before_or_at(rhs:string): deze speciale functie kan worden gebruikt voor de tabelrecords waarvoor het IngestionTime-beleid is ingeschakeld. Het retourneert een scalaire waarde van het type bool die aangeeft of de ingestion_time() databasecursorwaarde van de record vóór of bij de rhs databasecursorwaarde komt.

De twee speciale functies (cursor_after en cursor_before_or_at) hebben ook een neveneffect: Wanneer deze worden gebruikt, verzendt Kusto de huidige waarde van de databasecursor naar de @ExtendedProperties resultatenset van de query. De eigenschapsnaam voor de cursor is Cursoren de waarde ervan is één string.

Bijvoorbeeld:

{"Cursor" : "636040929866477946"}

Beperkingen

Databasecursors kunnen alleen worden gebruikt met tabellen waarvoor het IngestionTime-beleid is ingeschakeld. Elke record in een dergelijke tabel is gekoppeld aan de waarde van de databasecursor die van kracht was toen de record werd opgenomen. Als zodanig kan de functie ingestion_time() worden gebruikt.

Het databasecursorobject bevat geen zinvolle waarde, tenzij de database ten minste één tabel bevat met een IngestionTime-beleid gedefinieerd. Deze waarde wordt gegarandeerd bijgewerkt, indien nodig door de opnamegeschiedenis, in dergelijke tabellen en de query's die worden uitgevoerd, die verwijzen naar dergelijke tabellen. Het kan in andere gevallen wel of niet worden bijgewerkt.

Het opnameproces voert eerst de gegevens door, zodat deze beschikbaar zijn voor het uitvoeren van query's en wijst vervolgens alleen een werkelijke cursorwaarde toe aan elke record. Query's uitvoeren op gegevens direct na opname met behulp van een databasecursor bevatten mogelijk niet de laatste records die zijn toegevoegd omdat de cursorwaarde nog niet is toegewezen. Het ophalen van de huidige databasecursorwaarde kan ook herhaaldelijk dezelfde waarde retourneren, zelfs als de opname is uitgevoerd, omdat alleen een cursordoorvoering de waarde kan bijwerken.

Het uitvoeren van query's op een tabel op basis van databasecursors is alleen gegarandeerd 'werken' (precies eenmaal gegarandeerd) als de records rechtstreeks in die tabel worden opgenomen. Als u gebiedenopdrachten gebruikt, zoals .move extents of .replace extents om gegevens naar de tabel te verplaatsen, of als u .rename tablegebruikt, is het uitvoeren van query's op deze tabel met databasecursors niet gegarandeerd om ontbrekende gegevens te voorkomen. Dit komt doordat de opnametijd van de records wordt toegewezen wanneer deze in eerste instantie wordt opgenomen en niet wordt gewijzigd tijdens de verplaatsingsbewerking.

Wanneer de gebieden naar de doeltabel worden verplaatst, is de toegewezen cursorwaarde mogelijk al verwerkt en mist de volgende query door de databasecursor de nieuwe records.

Voorbeeld: Records exact één keer verwerken

Voor een tabel Employees met schema-[Name, Salary]gebruikt u het volgende proces om continu nieuwe records te verwerken wanneer ze in de tabel worden opgenomen:

// [Once] Enable the IngestionTime policy on table Employees
.set table Employees policy ingestiontime true

// [Once] Get all the data that the Employees table currently holds 
Employees | where cursor_after('')

// The query above will return the database cursor value in
// the @ExtendedProperties result set. Lets assume that it returns
// the value '636040929866477946'

// [Many] Get all the data that was added to the Employees table
// since the previous query was run using the previously-returned
// database cursor 
Employees | where cursor_after('636040929866477946') // -> 636040929866477950

Employees | where cursor_after('636040929866477950') // -> 636040929866479999

Employees | where cursor_after('636040929866479999') // -> 636040939866479000

Verwante inhoud