Office.com utiliza SharePoint como plataforma subyacente para proporcionar soporte a los usuarios finales de los productos de Office. Al migrar Office.com a SharePoint a gran escala, se aprendieron lecciones importantes sobre el rendimiento y el modelo de datos de SharePoint. Se determinó que para grandes volúmenes de datos y transacciones, el modelo de lectura/escritura en una sola base de datos no funciona, y se desarrolló un marco para operar sobre múltiples conjuntos de datos de forma masiva.

1. Office.com sobre SharePoint
Ariel Kirsman

2. Agenda
• Qué es Office.com
• SharePoint como plataforma
• Lecciones aprendidas
• Conclusiones
• Q&A

3. Qué es Office.com
Soporte para usuarios finales de los productos Office (Word,
Excel, PowerPoint, etc).
Web Site + Web Services

4. Qué es Office.com
En números
500 autores de contenido...
Que administran 6 millones de páginas...
Que visitan 120 millones de usuarios distintos...
Que generan >3000 RPS (requests por segundo)...
Servidos por 48 farms de 4:1 al 60% de CPU
Distribuidas en 2 data centers (por geo-redundancy)
37 developers, 24 testers, 11 PM’s

5. Qué es Office.com
Vista Conceptual
Content Management System («Authoring») - donde los
autores crean, administran y localizan el contenido,
Office.com («Rendering») – al cual los usuarios y las
aplicaciones de Office se conectan,
Bulk Operations Framework – que permite procesar
múltiples objetos de manera unificada,
Unified Warehouse - repositorio de sólo-lectura de todo tipo
de metadata (de contenido, social, estadísticas de uso, etc)
sobre el cual se ejecutan consultas, workflows y análisis.

6. Qué es Office.com
Vista de Componentes
...

7. Qué es Office.com
Legacy
Vista de Datos
Migración
Migración
Authoring
Propagación de Contenido
Rendering

8. Qué es Office.com
Publishing

9. SharePoint como plataforma
Razones de la elección
Llevar a SharePoint a una escala de Internet.
«Dogfooding»: si no es bueno para Microsoft, no es bueno
para los clientes.
Implementar a un nivel mayor de abstracción
Deployment
Workflows
Queries
Search
Pero, ¿hacerlo con la versión 14 en desarrollo?
Desventaja: «moving target»
Ventajas
Colaboración del equipo de SharePoint.
Círculo virtuoso.

10. Lecciones Aprendidas
Almacenamiento: Separación Authoring vs. Rendering
En teoría, esta es la proposición de valor de SharePoint: integrar
authoring y rendering de manera natural.
Pero no funciona para altos volúmenes de
Contenido
Creadores de contenido
Visitantes al sitio
¿Porqué?
Writes vs. Reads
Secure vs. Anonymous
Transacciones largas (check-in/out) vs. cortas
Solución: webapps y site collections separadas, y en Rendering
Denormalización
No versioning
Caching

11. Lecciones Aprendidas
Almacenamiento: Site collection por lenguaje (Authoring)
Todos los lenguajes ocupan aprox. 2TB.
Administrar la DB se vuelve más costoso a mayor tamaño
Backups
Mantenimiento (rebuild indexes, update statistics)
Problema: queries sobre múltiples site collections
Importante para el Localization team: «obtener todos los
artículos que fueron asignados al vendor X y no fueron
traducidos en una semana».
Solución: exportar metadata a SQL («Unified Data
Warehouse»).
Dentro de cada site collection, un root web sin subsites
Sub-sites no ofrecen ventajas de administración de datos.
Look & Feel es consistente por lenguaje.

12. Lecciones Aprendidas
Queries de SharePoint
Potencia de los Queries
performance.
expresividad.
A futuro, ¿SQL Server’s SPARSE columns?
Máximo de 2 columnas para compound indexes.
Diagnosibilidad de los Queries
e.g., bug cuando los CAML OR’s anidados superaban los
64 niveles 
CAML erróneos (e.g., en SPSiteDataQuery) resultan en
«default queries» en lugar de lanzarse una excepción.

13. Lecciones Aprendidas
Modelo de Datos
Relaciones (aprox. 3M)
Todas las aplicaciones las tienen, y tienen atributos.
SharePoint no soporta nativamente este concepto.
Sin embargo, pudimos haber resuelto los mismos
problemas con tagging y folders...
SharePoint no soporta
Logueo de cambios a nivel de configuración/sistema.
Logueo de items borrados en listas y bibliotecas.
Causa: Coupling - «change tracking» está implementado
en términos de «version tracking».
Gran volumen de binarios en la base de datos afecta
Performance
Administración
Deberíamos haber implementado EBS.

14. Lecciones Aprendidas
Concurrencia y Locking
Cuando el volumen de updates de metadata es grande,
pudimos observar problemas de contención
Excesivos SQL locks
Excesivas escalaciones de SQL locks
Lecturas lentas
SharePoint está optimizado para «long-running transactions»,
(e.g., check-in, check-out), stream de un item.
No está optimizado para cambios frecuentes en la metadata
de los items.

15. Lecciones Aprendidas
Bulk Operations
Muchas operaciones no se pueden hacer «de a muchos
(items)», o los límites son artificialmente bajos (e.g., máximo
de 100 items a la vez para upload).
uploads/downloads múltiples.
cambios de metadata.
SharePoint no posee «transactional inserts/updates/deletes»
(i.e., realizarlos completamente o no realizarlos del todo).
Gran problema para migración de datos.

16. Lecciones Aprendidas
Programming API
DB roundtrips
Cuándo se va a realizar un DB roundtrip, y cuánto cuestan
(e.g., SPList.Items.Count vs. SPList.ItemCount)
fetchDocForHttpGet() trae metadata del ContentType.
RT adicional para fields fuera de él, no 3 RT’s/artículo 
No SP* objects caching
Publishing APIs caching es costoso para 1er request.
Costo de list schema.
Event Receivers
La secuencia de eventos debería ser consistente.
No asumir nunca que otro event handler hizo su tarea.
Asincrónicos: no thread-safe, no cancelables.
Reglas complejas de disposing.
SharePoint loguea determinado «usage data» per request.
Metadata no es customizable (e.g., Asset ID)

17. Lecciones Aprendidas
Propagación de Contenido
Problema: cómo propagar datos de un master DB a múltiples
bases para lograr scale-out.
SQL Replication
Requiere primary keys en todas las tables de la base
SharePoint no las tiene 
Export & Import, Content Migration API (PRIME) API: config
DB data, check-out status, encuestas no completadas, etc.
Backup & DB Attach: latencia (i.e., tiempo de propagación
desde authoring a rendering SQL’s).
Solución elegida: log-shipping.
Requiere poner DB offline.
Mayor latencia que SQL Replication.
Múltiples chequeos adicionales sobre la solución OOB.
Alto costo operacional – «baby-sitting»

18. Lecciones Aprendidas
Propagación de Contenido con Log Shipping
Log Shipping
Manager (scheduled tasks)
Switch B->A, así Master
B se pone al día
Instance
A
SQL
SQL Alias -> A Instance .TRN’s
B

19. Lecciones Aprendidas
Propagación de Contenido con Log Shipping
Log Shipping
Manager (scheduled tasks)
Switch A->B, así Master
A se pone al día
Instance
A
SQL
SQL Alias -> B Instance .TRN’s
B

20. Lecciones Aprendidas
Deployment
Se usaron solutions packages y features.
Errores cometidos
Listas y content types se aprovisionaron («crearon») en base
a un formato propio (no CAML)
Topología y features a instalar/activar se manejó con código +
configuración custom
Complejidad => Errores.
Problemas en la migración de contenido entre versiones.
Alternativas
Usar CAML, site templates y restringir código sólo a feature
activation/deactivation, minimizando external scripts.
Ausencia de varias VS tools para SP al inicio del proyecto 

21. Lecciones Aprendidas
Security
Authoring: built-in authentication/authorization
Mantener autorización simple es fundamental
Limitar granularidad, minimizar «break inheritance»
Usar domain groups en lugar de domain users.
Problema: acceso de usuarios fuera del dominio.
Solución: Live ID on Claims.
Finalmente, no en producción (Claims no nos llegó a
tiempo)
Rendering: acceso anónimo, Live ID para identificar usuarios
Necesita ser «Partner site» para acceder al perfil de usuario.

22. Lecciones Aprendidas
Proceso
Curva de aprendizaje de SharePoint
1. Aprender
2. Aprender a hacerlo bien 
Perf Testing fue clave para el avance del proyecto
Regresiones (# de DB RT’s)
Plan de capacidad
Topología de farm.

23. Conclusiones
SharePoint soporta Internet scenarios con grandes volúmenes de
datos 
El modelo de datos es fundamental para la performance (e.g., #
de fields por content type).
Para grandes volúmenes de datos y transacciones, el modelo de
lectura/escritura en una base de datos única no funciona.
Desarrollar un framework para operar sobre múltiples datos a la
vez fue una decisión muy acertada.
Planeamiento de capacidad y perf testing desde el inicio fue muy
acertado.
Migrar contenido es siempre complicado... no se debe dejar nunca
para el final.
Invertir en logging (más allá del OOTB) es beneficioso.
Este proyecto significó un gran aprendizaje para SharePoint
mismo... veamos estas experiencias como oportunidades.

24. ¿Preguntas,
comentarios?
Muchas gracias.