¿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