In the case of my application that would not work. Depending on your use case this may or may not be useful. To use a Local index it would have been required to add the Artist key to the KeySchema in each of the indexes. The key is that the KeySchema was not setup correctly. I tried several alternatives each of which gave a different error message. When attempting to deploy this using the Serverless Framework CLI tool, it gave me error messages like: An error occurred: DesiredNameOfTable - Property AttributeDefinitions is inconsistent with the KeySchema of the table and the secondary indexes.Īn error occurred: DesiredNameOfTable - One or more parameter values were invalid: Index KeySchema does not have a range key for index: RecordLabelĪn error occurred: DesiredNameOfTable - Property AttributeDefinitions is inconsistent with the KeySchema of the table and the secondary indexes. In neither case does the KeySchema for either Local index match the requirements stated earlier. It is of course the same object structure that is handed to DynamoDB. This is using the Serverless Framework representation because it's easier to read. In my first attempt to define a Local Secondary Index, I came up with something like: resources: Resources: DesiredNameOfTable: Type: 'AWS::DynamoDB::Table' Properties: TableName: "Music" AttributeDefinitions: - AttributeName: "Artist", AttributeType: "S" - AttributeName: "SongTitle", AttributeType: "S" - AttributeName: "RecordLabel", AttributeType: "S" - AttributeName: "RecordAlbumName", AttributeType: "S" KeySchema: - AttributeName: "Artist", KeyType: "HASH" - AttributeName: "SongTitle", KeyType: "RANGE" ProvisionedThroughput: - ReadCapacityUnits: 10 WriteCapacityUnits: 5 LocalSecondaryIndexes: - IndexName: LabelIndex KeySchema: - AttributeName: RecordLabel KeyType: HASH - IndexName: AlbumIndex KeySchema: - AttributeName: RecordAlbumName KeyType: HASH These indexes require their own ProvisionedThroughput.These columns must be declared in the AttributeDefinitions. It can use any column as the partition key (and if desired sort key).These indexes do not have their own ProvisionedThroughput, and therefore use the computing resources assigned to the table.The partition key in the Local Secondary Index must be the same as the partition key in the primary index for the table.The best DynamoDB has to offer is the secondary indexes: Local Secondary Index, and Global Secondary Indexīoth are defined using a KeySchema, and therefore has the same partition key and sort key arrangement. The data type is deduced by DocumentClient. When you define a DynamoDB table, you declare a KeySchema attribute describubg the primary index. In DynamoDB, you simply define the tables. In SQL databases - you define a "database" and then you define tables within that database.
Each record in each table can have its own columns. As a NoSQL database, saving an object into DynamoDB causes whatever fields that object has to be stored as columns in the record that's created.