우리나라에서 좀 큰 영어 학원 서버 문제 고치러 갔다가
거기 팀장하고 노가리좀 까다가 그 이야기나왔음
그 팀장이 말해주길
우리나라에
테이블 설계 존나게 잘하는 사람이 있어 이름 생각이 안나네
속도를 위해
애초에 join이 없는 설계로 간다더라
음
예전에 한달에 몇천만건 쌓이는 데이터가지고 쿼리좀 뚜들긴적 있는데
그정도면 index 걸어놔도 뭐,,
결과가 하루 걸리나 이틀걸리나 개찐도찐이더라
혹시나 했는데 join 없는 설계로 간다는 말 듣고 혹했음
ㄴ 용량은 문제가 안되니까 insert 와 update 손해를 감수하고 그러겠지 오직 퍼포먼스를 위해
ㄴ 그런 설계로 모든 서비스를 구현할수 있다는건 아니고
ㅇㅇ 맞음 중복 컬럼 존나 많음
나도 세세히는 안물어 봤고 그런 설계를 한다는 이야기를 들은거라 자세히는 모름
캐꼬꼬닭 / 병신설계인지 아닌지는 갑이 퍼포먼스 보고 결정 내리는 거임 내부적으로 어떻게 도는지는 사용자와 갑은 신경 안씀 꼭 학교에서 가르쳐준 정도가 답이 아닌 상황인거지
index도 몇천만건 이상 지나가면 무용지물이라고 예전에 들은거 같긴 한데.. 용량제한이 없으면 정규화를 안거치는게 과연 퍼포먼스에서 뛰어날까.. 퍼포먼스를 위해서 반정규화 한다고도 듣긴 했는데 그거랑 같은 이치인가...
ㄴ 좀 핀트가 안맞는거 같은데 음.. 데이터 베이스를 잘 몰라서 그러는 것이 아니라 잘알고 RDBMS 구조의 한계를 아니까 그렇게 하는거라 생각하면됨
디비의 길도 멀고 험하다.... 진짜 프로그래밍 관련해서 알면 알수록 더 우울해짐... ㅠㅜ 아직 내가 좆밥이구나 느끼면서
캐꼬꼬닭/ 트레이드 오프 모르냐? 조인 연산 시간은 생각해야지. 그리고 하드는 상대적으로 값이 싸니까 그냥 중복으로 값 저장하고 속도 높이는거다.
그리고 중견, 중소 쪽 윗대가리는 최적화 이런거 신경 안 쓴다. 그냥 서버 한 대 더 들인다는게 일반적이야
a테이블 천만건 b테이블 천만건 이런거는 조인보다 퍼포먼스를 위해 한테이블에 몰아넣고 a테이블 천만건 b테이블 두건. . 이런건 나누는게 더 좋겠다는 내용으로 이해하면 되나. . 상황에따라. .
상황따라 트레이드오프 선택 잘하는게 잘하는걸려나. 그리고 중복테이블 하면 데이터 신뢰성 문제도 있지않음?
조인이고 지랄이고.. 그냥 만들어 쓰는게 좋음.. 수천만원 들여서 db 사지 말고.. 그냥 파일시스템에다가 하나 설계해서 만들어 쓰면 졸라 빠르고 가볍고 좋음..
반정규화도 분명 퍼포먼스를 올리기 위해 쓰이는 방법중에 하나니. . 꼭 중복값이 있다고 잘못된거라곤. .
테이블 설계를 잘하는 사람이니 반정규화로 생길수 있는 이상을 잘 피하면서 설계하겠지. . 그니까 테이블 설계 존나 잘한다는 소리 듣는거일지도
보편적으로 조인을 한번도 안걸수는 없다고 보는데 ㅋ 나도 그사람이 설계한건 보고싶긴 하다. .
사무직으로 잠깐 일했을때 회사 매입매출을 DB안쓰고 엑셀로 회사일 처리했었음. 엑셀만 쓰다보니 join이 없으니 한 테이블에 자료 때려박다 보니 중복 데이터값 동기화 하는게 좆같았제
저런 소리하는 게 전문가면 똥파리도 새네요.
저는 조그만한 벤쳐기업 다니는데 하루 15억건이상(이것도 작년통계 지금은 더 증가) 데이터 mysql 로 정규화해서 잘 다루고 있음. 글쓴이도, 그 전문가도 데이터베이스에 대해 개념이 전혀 없네요.
데이터베이스를 다루는데 있어서 진짜 어려운건 데이터양이 아니라, 엄청나게 많은 트랜잭션에도 불구하고 원할하게 액세스 할 수 있도록 하는 것. NoSQL은 그런쪽으로 유리한 거구요. -> 쉽게 적는게 힘드네요.
그냥 JOIN을 멋모르고 쓰는 것보단 수동으로 Lookup하는게 낫다는 얘기가 와전된거 같은데. 잘못된 JOIN은 레알 죄악이지 = _=)
솔까 DB는 정답이 없는건데 저렇게 얘기한 전문가가 있으면 그 인간을 빨리 프로젝트에서 빼야될듯. 안그럼 좆됨 ㅋㅋ
캐꼬횽// 올체횽이 쓴 글 얘기하는겅미 ㅇㅅㅇ) 좀 옛날에 DB 아키텍트가 JOIN이 남용된다고 신랄하게 까던 글을 읽은 기억이 있다능
ㅋㅋㅋㅋㅋㅋㅋ 정규화 안 하면 무슨 무식한 짓이고 비상식적이고 비효율적이냐? 다들 정규화해서 잘 처리하고 있으면 됐어. 그냥 올체하는 이야기는 속도를 보고 한 이야기니까.
ㅋㅋ 그 테이블 설계 잘한다는 분이 직접 와서 댓글 달지 않는 이상 안끝날듯.. 최대한 조인을 줄이면서 반정규화 할수 있는건 반정규화 하고..퍼포먼스에 신경쓴다는 말이 여러사람 거치면서 조인없는 설계가 된게 아닐까도 생각해봄.
그러니까 정규화한다고 왜 속도가 떨어짐? 설계가 잘못되서 떨어지겠죠.
ㄴ 그냥 데이터가 나누기도 지랄맞고 퍼포먼스 향상시킬 방도가 생각이 안나서 그런듯
= _=) 정규화가 성능을 낮춘다는게 정석 아님? 개발 마지막 단계에 denormalize를 한다는 얘기가 절대로 별세계 이야기는 아닌데.
ㄴ 정규화하면 조인이 추가되니까 속도가 떨어지지. 정규화가 만능이 아니란다. 근데 조인이 없는 설계란건 그냥 단순한 시스템만 가지고 작업하는거지. TPC 사이트가서 성능 결과 봐봐라, 1테라넘는 테이블가지고 조인하고 해도 하드웨어 받쳐주고 설계만 제대로 하면 몇초면 끝난다.
간단한 게시판을 만들어도 조인없이 만들면 병신되는건데, 복잡한 시스템에선 그렇게 할수가 없지.
ㄷㄷㄷ 조인은 도깨비 방망이라서 뚝딱하면 그냥 결과를 꽁으로 준단다. 그래서 속도 저하가 없어. 씨발
아니, \"정규화 = 느리다\"가 100% 맞는 말은 아님. 주로 JOIN 때문에 성능이 느리다고 하는거고, 그 외의 경우엔 정규화된 구조가 퍼포먼스 향상에 유리한건 맞음. ㅇㅇ. 또 비정규화가 전체 퍼포먼스에 오히려 악영향이라는 이야기도 있음.
조인이 속도저하가 있다는 말은 조인을 대체할 다른 무언가로 처리하고서 비교해야하는 건데 뭐로 처리할건데? 시스템을 그냥 테이블 하나로 만들어서 다 넣게? 그럴수 있는 시스템은 조낸 단순한 시스템이지
테이블이 10개라도 서로 조인이 안되게 한다는듯.. 대신 테이블 10개에서 중복되는 값들이 넘처날테고.. 하드웨어적인 측면에선 정말 쓸모없고.. insert delete update에서 관련된 테이블을 모두 업데이트 해야하니 그 속도면에선 느림.. select 할때만 속도향상을 기대할수 있음.. insert delete update가 하루에 2~3번 이루어지는데 select가 천만번 이상 한다면 하드웨어의 저장용량은 손해보는 대신 속도향상은 가능.. 역으로 select가 하루에 2~3번 이루어지는데 insert delete update가 천만번 이상 발생한다면 개삽질...
단순히 테이블을 뭉치는게 비정규화는 아니지 - _-) 연관 데이터를 테이블에 같이 넣어두면 JOIN의 숫자를 줄일 수 있음.