А если numpy или подобные либы есть, то можно не класс создавать, а матрицей прикинуться:
import numpy as np
def magic(x: int, y: int, z: int) -> int:
a = 10000000000000000000000
b = 20000000000000000000000
c = 30000000000000000000000
return a * x + b * y + c * z
X = np.array([[1, 0, 0]])
Y = np.array([[0, 1, 0]])
Z = np.array([[0, 0, 1]])
print(magic(X, Y, Z))
Ну это не так. Мне даже коммент на хабре проще на ПК писать, потому что тут клавиатура есть. Вот на днях жена кучку заявлений на госуслугах и mos.ru делала - тоже через ноутбук, а не планшетотелефон. Мой отец (72 года) фотографии редактирует и печатает на ПК. Чёрт, да даже старший сын ютуб смотрит на ПК, потому что с плагином в браузере можно скорость выше 2 ставить.
Подход с GG и пробными запросами понятен - это очень разумный подход, но я всё равно не смогу поверить, что все баги чинились незаметно. Мне при обсуждениях переезда с СУБД на другую на лету всегда вспоминается очень старый ролик EDS "Airplane". Спасибо за подробную статью.
Во-первых, не приплетайте здесь парадокс Рассела, он ни чём, а во-вторых, у меня другие формулировки. Усложнить систему, т.е. сделать сложной, то есть состоящей из большого числа элементов и связей, причём скорее всего с циклами обратной связи, т.е. нелинейной - просто. "Просто" в данном случае больше отражает объём усилий. Про то что сделать систему простой, т.е. выделить только существенные элементы и взаимосвязи, написано не "сложно", а "нужно приложить усилия". Сама такая деятельность, как правильно заметил @Ndochp не является системой, к ней не применима метрика сложности системы.
Сжатие на уровне строк полезно по факту только если много числовых (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 :)
А у меня до сих пор лежит мёртвый DTLA для напоминания. И Seagate ES 1ТБ из "той самой" серии (которая была с косячной прошивкой) есть - он сдох, но был восстановлен.
Сам по себе CXPACKET не является проблемой. По факту это практически только индикатор параллельного выполнения: при параллельном плане почти всегда будет часть веток, которые выполнились быстрее, часть - медленно, поэтому SQL Server часть времени проведёт в CXPACKET. Хорошее объяснение есть тут. Бороться с CXPACKET как таковым обычно не нужно. С параллельными планами запросов проблемы другие
В распараллеливание отдаётся план до прохождения всех оптимизаций. Чаще всего это очень неэффективный план. И получаются весы: с одной стороны n ядер, но план с с лишними сканами и неэффективными соединениями, с другой - лишние m миллисекунд на оптимизацию и может быть план с нормальными поисками и соединениями.
Очень низкая граница на распараллеливание. 5 "попугаев" - это "как бы 5 секунд на компьютере 2000 года", причём планировщик запросов редко попадает точно в кост, чем бы он ни был. Для 1С я эмпирически пришёл к тому, что Cost Threshold for Parallelism стоит ставить от 100 до 5000 примерно. Так жирные отчеты пойдут параллелиться, а в проведении SQL будет лучше оптимизировать.
(И это упомянуто в статье) По умолчанию параллелизм съедает все ядра. Ну так MS уже лет 10 (как появились сервера с 64 потоками) советует для многоядерных CPU ставить макс. параллельность 8, если нет особых обстоятельств. Ну от себя могу добавить, что какие-то операции, явно сканирующие большие талицы, можно вручную указывать OPTION MAXDOP по максимуму. В том числе, например, построение статистики и перестроение индексов.
А если
numpyили подобные либы есть, то можно не класс создавать, а матрицей прикинуться:На скорости 2,5-3 чаще всего какой-нибудь длинный видос про майнкрафт. Учебный материал 1,5-2.
Ну это не так. Мне даже коммент на хабре проще на ПК писать, потому что тут клавиатура есть. Вот на днях жена кучку заявлений на госуслугах и mos.ru делала - тоже через ноутбук, а не планшетотелефон. Мой отец (72 года) фотографии редактирует и печатает на ПК. Чёрт, да даже старший сын ютуб смотрит на ПК, потому что с плагином в браузере можно скорость выше 2 ставить.
Подход с GG и пробными запросами понятен - это очень разумный подход, но я всё равно не смогу поверить, что все баги чинились незаметно. Мне при обсуждениях переезда с СУБД на другую на лету всегда вспоминается очень старый ролик EDS "Airplane".
Спасибо за подробную статью.
Ха-ха. Вам показалось :)
Список - вся "внутренность", накопленная за ~25 лет.
Ну да, ну да. Сначала "дай носик отсканировать", а потом всё это превращается в "почему в jira время не оттрекано".
Пока приложение однопоточное - может быть. Как только приложение многопоточное - появляются весьма интересные способы выстрелить себе в ногу.
Так есть шанс депремировать каждый квартал новую команду.
Во-первых, не приплетайте здесь парадокс Рассела, он ни чём, а во-вторых, у меня другие формулировки.
Усложнить систему, т.е. сделать сложной, то есть состоящей из большого числа элементов и связей, причём скорее всего с циклами обратной связи, т.е. нелинейной - просто. "Просто" в данном случае больше отражает объём усилий.
Про то что сделать систему простой, т.е. выделить только существенные элементы и взаимосвязи, написано не "сложно", а "нужно приложить усилия". Сама такая деятельность, как правильно заметил @Ndochp не является системой, к ней не применима метрика сложности системы.
Усложнить систему - просто. А сделать простой - нужно приложить усилия.
Эх, были же времена, когда это считалось хорошей рабочей станцией! :)
И для 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 :)
А у меня до сих пор лежит мёртвый DTLA для напоминания. И Seagate ES 1ТБ из "той самой" серии (которая была с косячной прошивкой) есть - он сдох, но был восстановлен.
Сам по себе CXPACKET не является проблемой. По факту это практически только индикатор параллельного выполнения: при параллельном плане почти всегда будет часть веток, которые выполнились быстрее, часть - медленно, поэтому SQL Server часть времени проведёт в CXPACKET. Хорошее объяснение есть тут. Бороться с CXPACKET как таковым обычно не нужно.
С параллельными планами запросов проблемы другие
В распараллеливание отдаётся план до прохождения всех оптимизаций. Чаще всего это очень неэффективный план. И получаются весы: с одной стороны n ядер, но план с с лишними сканами и неэффективными соединениями, с другой - лишние m миллисекунд на оптимизацию и может быть план с нормальными поисками и соединениями.
Очень низкая граница на распараллеливание. 5 "попугаев" - это "как бы 5 секунд на компьютере 2000 года", причём планировщик запросов редко попадает точно в кост, чем бы он ни был. Для 1С я эмпирически пришёл к тому, что Cost Threshold for Parallelism стоит ставить от 100 до 5000 примерно. Так жирные отчеты пойдут параллелиться, а в проведении SQL будет лучше оптимизировать.
(И это упомянуто в статье) По умолчанию параллелизм съедает все ядра. Ну так MS уже лет 10 (как появились сервера с 64 потоками) советует для многоядерных CPU ставить макс. параллельность 8, если нет особых обстоятельств. Ну от себя могу добавить, что какие-то операции, явно сканирующие большие талицы, можно вручную указывать OPTION MAXDOP по максимуму. В том числе, например, построение статистики и перестроение индексов.
1C работает не с уровнем snapshot isolation, а read committed snapshot isolation (RCSI).