sql-server - SQL ServerのXML列はドキュメントDBの代わりになりますか？

Question

実際のドキュメントDB（CouchやMongoなど）の代わりにSQL Server XML列を使用することは可能ですか？

guidPKIdとドキュメントのXML列を含むテーブルを作成する場合。ドキュメントDBを使用する場合と比較して、主な問題は何でしょうか。

SQL ServerはXML列のインデックス作成をサポートしているので、クエリは完全にひどいものではありませんか？

Answer 1

ここにはいくつかの質問があります:

実際のドキュメント DB (Couch や Mongo など) の代わりに Sql Server XML 列を使用することはできますか? はい、代用として使用できますが、いいえ、XML のみを格納し、SQL Server のリレーショナル ツールをまったく利用しない場合、おそらくパフォーマンスに満足できないでしょう。

guid PK ID とドキュメントの XML 列を含むテーブルを作成するとします。ドキュメント DB を使用する場合と比較して、主な問題点は何ですか? 一言で言えば、スケールアウト。SQL Server は、この種のものをうまくスケールアウトしません。レプリケーションでそれを行うことはできますが、「実際の」ドキュメント DB と比較して管理するのは面倒です。

Sql Server は XML 列のインデックス作成をサポートしているので、クエリは完全に恐ろしいものではありませんか? 問題は、SQL Server の XML インデックスが元のデータの数倍のストレージ スペースを必要とすることです。これらのインデックスは (デフラグのように) オンラインで維持できないため、メンテナンス期間中にロックの問題が発生します。

Answer 2

私はこれをいくつか実験しています: http://rogeralsing.com/2011/03/02/linq-to-sqlxml-projections/

クエリ速度は 'まとも' です。スケーリングに使用するものではありません。しかし、標準インフラストラクチャで実行されるスキーマ フリー ストレージの利点は非常に優れています。

Answer 3

はい、できます。SqlServer XML 列内にドキュメントを格納することは機能し、標準の XML シリアル化を使用すると、適切な ACID 準拠のキー/値ストアが得られます。また、比較的簡単にクエリを実行でき、よりリレーショナルな方法で保存するデータに結果を結合できます。私たちはそうします、それはうまくいきます。コンテンツを XML フィールドに格納すると、NTEXT を使用する場合よりもストレージの需要がはるかに少なくなり、クエリがより柔軟かつ高速になります。

SqlServer では (mongo と比較して) 得られないのは、レプリカ セットのシームレスなフェールオーバーと mongo の自動シャーディングです。また、ドキュメントの奥深くで特定のプロパティをインクリメントするようなアトミック操作は困難です (ただし、XQuery の update 関数では不可能ではありません)。ほとんどの NoSql データベースでは、更新が高速になる傾向があります。これは、「データはディスク上でのみ安全である」という原則がより緩和されているためです。

Answer 4

はい、可能です。それが良いアイデアかどうかについては、これは私の 2 セントです...

XML データ型が登場する前は、XML を NTEXT 列に格納するシステムに取り組んでいましたが、これは快適ではありませんでした。データを実際に使用するには、そのデータの一部をリレーショナル形式に細分化する必要がありました。

OK、XML データ型により、XML BLOB のクエリと、特定の値の抽出/インデックス付けが簡単になりました。しかし、個人的には、一般的に、私はそうしません。シナリオがあるので、決して XML を使用しないと言っているわけではありません。むしろ、それがあなたの計画のすべてである場合は、「これは仕事に適したツールか」と考えるでしょう。RDBMS を文書データベースとして使用すると、少し不安になります。一方、MongoDB のようなものは、ドキュメント データベースとしてゼロから構築されています。

正直なところ、データを XML として格納するパフォーマンス テストを行っていないため、パフォーマンスがどのようなものになるかを示すことはできません。これが大規模にどのように機能するかを知りたいです。