seguridad - ¿Por qué muchos se refieren a Cassandra como una base de datos orientada a columnas?

consultas nosql (4)

Sí, la terminología "orientada a columnas" es un poco confusa.

El modelo en Cassandra es que las filas contienen columnas. Para acceder a la unidad de datos más pequeña (una columna), primero debe especificar el nombre de la fila (clave), luego el nombre de la columna.

Por lo tanto, en una familia de columnas llamada Fruit , podría tener una estructura como la del siguiente ejemplo (con 2 filas), donde los tipos de fruta son las claves de fila y cada una de ellas tiene un nombre y un valor.

apple -> colour weight price variety "red" 100 40 "Cox" orange -> colour weight price origin "orange" 120 50 "Spain"

Una diferencia de una base de datos relacional basada en tablas es que uno puede omitir columnas (el naranja no tiene variedad) o agregar columnas arbitrarias (el naranja tiene origen) en cualquier momento. Todavía puede imaginar los datos anteriores como una tabla, aunque escasa, donde muchos valores pueden estar vacíos.

Sin embargo, un modelo "orientado a columnas" también se puede usar para listas y series temporales, donde cada nombre de columna es único (y aquí tenemos solo una fila, pero podríamos tener miles o millones de columnas):

temperature -> 2012-09-01 2012-09-02 2012-09-03 ... 40 41 39 ...

que es bastante diferente de un modelo relacional, donde uno tendría que modelar las entradas de una serie temporal como rows no columns .

Al leer varios documentos y documentos en Internet, encontré mucha información contradictoria sobre el modelo de datos de Cassandra. Hay muchos que lo identifican como una base de datos orientada a columnas, otros como orientados a filas y luego lo definen como una forma híbrida de ambos.

De acuerdo con lo que sé sobre cómo almacena Cassandra el archivo, utiliza el archivo * -Index.db para acceder a la posición correcta del archivo * -Data.db donde está almacenado el filtro bloom, el índice de columna y luego las columnas del fila requerida

En mi opinión, esto está estrictamente orientado a las filas. ¿Se me escapa algo?

Si echa un vistazo al archivo Readme en Apache Cassandra git repo , dice que,

Cassandra es una tienda de fila dividida. Las filas se organizan en tablas con una clave principal requerida.
El particionamiento significa que Cassandra puede distribuir sus datos a través de múltiples máquinas en una materia transparente a la aplicación. Cassandra se reparticionará automáticamente a medida que se agreguen y eliminen máquinas del clúster.
Row store significa que, al igual que las bases de datos relacionales, Cassandra organiza los datos por filas y columnas.

Las bases de datos orientadas a columnas o columnares se almacenan en la columna del disco.
Ejemplo: mesa de Bonuses mesa
ID Last First Bonus 1 Doe John 8000 2 Smith Jane 4000 3 Beck Sam 1000
En un sistema de gestión de bases de datos orientado a filas , los datos se almacenarían así: 1,Doe,John,8000;2,Smith,Jane,4000;3,Beck,Sam,1000;
En un sistema de gestión de bases de datos orientado a columnas , los datos se almacenarían así:
1,2,3;Doe,Smith,Beck;John,Jane,Sam;8000,4000,1000;
Cassandra es básicamente una tienda familiar
Cassandra almacenaría los datos anteriores como "Bounses" : { row1 : { "ID":1, "Last":"Doe", "First":"John", "Bonus":8000}, row2 : { "ID":2, "Last":"Smith", "First":"Jane", "Bonus":4000} ... }
Lee esto para más detalles.

Espero que esto ayude.

Ambos hacen buenos puntos y pueden ser confusos. En el ejemplo donde

apple -> colour weight price variety "red" 100 40 "Cox"

apple es el valor clave y la columna es la información, que contiene los 4 elementos de datos. De lo que se describió, parece que los 4 elementos de datos se almacenan juntos como un solo objeto y luego la aplicación los analiza para obtener solo el valor requerido. Por lo tanto, desde una perspectiva IO, necesito leer todo el objeto. En mi humilde opinión esto es intrínsecamente basado en fila (u objeto) no basado en columna.

El almacenamiento basado en columnas se hizo popular para el almacenamiento, ya que ofrece una compresión extrema y IO reducida para escaneos completos de tablas (DW) pero a costa de un aumento de IO para OLTP cuando era necesario tirar cada columna (seleccionar *). La mayoría de las consultas no necesitan todas las columnas y, debido a la compresión, el IO se puede reducir en gran medida para escaneos completos de tablas para solo unas pocas columnas. Déjame dar un ejemplo

apple -> colour weight price variety "red" 100 40 "Cox" grape -> colour weight price variety "red" 100 40 "Cox"

Tenemos dos frutas diferentes, pero ambas tienen un color = rojo. Si almacenamos el color en una página de disco separada (bloque) de peso, precio y variedad, por lo que lo único almacenado es el color, cuando comprimimos la página podemos lograr una compresión extrema debido a una gran cantidad de deduplicación. En lugar de almacenar 100 filas (hipotéticamente) en una página, podemos almacenar 10.000 colores. Ahora, para leer todo con el color rojo, podría ser 1 IO en lugar de miles de IO, lo que es realmente bueno para almacenamiento y análisis, pero malo para OLTP si necesito actualizar toda la fila ya que la fila puede tener cientos de columnas y una sola la actualización (o inserción) podría requerir cientos de IO.

A menos que me esté perdiendo algo que no llamaría basado en columnas, lo llamaría basado en objetos. Todavía no está claro cómo se organizan los objetos en el disco. ¿Se han colocado varios objetos en la misma página del disco? ¿Hay alguna manera de asegurar que los objetos con los mismos metadatos vayan juntos? Hasta el punto de que una fruta puede contener datos diferentes a otra fruta dado que es solo metadatos o xml o lo que quieras almacenar en el objeto mismo, ¿hay alguna manera de asegurar que ciertos tipos de fruta coincidentes se almacenen juntos para aumentar la eficiencia?

Larry

Familia de columnas no significa que esté orientado a columnas. Cassandra es una familia de columnas pero no orientada a columnas. Almacena la fila con todas sus familias de columnas juntas.

Hbase es familia de columnas y almacena familias de columnas en forma orientada a columnas. Las diferentes familias de columnas se almacenan por separado en un nodo o incluso pueden residir en diferentes nodos.