ควรใช้ข้อมูลประเภทใดในการประทับเวลาใน DynamoDB


98

ฉันยังใหม่กับ DynamoDB ฉันต้องการสร้างตารางที่ใช้ DeviceID เป็นคีย์แฮชการประทับเวลาเป็นคีย์ช่วงของฉันและข้อมูลบางส่วน

{ DeviceID: 123, Timestamp: "2016-11-11T17:21:07.5272333Z", X: 12, Y: 35 }

ใน SQL เราสามารถใช้ประเภทวันที่เวลาสำหรับ Timestamp ได้ แต่ใน DynamoDB จะไม่มี

  1. ฉันควรใช้ข้อมูลประเภทใด สตริง? จำนวน?
    ป้อนคำอธิบายภาพที่นี่

  2. สำหรับประเภทข้อมูลที่เลือกฉันควรเขียนรูปแบบการประทับเวลาแบบใด รูปแบบ ISO (เช่น: 2016-11-11T17: 21: 07.5272333Z) หรือช่วงเวลา (เช่น 1478943038816)?

  3. ฉันต้องการค้นหาในตารางตามช่วงเวลาเช่น 1/1/2558 10:00:00 น. ถึง 31/12/2559 23:00 น.



2
เราใช้ตัวเลขในช่วงเวลา / รูปแบบ เราใช้มันสำหรับการค้นหาช่วงเช่นกันกับ customer_id โดยทั่วไป
George M Whitaker

สามารถใช้ชนิดข้อมูลสตริงและตัวเลขได้ สตริงเมื่อจัดเก็บรูปแบบ ISO8601 และ Number เมื่อจัดเก็บเวลา Epoch ข้อมูลเพิ่มเติมที่นี่: abhayachauhan.com/2017/12/…
Abhaya Chauhan

เอกสารอย่างเป็นทางการกล่าวว่า "คุณสามารถใช้ชนิดข้อมูลสตริงเพื่อแสดงวันที่หรือการประทับเวลา. วิธีหนึ่งที่จะทำเช่นนี้คือการใช้มาตรฐาน ISO 8601 สตริง"
ฮง

คำตอบที่คุณคัดลอกภาพหน้าจอมาจาก ( stackoverflow.com/a/27894543/1357094 ) ตอบคำถามนี้ - และคำถามนี้ซ้ำกับที่กล่าวว่าคำถามของคำตอบในตอนแรก: stackoverflow.com/questions/27894393/…
cellepo

คำตอบ:


83

String ชนิดข้อมูลควรจะใช้สำหรับวันหรือการประทับเวลา

คุณสามารถใช้ชนิดข้อมูล String เพื่อแสดงวันที่หรือการประทับเวลา วิธีหนึ่งที่ทำได้คือใช้สตริง ISO 8601 ดังที่แสดงในตัวอย่างเหล่านี้:

2016-02-15

2015-12-21T17: 42: 34Z

20150311T122706Z

ชนิดข้อมูล DynamoDB สำหรับวันที่หรือเวลาประทับ

ใช่รองรับการสืบค้นช่วงเมื่อวันที่ถูกจัดเก็บเป็น String ระหว่างที่สามารถใช้กับ FilterExpresssion ฉันได้รับรายการในผลลัพธ์โดยใช้นิพจน์ตัวกรองด้านล่าง

FilterExpression แบบไม่มีเวลา: -

FilterExpression : 'createdate between :val1 and :val2',
ExpressionAttributeValues : {
        ':hkey' : year_val,
        ':rkey' : title,
        ":val1" : "2010-01-01",
        ":val2" : "2010-12-31"
    }

FilterExpression พร้อมเวลา: -

FilterExpression : 'createdate between :val1 and :val2',
    ExpressionAttributeValues : {
        ':hkey' : year_val,
        ':rkey' : title,
        ":val1" : "2010-01-01T00:00:00",
        ":val2" : "2010-12-31T00:00:00"
    }

ค่าฐานข้อมูล: -

รูปแบบ 1 - พร้อมเขตเวลา:

{"Item":{"createdate":{"S":"2010-12-21T17:42:34+00:00"},"title":{"S":"The Big New Movie 2010"},"yearkey":{"N":"2010"},"info":{"M":{"rating":{"N":"0"},"plot":{"S":"Nothing happens at all."}}}}}

รูปแบบ 2 - ไม่มีเขตเวลา: -

{"Item":{"createdate":{"S":"2010-12-21T17:42:34Z"},"title":{"S":"The Big New Movie 2010"},"yearkey":{"N":"2010"},"info":{"M":{"rating":{"N":"0"},"plot":{"S":"Nothing happens at all."}}}}}

แต่คุณสามารถค้นหาช่วงวันที่เมื่อเก็บเป็นค่า String ได้หรือไม่?
Mark B

@notionquest คุณสามารถค้นหาช่วงวันที่และเวลาด้วย String ได้หรือไม่?
Dennis

54
ฉันไม่เห็นว่าคุณมาถึง "ประเภทข้อมูลสตริงควรใช้สำหรับวันที่หรือเวลาประทับ" ได้อย่างไร เอกสารยังบอกด้วยว่าคุณสามารถใช้ประเภทข้อมูล Number สำหรับวันที่ผ่านช่วงเวลา ทำไมคุณถึงคิดว่าควรใช้String กับ Number?
Roly

1
สามารถใช้ชนิดข้อมูลสตริงและตัวเลขได้ สตริงเมื่อจัดเก็บรูปแบบ ISO8601 และ Number เมื่อจัดเก็บเวลา Epoch ข้อมูลเพิ่มเติมที่นี่: abhayachauhan.com/2017/12/…
Abhaya Chauhan

1
ตัวเลข @roly ควรใช้งานได้ดี แต่อ่านได้น้อยลง
Matthew Bonig

22

ประเภทข้อมูลขึ้นอยู่กับความต้องการของคุณ

คุณสามารถใช้ String โดยใช้รูปแบบ ISO หรือ Number โดยใช้รูปแบบ epoch

ข้อดีของรูปแบบ ISO (String) คือความสามารถในการอ่านของมนุษย์ แต่ DynamoDB ไม่รองรับ Time To Live (TTL) สำหรับรูปแบบนี้ ตัวกรองทั้งหมดทำงานเช่น "ระหว่าง" และ "ช่วง" ตามที่อธิบายโดย notionquest

Time To Live (TTL)สำหรับ DynamoDB ช่วยให้คุณกำหนดเวลาที่รายการในตารางจะหมดอายุเพื่อให้สามารถลบออกจากฐานข้อมูลได้โดยอัตโนมัติ

ข้อดีของการใช้รูปแบบ epoch (ตัวเลข) คือคุณสามารถใช้คุณสมบัติ TTL และตัวกรองทั้งหมดได้

TLDR;

รูปแบบ Epoch (ประเภทตัวเลข) - สามารถใช้
รูปแบบ ISO แบบTime To Live (ประเภทสตริง) - ไม่สามารถใช้ Time To Live แต่สามารถอ่านได้โดยมนุษย์


ตัวเลขอาจรองรับนิพจน์ตัวกรอง แต่เงื่อนไขคีย์ตามช่วงจะรองรับเฉพาะกับสตริงในรูปแบบ ISO
Rafael Almeida

@RafaelAlmeida คุณหมายถึงอะไร? และแหล่งที่มาของคุณคืออะไร?
Zachary Ryan Smith

1
@ZacharyRyanSmith ฉันผิด - แน่นอนแอตทริบิวต์ Number ทำงานเป็นคีย์การเรียงลำดับและในเงื่อนไขคีย์ในตัวกรอง
Rafael Almeida

2

ประเภทข้อมูล Number หรือชนิดข้อมูล String

สามารถใช้สำหรับ Date หรือ Timestamp - ไม่ใช่แค่ String เป็นคำตอบที่ได้รับการยอมรับสำหรับคำถามนี้แยกออกจากกันอย่างไม่ถูกต้องในขณะที่ไม่สนใจ Number

คุณสามารถใช้ประเภทข้อมูลตัวเลขเพื่อแสดงวันที่หรือการประทับเวลา วิธีหนึ่งในการดำเนินการนี้คือการใช้เวลาตามยุคซึ่งเป็นจำนวนวินาทีนับตั้งแต่ 00:00:00 UTC ของวันที่ 1 มกราคม 1970 ตัวอย่างเช่นช่วงเวลา 1437136300 หมายถึง 12:31:40 น. UTC ของวันที่ 17 กรกฎาคม 2015

สำหรับข้อมูลเพิ่มเติมโปรดดูที่http://en.wikipedia.org/wiki/Unix_time

...

คุณสามารถใช้ชนิดข้อมูล String เพื่อแสดงวันที่หรือการประทับเวลา วิธีหนึ่งที่ทำได้คือใช้สตริง ISO 8601 ดังที่แสดงในตัวอย่างเหล่านี้:

2016-02-15

2015-12-21T17: 42: 34Z

20150311T122706Z

สำหรับข้อมูลเพิ่มเติมโปรดดูที่http://en.wikipedia.org/wiki/ISO_8601

ชนิดข้อมูล DynamoDB สำหรับวันที่หรือเวลาประทับ


1

สำหรับฉันที่สามารถกรองผลลัพธ์เมื่อส่งคำขอแบบสอบถามฉันใช้รูปแบบ epoch สำหรับ DateTime มันมีประสิทธิภาพมากกว่าการใช้สตริง

ลองนึกภาพสถานการณ์เหล่านี้: 31 วันที่ผ่านมา 24 ชั่วโมงที่ผ่านมา ... อีกครั้งเป็นไปได้โดยใช้รูปแบบสตริงเนื่องจากมีตัวดำเนินการstart_with ด้วย ( โปรดตรวจสอบตัวอย่างที่ 3 ในลิงค์ด้านล่างใน AWS doc ) แต่ค่าตัวเลขจะมีประสิทธิภาพมากกว่าในแง่ ของประสิทธิภาพในขณะที่เรียงลำดับ (เปรียบเทียบ) และการคำนวณ

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Query.html#Query.KeyConditionExpressions

ง่ายต่อการแปลงวันที่ - เวลาเป็นรูปแบบ epoch

Javascript:

var date = new Date();
var epoch = date.getTime();

// converting back to date-time
var initial_date = new Date(epoch);

ค#

var date = DateTime.UtcNow;
var epoch = new DateTimeOffset(date).ToUnixTimeSeconds();

// converting back to date-time
var initial_date = DateTimeOffset.FromUnixTimeSeconds(epoch);

Python

import time
epoch = time.time()
 
# converting back to date-time
initial_date = time.gmtime(epoch )
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.