NuGet Perf, Part III–Displaying the Packages page

the first thing that we will do with ravendb and the nuget data is to issue the same logical query as the one used to populate the packages page. as a reminder, here is how it looks:

select        top (30) 
          -- ton of fields removed for brevity
from        (

            select        filtered.id
                    ,    filtered.packageregistrationkey
                    ,    filtered.version
                    ,    filtered.downloadcount
                    ,    row_number() over (order by filtered.downloadcount desc, filtered.id asc) as [row_number]
            from        (
                        select        packageregistrations.id
                                ,    packages.packageregistrationkey
                                ,    packages.version
                                ,    packageregistrations.downloadcount
                        from        packages
                        inner join    packageregistrations on packageregistrations.[key] = packages.packageregistrationkey
                        where        packages.isprerelease <> cast(1 as bit)
                        ) filtered
            ) paged
inner join    packageregistrations on packageregistrations.[key] = paged.packageregistrationkey
inner join    packages on packages.packageregistrationkey = paged.packageregistrationkey and packages.version = paged.version
where        paged.[row_number] > 30
order by    packageregistrations.downloadcount desc
        ,    paged.id

despite the apparent complexity ,this is a really trivial query. what is does is say:

• give me the first 30 – 60 rows
• where isprerelease is false
• order by the download count and then the id

with linq, the client side query looks something like this:

var results = session.query<package>()
                         .where(x=>x.isprerelease == false)
                         .orderby(x=>x.downloadcount).thenby(x=>x.id)
                         .skip(30)
                         .take(30)
                         .tolist();

now, i assume that this is what the nuget code is also doing, it is just that the relational database has made it so they have to go to the data in a really convoluted way.

with ravendb, to match the same query, i could just issue the following query, but there are subtle differences between how the query works in sql and how it works in ravendb. in particular, the data that we have in ravendb is the output of this query, but it isn’t the raw output. for example, we don’t have the id column available, which is used for sorting. now, i think that the logic is meaning to say, “sort by download count descending and then by age ascending”. so old and popular packages are more visible than new and fresh packages.

in order to match the same behavior (and because we will need it to the next post) we will define the following index in ravendb:

and querying it:

the really nice thing about this?

this is the url for this search:

/indexes/packages/listing?query=isprerelease:false&start=0&pagesize=128&aggregation=none&sort=-downloadcount&sort=created

this is something that ravendb can do in its sleep, because it is a very cheap operation. consider the query plan that would for the sql query above. you have to join 5 times just to get to the data that you want, paging is a real mess, and the database actually have to work a lot to answer this fiddling little query.

just to give you some idea here. we are talking about something that conceptually should be the same as:

select top 30 skip 30 * from data where isprerelease = 0

but it get really complex really fast with the joins and the tables and all the rest.

in comparison, in ravendb, we actually do have just a property match to do. because we keep the entire object graph in a single location, we can do very efficient searches on it.

in the next post, i’ll discuss the actual way i modeled the data, and then we get to do exciting searches .