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

@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 позволяет его строить. Там существует понятия среза на дату.... Он как раз и предназначен для работы с большими объемами информации. Ну в общих чертах как то так... а дальше гугл))))

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

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

	Разработка приложений, ориентированных на работу с большими объемами данных 03.05.2012, 16:35. Показов 4983. Ответов 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

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

Решение