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.
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
@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. –