Richtlijnen voor het DirectQuery-model in Power BI DesktopDirectQuery model guidance in Power BI Desktop

Dit artikel is gericht op gegevensmodelleerders die Power BI DirectQuery-modellen ontwikkelen met behulp van Power BI Desktop of de Power BI-service.This article targets data modelers developing Power BI DirectQuery models, developed by using either Power BI Desktop or the Power BI service. Hierin worden use cases, beperkingen en richtlijnen van DirectQuery beschreven.It describes DirectQuery use cases, limitations, and guidance. De richtlijnen zijn met name ontworpen om u te helpen bepalen of DirectQuery de juiste modus voor uw model is en om de prestaties van uw rapporten te verbeteren op basis van DirectQuery-modellen.Specifically, the guidance is designed to help you determine whether DirectQuery is the appropriate mode for your model, and to improve the performance of your reports based on DirectQuery models. Dit artikel is van toepassing op DirectQuery-modellen die worden gehost in de Power BI-service of Power BI Report Server.This article applies to DirectQuery models hosted in the Power BI service or Power BI Report Server.

Dit artikel is niet bedoeld om een volledige uitleg te geven over het ontwerpen van DirectQuery-modellen.This article is not intended to provide a complete discussion on DirectQuery model design. Raadpleeg het artikel DirectQuery-modellen in Power BI Desktop voor een inleiding.For an introduction, refer to the DirectQuery models in Power BI Desktop article. Voor een uitgebreidere discussie gaat u rechtstreeks naar de whitepaper DirectQuery in SQL Server 2016 Analysis Services.For a deeper discussion, refer directly to the DirectQuery in SQL Server 2016 Analysis Services whitepaper. Houd er rekening mee dat in de whitepaper het gebruik van DirectQuery in SQL Server Analysis Services wordt beschreven.Bear in mind that the whitepaper describes using DirectQuery in SQL Server Analysis Services. Veel van de inhoud is echter nog steeds van toepassing op Power BI DirectQuery-modellen.Much of the content, however, is still applicable to Power BI DirectQuery models.

Samengestelde modellen worden niet specifiek in dit artikel behandeld.This article does not directly cover Composite models. Een samengesteld model bestaat uit ten minste één DirectQuery-bron en mogelijk meer.A Composite model will consist of at least one DirectQuery source, and possibly more. De richtlijnen die in dit artikel worden beschreven, zijn nog steeds relevant, ten minste gedeeltelijk, voor het ontwerpen van samengestelde modellen.The guidance described in this article is still relevant—at least in part—to Composite model design. De gevolgen van het combineren van importtabellen met DirectQuery-tabellen vallen echter niet binnen het bereik van dit artikel.However, the implications of combining Import tables with DirectQuery tables are not in scope for this article. Zie Samengestelde modellen in Power BI Desktop gebruiken voor meer informatie.For more information, see Use composite models in Power BI Desktop.

Het is belangrijk dat u begrijpt dat DirectQuery-modellen leiden tot een andere workload voor de Power BI-omgeving (Power BI-service of Power BI Report Server) en de onderliggende gegevensbronnen.It is important to understand that DirectQuery models impose a different workload on the Power BI environment (Power BI service or Power BI Report Server) and also on the underlying data sources. Als u bepaalt dat DirectQuery de juiste ontwerpmethode is, raden we u aan de juiste personen bij het project te betrekken.If you determine that DirectQuery is the appropriate design approach, we recommend that you engage the right people on the project. We zien vaak dat een geslaagde implementatie van een DirectQuery-model het resultaat is van een team van IT-professionals die nauw samenwerken.We often see that a successful DirectQuery model deployment is the result of a team of IT professionals working closely together. Het team bestaat doorgaans uit modelontwikkelaars en de brondatabasebeheerders.The team usually consists of model developers and the source database administrators. Ook kunnen er gegevensarchitecten en datawarehouse- en ETL-ontwikkelaars bij betrokken zijn.It can also involve data architects, and data warehouse and ETL developers. Vaak moeten optimalisaties rechtstreeks op de gegevensbron worden toegepast om goede prestaties te krijgen.Often, optimizations need to be applied directly to the data source to achieve good performance results.

Ontwerpen in Power BI DesktopDesign in Power BI Desktop

Er kan rechtstreeks verbinding worden gemaakt met zowel Azure SQL Data Warehouse als Azure HDInsight Spark-gegevensbronnen, zonder Power BI Desktop te hoeven gebruiken.Both Azure SQL Data Warehouse and Azure HDInsight Spark data sources can be connected to directly, without the need to use Power BI Desktop. U kunt dit doen door in de Power BI-service achtereenvolgens Gegevens ophalen en de tegel Databases te kiezen.It is achieved in the Power BI service by "Getting Data" and choosing the Databases tile. Zie Azure SQL Data Warehouse met DirectQuery voor meer informatie.For more information, see Azure SQL Data Warehouse with DirectQuery.

Een rechtstreekse verbinding is weliswaar handig, maar het gebruik van deze methode wordt niet aanbevolen.While direct connect is convenient, we don't recommend that you use this approach. De belangrijkste reden is dat het niet mogelijk is om de modelstructuur te vernieuwen indien het onderliggende gegevensbronschema wordt gewijzigd.The main reason is that it is not possible to refresh the model structure should the underlying data source schema change.

Het wordt aanbevolen Power BI Desktop te gebruiken om al uw DirectQuery-modellen te maken en te beheren.We recommend that you use Power BI Desktop to create and manage all of your DirectQuery models. Deze methode biedt u complete controle om het model dat u nodig hebt te definiëren, inclusief het gebruik van ondersteunde functies zoals hiërarchieën, berekende kolommen, metingen en meer.This approach provides you with complete control to define the model that you need, including the use of supported features like hierarchies, calculated columns, measures, and more. Hiermee kunt u ook het modelontwerp herzien, indien het onderliggende gegevensbronschema wordt gewijzigd.It will also allow you to revise the model design should the underlying data source schema change.

Prestaties van gegevensbronnen optimaliserenOptimize data source performance

De relationele databasebron kan op verschillende manieren worden geoptimaliseerd, zoals wordt beschreven in de volgende lijst met opsommingstekens.The relational database source can be optimized in several ways, as described in the following bulleted list.

Notitie

We begrijpen dat niet alle modelleerders over de machtigingen of vaardigheden beschikken om een relationele database te optimaliseren.We understand that not all modelers have the permissions or skills to optimize a relational database. Hoewel dit de voorkeurslaag is om de gegevens voor een DirectQuery-model voor te bereiden, kunt u een aantal optimalisaties ook bereiken bij het ontwerpen van het model, zonder de brondatabase te hoeven aanpassen.While it is the preferred layer to prepare the data for a DirectQuery model, some optimizations can also be achieved in the model design, without modifying the source database. De beste optimalisatieresultaten worden echter vaak bereikt door optimalisaties op de brondatabase toe te passen.However, best optimization results are often achieved by applying optimizations to the source database.

  • Controleer of de gegevensintegriteit compleet is: Het is met name belangrijk dat tabellen van het dimensietype een kolom met unieke waarden (dimensiesleutel) bevatten die aan de tabel(len) van het feittype worden toegewezen.Ensure data integrity is complete: It is especially important that dimension-type tables contain a column of unique values (dimension key) that maps to the fact-type table(s). Het is ook belangrijk dat dimensiekolommen van het feittype geldige dimensiesleutelwaarden bevatten.It's also important that fact-type dimension columns contain valid dimension key values. Hierdoor kunnen efficiëntere modelrelaties worden geconfigureerd waarvoor overeenkomende waarden aan beide zijden van relaties worden verwacht.They will allow configuring more efficient model relationships that expect matched values on both sides of relationships. Wanneer de brongegevens niet integer zijn, wordt het aanbevolen een 'onbekende' dimensierecord toe te voegen, om de gegevens effectief te herstellen.When the source data lacks integrity, it's recommended that an "unknown" dimension record is added to effectively repair the data. U kunt bijvoorbeeld een rij toevoegen aan de tabel Product als vertegenwoordiging van een onbekend product en hier vervolgens een sleutel aan toe te voegen die buiten het bereik ligt, zoals -1.For example, you can add a row to the Product table to represent an unknown product, and then assign it an out-of-range key, like -1. Als rijen in de tabel Verkoop een ontbrekende productsleutelwaarde bevatten, worden deze vervangen door -1.If rows in the Sales table contain a missing product key value, substitute them with -1. Hierdoor wordt ervoor gezorgd dat aan elke productsleutelwaarde in Verkoop een bijbehorende rij in de tabel Product is gekoppeld.It will ensure every Sales product key value has a corresponding row in the Product table.

  • Voeg indexen toe: Definieer juiste indexen, in tabellen of weergaven, om gegevens efficiënt te kunnen ophalen voor het filteren en groeperen van rapportvisuals.Add indexes: Define appropriate indexes—on tables or views—to support the efficient retrieval of data for the expected report visual filtering and grouping. Zie Architectuur van de SQL Server-index en ontwerphandleiding voor nuttige informatie over richtlijnen voor het ontwerpen van indexen voor SQL Server-, Azure SQL Database- of Azure SQL Data Warehouse-bronnen.For SQL Server, Azure SQL Database or Azure SQL Data Warehouse sources, see SQL Server Index Architecture and Design Guide for helpful information on index design guidance. Zie Aan de slag met Columnstore voor realtime operationele analyse voor vluchtige SQL Server- of Azure SQL Database-bronnen.For SQL Server or Azure SQL Database volatile sources, see Get started with Columnstore for real-time operational analytics.

  • Ontwerp gedistribueerde tabellen: Voor Azure SQL Data Warehouse-bronnen, waarvoor gebruik wordt gemaakt van MPP-architectuur (Massively Parallel Processing), kunt u grote tabellen van het feittype configureren als tabellen met hashverdeling en tabellen van het dimensietype om te repliceren naar alle rekenknooppunten.Design distributed tables: For Azure SQL Data Warehouse sources, which leverage Massively Parallel Processing (MPP) architecture, consider configuring large fact-type tables as hash distributed, and dimension-type tables to replicate across all the compute nodes. Zie Richtlijnen voor het ontwerpen van gedistribueerde tabellen in Azure SQL Data Warehouse voor meer informatie.For more information, see Guidance for designing distributed tables in Azure SQL Data Warehouse.

  • Zorg ervoor dat vereiste gegevenstransformaties worden gematerialiseerd: Voor relationele SQL Server-databasebronnen (en andere relationele databasebronnen) kunnen berekende kolommen worden toegevoegd aan tabellen.Ensure required data transformations are materialized: For SQL Server relational database sources (and other relational database sources), computed columns can be added to tables. Deze kolommen zijn gebaseerd op een expressie, zoals Quantity vermenigvuldigd met UnitPrice.These columns are based on an expression, like Quantity multiplied by UnitPrice. Berekende kolommen kunnen permanent worden gemaakt (gematerialiseerd) en kunnen soms, zoals gewone kolommen, worden geïndexeerd.Computed columns can be persisted (materialized) and, like regular columns, sometimes they can be indexed. Zie Indexen voor berekende kolommen voor meer informatie.For more information, see Indexes on Computed Columns.

    U kunt geïndexeerde weergaven gebruiken waarmee gegevens uit een feitentabel vooraf nauwkeuriger kunnen worden samengevoegd.Consider also indexed views that can pre-aggregate fact table data at a higher grain. Als gegevens in de tabel Verkoop bijvoorbeeld worden opgeslagen op het niveau van de orderregel, kunt u een weergave maken om deze gegevens samen te vatten.For example, if the Sales table stores data at order line level, you could create a view to summarize this data. De weergave kan worden gebaseerd op een SELECT-instructie waarmee de gegevens uit de tabel Verkoop op datum (op maandniveau), klant of product worden gegroepeerd en waarmee meetwaarden worden samengevat zoals verkoop, hoeveelheid enzovoort. De weergave kan vervolgens worden geïndexeerd.The view could be based on a SELECT statement that groups the Sales table data by date (at month level), customer, product, and summarizes measure values like sales, quantity, etc. The view can then be indexed. Zie Geïndexeerde weergaven maken voor SQL Server- of Azure SQL Database-bronnen.For SQL Server or Azure SQL Database sources, see Create Indexed Views.

  • Materialiseer een datumtabel: Een veelvoorkomende vereiste voor modelleren betreft het toevoegen van een datumtabel om filters op basis van tijd te ondersteunen.Materialize a date table: A common modeling requirement involves adding a date table to support time-based filtering. Ter ondersteuning van de bekende op tijd gebaseerde filters in uw organisatie, maakt u een tabel in de brondatabase en zorgt u ervoor dat hierin datumbereiken worden geladen die overeenkomen met de datums in de feitentabel.To support the known time-based filters in your organization, create a table in the source database, and ensure it is loaded with a range of dates encompassing the fact table dates. Zorg er ook voor dat de tabel kolommen bevat voor nuttige tijdperioden, zoals jaar, kwartaal, maand, week, enzovoort.Also ensure that it includes columns for useful time periods, like year, quarter, month, week, etc.

Modelontwerp optimaliserenOptimize model design

Een DirectQuery-model kan op verschillende manieren worden geoptimaliseerd, zoals wordt beschreven in de volgende opsomming.A DirectQuery model can be optimized in many ways, as described in the following bulleted list.

  • Vermijd complexe Power Query-query's: Een efficiënt modelontwerp kan worden bereikt door ervoor te zorgen dat er geen transformaties meer hoeven te worden toegepast door de Power Query-query's.Avoid complex Power Query queries: An efficient model design can be achieved by removing the need for the Power Query queries to apply any transformations. Dit houdt in dat elke query wordt toegewezen aan één relationele databasebrontabel of -weergave.It means that each query maps to a single relational database source table or view. U kunt een voorbeeld bekijken van een representatie van de daadwerkelijke SQL-queryinstructie voor een door Power Query toegepaste stap door de optie Systeemeigen query weergeven te selecteren.You can preview a representation of the actual SQL query statement for a Power Query applied step, by selecting the View Native Query option.

    Schermopname van Power BI Desktop met de optie Systeemeigen query weergeven onder Toegepaste stappen.

    Schermopname van Power BI Desktop met het venster Systeemeigen query.

  • Controleer het gebruik van berekende kolommen en wijzigingen van het gegevenstype: DirectQuery-modellen bieden ondersteuning voor het toevoegen van berekeningen en Power Query-stappen om gegevenstypen om te zetten.Examine the use of calculated columns and data type changes: DirectQuery models support adding calculations and Power Query steps to convert data types. Er worden echter vaak betere prestaties bereikt door, waar mogelijk, transformatieresultaten in de relationele databasebron te materialiseren.However, better performance is often achieved by materializing transformation results in the relational database source, when possible.

  • Gebruik geen Power Query-filtering voor relatieve datums: Het is mogelijk om relatieve datumfiltering te definiëren in een Power Query-query.Do not use Power Query relative date filtering: It's possible to define relative date filtering in a Power Query query. Bijvoorbeeld om de verkooporders op te halen die in het afgelopen jaar zijn gemaakt (ten opzicht van de datum van vandaag).For example, to retrieve to the sales orders that were created in the last year (relative to today's date). Dit type filters wordt omgezet in een inefficiënte systeemeigen query:This type of filter translates to an inefficient native query, as follows:

    …
    from [dbo].[Sales] as [_]
    where [_].[OrderDate] >= convert(datetime2, '2018-01-01 00:00:00') and [_].[OrderDate] < convert(datetime2, '2019-01-01 00:00:00'))  
    

    Een betere ontwerpmethode is het opnemen van relatieve-tijdkolommen in de datumtabel.A better design approach is to include relative time columns in the date table. In deze kolommen worden offsetwaarden ten opzichte van de huidige datum opgeslagen.These columns store offset values relative to the current date. In de kolom RelativeYear staat de waarde nul bijvoorbeeld voor het huidige jaar, -1 voor het jaar daarvoor enzovoort. Bij voorkeur wordt de kolom RelativeYear gematerialiseerd in de datumtabel.For example, in a RelativeYear column, the value zero represents current year, -1 represents previous year, etc. Preferably, the RelativeYear column is materialized in the date table. Hoewel minder efficiënt, kunt u deze kolom ook als een door een model berekende kolom toevoegen, op basis van de expressie waarvoor de DAX-functies TODAY en DATE worden gebruikt.While less efficient, it could also be added as a model calculated column, based on the expression using the TODAY and DATE DAX functions.

  • Houd metingen simpel: Zeker in eerste instantie is het raadzaam om metingen te beperken tot eenvoudige statistische functies.Keep measures simple: At least initially, it's recommended to limit measures to simple aggregates. De statische functies zijn SUM, COUNT, MIN, MAX en AVERAGE.The aggregate functions include SUM, COUNT, MIN, MAX, and AVERAGE. Als de metingen voldoende reageren, kunt u vervolgens experimenteren met complexere metingen; let wel goed op de prestaties van elke meting.Then, if the measures are sufficiently responsive, you can experiment with more complex measures, but paying attention to the performance for each. Hoewel de DAX-functie CALCULATE kan worden gebruikt om uitgebreide meetexpressies te produceren waarmee de filtercontext kan worden gemanipuleerd, kunnen hierdoor dure systeemeigen query's worden gegenereerd die niet goed presteren.While the CALCULATE DAX function can be used to produce sophisticated measure expressions that manipulate filter context, they can generate expensive native queries that do not perform well.

  • Vermijd relaties tussen berekende kolommen: Met modelrelaties kan alleen een relatie tussen één kolom in één tabel en één kolom in een andere tabel tot stand worden gebracht.Avoid relationships on calculated columns: Model relationships can only relate a single column in one table to a single column in a different table. Soms is het echter noodzakelijk om een relatie tussen tabellen tot stand te brengen met behulp van meerdere kolommen.Sometimes, however, it is necessary to relate tables by using multiple columns. De tabellen Verkoop en Geografie zijn bijvoorbeeld gerelateerd aan twee kolommen: Land en Stad.For example, the Sales and Geography tables are related by two columns: Country and City. Als u een relatie tussen de tabellen tot stand wilt brengen, is één kolom vereist en moet de kolom in de tabel Geografie unieke waarden bevatten.To create a relationship between the tables, a single column is required, and in the Geography table, the column must contain unique values. U kunt dit resultaat bereiken door het land en de stad met een streepje als scheidingsteken samen te voegen.Concatenating the country and city with a hyphen separator could achieve this result.

    De gecombineerde kolom kan worden gemaakt met ofwel een aangepaste Power Query-kolom of in het model als een berekende kolom.The combined column can be created with either a Power Query custom column, or in the model as a calculated column. Dit moet echter worden vermeden, aangezien de berekeningsexpressie zal worden ingesloten in de bronquery's.However, it should be avoided as the calculation expression will be embedded into the source queries. Niet alleen is dit inefficiënt, maar het voorkomt doorgaans ook het gebruik van indexen.Not only is it inefficient, it commonly prevents the use of indexes. In plaats daarvan voegt u gematerialiseerde kolommen in de relationele databasebron toe en kunt u deze indexeren.Instead, add materialized columns in the relational database source, and consider indexing them. U kunt ook surrogaatsleutelkolommen toevoegen aan tabellen van het dimensietype. Dit is een gangbare methode bij het ontwerpen van relationele datawarehouses.You can also consider adding surrogate key columns to dimension-type tables, which is a common practice in relational data warehouse designs.

    Er is één uitzondering op deze richtlijnen en dit heeft betrekking op het gebruik van de DAX-functie COMBINEVALUES.There is one exception to this guidance, and it concerns the use of the COMBINEVALUES DAX function. Het doel van deze functie is ondersteuning bieden aan relaties tussen modellen met meerdere kolommen.The purpose of this function is to support multi-column model relationships. Hierbij wordt geen expressie gegenereerd die door de relatie wordt gebruikt, maar een SQL-join-predicaat met meerdere kolommen.Rather than generate an expression that the relationship uses, it generates a multi-column SQL join predicate.

  • Vermijd relaties tussen kolommen van het type Unieke id: Power BI biedt niet vanuit het systeem zelf ondersteuning voor het gegevenstype Unieke id (GUID).Avoid relationships on "Unique Identifier" columns: Power BI does not natively support the unique identifier (GUID) data type. Wanneer u een relatie tussen kolommen van dit type definieert, genereert Power BI een bronquery met een join waarbij een cast-conversie betrokken is.When defining a relationship between columns of this type, Power BI will generate a source query with a join involving a cast. Deze conversie van tijdgegevens van een query leidt doorgaans tot slechte prestaties.This query-time data conversion commonly results in poor performance. Totdat deze situatie is geoptimaliseerd, is de enige oplossing het gebruik van kolommen van een alternatief gegevenstype in de onderliggende database.Until this case is optimized, the only workaround is to materialize columns of an alternative data type in the underlying database.

  • Verberg de eenzijdige kolom van relaties: De eenzijdige kolom van een relatie moet worden verborgen.Hide the one-side column of relationships: The one-side column of a relationship should be hidden. (Dit is doorgaans de primaire sleutelkolom van tabellen van het dimensietype.) Wanneer deze kolom verborgen is, is deze niet beschikbaar in het deelvenster Velden en kan deze dus niet worden gebruikt om een visual te configureren.(It is usually the primary key column of dimension-type tables.) When hidden, it is not available in the Fields pane and so cannot be used to configure a visual. De veelzijdige kolom kan zichtbaar blijven als dit handig is om rapporten te groeperen of te filteren op de kolomwaarden.The many-side column can remain visible if it is useful to group or filter reports by the column values. U kunt bijvoorbeeld een model gebruiken waarbij er een relatie bestaat tussen de tabellen Verkoop en Product.For example, consider a model where a relationship exists between Sales and Product tables. De relatiekolommen bevatten waarden van een product-SKU (Stock-Keeping Unit).The relationship columns contain product SKU (Stock-Keeping Unit) values. Als een product-SKU moet worden toegevoegd aan visuals, mag deze alleen zichtbaar worden gemaakt in de tabel Verkoop.If product SKU must be added to visuals, it should be visible only in the Sales table. Wanneer deze kolom wordt gebruikt om in een visual te filteren of te groeperen, genereert Power BI een query waarbij de tabellen Verkoop en Product niet hoeven te worden gekoppeld.When this column is used to filter or group in a visual, Power BI will generate a query that does not need to join the Sales and Product tables.

  • Stel relaties in om integriteit af te dwingen: Met de eigenschap Referentiële integriteit aannemen van DirectQuery-relaties wordt bepaald of door Power BI bronquery's worden gegenereerd met behulp van een inner join in plaats van een outer join.Set relationships to enforce integrity: The Assume Referential Integrity property of DirectQuery relationships determines whether Power BI will generate source queries using an inner join rather than an outer join. Dit is in het algemeen beter voor de queryprestaties, hoewel de specifieke relationele databasebron hierbij ook een rol speelt.It generally improves query performance, though it does depend on the specifics of the relational database source. Zie Instellingen voor referentiële integriteit aannemen in Power BI Desktop voor meer informatie.For more information, see Assume referential integrity settings in Power BI Desktop.

  • Vermijd het gebruik van bidirectionele relatiefiltering: Het gebruik van bidirectionele relatiefiltering kan leiden tot queryinstructies die niet goed werken.Avoid use of bi-directional relationship filtering: Use of bi-directional relationship filtering can lead to query statements that don't perform well. Gebruik deze relatiefunctie alleen wanneer dit nodig is. Dit is doorgaans het geval wanneer u een veel-op-veel-relatie implementeert op een overbruggingstabel.Only use this relationship feature when necessary, and it's usually the case when implementing a many-to-many relationship across a bridging table. Zie Relaties met een veel-op-veel-kardinaliteit gebruiken in Power BI Desktop voor meer informatie.For more information, see Relationships with a many-many cardinality in Power BI Desktop.

  • Beperk het aantal parallelle query's: U kunt het maximumaantal verbindingen instellen dat door DirectQuery wordt geopend voor elke onderliggende gegevensbron.Limit parallel queries: You can set the maximum number of connections DirectQuery opens for each underlying data source. Hiermee regelt u het aantal query's dat gelijktijdig naar de gegevensbron wordt verzonden.It controls the number of queries concurrently sent to the data source.

    Schermopname van Power BI Desktop met het venster Direct Query-opties.

    Deze instelling wordt alleen ingeschakeld als er ten minste één DirectQuery-gegevensbron in het model staat.The setting is only enabled when there's at least one DirectQuery source in the model. De waarde is van toepassing op alle DirectQuery-bronnen en op eventuele nieuwe DirectQuery-bronnen die worden toegevoegd aan het model.The value applies to all DirectQuery sources, and to any new DirectQuery sources added to the model.

    Als u het Maximumaantal verbindingen per gegevensbron vergroot, kunnen er meer query's (tot het maximumaantal dat is opgegeven) worden verzonden naar de onderliggende gegevensbron, wat nuttig is als er meerdere visuals op één pagina staan, of als veel gebruikers een rapport tegelijk bekijken.Increasing the Maximum Connections per Data Source value ensures more queries (up to the maximum number specified) can be sent to the underlying data source, which is useful when numerous visuals are on a single page, or many users access a report at the same time. Wanneer het maximale aantal verbindingen is bereikt, worden aanvullende query's in een wachtrij geplaatst tot er weer een verbinding beschikbaar is.Once the maximum number of connections is reached, further queries are queued until a connection becomes available. Als u de limiet verhoogt, resulteert dit in een grotere belasting voor de onderliggende gegevensbron. Met de instelling worden de algehele prestaties dus niet gegarandeerd beter.Increasing this limit does result in more load on the underlying data source, so the setting isn't guaranteed to improve overall performance.

    Wanneer het model wordt gepubliceerd naar Power BI, hangt het maximumaantal gelijktijdige query's dat naar de onderliggende gegevensbron wordt verzonden, ook af van de omgeving.When the model is published to Power BI, the maximum number of concurrent queries sent to the underlying data source also depends on the environment. In verschillende omgevingen (zoals Power BI, Power BI Premium en Power BI Report Server) kunnen verschillende doorvoerbeperkingen gelden.Different environments (such as Power BI, Power BI Premium, or Power BI Report Server) each can impose different throughput constraints. Zie Power BI Premium-capaciteiten implementeren en beheren voor meer informatie over beperkingen voor Power BI Premium-capaciteitsresources.For more information about Power BI Premium capacity resource limitations, see Deploying and Managing Power BI Premium Capacities.

Rapportontwerpen optimaliserenOptimize report designs

Rapporten op basis van een DirectQuery-gegevensset kunnen op verschillende manieren worden geoptimaliseerd, zoals wordt beschreven in de opsomming.Reports based on a DirectQuery dataset can be optimized in many ways, as described in the following bulleted list.

  • Schakel queryreductietechnieken in: Bij de Opties en instellingen voor Power BI Desktop vindt u de pagina Queryreductie.Enable query reduction techniques: Power BI Desktop Options and Settings includes a Query Reduction page. Deze pagina biedt drie nuttige opties.This page has three helpful options. Het is mogelijk om kruislings markeren en kruislings filteren standaard uit te schakelen, hoewel dit kan worden overschreven door interacties te bewerken.It's possible to disable cross-highlighting and cross-filtering by default, though it can be overridden by editing interactions. Het is ook mogelijk om de knop Toepassen weer te geven op slicers en filters.It is also possible to show an Apply button on slicers and filters. De slicer- of filteropties worden pas toegepast zodra de rapportgebruiker op de knop klikt.The slicer or filter options will not be applied until the report user clicks the button. Als u deze opties inschakelt, raden we u aan dit te doen wanneer u het rapport maakt.If you enable these options, we recommend that you do so when first creating the report.

    Schermopname van Power BI Desktop met het filter voor queryreductie in het venster Opties.

  • Pas eerst filters toe: Wanneer u voor het eerst rapporten ontwerpt, raden we u aan alle van toepassing zijnde filters toe te passen, op rapport-, pagina- of visualniveau, voordat u velden aan de visualvelden toewijst.Apply filters first: When first designing reports, we recommend that you apply any applicable filters—at report, page, or visual level—before mapping fields to the visual fields. U kunt bijvoorbeeld eerst het filter op het veld Jaar toepassen en pas daarna de meetwaarden voor Land en Verkoop verslepen en dan filtering op basis van een specifiek jaar toepassen.For example, rather than dragging in the Country and Sales measures, and then filtering by a particular year, apply the filter on the Year field first. De reden hiervoor is dat bij elke stap van het bouwen van een visual een query wordt verstuurd, en hoewel het mogelijk is om vervolgens een andere wijziging door te voeren voordat de eerste query is voltooid, wordt de onderliggende gegevensbron hierbij onnodig belast.It's because each step of building a visual will send a query, and whilst it's possible to then make another change before the first query has completed, it still places unnecessary load on the underlying data source. Door filters in een vroeg stadium toe te passen, zijn de tussenliggende query's over het algemeen minder belastend en sneller.By applying filters early, it generally makes those intermediate queries less costly and faster. Als u niet al in een vroeg stadium filters toepast, kan dit er bovendien toe leiden dat u de limiet van één miljoen rijen overschrijdt, zoals hierboven is beschreven.Also, failing to apply filters early can result in exceeding the 1 million-row limit, as described above.

  • Beperk het aantal visualisaties op een pagina: Wanneer een rapportpagina wordt geopend (en wanneer paginafilters worden toegepast) worden alle visuals op een pagina vernieuwd.Limit the number of visuals on a page: When a report page is opened (and when page filters are applied) all of the visuals on a page are refreshed. Er is echter een limiet op het aantal query's dat tegelijkertijd kan worden verzonden. Deze limiet wordt opgelegd door de Power BI-omgeving en de instelling voor het model Maximumaantal verbindingen per gegevensbron, zoals hierboven beschreven.However, there is a limit on the number of queries that can be sent in parallel, imposed by the Power BI environment and the Maximum Connections per Data Source model setting, as described above. Dus als het aantal paginavisuals toeneemt, is de kans groter dat ze serieel worden vernieuwd.So, as the number of page visuals increases, there is higher chance that they will be refreshed in a serial manner. Hierdoor duurt het langer om de gehele pagina te vernieuwen. Bovendien is de kans zo groter dat visuals mogelijke inconsistente resultaten weergeven (voor vluchtige gegevensbronnen).It increases the time taken to refresh the entire page, and it also increases the chance that visuals may display inconsistent results (for volatile data sources). Daarom is het raadzaam om het aantal visualisaties op een pagina te beperken en in plaats daarvan meerdere eenvoudigere pagina's te gebruiken.For these reasons, it's recommended to limit the number of visuals on any page, and instead have more simpler pages. Wanneer u meerdere kaartvisuals met één kaart vervangt door een visual met meerdere rijen, krijgt u een vergelijkbare paginaopmaak.Replacing multiple card visuals with a single multi-row card visual can achieve a similar page layout.

  • Schakel interactie tussen visuals uit: Voor interacties zoals kruislings markeren en kruislings filteren moeten query's worden ingediend bij de onderliggende bron.Switch off interaction between visuals: Cross-highlighting and cross-filtering interactions require queries be submitted to the underlying source. Als deze interacties niet noodzakelijk zijn, wordt het aanbevolen deze uit te schakelen als het onredelijk lang duurt voordat er op selecties door gebruikers wordt gereageerd.Unless these interactions are necessary, it's recommended they be switched off if the time taken to respond to users' selections would be unreasonably long. Deze interacties kunnen worden uitgeschakeld voor het volledige rapport (zoals hierboven beschreven voor de opties voor Query's beperken), of per geval.These interactions can be switched off, either for the entire report (as described above for Query Reduction options), or on a case-by-case basis. Zie Hoe visuele elementen elkaar kruislings filteren in een Power BI-rapport voor meer informatie.For more information, see How visuals cross-filter each other in a Power BI report.

Naast de bovenstaande lijst met optimalisatietechnieken, kunnen de volgende rapportagemogelijkheden bijdragen aan prestatieproblemen:In addition to the above list of optimization techniques, each of the following reporting capabilities can contribute to performance issues:

  • Maateenheidsfilters: Op visuals met metingen (of totalen van kolommen) kunnen filters op die metingen zijn toegepast.Measure filters: Visuals containing measures (or aggregates of columns) can have filters applied to those measures. In de onderstaande visual ziet u bijvoorbeeld Verkoop op Categorie, maar alleen voor categorieën met een verkoop hoger dan USD 15 miljoen.For example, the visual below shows Sales by Category, but only for categories with more than $15 million of sales.

    Schermopname van Power BI Desktop met tabelgegevens met toegepaste filters.

    Hiervoor worden mogelijk twee query's naar de onderliggende gegevensbron verzonden:It may result in two queries being sent to the underlying source:

    • De eerste query haalt de categorieën op die voldoen aan de voorwaarde (Omzet > USD 15 miljoen)The first query will retrieve the categories meeting the condition (Sales > $15 million)
    • Met de tweede query worden vervolgens de benodigde gegevens voor de visual opgehaald, waarbij de categorieën worden toegevoegd die voldoen aan de voorwaarde in de WHERE-componentThe second query will then retrieve the necessary data for the visual, adding the categories that met the condition to the WHERE clause

    Dit werkt meestal prima als er honderden of duizenden categorieën zijn, zoals in dit voorbeeld.It generally performs fine if there are hundreds or thousands of categories, as in this example. De prestaties kunnen echter afnemen als het aantal categorieën veel groter is. Het is zelfs zo dat de query mislukt als er meer dan een miljoen categorieën zijn die voldoen aan de voorwaarde, vanwege de rijlimiet van één miljoen die we eerder hebben besproken.Performance can degrade, however, if the number of categories is much larger (and indeed, the query will fail if there are more than 1 million categories meeting the condition, due to the 1 million-row limit discussed above).

  • TopN-filters: Er kunnen geavanceerde filters worden gedefinieerd om alleen op de hoogste (of laagste) N-waarden te filteren, geclassificeerd door een meetwaarde.TopN filters: Advanced filters can be defined to filter on only the top (or bottom) N values ranked by a measure. Als u bijvoorbeeld alleen de top vijf categorieën in de bovenstaande visual wilt weergeven.For example, to display only the top five categories in the above visual. Net zoals de filters voor de meetwaarden zullen ook hierdoor twee query's worden verzonden naar de onderliggende gegevensbron.Like the measure filters, it will also result in two queries being sent to the underlying data source. De eerste query retourneert echter alle categorieën uit de onderliggende gegevensbron, waarna vervolgens de top N wordt bepaald op basis van de geretourneerde resultaten.However, the first query will return all categories from the underlying source, and then the top N are determined based on the returned results. Afhankelijk van de kardinaliteit van de betrokken kolom kan dit prestatieproblemen veroorzaken (of mislukte query's door de limiet van één miljoen rijen).Depending on the cardinality of the column involved, it can lead to performance issues (or query failures due to the 1 million-row limit).

  • Mediaan: Over het algemeen wordt elke aggregatie (Sum, Count Distinct, enzovoort) naar de onderliggende gegevensbron gepusht.Median: Generally, any aggregation (Sum, Count Distinct, etc.) is pushed to the underlying source. Dit geldt echter niet voor Median, omdat deze statistische functie niet wordt ondersteund door de onderliggende gegevensbron.However, it's not true for Median, as this aggregate is not supported by the underlying source. In dergelijke gevallen worden detailgegevens opgehaald uit de onderliggende gegevensbron en wordt de mediaan door Power BI geëvalueerd aan de hand van de geretourneerde resultaten.In such cases, detail data is retrieved from the underlying source, and Power BI evaluates the median from the returned results. Dit is geen probleem wanneer de mediaan moet worden berekend voor een relatief klein aantal resultaten, maar er treden prestatieproblemen op (of de query mislukt door de limiet van één miljoen rijen) als de kardinaliteit groot is.It's fine when the median is to be calculated over a relatively small number of results, but performance issues (or query failures due to the 1 million-row limit) will occur if the cardinality is large. Zo kan het berekenen van de mediaan van het inwonertal van landen redelijk snel gaan, maar het berekenen van de mediaan van de verkoopprijs te lang duren.For example, median country population might be reasonable, but median sales price might not be.

  • Slicers voor meervoudige selectie: Het toestaan van meervoudige selectie in slicers en filters kan prestatieproblemen veroorzaken.Multi-select slicers: Allowing multi-selection in slicers and filters can cause performance issues. De reden hiervoor is dat door elke nieuwe selectie een nieuwe query wordt verzonden naar de onderliggende bron als de gebruiker extra sliceritems selecteert (bijvoorbeeld om tot aan tien producten te komen waarin ze zijn geïnteresseerd).It's because as the user selects additional slicer items (for example, building up to the 10 products they are interested in), each new selection results in a new query being sent to the underlying source. Hoewel de gebruiker het volgende item kan selecteren terwijl de query nog niet is voltooid, leidt dit tot extra belasting van de onderliggende bron.Whilst the user can select the next item prior to the query completing, it results in extra load on the underlying source. U kunt deze situatie vermijden door de knop Toepassen weer te geven, zoals hierboven beschreven bij de queryreductietechnieken.This situation can be avoided by showing the Apply button, as described above in the query reduction techniques.

  • Totaal aantal visuals: Standaard geven tabellen en matrices totalen en subtotalen weer.Visual totals: By default, tables and matrices display totals and subtotals. In veel gevallen moeten er extra query's worden verzonden naar de onderliggende bron om de waarden voor de totalen op te halen.In many cases, additional queries must be sent to the underlying source to obtain the values for the totals. Dit is steeds van toepassing wanneer u Afzonderlijke telling van statische mediaanwaarden gebruikt, en in alle gevallen wanneer u DirectQuery via SAP HANA of SAP Business Warehouse gebruikt.It applies whenever using Count Distinct or Median aggregates, and in all cases when using DirectQuery over SAP HANA or SAP Business Warehouse. Dergelijke totalen moeten worden uitgeschakeld (met het deelvenster Indeling) als ze niet noodzakelijk zijn.Such totals should be switched off (by using the Format pane) if not necessary.

Omzetten naar een samengesteld modelConvert to a Composite Model

De voordelen van Import- en DirectQuery-modellen kunnen worden gecombineerd in één model door de opslagmodus van de modeltabellen te configureren.The benefits of Import and DirectQuery models can be combined into a single model by configuring the storage mode of the model tables. De tabelopslagmodus kan Import of DirectQuery of beide zijn. Dit wordt ook wel Tweezijdig genoemd.The table storage mode can be Import or DirectQuery, or both, known as Dual. Wanneer een model tabellen met verschillende opslagmodi bevat, wordt dit ook wel een Samengesteld model genoemd.When a model contains tables with different storage modes, it is known as a Composite model. Zie Samengestelde modellen in Power BI Desktop gebruiken voor meer informatie.For more information, see Use composite models in Power BI Desktop.

Er zijn vele functionele en prestatiegerichte verbeteringen die kunnen worden bereikt door een DirectQuery-model om te zetten naar een samengesteld model.There are many functional and performance enhancements that can be achieved by converting a DirectQuery model to a Composite model. Een samengesteld model kan meer dan één DirectQuery-bron integreren, en het model kan ook aggregaties bevatten.A Composite model can integrate more than one DirectQuery source, and it can also include aggregations. Aggregatietabellen kunnen worden toegevoegd aan DirectQuery-tabellen om een samengevat overzicht van de tabel te importeren.Aggregation tables can be added to DirectQuery tables to import a summarized representation of the table. Hiermee kunt u uw prestaties aanzienlijk verbeteren wanneer visuals een query uitvoeren op aggregaties van een hoger niveau.They can achieve dramatic performance enhancements when visuals query higher-level aggregates. Zie Aggregaties in Power BI Desktop voor meer informatie.For more information, see Aggregations in Power BI Desktop.

Gebruikers informerenEducate users

Het is belangrijk om uw gebruikers erop te wijzen hoe ze efficiënt met rapporten kunnen werken op basis van DirectQuery-gegevenssets.It is important to educate your users on how to efficiently work with reports based on DirectQuery datasets. Uw rapportauteurs moeten worden gewezen op de inhoud die wordt beschreven in de sectie Rapportontwerpen optimaliseren.Your report authors should be educated on the content described in the Optimize report designs section.

Het wordt aanbevolen uw rapportgebruikers te informeren over uw rapporten die op DirectQuery-gegevenssets zijn gebaseerd.We recommend that you educate your report consumers about your reports that are based on DirectQuery datasets. Het kan voor hun handig zijn om de algemene gegevensarchitectuur te kennen, inclusief eventuele relevante beperkingen dit in dit artikel worden beschreven.It can be helpful for them to understand the general data architecture, including any relevant limitations described in this article. Laat ze weten dat ze kunnen verwachten dat vernieuwingssnelheden en interactieve filtering soms wat traag kunnen worden.Let them know to expect that refresh responses and interactive filtering may at times be slow. Wanneer rapportgebruikers begrijpen waarom verslechtering van gegevens optreedt, is de kans kleiner dat ze hun vertrouwen in de rapporten en gegevens verliezen.When report users understand why performance degradation happens, they are less likely to lose trust in the reports and data.

Wanneer u rapporten levert op vluchtige gegevensbronnen, moet u rapportgebruikers informeren over het gebruik van de knop Vernieuwen.When delivering reports on volatile data sources, be sure to educate report users on the use of the Refresh button. Laat ze ook weten dat ze mogelijk inconsistente resultaten zien en dat eventuele inconsistenties op de rapportpagina kunnen worden opgelost door het rapport te vernieuwen.Let them know also that it may be possible to see inconsistent results, and that a refresh of the report can resolve any inconsistencies on the report page.

Volgende stappenNext steps

Bekijk de volgende bronnen voor meer informatie over DirectQuery:For more information about DirectQuery, check out the following resources: