Suppose you have a batch processing job which runs daily from midnight till it gets complete to perform some operations on a table which has one index defined in it.If you are certain that not many users will query the table during night,then in that case,you can make the index UNUSABLE and let the job completes which will be faster because no index maintenance need to be done in the background.Post job completion, you can REBUILD the index to make the index USABLE.
Автор обосновывает партиционирование именно ускорением удаления: "Все это дело ускоряет DELETE ". А это с точностью до наоборот. Если нет других причин, то зачем городить партиционирование? Оно имеет как плюсы, так и минусы, поэтому должны быть явные причины. Просто потому что "много записей" - это еще не аргумент.
Допустим мы используем партиционирование по дате для таблиц которые по сути своей являются логами. То есть данные в них имеют ценность ограниченное время и не имеют на себя ссылок в виде внешних ключей. Партиционирование позволяет дешево очищать логи за прошлые периоды, так как drop партиции целиком гораздо дешевле, чем удаление всех записей в таблице или партиции. Это я сейчас про Oracle, может в Postgres свои особенности.
В OLAP-базах можно использовать партиционирование для оптимизации запросов. Но в примере автора юзер-заказ имеется ввиду OLTP система. Там партиционирование для оптимизации запросов реже бывает полезно, так как запросы в основном идут по юзеру, по заказу, а не по дате за большой период (месяцы). А по дате за малый период (день) индекс по дате будет эффективнее.
Использование партиции как раз замедлит удаление, потому что приводит к копированию записи в новую партицию и удалению записи из старой партиции. С точки зрения скорости запроса с join, у которой ведущая таблица users, никакого улучшения не будет (если в плане используется доступ nested loops). То есть для данного конкретного отчёта из примера партиционирование вредно.
Плюс ошибки с пониманием работы inner join и оперативности обновления matview, на которые уже указали выше.
И в конце предложение кого-то чему-то научить на открытых уроках. Может стоит самим вернуться к RTFM?
А секунды от какого до какого события? Чтобы сделать пивот или антипивот, по идее надо отфетчить все записи. А для javascript время у вас в единицах секунд для миллиона записей. Я не представляю, как можно отфетчить миллион записей за секунду.
Мне плевать на авторитеты. Тем более в цитате Пайка приветствуется ясность, а автор выдаёт ее за краткость.
Что такое nw и ew сам не догадался.
Го с его обработкой ошибок через err совсем не лаконичен, а наоборот.
Детализация может казаться излишней писателю, так как для него всё очевидно. Но никто не знает, во что этот код разрастется с годами, и кто его будет читать и поддерживать. И там станет всё совсем не так очевидно.
Стадартные сокращения типа err и ctx надо соблюдать, но даже в указанном примере вместо errWrite сделали ew и сразу стало непонятно. Если это стандарт в модуле, и встрчается многократно с этим можно жить. Но если сокращения бессистемные или неоднозначные, это ужас. Например переменная c может одначать и char и count и client и черта лысого.
Поэтому уважайте тех кто придёт за вами, и не жалейте буковок для названий переменных.
Как читать такой код? Как, читая чужой код, узнать, какая из нескольких существующих реализаций интерфейса будет вызвана в рантайме?
Если в ЯП реализация не указывает явно реализуемый интерфейс (как в go), то без специальных средств в ide просто невозможно получить список методов-реализаций, которые могут вызываться через метод интерфейса. А это есть далеко не во всех IDE, и ни в каких текстовых редакторах.
Если в ЯП реализация явно ссылается на интерфейс, описанный в другом (вызывающем) модуле, то эту реализацию невозможнопереиспользовать в другом проекте, не затащив туда вызывающий модуль (а он там не нужен).
Грустная новость. Фоксфорд был хорош. Помог ребенку олимпиады затащить и поступить в МГУ на бюджет, при этом очень бюджетно. И сервис вполне на уровне был. А теперь чую "пропал дом"...
Обычно ресурсы опытных разрабов, способных провести ревью, стоят значительно дороже тестеров. Поэтому логично ревью проводить после QA, чтобы не тратить время ревьюеров на выявление багов.
Но если делать ревью после QA, то в процессе ревью возникает необходимость корректировок, и нужно снова отдавать задачу тестерам.
Проведение кодревью и ведение документации существенно влияют на сроки софтверных проектов, поэтому обсуждать это на 6 этапе, после оценки (5 этап) - прямой путь к срыву сроков.
У нас вообще прикольно сделали. У каждого проекта свои несихронизированные спринты. Команда разработки участвует в нескольких проектах, то есть у команды сразу несколько спринтов. Как в таких условиях живется команде, менеджеров не волнует. У них-то всё по феншую.
– Вы стоите на самой низшей ступени развития, – перекричал Филипп Филиппович, – вы ещё только формирующееся, слабое в умственном отношении существо, все ваши поступки чисто звериные, и вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие-то советы космического масштаба и космической же глупости о том, как всё поделить… А в то же время вы наглотались зубного порошку…
Из 1992
Оболочка
Сидят как-то Диггер, командир Нортон и т. Комманд Ком, а
мимо идет отец Вындоуз. "Сидите, - говорит. - Ну, ну. Скоро все
подо мной сидеть будете". Никто ему так ничего и не ответил.
Один т. Комманд Ком сплюнул и грязно выругался. "Проходи,
проходи, - сказал, - оболочка дешевая".
Иконы
Весь день т. Комманд Ком ходил просветленный. А встретив
грустного отца Вындоуза, даже поинтересовался ласково: - Или
случилось что, батюшка? - Все иконы украли, - сказал отец
Вындоуз и заплакал. - Ах они нехристи, - утешал т. Комманд Ком,
- ах они оболочки дешевые! И усы его весело шевелились.
Мыши
Диггер спросил как-то т. Комманда Кома: "За что же, Вы,
т. Комманд Ком, отца Вындоуза так не любите?". "Мышами от него
воняет", - быстро ответил тот.
Ну так далее https://lib.ru/ANEKDOTY/pritchi.txt
Suppose you have a batch processing job which runs daily from midnight till it gets complete to perform some operations on a table which has one index defined in it.If you are certain that not many users will query the table during night,then in that case,you can make the index UNUSABLE and let the job completes which will be faster because no index maintenance need to be done in the background.Post job completion, you can REBUILD the index to make the index USABLE.
https://www.oraclemasterpiece.com/2020/11/understanding-unusable-index/
Автор обосновывает партиционирование именно ускорением удаления: "Все это дело ускоряет
DELETE". А это с точностью до наоборот. Если нет других причин, то зачем городить партиционирование? Оно имеет как плюсы, так и минусы, поэтому должны быть явные причины. Просто потому что "много записей" - это еще не аргумент.Допустим мы используем партиционирование по дате для таблиц которые по сути своей являются логами. То есть данные в них имеют ценность ограниченное время и не имеют на себя ссылок в виде внешних ключей. Партиционирование позволяет дешево очищать логи за прошлые периоды, так как drop партиции целиком гораздо дешевле, чем удаление всех записей в таблице или партиции. Это я сейчас про Oracle, может в Postgres свои особенности.
В OLAP-базах можно использовать партиционирование для оптимизации запросов. Но в примере автора юзер-заказ имеется ввиду OLTP система. Там партиционирование для оптимизации запросов реже бывает полезно, так как запросы в основном идут по юзеру, по заказу, а не по дате за большой период (месяцы). А по дате за малый период (день) индекс по дате будет эффективнее.
Использование партиции как раз замедлит удаление, потому что приводит к копированию записи в новую партицию и удалению записи из старой партиции. С точки зрения скорости запроса с join, у которой ведущая таблица users, никакого улучшения не будет (если в плане используется доступ nested loops). То есть для данного конкретного отчёта из примера партиционирование вредно.
Плюс ошибки с пониманием работы inner join и оперативности обновления matview, на которые уже указали выше.
И в конце предложение кого-то чему-то научить на открытых уроках. Может стоит самим вернуться к RTFM?
А секунды от какого до какого события? Чтобы сделать пивот или антипивот, по идее надо отфетчить все записи. А для javascript время у вас в единицах секунд для миллиона записей. Я не представляю, как можно отфетчить миллион записей за секунду.
В таблице производительности вертикальная шкала в каких единицах?
А разве нельзя получить у органов США уточнение о наличии сим-карты среди конфискованных вещ.доков?
Мне плевать на авторитеты. Тем более в цитате Пайка приветствуется ясность, а автор выдаёт ее за краткость.
Что такое nw и ew сам не догадался.
Го с его обработкой ошибок через err совсем не лаконичен, а наоборот.
Детализация может казаться излишней писателю, так как для него всё очевидно. Но никто не знает, во что этот код разрастется с годами, и кто его будет читать и поддерживать. И там станет всё совсем не так очевидно.
Стадартные сокращения типа err и ctx надо соблюдать, но даже в указанном примере вместо errWrite сделали ew и сразу стало непонятно. Если это стандарт в модуле, и встрчается многократно с этим можно жить. Но если сокращения бессистемные или неоднозначные, это ужас. Например переменная c может одначать и char и count и client и черта лысого.
Поэтому уважайте тех кто придёт за вами, и не жалейте буковок для названий переменных.
Как читать такой код? Как, читая чужой код, узнать, какая из нескольких существующих реализаций интерфейса будет вызвана в рантайме?
Если в ЯП реализация не указывает явно реализуемый интерфейс (как в go), то без специальных средств в ide просто невозможно получить список методов-реализаций, которые могут вызываться через метод интерфейса. А это есть далеко не во всех IDE, и ни в каких текстовых редакторах.
Если в ЯП реализация явно ссылается на интерфейс, описанный в другом (вызывающем) модуле, то эту реализацию невозможнопереиспользовать в другом проекте, не затащив туда вызывающий модуль (а он там не нужен).
Недостатки концепции DIP мне очевидны.
А какие она даёт преимущества?
Грустная новость. Фоксфорд был хорош. Помог ребенку олимпиады затащить и поступить в МГУ на бюджет, при этом очень бюджетно. И сервис вполне на уровне был. А теперь чую "пропал дом"...
Обычно ресурсы опытных разрабов, способных провести ревью, стоят значительно дороже тестеров. Поэтому логично ревью проводить после QA, чтобы не тратить время ревьюеров на выявление багов.
Но если делать ревью после QA, то в процессе ревью возникает необходимость корректировок, и нужно снова отдавать задачу тестерам.
Как правильно организовать процесс?
Проведение кодревью и ведение документации существенно влияют на сроки софтверных проектов, поэтому обсуждать это на 6 этапе, после оценки (5 этап) - прямой путь к срыву сроков.
В остальном отличная статья
У нас вообще прикольно сделали. У каждого проекта свои несихронизированные спринты. Команда разработки участвует в нескольких проектах, то есть у команды сразу несколько спринтов. Как в таких условиях живется команде, менеджеров не волнует. У них-то всё по феншую.
Я быстро догадался, что это ульи, которые передают новому хозяину. Про королеву и траур даже мысли не было. В ЧГК поигрываю ингода.
Отключат openai, неизбежно...
Так уже давно весь бекенд-софт живет в виртуалках, контейнерах и пр. На практике получается атомики - малополезная вещь...
– Вы стоите на самой низшей ступени развития, – перекричал Филипп Филиппович, – вы ещё только формирующееся, слабое в умственном отношении существо, все ваши поступки чисто звериные, и вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие-то советы космического масштаба и космической же глупости о том, как всё поделить… А в то же время вы наглотались зубного порошку…
Там в оригинале вода, к переводу-то и претензий нет.
На редкость бессвязный текст. Не просто вода, незамутненная бессмыслица.
Один бекдор случайно нашли, а тысячи других по-прежнему ждут своего часа.