|
Mostrando las entradas con la etiqueta JDBC. Mostrar todas las entradas
Mostrando las entradas con la etiqueta JDBC. Mostrar todas las entradas
miércoles, 16 de diciembre de 2020
Libros Gratuitos de Java code Geeks
miércoles, 17 de junio de 2020
Libros de Java Geeks
|
domingo, 14 de junio de 2020
JDBC en fibras
Si bien JDBC y otras tecnologías exponen API de bloqueo (principalmente debido a la espera de I/O), se está trabajando en el Project Loom. Loom presenta Fibers como una abstracción ligera que convertirá las API de bloqueo en no bloqueantes. Esto es posible mediante el cambio de pila tan pronto como una invocación golpea una API de bloqueo. Entonces, el Fiber subyacente intenta continuar en un flujo anterior que estaba usando una API de bloqueo.
El modelo de ejecución de Fiber reduce drásticamente la cantidad de hilos nativos requeridos. La consecuencia es una mejor escalabilidad y un comportamiento sin bloqueo, al descargar las llamadas de bloqueo a un ejecutor. Todo lo que necesitamos aquí es una API adecuada que permita el consumo de un JDBC sin bloqueo implementado con Fibras.
comsat-jdbc proporciona un contenedor de bloqueo de fibra de la API JDBC, para que pueda usar su conexión dentro de fibras en lugar de hilos Java normales.
¿Por qué harías eso? Debido a que las fibras son hilos livianos y puede tener muchas más fibras que hilos en su JVM. "Muchos más" significa que estamos hablando de millones frente a un puñado de miles.
Esto significa que tiene mucha más capacidad de concurrencia en su sistema para hacer otras cosas en paralelo mientras espera la ejecución de JDBC, ya sean cálculos simultáneos y/o paralelos (como el intercambio de mensajes de actores) o fibra -bloqueo de I/O (p. ej., servicio de solicitudes, invocación de microservicios, lectura de archivos a través de NIO en fibra o acceso a otras fuentes de datos habilitadas para fibra como MongoDB).
Las Fibras son una solución al problema de bloqueo de JDBC. Deberíamos hablar un poco más del proyecto Loom pero pero pero, esto es otra historia y va ha ser contada en otro post ...
Programación reactiva + bases de datos relacionales = R2DBC
Al carecer de una API estándar y la falta de disponibilidad de controladores, un equipo de Pivotal comenzó a investigar la idea de una API relacional reactiva que sería ideal para fines de programación reactiva. Y en ese momento nació, R2DBC que significa Conectividad de base de datos relacional reactiva.
Entre las características de R2DBC podemos nombrar:
R2DBC se basa en la especificación de Reactive Streams, que proporciona una API sin bloqueo totalmente reactiva.
Trabaja con bases de datos relacionales. A diferencia de la naturaleza bloqueante de JDBC, R2DBC le permite trabajar con bases de datos SQL utilizando una API reactiva.
Admite soluciones escalables. Con Reactive Streams, R2DBC le permite pasar del modelo clásico de "un subproceso por conexión" a un enfoque más potente y escalable.
Proporciona una especificación abierta. R2DBC es una especificación abierta y establece una interfaz de proveedor de servicios (SPI) para que los proveedores de controladores implementen y los clientes los consuman.
Actualmente existen las siguientes implementaciones :
- cloud-spanner-r2dbc: controlador para Google Cloud Spanner
- jasync-sql: contenedor R2DBC para Java & Kotlin Async Database Driver para MySQL y PostgreSQL escrito en Kotlin.
- r2dbc-h2: controlador nativo implementado para H2 como base de datos de prueba.
- r2dbc-mariadb: controlador nativo implementado para MariaDB.
- r2dbc-mssql: controlador nativo implementado para Microsoft SQL Server.
- r2dbc-mysql: controlador nativo implementado para MySQL.
- r2dbc-postgres: controlador nativo implementado para PostgreSQL.
Los estándares existentes, basados en el bloqueo de I/O, cortan la programación reactiva de los usuarios de bases de datos relacionales. R2DBC especifica una nueva API para permitir código reactivo que funciona de manera eficiente con bases de datos relacionales.
R2DBC es una especificación diseñada desde cero para la programación reactiva con bases de datos SQL. Define un SPI sin bloqueo para implementadores de controladores de bases de datos y autores de bibliotecas de clientes. Los controladores R2DBC implementan completamente el protocolo de conexión de la base de datos sobre una capa de I/O sin bloqueo.
R2DBC está pensado principalmente como un SPI del controlador para ser consumido por las bibliotecas del cliente y no para ser utilizado directamente en el código de la aplicación.
R2DBC admite aplicaciones nativas en la nube que utilizan bases de datos relacionales como PostgreSQL, MySQL y otras. Los desarrolladores de aplicaciones son libres de elegir la base de datos adecuada para el trabajo sin estar limitados por las API.
Spring Data R2DBC, parte de la familia Spring Data, facilita la implementación de repositorios basados en R2DBC. Spring Data R2DBC aplica abstracciones de la familia de Spring y soporte de repositorio para R2DBC. Facilita la creación de aplicaciones basadas en Spring que utilizan tecnologías de acceso a datos relacionales en una stack de aplicaciones reactivas.
Spring Data R2DBC pretende ser conceptualmente fácil. Para lograr esto, NO ofrece almacenamiento en caché, carga diferida, escritura detrás o muchas otras características de los marcos ORM. Esto hace que Spring Data R2DBC sea un mapeador de objetos simple, limitado y con opiniones.
Spring Data R2DBC permite un enfoque funcional para interactuar con su base de datos proporcionando DatabaseClient como el punto de entrada para las aplicaciones.
Veamos un ejemplo con postgres :
PostgresqlConnectionFactory connectionFactory = new PostgresqlConnectionFactory(PostgresqlConnectionConfiguration.builder()
.host(…)
.database(…)
.username(…)
.password(…).build());
DatabaseClient client = DatabaseClient.create(connectionFactory);
Mono<Integer> affectedRows = client.execute()
.sql("UPDATE person SET name = 'Joe'")
.fetch().rowsUpdated();
Flux<Person> all = client.execute()
.sql("SELECT id, name FROM person")
.as(Person.class)
.fetch().all();
Otro enfoque para atacar el bloqueo de JDBC es Fibers. Fibers como una abstracción ligera que convertirá las API de bloqueo en no bloqueantes. Esto es posible mediante el cambio de pila tan pronto como una invocación ... Pero eso es otra Historia y va ha ser contada en otro post ...
Dejo links:
Programación reactiva y bases de datos relacionales
Los beneficios completos de la programación reactiva entran en vigencia solo si toda el stack de tecnologías es reactiva y si todos los componentes participantes (código de aplicación, contenedor de tiempo de ejecución, integraciones) respetan la ejecución diferida, las API sin bloqueo y la naturaleza de flujo de flujo de datos, básicamente siguiendo los supuestos subyacentes .
Si bien es posible llevar componentes no reactivos a una aplicación que está escrita en un estilo funcional-reactivo, el resultado neto es que los beneficios reales esperados, disminuyen. En el peor de los casos, hay poca o ninguna diferencia en el comportamiento del tiempo de ejecución. Sin embargo, la programación reactiva ayuda a mejorar la legibilidad del código.
Si observamos el ecosistema reactivo, descubriremos varios frameworks, bibliotecas e integraciones. Cada uno de ellos tiene sus puntos fuertes específicos. Muchas áreas funcionales están bien cubiertas, ya sea con un enfoque genérico o dentro del contexto de un framework reactivo particular.
Java utiliza JDBC como tecnología principal para integrarse con bases de datos relacionales. JDBC es de naturaleza bloqueante: no hay nada sensato que se pueda hacer para mitigar la naturaleza bloqueante de JDBC. La primera idea de cómo hacer que las llamadas no se bloqueen es descargar las llamadas JDBC a un ejecutor (generalmente grupo de subprocesos). Si bien este enfoque funciona, viene con varios inconvenientes que descuidan los beneficios de un modelo de programación reactiva.
Los grupos de subprocesos requieren, no es de extrañar, subprocesos para ejecutarse. Los tiempos de ejecución reactivos suelen utilizar un número limitado de subprocesos que coinciden con el número de núcleos de CPU. Los hilos adicionales introducen gastos generales y reducen el efecto de limitación de hilos. Además, las llamadas JDBC generalmente se acumulan en una cola, y una vez que los hilos están saturados de solicitudes, el grupo se bloqueará nuevamente. Entonces, JDBC ahora no es una opción.
Hay un par de controladores independientes, como el reactive-pg-client. Estos controladores vienen con una API específica del proveedor y no son realmente adecuados para una adopción más amplia.
Como no hay una API estándar y la falta de disponibilidad de controladores, un equipo de Pivotal comenzó a investigar la idea de una API relacional reactiva que sería ideal para fines de programación reactiva. Se les ocurrió R2DBC que significa Conectividad de base de datos relacional reactiva. Pero eso es otra Historia y va ha ser contada en otro post ...
Dejo link:
jueves, 19 de diciembre de 2019
Libros de Java Code Geeks
|
jueves, 10 de octubre de 2019
Libros de Java geek
|
jueves, 13 de diciembre de 2018
Libro gratuitos sobre Linux, postgresql, jetty, jdbc
Download Dev Guides!
|
| ||||||
|
|
sábado, 10 de diciembre de 2011
Spring Data
Spring Data hace fácil la construcción de aplicaciones que usan nuevas formas de almacenar datos como por ejemplo base de datos no relacionales, servicios de datos en la nube, bases clave-valor, etc.
La idea es introducir una capa de abstracción que permita generalizar el acceso a dato a almacenes de datos tan dispares. Este proyecto fue desarrollado gracias al trabajo conjunto con un conjunto de compañías y desarrolladores.
Spring data esta dividido en diferentes subproyectos dependiendo los almacenes de datos que tenga que interactuar:
| Categoría |
Sub-proyecto
|
| Relational Databases | JPA |
| JDBC Extensions | |
| Big Data | Hadoop |
| Data-Grid | Gemfire |
| Key Value Stores | Redis |
| Riak | |
| Document Stores | MongoDB |
| CouchDB (planned) | |
| Graph Databases | Neo4j |
| Column Stores | HBase (planned) |
| Cassandra (planned) | |
| Blob-Stores | Blob |
| Common Infrastructure | Commons |
| Grails Mapping | |
Suscribirse a:
Entradas (Atom)
