trvalost ADO.NET zrnitosti

Článek
07/03/2024

Back-endový kód Orleans relačního úložiště je založený na obecných funkcích ADO.NET a v důsledku toho je nezávislý na dodavateli databáze. Rozložení Orleans úložiště dat už bylo vysvětleno v tabulkách modulu runtime. Nastavení připojovací řetězec se provádí, jak je vysvětleno v Orleans průvodci konfigurací.

Pokud chcete, aby Orleans funkce kódu s daným back-endem relační databáze fungovala, je nutné provést následující:

Do procesu musí být načtena příslušná knihovna ADO.NET. Tato hodnota by měla být definována obvyklým způsobem, například prostřednictvím elementu DbProviderFactories v konfiguraci aplikace.
Nakonfigurujte ADO.NET invariantní prostřednictvím Invariant vlastnosti v možnostech.
Databáze musí existovat a musí být kompatibilní s kódem. To se provádí spuštěním skriptu pro vytvoření databáze specifického dodavatelem. Další informace najdete v tématu ADO.NET Konfigurace.

Poskytovatel úložiště ADO .NET grain umožňuje ukládat stav zrnitosti v relačních databázích. V současné době jsou podporovány následující databáze:

SQL Server
MySQL/MariaDB
PostgreSQL
Oracle

Nejprve nainstalujte základní balíček:

Install-Package Microsoft.Orleans.Persistence.AdoNet

Informace o konfiguraci databáze, včetně odpovídajících ADO.NET Invariant a instalačních skriptů, najdete v článku o konfiguraci ADO.NET.

Následuje příklad konfigurace poskytovatele úložiště ADO.NET prostřednictvím ISiloHostBuilder:

var siloHostBuilder = new HostBuilder()
    .UseOrleans(c =>
    {
        c.AddAdoNetGrainStorage("OrleansStorage", options =>
        {
            options.Invariant = "<Invariant>";
            options.ConnectionString = "<ConnectionString>";
            options.UseJsonFormat = true;
        });
    });

V podstatě stačí nastavit připojovací řetězec konkrétního dodavatele databáze a Invariant (viz ADO.NET Konfigurace), která identifikuje dodavatele. Můžete také zvolit formát, ve kterém se data ukládají, což může být binární (výchozí), JSON nebo XML. I když je binární možnost nejkomprimovanější, je neprůžná a nebudete moct číst ani pracovat s daty. Json je doporučená možnost.

Následující vlastnosti můžete nastavit prostřednictvím AdoNetGrainStorageOptions:

/// <summary>
/// Options for AdoNetGrainStorage
/// </summary>
public class AdoNetGrainStorageOptions
{
    /// <summary>
    /// Define the property of the connection string
    /// for AdoNet storage.
    /// </summary>
    [Redact]
    public string ConnectionString { get; set; }

    /// <summary>
    /// Set the stage of the silo lifecycle where storage should
    /// be initialized.  Storage must be initialized prior to use.
    /// </summary>
    public int InitStage { get; set; } = DEFAULT_INIT_STAGE;
    /// <summary>
    /// Default init stage in silo lifecycle.
    /// </summary>
    public const int DEFAULT_INIT_STAGE =
        ServiceLifecycleStage.ApplicationServices;

    /// <summary>
    /// The default ADO.NET invariant will be used for
    /// storage if none is given.
    /// </summary>
    public const string DEFAULT_ADONET_INVARIANT =
        AdoNetInvariants.InvariantNameSqlServer;

    /// <summary>
    /// Define the invariant name for storage.
    /// </summary>
    public string Invariant { get; set; } =
        DEFAULT_ADONET_INVARIANT;

    /// <summary>
    /// Determine whether the storage string payload should be formatted in JSON.
    /// <remarks>If neither <see cref="UseJsonFormat"/> nor <see cref="UseXmlFormat"/> is set to true, then BinaryFormatSerializer will be configured to format the storage string payload.</remarks>
    /// </summary>
    public bool UseJsonFormat { get; set; }
    public bool UseFullAssemblyNames { get; set; }
    public bool IndentJson { get; set; }
    public TypeNameHandling? TypeNameHandling { get; set; }

    public Action<JsonSerializerSettings> ConfigureJsonSerializerSettings { get; set; }

    /// <summary>
    /// Determine whether storage string payload should be formatted in Xml.
    /// <remarks>If neither <see cref="UseJsonFormat"/> nor <see cref="UseXmlFormat"/> is set to true, then BinaryFormatSerializer will be configured to format storage string payload.</remarks>
    /// </summary>
    public bool UseXmlFormat { get; set; }
}

Trvalost ADO.NET má funkce pro data verzí a definovat libovolné (de)serializátory s libovolnými pravidly aplikace a streamováním, ale v současné době neexistuje žádná metoda, jak ji vystavit kódu aplikace.

ADO.NET odůvodnění trvalosti

Principy ADO.NET úložiště trvalosti jsou:

Udržujte důležitá obchodní data v bezpečí a přístupná, zatímco se data, formát dat a kód vyvíjejí.
Využijte výhod funkcí specifických pro dodavatele a úložiště.

V praxi to znamená dodržování cílů implementace ADO.NET a některé přidané logiky implementace v ADO. Poskytovatelé úložiště specifické pro net, kteří umožňují vývoj tvaru dat v úložišti.

Kromě obvyklých možností poskytovatele úložiště má poskytovatel ADO.NET integrovanou funkci:

Změňte data úložiště z jednoho formátu na jiný (např. z JSON na binární) při zaokrouhlování stavu.
Tvarujte typ, který se má uložit nebo číst z úložiště, libovolným způsobem. To umožňuje vývoj verze státu.
Streamujte data z databáze.

Obojí 1. a 2. lze je použít na základě libovolných rozhodovacích parametrů, jako jsou ID agregační hodnoty, typ zrnitosti, data datové části.

Jedná se o případ, abyste mohli zvolit formát serializace, např. Simple Binary Encoding (SBE) a implementuje IStorageDeserializer a IStorageSerializer. Předdefinované serializátory byly sestaveny pomocí této metody:

Po implementaci serializátorů je nutné je přidat do StorageSerializationPicker vlastnosti v .AdoNetGrainStorage Zde je implementace IStorageSerializationPicker. Ve výchozím nastavení StorageSerializationPicker se použije. Příklad změny formátu úložiště dat nebo použití serializátorů lze vidět na RelationalStorageTests.

V současné době neexistuje žádná metoda pro zveřejnění výběru serializace pro Orleans aplikaci, protože neexistuje žádná metoda pro přístup k framework-created AdoNetGrainStorage.

Cíle návrhu

1. Povolit použití jakéhokoli back-endu, který má poskytovatele ADO.NET

To by mělo zahrnovat nejširší možnou sadu back-endů dostupných pro .NET, což je faktor v místních instalacích. Někteří poskytovatelé jsou uvedeni v přehledu ADO.NET, ale ne všechny jsou uvedené, například Teradata.

2. Udržujte potenciál ladit dotazy a strukturu databáze podle potřeby, i když je spuštěné nasazení.

V mnoha případech jsou servery a databáze hostované třetí stranou ve smluvním vztahu s klientem. Není neobvyklé najít hostitelské prostředí, které je virtualizované a kde výkon kolísá kvůli nepředvídatelným faktorům, jako jsou hluční sousedi nebo vadný hardware. Binární soubory (ze smluvních důvodů) ani binární soubory aplikací není možné měnit ani znovu nasazovat Orleans , ale obvykle je možné upravit parametry nasazení databáze. Změna standardních komponent, jako Orleans jsou binární soubory, vyžaduje zdlouhavější postup optimalizace v dané situaci.

3. Umožňuje využívat schopnosti specifické pro konkrétní dodavatele a verze.

Dodavatelé implementovali různá rozšíření a funkce v rámci svých produktů. Je rozumné používat tyto funkce, pokud jsou k dispozici. Jedná se o funkce, jako jsou nativní UPSERT nebo PipelineDB v PostgreSQL, PolyBase nebo nativně zkompilované tabulky a uložené procedury v SQL Serveru.

4. Zajištění optimalizace hardwarových prostředků

Při návrhu aplikace je často možné předvídat, která data je potřeba vložit rychleji než jiná data a která data by mohla být pravděpodobnější vkládat do studeného úložiště, což je levnější (např. rozdělení dat mezi SSD a HDD). Mezi další aspekty patří fyzické umístění dat (některá data můžou být dražší (např. SSD RAID viz HDD) nebo bezpečnější) nebo jiné rozhodovací základ. V souvislosti s bodem 3., některé databáze nabízejí speciální schémata dělení, jako jsou tabulky a indexy rozdělené na SQL Server.

Tyto principy se použijí v průběhu životního cyklu aplikace. Vzhledem k tomu, že jedním ze samotných Orleans principů je vysoká dostupnost, mělo by být možné upravit systém úložiště bez přerušení Orleans nasazení, nebo by mělo být možné upravit dotazy podle dat a dalších parametrů aplikace. Příkladem dynamických změn může být vidět v blogovém příspěvku Briana Harryho:

Když je tabulka malá, skoro nezáleží na tom, co je plán dotazu. Když je plán dotazů v pořádku, je v pořádku, ale když je obrovský (miliony po milionech nebo miliardách řádků), může vás dokonce i nepatrná variace v plánu dotazu zabít. Z tohoto důvodu důrazně naznačíme naše citlivé dotazy.

5. Žádné předpoklady o tom, jaké nástroje, knihovny nebo procesy nasazení se používají v organizacích

Mnoho organizací zná určitou sadu databázových nástrojů, například Dacpac nebo Red Gate. Nasazení databáze může vyžadovat buď oprávnění, nebo osobu, například někoho v roli DBA, aby to udělala. Obvykle to znamená, že má také rozložení cílové databáze a hrubý náčrt dotazů, které aplikace vytvoří pro odhad zatížení. Můžou existovat procesy, které můžou mít vliv na oborové standardy, což vyžaduje nasazení založené na skriptech. Díky tomu se dají dotazy a databázové struktury v externím skriptu.

6. Použijte minimální sadu funkcí rozhraní potřebných k načtení ADO.NET knihoven a funkcí.

Je to rychlé a má méně povrchu vystavené nesrovnalostem v implementaci knihovny ADO.NET.

7. Nastavení horizontálního dělení návrhu

Pokud to dává smysl, například v relačním poskytovateli úložiště, vytvořte návrh snadno shardovatelný. To například znamená, že nepoužíváte žádná data závislá na databázi (např. IDENTITY). Informace, které rozlišují data řádků, by měly být založeny pouze na datech od skutečných parametrů.

8. Usnadnit testování návrhu

Vytvoření nového back-endu by v ideálním případě mělo být stejně snadné jako přeložit jeden ze stávajících skriptů nasazení do dialektu SQL back-endu, na který se pokoušíte cílit, a přidat do testů nový připojovací řetězec (za předpokladu výchozích parametrů), zkontrolovat, jestli je daná databáze nainstalovaná, a pak spouštět testy.

9. Vzhledem k předchozím bodům proveďte jak skripty přenosu pro nové back-endy, tak úpravu již nasazených back-endových skriptů co nejprůhlednější.

Realizace cílů

Architektura Orleans neví o hardwaru specifickém pro nasazení (který hardware se může během aktivního nasazení změnit), změnu dat během životního cyklu nasazení nebo o určitých funkcích specifických pro dodavatele, které jsou použitelné pouze v určitých situacích. Z tohoto důvodu by rozhraní mezi databází a Orleans mělo by dodržovat minimální sadu abstrakcí a pravidel pro splnění těchto cílů, zajistit, aby byla odolná proti zneužití a v případě potřeby se snadno testovat. Tabulky modulu runtime, správa clusteru a implementace konkrétního protokolu členství Implementace SQL Serveru také obsahuje ladění specifické pro edici SQL Serveru. Kontrakt rozhraní mezi databází a Orleans je definován takto:

Obecně platí, že data se čtou a zapisují prostřednictvím Orleanskonkrétních dotazů. Orleans pracuje s názvy a typy sloupců při čtení a u názvů parametrů a typů při psaní.
Implementace musí zachovat vstupní a výstupní názvy a typy. Orleans používá tyto parametry ke čtení výsledků dotazu podle názvu a typu. Je povoleno ladění specifické pro dodavatele a nasazení a za předpokladu zachování kontraktu rozhraní se doporučuje příspěvky.
Implementace skriptů specifických pro dodavatele by měla zachovat názvy omezení. To zjednodušuje řešení potíží na základě jednotného pojmenování napříč konkrétními implementacemi.
Verze – nebo ETag v kódu aplikace – pro Orleans, představuje jedinečnou verzi. Typ jeho skutečné implementace není důležitý, pokud představuje jedinečnou verzi. V implementaci Orleans kód očekává 32bitové celé číslo.
Pro účely explicitního a odstranění nejednoznačnosti očekává, Orleans že některé dotazy vrátí hodnotu PRAVDA jako > hodnotu 0 nebo NEPRAVDA jako hodnotu = 0 . To znamená, že počet ovlivněných nebo vrácených řádků nezáleží. Pokud je vyvolána chyba nebo je vyvolána výjimka, dotaz musí zajistit vrácení celé transakce zpět a může vrátit hodnotu NEPRAVDA nebo rozšířit výjimku.
V současné době se všechny dotazy kromě jednoho dotazu vkládají nebo aktualizují (všimněte si, že dotazy by mohly nahradit UPDATE dotazy INSERT, za předpokladu, že přidružené SELECT dotazy provedly poslední zápis).

Databázové stroje podporují programování v databázi. To se podobá myšlence načtení spustitelného skriptu a jeho vyvolání ke spouštění databázových operací. V pseudokódu může být znázorněn jako:

const int Param1 = 1;
const DateTime Param2 = DateTime.UtcNow;
const string queryFromOrleansQueryTableWithSomeKey =
    "SELECT column1, column2 "+
    "FROM <some Orleans table> " +
    "WHERE column1 = @param1 " +
    "AND column2 = @param2;";
TExpected queryResult =
    SpecificQuery12InOrleans<TExpected>(query, Param1, Param2);

Tyto principy jsou také zahrnuty do databázových skriptů.

Několik nápadů na použití přizpůsobených skriptů

Upravte skripty OrleansQuery pro trvalost zrnitosti tak IF ELSE , aby se určitý stav uložil pomocí výchozího INSERTstavu , zatímco některé stavy zrn mohou používat tabulky optimalizované pro paměť. Dotazy SELECT je potřeba odpovídajícím způsobem změnit.
Myšlenku 1. lze použít k využití jiných aspektů specifických pro nasazení nebo dodavatele, jako je rozdělení dat mezi HDDSSD šifrované tabulky nebo vložení některých dat do šifrovaných tabulek nebo třeba vložení statistických dat přes SQL Server-to-Hadoop nebo dokonce propojené servery.

Změněné skripty je možné testovat spuštěním Orleans testovací sady nebo přímo v databázi pomocí projektu testování jednotek SQL Serveru.

Pokyny pro přidání nových poskytovatelů ADO.NET

Přidejte nový skript pro nastavení databáze podle části Realizace výše uvedených cílů .
Do dbConstantsStore přidejte AdoNetInvariants invariantní název ADO dodavatele a ADO.NET data specifická pro zprostředkovatele. Ty se (potenciálně) používají v některých operacích dotazů. například vybrat správný režim vkládání statistik (tj. s UNION ALL nebo bez FROM DUAL).
Orleans obsahuje komplexní testy pro všechna systémová úložiště: členství, připomenutí a statistiky. Přidání testů pro nový databázový skript se provádí zkopírováním existujících testovacích tříd a změnou invariantního názvu ADO. Také odvozujte z RelationalStorageForTesting , aby bylo možné definovat funkce testování pro invariantní ADO.

Sdílet prostřednictvím