Низкая производительность табличной переменной на вставке в Хранимой процедуре SQL Server
Я использовал как LingPipe, так и Stanford's POS Tagger. Последний представляет собой современный POS Tagger, но, по моему опыту, он слишком медленный (хотя они предоставляют менее точные модели, которые достаточно быстры). Конечно, это всегда зависит от того, чего вы пытаетесь достичь, и всегда будет компромисс между скоростью и точностью.
Я также однажды использовал программное обеспечение NER на основе LBJ, и, хотя оно было довольно точным, исходный код был полным беспорядком. Источник LingPipe и Stanford очень чистый и хорошо документированный.
Вы также можете взглянуть на LTAG-позвоночный . Я еще не использовал его, но из описания алгоритма и из приведенной точности он, безусловно, кажется лучше, чем альтернативы, которые у вас есть.
Надеюсь, это поможет.
4 ответа
Использовать временную таблицу. Вы увидите гораздо лучшую производительность.
Подробное объяснение причин этого выходит за рамки первоначального вопрос, однако, чтобы подвести итог:
- Табличная переменная оптимизирована для одного строка, SQL Server, т.е. предполагает 1 будет возвращена строка.
- Табличная переменная не создает статистика.
Google временная таблица Vs. табличная переменная для множества ресурсов и обсуждений. Если вам понадобится конкретная помощь, напишите мне электронное письмо или свяжитесь со мной в Twitter.
Обычно для небольших наборов данных переменная таблицы должна быть быстрее, чем временная таблица. Для больших наборов данных производительность упадет, потому что переменные таблицы не поддерживают параллелизм (см. этот пост ).
С учетом сказанного, я не испытал и не обнаружил опыта, что такой небольшой набор данных будет медленнее для табличной переменной по сравнению с временной таблицей.
Не то чтобы это имело значение, но как выглядит ваш выбор? У меня была проблема в SQL Server 2005, когда мой выбор сам по себе выполнялся относительно быстро для того, что делал мой запрос, скажем, за 5 минут, чтобы вернуть все данные по сети около 150 000 строк. Но когда я попытался вставить тот же самый выбор во временную таблицу или табличную переменную, оператор работал более часа, прежде чем я его убил. Мне еще предстоит понять, что происходит на самом деле. Я закончил тем, что добавил принудительный порядок подсказки запроса, и он начал вставляться быстрее.
Ключевым моментом в отношении временных таблиц также является то, что вы можете помещать на них индексы и т. Д., Тогда как вы не можете использовать табличные переменные.