<div id="readability-page-1" class="page"><div><a href="https://youtu.be/U_GJYMUjiwA">https://youtu.be/U_GJYMUjiwA</a>
AWS Tier 0 service ?
Tier 0 service? 
Tier 0 (tier zero) is a level of data storage that is faster, and perhaps more expensive, than any other level in the storage hierarchy.
<a href="https://www.techtarget.com/searchstorage/definition/Tier-0">https://www.techtarget.com/searchstorage/definition/Tier-0</a>
<img src="https://velog.velcdn.com/images/2taesung/post/2fd1ec86-2b9a-4499-aa6e-0202beb91656/image.png">
<h2 id="개념-정리">개념 정리</h2>
<img src="https://velog.velcdn.com/images/2taesung/post/8f392de2-f677-4a6b-978e-10ef5f10d149/image.png">
Table 
테이블에 저장되는 레코드를 Item
<img src="https://velog.velcdn.com/images/2taesung/post/4fd3430c-be8e-476a-8e0e-54d053123bda/image.png">
기본적으로 PK에 의해 분산되며 같은 노드에서 sort key로 정렬됨.
Item 
내부에서 column이라고 불리는 Attributes로 구성됨
Partition Key 
하나의 테이블은 Partition Key로 분리가 됨 
그 때문에 반드시 필수적으로 설계 필요
일반적으로 유일성이 있는 사용자 아이디 같은 걸로 함. 
=&gt; user 정보라면 사용자 아이디가 유일성이 있는 key 
=&gt; 그런데 우리가 만들려고 하는 생육기록 테이블 같은 경우는 유일성이 날짜 ? 
=&gt; 아니다 다양한 아이디에서 해당 날짜의 데이터가 생성될 수 있고 심지어 한 아이디에서도 작물이 다른 두개의 데이터도 생성될 가능성은 존재한다.
aws 공식 문서 정리 해주신 블로그 
<a href="https://hello-world.kr/19">https://hello-world.kr/19</a>
=&gt; Partition Key에 따른 Hash함수에의해 물리적으로 partition된 노드로 저장됨.
=&gt; Partitioning 은 Partition 별로 동일한 Capacity Unit을 제공받기 때문에 균등한 요청, 크기로 Partition 할당이 중요하다. 이를통해 데이터의 분산이 필요하다.
=&gt; DynamoDB의 성능은 RCU(Read Capacity Units)와 WCU(Write Capacity Units)에 의해 결정됨.
=&gt; 고로 우리 시스템에서는 팀으로 대표되는 UserId가 적절. 
=&gt; 팀으로 ID가 되기 때문에 인원이 퇴사하더라도 유지가 되고 거의 균일하게 (정상적으로 생육기록이 진행될 경우)
=&gt; Primary Key가 복합키인 경우에도 단일 Partition Key ??
=&gt; Partiction Key와 sort key가 합쳐지는 복합키 Primary key를 계획하려고 할 때 고민이 많다. 
<a href="https://aws.amazon.com/blogs/database/choosing-the-right-dynamodb-partition-key/">https://aws.amazon.com/blogs/database/choosing-the-right-dynamodb-partition-key/</a>
<img src="https://velog.velcdn.com/images/2taesung/post/03792f01-990f-46ae-808d-1339774619bd/image.png">
<img src="https://velog.velcdn.com/images/2taesung/post/b6d53af1-60fc-446d-958c-04939a43f454/image.png">
=&gt; Partition은 각 table 안에 Partition Key를 통해 구분이 되는 것을 말함.
=&gt; 좀더 나아가 Partition Key와 SortKey가 합쳐져 PK(Primary Key)를 구성함
<a href="https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-sort-keys.html">https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-sort-keys.html</a>
aws dynamodb sdk node.js 연결 
<a href="https://m.blog.naver.com/nieah914/222006261945">https://m.blog.naver.com/nieah914/222006261945</a>
<img src="https://velog.velcdn.com/images/2taesung/post/03792f01-990f-46ae-808d-1339774619bd/image.png">
Partition
<img src="https://velog.velcdn.com/images/2taesung/post/7179d271-0505-48db-95b5-5be01dbe6116/image.png">
=&gt; 각 Partition 별로 10GB 제한 약 25,000개의 Item 
=&gt; 1년에 24개 
LSI(Local Secondary Index) 
원본 테이블과 PK를 같이 가져간다? 
즉, LSI는 테이블에 속한 Index 
=&gt; 그래서 이름이 Local이 붙는다. 
=&gt; 로컬 변수 이런것보다 로컬 인덱스인셈
GSI(Global Secondary Index) 
원본 테이블로부터 복사본을 갖는 별도의 테이블 
즉, GSI는 원본 테이블과 다른 PK를 생성할 수 있음 
=&gt; 얘네들은 필요에 따라 Partition Key로 별도 생성할 수 있음 
=&gt; 그러므로 추후에 필요시에 사용될 것 같은데 
=&gt; 여기서 미리 GSI를 설정해야하는지 확인이 필요할듯 
=&gt; GSI는 별도로 메모리를 먹기 때문에 적절한 설정이 중요함.
=&gt; 그런데 여기서 나오는 OrderId는 무엇?
auto scailing
<img src="https://velog.velcdn.com/images/2taesung/post/4ea131d9-52eb-4beb-a0bd-f743d52b7ba6/image.png">
=&gt; 트래픽 scailing을 해주는 것 
=&gt; 각각의 Partition 들의 트래픽에 따라 효율적으로 비용을 관리해줄 수 있음. 사진에서와 같이 다양한 옵션들이 존재. 
=&gt; 관련 트래픽 데이터를 확보하여 추후 최우선적으로 도입을 시도해야함
Burst
<img src="https://velog.velcdn.com/images/2taesung/post/eeb745db-a25d-4154-ae84-37a2f720db23/image.png">
<img src="https://velog.velcdn.com/images/2taesung/post/f7e54d03-9dc7-42c4-a59f-cc9bba424776/image.png">
=&gt; 특정 Partition에 트래픽이 몰릴 경우 효과적이고 효율적으로 처리할 수 있는 방법 
=&gt; Partition을 아이디로 할 경우 특정 트래픽으로 몰릴 가능성이 매우 낮음으로 신경 안써도 될듯.
Throttling
<img src="https://velog.velcdn.com/images/2taesung/post/9e9605ae-411a-43aa-957d-bcc99357c40f/image.png">
=&gt; 갑자기 예기치 않은 트래픽이 발생할 경우 생길 수 있는 문제 
=&gt; 우리는 이러지 않을 것이기에 이것도 신경 안써도 될듯.
Best Practice Data modeling
<img src="https://velog.velcdn.com/images/2taesung/post/9d0b0098-445b-455c-b297-b17336fa7fa1/image.png">
<img src="https://velog.velcdn.com/images/2taesung/post/01ec5256-dc45-4b8f-a3c9-043de76a3c26/image.png">
aws sdk 연결 
<a href="https://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v2/developer-guide/dynamodb-examples-using-tables.html">https://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v2/developer-guide/dynamodb-examples-using-tables.html</a></div></div>

2taesung.log

Taesung Lee

https://youtu.be/U_GJYMUjiwA
AWS Tier 0 service ?
Tier 0 service?
Tier 0 (tier zero) is a level of data storage that is faster, and perhaps more expensive, than any other level in the storage hierarchy.
https://www.techtarget.com/searchstorage/definition/Tier-0
개념 정리
Table
테이블에 저장되는 레코드를 Item
기본적으로 PK에 의해 분산되며 같은 노드에서 sort key로 정렬됨.
Item
내부에서 column이라고 불리는 Attributes로 구성됨
Partition Key
하나의 테이블은 Partition Key로 분리가 됨
그 때문에 반드시 필수적으로 설계 필요
일반적으로 유일성이 있는 사용자 아이디 같은 걸로 함.
=> user 정보라면 사용자 아이디가 유일성이 있는 key
=> 그런데 우리가 만들려고 하는 생육기록 테이블 같은 경우는 유일성이 날짜 ?
=> 아니다 다양한 아이디에서 해당 날짜의 데이터가 생성될 수 있고 심지어 한 아이디에서도 작물이 다른 두개의 데이터도 생성될 가능성은 존재한다.
aws 공식 문서 정리 해주신 블로그
https://hello-world.kr/19
=> Partition Key에 따른 Hash함수에의해 물리적으로 partition된 노드로 저장됨.
=> Partitioning 은 Partition 별로 동일한 Capacity Unit을 제공받기 때문에 균등한 요청, 크기로 Partition 할당이 중요하다. 이를통해 데이터의 분산이 필요하다.
=> DynamoDB의 성능은 RCU(Read Capacity Units)와 WCU(Write Capacity Units)에 의해 결정됨.
=> 고로 우리 시스템에서는 팀으로 대표되는 UserId가 적절.
=> 팀으로 ID가 되기 때문에 인원이 퇴사하더라도 유지가 되고 거의 균일하게 (정상적으로 생육기록이 진행될 경우)
=> Primary Key가 복합키인 경우에도 단일 Partition Key ??
=> Partiction Key와 sort key가 합쳐지는 복합키 Primary key를 계획하려고 할 때 고민이 많다.
https://aws.amazon.com/blogs/database/choosing-the-right-dynamodb-partition-key/
=> Partition은 각 table 안에 Partition Key를 통해 구분이 되는 것을 말함.
=> 좀더 나아가 Partition Key와 SortKey가 합쳐져 PK(Primary Key)를 구성함
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-sort-keys.html
aws dynamodb sdk node.js 연결
https://m.blog.naver.com/nieah914/222006261945
Partition
=> 각 Partition 별로 10GB 제한 약 25,000개의 Item
=> 1년에 24개 
LSI(Local Secondary Index)
원본 테이블과 PK를 같이 가져간다?
즉, LSI는 테이블에 속한 Index
=> 그래서 이름이 Local이 붙는다.
=> 로컬 변수 이런것보다 로컬 인덱스인셈
GSI(Global Secondary Index)
원본 테이블로부터 복사본을 갖는 별도의 테이블
즉, GSI는 원본 테이블과 다른 PK를 생성할 수 있음
=> 얘네들은 필요에 따라 Partition Key로 별도 생성할 수 있음
=> 그러므로 추후에 필요시에 사용될 것 같은데 
=> 여기서 미리 GSI를 설정해야하는지 확인이 필요할듯
=> GSI는 별도로 메모리를 먹기 때문에 적절한 설정이 중요함.
=> 그런데 여기서 나오는 OrderId는 무엇?
auto scailing
=> 트래픽 scailing을 해주는 것
=> 각각의 Partition 들의 트래픽에 따라 효율적으로 비용을 관리해줄 수 있음. 사진에서와 같이 다양한 옵션들이 존재.
=> 관련 트래픽 데이터를 확보하여 추후 최우선적으로 도입을 시도해야함
Burst
=> 특정 Partition에 트래픽이 몰릴 경우 효과적이고 효율적으로 처리할 수 있는 방법
=> Partition을 아이디로 할 경우 특정 트래픽으로 몰릴 가능성이 매우 낮음으로 신경 안써도 될듯.
Throttling
=> 갑자기 예기치 않은 트래픽이 발생할 경우 생길 수 있는 문제
=> 우리는 이러지 않을 것이기에 이것도 신경 안써도 될듯.
Best Practice Data modeling
aws sdk 연결
https://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v2/developer-guide/dynamodb-examples-using-tables.html

DynamoDB

댓글