It sounds like your game has a relatively small amount of rapidly mutating data. In general, this is the kind of thing that GAE is bad at. GAE is great for large amounts of data, each piece of which changes slowly. Aside from the read and write cost, there is an update limit of one transaction per "piece of data" per second which can be very challenging to work around.
Your 1GB database easily fits in RAM, even if it grows 10X that size. It will work well with a storage system optimized for resident memory, giving you fantastic read and write throughput. This includes most RDBMSes and some NoSQL stores like MongoDB. You can get thousands of queries per second out of single instances. The GAE datastore is optimized for datasets which cannot fit in RAM. Fetches are relatively glacial, often taking tens of milliseconds. The good news is that this performance will be consistent even when you have 10 petabytes of data. The bad news is that you don't care, because you only need to store a few gigs and what you really need is fast (and cheap!) transactions. If you want a PaaS solution to cut out some of the maintenance headaches, consider Heroku or Appfog. If you want to try something exotic, look into EC2's DynamoDB, which is supposed to be blistering fast. Although - since your dataset fits in RAM, you probably are best to stick with the database you already know - MySQL. Nothing is faster than a fetch from RAM. Jeff On Tue, Sep 13, 2011 at 4:03 AM, Karel Crombecq <[email protected]> wrote: > Hey Jay, > > I actually registered yesterday on your game to get an idea of a game hosted > on GAE. I'm enjoying it! > > But the new pricing greatly disturbs me. I'm not sure if running this game > on GAE is actually viable at all in terms of costs. I did some research on > the new pricing (for example > http://code.google.com/appengine/kb/postpreviewpricing.html#operations_charged_for) > and as far as I can see, datastore reads and writes both have a similar > cost. And they don't charge per query, but they charge per object (row) > fetched. > > I did some calculations on my current database data, and CQ2 generates about > 1M database writes for something like 650 daily users. That's about 3 times > as much as your game does, which would also triple the bill. That's a lot, > but something I can handle. Since most of the writes are one-record only, > the total cost would be $1,5 per day for 1000 users. > > However, the datastore reads are the real issue here. I have about 4M SELECT > queries for 650 users. Considering that many of these return more than one > row, I can easily reach 10M datastore reads each day, for an additional cost > of $2,8 each day. > > This results in a total of €159 per month, for 1000 users. My estimations > for the Amazon cloud were a cost of $65 per 1000 users each month (based on > our current system and their instances), which would make GAE 3 times more > expensive. That's quite worrysome, even though these statistics were > generated based on relational database writes as opposed to datastore > writes. It's hard to predict if I will need less or more datastore > operations to achieve the same result. I'm actually thinking less, because I > can cache a lot of static data into memory. > > > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine/-/_-Bf3oAZxu8J. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
