Pull to refresh
58
0.1
Alexander @speshuric

Пользователь

Send message

чинили баги незаметно для пользователей

Ха-ха. Вам показалось :)

На момент публикации список функций, не поддерживающих принудительное строгое шифрование, такой

Список - вся "внутренность", накопленная за ~25 лет.

Ну да, ну да. Сначала "дай носик отсканировать", а потом всё это превращается в "почему в jira время не оттрекано".

там большинство проблем уже решено

Пока приложение однопоточное - может быть. Как только приложение многопоточное - появляются весьма интересные способы выстрелить себе в ногу.

я бы вас депремировал и провел инструктаж всему отделу разработки

Так есть шанс депремировать каждый квартал новую команду.

Во-первых, не приплетайте здесь парадокс Рассела, он ни чём, а во-вторых, у меня другие формулировки.
Усложнить систему, т.е. сделать сложной, то есть состоящей из большого числа элементов и связей, причём скорее всего с циклами обратной связи, т.е. нелинейной - просто. "Просто" в данном случае больше отражает объём усилий.
Про то что сделать систему простой, т.е. выделить только существенные элементы и взаимосвязи, написано не "сложно", а "нужно приложить усилия". Сама такая деятельность, как правильно заметил @Ndochp не является системой, к ней не применима метрика сложности системы.

Усложнить систему - просто. А сделать простой - нужно приложить усилия.

Я проводил этот эксперимент на рабочей станции Pentium Xeon 2,2 ГГц с 2 ГБ оперативной памяти, Windows Server 2003 SP2 и SQL Server 2005 SP2.

Эх, были же времена, когда это считалось хорошей рабочей станцией! :)

Справедливо ли ваше утверждение для 32-битных процессоров?

И для ARM.

Сжатие на уровне строк полезно по факту только если много числовых (numeric) полей с нулями или небольшими значениями (при больших допустимых). Тогда все эти нули будут храниться компактно. Другие выгодные варианты придумать можно, конечно, но базовый, наверное, такой.

Сжатие на уровне страниц - если есть много повторяющихся (но не длинных строковых/бинарных) значений. Повторения могут быть частичными. Способ сжатия описан тут. Доступ к таким данным на чтение и запись дороже по CPU, но для таблиц с кучей похожих чисел и ссылками на другие записи (всеми типовыми способами: уидами, строками, числами, бинарными) жмутся очень хорошо и это часто даёт такой выигрыш при чтении/записи с диска, что становится оправданным. Даже для неплохих систем хранения.

Сжатие бэкапов явно алгоритм не описан, но судя по появлению в 2022 выбора между MS_XPRESS (по умолчанию) and QAT_DEFLATE (для аппаратного ускорения) и по некоторым другим признакам - штатный алгоритм сильно похож на обычный deflate - умеренно хорошо подходит для любых избыточных потоков.

Отсюда уже можно сделать все выводы данной статьи, но по другим соображениям :) Плюс есть всякие хитрозадые опции хранения типа sparse columns, column sets, columnstore indexes и другие. Плюс есть еще соображения разницы между Standard/Enterprise.

И есть еще куча граничных случаев. Так, например "таблица-лог" с большими сообщениями не будет нормально сжиматься ни rows, ни page, зато может в десяток раз сжаться в бэкапе. Таблица с большим количеством низкоселективных ссылочных полей будет отлично жаться в page, зато потом плохо в бэкапе. А может для конкретно случая лучше подойдёт columnstore.

Так что всё равно придётся смотреть по месту, экспериментировать и замерять.

Может быть закрывать лучше в обратном порядке?

Модальное окно редактирования ХП с пропорциональным шрифтом по умолчанию... Слеза ностальгии :)

Наличие рабочего экземпляра не отменяет того, что были эти и некоторые другие серии HDD, которые были хуже или сопоставимы с критерием "каждый 10 в первый же год на мусорку", упомянутым в комментарии, на который я ответил.
Поэтому я могу сделать только вывод, что у вас есть старый IBM DTLA, а у меня есть старый Seagate Constellation ES :)

C HDD я такого не припомню.

А у меня до сих пор лежит мёртвый DTLA для напоминания. И Seagate ES 1ТБ из "той самой" серии (которая была с косячной прошивкой) есть - он сдох, но был восстановлен.

Сам по себе CXPACKET не является проблемой. По факту это практически только индикатор параллельного выполнения: при параллельном плане почти всегда будет часть веток, которые выполнились быстрее, часть - медленно, поэтому SQL Server часть времени проведёт в CXPACKET. Хорошее объяснение есть тут. Бороться с CXPACKET как таковым обычно не нужно.
С параллельными планами запросов проблемы другие

  1. В распараллеливание отдаётся план до прохождения всех оптимизаций. Чаще всего это очень неэффективный план. И получаются весы: с одной стороны n ядер, но план с с лишними сканами и неэффективными соединениями, с другой - лишние m миллисекунд на оптимизацию и может быть план с нормальными поисками и соединениями.

  2. Очень низкая граница на распараллеливание. 5 "попугаев" - это "как бы 5 секунд на компьютере 2000 года", причём планировщик запросов редко попадает точно в кост, чем бы он ни был. Для 1С я эмпирически пришёл к тому, что Cost Threshold for Parallelism стоит ставить от 100 до 5000 примерно. Так жирные отчеты пойдут параллелиться, а в проведении SQL будет лучше оптимизировать.

  3. (И это упомянуто в статье) По умолчанию параллелизм съедает все ядра. Ну так MS уже лет 10 (как появились сервера с 64 потоками) советует для многоядерных CPU ставить макс. параллельность 8, если нет особых обстоятельств. Ну от себя могу добавить, что какие-то операции, явно сканирующие большие талицы, можно вручную указывать OPTION MAXDOP по максимуму. В том числе, например, построение статистики и перестроение индексов.

1C работает не с уровнем snapshot isolation, а read committed snapshot isolation (RCSI).

То, что компания и сотрудник не сработались - такое бывает. При этом почти всегда и представители компании и сотрудник считают, что неправа другая сторона, но обычно это всё свидетельство ошибок со стороны менеджмента. Причём ошибок, которые лечатся не размытыми "тщательнее отбирать" и "глубже погружать", а вполне стандартными решениями.
Если для вас этот проект ограничен по времени и имеет чёткую цель, то почему у вас сотрудник на обычном бессрочном договоре без рычага в виде существенной премии по итогам? Стандартно это же решается, например, одним из следующих способов:

  • Срочный договор с большим бонусом в конце (по чёткому критерию)

  • Бессрочный договор с существенными премиями от результата

  • Договор ГПХ, если задача "под ключ" - но здесь надо сторить работу не как с сотрудником, а как с подрядчиком

  • Привлечение сотрудника как аутстафф (да, дороже, но геморрой не ваш)

  • Решение задачи через аутсорс (но надо быть готовым, что на той стороне не согласятся с тем, что вы не приняли работу - договор, задание и документальное оформление должны быть достаточно чёткими для спора в суде).

Ну и есть еще миллион способов подстелить соломки. Если заранее не побеспокоились, то разойтись на "по соглашению, 2 оклада и отпускные" обычно самое дешёвое и быстрое решение. Внезапные "аттестации" одного сотрудника после угроз и хамства в переписке могут выйти дороже (тут, конечно, лотерея, но я не уверен, что такой "гэмблинг" оправдан).

Все аргументы что "отношения с заказчиком испорчены" и "9 месяцев и 7 млн потрачено"- это, извините, почти всегда проблемы менеджмента работодателя, а не рядового сотрудника, если в трудовом договоре не было аккуратно и юридически допустимо прописано иное - я лично такого не встречал, это сложно. Где был менеджмент эти 9 месяцев? Это же, блин, просто "чистосердечное признание" некомпетентности менеджера.

При этом я не говорю, что сотрудник - ангелочек с крылышками, тут всякое бывает. Но в ваших "вместо выводах" лично я не увидел реальных способов предотвратить повторение таких ситуаций.

Поверьте, ваша милость, то, что там виднеется, - вовсе не великаны, а ветряные мельницы, а то, что вы принимаете за руки, - это крылья, которые кружатся от ветра и вращают жернова.

В целом автор, конечно, молодец, но по поводу эффективности данной деятельности мне пришла в голову цитата Сервантеса.

У вас в первом комментарии было (ну или по крайней мере мне кажется что было) два независимых утверждения: первое про ГК РФ и Йохансен (если я правильно понимаю, то речь про Scarlett Johansson, т.е. правильнее было бы написать её фамилию как Йоханссон), и второе - про то, что суды в РФ часто не руководствуются законом.
Второе утверждение Сергей @Milfgard никак не прокомментировал, а с первым не согласился и спросил ваше мнение как "практикующего юриста" - это словосочетание взято из вашего первого комментария. Во втором комментарии вы, воспользовавшись отсылкой к этому же словосочетанию "практикующий юрист" ответили развитием второго тезиса из первого комментария, но проигнорировали вопрос о первом.

Information

Rating
2,818-th
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity