프로젝트에서 모든테이블의 PK값을 UUID로 사용하였습니다.

Question

이제 개발경력 7년차에 접어든 개발자입니다.프로젝트를 진행하면서 의문점이 많은 시스템의 유지보수를 맡게 되었습니다.Node기반의 프로젝트였고, DB는 mariaDB입니다.처음 인수인계 받고 좀 놀라게 된게 모든테이블이 UUID로 PK가 잡혀있고, FK도 모두 UUID로 잡혀있었습니다.초반에야 데이터 적재량이 적기에 속도에대한 이슈는 크게 없었지만, 나중에 분명히 문제가 생길거라 생각했습니다.그러다 6개월이 지나고 테이블한곳에 대략 30만건의 Data가 적재되고, 이후 Insert를 하면 항상 속도이슈가 발생했습니다.해당건으로 많은 연락을 받기도했습니다.저의 짧은 지식으로는 UUID같은경우 Btree기반인 PK에 사용 시 추후 Overhead문제가 발생한다고 알고있었습니다.당연하게도 Insert시 말도안되는 시간이 걸리고, 정말 오래걸릴때는 Timeout으로 연결이 끊어집니다.수행사측에 문의를 했고, 어떤기준으로 PK를 UUID로 사용하였는지에 대한 일부 답변을 받았습니다.수행사측 답변보통은 UUID를 사용하는 것을 권장하고 있어서 UUID를 적용했다.이전에 프로젝트를 진행하면서 한번도 해당내용으로 컴플레인을 받은적이 없었다.정규화내용은 담당자에게 확인 후 연락주겠다(1달째 답변 X)ERD를 보면서 정규화 된 테이블인가 싶었던게..(간소화한 구조입니다.)Table T 컬럼 [id(uuid), A_id, B_id, C_id, D_id, E_id, F_id] - PK: id, FK: A_id, B_id, C_id, D_id, E_id, F_idTable A [id(uuid), B_id(uuid), 컬럼1, 컬럼2 ...] - PK: id, FK: B_idTable B [id(uuid), 컬럼1, 컬럼2 ...] - PK: idTable C [id(uuid), D_id(uuid), 컬럼1, 컬럼2 ...] - PK: id, FK: D_idTable D [id(uuid), 컬럼1, 컬럼2 ...] - PK: idTable E [id(uuid), F_id(uuid), 컬럼1, 컬럼2 ...] - PK: id, FK: F_idTable F [id(uuid), 컬럼1, 컬럼2 ...] - PK: id, FK:B_id실제로는 더 많은 FK가 있고, ERD를 보면 해석이 불가능할정도로 복잡하게 되어있습니다.테이블이 많다면 모르겠으나, 다해서 대략 40개정도입니다.최초 설계된 프로젝트입니다.User정보, 기본 코드가 존재하는 Item에대한 테이블 등 모두 PK는 오직 UUID 1개로만 되어있습니다.UUID로 되어있다보니 고유값으로 존재해야하는 코드들도 중복으로 insert가됩니다.(소스코드에 공통도 없고, 심지어 UUID라 찾아가는게 말도안되게 힘듭니다..)Index는 PK, FK만 잡혀있고, 그외에는 별도로 잡혀있는 index는 없습니다.이렇게 수행하는 수행사는 자기들은 문제가없다, 정상적으로 개발되었고 기능은 문제없다는식으로 배째라는상황입니다.(속사정도 좀있는게 윗선에서 빨리 인수인계 싸인하라고 압박을 받아 싸인한것도 있습니다. 이건제가 잘못한거죠..)지금 막막합니다.. 이걸 어떻게 개선해나가야할지... 진짜 개선을 하는건지, 새로 개발하는건지 의문의 들정도의 수준이라..아니면 제가 아직 경험이 부족해서 우물안의 개구리인지 가늠이 안되서 이렇게 여쭤봅니다.이프로젝트가 잘못된건가요? 아니면 제가 잘못된건가요?

정규분포 · Accepted Answer

이프로젝트가 잘못된건가요? 아니면 제가 잘못된건가요?이미 답은 알고 계신 것 같습니다. 분풀이 하는 것도 필요하지만, 문제 해결해보려는 시도도 해야죠?저였으면 일단 스키마를 마음대로 다시 구축할 수 있으면, 서비스 내리고 테이블을 모두 리모델링 하는 쪽으로 갈 것 같네요. 일단 이미 생성된 UUID는 어쩔 수 없고(어차피 최초에 인덱싱 전략만 잘 짜면 접근속도에는 큰 영향이 없음), 기존 uuid pk는 일반 칼럼으로 빼고, 인덱싱 걸고, bigint pk로 alter 해야죠.인덱싱 스케일 문제 때문에 uuid에 5가지 버전이 존재하는 것은 아시죠? 모르셨다면 RFC 문서 참조하시기 바람. 이미 윗분이 언급한 대로, uuid 생성하는 쪽에서 완전 랜덤 버전 말고 namespace 부분만 최초 백엔드 초기화 시 랜덤으로 잡는 sequential uuid를 사용해서 데이터 지역성을 높이는 방법이 있습니다.https://github.com/tvondra/sequential-uuidsThis PostgreSQL extension implements two UUID generators with sequential patterns, which helps to reduce random I/O patterns associated with regular entirely-random UUID.Regular random UUIDs are distributed uniformly over the whole range of possible values. This results in poor locality when inserting data into indexes - all index leaf pages are equally likely to be hit, forcing the whole index into memory. With small indexes that's fine, but once the index size exceeds shared buffers (or RAM), the cache hit ratio quickly deteriorates.아니면 git이 파일시스템에 object 넣는 것처럼 파티셔닝이나 샤딩을 활용해서 기존 스키마 구조를 유지하는 방법도 있고요. 대규모 서비스는 대부분 이 둘을 적절하게 융합해서 스케일 문제를 해결합니다.UUID 4버전 같이 엔트로피가 빵인 데이터를 인덱싱하는 것은 확실히 스케일 문제가 있어서 파티셔닝을 사용하는 방법은 일시 방편이고, 나중에 tech debt로 작용할 겁니다. 판단은 알아서.글에서 경력이 어느 정도 느껴지는데, 제가 이렇게 길게 안써도 알아서 다 해낼 능력이 있으신 것 같습니다만.

공부가싫진않아요 · Answer

프로젝트가 문제고 저도 짧은 경험상 외주 업체에서 제대로 된 데이터베이스 설계나 이름 규칙을 정하고 문서화 해주는 꼴을 본 적이 없습니다. 그리고 인수인계 싸인은 압박 들어오면 진짜 개같은 상황 저도 경험해 봐서 알고 저도 어려운 선택 하겠지만 그거 걍 싸인 안 하고 배째 가야합니다. 책임 떠넘기기라 ㅈ같아요.. 고생하시네요 ㅠ

개발 까마귀 · Answer

데이터 수 때문에 AI로 하려면 서비스 중간에 닫고 해야할정도네요 ㄷㄷ

yeori · Answer

uuid를 b-tree primary key로 정하면 삽입할 때마다 자기 자리를 찾으려고 탐색을 할테고, 중간 쯤 어디에 끼워 넣으려다보니 페이지가 쪼개지는 현상도 생길테고,랜덤하게 키값이 들어오니 저수준에서 locality의 이점이 완전히 사라짐... range search는 사실상 포기하겠다는 건데...보나마나 검색할 때도 페이지를 다 헤집는 일도 생길테고...sequential uuid를 썼다면 모를까, 딱 봐도 그럴 거 같지는 않습니다.uuid를 장려한다는 괴담을 어디서 들었을지 짐작조차 잘 안됩니다.아마도 순서를 예측할 수 있는 pk 를 감추기위해서 문서에 uuid를 부여하는 걸 잘못 알아들은 건지...아마 끝까지 발뺌할거같음.

캐티 · Answer

앵간한거 아니나요. int, bigint 이케 안하였다고 심하게 느려지면 안대빈다.wordpress - MySQL/MariaDB write/insert take a very long time - Stack Overflowmysql - MariaDB Insert queries stuck frequently - Database Administrators Stack Exchange

프로젝트에서 모든테이블의 PK값을 UUID로 사용하였습니다.

5개의 답변

Q&A 목록