El almacenamiento es uno de los temas más puntiagudos en cuanto a gestores documentales. No todos están diseñados de manera óptima para soportar grandes cantidades de documentación.
A continuación, repasamos las dificultades de Sharepoint en este sentido.
La forma en que SQL Server almacena los contenidos
Como sabéis, Microsoft usa como gestor de bases de datos(SGBD) SQL Server. La mayoría de contenidos y documentos que almacenamos en Sharepoint se guardan en este SGBD como tipo "BLOB", que es un tipo que guarda datos binarios de gran tamaño a los que se accede mediante índices. Al no ser referencias a los contenidos, sino los contenidos en si mismos lo que se almacena en la base de datos, el acceso a ellos es bastante costoso para el sistema. Los tipos BLOB en bases de datos SQL Server constituyen el 95% de su tamaño en Sharepoint y estas, por supuesto, tienden a tener un tamaño bastante grande .
El alza del uso de formatos media de gran tamaño
Hace rato que los gestores documentales dejaron de ser sólo para documentos. En realidad, el término gestor documental es un término que se usa en España y en algunos países de habla hispana de forma indiscriminada. Las empresas no sólo almacenan documentos, tienen otros activos digitales, como vídeos, archivos de audio, presentaciones, etc. Entonces, es más adecuado hablar de Sistemas de Gestión de Contenidos Empresariales (Sistemas ECM).
El caso es que Sharepoint no se encuentra optimizado para el manejo de este tipo de ficheros que se caracterizan por su gran tamaño en la mayoría de los casos. Una forma muy fácil de detectar este problema es ver como en medio de una petición el navegador nos devuelve un pantallazo en el que nos indica que el servidor está tardando mucho en responder.
Problemas de escalabilidad en términos de hardware
Como se ha explicado en los epígrafes anteriores, el crecimiento de los datos en Sharepoint es bastante rápido, y con él los requerimientos de hardware para almacenar y procesar ese volumen de datos. A esto se suman las restrictivas especificaciones técnicas de Sharepoint, que no se caracteriza por su alta compatibilidad.
Posts relacionados: 5 motivos por los que Sharepoint no es un ECM ideal.
A continuación, repasamos las dificultades de Sharepoint en este sentido.
La forma en que SQL Server almacena los contenidos
Como sabéis, Microsoft usa como gestor de bases de datos(SGBD) SQL Server. La mayoría de contenidos y documentos que almacenamos en Sharepoint se guardan en este SGBD como tipo "BLOB", que es un tipo que guarda datos binarios de gran tamaño a los que se accede mediante índices. Al no ser referencias a los contenidos, sino los contenidos en si mismos lo que se almacena en la base de datos, el acceso a ellos es bastante costoso para el sistema. Los tipos BLOB en bases de datos SQL Server constituyen el 95% de su tamaño en Sharepoint y estas, por supuesto, tienden a tener un tamaño bastante grande .
El alza del uso de formatos media de gran tamaño
Hace rato que los gestores documentales dejaron de ser sólo para documentos. En realidad, el término gestor documental es un término que se usa en España y en algunos países de habla hispana de forma indiscriminada. Las empresas no sólo almacenan documentos, tienen otros activos digitales, como vídeos, archivos de audio, presentaciones, etc. Entonces, es más adecuado hablar de Sistemas de Gestión de Contenidos Empresariales (Sistemas ECM).
El caso es que Sharepoint no se encuentra optimizado para el manejo de este tipo de ficheros que se caracterizan por su gran tamaño en la mayoría de los casos. Una forma muy fácil de detectar este problema es ver como en medio de una petición el navegador nos devuelve un pantallazo en el que nos indica que el servidor está tardando mucho en responder.
Problemas de escalabilidad en términos de hardware
Como se ha explicado en los epígrafes anteriores, el crecimiento de los datos en Sharepoint es bastante rápido, y con él los requerimientos de hardware para almacenar y procesar ese volumen de datos. A esto se suman las restrictivas especificaciones técnicas de Sharepoint, que no se caracteriza por su alta compatibilidad.
Posts relacionados: 5 motivos por los que Sharepoint no es un ECM ideal.
Actualización: Abril del 2014
Quisiera incluir en el cuerpo de este post el enlace al post "Optimize SharePoint Storage with BLOB Externalization" que explora este asunto en mayor profundidad y que nos ha llegado por cortesía de nuestro amigo Bureado.
EBS: http://www.codeproject.com/Articles/316680/Optimize-SharePoint-Storage-with-BLOB-Externalizat Saludos.
ResponderEliminarInteresante artículo, y también la respuesta de bureando.
ResponderEliminarMe encuentro investigando sobre frameworks y aplicaciones que se integren a su vez con otros frameworks y aplicaciones. ¿Dónde podría ver un vídeo, tutorial o similar donde se vea Athento funcionando con Sharepoint?
Por otro lado, también es muy interesante el tema de la escalabilidad. Dado que vuestro producto se integra con terceros, ¿cómo manejáis la escalabilidad? ¿Cómo afecta a athento las posibles restricciones de escalabilidad que tengan aplicaciones y software de terceros con los que se pueda integrar? ¿Disponéis de algún tipo de análisis a este respecto?
Saludos.
Hola Athento Starter,
ResponderEliminarAhora mismo no tenemos ningún vídeo de integración con SharePoint, nos anotamos pedirle permiso a alguno de nuestros clientes para que nos deje hacer un vídeo de la integración en funcionamiento.
Tal vez esto te pueda resultar de interés: Tutorial para hacer funcionar la aplicación móvil de Athento con SharePoint 2013. http://blog.athento.com/2013/10/trabajar-con-sharepoint-2013-y-athento-ecm.html
Con respecto al segundo punto, las integraciones y la escalabilidad, pues va a depender mucho de qué es lo que estamos hablando. Lógicamente no podemos controlar las capacidades de escalar de software third party. Si estamos hablando de la escalabilidad del repositorio documental, el cliente tiene que decidir si puede y quiere escalar el repositorio que utiliza o si prefiere que la manera de escalar sea a través del repositorio por defecto de Athento, o si quiere utilizar algún otro mecanismo.
No sé si he respondido bien a tu pregunta. Tal vez me puedas aportar más detalles sobre tu duda para poder darte una respuesta más concisa.
Muchas gracias de nuevo!!!
Sobre la aplicación móvil ya conocía algo, pero tras consultar ese post también me surgen algunas preguntas,
ResponderEliminarcomo por ejemplo, ¿qué porción de la capacidad de Athento está disponible en Athento Mobile? Me refiero a si
están disponibles las funcionalidades de procesamiento, inteligencia, etc... o sólo se trata de una conexión
al repositorio documental.
Por otro lado, con respecto a la escalabilidad, si te parece me explico un poco mejor.
Athento presume de ser un framework que, además de integrarse con repositorios documentales y bases de datos
(si no me equivoco), aporta nueva funcionalidad (imágenes, inteligencia, etc...) a estos back-ends usando su
propio front-end. Por un lado, cuando mencionáis "inteligencia", entiendo que estáis hablando de Inteligencia
Artificial, ¿cierto?. Estas capacidades, por su naturaleza, suelen implicar un procesamiento muy pesado,
y por tanto la escalabilidad es un punto muy a tener en cuenta a la hora de decidir si es una buena opción.
Investigando por el blog y la web, no consigo encontrar ningún tipo de análisis del rendimiento del producto.
Para no extenderme más, mi duda es en relación a si existen análisis del rendimiento de vuestro producto:
- Almacenamiento: Análisis de rendimiento en función de accesos, concurrencia, cantidad de datos... ¿Soporta bases de datos no
relacionales (NoSQL)? ¿Integra con bases de datos no relacionales (NoSQL)? ¿Cuáles? Rendimiento bbdd relacionales vs bbdd NoSQL
- Procesamiento: ¿Soporta clustering? ¿Existen medidas de la capacidad de procesamiento (imágenes, inteligencia artificial, etc...)
en función del número de procesadores usados? En este punto, también sería interesante conocer si se usa algún framework orientado a
distribución de cargas de trabajo, por ejemplo el más conocido, Hadoop (modelo MapReduce).
- Interoperabilidad: ¿Cuáles son los protocolos soportados de almacenamiento (S3, FTP, HTTP)?
- Comunicación: ¿Servicios soportados? (REST, JSON, XML...). ¿Capacidad de peticiones de dichos servicios?
En definitiva, medidas de rendimiento que den un poco una visión global de la capacidad y las limitaciones del producto.
Disculpa por el atraco de información :-)
Saludos
Hola de nuevo Athento Starter,
ResponderEliminarLo paso a nuestro ingeniero de documentación para que nos comente dónde tenemos las respuestas a tus preguntas.
Te voy de todas maneras adelantando algunas respuestas:
* La aplicación móvil no tiene las capacidades de Athento, es un navegador CMIS.
* Tenemos integración con otras aplicaciones móviles en las que se aplican funcionalidades más inteligentes de Athento, como la extracción de datos https://www.youtube.com/watch?v=_onuxnypQq0
* Con inteligencia no nos referimos a la aplicación de tecnologías inteligentes que ayuden a automatizar procesos. Por ejemplo, la aplicación de semántica para facilitar la navegación entre documentos que son relacionados a través de palabras relevantes de forma automática. El ejemplo concreto de semántica puedes verlo aquí como un servicio de Athento utilizado por Box.net https://www.youtube.com/watch?v=7iUCqKF_L2g o desde aquí como funcionalidad disponible desde el front-end de Athento (min 8) https://vimeo.com/89507396
También nos referimos a inteligencia cuando hablamos de la funcionalidad de Athento que permite automatizar tareas como la clasificación automática de documentos https://vimeo.com/84291694
Otra funcionalidad inteligente en la que estamos trabajando en la actualidad, es en incorporar Machine Learning a algunos procesos de la gestión documental, con el objetivo de que el sistema aprenda del comportamiento del usuario y sea capaz de hacerle sugerencias que faciliten su trabajo con documentos.
* Clusterización: Sí, la soporta. Usamos balanceradores de carga para regular la carga de trabajo de los nodos.
* Interoperabilidad y Comunicación: Conectores CMIS, SOAP, REST, Atom, EJB3,JSF. http://doc.athento.com/xwiki/bin/view/Athento+Platform/Architecture#.U1eraFcsE2Q
Tenemos también información sobre cómo definir más conectores aquí http://doc.athento.com/xwiki/bin/view/Athento+Platform/Interoperability+Service#.U1esnlcsE2Q
Como te mencioné al comienzo, remito tus preguntas al ingeniero de documentación que es quién puede responderlas mejor.
Hola de nuevo,
ResponderEliminarMuchas gracias por el vídeo.
Quedo pues a la espera de esos datos. Revisaré este post periódicamente ;-).
Saludos