Какая парадигма доступа к данным является наилучшей для масштабируемости?
Microsoft предлагает множество различных вариантов доступа к данным. Какой из них лучше всего подходит для масштабируемых приложений?
Linq
Стоит ли использовать Linq? Это, конечно, кажется простым, но если вы знаете, что ваш SQL действительно помогает. Также я слышал, что вы не можете запускать асинхронные запросы в ASP.NET с помощью Linq. Поэтому мне интересно, действительно ли это масштабируемое? Есть ли действительно большие сайты, использующие Linq (за возможным исключением stackoverflow).
Entity Framework
Не слышите так много болтовни о Entity Framework. Кажется, ближе к знакомой мне объектной модели.
Astoria / Динамические данные
Должны ли мы раскрывать наши данные как услугу?
Я очень запутался, и это до того, как я перейду к другим продуктам ORM, таким как NHibernate. Какие идеи или мудрость лучше?
Ответы 9
Я думаю, что ADO.Net Data Services (ранее называвшаяся Astoria) призвана сыграть огромную роль. Он прекрасно вписывается в архитектуру Интернета в стиле REST.
Поскольку сеть масштабируется, я думаю, что все, что следует ее архитектуре, тоже масштабируется. Кроме того, вы можете следить за службами данных SQL Server.
Кто-нибудь уже использовал ADO.Net Data Services для большого приложения?
Сервисы данных ADO.Net только что были выпущены. Я больше делал упор на ОТДЫХ.
Да, уже существует ряд крупных сайтов служб данных ADO.NET. Некоторые люди начали работать в бета-версии на раннем этапе. Он выпущен сейчас. Я бы сосредоточился на Entity Framework и ADO.NET Data Services. Избегайте Linq 2 SQL.
Используйте то, что вам подходит. Все это проще всего настроить, если у вас уже есть достаточно нормализованная база данных (т. Е. Хорошее определение первичных и внешних ключей). Однако, если у вас есть данные, которые нелегко нормализовать, Entity Framework более гибкая, чем LINQ to SQL, но для ее настройки требуется больше работы.
Мы экспериментировали с LINQ в кластерной среде, и, похоже, он хорошо масштабируется на отдельных машинах и в кластере. Из 3 вариантов, которые вы предоставили, я бы сказал, что LINQ - лучший выбор, хотя каждый вариант имеет немного разную целевую аудиторию, поэтому вы должны определить, что вы будете делать с данными, прежде чем выбирать парадигму доступа.
Приятно знать, что вы успешно использовали его в кластерной среде. У вас есть приблизительная статистика по пропускной способности транзакций?
Если вы говорите о реляционных базах данных, то я голосую за инкапсуляцию всех ваших операций с данными в хранимых процедурах, независимо от того, как вы получаете к ним доступ из других уровней.
Если вы отключите доступ для чтения и записи к базе данных, кроме хранимых процедур, вы можете скрыть свою модель данных за четко определенными контрактами. Модель данных можно изменять, так что хранимые процедуры по-прежнему учитывают свои входные и выходные данные.
Это дает администраторам баз данных полную свободу настраивать ваше приложение и масштабировать его. Это очень и очень сложная задача, когда SQL создается инструментом вне базы данных.
Привет, Эрик, спасибо за ваш вклад. Я думаю, что само собой разумеется, что использование хранимых процедур - хороший способ оптимизировать производительность запросов. насколько я знаю, вы можете использовать хранимые процедуры с Linq
Вы можете, купить это как бы понизить опыт Linq To Sql.
Я бы предложил linq. Он хорошо масштабируется на нашем сайте и достаточно прост в использовании.
используйте хранимые процедуры с LINQ ... но не позволяйте sprocs превратиться в уровень доступа к данным!
Я бы порекомендовал либо NHibernate, либо Entity Framework. Для больших сайтов я бы использовал службы данных ADO.NET. Я бы не стал делать ничего большого с LINQ to SQL. Я думаю, что Stack Overflow может закончиться некоторыми интересными проблемами масштабирования, которые будут двухуровневыми, а не трехуровневыми, и у них также будут некоторые проблемы с рефакторингом, поскольку физические аспекты изменения базы данных и эти изменения будут отражаться во всем коде. Просто мысль.
Я думаю, вы правы насчет Linq. Это кажется удобным, но не корпоративным решением. Я действительно не хочу, чтобы моя объектная модель была слишком тесно связана с моей БД. Спасибо, я изучу другие варианты.
Леом, я думаю, вы используете слово Linq как синоним Linq to SQL. Linq - это широкий термин, сахар синтаксиса выражения поверх любого типа коллекции / object / xml /*.*
Хорошо, и помните, что LINQ to SQL - это LINQ to SQL СЕРВЕР
Кажется, что в наши дни привязка к хранимым процедурам становится все менее актуальной, по крайней мере, таковы мои текущие наблюдения. Такой способ мышления действительно подходит для мира ORM, поскольку они, как правило, более эффективны, обращаясь напрямую к таблицам, но любой стоящий ORM также допускает использование процедур - иногда у вас нет выбора.
Существует множество мнений по поводу EF, и независимо от того, что кто-то говорит, хорошее или плохое, это продукт V1, и с практическим правилом, что MS требуется около 3 оборотов, чтобы сделать все правильно, может быть разумно дождаться следующего обновления на наименее.
Похоже, что крупнейшим игроком в этой области является NHibernate, и это широко поддерживается сообществом. Linq, языковая функция, не должна быть слишком далека от того, чтобы попасть в стек NHibernate.
Этот пост написан в 2008 году, когда облако действительно не стало популярным. Похоже, требуется обновление ответа. Я просто предоставлю несколько ссылок и обзор. Я уверен, что на этом сайте есть более свежие сообщения по этой теме, и если я найду их, то добавлю сюда ссылки.
Когда дело доходит до масштабируемости данных и масштабируемости обработки транзакций, в 2017 году нужно говорить о облачных сервисах и поставщиках облачных услуг.
Я думаю, что на сегодняшний день в тройку лучших поставщиков облачных услуг входят:
Расходы
Одним из преимуществ использования облачных сервисов является то, что нет никаких авансовых затрат, нет платы за завершение, и вы платите только за то, что используете. (Цитата из статьи г-на Альбы "Параллельное сравнение AWS, Google Cloud и Azure" 2016 г.)
Мы сами пользуемся AWS. Мы платим только тогда, когда у нас установлены и работают виртуальные машины, так что это может быть дешевым способом запуска. Обычно поставщики услуг взимают поминутную или почасовую оплату, но вы гарантированно будете получать ее на все это время.
Более дешевый способ - это спотовое ценообразование. Спотовая цена представляет собой цену, выше которой вы должны сделать ставку, чтобы гарантировать выполнение одного спотового запроса. Когда ваша цена предложения превышает спотовую цену, Amazon EC2 запускает ваш спотовый инстанс, а когда спотовая цена превышает вашу цену предложения, Amazon EC2 завершает работу вашего спотового инстанса. (Бесстыдно цитируя Руководство пользователя Amazon здесь)
Параллельное сравнение AWS, Google Cloud и Azure - хорошая статья, в которой проводится параллельное сравнение этих трех доступных поставщиков услуг здесь.
Чтобы получить более академический взгляд на облачные сервисы, прочитайте статью Ю, Вана, Рена и Лу за 2010 год "Обеспечение безопасного, масштабируемого и детального контроля доступа к данным в облачных вычислениях " в материалах INFOCOM 2010 Proceedings, доступных здесь, но вам может потребоваться быть членом IEEE, чтобы получить к нему доступ. несколько устаревший, он отличный, и вы можете использовать его как отправную точку.
Масштабирование в облаке стремительно растет, и до недавнего времени это масштабирование осуществлялось путем запуска новых виртуальных машин, на что требовалось несколько секунд, но с помощью контейнеров можно запускать новые экземпляры за миллисекунды. Для получения дополнительной информации по этому поводу ознакомьтесь с Docker и Docker Containers здесь.
Прошу прощения за то, что этот ответ представляет собой просто набор ссылок для получения дополнительной информации, но я подумал, что ответ на этот вопрос должен быть обновлен. Я надеюсь, что это вдохновит кого-нибудь предоставить больше информации из первых рук. Если вы уже разместили некоторую связанную информацию, рассмотрите возможность предоставления ссылок на свои собственные сообщения. Спасибо!
Вы можете изменить заголовок своего вопроса, указав масштабируемость, то есть «Какая парадигма масштабируемого доступа к данным является наилучшей?» Я нажал на это, думая, что иду в неминуемую войну пламени!