Columnstore-indexen - Ontwerprichtlijnen

van toepassing op:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)SQL-database in Microsoft Fabric

Aanbevelingen op hoog niveau voor het ontwerpen van columnstore-indexen. Een aantal goede ontwerpbeslissingen helpen u bij het bereiken van de hoge gegevenscompressie en queryprestaties die columnstore-indexen zijn ontworpen om te bieden.

Voorwaarden

In dit artikel wordt ervan uitgegaan dat u bekend bent met columnstore-architectuur en terminologie. Zie Columnstore-indexen: Overzicht en Columnstore Index Architecturevoor meer informatie.

Uw gegevensvereisten kennen

Voordat u een columnstore-index ontwerpt, moet u zoveel mogelijk inzicht hebben in uw gegevensvereisten. Denk bijvoorbeeld na over de antwoorden op deze vragen:

• Hoe groot is mijn tafel?
• Voeren mijn query's voornamelijk analyses uit die grote reeksen waarden scannen? Columnstore-indexen zijn ontworpen voor goede werking bij het scannen van grote hoeveelheden gegevens in plaats van het opzoeken van specifieke waarden.
• Voert mijn workload veel updates en verwijderingen uit? Columnstore-indexen werken goed wanneer de gegevens stabiel zijn. Queries moeten minder dan 10% rijen bijwerken en verwijderen.
• Heb ik feiten- en dimensietabellen voor een datawarehouse?
• Moet ik analyses uitvoeren op een transactionele workload? Als dat het geval is, zie de columnstore-ontwerprichtlijnen voor realtime operationele analyses.

Mogelijk hebt u geen columnstore-index nodig. Rowstore-tabellen (of B-tree) met heaps of geclusterde indexen presteren het beste bij query's die een specifieke waarde zoeken of voor query's binnen een klein bereik van waarden. Gebruik rowstore-indexen bij transactionele werkbelastingen, omdat ze meestal tabel-opzoekopdrachten vereisen in plaats van grote range scans van tabellen.

Kies de beste columnstore-index voor uw behoeften

Een columnstore-index is geclusterd of niet geclusterd. Een geclusterde columnstore-index kan een of meer niet-geclusterde B-tree-indexen hebben. Columnstore-indexen zijn eenvoudig te proberen. Als u een tabel als columnstore-index maakt, kunt u de tabel eenvoudig terugzetten naar een rowstore-tabel door de columnstore-index te verwijderen.

Hier volgt een overzicht van de opties en aanbevelingen.

Columnstore-optie	Aanbevelingen voor wanneer het te gebruiken	Compressie
Geclusterde Columnstore Index	Gebruiken voor: 1) Traditionele datawarehouse-workload met een ster- of sneeuwvlokschema 2) IoT-workloads (Internet of Things) die grote hoeveelheden gegevens invoegen met minimale updates en verwijderingen.	Gemiddeld 10x
geordende geclusterde columnstore-index	Gebruik deze methode wanneer een geclusterde columnstore-index wordt opgevraagd via één geordende predicaatkolom of -kolomset. Deze richtlijnen zijn vergelijkbaar met het kiezen van de sleutelkolom(s) voor een geclusterde rijopslagindex, hoewel de gecomprimeerde onderliggende rijgroepen zich anders gedragen. Voor meer informatie, zie CREATE COLUMNSTORE INDEX en Performance tuning met geordende columnstore-indexen.	Gemiddeld 10x
Niet-geclusterde B-tree-indexen in een geclusterde columnstore-index	Gebruik dit om: Handhaaf beperkingen voor primaire sleutels en vreemde sleutels op een geclusterde columnstore-index. 2. Query's versnellen die zoeken naar specifieke waarden of kleine bereiken met waarden. 3. Updates versnellen en verwijderen van specifieke rijen.	Gemiddeld tien keer plus wat extra opslagruimte voor de NCI's.
niet-geclusterde columnstore-index op een schijfgebaseerde heap- of B-tree-index	Gebruiken voor: 1) Een OLTP-workload met enkele analysequery's. U kunt B-tree-indexen verwijderen die zijn gemaakt voor analyse en deze vervangen door één niet-geclusterde columnstore-index. 2) Veel traditionele OLTP-workloads die ETL-bewerkingen (Extract Transform and Load) uitvoeren om gegevens naar een afzonderlijk datawarehouse te verplaatsen. U kunt ETL en een afzonderlijk datawarehouse elimineren door een niet-geclusterde columnstore-index te maken op sommige OLTP-tabellen.	NCCI is een extra index waarvoor gemiddeld 10% meer opslagruimte is vereist.
Columnstore-index in een tabel in het geheugen	Dezelfde aanbevelingen als een niet-geclusterde columnstore-index op een schijfgebaseerde tabel, behalve dat de basistabel een in-memory tabel is.	Columnstore-index is een extra index.

Een geclusterde columnstore-index gebruiken voor grote datawarehouse-tabellen

De geclusterde columnstore-index is meer dan een index, het is de primaire tabelopslag. Het bereikt een hoge datacompressie en een aanzienlijke verbetering van de queryprestaties met betrekking tot grote dimensie- en feitentabellen voor datawarehousing. Geclusterde columnstore-indexen zijn het meest geschikt voor analysequery's in plaats van transactionele query's, omdat analysequery's meestal bewerkingen uitvoeren op grote bereiken van waarden in plaats van specifieke waarden op te zoeken.

Overweeg het gebruik van een geclusterde columnstore-index wanneer:

• Elke partitie heeft ten minste een miljoen rijen. Columnstore-indexen hebben rijengroepen binnen elke partitie. Als de tabel te klein is om een rijgroep binnen elke partitie te vullen, krijgt u niet de voordelen van columnstore-compressie en queryprestaties.
• Queries voeren voornamelijk analyses uit op waardereeksen. Als u bijvoorbeeld de gemiddelde waarde van een kolom wilt vinden, moet de query alle kolomwaarden scannen. Vervolgens worden de waarden samengevoegd door ze op te tellen om het gemiddelde te bepalen.
• De meeste invoegingen bevinden zich op grote hoeveelheden gegevens met minimale updates en verwijderingen. Veel workloads zoals Internet of Things (IOT) voegen grote hoeveelheden gegevens in met minimale updates en verwijderingen. Deze workloads kunnen profiteren van de compressie- en queryprestaties die afkomstig zijn van het gebruik van een geclusterde columnstore-index.

Gebruik geen geclusterde columnstore-index wanneer:

• De tabel vereist varchar(max), nvarchar(max)of varbinary(max) gegevenstypen. Of ontwerp de columnstore-index zodat deze geen kolommen bevat (van toepassing op: SQL Server 2016 (13.x) en vorige versies.
• De tabelgegevens zijn niet permanent. Overweeg om een heap of tijdelijke tabel te gebruiken wanneer u de gegevens snel wilt opslaan en verwijderen.
• De tabel bevat minder dan één miljoen rijen per partitie.
• Meer dan 10% van de bewerkingen in de tabel zijn updates en verwijderingen. Grote aantallen updates en verwijderingen veroorzaken fragmentatie. De fragmentatie beïnvloedt de compressiegraad en de prestaties van query's totdat u een bewerking start genaamd reorganiseren, die alle gegevens in de columnstore forceert en fragmentatie verwijdert. Zie Indexfragmentatie minimaliseren in columnstore-indexvoor meer informatie.

Zie Columnstore-indexen in datawarehousingvoor meer informatie.

Een geordende geclusterde columnstore-index gebruiken voor grote datawarehouse-tabellen

Zie voor de beschikbaarheid van geordende columnstore-indexen: Columnstore-indexen Overzicht.

Overweeg het gebruik van een geordende geclusterde columnstore-index in de volgende scenario's:

• Wanneer gegevens relatief statisch zijn (zonder vaak te schrijven en te verwijderen) en de geordende geclusterde columnstore-indexsleutel statisch is, kunnen geordende geclusterde columnstore-indexen aanzienlijke prestatievoordelen bieden ten opzichte van niet-geordende geclusterde columnstore-indexen of geclusterde rowstore-indexen voor analytische workloads.
• Hoe meer afzonderlijke waarden in de eerste kolom van de geordende columnstore-indexsleutel, hoe beter de prestatieverbeteringen kunnen zijn voor geordende geclusterde columnstore-indexen. Dit komt door verbeterde segmentuitschakeling voor tekenreeksgegevens. Zie segmentuitschakelingvoor meer informatie.
• Kies een geordende geclusterde columnstore-indexsleutel die regelmatig wordt opgevraagd en die kan profiteren van segmentverwijdering, met name de eerste kolom van de sleutel. Prestatieverbeteringen als gevolg van segmentuitschakeling op andere kolommen in de tabel zijn minder voorspelbaar.
• Gebruiksvoorbeelden waarbij alleen de meest recente analytische gegevens moeten worden opgevraagd, bijvoorbeeld de laatste 15 seconden, geordende geclusterde columnstore-indexen kunnen segmentverwijdering bieden voor oudere gegevens. De eerste kolom in de sleutel van de geordende geclusterde columnstoregegevens moet de datum-/tijdgegevens zijn, zoals een ingevoegde of gemaakte datum/tijd. De segmentuitschakeling zou effectiever zijn in een geordende geclusterde columnstore-index dan in een ongeordend geclusterde columnstore-index.
• Overweeg geordende geclusterde columnstore-indexen op tabellen met sleutels met GUID-gegevens, waarbij het gegevenstype uniqueidentifier nu kan worden gebruikt voor segmentuitschakeling.

Een geordende geclusterde columnstore-index is mogelijk niet zo effectief in deze scenario's:

• Net als bij andere columnstore-indexen kan een hoge snelheid van invoegactiviteit overmatige opslag-I/O creëren.
• Voor workloads waarbij er veel schrijfbewerkingen zijn, wordt de kwaliteit van segmentverwijdering in de loop van de tijd verminderd vanwege onderhoud van de rijgroep door de tuple-mover. Dit kan worden verzacht door regelmatig onderhoud van de columnstore-index met ALTER INDEX REORGANIZE.

B-tree niet-geclusterde indexen toevoegen voor efficiënte tabelzoekopdrachten

Vanaf SQL Server 2016 (13.x) kunt u niet-geclusterde B-tree- of rowstore-indexen maken als secundaire indexen op een geclusterde columnstore-index. De niet-geclusterde B-structuurindex wordt bijgewerkt wanneer er wijzigingen optreden in de columnstore-index. Dit is een krachtige functie die u in uw voordeel kunt gebruiken.

Door de secundaire B-structuurindex te gebruiken, kunt u efficiënt zoeken naar specifieke rijen zonder alle rijen te scannen. Er zijn ook andere opties beschikbaar. U kunt bijvoorbeeld een beperking voor een primaire of buitenlandse sleutel afdwingen met behulp van een unieke constraint op de B-tree-index. Omdat een niet-unieke waarde niet kan worden ingevoegd in de B-tree-index, kan SQL Server de waarde niet invoegen in de columnstore.

Overweeg het gebruik van een B-tree-index op een columnstore-index om:

• Voer zoekopdrachten uit die zoeken naar bepaalde waarden of kleine bereiken van waarden.
• Een beperking afdwingen, zoals een primaire sleutel of een vreemde-sleutelbeperking.
• Efficiënt update- en verwijderbewerkingen uitvoeren. De B-tree-index kan snel de specifieke rijen voor updates en verwijderingen vinden zonder de volledige tabel of partitie van een tabel te scannen.
• U hebt extra opslagruimte beschikbaar voor het opslaan van de B-tree-index.

Een niet-geclusterde columnstore-index gebruiken voor realtime analyses

Vanaf SQL Server 2016 (13.x) kunt u een niet-geclusterde columnstore-index hebben op een tabel op basis van een rowstore-schijf of een OLTP-tabel in het geheugen. Hierdoor kunt u de analyse in realtime uitvoeren op een transactionele tabel. Terwijl er transacties plaatsvinden in de onderliggende tabel, kunt u analyses uitvoeren op de columnstore-index. Aangezien één tabel beide indexen beheert, zijn wijzigingen in realtime beschikbaar voor zowel de rowstore als de columnstore-indexen.

Omdat een columnstore-index 10x betere gegevenscompressie bereikt dan een rowstore-index, heeft deze slechts een kleine hoeveelheid extra opslagruimte nodig. Als de gecomprimeerde rowstore-tabel bijvoorbeeld 20 GB kost, is voor de columnstore-index mogelijk extra 2 GB vereist. De vereiste extra ruimte is ook afhankelijk van het aantal kolommen in de niet-geclusterde columnstore-index.

Overweeg om een niet-geclusterde columnstore-index te gebruiken voor:

• Voer analyses in realtime uit op een transactionele rowstore-tabel. U kunt bestaande B-tree-indexen vervangen die zijn ontworpen voor analyse door een niet-geclusterde columnstore-index.

• Elimineer de noodzaak van een afzonderlijk datawarehouse. Traditioneel voeren bedrijven transacties uit op een rijtabel en laden vervolgens de gegevens in een afzonderlijk datawarehouse om analytica te verrichten. Voor veel workloads kunt u het laadproces en het afzonderlijke datawarehouse elimineren door een niet-geclusterde columnstore-index te maken voor transactionele tabellen.

SQL Server 2016 (13.x) biedt verschillende strategieën om dit scenario goed te laten presteren. Het is heel eenvoudig om het te proberen omdat u een niet-geclusterde columnstore-index kunt inschakelen zonder wijzigingen in uw OLTP-toepassing.

Als u aanvullende verwerkingsresources wilt toevoegen, kunt u de analyse uitvoeren op een leesbare secundaire. Met behulp van een leesbare secundaire wordt de verwerking van de transactionele workload en de analyseworkload gescheiden.

Voor meer informatie, zie Aan de slag met Columnstore voor realtime operationele analyses

Zie de blog van Sunil Agarwal Welke columnstore-index is geschikt voor mijn workload voor meer informatie over het kiezen van de beste columnstore-index?.

Tabelpartities gebruiken voor gegevensbeheer en queryprestaties

Columnstore-indexen ondersteunen partitionering. Dit is een goede manier om gegevens te beheren en te archiveren. Partitionering verbetert ook de queryprestaties door bewerkingen te beperken tot een of meer partities.

Partities gebruiken om de gegevens gemakkelijker te beheren

Voor grote tabellen is de enige praktische manier om gegevensbereiken te beheren het gebruik van partities. De voordelen van partities voor rowstore-tabellen zijn ook van toepassing op columnstore-indexen.

Voor tabellen rowstore en columnstore worden bijvoorbeeld partities gebruikt om:

• De grootte van incrementele back-ups beheren. U kunt een back-up maken van partities om bestandsgroepen te scheiden en deze vervolgens als alleen-lezen markeren. Hierdoor slaan toekomstige back-ups de alleen-lezen bestandsgroepen over.
• Bespaar opslagkosten door een oudere partitie naar goedkopere opslag te verplaatsen. U kunt bijvoorbeeld partitiewisselingen gebruiken om een partitie naar een goedkopere opslaglocatie te verplaatsen.
• Voer bewerkingen efficiënt uit door de bewerkingen te beperken tot een partitie. U kunt zich bijvoorbeeld alleen richten op de gefragmenteerde partities voor indexonderhoud.

Daarnaast gebruikt u partitionering met een columnstore-index om het volgende te doen:

• Bespaar nog eens 30% op de opslagkosten. U kunt oudere partities comprimeren met de COLUMNSTORE_ARCHIVE compressieopties. De gegevens zijn trager voor queryprestaties, wat acceptabel is als de partitie niet vaak wordt opgevraagd.

Partities gebruiken om de queryprestaties te verbeteren

Met behulp van partities kunt u uw query's beperken tot het scannen van alleen specifieke partities, waardoor het aantal rijen dat moet worden gescand, wordt beperkt. Als de index bijvoorbeeld per jaar wordt gepartitioneerd en de query gegevens van vorig jaar analyseert, hoeft deze alleen de gegevens in één partitie te scannen.

Minder partities gebruiken voor een columnstore-index

Tenzij u een grote gegevensgrootte hebt, presteert een columnstore-index het beste met minder partities dan wat u kunt gebruiken voor een rowstore-index. Als u niet ten minste één miljoen rijen per partitie hebt, gaan de meeste rijen mogelijk naar de deltastore, waar ze niet profiteren van het prestatievoordeel van columnstore-compressie. Als u bijvoorbeeld één miljoen rijen in een tabel laadt met 10 partities en elke partitie 100.000 rijen ontvangt, gaan alle rijen naar deltarijgroepen.

Voorbeeld:

• Laad 1000.000 rijen in één partitie of een niet-gepartitioneerde tabel. U krijgt één gecomprimeerde rijgroep met 1.000.000 rijen. Dit is ideaal voor hoge gegevenscompressie en snelle queryprestaties.
• Laad 1.000.000 rijen gelijkmatig in 10 partities. Elke partitie krijgt 100.000 rijen, wat minder is dan de minimumdrempel voor columnstore-compressie. Als gevolg hiervan kan de columnstore-index 10 deltarijgroepen met elk 100.000 rijen bevatten. Er zijn manieren om de deltarijgroepen in de columnstore te plaatsen. Als dit echter de enige rijen in de columnstore-index zijn, zijn de gecomprimeerde rijgroepen te klein voor de beste compressie- en queryprestaties.

Voor meer informatie over partitioneren, zie het blogbericht van Sunil Agarwal, Moet ik mijn columnstore-index partitioneren?.

De juiste methode voor gegevenscompressie kiezen

De columnstore-index biedt twee opties voor gegevenscompressie: columnstore-compressie en archiefcompressie. U kunt de compressieoptie kiezen wanneer u de index maakt of later wijzigen met ALTER INDEX ... Bouwopnieuw op.

Columnstore-compressie gebruiken voor de beste queryprestaties

Columnstore-compressie bereikt doorgaans 10x betere compressiesnelheden ten opzichte van rowstore-indexen. Het is de standaardcompressiemethode voor columnstore-indexen en maakt snelle queryprestaties mogelijk.

Archiefcompressie gebruiken voor de beste gegevenscompressie

Archiefcompressie is ontworpen voor maximale compressie wanneer queryprestaties niet zo belangrijk zijn. Het bereikt hogere gegevenscompressiesnelheden dan columnstore-compressie, maar het wordt geleverd met een prijs. Het duurt langer om de gegevens te comprimeren en decomprimeren, dus het is niet geschikt voor snelle queryprestaties.

Optimalisaties gebruiken wanneer u een rowstore-tabel converteert naar een columnstore-index

Als uw gegevens zich al in een rowstore-tabel bevinden, kunt u CREATE COLUMNSTORE INDEX gebruiken om de tabel te converteren naar een geclusterde columnstore-index. Er zijn enkele optimalisaties die de queryprestaties verbeteren nadat de tabel is geconverteerd, zoals hierna wordt beschreven.

MAXDOP gebruiken om de kwaliteit van de rijgroep te verbeteren

U kunt het maximum aantal processors configureren voor het converteren van een heap- of geclusterde B-boomstructuurindex naar een columnstore-index. Als u de processors wilt configureren, gebruikt u de maximale mate van parallelle uitvoering (MAXDOP).

Als u grote hoeveelheden gegevens hebt, is MAXDOP-1 waarschijnlijk te traag. Het verhogen van MAXDOP naar 4 werkt prima. Als dit resulteert in een paar rijengroepen die niet het optimale aantal rijen hebben, kunt u ALTER INDEX REORGANIZE uitvoeren om ze samen te voegen op de achtergrond.

De gesorteerde volgorde van een B-boomstructuurindex behouden

Omdat de B-tree-index al rijen in een gesorteerde volgorde opslaat, kan het behoud van die volgorde wanneer de rijen worden gecomprimeerd in de columnstore-index de queryprestaties verbeteren.

De columnstore-index sorteert de gegevens niet, maar gebruikt wel metagegevens om de minimum- en maximumwaarden van elk kolomsegment in elke rijgroep bij te houden. Bij het scannen op een bereik van waarden kan het snel berekenen wanneer de rijgroep moet worden overgeslagen. Wanneer de gegevens zijn geordend, kunnen er meer rijengroepen worden overgeslagen.

De gesorteerde volgorde behouden tijdens de conversie:

• Gebruik CREATE COLUMNSTORE INDEX met de DROP_EXISTING clausule. Hiermee blijft ook de naam van de index behouden. Als u scripts hebt die al de naam van de rowstore-index gebruiken, hoeft u ze niet bij te werken.

  In dit voorbeeld wordt een geclusterde rijstore-index op een tabel met de naam MyFactTable geconverteerd naar een geclusterde columnstore-index. De indexnaam, ClusteredIndex_d473567f7ea04d7aafcac5364c241e09, blijft hetzelfde.

  CREATE CLUSTERED COLUMNSTORE INDEX ClusteredIndex_d473567f7ea04d7aafcac5364c241e09
  ON MyFactTable
  WITH (DROP_EXISTING = ON);
  

Inzicht in segmentuitschakeling

Elke rijgroep bevat één kolomsegment voor elke kolom in de tabel. Elk kolomsegment wordt samen gecomprimeerd en opgeslagen op fysieke media.

Er zijn metagegevens voor elk segment, zodat segmenten snel kunnen worden verwijderd zonder ze te lezen. Gegevenstypekeuzen kunnen een aanzienlijke invloed hebben op queryprestaties op basis van algemene filterpredicaten voor query's in de columnstore-index. Zie segmentuitschakelingvoor meer informatie.

Gerelateerde taken

Dit zijn taken voor het maken en onderhouden van columnstore-indexen.

Taak	Naslagartikelen	Notities
Maak een tabel als een columnstore.	CREATE TABLE (Transact-SQL)	Vanaf SQL Server 2016 (13.x) kunt u de tabel maken als een geclusterde columnstore-index. U hoeft niet eerst een rowstore-tabel te maken en deze vervolgens te converteren naar columnstore.
Maak een geheugentabel met een columnstore-index.	CREATE TABLE (Transact-SQL)	Vanaf SQL Server 2016 (13.x) kunt u een tabel maken die is geoptimaliseerd voor geheugen met een columnstore-index. De columnstore-index kan ook worden toegevoegd nadat de tabel is gemaakt, met behulp van de syntaxis ALTER TABLE ADD INDEX.
Converteer een rowstore-tabel naar een columnstore.	COLUMNSTORE-INDEX aanmaken (Transact-SQL)	Converteer een bestaande heap of B-tree naar een columnstore. Voorbeelden laten zien hoe bestaande indexen worden verwerkt en ook de naam van de index bij het uitvoeren van deze conversie.
Converteer een columnstore-tabel naar een rowstore.	CREATE CLUSTERED INDEX (Transact-SQL) of Converteer een columnstore-tabel terug naar een rowstore heap	Meestal is deze conversie niet nodig, maar er kunnen momenten zijn waarop u moet converteren. Voorbeelden laten zien hoe u een columnstore converteert naar een heap- of geclusterde index.
Een columnstore-index maken in een rowstore-tabel.	COLUMNSTORE-INDEX (Transact-SQL) maken	Een rowstore-tabel kan één columnstore-index hebben. Vanaf SQL Server 2016 (13.x) kan de columnstore-index een gefilterde voorwaarde hebben. Voorbeelden geven de basissyntaxis weer.
Maak performante indexen voor operationele analyses.	Aan de slag met Columnstore voor realtime operationele analyses	Hierin wordt beschreven hoe u aanvullende columnstore- en B-tree-indexen maakt, zodat OLTP-query's B-tree-indexen en analysequery's columnstore-indexen gebruiken.
Maak performante columnstore-indexen voor datawarehousing.	Columnstore-indexen in datawarehousing	Hierin wordt beschreven hoe u B-tree-indexen gebruikt voor columnstore-tabellen om performante query's voor datawarehousing te maken.
Gebruik een B-tree-index om een primaire-sleutelbeperking af te dwingen voor een columnstore-index.	Columnstore-indexen in datawarehouses	Laat zien hoe u B-tree- en columnstore-indexen combineert om primaire-sleutelbeperkingen voor de columnstore-index af te dwingen.
Een columnstore-index verwijderen	DROP INDEX (Transact-SQL)	Als u een columnstore-index verwijdert, wordt de standaard DROP INDEX-syntaxis gebruikt die B-tree-indexen gebruiken. Als u een geclusterde columnstore-index verwijdert, wordt de columnstore-tabel omgezet in een heap.
Een rij verwijderen uit een columnstore-index	DELETE (Transact-SQL)	Gebruik DELETE (Transact-SQL) om een rij te verwijderen. columnstore rij: SQL Server markeert de rij als logisch verwijderd, maar maakt de fysieke opslag voor de rij pas vrij nadat de index opnieuw is opgebouwd. deltastore rij: SQL Server verwijdert de rij logisch en fysiek.
Een rij in de columnstore-index bijwerken	UPDATE (Transact-SQL)	Gebruik UPDATE (Transact-SQL) om een rij bij te werken. columnstore rij: SQL Server markeert de rij als logisch verwijderd en voegt vervolgens de bijgewerkte rij in de deltastore in. deltastore rij: SQL Server werkt de rij in de deltastore bij.
Dwing alle rijen in de deltastore om naar de columnstore over te gaan.	ALTER INDEX (Transact-SQL) ... REBUILDEN Indexonderhoud optimaliseren om de queryprestaties te verbeteren en het resourceverbruik te verminderen	ALTER INDEX met de optie REBUILD dwingt alle rijen om in de columnstore terecht te komen.
Een columnstore-index defragmenteren	ALTER INDEX (Transact-SQL)	ALTER INDEX ... REORGANIZE defragmenteert columnstore-indexen online.
Tabellen met columnstore-indexen samenvoegen.	SAMENVOEGEN (Transact-SQL)

Verwante inhoud

Een lege columnstore-index maken voor:

• Voor SQL Server of SQL Database, zie CREATE TABLE (Transact-SQL).
• Zie Azure Synapse Analytics, CREATE TABLE (Azure Synapse Analytics).

Raadpleeg CREATE COLUMNSTORE INDEX (Transact-SQL)voor meer informatie over het converteren van een bestaande heap- of B-tree-index naar een geclusterde columnstore-index, of om een niet-geclusterde columnstore-index te maken.

• Wat is er nieuw in columnstore-indexen
• Columnstore-indexen in datawarehousing
• Kolomgebaseerde indexen - Queryprestaties