Здравствуйте, alex_public, Вы писали:
_>3. Умная оптимизация запросов с учётом особенностей конкретной СУБД. Вот такое действительно было бы очень интересно. И т.к. подобного точно нет в обсуждаемом C++ решение или тем более голых строках, то это реально могло бы подтвердить тезис о возможности Linq формировать более оптимальные запросы. Только вот не смотря на анонс существования данной возможности в Linq ORM ни единого (!) примера, подтверждающего это на практике, пока так и не было представлено. Так что данную возможность мы пока что считаем мифом.
Я напомню, что влез в эту под-ветку именно потому, что допиливал в своё время linq-провайдер специфичной мулькой под конкретную специфику. Оптимизация под частный случай с бд, запросами по сети и кешированием. При чем так, что бы весь вызывающий и вызываемый код не надо было переписывать.
Здравствуйте, Sinclair, Вы писали:
S>NoSQL в большинстве случаев это не решение вообще. Это подмена требований к задаче, чтобы делать не то, чего хотелось, а то, чего удалось. S>А если NoSQL не устраивает (например, требования к consistency пожёстче, чем у фоточек с лайками), то надо таки задуряться тем, чтобы писать хорошие SQL запросы.
Только хорошие запросы всё равно не помогут выше определённого уровня нагрузки, т.к. цена кластера быстренько уходит в небеса, по сравнению с аналогичным набором простеньких параллельных серверов.
S>А про "выкидывание впустую" вы промахнулись — это скорее о затратах на ручную полировку SQL запросов, которая нужна только из-за кривых инструментов программистов.
Ну так это же вечный вопрос. Что лучше потратиться на новое железо или же на зарплату программиста, умеющего оптимизировать код. 2000-ые у нас прошли под девизами "память больше не ресурс" и "всё равно через 1,5 года процессоры будут в 2 раза быстрее". Понятно какая точка зрения стала популярной в это время. Однако в начале появились смартфоны с их дохлыми процессорами и ограниченными аккумуляторами. А потом неожиданно оказалось, что и новые десктопные/серверные процессоры больше не приносят прироста в производительности. Все достижения сводятся к расширению SIMD и снижению энергопотребления. Разве что IBM придумала кое-что новенькое в своих Power8/9 и то только в области повышения пропускной способности к памяти (не говоря уже о специфической области применения этих процессоров), так что на индустрию это особо не повлияет. В итоге постепенно приоритеты начинают меняться. Разве что многим программистам будет сложновато, т.к. они уже давно отучились создать оптимальный код.
_>>Давай всё же определимся о чём конкретно идёт речь. А то в данной дискуссии похоже постоянно путаются три разные вещи: _>>1. Генерация sql кода с синтаксисом соответствующим конкретной СУБД. Имеется везде (и linq ORM и в том C++ решение на шаблонах и ещё много где). 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 естественно будет, но ровно один на всё приложение. Более того, я уже не только говорил об этом, но и показывал прямые примеры компилируемого кода.
_>>2. Частичная оптимизация изначально криво записанных запросов (вне зависимости от вида СУБД). Никчемная возможность, полезная разве что совсем новичкам, а профессионалам только мешающая (см. пример тех же SO). Нигде кроме Linq не видел (ну MS славится своими Визардами и т.п. игрушками для снижения порога входа, правда следствием становится сплошной индусо-код) и надеюсь не увидеть в будущем. S>Это вы сами себе придумали глупую мысль про изначально криво написанные запросы. В реальной жизни стоит задача декомпозировать выражения. Это означает, что возможности "некриво" написать запрос у вас нет. А есть только S>public double GetTotalComissionsAmount(IQueryable<Orders> orders, Employee salesManager);. При этом она описана в одном модуле, разработанном и поддерживаемом командой А. А используется она в десятке других модулей, разработанных и поддерживаемых командами Б, В и Г. И в неё передаются самые разные виды аргументов — где-то запрос вида from o in Orders where o.Date > startDate and o.Date <= endDate; где-то — запрос вида from o in Orders join it in db.OrderItems on o.id equals it.OrderId where it.ProductId = product select o; и так далее. S>Окончательный SQL собирается там, где он будет использован. Нет никакого "изначально кривого" кода, который мог бы соптимизировать какой-то профи. Ну, если только этот профи не готов заменить лично собой команды А, Б, В и Г и переписать весь модульный код в монолитную массу, вносить исправления в которую может только он.
Мда, что-то у тебя всё совсем печально выглядит с самыми основами проектирования. Даже если захотеть растащить прямую работу с БД по всему приложению (что впрочем уже не самое лучшее решение для серьёзного приложения, в отличие от построения полноценного DBAL), то для этого совершенно не обязательны такие кривые подходы как в Linq. Достаточно всего лишь добавить соответствующий параметр в нашу функцию, чтобы в зависимости от него она генерировала нужную разновидность запроса. А не создавать некий обобщённый запрос, который потом в рантайме будет ужиматься под конкретные случаи.
_>>3. Умная оптимизация запросов с учётом особенностей конкретной СУБД. Вот такое действительно было бы очень интересно. И т.к. подобного точно нет в обсуждаемом C++ решение или тем более голых строках, то это реально могло бы подтвердить тезис о возможности Linq формировать более оптимальные запросы. Только вот не смотря на анонс существования данной возможности в Linq ORM ни единого (!) примера, подтверждающего это на практике, пока так и не было представлено. Так что данную возможность мы пока что считаем мифом. S>Для начала я рекомендую ознакомиться с тем, сколькими способами Skip().Take() конвертируется в SQL. Это не синтаксис, это вопросы оптимизации с учётом особенностей конкретной СУБД.
Хыхы, забавно. В сообщениях выше я приводил именно это в качестве примера зависимости от синтаксиса (т.е. в точности пункт 1).
А там я вообще не понял что находится по ссылке. Какие-то потоки цифр, но при этом не указано вообще ничего ни про запросы, ни про результаты. Т.е. самого главного то нет. Сравни с тем, как представлено в первой ссылке. Из неё сразу понятна вся реальная картина (она же для разных задач разная!).
S>На самом деле многое зависит от тестов при инициализации БД (Configuration.AutoDetectChangesEnabled = false,Database.SetInitializer<Model1>(null)) S> , скорости компиляции первого запроса параметров которое может соизмеримо со временем теста, Метод AsNoTracking . Я тебе показывал примеры где автокомпиляции запросов не будет итд.
Ерунда это всё. В том смысле, что понятно что в нормальном приложение это всё будет максимально заоптимизировано. А реально влияет на результаты очень простая вещь: соотношения сложности запроса (грубо говоря linq кода) и времени выполнения запроса (зависит от объёма БД, индексов в ней, объёма результата запроса). Если у нас запрос выполняется долго, то очевидно, что все накладные расходы на его генерацию из linq кода незначительны. Если же запрос исполняется быстро (небольшая БД или большая, но запрос на индекс; небольшой объём возвращаемых данных), то накладные расходы могут стать весьма существенными.
И вот именно это фанаты linq почему-то не хотят признавать — распространяют миф, что linq будет хорош на любых условиях.
Здравствуйте, alex_public, Вы писали:
_>Ерунда это всё. В том смысле, что понятно что в нормальном приложение это всё будет максимально заоптимизировано. А реально влияет на результаты очень простая вещь: соотношения сложности запроса (грубо говоря linq кода) и времени выполнения запроса (зависит от объёма БД, индексов в ней, объёма результата запроса). Если у нас запрос выполняется долго, то очевидно, что все накладные расходы на его генерацию из linq кода незначительны. Если же запрос исполняется быстро (небольшая БД или большая, но запрос на индекс; небольшой объём возвращаемых данных), то накладные расходы могут стать весьма существенными. _>И вот именно это фанаты linq почему-то не хотят признавать — распространяют миф, что linq будет хорош на любых условиях.
Снова враньё. Существенными — с точки зрения чего ?
Я тебя прямо спрашиваю уже в третий раз — как ты собираешься улучшить пропускную способность не устраняя узкого места ?
Или у тебя узкое место это именно генерация запросов ?
Ты меряешь относительно мифического "нулевого оверхеда", а фанаты linq — с точки зрения узкого места, а их всего несколько — внешний хттп, внутрисетевой и дисковый io.
Ну да, linq2db конечно получше, всего 100% накладных расходов, а не 500%. ))) Кстати, а насколько EF популярнее linq2db? )
G>И не забывай про абсолютные цифры — это микросекунды. Выиграв даже 700 мкс на запрос ни время ответа, ни пропускная способность не изменится от слова вообще.
Да да, вечный твой фокус с рассмотрением вроде как смешных абсолютных цифр. Только вот если окажется, что у тебя и сам запрос имеет сравнимое время исполнения, то это уже резко станет не смешным.
_>>Ну так кто бы спорил, что если обслуживать исключительно запросы со временем исполнения в секунду и больше, то тормоза Linq даже в лупу не увидишь. Только вот что-то людям оказывается больше нужны совсем другие запросы (смотри тот же SO). G>Еще раз посмотри ссылку которую ты привел. Время обработки linq измеряется несколькими миллисекундами, а то и долями миллисекунд. Время выполнения запроса БД — несколько миллисекунд или несколько десятков. linq составляет не более 10% от времени запроса. То есть 10% — максимум что ты сможешь выиграть со всеми приседаниями.
10% — это в самом лучше для linq случае, когда долгий запрос возвращает кучу данных и применяем лучшую ORM. А в худших случаях совсем другие цифры (см. выше).
_>>Ну и даже если с 2008-го года существовал некий кривой костыль для данной функциональности (который они заменили на приличный синтаксис только в 2012-ом), то это всё равно смешно, т.к. с нормальными СУБД люди пользуются (и с нормальным синтаксисом) данной функциональностью уже не первое десятилетие. G>С чего ты взял что это костыль?
Ну даже если забыть о нормальных реализация уже давно имеющихся в других СУБД, то хотя бы из того, что они исправили это в 2012-ом году. ))) Причём реализовав как раз как у других было.
_>>Да, но я теперь больше понимаю почему дотнетчики так фанатеют от различных вариаций linq2database (буду так называть их все вместе, чтобы не было путаницы с одной конкретной). Многие из них обречены на работу с SQL Server, а похоже что писать для него чистый SQL крайне печально. Во всяком случае было ещё совсем не давно. ))) G>С чего твой больной мозг решил что написание SQL для других БД кардинально отличается?
У тебя мозг уже не способен связать два последовательных абзаца? ) Перечитай ещё пару разу предыдущий абзац)))
_>>А подтверждение нужно очень простое. Я уже не раз писал. Пример linq запроса и примеры оптимизированного им под конкретные СУБД sql кода. Что может быть проще? Но пока в теме не было ни одного такого примера. Хотя фанаты анонсировали именно такую возможность, как главное преимущество. G>Я не знаю о каком оптимизированном коде идет речь.
Ну это не ты заявлял, а некоторые другие местные фанаты. )
G>Я тебе уже многократно писал, что linq генерирует разные запросы для разного сочетания параметров и проекций. Именно это и дает максимальное быстродействие. G>Человек так не может — слишком сложно поддерживать все запросы. Никаких магических оптимизаций нет.
Да да, конечно не может. И написать код, генерирующий эти запросы он тоже не может. )))
_>>Ты научись читать внимательно. Речь не о том какой код в этой процедуре, а о самом факте написания процедуры. G>Ты совсем тупой чтоли? Нет разницы процедура или запрос. SQL работает одинаково, одинаковое кеширование планов, одинаковая параметризация, одинаково исполняются.
Это если запрос написать полностью аналогичный процедуре. Что сделает разве что какой-то альтернативно одарённый программист.
_>>Нормальный запрос — это sql строка, передаваемая некой функции типа sql_execute(""). Так вот я с большим удовольствием посмотрю на твой код (на том же C#) создания этой sql строки с использованием той же самой C# переменной dateTime, как в твоём linq варианте. _>>Подсказка-анонс: твой неоптимизированный sql вариант (с которым ты вроде как борешься и побеждаешь его с помощью linq) будет намного длиннее и неудобнее простейшего оптимизированного и соответственно встретится только у очень странных людей. G>Ты сейчас какой-то бред написал, я даже не понял что ты имеешь ввиду. Можешь код показать?
Повторяю по слогам. Ты показал linq код, делающий запрос на базе C# переменной. При этом аналогом его у тебя была некая абстрактная хранимка, висящая в воздухе, а не соответствующий C# код (без linq, на голом sql) делающий аналогичное из той же переменной. Попробуй его написать и может до тебя дойдёт о чём речь.
_>>Ну во-первых я писал в том числе и про windows. То, что ты отвечаешь только на удобную тебе часть моей фразы, для меня не новость. Во-вторых изменение платформы вполне себе влияет и на разработку, т.к. под линухом там запускают совсем не .net код. G>Насколько я понял все что обрабатывает запросы и написано в SO работает под windows.
А какая разница в какой компании написан софт? ) Мы же языки/платформы/библиотеки обсуждаем...
_>>Я же сказал, с C#, SQL Server и т.п. кактусами возитесь сами. У меня нет времени разбираться в их кривых костылях. Я готов повозиться только с C++ аналогом. Плюс, чтобы провести тесты на одной машине я готов запустить подготовленный мне пакет. ) G>От тебя требуется только написать и отладить код, который с SQL Server работет и выложить на github. G>Найдутся люди, которые достаточно хорошо знают и C# и C++, чтобы провести замеры. G>Так ты сделаешь? Виртуалку с уже установленным SQL Server и VS я дам.
Без проблем. ) Но с PostgreSQL ну или чем-то ещё приличным. С кактусами возитесь сами. Или Linq не умеет PostgreSQL?) Ну давай тогда возьмём что-нибудь совсем простенькое и популярное, типа sqlite. )))
Здравствуйте, Danchik, Вы писали:
_>>Ну что же. Для начала сразу хочу поставить тебе "большой плюс", потому что пока что это единственный пример хоть какой-то оптимизации в данной теме. Остальные не смогли показать даже этого. Но к сожалению данная оптимизация не относится к требуемому (прочитай хотя бы цитату выше, на которую ты отвечал), т.к. в ней нет никакой оптимизации под конкретную СУБД. Это пример из той же серии, что и убирание лишних полей из изначально криво записанных запросов и в приличном коде просто не требуется. Т.е. актуальная разве что для начинающих специалистов вещь, а профессионалам наоборот мешающая. В отличие от анонсированной в данной теме некой умной оптимизации под конкретную СУБД. Вот такое действительно пригодилось бы всем, но судя по отсутствию конкретных примеров данная возможность — это всего лишь миф. D>Не передергивай, я тебе показал что оптимизации есть. Я написал ее в коде который общий для ВСЕХ SQL драйверов. Никто мне не мешал закинуть это только для Oracle
моего сообщения. В том время как я жду хоть какого-нибудь примера для пункта 3.
D>Такие же оптимизаторы есть под каждую базу, и там дерево выражений может существенно изменится. Беглый взгляд по сурцам показывает что сейчас отличия незначительны, просто более тонко используют служебные функции, НО они (оптимизации) возможны. Есть идеи — допиливай.
Эммм, ну так а кто-то разве утверждал, что они теоретически невозможны? ) Конечно возможны. Более того, они без проблем возможны и в той библиотечке на C++. Весь вопрос в том что имеется на данный момент...
Здравствуйте, Ikemefula, Вы писали:
_>>В случае отображения файла на фиксированную структуру очевидно, что никакие запросы не требуются в принципе. I>Вот чудо !. Вот пример — надо найти все проводки по всем юзерам за весь период времени которые удовлетворяют определенному фильтру. Наверное ты собираешься гигабайты дисковой памяти прокачивать через оперативу ?
Кончай придуриваться, если хочешь чтобы с тобой продолжали общение. В моих предыдущих сообщениях было всё чётко сформулировано. И области применимости каждого решения и сравнимое быстродействие. Если же ты не придуриваешься и реально не смог этого увидеть, то тем более нет смысла продолжать.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
_>>>В случае отображения файла на фиксированную структуру очевидно, что никакие запросы не требуются в принципе. I>>Вот чудо !. Вот пример — надо найти все проводки по всем юзерам за весь период времени которые удовлетворяют определенному фильтру. Наверное ты собираешься гигабайты дисковой памяти прокачивать через оперативу ?
_>Кончай придуриваться, если хочешь чтобы с тобой продолжали общение. В моих предыдущих сообщениях было всё чётко сформулировано. И области применимости каждого решения и сравнимое быстродействие. Если же ты не придуриваешься и реально не смог этого увидеть, то тем более нет смысла продолжать.
А надо было показать решение задачи из 4х пунктов или же прямо сказать — велосипед на файлах не поможет.
Ты, по обыкновению, переформулировал задачу из 4х пунктов в 4 независимые задачи. И кто из нас придуривается ?
Здравствуйте, Ikemefula, Вы писали:
_>>И вот именно это фанаты linq почему-то не хотят признавать — распространяют миф, что linq будет хорош на любых условиях. I>Снова враньё. Существенными — с точки зрения чего ? I>Я тебя прямо спрашиваю уже в третий раз — как ты собираешься улучшить пропускную способность не устраняя узкого места ? I>Или у тебя узкое место это именно генерация запросов ? I>Ты меряешь относительно мифического "нулевого оверхеда", а фанаты linq — с точки зрения узкого места, а их всего несколько — внешний хттп, внутрисетевой и дисковый io.
Там нет узкого места только в том смысле, что в отличие от РСУБД данные системы легко поддаются горизонтальному масштабированию. Т.е. грубо говоря покупка дополнительных X серверов полностью решает проблему (в отличие от ситуации с тормозящей РСУБД). Только вот подобное "решение" далеко не всем нравится с точки зрения бизнеса. ))) Тем же SO явно не захотелось иметь 300+ серверов (как им пришлось бы иметь при текущей нагрузке и старой архитектуре), вместо текущего расклада.
Здравствуйте, Ikemefula, Вы писали:
_>>Кончай придуриваться, если хочешь чтобы с тобой продолжали общение. В моих предыдущих сообщениях было всё чётко сформулировано. И области применимости каждого решения и сравнимое быстродействие. Если же ты не придуриваешься и реально не смог этого увидеть, то тем более нет смысла продолжать. I>А надо было показать решение задачи из 4х пунктов или же прямо сказать — велосипед на файлах не поможет. I>Ты, по обыкновению, переформулировал задачу из 4х пунктов в 4 независимые задачи. И кто из нас придуривается ?
Ты там смеялась над чьим-то тезисом, что система на базе отображаемого в память файла будет быстрее SQL БД. А я всего лишь прокомментировал, что на определённом классе задач этот тезис действительно будет справедлив. Что в этом некорректного?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
_>>>И вот именно это фанаты linq почему-то не хотят признавать — распространяют миф, что linq будет хорош на любых условиях. I>>Снова враньё. Существенными — с точки зрения чего ? I>>Я тебя прямо спрашиваю уже в третий раз — как ты собираешься улучшить пропускную способность не устраняя узкого места ? I>>Или у тебя узкое место это именно генерация запросов ? I>>Ты меряешь относительно мифического "нулевого оверхеда", а фанаты linq — с точки зрения узкого места, а их всего несколько — внешний хттп, внутрисетевой и дисковый io.
_>Там нет узкого места только в том смысле, что в отличие от РСУБД данные системы легко поддаются горизонтальному масштабированию.
Ты в курсе, что физически весь процессинг SO может выдержать один единственный сервер ? По твоей ссылке это сказано явно.
Это значит, что 11 серверов есть просто резервирование, для надежности и упрощения майнтенанса.
>Т.е. грубо говоря покупка дополнительных X серверов полностью решает проблему (в отличие от ситуации с тормозящей РСУБД). Только вот подобное "решение" далеко не всем нравится с точки зрения бизнеса. ))) Тем же SO явно не захотелось иметь 300+ серверов (как им пришлось бы иметь при текущей нагрузке и старой архитектуре), вместо текущего расклада.
Даппер, ссылки были дадены, нынче не самое быстрое решение. И судя по тому, что его никто не выпиливает из SO, очевидно ты и здесь попутал.
Здравствуйте, alex_public, Вы писали:
_>>>Кончай придуриваться, если хочешь чтобы с тобой продолжали общение. В моих предыдущих сообщениях было всё чётко сформулировано. И области применимости каждого решения и сравнимое быстродействие. Если же ты не придуриваешься и реально не смог этого увидеть, то тем более нет смысла продолжать. I>>А надо было показать решение задачи из 4х пунктов или же прямо сказать — велосипед на файлах не поможет. I>>Ты, по обыкновению, переформулировал задачу из 4х пунктов в 4 независимые задачи. И кто из нас придуривается ?
_>Ты там смеялась над чьим-то тезисом, что система на базе отображаемого в память файла будет быстрее SQL БД. А я всего лишь прокомментировал, что на определённом классе задач этот тезис действительно будет справедлив. Что в этом некорректного?
В вырожденных случаях — будет. Например, в десктоп приложении или мобайл
А вообще забавно наблюдать, как ты выступаешь
1. в разговоре 'где узкое место' ты выступаешь в духе 'а в с++ лучше'
2. в разговоре 'как работает база' ты выступаешь 'а в с++ нулевой оверхед !'
3. 'как работает хаскель' у тебя 'а в с++ все еще круче'
4. 'как работает динамика C#' у тебя 'а в с++ все вообще статикой делается'
Любой вопрос, который возникал за последние года три, ты уверенно сводишь или к С++, или к D.
Попробуй как нибудь на досуге отвечать на вопросы прямо, без увиливаний. А то сначала ты до посинения защищаешь С++, а потом выдаёшь общие слова 'на определённом классе задач этот тезис действительно будет справедлив'.
Здравствуйте, Ikemefula, Вы писали:
I>Ты в курсе, что физически весь процессинг SO может выдержать один единственный сервер ? По твоей ссылке это сказано явно. I>Это значит, что 11 серверов есть просто резервирование, для надежности и упрощения майнтенанса.
Не только для резервирования. Не забывай про время отклика — если запросов больше чем ядер (а у них именно так и есть), то они в начале ещё в очереди постоят...
Но в любом случае, даже если бы у них сейчас работал вообще один сервер, то это только бы ещё больше подтвердило мои слова. О том насколько существенно они оптимизировали свою архитектуру относительно изначальной (которая была на linq).
I>Даппер, ссылки были дадены, нынче не самое быстрое решение. И судя по тому, что его никто не выпиливает из SO, очевидно ты и здесь попутал.
Да, да, тут у некоторых товарищей с помощью лёгкого волшебства linq2db ещё и заметно быстрее прямого доступа к БД получался. Помним помним. )))
Здравствуйте, Ikemefula, Вы писали:
I>А вообще забавно наблюдать, как ты выступаешь I>1. в разговоре 'где узкое место' ты выступаешь в духе 'а в с++ лучше' I>2. в разговоре 'как работает база' ты выступаешь 'а в с++ нулевой оверхед !' I>3. 'как работает хаскель' у тебя 'а в с++ все еще круче' I>4. 'как работает динамика C#' у тебя 'а в с++ все вообще статикой делается' I>Любой вопрос, который возникал за последние года три, ты уверенно сводишь или к С++, или к D. I>Попробуй как нибудь на досуге отвечать на вопросы прямо, без увиливаний. А то сначала ты до посинения защищаешь С++, а потом выдаёшь общие слова 'на определённом классе задач этот тезис действительно будет справедлив'.
1. Хы, какая забавная аналитика. ))) Точнее просто статистика, потому что до собственно аналитики ты так и не дошёл. ))) Например даже начинающий аналитик сразу бы предположил, что я просто только и отвечаю на такие вопросы/темы, где можно дать ответ типа "а вот в C++ это лучше", хотя бы вследствие моей компетенции. А в остальных дискуссиях просто не участвую. )
2. Ты похоже забыл, что динамические языки я тоже вполне себе уважаю и защищаю (особенно Питончика). Только опять же в своей области применимость, а не как универсальный инструмент для всего.
3. Ну и если уж говорить про статические языки, то к самому C++ у меня есть тоже много претензий. Поэтому я внимательно смотрю на все языки потенциально способные его заменить: D, Rust, Nim, Swift. Они все очень разные с разными концепциями и целевыми аудиториями. К сожалению пока ни один из них не способен на практике стать полноценной заменой C++, разве что в отдельных узких областях. А хотелось бы. Хотя есть ещё надежда что в следующем стандарте (в следующем году выходит) доработают парочку самых больших недостатков современного C++ и тогда вопрос о поиске альтернативы C++ перестанет быть так актуален.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>Вот прямо здесь http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html в тесте "Simple TOP 10 query" EF показывает такие феерические результаты. G>>А при чем тут EF? Ты на linq2db смотри, он пока самый быстрый в этом забеге.
_>Ну да, linq2db конечно получше, всего 100% накладных расходов, а не 500%. )))
Да хоть 10000%, относительные величины не имеют никакого смысла.
Имеет смысл влияние скорости linq на время ответа и пропускную способность. Причем в реальном приложении, а не синтетическом тесте.
G>>И не забывай про абсолютные цифры — это микросекунды. Выиграв даже 700 мкс на запрос ни время ответа, ни пропускная способность не изменится от слова вообще. _>Да да, вечный твой фокус с рассмотрением вроде как смешных абсолютных цифр. Только вот если окажется, что у тебя и сам запрос имеет сравнимое время исполнения, то это уже резко станет не смешным.
Кончай показывать свой профанизм.
В тесте много раз повторяется один и тот же запрос. В реальном приложении такое случается чуть реже, чем никогда. Если действительно нужны одни и те же данные, то они будут тупо закешированы и никаких запросов в базу не будет. Если данные разные, то время запроса в базу окажется сильно выше, чем в тесте.
Поэтому в реальности, на очень простых можно уменьшит время ответа на 10% максимум.
Ты вообще понимаешь разницу между синтетическим тестом и реальным приложением? Похоже что нет.
_>>>Ну и даже если с 2008-го года существовал некий кривой костыль для данной функциональности (который они заменили на приличный синтаксис только в 2012-ом), то это всё равно смешно, т.к. с нормальными СУБД люди пользуются (и с нормальным синтаксисом) данной функциональностью уже не первое десятилетие. G>>С чего ты взял что это костыль?
_>Ну даже если забыть о нормальных реализация уже давно имеющихся в других СУБД, то хотя бы из того, что они исправили это в 2012-ом году. ))) Причём реализовав как раз как у других было.
Ок, если ты настолько глуп — объясняю.
SQL Server очень хорошо следует стандартам. В стандартах ANSI не было (и насколько я знаю до сих пор нету) штатного способа разбиения резалтсета на страницы. Было через курсоры, но реализация курсоров оказывается медленнее операций с множествами.
Поэтому в T-SQL долго не включали операторы постраничного разбиения. А вот ranking functions как раз в стандарте есть и через них прекрасно делается разбиение на страницы.
Только в конце 2000-х стало очевидно, что на стандарт уже все положили болт и тогда добавили операторы в T-SQL.
_>>>Да, но я теперь больше понимаю почему дотнетчики так фанатеют от различных вариаций linq2database (буду так называть их все вместе, чтобы не было путаницы с одной конкретной). Многие из них обречены на работу с SQL Server, а похоже что писать для него чистый SQL крайне печально. Во всяком случае было ещё совсем не давно. ))) G>>С чего твой больной мозг решил что написание SQL для других БД кардинально отличается? _>У тебя мозг уже не способен связать два последовательных абзаца? ) Перечитай ещё пару разу предыдущий абзац)))
Ок, давай возьмем современные версии двух движков и ты на примере покажешь чем pl\sql в Postgres кардинально отличается от T-SQL. Ты не сможешь этого сделать. Поэтому все твои рассуждения — бредятина.
_>>>А подтверждение нужно очень простое. Я уже не раз писал. Пример linq запроса и примеры оптимизированного им под конкретные СУБД sql кода. Что может быть проще? Но пока в теме не было ни одного такого примера. Хотя фанаты анонсировали именно такую возможность, как главное преимущество. G>>Я не знаю о каком оптимизированном коде идет речь. _>Ну это не ты заявлял, а некоторые другие местные фанаты. )
Ты просто не понимаешь о чем они пишут.
Они тебе говорят что для разных движков и даже разных версий одного движка одно и то же логическое выражение может быть записано по разному и давать разное быстродействие. Это означает, что в compile-time ты не сможешь сгенерировать оптимальный запрос к БД в принципе, а в runtime это можно сделать.
Я тебе говорю о том, что даже в рамках одного движка linq с легкостью сгенерирует сотни похожих запросов и каждый будет оптимальным для своего сценария, а руками даже десять таких запросов написать и поддерживать невозможно.
G>>Я тебе уже многократно писал, что linq генерирует разные запросы для разного сочетания параметров и проекций. Именно это и дает максимальное быстродействие. G>>Человек так не может — слишком сложно поддерживать все запросы. Никаких магических оптимизаций нет. _>Да да, конечно не может. И написать код, генерирующий эти запросы он тоже не может. )))
Если сможет, тогда у него получится linq. Или придется жертвовать выразительной силой, получая в итоге более универсальные и более тормозящие запросы. Ты же так и не смог показать генератор запросов, аналогичный linq по мощности, но без оверхеда.
_>>>Ты научись читать внимательно. Речь не о том какой код в этой процедуре, а о самом факте написания процедуры. G>>Ты совсем тупой чтоли? Нет разницы процедура или запрос. SQL работает одинаково, одинаковое кеширование планов, одинаковая параметризация, одинаково исполняются. _>Это если запрос написать полностью аналогичный процедуре. Что сделает разве что какой-то альтернативно одарённый программист.
Ты опять не понимаешь что тебе пишут. Почитай чтоли мануалы на досуге. Если взять один и тот же запрос и завернуть его в процедуру или вызывать текстом из кода, то в подавляющем большинстве случаев они будут исполняться абсолютно одинаково.
_>Повторяю по слогам. Ты показал linq код, делающий запрос на базе C# переменной. При этом аналогом его у тебя была некая абстрактная хранимка, висящая в воздухе, а не соответствующий C# код (без linq, на голом sql) делающий аналогичное из той же переменной. Попробуй его написать и может до тебя дойдёт о чём речь.
Ты хочешь сказать, что надо подставлять параметр в текст запроса, а не использовать механизм параметров?
Ты опять показал свой профанизм.
Подстановка параметров имеет два огроменных недостатка:
1) SQL-инъекции в случае текстовых параметров, они гарантированно будут. Надежного метода экранирования практически нет.
2) Каждый запрос будет компилироваться по новой. Это мееедленно и кушает память базы на хранение планов.
С твоим подходом быстродействие упадет и приложение станет более уязвимым.
Так что брось сразу эту затею и читай мануалы.
_>>>Ну во-первых я писал в том числе и про windows. То, что ты отвечаешь только на удобную тебе часть моей фразы, для меня не новость. Во-вторых изменение платформы вполне себе влияет и на разработку, т.к. под линухом там запускают совсем не .net код. G>>Насколько я понял все что обрабатывает запросы и написано в SO работает под windows. _>А какая разница в какой компании написан софт? ) Мы же языки/платформы/библиотеки обсуждаем...
Не знаю что ты обсуждаешь, а меня инересуют что делают парни из SO.
Парни из SO пишут код на C# и запускают его под вендой. А сторонние продукты запускают по nix потому что это дешевле.
Тут никаких идеологических мотивов нет, только экономические.
_>>>Я же сказал, с C#, SQL Server и т.п. кактусами возитесь сами. У меня нет времени разбираться в их кривых костылях. Я готов повозиться только с C++ аналогом. Плюс, чтобы провести тесты на одной машине я готов запустить подготовленный мне пакет. ) G>>От тебя требуется только написать и отладить код, который с SQL Server работет и выложить на github. G>>Найдутся люди, которые достаточно хорошо знают и C# и C++, чтобы провести замеры. G>>Так ты сделаешь? Виртуалку с уже установленным SQL Server и VS я дам.
_>Без проблем. ) Но с PostgreSQL ну или чем-то ещё приличным. С кактусами возитесь сами.
Ясно, слился.
_>Или Linq не умеет PostgreSQL?) Ну давай тогда возьмём что-нибудь совсем простенькое и популярное, типа sqlite. )))
Все умеет, но никто не будет адаптировать существующие тесты для других движков. Это же не просто поставить постгрес, надо еще базу перенести, текстовые запросы переписать. Никто для тебя этого делать не будет.
Или сам, или используй готовую базу на SQL Server.
Но помоему уже все поняли, что доказать свои слова ты не можешь.
Можешь не продолжать писать. Большего профана наверное на всем форуме не найдешь.
Здравствуйте, gandjustas, Вы писали:
G>Не знаю что ты обсуждаешь, а меня инересуют что делают парни из SO.
Мигрируют на аналог NoSQL, используя Redis в качестве оперативного хранилища и MSSQL как транзакционный лог. Кстати, все данные они там хранят в памяти.
G>Парни из SO пишут код на C# и запускают его под вендой. А сторонние продукты запускают по nix потому что это дешевле. G>Тут никаких идеологических мотивов нет, только экономические.
Идеологическая причина простая — Линукс банально удобнее.
Здравствуйте, alex_public, Вы писали:
I>>Ты в курсе, что физически весь процессинг SO может выдержать один единственный сервер ? По твоей ссылке это сказано явно. I>>Это значит, что 11 серверов есть просто резервирование, для надежности и упрощения майнтенанса.
_>Не только для резервирования. Не забывай про время отклика — если запросов больше чем ядер (а у них именно так и есть), то они в начале ещё в очереди постоят...
Сказано было — с нагрузкой справляется один сервер. Научись читать свои же ссылки.
_>Но в любом случае, даже если бы у них сейчас работал вообще один сервер, то это только бы ещё больше подтвердило мои слова. О том насколько существенно они оптимизировали свою архитектуру относительно изначальной (которая была на linq).
linq это не архитектура, это способ работы с базой.
_>Да, да, тут у некоторых товарищей с помощью лёгкого волшебства linq2db ещё и заметно быстрее прямого доступа к БД получался. Помним помним. )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
I>>А вообще забавно наблюдать, как ты выступаешь I>>1. в разговоре 'где узкое место' ты выступаешь в духе 'а в с++ лучше' I>>2. в разговоре 'как работает база' ты выступаешь 'а в с++ нулевой оверхед !' I>>3. 'как работает хаскель' у тебя 'а в с++ все еще круче' I>>4. 'как работает динамика C#' у тебя 'а в с++ все вообще статикой делается' I>>Любой вопрос, который возникал за последние года три, ты уверенно сводишь или к С++, или к D. I>>Попробуй как нибудь на досуге отвечать на вопросы прямо, без увиливаний. А то сначала ты до посинения защищаешь С++, а потом выдаёшь общие слова 'на определённом классе задач этот тезис действительно будет справедлив'.
_>1. Хы, какая забавная аналитика. ))) Точнее просто статистика, потому что до собственно аналитики ты так и не дошёл. )))
... _>я просто только и отвечаю на такие вопросы/темы, где можно дать ответ типа "а вот в C++ это лучше", хотя бы вследствие моей компетенции
Точнее ты просто игнорируешь, чего люди пишут и повторяешь одну и ту же мантру "а вот в C++ это лучше", и _постоянно_ намекаешь на квалификацию конкретного автора, дотнетчиков, фанатов linq, C# и тд и тд.
Вот пример — когда тебе говорят, что твоё приложение надо перекомпилировать при смене базы, ты придираешься к количеству if, что бы понамекать, что автор не так проектирует.
Возникает ощущение, что ты вообще не понимаешь, ради чего твоё решение надо перекомпилировать и почему такое возможно.
Здравствуйте, gandjustas, Вы писали:
_>>>>Ну и даже если с 2008-го года существовал некий кривой костыль для данной функциональности (который они заменили на приличный синтаксис только в 2012-ом), то это всё равно смешно, т.к. с нормальными СУБД люди пользуются (и с нормальным синтаксисом) данной функциональностью уже не первое десятилетие. G>>>С чего ты взял что это костыль?
Да он просто не знает ничего. Он примитивный запрос не может составить, о чем вообще с ним разговаривать в плане РСУБД?
G>SQL Server очень хорошо следует стандартам. В стандартах ANSI не было (и насколько я знаю до сих пор нету) штатного способа разбиения резалтсета на страницы.
В последнюю версию точно включили, может даже еще с предпоследней (2008). Причем именно тот синтаксис, что поддерживается T-SQL
с 2012-й версии.
Правда в тех драфтах стандарта, что есть у меня, он несколько более расширенный, а каков он в официальной версии 2011 я не знаю,
т.к. покупать не собираюсь.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Не знаю что ты обсуждаешь, а меня инересуют что делают парни из SO. C>Мигрируют на аналог NoSQL, используя Redis в качестве оперативного хранилища и MSSQL как транзакционный лог. Кстати, все данные они там хранят в памяти.
В блогах подтверждений нет. Это твои фантазии.
Redis в SO используется как кэш, ms sql — как хранилище данных.
G>>Парни из SO пишут код на C# и запускают его под вендой. А сторонние продукты запускают по nix потому что это дешевле. G>>Тут никаких идеологических мотивов нет, только экономические. C>Идеологическая причина простая — Линукс банально удобнее.
Опять фантазии, ник пишет лишь о том, что это "better money allocation", а не про удобства.
