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

Question

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

Linq

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

Entity Framework

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

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

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

Я довольно запутался, и это все, прежде чем я попал в другие продукты ORM, такие как NHibernate. Какие идеи или мудрость на что лучше?

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

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

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

• Amazon Web Services (AWS)
• Облачная платформа Google (GCP)
• Microsoft Azure

Стоимость

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

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

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

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

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

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

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