Elastic Database-clientbibliotheek met Entity Framework

Van toepassing op:Azure SQL Database

Dit document bevat de wijzigingen in een Entity Framework-toepassing die nodig zijn om te integreren met de hulpprogramma's voor Elastic Database. De focus ligt op het opstellen van shard-toewijzingsbeheer en gegevensafhankelijke routering met de Entity Framework Code First-benadering . De zelfstudie Code First - New Database voor EF fungeert als het actieve voorbeeld in dit document. De voorbeeldcode die bij dit document hoort, maakt deel uit van de verzameling voorbeelden van elastic database tools in de Visual Studio Code Samples.

De voorbeeldcode downloaden en uitvoeren

De code voor dit artikel downloaden:

• Visual Studio 2012 of hoger is vereist.
• Download het voorbeeld van Elastic DB Tools voor Azure SQL - Entity Framework Integration. Pak het voorbeeld uit naar een locatie van uw keuze.
• Start Visual Studio.
• Selecteer Bestand in Visual Studio -> Project/Oplossing openen.
• Open het dialoogvenster Project openen, navigeer naar het voorbeeld dat u hebt gedownload en selecteer EntityFrameworkCodeFirst.sln om het voorbeeld te openen.

Als u het voorbeeld wilt uitvoeren, moet u drie lege databases maken in Azure SQL Database:

• Shard Map Manager-database
• Shard 1-database
• Shard 2-database

Nadat u deze databases hebt gemaakt, vult u de plaatsaanduidingen in Program.cs met uw servernaam, de databasenamen en uw inloggegevens om verbinding te maken met de databases. Bouw de oplossing in Visual Studio. Visual Studio downloadt de vereiste NuGet-pakketten voor de clientbibliotheek voor elastische databases, Entity Framework en tijdelijke foutafhandeling als onderdeel van het buildproces. Zorg ervoor dat het herstellen van NuGet-pakketten is ingeschakeld voor uw oplossing. U kunt deze instelling inschakelen door met de rechtermuisknop op het oplossingsbestand in Visual Studio Solution Explorer te klikken.

Entity Framework-werkstromen

Entity Framework-ontwikkelaars zijn afhankelijk van een van de volgende vier werkstromen om toepassingen te bouwen en om persistentie voor toepassingsobjecten te garanderen:

• Code First (Nieuwe database): de EF-ontwikkelaar maakt het model in de toepassingscode en vervolgens genereert EF de database.
• Code First (bestaande database):de ontwikkelaar kan met EF de toepassingscode voor het model genereren op basis van een bestaande database.
• Model eerst: de ontwikkelaar maakt het model in de EF-ontwerpfunctie en vervolgens maakt EF de database op basis van het model.
• Database First: De ontwikkelaar gebruikt EF-hulpprogramma's om het model af te stellen van een bestaande database.

Al deze benaderingen zijn afhankelijk van de DbContext-klasse om databaseverbindingen en databaseschema's voor een toepassing transparant te beheren. Verschillende constructors in de DbContext-basisklasse bieden verschillende controleniveaus over het maken van verbindingen, het opstarten van databases en het maken van een schema. Problemen ontstaan voornamelijk doordat het databaseverbindingsbeheer van EF de mogelijkheden voor verbindingsbeheer van de gegevensafhankelijke routeringsinterfaces van de clientbibliotheek van de elastische database doorkruist.

Veronderstellingen voor hulpprogramma's voor elastische databases

Zie de woordenlijst hulpmiddelen voor Elastic Database voor termendefinities.

Met de clientbibliotheek voor elastische databases definieert u partities van uw toepassingsgegevens met de naam shardlets. Shardlets worden geïdentificeerd door een sharding-sleutel en worden toegewezen aan specifieke databases. Een toepassing kan zoveel databases als nodig hebben en de shardlets distribueren om voldoende capaciteit of prestaties te bieden op basis van de huidige bedrijfsvereisten. De toewijzing van sharding-sleutelwaarden aan de databases wordt opgeslagen door een shardmap die wordt verstrekt door de elastische database client-API's. Deze mogelijkheid wordt Shard-toewijzingsbeheer, afgekort als SMM, genoemd. De shardkaart fungeert ook als makelaar van databaseverbindingen voor verzoeken die een sharding-sleutel bevatten. Deze mogelijkheid wordt ook wel gegevensafhankelijke routering genoemd.

De shard-mapbeheerder beschermt gebruikers tegen inconsistente inzichten in shardlet-gegevens die kunnen optreden wanneer tegelijkertijd shardlet-beheerbewerkingen plaatsvinden, zoals het verplaatsen van gegevens van de ene shard naar een andere. Hiervoor bemiddelen de shard-kaarten, beheerd door de clientbibliotheek, in de databaseverbindingen voor een toepassing. Hierdoor kan de shardtoewijzingsfunctionaliteit automatisch een databaseverbinding beëindigen wanneer shardbeheerbewerkingen van invloed kunnen zijn op de shardlet waarvoor de verbinding is gemaakt. Deze benadering moet worden geïntegreerd met een deel van de functionaliteit van EF, zoals het maken van nieuwe verbindingen van een bestaande verbinding om te controleren op het bestaan van de database. Over het algemeen is onze observatie dat de standaard DbContext-constructors alleen betrouwbaar werken voor gesloten databaseverbindingen die veilig kunnen worden gekloond voor EF-werk. Het ontwerpprincipe van een elastische database is om alleen geopende verbindingen te beheren. Men zou kunnen denken dat het sluiten van een verbinding die door de clientbibliotheek is gefaciliteerd voordat deze wordt overgedragen aan de EF DbContext, dit probleem kan oplossen. Door de verbinding te sluiten en te vertrouwen op EF om de verbinding opnieuw te openen, verliest men echter de validatie- en consistentiecontroles die door de bibliotheek uitgevoerd worden. De functionaliteit voor migraties in EF gebruikt deze verbindingen echter om het onderliggende databaseschema te beheren op een manier die transparant is voor de toepassing. Idealiter behoudt en combineert u al deze mogelijkheden uit zowel de clientbibliotheek voor elastische databases als EF in dezelfde toepassing. In de volgende sectie worden deze eigenschappen en vereisten gedetailleerder besproken.

Behoeften

Wanneer u werkt met zowel de clientbibliotheek van de elastische database als de Entity Framework-API's, wilt u de volgende eigenschappen behouden:

• Uitschalen: Het toevoegen of verwijderen van databases uit de gegevenslaag van de geshardete toepassing zoals nodig voor de capaciteitsvereisten van de toepassing. Dit betekent dat u controle hebt over het maken en verwijderen van databases en het gebruik van de API's van de elastic database shard map manager om databases en toewijzingen van shardlets te beheren.
• Consistentie: De toepassing maakt gebruik van sharding en maakt gebruik van de gegevensafhankelijke routeringsmogelijkheden van de clientbibliotheek. Om beschadiging of verkeerde queryresultaten te voorkomen, worden verbindingen bemiddeld via de shardmapbeheerder. Dit behoudt ook validatie en consistentie.
• Code First: Om het gemak van het Code First-paradigma van EF te behouden. In Code First worden klassen in de toepassing transparant toegewezen aan de onderliggende databasestructuren. De toepassingscode communiceert met DbSets die de meeste aspecten maskeren die betrekking hebben op de onderliggende databaseverwerking.
• Schema: Entity Framework verwerkt het maken van het initiële databaseschema en de daaropvolgende schemaontwikkeling via migraties. Door deze mogelijkheden te behouden, is het aanpassen van uw app eenvoudig naarmate de gegevens zich ontwikkelen.

De volgende richtlijnen bevatten instructies voor het voldoen aan deze vereisten voor Code First-toepassingen met behulp van hulpprogramma's voor elastische databases.

Gegevensafhankelijke routering met EF DbContext

Databaseverbindingen met Entity Framework worden doorgaans beheerd via subklassen van DbContext. Maak deze subklassen door ze af te leiden van DbContext. Hier definieert u uw DbSets die de door databases ondersteunde verzamelingen van CLR-objecten voor uw toepassing implementeren. In de context van gegevensafhankelijke routering kunt u verschillende nuttige eigenschappen identificeren die niet noodzakelijkerwijs voor andere EF-code-eerste toepassingsscenario's gelden:

• De database bestaat al en is geregistreerd in de shard-kaart van de elastische database.
• Het schema van de toepassing is al geïmplementeerd in de database (zie hieronder).
• De data-afhankelijke routeringsverbindingen naar de database worden afgehandeld door de shardkaart.

DbContexts Integreren met gegevensafhankelijke routering voor uitschalen:

1. Maak fysieke databaseverbindingen via de clientinterfaces van de elastische database van de shardmapbeheerder.
2. De verbinding verpakken met de DbContext subklasse
3. Geef de verbinding door aan de DbContext basisklassen om ervoor te zorgen dat ook alle verwerking aan de EF-zijde plaatsvindt.

In het volgende codevoorbeeld ziet u deze benadering. (Deze code bevindt zich ook in het bijbehorende Visual Studio-project)

public class ElasticScaleContext<T> : DbContext
{
public DbSet<Blog> Blogs { get; set; }
...

    // C'tor for data-dependent routing. This call opens a validated connection
    // routed to the proper shard by the shard map manager.
    // Note that the base class c'tor call fails for an open connection
    // if migrations need to be done and SQL credentials are used. This is the reason for the
    // separation of c'tors into the data-dependent routing case (this c'tor) and the internal c'tor for new shards.
    public ElasticScaleContext(ShardMap shardMap, T shardingKey, string connectionStr)
        : base(CreateDDRConnection(shardMap, shardingKey, connectionStr),
        true /* contextOwnsConnection */)
    {
    }

    // Only static methods are allowed in calls into base class c'tors.
    private static DbConnection CreateDDRConnection(
    ShardMap shardMap,
    T shardingKey,
    string connectionStr)
    {
        // No initialization
        Database.SetInitializer<ElasticScaleContext<T>>(null);

        // Ask shard map to broker a validated connection for the given key
        SqlConnection conn = shardMap.OpenConnectionForKey<T>
                            (shardingKey, connectionStr, ConnectionOptions.Validate);
        return conn;
    }

Belangrijkste punten

• Een nieuwe constructor vervangt de standaardconstructor in de subklasse DbContext

• De nieuwe constructor gebruikt de argumenten die nodig zijn voor gegevensafhankelijke routering via de clientbibliotheek voor elastische databases:

  • de shard-kaart voor toegang tot de gegevensafhankelijke routeringsinterfaces
  • de shardingsleutel om het shardlet te identificeren,
  • een verbindingsreeks met de referenties voor de gegevensafhankelijke routeringsverbinding met de shard.

• De oproep van de basisklasseconstructor neemt een tussenstap naar een statische methode die alle stappen doorloopt die nodig zijn voor gegevensafhankelijke routering.

  • Bij gebruik van het OpenConnectionForKey-commando uit de clientinterfaces van de elastische database op de shardmap wordt een open verbinding tot stand gebracht.
  • De shard map creëert de verbinding met de shard die de shardlet voor de opgegeven shardingsleutel bevat.
  • Deze geopende verbinding wordt teruggegeven aan de basisklasseconstructor van DbContext om aan te geven dat deze verbinding door EF moet worden gebruikt in plaats van dat EF automatisch een nieuwe verbinding kan maken. Op deze manier is de verbinding gemarkeerd door de elastische database-API van de client, zodat de consistentie van gegevens kan worden gewaarborgd tijdens het beheer van shard-toewijzingen.

Gebruik de nieuwe constructor voor uw DbContext-subklasse in plaats van de standaardconstructor in uw code. Hier volgt een voorbeeld:

// Create and save a new blog.

Console.Write("Enter a name for a new blog: ");
var name = Console.ReadLine();

using (var db = new ElasticScaleContext<int>(
                        sharding.ShardMap,  
                        tenantId1,  
                        connStrBldr.ConnectionString))
{
    var blog = new Blog { Name = name };
    db.Blogs.Add(blog);
    db.SaveChanges();

    // Display all Blogs for tenant 1
    var query = from b in db.Blogs
                orderby b.Name
                select b;
    ...
}

De nieuwe constructor opent de verbinding met de shard die de gegevens voor de shardlet bevat die is geïdentificeerd door de waarde van tenantid1. De code in het gebruiksblok blijft ongewijzigd om toegang te krijgen tot de DbSet voor blogs met EF op de shard voor tenantid1. Hiermee wordt de semantiek voor de code in het using-blok gewijzigd, zodat alle databasebewerkingen nu worden beperkt tot de ene shard waar tenantid1 deze wordt bewaard. Een LINQ-query via de blogs retourneert bijvoorbeeld alleen blogs DbSet die zijn opgeslagen op de huidige shard, maar niet de blogs die zijn opgeslagen op andere shards.

Afhandeling van tijdelijke fouten

Het Microsoft Patterns &Practices-team heeft het toepassingsblok Tijdelijke foutafhandeling gepubliceerd. De bibliotheek wordt gebruikt met clientbibliotheek voor elastische schaal in combinatie met EF. Zorg er echter voor dat elke tijdelijke uitzondering terugkeert naar een plaats waar u ervoor kunt zorgen dat de nieuwe constructor wordt gebruikt na een tijdelijke fout, zodat elke nieuwe verbindingspoging wordt uitgevoerd met behulp van de constructors die u hebt aangepast. Anders wordt een verbinding met de juiste shard niet gegarandeerd en zijn er geen garanties dat de verbinding behouden blijft wanneer er wijzigingen in de shard-toewijzing plaatsvinden.

In het volgende codevoorbeeld ziet u hoe een SQL-beleid voor opnieuw proberen kan worden gebruikt rond de nieuwe DbContext subklasseconstructors:

SqlDatabaseUtils.SqlRetryPolicy.ExecuteAction(() =>
{
    using (var db = new ElasticScaleContext<int>(
                            sharding.ShardMap,  
                            tenantId1,  
                            connStrBldr.ConnectionString))
        {
                var blog = new Blog { Name = name };
                db.Blogs.Add(blog);
                db.SaveChanges();
        ...
        }
    });

SqlDatabaseUtils.SqlRetryPolicy in de voorbeeldcode wordt gedefinieerd als een SqlDatabaseTransientErrorDetectionStrategy met het aantal nieuwe pogingen van 10 en 5 seconden wachttijd tussen nieuwe pogingen. Deze benadering is vergelijkbaar met de richtlijnen voor EF- en door de gebruiker geïnitieerde transacties (zie Beperkingen met uitvoeringsstrategieën voor opnieuw proberen (EF6 en hoger). In beide situaties is vereist dat het toepassingsprogramma het bereik bepaalt waarop de tijdelijke uitzondering wordt geretourneerd: om de transactie opnieuw te openen of (zoals weergegeven) de context opnieuw te maken vanuit de juiste constructor die gebruikmaakt van de clientbibliotheek van de elastische database.

De noodzaak om te bepalen waar tijdelijke uitzonderingen ons terugbrengen in het bereik, sluit ook het gebruik van de ingebouwde SqlAzureExecutionStrategy die bij EF wordt geleverd. SqlAzureExecutionStrategy opent een verbinding opnieuw, maar gebruikt OpenConnectionForKey deze niet en omzeilt daarom alle validatie die wordt uitgevoerd als onderdeel van de OpenConnectionForKey aanroep. In plaats daarvan maakt het codevoorbeeld gebruik van de ingebouwde DefaultExecutionStrategy code die ook bij EF wordt geleverd. In tegenstelling tot SqlAzureExecutionStrategy, werkt het correct in combinatie met het herhalingsbeleid van Transient Fault Handling. Het uitvoeringsbeleid wordt ingesteld in de ElasticScaleDbConfiguration klasse. We hebben besloten om DefaultSqlExecutionStrategy niet te gebruiken, omdat het suggereert dat SqlAzureExecutionStrategy wordt gebruikt als de tijdelijke uitzonderingen optreden, wat zou leiden tot verkeerd gedrag zoals besproken. Zie Verbindingstolerantie in EF voor meer informatie over de verschillende beleidsregels voor opnieuw proberen en EF.

Constructor-herschrijvingen

In de bovenstaande codevoorbeelden ziet u de standaardherschrijfbewerkingen van de constructor die vereist zijn voor uw toepassing om gegevensafhankelijke routering te gebruiken met entity framework. In de volgende tabel wordt deze benadering voor andere constructors gegeneraliseerd.

De implementatie van shard-schema's via Entity Framework-migraties

Automatisch schemabeheer is een gemaksfunctie van Entity Framework. In de context van toepassingen met hulpprogramma's voor elastische databases wilt u deze mogelijkheid behouden om het schema automatisch in te richten voor nieuw gemaakte shards wanneer databases worden toegevoegd aan de shard-toepassing. De primaire use case is het verhogen van de capaciteit op de gegevenslaag voor shard-toepassingen met ef. Door te vertrouwen op de mogelijkheden van EF voor schemabeheer, wordt de inspanning voor databasebeheer verminderd bij een sharded toepassing die is gebouwd op EF.

Schema-implementatie via EF-migraties werkt het beste voor niet-geopende verbindingen. Dit is in tegenstelling tot het scenario voor gegevensafhankelijke routering die afhankelijk is van de geopende verbinding die wordt geleverd door de client-API voor elastische databases. Een ander verschil is de consistentievereiste: Hoewel het wenselijk is om consistentie te garanderen voor alle gegevensafhankelijke routeringsverbindingen ter bescherming tegen gelijktijdige bewerking van shard-toewijzingen, is het geen probleem met de eerste schema-implementatie voor een nieuwe database die nog niet is geregistreerd in de shard-toewijzing en nog niet is toegewezen aan het opslaan van shardlets. U kunt daarom vertrouwen op regelmatige databaseverbindingen voor dit scenario, in plaats van gegevensafhankelijke routering.

Dit leidt tot een benadering waarbij schema-implementatie via EF-migraties nauw is gekoppeld aan de registratie van de nieuwe database als een shard in de shardtoewijzing van de toepassing. Dit is afhankelijk van de volgende vereisten:

• De database is al gemaakt.
• De database is leeg. De database bevat geen gebruikersschema en geen gebruikersgegevens.
• De database kan nog niet worden geopend via de client-API's van de elastische database voor gegevensafhankelijke routering.

Met deze vereisten kunt u een reguliere niet-geopende SqlConnection maken om EF-migraties voor schema-implementatie te starten. Het volgende codevoorbeeld illustreert deze benadering.

// Enter a new shard - i.e. an empty database - to the shard map, allocate a first tenant to it  
// and kick off EF initialization of the database to deploy schema

public void RegisterNewShard(string server, string database, string connStr, int key)
{

    Shard shard = this.ShardMap.CreateShard(new ShardLocation(server, database));

    SqlConnectionStringBuilder connStrBldr = new SqlConnectionStringBuilder(connStr);
    connStrBldr.DataSource = server;
    connStrBldr.InitialCatalog = database;

    // Go into a DbContext to trigger migrations and schema deployment for the new shard.
    // This requires an un-opened connection.
    using (var db = new ElasticScaleContext<int>(connStrBldr.ConnectionString))
    {
        // Run a query to engage EF migrations
        (from b in db.Blogs
            select b).Count();
    }

    // Register the mapping of the tenant to the shard in the shard map.
    // After this step, data-dependent routing on the shard map can be used

    this.ShardMap.CreatePointMapping(key, shard);
}

In dit voorbeeld ziet u de methode RegisterNewShard waarmee de shard in de shard-kaart wordt geregistreerd, het schema wordt geïmplementeerd via EF-migraties en een sharding sleutel aan de shard wordt opgeslagen. Het is afhankelijk van een constructor van de DbContext subklasse (ElasticScaleContext in het voorbeeld) die een SQL-verbindingsreeks als invoer gebruikt. De code van deze constructor is eenvoudig, zoals het volgende voorbeeld aangeeft.

// C'tor to deploy schema and migrations to a new shard
protected internal ElasticScaleContext(string connectionString)
    : base(SetInitializerForConnection(connectionString))
{
}

// Only static methods are allowed in calls into base class c'tors
private static string SetInitializerForConnection(string connectionString)
{
    // You want existence checks so that the schema can get deployed
    Database.SetInitializer<ElasticScaleContext<T>>(
new CreateDatabaseIfNotExists<ElasticScaleContext<T>>());

    return connectionString;
}

Mogelijk hebt u de versie van de constructor gebruikt die is overgenomen van de basisklasse. Maar de code moet ervoor zorgen dat de standaard initialisatiefunctie voor EF wordt gebruikt bij het verbinden. Vandaar de korte omleiding naar de statische methode voordat u de constructor van de basisklasse aanroept met de verbindingsreeks. De registratie van shards moet worden uitgevoerd in een ander app-domein of -proces om ervoor te zorgen dat de initialisatie-instellingen voor EF niet conflicteren.

Beperkingen

De benaderingen die in dit document worden beschreven, omvatten een aantal beperkingen:

• EF-toepassingen die eerst LocalDb gebruiken, moeten eerst worden gemigreerd naar een reguliere SQL Server-database voordat ze een clientbibliotheek voor elastische databases kunnen gebruiken. Het is niet mogelijk LocalDbom een toepassing uit te schalen via sharding met Elastic Scale. Ontwikkeling kan nog steeds LocalDb gebruiken.
• Wijzigingen in de toepassing die wijzigingen in databaseschema's impliceren, moeten EF-migraties op alle shards doorlopen. De voorbeeldcode voor dit document laat niet zien hoe u dit doet. Overweeg om Update-Database te gebruiken met een ConnectionString-parameter om door alle shards te itereren; of extraheer het T-SQL-script voor de lopende migratie met Update-Database en de optie -Script, en pas het toe op uw shards.
• Bij een aanvraag wordt ervan uitgegaan dat alle verwerking van de database zich in één shard bevindt, zoals wordt geïdentificeerd door de shardingsleutel die door de aanvraag wordt verstrekt. Deze aanname is echter niet altijd waar. Bijvoorbeeld wanneer het onmogelijk is om een shardingsleutel beschikbaar te maken. Hiertoe biedt de clientbibliotheek de MultiShardQuery klasse waarmee een verbindingsabstractie wordt geïmplementeerd voor het uitvoeren van query's via verschillende shards. Leren om MultiShardQuery in combinatie met EF te gebruiken valt buiten de reikwijdte van dit document.

Conclusie

Via de stappen die in dit document worden beschreven, kunnen EF-toepassingen de mogelijkheid van de clientbibliotheek voor elastische databases gebruiken voor gegevensafhankelijke routering door constructors van de DbContext subklassen die in de EF-toepassing worden gebruikt, te herstructureren. Dit beperkt de wijzigingen die nodig zijn voor die plaatsen waar DbContext klassen al bestaan. Bovendien kunnen EF-toepassingen blijven profiteren van automatische schema-uitrol door de stappen te combineren die de benodigde EF-migraties aanroepen met de registratie van nieuwe shards en hun toewijzingen in de shardmap.

Verwante inhoud

Gebruikt u nog geen hulpprogramma's voor elastische databases? Bekijk onze Aan de slag-handleiding. Neem voor vragen contact met ons op op de Microsoft Q&A-vragenpagina voor SQL Database en voor functieaanvragen, voeg nieuwe ideeën toe of stem op bestaande ideeën in het SQL Database-feedbackforum.