Hantera lagringsläge i Power BI Desktop

I Microsoft Power BI Desktop kan du ange lagringsläget för en tabell. Med lagringsläget kan du styra om Power BI Desktop cachelagrar tabelldata i minnet för rapporter eller inte. Cachelagring innebär att data tillfälligt lagras i minnet.

Att ställa in lagringsläget ger många fördelar. Du kan ange lagringsläget för varje tabell individuellt i din modell. Den här åtgärden möjliggör en enda semantisk modell som ger följande fördelar:

• Frågeprestanda: När användare interagerar med visuella objekt i Power BI-rapporter skickas DAX-frågor (Data Analysis Expressions) till den semantiska modellen. Cachelagring data i minnet genom att korrekt ställa in lagringsläget kan öka frågeprestandan och interaktiviteten i dina rapporter.

• Stora semantiska modeller: Tabeller som inte cachelagras förbrukar inte minne i cachelagringssyfte. Du kan aktivera interaktiv analys över stora semantiska modeller som är för stora eller dyra för att helt cachelagra i minnet. Du kan välja vilka tabeller som är värda att cachelagra och vilka som inte är det.

• Datauppdateringsoptimering: Du behöver inte uppdatera tabeller som inte cachelagras. Du kan minska uppdateringstiderna genom att endast cachelagra de data som krävs för att uppfylla dina serviceavtal och dina affärskrav.

• Nästan realtidskrav: Tabeller med nästan realtidskrav kan ha nytta av att inte cachelagras, för att minska datafördröjningen.

• Tillbakaskrivning: Tillbakaskrivning gör det möjligt för företagsanvändare att utforska konsekvensscenarier genom att ändra cellvärden. Anpassade program kan tillämpa ändringar på datakällan. Tabeller som inte cachelagras kan visa ändringar omedelbart, vilket möjliggör omedelbar analys av effekterna.

Inställningen för lagringsläge i Power BI Desktop är en av tre relaterade funktioner:

• Sammansatta modeller: Tillåter att en rapport har två eller flera dataanslutningar, inklusive DirectQuery-anslutningar eller Import, i valfri kombination. Mer information finns i Använda sammansatta modeller i Power BI Desktop.

• Många-till-många-relationer: Med sammansatta modeller kan du upprätta många-till-många-relationer mellan tabeller. I en många-till-många-relation tas kraven bort för unika värden i tabeller. Den tar också bort tidigare lösningar, till exempel att introducera nya tabeller endast för att upprätta relationer. Mer information finns i Många-till-många-relationer i Power BI Desktop.

• Lagringsläge: Med lagringsläge kan du nu ange vilka visuella objekt som kräver en fråga till serverdelsdatakällor. Visuella objekt som inte kräver en fråga importeras även om de baseras på DirectQuery. Den här funktionen hjälper till att förbättra prestanda och minska belastningen på serverdelen. Tidigare initierade även enkla visuella objekt, till exempel utsnitt, frågor som skickades till serverdelskällor.

Använda egenskapen Lagringsläge

Egenskapen Lagringsläge är en egenskap som du kan ange för varje tabell i din modell och styr hur Power BI cachelagrar tabelldata.

Så här anger du egenskapen Lagringsläge eller visar dess aktuella inställning:

1. I modellvyn väljer du den tabell vars egenskaper du vill visa eller ange.

2. I fönstret Egenskaper expanderar du avsnittet Avancerat och expanderar listrutan Lagringsläge .

   

Du ställer in egenskapen Lagringsläge på något av följande tre värden:

• Importera: Importerade tabeller med den här inställningen cachelagras. Frågor som skickas till Power BI-semantikmodellen som returnerar data från importtabeller kan endast uppfyllas från cachelagrade data.

• DirectQuery: Tabeller med den här inställningen cachelagras inte. Frågor som du skickar till Power BI-semantikmodellen – till exempel DAX-frågor – och som returnerar data från DirectQuery-tabeller kan endast uppfyllas genom att köra frågor på begäran till datakällan. Frågor som du skickar till datakällan använder frågespråket för den datakällan, till exempel SQL.

• Dubbla: Tabeller med den här inställningen kan fungera som cachelagrade eller inte cachelagrade, beroende på kontexten för frågan som skickas till Power BI-semantikmodellen. I vissa fall uppfyller du frågor från cachelagrade data. I andra fall uppfyller du frågor genom att köra en fråga på begäran till datakällan.

Att ändra lagringsläget för en tabell till Import är en oåterkallelig åtgärd. När den här egenskapen har angetts kan den inte senare ändras till antingen DirectQuery eller Dual.

Kommentar

Du kan använda dubbelt lagringsläge i både Power BI Desktop och Power BI-tjänst.

Begränsningar för DirectQuery och dubbla tabeller

Dubbla tabeller har samma funktionsbegränsningar som DirectQuery-tabeller. Dessa begränsningar omfattar begränsade M-transformeringar och begränsade DAX-funktioner i beräknade kolumner. Mer information finns i DirectQuery-begränsningar.

Spridning av inställningen Dubbla

Tänk på följande modell, där alla tabeller kommer från en enda källa som stöder Import och DirectQuery.

Anta att alla tabeller i den här modellen ursprungligen är inställda på DirectQuery. Om du sedan ändrar lagringslägetför tabellen SurveyResponse till Importera visas följande varningsfönster:

Du kan ange dimensionstabellerna (Kund, Geografi och Datum) till Dubbla för att minska antalet begränsade relationer i semantikmodellen och förbättra prestandan. Begränsade relationer omfattar normalt minst en DirectQuery-tabell där kopplingslogik inte kan push-överföras till källsystemen. Eftersom dubbla tabeller kan fungera som directquery- eller importtabeller undviks den här situationen.

Spridningslogik är utformad för att hjälpa till med modeller som innehåller många tabeller. Anta att du har en modell med 50 tabeller och att endast vissa faktatabeller (transaktionella) måste cachelagras. Logiken i Power BI Desktop beräknar den minsta uppsättningen dimensionstabeller som måste anges till Dubbla, så att du inte behöver göra det.

Spridningslogik passerar bara till ena sidan av en-till-många-relationer.

Användningsexempel för lagringsläge

Tänk dig att tillämpa följande egenskapsinställningar för lagringsläge:

Register	Lagringsläge
Sales	DirectQuery
SurveyResponse	Import
Datum	Dubbla
Kund	Dubbla
Geografi	Dubbla

Om du ställer in dessa egenskaper för lagringsläge resulterar det i följande beteenden, förutsatt att tabellen Sales har betydande datavolym:

• Power BI Desktop cachelagrar dimensionstabeller, Datum, Kund och Geografi, så inläsningstiderna för de första rapporterna är snabba när de hämtar utsnittsvärden som ska visas.

• Power BI Desktop cachelagar inte tabellen Försäljning . Power BI Desktop ger följande resultat genom att inte cachelagra den här tabellen:

  • Datauppdateringstiderna förbättras och minnesförbrukningen minskas.
  • Rapportfrågor som baseras på tabellen Försäljning körs i DirectQuery-läge. De här frågorna kan ta längre tid men är närmare realtid eftersom ingen svarstid för cachelagring introduceras.

• Rapportfrågor som baseras på tabellen SurveyResponse returneras från minnesintern cache och är därför relativt snabba.

Frågor som träffar eller missar cacheminnet

Om du ansluter SQL Profiler till diagnostikporten för Power BI Desktop kan du se vilka frågor som träffar eller missar minnesintern cache genom att utföra en spårning som baseras på följande händelser:

• Frågehändelser\Fråga börja
• Frågebearbetning\Vertipaq SE-fråga börjar
• Frågebearbetning\DirectQuery Begin

För varje Query Begin-händelse kontrollerar du andra händelser med samma ActivityID. Om det till exempel inte finns någon DirectQuery Begin-händelse , men det finns en Vertipaq SE Query Begin-händelse , besvaras frågan från cacheminnet.

Frågor som refererar till Dubbla tabeller returnerar om möjligt data från cacheminnet. annars återgår de till DirectQuery.

Följande fråga fortsätter från föregående tabell. Den refererar bara till en kolumn från tabellen Datum , som är i dubbelt läge. Därför bör frågan träffa cacheminnet:

Följande fråga refererar endast till en kolumn från tabellen Försäljning , som är i DirectQuery-läge . Därför bör den inte träffa cachen:

Följande fråga är intressant eftersom den kombinerar båda kolumnerna. Den här frågan träffar inte cacheminnet. Du kan först förvänta dig att den hämtar CalendarYear-värden från cacheminnet och SalesAmount-värden från källan och sedan kombinerar resultaten, men den här metoden är mindre effektiv än att skicka åtgärden SUM/GROUP BY till källsystemet. Om åtgärden skickas ned till källan är antalet rader som returneras sannolikt mycket mindre:

Kommentar

Det här beteendet skiljer sig från många-till-många-relationer i Power BI Desktop när cachelagrade och icke-cachelagrade tabeller kombineras.

Cacheminnen ska vara synkroniserade

Frågorna som visas i föregående avsnitt visar att Dubbla tabeller ibland träffar cacheminnet och ibland inte gör det. Om cacheminnet därför är inaktuellt kan olika värden returneras. Frågekörningen försöker inte maskera dataproblem genom att till exempel filtrera DirectQuery-resultat för att matcha cachelagrade värden. Det är ditt ansvar att känna till dina dataflöden och du bör utforma detta. Det finns etablerade tekniker för att hantera sådana fall vid källan, om det behövs.

Läget För dubbel lagring är en prestandaoptimering. Det bör endast användas på sätt som inte äventyrar möjligheten att uppfylla affärskraven. För alternativa beteenden bör du överväga att använda de tekniker som beskrivs i många-till-många-relationer i Power BI Desktop.

Datavy

Om minst en tabell i semantikmodellen har sitt lagringsläge inställt på antingen Import eller Dubbla visas fliken Datavy .

När du väljer Dubbla tabeller och Importera tabeller i datavyn visar de cachelagrade data. DirectQuery-tabeller visar inte data och ett meddelande visas som anger att DirectQuery-tabeller inte kan visas.

Beaktanden och begränsningar

Det finns några begränsningar för den aktuella versionen av lagringsläget och dess korrelation med sammansatta modeller.

Följande realtidsanslutningskällor (flerdimensionella) kan inte användas med sammansatta modeller:

• SAP HANA
• SAP Business Warehouse

När du ansluter till dessa flerdimensionella källor med DirectQuery kan du inte ansluta till en annan DirectQuery-källa eller kombinera den med importerade data.

De befintliga begränsningarna för att använda DirectQuery gäller fortfarande när du använder sammansatta modeller. Många av dessa begränsningar är nu per tabell, beroende på tabellens lagringsläge. En beräknad kolumn i en importerad tabell kan till exempel referera till andra tabeller, men en beräknad kolumn i en DirectQuery-tabell är fortfarande begränsad till att endast referera till kolumner i samma tabell. Andra begränsningar gäller för modellen som helhet, om någon av tabellerna i modellen är DirectQuery.

Relaterat innehåll

Mer information om sammansatta modeller och DirectQuery finns i följande artiklar:

• Använda sammansatta modeller i Power BI Desktop
• Tillämpa många-till-många-relationer i Power BI Desktop
• DirectQuery i Power BI
• Power BI-datakällor