몇 가지 코멘트 남깁니다 🔸이 영상은 마지막 3부 영상입니다 1부 : B tree 개념과 특징, 데이터 삽입 (th-cam.com/video/bqkcoSm_rCs/w-d-xo.html) 2부 : 데이터 삭제 (th-cam.com/video/H_u28u0usjA/w-d-xo.html) 3부 : 왜 DB 인덱스에 B tree 계열이 사용되는가 🔸데이터베이스의 의미 데이터베이스는 실제 데이터 그 자체 뿐만 아니라 관련 인덱스(index), 메타 데이터 등등을 모두 포함하는 개념입니다 🔸00:57 시간 복잡도에서 best case는 따로 언급하지 않았습니다 왜냐하면 보통, 평균이나 최악의 케이스일 때 시간 복잡도가 어느 정도인지를 더 궁금해 하기도 하고, 화면에 쓸 공간도 부족해서 생략했습니다 🔸01:53 O(logN)이라는 것은 (쉽게 설명하면) 데이터를 조회/삽입/삭제 할 때 최대 logN 만큼 확인해야한다는 의미가 되기 때문에 O(N)보다 성능이 좋다고 말할 수 있습니다 🔸05:14 비휘발성(non-volatile) 메모리도 존재하긴 합니다 하지만 우리가 보통 RAM이라고 할 때는 휘발성(volatile) 메모리라고 보시면 됩니다 🔸06:46 memory DB도 있습니다 일반적으로 데이터베이스는 secondary storage에 저장되지만 더 빠른 속도를 위해서 main memory에 데이터를 저장하는 memory db도 있습니다 🔸07:08 RAM, SSD, HDD의 속도 비교는 다나와에 들어가서 요즘 잘 팔리는 제품군들 위주로 비교해서 어림잡아 작성한 내용입니다 그렇기 때문에 정확한 수치로 보기보다는 전체적인 차이를 비교하는 목적으로 봐주시면 되겠습니다 🔸11:11 ‘핵심이 되는 데이터’라고 표현했지만 조금 더 정확히는 ‘핵심이 되는 데이터 + 자주 쓰이는 데이터’라고 봐주시면 될 것 같습니다 그래서 자주 쓰는 데이터는 메모리에 올려 두고, 그게 아닌 데이터들은 기본적으로 secondary storage에 뒀다가 필요하면 메모리로 올리는 식으로 동작하게 됩니다 🔸20:28 root 노드는 M차에 따른 최소 조건이 없고, B tree 자체의 최소 조건만 있기 때문에, root 모드에서는 최소 두 개의 자녀도를 가져야 합니다 그러므로 root 노드가 가질 수 있는 자녀 노드 수는 2~5개 입니다 🔸22:01 마찬가지로, root 노드는 M차에 따른 최소 조건이 없고, B tree 자체의 최소 조건만 있기 때문에, root 노드에서는 최소 한 개의 데이터를 가져야 합니다 그러므로 root 노드가 가질 수 있는 데이터 수는 1~4개 입니다 🔸33:28 B tree는 그 자체로 이미 m이라는 파라미터가 있기 때문에, 이 파라미터를 사용해서 block 단위로 데이터를 꽉꽉 채워서 스토리지에 저장할 수 있도록 튜닝하는 것이 가능하지만, self-balancing BST tree는 이런 파라미터가 없기 때문에, tree의 노드들을 어떻게 최대한 알차게 block 단위로 채워서 저장할지는 BST tree 자체의 개념이나 특징과는 전혀 상관 없는 별개의 이슈가 됩니다 그래서 이런 측면에서도 B tree를 db index로 사용하는게 더 적절하다고 볼 수 있죠
크ㅠㅠ 응원의 메시지 감사합니다 :) 계속해서 꾸준히 영상을 올리고, 애청자 분들께서도 지금처럼 계속 응원해 주신다면, 전체적으로 개발자 생태계도 기본기에 더 많은 관심을 가지는 분위기가 형성될 거라고 믿습니다 함께 좋은 분위기를 만들어 갈 수 있으면 좋겠네요 😊 응원의 메시지 정말 감사합니다 👍👍👍
빌드업, 시각자료, 강의력 모두 정말 완벽하네요. 너무 감사합니다. 강의 내용 간략하게 정리해봤습니다. - DB Index 에서 B+Tree를 사용하는 이유 B+Tree, AVL Tree, Red-Black Tree 모두 워스트 케이스에 대한 O(logN)를 보장한다. 같은 시간복잡도를 제공함에도 DB Index에 굳이 B+Tree를 사용하는 이유는 다음과 같다. DB에서 다루는 데이터는 모두 SSD, HDD 같은 Secondary Storage에 저장된다. (휘발되어서는 안 되는 중요한 데이터이기 때문 + 용량 문제) Memory 상에 필요한 데이터가 없다면 반드시 Secondary Storage에 접근해서 가져와야 한다. 하지만 Secondary Storage 는 속도가 느린 저장장치이기 때문에 Secondary Storage 에 대한 접근 횟수를 줄이는 것이 성능 향상을 위한 길이다. BST 기반의 Tree들이 한 노드에 하나의 값만을 갖는 것에 비해 B+Tree는 하나의 노드에 여러 값을 가질 수 있다. 즉, 한 번의 접근으로 더 많은 값들에 대한 조회가 가능하기 때문에 Secondary Storage 접근 횟수를 줄일 수 있다. 또한 데이터 조회 시 Block 단위로 읽어오는 저장장치의 특성 상 연관된 데이터를 최대한 모아서 저장해놓는 것이 더 효율적이다. B+Tree의 한 노드 안에서는 물리적으로 연속된 공간에 데이터들이 저장되기 때문에 Block 단위의 조회에서 더 많은 유효데이터를 가져올 수 있다.
M을 계속 키우면 seconday storage에 접근하는 횟수를 계속 줄일 수 있을텐데, 그러면 메모리에 로드되는 key 수, 자식노드 포인터 수, 데이터 포인터 수도 M이 증가한만큼 커질테니 점유하는 메모리 크기도 늘어나겠네요? M을 증가시키는게 시간적으론 좋지만 메모리 공간면에서는 안좋다고 볼 수 있는건가요?
안녕하세요! 영상 감사합니다! 영상 10:35 를 보면 Secondary storage에 block단위로 읽고 쓴다고 설명하셨는데, 읽는 부분은 와닿지만 사실 쓰는 부분은 잘 와닿지 않는데, 혹시 이 부분도 설명가능할까요? 4KB블락을 사용한다고 가정했을 때, 0.5KB만 쓰면 될 때, 4KB블락으로 쓴다는 의미가 되는 건가요? 근데 그렇다면, 읽을때 실제로는 데이터가 0.5KB밖에 없는데 4KB를 읽는게 되는 것 같아서 효율적인 것 같지가 않습니다!
넵~ write할 때도 마찬가지로 동작하며, 그래서 말씀하신 것처럼 스토리지 공간의 일부 낭비가 발생할 수 있습니다~ 그런데 그러면 이건 무조건 비효율적이냐라고 하면 꼭 그렇다고 볼 수는 없는게, 반대로 크기가 큰 사이즈의 파일을 읽고 쓰는 경우에는 block size가 작으면 오히려 손해가 발생할 수 있습니다 왜냐하면 I/O 작업을 할 때 마다 해당 작업을 위한 overhead가 늘 존재하는데, block size가 작으면 사이즈가 큰 파일을 읽거나 쓸 때 더 많은 I/O 작업이 발생하게 돼서 (왜냐하면 블락 단위로 움직이기 때문에), 그만큼 overhead도 더 많아지게 되겠죠 그리고 각 block에 대한 상태 정보도 스토리지 공간 어딘가에 저장될 것이기 때문에 block size가 작을수록 이런 메타 정보를 저장하는데 사용되는 용량도 더 늘어나게 될 겁니다 이외에도 스토리지의 하드웨어적인 한계나 구조 등의 이유로 일정 사이즈 단위로 읽고 쓸 수 밖에 없는 특징들도 있고요 그래서 저장되는 파일들의 대부분의 크기가 어느 정도인지에 따라 적절하게 block size를 조정하기도 합니다 ---- 사실 이것 외에도 자세히 설명하려면 설명할 것들이 너무 많기 때문에, 영상 마지막에 말씀드린 것처럼 많은 부분을 생략을 했었습니다 더 깊게 이해하려면 실제로 스토리지(HDD, SSD)의 구조와 특징도 같이 봐야하고 스토리지 공간을 더 잘 활용하기 위해 block suballocation이라는 개념도 살펴봐야 합니다 그런데 이렇게까지 deep하게 하기에는 저도 더 많은 시간과 노력이 필요하고 그리고 영상의 핵심 내용은 아니었기 때문에 최대한 간략하게 설명을 드리게 됐어요 :)
엄청난 도움이 됬습니다! 궁금한 점이 있어서 여쭤봅니다. 1. multicolumn Index를 경우에 b-tree에서 key가 어떻게 구성되는지 궁금합니다. 2. 문자열에 대한 인덱스가 어떻게 동작하는지도 궁금합니다. 예를 들어 name varchar에 대한 columns이 인덱스여도 contain같은 경우는 full scan을 하게 되는가요? 정렬이기 때문에 크기비교만을 수행하나요?
영상 좋게 봐주셔서 감사합니다 :) 1. 구체적인 구현은 DB마다 다르겠지만, multicolumn index를 만들 때 지정해준 column 순서대로 B tree 내에서 정렬된다고 보시면 되겠습니다~ 즉, 지정된 column들을 노드의 key에 모두 저장은 하는데, 이때 인덱스를 만들 때 지정한 컬럼 순서대로 key들이 비교연산을 하면서 b tree에 저장된다고 보시면 될 것 같아요~ 2. 이 경우에는 완전 비교 연산 (=) 일 경우에는 문자열 비교 연산을 통해 정확히 매칭되는 것을 찾고요, 그게 아니라 like와 %를 통해 내가 찾으려는 문자(열)을 포함한 문자열을 찾을 경우 full scan을 하게 됩니다 하지만 이 경우에도 처음부터 중간부분까지를 포함하는 문자열을 찾는 경우(즉, prefix matching의 경우)에는 인덱스를 탈 수 있는데요, 이건 제가 간결하게 잘 설명하기가 쉽지 않아서 이정도로 마무리를 하겠습니다 :)
몇 가지 코멘트 남깁니다
🔸이 영상은 마지막 3부 영상입니다
1부 : B tree 개념과 특징, 데이터 삽입 (th-cam.com/video/bqkcoSm_rCs/w-d-xo.html)
2부 : 데이터 삭제 (th-cam.com/video/H_u28u0usjA/w-d-xo.html)
3부 : 왜 DB 인덱스에 B tree 계열이 사용되는가
🔸데이터베이스의 의미
데이터베이스는 실제 데이터 그 자체 뿐만 아니라 관련 인덱스(index), 메타 데이터 등등을 모두 포함하는 개념입니다
🔸00:57
시간 복잡도에서 best case는 따로 언급하지 않았습니다
왜냐하면 보통, 평균이나 최악의 케이스일 때 시간 복잡도가 어느 정도인지를 더 궁금해 하기도 하고, 화면에 쓸 공간도 부족해서 생략했습니다
🔸01:53
O(logN)이라는 것은 (쉽게 설명하면) 데이터를 조회/삽입/삭제 할 때 최대 logN 만큼 확인해야한다는 의미가 되기 때문에 O(N)보다 성능이 좋다고 말할 수 있습니다
🔸05:14
비휘발성(non-volatile) 메모리도 존재하긴 합니다
하지만 우리가 보통 RAM이라고 할 때는 휘발성(volatile) 메모리라고 보시면 됩니다
🔸06:46
memory DB도 있습니다
일반적으로 데이터베이스는 secondary storage에 저장되지만 더 빠른 속도를 위해서 main memory에 데이터를 저장하는 memory db도 있습니다
🔸07:08
RAM, SSD, HDD의 속도 비교는 다나와에 들어가서 요즘 잘 팔리는 제품군들 위주로 비교해서 어림잡아 작성한 내용입니다
그렇기 때문에 정확한 수치로 보기보다는 전체적인 차이를 비교하는 목적으로 봐주시면 되겠습니다
🔸11:11
‘핵심이 되는 데이터’라고 표현했지만 조금 더 정확히는 ‘핵심이 되는 데이터 + 자주 쓰이는 데이터’라고 봐주시면 될 것 같습니다
그래서 자주 쓰는 데이터는 메모리에 올려 두고, 그게 아닌 데이터들은 기본적으로 secondary storage에 뒀다가 필요하면 메모리로 올리는 식으로 동작하게 됩니다
🔸20:28
root 노드는 M차에 따른 최소 조건이 없고, B tree 자체의 최소 조건만 있기 때문에, root 모드에서는 최소 두 개의 자녀도를 가져야 합니다
그러므로 root 노드가 가질 수 있는 자녀 노드 수는 2~5개 입니다
🔸22:01
마찬가지로, root 노드는 M차에 따른 최소 조건이 없고, B tree 자체의 최소 조건만 있기 때문에, root 노드에서는 최소 한 개의 데이터를 가져야 합니다
그러므로 root 노드가 가질 수 있는 데이터 수는 1~4개 입니다
🔸33:28
B tree는 그 자체로 이미 m이라는 파라미터가 있기 때문에, 이 파라미터를 사용해서 block 단위로 데이터를 꽉꽉 채워서 스토리지에 저장할 수 있도록 튜닝하는 것이 가능하지만,
self-balancing BST tree는 이런 파라미터가 없기 때문에, tree의 노드들을 어떻게 최대한 알차게 block 단위로 채워서 저장할지는 BST tree 자체의 개념이나 특징과는 전혀 상관 없는 별개의 이슈가 됩니다
그래서 이런 측면에서도 B tree를 db index로 사용하는게 더 적절하다고 볼 수 있죠
DB 인덱스 공부하다가 해당 시리즈 보고 정말 도움많이 얻었습니다. 구체적인 예시로 잘 설명해주셔서 B-tree가 무엇인지 잘 이해되었어요. 남은 것은 제가 스스로 알고리즘을 구현하며 이해하는 것이겠죠. 크진 않지만 꾸준히 후원하겠습니다 감사합니다.
와 ㅠㅠㅠ 댓글 남겨주시는 것만으로도 마음이 뿌듯해지고 큰 힘이 되는데 슈퍼땡스까지!!! 정말 정말 감사합니다!!ㅠㅠ seul님께서는 머지않아 훌륭한 개발자로 성장하셔서 엄청 활약하실 것 같아요 🥳 그때까지 저도 좋은 영상들로 계속 응원하겠습니다 :)
쉬운 코드님의 강의는 정말 듣는 사람을 위한 배려가 돋보이는 강의네요
어떻게 하면 사람들이 쉽게 이해할 수 있을까, 듣다보면 어떤 의문점이 있을까 고민하고 준비하신 흔적들이 보이는 것 같아요
질 좋은 강의 영상 감사합니다!
기가 막히는 설명입니다 아주 좋아요 감사합니다
헤헤 칭찬의 말씀 감사합니다 :)
후원 처음해보네요ㅎㅎ정말 감사합니다~~
우와 ㅠㅠㅠ 정말 감사합니다!! 최초 후원의 영광을 제게 안겨주시다니..!! 진짜 정말 감사하고 기분도 좋고 힘도 나고 그렇습니다 ㅎㅎ 😍
앞으로도 꾸준히 좋은 영상으로 저도 응원할게요~! :)
이렇게 이해가 잘되는걸 보니, 강의 하시는 분의 지식의 깊이가 얼마나 깊을지 상상도 안되네요. 좋은 강의 감사합니다!
내용을 다루기전에 내가 무엇을 얻는지에 대하여 말해주니깐 시청을 다하고 정리하기가 참 좋은것같습니다! 늘 고생하십니다 ㅎㅎ
크 👍 알아봐 주셔서 감사합니다~!! 응원의 메시지 덕분에 저도 더 힘이 나네요~! 감사합니다 :)
유튜브에서 이런 퀄리티의 영상을 볼 수 있는 것에 정말 감사합니다. 조회수가 더 높아져서 쉬운코드님이 영상 만드는데 더욱 힘이 나셨으면 좋겠네요
크ㅠㅠ 응원의 메시지 감사합니다 :)
계속해서 꾸준히 영상을 올리고, 애청자 분들께서도 지금처럼 계속 응원해 주신다면, 전체적으로 개발자 생태계도 기본기에 더 많은 관심을 가지는 분위기가 형성될 거라고 믿습니다
함께 좋은 분위기를 만들어 갈 수 있으면 좋겠네요 😊
응원의 메시지 정말 감사합니다 👍👍👍
스크립트와 애니메이션이 딱딱 맞아떨어지는게 강의 준비를 엄청 준비하고 찍으시는게 많이 느껴집니다.... 애니메이션까지 있어서 이해하기 정말 편하하고요 정말 잘 들었습니다 !!
제가 유튜브 영상에 좋아요 거의 안누르는데 이 영상은 정말 좋아서 좋아요를 누릅니다.
특히 왜 DB 인덱스에 이진트리가 아닌 B트리를 사용하는지 컴퓨터 구조와 함께 설명해주는 부분이 다른데서는 들을 수 없는 아주 유익한 정보였습니다. 감사합니다.
우앙 ㅠㅠㅠ 영상 좋게 봐주셔서 넘넘 감사합니다! 정말 열심히 준비한 영상이었는데 도움이 된 것 같아서 뿌듯하네요 ❤️
와,,,진짜 진짜 감탄하고갑니다. 아래 코멘트까지 너무 좋네요, 덕분에 왜 B tree를 사용하는지 확실히 알게 됐습니다!! 자료구조랑 알고리즘도 괜히 나온게 아니네요 ㅎㅎ.. 강의 너무 감사합니다!
헤헿 영상들 유익하게 봐주셔서 정말 정말 감사합니다~!! 늘 꾸준히 달리시는 모습 최고십니다!! 👍
너무 유익합니다~!! 쵝오😍😍 정말 엄청난 강의력에 무릎을 탁 치고 갑니다!
와우! 칭찬의 말씀 정말 감사합니다!! 😄😄
너무 잘 보았습니다🥰🥰 이해가 잘 되네용
와 진짜 도움많이 됐습니다. 기억에 남길려면 자주 다시 봐야될거같아요
좋은 강의 감사합니다^^ 이해가 쏙쏙 잘되네요
와 너무 잘이해했어요 avl트리랑 b트리랑 비교하는 부분너무 짱! 이해가 완전잘됬슴니당 스승님으로 모시고싶습니다
영상 좋게 봐주셔서 넘넘 감사합니다 :) ㅎㅎ 스승님은 조금 쑥쓰럽지만 (헤헿) 쉬운코드 채널에서 앞으로도 소통 많이 해요 ❤️
정말 좋은 도움이 많이 되었습니다
DB 를 CS 중에 제일 좋아하는데 더 좋아하게 되었어요
최고입니다
감사합니다! :)
좋은 강의 감사합니다 :)
확실히 운영체제와 자료구조에대해 공부를 하고 오니깐 더 이해가 잘되네요 확실히 이해하고 갑니다!
진짜 최고에요~
!! 감사합니다.ㅎ
정말 설명 잟하십니다. 최고🎉
칭찬 감사합니다~!!! 이해하기 쉽게 설명하려고 정말 많은 노력과 편집(?)이 들어갔는데 좋은 피드백 주셔서 기분이 좋네요 ㅎㅎ✌
빌드업, 시각자료, 강의력 모두 정말 완벽하네요. 너무 감사합니다.
강의 내용 간략하게 정리해봤습니다.
- DB Index 에서 B+Tree를 사용하는 이유
B+Tree, AVL Tree, Red-Black Tree 모두 워스트 케이스에 대한 O(logN)를 보장한다.
같은 시간복잡도를 제공함에도 DB Index에 굳이 B+Tree를 사용하는 이유는 다음과 같다.
DB에서 다루는 데이터는 모두 SSD, HDD 같은 Secondary Storage에 저장된다.
(휘발되어서는 안 되는 중요한 데이터이기 때문 + 용량 문제)
Memory 상에 필요한 데이터가 없다면 반드시 Secondary Storage에 접근해서 가져와야 한다.
하지만 Secondary Storage 는 속도가 느린 저장장치이기 때문에 Secondary Storage 에 대한 접근 횟수를 줄이는 것이 성능 향상을 위한 길이다.
BST 기반의 Tree들이 한 노드에 하나의 값만을 갖는 것에 비해 B+Tree는 하나의 노드에 여러 값을 가질 수 있다.
즉, 한 번의 접근으로 더 많은 값들에 대한 조회가 가능하기 때문에 Secondary Storage 접근 횟수를 줄일 수 있다.
또한 데이터 조회 시 Block 단위로 읽어오는 저장장치의 특성 상 연관된 데이터를 최대한 모아서 저장해놓는 것이 더 효율적이다.
B+Tree의 한 노드 안에서는 물리적으로 연속된 공간에 데이터들이 저장되기 때문에 Block 단위의 조회에서 더 많은 유효데이터를 가져올 수 있다.
우와우 엄청난 요악이네요!! 👍👍👍
감사합니다.ㅠㅠ👍👍👍
와!!! 정말 설명 잘하시네요👍👍 늘 응원합니다!!!
헤헤 칭찬과 응원의 말씀 정말 감사합니다 :) 파이팅할게요!! 👍👍👍
정말 좋은 강의 감사합니다. 지식을 전달하기 위해 개념을 재구성하는것이 얼마나 시간이 많이 들어가는지 잘 알고 있습니다.
항상 잘 배우고 갑니다. 진심으로 감사인사를 드립니다.
알아봐 주셔서 감사합니다 ㅠㅠ 이런 응원의 메시지 덕분에 저도 힘을 얻고 계속해서 꾸준히 할 수 있는 것 같아요 :)
컴퓨터구조 관점에서 설명하니 왜 B tree 를 사용하는지 이해가 바로 되네요... 좋은 영상 정말 감사합니다
영상을 유익하게 봐주셔서 감사합니다 :)
1주 뒤에 면접이 잡혀서 면접준비하는데 너무 유익하게 보고있습니다 감사합니다
헤헿 채널 영상을 유익하게 봐주셔서 정말 감사합니다 :)
면접 대박나셔서 꼭 원하시는 결과 얻으시길 응원할게요~! 👍
진짜 진짜 감사합니다 !!!!!!
저도 B tree 3부작 다 봐주셔서 감사합니다 👍
이런 저런 수치를 계산해서 복잡하게 했지만, 빅오 표기법의 한계를 보여준거죠. 모든 데이터가 이미 메모리에 올라와있었다고 가정해도, 로그의 밑이 달라지게 되서 b 트리가 더 효율적이다 라는 설명이 더 맞는거 같아요.
미쳤습니다...
감사합니다! 👍
와 B-Tree 책에서 읽고 그럼 왜 java TreeMap에서는 Red-Black Tree를 사용하는데 차이가 뭐지 궁금했었는데 딱 맞는 주제네요 감사합니다 !
진짜 많은 조회수 적은게 이해가 안가네요ㅎㅎ
영상 길이 때문일 가능성이 높을까...진짜 퀄리티 높은데요
광고 많이 넣어주세요~~
크ㅠㅠ 감사합니다 이런 응원의 메시지 덕분에 제가 또 힘을 낼 수가 있습죠 ㅠㅠ 👍
파이팅하겠습니다!!! 💪
헉헉~~!! DB 끝난 줄 알았었는데, 영상이 4개가 더 추가가 돼 있었더군요.. 하루 걸쳐서 재완강!!!
글고, 몸 관리 잘 하셔여~~^^
몸이 아프면 머리도 안 돌아고, 하는 일의 결과의 퀄리티가 매우 낮아져요 ㅠㅠ
앜ㅋㅋ B tree 자료 구조 하면서 이것도 DB 재생목록에 넣으면 좋겠다는 생각이 들어서 추가가 됐어요~ 재완강 멋지십니다!!
걱정해주셔서 감사해요 ㅠㅠ 진짜 말씀하신 것처럼 이게 몸이 안좋으니 전반적인 퀄리티가 떨어지네요 ㅠㅠ
건강 잘 지키겠습니다 👍
이제 왜 DB에 B-Tree가 사용되는지 확실히 이해했습니다. 면접에서 나오면 확실히 설명할 수 있겠네요 ㅎㅎ
다음번엔 면접관으로서 이런 질문해 보시겠네요 ㅎㅎ 👍
고고씽~
레전드 오브 레전드
모 회사 면접 보기전에 이거 봤으면 더 잘 대답했을 것 같은데 ㅜㅜㅜ. 꼭 가고 싶은 회사였는데 아쉽네요
디스크에서의 데이터 엑세스는 바이트 단위가 아니라 블럭 단위로 수행되기 때문에 랜덤 액세스, 포인터 연산이 굉장히 비싸다.
알고리즘의 시간복잡도는 일반적으로 포인터 연산의 수행속도가 상수시간으로 일정하다는 RAM 환경을 가정하고 이야기하는 것.
정리가 깔끔보스네요 👍👍👍
이런강의를 유튜브에서 공짜로 볼 수 있다니.... 감사합니다 ㄷㄷㄷㄷ
b tree 관련 1부와 2부가 데이터베이스 재생목록에 누락되어 있는것 같습니다..!
취업준비중인 비전공자로서 cs 지식 학습에 큰 도움이 되는것 같습니다. 감사합니다.
오 피드백 감사합니다~!
사실 데이터베이스 재생목록에서는 일부러 3부만 올린 거였긴 한데요
피드백 받고 보니 1부, 2부도 다 같이 올리는 게 좋을 것 같네요 :)
수정해 놓겠습니다~ 의견 감사드려요 👍
네트워크인강 언제나오나요?
죄송합니다! 한동안 여러 이유들로 업로드가 늦었습니다 ㅠ
오늘 네트워크 입문 영상 촬영 예정입니다
최대한 신속히 올릴게요~!
M을 계속 키우면 seconday storage에 접근하는 횟수를 계속 줄일 수 있을텐데, 그러면 메모리에 로드되는 key 수, 자식노드 포인터 수, 데이터 포인터 수도 M이 증가한만큼 커질테니 점유하는 메모리 크기도 늘어나겠네요? M을 증가시키는게 시간적으론 좋지만 메모리 공간면에서는 안좋다고 볼 수 있는건가요?
안녕하세요! 영상 감사합니다!
영상 10:35 를 보면
Secondary storage에 block단위로 읽고 쓴다고 설명하셨는데, 읽는 부분은 와닿지만 사실 쓰는 부분은 잘 와닿지 않는데, 혹시 이 부분도 설명가능할까요?
4KB블락을 사용한다고 가정했을 때,
0.5KB만 쓰면 될 때, 4KB블락으로 쓴다는 의미가 되는 건가요? 근데 그렇다면, 읽을때 실제로는 데이터가 0.5KB밖에 없는데 4KB를 읽는게 되는 것 같아서 효율적인 것 같지가 않습니다!
넵~ write할 때도 마찬가지로 동작하며, 그래서 말씀하신 것처럼 스토리지 공간의 일부 낭비가 발생할 수 있습니다~
그런데 그러면 이건 무조건 비효율적이냐라고 하면 꼭 그렇다고 볼 수는 없는게,
반대로 크기가 큰 사이즈의 파일을 읽고 쓰는 경우에는 block size가 작으면 오히려 손해가 발생할 수 있습니다
왜냐하면 I/O 작업을 할 때 마다 해당 작업을 위한 overhead가 늘 존재하는데, block size가 작으면 사이즈가 큰 파일을 읽거나 쓸 때 더 많은 I/O 작업이 발생하게 돼서 (왜냐하면 블락 단위로 움직이기 때문에), 그만큼 overhead도 더 많아지게 되겠죠
그리고 각 block에 대한 상태 정보도 스토리지 공간 어딘가에 저장될 것이기 때문에 block size가 작을수록 이런 메타 정보를 저장하는데 사용되는 용량도 더 늘어나게 될 겁니다
이외에도 스토리지의 하드웨어적인 한계나 구조 등의 이유로 일정 사이즈 단위로 읽고 쓸 수 밖에 없는 특징들도 있고요
그래서 저장되는 파일들의 대부분의 크기가 어느 정도인지에 따라 적절하게 block size를 조정하기도 합니다
----
사실 이것 외에도 자세히 설명하려면 설명할 것들이 너무 많기 때문에, 영상 마지막에 말씀드린 것처럼 많은 부분을 생략을 했었습니다
더 깊게 이해하려면 실제로 스토리지(HDD, SSD)의 구조와 특징도 같이 봐야하고
스토리지 공간을 더 잘 활용하기 위해 block suballocation이라는 개념도 살펴봐야 합니다
그런데 이렇게까지 deep하게 하기에는 저도 더 많은 시간과 노력이 필요하고
그리고 영상의 핵심 내용은 아니었기 때문에 최대한 간략하게 설명을 드리게 됐어요 :)
감사합니당 혹시 101차 예시 드실때 레벨 3까지 하셨는데, 이건 예시로 3까지만 한 것일까요?
아니면 101차면 무조건 레벨3까지다 이런건 없는걸까요
네 맞습니다 지면 관계상 예시로 3차까지만 한 거예요 :) 따로 레벨 제한이나 이런건 없습니다
엄청난 도움이 됬습니다!
궁금한 점이 있어서 여쭤봅니다.
1. multicolumn Index를 경우에 b-tree에서 key가 어떻게 구성되는지 궁금합니다.
2. 문자열에 대한 인덱스가 어떻게 동작하는지도 궁금합니다. 예를 들어 name varchar에 대한 columns이 인덱스여도 contain같은 경우는 full scan을 하게 되는가요? 정렬이기 때문에 크기비교만을 수행하나요?
영상 좋게 봐주셔서 감사합니다 :)
1. 구체적인 구현은 DB마다 다르겠지만, multicolumn index를 만들 때 지정해준 column 순서대로 B tree 내에서 정렬된다고 보시면 되겠습니다~ 즉, 지정된 column들을 노드의 key에 모두 저장은 하는데, 이때 인덱스를 만들 때 지정한 컬럼 순서대로 key들이 비교연산을 하면서 b tree에 저장된다고 보시면 될 것 같아요~
2. 이 경우에는 완전 비교 연산 (=) 일 경우에는 문자열 비교 연산을 통해 정확히 매칭되는 것을 찾고요, 그게 아니라 like와 %를 통해 내가 찾으려는 문자(열)을 포함한 문자열을 찾을 경우 full scan을 하게 됩니다
하지만 이 경우에도 처음부터 중간부분까지를 포함하는 문자열을 찾는 경우(즉, prefix matching의 경우)에는 인덱스를 탈 수 있는데요, 이건 제가 간결하게 잘 설명하기가 쉽지 않아서 이정도로 마무리를 하겠습니다 :)
너무 좋은 공부 됐습니다. 감사합니다 !