Sql Server XML столбцы заменить БД документов?

Question

Можно ли использовать XML-столбцы Sql Server в качестве замены реальной БД документов (например, Couch или Mongo)?

Если бы мне нужно было создать таблицу с идентификатором PK guid и столбцом XMLдля документа.Какие основные проблемы по сравнению с использованием БД документов?

Sql Server поддерживает индексирование по столбцам XML, поэтому запросы не должны быть совершенно ужасными?

Answer 1

У вас есть несколько вопросов здесь:

Можно ли использовать XML-столбцы Sql Server вместо реальной БД документов (например, Couch или Mongo)? Да, вы можете использовать его как замену, но нет, вы, вероятно, не будете удовлетворены производительностью, если вы храните исключительно XML и не используете какой-либо из реляционных инструментов SQL Server.создать таблицу с идентификатором PK guid и столбцом XML для документа.Каковы основные проблемы по сравнению с использованием БД для документов? В двух словах, масштабирование.SQL Server плохо масштабирует подобные вещи.Вы можете сделать это с репликацией, но управлять по отношению к «реальной» БД документов очень сложно.

Sql Server поддерживает индексирование по столбцам XML, поэтому запросы не должны быть совершенно ужасными? Проблемазаключается в том, что XML-индексы SQL Server могут в несколько раз занимать пространство хранения исходных данных.Эти индексы нельзя поддерживать в оперативном режиме (как в дефрагментации), поэтому у вас возникают проблемы с блокировкой во время окон обслуживания.

Answer 2

Я экспериментирую с этим на: http://rogeralsing.com/2011/03/02/linq-to-sqlxml-projections/

Скорость запроса «приличная», я ничего не буду использовать для масштабирования. Но радость от свободного хранилища схемы, работающего на стандартной инфраструктуре, довольно приятна.

Answer 3

Да, вы можете.Хранение документа в столбце XML SqlServer будет работать, и если вы используете стандартную сериализацию XML, то у вас останется приличное хранилище ключей / значений для ACID.Кроме того, это позволит вам делать запросы относительно легко и присоединять результаты к данным, которые вы храните, более реляционным способом.Мы делаем это, это работает.Если вы храните контент в полях XML, требования к хранилищу намного ниже, чем при использовании NTEXT, и запрос к нему будет более гибким и быстрым.

То, что SqlServer не получит (по сравнению с mongo), - это плавное переключение наборов реплик и автоматическое удаление mongo.Кроме того, атомарные операции, такие как приращение определенного свойства глубоко внутри документа, являются сложными (хотя и не невозможными с помощью функции обновления XQuery).Обновления, как правило, быстрее в большинстве баз данных NoSql, поскольку они более расслаблены по принципу «данные безопасны только на диске».

Answer 4

Да, это возможно.Что касается того, хорошая ли это идея, это всего лишь мои 2 цента ...

До того, как появился тип данных XML, я работал над системой хранения XML в столбце NTEXT - это было неприятно, и чтобы получитьлюбое реальное использование данных означало измельчение некоторых из этих данных в реляционную форму.

OK, тип данных XML теперь упрощает запрос к BLOB-объекту и извлечение определенных значений / индексацию их.Но лично я вообще бы не стал.Я не говорю, что никогда не используйте XML, так как для этого есть сценарии - скорее, если это все, что вы планируете делать, то я подумаю, «это правильный инструмент для работы».Использование СУБД в качестве базы данных документов заставляет меня чувствовать себя немного неловко.Принимая во внимание, что что-то вроде MongoDB изначально создавалось как база данных документов.

Честно говоря, я не проводил никаких тестов производительности при хранении данных в формате XML, поэтому я не могу дать вам представление о том, чтопроизводительность будет как.Было бы интересно узнать, как это работает в масштабе.