Thanks for mentioning this: I didn't know they had added this feature; that definitely makes some of the data modeling problems easier. Without this, I found it often led to situations where you had to make horribly painful decisions that affected both functionality and scalability very early on in your project lest you end up with tons of data that you now have to programmatically and mostly manually migrate (which is why, to me, I keep being surprised that you keep mentioning ops challenges for normal databases: with the ability to do global schema and index changes concurrently and safely inside of transactions, I found the amount of time and thought I need to put into managing something like PostgreSQL a fraction of most alternatives that supposedly scale better).
Re:Streak brings CRM to the inbox with Google Cloud Platform
by saurik on Tuesday October 09, 2012 @09:45PM
(#4634714)
>... especially with cross-group transactions (added last year)...
* You must be careful of entity group boundaries. This ends up being fairly easy to do, especially with cross-group transactions (added last year). It's definitely a design consideration, but one you internalize very quickly and as long as you don't screw up your database design, isn't a scaling bottleneck.
* Tablet splitting. If you write monotonically increasing values to one index at high rates (1k/s is what I've heard, but I haven't hit it myself) you may have to work around this issue by federating the index. It's not pretty, but it's not a common problem.
I agree that traditional RDBMS architectures can handle quite a lot of traffic before they hit a wall. It's just a lot more ops work. What I like about GAE-land is that you just have to be a little more careful in your data modeling and you can stop worrying about all the usual problems like monitoring the performance of your database server. I've built rather large sites on RDBMSes in the past, and getting the ops right was always painful.