NoSQL 데이터베이스가 빠른 이유 | LSM Tree 완전정복

NoSQL 데이터베이스가 빠른 이유 | LSM Tree 완전정복 | DB 의 데이터 저장 방법

Рет қаралды 5,231

코맹탈출 - 실리콘밸리 개발이야기

Күн бұрын

Пікірлер: 35

@nagnelife2010 Жыл бұрын

미뤄둔거 드디어 봤습니다.. 넘 좋아요 다음편도 이어서 보겠습니다!!

@comg-dev 11 ай бұрын

감사합니다!!

@jayasome199 Жыл бұрын

볼 때마다 발표자료 퀄리티가 ㅎㄷㄷ 하네요 얼마나 오랜 시간을 쓰셨을지 ㅠㅠㅠ 늘 감사합니다!

@comg-dev Жыл бұрын

감사합니다 ㅎㅎ 감동이네요 ~ 오랫동안 라이브 안했는데 조만간 다시 켜겠습니다 ~

@jerryk0269 2 жыл бұрын

영상 잘봤습니다. 어려운 개념이라고 생각했는데 이렇게 쉽게 설명해 주시는 분 처음 봤습니다 ㅋㅋ 대박이네요 제 생각엔 delete 작업의 경우 rdb의 index delete 처럼 레코드에 delete 되었다고 마킹해 두었다가, compaction 과정에서 제거할 것 같네요~ 추가적으로 이전 영상에서 말씀드린 bloom filter 같은 것도 사용해서 성능 향상도 시킬 수도 있을 것 같고요! 이번 영상을 보면서 느낀 점 - LSM Tree의 백업용 Log File은 일종의 Redo Log라고 볼 수 있겠군요 - db마다 구현 방법이 다르겠지만 compaction 과정에서 log file에 대한 lock이 걸릴 것 같은데, 이것에 대한 대응 방안을 생각해 봤을 때 memory에 compaction target file 데이터를 memory에 input하고 hash index의 value를 memory로 link했다가 compaction 과정이 끝나면 lock을 해제하고, memory가 모자르면 disk에 dump해서(어차피 segments기 때문에 작다) compaction할 수 있겠다라는 생각이 드네요 영상을 보면서 몇가지 질문이 있는데요 1. Log structure storage engine에서 7:02 와 같은 경우에서 key 2112가 Segment2, Segment3에서 중복되어 있는데요 Active Segment가 아닌 이상 중복 검사를 수행하지 않고 이러한 중복 검사를 지연시킨 뒤, LSM Tree에서 low-level의 SSTables가 많을 때 compaction하는 것 처럼 Log structure ~ 에서도 low-level segment files을 동일하게 compaction 수행한다고 이해하면 될까요? 2. NoSQL에서 Join을 지원하지 않는 이유도 Log 파생 자료구조들의 특성 상 pk를 위주로 다루기 때문이라고 생각이 드는데요 이 생각도 맞을까요? (compaction 수행 과정 중 unique하지 않은 키값들은 compaction되므로 nested loop 등 rdb에서 기대하는 카타시안 곱 형태의 join이 나타날 수 없어 의미가 없다? 라는 생각도 들고, 같은 이유로 Index도 B+Tree가 아닌 Hash로 모든게 해결이 가능한 건가? 라는 생각이 드네요ㅎㅎ) 좋은 가르침 주셔서 감사합니다 선생님 :D

@learnstorock4162 2 жыл бұрын

2번은 NoSQL에서 조인을 지원 안하냐는 일단 NoSQL(키,밸류)는 테이블 개념이 없습니다. 그래서 두 테이블의 조인이란 말도 없게 됩니다. PK-FK를 정의하는 것도 기본적으로 없습니다. FK가 정의되어 있어야 연결 할 무언가를 찾게 되겠지요. 억지로 테이블을 만든다면 KEY-VALUE에서 KEY는 테이블명:PK로 만들고 Value는 콤마로 구분하는 문자리스트(컬럼들)가 되겠는데요. 특정 테이블의 로우들을 다 찾는것도 일이고, 그 테이블을 모아서 조인하는 것도 일인데 그것들은 NoSQL(LSM TREE,KEY-VALUE) 특성상 지원해 줄 의미가 없는거죠. 그건 상위레이어에서 사용자가만들어야 할 부분인거 같으며, 그걸 만들바엔 RDB를 사용하는게 낫겠죠.

@comg-dev 2 жыл бұрын

너무나 좋은 댓글 감사합니다 ~ > 제 생각엔 delete 작업의 경우 rdb의 index delete 처럼 레코드에 delete 되었다고 마킹해 두었다가, compaction 과정에서 제거할 것 같네요~ 정답입니다! tombstone 이라고 지웠다 라는 표시를 해놓습니다. 그래서 delete 도 용량을 free up 시켜주는게 아니라 용량을 차지하게 되죠 (말씀하신것 처럼 compaction 하면서 없어질 수도 있지만요 ㅎㅎ) > 추가적으로 이전 영상에서 말씀드린 bloom filter 같은 것도 사용해서 성능 향상도 시킬 수도 있을 것 같고요! 영상에 이 내용을 넣을까 말까 고민했는데 댓글 달아주셔서 감사합니다! Read 할 때 존재하지 않는 key 리퀘스트가 오면 존재하는 모든 SSTable 을 확인해야 하는데 이럴 때 Bloom Filter 사용해서 성능 향상 시킬 수 있습니다 ㅎㅎ > LSM Tree의 백업용 Log File은 일종의 Redo Log라고 볼 수 있겠군요 네 맞습니다 ~ > db마다 구현 방법이 다르겠지만 compaction 과정에서 log file에 대한 lock이 걸릴 것 같은데, 이것에 대한 대응 방안을 생각해 봤을 때 memory에 compaction target file 데이터를 memory에 input하고 hash index의 value를 memory로 link했다가 compaction 과정이 끝나면 lock을 해제하고, memory가 모자르면 disk에 dump해서(어차피 segments기 때문에 작다) compaction할 수 있겠다라는 생각이 드네요 SSTable 의 장점중의 하나가 SSTable 이 immutable 이기 때문에 lock 이 필요가 없다라는 겁니다. Compaction 할 때 있는 SSTable 을 수정하는게 아니라 아에 새로운 SSTable 을 만들게 되는데 Compaction 중간에 Read request 가 오면 원래 있던 SSTable 을 가지고 리퀘스트 핸들하고 Compaction 이 다 끝나서 새로운 SSTable 이 준비가 되었을 때 원래 파일을 지우는 방식으로 할 수 있습니다. > 1. Log structure storage engine에서 7:02 와 같은 경우에서 key 2112가 Segment2, Segment3에서 중복되어 있는데요 Active Segment가 아닌 이상 중복 검사를 수행하지 않고 이러한 중복 검사를 지연시킨 뒤, LSM Tree에서 low-level의 SSTables가 많을 때 compaction하는 것 처럼 Log structure ~ 에서도 low-level segment files을 동일하게 compaction 수행한다고 이해하면 될까요? 네 예제로 사용했던 기본적인 log structured storage engine 예제에서도 segment file 이 많아지면 compaction 할 때 여러개의 segment file 을 merge 한다고 생각하시면 됩니다. merge 되는 segment file 들 간에 중복되는 key 가 있으면 그 때 중복된 데이터를 없애는 방식으로 진행됩니다. > 2. NoSQL에서 Join을 지원하지 않는 이유도 Log 파생 자료구조들의 특성 상 pk를 위주로 다루기 때문이라고 생각이 드는데요 이 생각도 맞을까요? (compaction 수행 과정 중 unique하지 않은 키값들은 compaction되므로 nested loop 등 rdb에서 기대하는 카타시안 곱 형태의 join이 나타날 수 없어 의미가 없다? 라는 생각도 들고, 같은 이유로 Index도 B+Tree가 아닌 Hash로 모든게 해결이 가능한 건가? 라는 생각이 드네요ㅎㅎ) join 이 어떤식으로 구현되는지는 제가 정확히 몰라서 잘 답할 수 있는지 모르겠는데요. 한가지 말씀드릴수 있는건 LSM-Tree 가 join 을 못하는 이유는 아마 아닐거에요. 보통 MySQL 은 innoDB 라는 storage engine 을 쓰는데 페이스북에서 MyRocks 라고 MySQL 을 RocksDB 기반으로 만든게 있습니다. RocksDB 가 LSM-Tree 기반이고 MyRocks 가 join 을 지원하기 때문에 LSM-Tree 가 join 을 못하게 하는건 아닐거라는 생각이 드네요. NoSQL 데이터베이스들이 왜 join 을 지원하지 않는지에 대한 정확한 이유는 잘 모르겠네요 ㅜ

@jerryk0269 2 жыл бұрын

우와 두 분다 성의 있는 댓글 너무나 감사드립니다!! 덕분에 공부가 많이 되었네요 ㅎㅎㅎ

@제한상태 Жыл бұрын

너무 쉽게 설명해주시네요 바로 이해가 되었어요 감사해요

@comg-dev Жыл бұрын

감사합니다 ~

@bbang_b7 Жыл бұрын

설명 진짜 너무너무 좋았습니다.

@comg-dev Жыл бұрын

감사합니다!!

@learnstorock4162 2 жыл бұрын

일주일간 고생해서 이해했던건데 15분만에 그걸 점진적으로 해내네. 정말 대단한 티칭 능력이시네요. 굿~

@comg-dev 2 жыл бұрын

감사합니다 ~ ㅎㅎ 책의 도움을 많이 받았습니다 ㅎㅎ

@임혁진-v1b 2 жыл бұрын

당장 떠오르는 간단한 delete 방법은 해당 데이터가 삭제 되었다는 정보(빈데이터나 available비트변경?)를 추가하면 최근 값들을 우선으로 읽어서 데이터를 지운 효과를 얻을 수 있을 것 같아요

@comg-dev 2 жыл бұрын

정확합니다 ㅎㅎ tombstone 이라고 하는데 지웠다 라는 표시를 함으로서 데이터 삭제를 합니다. 그래서 delete 도 용량을 줄이는게 아니라 용량을 더 차지하게됩니다 ㅎㅎ

@류성훈-d5x Жыл бұрын

설명이 정말 깔끔해서 귀에 쏙쏙 들어옵니다 감사합니다 !!!

@comg-dev Жыл бұрын

좋은 말씀 감사합니다 ~ 널리 퍼트려 주세요 ~

@Pawn-mg3bd 2 жыл бұрын

영상에서 언급 주신 내용을 책으로 공부하면서 이해되지 않던 부분들이 많았는데 덕분에 이해가 되었습니다ㅜ 좋은 영상 만들어주셔서 감사합니다!

@comg-dev 2 жыл бұрын

도움이 되었다니 기쁩니다 ~ ㅎㅎ 감사합니다 ~

@BetterMovies 2 жыл бұрын

시스템 디자인 시리즈 매우유용하네요 감사합니다.

@comg-dev 2 жыл бұрын

감사합니다 ~~

@YooHyukLee-bk7my 11 ай бұрын

안녕하세요. 영상 잘 봤습니다. ^^ 간단한 질문이 하나 있어서 남깁니다. q1. 자료화면에서의 Sparse Index 2는 start offset에 대한 key만 갖고 있는 것으로 보입니다. (key 2112) SSTable이 이미 만들어진 상태라면 Sparse Index는 항상 start offset과 end offset이 포함된 상태여야 하지 않나 싶은데, 그렇지 않은 경우도 있을까요? 좋은 영상 만들어주셔서 감사합니다! 부족하지만 모르는 부분에 대해 알려주시면 정말 감사하겠습니다.

@nick6267 2 жыл бұрын

elasticsearch 같은 경우는 세그먼트가 불변이라 일정 크기까지 머지가 되고 머지될 때 삭제 체크된 것은 제거하고 합치게 되는데ㅎㅎlsm에 대해서 공부한거 복습한다고 생각하고 다시 봤어요

@comg-dev 2 жыл бұрын

elasticsearch 어떻게 작동하는지 한번 봐야겠다 생각하고 있는데 비슷한 개념이 들어있나 보군요!

@해리-h1w 2 жыл бұрын

오늘도 좋은 영상 감사드립니다! 집 가는 지하철에서 재밌게 봤습니다. 영상 보면서 한 가지 질문이 있어서 에피님께 여쭤보고 싶습니다. 12:36 에서 SSTable 1과 2 내에서 각각 정렬된 데이터가 들어가있는 것으로 보이는데요..! 만약 2114라는 데이터가 SSTable 1에 저장되어있다고 가정하고, 유저가 2114를 찾는다고 하면, 인덱스 2번을 본 다음에 없으면 인덱스 1번을 본다고 이해하면 될까요? 만약에 이렇게 조회가 된다고 하면 말씀하신 조금 더 큰 SSTable이 만들어졌을 때, 기존 조그마한 인덱스들은 어떻게 되는지도 궁금하네요! (새로 만들어지게 되는걸까요?) LSM Tree를 처음 봐서 이래저래 궁금한 점이 많아서 질문을 많이 드렸네요. 😅 항상 좋은 정보 공유주셔서 감사드립니다!!

@comg-dev 2 жыл бұрын

영상이 도움이 됐다니 기쁘네요 ㅎㅎ > 12:36 에서 SSTable 1과 2 내에서 각각 정렬된 데이터가 들어가있는 것으로 보이는데요..! 만약 2114라는 데이터가 SSTable 1에 저장되어있다고 가정하고, 유저가 2114를 찾는다고 하면, 인덱스 2번을 본 다음에 없으면 인덱스 1번을 본다고 이해하면 될까요? 네 정확하십니다. 2114 같은 경우에는 memtable 에 들어있기 때문에 memtable 확인하고 바로 리턴 하겠지만. 만약에 SSTable 1 에 9999 라는 데이터가 있다고 가정하고 유저가 9999 를 읽는 리퀘스트를 보내면 memtable 확인 -> SSTable 2 확인 -> SSTable 1 확인 하는 순서로 진행이 됩니다. 인덱스까지 포함해서 말하자면 memtable 확인 -> SSTable 2 index 확인 -> SSTable 2 확인 -> SSTable 1 index 확인 -> SSTable 1 확인 이런식으로 진행이 됩니다. SSTable 2 index 를 확인했음에도 SSTable 2 를 따로 확인해줘야하는 이유는 index 가 sparse 한 index 이기 때문인데요 (key 가 index 에 없는 경우 이 key 가 존재하지 않기 때문인지 아니면 index 가 sparse 해서 이 key 가 index 에서만 빠진거인지 알기 어렵기 때문에). 만약에 전체 key 를 저장하는 index 를 사용한다면 index 확인 하고 없으면 바로 다음 SSTable 의 index 로 넘어 갈 수 있습니다. > 만약에 이렇게 조회가 된다고 하면 말씀하신 조금 더 큰 SSTable이 만들어졌을 때, 기존 조그마한 인덱스들은 어떻게 되는지도 궁금하네요! (새로 만들어지게 되는걸까요?) 작은 SSTable 들이 merge/compaction 과정을 통해서 큰 SSTable 이 만들어 지고 나면 merge 된 작은 SSTable 들은 삭제됩니다 (그들의 index 도 같이 삭제 됩니다. 그 대신 새로 만들어진 큰 SSTable 의 index 를 다시 만듭니다). 하지만 memtable 이 일정 사이즈가 될 때 마다 다시 새로운 작은 SSTable 이 생기기 때문에 항상 여러 크기의 SSTable 이 동시에 존재하게 됩니다. 그래서 LSM-Tree based 된 DB 들 configure 할 때 중요한것 중 하나가 얼마나 자주 merge/compaction 을 할지 / memtable 이 어느 사이즈가 되면 SSTable 을 만들건지 정하는거라고 하네요.

@해리-h1w 2 жыл бұрын

@@comg-dev 아 그렇군요. 굉장히 흥미롭네요! 자세하게 설명해주셔서 감사합니다. 에피님 덕에 덕분에 많이 배웁니다. 감사합니다!!

@comg-dev 2 жыл бұрын

@@해리-h1w 감사합니다 ~~ 화이팅 ~