sql server - tuning - Rendimiento de tablas de bases de datos vs SharePoint
trucos sql server (8)
La regla de oro es limitar las listas de SharePoint a 2000 elementos por motivos de rendimiento.
En 100k, el rendimiento iría "de succión a golpe".
La única forma de que esto funcione es si puede segmentar el conjunto de datos en múltiples listas con menos de 2000 en cada una.
- Estamos buscando almacenar datos transaccionales en listas de SharePoint. Las listas crecerán fácilmente a más de 100,000 elementos.
- ¿Cómo se compararía el rendimiento de la consulta con las consultas en una tabla de base de datos con estas columnas?
Consultas: Seleccionar por Id Seleccionar donde ColumnValue = X Group por OrderId Agrupar por fecha
La Lista SP tendrá 6 columnas de ancho: Id, Fecha, ID de pedido (Búsqueda), Quanity, ItemName, Título
+1 No
La función de SharePoint principalmente es la colaboración. En su caso, solo listará los datos como de solo lectura. En su situación, recomendaría almacenar los datos en SQL DB, si necesita mostrarlos en el portal de SharePoint puede usar BDC o algo así como el elemento web Bamboo Data View. http://store.bamboosolutions.com/p-71-data-viewer-web-part.aspx
Las listas de SharePoint serán más lentas.
Más gastos generales = peor rendimiento.
Estoy de acuerdo con todos los comentarios anteriores. He tenido una amplia experiencia con clientes que querían usar listas de SharePoint para cosas que no encajaban. Si le preocupa el rendimiento en absoluto, entonces las listas de SharePoint no son el camino a seguir. Si solo es para fines de archivo y realiza búsquedas infrecuentes de los datos y las funciones de búsqueda de SharePoint son suficientes para usted, podría considerarlo y no descartarlo de forma inmediata (si está utilizando MOSS).
Pero consideraría todos los aspectos de esto cuidadosamente. No es demasiado difícil a través de los elementos web de formularios de datos y el BDC para obtener datos del servidor SQL en el entorno de SharePoint, pero es más difícil obtener datos de SharePoint en otras plataformas o aplicaciones.
Y nuevamente, si el rendimiento es en absoluto un requisito, entonces no lo hagas.
Para obtener más información sobre mejores prácticas de escalabilidad y rendimiento de SharePoint, consulte: http://technet.microsoft.com/en-us/library/cc287790.aspx
No lo hagas SharePoint no es bueno en el manejo de datos transaccionales y tendrá un mal rendimiento.
Cualquier habilidad que pueda tener para mejorar el rendimiento en el nivel de la base de datos (como agregar índices) puede tener efectos perjudiciales en la instalación de SharePoint (aunque las columnas en las listas se pueden "indexar" a través de SharePoint.
Esencialmente, SharePoint está diseñado para un propósito específico (contenido / documentos) y tratar de lograr que haga algo fuera de lo normal significa que tiene que luchar contra la aplicación con uñas y dientes.
Afortunadamente, SharePoint tiene varios medios para integrar datos transaccionales en él.
En primer lugar (si tiene la licencia Enterprise más cara) tiene el Catálogo de datos profesionales que le permite importar valores de base de datos que aparecerán de forma similar a los elementos de la lista.
Si no tiene la licencia de Enterprise, puedo recomendar controles / webparts personalizados o el elemento web Vista de datos para permitir que esos datos se "muestren" en las páginas relevantes dentro de SharePoint.
En resumen: se preparará para una gran cantidad de trabajo heterogéneo almacenando datos transaccionales dentro de SharePoint en comparación con otros diseños de aplicaciones que hospedan los datos en aplicaciones de bases de datos tradicionales y se integran a SharePoint.
También estoy de acuerdo con los tipos anteriores. Sin embargo, muchos de los problemas de rendimiento que se comentan en los blogs se deben al hecho de que el Modelo de objetos de SharePoint no se usa correctamente.
Puede consultar mi serie de blog sobre el rendimiento de la lista de SharePoint en dynaTrace Blog. Esta serie analiza el Modelo de objetos de SharePoint para resaltar lo que realmente está sucediendo entre los servidores de SharePoint y la base de datos de contenido
Por supuesto, el enfoque propuesto no es recomendable.
Pero, al estar en el tema, aquí hay un buen documento para grandes listas perf en WSS
Habiendo hecho esto yo mismo, ¡diría que trate de evitarlo si es posible! Es un campo de minas, especialmente después de aproximadamente 100,000 filas.
Algo que también puede terminar mordiéndote, es que el rastreador de búsqueda puede comenzar a agotar el tiempo tratando de rastrear listas realmente grandes: puedes aumentar los tiempos muertos, pero es el comienzo de una batalla perdida.