Производительность SQL Server с Ключевой/Парной Таблицей по сравнению с Полем XML и XPath
Я уже видел несколько вопросов по этой теме, но я ищу некоторое понимание на различиях в производительности между этими двумя методами.
Например, позволяет, говорят, что я записываю журнал событий, которые войдут в систему с коллекцией словарей пар ключ/значение для определенного события. Я запишу запись в таблице Events с базовыми данными, но затем мне нужен способ также связать дополнительные данные ключа/значения. Я никогда не буду знать, какие виды Ключей или Значений войдут так, любой вид предопределенной перечислимой таблицы кажется вне рассмотрения.
Эти данные о событии будут постоянно передавать потоком в, так вставьте времена, так же важно как времена запроса.
Когда я запрошу для определенных событий, я буду использовать некоторые поля на Событии, а также данных из данных ключа/значения. Для пути XML я просто использовал бы оператор Attributes.exists('xpath') в качестве части где пункт для фильтрации записей.
Нормализованный путь состоял бы в том, чтобы использовать Таблицу с в основном полями Key и Value с внешней ссылкой на запись События. Это кажется чистым и простым, но я волнуюсь об объеме данных, который включен.
3 ответа
Проблема, я думаю, что подход таблицы ключ / значение касается типов данных - может ли значение быть datetime, или строкой, или строкой Unicode, или целое число, тогда как вы определяете столбец? Эта дилемма означает, что столбец значений должен быть типом данных, который может содержать все различные типы данных, что затем вызывает вопрос об эффективности / простоте запросов. В качестве альтернативы у вас есть несколько столбцов с определенными типами данных, но я думаю, что это немного неуклюже.
Для действительно гибкой схемы я не могу придумать лучшего варианта, чем XML. Вы можете индексировать столбцы XML.
В этой статье из MSDN хранилище XML обсуждается более подробно.
У вас есть три основных варианта «гибкого» механизма хранения.
Поля XML являются гибкими, но помещают вас в сферу хранилища BLOB-объектов, которое медленно запрашивает. Я видел, как запросы к небольшим наборам данных из 30 000 строк занимали 5 минут, когда он извлекал информацию из больших двоичных объектов с помощью запросов Xpath. Это самый медленный вариант, но он гибкий.
Пары ключ / значение работают намного быстрее, особенно если вы поместите кластерный индекс на ключ события. Это означает, что все атрибуты для одного события будут физически храниться вместе в базе данных, что минимизирует ввод-вывод. Этот подход менее гибкий, чем XML, но значительно быстрее. Наиболее эффективные запросы для составления отчетов включают в себя поворот данных (то есть сканирование таблицы для получения промежуточного сглаженного результата); объединение для получения отдельных полей будет намного медленнее.
Самый быстрый подход - иметь плоскую таблицу с набором определяемых пользователем полей (Поле1 - Поле50) и хранить некоторые метаданные о содержимом полей. Это самый быстрый способ вставки, самый быстрый и простой для запроса, но содержимое таблицы непрозрачно для всего, что не имеет доступа к метаданным.
Используйте следующее:
REPLACE(myString, char(0), '')
В Oracle
WITH
START_DATE AS
(
SELECT TO_CHAR(TO_DATE('JANUARY 5 2010','MONTH DD YYYY'),'J')
JULIAN FROM DUAL
),
END_DATE AS
(
SELECT TO_CHAR(TO_DATE('JANUARY 30 2010','MONTH DD YYYY'),'J')
JULIAN FROM DUAL
),
DAYS AS
(
SELECT END_DATE.JULIAN - START_DATE.JULIAN DIFF
FROM START_DATE, END_DATE
)
SELECT TO_CHAR(TO_DATE(N + START_DATE.JULIAN, 'J'), 'MONTH DD YYYY')
DESIRED_DATES
FROM
START_DATE,
(
SELECT LEVEL N
FROM DUAL, DAYS
CONNECT BY LEVEL < DAYS.DIFF
)
я бы предположил, что нормализованный способ будет быстрее для операций INSERT и SELECT, хотя бы потому, что любая RDBMS будет оптимизирована. Часть «Объем задействованных данных» тоже может быть проблемой, но более разрешимой - как долго вам нужны эти данные сразу на руках, можете ли вы архивировать их через день, пару недель или 3 месяца и т.д.? SQL Server может справиться с большим количеством проблем.
Данные этого события будут постоянно передаваться в потоковом режиме, поэтому время вставки не менее важно, чем время запроса.
Вариант 3: Если у вас действительно есть много данных, постоянно передаваемых в потоковом режиме - создайте отдельную очередь в общей памяти, внутрипроцессном sqlite, отдельной таблице БД или даже на собственном сервере, чтобы сохранить входящее необработанное событие и атрибуты, а другой процесс (запланированная задача, служба Windows и т. д.) проанализируйте эту очередь в любом предпочтительном формате, настроенном для быстрых SMTP. Оптимальный ввод, оптимальный вывод, готовность к масштабированию в любом направлении, все довольны.