Прошлый айфон прожил у меня 7 лет (дважды менял батарейку, первый раз неудачно - польстился на какую-то паль). Текущий айфон живёт уже 3,5 года (покупал как раз предыдущее поколение), пока расставаться с ним не собираюсь
Онбординг, оффер, гайдлайн, ассемблит - вы уверены, что используете эти совершенное не нужные в данном контексте англицизмы в их более-менее общепринятом значении в современном русском языке? Лично мне было трудно это читать, всё время приходилось включать внутренний переводчик
Вы бы хотя круг задач, для чего вам БД, вначале очертили. Почему вам не годится ванильный Постгрес, Clickhouse, да даже SQLite, из статьи не понятно. Ну и чем привлекательна Yuga по сравнению с Greenplum, к примеру (ну да, слива перестала быть OpenSource)?
Перфокарты были прекрасны в качестве листочков для заметок :) А широкой пленкой от бобин мы в конце 1990-х помидоры в теплице подвязывали :) Родители в 80-х были не то что программисты в современном понимании, но какие-то программы для расчетов писали, а отец на рубеже 80х-90х был зав ВЦ в местном университете (оттуда потом и попали к нам эти бобины) А в 90е, до внедрения 1С в провинции, был самописный расчет зп и пр.
Еще когда я работал в науке (больше 10 лет назад) меня не то, чтобы бесило, но настораживало, что всех научных сотрудников обязательно заставляли заниматься педагогической деятельностью, а штатных преподавателей ВУЗов - писать научные статьи. Первое ещё объяснимо - всё же передача реального опыта, а второе привело к появлению многочисленных местных конференций, сборников их тезисов с обильным цитированием соседа по кафедре по принципу "он хороший мужик"...
Я даже в ковид работал в офисе. Банк, персональные данные, кибербеза, все дела. Ну и не сдох. Повезло, конечно, что до офиса было 40 минут. Сейчас с удовольствием работаю в гибридном формате. Офис даже предпочтительнее, потому что переезд с одной съемной квартиры на другую показал, что много вкладывать в рабочее место в недвижке, которая тебе не принадлежит, смысл, может, и имеет, но тоже влечет за собой определенные последствия
Прочитали совместно с коллегами, обсудили - и немножко осудили и остудили пыл автора :)
Также в современных реалиях бизнеса выдвигаются требования к скорости работы OLAP-системы: *при выполнении запросов, результаты должны быть возвращены за секунды или менее; *хранение данных на диске, так как полностью хранить свойственный для OLAP системы объем данных в ОЗУ непозволительно дорого с точки зрения затрат на оборудование;
Я не представляю, как у автора эти два пункта уживаются в одном абзаце. Как сказал один умный человек: Кликхаус стремится быть быстрым. Дополню, что "хранение данных на диске" и "быстрый" - вещи противоположные, так что выбираем: либо скорость, либо денежки. И если мы выбираем денежки и храним на Клике - то мы альтернативно одарённые, потому что хранить можно и подешевле, а чтобы что-то дёргать и совать в "быстро" - Кликхаус может присосаться практически к любой СУБД, так или иначе.
например, если планируется несколько миллионов операций вставок в секунду, лучше использовать семейство Log engine
Если планируется несколько миллионов вставок в секунду, лучше использовать другую СУБД, так как КХ вообще не для этого предназначен, он крайне плохо уживается с Insertами, особенно малых объемов, нечего извращаться с Log Engine, который по сути своей весьма кастрирован и для аналитических обработок не подходит, его предназначение буквально - писать логи.
В итоге пришли ко мнению, что полезная информация только та, которую автор взял из доков КХ, а его выводы - сомнительны и спорны, рассуждения глубоко философские, статью советую для ознакомления с иной точкой зрения, но не как руководство или, не дай бог, жизненный опыт.
Не подходит под этот контекст. Скорее, "изобретать велосипеды", "Наступать на грабли". Но выражения такого не слышал
я думаю, список тут открытый :)
Отличный игрок в танчики - неплохой ресурс для военкомата!
Был у меня такой двухтомник. Очень мне нравился.
Вообще, отец умел откуда-то доставать такие книги, но он и был программистом.
Байт у них хорош. "Октет", как-то так :)
Прошлый айфон прожил у меня 7 лет (дважды менял батарейку, первый раз неудачно - польстился на какую-то паль). Текущий айфон живёт уже 3,5 года (покупал как раз предыдущее поколение), пока расставаться с ним не собираюсь
Онбординг, оффер, гайдлайн, ассемблит - вы уверены, что используете эти совершенное не нужные в данном контексте англицизмы в их более-менее общепринятом значении в современном русском языке?
Лично мне было трудно это читать, всё время приходилось включать внутренний переводчик
Вы бы хотя круг задач, для чего вам БД, вначале очертили. Почему вам не годится ванильный Постгрес, Clickhouse, да даже SQLite, из статьи не понятно.
Ну и чем привлекательна Yuga по сравнению с Greenplum, к примеру (ну да, слива перестала быть OpenSource)?
В Сбере, емнип, нет понятия "младший разработчик / инженер". Есть "разработчик", потом "ведущий", потом "главный" :-)
насколько я помню, курсант - это пока присягу не принёс. После присяги будет воинское звание (рядовой / матрос)
Перфокарты были прекрасны в качестве листочков для заметок :)
А широкой пленкой от бобин мы в конце 1990-х помидоры в теплице подвязывали :)
Родители в 80-х были не то что программисты в современном понимании, но какие-то программы для расчетов писали, а отец на рубеже 80х-90х был зав ВЦ в местном университете (оттуда потом и попали к нам эти бобины)
А в 90е, до внедрения 1С в провинции, был самописный расчет зп и пр.
Диагноз, конечно, по юзерпику, но дефицит железа исключили из списка возможных причин?
Еще когда я работал в науке (больше 10 лет назад) меня не то, чтобы бесило, но настораживало, что всех научных сотрудников обязательно заставляли заниматься педагогической деятельностью, а штатных преподавателей ВУЗов - писать научные статьи. Первое ещё объяснимо - всё же передача реального опыта, а второе привело к появлению многочисленных местных конференций, сборников их тезисов с обильным цитированием соседа по кафедре по принципу "он хороший мужик"...
Ахахах, ну сделают оклад рядовому доценту 300-500 тыс. Да хоть миллион! Но нанимать будут на 1/10 ставки. В научных институтах такое проходили.
Я даже в ковид работал в офисе. Банк, персональные данные, кибербеза, все дела. Ну и не сдох. Повезло, конечно, что до офиса было 40 минут.
Сейчас с удовольствием работаю в гибридном формате. Офис даже предпочтительнее, потому что переезд с одной съемной квартиры на другую показал, что много вкладывать в рабочее место в недвижке, которая тебе не принадлежит, смысл, может, и имеет, но тоже влечет за собой определенные последствия
Понимаю, лично я отлично работаю в гибридном формате.
Прочитали совместно с коллегами, обсудили - и немножко осудили и остудили пыл автора :)
Я не представляю, как у автора эти два пункта уживаются в одном абзаце. Как сказал один умный человек: Кликхаус стремится быть быстрым. Дополню, что "хранение данных на диске" и "быстрый" - вещи противоположные, так что выбираем: либо скорость, либо денежки. И если мы выбираем денежки и храним на Клике - то мы альтернативно одарённые, потому что хранить можно и подешевле, а чтобы что-то дёргать и совать в "быстро" - Кликхаус может присосаться практически к любой СУБД, так или иначе.
Если планируется несколько миллионов вставок в секунду, лучше использовать другую СУБД, так как КХ вообще не для этого предназначен, он крайне плохо уживается с Insertами, особенно малых объемов, нечего извращаться с Log Engine, который по сути своей весьма кастрирован и для аналитических обработок не подходит, его предназначение буквально - писать логи.
В итоге пришли ко мнению, что полезная информация только та, которую автор взял из доков КХ, а его выводы - сомнительны и спорны, рассуждения глубоко философские, статью советую для ознакомления с иной точкой зрения, но не как руководство или, не дай бог, жизненный опыт.
Объясните, плиз, человеку, привыкшему к понятию "кроп-фактор", как вот эти 1/1.8", 1/2.3" перевести в физические размеры матрицы?
А унитазы вообще вечны!
У нас была "группа размножения". И работали там девушки.И да, мы нередко ходили в эту группу :-)