기존 레코드 3~4억건, 추가하려는 컬럼은 인덱스 X, int 형 숫자, 기본값 null이라면
컬럼을 추가하는데 발생하는 오버헤드도 상당한가?
내가 아는 어떤 서비스에서 기존 기능을 점검 없이 실시간으로 확장한 사례가 있는데
이러면 컬럼을 직접 추가한게 아니라 테이블만 새로 생성하고 애플리케이션에서 둘을 조인하건 뭘하건 해서 처리했다고 봐야하려나?
기존 레코드 3~4억건, 추가하려는 컬럼은 인덱스 X, int 형 숫자, 기본값 null이라면
컬럼을 추가하는데 발생하는 오버헤드도 상당한가?
내가 아는 어떤 서비스에서 기존 기능을 점검 없이 실시간으로 확장한 사례가 있는데
이러면 컬럼을 직접 추가한게 아니라 테이블만 새로 생성하고 애플리케이션에서 둘을 조인하건 뭘하건 해서 처리했다고 봐야하려나?
online ddl?
스키마를 변경했다면 아마 그걸로 했겠지
그정도면 online ddl 해도 문제없지 않나.
트래픽 좀 있어도 저 정도는 무리없이 수행 가능인가?
레코드갯수가 아니라 그 데이터가 어찌 구성되는지 아는게 더 중요해보이는데 - dc App
nullable에 default없으면 컬럼추가할때 리소스 안씀 - dc App
헉 그런거였나?
mysql은 다를수도 있음 - dc App
채용스펙보니 MYSQL 쓰는거 같던데
mysql많이씀 나는 mssql 밖에 안써봄 그래서 다를수도 있다고 한겨 - dc App
36억건 쌓인 주문 테이블에 컬럼 추가할때 우리 같은 경우는 새로운 컬럼을 가진 테이블을 만들고, 기존 테이블의 테이블 이름을 temp같은거로 바꾸고 새로 추가한 테이블을 원래 테이블 명으로 추가하고 그 추가한 테이블로 로직이 돌아가게끔 한다음 temp가 붙은 기존 테이블의 데이터를 새로 바꾼 테이블로 마이그레이션 하도록 batch script같은거 만들어서 한달동안 돌렸음요 기존 테이블의 데이터는 그대로 둬서 기존데이터 조회가 필요할때는 그 테이블에서 조회해서 반환하도록 임시 구성하고나서 한달후 테이블 다 옮겨졌을때 기존테이블 drop처리
위에놈들 미쳤나 테이블이 컬럼구조하고 연관된 테이블이 뭔지 정보가없는데 단순행 3억개있다고 어찌처리하는지 고민하는게 신기하네 .. 임시테이블만들어서 걸쳐나야지 - dc App
저 컬럼을 어찌쓸지 남들이 다 아는것처럼 말하노 - dc App
남궁형이 그걸 어찌아시오 - dc App
몰라서 물음표 붙였잔아 한잔해