https://gall.dcinside.com/mgallery/board/view/?id=github&no=53894&page=2

in-memory DB 웨씀? ㅋㅋㅋ안녕 퇴물이다밑에서 글 쓰다보니 in-memory DB 이야기가 나왔는데, 이게 몬가 싶은 애들도 있을꺼임.CS교양 영양보충의 개념으로 살짝 듣고 흘려라.In-memory DB는 데이터베이스이긴 한데, 램 메모리에 데gall.dcinside.com


인메모리 디비 회사에서 일하다 지금은 데이터 엔지니어 쪽으로 일하고 있음

인프라쟁이였는데 개발 가고싶어도 씨;발 개발 할 기회를 안주네 회사가


어쨌거나


우리가 쓰는 대부분의 디비는 Row 단위로 파일시스템에 저장함. Row-base라고 한다. 이건 RDBMS의 기본이라 할 수 있는 오라클-mysql의 경우임.

그리고 반대의 경우, 쌥과 같은 놈들은 Columnar라고들 많이 하는데 이건 Column-base임.

메모리구조가

Row1 - Row2 - Row3 과 같이 저장되는게 로우베이스

Column1 - Column2 - Column3과 같이 저장되는게 컬럼나(컬럼 베이스)

파일포맷으로 치면 CSV와 Parquet의 차이.


컬럼나의 장점이라면 보통 OLAP성 데이터에 특장점을 가진다.

특정 컬럼의 내용을 다 훑어서 보고 싶은데 row는 어쨌거나 인덱스타고 하나씩 긁어와야 되고

컬럼나는 그냥 메모리 1~10까지 긁어 보면 된다. 당연히 훨씬 더빠름.


반대로 로우베이스면 OLTP 특화다.

OLTP는 '한 개의 데이터를 빨리 뽑는 데' 특화되어 있다고 보면 된다.

당연히 인덱스 타고 한개만 훑으면 되는 놈이 빠르다.(통신, 금융 특장점)



사실 컬럼나-인메모리 라고 생각하는 경우가 많은데

이론적으로 인메모리가 딱히 컬럼나일 이유는 없다.

컬럼나가 많은 데이터를 긁어오기 위한 놈이라 메모리에 다 올려 쓰면 좋음! 인거임.


즉 로우베이스에도 인-메모리 DB가 있고

실제로 한국에도 몇개 있다. 대표적인것이 알티베이스.(SI 전전한 인간들은 잘 알것임. 아마도.. )


인-메모리 디비라는 것은 걍 파일을 메모리에 싹 다 올리면 인메모리다. 정말임. ( 또한 그 때문에 초기 구동 속도가 느리다. 파일을 다 메모리에 올려야되니 )

뭐 굳이 우기자면 mysql oracle도 버퍼를 파일크기만큼 키워서 올리면 인메모리 맞지않음? 갠적으론 맞는 말이라고 우겨도 되긴한다고 본다 ㅋㅋ 당연히 아무도 인정 안해줌

근데 인메모리 디비는 '메모리에서 하는 작업'이라는 걸 인지한 설계가 있기 때문에 성능차이는 있을 것이다.


그럼 정합성은 어떡할건데?

이부분은 사실 '파일시스템 기반 디비와 비슷'하다.

일반적으로 DB에서 정합성이라고 하면 commit 하고나면 데이터 보장 이란 것인데

어차피 인메모리 DB도 commit하고 나면 파일로 내린다.(대신에 쓰레드를 하나 더 두거나 하기 때문에 병렬처리된다. 속도장점이 생기겠지..) 파일이 없으면 정합성 보장이 불가능하고 리두 로그도 기록해야 하기 때문이다.

그럼 별 차이 없는 거 아녀? 

진짜 맞다. '모든 파일을 메모리에 올려서' 생기는 이점 정도... '인덱스도 메모리에 올릴 수 있다' 정도의 차이라고 보면 되겠음.

실제로, 오라클은 파일기반임에도 인메모리 디비와 성능차이가 압도적이지 않음. 오라클은 진짜 잘 만든 디비가 맞다.


메모리에 파일을 올려서 파일시스템, DB처럼 사용하는 솔루션들도 꽤 있었는데 요즘은 거의 안 쓰는듯? 인메모리 디비 나오기 전 캐시나 최소 마이크로초단위 연산이 필요한 곳에서 많이 쓰던 것 같음.


글고 RDBMS, Key-value와 인메모리, 파일시스템은 또 별개의 얘기다

싱글, 온라인게임과 패키지, 플랫폼게임의 구분이 어느 정도 정형화 되어 있지만 실제론 온라인-패키지게임이 존재할 수 있는 것처럼...