Nuget Perf Problem, Part II–Importing To RavenDB
The first part of actually showing how RavenDB can handle the NuGet scenario was to actually get the data to RavenDB. Luckily, NuGet makes the data accessible using OData, so I quickly hacked up the following program:
using (var store = new DocumentStore { Url = "http://localhost:8080", DefaultDatabase = "Nuget" }.Initialize()) { string url = "https://nuget.org/api/v2/Packages"; while (true) { Console.WriteLine("GET {0}", url); if (url == null) break; var webRequest = (HttpWebRequest)WebRequest.Create(url); webRequest.Accept = "application/json"; using (var resp = webRequest.GetResponse()) using (var strema = resp.GetResponseStream()) { url = WritePackagesToRaven(strema, store); } } }
This is imply going to NuGet and asking for the packages in json format. It is very easy for us to work with json data with RavenDB, so that is what we are doing.
The next stage is to actually read the response and write the packages to RavenDB, this is handled here:
private static string WritePackagesToRaven(Stream strema, IDocumentStore store) { var json = RavenJToken.ReadFrom(new JsonTextReader(new StreamReader(strema))) .Value<RavenJObject>("d"); using (var session = store.OpenSession()) { foreach (RavenJObject result in json.Value<RavenJArray>("results")) { ModifyResult(result); session.Advanced.Defer(new PutCommandData { Document = result, Metadata = new RavenJObject { {"Raven-Entity-Name", "Packages"} }, Key = "packages/" + result.Value<string>("Id") + "/" + result.Value<string>("Version") }); } session.SaveChanges(); } return json.Value<string>("__next"); }
I am not really sure why we have this “d” as the beginning of the json results, but that is what NuGet returns. We iterate over the query results, and write all of them to RavenDB.
You might note that we use the Defer() option, which means that we can rely on the session to handle batching for us and only go to the server once, when we call SaveChanges(). We also set the document metadata to be pretty basic, merely indicating that this should go on the Packages collection. Finally, we set the id to be composed of the package id and the version, resulting in a unique and human readable key for the imported package.
Note that we return the next page location, and continue on working on that in the next page loop.
There is one thing that we need to do, the NuGet data is still highly relational, and quite ugly at times. For example, let us take Tags and Dependencies. Here is how they show up in the raw results:
- Dependencies: AboditUnits:1.0.4|Autofac.Mef:2.5.2.830|ImpromptuInterface:5.6.2|log4net:1.2.11
- Tags: Ian_Mercer Natural_Language Abodit NLP
That isn’t a really nice way to work with the data, so before we save the results to RavenDB, we modify it slightly.
private static void ModifyResult(RavenJObject result) { var tags = result.Value<string>("Tags"); if (tags != null) { result["Tags"] = new RavenJArray(tags.Split(new[] {' ', ',', ';'}, StringSplitOptions.RemoveEmptyEntries)); } else { result["Tags"] = new RavenJArray(); } var deps = result.Value<string>("Dependencies"); if (deps != null) { result["Dependencies"] = new RavenJArray(deps.Split(new[] {'|'}, StringSplitOptions.RemoveEmptyEntries) .Select(s => { var strings = s.Split(':'); return RavenJObject.FromObject(new {Package = strings[0], Version = strings[1]}); })); } result.Remove("__metadata"); }
Finally, let us take a peek at RavenDB and see how the results look like there:
Now that is much more like it.
On my next post, I am going to show how to do some queries againt this data, which currently have about 66,483 results.
Comments
That 'd' is part of the serialization that occurs from WCF...
I believe there's small typo in "how to do some queries again this data"
Arnis, Thanks, fixed.
Here is the explanation for the 'd' http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx
I believe there's still small typo in "how to do some queries againt this data" :D
Will this be a downloadable sample when your done? If so good thinking. It's complex enough to be useful but a familiar domain for most of us.
It would be great if Raven had an OData endpoint -- especially since WebAPI stripped out their OData [queryable] tag for a future release.
Best we can do currently is to wrap Raven with Linq2Rest.
Comment preview