왜 Realm이 빠르냐고 질문을 하고 근거를 요청하신 분이 있는데 MongoDB가 지원 중단을 하며 글을 삭제한 것 같네요.

그래서 한 때 일했던 입장에서 기억나는 기술적인 이유를 설명해드리려고 합니다. 가장 큰 이점은 Realm이 SQLite 대비해 더 적은 메모리를 사용하고 캐쉬 히트율이 높았던 점이 가장 큰 이유였다고 생각됩니다.

Realm은 기본적으로 사용하는 사이즈를 기반으로 메모리에 저장되는 용량을 선택합니다. 그래서 사용자가 큰 사이즈의 자료형을 선택하더라도 수 비트의 작은 사이즈로 직렬화를 하는 경우가 많습니다. 실제로 사용자가 더 큰 자료를 쓰는 경우에 컨버전을 합니다.

Realm은 같은 자료형끼리 묶어서 인접해서 저장합니다. 사용자는 테이블의 모든 데이터에 접근하지 않고 일부 데이터를 연속으로 접근 하는 경우가 많습니다. 위에 이야기했던 적은 사이즈의 인코딩 때문에 한번에 캐쉬에서 찾을 수 있는 데이터가 훨씬 더 많아지겠죠.

Realm은 POJO 객체에 hydrate를 하지 않고 getter와 setter에서 필요할 때 자료를 전달하는 형식입니다. 이를 위해 자바의 경우에는 바이트 코드 수준에서 조작을 합니다. Protobuf와 같은 자료형이 그 당시 Meta의 Facebook 앱 클라이언트에 쓰였던 이유가 이 hydrate 과정이 성능상의 큰 단점이 되고 필요한 데이터만 접근하는게 이점이 있기 때문입니다.

Realm은 SQLite에 비해서 대부분의 시나리오에서 훨씬 빨랐지만 이 부분이 시장에서 큰 요인은 아니었다고 생각합니다.

Realm의 가장 큰 경쟁자는 Facebook에서 만들었던 파스였던 것으로 기억을 합니다. 그 이후에는 Google의 Firebase가 경쟁자가 되었고요. 이 둘은 로컬 모바일 데이터베이스는 아니고 원격에 데이터를 간단하게 저장할 수 있는 서비스입니다. 어떻게 Realm의 경쟁자가 이 둘이 될 수 있냐 싶지만 실제 유저는 그냥 어디든 저장하면 되고 속도는 크게 중요하지는 않았던 것 같습니다.

그리고 이후 에릭슨이 투자하게 되며 Realm의 범위는 축소되었습니다. 에릭슨은 Realm이 iOS에서 어느 정도 점유를 하고 있는데 더 기능 개발하는 것을 이해하지 못했습니다. 그리고 동기화 솔루션으로서의 가치를 더 인정했고요. 이후 MongoDB에 Realm은 합병되었습니다.

SQLite를 선택했던 이유의 8할은 다루기 쉽다는 것이었던 것 같네요.

이것도 중요한 이유중 하나로 생각합니다. Realm은 스레드 로컬 기반으로 사용법을 제공했고, 자동 업데이트를 제공했으며, 다른 스레드에서 새로 질의를 하면 매우 적은 비용으로 같은 데이터를 전달한다고 이야기했고, 다른 스레드로 자료를 전달하지 말 것을 권고했지만 이런 이야기를 설명하기는 쉽지 않았습니다.