On November 20, the development team took a break from planned sprints to investigate the potential of Dgraph. We currently use Azure CosmosDB graph database with the Gremlin API. However, we’ve run into some limitations with it, mostly concerning speed, so our plan for the day was to look into whether using Dgraph could yield improvements on that front
We wanted to import a large amount of product data for our proof of concept: millions of products in thousands of product categories, with tens of millions of attribute values. A VM (virtual machine) with Dgraph was set up and the experiment began. We started by testing bulk inserts, to see if it was possible to quickly import large quantities of product data. The C# client hasn’t yet been officially supported, but we thought we’d give it a go and see how it panned out. We soon found that it was indeed not finished. The implementation of queries seemed to run smoothly and quickly, without errors or exceptions occurring. However, we noticed that the data wasn’t visible in Dgraph’s Ratel interface. Upon closer examination, an error was found in the .NET client library code. There was a line of code missing, which meant that database transactions were not being committed. We added the missing line of code to our version of the library, which then made it possible to do bulk inserts.
After a nice lunch, a match or two of table tennis, and a patched library, we got back to work. Our focus shifted to reading data in order to display product information neatly and quickly on users’ screens. A query that took a second in CosmosDB was processed in ten milliseconds by Dgraph, which was a huge step forward. We also noticed similarities between Dgraph’s query language and GraphQL, something we’re familiar with. Where before we had to wrestle with CosmosDB to produce fast queries, Dgraph was able to give us quicker, better results. This has given us great confidence in continuing to test and work with Dgraph. Overall, the day was successful with positive results.