ID 생성 방법이 다양해서 재밌네요 오늘도 잘 봤습니다! 혹시 녹음 해주실 때 소리를 조금만 더 크게 녹음 해주실 수 있으실까요? (소리가 조금 작은 것 같아서요 ㅠㅠ)

@madvirus

Ай бұрын

아 저도 다시 들어보니까 소리가 작네요. 신경 써 보겠습니다.

항상 좋은 주제로 영상 만들어주셔서 감사합니다 형님 👍

오 최근에 UUIDv7을 분리된 서비스에서 사용한 적이 있어서, 더 재밌게 내용 봤습니다! 👍

항상 궁금하던 내용이었는데 좋은 내용 공유해주셔서 감사합니다👍👍

ID 생성에 대한 개념이 더 명확해졌어요! 감사합니다. 한 가지 궁금한 점이 있는데, RAC의 경우 왜 PK가 시퀀셜하지 않은 건가요? 찾아보니 캐시 관련 내용이 가장 많은데... 정확한 내용을 찾기 어려워 댓글로 질문드려요. 하나의 인스턴스에서 생성된 데이터를 다른 인스턴스에서 공유하는 과정에서 생기는 이슈일까요?

@sseob1169

Ай бұрын

최근에 회사에서 이 문제를 겪었습니다 ㅠ 오라클 RAC 인스턴스환경의 운영DB에서 발생한 케이스인데요 원인은 정확히 모르겠지만, RAC 환경에서 시퀀스 cache size 옵션을 사용하는 경우 시퀀스 순서를 보장할 수 없다고 합니다. 한국 오라클사에서 회사로 세미나 왔었을때에도 그렇게 말씀해주셨습니다. 순서를 보장받고 싶으면 캐시사이즈 옵션을 사용하지 말라고 하더라구요. 뭔가 캐시사이즈에 도달해서 번호가 증가할 때 인스턴스간에 기술적인 문제가 있지 않을까 .. 생각이 드네요 세미나할 때 적어두었던 메모가 있으면 추가로 답글 달아놓겠습니당

@madvirus

Ай бұрын

시퀀스를 1 증가실 때마다 rac 인스턴스끼리 통신하면 성능이 느려질 겁니다. 이런 통신을 줄이기 위해 각 인스턴스마다 생성가능한 시퀀스 범위를 잡아두는거죠. 예를 들어 1번은 1-10, 2번은 11-20 이렇게요.

@setset1393

Ай бұрын

@@madvirus 안 그래도 글을 읽으면서 캐시 사이즈라는 말을 가장 많이 봐서, 여기서의 캐시가 인스턴스당 풀을 잡아놓는 개념일까 생각하고 있었는데 그게 맞군요 ㅎㅎ 그러면 캐시 사이즈 재할당은 어떻게 받나? 하는 생각이 바로 떠오르네요. 찾아봐야겠습니다. 계속해서 시야가 넓어지는 것 같아요. 감사합니다 :)

너무 유익했어요 감사합니다!

시퀀셜을 선택할 경우 서비스의 규모라던가 다른 유저의 아이디를 짐작/예측 가능한것에 비해 uuid 를 선택하는 이유 중에는 보안도 있지요~!

와 !좋은내용 감사합니다 : D

uuid를 id로 왜 쓰는지 이해 못했었는데, db 부하를 줄이는거였군요 ㅎㅎ 궁금한게 있습니다. 처음 소규모때는 sequential하게 쓰다가 대규모가 되면 uuid로 바꾸는 옵션은 비용이 많이 들까용..?

@madvirus

Ай бұрын

uuid는 애초에 문자열이니까 정수 타입 ID를 사용하다가 UUID로 넘어가기는 쉽지 않을 듯 하네요. 오히려 snowflake 류로 넘어가는 게 어떠까 합니다. 그런데 그 정도로 서비스가 성장하면 충분히 돈을 벌고 있지 않을까요?

snowflake 사용시 sequence로 인한 db부하가 없는 이유는 프로세스별로 각자 sequence를 1씩 올리면서 쓰기 때문인거죠? 그리고 초당 프로세스당 400만개인데 오타 있어요

@madvirus

Ай бұрын

아 밀리초니까 400만개죠. 확인 고맙습니다.

잘 봤습니다1 근데 오늘 영상은 소리가 많이 작네요 흑흑

@madvirus

Ай бұрын

아마추어 티가 이렇게 나네요. 다음에는 신경 써 보려고 합니다.

09:28 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

정말 재미있게 잘 봤습니다! 다만 깃헙에 있는 트위터 snowflake는 이제 더이상 지원하지 않나봐요. 알게 되면 댓글 수정하겠습니다, 감사합니다~ 최고~!❤

9:28 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ