¿Es posible utilizar columnas Sql Server XML como sustituto de un Document DB real (como Couch o Mongo)?Sql Server ¿Las columnas XML sustituyen Document DB?
Si tuviera que crear una tabla con un ID PK de guía y una columna XML para el documento. ¿Cuáles serían los principales problemas en comparación con el uso de un documento DB?
El servidor Sql admite la indexación en columnas XML, por lo que las consultas no deberían ser completamente horribles.
que estoy haciendo un poco de experimentación con este artículo en: http://rogeralsing.com/2011/03/02/linq-to-sqlxml-projections/
velocidad de consulta es 'decente', no es nada que haría uso de la escala. Pero la alegría del almacenamiento gratuito de esquemas que se ejecuta en la infraestructura estándar es bastante agradable.
"esquema de almacenamiento gratuito que se ejecuta en la infraestructura estándar" - Estoy 100% de acuerdo. Para proyectos pequeños que no necesitan la escala masiva, creo que esto es una mejor solución de compromiso y reduce la complejidad del sistema, si ya tiene sql en su lugar. –
Sí, es posible. En cuanto a si es una buena idea, estos son solo mis 2 centavos ...
Antes de que apareciera el tipo de datos XML trabajé en un sistema que almacenaba XML en una columna NTEXT, eso no era agradable, y para obtener cualquier real utilizar fuera de los datos significaba triturar algunos de esos datos en forma relacional.
OK, el tipo de datos XML ahora hace que sea más fácil consultar un blob XML y extraer ciertos valores/indexarlos. Pero personalmente, en general, no lo haría. No digo que nunca utilices XML, ya que hay escenarios para eso, más bien, si eso es lo que planeas hacer, entonces estaría pensando "¿es esta la herramienta adecuada para el trabajo?". Usar un RDBMS como base de datos de documentos me hace sentir un poco incómodo. Mientras que algo como MongoDB se ha construido desde cero como una base de datos de documentos.
Honestamente, no he hecho ninguna prueba de rendimiento en el almacenamiento de datos como XML, así que no puedo darle una indicación de cómo sería el rendimiento. Estaría interesado en saber cómo funciona a escala.
Sí, puedes. El almacenamiento de un documento dentro de una columna SqlServer XML funcionará y si utiliza la serialización XML estándar que lo dejará con una clave compilada ACID decente/almacén de valores. Además, le permitirá realizar consultas con relativa facilidad y puede unir los resultados a los datos que almacena de una manera más relacional. Nosotros lo hacemos, funciona. Si almacena contenido en campos XML, las demandas de almacenamiento son mucho menores que con NTEXT y las consultas serán más flexibles y rápidas.
Lo que SqlServer no le conseguirá (en comparación con mongo) es la conmutación por error sin fisuras de los conjuntos de réplicas y el autosharding de mongo. Además, las operaciones atómicas como el incremento de una propiedad específica en el interior de un documento son difíciles (aunque no imposibles con la función de actualización de XQuery). Las actualizaciones tienden a ser más rápidas en la mayoría de las bases de datos NoSql, porque son más relajadas con el principio de "los datos son seguros solo en el disco".
que tienes varias preguntas en aquí:
¿Es posible utilizar columnas XML de SQL Server como un sustituto de un verdadero documento DB (como el sofá o el Mongo)? Sí, puede usarlo como sustituto, pero no, probablemente no estaría satisfecho con el rendimiento si almacena exclusivamente XML y no utiliza ninguna de las herramientas relacionales de SQL Server.
Si tuviera que crear una tabla con un ID PK de guía y una columna XML para el documento. ¿Cuáles serían los principales problemas en comparación con el uso de un documento DB? En pocas palabras, escalar. SQL Server no escala este tipo de cosas bien. Puede hacerlo con la replicación, pero es doloroso administrarlo en relación con un Documento DB "real".
Sql Server admite la indexación en columnas XML, por lo que las consultas no deberían ser completamente horribles. El problema es que los índices XML de SQL Server pueden ocupar varias veces el espacio de almacenamiento de los datos originales. Estos índices no se pueden mantener en línea (como en defrags), por lo que termina con problemas de bloqueo durante las ventanas de mantenimiento.
Gracias por la respuesta detallada. Actualmente estoy probando el concepto en un marco pequeño: de Linq a Sql Xml -> http://rogeralsing.com/2011/02/28/linq-to-sqlxml/ –
De nada, ¡me alegro de haber podido ayudar! –
Hola Brent, ¿puedes dar más detalles sobre la última frase? "Estos índices no se pueden mantener en línea (como en defrags), por lo que terminas con problemas de bloqueo durante las ventanas de mantenimiento". –
¡Muy buena pregunta! He estado utilizando columnas SQL XML como una solución NoSql para personas de escasos recursos durante bastante tiempo y funciona bien. Estuve muy tentado de probar mongo, pero agregar una infraestructura adicional no debe tomarse a la ligera (estrategia de respaldo, actualización de la base de datos, actualización de controladores ...) –