Oliver Bleckmann Ответов: 5

Опрос-SQL Server самый медленный выбор?

Мне часто приходится импортировать данные из нескольких источников, включая текстовые и XML-файлы. Иногда я спрашиваю себя, почему SQL-сервер настолько медленный? В настоящее время команда SQL bulkcopy останавливает мое приложение через несколько секунд (примерно 600 наборов данных из 15000! 11 МБ csv файла), а загрузка, анализ и преобразование данных в набор данных занимает так мало времени, что вы даже не можете уведомление. Единственное узкое место - это команда sql bulkcopy. Раздражает! Конечно, базы данных XML не заменяют реляционные базы данных, которые также имеют определенные преимущества. От серверов SQL нельзя отказаться - подумайте о концепции транзакции, стандартизированном синтаксисе запросов, хранимых процедурах и других расширенных / специализированных функциях. Но, учитывая производительность ненастроенного / оптимизированного SQL Server по сравнению с чтением csv-файла, мне кажется, это плохая шутка. В локальной файловой системе базы данных XML работают намного лучше, несмотря на огромные накладные расходы на синтаксис XML. Использование простых текстовых файлов, доступ к которым осуществляется через SAN, превосходит любое решение БД по скорости реакции, скорости и размеру транзакций, а также по общему использованию памяти с течением времени (мой опыт и я говорю о глупом и некэшированном решении).

Поэтому мой вопрос к вам будет заключаться в том, что вы скажете по этому вопросу, какие альтернативы вы используете (Apache Derby, Berkeley, in-memory and XML, IBM DB2 pureXML и т. д.) и проводил ли кто-нибудь когда-нибудь какой-нибудь тест на эту тему. Существует ли там база данных .net с полной поддержкой Entity-Framework?

О'Кей, ребята,я рад услышать вас и начать работу...

5 Ответов

Рейтинг:
32

Mehdi Gholam

Попробуй RaptorDB-хранилище документов[^]

Рейтинг:
1

Pete O'Hanlon

Проблема, как правило, не в том, что SQL Server является плохим выбором для массовых вставок, проблема на самом деле заключается в необходимости перебалансировать индексы после каждой вставки записи. Чем больше индексов у вас есть, тем больше работы должен выполнить компонент database engine, чтобы справиться с этим. Распространенным решением этой проблемы является удаление индексов, массовая загрузка данных, а затем повторное применение индексов - повторное создание индексов намного быстрее.

Эта проблема связана не только с SQL Server, просто массовая загрузка в любую из больших индексированных баз данных имеет тот же эффект.

Oliver Bleckmann

Ну, как я уже сказал, "не настроенный / оптимизированный SQL-сервер" означает, что здесь не задействован индекс БД, и ни текстовые файлы не кэшируются, ни не выгружаются, не фрагментируются и не сортируются заранее!

Рейтинг:
1

Wendelius

Я думаю, что вы слишком рано прекратили расследование этой проблемы. Как заметил Пит, есть факторы, которые влияют на общую производительность. Один из них-индексация, конечно, сеть может вызвать задержку, преобразование типов данных (особенно неявное) и так далее.

Поэтому я бы не советовал менять продукт, пока вы не копнете глубже и не выясните первопричину. Кроме того, вместо использования массового копирования производительность может быть (а может и не быть) лучше, если вместо этого вы используете определение типа. Для этого взгляните на СОЗДАТЬ ТИП[^] или для примера Как передать несколько записей в хранимую процедуру[^]

Рейтинг:
0

Oliver Bleckmann

Ну, я сделал некоторые улучшения в своем коде, и вуаля, процедура bulkcopy (без изменений!) работает быстрее, чем когда-либо (около 6 секунд для 11 Мб данных в 15000 строк)! Вывод: обновите свой код bevore жалуясь ;-)
Серьезно, это не изменило моего мнения. Производительность SQL низкая, поэтому вставка занимает 6 секунд, но загрузка и анализ csv-файла вообще не занимает много времени.

1. Использование OleDb над ODBC любить: 

// cahnage 
OdbcConnection, OdbcCommand, OdbcDataReader 
// to -> 
OleDbConnection, OleDbCommand, OleDbDataReader 
// and so on...

2. Использование ACE над Jet для 64-битной поддержки-установите из распространяемого файла, если это необходимо, найдите AccessDatabaseEngine_X64 для 64 битной версии
3. и выберите правильную соединительную строку, например: 
// not this connection string is for csv files, a schema.ini may be needed for correct results
@"Provider=Microsoft.ACE.OLEDB.12.0;Data Source="   CsvDirectory.Trim()   @";Extended Properties=""text;HDR=yes;FMT=Delimited""

// These are depricated and for use with odbc/ jet
"Driver={Microsoft Text Driver (*.txt; *.csv)};Dbq="   CsvDirectory.Trim()   ";Extensions=asc,csv,tab,txt;Persist Security Info=False";
// or
"Driver={Microsoft Access Text Driver (*.txt, *.csv)};Extensions=asc,csv,tab,txt;Persist Security Info=False;Dbq="   CsvDirectory.Trim()


3. Теперь мы можем взять его в архитектуру x64
4. я чувствую, что что-то забыл...

Pete O'Hanlon

Почему вы не используете SqlConnection, SqlCommand и SqlDataReader? Они намного быстрее, чем более общие типы команд/соединений. Кроме того, почему бы вам не использовать SqlBulkCopy? http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlbulkcopy.aspx.

Oliver Bleckmann

Ну, поправьте меня, если я ошибаюсь, но SqlConnection предназначен только для соединений с SQL Server, так что в моем случае нет никакой возможности подключить csv или текстовый файл. Предоставьте мне строку подключения для csv, и я попробую. И да, возможно, вы правы, но в других местах я действительно использую SqlConnection...

Pete O'Hanlon

Мое извинение. Часть 1 вашего списка здесь выглядела так, как будто вы использовали их для соединений с SQL Server. Хотя, честно говоря, большинство людей не стали бы пытаться массово загружать данные в SQL Server подобным образом - SQL Server предоставляет процедуры массового копирования, которые вам было бы лучше использовать.

Рейтинг:
0

Oliver Bleckmann

Четыре года спустя, зная некоторые другие решения, я могу сказать, что некоторые из действительно огромных компаний в конечном итоге написали свою собственную стратегию хранения данных в соответствии с их потребностями. Вот откуда взялись такие решения, как HBase, BigTable и т. д. Компании, как правило, становятся гибридными или нереляционными. Последнее не означает, что концепция транзакции не задействована или не может быть использована для критических данных. Разнообразие баз данных действительно пугает,и никакой консолидации не видно. Во времена Интернета вещей и BigData выбор зависит скорее от существующей инфраструктуры, чем от особенностей или соображений производительности. О, МОЙ БОГ...