Ejemplo de esquema de ficheros

[spilby]

Buenas,

actualmente tenemos, mediante Alfresco 4.1.6, casi dos millones de documentos repartidos en carpetas que siguen la siguiente estructura:

Repositorio: /User Homes/APP/*

Donde * es un código numérico de 10 dígitos, y son aproximadamente unas 3000 carpetas. (Cada código representa a un usuario).

Dicho usuario se administra las carpetas como quiere, pero cada uno de ellos puede tener miles y miles de documentos, llegando a tener un árbol de carpetas con más de 200 directorios en alguna de sus ramas.

El problema que tenemos es que el acceso cada vez va más lento, hasta el punto que si desde el propio share intento mirar el contenido de /User Homes/APP con sus 3000 carpetas, tras varios minutos acaba dando un error y no muestra los elementos.

Pero no es solo eso, es que desde la aplicación que tenemos que navega y crea carpetas mediante la API de Java va muy lento, llegando a dar timeouts en algunas búsquedas. Los propios métodos Java que invocamos tardan demasiado en dar respuesta, al localizar documentos o buscar hijos.

Por descartar un problema de estructura de árbol… ¿Es correcto que tengamos las carpetas colgando del User Homes? ¿Sería más eficiente por ejemplo crear un Site para cada uno de los 3000 usuarios? ¿O pasaría lo mismo y al intentar buscar o mostrar los sites seguiría colgándose? ¿Alguna idea?

Muchas gracias!

[angelborroy]

Échale un vistazo a las recomendaciones de Luis Cabaceira para mejorar el rendimiento del sistema:
https://summit.alfresco.com/cmis/views/workspace%253A%252F%252FSpacesStore%252F50bdd351-16f8-4a95-bc...
http://es.slideshare.net/LuisCabaceira/alfresco-tuning-part1

Si utilizáis SOLR, quizá podáis balancear la carga instalándolo en un nodo independiente y dándole más recursos, aunque si habéis dejado que los usuarios establezcan permisos personalizados en las carpetas el problema puede ser realmente más grave. Quizá deberíais replantearos la política de asignación de permisos a carpetas.

En cualquier caso, no sería más eficiente crear un sitio para cada uno de los 3.000 usuarios: sería exactamente lo mismo. En este punto Alfresco (y cualquier otro sistema basado en ficheros, carpetas y SOLR) no es demasiado eficiente, el límite suele estar en unos 1.000 nodos paralelos. Nosotros en alguna ocasión hemos aplicado una política de división de carpetas por hashing. Esto es, se le asigna un hash a cada carpeta (puede valer el uuid) y después se almacena por niveles: el UUID 4506-192381-129383 se almacenaría en las carpetas 4506/192381/129383. Con esta técnica reduces el número de carpetas en paralelo.

En mi opinión y sin tener más datos, creo que el problema básico reside en la optimización de SOLR. Quizá migrar a 5.0 con SOLR 4 sea también una alternativa.

Suerte

[spilby]

Hola Ángel, muchas gracias por las recomendaciones, las tendremos realmente en cuenta.

Una cosa que no entiendo de la subdivisión de carpetas… Pongo un ejemplo sencillo para que quede más claro.

En una aplicación (que sirva por ejemplo para navegar y crear carpetas y subir archivos en ellas) el usuario elije crear la carpeta "Expedientes a tramitar". Mediante la API Java de Alfresco le decimos a Alfresco que cree el nodo y le asigna un uuid 4506-192381-129383. El usuario ve la carpeta creada.

De ahí el usuario crea dos carpetas más que cuelgan de ella: "Expedientes 2014" y "Expedientes 2015" y Alfresco les asigna los uuid 8506-192482-126381 y 9572-109382-229382, respectivamente.

El usuario verá por tanto una carpeta "Expedientes a tramitar" y cuando quiera ver sus hijos, haremos la petición a Alfresco para averiguar los hijos de ese nodo, y le mostraremos "Expedientes 2014" y "Expedientes 2015".

Ahora bien, si lo que hacemos es guardar esas carpetas segun un hash para evitar que crezca el número de nodos en paralelo, ¿cómo mostraremos al usuario los dos hijos de esa carpeta si los estamos ubicando en realidad en un árbol diferente?. Es decir, si lo guardamos en las carpetas 4506/192381/129383, cuando pidamos a alfresco qué hijos tiene "129383" no nos devolverá los que han sido guardados en "8506/192482/126381" y en "9572/109382/229382".

Entiendo que entonces al usuario no se le muestra el árbol real de carpetas, sino que hay dos, el que se muestra (que es el que ha ido creando él) y el real (que es el árbol segun los hash).

¿Guardáis de alguna forma una propiedad que identifica los parentescos en el árbol? ¿O no usáis nunca los métodos de jerarquía para obtener hijos o padres (getChildren, etc.), sino que buscáis siempre por metadatos como el name u otros? De ser así, en un sistema con varios millones de archivos, ¿tardará menos en hacer N búsquedas de metadatos para averiguar la ruta y mostrar al usuario los elemenos por los que navegar, que usando los métodos que te proporcionan los hijos directos?

Muchas gracias de nuevo!

[angelborroy]

Creo que bastaría con realizar esta técnica de desglose de carpetas en el nivel usuario: ahí es donde está el problema grave (3.000 nodos paralelos). Una vez dentro, dejaría al usuario que se organizase como quisiese.

El tema del UUID era un ejemplo para ilustrar el concepto. Quizá en vuestro caso debáis agrupar a los usuarios por algún otro concepto (departamento, colectivo, primeras letras del apellido…) y cambiarles la URL de home. De esa manera, todo el resto funcionará uniformemente.

[spilby]

Ok, Ángel, merci! Moveremos las carpetas entonces para evitar esa cantidad tan alta de nodos en paralelo.

Así mismo, voy a modificar algunas cosas más para intentar optimizar el tiempo de respuesta en búsquedas y accesos a nodos.

1. Eliminaré el PATH de las queries, y utilizaré PARENT. He leído que es más rápido.

2. No usaré getChildAssocs para obtener los hijos de un nodo. Parece que tampoco es recomendable para grandes cantidades de información. Búscaré métodos de FileFolderService que hagan ese trabajo.

A ver si así responde mejor la aplicación!

[spilby]

Ostras, me encuentro con un problema a la hora de eliminar el PATH. Tenemos diversas carpetas en User Homes. De una cuelga toda la estructura que comentaba, de otra un backup, etc.

¿Qué pasa? Pues que si uso querys con un TYPE y una búsqueda por metadato, eliminando el PATH, ¿cómo le digo a Alfresco que busque en la carpeta correcta del User Homes? Ya que podría encontrarme datos en la de backup, por ejemplo, y no sería correcto.

Dicho de otra manera, necesito especificar a partir de qué carpeta del User Homes debe buscar.

Y a raíz de esto, estoy dándome cuenta del problema de estructura que tenemos…

En el User Homes tenemos una carpeta X. De esa carpeta X cuelgan las miles de carpetas, cada una de las cuales representa a un usuario, y desde ahí ellos cuelgan las carpetas y documentos. Todo mediante una aplicación en Java que desarrollamos, no hacen nada por el share.

Disponemos de un único usuario/password con permisos en todas esas carpetas, por tanto cuando me autentico para realizar las operaciones que sean (búsquedas, creación de nodos, etc), lo hago con ese usuario. Y con el PATH indicaba a partir de qué carpeta de usuario buscar.

Si tuviéramos distintos usuarios, y cada uno de ellos tuviera permisos para ver sólo la carpeta de su usuario, imagino que al autenticarme y realizar operaciones, éstas se harían sólo sobre esa carpeta específica, y mejoraría el tiempo de respuesta. Imagino que el Alfresco cuando hace búsquedas ya filtraría y sin necesidad del PATH buscaría sólo desde esa carpeta de usuario. ¿O igualmente busca sobre todos y no ganaría nada con esto?