2000 según Microsoft. No, no es cierto, después de 2000 elementos la Lista empieza a tener problemas para mostrar los elementos en pantalla (http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=inf&itm=382 ). Así que en realidad cuantos elementos se pueden meter en una Lista antes de que SharePoint diga “hasta aquí voy yo” y deje de funcionar? De nuevo, según Microsoft, por los cinco millones...
Pero una cosa es meter elementos en una Lista, y otra muy diferente poder hacer algo con ellos. Si después de una cierta cantidad es infinitamente demorado encontrar uno de los elementos, no tenemos nada con cinco millones...
Problema: Una intranet de una empresa con más o menos 20.000 usuarios. Cada mes el sistema de administración (separado de SharePoint) suministra un archivo pdf (7 kb) con el extracto del salario de cada empleado (usuario) y uno de los requisitos de la Intranet es que los usuarios puedan ver sus extractos en la Intranet, y de una forma segura. Esto significa que cada mes habrá que meter por lo menos 20.000 archivos pdf en algún lado en el Portal... en una Librería, por supuesto, pues SharePoint es todo Listas y Librerías.
Especulación: Usar una Librería por año? Un cuarto de millón de elementos en una Librería debería ser posible según Microsoft, pero cuanto se demora SharePoint en encontrar un archivo de un usuario de un determinado mes?
Una Librería por mes? Si la Librería puede con cinco millones, tiene que poder con 20.000, pero la pregunta sigue: que tan rápido se puede encontrar un elemento?
Una Librería por usuario (en MiSitio, por ejemplo), con solamente sus archivos? Y cuanto se demora el sistema en subir 20.000 archivos en 20.000 diferentes sitios?
Pruebas: Como no existen estadísticas al respecto, lo mejor es probar a ver qué pasa. Primero crear una Librería e irle metiendo archivos hasta que reviente (o no), y al mismo tiempo ver cuánto tiempo cuesta encontrar un elemento random en ella. Algunos resultados:
| Número de Elementos en la Lista |
Tiempo para encontrar un Elemento (milisegundos) |
| 10 |
2,156 |
| 100 |
2,170 |
| 1.000 |
2,640 |
| 10.000 |
6,420 |
| 100.000 |
37,125 |
La búsqueda se realizó “a lo bestia”, es decir recorriendo uno por uno de los elementos en busca de uno generado en forma random. Esto se hizo así para ver que tan ágil es el Modelo de Objetos para “loopear” (no muy ágil, por lo visto). Haciendo la búsqueda con una consulta CAML (la forma inteligente) los resultados varían de 2,203 milisegundos para encontrar un elemento entre 1.000 y 2,296 en una Librería con 100.000 elementos (eso está mucho mejor). Y si la columna de búsqueda en la Lista se indexa, cuesta 2,140 milisegundos en la Librería con 100.000 elementos.
Nota separada No. 1: parece que siempre hay un “threshold” de 2 milisegundos, probablemente el tiempo necesario para hacer que el JIT se despierte, y para que toda la burocracia de DotNet empiece a funcionar.
Nota separada No. 2: es interesante ver cómo crece la Base de Datos de contenido de SharePoint: con los 100.000 elementos (de 7 kb cada uno) creció en 797.076.928 bytes, lo que indica que hay un “desperdicio” de 10%... probablemente no desperdicio sino espacio para los meta-datos o algo así...
Conclusión: Buscar a lo bestia es de lo mas bestia... no hacerlo. Buscar con consultas CAML funciona de maravilla, y no importa si hay que buscar en una Librería con 100 o con 100.000 elementos, el tiempo de búsqueda es igual. Y si se indexa la columna a buscar, mejor aún. Y hay una carga interna de 2 milisegundos de la que no nos libramos por nada del mundo...
Y como se ha hecho el asunto: Un SharePoint Job ejecuta cada día al amanecer y escanea un directorio en busca de los archivos generados (solamente una vez al mes encontrara algo, pero eso no se lo vamos a contar para que no se vuelva perezoso). Cuando encuentra archivos, el Job crea una Librería y sube todos los archivos del mes de una sola vez, asegurando los derechos de cada archivo para que solamente el dueño tenga suficientes derechos para leerlo. Una WebPart revisa las Librerías de cada mes en busca de los archivos de salario del CurrentUser y muestra lo que encuentra. Solucionado. SharePoint contento, cliente contento, todos contentos...
Nota: como subir 100.000 elementos a una Librería de SharePoint manualmente es bastante aburrido, se ha usado una herramienta gratis, el “BulkFiller”, que pueden encontrar en http://www.sharepartsshop.com (búsquelo en la sección de “Gratis”); subir 100.000 elementos a una Librería cuesta un par de minutos, increíble. Y para borrarlos, en el mismo sitio hay otra herramienta, el “BulkCleaner”, que hace lo mismo pero al revés, y aun mas rápido...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...