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


MH>>MapReduce это больше про как выполнять. а sql про как описать. MapReduce выражается через sql — упрощенно это select и group by.
MH>>и я бы не назвал MapReduce "императивным" подходом.

Gt_>не правда. маппер и редюсер это в случае хадуп это обычный императивный жава код. любой sql можно выразить через MapReduce, но в другую сторону зачастую не выйдет.
что тогда мешает сказать, что и для sql выражения (например name like 'А%', соотвествует "обычный императивный" C# код — x.Name.StartsWith("А") ?
с точки зрения концепции неважно как внутри реализован маппер и редьюсер. для маппера важно что это чистая функция без побочных эффектов, а это значит если мы можем расширять скл своими функциями (а мы можем), то любой маппер мы можем выразить за счет select и композиции базовых функций, то есть возможность выразить мап-редюс через скл, ограничена только возможность расширения скл-сервера нужными функциями.

Gt_>в императивном коде мап-редюс не проблема подключить допустим хитрую либо шифрования и читать писать шифрованные данные, а в sql если функции нет, то все.
да, можно, если на сервере выполняющем мап-редюс она (хитрая функция для шифрования) есть. но тогда что мешает на скл-сервере тоже написать/подключить любую нужную функцию? и чем ситуации будут отличаться?

и если на сервере мап-редюс нужной функции/либы нет — то тоже всё.

MH>>>MapReduce это больше про как выполнять. а sql про как описать. MapReduce выражается через sql — упрощенно это select и group by.
MH>>>и я бы не назвал MapReduce "императивным" подходом.

Gt_>>не правда. маппер и редюсер это в случае хадуп это обычный императивный жава код. любой sql можно выразить через MapReduce, но в другую сторону зачастую не выйдет.
MH>что тогда мешает сказать, что и для sql выражения (например name like 'А%', соотвествует "обычный императивный" C# код — x.Name.StartsWith("А") ?

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

MH>с точки зрения концепции неважно как внутри реализован маппер и редьюсер. для маппера важно что это чистая функция без побочных эффектов, а это значит если мы можем расширять скл своими функциями (а мы можем), то любой маппер мы можем выразить за счет select и композиции базовых функций, то есть возможность выразить мап-редюс через скл, ограничена только возможность расширения скл-сервера нужными функциями.

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

Gt_>>в императивном коде мап-редюс не проблема подключить допустим хитрую либо шифрования и читать писать шифрованные данные, а в sql если функции нет, то все.
MH>да, можно, если на сервере выполняющем мап-редюс она (хитрая функция для шифрования) есть. но тогда что мешает на скл-сервере тоже написать/подключить любую нужную функцию? и чем ситуации будут отличаться?

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

MH>и если на сервере мап-редюс нужной функции/либы нет — то тоже всё.

нет. на маперы/редюсеры jar-ники могут передаваться

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

_>И этот пример отлично демонстрирует одну из концептуальных проблем,
Ну так сформулируйте уже эту концептуальную проблему наконец! ) Что мешает перейти от частного к общему?

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

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

_>Ну кому интересно могут сами легко это проверить, пройдясь по сообщениям выше и убедившись в твоём вранье. )))
Все заинтересованные это уже сделали и поняли, что вру тут не я.

_>Я уже формулировал и не раз.
Не видел.

_> Даже большое отдельное сообщение писал (не тебе) прямо на эту тему.
Тема большая, мог и пропустить, повторите, если не сложно.

_> Только вот ты об этом вспоминаешь в очень специфические моменты и что-то пока вообще ничего не смог предложить от себя.
То что предложенное мной не нравится, не значит, что я ничего не смог предложить ))

_>Эммм, ты вообще сам то понял, что написал?
Я очень хорошо понимаю в том о чем пришу, а вот вы похоже не совсем.
Попытаюсь разжевать еще раз. SQL или LINQ описывают в терминах конечного результата, а не то, как именно этот результат надо получить. Таким образом, под капотом у select может быть и map/reduce. Таким образом, пенять sql-ю, что он map/reduce или другие какие распределенные вычисления не умеет, мягко говоря, не корректно. Тем более что умеет.

_>Ну и в мире СУБД надеюсь скоро будет такая же ситуация, в первую очередь благодаря nosql решениям. Этот процесс очень явно виден.
Явно виден процесс совершенно обратный, как в СУБД, так и других областях.

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

Gt_>серьезно. и опыт реальный имеется. раньше было модно подготавливать данные чем-то высокоуровневым типа sas data miner, который транслировал свои flow в sql. теперь мода на гораздо более низкоуровневые R/Phyton
То есть из-за того, что вы перешли с одного стека технологий на другой, теперь делаем далеко идущие выводы о том что в место sql-я теперь везде используют R/Python? Ну, то есть, ничего бы нам с той водки не было, еслиб не ириска?
Еще раз, если данные хранить не надо, значит sql там и не нужен был. Если кто-то готовил модели в sql-е, а потом стал готовить их в питоне, это не значит, что sql плохой, это значит, что для работы с моделями в питоне больше библиотек, фреймворков и других инструментов. sql, как уже было сказано, в другом месте стека находится.

Gt_>вообше не понял о чем тут речь.
Это видно ) Пример с DS тут вообще не в тему, но видимо билет был выучен только про блох ))

Gt_>ML фреймворк это уже следующий этап, но и там я уже не вижу ничего декларативного.
Там декларативного, чуть менее чем все, на то он и фреймворк.

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

_>Ну а мне кажется, что не ошущаешь способности это сделать. ))) Причём сразу в двух простейших задачках. В общем уже всё понятно с тобой: как доходим до кода или других реальных аргументов, так сразу мгновенный слив.
Мне в целом все равно, что вам кажется... Но в обоих случаях код будет не реальным аргументом, а попыткой увести дискуссию в сторону. Писать код здесь более-менее все умеют, а вот придерживаться четкой аргументации и не заниматься резней по цитатам, как видно, удается далеко не всем ))

_> А беседа с тобой навевает только скуку (меня уже давно не привлекает возможность продемонстрировать слив своего оппонента, вместо этого интереснее спор со способным ответить что-то толковое).
Да вы только и занимаетесь тем, что демонстрируете слив, ясное дело — скучно и не интересно )))

_>Да, а понты от тебя в дискуссии с vdimas были такие, что аж смешно было читать (я тогда ещё даже не участвовал в дискуссии, но был на неё подписан).
Во всей этой дискуссии понты были только у vdimas-а, и да, действительно смешные )

_>Да, именно это будет с nosql. И это не имеет ничего общего с печальной ситуацией в мире SQL. Причём ты даже недооцениваешь скорость прогресса в такой ситуации. SQL-подобный интерфейс у того же hadoop не просто появится, а он уже есть и в нескольких разных вариантах. И каждый использует удобный ему вариант. А если кому-то не подойдёт ни один из существующих, то он элементарно напишет ещё один, свой. И всё это потому, что после появления этих интерфейсов никому не пришла в голову идея отрезать базовый api hadoop'а. Теперь надеюсь понятна мысль? )))
Мысль-то понятна, только SQL, как мы выяснили, начинался точно так же, а теперь это для него не "печальная ситуация", а давно пройденый этап.
На самом деле, против низкоуровнего api никто, ничего не имеет, пусть будет, если/пока он пользу приносит, но той пользы все меньше и меньше, и я вижу кто тут недооценивает скорость прогресса )

_>"масштабируемость и параллельность это уже следствие." Так может ты способен предложить другое решение для обработки большого объёма данных? Нет? Тогда возможно это уже не просто следствие, а как раз целевое инженерное решение?
Решение и есть следствие, а не причина. ))) Причина, как уже говорилось, появление нового класса задачь, для которого, с одной стороны, не критичны ограничения существующего подхода, а с другой, иные требования к производительности и объемам.

_>Да, кстати, а что ты называешь отказоустойчивостью? Что-то я подозреваю, что nosql решения, развёрнутые на множестве узлов с резервированиями (см на тот же гугл) дадут гораздо большую доступность сервиса, чем одинокий сервер с РСУБД. Или ты быть может называешь отказоустойчивостью что-то другое? )
Под отказоустойчивостью я понимаю полноценный ACID. nosql решение на множестве узлов будет доступно, но отвечать будет не всегда согласованно, может и чушь какую-нибудь выдать.

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

_>Ты почему то не можешь увидеть принципиальную разницу между этой ситуацией и случаем с SQL.
Это потому, что её нет.
_>Уменьшение потребности обращения к низкому уровню не убирает его из цепочки, а всего лишь делает автоматически генерируемым для большинства случаев. И при необходимости (причём это может быть не только оптимизации, но и вообще написание нового языка) ты можешь в любой момент обратиться к этому низкому уровню. А в случае SQL у тебя нет этого низкого уровня в принципе — базовым API уже сложит высокоуровневый декларативный язык.
Нет, языки так не работают. Как только ты вмешиваешься в низкий уровень, ты начинаешь мешать.
Вот, компилятор хотел вовсе устранить переменную, т.к. она не нужна.
Но тут пришёл программист, и говорит "А напишу-ка я ассемблерную вставку", хреначит mov &i, eax, и вот компилятор уже вынужден резервировать место на стеке и складывать туда значение.
_>А ещё можно поделить в коде на ноль. А ещё можно просто дать команду форматирования диска. И что? Или может стоит убрать эту команду с компьютеров от греха подальше? )))
Аналогии некорректны.
_>В текущем стандарте C++ такого ключевого слова вообще то нет. ))) А вот различный "ручной привод" вполне имеется и используется.
Ну, вот видите — убрали.

_>Это слишком общая фраза, чтобы с ней можно было спорить или соглашаться. И кстати тех же C++ или SQL можно легко подвести под эту же мысль, только с другой стороны (сказать что они слишком низкоуровневые для определённых задач).
Конечно. Именно поэтому плюсами мир программирования не исчерпывается, и уровень SQL меня не устраивает. Он действительно слишком низкий для многих задач — стоило бы повысить выразительность и дать возможность СУБД исполнять его эффективнее, чем следовать навязанным стратегиям.

_>И какое это всё имеет отношение, к обсуждаемой нами теме? )
Прямое: низкий уровень — это тупик.

_>Почему бы и нет, особенно если сможешь ещё на сеть смаштабироваться. Возможно такое решение оказалось бы востребованным. И кстати, если бы современные СУБД имели низкоуровневый интерфейс, то ты бы возможно уже давно смог бы реализовать нечто подобное сам (при этом без потребности создания своей СУБД). Ну а в нашей реальности ты можешь только фантазировать (поверх SQL то такое не прикрутишь)...
Никакой низкоуровневый интерфейс тут не нужен. Прикрутке поверх SQL мешает, в первую очередь, как раз отстутствие "высокого уровня" — вот для C#, скажем, есть roslyn, который позволяет не писать парсер языка для того, чтобы реализовать какой-нибудь простенький анализ кода.

Здравствуйте, alex_public, Вы писали:
S>>Ещё раз: нас интересует производительность, а не накладные расходы. Грубо говоря, вы выжимаете константу при O(N), а меня интересует переход к O(Log Log N).
_>Эм, какое ещё O(...), когда мы говорим о работе с нынешними СУБД (т.е. вся работа нашего кода заключается в генерации sql строк)?
Очень удобная позиция. "Мой код справился за 1мкс, а то, что СУБД была вынуждена лопатить 15 минут — это не ко мне вопрос". Людей не интересует работа вашего кода, их интересует решение бизнес-задачи.
Например, показать список отелей с номерами, удовлетворяющими запросу клиента, по возрастанию расстояния от Point of Interest. И сколько там времени работает JS, сколько Java, а сколько СУБД — неважно.
Важно, что надо успеть за секунду сделать всю работу. Поэтому потратить лишние 200мс на то, чтобы сэкономить лишнее обращение к СУБД — это хорошая идея.

_>Вообще то Фортран как раз является вполне универсальным императивным языком. Так что мне вполне хватило бы его убогой выразительности в качестве базового языка для передачи запросов в СУБД. )))
Вы, похоже, с Фортраном не знакомы.
_>Хотя в реальности было бы интереснее рассмотреть что-нибудь посовременнее, типа wasm.
Ничего интересного в wasm нету. Скукотня.

_>Какая ещё реализация? Судя по сообщениям в данной темке оно ещё только в разработке пока.
Вот ровно та, которая упоминалась в данной темке. Мы же говорим не о том, как там оно под капотом, а о том, как оно выглядит для пользователя.

_>Это понятно и правильно. Непонятно зачем тут linq. )))
Затем, чтобы мы писали запросы на языке высокого уровня, который поддерживает нормальную декомпозицию и манипуляцию запросами. В отличие, например, от SQL.

_>Не очень понял про что ты. Но использование t4 для генерирования C# кода — это вполне себе МП (пусть и крайне убогое). Однако какое это имеет отношение к нашему вопросу?
То, что это такое же МП, как и "подготовка SQL кода по C# коду".

_>Он в любом случае задаётся программистом. ))) Просто в текущей ситуации с РСУБД этими программистами являются только создатели РСУБД, а программистам, использующим РСУБД, это недоступно. В отличие от популярных noslq решений, в которых это доступно всем.
Вы попадаете в стандартную ловушку фанатов низкого уровня: там, где вы видите "возможность", мы видим "обязанность". То есть вы хотите, чтобы программист мог писать эти алгоритмы. А я хочу — чтобы он мог их не писать.
Это гораздо ценнее.
_>Для слабых программистов тебе никто не мешает написать готовый фреймворк (собственно его даже писать с нуля не надо — можно просто скопировать основное из исходников текущих РСУБД), генерирующий нужный код для базовых случаев, задаваемых каким-то DSL.
Для базовых случаев неинтересно. Это опять приводит к тому, что либо ты сидишь на фреймворке, либо ты должен сразу написать 150 килобайт кода для минимальной модификации кода.
Фреймворк должен покрывать все практически интересные случаи. Вот после того, как он это делает, и можно обсуждать введение доп. велосипедности. Если она вообще потребуется.

_>Так при создание range из двух итераторов он и подставляется.
В коде не было никакого создания из двух итераторов. Использовалась сама коллекция (массив) и её длина.
_>Кстати, на самом деле для коллекций так делать не обязательно (т.е. внутри оно так и происходит, но писать этот код руками не надо — range умеет инициироваться по любой коллекции сам), я просто хотел продемонстрировать самый низкий уровень и универсальность подхода (итератор то может быть любым).
Вот это-то и непонятно.

_>Вот не стоит передёргивать мои слова. Я нигде не говорил, что у C# есть какие-то проблемы с написанием подобного кода. Как раз наоборот, на C#, как на полноценном императивном языке, все описанные проблемные примеры легко реализуются (через банальный for и т.п., который уже даже может быть написан и находиться в библиотеке как готовая функция). Речь шла о неспособности решать эти задачи именно на Linq.
Linq решает другие задачи. У него нет цели давать низкоуровневый доступ для написания своих велосипедов.

_>Ну а можно писать код, который будет выполняться за O(1) и без анализа предусловий. )
Правда, выдавать будет фигню — но кого это интересует, да?

Здравствуйте, alex_public, Вы писали:
_>Вообще то это уже не раз тут проговаривалось, так что лень повторяться. Это я про общие положения. Но могу для разнообразия подкинуть ещё один примерчик для понимания. Простейшая, но очень нужная во многих областях задачка: имеем двухмерный массив чисел и надо получить из него новый массив, в котором каждая точка является средним от своих соседей (4-ёх или 8-ми, не суть). Что об этом скажет linq? )))
Linq об этом, к сожалению, ничего не скажет. Он — про другое. Нам же потребуется какой-то фреймворк для 2d-фильтров.
Что-то типа ApplyFilter(data, filter, edgeHandlingRules), где data — наш массив чисел, filter — матрица коэффициентов, edgeHandlingRules — набор параметров, описывающих, как обрабатывать границу (считать ли точки, выходящие за границы массива, нулевыми, единичными, или аппроксимировать средними).
В зависимости от задачи, мы, возможно, захотим уметь записывать цепочки фильтров — чтобы минимизировать количество проходов.
Нам потребуется фреймворк, умеющий превращать data.Filter(filter1).Filter(filter2) в data.Filter(filter1_filter2).
При этом мы, естественно, понимаем, что data запросто может оказаться больше размера доступной RAM, и что обрабатывать мы это всё, возможно, захотим в несколько потоков одновременно.
Поэтому наивная реализация через четыре вложенных цикла нас не интересует. Через два вложенных цикла — тем более, т.к. мы хотим иметь возможность быстро менять фильтр, подбирая его по качеству результата. Ручное переписывание 4х точек на 8 точек, а потом на 12 в этом смысле нас не устраивает.
Не говоря уже о том, что порядок чтения и записи результатов нам надо будет подбирать с учётом особенностей кэширования, и наличия векторных операций в процессоре, на котором мы исполняемся (ну, это в зависимости от типа данных, которые мы обрабатываем — для 16-разрядных целых детали оптимального ассемблерного кода будут существенно отличаться от случая 80-битных плавающих)

Итого, сам Linq тут ни при чём. Но подход к решению должен быть именно таким — мы пишем максимально декларативный код, и пишем механизм конверсии этого кода в оптимальный низкоуровневый код.
Язык, который навязывает нам использование вложенных циклов, неинтересен.

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

_>На самом деле у Монго немного другая схема. Sinclair тут намекал на то, что в Mongo данные пишутся на диск не перед завершением транзакции, а с какой-то переодичностью (раз в сколько-то секунд, как раз для оптимизации быстродействия) и что типа только из-за этого она такая быстрая, но зато при сбое теряются данные, которые не успели быть записаны. Так вот на самом деле данные там пишутся как раз мгновенно (ну т.е. перед завершением транзакции), только не в саму БД, а в некий специальный журнал изменений (очищаемый как раз при записи в саму БД).
Во-первых, это опциональный режим. То есть они всё ещё умеют обходиться без write-through коммита.
Во-вторых, вот именно эта штука, которая называется write-ahead log, взята 1-в-1 из RDBMS, потому что их тоже не дураки писали. И именно поэтому я и "намекал", а, точнее, писал открыто: в таком режиме commit в Монгу занимает ровно столько же времени, как и в RDBMS. Потому что делается ровно то же: флашится буфер журнала, а это как минимум 1 IO операция, которая, внезапно, упирается в HDD, а не в алгоритмы СУБД или язык реализации.
Все легендарные скорости записи достигаются исключительно при отключении write-through коммитов, потому что чудес не бывает. Некоторые особо резвые RDMBS тоже оборудованы аналогичными режимами, но их использование малоинтересно, т.к. нас интересуют предсказуемые поведения, а не "авось проконает". Если вы готовы пожертвовать данными, то математик внутри меня подталкивает сразу смонтировать базу на dev/null и обеспечить непревзойдённую скорость записи

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

_>А ты вообще в курсе что такое Jupyter Notebook, как он работает и какое место занимает в современном мире DS? )))

Как ты думаешь, а зачем Яндекс пилит собственный движок запросов с SQL-подобным синтаксисом, если Python так прекрасен?
https://habr.com/company/yandex/blog/312430/

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

_>>Если linq научится отправлять прямо свой код (включая пользовательские лямбды) для выполнения на сервер, то это будет уже совсем другая история. Но это опять же будет возможно только при появление у СУБД какого-то иного интерфейса, помимо SQL. О чём собственно и была изначальная дискуссия.
MH>дак linq уже умеет отправлять пользовательские лямбды (не любые конечно) на сервер. например подобная : .Where(x=> x.Name.StartsWith("И") && x.Name.Length>=5)
MH>целиком будет выполнено на сервере.

Он может только то, что находится в рамках SQL. Вот если бы смог ещё и то, что находится в рамках PL/SQL, то был бы совсем другой разговор.

_>>MapReduce очевидно не является разновидностью sql. ))) Более того, все эти императивные подходы очевидно являются более низкоуровневыми, чем декларативный подход sql. И соответственно можно относительно не сложно реализовать SQL интерфейс поверх того же Hadoop или Spark (и такие проекты есть), но не выйдет сделать обратное.
MH>MapReduce это больше про как выполнять. а sql про как описать. MapReduce выражается через sql — упрощенно это select и group by.
MH>и я бы не назвал MapReduce "императивным" подходом.

Да, это довольно ироничный момент, т.к. само использование функций типа map и reduce традиционно относится к парадигме функционального программирования. Однако в данном случае под "императивным подходом" подразумевался тот факт, что в качестве параметров для map и redude в современные СУБД, поддерживающие этот подход, можно передать произвольный императивный код. И соответственно в общем случае ты не можешь выразить MapReduce через SQL. А вот обратное наоборот легко реализуется.

Причём это всё была речь только про синтаксические нюансы, не затрагивая принципиальную разницу в вопросах масштабирования.

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

Эх, хотя и лень повторяться, но не могу отказать такому вежливому собеседнику. Правда дискуссия была длинная и недостатки рассматривались с очень разных сторон, так что я бы разделил ответ на 3 части:

1. То, о чём я тут беседую в последних сообщения, а именно о неправильности роли SQL в качестве базового API для РСУБД. По сути это конечно же является не проблемой SQL, как языка запросов, а проблемой его места в мире РСУБД. Но это в любом случае проблема (с универсальностью), следующая из излишней высокоуровневости SQL (что было абсолютно нормально для его изначально предназначения в роли инструмента бухгалтеров, но странно в руках программистов). В качестве более правильной реализации можно взглянуть на тот же hadoop, имеющий низкоуровневый императивный API и при этом уже несколько разных реализаций SQL поверх этого API.

2. Обсуждаемые в самом начале дискуссии недостатки SQL именно как языка запросов к существующим РСУБД. Пример моей критики по данному вопросу можно увидеть например в предпоследнем абзаце вот этого http://rsdn.org/forum/flame.comp/7060147.1

Автор: alex_public
Дата: 20.02.18

старого сообщения.

3. Недостатки связанные с выходящими за рамки РСУБД задачами. Таких задач и соответствующих им СУБД сейчас множество: документоориентированные, графоориентированные, заточенные на работу одновременно на тысячах узлов и т.д., не буду перечислять их все. И у всех этих СУБД имеется или какой-то свой оригинальный язык запросов или же очень сильно мутированный SQL. И это очевидно не причуды авторов (гораздо легче было бы взять всем известное и популярное решение), а вынужденная необходимость, потому как стандартный SQL не имеет средств для решения этих задач.

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

_>>На самом деле у Монго немного другая схема. Sinclair тут намекал на то, что в Mongo данные пишутся на диск не перед завершением транзакции, а с какой-то переодичностью (раз в сколько-то секунд, как раз для оптимизации быстродействия) и что типа только из-за этого она такая быстрая, но зато при сбое теряются данные, которые не успели быть записаны. Так вот на самом деле данные там пишутся как раз мгновенно (ну т.е. перед завершением транзакции), только не в саму БД, а в некий специальный журнал изменений (очищаемый как раз при записи в саму БД). Так что при сбое данные нормально будут жить на диске, и при новом запуске Монго спокойно прочитает журнал и добавит все нужные изменения в саму БД.
Gt_>не. нету там транзакций. какие-то документы на одном узле, какие-то на другом. у каждого узла свой журнал, значит может быть ситуация когда один узел записал в свой журнал, а другой не успел и в результате запишется пол транзакции. потому они и говорят что гарантируют лишь атомарность записи документа, но не транзакции.

То, что транзакции в Монго ограничены одним документом (точнее были ограничены https://www.mongodb.com/blog/post/multi-document-transactions) — это само собой. Но я писал про другое. Что грубо говоря при выключение питание на сервере, успешно переданные на него данные не будут потеряны, как могло показаться из сообщения Sinclair'а.

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

_>>Значит изначально мы обсуждали вопрос, как бы покрасивее заставить выполняться наш произвольный код (задаваемый клиентом) на сервере (в данном случае РСУБД). И смотрели можно ли приспособить к этому Linq в текущей или некой гипотетической реализации.
IT>И я тебе сразу объясняю как ведущий сабаковод в этом деле. Приспособить к этому Linq без существенной кастрации его возможностей нельзя. Какое слово из этого предложения тебе не понятно?

Так а где техническая аргументация этого (хотя бы простенький контрпример с кодом)? Или предлагаешь поверить тебе на слово? )))

_>>Теперь поясни, откуда взялась мысль о том, что кому-то понадобится передавать серверу на выполнение код GUI?
IT>Это то, что ты в результате получишь. Точнее ты это даже не получишь. Ты об это элементарно обламаешься.

Эм, ты какой-то странный. Я правильно понимаю, что если я захочу передать для выполнение на GPU код обращения к СУБД и компилятор пошлёт меня подальше с такими идеями, то это будет означать что я (или транслятор в CUDA? или кто?) обламался?

_>> Или ты имел в виду, что это произойдёт как-то не специально? Ну очевидно же, что если уж делать такую реализацию через Linq, то предназначенный для исполнения на сервере код должен быть чётко обособлен от всего остального кода, иначе как компилятор поймёт что исполнять на клиенте, а что отсылать на сервер?
IT>В случае Linq компилятор вообще ничего не поймёт. Ещё раз, для этого нужно будет либо заранее вводить массу ограничений, либо научить компилятор вместе с клиентским кодом заглядывать в код сервера.

Заглядывать в код сервера не нужно. Сервер очевидно должен предоставлять загружаемому коду некий API, так же как это делает сейчас например браузер. Именно поэтому я и говорил, что для подобного, API к РСУБД в виде SQL недостаточно. А вот при наличие более низкоуровневого API проблем очевидно уже не будет.

_>>Ну лично у меня есть сомнения в том, что "нет никаких проблем"... ))) Однако если постараться (на уровне языка и компилятора, т.е. не с текущей реализацией Linq), то думаю вполне реально.
IT>Советую сразу поработать над составлением списка ограничений. А затем убедиться в том, что твой кастрат будет проигрывать даже текущей реализации Linq.

Ну я то этим точно заниматься не собираюсь, т.к. к Linq у меня никаких особых симпатий нет (предпочитаю инструменты получше) и соответственно развивать его в этом направление не планирую. Однако теоретическую возможность такого развития я не могу отрицать.

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

_>Он может только то, что находится в рамках SQL. Вот если бы смог ещё и то, что находится в рамках PL/SQL, то был бы совсем другой разговор.
А что ему мешает? Тот же linq2db неплохо справляется с поддержкой различных диалектов SQL, лишь бы сервер понимал.

_>Причём это всё была речь только про синтаксические нюансы, не затрагивая принципиальную разницу в вопросах масштабирования.
Ну наконец то! То есть дело в этом вопросе все-таки исключительно в синтаксисе? ))

Воот, уже ближе к делу, тут хотя бы есть о чем поговорить ))
_>1. То, о чём я тут беседую в последних сообщения, а именно о неправильности роли SQL в качестве базового API для РСУБД. По сути это конечно же является не проблемой SQL, как языка запросов, а проблемой его места в мире РСУБД.
Все же у SQL как языка в этом смыле проблем таки нет. Прекрасно, и это я тоже давно пытался выяснить))

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

_> В качестве более правильной реализации можно взглянуть на тот же hadoop, имеющий низкоуровневый императивный API и при этом уже несколько разных реализаций SQL поверх этого API.
Давайте зайдем с другой стороны. А что-бы вы хотели получить от API более низкоуровневого, чем SQL? что бы такой API мог дать?

_>3. Недостатки связанные с выходящими за рамки РСУБД задачами. Таких задач и соответствующих им СУБД сейчас множество: документоориентированные, графоориентированные, заточенные на работу одновременно на тысячах узлов и т.д., не буду перечислять их все. И у всех этих СУБД имеется или какой-то свой оригинальный язык запросов или же очень сильно мутированный SQL. И это очевидно не причуды авторов (гораздо легче было бы взять всем известное и популярное решение), а вынужденная необходимость, потому как стандартный SQL не имеет средств для решения этих задач.
Вот тут интересно... Что такого не умеет SQL, если мы буквально прой абзацев выше выяснили, что все эти концепции на SQL отлично ложатся? Коль скоро SQL к хадупу и прочим монгам прикручивают сейчас, что мешало реализовать его в самом начале?
Сдается мне, что причина в другом, все эти изделия родились из решения конкретной прикладной задачи, и в момент решения было не до SQLя, так как конкретная задача вполне выражалась императивно и никаких проблем с этим не было. Однако позже стало понятно, что есть целый класс задач, который можн решить посредством нового инструмента, но каждый раз выпиливать императивный код — долго, неэффективно и черевато ошибками, и тут вспомнили про SQL.
Иными словами, нормальный эволюционный путь от императивного кода к декларативному.

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

_>>И этот пример отлично демонстрирует одну из концептуальных проблем,
IB>Ну так сформулируйте уже эту концептуальную проблему наконец! ) Что мешает перейти от частного к общему?

Так уже было давно сформулировано, причём в сообщение, на которое ты отвечал (http://rsdn.org/forum/flame.comp/7132920.1

Автор: alex_public
Дата: 02.05.18

). Если есть трудности с чтением, то процитирую себя:

использования вычислений из соседних итерация ("строк"), использование отсортированных коллекций, использование коллекций типа деревьев и других вариаций на тему графов. А уж если вспомнить про множество задач с рекурсиями...

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

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

Кстати, особенно смешно это выглядит на фоне того же Sinclair'а, который с ходу отвечал на эти задачки, что Linq тут ничего не может.

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

Суть претензий в том, что любой школьник решит указанную задачку с помощью того самого императивного for'а в три строчки, а ты уже которое сообщение всеми силами отмазываешься от предложения продемонстрировать решение этой задачки с помощью linq. Мне кажется, что более эффектную демонстрацию ограниченности Linq даже трудно себе представить.

_>>Я уже формулировал и не раз.
IB>Не видел.
_>> Даже большое отдельное сообщение писал (не тебе) прямо на эту тему.
IB>Тема большая, мог и пропустить, повторите, если не сложно.

Вообще то видел и даже отвечал на это сообщение. Очередная жалкая отмазка...

_>> Только вот ты об этом вспоминаешь в очень специфические моменты и что-то пока вообще ничего не смог предложить от себя.
IB>То что предложенное мной не нравится, не значит, что я ничего не смог предложить ))

_>>Эммм, ты вообще сам то понял, что написал?
IB>Я очень хорошо понимаю в том о чем пришу, а вот вы похоже не совсем.
IB>Попытаюсь разжевать еще раз. SQL или LINQ описывают в терминах конечного результата, а не то, как именно этот результат надо получить. Таким образом, под капотом у select может быть и map/reduce. Таким образом, пенять sql-ю, что он map/reduce или другие какие распределенные вычисления не умеет, мягко говоря, не корректно. Тем более что умеет.

Ещё раз: выполнить sql запрос на каком-нибудь "императивном движке" (типа MapReduce) безусловно можно. Но при этом на том же движке можно выполнить ещё и другие запросы, не укладывающиеся в sql. Так понятно?

_>>Ну и в мире СУБД надеюсь скоро будет такая же ситуация, в первую очередь благодаря nosql решениям. Этот процесс очень явно виден.
IB>Явно виден процесс совершенно обратный, как в СУБД, так и других областях.



Ты надеюсь в курсе про такой API как OpenGL (ну и его аналог на винде Direct3D)? Он конечно совсем не декларативный, но относительно высокоуровневый. Так вот не так давно был представлен более низкоуровневый интерфейс под названием Vulkan. И вся индустрия начала очень быстро переползать на него. Почему? Ну он банально позволяет писать более производительный код. Ничего не напоминает, а? )))

Причём главные GUI библиотеки (считай аналог ORM) просто добавили себе новый бэкенд, так что их пользователи даже ничего не заметили. А вот те, кому нужна реальная производительность (топовые игры, cad'ы, рендереры, тяжёлые вычисления) получили инструмент для тонкого тюнинга под свои задачи.

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

_>>Ну а мне кажется, что не ошущаешь способности это сделать. ))) Причём сразу в двух простейших задачках. В общем уже всё понятно с тобой: как доходим до кода или других реальных аргументов, так сразу мгновенный слив.
IB>Мне в целом все равно, что вам кажется... Но в обоих случаях код будет не реальным аргументом, а попыткой увести дискуссию в сторону. Писать код здесь более-менее все умеют, а вот придерживаться четкой аргументации и не заниматься резней по цитатам, как видно, удается далеко не всем ))

Аааа, ну если у нас теперь код — это не реальный аргумент, а попытка увести дискуссию в сторону, то тогда тогда мне действительно всё понятно...

IB>На самом деле, против низкоуровнего api никто, ничего не имеет, пусть будет, если/пока он пользу приносит, но той пользы все меньше и меньше, и я вижу кто тут недооценивает скорость прогресса )

Вот если бы у существующих РСУБД он был (или появился сейчас), то это резко принесло бы пользу. Потому как позволило бы разделить данные монстроидальные продукты на два отдельных модуля. Один отвечающий за саму СУБД с простейшим API (чтение, запись, блокировки, статистики) и неким универсальным загрузчиком/исполнителем кода (какой-нибудь эффективной виртуальной машиной). И другой, генерирующий оптимальный код (сейчас это по сути называется планом) для этой виртуальной машины по переданным SQL запросам. В таком случае резко повысилась бы конкуренция в данной области (можно было менять исполнитель slq'я, не меня базу данных). Причём самое главное, что по сути всё вышеописанное и так уже существует (т.е. почти не надо писать нового кода), только внутри существующих СУБД и с непубличным API.

_>>"масштабируемость и параллельность это уже следствие." Так может ты способен предложить другое решение для обработки большого объёма данных? Нет? Тогда возможно это уже не просто следствие, а как раз целевое инженерное решение?
IB>Решение и есть следствие, а не причина. ))) Причина, как уже говорилось, появление нового класса задачь, для которого, с одной стороны, не критичны ограничения существующего подхода, а с другой, иные требования к производительности и объемам.

Задачи такие давным давно были, только подходящих инструментов не было. Поэтому их со страданиями делали (да и сейчас продолжают, т.к. не все решаются на переделку с нуля уже работающей системы) на РСУБД.

_>>Да, кстати, а что ты называешь отказоустойчивостью? Что-то я подозреваю, что nosql решения, развёрнутые на множестве узлов с резервированиями (см на тот же гугл) дадут гораздо большую доступность сервиса, чем одинокий сервер с РСУБД. Или ты быть может называешь отказоустойчивостью что-то другое? )
IB>Под отказоустойчивостью я понимаю полноценный ACID. nosql решение на множестве узлов будет доступно, но отвечать будет не всегда согласованно, может и чушь какую-нибудь выдать.

Ну так и SQL решения (да и любого другого — думаю тут все в курсе некой теоремы) с ACID на тысячи узлов тоже нет. Так что это не недостаток, а суровая реальность, с которой надо как-то жить...

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

_>>Уменьшение потребности обращения к низкому уровню не убирает его из цепочки, а всего лишь делает автоматически генерируемым для большинства случаев. И при необходимости (причём это может быть не только оптимизации, но и вообще написание нового языка) ты можешь в любой момент обратиться к этому низкому уровню. А в случае SQL у тебя нет этого низкого уровня в принципе — базовым API уже сложит высокоуровневый декларативный язык.
S>Нет, языки так не работают. Как только ты вмешиваешься в низкий уровень, ты начинаешь мешать.
S>Вот, компилятор хотел вовсе устранить переменную, т.к. она не нужна.
S>Но тут пришёл программист, и говорит "А напишу-ка я ассемблерную вставку", хреначит mov &i, eax, и вот компилятор уже вынужден резервировать место на стеке и складывать туда значение.

Давай всё же определимся. Если программист вставляет что-то подобное, то значит он знает что делает и это действительно лучшее решение. Иначе зачем ему это делать?

_>>Это слишком общая фраза, чтобы с ней можно было спорить или соглашаться. И кстати тех же C++ или SQL можно легко подвести под эту же мысль, только с другой стороны (сказать что они слишком низкоуровневые для определённых задач).
S>Конечно. Именно поэтому плюсами мир программирования не исчерпывается, и уровень SQL меня не устраивает. Он действительно слишком низкий для многих задач — стоило бы повысить выразительность и дать возможность СУБД исполнять его эффективнее, чем следовать навязанным стратегиям.

Вот тебе хорошо, т.к. тебе надо только "вверх" относительно SQL. А что предложишь делать тем, кому надо "вбок"? )

_>>И какое это всё имеет отношение, к обсуждаемой нами теме? )
S>Прямое: низкий уровень — это тупик.

Это не тупик, а это фундамент, на котором лежит весь мир IT. И да, чем больше мы создаём новых абстракций (а потом и абстракций поверх этих абстракций), тем меньше потребности к ручной правке этого фундамента. Но при этом он всегда в действие (исполняется именно такой код в итоге) и всегда под рукой для правки, если существующие абстракции не справляются.

_>>Почему бы и нет, особенно если сможешь ещё на сеть смаштабироваться. Возможно такое решение оказалось бы востребованным. И кстати, если бы современные СУБД имели низкоуровневый интерфейс, то ты бы возможно уже давно смог бы реализовать нечто подобное сам (при этом без потребности создания своей СУБД). Ну а в нашей реальности ты можешь только фантазировать (поверх SQL то такое не прикрутишь)...
S>Никакой низкоуровневый интерфейс тут не нужен. Прикрутке поверх SQL мешает, в первую очередь, как раз отстутствие "высокого уровня" — вот для C#, скажем, есть roslyn, который позволяет не писать парсер языка для того, чтобы реализовать какой-нибудь простенький анализ кода.

И как тебе roslyn поможет управлять локами в транзакции?

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

IT>Даже с этим проблема. Представь, что у тебя в linq выражении в финальной проекции создаётся клинтский класс, который нерадивый девелопер завязал на какой-нибудь местный view model, которая в свою очередь имеет ссылку на UIWPF форму, где используются другие ресурсы всего приложения. Таким образом, чтобы это заработало на сервере нужно туда передавать не только код всего приложения, но и используемый им фреймворк, т.к. он может отличаться от серверного и вообще быть не установлен на сервере. Думаешь весь этот паровоз взлетит?
Нуу, такой паровоз конечно не взлетит, но технически встроить язык таки можно.
Собственно Python и R в MSSQL уже встроили и питоновскую функцию вполне можно вкрячить в TSQL запрос. Другое дело, что если попытаться http запросы в этой функции отправлять или UI рисовать, то эффект будет забавным, но все же...

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

_>Так уже было давно сформулировано, причём в сообщение, на которое ты отвечал (http://rsdn.org/forum/flame.comp/7132920.1

Автор: alex_public
Дата: 02.05.18

). Если есть трудности с чтением, то процитирую себя:
_>

_>использования вычислений из соседних итерация ("строк"), использование отсортированных коллекций, использование коллекций типа деревьев и других вариаций на тему графов. А уж если вспомнить про множество задач с рекурсиями...

Это не общее, это опять набор частностей, ну допустим.
linq позволяет описать желаемый результат, вне зависимости от того, что там внизу за коллекция — отсортированная, дерево, граф, и т. д. Конкретная реализация этого линковского выражения может быть эффективной, а может не очень, но ее можно поменять на лету, не трогая прикладной код.
Поэтому попрежнему непонятно, где здесь проблемы у linq?

_>Кстати, особенно смешно это выглядит на фоне того же Sinclair'а, который с ходу отвечал на эти задачки, что Linq тут ничего не может.
Сейчас у нас опять начнется очередной раунд интерпретации его ответов. ))
От сказал, что это не задача linq, а не то что он не может. Чувствуете разницу? )

_>Ещё раз: выполнить sql запрос на каком-нибудь "императивном движке" (типа MapReduce) безусловно можно. Но при этом на том же движке можно выполнить ещё и другие запросы, не укладывающиеся в sql. Так понятно?
Не понятно. Какие другие запросы неукладываются в sql?

_>Ты надеюсь в курсе про такой API как OpenGL (ну и его аналог на винде Direct3D)?
Про OpenGL я в курсе, но не готов аргументировано дискутировать. Я не знаю степерь абстрагированности OpenGL и то насколько он удачно был написан, а так же не в курсе реальных причин перехода на более низкоуровневый API...
Но вижу что во всех других областях, как только прогресс доходит до определенного уровня, более высокоуровневые и декларативные конструкции вытесняют императивные. Скорее всего здесь тоже произойдет то же самое, хотя возможна своя специфика.

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

_>>Эм, какое ещё O(...), когда мы говорим о работе с нынешними СУБД (т.е. вся работа нашего кода заключается в генерации sql строк)?
S>Очень удобная позиция. "Мой код справился за 1мкс, а то, что СУБД была вынуждена лопатить 15 минут — это не ко мне вопрос".

А какая связь между временем генерации SQL строки (одной и той же) и тем сколько времени будет её исполнять сервер?

S>Людей не интересует работа вашего кода, их интересует решение бизнес-задачи.
S>Например, показать список отелей с номерами, удовлетворяющими запросу клиента, по возрастанию расстояния от Point of Interest. И сколько там времени работает JS, сколько Java, а сколько СУБД — неважно.
S>Важно, что надо успеть за секунду сделать всю работу. Поэтому потратить лишние 200мс на то, чтобы сэкономить лишнее обращение к СУБД — это хорошая идея.

Возможно и не плохая. Если конечно нельзя сэкономить это лишнее обращение, не потратив 200мс.

_>>Вообще то Фортран как раз является вполне универсальным императивным языком. Так что мне вполне хватило бы его убогой выразительности в качестве базового языка для передачи запросов в СУБД. )))
S>Вы, похоже, с Фортраном не знакомы.

)))

_>>Хотя в реальности было бы интереснее рассмотреть что-нибудь посовременнее, типа wasm.
S>Ничего интересного в wasm нету. Скукотня.

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

_>>Это понятно и правильно. Непонятно зачем тут linq. )))
S>Затем, чтобы мы писали запросы на языке высокого уровня, который поддерживает нормальную декомпозицию и манипуляцию запросами. В отличие, например, от SQL.

Ну так если мы говорим о передаче подобного императивного кода, то с ним напрямую справляются платформы типа Spark. Ну точнее вот это самое разделение одной функции на этапы делает сам программист, а вот потом этот код спокойно отсылается на исполнение сервером.

_>>Не очень понял про что ты. Но использование t4 для генерирования C# кода — это вполне себе МП (пусть и крайне убогое). Однако какое это имеет отношение к нашему вопросу?
S>То, что это такое же МП, как и "подготовка SQL кода по C# коду".

Ну во-первых не по C# коду, а по некому специальному AST. А во-вторых называть генерацию SQL строки для сервера метапрограммированием — это уже несколько перебор... Тогда уж все серверные веб-решения (выдающие в браузеры js код) тоже являются чисто метапрограммными инструментами. )))

_>>Он в любом случае задаётся программистом. ))) Просто в текущей ситуации с РСУБД этими программистами являются только создатели РСУБД, а программистам, использующим РСУБД, это недоступно. В отличие от популярных noslq решений, в которых это доступно всем.
S>Вы попадаете в стандартную ловушку фанатов низкого уровня: там, где вы видите "возможность", мы видим "обязанность". То есть вы хотите, чтобы программист мог писать эти алгоритмы. А я хочу — чтобы он мог их не писать.
S>Это гораздо ценнее.

По-моему это не противоречащие друг другу пожелания.

_>>Для слабых программистов тебе никто не мешает написать готовый фреймворк (собственно его даже писать с нуля не надо — можно просто скопировать основное из исходников текущих РСУБД), генерирующий нужный код для базовых случаев, задаваемых каким-то DSL.
S>Для базовых случаев неинтересно. Это опять приводит к тому, что либо ты сидишь на фреймворке, либо ты должен сразу написать 150 килобайт кода для минимальной модификации кода.
S>Фреймворк должен покрывать все практически интересные случаи. Вот после того, как он это делает, и можно обсуждать введение доп. велосипедности. Если она вообще потребуется.

Ну вот как мы тут выяснили, linq для коллекций точно не покрывает все интересные случаи.

_>>Так при создание range из двух итераторов он и подставляется.
S>В коде не было никакого создания из двух итераторов. Использовалась сама коллекция (массив) и её длина.

Посмотри повнимательнее http://rsdn.org/forum/flame.comp/7127041.1

Автор: alex_public
Дата: 26.04.18

. Передаётся именно два итератора (один указывает на начало и один на конец).

_>>Кстати, на самом деле для коллекций так делать не обязательно (т.е. внутри оно так и происходит, но писать этот код руками не надо — range умеет инициироваться по любой коллекции сам), я просто хотел продемонстрировать самый низкий уровень и универсальность подхода (итератор то может быть любым).
S>Вот это-то и непонятно.

Ну я думаю ты помнишь, что любая STL коллекция (да и в сторонних решениях обычно придерживаются этого подхода) имеет функции begin и end, возвращающие соответствующие итераторы. Соответственно элементарно пишется шаблонный конструктор range из произвольной коллекции. Ну и для встроенных массивов C он тоже есть. Так что можно не конструировать руками из итераторов, а сразу начинать цепочки с коллекции. А в данном примере я для наглядности показал как оно там всё происходит внутри.

_>>Вот не стоит передёргивать мои слова. Я нигде не говорил, что у C# есть какие-то проблемы с написанием подобного кода. Как раз наоборот, на C#, как на полноценном императивном языке, все описанные проблемные примеры легко реализуются (через банальный for и т.п., который уже даже может быть написан и находиться в библиотеке как готовая функция). Речь шла о неспособности решать эти задачи именно на Linq.
S>Linq решает другие задачи. У него нет цели давать низкоуровневый доступ для написания своих велосипедов.

Да, но при этом спектр охватываемых им задач меньше не только чем у тупого for, но даже меньше чем у цепочки range (тоже довольно абстрактной конструкции).

_>>Ну а можно писать код, который будет выполняться за O(1) и без анализа предусловий. )
S>Правда, выдавать будет фигню — но кого это интересует, да?

И выдавать будет нормальные данные, если соблюдать условия игры.