Everything Realm
What is Realm?
The whole point of Realm, or at least one of its very core ideas, is that it consists of objects that go all the way down, to the deepest part of the system. If you look at existing solutions that are currently out there, they tend to be ORMs. More often than not, there’s this conceptual object-oriented model that people are working with, which is really an abstraction of what’s going on underneath. Usually, these are records, tables with foreign keys, and primary keys. As soon as you start to have relationships, the abstraction starts to fall apart because you start needing expensive operations to be able to traverse these relationships. As a result, there is often an unnecessary layer of mapping and complexity that, when avoided, can result in big gains. Gains not only in performance, but in simplicity as well, so the concept of Realm is remove unnecessary layers to obtain this gains.
At its heart, Realm is really an embedded database, but it’s also a way to think about data. It’s a way to think about models and business logic for your mobile applications. One way in which that happens is by trying to minimize overhead.
Realm also tries to keep as many operations as zero-copy as possible. That’s why realm goes out and replaces your object’s accessors as you’re using them. Realm reduces the need to ship things from the database, reads it out, and puts it in a variable instance so that you can use it. Instead, you just have raw access to the database. That way, you never copy anything out, and you never deserialize when you don’t mean to.
How does Realm work?
Imagine Realm like a Git repository so we can say that Realm is a MVCC database, you can have a lot of different branches of the database but they always are up to date because, before Realm saves everything to the file, it makes sure that the data is valid so you won’t corrupt your database.
Also, objects in Realm could be represented as a B-tree, when you are requesting some information to the db it will access directly to the realm file it will not be necessary to deserialize and make a translation to the query, because the query is also a B-tree.
Moreover, relationships are just indexes to other objects in the tree, thus making everything faster.
What Does Realm Look Like?
Realm is supported in a wide variety of languages (Android, Objective-C, Swift, Xamarin and React-Native). For the examples we are going to show we used Android/Java:
There are 2 ways of creating Objects Classes; one is extending the RealmObject and another way is implementing RealmModel, then you can set a Primary Key or not, without a primary key you will not be able to update an object, you can also add an Index to a field so the query is faster.
There is no real benefit between the two it just change the way you have to call the RealmObject properties
If you want to store an object in Realm there are also many options:
From ORMLite to Realm
First we need to talk about how we got this into our head. We were having issues when the user did the first initial sync after logging in. The application was hanging with ORMLite, we tried to improve the performance but we couldn’t do much.
We started to look at alternatives doing some benchmarks of different DBs libraries (Realm, SQLite alternatives) and after looking at the results Realm was the fastest.
So we started implementing Realm in our code, the first problem we noticed was that Realm does not allow polymorphism. As we said before, Objects have to extend RealmObjects, the solution was to implement Interfaces because we have objects in a different library (we have a Core library for shared code that is used in the app code).
The second problem we found is that Realm doesn’t allow to pass a Parcelable and/or Serializable object. Therefore, in order to send an object to another intent you have to pass the primary key of the object and query for that object to the new Fragment/Activity. Fortunately, queries in Realm are fast.
Third, and I think this was the issue that caused us the most problems, Realm does not have an auto-increment to the Primary Key of objects, so we had to implement our own in the Database persistence layer. We have a persist layer for each model that requires an auto-increment, when the persistences are created they query for the maximum value in the db and then save it in memory so every time an object is added this value is incremented by one.
After all these changes we did a benchmark on the sync process, the result was that in Android 7.0 and above the sync process was faster, and in the older versions it was slower but the app wasn’t freezing every second and was responsive during the syncing process.
Overall this process took us 5 months from development, testing and release to production (although we didn’t dedicate 100 % of our time the first months as we had other features to work on and only one developer worked on this change).
TLDR: Realm is a great database that skips some layers that others don’t, so it’s faster and has a lower memory footprint. There is some stuff that is not yet implemented in Realm but can be avoided easily. It gets time to get used to but after that the work is absolutely worth it.
Resources: Realm’s Core DB Engine, Realm Threading Deep Dive, Realm for Android
