Sharding de ontologías en la BDTR

En la release 2.14 de Sofia2 hemos añadido una nueva funcionalidad muy útil para aumentar el rendimiento de la plataforma: el sharding (o “particionado”) automático de ontologías en la BDTR.

¿Pero por qué implementar el sharding manualmente cuando MongoDB ya nos lo ofrece? Fijaos en la configuración de un shard típico:

Shard típico de MongoDB
Shard típico de MongoDB

Como veis, para utilizar sharding necesitamos, como mínimo,

  • tres servidores de configuración
  • tres replica sets, con tres máquinas cada uno.
  • un proceso balanceador, mongos.

Así, para distribuir los datos entre tres shards, necesitamos la friolera de 13 máquinas, y algunas deberán estar en datacenters distintos. En muchos casos, la dificultad del mantenimiento y el propio coste de las máquinas hacen que esta solución no sea asumible.

Otra alternativa para mejorar el rendimiento de MongoDB es utilizar muchas colecciones pequeñas en el mismo servidor. Por el simple hecho de tener menos registros, todas las operaciones que se hagan sobre esas colecciones (como inserciones, borrados,…) serán mucho más rápidas. Además, el mantenimiento de los índices será mucho menos costoso, ya que el tamaño de estos será mucho menor.

Esto es precisamente lo que buscamos con el sharding automático de ontologías en la BDTR. Al activarlo, para cada ontología se generarán n colecciones en la BDTR de acuerdo a dos posibles estrategias:

  • usar la identificación de usuario, de forma que haya una colección para cada usuario que manipule la ontología.
  • usar la instancia del KP, de forma que haya una colección para cada instancia de KP que manipule la ontología.

La estrategia que se usará para particionar los datos puede configurarse editando la ontología en modo administrador (en la sección Configuración BDTR y BDH Particionar datos en BDH):

Configuración del sharding en modo administrador
Configuración del sharding de ontologías (en modo administrador)

El sharding es totalmente transparente para el usuario, y se consigue parcheando las operaciones que actúan sobre la BDTR antes de enviárselas a MongoDB. Por ejemplo, un mensaje SSAP QUERY que recupera algunos registros de la ontología TestSensorTemperatura contendrá esta query:

db.TestSensorTemperatura.find({…})

Si los datos de la ontología TestSensorTemperatura están particionados en la BDTR por el identificador de usuario y el KP que ha enviado el mensaje es propiedad del usuario lbarrios, al final se enviará esta query a MongoDB:

db.TestSensorTemperatura_lbarrios.find({…})

Como habréis notado, cuando el sharding está activo no es posible consultar sobre todas las colecciones asociadas a una misma ontología, pero esta limitación puede eliminarse fácilmente si es necesario.

Gracias al sharding de ontologías, es posible aumentar inmediatamente el rendimiento de una instalación de Sofia2. Además, de cara a la esperadísima versión 2.8 de MongoDB, el sharding de ontologías mejorará aún más el rendimiento. Hasta la versión 2.6 de MongoDB, los bloqueos de lectura y escritura se aplican sobre toda la BDTR. En la versión 2.8, estos bloqueos se aplicarán a nivel de colección, y puesto que el sharding hace más difícil que dos KPs hagan peticiones sobre una misma colección, el número total de bloqueos se reducirá drásticamente.

Sharding de ontologías en la BDTR

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s