Производительность SQL Server с таблицей ключей / пар в сравнении с полями XML и XPath

Question

Я уже видел несколько вопросов по этой теме, но мне нужно немного узнать о различиях в производительности между этими двумя методами.

Например, допустим, я записываю журнал событий, которые поступят в систему со словарным набором пар ключ / значение для конкретного события. Я запишу запись в таблице событий с базовыми данными, но затем мне нужен способ также связать дополнительные данные ключ / значение. Я никогда не узнаю, какие типы ключей или значений появятся, поэтому о какой-либо предопределенной таблице enum не может быть и речи.

Данные этого события будут постоянно передаваться, поэтому время вставки так же важно, как и время запроса.

Когда я запрашиваю определенные события, я буду использовать некоторые поля в событии, а также данные из ключа / значения. Для XML-способа я бы просто использовал оператор Attributes.exists ('xpath') как часть предложения where для фильтрации записей.

Нормализованным способом было бы использование таблицы с полями Key и Value с внешней ссылкой на запись Event. Это кажется простым и понятным, но я беспокоюсь о количестве задействованных данных.

Answer 1

У вас есть три основных варианта «гибкого» механизма хранения.

• Поля XML являются гибкими, но помещают вас в область хранения больших двоичных объектов, что делает запрос медленным. Я видел, как запросы к маленьким наборам данных из 30000 строк занимали 5 минут, когда он копал вещи из BLOB-объектов с помощью запросов Xpath. На данный момент это самый медленный вариант, но он гибкий.

• Пары ключ / значение намного быстрее, особенно если вы добавили кластерный индекс в ключ события. Это означает, что все атрибуты для одного события будут физически храниться вместе в базе данных, что минимизирует количество операций ввода-вывода. Подход менее гибок, чем XML, но существенно быстрее. Наиболее эффективные запросы для отчета по ним будут включать в себя поворот данных (то есть сканирование таблицы для получения промежуточного сглаженного результата); объединение для получения отдельных полей будет намного медленнее.

• Самый быстрый подход состоит в том, чтобы иметь плоскую таблицу с набором пользовательских полей (Field1 - Field50) и содержать некоторые метаданные о содержимом полей. Это самый быстрый для вставки и самый быстрый и простой для запроса, но содержимое таблицы непрозрачно для всего, что не имеет доступа к метаданным.

Answer 2

Я думаю, что проблема с таблицей ключ / значение связана с типами данных - если значением может быть дата-время, или строка, или строка в Юникоде, или целое число, как вы определяете столбец? Эта дилемма означает, что столбец значений должен быть типом данных, который может содержать в себе все типы данных, что ставит вопрос об эффективности / простоте запросов. Кроме того, у вас есть несколько столбцов определенных типов данных, но я думаю, что это немного неуклюже.

Для настоящей гибкой схемы я не могу придумать лучшего варианта, чем XML. Вы можете индексировать столбцы XML.

В этой статье, посвященной MSDN , более подробно рассматривается хранение XML.

Answer 3

Я бы предположил, что нормализованный способ будет быстрее для операций INSERT и SELECT, хотя бы потому, что для этого будет оптимизирована любая СУБД.Часть «количество вовлеченных данных» также может быть проблемой, но более разрешимой - как долго вам нужны эти данные сразу под рукой, можете ли вы заархивировать их через день, пару недель или 3 месяца и т. Д.?SQL Server может обрабатывать очень много.

Эти данные события будут постоянно передаваться, поэтому время вставки так же важно, как и время запроса.

Вариант 3: Если вына самом деле большое количество данных постоянно передается в потоковом режиме - создайте отдельную очередь в разделяемой памяти, в незавершенном sqlite, в отдельной таблице БД или даже на собственном сервере, чтобы хранить входящие необработанные события и атрибуты, и иметь другой процесс (запланированная задача, окнаслужба и т. д.) разбирать эту очередь в любом предпочтительном формате, настроенном для быстрого SELECT.Оптимальный ввод, оптимальный вывод, готовность к масштабированию в любом направлении, все довольны.