듣기 버전 : https://youtu.be/NmyiPYYHlNo?si=L-DDsTkBOWJhzNKR 제가 이전에 메모리 DB라고 얘기 한 것들이 있지요. 좀 알기 쉽게 퉁쳐서 불렀는데요, 이들은 크게 두 가지 종류가 있습니다. in-memory database 라고 하는 rdbms이면서 메모리에 일부 데이터를 저장하거나 완전히 메모리만 사용하여 RDBMS의 disk io병목을 해소하고자 만든 제품이죠.. 크게 Cubrid, Oracle In-Memory Option이나, SAP HANA, Altibase 등등 굉장히 많은 종류가 있습니다. 그리고 memory store라고 부르는 제품들이 있지요. memcached, redis 가 이에 해당합니다. 인메모리 데이터베이스는 데이터베이스의 확장 같은거라 기존 RDBMS와 거의 동일하게 설치하고 표준SQL로 운용을 할 수 있습니다. Cubrid 하니까 생각 나는 에피소드가 있네요. 모 신문사에 도입 된 것인데 클라우드 인프라로 옮기고 싶다는 요청에 분석하고 옮기는 준비를 하던 중이었지요.. 2012년 근처로 기억이 됩니다. Cubrid는 다른 RDBMS와는 달리 브로커 라는게 중간에 있어서 RDBMS의 부하를 분산시키는 부분이 있고 메모리 영역과 디스크 영역을 혼합해서 사용하면서 브로커가 엔진 기동시 메모리에 띄워주고 하는 역할을 하는 것 같았습니다. 구조 자체를 보면 상당히 효율적이네 하고 생각을 했습니다. VM에 올린다는 얘기는 에뮬레이트 된 HW에 OS를 올리고 그 위에 올리게 되다보니, 100%호환이 된다고 장담할 수가 없지요. 그래서 미리 환경을 만들고 cubrid를 설치해서 동일하게 구성했는데, 오히려 VM위의 환경이 더 느리더랍니다. 브로커가 무슨일인지 두세배 늦게 반응을 했지요.. 큐브리드 개발사는 한국회사라서 그 회사에 연락해서 공조를 요청해서 한참을 봤는데, 결국 개발사는 두손을 들었습니다. 자기네가 봐서는 브로커가 이유를 모르겠지만 늦게 반응한다는 것이었습니다. 구조가 아무리 좋아도 기술력이