DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • DZone's Article Submission Guidelines
  • Avoiding Pitfalls With Java Optional: Common Mistakes and How To Fix Them [Video]
  • Comparing Cloud Hosting vs. Self Hosting
  • Competing Consumers With Spring Boot and Hazelcast

Trending

  • DZone's Article Submission Guidelines
  • Avoiding Pitfalls With Java Optional: Common Mistakes and How To Fix Them [Video]
  • Comparing Cloud Hosting vs. Self Hosting
  • Competing Consumers With Spring Boot and Hazelcast

Benchmarking RavenDB 4.0 vs. CouchDB

RavenDB's lead developer puts version 4.0 to the test against CouchDB. According to the benchmarking, RavenDB handles inserts four times faster than CouchDB.

Oren Eini user avatar by
Oren Eini
·
Jan. 06, 17 · Analysis
Like (3)
Save
Tweet
Share
6.50K Views

Join the DZone community and get the full member experience.

Join For Free

I ran into this post, which was pretty interesting to read. It compares a bunch of ways to index inside CouchDB, so I decided to see how RavenDB 4.0 compares.

I wrote the following code to generate the data inside RavenDB:

public class User
{
    public int Score;
    public string Name;
    public DateTime CreatedAt;
}

private static char[] _buffer = new char[6];
private static string RandomName(Random rand)
{
    _buffer[0] = (char)rand.Next(65,91);
    for (int i = 1; i < 6; i++)
    {
        _buffer[i] = (char) rand.Next(97, 123);
    }
    return new string(_buffer);
}
static void Main(string[] args)
{
    using (var store = new DocumentStore
    {
        Url = "http://localhost:8080",
        DefaultDatabase = "bench"
    }.Initialize())
    {
        var sp = Stopwatch.StartNew();
        using (var bulk = store.BulkInsert())
        {
            var rand = new Random();
            for (int i = 0; i < 100*1000; i++)
            {
                bulk.Store(new User
                {
                    CreatedAt = DateTime.Today.AddDays(rand.Next(356)),
                    Score = rand.Next(0, 5000),
                    Name = RandomName(rand)
                });
            }
        }
        Console.WriteLine(sp.Elapsed);
    }
}


In the CouchDB post, this took… a while. With RavenDB, this took 7.7 seconds and the database size at the end was 48.06 MB. This is my laptop, a 6th gen i7 with 16 GB RAM and SSD drive. The CouchDB tests were run over a similar machine, but with 8 GB RAM, but RavenDB didn’t get to use much memory at all throughout the benchmark.

It is currently sitting on a roughly 205MB working set and allocated a total of 70 MB managed memory and 19 MB of native memory.

I then created the following index:

image

This does pretty much the same as the indexes created in CouchDB. Note that in this case, this is running in process, so the nearest equivalent would be Erlang native views.

This took 1.281 seconds to index 100,000 documents, giving us a total of 78,064 indexed documents per second.

The working set grew to 312MB during the indexing process.

But those were small documents. What about larger ones? In the linked post, there was another test done, this time with each index also having a 300KB text property. Note that this is a single property.

The math goes like this: 300KB * 100,000 documents = 30,000,000 KB = 29,296 MB = 28.6 GB.

Inserting those took 1 minute and 40 seconds. However, the working set for RavenDB peaked at around 500 MB, and the total size of the database at the end was  512.06 MB. It took me a while to figure out what was going on.

One of the features that we have with the blittable format is the fact that we can compress large string values. The large string property was basically lorem ipsum repeated 700 times, so it compressed really well. And the beauty of this is that unless we actually need to touch that property and do something to it, it can remain compressed.

Indexing that amount of data took 1.45 seconds, for 68,965 indexes documents per second.

My next test was to avoid creating a single large property and go with a lot of smaller properties.

var entity = new User
{
    CreatedAt = DateTime.Today.AddDays(rand.Next(356)),
    Score = rand.Next(0, 5000),
    Name = RandomName(rand),
};
for (int j = 0; j < rand.Next(150,1500); j++)
{
    entity.CustomProperties[RandomName(rand)] = Random600CharString(rand);
}


This generates 100,000 documents in the 90–900KB range. Inserting this amount of data took a while longer. This is mostly because of the amount of data that we write in this scenario, which is in the many GB range. In fact, this is what my machine looked like while the insert was going on:

image

Overall, the insert process took 8:01 minutes to complete. And the final DB size was around 12 GB.

Indexing that amount of information took a lot longer and consumed a few resources:

image

Time to index? Well, it was about twice as much as before, with RavenDB taking a total of 2.58 seconds to index 100,000 documents totaling 12 GB in size.

That comes to 38,759 indexes documents per second.

A large part of that is related to the way we are storing information in blittable format. We don’t need to do any processing to it, so we are drastically faster.

Comparing to the CouchDB results in the linked post, we have:

  RavenDB CouchDB
Small documents 78,064 19,821
Large documents 38,759   9,363


In other words, we are talking about being four times faster than the faster CouchDB option.

Document

Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • DZone's Article Submission Guidelines
  • Avoiding Pitfalls With Java Optional: Common Mistakes and How To Fix Them [Video]
  • Comparing Cloud Hosting vs. Self Hosting
  • Competing Consumers With Spring Boot and Hazelcast

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: