Да, к сожалению, сегодня с негодованием в этом убедился. Разработчики даже знали об этой проблеме - я нашёл несколько тикетов с багрепортами, но, видимо, на релизе решили, что "и так сойдёт". Разумным способом быстро пофиксить оказался переход на версию с docker.com.
Смею заметить, что Гугл уже давно достаточно велик, чтобы создавать свои серверы самостоятельно.
Но, начинали они именно с идеологии «максимально дёшево, но заменяемо». По слухам, так живут и сейчас.
Максимально дешёвые серверы, состоящие из материнки и минимального набора компонентов, чтобы оно не вывалилось из стойки, и не сгорело.
Общий принцип — многократное резервирование и контроль за тем, что именно сгорело. Вроде бы работает: на серваках Гугла (включая youtube, и других), чуть ли ни четверть мирового интернет-трафика.
Основной идеей выбора именно такой основной идеи было то, что поставщики серверов дерут втридорога, и всё-равно не способны обеспечить даже 3 девятки.
… иногда даже вина человека, который занимался выбором БД. Просто потому что колоночные БД и, например, теперь уже бесплатный кликхауз, это могут делать на порядки быстрее.
Но, в целом, мы приходим к изначальному вопросу статьи.
Для того, чтобы выбрать Clickhouse для решения определённого набора задач, надо знать и про Clickhouse, и про то, на каких наборах задач он будет в сотни раз быстрее других СУБД…
И, да, в общем случае, я фиг знает, как вообще можно такие вопросы гарантированно решать за 2-3-4 часа одного собеседования. Но в Яндекс с 10ю собеседованиями и ставкой ниже рынка не пойду. Ну разве что совсем от голода помирать придётся…
Так, стоп! Это кто там такие принципы напридумывал? Те же самые люди, которые придумали триггеры и хранимые процедуры? Ок, у меня к ним есть только одно пожелание, и оно связано с адом и огнём.
Да, и триггеры, и хранимые процедуры могут быть полезны, Но вот крайне было бы замечательно, если бы каждый занимался своим делом. БД — хранила и выбирала данные, а все остальные — всё остальное.
Кхм, ну и да, я понимаю, что уже может быть преувеличиваю… Так можно и JOIN ересью объявить… Но возможно, об этом стоило бы подумать. :-)
Спрашивали, спрашивали про мячики. Ещё году в 2007, когда это и в гугле могло сойти за новинку. Ну и, собственно, да — в общем, вряд ли я в Яндекс пойду. В прошлый раз пока их рекрутёр расщедрился договориться о собеседовании, у меня уже другой оффер был. И не один.
Да знаю я всё это, знаю. То, что одна очень богатая корпорация, имеет столь хорошие связи в законодательных органах США, что ровно под неё меняют закон, и ровно тогда, когда ей надо, ещё не отменяет факта что срок действия у авторских прав всё же есть.
С одной стороны, такое бывает не только в США, с другой — вообще изначальная цель изобретения авторского права сейчас ровно этими же законами об авторском праве и уничтожается. Но это уже другая история.
Для авторских прав есть ограничение по сроку действия. Иногда ещё нет изначального правообладателя, который слишком быстро исчез, чтобы продать хоть за сколько-то авторские права. И сами законы об авторских правах могут очень разниться в зависимости от локации.
У некоторых просто нет выбора. Либо лицензионные ограничения, либо ограничения по железу. Либо, например, корпоративные правила, или необходимость работать под старой версией определённой программы. Да что, там, даже DOS ещё в какой-то степени жив. )
Честно сказать, крайне побоялся бы скачивать и использовать этот браузер из соображений более связанных с безопасностью. А ещё из-за того, что он основан на Chrome, который сейчас занял нишу, в которой господствовал Internet Explorer 20 лет назад. Тем не менее — и правда, вдруг кому-то пригодится от безысходности.
Из такой логики может исходить операционная система — она главное, а иногда даже единственное «приложение», исполняемое на ПК. И она выделяет остальным приложениям столько памяти, сколько они попросят.
Когда из такой логики — «мне нужнее, я обратно память не отдам, всё-равно никого рядом нет» — начинает исходить другое приложение, пусть даже важное и нужное, может получиться плохо. Оно не может знать сколько физической памяти в системе, какая часть из неё используется, и сколько других приложений выгружено в swap для того чтобы выделить ещё немного памяти для него.
Приложение не должно подменять собой систему распределения памяти ОС. А следовательно, не должно использовать больше памяти чем необходимо.
Я мерил с точки зрения простого пользователя, у которого память в ноутбуке, в принципе есть. Да собственно, даже и не мерил, а просто проверял, возможно ли вообще использование более старых браузеров с новыми сайтами.
Современные браузеры по сложности не уступают операционной системе, это так. И я надеюсь, что рано или поздно их создатели (а на текущий момент в этом вопросе всё решает Google), перейдут к более модульной структуре браузера, с возможностью отключать неиспользуемые возможности. Когда-то такое произошло с операционными системами.
К сожалению, черты этого «светлого» будущего пока даже не видны в тумане.
В принципе, да. Не углубляясь в политику, уточню, что время президентства Медведева можно датировать (в релизах Firefox) примерно версиями 3.0 — 12.0. 10ая версия в этот период попадает. Размер дистрибутива Firefox 10.0.2 — 15 688 КБ.
Конечно, на самом деле, большАя часть проблемы — это не столько размер кода (то есть время его загрузки), сколько скорость и сложность его выполнения. Мало того, что объём страниц стал больше, так ещё и разбирать и выполнять их стало сложнее.
Святой уверенности конечно же не было. Даже если не знать о тенденциях развития веб в последние 10 лет, остаются ещё оптимизация браузеров и выпуск новых процессоров с новыми инструкциями, которые могут поддерживать только браузеры, собранные новыми компиляторами.
В данном случае был просто мини-эксперимент, результат которого меня даже немного удивил. Я ожидал, что старые браузеры будут медленнее. Я не ожидал, что разница окажется настолько невелика — что, в общем-то, даже и «не медленнее». С учётом появления за это время HTTP2 и HTTP3, новых алгоритмов сжатия (а-ля Brotli), радикальных изменений в рендеринге страниц… Если честно, стоило бы ожидать того, что старые браузеры будут очень медленными.
Ну то есть если какой-то пользователь заорет, что-то типо «У меня ничего не работает» и вы тут же всё бросите и начнете проводить полную регрессию всего приложения, чтобы понять что же конкретно не работает
Нет, конечно же. Для этого и есть поддержка, которая может собрать статистику, попробовать разобраться в том, чего же пользователь хочет, и, при необходимости (например, заметив высокую частоту обращений, или важность функционала), эскалировать инцидент. Простите, перешёл на новояз — создать задачу о проблеме.
Помоему лучше идти по пути наименьшего сопротивления, задав уточняющие вопросы, чем в общем-то и должна заниматься поддержка. Поддержка — это не ретранслятор криков пользователей.
Вот это-то «идти по пути наименьшего сопротивления» мне и не нравится. В компаниях, где копают от забора и до обеда, это самый естественный ход мыслей для сотрудника. Мне же хочется делать продукт лучше, даже если я сам им не пользуюсь. И мне чётко известно, что не во всех случаях можно получить всю нужную информацию. Да, можно попросить техподдержку о ней, но сидеть и ждать пока информация появится — слишком большая роскошь.
Особенно забавно это будет выглядеть, если в итоге окажется, что пользователь идиот и делает что-то не так, а система отрабатывает штатно, согласно его неадекватному поведению.
Вы реально, как мне кажется, работаете в основном с корпоративным софтом. С пользовательским, особенно с массовым пользовательским софтом это так не работает. Если пользователь «глупый» — это может быть его проблема, но если их таких много — это ваша проблема. И если штатное поведение вашей программы вызывает недоумение и даже письма или звонки в поддержку, вероятно что-то не так с вашим софтом, а не с его пользователями. Да, пользователи часто поступают неадекватно (на чей-то взгляд), это нормально.
Пользователь вас просто пошлёт нафиг, и даже не ответит. А техподдержка — это просто средство коммуникации с пользователями, вы конечно можете их просить об информации, но во многих случаях они её добыть не смогут.
Разработка массового продукта очень отличается от «систем автоматизации» для банков и других штучных заказчиков. У продукта может быть не 100 пользователей в галстуках и наруч… костюмах, а хотя бы 10 миллионов. И никто из них ничего не должен и не хочет отвечать, а если ваш продукт что-то плохо делает… есть ещё несколько у конкурентов.
И даже если вам попадётся человек, который искренне захочет помочь, и за счёт своего времени и денег попробует воспроизвести вашу (в общем-то) проблему, и помочь вам улучшить ваш продукт, вовсе не факт, что удастся воспроизвести нечастый случай, когда происходит баг.
Компания несёт убытки, а вы упёрлись рогом, и уверены что она должна предоставить вам любую информацию по запросу. А может быть стоит самому мозг напрячь? Не надеясь на аналитиков, тестировщиков и саппорт? Работа программиста — думать, а уже во вторую очередь — писать код.
Очень хорошо работать в крупной организации. В той самой, где есть отдельные подносильщики платочков для левой и правой руки. Однако большинство компаний себе такую роскошь позволить не могут, и платят за то, что вы решаете проблему, а не за то, что вы очень похожи на чёрный ящик.
И нередко описание проблемы сводится к тому, что «некоторые пользователи жалуются, что наше приложение у них не работает в Таджикистане». Причём пользователей много, и проблему воспроизвести вне Таджикистана не получается.
И я знаю, что вы предложите — отправить тестировщика в командировку, чтобы он воспроизвёл проблему. Если пользователи приносят не миллионы долларов так не будет делать никто. А если будет, то уже можно спокойно позвать подавальщика платочков для правой руки, и протереть её перед тем как поставить на задаче штампик «Won't do».
Игорь Ашманов, который во время приёма на работу Сысоева был техническим директором Рамблера на Роем прямо заявил, что обязанности писать код в трудовом договоре не было, более того, специально оговаривалась возможность работать над личным проектом (который впоследствии стал называться Nginx). Таким образом, у меня в голове сам собой складывается заголовок типа: "Сын олигарха пытается отобрать деньги у программиста, пользуясь связями в МВД". И вот не удивлюсь, если во всех завтрашних западных сми что-то такое и будет.
Да, к сожалению, сегодня с негодованием в этом убедился. Разработчики даже знали об этой проблеме - я нашёл несколько тикетов с багрепортами, но, видимо, на релизе решили, что "и так сойдёт". Разумным способом быстро пофиксить оказался переход на версию с docker.com.
Обновился с 38 до 39. Первые полчаса - полёт нормальный.
Но, начинали они именно с идеологии «максимально дёшево, но заменяемо». По слухам, так живут и сейчас.
Максимально дешёвые серверы, состоящие из материнки и минимального набора компонентов, чтобы оно не вывалилось из стойки, и не сгорело.
Общий принцип — многократное резервирование и контроль за тем, что именно сгорело. Вроде бы работает: на серваках Гугла (включая youtube, и других), чуть ли ни четверть мирового интернет-трафика.
Основной идеей выбора именно такой основной идеи было то, что поставщики серверов дерут втридорога, и всё-равно не способны обеспечить даже 3 девятки.
Но, в целом, мы приходим к изначальному вопросу статьи.
Для того, чтобы выбрать Clickhouse для решения определённого набора задач, надо знать и про Clickhouse, и про то, на каких наборах задач он будет в сотни раз быстрее других СУБД…
И, да, в общем случае, я фиг знает, как вообще можно такие вопросы гарантированно решать за 2-3-4 часа одного собеседования. Но в Яндекс с 10ю собеседованиями и ставкой ниже рынка не пойду. Ну разве что совсем от голода помирать придётся…
Да, и триггеры, и хранимые процедуры могут быть полезны, Но вот крайне было бы замечательно, если бы каждый занимался своим делом. БД — хранила и выбирала данные, а все остальные — всё остальное.
Кхм, ну и да, я понимаю, что уже может быть преувеличиваю… Так можно и JOIN ересью объявить… Но возможно, об этом стоило бы подумать. :-)
С одной стороны, такое бывает не только в США, с другой — вообще изначальная цель изобретения авторского права сейчас ровно этими же законами об авторском праве и уничтожается. Но это уже другая история.
Когда из такой логики — «мне нужнее, я обратно память не отдам, всё-равно никого рядом нет» — начинает исходить другое приложение, пусть даже важное и нужное, может получиться плохо. Оно не может знать сколько физической памяти в системе, какая часть из неё используется, и сколько других приложений выгружено в swap для того чтобы выделить ещё немного памяти для него.
Приложение не должно подменять собой систему распределения памяти ОС. А следовательно, не должно использовать больше памяти чем необходимо.
Современные браузеры по сложности не уступают операционной системе, это так. И я надеюсь, что рано или поздно их создатели (а на текущий момент в этом вопросе всё решает Google), перейдут к более модульной структуре браузера, с возможностью отключать неиспользуемые возможности. Когда-то такое произошло с операционными системами.
К сожалению, черты этого «светлого» будущего пока даже не видны в тумане.
Святой уверенности конечно же не было. Даже если не знать о тенденциях развития веб в последние 10 лет, остаются ещё оптимизация браузеров и выпуск новых процессоров с новыми инструкциями, которые могут поддерживать только браузеры, собранные новыми компиляторами.
В данном случае был просто мини-эксперимент, результат которого меня даже немного удивил. Я ожидал, что старые браузеры будут медленнее. Я не ожидал, что разница окажется настолько невелика — что, в общем-то, даже и «не медленнее». С учётом появления за это время HTTP2 и HTTP3, новых алгоритмов сжатия (а-ля Brotli), радикальных изменений в рендеринге страниц… Если честно, стоило бы ожидать того, что старые браузеры будут очень медленными.
Нет, конечно же. Для этого и есть поддержка, которая может собрать статистику, попробовать разобраться в том, чего же пользователь хочет, и, при необходимости (например, заметив высокую частоту обращений, или важность функционала), эскалировать инцидент. Простите, перешёл на новояз — создать задачу о проблеме.
Вот это-то «идти по пути наименьшего сопротивления» мне и не нравится. В компаниях, где копают от забора и до обеда, это самый естественный ход мыслей для сотрудника. Мне же хочется делать продукт лучше, даже если я сам им не пользуюсь. И мне чётко известно, что не во всех случаях можно получить всю нужную информацию. Да, можно попросить техподдержку о ней, но сидеть и ждать пока информация появится — слишком большая роскошь.
Вы реально, как мне кажется, работаете в основном с корпоративным софтом. С пользовательским, особенно с массовым пользовательским софтом это так не работает. Если пользователь «глупый» — это может быть его проблема, но если их таких много — это ваша проблема. И если штатное поведение вашей программы вызывает недоумение и даже письма или звонки в поддержку, вероятно что-то не так с вашим софтом, а не с его пользователями. Да, пользователи часто поступают неадекватно (на чей-то взгляд), это нормально.
Разработка массового продукта очень отличается от «систем автоматизации» для банков и других штучных заказчиков. У продукта может быть не 100 пользователей в галстуках и наруч… костюмах, а хотя бы 10 миллионов. И никто из них ничего не должен и не хочет отвечать, а если ваш продукт что-то плохо делает… есть ещё несколько у конкурентов.
И даже если вам попадётся человек, который искренне захочет помочь, и за счёт своего времени и денег попробует воспроизвести вашу (в общем-то) проблему, и помочь вам улучшить ваш продукт, вовсе не факт, что удастся воспроизвести нечастый случай, когда происходит баг.
Компания несёт убытки, а вы упёрлись рогом, и уверены что она должна предоставить вам любую информацию по запросу. А может быть стоит самому мозг напрячь? Не надеясь на аналитиков, тестировщиков и саппорт? Работа программиста — думать, а уже во вторую очередь — писать код.
И нередко описание проблемы сводится к тому, что «некоторые пользователи жалуются, что наше приложение у них не работает в Таджикистане». Причём пользователей много, и проблему воспроизвести вне Таджикистана не получается.
И я знаю, что вы предложите — отправить тестировщика в командировку, чтобы он воспроизвёл проблему. Если пользователи приносят не миллионы долларов так не будет делать никто. А если будет, то уже можно спокойно позвать подавальщика платочков для правой руки, и протереть её перед тем как поставить на задаче штампик «Won't do».
Игорь Ашманов, который во время приёма на работу Сысоева был техническим директором Рамблера на Роем прямо заявил, что обязанности писать код в трудовом договоре не было, более того, специально оговаривалась возможность работать над личным проектом (который впоследствии стал называться Nginx). Таким образом, у меня в голове сам собой складывается заголовок типа: "Сын олигарха пытается отобрать деньги у программиста, пользуясь связями в МВД". И вот не удивлюсь, если во всех завтрашних западных сми что-то такое и будет.