How to implement simple dynamodb table with daily value

I'am learning AWS API Gateway + Lambda + Dynamodb by building a very simple API project.

I have a daily value starting from 2013-01-01 and keep updating every day, so basically is something like:

[

    {

        "value": 1776.09,

        "date": "2013-01-01"

    },

    {

        "value": 1779.25,

        "date": "2013-01-02"

    },

    // ...

    {

        "value": 2697.32,

        "date": "2018-11-22"

    }

]

In the API I want to get the data for a specific day and for a range (dateFrom - dateTo), and I've been reading about Dynamodb and planning to have date as partition key in format YYYY-MM-DD and no sorting key, but not sure if this is the correct aproach for this type of data and the range query I'm going to be doing as I assume I'm going to have to do a full table scan for the range query, although is a small data set.

Can someone point me if this aproach is right or do I need to reconsider my table structure.

asked Nov 22 '18 at 22:48

archemiro

1,3181215

add a comment |

I'am learning AWS API Gateway + Lambda + Dynamodb by building a very simple API project.

I have a daily value starting from 2013-01-01 and keep updating every day, so basically is something like:

[

    {

        "value": 1776.09,

        "date": "2013-01-01"

    },

    {

        "value": 1779.25,

        "date": "2013-01-02"

    },

    // ...

    {

        "value": 2697.32,

        "date": "2018-11-22"

    }

]

Can someone point me if this aproach is right or do I need to reconsider my table structure.

asked Nov 22 '18 at 22:48

archemiro

1,3181215

add a comment |

I'am learning AWS API Gateway + Lambda + Dynamodb by building a very simple API project.

I have a daily value starting from 2013-01-01 and keep updating every day, so basically is something like:

[

    {

        "value": 1776.09,

        "date": "2013-01-01"

    },

    {

        "value": 1779.25,

        "date": "2013-01-02"

    },

    // ...

    {

        "value": 2697.32,

        "date": "2018-11-22"

    }

]

Can someone point me if this aproach is right or do I need to reconsider my table structure.

asked Nov 22 '18 at 22:48

archemiro

1,3181215

I'am learning AWS API Gateway + Lambda + Dynamodb by building a very simple API project.

I have a daily value starting from 2013-01-01 and keep updating every day, so basically is something like:

[

    {

        "value": 1776.09,

        "date": "2013-01-01"

    },

    {

        "value": 1779.25,

        "date": "2013-01-02"

    },

    // ...

    {

        "value": 2697.32,

        "date": "2018-11-22"

    }

]

Can someone point me if this aproach is right or do I need to reconsider my table structure.

amazon-web-services amazon-dynamodb

asked Nov 22 '18 at 22:48

archemiro

1,3181215

asked Nov 22 '18 at 22:48

archemiro

1,3181215

asked Nov 22 '18 at 22:48

archemiro

1,3181215

asked Nov 22 '18 at 22:48

archemiro

1,3181215

asked Nov 22 '18 at 22:48

archemiro

1,3181215

add a comment |

1 Answer
1

active

oldest

votes

What you propose will work.

However, if you want to improve the efficiency of the design, you could use a partition key of YYYY and then your sort key could be MM-DD. That way, you can use a query operation to limit the results (or you could still use a scan).

You could even use a single, constant value for the partition key and date as the sort key, but having the same partition key for every item is generally not recommended.

Either way, your data is small enough that you should probably just pick the implementation that is simplest to develop and maintain.

answered Nov 23 '18 at 0:29

Matthew Pope

1,3521612

Thanks! your answer gives me great insight about partition and sort keys. But I have a question regarding the first aproach (YYYY as partition key and MM-DD as sort key: If I do it that way, would I have to restrict the range queries by year, or could I still make a query that overlaps multiple years, for example from 2013-01-01 to 2015-12-31? Or maybe have YYYY as partition key (even just the last two digits: 13, 14, 15, etc) and YYYY-MM-DD as sort key? So I can make an date query overlaping multiple years.
– archemiro
Nov 23 '18 at 1:42

1

If your query spans multiple years, you can execute one query for each year and combine the results in your application, or you could do a table scan. Compared to a table scan, multiple queries will consume less RCU and (if you execute the queries in parallel) it will be faster.
– Matthew Pope
Nov 23 '18 at 2:01

1

If you’re going to use YYYY as the partition key, then you can’t get multiple years’ results even if you have a sort key of yyyy-mm-dd. Each query operation can only look at one partition key value.
– Matthew Pope
Nov 23 '18 at 2:09

Thank you for all that valuable info... just one last question: Is there going to be any performance difference if I use an integer type for the partition key over a string type, since it is going to be a number anyway?
– archemiro
Nov 23 '18 at 2:12

2

I work on an application that has large tables, some with number keys and some with string keys. I have never had any noticeable performance difference caused by the key type.
– Matthew Pope
Nov 23 '18 at 2:20

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53438790%2fhow-to-implement-simple-dynamodb-table-with-daily-value%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

What you propose will work.

You could even use a single, constant value for the partition key and date as the sort key, but having the same partition key for every item is generally not recommended.

Either way, your data is small enough that you should probably just pick the implementation that is simplest to develop and maintain.

answered Nov 23 '18 at 0:29

Matthew Pope

1,3521612

Thanks! your answer gives me great insight about partition and sort keys. But I have a question regarding the first aproach (YYYY as partition key and MM-DD as sort key: If I do it that way, would I have to restrict the range queries by year, or could I still make a query that overlaps multiple years, for example from 2013-01-01 to 2015-12-31? Or maybe have YYYY as partition key (even just the last two digits: 13, 14, 15, etc) and YYYY-MM-DD as sort key? So I can make an date query overlaping multiple years.
– archemiro
Nov 23 '18 at 1:42

1

If your query spans multiple years, you can execute one query for each year and combine the results in your application, or you could do a table scan. Compared to a table scan, multiple queries will consume less RCU and (if you execute the queries in parallel) it will be faster.
– Matthew Pope
Nov 23 '18 at 2:01

1

If you’re going to use YYYY as the partition key, then you can’t get multiple years’ results even if you have a sort key of yyyy-mm-dd. Each query operation can only look at one partition key value.
– Matthew Pope
Nov 23 '18 at 2:09

Thank you for all that valuable info... just one last question: Is there going to be any performance difference if I use an integer type for the partition key over a string type, since it is going to be a number anyway?
– archemiro
Nov 23 '18 at 2:12

2

I work on an application that has large tables, some with number keys and some with string keys. I have never had any noticeable performance difference caused by the key type.
– Matthew Pope
Nov 23 '18 at 2:20

add a comment |

What you propose will work.

You could even use a single, constant value for the partition key and date as the sort key, but having the same partition key for every item is generally not recommended.

Either way, your data is small enough that you should probably just pick the implementation that is simplest to develop and maintain.

answered Nov 23 '18 at 0:29

Matthew Pope

1,3521612

Thanks! your answer gives me great insight about partition and sort keys. But I have a question regarding the first aproach (YYYY as partition key and MM-DD as sort key: If I do it that way, would I have to restrict the range queries by year, or could I still make a query that overlaps multiple years, for example from 2013-01-01 to 2015-12-31? Or maybe have YYYY as partition key (even just the last two digits: 13, 14, 15, etc) and YYYY-MM-DD as sort key? So I can make an date query overlaping multiple years.
– archemiro
Nov 23 '18 at 1:42

1

If your query spans multiple years, you can execute one query for each year and combine the results in your application, or you could do a table scan. Compared to a table scan, multiple queries will consume less RCU and (if you execute the queries in parallel) it will be faster.
– Matthew Pope
Nov 23 '18 at 2:01

1

If you’re going to use YYYY as the partition key, then you can’t get multiple years’ results even if you have a sort key of yyyy-mm-dd. Each query operation can only look at one partition key value.
– Matthew Pope
Nov 23 '18 at 2:09

Thank you for all that valuable info... just one last question: Is there going to be any performance difference if I use an integer type for the partition key over a string type, since it is going to be a number anyway?
– archemiro
Nov 23 '18 at 2:12

2

I work on an application that has large tables, some with number keys and some with string keys. I have never had any noticeable performance difference caused by the key type.
– Matthew Pope
Nov 23 '18 at 2:20

add a comment |

What you propose will work.

You could even use a single, constant value for the partition key and date as the sort key, but having the same partition key for every item is generally not recommended.

Either way, your data is small enough that you should probably just pick the implementation that is simplest to develop and maintain.

answered Nov 23 '18 at 0:29

Matthew Pope

1,3521612

What you propose will work.

You could even use a single, constant value for the partition key and date as the sort key, but having the same partition key for every item is generally not recommended.

Either way, your data is small enough that you should probably just pick the implementation that is simplest to develop and maintain.

answered Nov 23 '18 at 0:29

Matthew Pope

1,3521612

answered Nov 23 '18 at 0:29

Matthew Pope

1,3521612

answered Nov 23 '18 at 0:29

Matthew Pope

1,3521612

answered Nov 23 '18 at 0:29

Matthew Pope

1,3521612

Thanks! your answer gives me great insight about partition and sort keys. But I have a question regarding the first aproach (YYYY as partition key and MM-DD as sort key: If I do it that way, would I have to restrict the range queries by year, or could I still make a query that overlaps multiple years, for example from 2013-01-01 to 2015-12-31? Or maybe have YYYY as partition key (even just the last two digits: 13, 14, 15, etc) and YYYY-MM-DD as sort key? So I can make an date query overlaping multiple years.
– archemiro
Nov 23 '18 at 1:42

1

If your query spans multiple years, you can execute one query for each year and combine the results in your application, or you could do a table scan. Compared to a table scan, multiple queries will consume less RCU and (if you execute the queries in parallel) it will be faster.
– Matthew Pope
Nov 23 '18 at 2:01

1

If you’re going to use YYYY as the partition key, then you can’t get multiple years’ results even if you have a sort key of yyyy-mm-dd. Each query operation can only look at one partition key value.
– Matthew Pope
Nov 23 '18 at 2:09

Thank you for all that valuable info... just one last question: Is there going to be any performance difference if I use an integer type for the partition key over a string type, since it is going to be a number anyway?
– archemiro
Nov 23 '18 at 2:12

2

I work on an application that has large tables, some with number keys and some with string keys. I have never had any noticeable performance difference caused by the key type.
– Matthew Pope
Nov 23 '18 at 2:20

add a comment |

Thanks! your answer gives me great insight about partition and sort keys. But I have a question regarding the first aproach (YYYY as partition key and MM-DD as sort key: If I do it that way, would I have to restrict the range queries by year, or could I still make a query that overlaps multiple years, for example from 2013-01-01 to 2015-12-31? Or maybe have YYYY as partition key (even just the last two digits: 13, 14, 15, etc) and YYYY-MM-DD as sort key? So I can make an date query overlaping multiple years.
– archemiro
Nov 23 '18 at 1:42

1

If your query spans multiple years, you can execute one query for each year and combine the results in your application, or you could do a table scan. Compared to a table scan, multiple queries will consume less RCU and (if you execute the queries in parallel) it will be faster.
– Matthew Pope
Nov 23 '18 at 2:01

1

If you’re going to use YYYY as the partition key, then you can’t get multiple years’ results even if you have a sort key of yyyy-mm-dd. Each query operation can only look at one partition key value.
– Matthew Pope
Nov 23 '18 at 2:09

Thank you for all that valuable info... just one last question: Is there going to be any performance difference if I use an integer type for the partition key over a string type, since it is going to be a number anyway?
– archemiro
Nov 23 '18 at 2:12

2

I work on an application that has large tables, some with number keys and some with string keys. I have never had any noticeable performance difference caused by the key type.
– Matthew Pope
Nov 23 '18 at 2:20

Thanks! your answer gives me great insight about partition and sort keys. But I have a question regarding the first aproach (YYYY as partition key and MM-DD as sort key: If I do it that way, would I have to restrict the range queries by year, or could I still make a query that overlaps multiple years, for example from 2013-01-01 to 2015-12-31? Or maybe have YYYY as partition key (even just the last two digits: 13, 14, 15, etc) and YYYY-MM-DD as sort key? So I can make an date query overlaping multiple years.
– archemiro
Nov 23 '18 at 1:42

If your query spans multiple years, you can execute one query for each year and combine the results in your application, or you could do a table scan. Compared to a table scan, multiple queries will consume less RCU and (if you execute the queries in parallel) it will be faster.
– Matthew Pope
Nov 23 '18 at 2:01

If you’re going to use YYYY as the partition key, then you can’t get multiple years’ results even if you have a sort key of yyyy-mm-dd. Each query operation can only look at one partition key value.
– Matthew Pope
Nov 23 '18 at 2:09

Thank you for all that valuable info... just one last question: Is there going to be any performance difference if I use an integer type for the partition key over a string type, since it is going to be a number anyway?
– archemiro
Nov 23 '18 at 2:12

I work on an application that has large tables, some with number keys and some with string keys. I have never had any noticeable performance difference caused by the key type.
– Matthew Pope
Nov 23 '18 at 2:20

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

Some of your past answers have not been well-received, and you're in danger of being blocked from answering.

Please pay close attention to the following guidance:

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Htykuut