Нет, это всё издержки переноса англоязычной терминологии на русский язык. Каким образом так случилось, что в русском scheduler стал планировщиком, я внятно объяснить не могу.
Schedule — это вообще-то график (дежурств), расписание (действий). Планирование как составление плана действий, здесь отсутствует, расписание — продукт планирования, а не процесс. И scheduler в этом смысле — это исполнитель расписания, а не его составитель.
Plan — это в некотором смысле алгоритм, последовательность шагов при исполнении какого-либо действия (из, например, расписания).
Optimize — в общем случае улучшение этого самого Plan.
Подытожим:
scheduler — хранит таблицу, расписание выполнения задач, и обеспечивает их запуск по этому расписанию;
planner — составляет план действий для исполнения конкретного запроса (а EXPLAIN его, этот план, показывает);
optimizer — часть planner'а (может и отсутствовать). Например, переупорядочивает действия, исключает повторные действия, и т.п.
Таким образом получается, что именно в PostgreSQL всё как раз таки и называется правильно:
При всё том, что основной тезис статьи — “Дефолтная конфигурация — упавший сервис” — должен быть огромными буквами написан на всех стенах, на которые хотя бы изредка падают взоры администраторов, смутил всё же один момент:
Redis съедал всю возможную память, сервер вис и падал
и
iostat. Но и тут без проблем:
Только мне кажется, что это — несколько противоречивые факты? redis сожрал всю память до висячей и падучей, а в статистиках iostat — всё прелестно?
По-моему, это фундаментальное заблуждение, которое и привело нас к тем системам мониторинга, которые мы имеем. Логи очень редко (почти никогда) дают понять, что “в точности происходит”. Даже сама суть слова “лог” прямо говорит — это исторические факты, а не песня акына об окружающей действительности. То есть, логи дают понять, что когда-то произошло, а не происходит здесь и сейчас. Они — форенсик-инструмент в руках расследователя (в действующей системе), или отладочный инструмент в руках разработчика (в создаваемой/развивающейся системе).
SIEM-системы не должны использоваться для мониторинга. А мониторинговые системы должны опираться на такие средства, как, например, SNMP в сетях. Только вот единого набора OID, MIB и метрик для приложений до сих пор никто не придумал.
Авторы стандартов используют предельно лаконичные и строгие формулировки, иноязычные читатели стандартов нагружают прочтённое адекватными их знаниям чужого языка собственными смыслами — и в результате мы получаем настоящие “перлы” типа “Никто не знает, как будет вести себя код, содержащий UB.”
Текст вроде и осмысленный, и корректный, и кому-то на что-то откроет глаза, но в его основе лежит семантическое заблуждение, и потому весь текст получается вовсе не о том, о чём заявляется заголовком, а местами и вовсе заставляет задуматься — а не ставит ли автор телегу впереди лошади? Не попутаны ли причинно-следственные связи?
О каком семантическом заблуждении я? Излагать буду максимально подробно. Автор (масса авторов и комментаторов по всему интернету, к сожалению) в обсуждаемых терминах Стандарта “undefinded behaviour”, ”unspecified behaviour”, “implementation-defined behaviour” привязывает первое слово к последнему как характеристику последнего. В результате мы получаем чушь в форме “код, содержащий UB”. Извините, но B (поведение) скомпилированного кода очень даже определено — архитектурой целевой платформы и средой исполнения.Код не может содержать какого-то там неопределённого поведения. Или неуточнённого. Или реализацией-определямого. Он всегда будет исполняться так, как определено, повторюсь, архитектурой целевой платформы и средой исполнения.
Эта смешная программка (“содержащая UB”, выражаясь в стиле автора) на AMD64 всегда, будучи хоть миллиард раз запущена, выведет 1/256. Очень даже определённое поведение.
Эта же смешная программка на ARM точно так же всегда выведет — ахтунг! начинается интересное — либо 1/256, либо 256/1, и зависит это от среды исполнения (для тех, кто не знает — порядок байтов в многобайтовых словах, так называемый endian, на ARM настраивается при старте, и может быть как little, так и big), Но в одной и той же среде результат при миллиардах запусков будет один, то есть поведение вполне себе определённое.
И эта же смешная программка на PDP-11/VAX всегда, сколько ни запускай, фолтнется с bus error. И это тоже вполне определено, нельзя там выдёргивать слово по нечётному адресу.
То есть, поведение программки всегда детерминировано, полностью определено. Но позвольте, она же “содержит UB”, как же так?
Возвращаемся к семантической ошибке. Первое слово в термине undefined behaviour (и других упомянутых терминах поведения) — это не характеристика поведения(которое — смотри пример выше — всегда очень даже определено), это — позиция Стандарта.
Попробуем теперь переосмыслить и выразить простым русским языком значения этих терминов:
unspecified behaviour — Стандарт определяет, что параметры функции конечно же будут вычислены, и это точно произойдёт до вызова функции, но Стандарт не уточняет порядок вычисления этих параметров в случае, когда их более одного.
implementation-defined behaviour — Стандарт не определяет, что будет со старшим битом знакового целочисленного типа при сдвиге вправо, но предписывает авторам реализации чётко определить в документации на их компилятор, что при этом будет происходить в этой конкретной реализации.
undefined behaviour — Стандарт не определяет, каким будет результат использования той или иной языковой конструкции в исполняемом коде на целевой платформе в целевой среде исполнения.
Чувствуете же разницу, друзья-коллеги? Не “Поведение неопределённое”, а “Стандарт никоим образом не определяет, каким должно быть поведение” при целочисленном делении на 0 — на PDP-11/VAX всегда и определённо трапнется, на MIPS молча и так же всегда и c чётко определённым результатом поедет дальше.
Ничего феноменального в UB нет, надо лишь вспомнить чуть-чуть историю языка C. Его не зря всегда сравнивали с высокоуровневым ассемблером — это язык очень низкого уровня, почти абстрактный ассемблер и есть. Множество архитектур, на которые он был в то или иное время перенесён, имеют существенные различия. И эти различия не особо напрягали как отцов, так и многочисленных “портировщиков” UNIX (напоминаю — C родился для создания переносимой UNIX) на другие платформы, принципиальные отличия в архитектуре решались условной компиляцией и чистым ассемблером в совсем уж железо-зависимых частях.
Но потом появился Стандарт. И члены рабочей группы прекрасно понимали, что решение проблем разности архитектур при таком многообразии архитектур — mission impossible. Для упрощения проблем реализаций сначала определили кучу implemetation-defined behaviour, а потом, абстрагируясь всё выше, и undefined behaviour.
А потом “в тусовку” пришли дети Фортрана и Бейсика, решившие, что они тоже хотят писать на C всё те же свои математические, физические, экономические и прочие очень далёкие от “железа” программы. Им многого не хватало из привычных им сред, и они стали прессовать Комитет. И Комитет повёлся. В язык стали вводить конструкции, которые стали превращать очень низкоуровневый C во всё более высокоуровневый язык (взять хотя бы те же VLA). И ситуация дошла “до ручки”. Одно из самых свежих нововведений — сравнение указателей, не относящихся к одной и той же области storage— UB. У кучи разработчиков системного (очень низкого) уровня подорвались пердаки. Мегасрачи на reddit. Но всё же понятно при всей своей непонятности: тому, кто не знает, чем стэнфордская архитектура отличается от гарвардской архитектуры, тяжело понять, почему нельзя сравнивать указатели на код с указателями на данные. Но как быть в системах, где нет защиты памяти, и можно сгенерить код в области данных, и передать ему управление (привет вирусописателям)? А как быть на гарвардской архитектуре, где код лежит в 16-разрядной памяти, а данные — в 32-разрядной?
Комитет пошёл на поводу у людей, которые о low-level программировании — ни ухом, ни рылом, какими бы доками они ни было в квантовой физике и макроэкономике. Комитет смирился с идеей превратить низкоуровневый C в высокоуровневый C-хрен_знает_что. Язык, на котором можно было (и неоднократно реализовано) делать операционные системы, превращается в сверхвысокоуровневое, не имеющее никакого отображения на железо, нечто, на котором можно писать очередное 1С, но ОС или хотя бы драйвер — нет, ребята, пишите на ассемблере.
А потом C++ посредством механизма наследования (какая издёвка над столпами ООП) получил всё это дерьмо на свой обеденный стол. Держитесь, ребята. Или, осознавая существенные отличия архитектур, переносимо операционки писать, или разргребать, подобно дерьму, существенные отличия архитектур в угоду Васе, который не может понять, почему нельзя просто поделить икс на игрек...
Существуют системы с различными моделями данных, где int может содержать и 8 байт, и 2 байта и даже 1 байт!
Тут очень важно сделать уточнение — речь идёт не о том байте, о котором большинство сразу могло подумать (и который правильнее называть “октет”), а о том, который определён стандартами языков С или С++ как нечто адресуемое и способное хранить любой символ из набора символов среды исполнения ("addressable unit of data storage large enough to hold any member of the basic character set of the execution environment")
С системами, на которых sizeof(char) == sizeof(short) == sizeof(int) == sizeof(long) == 1, мне довелось работать 35 лет назад :)
А я, пока писал тот комментарий, поймал себя на мысли, что тоже использовал бы такую форму, если бы мне сегодня пришлось писать на Фортране. Но я с ним расстался более 30 лет назад, и, признаться, ни разу не пожалел.
В РАФОС/ОСРВ (RT11/RSX11M) ABI был настолько логичен и строен, что вряд ли бы кому-то пришло в голову писать об этом целую книгу — пары страниц было достаточно.
Дело скорее не в персональных компутерах. Сначала в DEC долго жевали сопли, выбирая между CISC и RISC. И даже остановили разработку Prism. Потом долго жевали сопли, размышляя о том, стоит ли влезать в разработку микропроцессоров. А когда наконец увидели, что будущее таки за микропроцессорами, подорвались, откопали Prism, выпустили фантастическую Alpha... Но было уже поздно,Compaq сожрал DEC, добил Alpha, и благополучно издох сам под тушкой HP.
Со мной недавно делились воспоминаниями про то как как легко было программировать PDP-11. Какая удобная была система команд. И какая гадость х86 :)
Категорически подтверждаю. Система команд Intel x86 (да и 8080 тоже) после PDP-11 — это раздутое чудовище. Чего, кстати, нельзя сказать о системе команд Mototola 68000, по-моему, над ней работали чуваки под сильным впечатлением от PDP-11.:) Я вообще в те времена надеялся, что победит Motorola. Но рынок при наличии альтернатив практически никогда не выбирает лучшую. Да ещё и военные давят иногда.
Ну, про “не чувствуете” — это перебор немножко. Например, на x86 ты преспокойно можешь дереферить нечётный указатель на слово, на PDP-11 ты за это гарантированно огребаешь "Bus error".
Чудесно они подходили. Первая половина 80-х, в одном там СМУ (пусконаладчики на нашем испытательном полигоне) в Караганде — СМ-1420 с консолью в машзале и 4-мя терминалами в кадрах/бухгалтерии.
...и успешно показали, что “сохранность работы российских сервисов” успешно не сохранилась. Успешный успех!
Нет, это всё издержки переноса англоязычной терминологии на русский язык. Каким образом так случилось, что в русском scheduler стал планировщиком, я внятно объяснить не могу.
Schedule — это вообще-то график (дежурств), расписание (действий). Планирование как составление плана действий, здесь отсутствует, расписание — продукт планирования, а не процесс. И scheduler в этом смысле — это исполнитель расписания, а не его составитель.
Plan — это в некотором смысле алгоритм, последовательность шагов при исполнении какого-либо действия (из, например, расписания).
Optimize — в общем случае улучшение этого самого Plan.
Подытожим:
scheduler — хранит таблицу, расписание выполнения задач, и обеспечивает их запуск по этому расписанию;
planner — составляет план действий для исполнения конкретного запроса (а EXPLAIN его, этот план, показывает);
optimizer — часть planner'а (может и отсутствовать). Например, переупорядочивает действия, исключает повторные действия, и т.п.
Таким образом получается, что именно в PostgreSQL всё как раз таки и называется правильно:
При всё том, что основной тезис статьи — “Дефолтная конфигурация — упавший сервис” — должен быть огромными буквами написан на всех стенах, на которые хотя бы изредка падают взоры администраторов, смутил всё же один момент:
и
Только мне кажется, что это — несколько противоречивые факты? redis сожрал всю память до висячей и падучей, а в статистиках iostat — всё прелестно?
По-моему, это фундаментальное заблуждение, которое и привело нас к тем системам мониторинга, которые мы имеем. Логи очень редко (почти никогда) дают понять, что “в точности происходит”. Даже сама суть слова “лог” прямо говорит — это исторические факты, а не песня акына об окружающей действительности. То есть, логи дают понять, что когда-то произошло, а не происходит здесь и сейчас. Они — форенсик-инструмент в руках расследователя (в действующей системе), или отладочный инструмент в руках разработчика (в создаваемой/развивающейся системе).
SIEM-системы не должны использоваться для мониторинга.
А мониторинговые системы должны опираться на такие средства, как, например, SNMP в сетях. Только вот единого набора OID, MIB и метрик для приложений до сих пор никто не придумал.
Авторы стандартов используют предельно лаконичные и строгие формулировки, иноязычные читатели стандартов нагружают прочтённое адекватными их знаниям чужого языка собственными смыслами — и в результате мы получаем настоящие “перлы” типа “Никто не знает, как будет вести себя код, содержащий UB.”
Текст вроде и осмысленный, и корректный, и кому-то на что-то откроет глаза, но в его основе лежит семантическое заблуждение, и потому весь текст получается вовсе не о том, о чём заявляется заголовком, а местами и вовсе заставляет задуматься — а не ставит ли автор телегу впереди лошади? Не попутаны ли причинно-следственные связи?
О каком семантическом заблуждении я? Излагать буду максимально подробно. Автор (масса авторов и комментаторов по всему интернету, к сожалению) в обсуждаемых терминах Стандарта “undefinded behaviour”, ”unspecified behaviour”, “implementation-defined behaviour” привязывает первое слово к последнему как характеристику последнего. В результате мы получаем чушь в форме “код, содержащий UB”. Извините, но B (поведение) скомпилированного кода очень даже определено — архитектурой целевой платформы и средой исполнения.Код не может содержать какого-то там неопределённого поведения. Или неуточнённого. Или реализацией-определямого. Он всегда будет исполняться так, как определено, повторюсь, архитектурой целевой платформы и средой исполнения.
Пример:
Эта смешная программка (“содержащая UB”, выражаясь в стиле автора) на AMD64 всегда, будучи хоть миллиард раз запущена, выведет 1/256. Очень даже определённое поведение.
Эта же смешная программка на ARM точно так же всегда выведет — ахтунг! начинается интересное — либо 1/256, либо 256/1, и зависит это от среды исполнения (для тех, кто не знает — порядок байтов в многобайтовых словах, так называемый endian, на ARM настраивается при старте, и может быть как little, так и big), Но в одной и той же среде результат при миллиардах запусков будет один, то есть поведение вполне себе определённое.
И эта же смешная программка на PDP-11/VAX всегда, сколько ни запускай, фолтнется с bus error. И это тоже вполне определено, нельзя там выдёргивать слово по нечётному адресу.
То есть, поведение программки всегда детерминировано, полностью определено. Но позвольте, она же “содержит UB”, как же так?
Возвращаемся к семантической ошибке. Первое слово в термине undefined behaviour (и других упомянутых терминах поведения) — это не характеристика поведения (которое — смотри пример выше — всегда очень даже определено), это — позиция Стандарта.
Попробуем теперь переосмыслить и выразить простым русским языком значения этих терминов:
unspecified behaviour — Стандарт определяет, что параметры функции конечно же будут вычислены, и это точно произойдёт до вызова функции, но Стандарт не уточняет порядок вычисления этих параметров в случае, когда их более одного.
implementation-defined behaviour — Стандарт не определяет, что будет со старшим битом знакового целочисленного типа при сдвиге вправо, но предписывает авторам реализации чётко определить в документации на их компилятор, что при этом будет происходить в этой конкретной реализации.
undefined behaviour — Стандарт не определяет, каким будет результат использования той или иной языковой конструкции в исполняемом коде на целевой платформе в целевой среде исполнения.
Чувствуете же разницу, друзья-коллеги? Не “Поведение неопределённое”, а “Стандарт никоим образом не определяет, каким должно быть поведение” при целочисленном делении на 0 — на PDP-11/VAX всегда и определённо трапнется, на MIPS молча и так же всегда и c чётко определённым результатом поедет дальше.
Ничего феноменального в UB нет, надо лишь вспомнить чуть-чуть историю языка C. Его не зря всегда сравнивали с высокоуровневым ассемблером — это язык очень низкого уровня, почти абстрактный ассемблер и есть. Множество архитектур, на которые он был в то или иное время перенесён, имеют существенные различия. И эти различия не особо напрягали как отцов, так и многочисленных “портировщиков” UNIX (напоминаю — C родился для создания переносимой UNIX) на другие платформы, принципиальные отличия в архитектуре решались условной компиляцией и чистым ассемблером в совсем уж железо-зависимых частях.
Но потом появился Стандарт. И члены рабочей группы прекрасно понимали, что решение проблем разности архитектур при таком многообразии архитектур — mission impossible. Для упрощения проблем реализаций сначала определили кучу implemetation-defined behaviour, а потом, абстрагируясь всё выше, и undefined behaviour.
А потом “в тусовку” пришли дети Фортрана и Бейсика, решившие, что они тоже хотят писать на C всё те же свои математические, физические, экономические и прочие очень далёкие от “железа” программы. Им многого не хватало из привычных им сред, и они стали прессовать Комитет. И Комитет повёлся. В язык стали вводить конструкции, которые стали превращать очень низкоуровневый C во всё более высокоуровневый язык (взять хотя бы те же VLA). И ситуация дошла “до ручки”. Одно из самых свежих нововведений — сравнение указателей, не относящихся к одной и той же области storage— UB. У кучи разработчиков системного (очень низкого) уровня подорвались пердаки. Мегасрачи на reddit. Но всё же понятно при всей своей непонятности: тому, кто не знает, чем стэнфордская архитектура отличается от гарвардской архитектуры, тяжело понять, почему нельзя сравнивать указатели на код с указателями на данные. Но как быть в системах, где нет защиты памяти, и можно сгенерить код в области данных, и передать ему управление (привет вирусописателям)? А как быть на гарвардской архитектуре, где код лежит в 16-разрядной памяти, а данные — в 32-разрядной?
Комитет пошёл на поводу у людей, которые о low-level программировании — ни ухом, ни рылом, какими бы доками они ни было в квантовой физике и макроэкономике. Комитет смирился с идеей превратить низкоуровневый C в высокоуровневый C-хрен_знает_что. Язык, на котором можно было (и неоднократно реализовано) делать операционные системы, превращается в сверхвысокоуровневое, не имеющее никакого отображения на железо, нечто, на котором можно писать очередное 1С, но ОС или хотя бы драйвер — нет, ребята, пишите на ассемблере.
А потом C++ посредством механизма наследования (какая издёвка над столпами ООП) получил всё это дерьмо на свой обеденный стол. Держитесь, ребята. Или, осознавая существенные отличия архитектур, переносимо операционки писать, или разргребать, подобно дерьму, существенные отличия архитектур в угоду Васе, который не может понять, почему нельзя просто поделить икс на игрек...
Microsoft на старте Windows 95 тоже со своим “интернетом” выступала.
Тут очень важно сделать уточнение — речь идёт не о том байте, о котором большинство сразу могло подумать (и который правильнее называть “октет”), а о том, который определён стандартами языков С или С++ как нечто адресуемое и способное хранить любой символ из набора символов среды исполнения ("addressable unit of data storage large enough to hold any member of the basic character set of the execution environment")
С системами, на которых
sizeof(char) == sizeof(short) == sizeof(int) == sizeof(long) == 1, мне довелось работать 35 лет назад :)«Чужой» прекрасен, но лучшим всё же считаю второй фильм — «Чужие».
А я, пока писал тот комментарий, поймал себя на мысли, что тоже использовал бы такую форму, если бы мне сегодня пришлось писать на Фортране. Но я с ним расстался более 30 лет назад, и, признаться, ни разу не пожалел.
Пока вникал в комментарий и строчил свой — уже успел забыть :)
А мне не нравилось, но пришлось много :)
В РАФОС/ОСРВ (RT11/RSX11M) ABI был настолько логичен и строен, что вряд ли бы кому-то пришло в голову писать об этом целую книгу — пары страниц было достаточно.
Привет тебе от них, стоят у меня на полке :)
Вообще-то логический IF (к упомянутому арифметическому) появился в FORTRAN IV (который и стал стандартом 66) и без всех этих знаков.
.NE., .EQ., .LT., .LE., .GT., .GE..NOT., .AND., .OR.
Дело скорее не в персональных компутерах. Сначала в DEC долго жевали сопли, выбирая между CISC и RISC. И даже остановили разработку Prism. Потом долго жевали сопли, размышляя о том, стоит ли влезать в разработку микропроцессоров. А когда наконец увидели, что будущее таки за микропроцессорами, подорвались, откопали Prism, выпустили фантастическую Alpha... Но было уже поздно,Compaq сожрал DEC, добил Alpha, и благополучно издох сам под тушкой HP.
Там прямо написано — “СМ-4, спарка, RSX-11M”. А “похоже на ДВК” потому, что это знаменитый “фрязинский” терминал «Электроника 15ИЭ-00-013»
Это был какой-то сильно более другой ДЕМОС (да и ДЕМОС ли вообще?). Обсуждаемый был ничуть не менее англоговорящим, чем его заокеанский “родитель”.
Юристы с копирастами :)
Тот же Торвальдс сам говорил, что linux не появился, если бы не было юридического наезда Novell на BSD.
Категорически подтверждаю. Система команд Intel x86 (да и 8080 тоже) после PDP-11 — это раздутое чудовище. Чего, кстати, нельзя сказать о системе команд Mototola 68000, по-моему, над ней работали чуваки под сильным впечатлением от PDP-11.:) Я вообще в те времена надеялся, что победит Motorola. Но рынок при наличии альтернатив практически никогда не выбирает лучшую. Да ещё и военные давят иногда.
Ну, про “не чувствуете” — это перебор немножко. Например, на x86 ты преспокойно можешь дереферить нечётный указатель на слово, на PDP-11 ты за это гарантированно огребаешь "Bus error".
Чудесно они подходили. Первая половина 80-х, в одном там СМУ (пусконаладчики на нашем испытательном полигоне) в Караганде — СМ-1420 с консолью в машзале и 4-мя терминалами в кадрах/бухгалтерии.