Dela via


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 av data i minnet genom att ange lagringsläget korrekt 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.

  • krav på nära realtid: Tabeller med nästan realtidskrav kan ha nytta av att inte cachelagras för att minska datafördröjningen.

  • Tillbakaskrivning: Med tillbakaskrivning kan affärsanvändare utforska vad-om-scenarier 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 Storage-läge är en egenskap som du kan ange i varje tabell i din modell och styr hur Power BI cachelagrar tabelldata.

Om du vill ange egenskapen Lagringsläge eller visa dess aktuella inställning:

  1. I vyn Modell 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.

    Skärmbild av relationsvyn framhäver listrutan för att ändra lagringsläge.

Du ställer in egenskapen Storage-läge till 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 besvarar du förfrågningar 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äge för en tabell till Importera är en oåterkallelig åtgärd. När den här egenskapen har angetts kan den inte senare ändras till antingen DirectQuery eller Dubbla.

Notera

Du kan använda lagringsläge med Dubbla i både Power BI Desktop och Power BI-tjänsten.

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 Dubbla inställningen

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

Skärmbild av exemplet Relationsvy för lagringsläge.

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

Skärmbild som visar ett varningsfönster som beskriver resultatet av att ändra lagringsläget till Import.

Du kan ange dimensionstabellerna (Customer, Geographyoch Date) 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ättning dimensionstabeller som behöver sättas till Dubbla, så att du inte behöver göra det.

Spridningslogiken behandlar bara ena sidan av ett-till-många-relationer.

Användningsexempel för lagringsläge

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

Bord Lagringsläge
Försäljning DirectQuery
SurveyResponse Import
Datum Dubbel
Kund Dubbel
Geografi Dubbel

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, Date, Customeroch Geography, så inläsningstiderna för de första rapporterna är snabba när de hämtar utsnittsvärden som ska visas.

  • Power BI Desktop cachelagr inte tabellen Sales. 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 Sales 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.

Förfrågningar 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ågebörjan
  • Frågebearbetning\Vertipaq SE-fråga börjar
  • Frågebearbetning\DirectQuery Begin

För varje Fråga börjar händelse, kontrollera andra händelser med samma Aktivitets-ID. 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 Date, som är i Dubbelläget. Därför bör frågan träffa cacheminnet:

Skärmbild som visar texten i frågan som refererar till tabellen Datum.

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

Skärmbild som visar texten i frågan som refererar till tabellen Försäljning.

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 kombinera 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:

Skärmbild som visar texten i frågan som refererar till både tabellen Datum och tabellen Försäljning.

Obs

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 hållas 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.

Lagringsläget dubbla ä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.

Tabellvy

Om minst en tabell i semantikmodellen har sitt lagringsläge inställt på antingen Importera eller Dubblavisas fliken Tabell vy.

Skärmbild som framhäver ikonen för Tabellvy.

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

Överväganden 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.

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