거래데이터와 원장데이터, 두 개는 다르다.

사실 기초인데, 물어볼 사람이 없다보면 3년이 지나도 모르는 경우가 많다.

생각난 거만 정리해 본다.

원장데이터 Master Data

은행의 계좌테이블, 고객테이블.

이런 걸 원장이라고 한다.

중복데이터가 존재하더라도 물리적인 기준으로 삼을만한 테이블.

분쟁이 일어나도 보고 판결할 수 있는 테이블.

이런 걸 "원장"이라고 한다. "원본장부"라는 뜻이다.

용어는 조금 오래된 거다.

옛날엔 모든 걸 손으로 써서 기록했다.

그래서 장부하나를 정해서 거기에 중요정보를 모두 기록했다.

이 장부 이름이 "원장"이었다.

요즘은 Master Table 이라고 한다. 영어라 조금 더 멋있긴 하다.

사실 "원장"이나 Master Table 이나 같은 말이긴 하지만...

"원장"이라는 말은 이제 금융권이나 상거래 쪽에만 남아 있다.

Master Table 사례를 이야기해보면 다음과 같다.

"(옛날) 호적정보 데이터". 약 6억건 이상.

전 국민 데이터가 있고, 죽은 사람 데이터까지 있다.

"은행 계좌 데이터". 국내 은행권 데이터 총합 2억건 이상. (2016년 기준)

살아있는 데이터만 보관하고, 오래된 데이터는 백업 후 삭제하기 때문에 많지 않다.

사실 6억건 정도는 성능좋은 서버에 Oracle로도 커버가 된다.

굳이 Memory DB까지 갈 필요도 없다.

Master Table의 특징은 필드수가 많아 1 Row당 Size가 크다는 거다.

원본이기 때문에 Insert, Update, Delete 의 종착역이다.

그래서, 신뢰성이 증명된 DB를 쓴다.

Insert 했는데 DB 값이 변하지 않았다면 사용할 수 없다.

Master Table 인만큼 많은 곳에서 조회한다.

Join 문이 많을 수 밖에 없다.

성능을 높이려면 Index를 만들어야 한다.

그런데 많이 만들다보면 Insert 시간이 늘어난다.

1,000개 밀어 넣는데 1분 넘게 걸리는 경우도 봤다.

요즘은 아예 DB Replication을 쓰기도 한다.

서버 성능이 좋아서 그래도 되긴 한다.

하지만, 나노 시간의 세계에선 그렇지 않다.

Delay 에 의해 서로 다른 값이 조회될 수 있다.

사용자가 뜸할 땐 전혀 문제가 없다가 붐비면 문제가 된다.

Key 값을 Select 한 후 1 을 더해서 증가시키는 경우 특히 문제가 된다.

(Sequential Key Generation을 가능하면 이렇게 하지 말았음 좋겠다.)

불 끄러 들어가보면 생각보다 흔하다.

"블로그" 만들 땐 그래도 되지만, "과금"은 그렇게 만들면 안된다.

High Available 한 상황에서 Replication 은 Backup용으로만 사용한다.

여기서부터 복잡해지니까 나중에 따로 정리하겠다.

거래데이터 Transaction Log Data

거래는 기록이다. 사회적 룰의 기본이 "불신"이다.

"반드시 언젠가 분쟁이 발생할거다"라고 보는 거다.

그래서 지불한 사람과 받은 사람이 모두 거래내역을 저장한다.

영수증을 받는 이유도 그거다.

요즘은 메일로 발송한다. 다만, 귀찮으니까 사람들이 안받긴 한다.

잘 알아서 하겠거니 하고. 하지만, 그것도 믿을만한 사이트만 그렇다.

처음으로 상거래 사이트를 만들었다면 영수증 발급 기능은 필수다.

"분쟁방지"를 위해서는 증거가 필요하다.

그래서 거래확정시점에 기록을 "박제"시켜야 한다.

시점은 필요에 따라 달라진다.

그 액션을 "확정", "결산"이라고 한다.

거래건수 상위 사례만 들면 다음과 같다.

11번가, 지마켓 등 전체 : 일평균 114만건 (연간 4억건, 2016년기준)

온라인 쇼핑 전체 : 일평균 362만건(연간 13억건, 2016년 기준)

거래데이터의 특징은 한 번 확정되면 고칠 일이 없다는 거다.

그래서 데이터를 세가지 방식으로 저장할 수 있다.

(1) 테이블에 변경내역을 Insert 로 누적시킨다.

(2) 확정 전에는 Update 하다가, 확정 후에는 특정테이블로 (기록)이동시킨다.

(3) 상태 필드를 추가해서 확정상태임을 저장해 놓는다.

물론 이거 한다고 DB Trigger 까지 작업하면 오버다.

IDE 환경에서 한번에 뜯어 볼 수 있도록 코드를 관리하는 게 좋다.

(1)(2)번 케이스라면 무한히 늘어나는 Table을 만들 수 밖에 없다.

Table Partitioning 이 기본이다.

하지만, 무한히 늘릴 수는 없으니 1년이 지나면 로그파일로 만든 다음 백업한다.

백업되고나면 DB내용을 지운다.

그런데 10년전 기록을 뒤져볼 때도 있다.

그렇다면 별도 DB로 분리해야 한다.

사람이 많지 않으니까 성능은 낮아도 저장공간이 빵빵한 시스템으로 바꾸는 거다.

보통 비용관점으로 접근한다.

송수신 데이터

거래데이터와 비슷한데 조금 다르다.

제휴업무는 보통 API 통신을 하게 된다.

이 때 주고받은 데이터는 내 테이블에 남긴다.

특히 돈 데이터라면 꼭 남긴다.

돈이 잘못되면 회사신뢰성에 문제가 생긴다.

송수신은 절대 Update 가 없는 테이블이다.

상이한 값이 존재한다면 로직을 잘못 짠거다.

대부분 송수신이 종료되면 필요없어진다.

그래서 확정란게 없다.

하지만 송수신 내역이 상이하면 전수조사를 한다.

최소한 분쟁발생 시점 그날만이라도 전부 뒤지게 된다.

그래서 파일로그를 함께 만들어 백업한다.

양이 많지는 않다.

그래서 실시간 처리에는 문제가 없다.

하지만 꾸준히 매일 쌓여 몇 달 지나면 양이 꽤 많다.

특히 과거 데이터 조회할 때가 문제다.

몇 달치를 한꺼번에 다루어야 한다.

조회할 일이 없다면 파일로만 관리해도 괜찮은데, 조회할 일이 생긴다면 RDBMS에 올려야 된다.

JOIN을 통해 교차확인해야 하기 때문이다.

따라서 주로 임시 테이블 형태로 관리한다.

요약 내역만 통계테이블로 관리한다.

트래픽 로그 Traffic log

포털 사에서 웹로그 형태로 생성되는 것을 말한다.

네이버 일일 페이지뷰수가 1.6억건 정도 된다.(2016년 기준)

Apache log 가 1.6억건 정도 된다는 뜻이다. (nginx log도 있겠지.)

1년이면 584억건, 그런데 WAS 까지 포함하면 3배 이상은 봐야 한다.

로그성 데이터라 비교를 하거나 업데이트 할 일이 없다.

그냥 파일형태로만 관리하면 된다.

요즘은 사후분석을 위해 Hadoop 에 쌓았다가 HBase 에 넣기도 한다.

아니 HBase로는 대량의 실시간 트래픽을 분석하기 위해 쓰기도 한다.

타자간 계약관계에 쓰이지 않는다.

따라서 비교적 자유롭게 다룰 수 있다.

그래서 데이터 다루기가 덜 엄격한 편이다.

이동통신 통화로그 Call Data Record

초당 10원. 이렇게 과금하는 형태다.

1초가 지나면 과금증거를 남겨서 "과금시스템"으로 전송한다.

"과금시스템"은 이 증거를 합산해서 "청구서"를 찍어낸다.

이때 만드는 과금증거를 CDR (Call Data Record)라고 한다.

이동통신사 기준 하루에 6억건 생성된다. (연간 2,190억건)

발렌타인데이, 크리스마스이브 같은 날 특별히 더 많이 생성된다.

빠른 처리시간을 위해 대부분 "파일로그"형태로 만들어진다.

하지만, 합산, 검증 과정을 위해 다시 RDBMS로 들어간다.

그래서 상황에 따라 테이블 설계가 좀 복잡하다.

정리

불끄러 들어가보면 종종 겪는 일이다.

(1) 사용자 수는 적은데 어떤 테이블에 트래픽이 잔뜩 몰려 있다.

응답속도가 엄청 늦어 분명히 데이터 구조나 SQL 문제이다.

그런데 어떤 것이 이 테이블과 연결되어 있는지 알 수가 없다.

실행중인 SQL 프로세스를 캡쳐해서 확인할 수 밖에 없다.

(2) 그리고, 동적 SQL 문이 과다하게 쓰여져 있다.

난감하다. 아예 필드단위까지 분해해서 수습해야 한다.

고치다 보면, 구조문제까지 건드리게 된다.

간단하지 않다. 그런데 생각보다 그런 친구들 많다.

(3) 테이블정의서까지는 아니더라도 이렇게는 Wiki에 적어 놓자.

"이 테이블은 일결산 후 데이터값이 변하지 않음."

그렇지 않음 일일히 대조까지 하는 경우까지 생긴다.

필요한 걸 적어 놓으면 인수인계할 때 정말 편하다.

인수인계를 해줘야 더 도전적인 일을 할 수 있다.

(4) 개발할 땐 지금 개발하는 시스템이 뭔지 사업팀에게 물어보자.

물론 대답이 "기술용어"는 아니다.

"인문용어"를 "기술용어"로 바꾸는 건 기술자의 일이다.

시스템을 어떻게 만들지는 기술자가 결정해야 한다.

"사업문제"는 사업팀이 결정하고, "기술문제"는 기술팀이 결정하자.

의심스러운 건 미리 묻고 협의한다. 그게 일의 기본이다.

참고로, 책임지기 싫어서 "기술적 결정사항"까지 사업팀에게 넘기는 경우도 봤다.

그러면 안된다. 정말 시스템이 산으로 간다.

당장 문제되어 보이진 않지만, 시스템이 오픈되면 알게 된다.

책임논쟁으로 지금 시스템을 조치할 수 없다는 것을.

정말 열이 뻗치다가 현타가 올 것이다.

FIN.