뭐 이런저런 다른 게 있겠지만...

제로보드는 집계 컬럼이 있고, 내 홈피에는 그런 게 없다는 게 일종의 철학이나

로직의 차이가 되겠군.

뭔 말이냐 하면...

류리 홈페이지를 텍스트파일 기반의 화이트보드에서 DB 기반의 제로보드로 컨버팅을

시키는데...

DB에 데이터가 잘 올라갔고, 이상이 없음에도 불구하고 게시판의 글 번호가 이상한

거야. 허허...

이상하다, 이상하다... 싶어서 봤더니만 제로보드는 글 개수에 관한 정보가 따로

있었음.

내 게시판 같은 경우에는 실제로 존재하는 글 개수를 전부 헤아린 후에 그걸 기초로

글 번호를 "매번" 산출해내는데, 제로보드는 아예 글 개수를 저장해놓고는 그것만

꺼내오는 형태로 되어 있더구만. 그러니 내가 글을 컨버팅해서 DB에 밀어올려도

그 전체 정보는 안바꿔줬으니 글 개수는 계속 동일하게 나올 거고, 실제와는 안맞아

버리는 현상이 생긴 거지. 뭐 답글의 숫자도 따로 집계를 하더라고.

이런 건 DB를 설계할 때 항상 맞부딪치는 문제이지. 데이터의 정합성을 우선시하느냐,

아니면 속도를 우선시하느냐의 문제라고 해도 좋겠다.

제로보드와 같이 미리 글 개수를 저장해두는 곳이 있으면 속도에서 많이 유리하다.

리스트를 보여줄 때마다 "매번" 집계하는 게 꽤나 속도를 많이 잡아먹을테니까.

거기에 단순한 카운트 말고 해당 글의 리플 개수를 세는 건 '해당글'이라는 조건까지

들어가서 더욱더 시간이 걸리지.

지금 내 게시판처럼 글이 몇 개 안되고, 리플도 몇개 안되는 동네에서야 금방 끝나지만

디씨 같은 데에서는 난리나는 거지. 수만명의 사람의 요청을 받고 수백만/수천만의

글 개수를 세어야 하니까. 거기에 리플 개수까지 생각하면... 아무리 멋진 서버라도

괴로워할 것이다.

그러면 당연히 항상 저런 방식으로 나가면 좋을테지만... 데이터의 정합성이라는 문제는

언제나 사람을 판단하기 어렵게 만든다.

단적인 예로 류리 홈피의 컨버팅작업 같은 것처럼 데이터만 밀어넣고 집계 정보를

수정하지 않았을 경우에, 혹은 DB 작업의 문제에 의해서 제대로 반영이 안됐을

경우... 문제가 나는 건 당연한 거다.

뭐 은행 같은 데를 떠올려보자. 은행에는 거래의 내역(히스토리)이 있고, 그것들을

다 계산해서 최종 결과만 가지고 있는 잔액이 있을 거다. 그런데 어떤 사람이 돈을

인출했는데 시스템의 문제로 거래내역은 남아있지만 잔액쪽은 수정안했다 치자.

그럼 그 사람은 돈을 빼고도 잔액은 그대로인 사고(!!!)가 생긴다. 반대로 돈을

입금했는데 잔액이 그대로이면 고객의 엄청난 손해를 가져오게 되는 사고(!!!)가

생기는 것이고. 거래내역을 매번 계산하면 그런 잘못된 오류는 생기지 않을텐데

말이다.

쇼핑몰 같은 데에서 매번의 거래내역에 고객의 이름과 정보를 일일이 다 기록한다고

해보자. 그러면 나중에 해당 고객의 정보가 바뀔 때마다 그 모든 정보를 다 다시

수정해줘야 하는데, 프로그래머의 실수이든 시스템의 실수이든 빼먹는 정보도 생길

것이고, 예전 데이터가 그대로 있는 경우도 생길 것이다. 하지만 고객정보 테이블을

따로 만들어두고, 거래내역쪽에서는 그 정보를 "매번" 참조한다고 할 때에는 그런

오류가 생기지는 않을 것이다. 또한 정보는 고객정보 테이블만 바꿔주면 모든 곳에

반영이 될 것이고. 하지만 "매번" 참조한다는 것 자체가 시스템에 엄청난 부하를

주게 되는 것이고.

그래서 데이터의 정합성과 속도의 향상 사이에서 DB 설계자들은 항상 고민하게 되는

것이다.

하지만 현실적으로는 속도를 올리는 데에 들이는 비용이 너무나도 엄청나고, 한계가

있기 때문에 (아무리 돈을 많이 들여도 현존하는 최고 시스템이 안되면 안되는 거다.)

결국에는 제로보드와 같은 방식으로 나아가고, 예상되는 오류를 최소화시켜서 정합성을

맞춰나가는 방식으로 하는 게 대부분이다. 그건 사람을 쪼으기만 하면 가능한 일이니까.

그리고 집계정보가 제대로 되었는지 한번쯤은 재정비하는 프로그램이 필요하다.

역시나 제로보드에도 마찬가지로 정보들을 재정비하는 게 Admin 툴에 있더군.

전에 회사 사람들이랑 농담조로 했던 얘기중의 하나가 '중국에서 은행 시스템을 만들면

관계형 DB(RDB)는 포기해야 할 거다. 고객만 5억건 이상에 거래내역은 더 엄청날테니.

건수가 늘어날 때마다 DB의 시간은 기하급수적으로 늘어나버리니, 중국에서는

고객테이블, 계좌테이블의 분리해서는 도저히 성능이 안날 거다.'라는 얘기가

떠오른다.
profile

이브리타, 나의 에뜨와르
너와 내가 공유하는 추억
너와 내가 만들 추억