Albert Ribera – Intentando ver el árbol y el bosque

20 noviembre , 2007

Arquitectura de ebay

Filed under: ebay,Proyectos — inspirit_bcn78 @ 2:51 am
Tags: ,

Yo no se mucho de arquitectura web, lo suficiente para entender como está montado la arquitectura de un site y cuales son las diferentes partes que conforman una plataforma web. Pero para mi ebay siempre ha sido un referente desde que fui al seminario de Nielsen y me explicaron el modelo de ebay siempre lo he tenido como un referente. Este fin de semana me pasaron un post que me parece muy interesante y curioso a la vez, cómo está montada la arquitectura de datos de ebay, impresionante:

Algunas estadísticas:

  •  De media 26 billiones de consultas SQL
  •  100 millones de items vendibles
  •  212 milliones de usuarios registrados
  •  1 billion de fotos
  •  1 billion de páginas vistas por día
  •  2 petabytes de datos
  •  3 billion de llamadas a la API cada mes
  •  Crecimientos de factor 35 en paginas vistas, emails enviados y ancho de banda desde el 99.
  •  99.94% de disponibilidad web>
  •  15,000 servidores todos J2EE.

Para aguantar esto tienen la siguiente plataforma

  • Todo se planifica y se monta para que aguante x10.
  • Arquitectura dividida por capas: data tier, application tier, search, operations,
  • Leverages MSXML framework para la capa de presentación (incluso en Java)
  • Oracle databases, WebSphere Java (still 1.3.1)
  • Separa la base de dato por acceso primerio, modulo on a key.
  • Cada base de datos tiene almenos 3 bases de datos online. Distribuidos en 8 datacenters.
  • Database copies run 15 min behind, 4 hours behind
  • Databases are segmented by function: user, item account, feedback, transaction, over 70 in all.
  • No stored procedures are used. There are some very simple triggers.
  • Move cpu-intensive work moved out of the database layer to applications applications layer: referential integrity, joins, sorting done in the application layer! Reasoning: app servers are cheap, databases are the bottleneck.
  • No client-side transactions. no distributed transactions
  • J2EE: use servlets, JDBC, connection pools (with rewrite). Not much else.
  • No state information in application tier. Transient state maintained in cookie or scratch database.
  • App servers do not talk to each other — strict layering of architecture
  • Search, in 2002: 9 hours to update the index running on largest Sun box available — not keeping up.
  • Average item on site changes its search data 5 times before it is sold (e.g. price), so real-time search results are extremely important.
  • “Voyager”: real-time feeder infrastructure built by eBay.. Uses reliable multicast from primary database to search nodes, in-memory search index, horizontal segmentation, N slices, load-balances over M instances, cache queries.

Casi nada…

–> Para ver el artículo completo

Anuncios

Crea un blog o un sitio web gratuitos con WordPress.com.