JonoonDB

Introduction

JonoonDB is a multi-model database. It aims to do what specialized databases (row stores, column stores, nosql stores etc.) do at equal or better performance.

Not another database! Don't we have enough already?

Well we have too many, somewhere north of 100. But the real question is why do we have so many databases. If it’s a solved problem, we should have maybe less than 5 right? The truth is a lot of databases just cover a thin vertical slice of the overall data use cases. We need a database that can cover all the data uses cases or at least try. JonoonDB is an attempt to write such a database.

So you want to write a general purpose database. That's nuts. You cannot have one size fit all.

I would agree if we were talking about a pair of shoes. But we are talking about a pretty sophisticated piece of software (JonoonDB) that is already catering to a wide range of use cases.

I keep hearing "wide range of use cases ". What are these use cases?

The most important ones are:

1. Handle complex schema (Nesting, lists etc.)
2. Handle schema evolution
3. Handle OLTP and OLAP queries
4. Handle high concurrency
5. Handle fast get/put of entire records
6. Support SQL

Ok I see, you want a database that can have the best qualities of a row store, column store and a NoSQL document store. But how is it even possible?

The secret sauce is that JonoonDB internally keeps the same record in many different forms. This allows JonoonDB to behave as a row store, column store or a document store depending upon the query. JonoonDB's query planner is even smart enough to use these different forms in a single query plan to perform really fast queries.

Wouldn't keeping data in many different forms make the writes extremely slow?

JonoonDB uses a row oriented format for on disk representation. Also, it allows the user to create different kinds of indexes (InvertedCompressedBitmaps, Vector and more to come.) that are only stored in memory. Keeping the indexes in memory allows us to do very fast inserts as compared to traditional databases.

So you are an in-memory database right?

No. Everything you write to the database is reliably written to the disk in a transaction. It’s even protected against process and OS crash. However, to get the best performance the indexes need to fit in memory and that is a recommendation that all leading database have so there is nothing new here.

But what happens when the process restarts?

The indexes have to be rebuilt and that can take time proportional to your database size. It will reduce your database availability and the way we propose to make JonoonDB highly available is to use replica sets (Part of the JonoonDB roadmap).

Are there any other benefits?

Damn skippy!

• No Polyglot: With JonoonDB you don't need to replicate the same data in multiple specialized databases.
• Embeddable: JonoonDB is shipped as a library so you can embed the database in your process. This means you can avoid network round trip and achieve in-memory speeds.
• NoORM: If your application uses the same storage format as JonoonDB then you can avoid the mapping between application and database format. Currently we only support flatbuffers but in future we will support other popular formats such as Cap'n Proto and Protobuf.
• Cross platform: Supported on Windows, Linux and Mac OS X.
• LGPL license: Can be used in both open source and closed source projects.
• Extensible: JonoonDB allows you to plugin your custom indexers and encoding formats.