thefarmersfront / helloworld-comment

Kurly Dev Blog Comment Repository
2 stars 1 forks source link

blog/bulk-performance-tuning/ #60

Open utterances-bot opened 1 year ago

utterances-bot commented 1 year ago

BULK 처리 Write에 집중해서 개선해보기 - 컬리 기술 블로그

http://thefarmersfront.github.io/blog/bulk-performance-tuning/

sj602 commented 1 year ago

좋은 글 잘 읽었습니다. 질문이 있는데요,

INSERT INTO member(name, age) VALUES ("name1", 10), ("name2", 20), ("name3", 30);와 같이 bulk insert를 할 때 다른 비즈니스 로직에 의해 insert가 도중에 실행된다면 auto-increment id도 그 연속성이 어긋나는 경우는 없을까요?

dkswnkk commented 1 year ago

안녕하세요! batch insert에 대한 상세한 설명과 고민들 전부 잘 읽었습니다! 저도 sj602 님이 남겨주신 의견과 동일하게 insert 중 다른 insert가 먼저 수행되어버리면 시퀀스를 예측하는 게 불가능하다고 생각되는데 실 환경에서 문제 없을까요..?

문제가 있다면 Write개선2 단점 부분에 이 문제가 추가되면 어떨까 싶습니당

dohankk commented 1 year ago

트랜잭션을 걸어주면 문제 없지 않을까요?

leeseojune53 commented 1 year ago

Transaction을 걸어준다면 걸린 내부의 코드에서 일관성은 유지할 수 있으나, Transaction 외부의 곳에서 저장하여 올라간 auto-increment는 추적하기 어렵기에 Transaction으로 묶어줘도 결국 다른 서비스(UseCase)에서 추가한다면 중복되는 PK가 발생할 수 있을 것 같네요.. 🤔

leeseojune53 commented 1 year ago

UUID와 같은 불규칙적인 ID를 사용하는 부분은 제 짧은 지식으로 잠깐 생각해본결과, UUID와 같은 랜덤값이라면 오히려 괜찮을 수 있겠네요(FK 매핑 케이스에서)

UUID를 Row의 개수만큼 미리 생성해놓고, For문 내에서 가져와서 사용하면 몇 번째 row의 ID인지 알 수 있겠네용 ㅎㅎ

hyunghwan-yu commented 1 year ago

@leeseojune53 @dohankk @dkswnkk @sj602

안녕하세요😄 댓글 감사합니다~! 말씀해주신 내용들은 Transaction과는 크게 관련이 없다고 알고있습니다~ 오히려 mysql의 innodb_autoinc_lock_mode 설정에 연관이 있습니다~!

그리고 해당 예시에만 국한해서 추가 설명을 드리자면 -> innodb_autoinc_lock_mode가 어떤 값이어도 예시에서 사용된 insert ... values (...),(...), ... ;형태는 insert될 row수를 알 수 있기 때문에 (문서에서는 simple inserts라 부릅니다.) 결국 연속된 PK를 보장할 수 있습니다~!

감사합니다 😃🙏🏻

px201226 commented 1 year ago

last_insert_id() 라는게 있었네요. 좋은 글 잘 읽었습니다. 그런데 INSERT INTO … VALUES (…), (…), (…), ... 형태로 쿼리를 날릴 때 데이터가 1000만건 정도되니까 SQL이 너무 길어서 서버에서 OOM이 발생하더라구요. 또, DB의 max_allowed_packet 설정에 따라 쿼리가 안되는 상황도 발생할 수 있을 것 같아요. 참고바랍니다~

violetbeach commented 10 months ago

오우.. 이런 방법이 있었군요~! 👍

Wordbe commented 8 months ago

@hyunghwan-yu 좋은글 감사합니다. last_insert_id() 는 커넥션 단위로 관리된다고 합니다. 참고: mysql docs 그래서 다른 클라이언트에서 insert 가 동시에 발생하여 더 증가된 id 를 받을 일은 없다고 하네요. lock 이나 transaction 을 고려할필요가 없다고 말하고있습니다.

banggeunho commented 7 months ago

우선 좋은 글 잘 읽었습니다!

저도 비슷한 상황을 주문 데이터를 수집하는 배치를 개발하면서 경험한 적이 있었는데요.. 처음에는 형환님처럼 마지막 인서트 PK의 값을 토대로 계산해서 관계를 맺어줬는데, 문득 인서트문에 작성된 데이터들이 순서대로 차곡차곡 디비에 쌓일까? 라는 의문점을 생기더라구요.

여기저기 공식문서나 스택오버플로우를 뒤적 거렸지만 데이터들이 작성된 순서대로 들어간다는 증거(?)는 결국 찾지못해서, 매핑을 위한 해당 작업에 대한 UUID와 Seqence 컬럼을 별도로 만들어 관계를 매핑 시켜주었던 경험이 있습니다.

혹시 인서트문에 적힌 데이터들이 순서대로 들어간다는게 보장받나요?

limwoobin commented 3 days ago

오 좋은글 감사합니다! ㅎㅎ 👍