Translate

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 :

  • 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 :


Dejo links :
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.


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 :
  • 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
Así que ese es el enfoque de abajo hacia arriba para mirar el modelo de datos de Cassandra. Ahora que conocemos la terminología básica, examinemos cada estructura con más detalle en proximos posts.

jueves, 30 de mayo de 2019

Libros de Java Geeks

Download IT Guides!

 
Spring Data?s mission is to provide a familiar and consistent, Spring-based programming model for data access while still retaining the special traits of the underlying data store. It makes it easy to use data access technologies, relational and non-relational databases, map-reduce frameworks, and cloud-based data services. In this eBook, we provide a compilation of Spring Data examples that will help you kick-start your own projects. We cover a wide range of topics, from setting up the environment and creating a basic project, to handling the various modules (e.g. JPA, MongoDB, Redis etc.). With our straightforward tutorials, you will be able to get your own projects up and running in minimum time.
 
 
Android is a mobile operating system developed by Google, based on the Linux kernel and designed primarily for touchscreen mobile devices such as smartphones and tablets. Android's user interface is mainly based on direct manipulation, using touch gestures that loosely correspond to real-world actions, such as swiping, tapping and pinching, to manipulate on-screen objects, along with a virtual keyboard for text input. In this ebook, we provide a compilation of Android programming examples that will help you kick-start your own web projects. We cover a wide range of topics, from Services and Views, to Google Maps and Bluetooth functionality. With our straightforward tutorials, you will be able to get your own projects up and running in minimum time.
 
 
java.nio (NIO stands for non-blocking I/O) is a collection of Java programming language APIs that offer features for intensive I/O operations. It was introduced with the J2SE 1.4 release of Java by Sun Microsystems to complement an existing standard I/O. The APIs of NIO were designed to provide access to the low-level I/O operations of modern operating systems. Although the APIs are themselves relatively high-level, the intent is to facilitate an implementation that can directly use the most efficient operations of the underlying platform.
 
 
IntelliJ IDEA is a Java integrated development environment (IDE) for developing computer software. It is developed by JetBrains, and is available as an Apache 2 Licensed community edition, and in a proprietary commercial edition. Both can be used for commercial development. The IDE provides for integration with build/packaging tools like grunt, bower, gradle, and SBT. It supports version control systems like GIT, Mercurial, Perforce, and SVN. Databases like Microsoft SQL Server, ORACLE, PostgreSQL, and MySQL can be accessed directly from the IDE.

domingo, 26 de mayo de 2019

Que son los System Keyspaces en Cassandra?

Cassandra tiene su propio almacenamiento para realizar un seguimiento de los metadatos sobre el clúster y el nodo local. Esto es similar a la forma en que Microsoft SQL Server mantiene las metabases de datos master y tempdb. El master se usa para mantener información sobre el espacio en disco, el uso de este, la configuración del sistema y las notas generales de instalación del servidor; el tempdb se utiliza como un espacio de trabajo para almacenar resultados intermedios y realizar tareas generales. La base de datos Oracle siempre tiene un tablespace llamado SYSTEM, usado para propósitos similares. Los System Keyspaces de Cassandra se utilizan de forma muy similar a estos.

Si vamos a cqlsh y echamos un vistazo rápido a las tablas System Keyspaces en Cassandra, si hacemos :

cqlsh> DESCRIBE TABLES;

Al observar estas tablas, vemos que muchas de ellas están relacionadas con los conceptos que se analizado en post anteriores :

  • La información sobre la estructura del clúster comunicada a través de gossip se almacena en system.local y system.peers. Estas tablas contienen información sobre el nodo local y otros nodos en el clúster, incluidas direcciones IP, ubicaciones por centro de datos y rack, CQL y versiones de protocolo.
  • system.range_xfers y system.available_ranges rastrean los rangos de token administrados por cada nodo y cualquier rango que necesite asignación.
  • Los system_schema.keyspaces, system_schema.tables y system_schema.columns almacenan las definiciones de los espacios de claves, tablas e índices definidos para el clúster.
  • La construcción de vistas materializadas se rastrea en las tablas system.materialized_views_builds_in_progress y system.built_materialized_views, lo que da como resultado las vistas disponibles en system_schema.materialized_views.
  • Extensiones proporcionadas por el usuario, como system_schema.types para tipos definidos por el usuario, system_schema.triggers para activadores configurados por tabla, system_schema. funciones para funciones definidas por el usuario, y system_schema.aggregates para agregados definidos por el usuario.
  • La tabla system.paxos almacena el estado de las transacciones en curso, mientras que la tabla system.batchlog almacena el estado de los lotes atómicos.


Volvamos a cqlsh para echar un vistazo rápido a los atributos System Keyspaces de Cassandra:

cqlsh> USE system;
cqlsh:system> DESCRIBE KEYSPACE;
CREATE KEYSPACE system WITH replication = {'class': 'LocalStrategy'} AND durable_writes = true;
...

Al observar la primera declaración en la salida, vemos que el espacio System Keyspaces está usando la estrategia de replicación LocalStrategy, lo que significa que esta información está destinada para uso interno y no se replica en otros nodos.

Clases que componen Apache Cassandra Parte 2


Y llego la continuación del post "Clases que componen Apache Cassandra" 

El Protocolo nativo CQL es el protocolo binario utilizado por los clientes para comunicarse con Cassandra. El paquete org.apache.cassandra.transport contiene las clases que implementan este protocolo, incluido el Servidor. Este servidor de transporte nativo administra las conexiones de clientes y enruta las solicitudes entrantes, delegando el trabajo de realizar consultas al StorageProxy.
Hay varias otras clases que manejan las características clave de Cassandra. Aquí hay algunos para investigar si estás interesado:















Clases que componen Apache Cassandra


Hay un conjunto de clases que forman los mecanismos básicos de control interno de Cassandra. Ya nos hemos encontrado con algunos de ellos en post anteriores, incluidos Hinted HandOffManager, CompactionManager y StageManager. Aquí presentamos una breve descripción de algunas otras clases para que pueda familiarizarse con algunas de las más importantes. Muchos de ellos exponen los MBeans a través de Java Management Extension (JMX) para informar el estado y las métricas y, en algunos casos, permitir la configuración y el control de sus actividades.

La interfaz org.apache.cassandra.service.CassandraDaemon representa el ciclo de vida del servicio Cassandra ejecutándose en un solo nodo. Incluye las operaciones típicas de ciclo de vida que se podrían esperar: iniciar, detener, activar, desactivar y destruir.

También puede crear una instancia de Cassandra en memoria mediante programación utilizando la clase org.apache.cassandra.service.EmbeddedCassandraService. Crear una instancia embebida puede ser útil para los programas de prueba unitaria que usan Cassandra.

La funcionalidad de almacenamiento de datos principal de Cassandra se conoce comúnmente como el motor de almacenamiento, que consiste principalmente en clases en el paquete org.apache.cassandra.db. El punto de entrada principal es la clase ColumnFamilyStore, que administra todos los aspectos del almacenamiento de tablas, incluidos los registros de confirmación, memtables, SSTables e índices.

Cassandra encasula el motor de almacenamiento en servicio representado por la
clase org.apache.cassandra.service.StorageService. El servicio de almacenamiento contiene el token del nodo, que es un marcador que indica el rango de datos de los que es responsable el nodo.
El servidor se inicia con una llamada al método initServer de esta clase, en el que el servidor registra los controladores SEDA, realiza algunas determinaciones sobre su estado (por ejemplo, si fue un programa de arranque o no, y cuál es su particionador), y registra un MBean con el servidor JMX.

El propósito de org.apache.cassandra.net.MessagingService es crear listeners de socket para el intercambio de mensajes; los mensajes entrantes y salientes de este nodo llegan a través de este servicio. El método MessagingService.listen crea un hilo. Cada conexión entrante luego se sumerge en el grupo de subprocesos ExecutorService usando org.apache.cassandra.net.IncomingTcpConnection (una clase que extiende Thread) para deserializar el mensaje. El mensaje se valida y luego se enruta al controlador apropiado.

Debido a que MessagingService también hace un uso intensivo de las etapas y el grupo que mantiene está envuelto con un MBean, puede descubrir mucho sobre cómo está funcionando este servicio (si las lecturas se están respaldando y demás) a través de JMX.

La transmisión por secuencias es la forma optimizada de Cassandra de enviar secciones de archivos SSTable de un nodo a otro a través de una conexión TCP persistente; todas las demás comunicaciones entre nodos se producen a través de mensajes serializados. org.apache.cassandra.streaming.StreamManager maneja estos mensajes de transmisión, incluida la administración de la conexión, la compresión de mensajes, el seguimiento de progreso y las estadísticas.

Nos quedan unas cuantas clases que seguiremos viendo en una parte 2.



viernes, 24 de mayo de 2019

Usando .NET y Docker


NET Core es cada día más amigable con docker y todas las mejoras se centraron en .NET Core 3.0. El cambio más importante fue la reducción de la memoria que utiliza en tiempo de ejecución de .NET Core (CoreCLR) de forma predeterminada. El CoreCLR gestiona la ejecución de todos los programas .NET Core; la memoria que utiliza de forma predeterminada es la cantidad de memoria asignada inicialmente cuando se ejecuta un programa .NET. Reducir el uso de memoria CoreCLR predeterminado significa aumentar la eficiencia de uso de memoria del contenedor sin cambiar la configuración predeterminada de .NET Core.

Con las modificaciones recientes, .NET Core 3.0 ahora también admite límites de recursos de Docker (memoria y CPU). Los límites de recursos permiten controlar cuánta memoria o CPU puede usar un contenedor. Estos límites se describen en términos de cantidad tanto para la memoria como para la CPU (es decir, 128 MB de memoria o dos CPU). Cuando se establecen los límites de memoria, .NET Core 3.0 cambia su comportamiento en consecuencia: el tamaño del montón del recolector de basura está limitado a 20 MB o 75% del límite de memoria. En el caso de los límites de la CPU, el valor establecido en Docker se redondea al siguiente valor entero. Este valor es el número máximo efectivo de núcleos de CPU utilizados por CoreCLR.

Las mejoras también afectaron la capacidad de uso de .NET en los contenedores de Docker a un nivel superior. De acuerdo con la solicitud de la comunidad, Microsoft agregó PowerShell Core como una aplicación independiente a las imágenes de contenedor de .NET Core SDK Docker disponibles. Además, las imágenes de contenedor de .NET Core ahora están disponibles a través de Microsoft Container Registry (MCR). Esto permite utilizar Microsoft Azure como la fuente oficial de imágenes de contenedor provistas por Microsoft, y como una red de distribución de contenido global (CDN) para entregar imágenes de contenedor de acuerdo con la ubicación geográfica del usuario.

Si bien .NET Core es compatible con múltiples distribuciones y versiones de plataforma, la lista de distribuciones compatibles para Docker es mucho más pequeña. Por el momento, solo se admiten versiones específicas de las distribuciones Alpine, Debian y Ubuntu, junto con todas las versiones de Windows Nano Server. El equipo de .NET Core está en proceso de agregar soporte para ARM64 en Linux.

Richard Lander, gerente de programas del equipo de .NET, dijo en la publicación del blog sobre las mejoras: "Estamos comprometidos en hacer de .NET un runtime de contenedores. En versiones anteriores, pensamos en .NET Core como un contenedor amigable. Ahora estamos fortaleciendo el tiempo de ejecución para que sea consciente de los contenedores y funcione de manera eficiente en entornos de poca memoria ".

La comunidad .NET recibió bien las mejoras en el rendimiento del marco. Además de la publicación del blog, los oradores de Microsoft y Docker presentaron varias sesiones en DockerCon 2019 relacionadas con el desarrollo de .NET mediante contenedores. Una de estas sesiones se centró en la contención de aplicaciones .NET heredadas, que es un tema de especial interés para las empresas con una larga historia de desarrollo utilizando .NET. Esta sesión fue organizada por un representante de Docker, e ilustra los esfuerzos recientes de la compañía de estimular el uso de contenedores por parte de la industria y apoyar a la comunidad de desarrolladores.

Los esfuerzos de Microsoft parecen alinearse con las intenciones de Docker, así como con otras iniciativas de diferentes comunidades de desarrollo. Otras áreas de productos de Microsoft están siguiendo la misma tendencia: a principios de este mes, Microsoft lanzó una nueva extensión de desarrollo remoto para VS Code, que permite el desarrollo continuo utilizando contenedores remotos junto con una instancia local de VS Code.

Dejo link: https://devblogs.microsoft.com/dotnet/using-net-and-docker-together-dockercon-2019-update/

domingo, 19 de mayo de 2019

Arquitectura dirigida por eventos (SEDA) en Apache Cassandra


El diseño de Cassandra fue influenciado por Staged Event-Driven Architecture (SEDA). SEDA es una arquitectura general para servicios de Internet altamente concurrentes, propuesta originalmente en un documento de 2001 llamado "SEDA: An Architecture for Well-Conditioned, Scalable
Internet Services" de Matt Welsh, David Culler y Eric Brewer. Puede leer el documento original de SEDA en http://www.eecs.harvard.edu/~mdw/proj/seda.

En una aplicación típica, una sola unidad de trabajo se realiza a menudo dentro de los límites de un solo hilo. Una operación de escritura, por ejemplo, comenzará y terminará dentro del mismo hilo. Cassandra, sin embargo, es diferente: su modelo de concurrencia se basa en SEDA, por lo que una sola operación puede comenzar con un hilo, que luego pasa el trabajo a otro hilo, que puede pasarlo a otros hilos. Pero no corresponde al hilo actual entregar el trabajo a otro hilo. En su lugar, el trabajo se subdivide en lo que se denomina etapas, y el grupo de subprocesos (en realidad, un servicio java.util.concurrent.Executor) asociado con la etapa determina la ejecución.

Una etapa es una unidad básica de trabajo, y una sola operación puede realizar una transición interna de estado de una etapa a la siguiente. Debido a que cada etapa puede ser manejada por un grupo de subprocesos diferente, Cassandra experimenta una mejora masiva del rendimiento. Este diseño también significa que Cassandra puede administrar mejor sus propios recursos internamente porque diferentes operaciones pueden requerir Entrada y Salida de disco, o pueden estar vinculadas al CPU, o pueden ser operaciones de red, y así sucesivamente, para que los grupos puedan administrar su trabajo de acuerdo a la disponibilidad de estos recursos.

Una etapa consiste en una cola de eventos entrantes, un controlador de eventos y un grupo de subprocesos asociado. Las etapas son administradas por un controlador que determina la programación y la asignación de subprocesos; Cassandra implementa este tipo de modelo de concurrencia utilizando el grupo de subprocesos java.util.concurrent.ExecutorService. Para ver específicamente cómo funciona esto, echa un vistazo a la clase org.apache.cassandra.concurrent.StageManager. Las siguientes operaciones se representan como etapas en Cassandra, incluidos muchos de los conceptos que hemos analizado en post anteriores :


Algunas operaciones adicionales también se implementan como etapas, como las operaciones en memtables que incluyen el vaciado de datos a SSTables y la liberación de memoria. Las etapas implementan la interfaz IVerbHandler para admitir la funcionalidad de un verbo dado. Debido a que la idea de mutación se representa como una etapa, puede desempeñar un papel en las operaciones de inserción y eliminación.

Dejo link : https://en.wikipedia.org/wiki/Staged_event-driven_architecture


sábado, 18 de mayo de 2019

Libros de Java Code Geeks

Download IT Guides!

 
Git is, without any doubt, the most popular version control system. Ironically, there are other version control systems easier to learn and to use, but, despite that, Git is the favorite option for developers, which is quite clarifying about the powerfulness of Git. In this guide, we will cover all the topics needed to know in order to use Git properly, from explaining what is it and how it differs from other tools, to its usage, covering also advanced topics and practices that can suppose an added value to the process of version controlling.
 
 
The Spring Framework is an open-source application framework and inversion of control container for the Java platform. The framework's core features can be used by any Java application, but there are extensions for building web applications on top of the Java EE platform. Although the framework does not impose any specific programming model, it has become popular in the Java community as an alternative to, replacement for, or even addition to the Enterprise JavaBeans (EJB) model.
 
 
Apache Hadoop is an open-source software framework written in Java for distributed storage and distributed processing of very large data sets on computer clusters built from commodity hardware. In this eBook, we provide a compilation of Hadoop based examples that will help you kick-start your own web projects. We cover a wide range of topics, from installation and configuration, to distributed caching and streaming. 
 
 
Selenium is a portable software testing framework for web applications. Selenium provides a record/playback tool for authoring tests without learning a test scripting language (Selenium IDE). It also provides a test domain-specific language (Selenese) to write tests in a number of popular programming languages, including Java, C#, Groovy, Perl, PHP, Python and Ruby.
 

jueves, 16 de mayo de 2019

Borrar redologs viejos en Oracle

Si utilizamos las base de datos Oracle estaremos familiarizados con el modo ArchiveLog. En este modo la base de datos archiva redologs viejos, lo que nos permite realizar muchas acciones de recuperación de datos, pero nos llena el disco. Por esa razon es conveniente periodicamente remoder redologs muy antiguos.

Para hacerlo debemos utilizar la herramienta RMAN. Para esto nos logeamos en el servidor y tipiamos rman:

% rman

RMAN>

Las conexiones RMAN a una base de datos se especifican y autentican de la misma manera que las conexiones SQL * Plus a una base de datos. La única diferencia es que las conexiones RMAN a una base de datos de destino o auxiliar requieren el privilegio SYSDBA. Las palabras clave AS SYSDBA están implícitas y no se pueden especificar explícitamente.

Puede conectarse a una base de datos con opciones de línea de comandos o mediante el comando CONNECT TARGET. El siguiente ejemplo inicia RMAN y luego se conecta a una base de datos de destino a través de Oracle Net (tenga en cuenta que AS SYSDBA no se especifica porque está implícito). RMAN solicita una contraseña.

RMAN>  CONNECT TARGET SYS@SERVER


Primero listamos los logs :


RMAN> list archivelog all;


Luego removemos los que tienen más de 10 días


RMAN> delete archivelog until time 'SYSDATE-10';



released channel: ORA_DISK_1

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=55 device type=DISK

List of Archived Log Copies for database with db_unique_name SERVER

=====================================================================



Key     Thrd Seq     S Low Time

------- ---- ------- - ---------

504     1    635     A 26-MAR-19

        Name: /1_635_966300309.dbf



505     1    636     A 27-MAR-19

        Name: /1_636_966300309.dbf



...

Do you really want to delete the above objects (enter YES or NO)? YES

deleted archived log

archived log file name=/1_635_966300309.dbf RECID=504 STAMP=1003998698

deleted archived log

...


Y Listo!

También podemos eliminar los logs y de las siguientes maneras :

RMAN>delete archivelog all;
RMAN>delete archivelog until time ‘SYSDATE-10’;
RMAN>delete archivelog from time ‘SYSDATE-10’
RMAN>delete archivelog from time ‘SYSDATE-10’ until time ‘SYSDATE-2’;
RMAN>delete archivelog from sequence 1000;
RMAN>delete archivelog until sequence 1500;
RMAN>delete archivelog from sequence 1000 until sequence 1500;



domingo, 12 de mayo de 2019

Anti-Entropia, Reparación y Arboles de Merkle en Cassandra



Cassandra utiliza un protocolo anti-entropico, que es un tipo de protocolo gossip para reparación de replicas de datos. Los protocolos anti-entropicos funcionan por medio de comparación de las diferentes replicas de datos y conciliando las diferencias entre las replicas. Los protocolos anti-entropicos son usados por muchas bases de datos noSql como Amazon’s Dynamo.

La sincronización de réplicas se admite a través de dos modos diferentes conocidos como reparación de lectura y reparación anti-entropía. La reparación de lectura se refiere a la sincronización de las réplicas a medida que se leen los datos. Cassandra lee los datos de varias réplicas para alcanzar el nivel de consistencia solicitado y detecta si alguna réplica tiene valores desactualizados. Si un número insuficiente de nodos tiene el último valor, se realiza una reparación de lectura inmediatamente para actualizar las réplicas desactualizadas. De lo contrario, las reparaciones se pueden realizar en segundo plano después de las devoluciones de lectura. Esta funcionalidad no es solo de Cassandra, también es utilizada en bases noSql clave/valor como Voldemort y Riak.

La reparación anti-entropica (a veces llamada reparación manual) es una operación iniciada manualmente en nodos como parte de un proceso de mantenimiento regular. Este tipo de reparación se ejecuta mediante una herramienta llamada nodetool. La ejecución de la reparación de nodetool hace que Cassandra ejecute una compactación principal. Durante una compactación principal, el servidor inicia una conversación TreeRequest / TreeReponse para intercambiar árboles Merkle con nodos vecinos. El árbol Merkle es un hash que representa los datos en esa tabla. Si los árboles de los diferentes nodos no coinciden, deben ser reconciliados (o "reparados") para determinar los valores de datos más recientes en los que se deben configurar. Esta validación de comparación de árbol es responsabilidad de la clase org.apache.cassandra.service.AbstractReadExecutor.

Los arboles de Merkle son utilizados por Cassandra y Dynamo para conciliar los datos de diferentes nodos, su nombre se debe a su inventor Ralph Merkle y se lo conoce tambien como “hash tree.” En cassandra esto se implementa con la clase org.apache.cassandra.utils.MerkleTree.

Tanto Cassandra y Dynamo utilizan arboles hash como un protocolo anti-entropico pero su implementación es un tanto diferente. En Cassandra cada tabla tiene su propio arbol, y esto es construido como un snapshot o fotografía en el momento de una compactación principal y se mantiene solo el tiempo necesario para enviarlo a los nodos vecinos en el anillo. La ventaja de esta implementación es que reduce la entrada/salida de la red.