Внимательный читатель наверняка предложит полностью перейти на синхронные логгеры. Почему бы и нет? У синхронных логгеров есть неприятность – они сильно нагружают cpu. Например, в моем случае с асинхронным логгером загрузка cpu ~100% (по данным утилиты top), а в синхронном варианте порядка 10-20%. Если асинхронных логгеров будет больше, то и загрузка cpu значительно поднимется.
Так кто больше нагружает CPU, синхронный или асинхронный?
У асинхронных логгеров есть другая проблема — в случае креша приложения, информация асинхронном логе может пропасть, т.е. как раз самая важная причина креша будет недоступна.
А Яндекс встречается? Какой-то странный довод. Да ещё «возможно». С учётом того, что у вас в профиле написано HR — не знать названия компаний, да ещё и коверкать их — какое-то странное поведение :)
А у меня есть примеры, что разработчики разрабатывают на .NET/.NET Core на Windows, а деплоят это и на Linux, и на Windows. Т.е. используется мультитаргет, а запускается где удобнее. И волосы густые и шелковистые.
С симуляциями как-то обойдён стороной момент, что мир за пределами симуляции может быть совершенно другим. Скорость света там может быть больше, или вообще бесконечная, так что для «компьютеров» там совершенно другие ограничения. Время может течь по-другому, размерность пространства тоже быть другой.
В итоге, по факту, доказательствами симуляции могут быть только какие-то концептуальные противоречия в нашей физике, что объекты ведут себя не так, как должны, и это никак не может быть объяснено (например, из-за ограничений симуляции и оптимизации расчётов).
С другой стороны, любые проблемы могут мгновенно перестать ими быть (всем людям исправят в голове устройство мира). Т.е., например, Земля была в прошлом плоская, а звёзды были обычными цветными пикселями. Но, когда начались исследования — всё поменялось и «отрендерилось» и стало по-другому. Впрочем, это уже как раз философия.
Про глубину legacy и скриншоты СБИСа мне понравилось :)
Но вообще, есть же вьюшки и триггеры в базе данных, т.е. можно изменить структуру, улучшить алгоритмы, а для legacy кода подснуть представление.
А как вы разрабатываете? Т.е. задача формулируется максимально абстрактно, и делается максимально абстрактно? Если вы настолько не знаете требования к своей же функциональности.
Через ID предка — самый простой вариант, но самый неэффективный. И оптимизировать его, вместо использования более логичных структур — интересное, но не очень полезное занятие.
Небольшую иерархию можно вообще засосать в память и не париться ни о чём. А если иерархия с 10 млн элементами, то стоит всё-таки подумать о конретных требованиях к задаче.
Конечно же, если статья написана с целью рассказать про CTE и рекурсивные джойны, а в реальности вы используете что-то другое, то это отдельный разговор.
Кирилл, твой ответ выглядит так, что ты пошёл гуглить что такое Nested Set и взял первую ссылку из гугла на википедию, и из этого сделал выводы :)
Отвечаю:
1. Да, Nested сет имеет более затратные операции изменения иерархии, при этом сильно упрощая операции поиска. Если у вас постоянная текучка кадров, что операции вставки становятся неприлично тяжёлыми, то стоило бы упомянуть это в задаче. Т.к. большинство иерархий достаточно редко меняются.
2. В Nested Set надо переупорядочивать только Left/Right указатели, Id — это отдельное поле, которое трогать не надо.
Т.е. куча страданий и потраченного времени программиста, лишь бы не вводить Lineage или какой-нить Nested set? Которые кучу проблем смогли бы решить гораздо проще.
Так опять же. Насколько он мешает? У нас идёт только вставка, т.е. мёртвых записей не должно быть, вакуум просто пропустит эту таблицу.
А вот пункт «4 — кое что меняется в данных», выглядит как объяснение всего что может быть. В общем-то это смысл существования базы данных — кое-что менять в данных :)
А стоят ли такие сложности выигрыша в сколько-то % производительности, даже не могу представить сколько 1? 2? (с учётом статьи, вакуум даже работать не будет на этих таблицах, т.к. по критериям очистки не подойдут).
А можно перечислить причины, почему нужно отключать автовакуум? Просто все статьи, упоминающие Постгре серьёзно настаивают и предупреждают, что ни в коем случае, никогда, ни при каких условиях не отключайте вакуум. Данная не исключение.
Соответственно, я никак не могу понять, откуда берутся люди, которые это делают? Это специальные вредители среди разработчиков и админов? Или классический гипотетический сотрудник, который только в рекламе и сериалах попадается?
В C# тоже самое. По факту, структуры придуманы не от хорошей жизни, а ради перфоманса. И мутабельные структуры — это дорога в ад (во всяком случае в C#). А если структура не мутирует, то думать про копирование особо не надо.
У меня в топе лидеров пекедж net (и да, разработчики его зачем-то подключили в проект, поэтому и узнал про него, пытки паяльником выявили только то, что «что-то не работало»).
У нас забавнее делали. Народ говорит: «хотим такой-то маршрут». Руководство города: «Ок, проверим, пустим в тестовом режиме». Пускают автобус раз в час, естественно, кому надо уехать, уезжают на том, что приехало. Рукововодство: «хмм… не пользуется популярностью, смысла нет, убираем».
Ну такое: Содержится во многих белках обычной пищи
А такие побочки — ничего страшного, да и не у всех (иначе я бы щас сидел с больной головой и весь чесался). А у кого-то аллергия на груши есть, например. Значит что груши вредные?
Еще накидывают на вентилятор СМИ:
В статье как-то мало накидали. Есть какое-то исследование, где повышается риск диабета, но в целом проблем нет.
Бытовая логика подсказывает, что наш организм более «заточен» на переработку существующих в природе веществ, причем не всех. А не концентрированной химии.
Про вред «химии» не буду спорить, просто картинка.
А можно ссылки? Потому что та же википедия про аспартам утверждает:
Таким образом, в результате употребления 1 литра напитка, подслащённого аспартамом (выход 56-60 мг метанола на литр) в организм поступает меньше метанола, чем при употреблении натурального сока (до 160 мг на литр)
Т.е. получается что сок в 3 раза вреднее чем жидкость с сахарозаменителем.
Так кто больше нагружает CPU, синхронный или асинхронный?
У асинхронных логгеров есть другая проблема — в случае креша приложения, информация асинхронном логе может пропасть, т.е. как раз самая важная причина креша будет недоступна.
В итоге, по факту, доказательствами симуляции могут быть только какие-то концептуальные противоречия в нашей физике, что объекты ведут себя не так, как должны, и это никак не может быть объяснено (например, из-за ограничений симуляции и оптимизации расчётов).
С другой стороны, любые проблемы могут мгновенно перестать ими быть (всем людям исправят в голове устройство мира). Т.е., например, Земля была в прошлом плоская, а звёзды были обычными цветными пикселями. Но, когда начались исследования — всё поменялось и «отрендерилось» и стало по-другому. Впрочем, это уже как раз философия.
Но вообще, есть же вьюшки и триггеры в базе данных, т.е. можно изменить структуру, улучшить алгоритмы, а для legacy кода подснуть представление.
А в течение 12 лет тратить на обогрев улицы ресурсы CPU постоянно делая неэффективные операции — это норма?
Через ID предка — самый простой вариант, но самый неэффективный. И оптимизировать его, вместо использования более логичных структур — интересное, но не очень полезное занятие.
Небольшую иерархию можно вообще засосать в память и не париться ни о чём. А если иерархия с 10 млн элементами, то стоит всё-таки подумать о конретных требованиях к задаче.
Конечно же, если статья написана с целью рассказать про CTE и рекурсивные джойны, а в реальности вы используете что-то другое, то это отдельный разговор.
Отвечаю:
1. Да, Nested сет имеет более затратные операции изменения иерархии, при этом сильно упрощая операции поиска. Если у вас постоянная текучка кадров, что операции вставки становятся неприлично тяжёлыми, то стоило бы упомянуть это в задаче. Т.к. большинство иерархий достаточно редко меняются.
2. В Nested Set надо переупорядочивать только Left/Right указатели, Id — это отдельное поле, которое трогать не надо.
А вот пункт «4 — кое что меняется в данных», выглядит как объяснение всего что может быть. В общем-то это смысл существования базы данных — кое-что менять в данных :)
Соответственно, я никак не могу понять, откуда берутся люди, которые это делают? Это специальные вредители среди разработчиков и админов? Или классический гипотетический сотрудник, который только в рекламе и сериалах попадается?
Ну такое: Содержится во многих белках обычной пищи
А такие побочки — ничего страшного, да и не у всех (иначе я бы щас сидел с больной головой и весь чесался). А у кого-то аллергия на груши есть, например. Значит что груши вредные?
В статье как-то мало накидали. Есть какое-то исследование, где повышается риск диабета, но в целом проблем нет.
Про вред «химии» не буду спорить, просто картинка.
Т.е. получается что сок в 3 раза вреднее чем жидкость с сахарозаменителем.