[ 
https://issues.apache.org/jira/browse/HADOOP-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16789791#comment-16789791
 ] 

Steve Loughran commented on HADOOP-16118:
-----------------------------------------

APIs to create and update tables let you specify this

https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateTable.html
https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/dynamodbv2/AmazonDynamoDB.html#createTable-com.amazonaws.services.dynamodbv2.model.CreateTableRequest-

I've been testing with a pay-per-request table and part from where the  test 
ITestS3GuardToolDynamoDB.testDynamoDBInitDestroyCycle fails on those branche 
2.9-3.1 (We cut the capacity change from 3.2), all is well
{code}
testDynamoDBInitDestroyCycle(org.apache.hadoop.fs.s3a.s3guard.ITestS3GuardToolDynamoDB)
  Time elapsed: 18.179 s  <<< ERROR!
com.amazonaws.services.dynamodbv2.model.AmazonDynamoDBException: One or more 
parameter values were invalid: Neither ReadCapacityUnits nor WriteCapacityUnits 
can be specified when BillingMode is PAY_PER_REQUEST (Service: 
AmazonDynamoDBv2; Status Code: 400; Error Code: ValidationException; Request 
ID: J4B2L7CSQAGEF9LD028G4T8ACVVV4KQNSO5AEMVJF66Q9ASUAAJG)
{code}

Proposed

* we add this option
* it is on by default, especially for tests

That saves us having to guess what a good capacity is, keeps cost down for all

> S3Guard create bucket process to support on-demand DDB tables
> -------------------------------------------------------------
>
>                 Key: HADOOP-16118
>                 URL: https://issues.apache.org/jira/browse/HADOOP-16118
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: fs/s3
>    Affects Versions: 3.3.0
>            Reporter: Steve Loughran
>            Priority: Minor
>
> AWS now supports [on demand DDB 
> capacity|https://aws.amazon.com/blogs/aws/amazon-dynamodb-on-demand-no-capacity-planning-and-pay-per-request-pricing/]
>  
> This has lowest cost and best scalability, so could be the default capacity. 
> + add a new option to set-capacity.
> Will depend on an SDK update: created HADOOP-16117.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to