Здравствуйте, alex_public, Вы писали:
I>>Ты в курсе, что физически весь процессинг SO может выдержать один единственный сервер ? По твоей ссылке это сказано явно. I>>Это значит, что 11 серверов есть просто резервирование, для надежности и упрощения майнтенанса.
_>Не только для резервирования. Не забывай про время отклика — если запросов больше чем ядер (а у них именно так и есть), то они в начале ещё в очереди постоят...
Ужос, небольшой процент юзеров получат ответ на 1-10мс позже ! Катастрофа ! У тебя хттп съедает больше, алё !
_>Но в любом случае, даже если бы у них сейчас работал вообще один сервер, то это только бы ещё больше подтвердило мои слова. О том насколько существенно они оптимизировали свою архитектуру относительно изначальной (которая была на linq).
Они полностью изменили архитектуру, целиком. Linq это ничтожная часть изменений, не самая важная.
Ты глаза раскрой — экономия от милисекунд на запрос, до максимум десятка милисекунд на запрос.
I>>Даппер, ссылки были дадены, нынче не самое быстрое решение. И судя по тому, что его никто не выпиливает из SO, очевидно ты и здесь попутал. _>Да, да, тут у некоторых товарищей с помощью лёгкого волшебства linq2db ещё и заметно быстрее прямого доступа к БД получался. Помним помним. )))
Я уже подустал твоё враньё читать. Ты увидел непонятную тебе особенность в одном тесте, а теперь уже недели две бегаешь и игнорируешь вообще все тесты.
_>Только хорошие запросы всё равно не помогут выше определённого уровня нагрузки, т.к. цена кластера быстренько уходит в небеса, по сравнению с аналогичным набором простеньких параллельных серверов.
И это всё ещё не повод выбирать говноинструменты, неспособные устранять банальные избыточности в запросах, построенных в рантайме.
S>>Нет, в шаблонном решении на С++ эта задача решена на твёрдую три с минусом: S>>А. Нет возможности переструктурировать запрос. Для того, чтобы корректно собрать SQL Statement для всяких разных условий, надо не строки клеить, а анализировать дерево выражений. Пример только что приводили http://rsdn.ru/forum/prj.rfd/6345934.flat
— там исчезают лишние join вообще. Одно и то же linq-выражение типа where x.Contains(o.id) должно превращаться в зависимости от диалекта и переданных параметров либо в where o.id = @x1 or o.id = @x2 or o.id = @x2, либо в where o.id in (@x1, @x2, @x3), либо в inner join f.tableValue(@x1, @x2, @x3) x on o.id = x.id
_>Приведённый по ссылке пример — это в точности мой пункт 2, а совсем не пункт 1.
S>>Б. Нет возможности подключать новые провайдеры, которые бы даже в примитивном случая заменяли бы одн на другое. Поскольку весь анализ "дерева выражений" делается в компайл-тайм, то и все оптимизации делаются в компайл тайм. Единственный способ научить приложение генерировать все три вида строк — это вставить в каждый вызов SQL if-statement, проверяющий "если SQLite — то так, если SQLServer 2012 — то так, если SQL Server 2005 — то вот эдак". И даже после этого прикрутка Postgres потребует перекомпиляции.
_>Эм, ты похоже даже самые базовые архитектурные паттерны не знаешь, если такую ересь пишешь. If естественно будет, но ровно один на всё приложение. Более того, я уже не только говорил об этом, но и показывал прямые примеры компилируемого кода.
Я, конечно, не в курсе последних новостей С++, так как перестал на нём активно писать года примерно после 2000го. Однако сдаётся мне, что имеет место трендёж. Решительно не понимаю, как можно одновременно использовать компайл-тайм генерацию запросов, несколько провайдеров, и при этом единственный IF за пределами текущей единицы компиляции. _>Мда, что-то у тебя всё совсем печально выглядит с самыми основами проектирования. Даже если захотеть растащить прямую работу с БД по всему приложению (что впрочем уже не самое лучшее решение для серьёзного приложения, в отличие от построения полноценного DBAL), то для этого совершенно не обязательны такие кривые подходы как в Linq. Достаточно всего лишь добавить соответствующий параметр в нашу функцию, чтобы в зависимости от него она генерировала нужную разновидность запроса. А не создавать некий обобщённый запрос, который потом в рантайме будет ужиматься под конкретные случаи.
Это как раз у вас с основами проектирования — полная труба. Опыта работы в команде явно тоже нет совсем — иначе такую чушь писать рука бы не поднялась.
Я же вам написал чёрным по белому — функцию пишет одна команда, использует — другая. Кто должен добавить параметр — команда А или команда Б? Кто даст команде Б права лезть в код команды А?
S>>Для начала я рекомендую ознакомиться с тем, сколькими способами Skip().Take() конвертируется в SQL. Это не синтаксис, это вопросы оптимизации с учётом особенностей конкретной СУБД. _>Хыхы, забавно. В сообщениях выше я приводил именно это в качестве примера зависимости от синтаксиса (т.е. в точности пункт 1).
Конечно забавно. Забавно то, что вы это приводите в качестве синтаксиса — это полностью показывает ваш уровень невладения предметом. Это не просто выбор верного ключевого слова, это разная структура SQL.
Вплоть до select top 100 from Orders where ID not in (select top 4000 ID from orders order by OrderDate) order by OrderDate.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
C>>Мигрируют на аналог NoSQL, используя Redis в качестве оперативного хранилища и MSSQL как транзакционный лог. Кстати, все данные они там хранят в памяти. G>В блогах подтверждений нет. Это твои фантазии. http://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/
G>Redis в SO используется как кэш, ms sql — как хранилище данных.
We currently have about 2 TB of SQL data (1.06 TB / 1.63 TB across 18 SSDs on the first cluster, 889 GB / 1.45 TB across 4 SSDs on the second cluster), so that’s what we’d need on the cloud (hmmm, there’s that word again). Keep in mind that’s all SSD. The average write time on any of our databases is 0 milliseconds, it’s not even at the unit we can measure because the storage handles it that well. With the database in memory and 2 levels of cache in front of it, Stack Overflow actually has a 40:60 read-write ratio. Yeah, you read that right, 60% of our database disk access is writes (you should know your read/write workload too). There’s also storage for each web server — 2x 320GB SSDs in a RAID 1. The elastic boxes need about 300 GB a piece and do perform much better on SSDs (we write/re-index very frequently).
Т.е. БД используется как хранилище и "источник истины", а вся работа ложится на кэш. Следующий шаг — это понимание того, что кэш уже почти стал базой данных сам по себе.
C>>Идеологическая причина простая — Линукс банально удобнее. G>Опять фантазии, ник пишет лишь о том, что это "better money allocation", а не про удобства. G>Впредь подтверждай слова фактами пожалуйста.
Я работаю в компании, у которой больше всего серверов в мире После того, как они купили мою компанию, которая занимается кластерными вычислениями. Я могу с некоторой долей авторитета утверждать, что примерно знаю почему используется Линукс.
Здравствуйте, Cyberax, Вы писали:
C>Т.е. БД используется как хранилище и "источник истины", а вся работа ложится на кэш. Следующий шаг — это понимание того, что кэш уже почти стал базой данных сам по себе.
Бред. Кэш не становится базой. Сценарии использования разные от слова вообще.
У базы задача — долгосрочное хранение и сохранение целостности. Кэш должен быстро отдавать данные по ключу. Кэш не может обеспечить сохранение целостности и гарантировать долгосрочное хранение.
C>>>Идеологическая причина простая — Линукс банально удобнее. G>>Опять фантазии, ник пишет лишь о том, что это "better money allocation", а не про удобства. G>>Впредь подтверждай слова фактами пожалуйста. C>Я работаю в компании, у которой больше всего серверов в мире После того, как они купили мою компанию, которая занимается кластерными вычислениями. Я могу с некоторой долей авторитета утверждать, что примерно знаю почему используется Линукс.
А ты тут при чем? У тебя может быть своя идеология, о которой нам ничего не известно.
Ты же утверждал про SO, а у них никакой идеологии нет, просто "better money allocation".
У тебя насколько я знаю серваки чето-там считают, это не веб-приложение, которое должно ответить пользователю менее чем за 100мс.
Здравствуйте, alex_public, Вы писали:
_>Проект с подобной архитектурой обречён быть тормозом.
Тормозом будет твой стрококлей, потому что даже на тривиальных сценариях типа "пользователь покликал по колонкам для сортировки, потом пару фильтров вписал и полистал странички" твой стрококлей все что сможет это навертеть кучу вложенных селектов и молиться чтобы это луковое чудовище не сильно поставило раком планировщик. А если там еще и со стороны сервера всякие чудеса типа Row Level Security, то уже можно даже не молиться, результат полностью предсказуем.
Здравствуйте, Ikemefula, Вы писали:
I>Кроме того, по твоей ссылке создается ощущение, что БД на SO не является узким местом, что и объясняет возможность применения даппера. То есть, SO все еще полирует HTTP трафик. Вот как эта часть подойдет к насыщению, тогда и посмотрим про БД, выживет ли там даппер или нет.
По слухам, рост нагрузки на SO прекратился, так что особая нужда в оптимизации дальше тоже отпала.
Здравствуйте, alex_public, Вы писали:
_>1. sqlite (Postgresql для сетевого случая)
sqlite даже не десктопе не того, стоит попытаться чуть чуть сгладить пользователю жизнь за счет распараллеливания. А постгри, конечно, довольно приличная штука на фоне остального опенсорса, но оптимизатор у него совсем уж простенький, и некачественный sql (а иногда даже и вроде бы качественный на первый взгляд) легко ставит его раком.
Здравствуйте, alex_public, Вы писали:
_>3. Умная оптимизация запросов с учётом особенностей конкретной СУБД. Вот такое действительно было бы очень интересно. И т.к. подобного точно нет в обсуждаемом C++ решение или тем более голых строках, то это реально могло бы подтвердить тезис о возможности Linq формировать более оптимальные запросы. Только вот не смотря на анонс существования данной возможности в Linq ORM ни единого (!) примера, подтверждающего это на практике, пока так и не было представлено.
А ты и не просил. Смотрим модель провайдера linq2db:
public class SqlProviderFlags
{
public bool IsParameterOrderDependent { get; set; }public bool AcceptsTakeAsParameter { get; set; }public bool AcceptsTakeAsParameterIfSkip { get; set; }public bool IsTakeSupported { get; set; }
public bool IsSkipSupported { get; set; }
public bool IsSkipSupportedIfTake { get; set; }
public bool IsDistinctOrderBySupported { get; set; }
public bool IsSubQueryTakeSupported { get; set; }
public bool IsSubQueryColumnSupported { get; set; }
public bool IsCountSubQuerySupported { get; set; }
public bool IsIdentityParameterRequired { get; set; }
public bool IsApplyJoinSupported { get; set; }public bool IsInsertOrUpdateSupported { get; set; }public bool CanCombineParameters { get; set; }public bool IsGroupByExpressionSupported { get; set; }
public int MaxInListValuesCount { get; set; }public bool IsUpdateSetTableAliasSupported { get; set; }
public bool IsSybaseBuggyGroupBy { get; set; }
public bool GetAcceptsTakeAsParameterFlag(SelectQuery selectQuery)
{
return AcceptsTakeAsParameter || AcceptsTakeAsParameterIfSkip && selectQuery.Select.SkipValue != null;
}
public bool GetIsSkipSupportedFlag(SelectQuery selectQuery)
{
return IsSkipSupported || IsSkipSupportedIfTake && selectQuery.Select.TakeValue != null;
}
}
Жирным я выделил те вещи, которые непосредственно влияют именно на оптимизацию sql. Едем дальше. Видим интерфейсы и классы:
public interface ISqlOptimizer
{
SelectQuery Finalize (SelectQuery selectQuery);
ISqlExpression ConvertExpression(ISqlExpression expression);
ISqlPredicate ConvertPredicate (SelectQuery selectQuery, ISqlPredicate predicate);
}
public class BasicSqlOptimizer : ISqlOptimizer ...
Теперь смотрим на его наследников:
class SqlServerSqlOptimizer : BasicSqlOptimizer
class SqlServer2000SqlOptimizer : SqlServerSqlOptimizer
class SqlServer2005SqlOptimizer : SqlServerSqlOptimizer
class AccessSqlOptimizer : BasicSqlOptimizer
class DB2SqlOptimizer : BasicSqlOptimizer
class FirebirdSqlOptimizer : BasicSqlOptimizer
class InformixSqlOptimizer : BasicSqlOptimizer
class MySqlSqlOptimizer : BasicSqlOptimizer
class OracleSqlOptimizer : BasicSqlOptimizer
class PostgreSQLSqlOptimizer : BasicSqlOptimizer
class SQLiteSqlOptimizer : BasicSqlOptimizer
class SapHanaSqlOptimizer : BasicSqlOptimizer
class SqlCeSqlOptimizer : BasicSqlOptimizer
class SybaseSqlOptimizer : BasicSqlOptimizer
Содержимое означенных классов ты можешь изучить самостоятельно.
Здравствуйте, gandjustas, Вы писали:
C>>Т.е. БД используется как хранилище и "источник истины", а вся работа ложится на кэш. Следующий шаг — это понимание того, что кэш уже почти стал базой данных сам по себе. G>Бред. Кэш не становится базой. Сценарии использования разные от слова вообще.
Ещё как становится.
G>У базы задача — долгосрочное хранение и сохранение целостности. Кэш должен быстро отдавать данные по ключу. Кэш не может обеспечить сохранение целостности и гарантировать долгосрочное хранение.
Правильный кэш всё может. В частности: запросы, в том числе и сложные, гарантию целостности данных (транзакционный лог, репликация с eventual consistency и т.д.).
Собственно, так и получился NoSQL — сначала делался кэш, а потом оказалось, что получилась полноценная БД (вид сбоку).
C>>Я работаю в компании, у которой больше всего серверов в мире После того, как они купили мою компанию, которая занимается кластерными вычислениями. Я могу с некоторой долей авторитета утверждать, что примерно знаю почему используется Линукс. G>А ты тут при чем? У тебя может быть своя идеология, о которой нам ничего не известно. G>Ты же утверждал про SO, а у них никакой идеологии нет, просто "better money allocation".
SO пишут несколько человек, которые случайно были больше всего знакомы с C#. Потому и выбор технологий немного странный.
Если заниматься крупным масштабом, то там просто никак кроме как с Линуксом не получается. Даже у MS, что самое смешное.
G>У тебя насколько я знаю серваки чето-там считают, это не веб-приложение, которое должно ответить пользователю менее чем за 100мс.
Сейчас конкретно у меня API, которое начинает мне на пейджер пищать среди ночи, если латентность запросов поднимается более чем на 500мс.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Т.е. БД используется как хранилище и "источник истины", а вся работа ложится на кэш. Следующий шаг — это понимание того, что кэш уже почти стал базой данных сам по себе. G>>Бред. Кэш не становится базой. Сценарии использования разные от слова вообще. C>Ещё как становится.
Хотя бы обосновать свои слова можешь? А лучше доказать.
G>>У базы задача — долгосрочное хранение и сохранение целостности. Кэш должен быстро отдавать данные по ключу. Кэш не может обеспечить сохранение целостности и гарантировать долгосрочное хранение. C>Правильный кэш всё может. В частности: запросы, в том числе и сложные, гарантию целостности данных (транзакционный лог, репликация с eventual consistency и т.д.).
И скорость при этом выше, чем у RDBMS при одинаковом объеме данных? Что за магический движок такой?
C>Собственно, так и получился NoSQL — сначала делался кэш, а потом оказалось, что получилась полноценная БД (вид сбоку).
Вот только на практике не получилась ни БД — не хватает гарантий, ни кэш — работает медленно.
C>>>Я работаю в компании, у которой больше всего серверов в мире После того, как они купили мою компанию, которая занимается кластерными вычислениями. Я могу с некоторой долей авторитета утверждать, что примерно знаю почему используется Линукс. G>>А ты тут при чем? У тебя может быть своя идеология, о которой нам ничего не известно. G>>Ты же утверждал про SO, а у них никакой идеологии нет, просто "better money allocation". C>SO пишут несколько человек, которые случайно были больше всего знакомы с C#. Потому и выбор технологий немного странный.
Да-да. Стандартная тактика неумелого тролля — искать проблему в людях когда нечем аргументировать позицию.
Почитай старые посты на coding horror, там много почему SO сделан был именно так. По сути две причины — asp.net mvc и linq2sql.
C>Если заниматься крупным масштабом, то там просто никак кроме как с Линуксом не получается. Даже у MS, что самое смешное.
SO доказывает обратное. Это крупный масштаб. 99% проектов меньший масштаб имеют.
Здравствуйте, gandjustas, Вы писали:
_>>Ну да, linq2db конечно получше, всего 100% накладных расходов, а не 500%. ))) G>Да хоть 10000%, относительные величины не имеют никакого смысла. G>Имеет смысл влияние скорости linq на время ответа и пропускную способность. Причем в реальном приложении, а не синтетическом тесте.
Похоже что уже не имеет смысла продолжать дискуссию с тобой, т.к. от тебя пошла исключительно демагогия и отмазки. Вот на 100% уверен, что если бы тесты показывали бы преимущество linq решений, то ты бы тут соловьём пел о необходимость верить только тестам. )))
_>>Ну даже если забыть о нормальных реализация уже давно имеющихся в других СУБД, то хотя бы из того, что они исправили это в 2012-ом году. ))) Причём реализовав как раз как у других было. G>Ок, если ты настолько глуп — объясняю. G>SQL Server очень хорошо следует стандартам.
Хороший юмор. Это "top x" у нас соответствует стандарту, да? ) Да и вообще MS славится своим отношением к стандартам во всём. )))
G>В стандартах ANSI не было (и насколько я знаю до сих пор нету) штатного способа разбиения резалтсета на страницы. Было через курсоры, но реализация курсоров оказывается медленнее операций с множествами.
Ну вот теперь и проявляется кто у нас на самом деле не знаком с SQL, а знаком исключительно с конкретной поделкой одной известной компании. Хотя я в общем то совсем не удивлён — почти всегда те, кто громче всех кричит о незнание других, на самом деле сами не особо разбираются. Тут таких много на форуме...
В стандарте SQL2008 оно появилось.
G>Поэтому в T-SQL долго не включали операторы постраничного разбиения. А вот ranking functions как раз в стандарте есть и через них прекрасно делается разбиение на страницы. G>Только в конце 2000-х стало очевидно, что на стандарт уже все положили болт и тогда добавили операторы в T-SQL.
Зачем врать то? ) Появилось оно не в конце 2000-ых, а вполне себе в 2012, т.е. через несколько лет после появления в стандарте. И через десятилетие после того, как этим спокойно работали пользователи нормальных СУБД.
_>>У тебя мозг уже не способен связать два последовательных абзаца? ) Перечитай ещё пару разу предыдущий абзац))) G>Ок, давай возьмем современные версии двух движков и ты на примере покажешь чем pl\sql в Postgres кардинально отличается от T-SQL. Ты не сможешь этого сделать. Поэтому все твои рассуждения — бредятина.
Похоже тебе надо ещё раз 10 перечитать тот абзац. ) Речь как раз и шла о том, что только в 2012-ом SQL Server приблизился к нормальным решениям. Т.е. речь шла о сравнение не современных решений, а предыдущих лет. А вот сейчас похоже можно уже и с SQL Server без linq нормально жить.
G>Ты просто не понимаешь о чем они пишут. G>Они тебе говорят что для разных движков и даже разных версий одного движка одно и то же логическое выражение может быть записано по разному и давать разное быстродействие. Это означает, что в compile-time ты не сможешь сгенерировать оптимальный запрос к БД в принципе, а в runtime это можно сделать.
До тебя так и не дошло? ) Генерируется во время компиляции не сам запрос, а код его создания (склейки строк). Собственно иначе и невозможно, т.к. в запрос входят данные.
G>Я тебе говорю о том, что даже в рамках одного движка linq с легкостью сгенерирует сотни похожих запросов и каждый будет оптимальным для своего сценария, а руками даже десять таких запросов написать и поддерживать невозможно.
Даже если не использовать готовую библиотечку генерации во время компиляции (типа обсуждаемой), то это всё равно не означает что надо каждый запрос прописывать руками. Ты там со своим linq похоже совсем уже забыл, что есть банальные операции со строками, функциям можно параметры передавать и т.п..
_>>Да да, конечно не может. И написать код, генерирующий эти запросы он тоже не может. ))) G>Если сможет, тогда у него получится linq. Или придется жертвовать выразительной силой, получая в итоге более универсальные и более тормозящие запросы. Ты же так и не смог показать генератор запросов, аналогичный linq по мощности, но без оверхеда.
Помнится в той старой темке ты говорил тоже самое (и даже ещё смешнее, что типа банальных join, groupby и т.п. нет). Но когда тебя ткнули в нос в соответствующие работающие примеры (причём даже не на форуме, а прямо в папке example той библиотечки, в которую ты сам не догадался заглянуть), то по тихому слился из дискуссии. Если сейчас попробовать повторить тоже самое, то не сомневаюсь в аналогичном результате.
_>>Это если запрос написать полностью аналогичный процедуре. Что сделает разве что какой-то альтернативно одарённый программист. G>Ты опять не понимаешь что тебе пишут. Почитай чтоли мануалы на досуге. Если взять один и тот же запрос и завернуть его в процедуру или вызывать текстом из кода, то в подавляющем большинстве случаев они будут исполняться абсолютно одинаково.
А ты даже читать не умеешь похоже. Ответить на фразу "одинаково только если запрос написать полностью аналогичный процедуре, что бредово" фразой "если взять один и тот же запрос, то будет одинаков" может только реальный уникум.
_>>Повторяю по слогам. Ты показал linq код, делающий запрос на базе C# переменной. При этом аналогом его у тебя была некая абстрактная хранимка, висящая в воздухе, а не соответствующий C# код (без linq, на голом sql) делающий аналогичное из той же переменной. Попробуй его написать и может до тебя дойдёт о чём речь. G>Ты хочешь сказать, что надо подставлять параметр в текст запроса, а не использовать механизм параметров?
Вообще то и при использование параметров нормальный запрос будет выглядеть короче твоего чудища в хранимке. И при этом работать оптимизировано. Попробуй сам написать такое и увидишь. Или ты уже совсем разучился с этим своим linq и нужна подсказка? )
G>Ты опять показал свой профанизм. G>Подстановка параметров имеет два огроменных недостатка: G>1) SQL-инъекции в случае текстовых параметров, они гарантированно будут. Надежного метода экранирования практически нет.
G>2) Каждый запрос будет компилироваться по новой. Это мееедленно и кушает память базы на хранение планов. G>С твоим подходом быстродействие упадет и приложение станет более уязвимым. G>Так что брось сразу эту затею и читай мануалы.
О, я смотрю что незнание проявляется всё больше и больше. Причём здесь уже включает даже твой любимый sql server, а не только сам язык sql. Похоже что ты слышал только о кэширование планов параметризованных программистом запросов. А о просто кэширование планов или об автопараметризации констант ты и не слышал видимо. Мда... )
_>>А какая разница в какой компании написан софт? ) Мы же языки/платформы/библиотеки обсуждаем... G>Не знаю что ты обсуждаешь, а меня инересуют что делают парни из SO. G>Парни из SO пишут код на C# и запускают его под вендой. А сторонние продукты запускают по nix потому что это дешевле. G>Тут никаких идеологических мотивов нет, только экономические.
А причём тут какая-то идеология? ) Это только у неадекватов с форумов она встречается, а нормальные люди тупо используют то, что дешевле. ))) И если готовые решения на C++, работающие под Linux оказываются быстрее и дешевле C# аналогов, работающих под виндой, то это и есть решающий фактор.
_>>Без проблем. ) Но с PostgreSQL ну или чем-то ещё приличным. С кактусами возитесь сами. G>Ясно, слился.
Считай как хочешь. )
_>>Или Linq не умеет PostgreSQL?) Ну давай тогда возьмём что-нибудь совсем простенькое и популярное, типа sqlite. ))) G>Все умеет, но никто не будет адаптировать существующие тесты для других движков. Это же не просто поставить постгрес, надо еще базу перенести, текстовые запросы переписать. Никто для тебя этого делать не будет. G>Или сам, или используй готовую базу на SQL Server.
Можем не использовать row sql запросы вообще (собственно нас же только сравнение с linq версией интересует). База переноситься в две консольные команды.
G>Но помоему уже все поняли, что доказать свои слова ты не можешь. G>Можешь не продолжать писать. Большего профана наверное на всем форуме не найдешь.
Ага, и поэтому ты пишешь мне по 3 сообщения в ответ на одно моё. И поэтому так нервничаешь в каждом из них. Я так и понял. )))
Здравствуйте, Ikemefula, Вы писали:
I>Точнее ты просто игнорируешь, чего люди пишут и повторяешь одну и ту же мантру "а вот в C++ это лучше", и _постоянно_ намекаешь на квалификацию конкретного автора, дотнетчиков, фанатов linq, C# и тд и тд.
И? ) В чём проблема? Или кому-то тут сложно смириться с неприятной истиной? )
I>Вот пример — когда тебе говорят, что твоё приложение надо перекомпилировать при смене базы, ты придираешься к количеству if, что бы понамекать, что автор не так проектирует. I>Возникает ощущение, что ты вообще не понимаешь, ради чего твоё решение надо перекомпилировать и почему такое возможно.
Вот в том то и дело, что перекомпилировать его не надо. Но собеседник не может этого осознать в силу свой компетенции.
Здравствуйте, Ikemefula, Вы писали:
I>Ужос, небольшой процент юзеров получат ответ на 1-10мс позже ! Катастрофа ! У тебя хттп съедает больше, алё !
Не забывай, что на каждый запрос страницы приходится несколько запросов в БД. Т.е. в реальности картинка выглядит так: эти 10мс оверхеда умножаешь на число запросов к бд (ну скажем 5) и это всё ставишь в очередь скажем из 100 пользователей в секунду (если про тот же SO говорить)/число ядер машинки. Вполне себе неприятная картина... Притом что данная нагрузка не приносит никакой реальной пользы.
Т.е. естественно это беспроблемно решается дополнительным железом, т.к. данная часть легко масштабируется горизонтально. Только вот зачем платить лишние деньги впустую?
_>>Но в любом случае, даже если бы у них сейчас работал вообще один сервер, то это только бы ещё больше подтвердило мои слова. О том насколько существенно они оптимизировали свою архитектуру относительно изначальной (которая была на linq). I>Они полностью изменили архитектуру, целиком. Linq это ничтожная часть изменений, не самая важная. I>Ты глаза раскрой — экономия от милисекунд на запрос, до максимум десятка милисекунд на запрос.
Я нигде и не говорил, что убирание linq является главной оптимизацией (главное там скорее в области Redis'a прячется, причём он у них похоже уже не просто как кэш работает). Но это очевидно необходимый пункт для построения нормальной системы.
Здравствуйте, Sinclair, Вы писали:
S>И это всё ещё не повод выбирать говноинструменты, неспособные устранять банальные избыточности в запросах, построенных в рантайме.
Ну так это же известная вечная дилемма. Или выбирать дорогих умных программистов+дешёвые (в смысле отжирания ресурсов) инструменты или же выбирать дорогие (в смысле отжирания ресуросов) умные инструменты+дешёвых программистов.
Для не IT компаний обычно предпочтительнее второе, а для IT компаний первое.
_>>Эм, ты похоже даже самые базовые архитектурные паттерны не знаешь, если такую ересь пишешь. If естественно будет, но ровно один на всё приложение. Более того, я уже не только говорил об этом, но и показывал прямые примеры компилируемого кода. S>Я, конечно, не в курсе последних новостей С++, так как перестал на нём активно писать года примерно после 2000го. Однако сдаётся мне, что имеет место трендёж. Решительно не понимаю, как можно одновременно использовать компайл-тайм генерацию запросов, несколько провайдеров, и при этом единственный IF за пределами текущей единицы компиляции.
Уже вроде как раз 100 в данной темке было сказано, что во время компиляции генерируется не готовый sql запрос (что как бы вообще изначально очевидно, т.к. в запрос входят данные пользователя и соответственно невозможно его сгенеровать целиком во время компиляции), а соответствующий код склейки строк.
_>>Мда, что-то у тебя всё совсем печально выглядит с самыми основами проектирования. Даже если захотеть растащить прямую работу с БД по всему приложению (что впрочем уже не самое лучшее решение для серьёзного приложения, в отличие от построения полноценного DBAL), то для этого совершенно не обязательны такие кривые подходы как в Linq. Достаточно всего лишь добавить соответствующий параметр в нашу функцию, чтобы в зависимости от него она генерировала нужную разновидность запроса. А не создавать некий обобщённый запрос, который потом в рантайме будет ужиматься под конкретные случаи. S>Это как раз у вас с основами проектирования — полная труба. Опыта работы в команде явно тоже нет совсем — иначе такую чушь писать рука бы не поднялась. S>Я же вам написал чёрным по белому — функцию пишет одна команда, использует — другая. Кто должен добавить параметр — команда А или команда Б? Кто даст команде Б права лезть в код команды А?
1. Вот как раз из-за таких проблем я и сказал, что это изначально убогая архитектура.
2. Согласование контрактов модулей и запрос новых возможностей в любом случае необходим, пусть это и происходит через некую бюрократию.
S>>>Для начала я рекомендую ознакомиться с тем, сколькими способами Skip().Take() конвертируется в SQL. Это не синтаксис, это вопросы оптимизации с учётом особенностей конкретной СУБД. _>>Хыхы, забавно. В сообщениях выше я приводил именно это в качестве примера зависимости от синтаксиса (т.е. в точности пункт 1). S>Конечно забавно. Забавно то, что вы это приводите в качестве синтаксиса — это полностью показывает ваш уровень невладения предметом. Это не просто выбор верного ключевого слова, это разная структура SQL. S>Вплоть до select top 100 from Orders where ID not in (select top 4000 ID from orders order by OrderDate) order by OrderDate.
О, это тот самый ужас на который многие годы были обречены пользователи убогого SQL Server, в то время как пользователи других СУБД спокойно использовали нормальные решения. Только вот он уже давно не актуален даже в SQL Server. ))) Т.е. даже сама обсуждаемая библиотечка родилась позже того, как MS наконец то исправилась.
Кстати, сейчас уже все СУБД подтягиваются к стандарту (оставляя и свой старый синтаксис), так что может в будущем даже на чистом SQL (без всяких генерирующих библиотек) уже можно будет проще писать. Жаль только что в данном конкретном случае они взяли в стандарт этот многословный вариант с "OFFSET o ROWS FETCH NEXT l ROWS ONLY", мне больше нравился вариант с "LIMIT l OFFSET o", который привычен многим уже многие годы.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Тормозом будет твой стрококлей, потому что даже на тривиальных сценариях типа "пользователь покликал по колонкам для сортировки, потом пару фильтров вписал и полистал странички" твой стрококлей все что сможет это навертеть кучу вложенных селектов и молиться чтобы это луковое чудовище не сильно поставило раком планировщик. А если там еще и со стороны сервера всякие чудеса типа Row Level Security, то уже можно даже не молиться, результат полностью предсказуем.
Вот с чего вы все берёте то подобный бред? ) Вроде же было чётко сказано, что в отличие от Linq данный инструмент является точным отражением SQL. Т.е. если ты поставил одно слово select, то ровно он один и будет в итоговом запросе. Ничего от себя библиотечка не добавит. Или же ты хочешь сказать, чтобы ты бы написал подобный (с кучей вложенных селектов) sql запрос сам? )))
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>3. Умная оптимизация запросов с учётом особенностей конкретной СУБД. Вот такое действительно было бы очень интересно. И т.к. подобного точно нет в обсуждаемом C++ решение или тем более голых строках, то это реально могло бы подтвердить тезис о возможности Linq формировать более оптимальные запросы. Только вот не смотря на анонс существования данной возможности в Linq ORM ни единого (!) примера, подтверждающего это на практике, пока так и не было представлено. НС>А ты и не просил.
Просил в данной темке и не раз. Но никто не смог показать. Более того, и ты сейчас этого не сделал.
НС>Смотрим модель провайдера linq2db:
Так пример то можно или нет? )))
НС>Содержимое означенных классов ты можешь изучить самостоятельно.
Всё же фанаты linq такие забавные. ))) Уже второй предлагает мне самостоятельно заняться поиском аргументов для подтверждения высказанного им тезиса. Притом что у меня есть сомнения в верности самого этого тезиса. Очень заманчивое предложение. )))
Здравствуйте, alex_public, Вы писали:
_>Не забывай, что на каждый запрос страницы приходится несколько запросов в БД.
Хоть миллион.
_>Т.е. естественно это беспроблемно решается дополнительным железом, т.к. данная часть легко масштабируется горизонтально. Только вот зачем платить лишние деньги впустую?
Фактически с нагрузкой может справиться ровно один сервер. Остальное — надежность, майнтенанс и тд.
I>>Они полностью изменили архитектуру, целиком. Linq это ничтожная часть изменений, не самая важная. I>>Ты глаза раскрой — экономия от милисекунд на запрос, до максимум десятка милисекунд на запрос.
_>Я нигде и не говорил, что убирание linq является главной оптимизацией (главное там скорее в области Redis'a прячется, причём он у них похоже уже не просто как кэш работает). Но это очевидно необходимый пункт для построения нормальной системы.
Нет, не является необходимым. EF != linq. Ты все еще продолжаешь передёргивать
Здравствуйте, alex_public, Вы писали:
I>>Точнее ты просто игнорируешь, чего люди пишут и повторяешь одну и ту же мантру "а вот в C++ это лучше", и _постоянно_ намекаешь на квалификацию конкретного автора, дотнетчиков, фанатов linq, C# и тд и тд.
_>И? ) В чём проблема? Или кому-то тут сложно смириться с неприятной истиной? )
Ты не аргументруешь, а всего лишь пытаешься оскорбить, только намеками.
I>>Вот пример — когда тебе говорят, что твоё приложение надо перекомпилировать при смене базы, ты придираешься к количеству if, что бы понамекать, что автор не так проектирует. I>>Возникает ощущение, что ты вообще не понимаешь, ради чего твоё решение надо перекомпилировать и почему такое возможно.
_>Вот в том то и дело, что перекомпилировать его не надо. Но собеседник не может этого осознать в силу свой компетенции.
Итого — ты или врёшь, или некомпетентен. Вопрос был про то, как подключить _новую_ базу, провайдер и тд.
Здравствуйте, Ikemefula, Вы писали:
_>>И? ) В чём проблема? Или кому-то тут сложно смириться с неприятной истиной? ) I>Ты не аргументруешь, а всего лишь пытаешься оскорбить, только намеками.
Давай я тебе напомню ход дискуссии.
Всё началось с того, что я высказал тезис о тормознутости ORM на базе Linq. Примеры запросов в которых linq приводит к накладным расходам в 100-500% (в зависимости вида ORM) в теме имеются, так что непонятно какие ещё аргументы нужны. Хотя если кто-то не считает 100-500% накладных расходов существенным, то тут мне уже нечего сказать...
Далее, кто-то выдал контртезис, что пусть даже и есть такие накладные расходы, но зато эти ORM производят некие умные (т.е. не просто синтаксис, а как ты сам говорил какая-нибудь там замена join'a и т.п.) оптимизации под конкретную СУБД, которые полностью компенсируют эти расходы. Это естественно не является аргументов в случае сравнения с голыми sql строками (т.к. в них мы просто пишем под конкретную СУБД и естественно оптимально), но является аргументом в случае сравнения с той C++ библиотечкой на шаблонах, которая умеет генерировать код под каждую СУБД, но без всяких оптимизаций. Для подтверждения данного тезиса я попросил привести хотя бы один простейший пример (linq запрос и парочку разных sql запросов, соответствующих ему в разных СУБД). Однако так ни одного и не получил.
Так кому у нас тут стоит говорить об отсутствие аргументов? )
_>>Вот в том то и дело, что перекомпилировать его не надо. Но собеседник не может этого осознать в силу свой компетенции. I>Итого — ты или врёшь, или некомпетентен. Вопрос был про то, как подключить _новую_ базу, провайдер и тд.
Если надо подключить новую СУБД (в смысле которой раньше вообще не было в проекте), то надо добавить один #include, одну дополнительную ветку в if (который уже скорее всего есть) и пересобрать проект. И в чём проблема? ) Кстати, в случае linq решения тоже придётся обновлять дистрибутив (как минимум добавить одну dll).
Здравствуйте, alex_public, Вы писали:
_>Просил в данной темке и не раз. Но никто не смог показать. Более того, и ты сейчас этого не сделал.
А, ну как обычно, включаем дурака.
НС>>Смотрим модель провайдера linq2db:
_>Так пример то можно или нет? )))
Пример я тебе привел. Дальше только за деньги, потому что что то объяснять человеку, который специально понимать не хочет я бесплатно не буду.
НС>>Содержимое означенных классов ты можешь изучить самостоятельно. _>Всё же фанаты linq такие забавные
После того, как они купили мою компанию, которая занимается кластерными вычислениями. Я могу с некоторой долей авторитета утверждать, что примерно знаю почему используется Линукс.
Это "top x" у нас соответствует стандарту, да? ) Да и вообще MS славится своим отношением к стандартам во всём. )))