Являются ли наборы данных масштабируемыми? Будет ли сайт, как MySpace, использовать их для поиска данных?

Question

Насколько масштабируемы наборы данных? Член команды хочет использовать наборы данных для извлечения и обработки данных, использовать встроенную целостность данных и т. Д., Чтобы использовать объект для обновления данных и т. Д.

Наша система рассчитана на миллионы пользователей.

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

Answer 1

Отказ от ответственности - это мои мнения, взятые из личного опыта

Наборы данных настолько болезненны для использования, что я бы ДЕЙСТВИТЕЛЬНО не рекомендовал их использовать, если у вас нет к ним особой необходимости. Я работал над большими проектами эпохи .NET 1.0 (с тысячами наборов данных) и считаю, что их трудно поддерживать, использовать и тестировать . Вы должны получить доступ ко всему с использованием синтаксиса на основе массива, если только вы не используете строго типизированные наборы данных, которые вы будете тратить навсегда на поддержание.

Я бы действительно рекомендовал использовать ORM, например NHibernate . Вы можете узнать больше о NHibernate с помощью этих скриншотов .

Если вас интересует продаваемая архитектура, вам следует посетить веб-сайт High Scalability , где вы сможете найти MySpace Architecture , который вы упомянули в своем вопросе.

Для более объективного мнения о наборе данных, пожалуйста, проверьте эту ссылку MSDN (резюме ниже)

Когда использовать который

Как DataSets, так и пользовательские классы не ограничить то, что вы можете сделать любым способом, и оба могут быть использованы для достижения те же цели. Тем не менее, DataSets фантастические инструменты для прототипирования приложения и представляют отличные решения для построения систем в вид чрезвычайной ситуации - ограниченный бюджет, приближается срок или короткий срок службы приложения. Для относительно простые приложения, пользовательские объекты добавить возможно ненужный уровень сложность. В этом случае я предлагаю что вы серьезно думаете об использовании DataSets.

В хозяйстве большой, прочный, сложная система предприятия, которая принимает несколько месяцев до завершения, стоимость архитектуры и реализации куча коллекций классов относительно минимален и понесен только однажды. Преимущества с точки зрения производительность, выразительность, удобочитаемость и простота обслуживания в основном погасить инвестиции. Вы не привязан к табличной визуализации данные. Деловые правила и обычай хозяйствующие субъекты не всегда могут быть адаптирован, чтобы выглядеть как коллекция столы. В общем, вам следует избегать адаптация данных к данным контейнер - совсем наоборот, я бы сказал. Наконец, использование пользовательских классов делает для облегчения модульного тестирования, потому что классы и логика более строго связанных чем с DataSets. На рисунке 3 , вы найдете синоптическую таблицу с DataSets, типизированные DataSets и пользовательские сущности сравниваются по нескольким факторам.

Answer 2

DataSets тяжелые. Они предлагают гораздо больше, чем просто в памяти данных. У них есть отслеживание изменений, представления, отношения и т. Д. Если вы используете эти функции - тогда они, вероятно, лучше, чем то, что вы придете сами.

Когда люди сталкиваются с проблемами, они используют DataSets как своего рода HashTable, а затем жалуются, что они медленнее, чем DataReader. Ну, да - если вы можете обойтись только с помощью DataReader, то DataSet - это просто излишество - вы выполняете на 90% больше кода, чем вам нужно.

Итак, реальный вопрос, который вы должны себе задать, - мне нужен DataReader или DataSet? Если вам нужна функциональность DataSet, то вам, вероятно, следует обернуть абстракцию вокруг нее и начать с нее. Вы можете оптимизировать позже, если вам нужно (и независимо от того, что вы делаете, вам, вероятно, понадобится оптимизировать, когда вы выполните некоторое нагрузочное тестирование).

Редактировать: я просто хочу отметить, что я имею в виду масштабируемость проблем здесь - пожалуйста, не читайте, что я фанат дизайна API DataSet, типизированного кода DataSet и т. д. - нет.

Answer 3

Да, вы не правы в корпоративной части вашего вопроса - они приемлемы в корпоративной среде. Проблема обычно заключается в знании разработчиками DataSet и ошибочной идее о том, что вы сможете написать свой собственный, более эффективный механизм. Вот и все, прежде чем вы начнете воссоздавать общие функции, такие как фильтрация коллекций объектов, механизмы единиц работы и т. Д.

Это другой вопрос, чем масштабирование для миллионов пользователей. Вполне вероятно, что вы хотите обрезать любой жир, что требует от вас настройки всей логики данных. Идти POCO, вероятно, не правильное направление. С POCO вы по-прежнему отображаете структуры без поддержки базы данных в базу данных на отдельном уровне, добавляя дополнительную логику, которая при масштабировании до высокого уровня начинает показывать износ вашей производительности.

Вам нужно будет предоставить более конкретный набор вопросов, чтобы получить лучший ответ, но «предприятие» не обязательно равно «миллионам пользователей». POCO, DataSets и т. Д. Обеспечивают быструю разработку (независимо от неподдерживаемого мнения cgreeno), а также удобство обслуживания из-за «упрощения» POCO модели, используемой в приложении, и широкого распространения и понимания DataSet (среди большинства разработчиков). Но чтобы поддержать миллионы пользователей, вы, вероятно, пожертвуете удобством обслуживания для элементов дизайна производительности и масштабируемости. Вам просто нужно принять решение, какие "-способности" являются более важными.

Кстати, типизированные наборы данных - это наборы данных. Сказать, что типизированные наборы данных быстрее, чем нетипизированные, это все равно, что сказать, что я могу работать быстро, но с этим тегом имени я могу работать быстрее. Будьте внимательны при расследовании неподтвержденных утверждений о каком-либо конкретном инструменте и запросите доказательства.

Answer 4

Для чтения данных, DataSets просто отлично. Они должны быть только немного медленнее, чем пользовательские объекты, хотя, конечно, вам нужны тесты производительности для проверки этого.

Для записи данных вам действительно нужно что-то более эффективное. Динамический SQL, который обновляет только изменяемые столбцы или очень специфичные хранимые процедуры, даст вам гораздо лучшие результаты.

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

Answer 5

Слишком много переменных, чтобы отвечать требованиям производительности любым полезным способом (для начала общее количество пользователей - бесполезная мера; пиковые запросы в секунду были бы лучшим началом).

Я бы избегал наборов данных, если вам не нужна их способность многократно манипулировать данными в памяти. Если вам нужно один раз пройти через данные, используйте DataReader и избегайте хранения всего в памяти.

(ORM - другой вариант, конечно.)

Answer 6

Помимо производительности, я бы не стал использовать их для обслуживания. Я предпочитаю использовать объекты POCO и ORM.

Использование наборов данных, вероятно, не защитит вас от клеветы, но есть более быстрые альтернативы. Например, чтение с устройства чтения данных в POCO.

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

Ваша среда должна имитировать ваше конечное состояние (если вы собираетесь создать ферму с выделенным блоком sql, не запускайте тесты на одном сервере, который является web и sql)