Download Dev Guides!
|
| ||||||
|
|
jueves, 13 de diciembre de 2018
Libro gratuitos sobre Linux, postgresql, jetty, jdbc
martes, 11 de diciembre de 2018
¿Como esta compuesto Apache HBase? Parte 4
En la ultima parte hablaremos de 2 componentes: Client y Catalog Table :
El Client es responsable de encontrar el RegionServer, que alberga la fila particular (datos). Se realiza consultando las tablas del catálogo. Una vez que se encuentra la región, el cliente se pone en contacto directamente con RegionServers y realiza la operación de datos. Una vez que se obtiene esta información, el cliente la almacena en caché para una recuperación más rápida. El cliente puede escribirse en Java o en cualquier otro lenguaje mediante API externas.
Las catalog tables son dos tablas que mantienen la información sobre todos los RegionServers y las regiones. Estas son un tipo de metadatos para el clúster HBase. Las siguientes son las dos tablas de catálogo que existen en HBase:
- -ROOT-: Esto incluye información sobre la ubicación de la tabla .META.
- .META. : Esta tabla contiene todas las regiones y sus ubicaciones.
Al comienzo del proceso de inicio, la ubicación .META se establece en la raíz desde donde se leen los metadatos reales de las tablas y la lectura / escritura continúa. Por lo tanto, cada vez que un cliente desea conectarse a HBase y leer o escribir en la tabla, estas dos tablas se remiten y la información se devuelve al cliente para lectura directa y escritura en los RegionServers y las regiones de la tabla específica.
¿Como esta compuesto Apache HBase? Parte 3
Ahora hablaremos del RegionServer que con ese nombre suena importante.
De la misma manera que en clúster de Hadoop, un NameNode administra los metadatos y un DataNode mantiene los datos sin procesar. Del mismo modo, en HBase, un maestro HBase contiene los metadatos y los RegionServers los datos. Estos son los servidores que contienen los datos de HBase, ya que es posible que sepamos que en el clúster Hadoop, NameNode administra los metadatos y DataNode contiene los datos reales. Del mismo modo, en el clúster HBase, RegionServers almacena los datos reales sin procesar. Como puede suponer, un RegionServer se ejecuta o se aloja sobre un DataNode, que utiliza los DataNodes subyacentes en el sistema de archivos subyacente, es decir, HDFS.
RegionServer realiza las siguientes tareas:
• sirve las tablas asignadas a él
• Manejo de solicitudes de lectura / escritura del cliente
• Vaciar caché a HDFS
• Mantener HLogs
• Realizar compacciones.
Los siguientes son los componentes de RegionServers:
De la misma manera que en clúster de Hadoop, un NameNode administra los metadatos y un DataNode mantiene los datos sin procesar. Del mismo modo, en HBase, un maestro HBase contiene los metadatos y los RegionServers los datos. Estos son los servidores que contienen los datos de HBase, ya que es posible que sepamos que en el clúster Hadoop, NameNode administra los metadatos y DataNode contiene los datos reales. Del mismo modo, en el clúster HBase, RegionServers almacena los datos reales sin procesar. Como puede suponer, un RegionServer se ejecuta o se aloja sobre un DataNode, que utiliza los DataNodes subyacentes en el sistema de archivos subyacente, es decir, HDFS.
RegionServer realiza las siguientes tareas:
• sirve las tablas asignadas a él
• Manejo de solicitudes de lectura / escritura del cliente
• Vaciar caché a HDFS
• Mantener HLogs
• Realizar compacciones.
Los siguientes son los componentes de RegionServers:
- Registros de escritura anticipada o Write-Ahead logs (WAL): Cuando los datos se leen / modifican a HBase, no se escriben directamente en el disco, sino que se guardan en la memoria durante un tiempo (umbral, que podemos configurar según el tamaño y el tiempo). Mantener estos datos en la memoria puede ocasionar una pérdida de datos si la máquina se apaga repentinamente. Entonces, para resolver esto, los datos se escriben primero en un archivo intermedio, que se denomina archivo de registro de escritura anticipada y luego en la memoria. Entonces, en el caso de una falla del sistema, los datos se pueden reconstruir usando este archivo de registro.
- HFile: estos son los archivos reales donde los datos sin procesar se almacenan físicamente en el disco. Este es el archivo de la tienda real.
- Store: Aquí se almacena el HFile. Corresponde a una familia de columnas para una tabla de HBase.
- MemStore: este componente está en el almacén de datos de memoria; esto reside en la memoria principal y registra la operación de datos actual. Por lo tanto, cuando los datos se almacenan en WAL, RegionServers almacena el valor clave en el almacén de memoria.
- Región: Estas son las divisiones de la tabla HBase; la tabla se divide en regiones según la clave y están alojados por RegionServers. Puede haber diferentes regiones en un RegionServer
Bajar libros gratis desde Bookboon
Quiero compartir esta pagina de libros gratis. Si bien no tiene tantos libros técnicos, esta buena, tiene muchos libros soft, de metodología, Ingles, y tambien hay técnicos.
Dejo link: https://bookboon.com/
domingo, 9 de diciembre de 2018
¿Que novedades nos trae Linux Mint 19.1 Tessa?
Muchos sabrán que soy bastante fanático de Mint, pero no hago un post por cada versión pero esta versión me resulto por demás interesante por pequeños cambios en la interfaz que son un gran paso a la usabilidad:
El gestor de archivos Nemo es ahora tres veces más rápido
Se incluye un nuevo diseño del escritorio mucho más simple, claro y moderno respecto a su predecesor. En la parte de abajo encontramos una barra de iconos más grande incluyendo el botón de inicio (Menú).
Iconos de las aplicaciones ahora se compactarán
Mint 19.1 se viene con todo, si bien no tenemos la versión estable todavía podemos bajar la versión beta.
viernes, 7 de diciembre de 2018
¿Como esta compuesto Apache HBase? Parte 2
HMaster es el componente del cluster HBase que se puede considerar como el nodo maestro a la vez, actúa como un maestro para los Servidores de Región que se ejecutan en diferentes máquinas. Es responsable de monitorear todos los RegionServers en un cluster HBase y también proporciona una interfaz para todos los metadatos de HBase para las operaciones cliente.
También maneja el failover de RegionServer y las divisiones de región. Puede haber más de una instancia de HMaster en un clúster HBase esto lo configuraremos así para tener alta disponibilidad. Si tenemos más de un maestro, solo un maestro está activo a la vez; en el momento de la puesta en marcha, todos los maestros compiten para convertirse en el maestro activo en el cluster. Un nodo maestro ganara y todas las demás instancias maestras permanecen pasivas hasta que el maestro activo se bloquea, se apage o ZooKeeper lo decida. En resumen, HMaster es un componente de coordinación en un cluster HBase, que también administra y nos permite realizar una tarea administrativa en el cluster.
Discutamos ahora que pasa cuando inicia el servidor HMaster:
- Se bloquea (no atiende solicitudes) hasta que se active HMaster.
- Finaliza la inicialización.
- Atiende peticiones.
- Limpia los registros al finalizar.
En HBase, hay una tabla llamada .META. (nombre de la tabla en el sistema de archivos), que conserva toda la información sobre las regiones a las que HMaster hace referencia para obtener información sobre los datos. De forma predeterminada, HMaster se ejecuta en el número de puerto 60000 y su interfaz de usuario web HTTP está disponible en el puerto 60010, que siempre se puede cambiar por medio de configuración.
Resumiendo, HMaster es encargado de :
- Supervisa los servidores regionales
- Maneja el failover de los servidores de región.
- Maneja los cambios de metadatos.
- Asignación / desasignación de regiones
- Interfaces todos los cambios de metadatos
- Realiza balanceo de recarga en tiempo de inactividad
- Publica su ubicación al cliente utilizando ZooKeeper.
- La interfaz de usuario web de HMaster proporciona toda la información sobre el clúster HBase (tabla, regiones, RegionServers y así sucesivamente)
¿Como esta compuesto Apache HBase?
Bueno, Apache HBase esta compuesto
por :
- ZooKeeper
- Hmaster
- RegionServer
- Client
- Catalog Table
Empecemos con ZooKeeper:
ZooKeeper es un sistema de coordinación para aplicaciones distribuidas. El cual provee una sincronización de recursos distribuidos y un grupo de servicios para HBase.
Esto permite centrarnos en la lógica del nuestro negocio y no en la coordinación de los clusters. Este tambien provee un conjunto de APIS que permiten entre otras cosas desarrollar tareas de coordinación.
En HBase, ZooKeeper es usado para elegir el master de un cluster para mantener que servidor esta disponible y meta-informcación del cluster.
ZooKeeper provee Apis para :
- Consistencia, orden y durabilidad
- Sincronización
- Concurrencia para clusters distribuidos.
Zookeeper fue desarrollado por yahoo research y su nombre esta relacionado con que se encuadra en el marco del proyecto Hadoop, el cual sus subproyectos son todos animales. Es decir ZooKeeper es el encargado de cuidar estos animales.
ZooKeeper no solo simplifica el desarrollo sino que también es una capa de abstracción que facilita la mejor accesibilidad a los componentes del sistema.
ZooKeeper mantiene un árbol con datos llamados internamente znode. Esto puede ser de dos tipos:
- Efímero, que es bueno para las aplicaciones que necesitan entender si un recurso distribuido específico está disponible o no.
- El persistente se almacenará hasta que un cliente no lo elimine explícitamente y también almacene algunos datos de la aplicación.
ZooKeepers se basan en un principio de mayoría (quorum); requiere que tengamos un quórum de servidores para estar activo, donde el quórum es (n / 2) + 1, para un conjunto de tres nodos significa que dos nodos deben estar funcionando en cualquier momento, y para un conjunto de cinco nodos, un mínimo de tres nodos debe estar arriba. También es importante para la elección del maestro ZooKeeper.
martes, 4 de diciembre de 2018
Arquitectura de Apache HBase y los árboles LSM
Apache HBase almacena el archivo utilizando el árbol LSM, pero que es un árbol LSM?
En ciencias de la computación, el árbol de combinación estructurado de registro (o árbol LSM) es una estructura de datos con características de rendimiento que lo hacen atractivo para proporcionar acceso indexado a archivos con un alto volumen de inserción, como los datos de registro transaccional. Los árboles LSM, al igual que otros árboles de búsqueda, mantienen pares clave-valor. Los árboles LSM mantienen los datos en dos o más estructuras separadas, cada una de las cuales está optimizada para su respectivo medio de almacenamiento subyacente; los datos se sincronizan entre las dos estructuras de manera eficiente, en lotes.
Una versión simple del árbol LSM es un árbol LSM de dos niveles. Como lo describe Patrick O'Neil, un árbol LSM de dos niveles comprende dos estructuras en forma de árbol, llamadas C0 y C1. C0 es más pequeño y reside totalmente en la memoria, mientras que C1 reside en el disco. Los nuevos registros se insertan en el componente C0 residente en la memoria. Si la inserción hace que el componente C0 exceda un cierto umbral de tamaño, un segmento contiguo de entradas se elimina de C0 y se combina en C1 en el disco. Las características de rendimiento de los árboles LSM se derivan del hecho de que cada componente está sintonizado con las características de su medio de almacenamiento subyacente, y de que los datos se migran eficientemente a través de medios en lotes sucesivos, utilizando un algoritmo que recuerda el ordenamiento de fusión.
La mayoría de los árboles LSM utilizados en la práctica emplean múltiples niveles. El nivel 0 se mantiene en la memoria principal y puede representarse mediante un árbol. Los datos en el disco se organizan en series ordenadas de datos. Cada ejecución contiene datos ordenados por la clave de índice. Una ejecución se puede representar en el disco como un solo archivo, o como una colección de archivos con rangos de claves que no se superponen. Para realizar una consulta en una clave en particular para obtener su valor asociado, se debe buscar en el árbol de nivel 0 y cada ejecución.
Una clave en particular puede aparecer en varias ejecuciones, y lo que eso significa para una consulta depende de la aplicación. Algunas aplicaciones simplemente quieren el par más reciente de clave-valor con una clave dada. Algunas aplicaciones deben combinar los valores de alguna manera para obtener el valor agregado adecuado para devolver. Por ejemplo, en Apache Cassandra, cada valor representa una fila en una base de datos, y las diferentes versiones de la fila pueden tener diferentes conjuntos de columnas.
Para mantener bajo el costo de las consultas, el sistema debe evitar una situación en la que haya demasiadas ejecuciones.
Volviendo a Hbase, Apache HBase almacena el archivo utilizando el árbol LSM, que mantiene los datos en dos partes separadas que están optimizadas para el almacenamiento subyacente. Este tipo de estructura de datos depende de dos estructuras, una actual y una más pequeña en la memoria y una más grande en el disco persistente, y una vez que la parte en la memoria se vuelve más grande que un cierto límite, se fusiona con la estructura más grande que se almacena en el disco que utiliza un algoritmo de clasificación de mezcla y un nuevo árbol en memoria se crea para las solicitudes de inserción más nuevas. Transforma el acceso aleatorio a los datos en un acceso secuencial a los datos, lo que mejora el rendimiento de lectura, y la fusión es un proceso en segundo plano, que no afecta el procesamiento en primer plano.
Ventajas y desventajas de una base de datos orientada a columnas
Entre las ventajas tenemos:
- Tiene tiene soporte incorporado para la compresión eficiente de datos.
- Es compatible con la recuperación rápida de datos.
- La administración y configuración simplificada. Es fácil escalar horizontalmente.
- Es buena para hacer consultas con agreegación (SUM, COUNT, AVG, MIN, etc)
- Es buena para particionar datos, se puede contar con varios datacenter distribuidos
- No soporta joins o no esta optimizadas para esto.
- Puede ser difícil diseñar modelos eficientes, ya que no aplica el modelo relacional al que estamos acostumbrados.
- Registra y elimina muchas actualizaciones y tiene que realizar compactaciones frecuentes y también se divide. Esto reduce su eficiencia de almacenamiento.
Apache ActiveMQ Cookbook y Amazon AWS Tutorial
|
domingo, 2 de diciembre de 2018
Bases de datos orientadas a filas vs orientadas a columnas
Notemos que bases de datos como HBase o Cassandra nos proponen un modelo basado en columnas mientras que nosotros venimos de un modelo basado en Filas. Por esa razón esta bueno confrontar estos modelos.
|
Filas |
Columnas |
|
Es eficiente para agregar o modificar datos |
Es eficiente para leer datos |
|
Leen páginas que contienen filas enteras. |
Sólo leen las columnas que es necesitan |
|
Son las mejores para OLTP |
No están tan optimizadas para OLTP todavía |
|
Los datos de la fila se almacenan en páginas contiguas en la
memoria o en el disco |
Las columnas se almacenan en páginas en memoria o en disco. |
Supongamos que los registros de una tabla se almacenan en las páginas o registros de la memoria. Cuando es necesario acceder a ellas, estas páginas se llevan a la memoria primaria, si aún no están presentes en la memoria.
Si una fila ocupa una página y necesitamos todas las columnas específicas, como el salario o la tasa de interés de todas las filas para algún tipo de análisis, cada página que contenga las columnas debe ingresarse en la memoria; por lo que esta página en la página de salida dará como resultado una gran cantidad de entradas y salidas, lo que puede resultar en un tiempo de procesamiento prolongado.
En las bases de datos orientadas a columnas, cada columna se almacenará en páginas. Si necesitamos recuperar una columna específica, habrá menos entradas y salidas, ya que solo las páginas que contienen la columna especificada deben incluirse en la memoria principal y leer, y no es necesario que aparezcan y lean todas las páginas que contienen filas / registros. De ahora en adelante en la memoria. Por lo tanto, el tipo de consultas en las que solo necesitamos obtener columnas específicas y no registros o conjuntos completos se realiza mejor en una base de datos orientada a columnas, lo que es útil para el análisis en el que podemos recuperar algunas columnas y realizar algunas operaciones matemáticas, como la suma y media.
miércoles, 28 de noviembre de 2018
martes, 27 de noviembre de 2018
Comparando HBase con una base de datos relacional
|
Base de datos relacional |
Apache HBase |
|
Escala de forma horizontal |
Escala de forma vertical |
|
Usa SQL para leer registros en la tabla |
Usa una API y Mapreduce para resolver las consultas |
|
Esta organizada en tablas donde cada fila tienen el mismo
numero de columnas que todas las filas de la tabla.
|
Esta organizada en tablas pero cada fila puede tener un numero
variable de columnas.
|
|
La cantidad de datos que se pueden guardar dependen de la
capacidad de un server |
La cantidad de datos que se pueden guardar dependen de la
capacidad del cluster de servidores |
|
Tiene un esquema restrictivo |
Tiene un esquema flexible |
|
Soporta ACID, es decir soporta transacciones |
No soporta ACID, no soporta transacciones |
|
Es ideal para datos estructurados |
Es ideal para datos estructurados y no estructurados.
|
|
Centralizada |
Distribuida |
|
Soporta joins |
No soporta joins |
|
Soporta integridad referencial |
No soporta integridad referencial |
|
|
|
Por lo visto son
cosas totalmente diferentes, pensadas para casos de uso diferentes.
Por lo tanto lo peor que podemos hacer es tomar un problema que se
resuelve con una base de datos relacional y tratar de utilizar HBase.
lunes, 26 de noviembre de 2018
Como es streams en Kotlin?
En Java 8 tenemos los Streams que nos permiten convertir o filtrar colecciones.
Veamos un ejemplo:
List<String> names = Arrays.asList("Joe", "Jack", "William", "Averell");
List<String> jNames = names.stream()
.filter(name -> name.startsWith("J"))
.collect(Collectors.toList());
Veamos ahora como haríamos lo mismo con Kotlin:
val names = listOf("Joe", "Jack", "William", "Averell")
val jNames = names.filter { it.startsWith("J") }
La pregunta es por que escribimos mucho menos en Kotlin. Esto es una ventaja del azúcar sintáctico + convención ante configuración. Otro temita es que kothin no es lazy como streams de java. Pero eso es tema para otro post.
domingo, 25 de noviembre de 2018
Luchando contra NullPointerException con Kotlin - parte 2
Esta es la primera parte : https://emanuelpeg.blogspot.com/2018/11/luchando-contra-nullpointerexception.html
Como habíamos dicho Kotlin tienen diferente un montón de operadores para controlar los NullPointerException.
Veamos el operador ?. Un pequeño ejemplo:
val a = "Kotlin"
val b: String? = null
println(b?.length)
println(a?.length)
Esto devuelve b.length si b no es nulo, y nulo de lo contrario, por lo tanto esto retorna un valor de tipo : Int?
Esto es muy practico, ya que nos olvidamos de hacer muchas comprobaciones por ejemplo, si necesito el nombre del profesor del curso que esta haciendo juan :
juan?.curso?.profesor?.nombre
Como no estoy seguro que juan este haciendo un curso y el curso tenga un profesor y el profesor un nombre, uso ?.
Si queremos solo valores no nulos podemos usar let :
val listWithNulls: List<String?> = listOf("Kotlin", null)
for (item in listWithNulls) {
item?.let { println(it) } // prints A and ignores null
}
let realiza la acción si no es nulo.
el operador ?. es útil para la asignación:
person?.department?.head = managersPool.getManager()
Si person o department es nulo no asigna nada.
El operador Elvis nos permite hacer acciones si los campos son nulos, veamos un ejemplo:
fun foo(node: Node): String? {
val parent = node.getParent() ?: return null
val name = node.getName() ?: throw IllegalArgumentException("name expected")
// ...
}
El operador de aserción no-nula (!!) convierte cualquier valor a un tipo que no sea nulo y lanza una excepción si el valor es nulo:
val l = b!!.length
Deberíamos manejar el NullPointerException.
Por ultimo tenemos unos chiches, por ejemplo si un valor es nulo y queremos castear nos va traer problema si este valor es null por lo tanto tenemos el as?
val aInt: Int? = a as? Int
Si tenemos una lista que permite nulos y queremos solo los valores no nulos contemos con filterNotNull :
val nullableList: List<Int?> = listOf(1, 2, null, 4)
val intList: List<Int> = nullableList.filterNotNull()
Y ya esta, que más queres?
Dejo link:
https://kotlinlang.org/docs/reference/null-safety.html
Suscribirse a:
Entradas (Atom)
