코멘트 몇가지 남깁니다~ 🔸03:43 일단 그 row 자체를 다 읽어오는 이유는 RDB가 row 단위로 저장되기 때문에 그렇습니다 참고로 Columnar DBMS의 경우에는 column 단위로 저장하기 때문에 필요한 column만 읽어올 수 있어서 I/O 측면에서 보다 효율적으로 동작하게 됩니다 🔸12:30 horizontal partitioning을 설명하는 이 예제는, 본래 목적은 하나의 테이블일 때와 두 개의 테이블로 파티셔닝이 됐을 때 어떻게 다른지를 보여주기 위한 목적입니다 즉, 원래 있던 테이블을 새로운 두 개의 테이블로 나누는 과정을 설명하는 것은 아닙니다. (참고로, 실제로 서비스에서 이미 사용중인 테이블을 파티셔닝 하는 것은 매우 까다로운 작업입니다) 🔸sharding : 실제 제 개인적으로 실무에서 샤딩을 경험했을 때 트래픽이 많은 테이블의 부하를 분산시키는데는 확실히 탁월한 효과가 있었습니다 🔸replication은 DB 서버 구성할 때 거의 기본이라고 보셔도 괜찮습니다. 저도 실무에서 당연히 사용 경험이 있습니다 🔸21:03 여기서는 slave(= secondary) 서버가 여러 개 있을 수 있다라고 강조했지만, repliation의 구성 방법에 따라서는 master(primary) 서버도 여러개가 존재할 수 있습니다 🔸21:28 이제 이 상황에서는 두 서버의 primary/secondary 역할이 바뀌게 됩니다 🔸partitioning, sharding, replication 개념은 동일하거나 유사한 형태로 noSQL 에서도 적용될 수 있는 개념입니다

너무 잘 봤습니다. 감사합니다🥰

매번 잘 보고 있습니다 감사합니다

쉬운 설명감사합니다 선생님~!

좋은 영상 잘 보았습니다. 감사합니다

좋은 강의 감사합니다 :)

항상 좋은 영상 감사합니다!

@ez.

Жыл бұрын

늘 애청해 주셔서 감사합니다! :)

한 번에 정리 잘 해주셔서 이해가 잘 되네요 ㅎㅎㅎ

@ez.

Жыл бұрын

헤헤 다행입니다~! 좋게 봐주셔서 감사해요 :)

사이버 사수님 감사합니다. 새해 복 많이 받으세요

수평 파티셔닝과 샤딩 비교를 해주셔서 기존보다 더 이해가 되었네요 ㅎㅎ 감사합니다

@ez.

Жыл бұрын

영상을 유익하게 봐주셔서 감사합니다 :) 👍

최고십니다 👍

@ez.

Жыл бұрын

AI님은 최최고십니다 👍

ㅠㅠ코멘트까지 너무 감사합니다! 이제 거의 다와가네요!! 덕분에 DB에서 중요한 개념들 잘 공부할 수 있을 것 같습니다. 복습하면서 또 들어야겠어요 ㅎㅎ 항상 응원합니다!!👍🙏

@ez.

Жыл бұрын

크 이렇게 집중력있게 정주행하는 것도 쉽지 않으실텐데 정말 대단하셔요~! 👍 응원합니다 화이팅!!!!

좋은 영상 감사합니다~!

@ez.

Жыл бұрын

좋게 봐주셔서 감사합니다 :)

진짜 레전드네요

지리고 갑니다....

잘봤습니다.

잘보고가요!

@ez.

Жыл бұрын

항상 댓글로 응원해 주셔서 감사해요 ㅠㅠ 👍

이러한 강의는 정말 여러 사람한테 공유되야한다고 봅니다. 많은 회사에서도 레플리카는 aws에서 기본적으로 지원하니깐 쓰지만 파티셔닝이나 샤딩은 쓰는 회사가 많이없어서 무조건 인덱스를 이용해서 성능개선을 하려는 일반화에 갇힌거같습니다. 인덱스는 btree 특성으로 계속 tree 형식으로 뻗쳐서 나가가지고 데이터가 10억이상이면 인덱스를 써도 최고의 성능을 못내는데 말이죠... 정말 유용하고 실무에서 바로 적용할수있는 강의 만들어주셔서 감사합니다.

@ez.

Жыл бұрын

좋게 봐주셔서 감사합니다 😊👍 맞습니다~ 말씀하신 것처럼 DB에 데이터가 몇십억건 정도 되면 아무리 인덱스라도 인덱스 자체의 사이즈도 커지기 때문에 점점 퍼포먼스에 영향을 주게 돼서 다른 방법도 같이 고민해 보는게 좋죠~! 이렇게 같이 시너지 낼 수 있어서 좋으네요 :)

감사합니다

@ez.

Жыл бұрын

댓글 감사합니다 :)

db 내용 많이 다뤄주세요!👍👍

@ez.

Жыл бұрын

넵 :) 항상 재밌게 봐주셔서 감사합니다 👍👍

운영체제, 네트워크, DB, 자료구조 이렇게 모아서 인프런에 강의 내주시면 바로 달려가서 결제하고 보겠습니다 ㅠㅠㅠㅠ 너무 감사합니다 항상 잘 보고 있습니다

@ez.

Жыл бұрын

크 ㅠㅠ 좋게 봐주셔서 정말 감사합니다!! 다음에 기회되면 인프런에 유료 강의도 도전해 보겠습니다!! 👍

추석때도 고고씽

이번에도 잘 보았습니다:) 혹시 파티셔닝, 샤딩, 레플리케이션을 직접 해보려면 어떤 서적이나 레퍼런스를 참고해보면 좋을까요? 새로 입사하게 된 기업의 최종면접때 어떤 부분을 공부해가면 좋을지 여쭤보니, 이중화를 직접 해보고 오면 좋겠다고 하셨었어서요 :)

@ez.

Жыл бұрын

크 ㅠㅠ 항상 애청해 주셔서 정말 감사합니다 👍 그리고 새로운 회사에 입사도 정말 축하드려요!!! 그곳에서 많은 행복한 시간들과 건강한 성장이 있길 응원하겠습니다 :) 🙏 저같은 경우에는 서적을 보기보다는 다른 분들이 정리해 놓은 자료 + 공식 문서를 참고해서 많이 했었어요 구글링 하면 여러 좋은 자료들이 많더라고요 (특히 영어 자료는 정말 방대합니다) AWS 같은 클라우드에서 무료로 서버 몇 대 받아서 회사에서 쓰는 DBMS로 설치하고 replication 구성까지 해보시고 그 다음 백엔드 서버와 연결해보고, 일부러 primary DB 인스턴스 kill해서 failover가 잘 일어나는지 그때 최대한 백엔드 서버가 문제 없이 동작하는지 등등 위주로 확인해보시면 (물론 중간 중간 막히는 부분들이 있겠지만ㅠㅠ) 아마 스스로에게도 도움도 많이 되고 회사에 계신 분들도 좋아하시지 않을까 싶어요~ 그럼 화이팅이십니다!! 💪

@user-te2ty2oz8x

Жыл бұрын

@@ez. 축하해주셔서 감사드립니다☺️☺️ 일부러 primary 를 킬하는건 전혀 고려하지 않고 있었는데, DR이 잘 되는지를 보려면 그렇게 하는게 좋겠네요!!! 말씀해주신대로 레퍼런스 잘 찾아보고 해보도록 하겠습니다 ㅎㅎ 상세한 답글 정말 감사드려요 !!

@ez.

Жыл бұрын

저도 항상 영상 봐주셔서 감사해요 :) 오늘도 기분 좋은 하루 되세요~!! 😄😄

현재 시점, DB 정주행 완료!! 헉헉

@ez.

Жыл бұрын

와 대박!!!ㅎ 정주행 최고십니다!!

replication의 경우 'A' 라는 db의 'a-1' table 정보를 'B '라는 db의 'a-1' table에도 동일하게 저장하는 방식으로 이해를 했는데, 만약 'A' db의 'a-1' table이 기존에 sharding이 된 테이블인 경우 replication이 어떤식으로 동작하게 되는지 알수있을까요? 훌륭한 강의 감사합니다~!

안녕하세요. 좋은 영상 감사합니다. 질문이 몇가지가 있습니다. 1. Replication에서 장애가 발생하여 primary가 죽으면 대기중인 secondary가 primary로 바뀌는건가요? 아니면 primary, secondary 개념은 그대로고 secondary가 primary 역할을 하게 되는건가요? 2. 고가용성이라 해도 read/write가 primary에서 secondary로 옮겨갈 때 사용자의 입장에서 장애를 느낄 수가 있나요?

@ben-hn5vl

Жыл бұрын

db내용 다뤄주시는거 너무 좋습니다 ㅎㅎ

@ez.

Жыл бұрын

흐흐 항상 유익하게 봐주셔서 정말 감사합니다 :) 1. 말씀하신 것처럼 secondary와 primary의 역할이 바뀌게 됩니다 2. 문제가 감지되면 진행되는 것이 fail over이기 때문에 일단 일부 기능은 정상적으로 동작하지 않아 일부 사용자는 장애를 느꼈을 수도 있습니다 하지만 fail over가 빠르게 일어나기 때문에 (제 직간접적인 경험으로는 빠르면 수초가 걸렸고 보통은 1분 이내 였습니다) 대부분의 사용자들은 일시적으로 잠시 문제가 생겼다 정도 수준으로 인지되지 않을까 싶어요 만약 백엔드 아키텍처를 견고하게 잘 설계 했다면 DB 앞 단에 캐시(cache)도 있을거고 리트라이 로직도 있을 수 있으니 이런 것들까지 고려하면 사용자들의 일부가 잠깐동안 '동작이 이상하네' 수준으로 느끼지 않을까 싶어요

@ben-hn5vl

Жыл бұрын

자세한 답변 감사합니다!!

@ez.

Жыл бұрын

@@ben-hn5vl 오늘도 화이팅이에요!!

수평 파티셔닝에 대한 질문 하나 드리고 싶습니다. 1. partition_key 컬럼과 index 컬럼을 같은 것으로 둘 수 있나요? 2. 파티셔닝 된 두 테이블이 존재할 때 인덱스를 구성하는 B+Tree 역시 두개로 존재하게 되나요? 조회 조건에 partition_key 가 포함되지 않고 다른 index 는 포함되었다고 할 때, 이런 경우에서는 subscription_0 의 index B+Tree 조회, subscription_1 의 index B+Tree 조회 후 두 결과를 합쳐서 최종 결과를 보여주는 식으로 작동하나요? 3. 만약 범위 기반 검색을 하려고 한다면 이러한 경우에는 파티셔닝 때문에 조회 속도가 더 느려질 수도 있을 것이라는 생각이 드는데.. 타당한 유추일까요? (그럼에도 불구하고 파티셔닝으로 얻는 이점이 더 크기에 사용하는 것이겠죠?) 강의들 잘 보고 있습니다. 감사합니다 !

@ez.

Жыл бұрын

제가 다른 분들 댓글도 답을 드리고 있어서, 시간 관계상 일부만 답변을 드릴게요 ㅠㅠ >> 1. partition_key 컬럼과 index 컬럼을 같은 것으로 둘 수 있나요? 네, partition key는 말 그대로 파티션된 테이블들 중에 하나를 찾아가기 위한 목적으로 사용되기 때문에 인덱스와는 전혀 독립적으로, 별개로 보시면 됩니다 >> 2. 파티셔닝 된 두 테이블이 존재할 때 인덱스를 구성하는 B+Tree 역시 두개로 존재하게 되나요? 두 개의 테이블로 수평 파티셔닝 하셨다면, 각 테이블 마다 인덱스를 걸어줘야 합니다. 그러면 각 테이블 마다 B+Tree 기반의 인덱스가 생깁니다

@user-tl8ji9os1y

Жыл бұрын

아. 인덱스가 걸려있는 상태에서 수평파티션을 걸면 자동으로 인덱스도 따로따로 생기는 게 아니라 애초에 파티셔닝 된 각 테이블에 인덱스를 따로따로 걸어주는 거군요. 감사합니다!!

수평 파티셔닝 하면 똑같은 컬럼의 스키마를 여러개 만들어서 사용하는거죠 ?? 그럼 create table로 만들고 보통 _0, _1, _2 이렇게 번호를 붙여서 사용하나요 ?? 만약 100만건 넘는 데이터가 있는데 파티셔닝 한다면 스키마를 새로 만들고 기존 데이터를 파티셔닝키에 맞춰서 분배 해야 되는건가요 ???

@ez.

Жыл бұрын

네이밍을 어떻게 하는지는 팀 별로 결정할 것 같아요~ 저는 예제를 들기 위해서 _0, _1, _2라고 했지만요~ 그리고 100만건 넘는 데이터를 담고 있는 테이블을 수평 파티셔닝을 한다면, 말씀하신 것처럼 기존 데이트를 파티셔닝 키에 맞춰서 분배해서 저장하는 과정이 필요합니다~ 이게 무중단으로 하려면 제법 까다로운 작업이죠 ㅠ

잘보고 있습니다. user_id를 샤드키로 샤딩을 구성한다고 했을 때 샤드키를 숫자로 하는게 좋을까요 문자열로 하는게 좋을까요 ?

@ez.

Жыл бұрын

user_id를 문자열로 할지 숫자로 할지 말씀이신거죠? 개인적으로는 샤드키의 관점에서 보다는 서비스 구현함에 있어서 user_id를 숫자로 할지 문자열로 할지 생각해 보는게 더 좋지 않을까 싶어요 숫자로 하게 되면 user_id에 대한 보안 측면에서는 그 범위가 명확해지기 때문에 문자열보다 안좋을 수도 있고요

처음 의도적으로 광고 다 봤어요

@ez.

Жыл бұрын

흐엉 ㅠㅠㅠ 정말 감사합니다 ㅠㅠㅠ 👍👍👍

레플리케이션설명 듣다가 질문이 드려요 RAID1 과 방식이 같은거 같은데 동일한건가요??

@ez.

Жыл бұрын

오 네네~ 동일한 데이터를 복사해서 저장한다는 측면에서 컨셉 자체가 동일합니다~