이 블로그의 내용은 대단히 주관적인 내용이 가득합니다.
그리고 양질의 글
을 읽었지만 똥글
이 나오는건 제 미숙함 때문입니다.
그럼에도 불구하고 피드백 많이 주신다면 자세히 조사하여 반영하도록 하겠습니다.
또한.. 가능한 링크로 올려놓은 자료들은 반드시 열어보시기 바랍니다. 분명 도움이 될 것입니다.
(- -)(_ _)
글을 읽는 대상인 독자님들은 RDBMS의 서비스를 경험해보았다는것을 기본 전제로 합니다.
또한, mongoDB를 약간이나마 경험해보았다면 더 없이 좋습니다.
하지만, 그렇다 하더라도 자세하게 설명하도록 노력해보겠습니다. 이해가 안되는 부분이 있다면 언제든지 지적해주세요!
읽기 용량 단위 1개는 크기 4 KB 이하의 항목에서 1초당 강력한 일관된 읽기 1회 또는 1초당 최종적 일관된 읽기 1회를 나타냅니다.
ex) 읽기 용량 단위 10개로 할당된 테이블이 있다.
이렇게 하면 크기 4 KB 이하의 항목에 대해 1초당 강력한 일관된 읽기(strongly consistent read) 10회
또는 1초당 최종적 일관된 읽기(eventually consistent query) 20회를 수행할 수 있습니다.
쓰기 용량 단위 1개는 크기 1 KB 이하인 항목을 1초당 1회 쓴다는 의미입니다.
ex) 쓰기 용량 단위 10개로 할당된 테이블이 있다.
이렇게 하면 크기 1 KB 이하의 항목에 대해 1초당 쓰기 10회를 수행할 수 있습니다.
쓰기 항목 크기는 다음 1 KB 배수로 반올림됩니다. 예를 들어 500바이트의 항목을 쓰려면 1 KB 항목을 쓸 때와 동일한 처리량이 소비됩니다. 1.5KB는 2KB로 처리된다.
쓰기 용량은 읽기 용량과 다르게 strongly consistent read, eventually consistent query가 없다.
트랜젝션처럼 구현하려면 조건문을 이용한 insert(put)을 이용하여서 구현한다.참고자료
이 부분에 대해서는 간단한 게시판 예제를 만들면서 한번 더 언급하겠습니다. 우선은 훑고 넘어만 가 줍시다.
full-managed에 메리트를 별로 못 느끼고 AWS를 적극활용하지 않는 곳이라면 굳이?(그러고 보니 PostgreSQL 재밌어 보이던데 ORM지원도 짱짱하고)
DynamoDB!
좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠!
좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠!
좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠!
좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠! 좀 더 노오오오력 하죠!
다음 포스트에서는 DynamoDB로 간단한 테이블을 만들어 보고 CRUD를 돌려보는 예제를 만들어 보겠습니다. :) (다음 예제는 AWS 계정 없이 진행할 수 있습니다. 하지만 dynamodb를 local환경에서 구성해서 예제를 만들것이기 때문에 docker & docker-compose는 필요합니다.)
최근 로그테이블로 사용하는 입장으로
로깅된 데이터 출력 및 활용면에서 (aggregate)
dynamodb query으로 한계에 봉착하여 결국 아래와 같이 사용하고있습니다. (스스로 못나서 그럴수있음)
dynamodb -> glue -> athene
dynamodb -> emr
와 같은 방법으로 데이터를 활용하고 있는데 이렇게 사용하면서 구지 dynamodb에 이점이 머가 있는지
곰곰이 생각하게 됩니다.
혹시 생각하시기로는 데이터 활용관련면에서 이점을 머라고 생각하고 계신가요?
의견을 듣고싶습니다.