Чем лучше заменить EF Core для высоких нагрузок?

Хочу сделать свой крупный проект максимально быстрым.Что посоветуете для этого?Понятно, что скорей всего придётся отказаться от EF Core в пользу другого инструмента, но какого именно?Ваши обоснованные мнения.Спасибо!

0

sergeyilyin1984, можно Dapper использовать .

0

sergeyilyin1984, ничем. EF хорошая и удобная ОРМ. Не вижу смысла заменять ее на какието обрезки ради пары лишних наносекунд на DAL слое

Хотите быстродействия - используйте кеширование

0

Хочешь скорости - бери железо помощнее. Если проект крупный, то лучше брать в аренду сервер. Принцип такой, ты можешь потратить месяц на оптимизацию алгоритмов, подбор БД и прочую муть, а можешь переплатить 50 долларов в месяц и получить сервер в 2 раза производительнее. Ну, алгоритмы тоже надо пересматиривать в сторону уменьшения времени обработки запросов, но лучше это делать в спокойной обстановке, когда все уже работает. Тогда воно будет работать еще быстрее

Добавлено через 15 минут
Да, и чтобы там ни писали на хабрах - самая стабильная и безгеморройная работа связки "приложение + БД" - это Core + SQL Server.

Пробовал работать с MongoDb. БД работает шустрее, миграции автоматические, вообще понравилось: это плюс. Из минусов: траблы с Identity - много руками надо делать.
При разворачивании приложения трудно найти хост-провайдера, где помимо стандартного SQL Server на хостинге можно прикрутить MongoDb. На арендованном сервере можно, но тогда теряется смысл перехода. Мощность сервера такая-же как и на тарифах обычного хостинга, а платишь в 5-10 раз больше.

0

Сообщение от yurickas Хочешь скорости - бери железо помощнее

Я с этим согласен. Хочу только добавить, что некоторые делают такую муть, что никакое железо не затащит. Мой опыт работы (конечно же это субъктивно) показыват, что оснавная проблема низкой производительности - низкая квалификация.

0

Работаю с PostgreSql.Постгрэсники советуют везде пехать хранимые процедуры или вообще работать с Redis.Решил использовать метод FromSql() + кэширование в памяти.Как считаете?

0

Сообщение от sergeyilyin1984 Решил использовать метод FromSql() + кэширование в памяти.Как считаете?

Зачем?) Зачем эти извращения если вы начали мыслить в правильную сторону по поводу кеширования.

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

0

То есть, при использовании кеша, в методе FromSql() нет смысла?

0

Сообщение от sergeyilyin1984 в методе FromSql() нет смысла?

Только если у вас есть сторед процедуры, но тут уже нужно смотреть по ситуации на сколько вообще профитно использовать процедуру, а не выполнить просчет средствами .net,

0

Спасибо!Пока остановлюсь на кеше, а потом, если этого не хватит, то все нагруженные места перенесу в хранимки.

0

можно на чистый адо.нет перейти

0

Сообщение от sergeyilyin1984 Постгрэсники советуют везде пехать хранимые процедуры или вообще работать с Redis.

И не просто так советуют, Postgresql не считается быстрой СУБД. К примеру:

Why is retrieving data from Elasticsearch so much faster than from PostgreSQL?

ElasticSearch с поиском объектов очень даже неплохо справляется.

Usecases : Ecommerce websites use elasticsearch to index their entire product catalog and inventory with all the product attributes with which the end user can search against. So whenever a user search for a product in the website, the corresponding query will hit an index which has millions of products and it will retrieve the product in near real time.

0

А что SQL Server быстрее?Я бы его использовал, но ограниченный бесплатный лимит мне не подходит.

0

sergeyilyin1984, у Entity Framework (что у 6-го, что у Core) есть два фатальных недостатка, которые никто не собирается исправлять: "разогрев" и невозможность тонкой настройки запросов. А у 6-го ещё и не самые вменяемые (иногда вообще невменяемые запросы).

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

Опускаться до уровня хранимых процедур тоже не рекомендую без полной уверенности в том, что это необходимо. Поддерживать тонны хранимых процедур - дело неблагодарное. Их код переиспользовать сложно. Сложно и отлаживать. Ну и если встанет вопрос миграции, то тут тоже могут быть проблемы. Тоже самое и с голым SQL.

Я рекомендую для начала убедиться, что EF Core вам не подходит и уже потом смотреть на что-то более лёгкое.

Как вариант, вполне себе отличной заменой EF'у является Linq2Db. Там нет change tracker'а, нет многих удобств EF'а, но оно сильно ближе к SQL'у, не пытается из себя строить Domain Model, позволяет даже (хоть и ограниченно) использовать Query Hints. При этом, оно всё равно строит за вас запросы, поддерживает все современные СУБД, и с помощью этой ORM очень сложно будет написать дерьмовый запрос.

0

А что насчёт вышеперечисленных советов в плане кеширования в памяти и наращивания "железа", а также dapper, а?Ваше мнение?

0

sergeyilyin1984, кеширование и мощное железо идёт параллельно выбору правильной ORM и особенно с этим вопросом не связано.

Dapper - простой мапер. Для работы с голым SQL. Насчёт SQL я выше уже озвучил своё мнение: нужно только тогда, когда иначе уже никак. Т.е. необходимость перехода на низкоуровневое общение с СУБД нужно ещё доказать.

0

Помню, как-то вы писали, что от EF стоит отказаться, если у меня в базе более 50 сущностей. Так вот, их точно не больше и больше не предвидится.Но точно будет ооочень высокая посещаемость в секунду времени.Планируются тысячи и миллионы зарегистрированных пользователей, которые будут пользоваться услугами приложения.Особенно много будет находиться в чате и общаться в реальном времени.Что скажете насчёт производительности EF при таких делах?

Добавлено через 23 минуты
Usaga, И ещё, есть какие-нибудь бенчмарки на сравнение производительности linq2db и EF Core?Насколько первый быстрее второго?

0

sergeyilyin1984, бенчмарков нет, ибо в них нет смысла. ORM - только треть того, что влияет на производительность запроса. Остальные две трети - схема базы и то, как программист распоряжается этой ORM. Легко и непринуждённо можно написать запрос на голом SQL, который будет работать хуже, чем даже на EF6.

Судя по описанию, у вас ни разу не информационная система или ERP или что-то в этом духе. А значит недостатки EF'а могут и не проявиться (долгий запуск приложения, в следствии "разогрева" - когда много сущностей в контексте, и отсутствие некоторых полезных "низкоуровневых" вещей типа Merge, Batch Update\Delete, Query Hints).

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

Если сомневаетесь, то просто возьмите Linq2Db и всё.

0

Usaga, Спасибо!

0