Какая парадигма доступа к данным лучше всего подходит для масштабируемости?

Question

Microsoft предлагает очень много разных вариантов доступа к данным.Какой из них лучше всего подходит для масштабируемых приложений?

Линк

Должны ли мы использовать Linq?Это, конечно, кажется простым, но если вы знаете свой SQL, это действительно поможет.Также я слышал, что вы не можете запускать асинхронные запросы в ASP.NET с помощью Linq.Поэтому мне интересно, действительно ли это масштабируемо?Есть ли действительно большие сайты, использующие Linq (за исключением, возможно, stackoverflow).

Entity Framework

Не слушайте столько шума по поводу Entity Framework.Кажется, ближе к объектной модели, с которой я знаком.

Астория/Динамические данные

Должны ли мы предоставлять наши данные как услугу?

Я в замешательстве, и это еще до того, как я перейду к другим продуктам ORM, таким как NHibernate.Есть идеи или мудрость, что лучше?

Answer 1

Я бы порекомендовал NHibernate или Entity Framework.Для больших сайтов я бы использовал службы данных ADO.NET.Я бы не стал делать ничего серьезного с LINQ to SQL.Я думаю, что Stack Overflow может привести к некоторым интересным проблемам масштабирования, которые будут двухуровневыми, а не трехуровневыми, и у них также возникнут некоторые проблемы с рефакторингом, поскольку физические аспекты базы данных изменяются, и эти изменения распространяются по всему коду.Просто мысль.

Answer 2

Я думаю, что ADO.Net Data Services (ранее называвшаяся Astoria) призвана сыграть огромную роль.Он прекрасно вписывается в архитектуру Интернета в стиле REST.

Поскольку сеть масштабируема, я думаю, что все, что соответствует ее архитектуре, тоже масштабируемо.Кроме того, вы можете следить за службами данных SQL Server.

Answer 3

Если вы говорите о реляционных базах данных, то я голосую за инкапсуляцию всех ваших операций с данными в хранимые процедуры, независимо от того, как вы получаете к ним доступ из других слоев.

Если вы отключите весь доступ к базе данных для чтения и записи, за исключением хранимых процедур, вы сможете скрыть свою модель данных за четко определенными контрактами.Модель данных можно свободно изменять, поэтому хранимые процедуры по-прежнему учитывают свои входные и выходные данные.

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

Answer 4

В наши дни блокировка хранимых процедур, похоже, уходит в прошлое, по крайней мере, таковы мои текущие наблюдения.Такой образ мышления действительно подходит для мира ORM, поскольку они, как правило, более эффективны при непосредственном взаимодействии с таблицами, но любой достойный ORM также позволяет использовать процедуры — иногда у вас нет выбора.

Существует множество мнений по поводу EF, и независимо от того, что кто-то говорит, хорошо это или плохо, это продукт V1, и с учетом эмпирического правила, согласно которому MS требуется около 3 оборотов, чтобы добиться правильного результата, возможно, было бы разумно дождаться следующей версии. наименее.

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

Answer 5

Используйте то, что работает для вас.Все это проще всего настроить, если у вас уже есть достаточно нормализованная база данных (т. е. хорошее определение первичных и внешних ключей).Однако если у вас есть данные, которые нелегко нормализовать, Entity Framework является более гибким, чем LINQ to SQL, но для его настройки потребуется больше работы.

Answer 6

Мы экспериментировали с LINQ в кластерной среде, и, похоже, он хорошо масштабируется как на отдельных машинах, так и в масштабе кластера.Из трех предложенных вами вариантов я бы сказал, что LINQ — лучший выбор, хотя каждый вариант имеет немного разную целевую аудиторию, поэтому вам следует определить, что вы будете делать с данными, прежде чем принимать решение о парадигме доступа.

Answer 7

Я бы предложил linq.Он хорошо масштабируется на нашем сайте и достаточно прост в использовании.

Answer 8

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

Answer 9

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

Когда речь заходит о масштабируемости данных и масштабируемости обработки транзакций, в 2017 году нам нужно будет поговорить об облаке и поставщиках облачных услуг.

Я думаю, что в тройку крупнейших облачных провайдеров на сегодняшний день входят:

• Веб-сервисы Amazon (AWS)
• Облачная платформа Google (GCP)
• Microsoft Azure

Расходы

Одна из замечательных особенностей использования облачных сервисов заключается в том, что отсутствуют авансовые платежи и плата за прекращение действия, и вы платите только за то, что используете.(Цитируя статью г-на Альбы 2016 года "Параллельное сравнение AWS, Google Cloud и Azure")

Мы сами используем AWS.Мы платим только тогда, когда у нас установлены и работают виртуальные машины, поэтому это может быть дешевый способ запуска.Обычно поставщики услуг взимают поминутную или почасовую оплату, но вы гарантированно получите ее на все это время.

Более дешевый способ – это спотовое ценообразование с учетом максимальных усилий.Спотовая цена представляет собой цену, выше которой вы должны предложить цену, чтобы гарантировать выполнение одного спотового запроса.Когда ваша цена предложения превышает спотовую цену, Amazon EC2 запускает ваш спотовый инстанс, а когда спотовая цена поднимается выше вашей цены предложения, Amazon EC2 прекращает работу вашего спотового инстанса.(Беззастенчивое цитирование Руководства пользователя Amazon. здесь)

Параллельное сравнение AWS, Google Cloud и Azure это хорошая статья, в которой проводится параллельное сравнение этих трех доступных поставщиков услуг. здесь.

Более академический взгляд на облачные сервисы можно найти в статье Ю, Вана, Рена и Лу за 2010 год.Обеспечение безопасного, масштабируемого и детального контроля доступа к данным в облачных вычислениях" в материалах INFOCOM 2010 доступны здесь, но вам может потребоваться быть членом IEEE, чтобы получить к нему доступ.Хотя он несколько устаревший, он превосходен, и вы можете использовать его как отправную точку.

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

Я прошу прощения за то, что этот ответ представляет собой просто набор ссылок для получения дополнительной информации, но я думал, что ответ на этот вопрос должен быть обновлен.Надеюсь, это вдохновит кого-нибудь рассказать больше подробностей из первых рук.Если вы уже публиковали соответствующую информацию, рассмотрите возможность предоставления ссылок на ваши собственные публикации.Спасибо!