I made the image a link over to the official Activity Lifecycle documentation on http://developer.android.com, which contains a nicer, larger version of the image in this post, along with a better explanation of the activity lifecycle.

Thanks for the feedback!

Only reason I’m complaining :)

That’s a lot of documents :) For the project I described in this blog post, we used daily summary documents (taking advantage of the document’s schema-less nature) to avoid having to deal with millions of individual, detailed docs. So, we’re dealing with hundreds of documents at a time, not millions.

MongoDB 2.2, which was just released, sports a new aggregation framework (http://docs.mongodb.org/manual/aggregation/). You may want to take a look at this to see if it supports what you will want to do, reporting wise. It seems much more powerful than the map/reduce in earlier versions of MongoDB, and includes a few features aimed at dealing with large data sets (early filtering, sharded operation, etc). However, this framework does have limitations that are clearly documented. So, you’ll certainly want to create a prototype with a large data set to make sure it can do what you want it to do.

In my opinion, you can’t beat a relational database on a big server with a lot of RAM for reporting.

Interesting article!
As i see you have an extended knowledge about using mongodb :), currently i’m working
on deploying mongodb for a system, but i have more than 5 millions documents stored
in a collection, how may i deal with reporting, statistics stuffs?

Do you think it’s good idea to adapt MapReduce to accomplish it?
I’m afraid it takes long to load because it’s an “almost” real time and report system.

Thank you again John! :)

I also think it’s interesting thinking about building a client library across multiple languages and how your thoughts about the API methods might change. Think that would have any impact?

I haven’t used Bugzilla since I wrote this blog post in 2008. So, unfortunately, I can’t help.

John

I have installed bugzilla 4.2.1 on centos 6.2 and it is working fine, but when I try to send create new account invitation it will show the following:

A confirmation email has been sent containing a link to continue creating an account. The link will expire if an account is not created within 3 days.

But the client/user is not receiving any bugzilla mail.

Thanks in advance,
Ravindra

Thanks for the comments.

1) The document represents a day in the user’s time zone. The time zone in the “date” field is not used. So, the user is stuck with this timezone, but not forever. The summary documents summarize data that is stored in our MySQL database. If necessary, we can always rebuild them for a user based on a new time zone.

2) The 502ms is for the full HTTP request, and not just the database query. I don’t have the breakdown, but I don’t think MongoDB was a big part of that time. I think much of it was spent in Ruby/Rails code (we fetch the documents from MongoDB, and then sum the data using Ruby code), and the HTTP request in general. If I’m able to track down the breakdown of that request, I’ll post it here.

1) Since you’re summarizing daily, does that mean you just pick a timezone and stick with it forever? In the code sample it looks like you’re using UTC, but you’re based in the US. Is it an issue to people looking at the reports that the “days” are 6-8 hours off of what they might be expecting? (This is something I’m trying to plan around).

2) Maybe I’ve misread the conclusion, but if it takes on the order of a half a second to run a report that’s querying 30 rows, that still seems about an order of magnitude too slow, no? At least, coming from a relational background, I would expect this to be a tens-of and not hundreds-of millisecond operation. Do you think this this because you wound up having to do the summations post-facto, Ruby?

Thanks again for sharing the article.

Also, I know you’re interested mobile optimization of applications – something we’re focusing on heavily this year. I think there will be a treasure trove of projects there that’ll get you excited.

I agree that practice doesn’t make perfect, but perfect practice isn’t necessary (or sufficient) either. It takes practice and reflection. This is exactly what you did at that retreat: practice, then think about how you did it, what you did well, what you could do better. Devoting a portion of our mind during practice to recording what we’re doing, and then reviewing and reflecting on those observations and the results later — that’s how we get better.

Practice and reflection! it’s my motto. (one of many)

We’ll be having another one on the day after the Software Craftsmanship North America conference. Look for the registration to go up sometime soon.