Разработка приложений, ориентированных на работу с большими объемами данных

@hex.style · Регистрация: 03.05.2012

Студворк — интернет-сервис помощи студентам

Всем доброго времени суток!
На днях столкнулся с весьма тривиальной, но, как оказалось, достаточно сложной проблемой. Все дело в выборе архитектуры для работы с большими массивами информации, а также применении технологий .net

Ситуация.
На предприятии имеется система, полная багов и ошибок с низкой возможностью кастомизации. Требования бизнеса постоянно меняются, на нее пишутся очередные надстройки. В итоге она превратилась в мегамонстра. Объемы информации там внушительные. Таблица может иметь 40 млн. записей (и это далеко не предел).

Требования.
Необходимо создать универсальный интерфейс для быстрого доступа к данным этой системы, размещенным на MS SQL Server 2008. При этом пользователь хочет работать сразу со всеми данными (отображать, фильтровать и сортировать большие объемы данных при сложных запросах).
В дальнейшем планируется внести также возможность редактирования. Так что это тоже надо учитывать.

Проблема.
В оперативной памяти такие объемы не уместить, пользователю 40 гигов тоже не загрузишь. Следовательно, логику сортировки, фильтрации и выборки информации приходится перенести на сервер.
Мое решение заключается в том, чтобы выдавать пользователю только часть информации. Так называемый Lazy Load. Но то, как его совместить с ADO.NET для меня остается загадкой.
Пользовательский комп просто виснет, когда я строю у него в оперативке DataSet.

ВОПРОСЫ

1. Есть ли в .net механизмы, обеспечивающие виртуализацию работы с большими объемами информации? У меня выдает timeout при ожидании отклика на моих объемах и перегружается оперативка.

2. Как в ADO.NET включить механизм кэширования на жесткий диск (http://msdn.microsoft.com/ru-r... 436.aspx)?

3. Как передать информацию не скопом, получив готовый запрос (40 гигов), а по мере его получения из SQL Server?

4. Можно ли создавать локальный кэш запросов? Что-то вроде закэшированной view =)

5. Итак, вопрос на миллион: что лучше выбрать двухзвенную или трехзвенную архитектуру (кто лучше справится с задачей выбора сотни значений из многомиллионной таблицы: дисковый кэш данных или проиндексированные view SQL SERVER)?

Буду рад, если кто-нибудь поделится опытом разработки приложений, ориентированных на работу с большими объемами данных на .net
Не хотелось бы изобретать велосипед.

@t1m0n · 03.05.2012, 18:30

может разбить базу на несколько? на хабре что-то было по этой теме

@hex.style · 03.05.2012, 21:18 **[ТС]**

В смысле "разбить базу"? Не очень понимаю (она находится в кластере).

Даже если представить (чисто гипотетически), что я буду читать 2... ну 3 или даже 5 потоков с различных баз пусть даже по 5 гигабайт каждый, производительности заметно не прибавится, а решение красивым не назовешь, ибо придется писать на эти потоки обработчики. Тогда зачем нужны приблуды .net, когда подобное лучше реализовать на C++?

Разбивать таблицы, используя merged table, тоже смысла нет, так как пользователь хочет работать со всей информацией сразу.

В голову приходят дикие извращения:
- создать обработчик, который каждый час будет актуализировать большие запросы на выборку в отдельную таблицу, а еще лучше в таблицу базы данных MySQL (MYISAM-таблицы);
- выделить эти объекты в отдельные адаптеры xsd-схемы;
- написать им процедуры insert, update, delete из MSSQL, а при выборке подставлять connection к MySQL (позволяет ли .net проделывать подобные извращения???);

C#
1
2
3
4
5
6
7
orderSQL = "SELECT TOP " + pageSize + 
  " * FROM Orders WHERE OrderID > " + lastRecord + " ORDER BY OrderID";
adapter.SelectCommand.CommandText = orderSQL;
 
dataSet.Tables["Orders"].Rows.Clear();
 
adapter.Fill(dataSet, "Orders");

- потом каким-то макаром увязать виртуализацию списков по варианту (http://bea.stollnitz.com/blog/?p=378) и формирование DataSet'а по DataAdapter. По мне это самое сложное в моем примитивном решении. Про это можно поговорить отдельно.

Ну если совсем уже уходить в говнокод, то можно с данными из MySQL работать каким-нибудь php-скриптом в купе с xmlhttprequest. Будет просто летать. Ну и тогда применение .net с его "главным компонентом" ADO.NET будет скорее лишним звеном, чем инструментом, поддерживающим бизнес-требования.

В общем, то, как это можно реализовать через .net, для меня видится громоздким и нелепым. Хотелось бы поддержать свою веру в данную платформу и найти какие-то суперские приблуды, которые позволят реализовать Lazy Load на фоне сложных запросов без использования костылей.

p.s. очень жду ответа хотя бы на 1 из вопросов =)

@m0nax · 04.05.2012, 01:29

Таблица может иметь 40 млн. записей (и это далеко не предел).
...
При этом пользователь хочет работать сразу со всеми данными (отображать, фильтровать и сортировать большие объемы данных при сложных запросах)

Мне кажется что-то тут не так, у пользователя точно пупок не развяжется просматривать 40млн записей?
Серьезно, зачем кому-то такое кол-во данных?
Ни один человек не просмотрит осознанно даже 10к записей, а если достаточно меньшего кол-ва может и прописать в запросах тупо ограничение "select TOP(1000)" и все счастливы?

@hex.style · 04.05.2012, 12:16 **[ТС]**

Что самое интересное - не развяжется. Конечно, они физически не просмотрят все данные. Но так как у них косяк на косяке в отчетности, они в режиме random access хотят искать те места, где у них "не те значения". При этом им нужно анализировать и просматривать все значения в таблице.
А это значит сортировки, группировки и выбор по маске. И да OLAP бы с ними. Но значения впоследствии необходимо будет править.
Если бы они дали сформулированные требования, по которым можно было бы отслеживать косяки и т.д. Но они сами порой не знают, что у них творится... или же это творится по вине несостоявшейся системы. В общем, алгоритм подавления информационного шума они выявляют сами. И эти алгоритмы каждый раз новые. Хоть SQL их обучай.
Но это к теме относится косвенно. Главные вопросы темы (.net и big data или, как ее переименовали, "разработка приложений, ориентированных на работу с большими объемами данных") остаются открытыми.

@nio · 04.05.2012, 14:04

Сообщение от hex.style

разработка приложений, ориентированных на работу с большими объемами данных

использование кубов

@hex.style · 05.05.2012, 17:27 **[ТС]**

nio, рассматривал возможность использования OLAP (ADOMD.NET и Analysis Services). Но ситуация такая, что нужен визуальный редактор для миллионов записей. Просмотр, анализ и редактирование. Ясно, что в оперативку такое не загрузишь. Нужен механизм кэширования и быстрого доступа к данным. Для этого и нужен Lazy Load.

Понял, что подобное разработчиками .NET не предусмотрено. Нашел интересные библиотеки:
http://nitrosbase.com
http://www.compilesoft.ru/news... l#20100915

Пошел разбираться.

@nio · 06.05.2012, 00:05

Не по теме:

Сообщение от hex.style

визуальный редактор для миллионов записей

это нереальные требования, ни один пользователь не будет с этим работать.
Математику не обманешь просмотр 1 млн записей со скоростью 1000 шт в мин. займет 16 часов (2 рабочих дня). При этом 1000 шт/мин это тупое скролирование не поддающееся анализу, про редактирование я молчу.
Наблюдая пользователей при работе со своей программой максимум, что я видел создание 3 записей в минуту, в среднем 1-2, это при том, что 3/4 данных заполняется автоматически. Итак при 3 записях в минуту для 1 млн строк получается больше 200 суток непрерывной работы или 2 года рабочего времени

также следует учитывать размер выбираемых данных. Ну к примеру три столбца Varchar(50) займут 150 байт, для 1 млн записей получаем 150 МБ. В реальной ситуации столбцов могут быть десятки. Такое не каждая сеть выдержит, а учитывая, что выбранные данные оседают в ОЗУ, то и не каждый комп.

Покажите эти цифры своему заказчику и сделайте совместные выводы :)

@FreedomHex · 08.05.2012, 12:41

Используйте OLAP куб. Средствами ADO его можно обрабатывать. SQL Server 2008 позволяет его строить. Там существует понятия среза на дату.... Он как раз и предназначен для работы с большими объемами информации. Ну в общих чертах как то так... а дальше гугл))))

Новые блоги и статьи Все статьи Все блоги /
Загрузка PNG с альфа-каналом на SDL3 для Android: с помощью SDL3_image 8Observer8 27.01.2026 Содержание блога SDL3_image - это библиотека для загрузки и работы с изображениями. Эта пошаговая инструкция покажет, как загрузить и вывести на экран смартфона картинку с альфа-каналом, то есть с. . .	влияние грибов на сукцессию anaschu 26.01.2026 Бифуркационные изменения массы гриба происходят тогда, когда мы уменьшаем массу компоста в 10 раз, а скорость прироста биомассы уменьшаем в три раза. Скорость прироста биомассы может уменьшаться за. . .	Воспроизведение звукового файла с помощью SDL3_mixer при касании экрана Android 8Observer8 26.01.2026 Содержание блога SDL3_mixer - это библиотека я для воспроизведения аудио. В отличие от инструкции по добавлению текста код по проигрыванию звука уже содержится в шаблоне примера. Нужно только. . .	Установка Android SDK, NDK, JDK, CMake и т.д. 8Observer8 25.01.2026 Содержание блога Перейдите по ссылке: https:/ / developer. android. com/ studio и в самом низу страницы кликните по архиву "commandlinetools-win-xxxxxx_latest. zip" Извлеките архив и вы увидите. . .
Вывод текста со шрифтом TTF на Android с помощью библиотеки SDL3_ttf 8Observer8 25.01.2026 Содержание блога Если у вас не установлены Android SDK, NDK, JDK, и т. д. то сделайте это по следующей инструкции: Установка Android SDK, NDK, JDK, CMake и т. д. Сборка примера Скачайте. . .	Использование SDL3-callbacks вместо функции main() на Android, Desktop и WebAssembly 8Observer8 24.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .	моя боль iceja 24.01.2026 Выложила интерполяцию кубическими сплайнами www. iceja. net REST сервисы временно не работают, только через Web. Написала за 56 рабочих часов этот сайт с нуля. При помощи perplexity. ai PRO , при. . .	Модель сукцессии микоризы anaschu 24.01.2026 Решили писать научную статью с неким РОманом

@hex.style 0 / 0 / 0 Регистрация: 03.05.2012 Сообщений: 10

	Разработка приложений, ориентированных на работу с большими объемами данных 03.05.2012, 16:35. Показов 4963. Ответов 8 Метки нет (Все метки) Всем доброго времени суток! На днях столкнулся с весьма тривиальной, но, как оказалось, достаточно сложной проблемой. Все дело в выборе архитектуры для работы с большими массивами информации, а также применении технологий .net Ситуация. На предприятии имеется система, полная багов и ошибок с низкой возможностью кастомизации. Требования бизнеса постоянно меняются, на нее пишутся очередные надстройки. В итоге она превратилась в мегамонстра. Объемы информации там внушительные. Таблица может иметь 40 млн. записей (и это далеко не предел). Требования. Необходимо создать универсальный интерфейс для быстрого доступа к данным этой системы, размещенным на MS SQL Server 2008. При этом пользователь хочет работать сразу со всеми данными (отображать, фильтровать и сортировать большие объемы данных при сложных запросах). В дальнейшем планируется внести также возможность редактирования. Так что это тоже надо учитывать. Проблема. В оперативной памяти такие объемы не уместить, пользователю 40 гигов тоже не загрузишь. Следовательно, логику сортировки, фильтрации и выборки информации приходится перенести на сервер. Мое решение заключается в том, чтобы выдавать пользователю только часть информации. Так называемый Lazy Load. Но то, как его совместить с ADO.NET для меня остается загадкой. Пользовательский комп просто виснет, когда я строю у него в оперативке DataSet. ВОПРОСЫ 1. Есть ли в .net механизмы, обеспечивающие виртуализацию работы с большими объемами информации? У меня выдает timeout при ожидании отклика на моих объемах и перегружается оперативка. 2. Как в ADO.NET включить механизм кэширования на жесткий диск (http://msdn.microsoft.com/ru-r... 436.aspx)? 3. Как передать информацию не скопом, получив готовый запрос (40 гигов), а по мере его получения из SQL Server? 4. Можно ли создавать локальный кэш запросов? Что-то вроде закэшированной view =) 5. Итак, вопрос на миллион: что лучше выбрать двухзвенную или трехзвенную архитектуру (кто лучше справится с задачей выбора сотни значений из многомиллионной таблицы: дисковый кэш данных или проиндексированные view SQL SERVER)? Буду рад, если кто-нибудь поделится опытом разработки приложений, ориентированных на работу с большими объемами данных на .net Не хотелось бы изобретать велосипед. 0

@t1m0n 638 / 416 / 27 Регистрация: 03.11.2009 Сообщений: 1,855
	03.05.2012, 18:30
	может разбить базу на несколько? на хабре что-то было по этой теме 0

@hex.style 0 / 0 / 0 Регистрация: 03.05.2012 Сообщений: 10
	04.05.2012, 12:16 [ТС]
	Что самое интересное - не развяжется. Конечно, они физически не просмотрят все данные. Но так как у них косяк на косяке в отчетности, они в режиме random access хотят искать те места, где у них "не те значения". При этом им нужно анализировать и просматривать все значения в таблице. А это значит сортировки, группировки и выбор по маске. И да OLAP бы с ними. Но значения впоследствии необходимо будет править. Если бы они дали сформулированные требования, по которым можно было бы отслеживать косяки и т.д. Но они сами порой не знают, что у них творится... или же это творится по вине несостоявшейся системы. В общем, алгоритм подавления информационного шума они выявляют сами. И эти алгоритмы каждый раз новые. Хоть SQL их обучай. Но это к теме относится косвенно. Главные вопросы темы (.net и big data или, как ее переименовали, "разработка приложений, ориентированных на работу с большими объемами данных") остаются открытыми. 0

@hex.style 0 / 0 / 0 Регистрация: 03.05.2012 Сообщений: 10
	05.05.2012, 17:27 [ТС]
	nio, рассматривал возможность использования OLAP (ADOMD.NET и Analysis Services). Но ситуация такая, что нужен визуальный редактор для миллионов записей. Просмотр, анализ и редактирование. Ясно, что в оперативку такое не загрузишь. Нужен механизм кэширования и быстрого доступа к данным. Для этого и нужен Lazy Load. Понял, что подобное разработчиками .NET не предусмотрено. Нашел интересные библиотеки: http://nitrosbase.com http://www.compilesoft.ru/news... l#20100915 Пошел разбираться. 0

@FreedomHex 43 / 44 / 12 Регистрация: 01.09.2011 Сообщений: 213
	08.05.2012, 12:41
	Используйте OLAP куб. Средствами ADO его можно обрабатывать. SQL Server 2008 позволяет его строить. Там существует понятия среза на дату.... Он как раз и предназначен для работы с большими объемами информации. Ну в общих чертах как то так... а дальше гугл)))) 0

Разработка приложений, ориентированных на работу с большими объемами данных

Решение