Здравствуйте, Sinclair, Вы писали:
_>>Так некий абстрактный "взрослый движок в сервере приложений" в теории "может" это обнаружить или же есть конкретный движок, который вот таких образом на практике оптимизирует вот этот конкретный пример? S>Да, linq2db выбрасывает дегенеративные джойны. S>Вот, например: S>
S> using (var db = new DbOrderTests())
S> {
S> var allOrders = from oi in db.OrderItems
S> group oi by oi.OrderId into og
S> from o in db.Orders.Where(q=>q.Id == og.Key).DefaultIfEmpty()
S> select new { OrderId = og.Key, Amount = og.Sum(oi => oi.Amount), o.Counterparty, o.CreationDate };
S> var orderProjection = from a in allOrders select a.OrderId;
S> foreach (var id in orderProjection)
S> Console.WriteLine(id);
S> }
S>
S>В сервер уезжает вот такой вот SQL: S>
S>SELECT
S> [t2].[OrderId] as [OrderId1]
S>FROM
S> (
S> SELECT
S> [t1].[OrderId]
S> FROM
S> [OrderItems] [t1]
S> GROUP BY
S> [t1].[OrderId]
S> ) [t2]
S>
S>При этом если я попробую материализовать не orderProjection, а allOrders, то исполнится запрос вместе с джойном: S>
S>SELECT
S> [t2].[OrderId] as [OrderId1],
S> [t2].[c1] as [c11],
S> [q].[Counterparty],
S> [q].[CreationDate]
S>FROM
S> (
S> SELECT
S> [t1].[OrderId],
S> Sum([t1].[Amount]) as [c1]
S> FROM
S> [OrderItems] [t1]
S> GROUP BY
S> [t1].[OrderId]
S> ) [t2]
S> LEFT JOIN [Orders] [q] ON [q].[Id] = [t2].[OrderId]
S>
Как автор даной оптимизации, скажу что здесь непорядок. Сабселект тоже надо убрать. Займусь на досуге.
Ну и хотелось бы чтобы пользовались новыми, легко читаемыми, расширениями для джоинов LeftJoin
Здравствуйте, Danchik, Вы писали:
D>Как автор даной оптимизации, скажу что здесь непорядок. Сабселект тоже надо убрать. Займусь на досуге. D>Ну и хотелось бы чтобы пользовались новыми, легко читаемыми, расширениями для джоинов LeftJoin
Ещё я тут не разобрался, как объяснить движку, что OrderID — это ForeignKey. Тогда устраняться должен и inner join, как не влияющий на rowset.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[92]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Danchik, Вы писали:
D>>Как автор даной оптимизации, скажу что здесь непорядок. Сабселект тоже надо убрать. Займусь на досуге. D>>Ну и хотелось бы чтобы пользовались новыми, легко читаемыми, расширениями для джоинов LeftJoin S>Ещё я тут не разобрался, как объяснить движку, что OrderID — это ForeignKey. Тогда устраняться должен и inner join, как не влияющий на rowset.
Ход ваших мыслей понял, вот не додумался до этого или забыл . Пока никак, движок пока работает только по primary key, и тут тоже уникальные индексы бы помогли, которые мы никак не учитываем. Гляну что можно сделать с foreign key, тоесть сделаю если вся необходимая информация есть в метаданных. Надеюсь никто матерится не будет если мы также пропроцесим foreign key созданный с хинтом with nocheck?
Здравствуйте, Danchik, Вы писали:
D>Все таки SQL сервер такое оптимизирует, но да, для других молодых баз данных это было бы ускорением. D>https://sqlperformance.com/2018/06/sql-performance/join-elimination-unnecessary-tables
Вот удивительно, всё-таки, как мир устроен. Сидим тут, спорим, и как раз параллельно чуваки из МС рассказывают ровно про эту тему
Проверил на своём 2017 експресс — вырезает.
Допилили-таки! Интересно, а допилили ли они переупорядочивание group by / join?
Это вторая из самых популярных semantic optimizations, которые раньше никто делать не умел.
Имеется в виду вот такой случай:
select city.id, city.Name, sum(o.amount)
from orders o
inner join city on o.Customer_City = city.id
group by city.id, city.Name
Семантически этот запрос строго эквивалентен
select city.id, city.Name, amount
from city inner join
(select Customer_City, sum(amount) as amount from orders group by orderId) o
on o.Customer_City = city.id
Благодаря, понятное дело, тому, что city.id — это PK, и дальнейшие группировки по зависимым полям этой таблицы нам гарантированно ничего не дадут.
При этом стоимость этих двух запросов отличается достаточно сильно — в клинических случаях в разы, т.к. group by по большим промежуточным результатам — это упс.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[94]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Danchik, Вы писали:
D>>Все таки SQL сервер такое оптимизирует, но да, для других молодых баз данных это было бы ускорением. D>>https://sqlperformance.com/2018/06/sql-performance/join-elimination-unnecessary-tables S>Вот удивительно, всё-таки, как мир устроен. Сидим тут, спорим, и как раз параллельно чуваки из МС рассказывают ровно про эту тему S>Проверил на своём 2017 експресс — вырезает. S>Допилили-таки! Интересно, а допилили ли они переупорядочивание group by / join? S>Это вторая из самых популярных semantic optimizations, которые раньше никто делать не умел.
[skip] S>При этом стоимость этих двух запросов отличается достаточно сильно — в клинических случаях в разы, т.к. group by по большим промежуточным результатам — это упс.
Антон, присоединайся к команде. Иногда нам не видно со своей подземной колокольни что пропустили. И, как бонус, хотелки от членов команды идут в приоритете. Просто напиши в issues — добавьте меня, Slack нам в помощь.
Re[90]: В России опять напишут новый объектно-ориентированны
. S>Там представлены разные мнения на тему того, что и как понятнее.
Интересное исследование. Только вот к нашей теме оно не имеет никакого отношение. Это исследование про оптимизацию выполнения специфического семейства алгоритмов (с обходом двухмерного массива) на языке C#. А к теме linq это исследование никакого отношения не имеет (ну не считая заголовка).
Это очень легко проверить каждому на практике. Достаточно заменить прямо в твоём коде запуск алгоритма с "from d in data select ... " на "map2d(data, d=>...)" и соответственно переименовать твою функцию select в map2d. После этого можно убирать из проекта ссылки на Linq (т.е. весь твой код будет работать без import System.Linq) и при этом получать в точности тот же самый результат. И по производительности и по уровню разделения описания и реализации алгоритма. Т.е. да, ты добился интересного тебе уровня абстрагирования и даже с хорошей (для C#) производительностью, но это произошло не с помощью linq, а помощью совершенно других возможностей C#.
Покажу тебе сейчас как это выглядит со стороны. Вот предположим я напишу на C# алгоритм численного решение обычного дифференциального уравнения. Причём этот алгоритм будет не простой, а благодаря хитрым оптимизация в несколько раз эффективнее стандартной реализации. Потом я возьму какой-нибудь класс из WPF (ну там контрол какой-нибудь, типа кнопки), пронаследуюсь от него и добавлю в своего потомка новый метод SolveODE, в который вставлю этот свой алгоритм. Потом напишу тестовый пример, вызывающий мой алгоритм через экземпляр кнопки и в итоге опубликую на форуме занимательную статью под названием "Использование всей мощи WPF позволяет решать дифференциальные уравнения в разы быстрее!". Как тебе такая история? А весь это стопроцентная аналогия твоего исследования...
Да, и что самое обидное, подобная подача в каком-то смысле компрометирует реально интересную часть исследования. Потому как у меня может быть там действительно очень интересный подход к решению уравнений, но при такой подаче этого никто не заметит и будут только смеяться над тем зачем тут было WPF.
S>vdimas, например, указывает на некорректность кода — по краям-то у нас тёмная каёмка. S>Можно попробовать написать корректный код на "тупом for в лоб" и посмотреть, останется ли он столь же понятным, как и select from.
мой старый тест, то легко увидишь очень знакомый (и вроде как некорректный, причём даже дважды) код. А так же сразу же увидишь какие интересные картинки он способен генерировать (особенно если подождать какое-то время).
_>>Угу, меняем в нашем for арифметические операторы языка на интринсики для SIMD оптимизации или добавляем OpenACC директивы для ускорения на GPU. S>Я с удовольствием посмотрю на конкретный пример c4-фильтра с интринсиками и OpenACC.
Так с OpenACC код вообще не изменится — надо только добавить пару прагм и всё. А вот с интринсиками конечно всё сложнее (это же по сути чистый ассемблер, только абстрагированный от конкретного семейства процессоров) и к ним прибегают только если действительно очень очень нужная оптимизация (ну или в библиотечном коде типа Eigen).
S>Они, кстати, взаимно совместимы?
Естественно нет (если мы говорим об одном коде, а не о просто использование в одном проекте), т.к. интринсиками — это рукопашный код, а OpenACC — это автоматический инструмент, генерирующий код сам (кстати, он умеет в том числе и SIMD на CPU, а не только GPU). Рукопашный всё ещё оптимальнее, но намного дольше в написание.
S>Или мне надо собирать екзещник отдельно под каждую целевую архитектуру?
Ты можешь написать две версии своего алгоритма с помощью эти разных технологий и вызывать потом нужную в рантайме, в зависимости от железа. Более того, т.к. SIMD реализации бывают разные даже для одной архитектуры процессора (SSE2, SSE4, AVX, AVX2 и т.д.), то многие инструменты уже умеют делать автоматически (например gcc умеет самостоятельно собирать N версий нужных функций под каждую архитектуру из указанного списка и потом автоматически вызывать в коде нужную, в зависимости от железа).
_>>Эм, а откуда у нас вообще взялась работающая функция Select? Напомню, что мы говорим о случае, когда готовой библиотеки алгоритмов нет и надо писать всё самому. S>Например, иы пишем её сами. Минимальная работоспособная функция Select состоит из четырёх строчек, и её достаточно для того, чтобы прогнать функциональные тесты. S>То есть суммарно у нас примерно столько же кода (плюс-минус лапоть), сколько и в "тупом императивном for", только этот код разазан по двум местам.
Т.е. по сути ты говоришь о том, что при написание нашего for мы разнесём внутри нашего приложения точки задания его тела и собственно самого цикла.
Ну и даже если забыть о том, что для такого абстрагирования linq не нужен в принципе, есть ещё один существенный нюанс — этот код получается изначально менее производительным. А чтобы добиться аналогичной производительности, тебе понадобятся уже нетривиальные усилия по оптимизации.
_>>Или быть может ты реально считаешь, что идея написать ручной рантаймовый разбор AST — это и есть "пишем максимально понятный и короткий код"? S>Нет, ручной рантаймовый разбор AST — это трудная (по крайней мере для меня) задача. S>Но тут есть нюанс: S>1. Мы откладываем её решение до момента, когда нам известно, где в коде узкое место. Это позволяет нам лучше использовать ограниченные ресурсы.
И при этом вполне есть вероятность, что без подобного абстрагирования (всё же в C# оно не бесплатно) производительности было бы достаточно.
S>2. Если программа состоит из чего-то большего, чем однократный вызов одного алгоритма фильтрации (а обычно так и бывает), то наши инвестиции в оптимизацию "ручного рантаймового разбора AST" начинают окупаться, т.к. они делаются один раз. А расставлять интринсики и директивы надо в каждом цикле вручную.
Ну, с учётом устройства существующей реализации Linq (я естественно говорю про работу с генерируемым компилятором AST, потому как всё остальное абсолютно не интересно и не нужно), подобная реализация будет всё равно менее эффективнее ручной.
Хотя степень этой неэфективности будет уже зависеть от объёма данных (т.к. оверхед вносимый кривизной реализации linq пропорционален сложности алгоритма, а не объёму данных и соответственно при больших объёмах размывается на фоне общего времени исполнения).
_>>Если говорить об оптимизаторах SQL (это отдельная тема, ортогональная генераторам SQL по DSL), то мне не очень понятно почему ты считаешь, что они возможны только в реализации через Linq? Это помимо того, что есть большой вопрос в необходимости подобных оптимизаторов вне СУБД. S>Не обязательно через сам Linq. Но подход будет точно таким же — оптимизатору нужно видеть выражения, из которых собран запрос, а не просто "штуки, которые я могу склеить". S>Если вы возьмётесь починить sqlpp так, чтобы он умел хоть что-то подобное linq2db, вам придётся построить те же самые Expression Trees, которые строит компилятор C#, только вручную.
Ну так оно там собственно прямо так и работает. ))) Точнее в sqlpp тоже строит компилятор, но для этого пришлось накрутить много метапрограммной магии. )))
S>И точно так же сворачивание этих деревьев придётся отложить до рантайма, потому что заранее неизвестно, что и куда придёт. S>Ну, или у вас будет комбинаторный взрыв, когда на N nullable-параметров вы будете статически генерировать 2^N деревьев (ну, или сразу стейтментов)
Хы, ты похоже не совсем понимаешь как работает sqlpp. Похоже что из моих слов о статической работе и минимальных накладных расходах ты сделал вывод, что оно генерирует итоговую SQL строку на этапе компиляции. Это конечно тоже реально сделать, но не имеет особого смысла, т.к. склейка строк на современных процессорах выполняется практически мгновенно, а проблемы от полностью готовой строки ты озвучил сам. Так что на практике после отрабатывания всего метапрограммного кода и прохода оптимизатора от sqlpp кода остаётся грубо говоря последовательность склейки строк, связанная условиями и т.п.
_>>Так некий абстрактный "взрослый движок в сервере приложений" в теории "может" это обнаружить или же есть конкретный движок, который вот таких образом на практике оптимизирует вот этот конкретный пример? S>Да, linq2db выбрасывает дегенеративные джойны. S>Вот, например: S>...
Так приведённый тобой ранее пример (про который я задавал вопрос) будет оптимизироваться в linq2db или нет? )
Что касается твоего нового примера, то в нём как раз хорошо видно, что человек по прежнему напишет более оптимальный sql код (или его аналог на каком-то dsl) для случая "orderProjection", чем это делает твой оптимизатор.
_>>А вот ты пытаешься писать решения просто "сверху". И это получается в случае наличия готовых фреймворков, библиотек и т.п. Но при этом в случае отсутствия таковых и в силу наличия привычки такого написания резко наступает ступор. Как это случилось с банальным примером двоичного поиска в массиве целых чисел — ведь его правильный (с разбором выражения предикатов и т.п.) код для Linq так и не появился в данной темке... S>Вы продолжаете хитрить. Покажите мне задачу, в которой возник этот "пример двоичного поиска в массиве целых чисел". S>Если мы попробуем начать решать прикладную задачу (а не задачу доказать невозможность двоичного поиска в linq), то там не факт, что двоичный поиск вообще возникнет.
ОК, согласен. По нормальному задача формулируется конечно же не через двоичной поиск, а так: "быстро найти в отсортированном (таким он уже поступает к нам на входе) массив подмножество, удовлетворяющее неким ограничениям сверху и снизу".
S>В лучшем случае возникнет задача "быстро найти элемент по ключу", где "двоичный поиск по отсортированному массиву" будет только одним из вариантов решения.
Нет, смотри выше.
S>Возможно, при решениии этой задачи на С++ двоичный поиск окажется самым идиоматическим. S>А при решении на С# запросто может оказаться, что .ToDictionary()[42] будет более наглядным решением. И заодно более эффективным, чем .Sort().BinarySearch(42).
Ну так для неотсортированного массива и на C++ будет быстрее просто линейный поиск осуществить. ))) Только вот это уже совсем другая задача...
S> S>>>А вот здесь
приведён пример кода, который хоть и использует рефлексию, но не требует выполнения процесса каждый раз с нуля. _>>Собственно опять же отсутствие разбора AST и отсутствие необходимости в Linq (оно здесь опять же исполняет никчемную роль "запускателя лямбд"). S>Тут важен не столько сам linq, сколько идеология разделения алгоритма обхода и алгоритма обработки "окрестности".
Совершенно верно. Для данного абстрагирования linq не нужно в принципе. И соответственно появляется вопрос: что данная ссылка (при все всей её интересности самой по себе) делает в данной дискуссии (напомню, что тут мы обсуждали пользу от Linq для обработки двухмерных массивов)? )))
_>>Опять же глупости — мы же измеряли, что по производительности на одной машине Mongo быстрее классических РСУБД (там же изначально была заточенность на работу в оперативной памяти). Так что 1000 серверов Mongo понадобится только для такой задачи, которую на РСУБД вообще невозможно решить (ну во всяком случае в классическом режиме, не переделывая её в аналог nosql с ручным шардингом). S>А размер данных-то был какой? Просто "заточенность на работу в оперативной памяти" хороша тогда, когда памяти больше чем данных. S>Просто я могу подключить к серверу HDD размером в 10TB, и SQL Server прекрасно справится с задачей в 8GB RAM благодаря могучему оптимизатору.
Только быстродействие будет убогое (ограниченное каналом к hdd).
S>А монга на той же железке с тем же размером склеит ласты, т.к. "там же изначально была заточенность на работу в оперативной памяти". Придётся срочно шардить, попилив на 250 восьмигигвыых машинок.
Но и эффект от работы такого кластера (кстати, поднимающегося автоматически) будет совершенно другой.
S>Можно будет для интересу сравнить стоимость такого парка с десятитерабайтным винчестером.
Сравнивать стоимость надо для решений с одинаковой производительностью.
_>>Ну так этот пример и не умеет максимальной производительности (достигаемой вручную), а умеет только автовекторизацию компилятора и плюс распараллеливание внутреннего for ( ) по системным потокам с помощью OpenMP. Если бы мы захотели максимально производительности, то пришлось бы записать этот for руками... S>Ухты! Только что video++ приводился как пример суперкрутого оптимального кода, и вдруг... Впрочем, там в дотнетном топике коллеги и Eigen обсирают — говорят, хуже только WPF.
Ну это библиотеки совсем разного класса. )))
Eigen — это общеизвестный инструмент, являющийся одним из лидеров. Точнее он один из лидеров если сравнивать только производительность (держится на уровне захадкорженной MKL http://eigen.tuxfamily.org/index.php?title=Benchmark). А если принять во внимание ещё и возможности построения абстракций (типа записи классического математического кода вместо набора страшных вызовов C-функций), то у него просто нет конкурентов.
А video++ — это не какой-то известный лидер, а всего лишь одно из многих "частных" решений. Главным преимуществом которого является использование современной версии языка. В некоторых местах (где получается) эта библиотека использует крутые оптимизации из Eigen. Однако в том конкретном моменте, что мы обсуждали (Pixel Wise Kernels) Eigen естественно (т.к. там поддерживается произвольный код) не используется и все надежды по генерации SIMD кода обращены к автовекторизации компилятором. Которая на данный момент всё ещё уступает рукопашному (на тех же интринсиках) SIMD коду.
Re[91]: В России опять напишут новый объектно-ориентированны
. S>>Там представлены разные мнения на тему того, что и как понятнее.
_>Интересное исследование. Только вот к нашей теме оно не имеет никакого отношение.
Я чуть не подавился. Ты же сам предложил задачу, а щас выходит, она не имеет отношения к теме?
Re[94]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Есть подозрение, что делаются тонкие намёки на то, что применение APPLY к дотнетному коду влечёт за собой маршалинг, т.к. использовать SQL-данные "напрямую" в дотнетной функции нельзя.
Именно, но мой поинт немного в другом. Даже если маршаллинг реально дорогой — это не проблема SQL-я как языка, это проблема конкретной реализации, где декларативная и императивная части живут в разных адресных пространствах и маршаллинг не оптимизирован.
Другой аспект проблемы в том, что необходимость такого APPLY императивной функции именно для выполнения запроса, в случае реляционных баз решается правильной декомпозицией на этапе проектирования, и необходимость такой функции исчезает, а эффективность увеличивается, так как больше данных и индексов, в случае необходимости, становится доступно оптимизатору. Результат императивной функции не прооптимизируешь же.
S>Не вполне понятно, насколько этот маршаллинг дорогой — в контексте всей стоимости исполнения запроса.
Ага.
S>Ну, вот и в дотнетной команде проснулись и осознали. Так что есть шансы и в управляемом коде копирования подсократить.
Будет потребность, будет и решение...
Мы уже победили, просто это еще не так заметно...
Re[83]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Ikemefula, Вы писали:
I>В целом же, если сделать вот те предположения, получается вполне себе стройная картинка. Другое дело, что прогресс лет двадцать назад пошел совсем по другому пути.
Где он пошёл по другому пути?
На сайтах-магазинах?
I>А то бы и писали по сей день на плюсах с ассемблерными вставками
Плюсы сегодня один из самых гибких инструментов и уже в начале нулевых компилятор умел порождать код, лучше чем ты напишешь на ассемблере.
Поэтому, эти аргументы устарели уже к концу 90-х.
I>и даже БД программировали так же — в реквест уходил бы С++ или сами ассемблерные вставки.
В реквест могут уходить параметры запросов.
I>А что, вполне логично, если каждый программист это эдакий Developer God или Goddes, то нет никакой проблемы за время 0 написать код любой сложности.
Или воспользоваться мощными имеющимися библиотеками.
На сегодня наиболее полное покрытие всех областей IT есть только на плюсах.
На остальных языках слишком выборочно и неполно.
И то, по большей части как обертка над плюсовым кодом.
Ткни в дотнет — там кроме обслуживания сайтов и неторопливого БД-интерфейса и ничего нет толком.
Какую задачу ни возьми — почти всё с 0-ля писать надо.
Сейчас даже на JS в наличии больше пригодного к использованию материала.
А так-то даже по банальному клиентскому GUI в дотнете происходит какая-то больших размеров ж-па уже десяток лет.
WPF монстрообразен.
Сервелат убили.
UWP пашет только на 10-ке.
Винформс рулит. ))
Было бы смешно, если бы не было так грустно.
I>Разница на самом деле в экономической целесообразности. Вот эту часть, возникает ощущение, он как будто или не слышит, или не понимает.
Понимает, просто давайте спорить насчёт вкуса устриц с теми, кто их ел.
Ты вообразил себе совсем другой вкус, причём, по страшилкам 20-тилетней давности.
Те времена давно прошли, забудь.
Здравствуйте, IB, Вы писали:
IB>"Мне всегда немного грустно, когда красноречиво, изящно и тонко оскорбляешь человека, а он слишком глуп, чтобы это понять."
Прикольная социопатия, однако.
"грустно" ему...
Re[85]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Имеется в виду вот такой случай: S>
S>select city.id, city.Name, sum(o.amount)
S>from orders o
S>inner join city on o.Customer_City = city.id
S>group by city.id, city.Name
S>
S>Семантически этот запрос строго эквивалентен S>
S>select city.id, city.Name, amount
S>from city inner join
S>(select Customer_City, sum(amount) as amount from orders group by orderId) o
S>on o.Customer_City = city.id
S>
S>Благодаря, понятное дело, тому, что city.id — это PK, и дальнейшие группировки по зависимым полям этой таблицы нам гарантированно ничего не дадут. S>При этом стоимость этих двух запросов отличается достаточно сильно — в клинических случаях в разы, т.к. group by по большим промежуточным результатам — это упс.
Так, я для себя уточню. Тоесть такая трансформация ускоряет запросы? Или даст возможность если человек не просил amount выбросить join с группировкой к черту?
Но так как sql не валиден еще не до конца понял. Customer_city в групбае откуда взялся? Также желательно видеть модель с PK.
Может вместе накидаем схематиечский алгоритм оптимизации?
Re[95]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Danchik, Вы писали:
D>Так, я для себя уточню. Тоесть такая трансформация ускоряет запросы? Или даст возможность если человек не просил amount выбросить join с группировкой к черту? D>Но так как sql не валиден еще не до конца понял. Customer_city в групбае откуда взялся? Также желательно видеть модель с PK. D>Может вместе накидаем схематиечский алгоритм оптимизации?
Виноват, накосячил.
Должно быть так:
select city.id, city.Name, amount
from city inner join
(select Customer_City, sum(amount) as amount from orders group byCustomer_City) o
on o.Customer_City = city.id
Тут у нас, во-первых, группировка выполняется над хранимой таблицей, а не над промежуточным результатом, что позволяет избавиться от spool.
Во-вторых, сам размер группируемых данных значительно меньше (благодаря отсутствию в них строк).
Насчёт дальнейших оптимизаций — если это только часть запроса — я не смотрел.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[95]: В России опять напишут новый объектно-ориентированны
Gt_>>не скрою, в свое время меня разобрал истерический хохот, когда мсскл на read committed начал выдавать больше записей чем было в реальности в любой момент времени. IB>А вот если бы не ржали, а мозг включили, то могли бы понять, что это хорошо описанное и понятное поведение RC уровня изоляции, которое понятно как обходить в зависимости от сценария. И это не является секретом ни для кого еще с восьмидесятых, когда уровни изоляции были представлены. IB>Если у вас это вызывает смех, то могу только посочувствовать.
я смотрю текст на англицком для тебя чересчур сложен. там описано совершенно не понятное поведение мсскл, которое нарушает основополагающие постулаты ACID. ACID требует консистентного состояния, тогда как по ссылке показывают как мсскл в нарушении стандарта выдает одну и ту же запись несколько раз. стандарт RC такое не позволяет и такой же блокировочник DB2 такого феномена не имеет.
Gt_>> в то время как snapshot в хадупе позволяет выдавать полностью консистентные данные в любой момент времени. в том числе и в момент перестройки витрины. IB>В каком именно хадупе? HBase, например, обладает точно такми же RC, как любой блокировочник и "A scan is not a consistent view of a table. Scans do not exhibit snapshot isolation." (с)
речь о snapshot на уровне файловой системы hdfs, hbase свои файлики на hdfs хранит и тоже умеет делать snapshot
Gt_>>тебе нет. тут программист нужен (с) IB>Да я не претендую, вы хоть кому-нибудь объясните.
IB>>Вы, похоже, многого не знаете про SQL. Пойдите, поучите функцию APPLY, например, потом продолжим. S>Есть подозрение, что делаются тонкие намёки на то, что применение APPLY к дотнетному коду влечёт за собой маршалинг, т.к. использовать SQL-данные "напрямую" в дотнетной функции нельзя. S>Не вполне понятно, насколько этот маршаллинг дорогой — в контексте всей стоимости исполнения запроса. S>Тем не менее противопоставляется именно чисто-джавная реализация, в которой можно просто передавать (и принимать обратно) ссылки на объект, не занимаясь копированиями между управляемой и неуправляемой памятью.
это лишь часть намека. вторая часть намека на то что sql работает лишь с примитивными типами данных. средствами sql нельзя взять данные таблицы, превратить их в "features" объект, скормить объекту модели и что-то сложное получить в ответ. sql лишь несколько типов знает.
Gt_
Re[96]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Danchik, Вы писали:
D>>Так, я для себя уточню. Тоесть такая трансформация ускоряет запросы? Или даст возможность если человек не просил amount выбросить join с группировкой к черту? D>>Но так как sql не валиден еще не до конца понял. Customer_city в групбае откуда взялся? Также желательно видеть модель с PK. D>>Может вместе накидаем схематиечский алгоритм оптимизации? S>Виноват, накосячил. S>Должно быть так: S>
S>select city.id, city.Name, amount
S>from city inner join
S>(select Customer_City, sum(amount) as amount from orders group byCustomer_City) o
S>on o.Customer_City = city.id
S>
S>Тут у нас, во-первых, группировка выполняется над хранимой таблицей, а не над промежуточным результатом, что позволяет избавиться от spool. S>Во-вторых, сам размер группируемых данных значительно меньше (благодаря отсутствию в них строк). S>Насчёт дальнейших оптимизаций — если это только часть запроса — я не смотрел.
Вернемся к этому вопросу после c# 8. Очень надеюсь что патерн матчинг упростит такие выкрутасы, а пока это еще та попаболь (
Re[96]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Gt_, Вы писали:
Gt_>я смотрю текст на англицком для тебя чересчур сложен.
Here’s the crunch and here’s where I didn’t make myself clear in the last post because of the perspective I was talking at, even with READ COMMITTED there is a possibility of getting missing or additional counts (or aggregations) purely because of the nature of the isolation level.
Перевести?
Gt_> там описано совершенно не понятное поведение мсскл, которое нарушает основополагающие постулаты ACID.
Поведение совершенно понятно тому, кто дал себе труд почитать стандарт и разобраться как на самом деле работают уровни изоляции.
Gt_> ACID требует консистентного состояния, тогда как по ссылке показывают как мсскл в нарушении стандарта выдает одну и ту же запись несколько раз. стандарт RC такое не позволяет и такой же блокировочник DB2 такого феномена не имеет.
Идите и почитайте еще раз внимательно стандарт ANSI SQL и то как там описаны уровни изоляции. Ткое поведение на RC полностью соответствует стандарту.
Более того, и на DB2 такой эффект тоже возможен, только там две транзакции потребуются, а не одна — insert/delete вместо update. Разница в том, что DB2 при блокировке, блокирует все ресурсы относящиеся к записи разом, и индексы и все остальное, а сиквел делает это независимо — блокировки на индексах отдельно, блокировки на записях отдельно. Стратегия DB2 предполагает меньший параллелизм, но большую вероятность прохождения транзакции. Стратегия сиквела большее количество дедлоков, но и больший параллелизм, как следствие потенциально большую пропускную способность.
Но с точки зрения стандарта все чисто в обоих случаях, и там и там честный RC.
Gt_>>> в то время как snapshot в хадупе позволяет выдавать полностью консистентные данные в любой момент времени. в том числе и в момент перестройки витрины. IB>>В каком именно хадупе? HBase, например, обладает точно такми же RC, как любой блокировочник и "A scan is not a consistent view of a table. Scans do not exhibit snapshot isolation." (с) Gt_>речь о snapshot на уровне файловой системы hdfs, hbase свои файлики на hdfs хранит и тоже умеет делать snapshot
Можно ссылочку на докуменацию где это описано? Уж очень странно — база сама реализует RC, но в snapshot полагается на файловую систему? К тому же единственный снапшот в hdfs — он для бакапа, а не для транзакций.
Gt_>объяснил http://rsdn.org/forum/flame.comp/7191948
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Прикольная социопатия, однако. НС>Социопатия это у тебя, когда тут ты мегавоин, а как Лонг попытался с тобой пересечься, так ты мгновенно в кусты.
А он воевать собирался или пива попить, не напомнишь?
Я Лонгу отписался по той ситуации, случился форсмажор, спасали ребенка, не до пива было.
Но прикольные, однако, сообщающиеся сосуды...
Спустя 16 лет. ))
. Пока никак, движок пока работает только по primary key, и тут тоже уникальные индексы бы помогли, которые мы никак не учитываем. Гляну что можно сделать с foreign key, тоесть сделаю если вся необходимая информация есть в метаданных. Надеюсь никто матерится не будет если мы также пропроцесим foreign key созданный с хинтом with nocheck?
Мы уже победили, просто это еще не так заметно...
