Sharding en el nivel de aplicación

Question

Estoy diseñando un sistema multi-tenant y estoy considerando la fragmentación por inquilino en el nivel de la capa de aplicación en lugar de la base de datos.

Hipotéticamente, la forma en que esto debería funcionar es que para la solicitud entrante, un proceso de enrutador tiene una colección global de inquilinos que contienen atributos primarios para determinar el inquilino para esta solicitud, así como la identidad del fragmento virtual. Esta identificación de fragmento virtual se correlaciona con un fragmento real.

El fragmento actual contiene tanto el código para la aplicación como los datos completos para este inquilino. Estos fragmentos serían servidores LNMP (Linux, Nginx, MySQL/MongoDB, PHP).

El proceso del enrutador debe actuar como proxy. Debería poder ejecutar algún código para determinar el fragmento de destino para la solicitud entrante en función de la colección almacenada en algunos db o archivos locales. Para poder escalar esto mejor, estoy considerando hacer que los fragmentos también actúen como enrutadores para que puedan ejecutar un proxy inverso que reenvíe la solicitud al fragmento apropiado. Quizás la instancia de nginx que se ejecuta en shard también puede actuar como ese proxy inverso. Pero cómo ejecutará la lógica de la aplicación necesaria para hacer coincidir la solicitud con el fragmento apropiado.

Agradeceré cualquier idea y sugerencia para la implementación de este enrutador.

Gracias

Answer 1

A menos que usted espera que sus inquilinos para generar volumen de datos aproximadamente igual, sharding por el inquilino no será muy eficiente.

En cuanto a la aplicación sharding nivel en general, permítanme compartir mi propia experiencia:

Versión 1 de nuestro gran volumen de productos SaaS fragmentada a nivel de aplicación. Descubrirá que, a medida que crece, el recambio será un gran dolor de cabeza si se compara con una solución de tipo SQL a nivel de aplicación, o tendrá que escribir herramientas significativas para automatizar el proceso.

Cambiamos a MongoDB (después de considerar múltiples alternativas, incluyendo Cassandra) en gran parte debido a todo el soporte integrado para el reajuste/reequilibrio a medida que crecen los datos.

Si su aplicación no necesita las capacidades relacionales de MySQL, le sugiero que concentre sus esfuerzos en MongoDB (ya que ha identificado eso como una plataforma de datos posible) si espera más que un modesto crecimiento de datos. Permita que MongoDB maneje el sharding de datos.

Answer 2

Otra opción sería usar un producto como dbShards. dbShards es el único producto de fragmentación que fragmenta a nivel de aplicación. De esta forma, puede usar cualquier RDMS (Postgres, MySQL, etc.) y aún así puede fragmentar su base de datos sin tener que colocar algún tipo de proxy intermedio. Muchos de los otros productos de fragmentación dependen de un proxy para señalar las transacciones al fragmento correcto, pero dbShards sabe a dónde ir sin tener que "preguntar" a nadie más.

Gran producto. dbshards