Vanliga frågor och svar om Azure Cosmos DB för Apache Cassandra

Här följer några viktiga skillnader mellan API:et för Cassandra-tjänsten och Apache Cassandra:

• Apache Cassandra rekommenderar en gräns på 100 MB för storleken på en partitionsnyckel. API:et för Cassandra för Azure Cosmos DB tillåter upp till 20 GB per partition.
• Med Apache Cassandra kan du inaktivera varaktiga incheckningar. Du kan hoppa över att skriva till incheckningsloggen och gå direkt till den minnesinterna datastrukturen. Detta kan leda till dataförlust om noden går ned innan minnesinterna datastrukturer töms till SSTables på disk. Azure Cosmos DB utför alltid varaktiga incheckningar för att förhindra dataförlust.
• Apache Cassandra kan se sämre prestanda om arbetsbelastningen omfattar många ersättningar eller borttagningar. Orsaken är gravstenar som läsarbetsbelastningen behöver hoppa över för att hämta de senaste data. API:et för Cassandra ser inte sämre läsprestanda när arbetsbelastningen har många ersättningar eller borttagningar.
• Under scenarier med höga ersättningsarbetsbelastningar måste komprimering köras för att slå samman SSTables på disk. (En sammanslagning krävs eftersom Apache Cassandras skrivningar endast läggs till. Flera uppdateringar lagras som enskilda SSTable-poster som regelbundet måste sammanfogas). Den här situationen kan också leda till lägre läsprestanda under komprimering. Den här prestandapåverkan inträffar inte i API:et för Cassandra eftersom API:et inte implementerar komprimering.
• Det går att ange en replikeringsfaktor på 1 med Apache Cassandra. Det leder dock till låg tillgänglighet om den enda noden med data går ned. Det här är inte ett problem med API:et för Cassandra för Azure Cosmos DB eftersom det alltid finns en replikeringsfaktor på 4 (kvorum på 3).
• Att lägga till eller ta bort noder i Apache Cassandra kräver manuella åtgärder, tillsammans med hög CPU-användning på den nya noden medan befintliga noder flyttar några av sina tokenintervall till den nya noden. Den här situationen är densamma när du inaktiverar en befintlig nod. API:et för Cassandra skalas dock ut utan några problem som observerats i tjänsten eller programmet.
• Du behöver inte ange num_tokens på varje nod i klustret som i Apache Cassandra. Azure Cosmos DB hanterar noder och tokenintervall fullständigt.
• API:et för Cassandra hanteras fullständigt. Du behöver inte kommandon, till exempel reparation och avaktiveringar som används i Apache Cassandra.

API:et för Cassandra för Azure Cosmos DB stöder Cassandra Query Language (CQL) m version 3.x. Dess CQL-kompatibilitet baseras på den offentliga Apache Cassandra GitHub-lagringsplatsen. Om du har feedback om stöd för andra protokoll kan du skicka e-post till askcosmosdbcassandra@microsoft.com.

Azure Cosmos DB anger standarddataflödet för din container baserat på var du skapar tabellen från: Azure-portalen eller CQL.

Azure Cosmos DB ger garantier för prestanda och svarstid, med övre gränser för åtgärder. Dessa garantier är möjliga när motorn kan framtvinga styrning av klientorganisationens åtgärder. Genom att ange dataflöde ser du till att du får garanterat dataflöde och svarstid, eftersom plattformen reserverar den här kapaciteten och garanterar att åtgärden lyckas. Du kan elastiskt ändra dataflödet för att dra nytta av programmets säsongsvariationer och spara kostnader.

Dataflödeskonceptet beskrivs i artikeln Enheter för begäran i Azure Cosmos DB . Dataflödet för en tabell är lika fördelat över underliggande fysiska partitioner.

Azure Cosmos DB använder enheter för begäranden per sekund (RU/s) som valuta för att tillhandahålla dataflöde. Tabeller som skapas via CQL har 400 RU som standard. Du kan ändra RU:en från Azure-portalen.

CQL

CREATE TABLE keyspaceName.tablename (user_id int PRIMARY KEY, lastname text) WITH cosmosdb_provisioned_throughput=1200

.NET

int provisionedThroughput = 400;
var simpleStatement = new SimpleStatement($"CREATE TABLE {keyspaceName}.{tableName} (user_id int PRIMARY KEY, lastname text)");
var outgoingPayload = new Dictionary<string, byte[]>();
outgoingPayload["cosmosdb_provisioned_throughput"] = Encoding.UTF8.GetBytes(provisionedThroughput.ToString());
simpleStatement.SetOutgoingPayload(outgoingPayload);

Azure Cosmos DB ger garantier för prestanda och svarstid, med övre gränser för åtgärder. Dessa garantier är möjliga när motorn kan framtvinga styrning av klientorganisationens åtgärder. Genom att ange dataflöde ser du till att du får garanterat dataflöde och svarstid, eftersom plattformen reserverar den här kapaciteten och garanterar att åtgärden lyckas.

När du går över den här kapaciteten får du följande felmeddelande som anger att kapaciteten har förbrukats:

0x1001 överbelastad: begäran kan inte bearbetas eftersom "Begärandefrekvensen är stor"

Det är viktigt att se vilka åtgärder (och deras volym) som orsakar det här problemet. Du kan få en uppfattning om förbrukad kapacitet som går över den etablerade kapaciteten med mått på Azure-portalen. Sedan måste du se till att kapaciteten förbrukas nästan lika över alla underliggande partitioner. Om du ser att en partition förbrukar det mesta av dataflödet har du skev arbetsbelastning.

Mått är tillgängliga som visar hur dataflödet används under timmar, över dagar och per sju dagar, över partitioner eller totalt. Mer information finns i Övervakning och felsökning med mått i Azure Cosmos DB.

Diagnostikloggar beskrivs i artikeln om diagnostikloggning i Azure Cosmos DB.

Ja, partitionsnyckeln används för att placera entiteten på rätt plats. I Azure Cosmos DB används den för att hitta rätt logisk partition som lagras på en fysisk partition. Partitioneringskonceptet beskrivs väl i artikeln Partition och skalning i Azure Cosmos DB . Det viktiga här är att en logisk partition inte ska överskrida gränsen på 20 GB.

Azure Cosmos DB är ett system baserat på serviceavtal (SLA). Den ger obegränsad skalning, med garantier för svarstid, dataflöde, tillgänglighet och konsekvens. Den här obegränsade lagringen baseras på horisontell utskalning av data med partitionering som nyckelbegrepp. Partitioneringskonceptet beskrivs väl i artikeln Partition och skalning i Azure Cosmos DB .

Du bör följa gränsen på 20 GB för antalet entiteter eller objekt per logisk partition. För att säkerställa att programmet skalar bra rekommenderar vi att du inte skapar en frekvent partition genom att lagra all information i en partition och köra frågor mot den. Det här felet kan bara komma om dina data är skeva: det vill: du har mycket data för en partitionsnyckel (mer än 20 GB). Du hittar fördelningen av data med hjälp av lagringsportalen. Sättet att åtgärda det här felet är att återskapa tabellen och välja en detaljerad primär (partitionsnyckel) som möjliggör bättre distribution av data.

Azure Cosmos DB kan lagra obegränsade data genom att skala ut lagringen. Den här lagringen är oberoende av dataflödet. Ja, du kan alltid använda API:et för Cassandra bara för att lagra och hämta nycklar och värden genom att ange rätt primär-/partitionsnyckel. Dessa enskilda nycklar får en egen logisk partition och sitter ovanpå en fysisk partition utan problem.

Ja, det går att skapa fler än en tabell med API:et för Cassandra. Var och en av dessa tabeller behandlas som en enhet för dataflöde och lagring.

Azure Cosmos DB är ett resursstyrt system för både data- och kontrollplansaktiviteter. Containrar, till exempel samlingar och tabeller, är körningsentiteter som etableras för en viss dataflödeskapacitet. Skapandet av dessa containrar i snabb följd är inte en förväntad aktivitet och kan begränsas. Om du har tester som släpper eller skapar tabeller omedelbart kan du försöka ta bort dem.

Det finns ingen fysisk gräns för antalet tabeller. Om du har ett stort antal tabeller (där den totala stadiga storleken överstiger 10 TB data) som måste skapas, inte de vanliga tiotals eller hundratals, skickar du e-post till askcosmosdbcassandra@microsoft.com.

Det finns ingen fysisk gräns för antalet nyckelområden eftersom de är metadatacontainrar. Om du har ett stort antal nyckelutrymmen skickar du e-post till askcosmosdbcassandra@microsoft.com.

Ja. Om vi antar enhetligt distribuerade partitioner hanteras lagringskapaciteten automatiskt och ökar när du skickar in mer data. Så du kan importera så mycket data som du behöver utan att hantera och etablera noder med mera. Men om du förväntar dig många omedelbara datatillväxt är det mer meningsfullt att direkt etablera för det förväntade dataflödet i stället för att börja lägre och öka det omedelbart.

API:et för Cassandra för Azure Cosmos DB tillhandahåller kompatibilitet på protokollnivå för körning av åtgärder. Den döljer komplexiteten i hantering, övervakning och konfiguration. Som utvecklare/användare behöver du inte bekymra dig om tillgänglighet, gravstenar, nyckelcachen, radcachen, bloom-filtret och en mängd andra inställningar. API:et för Cassandra fokuserar på att tillhandahålla den läs- och skrivprestanda som du behöver utan att behöva använda konfiguration och hantering.

API:et för Cassandra förenklar kapacitetsplaneringen och svarar på elasticitetskraven för dataflöde och lagring. Med Azure Cosmos DB etablerar du det dataflöde som du behöver. Sedan kan du skala upp och ned det valfritt antal gånger under dagen, utan att behöva oroa dig för att lägga till, ta bort eller hantera noder. Du behöver inte använda verktyg för nod- och klusterhantering.

Azure Cosmos DB tillhandahåller global distribution direkt av tillgänglighets- och svarstidsskäl. Du behöver inte konfigurera repliker eller andra saker. Skrivningar är alltid durably kvorum incheckade i alla regioner där du skriver, samtidigt som prestandagarantier ges.

Azure Cosmos DB ger prestandagarantier för läsningar, skrivningar och dataflöde. Så du behöver inte oroa dig för att röra någon av konfigurationsinställningarna och oavsiktligt manipulera dem. Dessa inställningar omfattar bloom-filter, cachelagring, läsreparationschans, gc_grace och komprimering memtable_flush_period.

Ja, TTL stöds.

Azure Cosmos DB är en plattformstjänst som hjälper dig att öka produktiviteten och inte oroa dig för att hantera och övervaka infrastruktur. Du behöver till exempel inte övervaka nodstatus, replikstatus, gc- och OS-parametrar tidigare med olika verktyg. Du behöver bara ta hand om dataflödet som är tillgängligt i portalmåtten för att se om du blir begränsad och sedan öka eller minska det dataflödet. Du kan:

• Övervaka serviceavtal
• Använda mått
• Använda diagnostikloggar

Apache Cassandra SDK:s klientdrivrutiner som använder CQLv3 användes för klientprogram. Om du har andra drivrutiner som du använder eller om du har problem kan du skicka e-post till askcosmosdbcassandra@microsoft.com.

Ja, du kan använda vanlig syntax för att skapa sammansatta partitionsnycklar.

Nej, sstableloader stöds inte.

Nu har Azure Cosmos DB en optimerad upplevelse för en molnmiljö utan åtgärder. Om du behöver parkoppling skickar du e-post till askcosmosdbcassandra@microsoft.com med en beskrivning av ditt scenario. Vi arbetar med ett erbjudande som hjälper dig att para ihop det lokala eller molnbaserade Cassandra-klustret med API:et för Cassandra för Azure Cosmos DB.

Azure Cosmos DB tillhandahåller två kostnadsfria fullständiga säkerhetskopior som görs med fyra timmars intervall för alla API:er. Så du behöver inte konfigurera ett säkerhetskopieringsschema.

Du kan hantera kvarhållning och frekvens av säkerhetskopior själv.

Om du vill återställa från säkerhetskopian skickar du ett e-postmeddelande till askcosmosdbcassandra@microsoft.com eller skapar ett supportärende. Information om säkerhetskopieringsfunktionen finns i artikeln Automatisk onlinesäkerhetskopiering och återställning med Azure Cosmos DB .

API:et för Cassandra lånar från den globalt distribuerade plattformen i Azure Cosmos DB. För att säkerställa att ditt program kan tolerera datacenteravbrott aktiverar du minst en region till för kontot i Azure-portalen. Mer information finns i Hög tillgänglighet med Azure Cosmos DB.

Du kan lägga till så många regioner som du vill för kontot och kontrollera var det kan redundansväxla till genom att ange en redundansprioritet. Om du vill använda databasen måste du också ange ett program där. När du gör det kommer dina kunder inte att uppleva stilleståndstid.

Nej. API:et för Cassandra stöder sekundära index som fungerar på ett liknande sätt som Apache Cassandra. API:et indexar inte alla attribut som standard.

Ja, det stöds. Du hittar information om hur du aktiverar detta i artikeln Använda Azure Cosmos DB-emulatorn för lokal utveckling och testning .

Du kan läsa om migreringsalternativ i självstudiekursen Migrera dina data till API för Cassandra-kontot i Azure Cosmos DB .

Relaterat innehåll

• Kom igång med elastisk skalning av ett Azure Cosmos DB för Apache Cassandra-konto

Gå vidare