Ejemplo práctico de Bigtable

Question

¿Alguien puede proporcionar un ejemplo real de cómo se estructurarían los datos dentro de un Bigtable? Por favor, hable desde un motor de búsqueda, redes sociales o cualquier otro punto de vista familiar que ilustre clara y pragmáticamente cómo la fila -> columna familia -> columna combinada es superior a los enfoques relacionales tradicionales normalizados.

Answer 1

lectura del original papel blanco Google era útil:

http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/en//papers/bigtable-osdi06.pdf

Como era esta lista completa de fuentes de información sobre la arquitectura de datos de Google:

http://highscalability.com/google-architecture

---

Actualización: 11/4/14

Una nueva versión del Google blanca de papel PDF se puede encontrar aquí:

http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf

Answer 2

Creo que la diferencia radica más en la forma en que se consultan los datos que en la forma en que se almacenan.

La principal diferencia entre las bases de datos relacionales y NoSQL es que no hay SQL en este último caso.

Esto significa que usted (no el optimizador de consultas) escribe los planes de consulta usted mismo.

Esto puede aumentar el rendimiento de la consulta si sabe cómo hacerlo.

Considere la posibilidad de encontrar un motor de búsqueda típico: encuentre las mejores 10 páginas con todas (o algunas) palabras incluidas, por ejemplo, "concurso de camisetas mojadas", ordenadas por relevancia (estamos dejando de lado la proximidad de la palabra por simplicidad).

Para hacer esto, necesita todas las palabras divididas y guardadas en una lista de búsqueda e iterativa ordenada por (word, relevance, source). A continuación, particione esta lista en (3 * ranks) conjuntos (cada uno comenzando en la parte superior de las palabras en su consulta de búsqueda en un rango determinado), donde ranks es el número o rangos posibles, por ejemplo, 1 a 10; y unirse a los conjuntos en source,.

En una base de datos relacional que se vería así:

SELECT w1.source 
FROM ranks r1 
JOIN words w1 
ON  w1.word = 'wet' 
     AND w1.rank = r1.value 
CROSS JOIN 
     ranks r2 
JOIN words w2 
ON  w2.word = 'shirt' 
     AND w2.rank = r2.value 
     AND w2.source = w1.source 
CROSS JOIN 
     ranks r3 
JOIN words w3 
ON  w3.word = 'contest' 
     AND w3.rank = r2.value 
     AND w3.source = w1.source 
ORDER BY 
     relevance_formula (w1.rank, w2.rank, w3.rank) 
LIMIT 10 

Esto se ejecuta mejor usando un MERGE JOIN más de los tres conjuntos divididas por rango.

Sin embargo, ningún optimizador que conozco construirá este plan (dejando de lado el hecho de que relevance_formula no puede distribuir en los rangos individuales).

Para evitar esto, usted debe implementar su propio plan de consulta: comenzar en la parte superior de cada par de palabras/rango y simplemente descender los tres conjuntos de forma simultánea, omitiendo los valores que faltan y el uso de search en lugar next si siente que hay será demasiado para omitir en uno de los conjuntos.

Dicho esto, el enfoque relacional le ofrece una forma más conveniente de consultar datos a un costo de posible penalización del rendimiento.

Si está desarrollando un servidor web de campus, entonces escribir esos SELECT * está bien, incluso si se ejecutan un microsegundo más de lo que podrían ser. Pero si está desarrollando un Google, vale la pena dedicar un tiempo a la optimización de las consultas (lo que los sistemas relacionales puros que solo permiten el acceso a sus datos usando SQL simplemente no lo permiten).

Las llamadas bases de datos relacionales NoSQL a veces se difunden entre sí. Por ejemplo, Berkeley DB es un conocido motor de almacenamiento NoSQL que fue utilizado por MySQL como back-end de almacenamiento para permitir SQL consultas. Y viceversa, HandlerSocket permite consultas de valores-clave puros a una tienda relacional InnoDB con una base de datos MySQL construida sobre ella.