Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Там проблема идеологического плана. C# тим вообще не хочет заниматься оптимизациями, а у JIT слишком мало времени. Что самое удивительное, Мэдс как раз за то чтобы двигаться в этом направлении, а вот новая молодежь, которая занимается сейчас Розлином, активно против.
Хипстеры... Хайлсберга на них нет.

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

_>А что там не так https://db-engines.com/en/ranking_trend ?
Ну, например то, что монга вышла на плато, в то время как насквозь реляционная Postgre протоптала монгу и идет дальше вверх.

_>Это где ты там увидел про образец? )
там где они сравнивают с SQL решениями. Вот этот вот пассаж особенно прекрасен: such as MySQL – were originally designed with only consistency and availability in mind.
Это MySQL-то про consistency и availability? Сразу видно, маркетолог для маркетологов писал.

_> Ну и кстати по производительности и популярности MySQL очень даже хороша, но это в любом случае не обсуждалось в статье — там сравнивались между собой разные noSQL СУБД. Причём для применения в банках...
Важно для какого именно применения в банках. Даже в этой статье не предлагается выкинуть реляционное хранилище и заменить его на NoSQL. Предлагается для биг-дата аналитики выгружать данные в NoSQL и изнурительно их там считать. В целом, в этом нет ничего нового, OLAP — это тоже не SQL и применяется примерно для таких же сценариев.
Иными словами, noSQL — это не замена SQL, а новый инструмент для нового сценария (Big Data). Насколько этот новый инструмент удачен — это отдельный вопрос, но даже здесь он не является альтернативой SQL-ю.

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

S>А что тут представлять???
S>

S>begin tran
S>insert into master (name) values ('Первыйнах')
S>set @ID1 = SCOPE_IDENTITY()
S>insert into slave(masterId, Name) values (@ID1, 'Первый-1')
S>insert into slave(masterId, Name) values (@ID1, 'Первый-2')
S>insert into master (name) values ('Между первой и второй перерыва вовсе нет')
S>set @ID2 = SCOPE_IDENTITY()
S>insert into slave(masterId, Name) values (@ID2, 'Второй-1')
S>insert into slave(masterId, Name) values (@ID2, 'Второй-2')
S>commit tran
S>

Какой кошмар. ))
А если в док-те порядка 250-ти строк?
На той технике (не мега-кластерной, а на простых пнях на 150 МГц тактовой) подобные подходы работали так себе.


S>И по-прежнему клиенту не обязательно знать идентификаторы заранее. Никаких тебе заморочек с над-реляционными кластерами.

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

В моих системах я делал так:
— заводил для редактируемых док-тов временные таблицы уровня пользователя;
— клиент редактирует, программа периодически пачками скидывает данные на сервак приложений (сохранять построчно-синхронно на трехзвенке на той технике было просто нереально — полусекундные спотыкания раздражают), сервак приложений обновляет данные во временных таблицах сервака базы;
— при потере связи клиента с сервером приложений или сервера приложений с базой данных ничего страшного не происходит (это как раз разрабатывалось в те времена, когда надёжной связи не существовало в принципе, даже локальной, бо тогда был коаксиал);
— для сохранения док-та делаются простые insert into из временных таблиц в обычные;
— при отмене док-та, т.е. удалении без сохранения, сервак приложений возвращает этот ID в список свободных.

Схема простая донельзя.

В твоём же варианте в любом случае надо придумывать уникальный ID для нового док-та, потому что пользователь может редактировать несколько док-тов, возвращаться к ним и т.д. Т.е. сама задача не пропадает, просто переезжает с одного места в другое.

У меня было так — можно было выйти из проги, с другого компа зайти и продолжить редактировать док-ты.
Такая функциональность получилась как побочный эффект от попыток борьбы с последствиями обрывов связи.
Потому что самая первая версия, которая была без такой защиты, вызывала нарекания именно по этому вопросу, т.е. такая функциональность была реализована одной из первых, среди других "навороченных". ))

А мне тут в соседних топиках Cyberax втирает, что подобные трюки являются сверхсовременными и только Гугл их асилил.

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

V>>Есть ли еще на свете такая система, где я одним запросом достаю удалённые данные и делаю им join с некими локальными? ))
S>Продолжаем нести свет в массы: да, есть такая система, как минимум одна. Называется MS SQL Server.

Это out of proc и для локального кеша является наихудшим выбором. ))

Здравствуйте, vdimas, Вы писали:
V>Это out of proc и для локального кеша является наихудшим выбором. ))
Есть аргументы, выраженные в цифрах?
А то у меня есть существенные подозрения, что на современном железе стоимость межпроцессного обмена пренебрежимо мала по сравнению с доставанием данных с локального диска.

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

V>>Это out of proc и для локального кеша является наихудшим выбором. ))
S>Есть аргументы, выраженные в цифрах?
S>А то у меня есть существенные подозрения, что на современном железе стоимость межпроцессного обмена пренебрежимо мала по сравнению с доставанием данных с локального диска.

Ну я когда-то наэкспериментировался.
Out-of-proc сервера работали существенно медленнее in-proc даже тогда, когда чтение с диска было на порядки дольше, чем из ОП, т.е. казалось бы... Ан нет. ))

Ограничение снизу для in-proc всегда было близко к 0-лю.
Да, я в курсе, что ты всё время напираешь на ограничение сверху, но это имеет смысл только для каких-то слишком сложных вычислений.
А так-то для самых ходовых сценариев должно быть малое время отклика, т.е. больше интересует ограничение снизу.

Сейчас из RAID SSD данные заливаются "сами" через DMA на скорости работы самой оперативки.
Т.е. чтением с диска можно пренебречь в сравнении с другими затратами, бо за один маленький чих со стороны проца заливается целая страница или группа их (причём, страницы сейчас не обязательно по 4 KB, запросто и по 64). Ну и, данные из диска в любом случае читать надо.

А вот "ручным" проталкиванием каждого байта через пайпы или сокеты пренебречь не получится при их наличии.
Более того, большой их параллельный трафик из разных потоков сильно тормозит систему в целом.
Пусть даже на стороне ДБ-сервака сидит "умный" пул, который, ну разумеется, создаст столько потоков, сколько есть ядер в системе.
А на стороне Апп-сервака сидит не менее умный пул с таким же кол-вом потоком.
Дальше объяснять требуется, почему уже давно выгодней вынести out-of-proc на другой комп по быстрой сетке, чем крутить его локально? Или и так уже понятно? ))

Здравствуйте, vdimas, Вы писали:
V>Ну я когда-то наэкспериментировался.
Ну, то есть данных нет.
V>Out-of-proc сервера работали существенно медленнее in-proc даже тогда, когда чтение с диска было на порядки дольше, чем из ОП, т.е. казалось бы... Ан нет. ))
V>Ограничение снизу для in-proc всегда было близко к 0-лю.
Мы всё ещё про MS Access?
V>А так-то для самых ходовых сценариев должно быть малое время отклика, т.е. больше интересует ограничение снизу.
Это для каких, например?
V>Сейчас из RAID SSD данные заливаются "сами" через DMA на скорости работы самой оперативки.
Мы всё ещё о настольном решении, в котором есть и "локальный кэш" и удалённое подключение? Или мы всеръёз рассуждаем о применимости MS Access на сервере в боевом режиме?
V>Т.е. чтением с диска можно пренебречь в сравнении с другими затратами, бо за один маленький чих со стороны проца заливается целая страница или группа их (причём, страницы сейчас не обязательно по 4 KB, запросто и по 64). Ну и, данные из диска в любом случае читать надо.
V>А вот "ручным" проталкиванием каждого байта через пайпы или сокеты пренебречь не получится при их наличии.
Эмм? Каждого байта? Откуда такие фантазии? Очень рекомендую ознакомиться с архитектурой современных сетевых стеков. Ну, чтобы представлять, что происходит, когда выполняется чтение из сокета, подключенного к 127.0.0.1.
Но и это — не лучший выбор для out-of-proc, по сравнению, скажем, с shared memory, которую SQL Server использует по умолчанию при локальном подключении.

В общем, прекращаем распространять тьму невежства.

V>Более того, большой их параллельный трафик из разных потоков сильно тормозит систему в целом.
Да ладно!
V>Пусть даже на стороне ДБ-сервака сидит "умный" пул, который, ну разумеется, создаст столько потоков, сколько есть ядер в системе.
V>А на стороне Апп-сервака сидит не менее умный пул с таким же кол-вом потоком.
V>Дальше объяснять требуется, почему уже давно выгодней вынести out-of-proc на другой комп по быстрой сетке, чем крутить его локально? Или и так уже понятно? ))
(facepalm). Локально крутить RDBMS вообще имеет смысл только при недогрузке CPU. А в таких условиях вынесение out-of-proc на другой комп "по быстрой сетке" будет как раз невыгодно.

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

V>>Ну я когда-то наэкспериментировался.
S>Ну, то есть данных нет.

Не хами.
Данные тебе были даны — более полусекунды лагов при построчном редактировании в простой двухзвенке.
Таковы реалии 96-97-го года.


V>>Ограничение снизу для in-proc всегда было близко к 0-лю.
S>Мы всё ещё про MS Access?

У MS Access визуальные формы поверх данных на DAO воообще быстрее всего летали.
Быстрее не существовало в природе на тот момент, потому что народ не понимал толком, как машины работают.
Натурально.
По крайней мере подавляющее большинство программистов, которые разрабатывали именно программы, работающие с БД, т.е. всякие учётные системы.
Эти гаврики по-жизни были от земли оторваны и нихрена не соображали.
Зато горазды лепить отмазки, почему и соображать не надо.

Кароч, если дёргать из MS Access данные через ADO, т.е. пробегаться по выборкам — это жуткое нубство.
Его надо пользовать через DAO, в режиме ODBCDirect, при исполнении запросов указывать способ навигации через индексы, то бишь по-сути будут запрошены лишь индексы нужных строк. А сами данные запрашиваются в основном по мере прорисовки формы на экране (таблицы на форме).
Вот тут и стоит помедитировать, ИМХО. ))
И да, пресловутая jet db в этом режиме не используется.
А то я помню, как тут некоторые руки заламывали, мол, почему Янус тормозит, виновата jet engine.
Виновато, для начала, ADODB, это если с самого начала начинать.

В общем, в 96-м году при отображении данных не спотыкался только MS Access.
Формы на FoxPro или на Клиппере имели кое-какую задержку при отображении.
Про Oracle вообще говорить смысла не было без техники за десятки тыщ баксов.
Sybase был так себе в те года, потом появился в точности такой же брат-близнец MS SQL. ))
Оба сливали по удобству и возможностям языка даже галимому Interbase.
Такое безобразие творилось вплоть до выхода верси MS SQL 7.0, которую следовало бы назвать 1.0, ы-ы-ы.
А 6-ку следовало бы назвать открытой альфой, даже не бетой.

Вот в таких условиях приходилось вертеться.
Скажи, тебе пришлось в своё время вдоволь натрахаться с 6-ым MS SQL? ))

А еще вокруг заполонили дельфисты, со своими херак-херак и в продакшен c умными видом.
Но для меня это всегда была как обратная сторона Луны, хотя на Дельфи одно время поупражнялся.
На асме и то прикольней, если вдруг приходится код именно писать, а не просто мышой накидывать. ))
В асме хотя бы мощнейший макропроцессор, а в Дельфях аж нифига от слова совсем.
Прямо смертная тоска берет. ))
Мне всегда казалось, что работать в Борланд или на их прожуктах — это такое наказание для непослушных инженеров.
Пока они клепали самую лучшую в мире среду для С++ (пусть даже текстовую), они были мега-популярны и уважаемы.
Как только забросили С++, так буквально за 3-4 года превратились в ничто и звать никак.
И до сих пор оттуда вылезти не могут.

V>>А так-то для самых ходовых сценариев должно быть малое время отклика, т.е. больше интересует ограничение снизу.
S>Это для каких, например?

Это когда девочка набирает по 2-3 строки заказа в секунду.
На той технике.
А сейчас смотрю на современные WPF/C# приложухи, на быстрые сетки... но не уверен, что на современной мейнстимовой платформе можно набивать данные с такой же скоростью. Сейчас всё всегда тормозит. При том, что мощности выросли в 100 раз.


V>>Сейчас из RAID SSD данные заливаются "сами" через DMA на скорости работы самой оперативки.
S>Мы всё ещё о настольном решении, в котором есть и "локальный кэш" и удалённое подключение?

Мы сейчас про что угодно.
У меня RAID SSD даже на ноуте.
Сейчас интелловские RAID-контроллеры везде, считай, кроме совсем начального уровня.
Два диска в параллель и огонь.


S>Или мы всеръёз рассуждаем о применимости MS Access на сервере в боевом режиме?

Мы всерьёз рассуждаем о твоей наивности.
Ты опять херню какую-то предполагать изволишь, аки Тереза Мэй, и ни мало не стесняясь годами обвиняешь оппонентов в одном и том же.
Прямо как строгий отец, который больше всего гоняет детей за собственные недостатки.
Т.е. явно у тебя бабка с негром согрешила было вдоволь неудачного опыта на файловый базах, что ты аж до сих пор не знал, что такое ISAM.

Кароч, уже было всё сказано, каким образом использовался MS Access — как GUI платформа, как удобный конструктор и САМЫЙ эффективный (на тот момент) COM-сервер своих объектов.
Потому что абсолютно все его контролы были windowsless.
Даже EDIT.
Даже списки и таблицы.
Даже TAB-контрол.
Вообще все.
Просто окно верхнего уровня всегда, которое даже не содержало дочерних окон-скроллбаров.
Всё рисовалось само.
Другой такой системы в природе не существовало, поэтому нагруженные формы с данными можно было лепить только на ём, используя его как каркас.
Благо, собственные ActiveX-контролы или просто COM-объекты с поддержкой визуального редакторивания св-в можно было делать самим на раз-два.

А всё остальное еле пыхало.
Для сравнения, в Дельфях windowsless были только лейблы, круги-овалы и всякие рамки вокруг окон.
Но эти контролы не "равнозначны" полноценным, а в хосте MS Access любые ActiveX контролы были вполне равнозначный.

Ну и про идиому использования собственной базы приложения как эффективного локального кеша-аагрегатора разных истоников данных — тоже уже говорил.

Просто мне и на MFC пришлось одно время поупражняться.
ТАк смешно выходит, что писаная полностю нейтивная прога для работы с БД будет сливать MS Access безбожно.


V>>Т.е. чтением с диска можно пренебречь в сравнении с другими затратами, бо за один маленький чих со стороны проца заливается целая страница или группа их (причём, страницы сейчас не обязательно по 4 KB, запросто и по 64). Ну и, данные из диска в любом случае читать надо.
V>>А вот "ручным" проталкиванием каждого байта через пайпы или сокеты пренебречь не получится при их наличии.
S>Эмм? Каждого байта?

Разумеется.


S>Откуда такие фантазии?

Не хами.


S>Очень рекомендую ознакомиться с архитектурой современных сетевых стеков.

Не хами.


S>Ну, чтобы представлять, что происходит, когда выполняется чтение из сокета, подключенного к 127.0.0.1.

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


S>Но и это — не лучший выбор для out-of-proc, по сравнению, скажем, с shared memory, которую SQL Server использует по умолчанию при локальном подключении.

Да-да.
При том, что эта технология — это на саммом деле технология маппинга файлов, где для возврата просто целого числа из базы тебе надо воспользоваться 4кB блоком или 8кB в популярных x64. Затратней даже обычного TCP с собственным сервис-провайдером для быстрой картейки какой-нить.


S>В общем, прекращаем распространять тьму невежства.

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

Дешевле WriteProcessMemory/ReadProcessMemory все-равно ничего нет.


V>>Более того, большой их параллельный трафик из разных потоков сильно тормозит систему в целом.
S>Да ладно!

Мля буду.
Просто ты не в курсе, наверно, что частые ядерны вызовы заметно тормзят систему в целом, даже если сами вызовы ничего сложного не выполняют.


S>(facepalm). Локально крутить RDBMS вообще имеет смысл только при недогрузке CPU.

Нормальный нейтивный сервак БД всегда архинедогружен.
Он способен считать что-то там намного быстрее, чем медленная внешняя БД вообще способна отдавать данные.
Поэтому, ему толком нечего делать.

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

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

Да.

S>То же самое мы имеем в том случае, если код енумератора заинлайнен.

Нет. Во всяком случае, если мы говорим о бесстековых сопрограммах — в них используемые переменные не являются локальными относительно вызываемых функций.

S>Скажем, компилятору C++ совершенно наплевать, как устроен цикл — в виде обращений к скалярным переменным либо к скалярным полям локальной переменной структурного типа.

Это само собой. А вот если наша структурка не локальная...

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

_>>Кстати, помнится ты в этой теме изначально был вовсе не сторонником SQL, а как раз наоборот. И ваш спор с vdimas был только по поводу разного идения претензий к SQL и соответственно того, где искать замену. А в последних сообщения ты всё упорно пытаешься защитить SQL, причём в большинстве случаев с помощью решений, вообще не имеющих к нему никакого отношения. Забавно. )))
S>Я не сторонник SQL. Но вы с vdimas видите проблемы не там, где они есть.
S>Проблема SQL вовсе не в том, что он "не позволяет произвольный императивный код". Меня меньше всего интересуют возможности навелосипедить произвольный код, для которого невозможно проводить никакого анализа.
S>Меня интересуют ровно обратные возможности — повысить выразительность кода, заодно получив дополнительные возможности по оптимизации.

Я как бы тоже за всё хорошее и против всего плохого... ))) Но хотелось бы конкретики, а то при переходе к ней обычно оказывается, что ради одних плюшек, надо жертвовать другими. И да, и у тебя и у меня и у vdimas абсолютно разные мысли в данной области. Единственное общее между нами в том, что мы все вместе считаем, что можно было бы подыскать более интересную замену SQL. А вот минусы SQL и варианты его замены каждый видит по разному. Но меня радует что хотя бы кто-то думает в этом направление, а то ведь многие находятся в полной уверенности идеальности SQL (это видно даже в этой теме).

_>>А причём тут типизированные языки то? ) Или ты может SQL считаешь типизированным? )))
S>Это я про то, что вы в качестве переменных скармливаете мне элементы перечисления. Полагаю, что монга использует не настоящий enum просто потому, что в JavaScript его нету.
_>>Это была не попытка написать агрегацию, а демонстрация работы с "глобальной" переменной из документации Монги. Первая попавшаяся, что я нашёл. )))
S>Как видим — неудачная.

Что-то мне кажется или ты не разобрался или я не понимаю твою мысль. Описанные переменные — это всего лишь предопределённые системой частные случаи этого https://docs.mongodb.com/manual/reference/aggregation-variables/.

_>>Да, и агрегацию с использованием глобальной переменной я писал огромное число раз и всегда без ошибок, но это всегда было в контексте того самого цикла for в императивном коде на языках типа C++. В СУБД (не важно реляционной или нет) такого писать не приходилось, но не вижу принципиальной разницы при наличие в ней полноценного императивного языка (не важно что это, pgsql, js или что-то ещё).
S>В том-то и дело, что пока вы находитесь в контексте "того самого" цикла, ваша "глобальная переменная" вполне себе локальна.
S>А как только вы попробуете отмасштабировать этот подход на массовый параллелизм, в том числе и за пределами одной физической машины, то внезапно окажется, что концепция "возьму-ка я значение, которое я тут прикопал на предыдущей итерации" не работает — потому что нет понятия "предыдущая итерация". А если вы настаиваете на его реализации, то ваш запрос вынужденно исполняется на 1 ядре из 1024 доступных.

Ну это зависит от конкретной реализации. Например в том же C++ я могу просто добавить одну коротенькую строчку перед циклом (директиву openmp) и получу нужный результат. И в разных СУБД аналогично, всё зависит от конкретной реализации. Например для Mongo ключевым будет вопрос в том действуем ли мы внутри одного документа или между разными — автоматический массовый параллелизм в этой СУБД имеет вполне конкретную природу. И да, как я уже говорил, я не считаю Mongo идеалом, но некоторые весьма интересные решения (которые можно было бы позаимствовать при попытке создания идеального решения) в ней явно есть.

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

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

Да.

S>Обсуждаем: он ещё хуже, чем SQL. Менее выразительный, работает медленнее, функциональность урезана.

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

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

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

_>Я предлагал обсуждать немного в другом контексте: в данной СУБД есть конкретная интересная (на мой взгляд) функциональность, недоступная в SQL. Это я про исполнение произвольного кода в запросе.
Вот внезапно. Что-то эту мысль никто не уловил. Изначально это позиционировалось как отличная замена SQL как по скорости так и по функциональным возможностям.

_>И я предлагал обдумать мысль о добавление подобной функциональности в некий гипотетический язык (ну или даже инструмент/протокол — не факт что это должен быть именно язык в стиле SQL, обязательно доступный для написания текстовых запросов бухгалтерами), претендующий на замену SQL.
Так linq же. Он и не гипотетический, он вполне практический.

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

_>>И? )
S>И он так и будет отставать на один шаг. В итоге у нас при честном сравнении быстродействия, "декларативное решение" будет всё время впереди.
S>А императивное будет бежать за ним, задыхаясь, и кричать "подождите, я вам сейчас на рояле поиграю!"

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

_>>Угу, особенно на задачах связанных с графами. Кстати, появление всяческих xml/json (как они у нас там укладываются в реляционную алгебру?) инструментов в современных РСУБД — это тоже очень забавный знак.
S>Совершенно верно.
S>Вот ссылка на прошлый забег "связанных с графами":
S>http://rsdn.org/forum/philosophy/5193007.1

Автор: Ikemefula
Дата: 06.06.13

S>А вот результат забега, после которого беседа сама собой прекратилась:
S>http://rsdn.org/forum/philosophy/5199991.1

Автор: Sinclair
Дата: 13.06.13

То, что в SQL, в отличие от того же Linq, есть средства задания рекурсии, я тебя сам писал несколько сообщений назад. Однако это ещё не означает автоматическую удобную работу с графами на SQL. Ты можешь сам сравнить эти возможности с полноценными решениями, типа таких https://neo4j.com/blog/why-database-query-language-matters/.

_>>Видимо во всяких там Яндексах и Гуглах не читали Кнута. )))
S>Читали.

А что же они не используют SQL СУБД в своей самой требовательной к производительности задаче (поиске)?

_>>Эм, а что не так с ACID у Монги работающей на одной машине? )
S>Эм, кратко — "всё".
S>Atomicity — если вам нужна атомарность за пределами одного документа, то будьте любезны закат солнца вручную.
S>Сonsistency — неа, нету. В процессе работы транзакции мы можем наблюдать произвольные состояния документов, в том числе и противоречащие друг другу.
S>Isolation — неа, нету. Параллельные модифицирующие транзакции наблюдают результаты друг друга, и запросто могут видеть фантомы — изменения, которые ещё будут откачены.
S>Durability — да, прикрутили под давлением общественности. Правда, если включить журналирование, то апдейты в монгу станут примерно такими же дорогими, как и в полноценные RDBMS.

Хы, ну вообще то как я уже писал, разница между работой в пределах документа и между документами в Mongo принципиальная, потому как именно на базе коллекции документов и работает автоматическое распараллеливание на много машин. Если мы попытаемся организовать нечто похоже на РСУБД, то там вообще будет страх и ужас с распределёнными транзакциями (в отличие от автоматического, хотя и слегка ограниченного решения в Mongo). Однако и здесь развитие не стоит на месте: в Mongo пытаются суметь совместить автоматическую работу на многих машинах с глобальными транзакциями: https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb.

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

_>>Это ты типа серьёзно хочешь сказать, что не в курсе таких терминов как stackful и stackless coroutines? )))
S>Я хочу сказать, что никаких coroutines в MSIL нету. Ни stackful, ни stackless.

Естественно, так же как и в ассемблере х86. Однако при этом они есть и в C++ (на уровне библиотек или спец. версий компиляторов) и в C# (на уровне компилятора), и именно с их помощью работает твой код с yield.

_>>Хы, ну расскажи например как удобнее вычислить на linq расстояние между узлами дерева с заданными значениям и т.п.
S>Не вполне понимаю вопрос. Пример кода бы помог.

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

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

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

_>>А что там не так https://db-engines.com/en/ranking_trend ?
IB>Ну, например то, что монга вышла на плато, в то время как насквозь реляционная Postgre протоптала монгу и идет дальше вверх.

Я предполагаю, что рост Postgre вполне коррелирует с падением Oracle и МС SQL — люди постепенно переходят на точно такое же решение, только бесплатное. )

_>>Это где ты там увидел про образец? )
IB>там где они сравнивают с SQL решениями. Вот этот вот пассаж особенно прекрасен: such as MySQL – were originally designed with only consistency and availability in mind.
IB>Это MySQL-то про consistency и availability? Сразу видно, маркетолог для маркетологов писал.

А что у MySQL с этим не так? )

_>> Ну и кстати по производительности и популярности MySQL очень даже хороша, но это в любом случае не обсуждалось в статье — там сравнивались между собой разные noSQL СУБД. Причём для применения в банках...
IB>Важно для какого именно применения в банках. Даже в этой статье не предлагается выкинуть реляционное хранилище и заменить его на NoSQL. Предлагается для биг-дата аналитики выгружать данные в NoSQL и изнурительно их там считать. В целом, в этом нет ничего нового, OLAP — это тоже не SQL и применяется примерно для таких же сценариев.
IB>Иными словами, noSQL — это не замена SQL, а новый инструмент для нового сценария (Big Data). Насколько этот новый инструмент удачен — это отдельный вопрос, но даже здесь он не является альтернативой SQL-ю.

Конечно. Только именно этот новый инструмент вполне себе растёт, завоёвывая всё новые прикладные области. В то время как про появление каких-то совершенно новых полезных применений для классических СУБД я что-то не слышал в последнее время.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>А причём тут вообще Монго то? ))) И что у нас за забег такой появился — снова воюем с оппонентами в своём воображение? )
НС>Позорище
НС>

_>>Кстати, ты в курсе языка запросов в MongoDB? Что скажешь про его возможность работы с произвольным кодом?
S>>Посмотрел. Не очень впечатлился: там, по большому счёту, SQL с другим синтаксисом.
_>>Так SQL тоже позволяет произвольный императивный код, глобальные переменные и т.п.?)))

Оу, я смотрю у нас тут подъехали мастера убогой демагогии и резьбы по цитатам. А что же ты тогда не процитировал например эту мою фразу:

Не совсем. Мы обсуждаем чем бы таким более эффективным заменить SQL в реляционных СУБД. И в этом смысле вполне можно в качестве вдохновения полистать различные вариации реализации запросов во множестве популярных nosql СУБД.

Или подобные ей ещё раньше? Любой вменяемый участник данной дискуссии отлично видел, что с какими целями я предлагал посмотреть на MongoDB. И только ты пытаешься создать видимость того, что я тут предлагаю устраивать соревнования разных СУБД.

Здравствуйте, vdimas, Вы писали:
V>Данные тебе были даны — более полусекунды лагов при построчном редактировании в простой двухзвенке.
То есть теперь даны.
Правда, врушные, но чо уж там.

V>Вот тут и стоит помедитировать, ИМХО. ))
Имхо, нет.
V>Формы на FoxPro или на Клиппере имели кое-какую задержку при отображении.
Я на клиппере писал ещё в 1991. Все "задержки" были исключительно со стороны чтения диска.

V>Такое безобразие творилось вплоть до выхода верси MS SQL 7.0, которую следовало бы назвать 1.0, ы-ы-ы.

V>Вот в таких условиях приходилось вертеться.
V>Скажи, тебе пришлось в своё время вдоволь натрахаться с 6-ым MS SQL? ))
Около полугода всего. Потом перешли на 7.0.
V>В асме хотя бы мощнейший макропроцессор, а в Дельфях аж нифига от слова совсем.
Дельфи — это очень круто, есличо. Тамошние метаданные и сейчас ещё ого-го. Просто есть разница между теми, кто только компоненты мышой на форму накидывает, и теми, кто может свой компонент написать. Мы писали свою ORM систему на Delphi и MS SQL. Ещё до Фаулера с его Энтерпрайз Паттернами и всех основных современных ORM.

V>Это когда девочка набирает по 2-3 строки заказа в секунду.
V>На той технике.
Ну вот у нас примерно такие времена и были, в Торговле 97. Которая работала, напомню, на Delphi и MS SQL.

V>Два диска в параллель и огонь.
И всё равно это медленнее, чем обращение к памяти.

V>Кароч, уже было всё сказано, каким образом использовался MS Access — как GUI платформа, как удобный конструктор и САМЫЙ эффективный (на тот момент) COM-сервер своих объектов.
V>Потому что абсолютно все его контролы были windowsless.
Ух ты! Только что главным было In-proc, и внезапно мы хотим поговорить об MS Access как GUI-платформе.

V>Для сравнения, в Дельфях windowsless были только лейблы, круги-овалы и всякие рамки вокруг окон.
V>Но эти контролы не "равнозначны" полноценным, а в хосте MS Access любые ActiveX контролы были вполне равнозначный.
Вполне себе равнозначны. Мы писали windowless компоненты на Delphi в ассортименте.

V>Ну и про идиому использования собственной базы приложения как эффективного локального кеша-аагрегатора разных истоников данных — тоже уже говорил.


V>Просто мне и на MFC пришлось одно время поупражняться.
V>ТАк смешно выходит, что писаная полностю нейтивная прога для работы с БД будет сливать MS Access безбожно.


V>>>Т.е. чтением с диска можно пренебречь в сравнении с другими затратами, бо за один маленький чих со стороны проца заливается целая страница или группа их (причём, страницы сейчас не обязательно по 4 KB, запросто и по 64). Ну и, данные из диска в любом случае читать надо.
V>>>А вот "ручным" проталкиванием каждого байта через пайпы или сокеты пренебречь не получится при их наличии.
S>>Эмм? Каждого байта?
V>Чтобы представлять, что происходит, надо хотя бы помнить, что пакеты данных перед отправкой ты формируешь ручками.
V>Ну, т.е. процессор формирует под твоим чутким руководством.
Ну и что.
V>И еще надо не забыть сокету прописать спецаильную опцию, чтобы не погружаться в уровни сетевого драйвера.
Если речь про FAST PATH, то он появился только в новейших виндах, и выигрыш даёт не очень-то большой. По сравнению с "обычным" loopback adapter, который был в наличии испокон веку, и никаких специальных настроек не требует. Межпроцессная коммуникация на loopback всё ещё в разы быстрее, чем через настоящую локальную сетку, даже 40gbit.

V>При том, что эта технология — это на саммом деле технология маппинга файлов, где для возврата просто целого числа из базы тебе надо воспользоваться 4кB блоком или 8кB в популярных x64. Затратней даже обычного TCP с собственным сервис-провайдером для быстрой картейки какой-нить.
Конечно. Про "затратней" — это полнейший булшит, естественно. Скорость передачи данных по shared memory не зависит от размера блока — он же на физическом уровне отображён. Просто буфер отправки и приёма одновременно доступен в обоих процессах. Вся разница с inproc — только во времени переключения контекста процесса.

V>Дешевле WriteProcessMemory/ReadProcessMemory все-равно ничего нет.
Да? А пацаны говорят, что нет. Что mapped file быстрее, т.к. нет копирований. Кому верить?

V>Мля буду.
V>Просто ты не в курсе, наверно, что частые ядерны вызовы заметно тормзят систему в целом, даже если сами вызовы ничего сложного не выполняют.
Я как раз в курсе. Просто, кроме самого факта, нужно немножко себе представлять, сколько этих вызовов происходит, сколько дополнительных вызовов потребуется для IPC в случае out-of-proc, и какова примерно стоимость одного вызова.

S>>(facepalm). Локально крутить RDBMS вообще имеет смысл только при недогрузке CPU.
V>Нормальный нейтивный сервак БД всегда архинедогружен.
Речь не о нём, а о приложении-клиенте. Если локальных CPU мощностей достаточно, чтобы запустить в них ещё и RDBMS, то запустить его локально будет всегда выгоднее, чем на удалённом сервере. А если у нас уже и так CPU под завязку (например, мы гоняем сервер приложений), то имеет смысл вынести RDBMS отдельно для того, чтобы можно было параллелить нагрузку добавлением других экземпляров сервера приложений.

Здравствуйте, alex_public, Вы писали:
_>Это само собой. А вот если наша структурка не локальная...
А с чего бы ей быть нелокальной?
Она становится локальной в момент инлайна.

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

_>>>Это была не попытка написать агрегацию, а демонстрация работы с "глобальной" переменной из документации Монги. Первая попавшаяся, что я нашёл. )))
S>>Как видим — неудачная.

_>Что-то мне кажется или ты не разобрался или я не понимаю твою мысль. Описанные переменные — это всего лишь предопределённые системой частные случаи этого https://docs.mongodb.com/manual/reference/aggregation-variables/.
Специфика описанных "переменных" — в том, что их нельзя модифицировать. Это константы, поэтому они никак не интересны.


_>>>Да, и агрегацию с использованием глобальной переменной я писал огромное число раз и всегда без ошибок, но это всегда было в контексте того самого цикла for в императивном коде на языках типа C++. В СУБД (не важно реляционной или нет) такого писать не приходилось, но не вижу принципиальной разницы при наличие в ней полноценного императивного языка (не важно что это, pgsql, js или что-то ещё).
S>>В том-то и дело, что пока вы находитесь в контексте "того самого" цикла, ваша "глобальная переменная" вполне себе локальна.
S>>А как только вы попробуете отмасштабировать этот подход на массовый параллелизм, в том числе и за пределами одной физической машины, то внезапно окажется, что концепция "возьму-ка я значение, которое я тут прикопал на предыдущей итерации" не работает — потому что нет понятия "предыдущая итерация". А если вы настаиваете на его реализации, то ваш запрос вынужденно исполняется на 1 ядре из 1024 доступных.

_>Ну это зависит от конкретной реализации. Например в том же C++ я могу просто добавить одну коротенькую строчку перед циклом (директиву openmp) и получу нужный результат.
Судя по примерам из MSDN, одной коротенькой строчкой вы не обойдётесь. Потребуется хотя бы две.

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

В отношении user-defined aggregate я в прошлый раз погорячился: прозрачным образом получить из "произвольного императивного кода" кастомный агрегат не получится.
В С# агрегация — это Func<IEnumerable<TInput>, TOutput>, а в SQL — это потомок класса вида

public abstract class Aggregate<A, TInput, TOutput>
        where A: Aggregate<A, TInput, TOutput>, new()
    {
        public abstract void Accumulate(TInput value);
        public abstract void Merge(A other);
        public abstract TOutput Terminate();
    }

Из второго первый сделать легко:

        public static Func<IEnumerable<TInput>, TOutput> CreateAggregator<A, TInput, TOutput>()
            where A : Aggregate<A, TInput, TOutput>, new()
        {
            return (IEnumerable<TInput> input) =>
            {
                var a = new A();
                foreach (var item in input)
                    a.Accumulate(item);
                return a.Terminate();
            };

        }

А вот обратно — нет.

Здравствуйте, alex_public, Вы писали:
_>Естественно, так же как и в ассемблере х86. Однако при этом они есть и в C++ (на уровне библиотек или спец. версий компиляторов) и в C# (на уровне компилятора), и именно с их помощью работает твой код с yield.
Но JIT оптимизирует не "код с yield", а значительно более банальную штуку. "Код с yield" порождает структурный тип. Инлайн вызова GetEnumerator() делает это видимым, после этого обращения к Current и MoveNext() теряют виртуальность и тоже могут быть заинлайнены. Все эти переменные __state и прочий стуфф, сгенерированный для енумератора, остаются в локальном скоупе и подлежат всем тем же оптимизациям, что и обычные локальные переменные.

_>Ну есть обычное произвольное неотсортированное дерево и требуется найти количество узлов на кратчайшем пути между двумя заданными узлами.
По-прежнему непонятно. Как устроено дерево? У каждого элемента есть указатель на parent?
linq как таковой тут ни при чём. Мы решаем задачу "найти common tail у двух связных списков", а точнее — "найти различные головы двух связных списков".
Есть N способов записать решение этой задачи; С# тут будет удобен невыразимой лёгкостью превращения ноды дерева в коллекцию её предков, что позволит нам использовать обобщённую версию поиска совпадений в коллекциях.

_>Кстати, сейчас подумалось ещё... А что там вообще у нас у linq с работой по отсортированным массивам? Вот есть у нас обычный вектор неких структурок и мы знаем, что этот вектор отсортирован по некоторому полю. Можем ли мы сказать об этом linq, чтобы фильтр where по этому полю стал логарфимическим? ) В императивном коде, как ты понимаешь, никаких проблем с этим нет.
Конечно можем, почему нет. Мы это сделаем при помощи реализации класса SortedList(), параметризованного селектором ключа сортировки, и метода Where в нём, который умеет принимать Expression<...> и разбирать его точно таким же образом, как это делает i4o.