Indextabel patroonIndex Table pattern

Indexen maken via de velden in de gegevensarchieven die vaak worden gebruikt door query's.Create indexes over the fields in data stores that are frequently referenced by queries. Dit patroon kan de queryprestaties verbeteren doordat toepassingen sneller vinden van de gegevens op te halen uit een gegevensopslag.This pattern can improve query performance by allowing applications to more quickly locate the data to retrieve from a data store.

Context en probleemContext and problem

Veel gegevensarchieven Organiseer de gegevens voor een verzameling entiteiten met behulp van de primaire sleutel.Many data stores organize the data for a collection of entities using the primary key. Een toepassing kan deze sleutel gebruiken om te zoeken en gegevens op te halen.An application can use this key to locate and retrieve data. De afbeelding toont een voorbeeld van een gegevensarchief klantgegevens houden.The figure shows an example of a data store holding customer information. De primaire sleutel is de klant-ID.The primary key is the Customer ID. De afbeelding toont klantgegevens onderverdeeld op basis van de primaire sleutel (klant-ID).The figure shows customer information organized by the primary key (Customer ID).

Afbeelding 1: informatie over de klant onderverdeeld op basis van de primaire sleutel (klant-ID)

Terwijl de primaire sleutel is van belang om query's die ophalen van gegevens die zijn gebaseerd op de waarde van deze sleutel, kunnen een toepassing mogelijk niet de primaire sleutel gebruiken als voor het ophalen van gegevens op basis van een ander veld.While the primary key is valuable for queries that fetch data based on the value of this key, an application might not be able to use the primary key if it needs to retrieve data based on some other field. Een toepassing kan niet de primaire sleutel van de klant-ID gebruiken voor het ophalen van klanten, als deze gegevens opvraagt uitsluitend door te verwijzen naar de waarde van een kenmerk, zoals de plaats waar de klant bevindt in het voorbeeld klanten.In the customers example, an application can't use the Customer ID primary key to retrieve customers if it queries data solely by referencing the value of some other attribute, such as the town in which the customer is located. De toepassing mogelijk om uit te voeren een query zoals deze, om te halen en het onderzoeken van elke klantrecord die een trage proces kan worden.To perform a query such as this, the application might have to fetch and examine every customer record, which could be a slow process.

Veel relationele databasesystemen ondersteunt secundaire indexen.Many relational database management systems support secondary indexes. Een secundaire index is een afzonderlijke gegevensstructuur die geordend op een of meer nonprimary (secundair) sleutelvelden en Hiermee wordt aangegeven waar de gegevens voor elke geïndexeerde waarde wordt opgeslagen.A secondary index is a separate data structure that's organized by one or more nonprimary (secondary) key fields, and it indicates where the data for each indexed value is stored. De items in een secundaire index worden doorgaans door de waarde van de secundaire sleutels inschakelen snel opzoeken van gegevens gesorteerd.The items in a secondary index are typically sorted by the value of the secondary keys to enable fast lookup of data. Deze indexen worden meestal automatisch beheerd door het databasebeheersysteem.These indexes are usually maintained automatically by the database management system.

U kunt zoveel secundaire indexen als nodig is voor de ondersteuning voor de verschillende query's die uw toepassing uitvoert.You can create as many secondary indexes as you need to support the different queries that your application performs. In een klantentabel in een relationele database waar de klant-ID de primaire sleutel is is het bijvoorbeeld handig zijn om een secundaire index via het ruimtelijke veld toevoegen als de toepassing die vaak Hiermee zoekt u klanten op de plaats waar ze zich bevinden.For example, in a Customers table in a relational database where the Customer ID is the primary key, it's beneficial to add a secondary index over the town field if the application frequently looks up customers by the town where they reside.

Hoewel secundaire indexen in relationele systemen, bieden niet de meeste NoSQL-gegevensopslag gebruikt door cloudtoepassingen echter een equivalente functie.However, although secondary indexes are common in relational systems, most NoSQL data stores used by cloud applications don't provide an equivalent feature.

OplossingSolution

Als het gegevensarchief geen secundaire indexen ondersteunt, kunt u ze handmatig geëmuleerd door uw eigen tabellen index maken.If the data store doesn't support secondary indexes, you can emulate them manually by creating your own index tables. De indextabel ordent de gegevens door een opgegeven sleutel.An index table organizes the data by a specified key. Drie strategieën wordt vaak gebruikt voor het structureren van een indextabel, afhankelijk van het aantal secundaire indexen die vereist zijn en de aard van de query's die een toepassing wordt uitgevoerd.Three strategies are commonly used for structuring an index table, depending on the number of secondary indexes that are required and the nature of the queries that an application performs.

De eerste strategie is het dupliceren van de gegevens in elke indextabel, maar deze rangschikken op verschillende sleutels (volledige denormalization).The first strategy is to duplicate the data in each index table but organize it by different keys (complete denormalization). De volgende afbeelding toont index tabellen die dezelfde klantgegevens door stad en LastName organiseren.The next figure shows index tables that organize the same customer information by Town and LastName.

Afbeelding 2 - gegevens is in elke indextabel gedupliceerd

Deze strategie is geschikt als de gegevens is relatief statische in vergelijking met het aantal keren dat deze wordt opgevraagd met behulp van elke sleutel.This strategy is appropriate if the data is relatively static compared to the number of times it's queried using each key. Als de gegevens meer dynamisch is, wordt de verwerkingsoverhead van het onderhouden van elke indextabel te groot voor deze benadering nuttig.If the data is more dynamic, the processing overhead of maintaining each index table becomes too large for this approach to be useful. Ook als de hoeveelheid gegevens erg groot is, is de hoeveelheid vereiste schijfruimte voor het opslaan van de dubbele gegevens van belang.Also, if the volume of data is very large, the amount of space required to store the duplicate data is significant.

De strategie voor de tweede is het maken van genormaliseerde index tabellen die zijn geordend door verschillende sleutels en verwijzing naar de oorspronkelijke gegevens op met behulp van de primaire sleutel in plaats van te dupliceren, zoals wordt weergegeven in de volgende afbeelding.The second strategy is to create normalized index tables organized by different keys and reference the original data by using the primary key rather than duplicating it, as shown in the following figure. De oorspronkelijke gegevens wordt een feitentabel genoemd.The original data is called a fact table.

Afbeelding 3 - gegevens wordt verwezen door elke indextabel

Deze techniek databaseruimte en vermindert de overhead van het onderhouden van de duplicaatgegevens.This technique saves space and reduces the overhead of maintaining duplicate data. Het nadeel is dat een toepassing heeft twee lookup bewerkingen opzoeken van gegevens met behulp van een secundaire sleutel uit te voeren.The disadvantage is that an application has to perform two lookup operations to find data using a secondary key. Het is te vinden van de primaire sleutel voor de gegevens in de indextabel en gebruik vervolgens de primaire sleutel om de gegevens in de feitentabel te zoeken.It has to find the primary key for the data in the index table, and then use the primary key to look up the data in the fact table.

De derde strategie is gedeeltelijk genormaliseerde index tabellen die zijn geordend op verschillende sleutels dat er dubbele vaak opgehaalde velden te maken.The third strategy is to create partially normalized index tables organized by different keys that duplicate frequently retrieved fields. Verwijzen naar de feitentabel aan velden van de toegang tot minder vaak worden gebruikt.Reference the fact table to access less frequently accessed fields. De volgende afbeelding ziet u hoe vaak gebruikte gegevens in elke indextabel is gedupliceerd.The next figure shows how commonly accessed data is duplicated in each index table.

Afbeelding 4 - vaak gegevens worden gedupliceerd in elke indextabel

Met deze strategie kunt u bieden een evenwicht tussen de eerste twee methoden.With this strategy, you can strike a balance between the first two approaches. De gegevens voor algemene query's kunnen snel worden opgehaald met behulp van een één-lookup, terwijl de overhead en het onderhoud is niet zo groot als de volledige gegevensset dupliceren.The data for common queries can be retrieved quickly by using a single lookup, while the space and maintenance overhead isn't as significant as duplicating the entire data set.

Als een toepassing vraagt regelmatig gegevens door te geven van een combinatie van waarden (bijvoorbeeld 'Alle klanten die live zoeken in Redmond en waarvoor de achternaam Smith'), kan u de sleutels voor de items in de indextabel implementeren als een samenvoeging van de stad kenmerk en het kenmerk LastName.If an application frequently queries data by specifying a combination of values (for example, “Find all customers that live in Redmond and that have a last name of Smith”), you could implement the keys to the items in the index table as a concatenation of the Town attribute and the LastName attribute. De volgende afbeelding toont de indextabel die op basis van de samengestelde sleutels.The next figure shows an index table based on composite keys. De sleutels worden gesorteerd op stad, en vervolgens op LastName voor records met dezelfde waarde voor stad.The keys are sorted by Town, and then by LastName for records that have the same value for Town.

Afbeelding 5: de indextabel van een op basis van samengestelde sleutels

Index tabellen versnellen querybewerkingen via gedeelde gegevens en met name nuttig zijn wanneer de shard-sleutel wordt opgedeeld.Index tables can speed up query operations over sharded data, and are especially useful where the shard key is hashed. De volgende afbeelding toont een voorbeeld waarin de shard-sleutel is een hash van de klant-ID.The next figure shows an example where the shard key is a hash of the Customer ID. De indextabel kunt Organiseer de gegevens door de nonhashed waarde (stad en LastName) en geef de hash shard-sleutel als de lookup-gegevens.The index table can organize data by the nonhashed value (Town and LastName), and provide the hashed shard key as the lookup data. Dit kunt opslaan dat de toepassing van het hash-sleutels (een dure bewerking) herhaaldelijk berekenen dat deze moeten gegevens ophalen die binnen een bereik valt of het gebruikersrecht voor het ophalen van gegevens in de volgorde van de nonhashed sleutel.This can save the application from repeatedly calculating hash keys (an expensive operation) if it needs to retrieve data that falls within a range, or it needs to fetch data in order of the nonhashed key. Bijvoorbeeld, een query, zoals 'Alle klanten die live vinden in Redmond' snel worden opgelost door de overeenkomende items in de indextabel vinden waar ze zijn alle opgeslagen in een aaneengesloten blok.For example, a query such as “Find all customers that live in Redmond” can be quickly resolved by locating the matching items in the index table, where they're all stored in a contiguous block. Volg daarna de verwijzingen naar de klantgegevens met behulp van de shard-sleutels opgeslagen in de indextabel.Then, follow the references to the customer data using the shard keys stored in the index table.

Afbeelding 6: de indextabel bieden snel lookup voor gedeelde gegevens

Problemen en overwegingenIssues and considerations

Houd rekening met de volgende punten bij het bepalen van het implementeren van dit patroon:Consider the following points when deciding how to implement this pattern:

  • De overhead van het onderhouden van de secundaire indexen kunt verwaarloosbaar zijn.The overhead of maintaining secondary indexes can be significant. U moet analyseren en inzicht in de query's die uw toepassing wordt gebruikt.You must analyze and understand the queries that your application uses. Alleen index tabellen maken wanneer ze waarschijnlijk regelmatig worden gebruikt.Only create index tables when they're likely to be used regularly. Maak tabellen speculatieve index ter ondersteuning van query's die een toepassing niet uitvoeren of alleen sporadisch uitvoert.Don't create speculative index tables to support queries that an application doesn't perform, or performs only occasionally.
  • Het dupliceren van gegevens in de indextabel kunt toevoegen aanzienlijke overhead opslagkosten en de moeite meerdere kopieën van gegevens.Duplicating data in an index table can add significant overhead in storage costs and the effort required to maintain multiple copies of data.
  • De indextabel implementeren als een genormaliseerde structuur die verwijst naar de oorspronkelijke gegevens, moet een toepassing voor bewerkingen twee lookup om gegevens te zoeken.Implementing an index table as a normalized structure that references the original data requires an application to perform two lookup operations to find data. De eerste bewerking in de indextabel om op te halen van de primaire sleutel wordt gezocht en de tweede maakt gebruik van de primaire sleutel voor het ophalen van de gegevens.The first operation searches the index table to retrieve the primary key, and the second uses the primary key to fetch the data.
  • Als een systeem een aantal tabellen index via zeer grote gegevenssets omvat, kan het lastig zijn om consistentie tussen de tabellen van de index en de oorspronkelijke gegevens te behouden.If a system incorporates a number of index tables over very large data sets, it can be difficult to maintain consistency between index tables and the original data. Het is mogelijk om de toepassing om het model uiteindelijke consistentie te ontwerpen.It might be possible to design the application around the eventual consistency model. Een toepassing kan bijvoorbeeld wilt invoegen, bijwerken of verwijderen van gegevens, een bericht naar een wachtrij plaatsen en kunt een afzonderlijke taak de bewerking niet uitvoeren en onderhouden van de index-tabellen die verwijzen naar deze gegevens asynchroon.For example, to insert, update, or delete data, an application could post a message to a queue and let a separate task perform the operation and maintain the index tables that reference this data asynchronously. Zie voor meer informatie over het implementeren van uiteindelijke consistentie de gegevens consistentie Primer.For more information about implementing eventual consistency, see the Data Consistency Primer.

    Microsoft Azure storage-tabellen ondersteuning voor transactionele updates voor wijzigingen in gegevens die zijn opgeslagen in dezelfde partitie (aangeduid als entiteit groepstransacties).Microsoft Azure storage tables support transactional updates for changes made to data held in the same partition (referred to as entity group transactions). Als u kunt de gegevens voor een feitentabel en een of meer tabellen van de index in dezelfde partitie opslaan, kunt u deze functie gebruiken om te consistentie te garanderen.If you can store the data for a fact table and one or more index tables in the same partition, you can use this feature to help ensure consistency.

  • Index tabellen zelf mogelijk gepartitioneerde of shard.Index tables might themselves be partitioned or sharded.

Het gebruik van dit patroonWhen to use this pattern

Gebruik dit patroon te verbeteren, wanneer een toepassing vaak moet het ophalen van gegevens met behulp van een sleutel dan de primaire (of shard)-sleutel.Use this pattern to improve query performance when an application frequently needs to retrieve data by using a key other than the primary (or shard) key.

Dit patroon mogelijk niet handig zijn wanneer:This pattern might not be useful when:

  • Gegevens zijn vluchtige.Data is volatile. De indextabel kunt verouderd raken zeer snel waardoor het ongeschikt of de overhead van het onderhouden van de indextabel die groter is dan een met behulp van het gerealiseerde besparingen maken.An index table can become out of date very quickly, making it ineffective or making the overhead of maintaining the index table greater than any savings made by using it.
  • Een veld dat is geselecteerd als de secundaire sleutel voor de indextabel is nondiscriminating en kan slechts een kleine set waarden (bijvoorbeeld, geslacht).A field selected as the secondary key for an index table is nondiscriminating and can only have a small set of values (for example, gender).
  • Het saldo van de waarden voor een veld dat is geselecteerd als de secundaire sleutel voor de indextabel zijn maximaal vervormd.The balance of the data values for a field selected as the secondary key for an index table are highly skewed. Bijvoorbeeld, als 90% van de records dezelfde waarde in een veld bevat, kunnen klikt u vervolgens het maken en onderhouden van de indextabel opzoeken van gegevens op basis van dit veld maken meer overhead dan scannen sequentieel worden verwerkt door de gegevens.For example, if 90% of the records contain the same value in a field, then creating and maintaining an index table to look up data based on this field might create more overhead than scanning sequentially through the data. Echter, wanneer query's heel vaak waarden die in de resterende 10% liggen, deze index kan nuttig zijn.However, if queries very frequently target values that lie in the remaining 10%, this index can be useful. De query's die uw toepassing wordt uitgevoerd en hoe vaak ze hebt uitgevoerd, moet u begrijpen.You should understand the queries that your application is performing, and how frequently they're performed.

VoorbeeldExample

Azure storage-tabellen bieden een uiterst schaalbare sleutel/waarde-gegevensarchief voor toepassingen die worden uitgevoerd in de cloud.Azure storage tables provide a highly scalable key/value data store for applications running in the cloud. Toepassingen opslaan en ophalen van waarden door te geven van een sleutel.Applications store and retrieve data values by specifying a key. De gegevenswaarden kunnen meerdere velden bevatten, maar de structuur van een gegevensitem ondoorzichtige naar table storage, die een gegevensitem gewoon als een matrix met bytes verwerkt is.The data values can contain multiple fields, but the structure of a data item is opaque to table storage, which simply handles a data item as an array of bytes.

Azure storage-tabellen ook ondersteunen sharding.Azure storage tables also support sharding. De sleutel sharding bevat twee elementen, een partitiesleutel en de rijsleutel van een.The sharding key includes two elements, a partition key and a row key. Items met dezelfde partitiesleutel worden opgeslagen in dezelfde partitie (shard) en de items worden opgeslagen in de rij sleutel volgorde binnen een shard.Items that have the same partition key are stored in the same partition (shard), and the items are stored in row key order within a shard. Table storage is geoptimaliseerd voor het uitvoeren van query's die gegevens van een aaneengesloten reeks rijwaarden binnen een partitie ophalen.Table storage is optimized for performing queries that fetch data falling within a contiguous range of row key values within a partition. Als u cloudtoepassingen die gegevens opslaan in Azure-tabellen maakt, moet u uw gegevens met deze functie in gedachten structuur.If you're building cloud applications that store information in Azure tables, you should structure your data with this feature in mind.

Neem bijvoorbeeld een toepassing die informatie over films opslaat.For example, consider an application that stores information about movies. De toepassing vraagt regelmatig films op genre (actie, documenten, historische, comedy, drama, enzovoort).The application frequently queries movies by genre (action, documentary, historical, comedy, drama, and so on). U kunt een Azure-tabel met partities die voor elke genre met behulp van het genre als de partitiesleutel en de naam van de film opgeven als de rijsleutel maken, zoals weergegeven in de volgende afbeelding.You could create an Azure table with partitions for each genre by using the genre as the partition key, and specifying the movie name as the row key, as shown in the next figure.

Afbeelding 7: film opgeslagen gegevens in een Azure-tabel

Deze aanpak is minder effectief als de toepassing ook query films moet door starring actor.This approach is less effective if the application also needs to query movies by starring actor. In dit geval kunt u een afzonderlijke Azure-tabel die als de indextabel van een fungeert maken.In this case, you can create a separate Azure table that acts as an index table. De partitiesleutel is de actor en de rijsleutel is de naam van de film.The partition key is the actor and the row key is the movie name. De gegevens voor elke actor zal worden opgeslagen in afzonderlijke partities.The data for each actor will be stored in separate partitions. Als een film meer dan één actor sterren, wordt de dezelfde film optreden in meerdere partities.If a movie stars more than one actor, the same movie will occur in multiple partitions.

U kunt de filmgegevens in de overstap op de eerste benadering beschreven in de bovenstaande oplossing sectie door elke partitie waarover waarden dupliceren.You can duplicate the movie data in the values held by each partition by adopting the first approach described in the Solution section above. Het is echter waarschijnlijk dat elke film wordt meerdere keren (één keer voor elke actor) worden gerepliceerd, zodat deze gedeeltelijk efficiënter om te kan worden de gegevens voor de ondersteuning van de meest voorkomende query's (zoals de namen van de andere actoren) en het inschakelen van een toepassing voor het ophalen van denormalize alle resterende gegevens door te nemen van de partitiesleutel die nodig zijn voor de volledige gegevens niet vinden in de genre-partities.However, it's likely that each movie will be replicated several times (once for each actor), so it might be more efficient to partially denormalize the data to support the most common queries (such as the names of the other actors) and enable an application to retrieve any remaining details by including the partition key necessary to find the complete information in the genre partitions. Deze aanpak is beschreven door de derde optie in de sectie oplossing.This approach is described by the third option in the Solution section. De volgende afbeelding ziet u deze methode.The next figure shows this approach.

Afbeelding 8 - Actor partities die fungeert als index tabellen voor Filmgegevens

De volgende patronen en richtlijnen mogelijk ook relevant zijn bij het implementeren van dit patroon:The following patterns and guidance might also be relevant when implementing this pattern:

  • Gegevens consistentie Primer.Data Consistency Primer. Een indextabel moet blijven de gegevens het indexeren van wijzigingen.An index table must be maintained as the data that it indexes changes. In de cloud, deze mogelijk niet mogelijk of wenselijk bewerkingen uitvoeren die voor het bijwerken van een index als onderdeel van dezelfde transactie waarmee de gegevens worden gewijzigd.In the cloud, it might not be possible or appropriate to perform operations that update an index as part of the same transaction that modifies the data. In dat geval is een benadering uiteindelijk consistent beter geschikt.In that case, an eventually consistent approach is more suitable. Bevat informatie over de problemen rond de uiteindelijke consistentie.Provides information on the issues surrounding eventual consistency.
  • Sharding-patroon.Sharding pattern. De indextabel-patroon wordt vaak gebruikt in combinatie met gegevens die worden gepartitioneerd met shards.The Index Table pattern is frequently used in conjunction with data partitioned by using shards. Het patroon Sharding bevat meer informatie over hoe u een gegevensarchief onderverdelen in een set met shards.The Sharding pattern provides more information on how to divide a data store into a set of shards.
  • Gerealiseerde weergave patroon.Materialized View pattern. In plaats van het indexeren van gegevens voor query's waarin gegevens worden samengevat ondersteuning mogelijk meer geschikt is voor het maken van een gerealiseerde weergave van de gegevens.Instead of indexing data to support queries that summarize data, it might be more appropriate to create a materialized view of the data. Beschrijft hoe u ondersteuning voor efficiënte samenvatting query's vooraf ingevulde weergaven van gegevens te genereren.Describes how to support efficient summary queries by generating prepopulated views over data.