Summary of Talking Points in the Webinar:
The more complex the application, the more meat there is to talk about, so we will use a sample application on Microsoft called eShopOnWeb. The focus is on the data rather than the UI or containers. We are focusing on how to optimize a data layer on RavenDB.
We are taking the most basic example you can have for a sample application, an online shop.
In the relational database, you have seven tables, OrderItems, Catalog, CatalogTypes, Orders, CatalogBrands, BasketItems, and Baskets. You also have four foreign keys. How much trouble can you get in using a relational database for such a small application? You’d be surprised, and you can get into quite a mess.
We set up NHibernate Profiler. Its main purpose is to tell you what’s going on between your application and the database. In many cases, this can be hard to figure out.
The Profiler is a referee to tell us which database is working better with the application and shaving time and workload off your application processes. I can look and see all the interactions between the application and the database from startup, to login, to the rendering of the homepage. Things like getting an item from the catalog, getting a type of item from the catalog, give me all items the user has purchased, give me all items the user might like.
You can see that for the relational database, there are a lot of queries made to the database to render a single page.
In the source code, we are calling the database from a loop. I have a basket of items, and I am telling my application to loop through every item in the basket and call the database and get it for each item. If I have 20 items, I need to call the database 20 times. Ouch!
This is the dreaded select n+1 issue that forces you to keep asking your database, “is there any more in this query?” until the answer is no.
This is a trivial application using the most simple database solution, and we can see right away costly efficiencies that hurt performance.
As you expand your cart to include things like discounts, special deals, whether or not this customer is a valued customer, buying history, the complexity, and cost in trips to the database can rise exponentially. Even when your code is correct, there can be performance errors that you only detect once your application goes to production, and thousands of users are accessing it every minute.
What RavenDB Does for Your Application and Income Statement
RavenDB was created to slash these very types of complexities to return efficiency to your database, and especially how your database interacts with your applications and your users.
According to Google, for every additional 100ms of performance lost, 1% of sales were reduced. Some of the features of RavenDB make business applications go a lot faster. The performance and efficiency gains RavenDB gives you will net real increases in sales.
Once you decide to move your data to RavenDB, the benefits immediately begin:
RavenDB will recommend a migration strategy for you once you tell it what needs to be moved and where it is coming from. RavenDB will also give you the configuration on the spot. RavenDB transforms your data from relational to document form for you.
Once you migrate your data, the first advantage you will see is that indexes will start to appear as you make queries. RavenDB’s automatic index feature will create and optimize indexes for every query to make sure you are retrieving your data in the best way possible.
The greatest enhancement is that nothing here is super groundbreaking. There aren’t any changes you need a PhD for. The bread and butter of business applications are that they are supposed to be simple – and they are. RavenDB works with this to keep things simple.
Skip to Navigation
