Таким образом получается, что проводимость газов - это вовсе не из за продуктов сгорания (хотя, я думаю, они вносят свою роль тоже - та же сажа, то бишь, углерод) а из за ионизации.
Вы забываете про масштаб явления. Я не сказал, что без продуктов сгорания разряда не будет. Я сказал, что проводимость воздуха без этих компонентов при той же температуре (интегрально там порядка 900К) будет настолько мала, что никакого "стрелка начинает падать" вы не увидите. Она будет падать ну очень медленно.
Порог, когда термическая ионизация воздуха начинает быть заметной - это порядка 1500К. Столько может быть только в самой горячей части пламени свечи. Но вы в принципе не сможете заполнить весь объём между электродами газом такой температуры - наружные слои пламени заметно холоднее, да плюс гидродинамический захват наружных холодных масс воздуха, да охлаждение за счёт излучения, теплопередачи, да ламинарный пристеночный слой... так что практически весь эффект передачи заряда между электродами наблюдается именно благодаря продуктам частичного сгорания. Кстати, если использовать не свечу, а газовую горелку с метаном, эффект разряда будет заметно меньше.
И насчёт первого я был прав всё таки
Увы. Вы-то говорили о кристалле, а не абстрактно о составе. А вот в кристаллической решётке ионов нет. Есть практически только нейтральные атомы, у которых по сравнению с моноатомным состоянием несколько смещена электронная плотность. Точно так же абстрактно можно было написать и "представляющее собой соотношение атомов натрия и хлора 1:1" - и это тоже было бы правдой. Но точно так же не отражающей того, о чём мы говорим.
сделать соль жидкой вполне возможно, нужно всего лишь её бросить в воду
У вас была соль - индивидуальное вещество, может, даже чистое. А стал - раствор соли в воде. А вовсе даже не жидкая соль.
она состоит из натрия и хлора, представленных в составе кристаллической решётки в соотношении 1 к 1 (то есть количество ионов* натрия и ионов хлора одинаково), располагаются они в виде октаэдров, то есть, один ион хлора окружён шестью ионами натрия
В кристалле? ионы? Это что-то новенькое...
повышение температуры разбивает молекулы молекулярных газов, другими словами, ионизирует их
Нет, я понимаю, что лекция для колхозников - но всему же должны быть пределы. Если поверить тому, что вы пишете - то молекула хлора должна "разбиться" на два атома, один из которых имеет заряд -1, а второй +1, что весьма сомнительно при вменяемых температурах. Чтобы оторвать электрон у хлора, потребуется ну ОЧЕНЬ повышение температуры. Гораздо вероятнее, что образуется атомный газ, а не ионы.
то есть, ток начинает течь прямо через нагретый свечой воздух
Щазз! если между электродами гнать не продукты (частичного) сгорания, а сухой нагретый до той же температуры воздух - состаришься ждать, пока заряд через него утечёт.
Навскидку 30 или 31 марта, может ещё плюс-минус день. Сего года, есссно.
Просто я достаточно язвительно прошёлся по автору в комментариях, ну не первый раз у этого автора такие косяки, сколько можно.. потом более развёрнуто пообщались в диалогах на предмет фактических ошибок с подробным их разбором, по итогам чего статью сняли. Диалоги датированы 2 апреля.
Комментарии к снятой статье, кстати, тоже недоступны.
И сразу возникает вопрос - а пространство локов одно на оба типа наборов аргументов, или они различны? А то ведь случайно попасть грязным пальцем куда не надо - это у нас запросто..
Это исключает любые коллизии
Слишком категорично, а потому вызывает сомнения. Всё хорошо, пока инстанс Постгресса обслуживает экземпляры одного приложения, ну или пусть нескольких, но построенных с учётом совместного существования. А если на одном инстансе собрались приложения, которые о соседях и слыхом не слыхивали? Да и хэширование - оно, конечно, штука хорошая, но отсутствия коллизий на строго 100% не гарантирует.
Он блокирует только тех, кто проверяет тот же advisory lock.
Странно.. мне показалось, что тот, кто обнаружил, что уже существует чужой advisory lock с заданным номером, сам себя блокирует. Вернее, ограничивает.
То есть с VPN я опасен только для товарищей из власти... которые, к слову, тоже где-то как-то соседи.
Кстати, с топором я для соседей опасен только если вдруг сделаю какой неправильный вывод.. да и то не всегда и не сразу. Впрочем, до вербовки дело уж точно не дойдёт.
Ну так это не проблема того, что в школе стало больше учеников. Проблема в том, что НЕ стало в этой школе больше учителей. Отсюда и избыточное количество обучаемых в классе, и недостаток внимания отдельному ученику. Косвенно, возможно, это и проблема площадей - сама-то школа от того, что в ней теперь учится на 60% больше учеников, не раздвинулась, а если в школе 20 помещений, то 30 классов одновременно заниматься ну никак не смогут. А вторая смена - не решение.
При нормальных соотношениях полтыщи учеников на школу - совсем не проблема. У нас в школе учеников куда как больше было, ничего, выучились, локтями не толкаясь, классы были в среднем по 20 учеников.
О минусах такой реализации, думаю, и говорить не стоит.
Собственно SQL-щикам известно, что принципиально существует две стратегии выполнения CTE. Это кэширование и инлайнинг.
С кэшированием (и его предельной версией - материализацией) всё понятно - это правильный и логичный подход. А заодно гарантирующий детерминированный результат. Правда, детерминированный не в смысле результата выполнения запроса, а в том смысле, что эта стратегия гарантирует идентичность наборов записей, используемых копиями CTE. Даже если само CTE содержит недетерминированные конструкции.
А вот инлайнинг - это весьма спорная стратегия. Особенно если внутри есть нечто недетерминированное. Каждая заинлайненная копия вернёт уникальный набор записей, не совпадающий с таковым, возвращённым другой копией. И неудивительно, что в конечном итоге результат может сильно отличаться не то что от ожидаемого, но и просто от вменяемого. Что вы как раз и наблюдаете.
Но при этом и инлайнинг имеет право на существование - просто потому, что кратное выполнение CTE может оказаться выгоднее по ресурсам, чем кэширование. Но для корректного использования инлайнинга СУБД должна грамотно исследовать код CTE и убедиться, что он производит гарантированно детерминированный результат, и что при этом план с кратным исполнением более выгоден, чем план с кэшированием. Некоторые СУБД это всё же умеют. Вроде бы...
Если ClickHouse использует инлайнинг и описывает это в документации, то он (или она? или вообще оно?) просто сваливает такой анализ на программиста. Не прочитал, не проанализировал, не учёл - ну хлебай полной ложкой. А если не описывает - то это несомненный косяк. Который, как вы говорите, уже обнаружили и даже начали исправлять.
С другой стороны, и программист тоже имеет право поучаствовать... наверное. Хоть язык изначально и декларативный. А потому возможность указать, какую стратегию использовать - ну если и не "должна быть", то во всяком случае невредно. И все шишки за свой счёт.
PS. К слову, было вовсе необязательно генерить миллион значений и обнаруживать косяк по косвенным признакам. Простой запрос должен по идее сразу и явно продемонстрировать эту проблему просто на выводимом результате выполнения:
WITH cte_numbers AS (
SELECT num FROM generateRandom(‘num UInt64’, NULL) LIMIT 2
)
SELECT t1.num, t2.num
FROM cte_numbers t1, cte_numbers t2;
По поводу похожей статьи, жду ссылку. Пока звучит как легенда.
Ничем не могу помочь - статья снята с публикации, и соответственно недоступна, в том числе на посмотреть или просто дать ссылку. А, судя по количеству и особенно качеству ошибок, ожидать её ре-публикации бессмысленно..
легаси без индексов годами, это не баг, а рынок. Кто не встречал, тому повезло. ORM и Django проекты живут по своим законам, это немного другой мир
Но у вас-то все они живут в одной системе. Нет, если вы скажете, что в Django возможно такое, что связи в модели есть, а внешних ключей да индексов, соответствующих этим связям, нет и никогда не было - поверю как имеющему дело с этой ORM, ибо сам не владею в принципе, а изучать по такому поводу уж точно лень. Просто поставлю в уме ещё один жирнючий минус.
сегодня в России (барабанная дробь) - 38,5К школ. Для сравнения: в 2000 году их было почти 69К. Получается, за 25 лет число школ сократилось примерно в полтора раза. При этом число школьников за тот же период снизилось гораздо слабее - с 20 до 18 миллионов, то есть примерно на 10%.
А поскольку все эти школьники таки учатся в школах, то просто в среднем количество учеников в одной школе увеличилось где-то на 60%, с 290 до 470 учащихся. И всё. И не вижу особого повода волосики на себе рвать.
А вот то, что сократилось абсолютное количество учащихся - это и вправду та проблема, которая должна всерьёз волновать. Да только не очень-то и волнует, походу - чем меньше учащихся, тем дешевле их обучение и тем больше экономия по сравнению с предыдущим периодом. А уж кому девать, всегда найдётся.
PS. Правда, заглянул я сюда, увидев 6/1*12, да и то лишь за тем, чтобы напомнить, что "чтобы корова меньше ела и давала больше молока, её надо меньше кормить и больше доить".
С точки зрения SQL-щика там легаси не при чём, просто там болван доделывал за идиотом. Вот как вся эта архитектура БД могла жить годами - ГОДАМИ! - без индексов? КАК? Там должно было тормозить всё, везде и всегда, и никакой Постгресс это не вывезет.
При этом непонятен вот какой момент. Поверх СУБД работает ORM. Чтобы она правильно понимала, с чем работает, в модели должны быть описаны связи, а на стороне СУБД это должно быть поддержано соответствующими внешними ключами и необходимыми для их обслуживания индексами. Но индексов-то НЕТ! Как же оно так существовало-то?
К слову, и проблема N+1 тоже не сама появилась - она создана добрыми руками очередного программиста, написавшего вот тот кривой код, который вы нам показываете.
В общем, всё описанное как-то слабо похоже на правду, скорее это придуманный, но не продуманный синтетический пример.
PS. К тому же уж больно сильно смахивает на недавно опубликованную, раскритикованную за кучу ошибок и в результате безвозвратно снятую с публикации статью за авторством одной дамы - почти что с точностью до текстов запросов.
Поэтому полный трибоэлектрический ряд составить оказалось невозможно
Ваши пояснения по этому вопросу заставляют предположить что в паре материалов А и Б возможно, что в одних условиях при их трении положительно зарядится материал А, а при других, наоборот, материал Б. Это действительно так? в смысле - наблюдается на практике...
Элементарно, Ватсон. Если постоянно проверять, то первый же бэкап после заражения покажет проблему, и можно откатиться на предыдущий. А если НЕ проверять, то есть шанс обнаружить, что не существуетни одного незараженного бэкапа, все битые, или что единственный валидный бэкап создан ещё при царе Горохе.
Ваш совет эквивалентен совету пользоваться антивирусом...
Хороший, между прочим, совет-то - пользоваться антивирусом.
Ага... а потом долго и упорно восстанавливайте наработанное за пропущенный период.
Ну и потом - если вы проверяете бэкапы, то утраченный период будет небольшим, и не зависящим от причины, по которой потребовалось подниматься из бэкапа. А вот если НЕ проверяли, а, когда он клюнул, обнаружили, что над бэкапом поработал зловред - будет больно.
Одна из самых популярных и рабочих схем резервного копирования «3-2-1»: храните не менее трёх копий, на двух типах носителей, а одну из копий держите за пределами дома или офиса.
Угу... и проверяйте, что бэкапы валидны. А не битые или, не дай бог, зашифрованные каким вирусом-вымогателем.
Вы забываете про масштаб явления. Я не сказал, что без продуктов сгорания разряда не будет. Я сказал, что проводимость воздуха без этих компонентов при той же температуре (интегрально там порядка 900К) будет настолько мала, что никакого "стрелка начинает падать" вы не увидите. Она будет падать ну очень медленно.
Порог, когда термическая ионизация воздуха начинает быть заметной - это порядка 1500К. Столько может быть только в самой горячей части пламени свечи. Но вы в принципе не сможете заполнить весь объём между электродами газом такой температуры - наружные слои пламени заметно холоднее, да плюс гидродинамический захват наружных холодных масс воздуха, да охлаждение за счёт излучения, теплопередачи, да ламинарный пристеночный слой... так что практически весь эффект передачи заряда между электродами наблюдается именно благодаря продуктам частичного сгорания. Кстати, если использовать не свечу, а газовую горелку с метаном, эффект разряда будет заметно меньше.
Увы. Вы-то говорили о кристалле, а не абстрактно о составе. А вот в кристаллической решётке ионов нет. Есть практически только нейтральные атомы, у которых по сравнению с моноатомным состоянием несколько смещена электронная плотность. Точно так же абстрактно можно было написать и "представляющее собой соотношение атомов натрия и хлора 1:1" - и это тоже было бы правдой. Но точно так же не отражающей того, о чём мы говорим.
У вас была соль - индивидуальное вещество, может, даже чистое. А стал - раствор соли в воде. А вовсе даже не жидкая соль.
В кристалле? ионы? Это что-то новенькое...
Нет, я понимаю, что лекция для колхозников - но всему же должны быть пределы. Если поверить тому, что вы пишете - то молекула хлора должна "разбиться" на два атома, один из которых имеет заряд -1, а второй +1, что весьма сомнительно при вменяемых температурах. Чтобы оторвать электрон у хлора, потребуется ну ОЧЕНЬ повышение температуры. Гораздо вероятнее, что образуется атомный газ, а не ионы.
Щазз! если между электродами гнать не продукты (частичного) сгорания, а сухой нагретый до той же температуры воздух - состаришься ждать, пока заряд через него утечёт.
Дальше не буду читать - надоело.
Навскидку 30 или 31 марта, может ещё плюс-минус день. Сего года, есссно.
Просто я достаточно язвительно прошёлся по автору в комментариях, ну не первый раз у этого автора такие косяки, сколько можно.. потом более развёрнуто пообщались в диалогах на предмет фактических ошибок с подробным их разбором, по итогам чего статью сняли. Диалоги датированы 2 апреля.
Комментарии к снятой статье, кстати, тоже недоступны.
И сразу возникает вопрос - а пространство локов одно на оба типа наборов аргументов, или они различны? А то ведь случайно попасть грязным пальцем куда не надо - это у нас запросто..
Слишком категорично, а потому вызывает сомнения. Всё хорошо, пока инстанс Постгресса обслуживает экземпляры одного приложения, ну или пусть нескольких, но построенных с учётом совместного существования. А если на одном инстансе собрались приложения, которые о соседях и слыхом не слыхивали? Да и хэширование - оно, конечно, штука хорошая, но отсутствия коллизий на строго 100% не гарантирует.
Странно.. мне показалось, что тот, кто обнаружил, что уже существует чужой advisory lock с заданным номером, сам себя блокирует. Вернее, ограничивает.
То есть с VPN я опасен только для товарищей из власти... которые, к слову, тоже где-то как-то соседи.
Кстати, с топором я для соседей опасен только если вдруг сделаю какой неправильный вывод.. да и то не всегда и не сразу. Впрочем, до вербовки дело уж точно не дойдёт.
Ну так это не проблема того, что в школе стало больше учеников. Проблема в том, что НЕ стало в этой школе больше учителей. Отсюда и избыточное количество обучаемых в классе, и недостаток внимания отдельному ученику. Косвенно, возможно, это и проблема площадей - сама-то школа от того, что в ней теперь учится на 60% больше учеников, не раздвинулась, а если в школе 20 помещений, то 30 классов одновременно заниматься ну никак не смогут. А вторая смена - не решение.
При нормальных соотношениях полтыщи учеников на школу - совсем не проблема. У нас в школе учеников куда как больше было, ничего, выучились, локтями не толкаясь, классы были в среднем по 20 учеников.
Собственно SQL-щикам известно, что принципиально существует две стратегии выполнения CTE. Это кэширование и инлайнинг.
С кэшированием (и его предельной версией - материализацией) всё понятно - это правильный и логичный подход. А заодно гарантирующий детерминированный результат. Правда, детерминированный не в смысле результата выполнения запроса, а в том смысле, что эта стратегия гарантирует идентичность наборов записей, используемых копиями CTE. Даже если само CTE содержит недетерминированные конструкции.
А вот инлайнинг - это весьма спорная стратегия. Особенно если внутри есть нечто недетерминированное. Каждая заинлайненная копия вернёт уникальный набор записей, не совпадающий с таковым, возвращённым другой копией. И неудивительно, что в конечном итоге результат может сильно отличаться не то что от ожидаемого, но и просто от вменяемого. Что вы как раз и наблюдаете.
Но при этом и инлайнинг имеет право на существование - просто потому, что кратное выполнение CTE может оказаться выгоднее по ресурсам, чем кэширование. Но для корректного использования инлайнинга СУБД должна грамотно исследовать код CTE и убедиться, что он производит гарантированно детерминированный результат, и что при этом план с кратным исполнением более выгоден, чем план с кэшированием. Некоторые СУБД это всё же умеют. Вроде бы...
Если ClickHouse использует инлайнинг и описывает это в документации, то он (или она? или вообще оно?) просто сваливает такой анализ на программиста. Не прочитал, не проанализировал, не учёл - ну хлебай полной ложкой. А если не описывает - то это несомненный косяк. Который, как вы говорите, уже обнаружили и даже начали исправлять.
С другой стороны, и программист тоже имеет право поучаствовать... наверное. Хоть язык изначально и декларативный. А потому возможность указать, какую стратегию использовать - ну если и не "должна быть", то во всяком случае невредно. И все шишки за свой счёт.
PS. К слову, было вовсе необязательно генерить миллион значений и обнаруживать косяк по косвенным признакам. Простой запрос должен по идее сразу и явно продемонстрировать эту проблему просто на выводимом результате выполнения:
С нетерпением жду методичку по выявлению кухонных ножей на кухнях. Страшный же предмет! Сколько ими было порезано народу - жуть!
И топоры на дачах не забыть. Тоже весьма опасная штука.
Спасибо за обстоятельный ответ. Очень познавательно... сочувствую.
Да я по таким поводам не минусую статьи. Ни как правило, ни в данном случае.
Ничем не могу помочь - статья снята с публикации, и соответственно недоступна, в том числе на посмотреть или просто дать ссылку. А, судя по количеству и особенно качеству ошибок, ожидать её ре-публикации бессмысленно..
Но у вас-то все они живут в одной системе. Нет, если вы скажете, что в Django возможно такое, что связи в модели есть, а внешних ключей да индексов, соответствующих этим связям, нет и никогда не было - поверю как имеющему дело с этой ORM, ибо сам не владею в принципе, а изучать по такому поводу уж точно лень. Просто поставлю в уме ещё один жирнючий минус.
А поскольку все эти школьники таки учатся в школах, то просто в среднем количество учеников в одной школе увеличилось где-то на 60%, с 290 до 470 учащихся. И всё. И не вижу особого повода волосики на себе рвать.
А вот то, что сократилось абсолютное количество учащихся - это и вправду та проблема, которая должна всерьёз волновать. Да только не очень-то и волнует, походу - чем меньше учащихся, тем дешевле их обучение и тем больше экономия по сравнению с предыдущим периодом. А уж кому девать, всегда найдётся.
PS. Правда, заглянул я сюда, увидев 6/1*12, да и то лишь за тем, чтобы напомнить, что "чтобы корова меньше ела и давала больше молока, её надо меньше кормить и больше доить".
С точки зрения SQL-щика там легаси не при чём, просто там болван доделывал за идиотом. Вот как вся эта архитектура БД могла жить годами - ГОДАМИ! - без индексов? КАК? Там должно было тормозить всё, везде и всегда, и никакой Постгресс это не вывезет.
При этом непонятен вот какой момент. Поверх СУБД работает ORM. Чтобы она правильно понимала, с чем работает, в модели должны быть описаны связи, а на стороне СУБД это должно быть поддержано соответствующими внешними ключами и необходимыми для их обслуживания индексами. Но индексов-то НЕТ! Как же оно так существовало-то?
К слову, и проблема N+1 тоже не сама появилась - она создана добрыми руками очередного программиста, написавшего вот тот кривой код, который вы нам показываете.
В общем, всё описанное как-то слабо похоже на правду, скорее это придуманный, но не продуманный синтетический пример.
PS. К тому же уж больно сильно смахивает на недавно опубликованную, раскритикованную за кучу ошибок и в результате безвозвратно снятую с публикации статью за авторством одной дамы - почти что с точностью до текстов запросов.
Так ведь добрым словом и пистолетом - оно надёжнее..
Конечно, проще сразу взять два пистолета - но уж больно палевно..
Ваши пояснения по этому вопросу заставляют предположить что в паре материалов А и Б возможно, что в одних условиях при их трении положительно зарядится материал А, а при других, наоборот, материал Б. Это действительно так? в смысле - наблюдается на практике...
Ну конкретных практических реализаций можно придумать много. Автоматизированные, несомненно, предпочтительнее.
Элементарно, Ватсон. Если постоянно проверять, то первый же бэкап после заражения покажет проблему, и можно откатиться на предыдущий. А если НЕ проверять, то есть шанс обнаружить, что не существуетни одного незараженного бэкапа, все битые, или что единственный валидный бэкап создан ещё при царе Горохе.
Хороший, между прочим, совет-то - пользоваться антивирусом.
Ага... а потом долго и упорно восстанавливайте наработанное за пропущенный период.
Ну и потом - если вы проверяете бэкапы, то утраченный период будет небольшим, и не зависящим от причины, по которой потребовалось подниматься из бэкапа. А вот если НЕ проверяли, а, когда он клюнул, обнаружили, что над бэкапом поработал зловред - будет больно.
Угу... и проверяйте, что бэкапы валидны. А не битые или, не дай бог, зашифрованные каким вирусом-вымогателем.
Когда-то междугородная связь именно так и работала.