user - multitenancy - Cómo implementar campos definidos por el usuario y agrupamiento para la aplicación multi-tenant: EAV, patrón de tablas fijas, NoSQL

multitenant mongodb

Question

Estoy trabajando en un SaaS, donde cualquier inquilino puede tener varias listas de contactos, cada lista puede tener cualquier cantidad de campos personalizados que los contactos de esta lista puedan almacenar y cualquier cantidad de grupos que puedan incluir los contactados de la lista (se usan grupos). para segmentar contactos de la lista). Cada contacto tiene un campo obligatorio: dirección_de_email y cualquier número de campos definidos por el usuario que estén definidos para la lista donde se encuentra, como mencioné anteriormente. Debemos ser capaces de encontrar contactos de las listas basadas en los grupos en los que se encuentran y los valores de los valores definidos por el usuario. Debemos provisionar hasta 30 campos definidos por el usuario. Veo ahora tres formas de resolver este problema:

1. Usando una especie de EAV (tratamos de hacerlo así), pero parece bastante complejo. Tenemos una tabla de listas (listas de inquilinos), tablas relacionadas custom_fields, tablas relacionadas suscriptores que almacenan email_addreses de suscriptores de la lista, tabla subscribers_custom_data que está relacionada con suscriptores y tablas custom_fields (valores almacenados de los campos personalizados de los suscriptores) .

2. Patrón de tablas de campo Las descripciones de esto están aquí http://blog.springsource.com/arjen/archives/2008/01/24/storing-custom-fields-in-the-database/ . En este caso, utilizaríamos un campo relacionado con campos personalizados, que almacenaría en columnas todos los campos personalizados, por ejemplo, 30 columnas para almacenar los valores de cada campo personalizado posible y una tabla que almacenara la asignación del nombre y el nombre de las columnas definidas por el usuario. campo. Parece complejo también. Tendríamos que tener al menos 30 índices al menos para buscar por los valores de los campos personalizados, también hay otros problemas,

3. Para utilizar algún tipo de base de datos NoSQL al menos para el almacenamiento de los campos definidos por el usuario y tal vez grupos de la lista. ¿Cree que estas bases de datos pueden ayudar aquí y, en caso afirmativo, cómo diseñar para almacenar campos y grupos personalizados? Intento mirar diferentes tipos de NoSQL, por ejemplo, documento orientado como MongoDb, pero de inmediato no puedo ver cómo puede ayudar a resolver este problema. Aquí podemos almacenar atributos arbitrarios, pero para buscar los valores de los campos personalizados necesitamos indexarlos con anticipación, así que tenemos que saber qué campos personalizados tendremos.

Gracias por cualquier información al respecto.

Answer 1

Si desea que todos los campos se indexen todo el tiempo, pruebe con una tecnología como Apache Solr que indexa todo. El objetivo principal de Solr es ser un motor de búsqueda de texto completo, pero básicamente es una base de datos orientada a documentos.

Aquí hay comentarios sobre otras opciones:

1. EAV no es bueno, y estoy en contra de usarlo. Rompe muchas reglas del diseño de bases de datos relacionales, y no se escalará. He escrito mucho sobre esto en , así que busca mis respuestas debajo de la etiqueta eav .

2. No necesita solo 30 índices: necesita hasta 30 índices factoriales para manejar cualquier posible combinación de índices. Tenga en cuenta que puede crear índices de varias columnas, y estos tipos de índices son importantes para admitir ciertas consultas. Por supuesto, esto es totalmente impráctico para crear tantos índices; necesita crear índices para que coincidan con las consultas para las que desea optimizar. Si no sabe qué campos tendrá y qué consultas tendrá contra ellos, no podrá optimizarlos.

3. Las bases de datos orientadas a documentos como MongoDB / CouchDB no son mágicas, sin importar cuánto intenten defender sus defensores. Requieren que indexe documentos para búsquedas rápidas, y eso significa que necesita conocer los campos indexables de un documento.

   Crear un índice en el tiempo de ejecución es un problema, ya que puede llevar mucho tiempo, dependiendo de la cantidad de datos que hay que indexar. Deberá encontrar una forma de ejecutar la creación del índice "fuera de línea" (es decir, no hacer que el usuario lo espere durante una sola solicitud http) y luego notificarlo cuando esté completo.

4. Debería leer sobre cómo FriendFeed utiliza MySQL para almacenar datos sin esquema . Usan un LOB serializado, básicamente combinan todos los atributos personalizados en un blob XML o JSON. Por lo tanto, los usuarios pueden crear cualquier cantidad de campos personalizados adicionales en cualquier momento que deseen. Pero antes de que un campo personalizado determinado se pueda buscar, se crearía una tabla secundaria que haga referencia a las filas en las que ese campo contiene un valor determinado. De este modo, obtiene un índice que es solo tan grande como el número de instancias de un campo personalizado definido por el usuario. Y no necesita hacer que todos los campos sean buscables.