Насколько критерий количества прочитанных страниц хорош для этой задачи?
Ну я бы сказал, что этот критерий, на первый взгляд, показывает, насколько эффективно мы читаем данные. Т.е. много ли лишних данных нужно прочитать, чтобы построить один и тот же результат запроса. Но я бы обратил внимание на то, что некоторые виды SQL движков могут построить более быстрый план, даже прочитав больше данных с дисков (и кстати, для SSD дисков объем читаемых данных вообще влияет на результат меньше), и загрузив больше ядер их параллельной обработкой. При условии что эти ядра у них конечно есть.
И я бы еще не забывал, что есть минимум два критерия производительности вообще - время выполнения запроса и пропускная способность, упрощенно говоря, и они частично противоречат друг другу. Потому что можно уменьшить время выполнения, затратив больше ресурсов.
Я полагаю что если вы в джаве считали секреты (откуда угодно), то они почти наверняка окажутся в heap-dump.
Ну, вы лично или мы можем кое-что предпринять, чтобы этого не было, например не хранить в виде String а хранить в виде char[] и затирать после использования, но я боюсь это такая глубокая кроличья нора... потому что проверить что все наши зависимости так тоже делают, очень сложно. Я бы скорее думал в сторону того, чтобы кто попало не мог получить дамп.
Ну мы конечно дождемся, но было бы интереснее немного не в такой постановке. Поясню, почему:
не у всех tomcat, тем более не у всех томкат нужной версии или его можно легко обновить
клиентские сертификаты как правило не вызывают особых проблем вообще, с учетом того, что выпуск нового сертификата автоматически не приводит к отзыву старого, проблемы обычно с чем-то типа пароля доменного, когда вы его использовали три раза неверный - и заблокировали учетку
и уж точно не у всех HikariDataSource
а еще есть например кафка, которой тоже нужны сертификаты, и где соединение устанавливается в долгую
Ну т.е. тема актуальная, но сами вопросы лично для меня не очень.
Трижды. Не бывает миграции одноразовой, практически никогда. Это процесс. И он практически всегда построен на том или ином способе выбрать свежие данные из одной базы, и добавить их в другую. Поэтому нормальные процессы миграции как правило строятся на чем-то типа Golden Gate, ну или применительно к постгресу - debesium. Т.е. что-то что читает WAL, пересылает транзакции в другое место, и там их применяет к другой БД.
А так да, за попытку прочитать все данные из таблицы в память, а потом записать их в другую базу - твердая двойка, даже последний джун должен был подумать о том, что записей в таблице может быть миллион или миллиард, и этот процесс нужно резать на кусочки. Я бы даже на спарке так не стал бы делать (хотя спарк способен такое переварить, если дать нужные ресурсы, но не миллиарды все равно, миллионы в лучшем случае).
Я думаю по сравнению с точностью определения времени плюс-минус часы, это уже мелочь. Примерно понятно, на какой высоте объектив, по картинке, в среднем он где-то на уровне роста человека/уровне глаз.
И да, я бы еще поправку на фокусное расстояние сделал - потому что далеко не факт, что снято не на широкоугольник, например.
Да. Когда я читаю "В каком порядке обрабатываются SQL-запросы?" - и это понимаю как "есть два запроса, в каком порядке они будут выполнены". А текст совсем про другое. Потому что в названии запросы во множественном, а текст про запрос в единственном.
Рассмотренный же в тексте вопрос не то чтобы не интересен, а скорее на практике обычно ставится в другой постановке: берется план, из которого видно порядок выполнения, если запрос работает медленно, пытаемся оптимизировать. Т.е. скажем, вопрос "как выполняется join" - он на самом деле интересен, особенно если вы знаете, как повлиять на выбор hash join или loop, например, и понимаете когда и какой лучше. А что до фильтров, то интересно обычно то, можно ли сделать им push в подзапрос, к примеру, то есть выполнить их как можно раньше, уменьшив число обрабатываемых на следующих этапах строк.
Я знаю, что групп которые писали (и программ) было много. Сердюк и Юрьев - это немного другие люди, я делал диплом у Д.Н. Щеверова. А программу похожую мы делали примерно в начале 80-х, для курса Р.Ф. Аппазова и вместе с ним. Это было первое, у чего был какой-никакой UI.
Ну и кстати - юникс это же не только линукс, но и скажем macos. А там и там разные пакетные менеджеры. И грубо говоря, написать скрипт для автоматизации установки чего-либо всегда придется так, чтобы проверять ОС. Я просто хорошо вижу на примерах софта от Apache Group, где скажем весь Java софт, который казалось бы, должен быть переносим, так вот он переносим - но все скрипты запуска, написанные на баше (да, потому что он "везде есть"), во-первых, проверяют тип ОС, и отличают скажем солярис от macos и от линукса, и всех их от цигвина. А еще оный баш дополняется .cmd для виндоус. И я таки склонен опыту этих людей доверять, потому что тиражи их софта намного больше, чем допустим моего.
Когда я учился в МАИ на 601 кафедре, то у нас была программа «Проектно-баллистического расчёта баллистических ракет и ракет-носителей» DEP.
А когда вы учились, если не секрет? Есть неплохие шансы, что к той программе (либо ее прототипу) приложил руку либо лично я, либо кто-то из моих учеников.
Например (сорян что специфичный, но совершенно реальный для меня) керберос. В винде у вас не будет krb5.conf, а будет krb5.ini. И синтаксис команд рабочей станции разный. И лежать оный krb5.ini будет не там (и не факт что переменная окружения будет на него указывать). Ну т.е. я бы сказал, что как только мы выйдем за пределы просто файлов - мы сразу столкнемся со спецификой винды или линукса. Между тем, автоматизация логина в домен - это одна из типовых задач в моем случае. И таки я ее пишу на груви :)
Ну или иными словами - если вы хотели сказать, что баш почти всегда есть и в windows, то я согласен - почти всегда он есть (у меня вот он из дистрибутива Git). Но гарантии работоспособности типичного баш скрипта нет никаких. Надо специально писать так, чтобы оно работало и в этой среде тоже.
Как правило если "везде" это linux и windows, то уже не факт что баш.
Если есть внешние команды, то скорее всего bash
Даже не совсем "скриптовые" языки как Scala или Groovy (у обоих правда есть REPL) прекрасно справляются с вызовом внешних команд. Т.е. грубо говоря, выглядеть это будет примерно так:
def out= "ls -la".execute().text
и в итоге out будет содержать stdout команды ls. И при этом вполне имеется гибкость, чтобы переварить вывод произвольного размера через стримы. И не имеется заморочек с искейпами, характерных для баша.
У автора просто ложная дилемма. Не неправильная, а скорее ограниченная. Вот в моем окружении энтерпрайза я всегда знаю, что "везде" (везде где мне нужно) стоит Java. И поэтому могу скриптовать на груви или скале, не заморачиваясь, потому что ни то ни другое не нужно устанавливать и настраивать окружение, в отличие от питона, и если мне нужны зависимости - то с ними все гораздо проще. Ну т.е. да, моя среда - контролируемая. И работать с объектами удобнее - и кроме питона появляется еще довольно широкий выбор.
Но да, если ваше или их "везде" не такое как мое - у вас другой выбор оптимален.
powershell? Ну в общем да, его бы тоже не мешало бы добавить к этому ограниченному сравнению.
Так никто вроде и не против. Все понимают, что это деятельность, которая не приносит им денег, а уносит их. А приносит она скорее как раз доверие - которое в деньгах не так просто измерить.
Вы похоже неявно предполагаете, что речь о кредитах физлицам. Это стоило бы явно уточнить, потому что модели для юрлиц могут быть сильно другие, например, возможны кредиты под залог или гарантии, и тогда оценивается сам этот залог или скажем гарант, и его вероятность дефолта.
Ну да, но в данном случае я про то, что сами пишете - сами понимаете, нет такого барьера, когда синьор написал, а джун не может понять.
Но самое наверное главное, что очень редко, описывая SOLID, принимают во внимание то самое время - что тут как с юнит тестами, вы тратите ресурсы и деньги сейчас, а профит от этого возможно получите позже.
Хотя по-хорошему, стоило бы прикинуть, ну вот мы тут соблюли принцип, нам это стоило скажем 2 человеко-дня, а если бы мы его не соблюдали, модификация этого куска кода стоила бы нам дополнительно человеко-день (из-за сильной связности текущего кода). Причем зачастую это простая рутинная работа (которую может сделать дешевый разработчик) - т.е. нужно например внести почти одинаковые правки в модули А и Б, вместо того, чтобы один раз изменить абстракцию В (изменением одной абстракции все равно же все не ограничится - ее же не зря меняли, видимо функциональность тоже изменится).
Я бы еще сказал - и в данное время. Потому что необходимость упростить сопровождение и понимание кода сильно зависит от того, кто понимает и сопровождает. Ну т.е. для синьора и джуна один и тот же код может быть легким для понимания, и совсем недоступным (как из-за уровня знания инструментов/языков, так и уровня понимания текущего проекта).
И если вы пишете проект в одно лицо, и редко меняете реализации - то вам в принципе нафиг не нужен конкретно рассматриваемый тут принцип. И его игнорирование будет вам стоить какой-то дополнительной работы при внесении изменений в реализацию. Когда-то потом, возможно сильно позже, или даже никогда.
Так в этом и дело. Если ты не понимаешь, для чего, все кончается чем-то вроде "давайте применим сюда все принципы SOLID" (на днях была такая статья, кстати). А зачем применяем, почему сразу все (при том что приложение уже содержит какие-то паттерны, решающие определенные задачи), и потом автор еще удивлялся, что стало хуже. Еще бы стало лучше, если ты не понимаешь, зачем вносишь изменения?
Ну я бы сказал, что этот критерий, на первый взгляд, показывает, насколько эффективно мы читаем данные. Т.е. много ли лишних данных нужно прочитать, чтобы построить один и тот же результат запроса. Но я бы обратил внимание на то, что некоторые виды SQL движков могут построить более быстрый план, даже прочитав больше данных с дисков (и кстати, для SSD дисков объем читаемых данных вообще влияет на результат меньше), и загрузив больше ядер их параллельной обработкой. При условии что эти ядра у них конечно есть.
И я бы еще не забывал, что есть минимум два критерия производительности вообще - время выполнения запроса и пропускная способность, упрощенно говоря, и они частично противоречат друг другу. Потому что можно уменьшить время выполнения, затратив больше ресурсов.
Ну, вы лично или мы можем кое-что предпринять, чтобы этого не было, например не хранить в виде String а хранить в виде char[] и затирать после использования, но я боюсь это такая глубокая кроличья нора... потому что проверить что все наши зависимости так тоже делают, очень сложно. Я бы скорее думал в сторону того, чтобы кто попало не мог получить дамп.
Ну мы конечно дождемся, но было бы интереснее немного не в такой постановке. Поясню, почему:
не у всех tomcat, тем более не у всех томкат нужной версии или его можно легко обновить
клиентские сертификаты как правило не вызывают особых проблем вообще, с учетом того, что выпуск нового сертификата автоматически не приводит к отзыву старого, проблемы обычно с чем-то типа пароля доменного, когда вы его использовали три раза неверный - и заблокировали учетку
и уж точно не у всех HikariDataSource
а еще есть например кафка, которой тоже нужны сертификаты, и где соединение устанавливается в долгую
Ну т.е. тема актуальная, но сами вопросы лично для меня не очень.
Трижды. Не бывает миграции одноразовой, практически никогда. Это процесс. И он практически всегда построен на том или ином способе выбрать свежие данные из одной базы, и добавить их в другую. Поэтому нормальные процессы миграции как правило строятся на чем-то типа Golden Gate, ну или применительно к постгресу - debesium. Т.е. что-то что читает WAL, пересылает транзакции в другое место, и там их применяет к другой БД.
А так да, за попытку прочитать все данные из таблицы в память, а потом записать их в другую базу - твердая двойка, даже последний джун должен был подумать о том, что записей в таблице может быть миллион или миллиард, и этот процесс нужно резать на кусочки. Я бы даже на спарке так не стал бы делать (хотя спарк способен такое переварить, если дать нужные ресурсы, но не миллиарды все равно, миллионы в лучшем случае).
Я думаю по сравнению с точностью определения времени плюс-минус часы, это уже мелочь. Примерно понятно, на какой высоте объектив, по картинке, в среднем он где-то на уровне роста человека/уровне глаз.
И да, я бы еще поправку на фокусное расстояние сделал - потому что далеко не факт, что снято не на широкоугольник, например.
Да. Когда я читаю "В каком порядке обрабатываются SQL-запросы?" - и это понимаю как "есть два запроса, в каком порядке они будут выполнены". А текст совсем про другое. Потому что в названии запросы во множественном, а текст про запрос в единственном.
Рассмотренный же в тексте вопрос не то чтобы не интересен, а скорее на практике обычно ставится в другой постановке: берется план, из которого видно порядок выполнения, если запрос работает медленно, пытаемся оптимизировать. Т.е. скажем, вопрос "как выполняется join" - он на самом деле интересен, особенно если вы знаете, как повлиять на выбор hash join или loop, например, и понимаете когда и какой лучше. А что до фильтров, то интересно обычно то, можно ли сделать им push в подзапрос, к примеру, то есть выполнить их как можно раньше, уменьшив число обрабатываемых на следующих этапах строк.
Я знаю, что групп которые писали (и программ) было много. Сердюк и Юрьев - это немного другие люди, я делал диплом у Д.Н. Щеверова. А программу похожую мы делали примерно в начале 80-х, для курса Р.Ф. Аппазова и вместе с ним. Это было первое, у чего был какой-никакой UI.
Я-то в 1981 закончил...
Ну и кстати - юникс это же не только линукс, но и скажем macos. А там и там разные пакетные менеджеры. И грубо говоря, написать скрипт для автоматизации установки чего-либо всегда придется так, чтобы проверять ОС. Я просто хорошо вижу на примерах софта от Apache Group, где скажем весь Java софт, который казалось бы, должен быть переносим, так вот он переносим - но все скрипты запуска, написанные на баше (да, потому что он "везде есть"), во-первых, проверяют тип ОС, и отличают скажем солярис от macos и от линукса, и всех их от цигвина. А еще оный баш дополняется .cmd для виндоус. И я таки склонен опыту этих людей доверять, потому что тиражи их софта намного больше, чем допустим моего.
Конкретно этот случай возможно не очевидный, но иногда предикаты можно протолкнуть внутрь скажем подзапросов, и такая оптимизация широко используется.
По-хорошему, вам следовало бы получить и показать нам тут план запроса в обоих случаях. Думаю многое можно было бы понять.
А когда вы учились, если не секрет? Есть неплохие шансы, что к той программе (либо ее прототипу) приложил руку либо лично я, либо кто-то из моих учеников.
Например (сорян что специфичный, но совершенно реальный для меня) керберос. В винде у вас не будет krb5.conf, а будет krb5.ini. И синтаксис команд рабочей станции разный. И лежать оный krb5.ini будет не там (и не факт что переменная окружения будет на него указывать). Ну т.е. я бы сказал, что как только мы выйдем за пределы просто файлов - мы сразу столкнемся со спецификой винды или линукса. Между тем, автоматизация логина в домен - это одна из типовых задач в моем случае. И таки я ее пишу на груви :)
Ну или иными словами - если вы хотели сказать, что баш почти всегда есть и в windows, то я согласен - почти всегда он есть (у меня вот он из дистрибутива Git). Но гарантии работоспособности типичного баш скрипта нет никаких. Надо специально писать так, чтобы оно работало и в этой среде тоже.
У меня вот отключен WSL, политиками там или как - не вникал, и чо? Cygwin предлагаете?
Как правило если "везде" это linux и windows, то уже не факт что баш.
Даже не совсем "скриптовые" языки как Scala или Groovy (у обоих правда есть REPL) прекрасно справляются с вызовом внешних команд. Т.е. грубо говоря, выглядеть это будет примерно так:
def out= "ls -la".execute().text
и в итоге out будет содержать stdout команды ls. И при этом вполне имеется гибкость, чтобы переварить вывод произвольного размера через стримы. И не имеется заморочек с искейпами, характерных для баша.
У автора просто ложная дилемма. Не неправильная, а скорее ограниченная. Вот в моем окружении энтерпрайза я всегда знаю, что "везде" (везде где мне нужно) стоит Java. И поэтому могу скриптовать на груви или скале, не заморачиваясь, потому что ни то ни другое не нужно устанавливать и настраивать окружение, в отличие от питона, и если мне нужны зависимости - то с ними все гораздо проще. Ну т.е. да, моя среда - контролируемая. И работать с объектами удобнее - и кроме питона появляется еще довольно широкий выбор.
Но да, если ваше или их "везде" не такое как мое - у вас другой выбор оптимален.
powershell? Ну в общем да, его бы тоже не мешало бы добавить к этому ограниченному сравнению.
Так никто вроде и не против. Все понимают, что это деятельность, которая не приносит им денег, а уносит их. А приносит она скорее как раз доверие - которое в деньгах не так просто измерить.
Вы похоже неявно предполагаете, что речь о кредитах физлицам. Это стоило бы явно уточнить, потому что модели для юрлиц могут быть сильно другие, например, возможны кредиты под залог или гарантии, и тогда оценивается сам этот залог или скажем гарант, и его вероятность дефолта.
Ну да, но в данном случае я про то, что сами пишете - сами понимаете, нет такого барьера, когда синьор написал, а джун не может понять.
Но самое наверное главное, что очень редко, описывая SOLID, принимают во внимание то самое время - что тут как с юнит тестами, вы тратите ресурсы и деньги сейчас, а профит от этого возможно получите позже.
Хотя по-хорошему, стоило бы прикинуть, ну вот мы тут соблюли принцип, нам это стоило скажем 2 человеко-дня, а если бы мы его не соблюдали, модификация этого куска кода стоила бы нам дополнительно человеко-день (из-за сильной связности текущего кода). Причем зачастую это простая рутинная работа (которую может сделать дешевый разработчик) - т.е. нужно например внести почти одинаковые правки в модули А и Б, вместо того, чтобы один раз изменить абстракцию В (изменением одной абстракции все равно же все не ограничится - ее же не зря меняли, видимо функциональность тоже изменится).
Я бы еще сказал - и в данное время. Потому что необходимость упростить сопровождение и понимание кода сильно зависит от того, кто понимает и сопровождает. Ну т.е. для синьора и джуна один и тот же код может быть легким для понимания, и совсем недоступным (как из-за уровня знания инструментов/языков, так и уровня понимания текущего проекта).
И если вы пишете проект в одно лицо, и редко меняете реализации - то вам в принципе нафиг не нужен конкретно рассматриваемый тут принцип. И его игнорирование будет вам стоить какой-то дополнительной работы при внесении изменений в реализацию. Когда-то потом, возможно сильно позже, или даже никогда.
Так в этом и дело. Если ты не понимаешь, для чего, все кончается чем-то вроде "давайте применим сюда все принципы SOLID" (на днях была такая статья, кстати). А зачем применяем, почему сразу все (при том что приложение уже содержит какие-то паттерны, решающие определенные задачи), и потом автор еще удивлялся, что стало хуже. Еще бы стало лучше, если ты не понимаешь, зачем вносишь изменения?
И 0 денег? :) Высший пилотаж тут как раз в том, чтобы деньги все равно получить, а делать меньше...