Facet peformance

[Felipe Leusin]

We're developing a new product at my company and we're considering the database engine. From my experience Raven would be a good fit but there is one requirement that i'm in doubt. We're going to have to provide "live" statistics based on multiple criteria. My initial idea was to use a Map/Reduce and be done with it but as we went further I realized that I would have to calculate the stats for every single possible relationship and this wouldn't be practical. So I wondered if I couldn't use Facets to provide those stats for me.

Basically let's suppose I have an Order object that has a { ShopId, SellerId, BuyerId, Status (Open, Completed, Failed), ...bunch of Props }. I have to provide how many orders a seller has with a buyer and how many orders a seller has with given shop and the same stats for the Buyer and a given shop, grouped by the Status.

What is the better alternative? Having a single Orders_Index that I query and generate facets grouped by the status? Having a Map/Reduce? Or just creating a OrderStats and caching it in Raven, so that when a order is updated we would update the related OrderStats documents accordingly?

[Chris Marisic]

I'd possibly consider a roll up document. Perhaps one per seller and one per store (or one per seller, and one per store-to-seller).

Then making reporting of this a first class aspect of the system (and not a byproduct that the database lets you run 'magic' queries no matter what side effects they cause for locking that giant SQL queries provide.)

If the data was to reset daily or weekly i'd then do reports/seller-id/20160518 if i wanted days, reports/seller-id/May2016Week1 for weeks and etc .

[Gleb Chermennov]

I would say it depends on your use case. If you want your stats reflecting most recent data, then it's better to update a OrderStats document each time your add an order. If you can tolerate some delay - use an index/faceted search. When you'd like to change your facets, redeploy process will take longer because you may need to change your index definition (e.g. add a field).

среда, 18 мая 2016 г., 17:11:46 UTC+3 пользователь Felipe Leusin написал:

[Felipe Leusin]

Yeah,

We could use the delay but after some tests we ended up going with a OrderStats document for each combination we needed that are updated asynchronally using a ServiceBus queue. Using semantic ids + ETags caching on Redis we skipped indexing completely and got a very good solution.