Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Here is <a href="http://www.infoq.com/presentations/shoup-ebay-architectural-principles" rel="nofollow noreferrer">Randy Shoup on Ebay's Architecture</a></p> <p>He mainly talks about scalability, availability, manageability etc. Schema is something that you ahve to devise on your own based on your specific requirements. <a href="http://www.slideshare.net/deimos/randy-shoup-ebays-architectural-principles" rel="nofollow noreferrer">Slides</a></p> <p>From his <a href="http://se-radio.net/transcript-109-ebay039s-architecture-principles-randy-shoup" rel="nofollow noreferrer">chat transcript</a></p> <p>"It is even a relational database or is it really different?</p> <p>It is a very different. It's a search engine like Google or Yahoo! developed by the same people that developed the AltaVista search engine, and as with many search engines, it's developed on similar principles, which is that it's an inverted index. There's a set of documents with IDs, keywords are indexed into those documents, and query operations happen by intersecting lists or vectors of those keywords, very simply, and there's a lot more detail about how that works. The challenge for -- just as an aside, the challenge for an eBay-style search engine is that our users expect the search engine to be updated in essentially near real-time. When somebody bids on an item that changes the price, and price is a filter that people are very interested in querying on. So it actually means that the style -- the sort of classic web search engine style of "you build the index in a kind of batch mode and then upload it to the search engine" is something that doesn't really work for us. It needs to be a lot more real-time. So I will talk a little bit about how that real-time system works in my asynchrony section, but anyhow, to finish the thought on scalability for search, the idea is that the search engine can be horizontally split. So there is this overall search index of whatever size it is. We divide it up into chunks of ten or twenty or sixty or hundred, and divide the infrastructure that way. And then we have an aggregator piece, which now does do scatter/gather over all those different parts of the index. So somebody queries for "iPod" or "Mickey Mouse" or "Wii" and the aggregator sends the query to each one of the different splits or shards and gets the results back and aggregates them and sends them back to user."</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload