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

Gt_>да. вот прямо сейчас у них параллельна. зачем что-то ждать, если гарантия лишь на атомарность одной записи ?
Про атомарность пока что речи нет. Есть речь про durability.
Вот я заказал билет в кино — мне пришло емло с подтверждением. А тут внезапный "hard stop", и после перезапуска кинотеатр отброшен на нцать миллисекунд назад.
Вот, помнится, Билеты на матч "Сибирь" — ЦСКА в интернете были раскуплены за 20 минут. Примерно 7 тысяч билетов, примерно 6 билетов в секунду.
Хотелось бы убедиться, что выданный билет реально выдан, а не будет продан заново после рестарта. Если нет такого желания, то можно и не ждать.
А где-то и мест в 100 раз больше, и раскупают шустрее.

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

S>>А вот так — нет:
IB>Ну, прям так нет... Но через Y-комбинатор рекурсию можно.

Поиграл, выглядит оно малость через Ж:

    class Program
    {
        public class Node
        {
            public Node Parent;
            public string Name;
        }

        static Node parent1 = new Node { Name = "Parent1" };
        static Node child1 = new Node { Parent = parent1, Name = "Child1" };
        static Node child2 = new Node { Parent = child1, Name = "Child2" };

        static Node parent2 = new Node { Name = "Parent2" };
        static Node child3 = new Node { Parent = parent2, Name = "Child3" };

        static Node[] Nodes = new[] { parent1, parent2, child1, child2, child3 };

        static void Main(string[] args)
        {
            Func<T, T> Y<T>(Func<Func<T, T>, Func<T, T>> f) => x => f(Y(f))(x);

            var allChild = Y<IEnumerable<Node>>(
                f =>
                parents => {
                    var children =
                        from n in Nodes
                        from p in parents
                        where n.Parent == p
                        select n;

                    return children.FirstOrDefault() == null ? children : children.Union(f(children));
                }
            );

            Console.WriteLine("Children of Parent1: ");
            foreach (var node in allChild(new[] { parent1 })) {
                Console.WriteLine("* " + node.Name);
            }

            Console.WriteLine("Children of Parent2: ");
            foreach (var node in allChild(new[] { parent2 })) {
                Console.WriteLine("* " + node.Name);
            }
        }
    }

А для примера Синклера всё-равно придётся предварительно объявлять тип тупла аргументов, передаваемых рекурсивно Y-комбинатору, потому что вот так не сработало:

var allChild = Y(...

приходится так:

var allChild = Y<IEnumerable<Node>>(...

V>Ты имеешь ввиду ситуацию, когда SQL вообще представляется сущностю третьего рода, от бишь вовсе чужеродной хренью в программе, типа склеиваемых вручную строк? ))
Рассуждения уровня кодера, а не инженера. С точки зрения БД сущность третьего рода это как раз сторонние программы, к ней подключающиеся. Коих хорошая база данных повидает на своем веку множество, рождающихся и умирающих. SQL как гальваническая изоляция в электронике – обеспечивает развязку. Да, неидеально, да, есть потери, но лучше (по всем пунктам, а не в одном аспекте) еще не придумали.

Gt_>>да. вот прямо сейчас у них параллельна. зачем что-то ждать, если гарантия лишь на атомарность одной записи ?
S>Про атомарность пока что речи нет. Есть речь про durability.
S>Вот я заказал билет в кино — мне пришло емло с подтверждением. А тут внезапный "hard stop", и после перезапуска кинотеатр отброшен на нцать миллисекунд назад.
S>Вот, помнится, Билеты на матч "Сибирь" — ЦСКА в интернете были раскуплены за 20 минут. Примерно 7 тысяч билетов, примерно 6 билетов в секунду.
S>Хотелось бы убедиться, что выданный билет реально выдан, а не будет продан заново после рестарта. Если нет такого желания, то можно и не ждать.
S>А где-то и мест в 100 раз больше, и раскупают шустрее.

да причем тут чья-то речь ? я рассказываю откуда там легендарные скорости. они там от параллельности записи, в том числе и лога. а параллельность приводит и к отказу от транзакций.
билет это документ с полем продан, документ или запишется на какой-то ноде или нет. целиком. это атомарность. но если ты пошлешь пачку из 3х билетов и в этот момент пропадет питание у всего кластера, то после рестарта может так случиться, что из той пачки 2 билета проданы, а третий нет. третья нода не успела записать в лог продажу.
с точки зрения продаж билетов это вполне годно. 2 билета получат подтверждение, третий получит ошибку.

Gt_

Здравствуйте, Gt_, Вы писали:
Gt_>да причем тут чья-то речь ? я рассказываю откуда там легендарные скорости. они там от параллельности записи, в том числе и лога. а параллельность приводит и к отказу от транзакций.
Gt_>билет это документ с полем продан, документ или запишется на какой-то ноде или нет. целиком. это атомарность. но если ты пошлешь пачку из 3х билетов и в этот момент пропадет питание у всего кластера, то после рестарта может так случиться, что из той пачки 2 билета проданы, а третий нет. третья нода не успела записать в лог продажу.
Так, давайте помедленнее. Пока что нет никакой пачки — есть три человека, которые покупают билеты плюс-минус одновременно.
Предположим, что у нас есть волшебство, благодаря которому они покупают билеты на разные места. (Как это волшебство обеспечить в чудесной монге — это ещё вопрос).
Теперь, собственно, хочется понять, каким волшебным образом обеспечивается "легендарная скорость".
При этом нам важно иметь гарантию, что "подтверждённый" билет не исчезнет, как дым, после сбоя питания.
То есть мы не можем себе позволить возвращать подтверждение до того, как произойдёт сброс на диск.
Вот у нас первый заказ пошёл — все ноды (допустим, три) плюс-минус одновременно начинают писать в лог.
Кто-то из них медленнее, кто-то — быстрее. Тем не менее, мы всё ещё ждём как минимум одного ответа от самого шустрого.
Вот пошёл второй заказ — его не удастся записать до тех пор, пока самый шустрый первый не отдаст подтверждение, потому что у всех остальных HDD всё ещё занят записью первого билета.
Или там есть какая-то волшебная механика распределения работы так, чтобы первый билет даже не пытался писаться на нодах 2 и 3, чтобы следующий клиент сразу мог писать в ноду 2, а третий — в ноду 3?

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

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

Ого! Что я слышу. Ты прям звучишь как главный поборник и харикришна технической аргументации. Как я понимаю, самого тебя об этом просить бесполезно, т.к. ты у нас читатель, а не писатель. Ну да ладно, если у тебя у самого на столь элементарные примеры фантазии не хватает, то вот:

var q =
    from t in Table
    where t.Field1 == GetWpfCustomeEditFormData().CustomerDataField
    select new WpfCustomerViewModel(t.Field2, t.Field3);

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

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

Похоже ты абсолютно не въезжаешь в проблему.

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

Почему SQL недостаточно? И почему более низкоуровневый (это какой) API достаточно?

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

S>Теперь, собственно, хочется понять, каким волшебным образом обеспечивается "легендарная скорость".
S>При этом нам важно иметь гарантию, что "подтверждённый" билет не исчезнет, как дым, после сбоя питания.
S>То есть мы не можем себе позволить возвращать подтверждение до того, как произойдёт сброс на диск.
За монгу не могу сказать, но можно не ждать сброса на диск (ты sync имеешь в виду?), а просто подтверждение от вторичного узла(ов), что он получил сетевой пакет с заказом. Так работают некоторые биржи, и там количество заказов не 6 в секунду, а порядков на 5 больше.

S>Так, давайте помедленнее. Пока что нет никакой пачки — есть три человека, которые покупают билеты плюс-минус одновременно.
S>Предположим, что у нас есть волшебство, благодаря которому они покупают билеты на разные места. (Как это волшебство обеспечить в чудесной монге — это ещё вопрос).
S>Теперь, собственно, хочется понять, каким волшебным образом обеспечивается "легендарная скорость".
S>При этом нам важно иметь гарантию, что "подтверждённый" билет не исчезнет, как дым, после сбоя питания.
S>То есть мы не можем себе позволить возвращать подтверждение до того, как произойдёт сброс на диск.
S>Вот у нас первый заказ пошёл — все ноды (допустим, три) плюс-минус одновременно начинают писать в лог.
S>Кто-то из них медленнее, кто-то — быстрее. Тем не менее, мы всё ещё ждём как минимум одного ответа от самого шустрого.
S>Вот пошёл второй заказ — его не удастся записать до тех пор, пока самый шустрый первый не отдаст подтверждение, потому что у всех остальных HDD всё ещё занят записью первого билета.
S>Или там есть какая-то волшебная механика распределения работы так, чтобы первый билет даже не пытался писаться на нодах 2 и 3, чтобы следующий клиент сразу мог писать в ноду 2, а третий — в ноду 3?

есть. шардинг называется https://docs.mongodb.com/manual/sharding/
каждый билет жилет на своей ноде, полностью независимой. у каждой ноды свой лог и свой HDD под лог. на счет реплики (standby по нашему) не знаю, обязана ли каждая нода реплику иметь.

Gt_

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

_>Эм, а ты сам то свою ссылку открывал, читал?

Открывал, смотрел по диагонали. Глубже не было смысла читать, ибо это "витрина" для внешнего мира, а у меня есть возможность регулярно использовать YQL вживую и читать внутреннюю документацию.
Питоном я при этом практически не пользуюсь (кроме редких случаев, когда нужно динамически генерировать YQL и выполнять его из скрипта), Jupyter'ом не пользуюсь вообще, ибо родного YQLного UI более чем хватает для моих задач.

_>А то там на первой же картинке под названием "Архитектура YQL" красуются и Python и Jupyter...

Угу, первый в качестве одного из языков расширения и одного из публичных API, второй — в качестве одного из возможных UI. Если их выкинуть, работоспособность YQL практически никак не пострадает.

_>И потом ещё идёт целая отдельная секция статьи просвещенна интеграции с Питоном, даже со скринами того самого Jupyter Notebook.

Вполне логично, ибо глупо выбрасывать тонны наработок и писать альтернативы с нуля.

_>В общем фееричное возражение у тебя получилось...

Ты его просто не понял. Статья вполне явно показывает, что в Яндексе тренд идет вовсе не в сторону отказа от SQLя в пользу питона, а, наоборот, в сторону создания "продвинутого SQLя", который позволяет решать многие задачи обработки данных вообще без питона, плюс позволяет интегрироваться с питоном, если возможностей одного YQLя недостаточно.

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

vsb>Ну вот должен-должен, а мне для каждого nullable-параметра приходится писать x == :param or x is null and :param is null (ну или делать динамический SQL, что в некоторых случаях ещё хуже). Неудобно. Особенно в каком-нибудь оракле, где пустая строка это null.

V>>Ты же понимаешь, что математически вот этот предикат абсурден: IS NOT NULL?

vsb>Не понимаю. Это синтаксический сахар для not (x is null). Что тут абсурдного? У меня претензия к тому, что (null == null) == false. Этого я не понимаю. Или не понимаю, почему нет специального оператора, какой-нибудь x =is= y, для которого (null =is= null) = true.

Как в IEEE754: вводить отдельный total ordering и операции сравнения по нему.
Но тогда NULLS FIRST и NULLS LAST потребуют введения -NULL и +NULL соответственно

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

Gt_>не, смешно было когда ты блокировки на чтение оракла нашел.
Так они все еще там есть, смешно что вам до сих пор их не видно. )) Еще смешнее здесь об этом писать. Ну натурально, за 15 лет так и не разобраться о чем там шла речь, но лелеять в памяти — вот у вас рвануло-то! =))
Может стоит перечитать ту статью, вдруг дойдет о чем там говорилось? Подучитесь наконец? ))

Gt_> хотя теперь постулат фреймворк = декларативность даже смешнее тех перлов.
Вот и тогда ржали, вместо того чтобы попытаться понять что говорят, продолжайте )

Gt_>мудрецы яндекс за неименеем спецов и е-майлы на оракле делали, мягко говоря не показатель. теперь них спецы только по С, но все равно как уже указали, там повсюду все тот же питон.
Ну конечно, яндекс неправильный, вы-то точно знаете как лучше делать ))
Там даже в том скриншоте с юпитером видно как предполагается этот язык использовать и где там питон.

Gt_>sql в бигдате лишь еще один интерфейс.
Конечно еще один. Не было, потом появился, очевидный же тренд?

Gt_>Ваня, ты можешь злиться, можешь бухать, но скрипты питона не станут декларативными.
Я нарошно ушел от термина "декларативный" к уровню абстракции, чтобы понятнее было, но теперь видно кто злится и бухает ))

Gt_>в ынтрпрайзе обычно из даталейка, а даталейк это просто parquet, csv, json файлики на hdfs. если объем не велик, просто могут к себе в винду скопировать файлики и играть с ними локально.
Прекрасно, то есть данные у нас в хадупе, на самом деле, к которому, как мы уже выяснили, прикручивают SQL. Какой там у нас тренд, напомните? То есть, не выиграл, а проиграл и не в шахматы, а в преферанс ))
Но даже не важно. Допустим получили мы наши csv-шки или json... И с какого боку к ним sql прислонять?
Когда источник данных понимал sql — использовали sql, когда он стал в csv или json, то вкрячивать между ними и питоном sql, очевидно странная затея. Как и предполагалось, пример вообще про другое, и не имеет никакого отношения к обсуждаемому вопросу.

Gt_>>не, смешно было когда ты блокировки на чтение оракла нашел.
IB>Так они все еще там есть, смешно что вам до сих пор их не видно. ))
и вот это еще рассуждает о выученных билетах

IB>Ну конечно, яндекс неправильный, вы-то точно знаете как лучше делать ))
не, яндекс конечно же безусловный авторитет, после того как почту запилил на oracle EE edition с rac, партишинингом, датагвардом и прочими лицензиями. ну реально, кто бы из профессионалов мог бы заранее предвидеть, что могучий оракл не совсем тот инструмент и выйдет дорого. а ставка на С++, тоже чувствуется глубокое понимание ...

Gt_>>sql в бигдате лишь еще один интерфейс.
IB>Конечно еще один. Не было, потом появился, очевидный же тренд?
тренд уход от hive sql к всяким spark dataframe, который дает больше низкоуровневых возможностей, не отнимая sql. по моим наблюдениям джависты sql вообще не пользуют в спарке.

IB>Я нарошно ушел от термина "декларативный" к уровню абстракции, чтобы понятнее было, но теперь видно кто злится и бухает ))
ты ушел, но я то запомнил твой перл о декларативных питон скриптах для работы с tensorflow.

IB>Прекрасно, то есть данные у нас в хадупе, на самом деле, к которому, как мы уже выяснили, прикручивают SQL. Какой там у нас тренд, напомните? То есть, не выиграл, а проиграл и не в шахматы, а в преферанс ))
IB>Но даже не важно. Допустим получили мы наши csv-шки или json... И с какого боку к ним sql прислонять?
IB>Когда источник данных понимал sql — использовали sql, когда он стал в csv или json, то вкрячивать между ними и питоном sql, очевидно странная затея. Как и предполагалось, пример вообще про другое, и не имеет никакого отношения к обсуждаемому вопросу.
тренд я напомнил, прислонить hive sql к parquet/csv/json секундное дело, просто create table .. stored as textfile location '/folder'
причем табличку делают один раз, а потом просто закидывают новый файлик в фолдер.
create table и sql это здорово, но дальше то о чем alex_public говорит, люди захотели большего. больше гибкости, джоинить не реляционные данные, подключать библиотеки ML, тут-же генерить графики. декларативный язык заточенный лишь на работу с реляционными данными все это может через обходные маневры, но тенденция явно просматривается в туче задач. люди хотят большего.

Gt_

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

Gt_>и вот это еще рассуждает о выученных билетах
Искреннюю веру ничем не перебить, преклоняюсь перед вашей упертостью ))

Gt_>не, яндекс конечно же безусловный авторитет, после того как почту запилил на oracle EE edition с rac, партишинингом, датагвардом и прочими лицензиями.
Яндекс авторитет после того что делает с ML и AI, каких людей к себе сманил и какие задачи им ставит. Относиться к ним можно по разному, но упрекать в не проффесионализме, как минимум не профессионально, а как максимум — глупо.

Gt_>тренд уход от hive sql к всяким spark dataframe, который дает больше низкоуровневых возможностей, не отнимая sql. по моим наблюдениям джависты sql вообще не пользуют в спарке.
продолжайте наблюдать ))

Gt_>ты ушел, но я то запомнил твой перл о декларативных питон скриптах для работы с tensorflow.
Так они и есть декларативные. Если вы этого не понимаете, то я вам ни чем не могу помочь ))

Gt_>тренд я напомнил, прислонить hive sql к parquet/csv/json секундное дело, просто create table .. stored as textfile location '/folder'
Gt_>причем табличку делают один раз, а потом просто закидывают новый файлик в фолдер.
Еще раз, медленно. Прислонять sql к hdfs для выбора файлов не надо, он там и так есть, прислонять его надо к содержимому этих самых файликов. Когда язык питон, а данные в csv или в json-e, то без вариантов, сидишь и скалдываешь. Вот был бы шарп, обрабатывали бы все linq-ом, а питон увы, до линка пока не дорос.

Gt_>больше гибкости, джоинить не реляционные данные, подключать библиотеки ML, тут-же генерить графики. декларативный язык заточенный лишь на работу с реляционными данными все это может через обходные маневры, но тенденция явно просматривается в туче задач. люди хотят большего.
Совершенно верно, тенденции просматриваются. Например, тот же яндекс наелся ручного выпиливания питоном по csv и начал делать свой SQL-подобный язык, который обладает нужными свойствами. Действительно, люди хотят большего.

Gt_>>ты ушел, но я то запомнил твой перл о декларативных питон скриптах для работы с tensorflow.
IB>Так они и есть декларативные. Если вы этого не понимаете, то я вам ни чем не могу помочь ))

ты то понятно что не можешь, с твоими то познаниями. это я тебе могу помочь

Gt_>>тренд я напомнил, прислонить hive sql к parquet/csv/json секундное дело, просто create table .. stored as textfile location '/folder'
Gt_>>причем табличку делают один раз, а потом просто закидывают новый файлик в фолдер.
IB>Еще раз, медленно. Прислонять sql к hdfs для выбора файлов не надо, он там и так есть, прислонять его надо к содержимому этих самых файликов. Когда язык питон, а данные в csv или в json-e, то без вариантов, сидишь и скалдываешь.

я так смотрю кругозор за 15 так и остался на уровне школоло. не надо тебе медленно, надо сосредоточиться. второй раз разжевываю: обрабатывать данные в формате parquet, csv, json и прочих можно и на декларативном sql. сами данные. не надо файлики выбирать, речь об обработке данных из файлов перед тем как скормить ML фреймворку. когда-то многие аналитики реально все трансформации в sql делали, но теперь декларативный sql у них не модно. и я разжувал почему.

IB>Вот был бы шарп, обрабатывали бы все linq-ом, а питон увы, до линка пока не дорос.

шарп ? в одном потоке насилуя одно ядро ? смешно. какое может быть сравнение с питон скриптами которые они запросто и на кластере yarn выполняют ?

IB>Совершенно верно, тенденции просматриваются. Например, тот же яндекс наелся ручного выпиливания питоном по csv и начал делать свой SQL-подобный язык, который обладает нужными свойствами. Действительно, люди хотят большего.

да выкинет яндекс эту муть точно так же как выкинул почту на оракле. то что яндекс сделал ставку на C++ и проиграл уже давно понятно.
и в догонку — структурированные данные в даталейк модно грузить в хорошо структурированные хранилища, например в parquet файлики. зачастую ровно в те же star схемы, что ранее грузили в рсубд, что бы не возиться с уже созданными под рдбмс BI/отчетами. почему ? да потому что sql на эти же файлики отлично работает. есть hive sql, есть impala, есть spark sql, но тем кому удобней чем-то с более широкими возможностями, типа аналитиков, отходят от sql. и ETL отходят. и доставка данных теперь всякими kafka модно, тоже то где раньше sql властвовал.

Gt_

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

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

Да всё что угодно. Сравнивать API hadoop и SQL — это тоже самое, что сравнивать C++ и 1C...

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

Не верно. И у тебя уже не первый раз проскакивает эта принципиальная ошибка в оценке того, какое множество включено в какое. Как раз любое sql решение можно выразить через низкоуровневые nosql инструменты. А вот обратное не верное — мы не можем выразить все возможные nosql решения через sql.

IB>Сдается мне, что причина в другом, все эти изделия родились из решения конкретной прикладной задачи, и в момент решения было не до SQLя, так как конкретная задача вполне выражалась императивно и никаких проблем с этим не было. Однако позже стало понятно, что есть целый класс задач, который можн решить посредством нового инструмента, но каждый раз выпиливать императивный код — долго, неэффективно и черевато ошибками, и тут вспомнили про SQL.
IB>Иными словами, нормальный эволюционный путь от императивного кода к декларативному.

Совершенно верно. И пока мы не будем убирать фундамент из полученной пирамиды абстракций, у нас всё будет отлично. А вот если мы выкинем возможность доступа на самом фундаментальном уровне (как сейчас в мире РСУБД), то сразу получим не эволюцию, а деградацию.

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

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

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

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

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

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

Ну так если проблем нет, то почему я не вижу кода обсуждаемых примеров? В чём проблема "описать на linq желаемый результат"? Вот на русском языке это звучит так: хотим получить массив, каждый элемент которого является усреднением соседей этого элемента в исходном двухмерном массиве. Вроде бы как раз описание желаемого результата, без каких-либо указаний о механизме реализации. Покажешь как это сформулировать на linq?

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

И в чём разница?

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

Ну для РСУБД это например все те, для которых сейчас применяется PL/SQL... ))) А для вообще СУБД там будет ещё много чего интересного, в зависимости от конкретной задачи (см. разные nosql СУБД — в большинстве из них есть что-то своё, не реализуемое на SQL).

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

Более высокоуровневые чем OpenGL уже давно есть — это всяческие GUI библиотеки, игровые движки и т.п. Но их все просто переписали (точнее бэкенд в них, т.к. он и так был выделен в отдельную абстракцию в силу наличия в прошлом нескольких конкурирующих API, типа того же Direct3D) под новый более низкоуровневый API, потому что он дал большее быстродействие. Причём пользователи этих библиотек возможно даже не заметили разницу. Так как и пользователи различных ORM могут не заметить разницу при замене SQL на что-то более эффективное.

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

_>>Аааа, ну если у нас теперь код — это не реальный аргумент, а попытка увести дискуссию в сторону, то тогда тогда мне действительно всё понятно...
IB>Конечно, все от контекста зависит )))



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

Наоборот, это ускорит прогресс, т.к. наконец то появится реальная конкуренция.

IB>А во-вторых, сильно снизит эффективность работы оптимизатора и планировщика, так как если на уровень ниже имеет доступ прикладной программист, то фиг знает что он там написал и нельзя полагаться на некоторые инварианты и внутренние договоренности. При том что реально этот низкий уровень никому не нужен, я не верю, что кто-то в серьез будет пытаться обыграть оптимизатор и планировщик на их поле, переделывая алгоритмы каждый раз, как изменится статистика.

Естественно какой-нибудь малоспособный энтерпрайзный программист из банка таким заниматься не будет. А вот автор какого-нибудь крутого фреймворка (ORM или ещё что-то подобное) вполне может осилить интересные решения. А в некоторых случаях возможно будет смысл взять готовое решение и подправить в нём пару строк по свою специфику. В общем нормальная жизнь разработчиков.

_>>Задачи такие давным давно были, только подходящих инструментов не было.
IB>Да ладно, инструменты появились моментально, как материализовалась потребность. Какое-то время они были для внутреннего потребления, потом вышли наружу.

Ну я имел ввиду появление доступных всем инструментов. А так да, Bigtable кажется в 2004-ом начали.

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

И я тебе уже сказал, что это у тебя в корне не правильное понимание.

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

_>Да всё что угодно. Сравнивать API hadoop и SQL — это тоже самое, что сравнивать C++ и 1C...
Не, что угодно — не ответ ) В каких конкретно сценариях не хватает возможностей sql и нужен доступ к потрохам СУБД?

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

_> А вот обратное не верное — мы не можем выразить все возможные nosql решения через sql.
Я кажется понял в чем у вас проблема, вы там выше писали, что "sql не имеет средств для решения задач". Так вот sql — не средство решения задач, это средство описания результата.
Если требовать от sql-я то же что и от императивного языка, то естественно будет куча претензий, но он вообще-то про другое )
Коль скоро мы можем описать желаемый результат, то совершенно пофиг через какое решение он там выражается, это уже задача сервера выбрать оптимальный алгоритм.

_>Совершенно верно. И пока мы не будем убирать фундамент из полученной пирамиды абстракций, у нас всё будет отлично. А вот если мы выкинем возможность доступа на самом фундаментальном уровне (как сейчас в мире РСУБД), то сразу получим не эволюцию, а деградацию.
Как раз наоборот, наличие низкоуровневого API ограничивает возможности оптимизации и эволюцию самих серверов.
В РСУБД, наличие теории и строгой мат-модели позволило формально доказать, что императивное API не нужно для достижения результата, поэтому его и не было изначально. nosql идут от практики, но закончится все тем же, скорее всего.

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

Gt_>ты то понятно что не можешь, с твоими то познаниями.
Не надо завидовать моим познаниям, просто поработайте над собой ))

Gt_>это я тебе могу помочь
Можете поднять настроение ))

Gt_>кругозор за 15 так и остался на уровне школоло.
Я заметил, сочувствую...

Gt_> когда-то многие аналитики реально все трансформации в sql делали, но теперь декларативный sql у них не модно. и я разжувал почему.
Это я разжевал почему, но видимо не дошло ))

Gt_>шарп ? в одном потоке насилуя одно ядро ? смешно. какое может быть сравнение с питон скриптами которые они запросто и на кластере yarn выполняют ?
:doublefacepalm: Идите, пилите свои скрипты на питоне.

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

_>Наоборот, это ускорит прогресс, т.к. наконец то появится реальная конкуренция.
Ну да, а сейчас чем конкуренция не реальная? ) С чем с чем, а с конкуренцией все хорошо.

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

_>И я тебе уже сказал, что это у тебя в корне не правильное понимание.
У меня в корне правильное понимание )