« Stuff The Internet Says On Scalability For January 17th, 2014 | Main | SharePoint VPS solution »

Vedis - An Embedded Implementation of Redis Supporting Terabyte Sized Databases

I don't know about you, but when I first learned about Redis my initial thought was wow, why hasn't anyone done this before? My next thought was why put this functionality in a separate process? Why not just embed it in your own server code and skip the network path completely? Especially in a Service Oriented Architecture there's no need for an extra hop or extra software installation and configuration.

Now you can embed Redis-like code directly into your server with Vedis - an embeddable datastore C library built with over 70 commands similar in concept to Redis but without the networking layer since Vedis run in the same process of the host application. It's transactional, cross platform, thread safe, key-value, supports terabyte sized databases, has a GPL-like license (which isn't great for commercial apps), and supports an on-disk as well as in-memory datastore.

More about Vedis:

Unlike most other datastores (i.e. memcache, Redis), Vedis does not have a separate server process. Vedis reads and writes directly to ordinary disk files. A complete database with multiple collections, is contained in a single disk file. The database file format is cross-platform, you can freely copy a database between 32-bit and 64-bit systems or between big-endian and little-endian architectures.

Vedis is a self-contained C library without dependency. It requires very minimal support from external libraries or from the operating system. This makes it well suited for use in embedded devices that lack the support infrastructure of a desktop computer. This also makes Vedis appropriate for use within applications that need to run without modification on a wide variety of computers of varying configurations.

Related Articles 

Reader Comments (5)

The point of network redis is a *shared* datastore to use among multiple processes. So, I don't see the value in this over other embeddable DB systems like SQLite or even BDB.

January 15, 2014 | Unregistered CommenterJeremy Wilson

Is there any more info on performance anywhere? The only mention of anything vaguely related is the claim of 'Terabyte sized' databases. But no description of data structure in docs as far as I can see. I can make a terabyte sized database very easily. Making it fast enough to be usable is quite a different matter.

Redis has some nice features which I can see some value in porting to be (re)usable on top of other embedded engines. But seems to be a fairly niche need. I question whether it really adds value to use Redis wire format commands as strings to the API though - that's just a lot more work and indirection for no gain. Redis format is not some expressive language like SQL that has value in itself or is useful to make portable expressions, it's just a pragmatic and simple RPC protocol. Implementing it as an API for in-process library calls just seems bizarre to me.

To put that another way: Redis is described as a "data-structure server" if you take the server away you just have "data-structures" but no info is actually given about how the data IS structured to be performant and the wire protocol of the server part has been retained despite no longer being necessary. Jeremy hit the nail on the head - being a shared resource for other nodes is really the whole point of Redis.

If anyone has used or benchmarked Vedis or has insight as to what really motivated it I'd love to hear that.

January 19, 2014 | Unregistered CommenterPaul Banks

Why expose a shared resource as data? Why not expose it has a higher level service, one that will probably take the data, apply transforms to it, and then return a higher value payload back?

January 19, 2014 | Registered CommenterTodd Hoff

how is it different from other embedded data store like berkley db?

January 20, 2014 | Unregistered Commenterpradheep

@Todd: jeremy is talking about sharing data between multiple instances of the same application, to effectively enable clustering, and thus scalability of a single logical service. I agree with Jeremy, and clearly Vedis does not reach for the same goals as Redis or memcached. They should not be compared... The use of a slightly deviated name (Vedis vs Redis) suggests a relationship that is to me non existant

January 22, 2014 | Unregistered CommenterDavidM

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>