Судя по всему, я буду одним из докладчиков на следующей харьковской UNETA, которая ориентировочно будет в начале-середине января. Тема у меня будет не совсем обычная, она будет связана с производительностью ORM. Точно будут L2S и EF, возможно, добавлю что-то еще, если хватит времени. Так как тема не связана с какой-то конкретной технологией, скорее, это разбор и сравнение, то я могу немного варьировать ее содержание. В связи с этим у меня возник вопрос, что бы вам хотелось услышать? В принципе, скелет доклада я уже продумал, но все равно есть место для различных деталей, тестов, которые я могу провести и т.д. Я постараюсь учесть все пожелания и осветить их в докладе по-максимуму.
В докладе я постараюсь рассказать о том, как работают рассматриваемые ORM внутри, что именно влияет на их производительность, проведу некоторые наиболее интересные и показательные тесты для их сравнения между собой и с чистым ADO.NET, и постараюсь рассмотреть генерируемые каждой ORM запросы.
Итак, у меня есть несколько вопросов к вам:
- Стоит ли включать в доклад NHibernate? Или достаточно будет L2S и EF?
- Какие тесты вы бы хотели увидеть?
- Какие сопутствующие темы вам были бы интересны? Что из неописанного выше можно осветить еще?
Ответы прошу оставлять в комментариях. Прошу поучаствовать в опросе не только харьковчан, которые планируют идти на UNETA, но и всех, кому это интересно. После доклада я сделаю отдельный пост, посвященный результатам, в котором выложу и презентацию, и тесты, и их результаты.
Спасибо за помощь :)
Скорее всего прийти послушать доклад не удастся.
ReplyDeleteНо я считаю что включить в доклад NHibernate было бы крайне полезно.
Все таки у L2S и EF достаточно разные сферы применения.
При этом NHibernate можно рассматривать как альтернативу EF.
Было бы интересно послушать каких возможностей EF нет в NHibernate и наоборот.
ReplyDeleteEgorK: Это не совсем вписывается в тему доклада. Я не планирую сильно расписывать функциональные различия этих ORM, кроме тех, которые влияют на производительность. То есть основной упор на то, какие операции занимают время и почему. Однако операции бывают разные, поэтому и спрашиваю, какие тесты мне стоит провести, чтобы покрыть как можно больше юскейсов, интересующих вас.
ReplyDeleteЯ имею ввиду сравнение по фичам как раз в контексте производительности.
ReplyDeleteТ.е. нечто вроде "Фича A в ORM B позволяет строить оптимальные запросы в сценарии C, а вот в ORM D сценарий C реализуется так-то и при этом эффект на производительность такой-то".
При этом можно было бы описать, например, где полезен lazy loading (а где вреден), как разные фреймворки строят запросы для сложных структур данных и т.п.
ИМХО было бы очень интересно, потому что например с NHibernate я разбирался, а до EF руки никак не дойдут; у кого-то наверняка обратная ситуация.
L2S в свете последних событий уже несколько отходит на второй план.
ну NH было бы очень неплохо рассмотреть ;) а вот есть ли смысл в L2S. Во-первых, он уже не поддерживается, а во-вторых, он не совсем ORM.
ReplyDeleteеще можно было бы вопрос Кеширования рассмотреть. Не знаю как обстаят дела с EF, а для NH есть 2-nd level cache, который при уместном использовании очень полезен для улучшения производительности.
Егор, с точки зрения производительности L2S на второй план не уходит точно :) Спасибо за советы, постараюсь поставить несколько опытов с lazy loading и сложными структурами данных.
ReplyDeletevitalya, согласен, не совсем ORM, но тем не менее как раз с точки зрения производительности очень даже стоит. Кеширование - интересная тема. Не уверен, что буду говорить об одном и том же кеше, но в EF в пределах контекста есть кеш для сгенерированных запросов и для уже однажды материализированных объектов. То есть, в базу мы все равно лезем, но если объект не изменился, то материализацию повторную не проводим. Что такое кеш 2го уровня в NH - надо почитать :)
Интересно было бы сравнить как разные ОРМ-ы обрабатывают деревья и связи разных типов. Особенно деревья - реляционные БД не слишком хорошо приспособлены для обработки структур такого типа, и ОРМ-ы довольно эффективно облегчают жизнь при работе с ними, с точки зрения написания кода.
ReplyDeleteНичего умного не скажу.
ReplyDeleteПостараюсь не прозевать и прийти на доклад.
понимаю, что доклад по производительности, но производительность, это только один из аспектов :) время разработки и сложность поддержки тоже немаловажные факторы.
ReplyDeleteАлександр Кондуфоров: в NH тоже кеш певого уровня, который привязан к сессии, и по сути кеширует ссылки на объекты по ID, но не кеширует значения пропертей и т.п. Кеш 2-го уровня как раз кеширует значения, и привязан не к ISession, а ISessionFactory. Но опять таки лучше почитать документацию :) А с L2S я на новом проекте связываться бы не стал - работать с мертвой библиотекой очень рисковано. Ну и просто - не просто же так она больше не поддерживается ;)
В тему деревьев: недавно сталкивался с подобной задачей. В качестве упрощающего фактора было то, что дерево категорий в нашей системе практически readonly. В итоге очень даже неплохо ратобает следующее решение - на app start загружаем все категории в 2nd level cache с помощью одного запроса к БД а ля "from Categories cat fetch join cat.Subcategories" (c синтаксисом могу ошибаться, т.к в основном использую Crtieria API). При выполнении этого запроса NH сам разберется в связях между категориями и построет дерево объектов. Теперь с деревом можно работать в памяти, не обращаясь к БД. Конкретно в нашем случае - очень полезное решение для облегчения нагрузки на БД :)
ЗЫ: а посетить мероприятие я не смогу, зато посмотреть примеры и материал будет очень интересно :)
vitalya: Немаловажные, но в данном случае я не хотел бы заострять внимание на этом. Я не успею ни приготовиться толком, ни рассказать все это :)
ReplyDeleteНасчет мертвой технологии я бы поспорил :) Да, я сам писал, что она не выдержит конкуренции с EF, но все же это реальная альтернатива всяким типизированным датасетам, которые люди очень часто используют на проектах. Легковесная, быстрая, простая в работе, работает с пол-оборота, сделали маппинг по базе и поехали. А почему она не будет активно развиваться, я уже писал здесь: http://merle-amber.blogspot.com/2008/11/linq-to-sql-entity-framework.html
Спасибо за описание кешей в NH. Такой вопрос: какой смысл в кеше первого уровня, если он не кеширует значения свойств сущностей? Их же все равно выбирать потом, разве нет?
И еще: насколько важно использовать в тесте чистый NH? Можно ли воспользоваться Active Record? Будет ли проигрыш, если да, на каком уровне?
<<< Такой вопрос: какой смысл в кеше первого уровня, если он не кеширует значения свойств сущностей?
ReplyDeleteПардон, не совсем четко в прошлом коменте написал - значения пропертей не кешируются между сессиями. Хотя "значения пропертей" наверно не самое подходящее название. Вобщем лучше умных людей почитать :) http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/11/09/first-and-second-level-caching-in-nhibernate.aspx
<<< реальная альтернатива всяким типизированным датасетам
А эти всякие датасеты кто-то до сих пор использует для новых проектов???? (про legacy code это отдельная история, но речь сейчас не об этом). Я за последние пару лет про использование датасетов от уважающих себя людей не слышал (разве что за кружкой пива и разговорами "а вот помнишь как это было..."). А вообще лучше религиозные споры отложить до оглашения официальных результатов сравнения :)))
<<< Какие тесты вы бы хотели увидеть?
может еще есть смысл посмотреть
- модель с базовыми сущностями и наследниками.
- insert \ update \ delete
- пейджинг на уровне БД
- аггрегатные функции а-ля count, sum
- сложные запросы с подзапросами и группировками
- проекции (например если надо выбрать только имена пользователей, а их емейлы и прочие данные тянуть не нужно)
- запросы с fetch'ем данных и использованием lazy load
Понимаю что я тут много написал, и все успеть практически невозможно :)
<<< Можно ли воспользоваться Active Record?
Понятно, что AR добавляет свой overhead, но насколько мне известно он незначительный.
Спасибо за ссылку - прочитал, разобрался. Теперь все стало намного понятнее. Кеш второго уровня - это действительно удобная и, главное, грамотно реализованная фича. Мы у себя заимплементили что-то наподобие, но все равно есть проблема в том, что сущности из одного контекста уже невалидны для другого. В NH этой проблемы, видимо, нет. Удобно.
ReplyDeleteНасчет датасетов спорить не будем, я уже высказывал свое отношение к ним :) Просто знаю кучу приложений, где они до сих пор используются, и людей, которые считали и продолжают считать датасеты панацеей, т.к. они позволяют не писать лишний код. Для них L2S будет достойной заменой. Хотя, EF тоже...
Все предложенные тесты попробовать точно не удастся, но я постараюсь сделать по-максимуму.
Да, я решил, что NH все же останется за бортом доклада :( У меня есть большой опыт работы с EF и чуть поменьше с L2S, я часто сталкивался с вопросами оптимизации в EF, из-за чего могу говорить об этих продуктах более-менее компетентно. В то же время NH я лишь начинаю изучать. Я не успею узнать все его оптимизации и хаки, чтобы провести действительно серьезный анализ и какое-то сравнение, а делать это поверхностно мне не хочется. Когда-нибудь лучше напишу отдельную заметку по этому поводу. А пока лучше серьезнее углубиться в L2S и EF.
жалко :( потому что NH в .NET мире используется довольно широко и без него тема доклада будет раскрыта неполностью. В принципе у меня сейчас есть время, и если будет желание - я могу реализовать тест провайдер под заданный интерфейс. Так хоть реальные циферки для сравнения будут.
ReplyDeleteСпасибо за предложение :) Согласен, что без NH этот доклад нельзя назвать описанием или сравнением производительности .NET ORM. Это нечестно. Но возможно, частично такой вариант может сработать. Я все равно считаю, что докладчик должен хорошо знать вопрос, чтобы что-то говорить, иначе это все теряет смысл. И даже тесты не спасут положение. Давай поступим так: я постараюсь побыстрее написать тестовое приложение с интерфейсами и реализациями для EF, L2S и DataReader'ов. Даже если я не успею в срок, я все равно выложу этот код потом, после доклада, чтобы ты мог реализовать часть, отвечающую за NH. И мы еще раз прогоним тесты и выложим результаты в режиме блога. Как тебе идея?
ReplyDeleteокей :) я седня кстати ишо на один ORM наткнулся. В этот раз коммерческий от Telerik'a http://www.telerik.com/products/orm.aspx?utm_source=Lounge&utm_medium=banner&utm_campaign=orm_500x25_january_lounge Судя по датам, он только-только выпустился
ReplyDeleteЭто круто :) Телерики жгут. Значит, кроме тех, что на слуху (NH, AR, EF, LLBLGen, Subsonic) и остальных, у нас теперь есть еще детище от телериков. Список фич впечатляет: поддерживаются оба направления генерации, 2 уровня кешей, свой язык запросов, LINQ, 6 баз данных и т.д. В общем, если это не надстройка над NH (а я думаю, что лицензия NH не позволит), то было бы интересно взглянуть на это чудо. Информации по нему пока не очень много, но если задаться целью, то можно почитать форумы и посмотреть мувики (типа этого).
ReplyDeleteСпасибо за наводку :)