Translate
miércoles, 8 de mayo de 2019
Apache NetBeans fue promovido a Top-Level Apache Project
NetBeans, un entorno de desarrollo integrado (IDE), fue promovido recientemente a un proyecto Top-Level Apache Project, aproximadamente dos años y medio después de que Oracle donó su código fuente a la Fundación de software Apache.
Los equipos de desarrollo que buscan probar las funciones completas de NetBeans pueden descargar directamente NetBeans 11 desde Apache y ver una lista completa de las nuevas funciones en esta versión. Los desarrolladores pueden probar el IDE en cualquier fase de sus proyectos, incluso si actualmente se usan otros IDE.
Dejo link: https://www.globenewswire.com/news-release/2019/04/24/1808620/0/en/The-Apache-Software-Foundation-Announces-Apache-NetBeans-as-a-Top-Level-Project.html
Libros de Java Code Geeks
Download IT Guides!
|
|
Compactaciones en Apache Cassandra
La compactación es
el proceso que libera espacio en le disco mergeando los archivos de
datos que se fueron acumulando. Esto es aproximadamente análogo a la
reconstrucción de una tabla en el mundo relacional. Pero la
principal diferencia en Cassandra es que está pensada como una
operación transparente que se realiza a lo largo de la vida del
servidor.
En la compactación,
los datos combinados se ordenan, se crea un nuevo índice sobre los
datos ordenados, y los datos recién fusionados, ordenados e
indexados se escriben en un único SSTable nuevo (cada SSTable consta
de varios archivos, incluidos: Datos, Índice y Filtros).
Este proceso es
administrado por la clase
org.apache.cassandra.db.compaction.CompactionManager.
Otra función
importante de la compactación es mejorar el rendimiento al reducir
el número de búsquedas requeridas. Hay un número limitado de
SSTables para inspeccionar y encontrar los datos de la columna para
una clave dada. Si una clave se muta frecuentemente, es muy probable
que todas las mutaciones terminen en SSTables vacios. Compactarlos
evita que la base de datos tenga que realizar una búsqueda para
extraer los datos de cada SSTable a fin de ubicar el valor actual de
cada columna solicitada en una lectura.
Cuando se realiza la
compactación, hay un pico temporal en la I/O del disco y el tamaño
de los datos en el disco mientras se leen los SSTables antiguos y se
están escribiendo nuevos SSTables.
Cassandra soporta
diferentes algoritmos de compactaciones y cada estrategía de
compactación esta relacionada con un algoritmo, es decir utiliza el
patron Strategy para implementar diferentes modos de compactar. La
clase padre de las estrategías es AbstractCompactionStrategy. Y se
tienen las siguientes estrategias disponibles:
- SizeTieredCompactionStrategy (STCS) es la estrategia de compactación predeterminada y se recomienda para tablas de escritura intensiva
- LeveledCompactionStrategy (LCS) se recomienda para tablas de lectura intensiva
- DateTieredCompactionStrategy (DTCS), que está destinado a series de tiempo o datos basados en la fecha.
Una característica
interesante de la compactación se relaciona con su intersección con
la reparación incremental. Una característica llamada
anticompactación se añadió en la versión 2.1. Como su nombre lo
indica, la anti-compactación es en cierto modo una operación
opuesta a la compactación regular, ya que el resultado es la
división de un SSTable en dos SSTables, uno que contiene datos
reparados y el otro que contiene datos sin reparar. La compensación
es que se introduce una mayor complejidad en las estrategias de
compactación, que deben manejar los SSTables reparados y no
reparados por separado para que no se fusionen entre sí.
sábado, 4 de mayo de 2019
Filtros Bloom en Apache Cassandra
Los filtros Bloom se utilizan para mejorar el rendimiento de las lecturas. Su nombre es por su inventor, Burton Bloom. Los filtros Bloom son algoritmos muy rápidos y no deterministas para comprobar si un elemento es miembro de un conjunto. No son deterministas porque es posible obtener una lectura de falsos positivos de un filtro Bloom, pero no un falso negativo.
Los filtros Bloom funcionan al mapear los valores de un conjunto de datos en una matriz de bits y condensar un conjunto de datos más grande en una cadena de resumen mediante una función hash. El compendio, por definición, utiliza una cantidad de memoria mucho menor que la de los datos originales. Los filtros se almacenan en la memoria y se utilizan para mejorar el rendimiento al reducir la necesidad de acceso al disco en las búsquedas de claves. El acceso al disco suele ser mucho más lento que el acceso a la memoria. Entonces, en cierto modo, un filtro Bloom es un tipo especial de caché. Cuando se realiza una consulta, el filtro Bloom comprueba primero antes de acceder al disco.
Debido a que los falsos negativos no son posibles, si el filtro indica que el elemento no existe en el conjunto, ciertamente no lo hace; pero si el filtro piensa que el elemento está en el conjunto, se accede al disco para asegurarse.
Los filtros Bloom son implementados por la clase org.apache.cassandra.utils.BloomFilter. Cassandra proporciona la capacidad de aumentar la precisión del filtro Bloom (reduciendo el número de falsos positivos) al aumentar el tamaño del filtro, a costa de más memoria. Esta posibilidad positiva falsa es ajustable por tabla.
Los filtros Bloom se utilizan en otras bases de datos distribuidas y tecnologías de almacenamiento en caché, como Apache Hadoop, Google Bigtable y Squid Proxy Cache.
Los filtros Bloom funcionan al mapear los valores de un conjunto de datos en una matriz de bits y condensar un conjunto de datos más grande en una cadena de resumen mediante una función hash. El compendio, por definición, utiliza una cantidad de memoria mucho menor que la de los datos originales. Los filtros se almacenan en la memoria y se utilizan para mejorar el rendimiento al reducir la necesidad de acceso al disco en las búsquedas de claves. El acceso al disco suele ser mucho más lento que el acceso a la memoria. Entonces, en cierto modo, un filtro Bloom es un tipo especial de caché. Cuando se realiza una consulta, el filtro Bloom comprueba primero antes de acceder al disco.
Debido a que los falsos negativos no son posibles, si el filtro indica que el elemento no existe en el conjunto, ciertamente no lo hace; pero si el filtro piensa que el elemento está en el conjunto, se accede al disco para asegurarse.
Los filtros Bloom son implementados por la clase org.apache.cassandra.utils.BloomFilter. Cassandra proporciona la capacidad de aumentar la precisión del filtro Bloom (reduciendo el número de falsos positivos) al aumentar el tamaño del filtro, a costa de más memoria. Esta posibilidad positiva falsa es ajustable por tabla.
Los filtros Bloom se utilizan en otras bases de datos distribuidas y tecnologías de almacenamiento en caché, como Apache Hadoop, Google Bigtable y Squid Proxy Cache.
miércoles, 1 de mayo de 2019
C# y F# para Apache Spark
Microsoft anunció el lanzamiento de .NET para Apache Spark.
Microsoft anunció la versión preliminar de .NET para Apache Spark. Apache Spark está escrito en Scala, por lo que siempre ha tenido soporte nativo para este lenguaje. También ha tenido durante mucho tiempo enlaces API para Java, así como los populares lenguajes de ciencia de datos Python y R. Los nuevos enlaces de lenguaje para C# y F# están escritos en una nueva capa de interoperabilidad Spark. En las pruebas en el punto de referencia TPC-H, el rendimiento de .NET fue comparable a otros lenguajes, y en algunos casos fue "2 veces más rápido que Python".
Los desarrolladores pueden reutilizar el código y las librerías compatibles con .NET estándar y "pueden acceder a todos los aspectos de Apache Spark, incluidos Spark SQL, DataFrames, Streaming, MLLib". Los desarrolladores de la nube pueden implementar .NET para Apache Spark en Azure de Microsoft usando Azure HDInsight y Azure Databricks, o en Amazon Web Services usando Amazon EMR Spark y AWS Databricks.
La ejecución de aplicaciones .NET en Spark requiere la instalación de los binarios de Microsoft.Spark.Worker, así como un JDK y los binarios estándar de Apache Spark. El desarrollo de una aplicación requiere la instalación del paquete nuget Microsoft.Spark. Los desarrolladores de Microsoft han enviado Propuestas de mejora de proyectos Spark (SPIP) para incluir la extensión de lenguaje C# y una capa de interoperabilidad genérica en Spark. Sin embargo, Sean Owen, un comentarista de Apache Spark, comentó que sería "altamente improbable" que el trabajo se fusionara con Spark.
La hoja de ruta de .NET para Apache Spark enumera varias mejoras al proyecto que ya está en marcha, incluida la compatibilidad con Apache Spark 3.0, la compatibilidad con la vectorización de .NET Core 3.0 y la compatibilidad con VS Code. .NET para el código fuente de Apache Spark está disponible en Github.
Libros gratis de Java Geeks.
|
Tombstones en Cassandra
En el mundo relacional, podría estar acostumbrado a la idea de una "eliminación suave o eliminación logica". En lugar de ejecutar realmente una instrucción de eliminación de SQL, la aplicación emitirá una instrucción de actualización que cambia un valor en una columna llamada "eliminado", a veces se hace esto por auditoría o mantener registros historico.
Este es un concepto similar en Cassandra llamado Tombstones (que no se como traducirlo). Así es como funcionan todas las eliminaciones. Cuando ejecuta una operación de eliminación, los datos no se eliminan inmediatamente. En su lugar, se trata como una operación de actualización que coloca una marca de eliminado.Tombstones es un marcador de eliminación que se requiere para suprimir datos antiguos en SSTables hasta que se pueda ejecutar la compactación.
Hay una configuración relacionada llamada Garbage Collection Grace Seconds. Esta es la cantidad de tiempo que el servidor esperará para recolectar un registro marcado como eliminado. De forma predeterminada, se establece en 864,000 segundos, el equivalente a 10 días. Cassandra hace un seguimiento del tiempo de marcado, y una vez que esta es más antigua que GCGraceSeconds, será recogida por el recolector de basura. El propósito de este retraso es dar a un nodo que no esté disponible el tiempo de recuperación; Si un nodo está inactivo por más tiempo que este valor, entonces se trata como fallido y reemplazado.
domingo, 28 de abril de 2019
Transacciones Ligeras y Paxos en Cassandra
Cassandra proporciona una consistencia ajustable, que incluye la capacidad de lograr una consistencia fuerte al especificar niveles de consistencia suficientemente altos.
Sin embargo, una consistencia sólida no es suficiente para evitar las condiciones de competencia en los casos en que los clientes necesitan leer y luego escribir datos.
Vamos explicar esto con un ejemplo, supongamos que tenemos una tabla Cliente. Imagine que estamos creando un cliente y que desea administrar los registros de usuarios como parte de una aplicación de administración de cuentas. Al crear una nueva cuenta de usuario, nos gustaría
asegúrarnos de que el registro de usuario no exista, para no sobrescribir involuntariamente los datos de usuario existentes. Así que hacemos una lectura para ver si el registro existe primero, y luego solo realizamos la creación si el registro no existe. El comportamiento que buscamos se denomina consistencia linealizable, lo que significa que nos gustaría garantizar que ningún otro cliente pueda interponerse entre nuestras consultas de lectura y escritura con su propia modificación. Desde la versión 2.0, Cassandra admite un mecanismo de transacción ligero (o "LWT") que proporciona una consistencia linealizable.
La implementación de LWT de Cassandra se basa en Paxos. Paxos es un algoritmo de consenso que permite que los nodos pares distribuidos se pongan de acuerdo sobre una propuesta, sin necesidad de un maestro para coordinar una transacción. Paxos y otros algoritmos de consenso surgieron como alternativas a los enfoques tradicionales basados en el compromiso de dos fases para las transacciones distribuidas.
El algoritmo básico de Paxos consta de dos etapas: preparar / prometer y proponer / aceptar. Para modificar los datos, un nodo coordinador puede proponer un nuevo valor a los nodos de réplica, asumiendo el rol de líder. Otros nodos pueden actuar como líderes simultáneamente para otras modificaciones. Cada nodo de réplica verifica la propuesta, y si la propuesta es la última que ha visto, promete no aceptar las propuestas asociadas con las propuestas anteriores. Cada nodo de réplica también devuelve la última propuesta que recibió que aún está en progreso. Si la propuesta es aprobada por la mayoría de las réplicas, el líder confirma la propuesta, pero con la advertencia de que primero debe cometer cualquier propuesta en curso que haya precedido a su propia propuesta.
La implementación de Cassandra amplía el algoritmo básico de Paxos para admitir la semántica de lectura antes de escritura deseada (también conocida como "comprobar y establecer"), y permitir que el estado se reinicie entre transacciones. Lo hace insertando dos fases adicionales en el algoritmo, para que funcione de la siguiente manera:
- Preparar / prometer
- Leer / Resultados
- Proponer / Aceptar
- Cometer / Ack
Por lo tanto, una transacción exitosa requiere cuatro viajes de ida y vuelta entre el nodo coordinador y las réplicas. Esto es más costoso que una escritura regular, por lo que debe pensar detenidamente sobre su caso de uso antes de usar LWT.
Las transacciones ligeras de Cassandra están limitadas a una sola partición. Internamente, Cassandra almacena un estado Paxos para cada partición. Esto asegura que las transacciones en diferentes particiones no puedan interferir entre sí.
Puede encontrar la implementación de Cassandra del algoritmo Paxos en el paquete org.apache.cassandra.service.paxos.
viernes, 26 de abril de 2019
Llego Ubuntu 19.04 Disco Dingo
Nueva versión de Ubuntu y que trae de nuevo viejo ...
Yaru, el tema por defecto introducido en Ubuntu 18.10 no soportaba iconos para varias aplicaciones de terceros. Los iconos regulares de estas aplicaciones no armonizaban demasiado bien con los de las instaladas. Ese problema estético fue corregido. También se modificaron los iconos del centro de software, la papelera y el panel de configuración. El fondo de escritorio, como sucede a cada nueva versión, corresponde a la mascota.
Viene con 3.22 de GNOME pero Ubuntu no adopta todas las características completas de la versión. Podemos seguir teniendo iconos en el escritorio y el panel lateral está presente en forma permanente. Por el contrario, no se incluyeron las (muy necesarias) mejoras en el centro de software ni los controles para activar fractional scalling en HiDPl.
La gran novedad de esta versión, es el soporte para las tarjetas gráficas AMD de gama alta, mejoras en el rendimiento de la CPU y soporte para más hardware todo gracias a Núcleo Linux 5.0
Dejo link: http://releases.ubuntu.com/19.04/
miércoles, 24 de abril de 2019
Libros a Java geeks
|
viernes, 19 de abril de 2019
Transferencia indirecta en Cassandra
Veamos el siguiente escenario: una solicitud de escritura se envía a Cassandra, pero un nodo de réplica al que pertenece la escritura, no está disponible debido un problema de la red, falla de hardware o alguna otra razón. Con el fin de garantizar la disponibilidad general del anillo en tal situación, Cassandra implementa una función llamada transferencia indirecta. Se puede pensar en una sugerencia como una pequeña nota Post-it que contiene la información de la solicitud de escritura. Si el nodo de réplica al que pertenece la escritura ha fallado, el coordinador creará una sugerencia, que es un pequeño recordatorio que dice: "Tengo la información de escritura destinada al nodo 4. Voy a recordar esta escritura hasta que el nodo 4 vuelva a estar en línea; cuando lo haga, le enviaré la solicitud de escritura". Es decir, una vez que detecte a través de gossip que el nodo 4 está nuevamente en línea, el nodo 6 entregará al nodo 4 la orden de escritura. Cassandra tiene una sugerencia diferente para cada partición que se va a escribir.
Esto permite que Cassandra esté siempre disponible para escrituras, y generalmente permite que un clúster sostenga la misma carga de escritura incluso cuando algunos de los nodos están inactivos. También reduce el tiempo en que un nodo fallido será inconsistente después de que vuelva a estar en línea.
En general, las sugerencias no cuentan como escrituras para propósitos de nivel de consistencia. La excepción es el nivel de consistencia ANY, que se agregó en 0.6. Este nivel de consistencia significa que un traspaso indirecto solo será suficiente para el éxito de una operación de escritura. Es decir, incluso si solo se pudo grabar una pista, la escritura todavía cuenta como exitosa. Tenga en cuenta que la escritura se considera duradera, pero es posible que los datos no se puedan leer hasta que la sugerencia se envíe a la réplica de destino.
Existe un problema práctico con las transferencia indirecta (y, en este caso, los enfoques de entrega garantizados): si un nodo está fuera de línea durante algún tiempo, los consejos pueden acumularse considerablemente en otros nodos. Luego, cuando los otros nodos notan que el nodo fallado ha vuelto a estar en línea, tienden a inundar ese nodo con solicitudes, justo en el momento en que es más vulnerable (cuando está luchando para volver a trabajar después de una falla). Para resolver este problema, Cassandra limita el almacenamiento de sugerencias a una ventana de tiempo configurable. También es posible deshabilitar el traspaso insinuado por completo.
Como su nombre lo sugiere, org.apache.cassandra.db.HintedHandOffManager es la clase
que gestiona las transferencias indirectas internamente.
Aunque la Transferencia indirecta ayuda a aumentar la disponibilidad de Cassandra, no reemplaza completamente la necesidad de reparación manual para garantizar la consistencia.
jueves, 18 de abril de 2019
Libros de java code geeks
|
domingo, 14 de abril de 2019
Caching en Apache Cassandra
Como vemos en la imagen anterior, Cassandra proporciona tres formas de almacenamiento en caché:
- La key cache almacena un mapa de claves de partición, lo que facilita un acceso de lectura más rápido a los archivos SSTables almacenados en el disco. La key cache se almacena en el heap de JVM.
- La row cache almacena filas enteras y puede acelerar enormemente el acceso de lectura para las filas a las que se accede con frecuencia, pero el costo de memoria es mayor. La row cache se almacena en la memoria fuera del heap.
- La counter cache se agregó en la versión 2.1 para mejorar el rendimiento del contador al reducir la contención de bloqueo para los contadores de acceso más frecuente.
De forma predeterminada, key cache y counter cache estan habilitados, mientras que la row cache está desactivada, ya que requiere más memoria. Cassandra guarda sus cachés en el disco periódicamente para ser más rápida en un reinicio de los nodos.
sábado, 13 de abril de 2019
Resultado de la encuesta 2019 de StackOverflow
StackOverflow desde hace algunos años hace unas encuestas que son muy buenas y nos permiten ver como esta el mercado del software.
En ocasión, no vi algo muy novedoso solo me llamo la atención es el lenguaje más amado :
Dejo link: https://insights.stackoverflow.com/survey/2019
En ocasión, no vi algo muy novedoso solo me llamo la atención es el lenguaje más amado :
Claramente le voy a tener que dar una oportunidad a Rush.
Dejo link: https://insights.stackoverflow.com/survey/2019
jueves, 11 de abril de 2019
BigData Europe
Necesitas una imagen de docker con un proyecto para procesar datos, bueno Big Data Europe es para vos...
Dejo link: https://github.com/big-data-europe
Suscribirse a:
Entradas (Atom)