7

Aparentemente, el motivo de la arquitectura de BigTable tiene que ver con la dificultad de escalar las bases de datos relacionales cuando se trata de la enorme cantidad de servidores con los que Google tiene que lidiar.¿Qué aspecto de las bases de datos relacionales les dificulta escalar lo suficiente en servicios como Google App Engine?

Pero, técnicamente hablando, ¿qué es exactamente lo que hace que sea difícil escalar las bases de datos relacionales?

En los centros de datos empresariales de grandes corporaciones, parecen ser capaces de hacerlo con éxito, así que me pregunto por qué no es posible hacer esto en mayor magnitud para escalar en los servidores de Google.

Respuesta

3

Además de la respuesta de Mitch, hay otra faceta: los webapps generalmente no se adaptan bien a las bases de datos relacionales. Las bases de datos relacionales ponen énfasis en la normalización, esencialmente, facilitando las escrituras, pero lee más (en términos de trabajo realizado, no necesariamente para usted). Esto funciona muy bien para OLAP, situaciones de tipo de consulta ad-hoc, pero no tan bien para webapps, que generalmente son ponderadas masivamente a favor de lecturas sobre escrituras.

La estrategia adoptada por las bases de datos no relacionales como Bigtable es la inversa: desnormalizar, hacer las lecturas mucho más sencillas, a costa de encarecer las escrituras.

+0

Acepto que la mayoría de las aplicaciones web implican más lectura que la introducción de datos por parte de los usuarios o la aplicación. Pero no entiendo lo que quiere decir cuando dice que las escrituras son "más fáciles (en términos de trabajo realizado)" en un RDBMS normalizado. Creo que el almacén de datos de App Engine es más fácil en términos de trabajo realizado ya que una clave única identifica cada entidad y una actualización es equivalente a una inserción debido al carácter tipo diccionario del almacén de datos. Poner y traer de un diccionario es tan fácil como se puede llegar a hacer, creo. – pacman

+0

@pacman: Olvidaste todo el trabajo que realmente se hizo. El índice es el gran rey del almacén de datos. Cuando agrega una entidad al almacén de datos, realiza una gran cantidad de datos de replicación de trabajo para que, si desea obtener una propiedad, pueda hacerlo rápidamente. Básicamente, escribe índices para cada propiedad, en cada entidad, dos veces (asc y desc), para todos los datos que almacena (quizás no los nuevos Blobs grandes, no estoy seguro). Esto es lo que lleva tanto tiempo escribir, pero también permite lecturas rápidas en una escala alucinante. Sugeriría obtener un buen libro de App Engine, ya que es importante cuando se diseña para GAE. –

6

Cuando realiza una consulta que involucra relaciones que se distribuyen físicamente, debe colocar esos datos para cada relación en un lugar central. Eso, obviamente, no se escalará bien para grandes volúmenes de datos.

Un servidor RDBMS bien configurado realizará la mayoría de sus consultas en páginas calientes en RAM, con poco disco físico o E/S de red.

Si está limitado por la E/S de red, entonces los beneficios de los datos relacionales se reducen.

+0

GRACIAS! Mucho más claro. Comentario original eliminado –

0

La razón principal como se indica es la ubicación física y la red IO. Además, incluso las grandes corporaciones lidian con una fracción de los datos que manejan los motores de búsqueda.

Piense en el índice en una base de datos estándar, quizás unos pocos campos ... los motores de búsqueda necesitan búsqueda rápida, en campos de texto grandes.

Cuestiones relacionadas