En SharePoint los documentos guardados en una biblioteca o como adjuntos se guardan como binary large objects (BLOBs) en la base de datos de contenido.

En SharePoint 2010 cuando se habilita el control de versiones de una biblioteca, cada versión se guarda como un nuevo BLOB para ese documento. En teoría si tenemos un archivo de 10 MB que tiene 5 versiones, se estará consumiendo 50MB. Aunque no se modifique el archivo, si se edita alguno de sus metadatos eso también generara una nueva versión y una copia BLOB es creada.

El patrón para obtener el BLOB es dbo.AllDocs/dbo.AllDocVersions > dbo.DocsToStreams >

En SharePoint 2013 cambian las cosas con la nueva característica Shredded Storage que divide el BLOB en pequeñas shreds (pedazos), por defecto de 64KB.

Una mejora de esta caracteristica implica que cuando se realiza un cambio no es necesario modificar todo el BLOB, solo las partes que se vean afectadas se modificaran y si es necesario se crearan nuevos shreds. Los distintos shreds que no cambien simplemente son asociados tanto a la versión antigua como a la nueva. Esto puede suponer una reducción del 30-40% en almacenamiento y una reducción de ~2x en operaciones de I/O al reducir la cantidad de información que hay que escribir en cada actualización.

Se puede ver que esto supone una mejora significativa en la utilización del almacenamiento. El mismo archivo de 10MG con 5 versiones, imaginando que cada versión aumenta el tamaño del documento en 2MG, supondrá que se estará usando unos ~20MB.

El patrón para recomponer el BLOB es dbo.AllDocs/dbo.AllDocVersions > dbo.AllDocVersions/dbo.DocsToStreams > dbo.DocsToStreams > dbo.DocStreams

Preocupaciones

  • A la hora de hacer una subida/descarga de documentos se tiene que dividir/recomponer los distintos shreds de forma correcta, pasando a ser una tarea más compleja y puede llegar aumentar los tiempos de carga, como muestran distintos tests
  • Con Shredded Storage la primera versión de un documento necesita más espacio y los ahorros en almacenamiento se empiezan a ver en la versión dos, tres… de documentos de Office, cuando un mismo shred es de varias versiones.
  • ¿El comportamiento en documentos que no son de Office?. Todos los documentos independientemente del tipo se dividirán en shreds, pero la duda surge cuando se actualiza un documento que no es Office, ¿se actualiza solamente lo que se ve afectado?

    Como hay diversidad de opiniones decidí hacer una prueba con una imagen jpg, y tanto si actualizaba la imagen como si solo cambiaba algún metadato, me genero nuevos shreds que solo eran de esa versión y ninguna versión tenia shreds en común. Lo que indica es que se crea un nuevo BLOB por cada versión, como en SharePoint 2010, pero dividido en shreds y por tanto nos penaliza en los dos puntos anteriores.

Preguntas frecuentes

¿Cómo se puede activar Shredded Storage?

Es una caracteristica que esta activada por defecto

¿Se puede cambiar el tamaño de los shreds?

Si, el valor por defecto es 64KB pero este valor puede ser cambiado por ejemplo usando PowerShell (La configuración de la propiedad FileWriteChunkSize deberá de probarse concienzudamente en un entorno de pruebas)

[void][System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)

$service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService

$service.FileWriteChunkSize = <size in b>

$service.Update()

¿Esto significa que todos los archivos que tengan varias versiones ocuparan menos espacio?

No. Si un documento es más pequeño que el tamaño del shred, entonces cada versión seguirá siendo una copia completa del documento.

¿Se puede desactivar Shredded Storage?

No, Shredded Storage esta activada por defecto y no puede deshabilitarse. En teoría un solución alternativa podría ser configurar la propiedad FileWriteChunkSize a 2GB (tamaño máximo de archivo en SharePoint 2013). Modificar esta propiedad y más a ese valor puede afectar el rendimiento y la latencia.