Photo courtesy of Wesley Fryer with permission under license CC BY-SA 2.0
tl;dr
Couchbase Mobile is easy to use, works completely standalone, yet provides enterprise-class scaling when you need it. You should try it.
In the beginning
This will be my second official post here at Couchbase. I’ll be blogging about more practical issues coming up. But for the moment, I’m going to indulge in a little higher level discourse.
I’ve been programming for a long time. Over the last several years, I’ve really gotten into mobile, but I’ve worked in a lot of other areas.
Still, I’d guess, before joining Couchbase, I had an average understanding of databases. Or, I should say, relational databases. Somehow achieving 6th normal form always seemed kind of cool, but I’ve never actually needed to worry about it.
Even so, for development, relational databases (and hence, SQLite on mobile) seemed like the way to go.
In this post, I’m going to talk about why I’ve changed my mind, and why I think you should too.
Setting the stage
Years ago, relational databases had pretty much won the day over other technologies. To the point that SQL, which is actually the name of a language, became almost synonymous with the term database.
The world has changed a lot with the explosion of both the Web and mobile. This includes the kinds of data, and how it’s accessed. Databases had to change, too. This gave birth to the NoSQL universe.
Why Couchbase Mobile
Couchbase Mobile (or CBM) is a complete package, including a stand-alone embedded database. (The stand-alone part is actually called Couchbase Lite.) CBM’s core architecture puts in squarely in the NoSQL camp.
I want to focus on two particularly compelling reasons why I believe CBM should be your first choice for mobile apps: ease of use, and architectural flexibility. I’ll talk more in terms of using CBM from the start of a project. The same points make a strong case for switching to CBM, even in a mature app.
Ease of Use
Both iOS and Android rely on SQLite for their standard databases. SQLite is an excellent open-source relational database. It’s just not that easy to use.
I went over to the Android developer portal to take a look at the current docs on using SQLite. Here’s the beginning of the first paragraph after the intro:
And here’s an example chunk of code for creating a database:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public class DictionaryOpenHelper extends SQLiteOpenHelper { private static final int DATABASE_VERSION = 2; private static final String DICTIONARY_TABLE_NAME = "dictionary"; private static final String DICTIONARY_TABLE_CREATE = "CREATE TABLE " + DICTIONARY_TABLE_NAME + " (" + KEY_WORD + " TEXT, " + KEY_DEFINITION + " TEXT);"; DictionaryOpenHelper(Context context) { super(context, DATABASE_NAME, null, DATABASE_VERSION); } @Override public void onCreate(SQLiteDatabase db) { db.execSQL(DICTIONARY_TABLE_CREATE); } |
Fun, right?
Now, don’t get me wrong. Android is an awesome technology bundle. SQLite is best-in-class. But apps need to store data. And if I’m trying to get a project off the ground, I don’t want to spend my time thinking about schema design and stuffing SQL statements into strings.
In contrast, this is roughly what it takes to start with Couchbase Mobile:
|
1 2 |
manager = new Manager(new AndroidContext(this), Manager.DEFAULT_OPTIONS); database = manager.getDatabase("crud"); |
And here’s code (minus boilerplate stuff) to store some new data:
|
1 2 3 4 5 6 7 8 |
Document document = database.createDocument(); String documentId = document.getId(); Map<String, Object> profile = new HashMap<>(); profile.put("firstName", "Hod"); profile.put("lastName", "Greeley"); document.putProperties(profile); |
That’s not a completely fair comparison. The Google sample has some of the extra bits you need to do things properly. On the other hand, the Couchbase sample already has data going into the database!
The real point has to do with how simple it all is. It’s so much easier to map natural structures in the code (Java objects, in this case) to the constructs needed for the database. The ease of mapping allows CBM to take care of a lot of other details for you, too. The code snippet above isn’t much more than it would take to to serialize a Java object to a file!
Couchbase is a document database, meaning you store a complete, semi-structured object as the fundamental data chunk (as opposed to a row in a table). More precisely, Couchbase stores JSON objects. JSON is lightweight and flexible. It handles arrays. Objects can be extended without breaking anything. It’s just nicer.
Contrast that with trying to glue some inflexible tables together to map to an object of any complexity. Whether you do it yourself in SQL, or you pull in a library to help, it’s not a pretty sight.
Flexibility
Couchbase Mobile gives you flexibility in two important ways, structure, and scalability.
Structure
CBM is “schema-less”. That shows in the ease-of-use. In the code sample, you can see the document structure gets created implicitly. No need to define tables or name columns.
Beyond that, schema-less means you can easily change your data structures without the migration headaches.
To illustrate these points, imagine starting with a user profile that contains one phone number for each person. The two figures show how that might look as a SQLite table, and a JSON document.
Think for a minute about managing that transition. I’m not even going to try to show how the code might look.
By contrast, with JSON, you have this diagram:
All it takes is overwriting the phone number entry with an array. It’s even easy to handle backward compatibility. You could simply check at runtime whether the phone entry was a single value or an array.
Scalability
Up to now, everything I’ve talked about works entirely stand-alone on a device. That’s powerful, and takes care of a lot of uses. Some mobile databases stop there. They work stand-alone only.
If you’re using a database, chances are some backend is at least a nice to have. Or, it could be critical to your success. Simply providing backups to make switching devices effortless comes to mind, if nothing else.
Once you start needing a backend, you have to worry about several new challenges. This brings me to my last point about Couchbase Mobile. CBM has many features to address off-device use.
Going back to what I find most compelling, the concern that stands out here is scalability. What’s it going to cost to handle 10,000 users, or maybe even 100,000 or a million? Can your architecture even support off-device operations without a lot of rework?
CBM includes something called Sync Gateway. Sync Gateway (SG) has some cool uses just in combination with Couchbase Lite. Where it really shines is as a replication endpoint for Couchbase Server. Couchbase Server is an enterprise-ready, heavy-duty NoSQL package already used in major installations. You can read more about Sync Gateway here. The following image gives an idea of how the components fit together.
Bottom line, CBM doesn’t box you into a corner. Getting started is easy, and you can do it knowing CBM has the flexibility to handle your needs as you progress.
Wrapping up
CBM is a modern, document-based, highly scalable NoSQL solution for mobile.
- CBM works great in isolation, on-device.
- Couchbase provides a complete back end, if you want it.
- The data format maps easily to native representations.
Together, that gives you a solution that’s easier to use for almost any project. Use it as a convenient store for user preferences. Use it to deliver a static bundle of data along with your app. Or, use it when you want to shoot for millions of active users. Enjoy the simplicity, and know you have the flexibility to adapt and scale as you need it.
Postscript
There are a lot of details behind the concepts I’ve discussed. I’ve included some references for further exploration, although I’ve relied on many more for this post.
You can follow me on Twitter @HodGreeley
I look forward to talking with you.
This post originally appeared on http://blog.couchbase.com/.
Trackbacks/Pingbacks