Cuantos elementos caben en una Lista de SharePoint?

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…

4 comentarios sobre “Cuantos elementos caben en una Lista de SharePoint?”

  1. Hola Gustavo…interesante análisis, a la par que parece una prueba bastante realista de los límitesde SharePoint.

    Una pregunta, ¿cómo has medido el tiempo que se tarda en encontrar un elemento en la lista?

    Un abrazo

    JC’s

  2. Hola Juan Carlos,
    Después de cargar la Librería con los elementos, un generador random selecciona uno de los elementos y se lo entrega a una rutina que crea una variable DataTime al principio, busca el elemento indicado, genera otra variable DataTime al final y luego resta el principio del final… nada superrefinado, por el contrario… pero efectivo. El objetivo no era tanto ver cifras absolutas de cuánto tiempo tarda una búsqueda, sino relativas, para comparar los cambios con diferentes cantidades de elementos y diferentes formas de buscar.
    Un abrazo para ti tambien,
    Gustavo

  3. Hola espero me puedas ayudar, en la empresa donde laboro actualmente implementaron SharePoint 2007 (MOSS) y me han pedido que desarrolle un Site donde las personas puedan llenar un formulario y saque unos reportes pues muy fácil cree una lista y cada columna era una campo del formulario jajaja, lo malo es que en 1 mes la lista se lleno hasta los 20000 registros y el site se volvió inmanejable, que harías tu recurrías a InfoPath pero los reportes?, o a una web part con DB externa y el desarrollo que implica? (no soy experto en desarrollo) es un problema de arquitectura creo yo. Espero me regales un buen consejo de antemano muchas gracias por tu tiempo. Si pudieras subir codigo de ejemplo de lo que mecionas en este articulo seria de lujo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *