Posted by Ian Holsman
Wed, 16 Apr 2008 19:39:00 GMT
From "Don't be Evil" to "We don't need to be Evil".
because its true.
This yahoo/msft/aol/newscorp thing is just noise to them.
James pointed me to Latrz, which to me is a delicious clone. I'm guessing it was written in a day. My recent experience and It highilghts a couple of things to me
- Having the user api just makes sense for google in so many ways. I wish they would have chosen OpenID for openness, but If I was in thier seats I wouldn't have.
- the next great idea will be written with appengine (or on a clone). it's just too easy not to. I was on a conference call yesterday, and while listening I nearly coded up a django picture gallery and voting tool. now I would have been done if I actually remember WTF I was doing (I haven't coded a django app in about a year and a half now).
- it is easier to just upload it on appengine than go through operations, and even copy it to a hosted machine I run.
- I don't see the lock in anymore. If google announced this about a month ago, I would have a SoC project proposed to write a GFS-SQL parser for Hbase and Hypertable. (Anyone see the irony/joy of getting google to pay for it's competition?) and it would have been done.
Posted in Business Related | Tags appengine, django, google | 3 comments
Posted by Ian Holsman
Sat, 12 Apr 2008 16:15:00 GMT
on a previous post about appengine, noodl asked a good question
How does a lack of joins stop web developers from writing slow apps? Surely having to write more queries or denormalising a schema makes things slower?
I was doing to write a long diatribe here (actually I did, and just deleted it).
by removing joins it forces the developer to work, and stop and think about what he is doing. writing that 'cool' 3-5-table join using all inner selects and left joins, while easy to type and runs great on a small dataset but usually sucks in performance. those queries can sometimes be rewritten into a set of SQL statements and a for-loop without much work by a developer. but usually these things are found about 1 week prior to launch (or 1 week after depending on if you ditched that performance QA phase when things were getting tight).
the usuall approach to these kind of things is even more 'coolness' you get to add a caching layer on top of your app. so instead of doing the 3-5 table join, you just get to do it for a single user every couple of hours when the cache expires, and add another layer of complexity for your operations team to maintain
The other approach I've seen used to great effect is pre-caching. in this example you can do it at the database layer. you take those 3-5 table join statements and just execute them in batch mode and store those results in a de-normalzed table. the web pages then reads that table instead.
so to answer your question directly. lack of joins stops web-developers from writing bad queries that the user have to wait on (and use memcache for) and they can either write the query using multiple selects (which can be faster in some cases, a wash in others, and slower in some as well) or query denormalized tables holding pre-computed results which is the fastest way.
updating the tables may be slower, but if you use async writing mechanisms the user wont be waiting for the write to occur. you may need to be a bit smart when a user has just updated something and your waiting for your writer to finish, but for most requests you can avoid that if you know the results will be there within a second/minute or so. or you can devise some sync/async writer where your update page updates some things so that the user knows it's been updated, but his friends might see the update a bit later
Tags appengine, caching, db, memcached | no comments
Posted by Ian Holsman
Fri, 11 Apr 2008 03:57:00 GMT
so i had some more time to thing about appengine, and the biggest problem I can see is the lock-in. all the other things are minor
Krow weighs in about people's complaining about lock-in. Initially I thought so too, as there is no equivalent to GQL. but then I remember about hbase and hypertable. Once some open source guy writes a GQL clone the platform is open and I see multiple hosting providers offering it as an alternative. personally I think the lack of joins a bonus. it prevents web developers from writing slow apps ;-)
the lack of language support is temporary.. I mean how hard would it be to make java not be able to access the local file system or jni? just replace/overwrite some jar files (unless you have legal issues that preclude someone doing that).
but it is still a 3rd platform, and definatly a boon to python guys. now.. what to call the generic version? Python Hadoop, And Gql (PHAG?)
Posted in Development | Tags appengine, google, python | 2 comments