Nano Hash - криптовалюты, майнинг, программирование

Загрузка нескольких больших ADO.NET DataTables/DataReaders — повышение производительности

Мне нужно загрузить несколько операторов SQL из SQL Server в DataTables. Большинство операторов возвращают от 10 000 до 100 000 записей, и загрузка каждого из них занимает до нескольких секунд. Я предполагаю, что это просто из-за количества данных, которые нужно перебрасывать. Обработка самих заявлений не занимает много времени.

Поэтому я попытался использовать Parallel.For() для параллельной загрузки данных, надеясь, что общее время обработки уменьшится. Я получаю увеличение производительности на 10%, но этого недостаточно. Причина может заключаться в том, что моя машина только двухъядерная, что ограничивает преимущество здесь. При этом сервер, на котором будет развернута программа, имеет 16 ядер.

Мой вопрос в том, как я могу улучшить производительность больше? Будет ли использование асинхронных запросов службы данных лучшим решением (BeginExecute и т. д.), чем PLINQ? Или, может быть, какой-то другой подход?

Сервер SQl работает на том же компьютере. Это также относится к серверу развертывания.

РЕДАКТИРОВАТЬ: я провел несколько тестов с использованием DataReader вместо DataTable. Это уже уменьшило время загрузки примерно на 50%. Здорово! Тем не менее мне интересно, улучшит ли параллельная обработка с BeginExecute общее время загрузки, если используется многопроцессорная машина. У кого-нибудь есть опыт в этом? Спасибо за любую помощь в этом!

ОБНОВЛЕНИЕ: я обнаружил, что около половины времени загрузки уходит на обработку инструкции sql. В SQL Server Management Studio операторы занимали лишь часть времени, но почему-то в ADO.NET они занимают гораздо больше времени. Таким образом, используя DataReaders вместо загрузки DataTables и адаптации операторов sql, я сократил примерно 25% первоначального времени загрузки. Загрузка DataReaders в параллельных потоках с помощью Parallel.For() здесь не дает улучшения. Так что пока я доволен результатом и на этом останавливаюсь. Возможно, когда мы обновимся до .NET 4.5, я попробую асинхронную загрузку DataReader.

c# sql-server vb.net ado.net
23.11.2012

  • пожалуйста, покажите исходный код... 23.11.2012
  • всегда есть хороший шанс, что загрузка 1000 записей является признаком плохого дизайна ... (если вы, например, не делаете это для кэширования) 23.11.2012
  • И опишите свой вариант использования... насколько своевременными должны быть данные? Какие варианты кэширования у вас есть? Можете ли вы ограничить элементы, которые вам нужно загрузить, уменьшив сетевой трафик? Можете ли вы оптимизировать базу данных на стороне сервера, чтобы облегчить выполнение запроса? 23.11.2012
  • Пишу поисковик. Я уже кэширую самые большие результаты, но на самом деле это не решает проблему, поскольку пользователи могут искать что угодно. В основном данные должны быть возвращены как можно скорее, так как пользователь ждет результатов поиска. 23.11.2012

Ответы:


1

Я предполагаю, что это просто из-за количества данных, которые нужно перебрасывать.

Нет, это связано с использованием SLOW framework. Я извлекаю почти миллион строк в словарь менее чем за 5 секунд в одном из своих приложений. Таблицы данных работают МЕДЛЕННО.

23.11.2012
  • Загрузка их в словарь была бы для меня вполне уместной. Я все равно не использую DataTables для дополнительной обработки. Было бы здорово, если бы был другой способ загрузить их! 23.11.2012
  • Ну так и делай. Я использую BlToolkit как легкий ORM и загружаю их в словарь. DataTables — это самый медленный способ работы с данными. Поместите данные в объекты, загрузите их. 24.11.2012
  • Спасибо за совет! Я просмотрел исходный код BIToolkit, и он использует сам DataReader для загрузки данных в словари или списки. Мои запросы могут занять немного больше времени, чем ваши, так как я читаю много столбцов со строковыми данными. Вероятно, я пока не стану быстрее, чем использовать DataReader. Или, может быть, еще, если я загружаю несколько DataReaders параллельно. Но это хорошо поддерживается только в .NET 4.5. Я все еще на .NET 4. 24.11.2012
  • Однако BlToolkit будет намного быстрее в ПРОГРАММИРОВАНИИ - и это деньги, прямо и напрямую (меньше потраченных часов). ВОТ почему используются ORM - НИЧТО в .NET в конце НЕ использует DataReader. 24.11.2012

    • 2

    Вы должны изменить характер проблемы. Давайте будем честными, кому нужно просматривать от 10 000 до 100 000 записей за один запрос? Я думаю никто.

    Вам нужно подумать об обработке пейджинга, и в вашем случае пейджинг должен выполняться на сервере sql. Чтобы было понятно, предположим, что у вас есть хранимая процедура с именем «GetRecords». Измените эту хранимую процедуру, чтобы она принимала параметр страницы и возвращала только данные, относящиеся к конкретной странице (скажем, только 100 записей) и общее количество страниц. Внутри приложения просто покажите эти 100 записей (они будут летать) и обработайте выбранный индекс страницы.

    Надеюсь, это поможет, с уважением!

    23.11.2012
  • -1. Есть несколько веских причин для извлечения более 10 000 строк на запрос, особенно при дальнейшей обработке. Я регулярно обрабатываю наборы данных с несколькими миллионами строк. Это действительно зависит от приложения. 24.11.2012
  • TomTom Я не могу согласиться с вашей концепцией. Загрузка 10-100 тыс. строк в запросе страницы asp просто убивает производительность. Разве мы не поговорим об этом прямо сейчас!? Кроме того, операции с данными гораздо более эффективны на стороне сервера sql, чем внутри приложения .net. 24.11.2012
  • Я много обрабатываю запросы, и конечный результат действительно выгружается. Я сделал все возможные оптимизации на стороне sql, но в исходной таблице 10 миллионов записей. Да, я мог бы переписать все это на T-SQL. Но какая это была бы боль. Другим решением было бы выполнить всю обработку в SQL Server CLR (загрузить сборку в базу данных). Тем не менее, это будет серьезный редизайн, которого я хочу избежать. 24.11.2012
  • @GregorPrimar Ну, возможно, на странице ASP.NET, но я пишу программное обеспечение, которое обрабатывает миллионы строк в сетке. Когда вы визуализируете данные за 3 года по 5 секунд для быстрой горизонтальной прокрутки — да, это много строк. Начните делать на нем математический анализ, чтобы выписать результаты и — да, мы говорим о гигабайтах данных. 24.11.2012

    • 3

    Вам часто приходится загружать эти запросы? Если да, то почему бы не использовать распределенный кеш?

    23.11.2012
  • Я уже кэширую самые большие результаты, но на самом деле это не решает проблему, поскольку пользователи могут искать что угодно. 23.11.2012
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..