27 febrero 2021

¿Hay vida más allá de Oracle database? Suscripción de aprendizaje del 25 aniversario de Java


 


Este es el contenido de la introducción que hace Oracle a la oferta de aprendizaje en Java, espero que os guste y que la aprovechéis.

Suscripción de aprendizaje del 25 aniversario de Java

Bienvenido a la suscripción de aprendizaje del 25 aniversario de Java de Oracle University. Oracle está celebrando el 25 aniversario del lenguaje de programación Java brindándole la oportunidad de aprender a programar usando Java SE 11. Puede estudiar los temas más importantes y fundamentales para la certificación Java y aprender de instructores expertos experimentados en su tiempo libre. Y cuando esté listo, puede registrarse para realizar el examen de certificación de Java Standard Edition 11.


Esta oferta de programación Java del 25 aniversario está destinada a aquellos que tienen alguna experiencia en programación en otro lenguaje de programación, como C #, C ++, JavaScript, PL / SQL, C, Node.js o incluso COBOL o Fortran. También es para aquellos que tienen algunos conocimientos básicos de Java y quieren ampliar o mejorar sus conocimientos. Para alguien que tomó un curso de Java hace un tiempo y realmente no lo ha usado, esto le servirá como un excelente repaso.


Y, por supuesto, si se está preparando para el examen de certificación Java SE 11, esta oferta cubre todos los temas cubiertos en el examen. Pero si es nuevo en programación y recién está comenzando, le sugerimos que tome primero el curso gratuito Java Explorer, que enseña habilidades básicas de programación, como estructura de programa, variables, tipos de datos, expresiones, toma de decisiones, bucles, clases, objetos, y mucho más. Esta es una introducción divertida y enfocada a los fundamentos de la programación con Java.

Luego regrese y aproveche la oferta del 25 aniversario para obtener el contenido y la experiencia completos de Java SE. Cuando toma esta oferta, obtiene acceso en línea a nuestra guía para estudiantes con diapositivas y notas que acompañan a las presentaciones del instructor grabadas profesionalmente. Puede detenerse, retroceder y revisar fácilmente lo que ha aprendido.

También hay tutoriales grabados de las soluciones de las prácticas que vienen con la suscripción completa de aprendizaje de Java. Puede observar y aprender mientras el instructor explica qué hace el código y por qué.

Para la certificación Java SE 11, hay un conjunto de preguntas de examen simuladas, para que pueda tener una idea del estilo y la dificultad de las preguntas reales del examen. Y cuando acceda a la página web de suscripción de aprendizaje de Java 25th, puede avanzar al mosaico de certificación para registrarse para realizar el examen. Los ejemplos y prácticas que se ven en el curso se basan en Java JDK 11 y NetBeans 11, ambas descargas gratuitas del sitio que se muestra en la pantalla.


Si eres programador y desea aprender Java más profundamente, puede intentar configurar un entorno de trabajo para probar las prácticas y los ejemplos en su computadora local. Si es un novato, como dije antes, considera comenzar con el Explorador de Java, nuestra oferta de programación básica de Java gratuita, que incluye las instrucciones para obtener y configurar una cuenta gratuita de Oracle Cloud para realizar sus prácticas. Luego, puede usar eso para probar estos ejemplos y prácticas también. Pero esto es completamente opcional y no es compatible con Oracle. La guía de práctica y laboratorio completa y el entorno de laboratorio configurado se proporcionan con la suscripción completa de aprendizaje de Java.


Hablando de eso, ¿qué sigue? ¿Qué incluye la suscripción completa de aprendizaje de Java? Bueno, creemos que una vez que haya disfrutado de la oferta del 25 aniversario de Java, querrá expandir y profundizar su aprendizaje y obtener acceso a más cursos y aprendizaje digital. Con la suscripción completa de aprendizaje de Java, obtiene acceso a un entorno de laboratorio alojado y guías de laboratorio detalladas para realizar las prácticas. Obtiene acceso a todo el contenido grabado digitalmente en la suscripción de aprendizaje, tanto el contenido actual como el contenido nuevo que se agrega o actualiza.

Puede acceder a la formación sobre las versiones actuales y anteriores de Java. Por ejemplo, algunos clientes todavía usan Java SE Standard Edition 8 y necesitan capacitación para esa versión. Tendrá acceso a todos los materiales de Java Standard Edition 8 y Java Enterprise Edition, así como a las certificaciones para SE 8 y EE 7, y los videos de preparación de la certificación grabados para ayudarlo a prepararse para su certificación. Y puede registrarse para sesiones en vivo. Estas son sesiones de capacitación semanales en vivo alojadas por Zoom, impartidas por instructores expertos en una gran variedad de temas. Esta es una excelente manera de hacer preguntas e interactuar con un instructor en vivo.



Este es el roadmap a seguir:














23 febrero 2021

Conceptos básicos de Data Guard de Oracle 12c

 

Data Guard es la verdadera tecnología de protección contra desastres de Oracle 12c. En él, tiene un mínimo de dos bases de datos, principal y en espera. Data Guard tiene opciones para múltiples sitios en espera, así como una configuración activo-activo.

Por activo-activo, significa que ambos / todos los sitios están en funcionamiento, en funcionamiento y accesibles. Esto se opone a los sitios que tienen una ubicación activa y las otras deben iniciarse cuando se necesitan. Este es un ejemplo del diseño arquitectónico general.


Arquitectura de Data Guard y Oracle 12c

Comenzar una descripción con la base de datos primaria es fácil porque se diferencia muy poco de cualquier otra base de datos que pueda tener. La única diferencia es lo que hace con sus registros de rehacer archivados.

La base de datos principal escribe un conjunto de registros de rehacer archivos en un área de recuperación de Flash o en un disco local. Sin embargo, puede configurar uno o más destinos en un entorno de Data Guard.

El parámetro LOG_ARCHIVE_DEST_n puede tener este aspecto para la configuración anterior:

LOG_ARCHIVE_DEST_10 = 'UBICACIÓN = USE_DB_RECOVERY_FILE_DEST'

LOG_ARCHIVE_DEST_1 = 'SERVICIO = PHYSDBY1 ARCH'

LOG_ARCHIVE_DEST_2 = 'SERVICIO = LOGSDBY1 LGWR'

 

·         LOG_ARCHIVE_DEST_10 está configurado para enviar registros de rehacer archivos al Área de recuperación de Flash local. Se requiere un destino local para todas las bases de datos en modo de registro de archivo.

·         LOG_ARCHIVE_DEST_1 está configurado para enviar los registros de archivo a través del proceso de archivado a un sitio remoto PHYSDBY1. El nombre del servicio para este sitio remoto tiene una entrada en el archivo tnsnames.ora en el servidor primario.

·         LOG_ARCHIVE_DEST_2 está configurado para enviar los registros de archivo a través del proceso LGWR a un sitio remoto llamado LOGSDBY1. El nombre del servicio para este sitio remoto también tiene una entrada en el archivo tnsnames.ora en el servidor primario.

 

¿Por qué la diferencia entre los métodos de envío ARCn y LGWR? Eso tiene algo que ver con los modos de protección. Un entorno de Data Guard tiene tres modos de protección.

Disponibilidad máxima

El modo de protección de máxima disponibilidad se compromete entre el rendimiento y la disponibilidad de datos. Funciona mediante el uso de LGWR para escribir simultáneamente para rehacer registros en los sitios principal y en espera. La degradación del rendimiento viene en forma de procesos que tienen que esperar a que las entradas del registro de rehacer se escriban en varias ubicaciones.

Las sesiones que emiten confirmaciones deben esperar hasta que se haya registrado toda la información necesaria en al menos un registro de rehacer de la base de datos en espera. Si una sesión se bloquea debido a su incapacidad para escribir información de rehacer, el resto de la base de datos sigue avanzando.

Protección máxima

El modo de protección máxima es similar a la disponibilidad máxima, excepto que si una sesión no puede verificar que rehacer está escrito en el sitio remoto, la base de datos principal se apaga.

Consejo:  Configure al menos dos sitios en espera para el modo de máxima protección. De esa manera, un sitio en espera que deje de estar disponible no interrumpirá el servicio para toda la aplicación.

 

Este modo verifica que no se producirá ninguna pérdida de datos en caso de desastre a costa del rendimiento.

Rendimiento máximo

El modo de protección de máximo rendimiento separa el proceso de trasvase de registros de la base de datos principal pasándolo al proceso de registro de archivo (ARCn). Al hacer esto, todas las operaciones en el sitio principal pueden continuar sin esperar a que se escriban las entradas de rehacer para rehacer los registros o rehacer el envío.

 

Esto se opone a los modos de trasvase de registros que utilizan el escritor de registros para transferir transacciones. El uso del escritor de registros puede ralentizar el procesamiento de la transacción porque puede verse afectado por la disponibilidad o el rendimiento de la red.

El rendimiento máximo proporciona el nivel más alto de rendimiento en el sitio principal a expensas de la divergencia de datos. La divergencia de datos se produce cuando los datos de los dos sitios comienzan a de sincronizarse. Los datos de rehacer del archivo no se envían hasta que se llena todo el registro de rehacer del archivo. En el peor de los casos, la pérdida de un sitio completo podría resultar en la pérdida de todos los datos de un registro de rehacer de archivo (archive redo log).

 

Realización de operaciones de conmutación y conmutación por error

Puede cambiar el procesamiento a su sitio en espera de dos maneras:

·         La conmutación (switchover) es un cambio planificado que puede ocurrir si desea realizar mantenimiento en el sitio principal que requiere que no esté disponible. Esta operación puede requerir unos minutos de inactividad en la aplicación, pero si tiene que realizar un mantenimiento que dure una hora o más, el tiempo de inactividad podría valer la pena. Esta operación se denomina cambio elegante porque convierte el sitio principal en su sitio en espera y su sitio en espera en el principal. Además, puede volver fácilmente al sitio principal original sin tener que volver a crearlo desde cero.

·         La conmutación por error (failover) ocurre cuando el sitio principal se ha visto comprometido de alguna manera. Quizás fue una pérdida total del sitio, o quizás descubrió daños físicos en un archivo de datos. No siempre, pero por lo general después de una conmutación por error, debe volver a crear completamente el sitio principal o recuperarlo de una copia de seguridad y reinstalarlo. Por lo general, realiza una conmutación por error solo cuando ha determinado que reparar el sitio principal llevará el tiempo suficiente para que prefiera no tener una interrupción de la aplicación durante todo el tiempo.

Para realizar un cambio, siga estos pasos:

1.        En el primario actual, inicie sesión en SQL * Plus y escriba lo siguiente:

<alter database commit to switchover to physical standby;>

 Deberías ver esto:

< Base de datos alterada >

.

2.       Apague la base de datos primaria:

 <shutdown immediate>

Deberías ver esto::

Database closed.
Database dismounted.
ORACLE instance shut down.

3.       Inicie la base de datos primaria en modo nomount:

  <startup nomount>

Debería ver algo como esto:

ORACLE instance started.

Total System Global Area 789172224 bytes

Fixed Size         2148552 bytes

Variable Size       578815800 bytes

Database Buffers     201326592 bytes

Redo Buffers        6881280 bytes

4.       Monte la base de datos en espera:

<alter database mount standby database;>

Deberías ver esto:

Database altered.

5.       Iniciar la recuperación:

<recover managed standby database disconnect;>

Ves esto:

Media recovery complete.

6.       Inicie sesión en SQL * Plus en el modo de espera actual y escriba lo siguiente:

<alter database commit to switchover to physical primary;>

Deberías ver esto:

Database altered.

7.       Apague la base de datos en espera:

 <shutdown immediate>

Deberías ver esto:

Database closed.

Database dismounted.

ORACLE instance shut down.

8. Asegúrese de que todos los parámetros de inicialización apropiados estén configurados para que esta base de datos se comporte correctamente como primaria.

9.       Empiece normalmente:

<startup>

Debería ver algo como esto:

ORACLE instance started.

Total System Global Area 789172224 bytes

Fixed Size         2148552 bytes

Variable Size       578815800 bytes

Database Buffers     201326592 bytes

Redo Buffers        6881280 bytes

Database mounted.

Database opened.


Asegúrese de que los usuarios y las aplicaciones puedan conectarse y utilizar la nueva instancia principal.



17 febrero 2021

¿Hay vida más allá de Oracle? Diez ejemplos de reglas de cumplimiento de AML (Anti-money laundry)

 


Esos son los primeros pasos para mitigar riesgos de "Lavado de Dinero" en una institución financiera, esto es una introducción a una práctica habitual de despliegue de una herramienta de detección de fraude y lavado de dinero, tipo NetReveal o Nice Actimize.

Los esquemas de "Lavado de Dinero" (LD) son difíciles de detectar. El objetivo de los equipos de cumplimiento en "fintechs", bancos, plataformas y procesadores de pagos es encontrar estos patrones anormales en el mar de datos de transacciones que se generan todos los días. Esto crea un acto de equilibrio crítico en el que las reglas deben detectar todas las malas actividades sin ser tan amplias que generen falsos positivos abrumadores.

Al establecer un programa de cumplimiento, uno de los pasos más importantes es establecer el conjunto inicial de reglas. Con el tiempo, este conjunto de reglas crecerá a medida que se detecten nuevos esquemas y se creen las reglas correspondientes. Pero ese primer conjunto de reglas es fundamental para lanzar rápidamente un programa de cumplimiento y preparar a su equipo para el éxito futuro.

La creación de reglas puede ser un verdadero desafío, ya que cada situación empresarial tiene diferentes factores de riesgo y umbrales adecuados. Sin embargo, existen algunas estructuras de reglas básicas que todo equipo de cumplimiento debería considerar implementar para cubrir los esquemas más comunes.


Ejemplo un escenario "Comercial" de detección que identifique si se han realizado transacciones de crédito en efectivo en más de 5 sucursales durante la semana actual y si el valor acumulado de estas transacciones es superior a 100000


A continuación, se muestran 10 reglas universales contra el lavado de dinero (AML) que los departamentos de cumplimiento deben considerar ejecutar en todas sus transacciones. Estas reglas están pensadas como un punto de entrada para cualquiera que busque establecer un programa de cumplimiento que incluya fintechs, plataformas de pago, bancos desafiantes y mercados.

1. Estructuración en el tiempo

Esta regla detecta una proporción excesiva de transacciones apenas por debajo de un umbral interno o de informes. En el siguiente ejemplo, el umbral es de $ 10,000 y estamos buscando un patrón en el que las transacciones para la parte caigan en gran medida entre $ 9,000 y $ 10,000 durante un período de 60 días.

Sample Expression:
(PARTY_PAY_OUT_NUMBER_OF_TRANSACTION_AMOUNTS_BETWEEN_9000_AND_10000_LAST_60_DAYS + PARTY_PAY_IN_NUMBER_OF_TRANSACTION_AMOUNTS_BETWEEN_9000_AND_10000_LAST_60_DAYS) / (PARTY_PAY_OUT_NUMBER_OF_TRANSACTIONS_LAST_60_DAYS + PARTY_PAY_IN_NUMBER_OF_TRANSACTIONS_LAST_60_DAYS) > .1


2. Cambio de perfil antes de una transacción importante

Esta regla identifica una situación en la que un cliente realiza un cambio de perfil en la información de identificación personal (PII) poco antes de realizar una transacción grande (en este ejemplo, una transacción superior a $ 750). Esto puede indicar una toma de control de la cuenta o una posible actividad de "estratificación" para ocultar el camino de los fondos.

Sample Expression:
PARTY_DAYS_SINCE_LAST_MODIFIED_PII  < 2 && AMOUNT_VALUE > 750


3. Volumen de transacciones anormalmente alto

Esta regla identifica a las partes con volúmenes de transacciones de pago anormalmente altos. Una regla como esta es apropiada para una red de pago de igual a igual con la capacidad de retirar fondos a una cuenta externa. En este ejemplo simple, el umbral está codificado en 300 transacciones durante 30 días; ambas variables se establecerían para su modelo de negocio.

Sample Expression:
PARTY_PAY_OUT_NUMBER_OF_TRANSACTIONS_LAST_30_DAYS > 300


4. Aumento anómalo del volumen total de transacciones

Esta regla identifica un aumento significativo en el valor de las transacciones salientes de una parte en comparación con su promedio reciente. Busca partes con actividad reciente en las que el valor de transacción de la parte sea sustancialmente más alto que el promedio móvil de 7 días. La regla filtra las partes que han existido durante un corto período de tiempo, las partes con un saldo bajo y un valor de transacción saliente bajo durante la ventana de tiempo relevante.

Sample Expression:
(PARTY_PAY_OUT_NUMBER_OF_ALL_TRANSACTIONS_LAST_7_DAYS) / (PARTY_PAY_OUT_NUMBER_OF_ALL_TRANSACTIONS_LAST_14_DAYS – PARTY_PAY_OUT_NUMBER_OF_ALL_TRANSACTIONS_LAST_7_DAYS) > 2 && PARTY_INSIGHT_BALANCE_VALUE > 5000 && ((new Date() – PARTY_SOURCE_CREATED)/(60*60*24*1000)) > 60 && PARTY_NUMBER_OF_ALL_TRANSACTIONS_LAST_14_DAYS > 10

 5. Pago propio por dirección IP

Esta regla identifica transferencias entre partes con la misma dirección IP.

(Esta regla no era de la partida cuando empecé con esto por 2012) 

Sample Expression:
PARTY_GEO_CODE_IP_ADDRESS == REFERENCE_PARTY_GEO_CODE_IP_ADDRESS

 6. Actividad excesiva de flujo continuo

Esta regla identifica las partes en las que el valor total de los créditos es similar al valor total de los débitos en un período de tiempo corto. En este ejemplo, la regla está codificada para cubrir 7 días. Una regla como esta es apropiada para un servicio que generalmente ofrece la recolección de fondos donde no esperaría ver una actividad de gasto comparable (por ejemplo, un mercado de bienes y servicios).
 

Sample Expression:
PARTY_PAY_IN_VALUE_OF_TOTAL_AMOUNT_TRANSACTIONS_LAST_7_DAYS > .9 * PARTY_PAY_OUT_VALUE_OF_TOTAL_AMOUNT_TRANSACTIONS_LAST_7_DAYS && PARTY_PAY_IN_VALUE_OF_TOTAL_AMOUNT_TRANSACTIONS_LAST_7_DAYS < 1.1 * PARTY_PAY_OUT_VALUE_OF_TOTAL_AMOUNT_TRANSACTIONS_LAST_7_DAYS && PARTY_PAY_IN_VALUE_OF_TOTAL_AMOUNT_TRANSACTIONS_LAST_7_DAYS > 30000

 7. Comportamiento de gasto sospechoso de los usuarios

Esta regla identifica transacciones que se desvían mucho del comportamiento de gasto estándar de la parte. Esto puede indicar una toma de control de la cuenta o una transacción influenciada externamente. Incluye un límite inferior de $ 500, que es posible que desee modificar para evitar la creación de falsos positivos excesivos.

Sample Expression:
((TOTAL_PRICE_VALUE – BUYER_AVG_VALUE_OF_TOTAL_PRICE_USD_TRANSACTIONS_LAST_60_DAYS) / BUYER_STDDEV_VALUE_OF_TOTAL_PRICE_USD_TRANSACTIONS_LAST_60_DAYS) > 1.5 && TOTAL_PRICE_VALUE > 500

 8. Baja diversidad de compradores

Esta regla es la más adecuada para una plataforma en la que generalmente ve a muchos compradores (remitentes) interactuando con un solo vendedor (destinatario). Identifica a los comerciantes que solo reciben pagos de una pequeña cantidad de compradores (en este ejemplo, menos de 10). Esta regla solo se activa para las cuentas más antiguas que el umbral establecido para validar la diversidad baja a lo largo del tiempo y permitir que los comerciantes aumenten su interacción.

Sample Expression:
SELLER_ACCOUNT_AGE_DAYS > 90 && SELLER_NUMBER_OF_UNIQUE_BUYERS <= 10

 9. Mensaje de vendedor a comprador bajo

Esta regla, como la número 8 anterior, se adapta bien a una plataforma que permite una relación comprador / vendedor. Es más útil para plataformas que rastrean la frecuencia de comunicación entre compradores y vendedores en el servicio. Identifica a los comerciantes con altos ingresos pero muy pocos mensajes enviados, lo que podría indicar colusión o lavado de dinero en lugar de una actividad comercial convencional. Esta regla se activa en función de un umbral de porcentaje ajustable de mensajes enviados por USD ganado.

Sample Expression:
(SELLER_NUMBER_OF_MESSAGES_SENT / SELLER_TOTAL_EARNINGS_VALUE) < .013 && SELLER_NUMBER_OF_MESSAGES_SENT > 10

10. Alto recuento de transacciones de nuevos usuarios

Esta regla, como la n. ° 8 y la n. ° 9 anteriores, se adapta bien a una plataforma que permite una relación comprador / vendedor. Identifica a los comerciantes con un alto porcentaje de su actividad proveniente de nuevas cuentas, una posible señal de alerta por lavado de dinero o fraude convencional.

Sample Expression:
(SERVICE_NUMBER_OF_BUYERS_USER_CREATED_LAST_30_DAYS / SERVICE_NUMBER_OF_BUYERS) > .5

 ¿Quieres implementar rápidamente estas reglas y lanzar tu programa de cumplimiento?

Hace pocos años como consultor técnico de una firma internacional ayudaba a fintechs, bancos, corredores de bolsa, entidades que usan blockchain y otros grupos financieros regulados que necesitan cumplir con los requisitos regulatorios contra el lavado de dinero (AML), conozca a su cliente (KYC) y reporte de actividades sospechosas (SAR). .




15 febrero 2021

¿Hay vida más allá de Oracle?, Hoy, Voldemort a.k.a Amazon Dynamo

 

Voldemort es un sistema de almacenamiento de valor clave distribuido

  • Los datos se replican automáticamente en varios servidores.
  • Los datos se particionan automáticamente para que cada servidor contenga solo un subconjunto de los datos totales
  • Proporciona una consistencia ajustable (quórum estricto o consistencia eventual)
  • La falla del servidor se maneja de manera transparente
  • Motores de almacenamiento conectables: BDB-JE, MySQL, solo lectura
  • Serialización conectable - Búferes de protocolo, Thrift, Avro y serialización de Java
  • Los elementos de datos se versionan para maximizar la integridad de los datos en escenarios de falla sin comprometer la disponibilidad del sistema
  • Cada nodo es independiente de otros nodos sin un punto central de falla o coordinación.
  • Buen rendimiento de un solo nodo: puede esperar de 10 a 20.000 operaciones por segundo, según las máquinas, la red, el sistema de disco y el factor de replicación de datos
  • Soporte para estrategias de colocación de datos conectables para respaldar cosas como la distribución entre centros de datos que están geográficamente alejados.
Es utilizado en LinkedIn por numerosos servicios críticos que impulsan una gran parte del sitio.

Comparación con bases de datos relacionales

Voldemort no es una base de datos relacional, no intenta satisfacer relaciones arbitrarias mientras satisface las propiedades ACID. Tampoco es una base de datos de objetos que intenta mapear de forma transparente gráficos de referencia de objetos. Tampoco introduce una nueva abstracción como la orientación al documento. Es básicamente una tabla hash grande, distribuida, persistente y tolerante a fallas. Para aplicaciones que pueden utilizar un mapeador O / R como registro activo o hibernación, esto proporcionará escalabilidad horizontal y una disponibilidad mucho mayor, pero con una gran pérdida de conveniencia. Para aplicaciones grandes bajo presión de escalabilidad del tipo de Internet, un sistema probablemente puede consistir en una serie de servicios o API funcionalmente particionados, que pueden administrar recursos de almacenamiento en múltiples centros de datos utilizando sistemas de almacenamiento que a su vez pueden estar divididos horizontalmente. Para las aplicaciones en este espacio, las uniones arbitrarias en la base de datos ya son imposibles ya que todos los datos no están disponibles en una sola base de datos. Un patrón típico es introducir una capa de almacenamiento en caché que de todos modos requerirá semántica de tabla hash. Para estas aplicaciones, Voldemort ofrece una serie de ventajas:
  • Voldemort combina el almacenamiento en caché de la memoria con el sistema de almacenamiento para que no se requiera un nivel de almacenamiento en caché separado (en cambio, el sistema de almacenamiento en sí es simplemente rápido)
  • A diferencia de la replicación de MySQL, tanto las lecturas como las escrituras escalan horizontalmente
  • El reparto de datos es transparente y permite la expansión del clúster sin reequilibrar todos los datos.
  • La replicación y ubicación de datos se decide mediante una API simple para poder adaptarse a una amplia gama de estrategias específicas de la aplicación
  • La capa de almacenamiento es completamente simulada, por lo que el desarrollo y las pruebas unitarias se pueden realizar en un sistema de almacenamiento en memoria desechable sin necesidad de un clúster real (o incluso un sistema de almacenamiento real) para realizar pruebas simples.
Este software

Configuración

Hay tres archivos de configuración que controlan el funcionamiento del servidor:

  • cluster.xml: contiene la información sobre todos los nodos (es decir, servidores) en el clúster, en qué nombre de host se encuentran, los puertos que usan, etc. Es exactamente lo mismo para todos los nodos de voldemort. No contiene parámetros de ajuste ni directorios de datos para esos nodos, ya que esa información no es pública para el clúster, sino que es específica de esa configuración de nodos en particular.
  • stores.xml: contiene la información sobre todas las tiendas (es decir, tablas) en el clúster. Esto incluye información sobre el número necesario de lecturas correctas para mantener la coherencia, el número necesario de escrituras, así como cómo las claves y los valores se serializan en bytes. Es igual en todos los nodos del clúster.
  • server.properties: contiene los parámetros de ajuste que controlan un nodo en particular. Esto incluye la identificación del nodo local para que sepa qué entrada en cluster.xml corresponde a sí mismo, también el tamaño de la agrupación de subprocesos, así como cualquier configuración necesaria para el motor de persistencia local como BDB o mysql. Este archivo es diferente en cada nodo. Finalmente, hay una variable de entorno, VOLDEMORT_HOME, que controla el directorio en el que residen los datos y la configuración. Puede ver un ejemplo de cómo se presenta la configuración en el subdirectorio config / del proyecto. Esto incluye configuraciones de muestra que puede modificar con sus propios detalles.

Configuración de clúster

A continuación, se muestra un cluster.xml de ejemplo para un clúster de 2 nodos con 8 particiones de datos. También tenemos campos de 'zona' opcionales que le permiten mapear nodos a ciertos clústeres lógicos (centro de datos, rack, etc.) llamados zonas:

<cluster>

    <!-- The name is just to help users identify this cluster from the gui -->

    <name>mycluster</name>

    <zone>

      <zone-id>0</zone-id>

      <proximity-list>1</proximity-list>

    <zone>

    <zone>

      <zone-id>1</zone-id>

      <proximity-list>0</proximity-list>

    <zone>

    <server>

  <! - La identificación del nodo es una identificación secuencial única que comienza con 0 que identifica a cada servidor en el clúster ->

      <id>0</id>

      <host>vldmt1.prod.linkedin.com</host>

      <http-port>8081</http-port>

      <socket-port>6666</socket-port>

      <admin-port>6667</admin-port>

      <! - Una lista de particiones de datos asignadas a este servidor ->

      <partitions>0,1,2,3</partitions>

      <zone-id>0</zone-id>

    </server>

    <server>

      <id>1</id>

      <host>vldmt2.prod.linkedin.com</host>

      <http-port>8081</http-port>

      <socket-port>6666</socket-port>

      <admin-port>6667</admin-port>

      <partitions>4,5,6,7</partitions>

      <zone-id>1</zone-id>

    </server>

  </cluster>

 


Una cosa que es importante entender es que las particiones no son particiones estáticas de servidores, sino que son un mecanismo para particionar el espacio de claves de tal manera que cada clave se asigna estáticamente a una partición de datos en particular. Esto significa que un clúster en particular puede admitir muchas tiendas, cada una con diferentes factores de replicación; el factor de replicación no está codificado en el diseño del clúster. Esto es importante, ya que algunos datos son más importantes que otros, y la compensación correcta entre rendimiento y consistencia para una tienda puede ser diferente de otra.

Otro punto importante para recordar es que no se puede cambiar el número de particiones de datos. Apoyamos una redistribución en línea (reequilibrio) de particiones. En otras palabras, la inclusión de nuevos nodos da como resultado el traslado de la propiedad de las particiones, pero el número total de particiones siempre será el mismo, al igual que la asignación de clave a partición. Esto significa que es importante dar un buen número de particiones para empezar. El script aquí generará esta parte de la configuración por usted.

Gestión de BDB

El almacén de clave-valor subyacente también es importante para la configuración y la gestión de operaciones. Si se utiliza BDB, toda la configuración se realiza a través del archivo server.properties. Si se utiliza MySQL, se debe realizar la administración habitual de mysql.

Oracle tiene una reseña que brinda una buena descripción general del lado operativo de BDB.

Oracle NoSQL Database es una base de datos NoSQL tipo clave-valor (del estilo de Redis o Voldemort):

Sus principales características son:

Arquitectura

· Está construida sobre Oracle Berkeley DB Java Edition sobre la que añade una capa de servicios para usarse en entornos distribuidos



 Alta Disponibilidad y No-Single Point of Failure

  • Provee replicación de base de datos 1 Master-Multi-Replica
  • Las datos transaccionales se replican

 Balanceo de carga transparente:

· El Driver de Oracle NoSQL particiona los datos en tiempo real y los distribuye sobre los nodos de almacenaminto

· Su topología rutea las operaciones de escritura y lectura al nodo de almacenamiento más adecuado para optimizar la distribución de carga y rendimiento

Formato JSON

· La version 2 añade sopote para serialización con Avro, lo que permite definer un schema en JSON para los datos almacenados

Topologías configurables

· Los administradores pueden indicar cuanta capacidad está disponible en un nodo de almacenamiento permitiendo a los nodos con más capacidad almacenar varios nodos de replicación

Administación sencilla y Monitorización:

· Oracle NoSQL suministra un servicio de administración, tanto por consola web

 


 

Algunas sugerencias adicionales

Configuración de JVM

En LinkedIn mantenemos dos conjuntos de clústeres, de solo lectura y de lectura y escritura. Los clústeres de lectura y escritura son clústeres que utilizan almacenes BDB y tienen características de JVM totalmente diferentes de los que utilizan almacenes de solo lectura. Esto es lo que usamos en LinkedIn para nuestras tiendas de lectura y escritura:

  # Tamaño mínimo, máximo y total de JVM
  JVM_SIZE = "- servidor -Xms32g -Xmx32g"

  # Tamaños de nueva generación
  JVM_SIZE_NEW = "- XX: NewSize = 2048m -XX: MaxNewSize = 2048m"

  # Tipo de recolector de basura a usar
  JVM_GC_TYPE = "- XX: + UseConcMarkSweepGC -XX: + UseParNewGC"

  # Opciones de ajuste para el recolector de basura anterior
  JVM_GC_OPTS = "- XX: CMSInitiatingOccupancyFraction = 70 -XX: SurvivorRatio = 2"

  # Configuración de registro de actividad de JVM GC
  JVM_GC_LOG = "- XX: + PrintTenuringDistribution -XX: + PrintGCDetails -XX: + PrintGCDateStamps -Xloggc: $ LOG_DIR / gc.log"

Tener en cuenta que debe usar la marca simultánea y el barrido gc o, de lo contrario, el GC se detiene para recolectar un montón tan grande que causará períodos que no responden (tampoco sucede al principio, se arrastra y luego finalmente entra en una espiral de gc pause death ).

Esta es la configuración en una caja de RAM de 48 GB con un tamaño de caché BDB de 20 GB y 1 hilo más limpio, en SSD. Puede encontrar la configuración completa en config / prod_single_node_cluster. Para abrir un servidor con esta configuración, use bin / voldemort-prod-server.sh