DB 정규화를 하지 않는 이유

DB 정규화를 하지 않는 이유는 한마디로 성능이다.

그렇다면 DB 정규화는 왜 성능을 해치는가?

1. DB 정규화는 테이블을 많이 나누게 하고, 테이블이 맣아지면 Join 이 많아진다. 그리고 Join 은 성능에 큰 악영향을 미친다.

1.1 Join 은 테이블 락 (Lock) 을 일으키고, 테이블 락은 병렬성의 큰 적이다.

아마 이 이유가 No-SQL 이 부상하게 된 가장 주된 원인이 아닐까 생각한다.

Python 의 GIL 이랑 같은 원리.

1.2 Join 은 여러 테이블을 가로지르는 다중 Disk-seeking 을 일으킨다. 한마디로 데이터 국지화의 적이다.

컴퓨터 하드웨어와 소프트웨어에서 많은 최적화장치들의 작동근거가 데이터 국지화이다. 이 가정이 깨질 경우 데이터 액세스가 굉장히 비싸진다.

DB 정규화는 공간을 가장 절약하는 방식이다 (i). 하지만 저장공간은 저렴하다 [1].

공간을 절약하는건 당연히 죄가 아니다. 심지어 공간을 절약해야 시간도 절약되는 경우가 많다. 그리고 이것 역시 “정규화가 성능에 좋다” 라고 주장하는 사람들의 한가지 근거이다.

하지만 알고리즘이란게 어느 선에 도달한 뒤에는 불가피하게 시간과 공간 사이의 트레이드오프에 직면하게 된다.

정규화는 공간 절약의 극한에 서있다.

이는 이론적으로도 당연하게 시간을 트레이딩 할 여지가 있음을 의미하지만, 많은 실천결과들이 역시 이 결론을 뒷받침해주고 있다.

또한 위의 1.2 와 결합시켜서 살펴보면 알게 되는데, 데이터 양을 줄인다고 무조건 시간이 절약되는게 아니라, 다수의 경우 데이터 국지화가 성능에 훨씬 큰 영향을 미친다. 이것은 실천적으로도 많이들 이중화 (Redundency) 로 정규화를 타파해 성능향상을 이룩하고 있는 산업현황과도 매칭된다.

또한 이 점은 저장 매개체의 랜덤 액세스와 순서적 액세스 사이의 수량급을 초월하는 성능 gap 의 배경속에서 더욱 확대된다. 이것은 물리적인 HDD 에서 유독 두드러지지만 SSD 에서도 상황은 비슷하다.

정규화는 쓰기에 최적화되어 있다. 하지만 읽기가 훨씬 중요하다.

Continue reading

Advertisements

슈퍼마리오 멀티플레이어 개발 후기

coolspeed

왓 스튜디오 팀 합류 과제로 게임제작 미션을 받았다.

나는 과제로 “슈퍼마리오 멀티플레이어 게임”을 만들었다:

EnemyCD.gif

과제 결과물을 왓 스튜디오의 허락을 받고 소스코드를 Github 에 공개하였다:

https://github.com/coolspeed/MarioMultiplayer

관심 있으신 분들은 별표 하나씩 찍어 즐찾해주시길 부탁립니다.

게임 룰: 위의 GIF 움짤  그대로. 먼저 상대방을 밟는 쪽이 이긴다.

 

과제가 1차, 2차로 나뉘는데 1차에서는 싱글 플레이어 슈퍼마리오를 만들었고 2차에서는 그것을 멀티플레이어 게임으로 발전시켰다.

최종 클라 Java (Processing) 1500 줄, 서버 C# 22줄로 짜여졌다.

클라

Processing 으로 만들었다. 왜?

  1. Processing 이 좋아서. (유쾌한 시각적 프로그래밍)
  2. Unity 쓸줄 몰라서.
  3. 다른 엔진도 쓸줄 몰라서.
  4. 엔진부분이 더 재밌어서.
  5. 웹에다 배포하고 싶어서. (P5.js 를 통하여. 하지만 망했다. 그냥 일반 Processing 애플리케이션처럼 exe 파일로 빌드했다.)

서버

단순한 릴레이 서버.

big_mirror.png

넷코드

ZeroMQ 를 네트워크 라이브러리로 사용했다.

Continue reading

왜 그동안의 함수식 언어 홍보는 잘못됐는가?

그렇다. 함수식 프로그래밍과 그것을 포함하는 “선언식 프로그래밍” [1] 은 그동안 이른바 산업 프로그래밍과 산업 프로그래밍 언어의 혁신요소들의 주요 원천 중 하나였다[2]. 하지만 그동안의 함수식 언어 홍보에서는 중요한 오류들을 범했다.

예를 들어 함수식 에반젤리스트들은 아래와 같은 광고어들을 내세웠었다.

“함수식 언어에서 변수는 값이 바뀔 수 없어요. 그리고 이게 좋아요. 버그를 막아주니까.”

이걸 듣는 사람들의 반응은 아마도 당장 발이 묶인 느낌일 것이다. 그래서 “그러면 코딩을 어떻게 해요?” 라고 묻는다면, 이런 대답이 올 것이다. “변수 변경이 정말 필요할 때는 변경할 수도 있어요. 그리고 함수식 프로그래밍에서는 꼬리 재귀를 사용하지요.” 그러면서 아마도 계승(factorial)이나 피보나치 예제를 주머니에서 꺼낼 것이다.

이렇게 되면 프로그래머는 아마도 고개를 갸우뚱 하며 (말은 하지 않고) 생각할 것이다.

“그렇게 되면 어차피 명령식에서랑 똑같이 변하는 변수를 사용하지 않을까? 과연 참고 변수를 변하지 않게 사용할 수 있을까?”

“그리고 나는 일할 때 매일 계승을 짜진 않는단 말야..흠..”

Continue reading

프로그래밍 바벨탑 해결

Python 을 Go 로 번역해주는 트랜스컴파일러:

https://github.com/google/grumpy

Python 을 Go 로 트랜스컴파일한다는 것은 무엇을 의미하는가, Python이 최정적으로 네이티브 컴파일 됨을 의미합니다..

저는 어제 이 리포의 별수가 실시간으로 오르는 걸 보았습니다. 오늘은 어제 대비 별표가 많이 늘어났더라구요.

이런 갓 프로젝트를 누가 만들었나 했더니 갓 Google 님이 만들었더라구요.

이게 좀더 성숙해지면 구글은 python 으로 짜여진 유튜브를 네이티브 프로그램으로 서비스 하겠네요.

자 그러면 앞으로 이런 식으로 프로그래밍 바벨탑들이 다 해결 될 것인가?

 


하스스톤 역기획 해 python 코딩하는 알파고:

http://kotaku.com/google-deepmind-is-now-analysing-magic-and-hearthstone-1767628685

프로그래머들을 아예 다 해치울지도..? ㅋㅋㅋ

2016회고: 같은 성형외과 나온 프로그래밍 언어들

내 언어의 경계는 내 세계의 극한이다 — 루트비히 비트겐슈타인 <논리철학 논고> [1] (5.6)

프로그래밍 언어는 빠르게 발전한다 — 적어도 빠르게 변화한다. 한때 유행했던 Delphi 나 한때는 쿨하다고 여겨졌는 Perl 이 오늘날 이토록 사람들로부터 외면 받을 줄은 그때 당시는 상상하기도 어려웠던 것처럼[2]. 2016 년에도 프로그래밍 언어는 1년어치 뉴스를 듬뿍 채울 만큼 착실하게 발전했다. 뜻인즉 프로그래머들의 식후 티타임 화제를 옹근 2016년 한해만큼 제공하기에 충분한 분량을 채울 만큼 확실하고 견고하게 발자국을 내디뎠다는 말이다. 원한다면 프로그래밍 언어 2류 관찰가의 시선을 따라 2016년의 프로그래밍 언어를 회고해보자. (일부 특성들은 사실 2016년에 추가된게 아니다, 엄밀히 따지자면. 하지만 그게 2016년에야 각광받았다면 2016년의 뉴스로 치부할 수도 있을 것이다)

2016 년 “올해의 프로그래밍 언어”

프로그래밍 언어 유행지수를 발표하는 것으로 프로그래밍 커뮤니티에서 유명한 TIOBE 가 곧 2016년 “올해의 프로그래밍 언어” (Programming language of the year 2016) 를 발표할 예정이다. 이 영광을 차지할 언어는 Go 언어가 거의 확정이다 [3]. 원인은 1개 퍼센트 포인트 이상의 유행도 상승을 보여준 프로그래밍 언어가 Go 와 Groovy 밖에 없는데, Groovy는 이미 과거형으로 되었기 때문이다.

Google이라는 명문 출신, C언어의 아버지와 UNIX의 아버지가 만든, 대규모 동시성 프로그래밍을 위해 태어났다는 슬로건, 등등 태그들을 달고, 프로그래밍 언어들이 혈전고투로 어려워하는 와중에 Go 언어는 자기만의 길을 개척해 유행도를 얻고 있다. 또한 컨테이너 프로그램 Docker 가 점점 일반 가정에 까지 들어설 만큼 유행해진 것이 그것의 개발 언어 Go가 나날이 주목받는데 일조를 하는 것 같다.

JetBrains 도 이런 배경에서였는지, Go언어 IDE 프리뷰 버전(현재 이름: Gogland)을 내놓았다. 성숙한 IDE는 Go 생태계의 빠른 성장에도 큰 도움이 될 것 같다.

Async/Await 유행년

2016 년을 감히 Async/Await 의 해라고 부르겠다. 2016 년에 뭐가 가장 핫했냐고 물어본다면 당근 Async/Await 이겠으니. Continue reading