Как сказала моя коллега "мы не специалисты в БД"
Проблема в следующем. Имеется база данных доступ к которой организован через запросы LINQ to SQL. Шеф сказал, что от LINQ он отказываться не хочет, но теперь вместо доступа к таблицам и полям БД надо будет использовать LINQ к Store Procedure. Аргументом к этому служит то, что SQL-серверу не надо будет компилировать запрос каждый раз и это увеличит производительность.
Вопрос в следующем.
На самом деле ли LINQ к Store Procedure сможет улучшить производительность системы?
Здравствуйте, Spender, Вы писали:
S>На самом деле ли LINQ к Store Procedure сможет улучшить производительность системы?
Плюс хранимой процедуры в том, что ее можно "оптимизировать" не трогая оригинальное приложение. в остальном, современные SQL сервера умеют кешировать планы выполнения запросов.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Плюс хранимой процедуры в том, что ее можно "оптимизировать" не трогая оригинальное приложение. в остальном, современные SQL сервера умеют кешировать планы выполнения запросов.
Оптимизировать никто не будет. Предлагается текущие запросы, сформированные LINQ просто скопировать на сервер и сделать из них хранимые процедуры. Про кэш я сказал. На это мне ответили, что запросов тысячи и что кэш здесь не поможет. Я не силен в этом, но как-то сомневаюсь. Зачем же он тогда нужен, если не поможет. Можете привести аргументы, статьи какие-нибудь. Буду очень признателен
Здравствуйте, Spender, Вы писали:
S>Проблема в следующем. Имеется база данных доступ к которой организован через запросы LINQ to SQL. Шеф сказал, что от LINQ он отказываться не хочет, но теперь вместо доступа к таблицам и полям БД надо будет использовать LINQ к Store Procedure. Аргументом к этому служит то, что SQL-серверу не надо будет компилировать запрос каждый раз и это увеличит производительность.
S>Вопрос в следующем. S>На самом деле ли LINQ к Store Procedure сможет улучшить производительность системы?
Нет, не сможет.
SQL-серверу определяет нужно компилировать запрос или нет полагаясь только на текст запроса. Откуда конкретно этот текст взят (из хранимки или пришел с клиента) ему абсолютно не важно. Важно лишь чтобы текст запроса всегда был одним и тем же. Если вы сможете гарантировать, что sql, генерируемый по LINQ-запросу, будет одним и тем же, то автоматом получите кеширование планов запроса.
Здравствуйте, Lloyd, Вы писали:
L>Нет, не сможет.
... L>Если вы сможете гарантировать, что sql, генерируемый по LINQ-запросу, будет одним и тем же, то автоматом получите кеширование планов запроса.
Запросы будут одинаковые, параметры запроса будут разные. Я так понимаю, это не повлияет на кэш. А где об этом можно почитать, желательно на английском
Здравствуйте, Spender, Вы писали:
L>>Если вы сможете гарантировать, что sql, генерируемый по LINQ-запросу, будет одним и тем же, то автоматом получите кеширование планов запроса.
S>Запросы будут одинаковые, параметры запроса будут разные. Я так понимаю, это не повлияет на кэш. А где об этом можно почитать, желательно на английском
Спасибо большое!!!
А ещё я как-то не нашел в сети сравнения производительности LINQ и Store Procedure. Вернее нашел, один, но там было сказано, что Store Procedure в 3-4 раза "быстрее", имеется ввиду эффективнее. Ссылкой на такие сравнения не раполагаете?
Здравствуйте, Spender, Вы писали:
S>А ещё я как-то не нашел в сети сравнения производительности LINQ и Store Procedure. Вернее нашел, один, но там было сказано, что Store Procedure в 3-4 раза "быстрее", имеется ввиду эффективнее. Ссылкой на такие сравнения не раполагаете?
Нет, таких ссылок нет. Но что мешает самому написать подобные тесты? Вроде ничего сложного не должно быть.
Здравствуйте, Lloyd, Вы писали:
L>Нет, таких ссылок нет. Но что мешает самому написать подобные тесты? Вроде ничего сложного не должно быть.
Опыта c SQL не много. Попробую. Вот сейчас коллегам разослал. Сидят, что-то обсуждают. Смеются. Я по-китайски не очень Сказли шефу пошли. Вот думаю, не уволит за слишком "рьяное" стремление улучшить?
Здравствуйте, Spender, Вы писали:
S>Доброго времени суток, всем!
S>Как сказала моя коллега "мы не специалисты в БД" S>Проблема в следующем. Имеется база данных доступ к которой организован через запросы LINQ to SQL. Шеф сказал, что от LINQ он отказываться не хочет, но теперь вместо доступа к таблицам и полям БД надо будет использовать LINQ к Store Procedure. Аргументом к этому служит то, что SQL-серверу не надо будет компилировать запрос каждый раз и это увеличит производительность.
S>Вопрос в следующем. S>На самом деле ли LINQ к Store Procedure сможет улучшить производительность системы?
производительность системы — да, производительность программистов от этого сильно уменьшится.
Давно я не встречал технических документов, которые были написаны хуже чем этот. Уже несколько лет читаю книги и литературу на английском, но этот текст заставил меня неслабо напрягаться и перечитывать предложения и абзацы по несколько раз.
Здравствуйте, Spender, Вы писали:
S>Оптимизировать никто не будет. Предлагается текущие запросы, сформированные LINQ просто скопировать на сервер и сделать из них хранимые процедуры. Про кэш я сказал. На это мне ответили, что запросов тысячи и что кэш здесь не поможет. Я не силен в этом, но как-то сомневаюсь. Зачем же он тогда нужен, если не поможет. Можете привести аргументы, статьи какие-нибудь. Буду очень признателен
Почитайте тут: http://msdn.microsoft.com/ru-ru/library/ms181055.aspx
В остальном, надо исходить из того, что SQL Server хранит только исходный код хранимых процедур и триггеров. При выполнении хранимой процедуры или триггера в первый раз исходный код компилируется в план выполнения. т.е. разница только в том, где будет хранится "текст" запросов. в случае с хранимыми процедурами (особенно если их тысячи) вы "усложняете" себе поддержку вашего решения.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, gandjustas, Вы писали:
S>>На самом деле ли LINQ к Store Procedure сможет улучшить производительность системы? G>производительность системы — да,
Можешь объяснить из-за чего может улучшиться производительность системы?
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Lloyd, Вы писали:
L>>Можешь объяснить из-за чего может улучшиться производительность системы?
K>Экономия трафика на пересылку запроса vs пересылку имени хранимки?
Наверное только этим. Ну и еще конечно отсуствие затрат по генерации запроса.
[...]
свои пять копеек...из того небольшого опыта применения linq to sql могу сказать следующее:
linq to sql не панацея от всех болезней, существуют и другие orm системы (например, от DevExpress очень неплох XPO, гораздо дальше ушел от linq to sql),
позволяющие убрать непосредственное общение со скриптами, но общий минус у всех один и тот же — это возможность получения такого плана выполнения,
который и в страшном сне не приснится ну и соотвественно медленные запросы...те вещи, которые являются родными для sql определенного диалекта ну никак не перенести в конструкции c# linq (функции обработки данных, преобразования типов), к тому же, если речь идет о сложной логике обработки данных (скажем, некие предпросчеты, или запросы к распределенным системам, построенным на linked servers) то гораздо выгоднее и компактнее написать такую логику в процедурах и использовать их как методы linq to sql context-а... (уж не говорю о том, что сложно построить linq контекcт, построенный на нескольких базах данных)
мое скромное мнение — linq to sql годится для небольших систем с небольшой нагрузкой аля desktop winforms app,
если же предполагается, что система будет расти, то лучше сразу закладываться на использование процедур...
некоторые могут возразить по поводу оптимизации — мы же можем спрофилировать сгенерированные запросы от linq и произвести их оптимизацию путем оптимизации планов, построения индексов и прочее, но поверьте, когда запрос наподобие указанного ниже уходит на сервер, оптимизировать его становится очень сложно, опять таки, если есть кому оптимизировать такие запросы и работать с базой (есть такие люди dba), то может лучше ему и отдать обязанности по обработке этих данных на стороне сервера — разделение труда и узкая специализация?
var leads = (from lsp in ctx.LeadsSalesReps
join lead in ctx.Leads on lsp.LeadID equals lead.ID
join customer in ctx.Customers on lead.CustomerID equals customer.ID
let leadProvider = lead.LeadProvider
where lead.CustomerID != null &
lsp.CompanyGUID == CurrentCompany.GUID
select new
{
LeadID = lead.ID,
CustomerID = lead.CustomerID,
Name = lead.Customer.FirstName + " " + lead.Customer.LastName,
Source = lead.LeadSource,
LeadRequestDate = lead.LeadRequestDate,
LeadPriority = lead.LeadPriority,
LastActionCompleted = (from phocecall in ctx.PhoneCalls
where phocecall.CustomerID == lead.CustomerID
select new
{
Action = "Made a phone call",
Date = phocecall.CallDate
}
).Union(
(from email in ctx.EMails
where email.CustomerID == lead.CustomerID
select new
{
Action = "Send an email",
Date = email.SentDate
})
).OrderByDescending(d => d.Date).First().Action,
NextActionDate = (from appointment in ctx.Appointments
where appointment.CustomerID == lead.CustomerID &&
appointment.StartDate >= lead.LeadRequestDate &&
appointment.Status.HasValue && appointment.Status.Value != 3 /* completed */select appointment
).OrderBy(a => a.StartDate).First().StartDate,
NextAction = (from appointment in ctx.Appointments
where appointment.CustomerID == lead.CustomerID &&
appointment.StartDate >= lead.LeadRequestDate &&
appointment.Status.HasValue && appointment.Status.Value != 3 /* completed */select appointment
).OrderBy(a => a.StartDate).First().AppointmentType,
ProviderTypeID = (leadProvider != null ? leadProvider.ProviderTypeID : 0),
Provider = leadProvider
}).ToList();
вообще, база данных не только запросы к ней и таблички...ее также приходится поддерживать, сопровождать, она влияет на производительность системы в целом и даже больше, чем ее клиенты, это неотъемлемая составляющая серьезной системы, и linq to sql не предназначен для того, чтобы эту составляющую убрать полностью...нужно в первую очередь исходить из требований к самой базе.
Если коротко:
1) СП стоит рассматривать не как средство подтюнить производительность, а как средство инкапсуляции БД/внешние интерфейсы. Другими словами — способ дать доступ к данным, не открывая всех внутренностей.
2) +1 к "не использовать Linq2SQL в серьёзных системах".
3) Linq2SQL уже не модно — EF очередное наше всё.
Сказли шефу пошли. Вот думаю, не уволит за слишком "рьяное" стремление улучшить?
