У меня идёт процесс ровно наоборот- по мере возможности переписываю сервисы с C# на Go. Наиболее ощутима разница когда приходится возвращаться к проекту спустя год - два после предыдущей доработки, с Go этот процесс гораздо легче.
Забегая вперед, таким же способом может решаться и обратная задача, — скрытно извлечь произвольный файл с конфиденциальными данными из периметра предприятия.
Это в каком смысле таким же? Обратного клавиатурного канала нет, есть визуальный, то есть надо распознавать изображение в текст, технически это сложно назвать таким же способом.
Графики оценки затрат на коммуникации/написание кода некачественно отражают картину влияния коммуникаций. Если затраты на коммуникации 20% времени, а остальные 80% идёт на написание кода, это не значит что эффективность кодирования упала на 20%, поскольку коммуникации выбивают из рабочего ритма и часто бывают неэффективны, что утомляет. В итоге эффективность написания кода может упасть и на 40%.
Никогда не сталкивался с проблемами при миграции через логическую репликацию. Ключевая проблема у автора похоже заключается во фразе FOR ALL TABLES, в этом случае нужно дополнительно контролировать объем хранения журнала. Лучше всё же добавлять таблицы в репликацию порциями, начиная с неизменяемых или медленнее меняющихся, это позволяет как решить проблему с журналом так и избежать некоторых других рисков, например остановки репликации если кто-нибудь добавит таблицу на мастере, также позволяет перенастроить репликацию для отдельной таблицы (например изменив уникальный ключ).
Мускуль проигрывал постгресу по производительности на всех основных типах запросов кроме массовых (не атомарных) апдейтов. Раздражала его способность выжирать память свыше значений в настройках innodb, что требовало периодических перезапусков. Но решающее значение имел факт систематических крашей баз данных, содержащих партиционированные таблицы при достижении неких критических нагрузок: объяснения этому так и не нашлось и на этом доверие к этому изделию было окончательно утрачено.
Мы вот телеком и да, постгрес вполне тянет (в отличие от мускуля кстати). И невозможно себе представить что могло бы нас заставить вернуться на Оракл, независимо от политики. Да, в целом Оракл получше, но с учетом его стоимости и отсутствия принципиальных преимуществ его использование оправдано только для обработки очень высокомаржинальных (с большой выручкой на байт) данных.
5 Исходя из всех предыдущих пунктов совершенно не видно экономического преимущества в использовании PostgreSQL. На мой взгляд, эффективность PostgreSQL настолько низка, что даже одна стоимость серверов для неё превышает стоимость лицензий Oracle. Я уж не говорю, о стоимости работы программистов.
А из опыта этот вывод как-то подтверждается? У нас есть опыт миграции нагруженных оракловых серверов на постгрес и ни разу миграция не потребовала наращивания железа.
"Богомерзкий MVCC" нельзя считать абсолютным злом - зависит от способа использования. Конечно bloat это плохо, зато без проблем выполняются долгие запросы. В Оракле на нагруженной базе долгие запросы приводят к snapshot too old, а большие апдейты вообще противопоказаны, поскольку могут закончиться переполнением undo tablespace и длительным откатом с блокировкой таблицы. К тому же это не фундаментальный недостаток PostgreSQL - для него разработаны или разрабатываются не MVCC-шные хранилища (zheap, orioledb например) и когда в обозримом будущем они появятся в широком использовании уже у постгреса будет преимущество в этом компоненте за счет возможности выбора.
Т.е. по вашей теории парникового эффекта вообще не существует, поскольку газы не поглощают ИК и все представления о связи температуры поверхности планет с составом и плотностью атмосферы не верны?
Недостаток PlantUML в том, что Sequence это практически единственное, что он рисует хорошо. Причина в том что в PlantUML крайне скудные средства управления размещением элементов (layouts) и в Sequence размещение весьма простое, а схему почти любого другого типа он может безнадёжно слажать.
Есть российская, сертифицированная для использования на госпредприятиях РЕД ОС, использует довольно свежие версии RHEL и Fedora, в деле пока не пробовали.
Моя идея в том, чтобы каждый релиз языка поставлялся с руководством по стилю. Никто не обязан ему следовать.
И не будет их читать. Чтобы это работало нужна реализация на уровне компилятора, чтобы можно было указывать в опциях, операторы каких стилей он будет считать ошибками. Тогда руководитель разработки сможет задавать единый стиль, в котором работает команда. Но создание такого компилятора скажем для Scala с учетом размытости границ между стилями очень сложная и неоднозначная задача.
Как правило все: если нет четких фактов или доказательств утверждения, это анонсируется как гипотеза, мнения излагаются в публикациях других типов. "Мне́ние — понятие о чём-либо, убеждение, суждение, умозаключение, вывод, точка зрения по теме, в которой невозможно достичь полной объективности, основанное на интерпретации фактов или эмоциональном отношении к ним." (Википедия)
Википедия называет себя энциклопедией, а энциклопедия в отличие от соцсетей не место для публикации взглядов и мнений, если таковые не подтверждены однозначно интерпретируемыми фактами.
Спасибо, познавательно. Хотелось бы еще узнать, какое место автор отводит функциональности arena из go 1.20, казалось бы идеальный вариант для приложений со сложным и непредсказуемым использованием памяти. Или это все еще считается go разработчиками экспериментальным и неблагонадёжным функционалом?
Может хотя бы оптимизируют. Как раз вчера пытался начать использовать Thunderbird после перерыва лет в 10, закончил через минуту, поскольку вспомогательное ПО, которое отжирает 400М памяти до начала наполнения пользовательскими данными вызывает у меня непреодолимое недоумение.
Предположение что виртуальные частицы могут взаимодействовать с реальными как раз позволяют создать математическую модель эффекта, согласующуюся с экспериментами. Сомневаюсь, что открыт какой-нибудь эффект, для объяснения которого необходимо признание виртуальных частиц "не настоящими".
У меня идёт процесс ровно наоборот- по мере возможности переписываю сервисы с C# на Go. Наиболее ощутима разница когда приходится возвращаться к проекту спустя год - два после предыдущей доработки, с Go этот процесс гораздо легче.
Это в каком смысле таким же? Обратного клавиатурного канала нет, есть визуальный, то есть надо распознавать изображение в текст, технически это сложно назвать таким же способом.
Графики оценки затрат на коммуникации/написание кода некачественно отражают картину влияния коммуникаций. Если затраты на коммуникации 20% времени, а остальные 80% идёт на написание кода, это не значит что эффективность кодирования упала на 20%, поскольку коммуникации выбивают из рабочего ритма и часто бывают неэффективны, что утомляет. В итоге эффективность написания кода может упасть и на 40%.
Никогда не сталкивался с проблемами при миграции через логическую репликацию. Ключевая проблема у автора похоже заключается во фразе FOR ALL TABLES, в этом случае нужно дополнительно контролировать объем хранения журнала. Лучше всё же добавлять таблицы в репликацию порциями, начиная с неизменяемых или медленнее меняющихся, это позволяет как решить проблему с журналом так и избежать некоторых других рисков, например остановки репликации если кто-нибудь добавит таблицу на мастере, также позволяет перенастроить репликацию для отдельной таблицы (например изменив уникальный ключ).
Мускуль проигрывал постгресу по производительности на всех основных типах запросов кроме массовых (не атомарных) апдейтов. Раздражала его способность выжирать память свыше значений в настройках innodb, что требовало периодических перезапусков.
Но решающее значение имел факт систематических крашей баз данных, содержащих партиционированные таблицы при достижении неких критических нагрузок: объяснения этому так и не нашлось и на этом доверие к этому изделию было окончательно утрачено.
Мы вот телеком и да, постгрес вполне тянет (в отличие от мускуля кстати). И невозможно себе представить что могло бы нас заставить вернуться на Оракл, независимо от политики.
Да, в целом Оракл получше, но с учетом его стоимости и отсутствия принципиальных преимуществ его использование оправдано только для обработки очень высокомаржинальных (с большой выручкой на байт) данных.
А из опыта этот вывод как-то подтверждается? У нас есть опыт миграции нагруженных оракловых серверов на постгрес и ни разу миграция не потребовала наращивания железа.
"Богомерзкий MVCC" нельзя считать абсолютным злом - зависит от способа использования. Конечно bloat это плохо, зато без проблем выполняются долгие запросы. В Оракле на нагруженной базе долгие запросы приводят к snapshot too old, а большие апдейты вообще противопоказаны, поскольку могут закончиться переполнением undo tablespace и длительным откатом с блокировкой таблицы.
К тому же это не фундаментальный недостаток PostgreSQL - для него разработаны или разрабатываются не MVCC-шные хранилища (zheap, orioledb например) и когда в обозримом будущем они появятся в широком использовании уже у постгреса будет преимущество в этом компоненте за счет возможности выбора.
Т.е. по вашей теории парникового эффекта вообще не существует, поскольку газы не поглощают ИК и все представления о связи температуры поверхности планет с составом и плотностью атмосферы не верны?
Недостаток PlantUML в том, что Sequence это практически единственное, что он рисует хорошо. Причина в том что в PlantUML крайне скудные средства управления размещением элементов (layouts) и в Sequence размещение весьма простое, а схему почти любого другого типа он может безнадёжно слажать.
Есть российская, сертифицированная для использования на госпредприятиях РЕД ОС, использует довольно свежие версии RHEL и Fedora, в деле пока не пробовали.
И не будет их читать. Чтобы это работало нужна реализация на уровне компилятора, чтобы можно было указывать в опциях, операторы каких стилей он будет считать ошибками. Тогда руководитель разработки сможет задавать единый стиль, в котором работает команда. Но создание такого компилятора скажем для Scala с учетом размытости границ между стилями очень сложная и неоднозначная задача.
Как правило все: если нет четких фактов или доказательств утверждения, это анонсируется как гипотеза, мнения излагаются в публикациях других типов.
"Мне́ние — понятие о чём-либо, убеждение, суждение, умозаключение, вывод, точка зрения по теме, в которой невозможно достичь полной объективности, основанное на интерпретации фактов или эмоциональном отношении к ним." (Википедия)
Википедия называет себя энциклопедией, а энциклопедия в отличие от соцсетей не место для публикации взглядов и мнений, если таковые не подтверждены однозначно интерпретируемыми фактами.
Спасибо, познавательно. Хотелось бы еще узнать, какое место автор отводит функциональности arena из go 1.20, казалось бы идеальный вариант для приложений со сложным и непредсказуемым использованием памяти. Или это все еще считается go разработчиками экспериментальным и неблагонадёжным функционалом?
Но без оптимизации, после добавления 1 ящика сожрал 500М, совершенно не понятно на что.
Может хотя бы оптимизируют. Как раз вчера пытался начать использовать Thunderbird после перерыва лет в 10, закончил через минуту, поскольку вспомогательное ПО, которое отжирает 400М памяти до начала наполнения пользовательскими данными вызывает у меня непреодолимое недоумение.
Фраза Хотя есть и рациональное объяснение применительно данному случаю звучит особенно пикантно.
Предположение что виртуальные частицы могут взаимодействовать с реальными как раз позволяют создать математическую модель эффекта, согласующуюся с экспериментами. Сомневаюсь, что открыт какой-нибудь эффект, для объяснения которого необходимо признание виртуальных частиц "не настоящими".
Чем в таком случае объяснить эффект Казимира, что воздействует на пластины?