Translate
domingo, 23 de junio de 2019
Tipos en Cassandra
Veamos los distintos tipos que tenemos disponibles para nuestros valores. Como hemos visto en nuestra exploración hasta ahora, cada columna de nuestra tabla es de un tipo específico.
CQL admite un conjunto flexible de tipos de datos, incluidos tipos de caracteres y numéricos simples, colecciones y tipos definidos por el usuario. Describiremos estos tipos de datos y proporcionaremos algunos ejemplos de cómo podrían usarse para aprender a tomar la decisión correcta para los diferentes modelos de datos.
int: 32-bit entero con signo como java.
bigint: 64-bit entero grande con signo equivalente a long de Java
smallint: 16-bit entero con signo equivalente a short de Java
tinyint: 8-bit entero con signo
varint: A variable precision signed integer (equivalent to java.math.BigInteger )
float: 32-bit IEEE-754 equivalente a float de java
double: 64-bit IEEE-754 equivalente a double de Java
decimal: equivalente a java.math.BigDecimal
Si bien los tipos enumerados son comunes en muchos lenguajes, no hay un equivalente directo en CQL. Una práctica común es almacenar valores enumerados como cadenas. Por ejemplo, usando el método Enum.name() para convertir un valor enumerado en una Cadena para escribir en Cassandra como texto, y el método Enum.valueOf() para volver a convertir el texto al valor enumerado.
CQL proporciona dos tipos de datos para representar texto, uno de los cuales ya hemos utilizado bastante :
text , varchar : cadena de caracteres UTF-8
ascii : una cadena de ascii
UTF-8 es el estándar de texto más reciente y más utilizado y es compatible con la internacionalización, por lo que recomendamos utilizar texto sobre ascii al crear tablas para nuevos datos. El tipo de ascii es más útil si está tratando con datos heredados que están en formato ASCII.
Cassandra nos provee tipos para representar el tiempo :
timestamp : Si bien señalamos anteriormente que cada columna tiene una marca de tiempo que indica cuándo se modificó por última vez, también puede usar una marca de tiempo como el valor de una columna en sí. El tiempo se puede codificar como un entero con signo de 64 bits, pero normalmente es mucho más útil ingresar una marca de tiempo utilizando uno de los varios formatos de fecha ISO 8601 compatibles.
date, time : hasta Cassandra 2.1 solo tenían el tipo timestamp para representar los tiempos, que incluía tanto una fecha como una hora del día. La versión 2.2 introdujo los tipos de fecha y hora que permitieron que estos se representaran de forma independiente; es decir, una fecha sin una hora y una hora del día sin referencia a una fecha específica. Al igual que con ltimestamp, estos tipos admiten formatos ISO 8601.
Aunque hay nuevos tipos de java.time disponibles en Java 8, el tipo de fecha se asigna a un tipo personalizado en Cassandra para preservar la compatibilidad con JDK más antiguos. El tipo de tiempo se asigna a una Java long que representa el número de nanosegundos desde la medianoche.
Veamos el tipo de datos para las claves:
uuid : El identificador único universal (UUID) de RA es un valor de 128 bits en el que los bits se ajustan a uno de varios tipos, de los cuales los más utilizados comúnmente se conocen como Tipo 1 y Tipo 4. El tipo de uuid CQL es un UUID de Tipo 4, que se basa enteramente en números aleatorios. Los UUID se representan normalmente como secuencias separadas por guiones de dígitos hexadecimales. El tipo uuid se usa a menudo como una clave sustituta, ya sea por sí misma o en combinación con otros valores. Debido a que los UUID son de una longitud finita, no están absolutamente garantizados para ser únicos. Sin embargo, la mayoría de los sistemas operativos y lenguajes de programación proporcionan utilidades para generar ID que proporcionan una singularidad adecuada, y cqlsh también lo hace. Puede obtener un valor UUID de Tipo 4 a través de la función uuid () y usar este valor en INSERT o UPDATE.
timeuuid : Este es un UUID de Tipo 1, que se basa en la dirección MAC de la computadora, la hora del sistema y un número de secuencia utilizado para evitar duplicados. Este tipo se usa frecuentemente como una marca de tiempo libre de conflictos. cqlsh proporciona varias funciones convenientes para interactuar con el tipo de timeuuid: now (), dateOf () y unixTimestampOf (). La disponibilidad de estas funciones de conveniencia es una de las razones por las que timeuuid tiende a usarse con más frecuencia que uuid.
Para terminar veamos otros tipos que no se donde agruparlos :
boolean : Este es un simple valor verdadero / falso. El cqlsh no distingue entre mayúsculas y minúsculas en la aceptación de estos valores, pero da como resultado True o False.
blob : Un objeto grande binario (blob) es un término informático coloquial para una matriz arbitraria de bytes. El tipo de blob CQL es útil para almacenar medios u otros tipos de archivos binarios. Cassandra no valida ni examina los bytes en un blob. CQL representa los datos como dígitos hexadecimales, por ejemplo, 0x00000ab83cf0. Si desea codificar datos textuales arbitrarios en el blob, puede usar la función textAsBlob() para especificar valores para la entrada.
inet : Este tipo representa las direcciones de Internet IPv4 o IPv6. cqlsh acepta cualquier formato legal para definir direcciones IPv4, incluidas representaciones con puntos o sin puntos que contengan valores decimales, octales o hexadecimales. Sin embargo, los valores se representan utilizando el formato decimal punteado en la salida cqlsh, por ejemplo, 192.0.2.235.
Las direcciones IPv6 se representan como ocho grupos de cuatro dígitos hexadecimales, separados por dos puntos, por ejemplo, 2001: 0db8: 85a3: 0000: 0000: 8a2e: 0370: 7334. La especificación de IPv6 permite el colapso de valores hexadecimales cero consecutivos, por lo que el valor anterior se representa de la siguiente manera cuando se lee con SELECT: 2001: db8: 85a3: a :: 8a2e: 370: 7334.
counter : El tipo de datos de contador proporciona un entero con signo de 64 bits, cuyo valor no se puede establecer directamente, sino que solo se puede incrementar o disminuir. Los contadores se utilizan con frecuencia para el seguimiento de estadísticas, como el número de páginas vistas, tweets, mensajes de registro, etc. El tipo de contador tiene algunas restricciones especiales. No se puede utilizar como parte de una clave principal. Si se usa un contador, todas las columnas que no sean columnas de clave primaria deben ser contadores.
En proximos post hablaremos de tipos de datos compuestos como las colecciones y en la capacidad de crear nuestros propios tipos de datos.
jueves, 20 de junio de 2019
C# 8 mejoras en Pattern Matching
Con C# 7 tuvimos Pattern Matching y con C# 8 tenemos mejoras!!!
Todo el mundo esta hablando de C# 8 y porque va salir C# 8, pues claro! Entre otras mejoras, han mejorado el Pattern Matching:
Ajuste posicional
En C# 7 hacíamos :
case Rectangle r when r.Length == 10 && r.Width == 10: return "Found 10x10 rectangle"
Y ahora :
case Rectangle (10, 10): return "Found 10x10 rectangle";
Propiedades
Con ajuste posicional el pattern matching es conciso, pero solo funciona si tiene un método Deconstruct adecuado. Cuando no lo tienes puedes usar un patrón de propiedad en su lugar.
case Rectangle {Width : 10 }: return "Found a rectangle with a width of 10"
Mejoras del deconstructor
Otra idea que se está considerando en el tema Abrir LDM en el ticket de coincidencia de patrones es permitir múltiples métodos Deconstruct con el mismo número de parámetros. Además de tener diferentes tipos, los parámetros deben tener un nombre diferente.
ITuple
La interfaz de ITuple, introducida en .NET 4.7.1 y .NET Core 2.0, plantea varias preguntas en C# 8. La idea básica es que si un objeto implementa esta interfaz, entonces puede participar en la comparación de patrones. Se están considerando tres escenarios con respecto a cuándo entrará en vigencia.
if (x is ITuple(3, 4)) // (1) permitted?
if (x is object(3, 4)) // (2) permitted?
if (x is SomeTypeThatImplementsITuple(3, 4)) // (3) permitted?
Una pregunta relacionada es si una clase implementa ITuple y hay un método de extensión Deconstruct, ¿cuál tiene prioridad? Idealmente, devolverían los mismos valores, pero se necesita un desempate si ese no es el caso.
martes, 18 de junio de 2019
Probando Linux Deepin
Este es mi primer post con Deepin y en lineas generales estoy muy contento, tuve algunos problemas.
Sobretodo con algunas instalaciones. Me sorprendio que el market no traiga algunas aplicaciones que son historicas de linux.
Y por lo demás todo muy bien samba se configuro casi solo.
La interfaz es muy cuidada y las aplicaciones que trae son muy utilies.
En fin, muy bueno...
Dejo link : https://www.deepin.org/es/
Sobretodo con algunas instalaciones. Me sorprendio que el market no traiga algunas aplicaciones que son historicas de linux.
Y por lo demás todo muy bien samba se configuro casi solo.
La interfaz es muy cuidada y las aplicaciones que trae son muy utilies.
En fin, muy bueno...
Dejo link : https://www.deepin.org/es/
domingo, 16 de junio de 2019
Tiempo de vida en las columnas en Apache Cassandra
Una característica muy poderosa que tiene apache Cassandra es la capacidad de expirar datos que no necesita por mucho tiempo. Esta característica es muy flexible y trabaja a nivel individual de cada valor de una columna. El tiempo de vida (TTL) es el tiempo que Cassandra persiste un campo y se indica a nivel de columna.
El TTL por defecto es null y esto significa que el dato escrito no espira. Con la funcion TTL() podemos ver el tiempo de vida de un campo determinado :
cqlsh:my_keyspace> SELECT first_name, last_name, TTL(last_name) FROM user WHERE first_name = 'Mary';
first_name | last_name | ttl(last_name)
-------------+-------------+----------------
Mary | Boateng | null
(1 rows)
Ahora vamos a modificar esto:
cqlsh:my_keyspace> UPDATE user USING TTL 3600 SET last_name ='McDonald' WHERE first_name = 'Mary' ;
cqlsh:my_keyspace> SELECT first_name, last_name, TTL(last_name) FROM user WHERE first_name = 'Mary';
first_name | last_name | ttl(last_name)
-------------+-------------+---------------
Mary | McDonald | 3588
(1 rows)
En este caso modificamos el TTL con update pero también podemos utilizar insert con el comando USING TTL.
El TTL es por columnas, no tenemos un mecanismo para settear el TTL a nivel de fila directamente. Y esto es setteado cuando proveemos un valor a una columna. Si queremos settear el TTL a nivel de fila, debemos proveer un valor para la primary key en el update o insert.
sábado, 15 de junio de 2019
Apache Ambari parte 2
Continuamos descubriendo Apache Ambari.
Se puede integrar fácilmente las capacidades de aprovisionamiento, gestión y supervisión de Hadoop en sus propias aplicaciones con las API REST de Ambari.
Ambari simplifica la administración de Hadoop al proporcionar una plataforma consistente y segura para el control operativo. Ambari proporciona una interfaz de usuario web intuitiva, así como una API REST robusta, que es particularmente útil para automatizar las operaciones de clúster. Con Ambari, los operadores de Hadoop obtienen los siguientes beneficios principales:
Ambari permite a los administradores de sistemas:
Se puede integrar fácilmente las capacidades de aprovisionamiento, gestión y supervisión de Hadoop en sus propias aplicaciones con las API REST de Ambari.
Ambari simplifica la administración de Hadoop al proporcionar una plataforma consistente y segura para el control operativo. Ambari proporciona una interfaz de usuario web intuitiva, así como una API REST robusta, que es particularmente útil para automatizar las operaciones de clúster. Con Ambari, los operadores de Hadoop obtienen los siguientes beneficios principales:
- Instalación, configuración y gestión simplificadas. Se puede crear, administrar y supervisar los clusters de forma fácil y eficiente a escala. Elimina las conjeturas de la configuración con Smart Configs y las recomendaciones de cluster. Permite la creación repetida y automatizada de clústeres con Ambari Blueprints.
- Configuración de seguridad centralizada. Reduce la complejidad para administrar y configurar la seguridad del clúster en toda la plataforma. Ayuda a automatizar la configuración y configuración de las capacidades avanzadas de seguridad de clúster, como Kerberos y Apache Ranger.
- Visibilidad completa en la salud del clúster. Asegurará de que su grupo sea saludable y esté disponible con un enfoque holístico para el monitoreo. Se puede configurar alertas predefinidas, basadas en las mejores prácticas operativas, para la supervisión de clústeres. Captura y visualiza métricas operacionales críticas, utilizando Grafana, para el análisis y la resolución de problemas. Integrado con Hortonworks SmartSense para la prevención y resolución proactiva de problemas.
- Altamente extensible y personalizable. Ajuste Hadoop a la perfección en su entorno empresarial. Altamente extensible con Ambari Stacks para administrar servicios personalizados bajo administración, y con Ambari Views para personalizar la interfaz de usuario web de Ambari.
Ambari permite a los administradores de sistemas:
- Aprovisionar un clúster de Hadoop
- Ambari proporciona un asistente paso a paso para instalar los servicios de Hadoop en cualquier número de hosts.
- Ambari maneja la configuración de los servicios de Hadoop para el cluster.
- Administrar un clúster de Hadoop
- Ambari proporciona administración central para iniciar, detener y reconfigurar los servicios de Hadoop en todo el clúster.
- Monitorear un clúster de Hadoop
- Ambari proporciona un panel de control para monitorear la salud y el estado del clúster de Hadoop.
- Ambari aprovecha el sistema de métricas de Ambari para la recopilación de métricas.
- Ambari aprovecha Ambari Alert Framework para alertar al sistema y le notificará cuando necesite atención (por ejemplo, un nodo se apaga, el espacio restante en el disco es bajo, etc.).
miércoles, 12 de junio de 2019
Libro Java Code Geeks
Apache Dumbo
Apache Software Foundation anunció recientemente que Apache Dubbo es un proyecto Top level. Apache Dubbo es framework RPC de código abierto basado en Java. Originalmente fue desarrollado en Alibaba, fue de código abierto en 2011 e ingresó a la Incubadora de Apache en febrero de 2018. Dubbo trae funcionalidades clave como llamadas remotas basadas en interfaz, tolerancia a fallas y balanceo de carga, y registro y descubrimiento automáticos de servicios.
Veamos como funciona:
- Container es responsable de iniciar, cargar y ejecutar el proveedor de servicios
- Provider registra sus servicios en el Register durante su inicialización.
- Consumer suscribe los servicios que necesita en el Register cuando comienza
- Register devuelve la lista de Providers a los Consumer y, cuando se produce un cambio, el Register envía los datos modificados al Consumer
- Sobre la base de un algoritmo de equilibrio de carga flexible, el Consumer seleccionará uno de los Provider y ejecutará la invocación, seleccionará automáticamente otro Provider cuando ocurra una falla.
- Tanto el Consumer como el Provider contarán las invocaciones de servicio y el tiempo que lleva en la memoria, y enviarán las estadísticas a Monitorear cada minuto.
Las características de Apache Dubbo incluyen:
- Una interfaz transparente basada en RPC.
- Balanceo de carga inteligente, que soporta múltiples estrategias de balanceo de carga listas para usar
- Registro de servicio automático y descubrimiento.
- Alta extensibilidad, diseño de micro-kernel y plugin que asegura que puede ser fácilmente extendido por la implementación de terceros a través de características principales como protocolo, transporte y serialización.
- Enrutamiento del tráfico en tiempo de ejecución, que se puede configurar en tiempo de ejecución para que el tráfico se pueda enrutar de acuerdo con diferentes reglas, lo que facilita la compatibilidad con características como la implementación azul-verde, el enrutamiento que reconoce el centro de datos, etc.
- Gobierno visualizado del servicio, que proporciona herramientas completas para el gobierno y el mantenimiento del servicio, como la consulta de metadatos del servicio, el estado de mantenimiento y las estadísticas
Para comenzar a usar Dubbo, primero agregue la dependencia de Maven:
<dependencies>
<dependency>
<groupId>org.apache.dubbo</groupId>
<artifactId>dubbo</artifactId>
<version>2.7.2<</version>
</dependency>
<dependency>
<groupId>org.apache.dubbo</groupId>
<artifactId>dubbo-dependencies-zookeeper</artifactId>
<version>2.7.2<</version>
<type>pom</type>
</dependency>
</dependencies>
domingo, 9 de junio de 2019
Columnas en Apache Cassandra
Una columna es la unidad más básica de la estructura de datos en el modelo de datos de Cassandra. Hasta ahora hemos visto que una columna contiene un nombre y un valor. Restringimos cada uno de los valores para que sean de un tipo particular cuando definimos la columna. Vamos profundizar en los diversos tipos que están disponibles para cada columna, pero primero echemos un vistazo a algunos otros atributos de una columna que aún no hemos discutido: marcas de tiempo y tiempo de vida. Estos atributos son clave para entender cómo Cassandra usa el tiempo para mantener los datos actualizados.
Marcas de tiempo: Cada vez que escribe datos en Cassandra, se genera una marca de tiempo para cada valor de columna que se actualiza. Internamente, Cassandra usa estas marcas de tiempo para resolver cualquier cambio conflictivo que se realice en el mismo valor. Generalmente, la última marca de tiempo gana.
Veamos las marcas de tiempo que se generaron para nuestras escrituras anteriores agregando la función writetime() a nuestro comando SELECT. Haremos esto en la columna de apellido e incluiremos un par de otros valores para el contexto:
cqlsh:my_keyspace> SELECT first_name, last_name, writetime(last_name) FROM user;
first_name | last_name | writetime(last_name)
------------+-------------+----------------------
Mary | Rodriguez | 1434591198790252
Bill | Nguyen | 1434591198798235
(2 rows)
Podríamos esperar que si solicitamos la marca de tiempo en first_name obtendríamos un resultado similar. Sin embargo, resulta que Cassandra no nos permite solicitar la marca de tiempo en las columnas de clave principal:
cqlsh:my_keyspace> SELECT WRITETIME(first_name) FROM user;
InvalidRequest: code=2200 [Invalid query] message="Cannot use selection function writeTime on PRIMARY KEY part first_name"
Cassandra también nos permite especificar una marca de tiempo cuando modificamos. Usaremos la opción USING TIMESTAMP para establecer manualmente una marca de tiempo (tenga en cuenta que la marca de tiempo debe ser posterior a la de nuestro comando SELECT, o se ignorará la ACTUALIZACIÓN):
cqlsh:my_keyspace> UPDATE user USING TIMESTAMP 1434373756626000 SET last_name = 'Boateng' WHERE first_name = 'Mary' ;
cqlsh:my_keyspace> SELECT first_name, last_name, WRITETIME(last_name) FROM user WHERE first_name = 'Mary';
first_name | last_name | writetime(last_name)
------------+-------------+---------------------
Mary | Boateng | 1434373756626000
(1 rows)
Esta declaración tiene el efecto de agregar la columna de apellido a la fila identificada por la clave principal "Mary", y establecer la marca de tiempo al valor que proporcionamos.
sábado, 8 de junio de 2019
Apache Ambari
Apache Ambari es un proyecto de software de Apache Software Foundation. Ambari permite a los administradores de sistemas aprovisionar, administrar y monitorear un clúster de Hadoop, y también integrar Hadoop con la infraestructura empresarial existente. Apache Ambari elimina las conjeturas de operar Hadoop y nos permite utilizar Hadoop de forma interactiva y fácil. Ambari era un subproyecto de Hadoop pero ahora es un proyecto de Top level de Apache.
Ambari es utilizado por compañías como IBM, Hortonworks, Cardinal Health, EBay, Expedia, Kayak.com, club de préstamos, Neustar, Macy's, Pandora Radio, Samsung, Shutterfly y Spotify.
Apache Ambari, como parte de la plataforma de datos Hortonworks, permite que las empresas planifiquen, instalen y configuren de manera segura HDP, lo que facilita el mantenimiento y la administración continua del clúster, sin importar el tamaño del clúster.
HDP sanbox es una imagen de los productos de apache que se utilizan en la distribución de HortonWorks y permite administrar todo el software con ambari, de forma muy fácil.
Ambari actualmente soporta 64-bit y corre sobre los siguientes sistemas operativos :
Les dejo un video :
Dejo links :
https://ambari.apache.org/
https://es.hortonworks.com/apache/ambari/
https://en.wikipedia.org/wiki/Apache_Ambari
Ambari es utilizado por compañías como IBM, Hortonworks, Cardinal Health, EBay, Expedia, Kayak.com, club de préstamos, Neustar, Macy's, Pandora Radio, Samsung, Shutterfly y Spotify.
Apache Ambari, como parte de la plataforma de datos Hortonworks, permite que las empresas planifiquen, instalen y configuren de manera segura HDP, lo que facilita el mantenimiento y la administración continua del clúster, sin importar el tamaño del clúster.
HDP sanbox es una imagen de los productos de apache que se utilizan en la distribución de HortonWorks y permite administrar todo el software con ambari, de forma muy fácil.
Ambari actualmente soporta 64-bit y corre sobre los siguientes sistemas operativos :
- RHEL (Redhat Enterprise Linux) 7.4, 7.3, 7.2
- CentOS 7.4, 7.3, 7.2
- OEL (Oracle Enterprise Linux) 7.4, 7.3, 7.2
- Amazon Linux 2
- SLES (SuSE Linux Enterprise Server) 12 SP3, 12 SP2
- Ubuntu 14 and 16
- Debian 9
Les dejo un video :
https://ambari.apache.org/
https://es.hortonworks.com/apache/ambari/
https://en.wikipedia.org/wiki/Apache_Ambari
viernes, 7 de junio de 2019
Cloud data warehousing for Dummies
Otro libro gratuito!!
Esta guía explica data warehousing en la nube y cómo se compara con otras plataformas de datos.
Incluyen:
- Qué es un data warehousing de datos en la nube.
- Tendencias que provocaron la adopción del almacenamiento de datos en la nube.
- Cómo el almacén de datos en la nube se compara con las ofertas tradicionales y noSQL
- Cómo evaluar diferentes soluciones de almacenamiento de datos en la nube.
- Consejos para elegir un almacén de datos en la nube
Data as a feature
Recibí un mail de O'reilly sobre un libro gratuito y bueno, quiero compartirlo :
|
jueves, 6 de junio de 2019
Tablas en Cassandra
Una tabla es un contenedor para una colección ordenada de filas, cada una de las cuales es una colección ordenada de columnas. El orden está determinado por las columnas, que se identifican como claves. Pronto veremos cómo Cassandra usa claves adicionales más allá de la clave principal.
Cuando escribe datos en una tabla en Cassandra, especifica valores para una o más columnas. Esa colección de valores se llama una fila. Al menos uno de los valores que especifique debe ser una clave principal que sirva como identificador único para esa fila.
Leemos usando el comando SELECT en cqlsh:
cqlsh:my_keyspace> SELECT * FROM user WHERE first_name='Bill';
first_name | last_name
------------+-----------
Bill | Nguyen
(1 rows)
Notarás en la última fila que el shell nos dice que se devolvió una fila. Resulta ser la fila identificada por el primer nombre "Bill". Esta es la clave principal que identifica esta fila.
No necesitamos incluir un valor para cada columna cuando agregamos una nueva fila a la tabla. Probemos esto con nuestra tabla de usuarios usando el comando ALTER TABLE y luego veamos los resultados usando el comando DESCRIBE TABLE:
cqlsh:my_keyspace> ALTER TABLE user ADD title text;
cqlsh:my_keyspace> DESCRIBE TABLE user;
CREATE TABLE my_keyspace.user (
first_name text PRIMARY KEY,
last_name text,
title text
) ...
Vemos que se ha añadido la columna de título. Tenga en cuenta que hemos acortado la salida para omitir las diversas configuraciones de la tabla.
Ahora, escribamos un par de filas, llenemos diferentes columnas para cada una y veamos los resultados:
cqlsh:my_keyspace> INSERT INTO user (first_name, last_name, title)
VALUES ('Bill', 'Nguyen', 'Mr.');
cqlsh:my_keyspace> INSERT INTO user (first_name, last_name) VALUES
('Mary', 'Rodriguez');
cqlsh:my_keyspace> SELECT * FROM user;
first_name | last_name | title
------------+-----------+-------
Mary | Rodriguez | null
Bill | Nguyen | Mr.
(2 rows)
Ahora que hemos aprendido más sobre la estructura de una tabla y hemos realizado algunos modelos de datos, profundicemos en las columnas.
domingo, 2 de junio de 2019
Clusters y Keyspaces en Cassandra
Clusters: la base de datos Cassandra está diseñada específicamente para ser distribuida en varias máquinas que operan juntas y que aparecen como una sola instancia para el usuario final. Así que la estructura más externa en Cassandra son los clusters, a veces llamado el anillo, porque Cassandra asigna datos a los nodos en el grupo organizándolos en un anillo.
Keyspaces: Un clúster es un contenedor para keyspaces. Un keyspace es un contenedor más externo para datos en Cassandra, que se corresponde estrechamente con una base de datos relacional. De la misma manera que una base de datos es un contenedor para tablas en el modelo relacional, un keyspace es un contenedor para tablas en el modelo de datos de Cassandra. Al igual que una base de datos relacional, un keyspace tiene un nombre y un conjunto de atributos que definen el comportamiento de todo el keyspace.
Keyspaces: Un clúster es un contenedor para keyspaces. Un keyspace es un contenedor más externo para datos en Cassandra, que se corresponde estrechamente con una base de datos relacional. De la misma manera que una base de datos es un contenedor para tablas en el modelo relacional, un keyspace es un contenedor para tablas en el modelo de datos de Cassandra. Al igual que una base de datos relacional, un keyspace tiene un nombre y un conjunto de atributos que definen el comportamiento de todo el keyspace.
Modelo de datos en Cassandra
El almacén de datos más simple con el que querrías trabajar podría ser una matriz o una lista. Se vería como la siguiente figura:
Si se persiste en esta lista, podría consultarla más adelante, pero tendría que examinar cada valor para saber qué representaba, o almacenar siempre cada valor en el mismo lugar de la lista y luego mantener externamente la documentación sobre qué se encuentra en que celda. Eso significa que podría tener que proporcionar valores de marcador de posición vacíos (nulos) para mantener el tamaño predeterminado de la matriz en caso de que no tuviera un valor para un atributo opcional (como un número de fax o un número de apartamento). Una matriz es una estructura de datos claramente útil, pero no semánticamente rica.
Así que nos gustaría agregar una segunda dimensión a esta lista: nombres para que coincidan con los valores. Daremos nombres a cada celda, y ahora tenemos una estructura de mapa, como se muestra en la siguiente figura:
Esto es una mejora porque podemos saber los nombres de nuestros valores. Entonces, si decidimos que nuestro mapa contendría la información del usuario, podríamos tener nombres de columna como primer nombre, último nombre, teléfono, correo electrónico, etc. Esta es una estructura algo más rica para trabajar.
Pero la estructura que hemos construido hasta ahora solo funciona si tenemos una instancia de una entidad determinada, como una sola persona, usuario, hotel o tweet. No nos da mucho si queremos almacenar varias entidades con la misma estructura, que es ciertamente lo que queremos hacer. No hay nada para unificar una colección de pares de nombre / valor, y no hay manera de repetir los mismos nombres de columna. Así que necesitamos algo que agrupará algunos de los valores de columna en un grupo claramente direccionable. Necesitamos una clave para hacer referencia a un grupo de columnas que deben tratarse juntas como un conjunto. Necesitamos filas. Luego, si obtenemos una sola fila, podemos obtener todos los pares de nombre / valor para una sola entidad a la vez, o simplemente obtener los valores de los nombres que nos interesan. Podríamos llamar a estas columnas de pares de nombre / valor. Podríamos llamar a cada entidad separada que contiene un conjunto de filas de columnas.
Y el identificador único para cada fila podría llamarse clave de fila o clave principal.
La siguinte figura muestra el contenido de una fila simple: una clave principal, que es en sí misma una o más columnas, y columnas adicionales.
Cassandra define una tabla como una división lógica que asocia datos similares. Por ejemplo, podríamos tener una tabla de usuario, una tabla de hotel, una tabla de libreta de direcciones, etc. De esta manera, una tabla de Cassandra es análoga a una tabla en el mundo relacional.
Ahora no necesitamos almacenar un valor para cada columna cada vez que almacenamos una nueva entidad. Quizás no sepamos los valores de cada columna para una entidad dada. Por ejemplo, algunas personas tienen un segundo número de teléfono y otras no, y en lugar de almacenar el valor nulo para aquellos valores que no conocemos, lo que desperdiciaría espacio, simplemente no almacenaremos esa columna para esa fila. Así que ahora tenemos una estructura de matriz multidimensional dispersa que se parece a la siñguiente figura :
Al diseñar una tabla en una base de datos relacional tradicional, normalmente se trata de "entidades" o del conjunto de atributos que describen un nombre particular (hotel, usuario, producto, etc.). No se piensa mucho en el tamaño de las filas en sí, porque el tamaño de la fila no es negociable una vez que haya decidido qué sustantivo representa su tabla. Sin embargo, cuando trabajas con Cassandra, realmente tienes que tomar una decisión sobre el tamaño de tus filas: pueden ser anchas o delgadas, dependiendo del número de columnas que contenga la fila.
Una fila ancha significa una fila que tiene muchos y muchos (quizás decenas de miles o incluso millones) de columnas. Normalmente, hay un número menor de filas que van junto con tantas columnas. A la inversa, podría tener algo más cercano a un modelo relacional, donde define un número menor de columnas y usa muchas filas diferentes, es decir, el modelo delgado.
En Cassandra, tenemos estas estructuras de datos básicas :
Si se persiste en esta lista, podría consultarla más adelante, pero tendría que examinar cada valor para saber qué representaba, o almacenar siempre cada valor en el mismo lugar de la lista y luego mantener externamente la documentación sobre qué se encuentra en que celda. Eso significa que podría tener que proporcionar valores de marcador de posición vacíos (nulos) para mantener el tamaño predeterminado de la matriz en caso de que no tuviera un valor para un atributo opcional (como un número de fax o un número de apartamento). Una matriz es una estructura de datos claramente útil, pero no semánticamente rica.
Así que nos gustaría agregar una segunda dimensión a esta lista: nombres para que coincidan con los valores. Daremos nombres a cada celda, y ahora tenemos una estructura de mapa, como se muestra en la siguiente figura:
Esto es una mejora porque podemos saber los nombres de nuestros valores. Entonces, si decidimos que nuestro mapa contendría la información del usuario, podríamos tener nombres de columna como primer nombre, último nombre, teléfono, correo electrónico, etc. Esta es una estructura algo más rica para trabajar.
Pero la estructura que hemos construido hasta ahora solo funciona si tenemos una instancia de una entidad determinada, como una sola persona, usuario, hotel o tweet. No nos da mucho si queremos almacenar varias entidades con la misma estructura, que es ciertamente lo que queremos hacer. No hay nada para unificar una colección de pares de nombre / valor, y no hay manera de repetir los mismos nombres de columna. Así que necesitamos algo que agrupará algunos de los valores de columna en un grupo claramente direccionable. Necesitamos una clave para hacer referencia a un grupo de columnas que deben tratarse juntas como un conjunto. Necesitamos filas. Luego, si obtenemos una sola fila, podemos obtener todos los pares de nombre / valor para una sola entidad a la vez, o simplemente obtener los valores de los nombres que nos interesan. Podríamos llamar a estas columnas de pares de nombre / valor. Podríamos llamar a cada entidad separada que contiene un conjunto de filas de columnas.
Y el identificador único para cada fila podría llamarse clave de fila o clave principal.
La siguinte figura muestra el contenido de una fila simple: una clave principal, que es en sí misma una o más columnas, y columnas adicionales.
Cassandra define una tabla como una división lógica que asocia datos similares. Por ejemplo, podríamos tener una tabla de usuario, una tabla de hotel, una tabla de libreta de direcciones, etc. De esta manera, una tabla de Cassandra es análoga a una tabla en el mundo relacional.
Ahora no necesitamos almacenar un valor para cada columna cada vez que almacenamos una nueva entidad. Quizás no sepamos los valores de cada columna para una entidad dada. Por ejemplo, algunas personas tienen un segundo número de teléfono y otras no, y en lugar de almacenar el valor nulo para aquellos valores que no conocemos, lo que desperdiciaría espacio, simplemente no almacenaremos esa columna para esa fila. Así que ahora tenemos una estructura de matriz multidimensional dispersa que se parece a la siñguiente figura :
Al diseñar una tabla en una base de datos relacional tradicional, normalmente se trata de "entidades" o del conjunto de atributos que describen un nombre particular (hotel, usuario, producto, etc.). No se piensa mucho en el tamaño de las filas en sí, porque el tamaño de la fila no es negociable una vez que haya decidido qué sustantivo representa su tabla. Sin embargo, cuando trabajas con Cassandra, realmente tienes que tomar una decisión sobre el tamaño de tus filas: pueden ser anchas o delgadas, dependiendo del número de columnas que contenga la fila.
Una fila ancha significa una fila que tiene muchos y muchos (quizás decenas de miles o incluso millones) de columnas. Normalmente, hay un número menor de filas que van junto con tantas columnas. A la inversa, podría tener algo más cercano a un modelo relacional, donde define un número menor de columnas y usa muchas filas diferentes, es decir, el modelo delgado.
En Cassandra, tenemos estas estructuras de datos básicas :
- La columna, que es un par de nombre / valor
- La fila, que es un contenedor para columnas referenciadas por una clave primaria
- La tabla, que es un contenedor para filas.
- El keyspace, que es un contenedor para tablas.
- El clúster, que es un contenedor para espacios de claves que abarca uno o más nodos
Suscribirse a:
Entradas (Atom)