Hacker News Reader

Comment by drawkbox | Hacker News Reader

It isn't really an anti-sorting stance. If you have worked on appengine and with Google File System you will see that it is fast almost solely because there is no complete dataset. So sorting is really tough on 64K or 64MB chunks spread around many many machines. Google is so fast and scalable exactly because there is no complete dataset easily attainable. GFS works in 1000 item chunks and that is about the best you can get with that setup. Searching, counts/increments and metadata about ALL of your data in the GFS or email in this case, is a tough problem. The same underlying data system is used for gmail, reader, etc.

View on HN

Why does it have to be a 'sorting' stance? Why can't you just search for something like 'size:>1MB' to get all emails that are larger than 1MB? Even if they aren't 'sorted' one can easily scale the search to narrow in on really large attachments.

I wonder how difficult it would be for them to create a metadata file per account that would only contain things like sent from, sent to, size, subject, date sent (standard email metadata). Then if someone wants to go digging around, send the metadata down as JSON and let the sorting happen client side and let the client return the order the messages should render.

It is possible but it also means creating more data. I could easily see this being a pay element to gmail in the future. Basically it could be almost like a bot/spider/worker that gets a fairly recent snapshot of your data as metadata and allows you to clean up or organize based on it. It could be pretty tasking though and may need alot of engineering because right now your gmail data might be spread across thousands of machines. With more data/years this only going to get more tasking and costly.

At a certain point with data we have been living in a relative small sandbox in terms of data. As our lives spread to terrabytes of data and across many services, we to will be unable to run atomic operations on the whole of your data.

Every time you mention GFS, you're really talking about Bigtable (which happens to be built on top of GFS)

Yes I say GFS because that is the core of why it is this way. From search to reader to gmail etc. All google data operates this way because of the architecture.

It is all in 1000 buckets. Ever gone beyond page 100 in google results? You can't. Even though there are millions of results you can only get to page 99 at 10 results per page because it too is built on GFS.

You are correct: http://www.google.com/search?q=blue&start=1000

> Sorry, Google does not serve more than 1000 results for any query. (You asked for results starting from 1000.)

Results 811 - 817 of about 687,000,000 for test [definition]. (2.19 seconds) after seeing this, I doubt whether 687,000,000 is correct or not..

Term counting is the hello world of map-reduce examples, so while that number is obviously not exact (exactly 687 million?), it's reasonably accurate, considering the actual use of the count, which is more useless the bigger it is. No one created the opposite of Google Whack, finding the terms that yielded the most results; that's largely uninteresting when the counts are in the hundreds of millions range.

Found this out working at a Web Consultant when working with a google appliance. Specifically this page: http://bidmc.org/Search.aspx

Thanks for that-had no idea how GFS worked.

Seems like Google could easily treat it as a searching issue rather than a sorting issue, though. It would be easier than full text searching (which it already does).

Gmail does not support rich full-text search -- the indexer used is very limited. Among other things no synonyms, word stems, or subwords are indexed.

This is the biggest problem I have with gmail, and one of the principle reasons why I don't feel I'll be using it "permanently." My search queries very rarely find the emails that I'm looking for.

Thanks for the insight.

Reply on news.ycombinator.com