29 agosto 2017

¿Hay vida más allá de Oracle? Hoy presentamos PrestoDB

Este artículo está hecho para que los posibles administradores y usuarios finales sepan qué esperar de Presto.


Definición

Presto es un motor de consulta SQL distribuido diseñado para consultar conjuntos de datos grandes distribuidos sobre una o más fuentes de datos heterogéneas.


Lo que no es Presto DB en la actualidad

Debido a que Presto está siendo llamado una base de datos por muchos miembros de la comunidad, tiene sentido comenzar con una definición de lo que Presto no es.

No confunda el hecho de que Presto entiende SQL con él que proporciona las características de una base de datos estándar. Presto no es una base de datos relacional de uso general. No es un reemplazo para bases de datos como MySQL, PostgreSQL u Oracle. Presto no fue diseñado para procesar transacciones en línea (OLTP). Esto también es cierto para muchas otras bases de datos diseñadas y optimizadas para data warehouse o análisis de datos.

¿Qué es Presto?

Presto es una herramienta diseñada para consultar eficientemente grandes cantidades de datos mediante consultas distribuidas. Si trabaja con terabytes o petabytes de datos, es probable que utilice herramientas que interactúen con Hadoop y HDFS. Presto fue diseñado como una alternativa a las herramientas que consultan HDFS usando tuberías de trabajos de MapReduce como Apache Hive o Pig, pero Presto no se limita a acceder a HDFS. Presto puede ser ampliado para operar sobre diferentes tipos de fuentes de datos, incluyendo bases de datos relacionales tradicionales y otras fuentes de datos como Cassandra.

Presto fue diseñado para manejar data warehousing y análisis: análisis de datos, agregando grandes cantidades de datos y produciendo reportes. Estas cargas de trabajo se clasifican a menudo como procesamiento analítico en línea (OLAP).

¿Quién usa Presto?


Presto es un proyecto de código abierto que funciona bajo los auspicios de Facebook. Fue inventado en Facebook y el proyecto continúa siendo desarrollado por los desarrolladores internos de Facebook y un número de desarrolladores de terceros en la comunidad. En mi último trabajo se usó para sustituir a la base de datos que soportaba el modelo de datawarehouse, debido a coste económico del mantenimiento.

Presto es un sistema distribuido que se ejecuta en un grupo de máquinas. Una instalación completa incluye un coordinador y varios trabajadores. Las consultas se envían desde un cliente como la CLI Presto al coordinador. El coordinador analiza, analiza y planifica la ejecución de la consulta, luego distribuye el procesamiento a los trabajadores.

Requisitos

Presto tiene algunos requisitos básicos: 
  • Linux o Mac OS X
  • Java 8, 64 bits
  • Python 2.4+



Conectores

Presto admite conectores enchufables que proporcionan datos para consultas. Los requisitos varían según el conector.

HADOOP / HIVE

Presto admite la lectura de datos de cola de las siguientes versiones de Hadoop: 
    • Apache Hadoop 1.x
    • Apache Hadoop 2.x
    • Cloudera CDH 4
    • Cloudera CDH 5

Se admiten los siguientes formatos de archivo: Texto, Archivo secuencial, RCFile, ORC y Parquet.

Además, se requiere un metastore remoto de colmena. No se admite el modo local o incorporado. Presto no usa MapReduce y por lo tanto sólo requiere HDFS.

CASSANDRA

Se requiere Cassandra 2.x. Este conector es completamente independiente del conector Hive y sólo requiere una instalación de Cassandra existente.

TPC-H

El conector TPC-H genera dinámicamente datos que pueden utilizarse para experimentar y probar Presto. Este conector no tiene requisitos externos.

Despliegue

Consulte Implementación de Presto para obtener instrucciones completas de implementación.

Ejecución de consultas

Puede ejecutar consultas utilizando la Interfaz de línea de comandos después de implementar Presto.
La CLI de Presto proporciona un shell interactivo basado en terminal para ejecutar consultas. La CLI es un archivo JAR que se ejecuta automáticamente, lo que significa que actúa como un ejecutable normal de UNIX.

Descargar presto-cli-0.183-ejectable.jar, renombrarlo a presto, hacerlo ejecutable con chmod + x, luego ejecutarlo:

./presto --server localhost: 8080 --cambio de catálogo --schema default

Ejecute la CLI con la opción --help para ver las opciones disponibles.


De forma predeterminada, los resultados de las consultas se paginan utilizando el programa menos que está configurado con un conjunto cuidadosamente seleccionado de opciones. Este comportamiento se puede sobreescribir estableciendo la variable de entorno PRESTO_PAGER al nombre de un programa diferente como, por ejemplo, más o establecerlo en un valor vacío para desactivar completamente la paginación.

28 agosto 2017

Entender Oracle Data Guard

En este artículo, escribiré sobre la solución de recuperación de desastres de Oracle (recuperación de desastres). Voy a dar la terminología básica en una breve información sobre el Data Guard. Como gestores de datos, estamos obligados a tomar las medidas necesarias antes de que ocurran estos desastres. También hay que considerar tomar las acciones necesarias que son muy importantes. Estos son;
  • RPO (Recovery Point Objective) - ¿Cuántos datos puede permitirse perder?
  • RTO (Recovery Time Objective) - Sin acceso a los datos, ¿Cuanto tiempo puedes soportar?

De acuerdo con las respuestas de estas preguntas debemos establecer el sistema de copia de seguridad. No estamos satisfechos con la instalación de nuestro sistema, y ​​debemos monitorear nuestro sistema.

Ahora, veamos la solución que Oracle propone:  Oracle Data Guard.

Oracle Data Guard es la solución de recuperación de desastres. Protege nuestra base de datos de producción de los desastres, reduciendo la carga de trabajo sobre ella y su uso más efectivo. Technology, introducida por primera vez mediante el establecimiento de la base de datos de reserva manualmente con Oracle 7. Apareció como un Data Guard con Oracle 8i. 

Evolución histórica de Oracle Data Guard
Si examinamos las características de un Data Guard desde el pasado hasta el presente;
  • ORACLE 8i
    • Base de datos en espera de sólo lectura
    • Recuperación gestionada
    • Archivo de registro de rehacer archivos remotos
  • ORACLE 9i
    • Integración "Pérdida de datos cero"
    • Data Guard Broker y Data Guard Manager GUI
    • Operaciones de Switcover y Failover
    • Sincrónico automático
    • Base de datos de espera lógica
    • Protección máxima
  • ORACLE 10g
    • Aplicación en tiempo real
    • Soporte forzado para Oracle RAC
    • Failover de arranque rápido
    • Transferencia asíncrona de rehacer
    • Base de datos Flashback
  • ORACLE 11g
    • Base de datos de espera activa (Active Data Guard)
    • Instantánea de la instantánea
    • Soporte de plataforma heterogénea (Producción -Linux, Standby - Windows)
  • ORACLE 12C
    • Funciones comunes a Redo Apply y SQL Apply
    • Funciones especificas a Redo Apply
    • Funciones especificas a  SQL Apply




FLUJO DE DATOS: PHYSICAL STANDBY
Vamos a entender cómo los datos fluyen en la configuración de Oracle Data Guard mostrada arriba en ocho puntos:


  • En la base de datos principal, se inician las transacciones. Todos los bloqueos de caché del búfer (bloqueos exclusivos) que se requieren para la transacción se obtienen.
  • En la base de datos principal, los bloques de rehacer que describen los cambios (o los vectores de cambio) se generan y almacenan en el Área Global del Programa (PGA) de los procesos. Después de adquirir con éxito el bloqueo de rehacer asignación, el espacio se asigna en el búfer de registro de rehacer. El redo generado se copia de PGA de los procesos en el búfer de registro de rehacer.
  • En la base de datos primaria, el proceso de primer plano de oracle le indica a LGWR que limpie los búferes de registro de rehacer en el disco. Recuerde que los bloques de base de datos de la base de datos aún no se han actualizado con los cambios DML. El LGWR descarga los buffers de redo al ORL y reconoce la finalización de la sesión. En este punto, la transacción es persistente en el disco. No se ha cometido hasta el momento.



En algún momento futuro, los buffers de base de datos que fueron cambiados previamente serán escritos en disco por el proceso de escritura de base de datos (DBWR) en el momento del punto de control. Este punto no está marcado en el diagrama anterior.
Tenga en cuenta que antes de que el proceso DBWR haya descargado los búferes de la base de datos a los discos, el proceso LGWR debe haber escrito ya los búferes de rehacer en el disco. Esta secuencia explícita es reforzada por el protocolo de registro anticipado.
También el proceso ARCH en la base de datos primaria archiva los ORL en archivos de registro de archivos. Este punto tampoco está marcado en el diagrama anterior.

  • En la base de datos primaria, el proceso LNS lee el redo recientemente descargado del búfer de registro de redo y envía los datos de rehacer a la base de datos en espera utilizando el destino de transporte redo (LOG_ARCHIVE_DEST_n) que definimos durante la creación de la base de datos en espera. Estamos utilizando el método de transporte ASYNC, por lo que el LGWR no espera ningún reconocimiento de la LNS para esta operación de envío de red. No se comunica con el LNS excepto para iniciarlo en la etapa de inicio de la base de datos y después de un fallo de una conexión en espera.
  • En la base de datos de espera, el RFS lee el flujo de rehacer desde el socket de red en los búferes de red y, a continuación, escribe este flujo de rehacer a la SRL.
  • En la base de datos de espera, el proceso ARCH archiva las SRL en archivos de registro de archivo cuando se produce un cambio de registro en la base de datos primaria. El archivo de registro de archivo generado se registra con el archivo de control de espera.
  • En la base de datos de espera, el proceso de recuperación real comienza en este paso. El proceso de recuperación administrado (MRP) leerá de forma asincrónica el rehacer de los SRL o de los registros de rehacer archivados (cuando la recuperación se reduce o no se aplica en tiempo real). Los bloques que requieren redo apply se analizan y se colocan en segmentos de mapa en memoria apropiados.
  • En la base de datos en espera, el proceso MRP envía rehacer a los esclavos de recuperación utilizando el marco de comunicación entre procesos de consulta en paralelo (PQ). Medios paralelos

Recuperación (PMR) hace que los bloques de datos requeridos sean leídos en la caché del búfer, y posteriormente redo se aplicará a estos búferes del búfer del búfer.


PROCESOS RELACIONADOS CON BASE DE DATOS EN ESPERA FÍSICA

En la base de datos primaria:
  • LGWR: El proceso de escritura de registros vacía los buffers de registro de los archivos SGA a Online Redo Log.
  • LNS: El servicio de red de LogWriter (LNS) lee el redo que es descargado de los almacenadores intermediarios del redo por el LGWR y envía el redo sobre red a la base de datos espera. El propósito principal del proceso LNS es liberar el proceso LGWR de realizar el rol redo transport. 
  • ARCH: El archivador procesa los archivos de ORL para archivar los archivos de registro. Pueden existir hasta 30 procesos ARCH, y estos procesos ARCH también se utilizan para satisfacer solicitudes de resolución de huecos. Tenga en cuenta que un proceso ARCH tiene un papel especial en que está dedicado al archivo de registro de redo local solo y nunca se comunica con una base de datos en espera.

En la base de datos de reserva:
  • RFS: El objetivo principal del proceso de servidor de archivos remotos es realizar una red de recepción de redo transmitida desde el sitio principal y, a continuación, escribe el búfer de red (rehacer datos) a los archivos de redo registro (SRL) en espera.
  • ARCH: Los procesos de archivo en el sitio en espera realizan las mismas funciones realizadas en el sitio principal, excepto que en el sitio en espera, un proceso ARCH genera archivos de registro archivados de las SRL.
  • MRP: el proceso de recuperación administrado coordina la administración de recuperación de medios. Recuerde que un modo de espera físico está en modo de recuperación perpetua.
Básicamente, podemos categorizar la base de datos de espera física en tres componentes principales:

Data Guard Redo Servicios de Transporte
Para transferir el redo generado por la base de datos primaria a la base de datos en espera.

Data Guard Aplicar Servicios
Para recibir y aplicar el redo enviado por Redo Transport Services a la base de datos en espera.

Data Guard servicios de gestión de roles
Para ayudar en los cambios de rol de la base de datos en los escenarios de conmutación y conmutación por error- Este servicio funciona en segundo plano y se ocupa de los escenarios de conmutación / conmutación por error

27 agosto 2017

Nueva versión de Oracle GoldenGate para Big Data 12.3.1.1



En este artículo vamos a ver, Lo que todo el mundo debe saber sobre Oracle GoldenGate Big Data 12.3.1.1 

Las principales características de esta versión incluyen las siguientes novedades
  • Como nuevos objetivos de Oracle GoldenGate 12c se encuentran los siguientes sistemas:
    • Amazon Kinesis
    • API de Integración Kafka o Kafka Connect Confluent.
    • Elasticsearch
  • El Motor de Oracle GoldenGate Core 12.3: soporta los formatos de base de datos Oracle Database 12.2 y más recientes
  • Nuevas Certificaciones:
    • Apache Hadoop 2.8,
    • CDH 5.10, 5.11,
    • Hive 2.x,
    • Kafka 0.10, 0.11,
    • Cassandra 3.11
    • ...
  • Mapeo de plantillas: define plantillas para resolver dinámicamente el nombre de secuencia y la clave de partición en tiempo de ejecución
  • Rendimiento: Rendimiento mejorado hasta el 20% en comparación con la versión anterior.



Oracle GoldenGate ofrece una arquitectura modular diseñada para un rendimiento extremo, tolerancia a fallos y flexibilidad. Oracle GoldenGate para Big Data se basa en la misma arquitectura para permitir soluciones extensibles para los grandes entornos de datos de los clientes.
Oracle GoldenGate captura datos de sistemas fuente heterogéneos incluyendo sistemas de mensajería basados en Java, de forma no invasiva y con gastos indirectos insignificantes. Almacena transacciones de base de datos en archivos planos y lo bombea al marco del Adaptador Java.

Oracle GoldenGate para Big Data incluye controladores para diferentes grandes tecnologías de datos, como HDFS, Hive, HBase, Flume, Kafka, NoSQL, JDBC, etc. También incluye tecnología de formateo conectable que puede usarse para transformar datos en formatos estándar como XML , JSON, Avro, Texto delimitado. Está construido utilizando la arquitectura Java extensible, que le permite entregar fácilmente a otros grandes sistemas de datos y soportar casos de uso específicos para satisfacer sus demandas empresariales.

Con la plataforma de streaming en tiempo real de Oracle GoldenGate, puede capturar desde el sistema de origen una vez y entregar todo o una parte de los datos modificados a múltiples destinos sobre cloud, híbridos e incluso bases de datos, sistemas de mensajería y entornos de datos grandes.



En siguientes entradas de blog haremos un ejemlo de uso de GoldenGate con Big Data.