Здравствуйте, alex_public, Вы писали:

_>С учётом того, что Linq всего лишь генерирует SQL, то разговоры о том, что он "рвёт по производительности прямой SQL как тузик грелку" крайне забавны.
Они забавны только для тех, кто упорно пытается не понять что им пытаются объяснить.

_>Это вот буквально так же смешно, как утверждение IB (уже благополучно замятое) о том, что linq для коллекций рвёт по быстродействию тупой for.
Оно не замято, тем более, что вы его вспоминаете при каждом удобном и не удобном случае, но от этого не перестает быть менее верным. Что характерно, ровно в том же смысле, что и утверждение Игоря.

_>Ну это текущий компилятор C# и текущая реализация Linq только так умеют (и то в теории). А есть ещё и другие варианты, в более мощных языках.
Тоже парадокс — язык более мощный, а получается хуже...

_>Если это никому не надо, то зачем по-твоему появились на свет различные вариации PL/SQL? )))
Кау уже говорилось, PL/SQL не правильный пример, он не дает доступ к внутреннему API базы в обход SQL-я. Он лишь позволяет работать с результатом SQL-я в контексте СУБД, точно так же работают и хранимки на с++ или с#, а с недавних пор и питон или R можно вообще в виде функции передать в запрос. Но сути дела это не меняет.

Здравствуйте, alex_public, Вы писали:

_>Как минимум для всех тех случаев, для которых сейчас применqется PL/SQL.
PL/SQL не дает доступ к API СУБД, поэтому не понятно причем тут он. Он точно так же работает с результатами выборки, как и обычный прикладной код.

_>Плюс к этому можно добавить ещё и множество nosql возможностей. В первую очередь конечно же типа MapReduce (почти стандартная вещь уже, причём требующая возможности исполнения присылаемого императивного кода).
Если нужен MapReduce, то это не значит, что его надо делать руками, его база должна поддерживать и сама решать, нужен он тут или нет.
И я продолжаю не понимать, зачем нужно иметь возможность выполнять присылаемый императивный код. По эффективности выигрыша нет, а возни больше... Тем более, что эта фича таки есть, если очень надо.

_>Но и работа с документами, графами и т.п. тоже бывает нужна.
Вот это уже интереснее, но и тут — для графов добавляют поддержку нарошных индексов, добавляют аналитические функции в язык. То есть как только появляется более-менее актуальная задача, то язык и база под нее расширяется, если это имеет смысл.

_>И всё это легко реализуется поверх низкоуровневого API типа Hadoop.
Это все реализуется и поверх высокоуровневого API типа SQL. Первичные данные извлекаются и трансформируются SQL-ем, пока его возможности позволяют, дальше берется подходящий язык и пишется сверху все что надо. Собственно, так аналитика данных и работает. зачем здесь доступ к низкоуровневому API? базовые вещи SQL все равно сделает эффективнее.

_>Только при таком подходе, тебе для решения задачи придётся каждый раз писать свою СУБД.
Зачем? Достаточно брать от готовой базы все что она может дать, а дальше дописывать уже то, чего в ней пока нет. Со временем это добавят в базу и писать придется меньше, как это произошло с аналитическими функциями, например.

_>Хы, вообще то теория появилась несколько позже. А изначально sql имеет такой вид, потому что разрабатывался не как API для программистов, а как интерактивный пользовательский интерфейс для бухгалтеров и т.п.
Нет, изначально была именно теория, потом был заказ на разработку языка в рамках реализации System R. Причем делали этот язык не те люди, что разрабатывали теорию... Более того, на тот момент, если я правильно помню, Кодд был вообще отстранен от разработки System R. В итоге получилось то что получилось, а Кодд много лет спустя написал статью Fatal Flaws in SQL, где как раз критиковал несоответствие теории и фактической реализации SQL-я в RDBMS.

Более точно, с датами:
Реляционную теорию Кодд опубликовал в 70-м, тогда же его взяли в IBM на работу.

Codd had developed two languages – a relational algebra and a relational calculus – to express extremely complex queries.

System R начали разрабатывать в 74-м, и это была первая СУБД с SQL.

The researchers query language — initially called SQUARE — or Specifying Queries As Relational Expressions. Even SQUARE had some mathematical notations. Its successor, Structured English Query Language, was based exclusively on English words.

Здравствуйте, alex_public, Вы писали:

_>А что мешает написать написать просто res=Filter(data, filterType, parameters) ?
Написать не мешает, только вот что делать с этим потом? Только for-ом туда-сюда бегать. )))

_>Ну т.е. Linq не может (ок, потому что и не должен мочь) многие операции с коллекциями.
Его задача вообще не "мочь", его задача описывать желаемый результат. При этом да, у имплементации линка, может не быть реализации под конкретную операцию. Что не мешает написать ее при нужде, при помощи того де for.

_> В отличие от того же тупого императивного for. Теперь надеюсь мы это уже однозначно выяснили, правильно?
А for и есть реализация, только ее нужно каждый раз выписывать в рукопашную под каждый сценарий и каждую коллекцию индивидуально, а так же при малейшем его изменении этого сценария, вот это мы выяснили.

Здравствуйте, alex_public, Вы писали:

_>Как раз очень плохо, потому что для использования например другого диалекта sql или чуть более продвинутого языка потребуется замена всей БД.
Но этот факт никак не влияет на конкуренцию между БД, это просто означает, что момент выбора БД еще более критичен. А конкуренция между БД от этого не страдает и она там весьма и весьма.
То что переписать то же приложение на другом языке еще сложнее, чем мигрировать данные на другую СУБД, не означает же, что языки программирования перестали развиваться.

_>Вообще то низкоуровневые потроха СУБД как раз не надо будет переписывать
Если не надо переписывать, то вот SQL, там уже есть все что доступно из этих потрохов )

_> — в этом и есть главное преимущество по сравнению с твоим подходом (писать запрос на SQL, а тюнинг под конкретную специфику осуществлять с помощью написания новой СУБД с нуля).
Не надо писать новую СУБД, можно получить результат у старой и написать свою обработку этого результата, если уж прям приперло.

_> Потребуется написать только конвертер из некого внутреннего DSL (уже есть в большинстве ORM) в алгоритмы исполнения запросов (шаблоны алгоритмов можно взять например из исходников postgresql).
Прибегая к вашему же примеру — не получится написать свой hadoop, пользуясь готовыми алгоритмами postgresql. Придется переписать чуть менее чем все.
А все что есть в готовых алгоритмах, доступно и через SQL.

Здравствуйте, Gt_, Вы писали:

Gt_>конкретно мне образование. x.Name.StartsWith() указывает как именно фильтровать, like в sql не обязывает использовать конкретный алгоритм.
StartsWith() — тоже не обязывает, если что...

Gt_>скл-сервер расширяется императивным t-sql или С#. у мсскл исторически не самая продвинутая аудитория, потому им пришлось ради упрощения объявить t-sql расширением, хотя реально это другой, императивный, язык. лидеры, типа оракла четко разделяют декларативный sql и императивный pl/sql.
Вазелин для слабаков, настоящие мужики — терпят! ))))

Gt_>тем что функция будет написана на императивном C#, а не декларативным sql, ограниченным несколькими DML командами.
И что?

Gt_>нет. на маперы/редюсеры jar-ники могут передаваться
Что технически тоже самое, что хранимка на шарпе или плюсах.

Здравствуйте, alex_public, Вы писали:

IT>>И это является одной из самых сильных сторон linq. Это позволяет строить более оптимальные запросы, которые при всей якобы медлительности linq, рвут по производительности всякие сохранённые процедуры и прямой SQL как тузик грелку.

_>

_>С учётом того, что Linq всего лишь генерирует SQL, то разговоры о том, что он "рвёт по производительности прямой SQL как тузик грелку" крайне забавны. Это вот буквально так же смешно, как утверждение IB (уже благополучно замятое) о том, что linq для коллекций рвёт по быстродействию тупой for.

Ты ещё эээ... безнадёжнее, чем я думал. Да, в этом трудно поверить тому, кто воспринимает оптимизацию исключительно как выжать ещё пару бит из байта и ускориться аж на пол процента. Для остальных нормальным результатом оптимизации, в частности работы с БД, является ускорение работы приложения в разы. И linq при переписывании всякого спроков и прочего прямого SQL рулит со страшной силой.

_>Ну это текущий компилятор C# и текущая реализация Linq только так умеют (и то в теории). А есть ещё и другие варианты, в более мощных языках.

Поясни и приведи примеры других вариантов в более мощных языках. Мне интересен сам подход и как он реализуется компилятором. Кстати, что за языки такие?

IT>>Никто — это для меня слишком абстракто. Кто именно никто?
_>Однако стоит тебе вставить внутри этого цикла какую-нибудь ересь (неподходящий для GPU код, например тоже самое обращение к СУБД), как компилятор сразу же пошлёт тебя очень далеко.

Вот! Хороший пример, демонстрирующий, что nvidia в этом мире одна и спецификация у неё одна. Её можно формализовать и реализовать в компиляторе. Мы же имеем дело с десятками различных БД, у которых разные диалекты SQL, рызный набор поддерживаемых функций, куча версий, от которых пользователи не собираются отказываться, потому что ты собрал новую версию компилятора, который наконец-то теперь сможет поддерживать какую-нибудь фичу. Ты вынужден будешь либо ограничить поддерживаемый API, либо идти договариваться с разработчиками БД.

IT>>Зачем? Кому это надо?
_>Если это никому не надо, то зачем по-твоему появились на свет различные вариации PL/SQL? )))

Зачем? Я правда без понятия. Оно появилось, чтобы решить какую-нибудь проблему или как обычно, потому что это сделали не мы?

Здравствуйте, alex_public, Вы писали:

_>Ну так в любом случае это был и не sql и не питон, а нечто низкоуровневое. Так что ни о каких перехода в одну или другую сторону априори речи нет.

Это если читать в лоб, не рассуждая. А если чуток подумать, то верность исходного утверждение про отказ от SQL в пользу Питона ведет и к отказу от разработки YQL. Соответственно, факт существования такой разработки прямо противоречит исходному утверждению.

_>О, интересненько... С удовольствием послушаю как в языке SQL описывается загрузка UDF функций...

Ты опять про "SQL в вакууме"? А я про конкретные реализации, которые умеют сильно больше, чем просто SQL.

L>>Получение и подготовка данных — это, внезапно, часть реальной обработки, без которой ты никуда не уедешь.

_>SQL/YQL и т.п. теперь касается только получение данных. )

Выделенное ты успешно проигнорировал, как я вижу. А между тем, в этой части могут делаться различные тяжелые вычисления. Да и получение может включать в себя сложные джоины и фильтры, которые сами по себе тянут на обработку данных.

Здравствуйте, Sinclair, Вы писали:

S>>>Ну ладно, уговорил.
S>>>Вот как это выглядит на linq:
S>>>

S>>>var data = new int[10, 10];
S>>>var t1 = from d in data group d by (d[-1, 0] + d[1, 0] + d[0, -1] + d[0, 1]) / 4;
S>>>

_>>

_>>error CS1935: Не удалось найти реализацию шаблона запроса для типа источника "int[*,*]". "GroupBy" не найден. Возможно, отсутствует ссылка или используется директива для "System.Linq".

_>>:
S>Все верно. Это было описание желаемого. Теперь надо к нему прикрутить реализацию.
S>И вот как раз тут мы можем рулить всем процессом — от тупого императивного for до автоматической трансляции в cuda.

Ну так можешь показать как будет выглядеть самый простейший вариант реализации? А то у меня есть подозрения, что тебе тут снова придётся заниматься всяческими рантаймовыми анализами AST. Что очевидно совершенно дико и с точки зрения времени разработки и с точки зрения эффективности итогового кода.

Здравствуйте, Sinclair, Вы писали:

_>>Да причём тут это. Ты разве не понимаешь, что отсутствие низкоуровневого интерфейса убивает сам принцип разнообразия высокоуровневых абстракций, оставляю только одну (которая сейчас служит API). Т.е. дело не в конкретном языке для графов, а в подходе расширяемости.
S>Совершенно верно. Просто надо выбирать: шашечки либо ехать. Если хочется шашечки — то да, надо низкий уровень, и пусть программист лично отвечает за всё, что происходит. И за корректность, и за производительность. Примерно так и было в семидесятые годы. Потом оказалось, что подобные проекты тонут: время реализации нелинейно зависит от объёма кода, несмотря на увеличение количества разработчиков.
S>Поэтому стали развиваться средства декомпозиции и изоляции: идея в том, чтобы вместо позволения писать "любой" код позволять писать "корректный" код. И давать гарантиии сохранения корректности при внесении изменений.
S>Для меня "принцип разнообразия высокоуровневых абстракций" имеет второстепенное значение. Да, я понимаю привлекательность средств языкостроения типа Немерле, но как продакт менеджер я больше заинтересован в одном "хорошем" языке, чем в дюжине бездарных.

Это всё понятно. Но "бороться" с низкоуровневым кодом можно разными способами. Единственно правильный на мой взгляд способ — это оборачивать его в высокоуровневые абстракции (готовые библиотеки, фреймворки и т.п.). А вот самый простейший способ, под названием "запрет" на мой взгляд не верен.

S>>>В-третьих, если вы хотите гонять его поверх RDBMS, то скорее всего, его не очень трудно просто транслировать в SQL. Без какой-либо потери производительности.
_>>Сомневаюсь. Тут нужны совсем другие алгоритмы обхода данных.
S>В SQL нет никаких алгоритмов. Именно в этом его преимущество: он описывает то, какие данные надо получить, а не алгоритм обхода.

В текущих РСУБД у SQL вполне конкретный набор алгоритмов. )))

_>>Естественно коллекции numpy имеют специфичные свойства (и именно из-за этого они в разы быстрее встроенных). Так их и применяют не где попало, а в специфическом коде (тяжёлых вычислений). Так что не вижу никаких проблем.
S>Ну, то есть мы говорим не о подтюнивании, а о полной замене с потерей интероперабельности. Так — неинтересно: невозможно начать проект, изолировать в нём узкие места, и оптимизировать их.
S>С numpy ситуация другая — там у нас задача известна с самого начала, и питон используется только как высокоуровневый клей для вызова хардкорных алгоритмов, написанных не на нём.

Угу, отличный подход. И главное, что если вдруг в numpy не будет нужного кода, то у тебя нет никаких проблем (если конечно ты знаком с C/C++) написать свой низкоуровневый кусочек...

_>>Ну ОК, вот есть у нас PostgreSQL сервер...
S>У постгрес стратегия изоляции транзакций другая — в нём нет локов, как таковых; поэтому нет и смысла ими управлять.

https://www.postgresql.org/docs/current/static/explicit-locking.html гммм)

Здравствуйте, IB, Вы писали:

_>>С учётом того, что Linq всего лишь генерирует SQL, то разговоры о том, что он "рвёт по производительности прямой SQL как тузик грелку" крайне забавны.
IB>Они забавны только для тех, кто упорно пытается не понять что им пытаются объяснить.

Ну если объяснение в стиле того, что было для варианта с for, то над ним можно только посмеяться...

_>>Это вот буквально так же смешно, как утверждение IB (уже благополучно замятое) о том, что linq для коллекций рвёт по быстродействию тупой for.
IB>Оно не замято, тем более, что вы его вспоминаете при каждом удобном и не удобном случае, но от этого не перестает быть менее верным. Что характерно, ровно в том же смысле, что и утверждение Игоря.

Ага, я помню этот фееричный подход в сравнение производительности: возьмём для Linq алгоритм с логарифмической сложностью, а для императивного кода с линейной. И на логичный вопрос "а какого ...?" ответим какой-нибудь чушью в стиле: "ну если у нас в проекте изначально был линейный алгоритм, то переписывание его на логарифмический с помощью Linq можно осуществить быстрее, чем для императивного кода".

_>>Если это никому не надо, то зачем по-твоему появились на свет различные вариации PL/SQL? )))
IB>Кау уже говорилось, PL/SQL не правильный пример, он не дает доступ к внутреннему API базы в обход SQL-я. Он лишь позволяет работать с результатом SQL-я в контексте СУБД, точно так же работают и хранимки на с++ или с#, а с недавних пор и питон или R можно вообще в виде функции передать в запрос. Но сути дела это не меняет.

А причём тут внутренний API? Я тут отвечал на вполне конкретный вопрос "Кому надо исполнять произвольный императивный код на сервере?". Судя по распространённости множества разных диалектов PL/SQL и даже применения более серьёзных языков — это очень много кому надо... )))

Здравствуйте, IB, Вы писали:

_>>Как минимум для всех тех случаев, для которых сейчас применqется PL/SQL.
IB>PL/SQL не дает доступ к API СУБД, поэтому не понятно причем тут он. Он точно так же работает с результатами выборки, как и обычный прикладной код.

Ну для начала у PL/SQL есть доступ к построковой работе с данными. Точнее у SQL он конечно же тоже есть, но не имеет абсолютно никакого смысла (это всё равно что просто загрузить все сырые данные на клиента и там с ними работать). А вот для исполняемого на сервере императивного кода такой доступ уже имеет смысл...

Далее, возьмём классическую задачку: у нас есть табличка с некими числами в одном из столбцов, надо создать новую табличку, в которой количество строк определённого вида будет равно этому самому числу. Несколько сумбурно сформулировал, но думаю ты понял о чём я. Так как ты опишешь такое на SQL или Linq? )

_>>Плюс к этому можно добавить ещё и множество nosql возможностей. В первую очередь конечно же типа MapReduce (почти стандартная вещь уже, причём требующая возможности исполнения присылаемого императивного кода).
IB>Если нужен MapReduce, то это не значит, что его надо делать руками, его база должна поддерживать и сама решать, нужен он тут или нет.
IB>И я продолжаю не понимать, зачем нужно иметь возможность выполнять присылаемый императивный код. По эффективности выигрыша нет, а возни больше... Тем более, что эта фича таки есть, если очень надо.

Эм, весь смысл MapReduce как раз в том, что туда отсылается почти произвольный код, исполняемый при этом параллельно на множестве узлов...

_>>Но и работа с документами, графами и т.п. тоже бывает нужна.
IB>Вот это уже интереснее, но и тут — для графов добавляют поддержку нарошных индексов, добавляют аналитические функции в язык. То есть как только появляется более-менее актуальная задача, то язык и база под нее расширяется, если это имеет смысл.

Да, только в случае таких решений как Hadoop, никому не надо ждать расширения от авторов СУБД — можно самим накидать его за пару минут.

_>>И всё это легко реализуется поверх низкоуровневого API типа Hadoop.
IB>Это все реализуется и поверх высокоуровневого API типа SQL. Первичные данные извлекаются и трансформируются SQL-ем, пока его возможности позволяют, дальше берется подходящий язык и пишется сверху все что надо. Собственно, так аналитика данных и работает. зачем здесь доступ к низкоуровневому API? базовые вещи SQL все равно сделает эффективнее.

Нет, поверх SQL это даже близко не реализуется. Можно говорить об обратном процесс — использование другой внутренней механики (типа MapReduce) в движке, при сохранение тех же SQL запросов. Но для этого надо переписывать СУБД.

_>>Только при таком подходе, тебе для решения задачи придётся каждый раз писать свою СУБД.
IB>Зачем? Достаточно брать от готовой базы все что она может дать, а дальше дописывать уже то, чего в ней пока нет. Со временем это добавят в базу и писать придется меньше, как это произошло с аналитическими функциями, например.

Интересно, и почему Гугл с Яндексом не пошли по такому пути? ))) Всего то допилить MySQL или PostgreSQL до нужного состояния...

_>>Хы, вообще то теория появилась несколько позже. А изначально sql имеет такой вид, потому что разрабатывался не как API для программистов, а как интерактивный пользовательский интерфейс для бухгалтеров и т.п.
IB>Нет, изначально была именно теория, потом был заказ на разработку языка в рамках реализации System R. Причем делали этот язык не те люди, что разрабатывали теорию... Более того, на тот момент, если я правильно помню, Кодд был вообще отстранен от разработки System R. В итоге получилось то что получилось, а Кодд много лет спустя написал статью Fatal Flaws in SQL, где как раз критиковал несоответствие теории и фактической реализации SQL-я в RDBMS.

Ну ОК, возможно точные даты я забыл, но суть всё равно осталась верной: разрабатывался sql не на базе той теории. )

Здравствуйте, IB, Вы писали:

_>>А что мешает написать написать просто res=Filter(data, filterType, parameters) ?
IB>Написать не мешает, только вот что делать с этим потом? Только for-ом туда-сюда бегать. )))

Эээ что? res — это уже итоговый результат (новый массив), который мы должны были получить в решение нашей задачки.

_>>Ну т.е. Linq не может (ок, потому что и не должен мочь) многие операции с коллекциями.
IB>Его задача вообще не "мочь", его задача описывать желаемый результат. При этом да, у имплементации линка, может не быть реализации под конкретную операцию. Что не мешает написать ее при нужде, при помощи того де for.

У Linq и с описанием многих задач большие проблемы. Один вопрос рекурсии чего стоит. )))

_>> В отличие от того же тупого императивного for. Теперь надеюсь мы это уже однозначно выяснили, правильно?
IB>А for и есть реализация, только ее нужно каждый раз выписывать в рукопашную под каждый сценарий и каждую коллекцию индивидуально, а так же при малейшем его изменении этого сценария, вот это мы выяснили.

Да, это в каком-то смысле реализация. Только она позволяет описывать гораздо больше решений, чем позволяет задавать Linq.

Здравствуйте, IB, Вы писали:

_>>Вообще то низкоуровневые потроха СУБД как раз не надо будет переписывать
IB>Если не надо переписывать, то вот SQL, там уже есть все что доступно из этих потрохов )

SQL тут не подходит.

_>> — в этом и есть главное преимущество по сравнению с твоим подходом (писать запрос на SQL, а тюнинг под конкретную специфику осуществлять с помощью написания новой СУБД с нуля).
IB>Не надо писать новую СУБД, можно получить результат у старой и написать свою обработку этого результата, если уж прям приперло.

Уже сто раз обсуждали, что не будет так работать.

_>> Потребуется написать только конвертер из некого внутреннего DSL (уже есть в большинстве ORM) в алгоритмы исполнения запросов (шаблоны алгоритмов можно взять например из исходников postgresql).
IB>Прибегая к вашему же примеру — не получится написать свой hadoop, пользуясь готовыми алгоритмами postgresql. Придется переписать чуть менее чем все.
IB>А все что есть в готовых алгоритмах, доступно и через SQL.

В том то и дело, что никому не надо писать свой hadoop — он как раз низкоуровневый и поэтому подходит всем (он и есть аналог тех низкоуровневых потрохов СУБД, которые не надо переписывать). А писать надо свои аналоги такого https://en.wikipedia.org/wiki/Apache_Hive.

Здравствуйте, IT, Вы писали:

IT>>>И это является одной из самых сильных сторон linq. Это позволяет строить более оптимальные запросы, которые при всей якобы медлительности linq, рвут по производительности всякие сохранённые процедуры и прямой SQL как тузик грелку.
_>>
_>>С учётом того, что Linq всего лишь генерирует SQL, то разговоры о том, что он "рвёт по производительности прямой SQL как тузик грелку" крайне забавны. Это вот буквально так же смешно, как утверждение IB (уже благополучно замятое) о том, что linq для коллекций рвёт по быстродействию тупой for.
IT>Ты ещё эээ... безнадёжнее, чем я думал. Да, в этом трудно поверить тому, кто воспринимает оптимизацию исключительно как выжать ещё пару бит из байта и ускориться аж на пол процента. Для остальных нормальным результатом оптимизации, в частности работы с БД, является ускорение работы приложения в разы. И linq при переписывании всякого спроков и прочего прямого SQL рулит со страшной силой.

Как аргументировано то... )))

_>>Ну это текущий компилятор C# и текущая реализация Linq только так умеют (и то в теории). А есть ещё и другие варианты, в более мощных языках.
IT>Поясни и приведи примеры других вариантов в более мощных языках. Мне интересен сам подход и как он реализуется компилятором. Кстати, что за языки такие?

Да возьми любой язык с приличным метапрограммированием, отрабатывающем в процессе компиляции.

IT>>>Никто — это для меня слишком абстракто. Кто именно никто?
_>>Однако стоит тебе вставить внутри этого цикла какую-нибудь ересь (неподходящий для GPU код, например тоже самое обращение к СУБД), как компилятор сразу же пошлёт тебя очень далеко.
IT>Вот! Хороший пример, демонстрирующий, что nvidia в этом мире одна и спецификация у неё одна. Её можно формализовать и реализовать в компиляторе. Мы же имеем дело с десятками различных БД, у которых разные диалекты SQL, рызный набор поддерживаемых функций, куча версий, от которых пользователи не собираются отказываться, потому что ты собрал новую версию компилятора, который наконец-то теперь сможет поддерживать какую-нибудь фичу. Ты вынужден будешь либо ограничить поддерживаемый API, либо идти договариваться с разработчиками БД.

Вообще то OpenAcc — это открытый стандарт, не завязанный на Nvidia (https://developer.amd.com/amd-joins-openacc/). Более того, он поддерживает не только классические GPU, но и такие интересные штуки как Xeon Phi (хотя их ещё OpenMP начал поддерживать). Но это на самом деле не суть: пусть даже была бы только Nvidia — и что? То, что конкретная реализация исполнения произвольного кода на сервере работала бы только с конкретной СУБД как-то меняет факт самой возможности написания такой реализации (в котором ты вроде как сомневался)?

IT>>>Зачем? Кому это надо?
_>>Если это никому не надо, то зачем по-твоему появились на свет различные вариации PL/SQL? )))
IT>Зачем? Я правда без понятия. Оно появилось, чтобы решить какую-нибудь проблему или как обычно, потому что это сделали не мы?

Мдааа....

Здравствуйте, Lexey, Вы писали:

_>>Ну так в любом случае это был и не sql и не питон, а нечто низкоуровневое. Так что ни о каких перехода в одну или другую сторону априори речи нет.
L>Это если читать в лоб, не рассуждая. А если чуток подумать, то верность исходного утверждение про отказ от SQL в пользу Питона ведет и к отказу от разработки YQL. Соответственно, факт существования такой разработки прямо противоречит исходному утверждению.

Ох, как утомляют эти любители спорить с голосами в своей голове...

Ну покажи моё утверждение об "отказе Яндекса от SQL в пользу Питона". )))

_>>О, интересненько... С удовольствием послушаю как в языке SQL описывается загрузка UDF функций...
L>Ты опять про "SQL в вакууме"? А я про конкретные реализации, которые умеют сильно больше, чем просто SQL.

Может ты тогда ещё и PL/SQL считаешь как часть SQL? )

L>>>Получение и подготовка данных — это, внезапно, часть реальной обработки, без которой ты никуда не уедешь.
_>>SQL/YQL и т.п. теперь касается только получение данных. )
L>Выделенное ты успешно проигнорировал, как я вижу. А между тем, в этой части могут делаться различные тяжелые вычисления. Да и получение может включать в себя сложные джоины и фильтры, которые сами по себе тянут на обработку данных.

Ещё раз: в современных условиях использование запроса сложнее чем "select * from my_table" имеет смысл только в том случае, если там терабайты данных. Во всех остальных случаях проще загрузить в Питон таблицу целиком, как сырые данные, и уже там обрабатывать удобными инструментами.

Здравствуйте, alex_public, Вы писали:

S>>Все верно. Это было описание желаемого. Теперь надо к нему прикрутить реализацию.
S>>И вот как раз тут мы можем рулить всем процессом — от тупого императивного for до автоматической трансляции в cuda.

_>Ну так можешь показать как будет выглядеть самый простейший вариант реализации? А то у меня есть подозрения, что тебе тут снова придётся заниматься всяческими рантаймовыми анализами AST. Что очевидно совершенно дико и с точки зрения времени разработки и с точки зрения эффективности итогового кода.
Тупой влобный вариант — вот:

        public static T[,] GroupBy<T>(this T[,] source, Func<IRelativeAccess2d<T>, T> kernel)
        {
            var km = new KernelMeasure<T>(kernel);
            var result = new T[source.GetLength(0), source.GetLength(1)];
            var ra = new RelativeArrayAccess2d<T>(source);

            for (int i = source.GetLowerBound(0) - km.xmin; i < source.GetUpperBound(0) - km.xmax; i++)
                for (int j = source.GetLowerBound(1) - km.ymin; j < source.GetUpperBound(1) - km.ymax; j++)
                {
                    ra.x = i;ra.y = j;
                    result[i, j] = kernel(ra);
                }
            return result;
        }

Это, в общем-то, ровно то же самое, что под капотом у С++-библиотеки.
Минус возможности инлайнинга kernel, из-за которых внутри цикла — косвенный вызов, внутри которого — косвенные вызовы.
Не очень сложным способом мы можем проинлайнить kernel вручную, и получить на выходе MSIL, эквивалентный "идеальному" для CLR императивному коду.

Здравствуйте, alex_public, Вы писали:
_>Это всё понятно. Но "бороться" с низкоуровневым кодом можно разными способами. Единственно правильный на мой взгляд способ — это оборачивать его в высокоуровневые абстракции (готовые библиотеки, фреймворки и т.п.). А вот самый простейший способ, под названием "запрет" на мой взгляд не верен.
Пока вы контролируете 100% codebase — да, всё ок.
Что ограничивает нас любительскими проектами на 1-3 человек.
Как только у нас возникает совместная деятельность — упс, лишние разрешения только мешают.
А когда у нас есть совместная деятельность без общей цепочки подчинения — то надо разрешать как можно меньше.
Вот, к примеру, есть какой-нибудь booking.com.
Он позволяет делать поиски по всяким критериям. Но я не могу запихать в него произвольный императивный код для поиска — ибо нефиг. Даже если "опесочить" этот код так,чтобы он не разломал полбазы, я всегда могу скормить туда пожиратель ресурсов и спровоцировать DoS. Проверить, можно ли исполнять произвольный запрос, или он положит всю систему, эквивалентно решению проблемы останова.

S>>В SQL нет никаких алгоритмов. Именно в этом его преимущество: он описывает то, какие данные надо получить, а не алгоритм обхода.
_>В текущих РСУБД у SQL вполне конкретный набор алгоритмов. )))
И он, что характерно, менялся с годами. Если есть мнение, что какие-то реляционные данные эффективнее "обходить" по-другому, то лучше инвестировать в улучшение исполнителя SQL, который поможет всем, чем в ручное итерирование по курсорам.

_>Угу, отличный подход. И главное, что если вдруг в numpy не будет нужного кода, то у тебя нет никаких проблем (если конечно ты знаком с C/C++) написать свой низкоуровневый кусочек...
Угу. И зачем мне Питон, если я умею в С++? Если чо, там пол-языка было изобретено исключительно для того, чтобы побить фортран в математике.

_>>>Ну ОК, вот есть у нас PostgreSQL сервер...
S>>У постгрес стратегия изоляции транзакций другая — в нём нет локов, как таковых; поэтому нет и смысла ими управлять.

_>https://www.postgresql.org/docs/current/static/explicit-locking.html гммм)
О, спасибо, не знал. Плохо знаком с постгре — увы.
Ну, тогда возвращаемся к вашему предыдущему вопросу — посмотрев на полный сценарий транзакции, я мог бы автоматически приписывать for update в те селекты, результаты которых мне нужны до конца транзакции. Без принудительного serializable, который заставит такие локи навешивать на всё подряд.

Gt_>>конкретно мне образование. x.Name.StartsWith() указывает как именно фильтровать, like в sql не обязывает использовать конкретный алгоритм.
IB>StartsWith() — тоже не обязывает, если что...

указывает.

Gt_>>скл-сервер расширяется императивным t-sql или С#. у мсскл исторически не самая продвинутая аудитория, потому им пришлось ради упрощения объявить t-sql расширением, хотя реально это другой, императивный, язык. лидеры, типа оракла четко разделяют декларативный sql и императивный pl/sql.
IB>Вазелин для слабаков, настоящие мужики — терпят! ))))

настоящие мужики выбирают лидирующие технологии: oracle rdbms, oracle java, а слабаки да, на технологиях второго эшелона mssql, .net созданные по мотивам оракла

Gt_>>тем что функция будет написана на императивном C#, а не декларативным sql, ограниченным несколькими DML командами.
IB>И что?

то что декларативным sql такие вещи не решить, но есть костыль на императивном C#, который убьет оптимизатор и все равно ничего не даст.

Gt_>>нет. на маперы/редюсеры jar-ники могут передаваться
IB>Что технически тоже самое, что хранимка на шарпе или плюсах.

нет. хранимка это то, что заранее задефайнено в субд, а тут либы используемые твоим кодом. соответственно можно выполнять код с разными версиями либ одновременно.

Gt_

Здравствуйте, alex_public, Вы писали:

_>Ага, я помню этот фееричный подход в сравнение производительности: возьмём для Linq алгоритм с логарифмической сложностью, а для императивного кода с линейной. И на логичный вопрос "а какого ...?" ответим какой-нибудь чушью в стиле: "ну если у нас в проекте изначально был линейный алгоритм, то переписывание его на логарифмический с помощью Linq можно осуществить быстрее, чем для императивного кода".
Ну почему же чушью, если это так и есть? )

_>А причём тут внутренний API? Я тут отвечал на вполне конкретный вопрос "Кому надо исполнять произвольный императивный код на сервере?". Судя по распространённости множества разных диалектов PL/SQL и даже применения более серьёзных языков — это очень много кому надо... )))
А, в этом смысле. Ну так PL/SQL, равно как и другие императивные расширения для написания процедур на сервере, были придуманы в те времена, когда считалось, что СУБД должна еще и логику выполнять. Но практика показала, что это самый неудачный подход из всех возможных. И хотя еще до сих пор есть любители выписывать логику на сервере, лучшим доказательством, что языки типа PL/SQL не востребованы — это то, что они не развиваются. Если бы была потребность в нормальном языке на серврере, то их давно бы уже привели в порядок, но так как нет такой нужды, то никто в эти языки не в кладывается и они как были убожеством, так и остались.
Так что да, произвольный императивный код на сервере непонятно зачем нужен, всегда можно достать результат запроса на клиент и сделать с ним все что хочется.

Здравствуйте, alex_public, Вы писали:

_>Ну для начала у PL/SQL есть доступ к построковой работе с данными.
Технически это просто select одной записи

_>А вот для исполняемого на сервере императивного кода такой доступ уже имеет смысл...
Практического смысла в этом нет...

_>Далее, возьмём классическую задачку: у нас есть табличка с некими числами в одном из столбцов, надо создать новую табличку, в которой количество строк определённого вида будет равно этому самому числу. Несколько сумбурно сформулировал, но думаю ты понял о чём я. Так как ты опишешь такое на SQL или Linq? )
Не, не понял задачу... Если эти строки определенного вида есть в другой таблице, то нет проблем сделать select top(select столбец_с_числами from таблица_с_числами) строка from таблица_со_строками. Если же таблицы нет, то это не задача sql — данные генерить, хотя иногда можно извернуться с псевдотаблицами или какими-нибудь служебными.

_>Интересно, и почему Гугл с Яндексом не пошли по такому пути? ))) Всего то допилить MySQL или PostgreSQL до нужного состояния...
Почеу не пошли? Пошли, гугл довольно долго пилил MySQL и всячески его использовал, думаю и до сих пор продолжают.

_>Ну ОК, возможно точные даты я забыл, но суть всё равно осталась верной: разрабатывался sql не на базе той теории. )
Ну как же не на базе то, алгебра -> SQUARE -> SQL я прямо цитату привел: The researchers query language — initially called SQUARE — or Specifying Queries As Relational Expressions. Even SQUARE had some mathematical notations. Its successor, Structured English Query Language, was based exclusively on English words