Идея этой статьи с сантехническим уклоном у меня возникла после просмотра в Ютубе видеоролика о монтаже нового секционного биметаллического радиатора при замене старого отопительного прибора типа «гармошка» в старой однотрубной системе отопления, которую с советских времён применяют в подавляющем количестве панельных домов.

В этом видосике сошлись в смертельной схватке два «блогера‑сантехника», каждый из которых считал, что только он прав.

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

Своё видение решения я описал в комментариях к видеоролику, но ответа не получил. В итоге решил написать эту статью для прояснения сути проблемы широкой массе жителей панельных домов.

Особый интерес к этой теме у меня возник потому, что я сам лично как‑то собрался поменять такую старую облезлую «гармошку» (см.рис.1) на новый белый и красивы биметаллический радиатор (см.рис.2).

Привет Хабр! Возможно тема возврата денежных средств за приобретенный товар поднималась и ранее, но положения законодательных актов и судебные позиции склонны со временем меняться. Решил для читателей собрать в одном месте все правовые нормы, разложить по полочкам права покупателя и обязанности продавца, а также объяснить с точки зрения законодательства процесс осуществления возврата денежных средств за технически сложный товар. И заодно раз и навсегда ответить на вопрос, почему в случае обнаружение неисправности устройства надо всегда фиксировать все совершенные действия.

Рассмотрим следующий пример:

CREATE TABLE T (PK INT PRIMARY KEY, A INT, B INT)
CREATE INDEX TA ON T(A)
CREATE UNIQUE INDEX TB ON T(B)
INSERT T VALUES (0, 0, 0)
INSERT T VALUES (1, 1, 1)

Теперь предположим, что мы выполним обновление:

UPDATE T SET A = 1 – A

Это изменение влияет на кластерный индекс (PK__T__15502E78) и на некластерный индекс TA. План в значительной степени такой, какой мы ожидали:

  _{|--Clustered Index Update(OBJECT:([T].[PK__T__15502E78]), OBJECT:([T].[TA]), SET:([T].[A] = [Expr1003]))
       |--Compute Scalar(DEFINE:([Expr1016]=[Expr1016]))
            |--Compute Scalar(DEFINE:([Expr1016]=CASE WHEN [Expr1004] THEN (1) ELSE (0) END))
                 |--Compute Scalar(DEFINE:([Expr1003]=(1)-[T].[A], [Expr1004]=CASE WHEN [T].[A] = ((1)-[T].[A]) THEN (1) ELSE (0) END))
                      |--Top(ROWCOUNT est 0)
                           |--Clustered Index Scan(OBJECT:([T].[PK__T__15502E78]))}

Это типичный «узкий» план обновления. В одном операторе обновления затрагиваются кластерный и некластерный индексы. План содержит Compute Scalar, которые определяют, нужно ли изменять соответствующую строку некластерного индекса. О подобных планах я писал в этой статье.

_{Оперативно узнавать о новостях MS SQL Server можно в телеграмм-канале: MS SQL Server - дело тонкое...}

Это выдержка из восьмой главы книги Rodney Landrum: «SQL Server Tacklebox», в которой описывается, как DBA может устранить последствия повреждения данных. Будут продемонстрированы инструменты и сценарии, необходимые для своевременного поиска и устранения повреждений данных и предотвращения их попадания в резервные копии.

Продолжаем делиться конспектами Алексея Барабанова, IT-директора «Хлебницы». На этот раз обсудим специфику работы RabbitMQ с высокими нагрузками (High Load) и обеспечением высокой доступности (High Availability). Рассмотрим различные методы увеличения производительности и горизонтального масштабирования, разберём и настроим внутренние инструменты. Также по мере погружения постараемся изучить основные подводные камни всех подходов.

В этой статье мы разберём несколько аномальных случаев высокой нагрузки в СУБД PostgreSQL. Что это такое? Обычно PostgreSQL хорошо показывает себя под нагрузкой и оправдывает ожидания в отношении производительности — она остаётся высокой. Но при определённых профилях нагрузки СУБД может вести себя не так, как мы ожидаем. Это и есть аномалии, на которых мы сосредоточимся в данной статье (для тех, кто предпочитает видео, эта информация доступна в виде записи доклада на HighLoad++).

Наша компания помогает обслуживать мультитерабайтные базы данных в крупных проектах, поэтому мой рассказ об аномалиях основан на реальном опыте промышленной эксплуатации СУБД в Postgres Professional — порой мы сталкиваемся с тем, что СУБД ведёт себя не так, как мы ожидали.

Также в рамках статьи мы рассмотрим следующее:

Приветствую!

В прошлой статье была исследована входная точка бэкэнда до главного цикла. В этой статье закончим ее обзор исследованием главного цикла.

Кроме нее будут рассмотрены:

— Модуль для работы с транзакциями.

— Исключения в С и их реализацию.

— Клиент‑серверный протокол.

В этом номере самое интересное за январь начало февраля 2023. В том числе, конечно, о релизах

PostgreSQL 15.2 и Postgres Pro Enterprise 15.1.1

К моим словам прошу относиться со здоровой долей скепсиса, ибо я не нейтив-спикер, а просто ИТшный переводчик-редактор (пусть даже и с 20-летним опытом).

В последние полгода англо-русские переводы по понятным причинам практически исчезли, и по работе на проверку приходят в основном русско-английские, зачастую на «рунглише». Отмечу, что «рунглишевые» ошибки в присылаемых материалах более или менее однотипные, поэтому я и предположил, что коллегам может быть полезно, если эти ошибки кто-то разложит по полкам.

Эту памятку или «дорожную карту» я опубликовал в своем телеграм-канале несколько месяцев назад, многократно её обкатал на проектах, и убедился в ее применимости — поэтому вешаю ниже.

Шагов в этой памятке 5:

Меня зовут Василий, и уже больше пяти лет я причиняю DevOps в хранилищах. Последние полтора года руковожу группой автоматизации хранилищ данных в Почтатехе. 

В нашем data warehouse 6,5 петабайт активных данных. Вы и сами можете представить масштабы, когда речь идет о Почте России: работа сайта и приложения, логистика, трейсинг посылок и даже строительство сортировочных центров основываются на данных нашего хранилища. 

Я расскажу, как мы применяем DevOps-практики на таких объемах DWH и как внедрить подобное у себя.

Это объект Pizza, там хранится инфа о латте, а заказали его в Restaurant или в Pizzeria? Неудобно? Максимально. Мы читаем код существенно больше, чем пишем. И хочется сразу понимать, что происходит, не играя в квесты «что имел в виду автор», «да как это работает» и «я снова ничего не понял». Без навыка давать хороший нейминг невозможно писать качественный и поддерживаемый код. Про нейминг говорят заодно, в рамках архитектуры и общих инженерных практик. В статье поговорим про него отдельно.

Как получается, что код становится мало понятным даже для его авторов? Почему нейминг так важен? Как придумывать названия, не применяя целые теории нейминга? Как лёгким процессом организовать работу с неймингом в команде? На все эти вопросы мы ответим в статье.

Всем привет :) 

Меня зовут Голов Николай, я строю платформу данных на основе Snowflake и Anchor Modeling в ManyChat.

В этой статье я уже подробно рассказывал, как решал аналогичную задачу  в Авито, используя Vertica и методологию Anchor Modeling. В комментариях меня спрашивали, с какими сложностями приходится сталкиваться при использовании этой модели, поэтому сегодня я решил поговорить именно о них и заодно поделиться решением, к которому мы пришли.

Приветствую!

На прошлом шаге мы дошли до входной точки Postgres. Сегодня мы пройдемся по ней до главного цикла. Будут рассмотрены:

— Модули для работы с файлами и файловой системой

— Как SIGUSR1передает множественные значения

— Реализации хэш‑таблиц

— Представление и хранение GUC

и многое другое.

В первой части статьи мы обсуждали разработку самого нижнего слоя СУБД Boson - CachedFileIO. Как упоминалось, статистика такого явления как Locality of Reference говорит о том, что в реальных приложениях ~95% запросов к данным локализованы в 10-15% базы данных. При этом среднее соотношение чтения/записи - 70%/30%. Это делает эффективным использование кэша (cache) работающего на основе алгоритма Least Recently Used (LRU). Реализовав его, мы получили 260%-600% прироста скорости чтения при 87%-97% cache hits.

Следующим после кэша слоем СУБД Boson является хранилище записей RecordFileIO. Это уже первый прообраз базы данных, который начинает приносить прикладную пользу. Сформулируем верхнеуровневую спецификацию требований:

Или максимы Английского языка, которые бы я хотел знать 20 лет назад.

Чем отличается хороший геймер от плохого? Хороший геймер сидит и изучает игру. Он знает каждый закуток. Он может без запинки назвать все характеристики всех юнитов в Star Craft. А самый крутой игрок знает все пропускные способности желтых, красных и синих конвейеров. А плохой игрок использует чит-коды или assistant apps. 

Можно сколько угодно сидеть и жаловаться о том, что правила сложны. А можно просто взять, изучить эти правила и уделать наисложнейшую игру.

Я не раз в своей жизни слышал, что Английский чрезвычайно сложен. Подобные заявления фактически являются чит-кодом. Вы просто сдаётесь и перестаёте пытаться. А зря. В английском языке есть очень много полезных и понятных вещей. 

В этой статье я хочу вам показать основные моменты, которые помогли мне хорошо овладеть языком. И надеюсь, что понимание этих моментов поможет и вам. 

Участвую в стартапе, в котором разрабатывается СУБД нового типа (работает поверх некоторых kv-движков, кардинально расширяя их возможности, про это немного можно прочитать здесь). Для того, чтобы сравнить то, что понемногу получается, с тем, что имеется в индустрии, пришлось на глубоком уровне проработать первоисточники по темам Isolation и Consistency (уточню, что имеется ввиду не та Consistency, что в ACID). Обнаружил интересные нюансы, которые и излагаю в этой статье.

Тезисно:

• Термин Phantom Read является продуктом испорченного телефона
• Смысл понятий Lost Update, Write Skew и Read Skew для разделения уровней изоляций неочевиден и относителен
• Движок, который обеспечивает уровень изоляции Serializable, в распределённом мире может вести себя весьма причудливо, например, всегда возвращать пустой результат для read-only транзакций — и ему за это по стандарту "ничего не будет"
• Strong consistency в Cosmos DB — предел мечтаний? (спойлер: нет)

Ну, и ещё кое-что по мелочи. В конце рассмотрим вот такой венец творения человеческого разума:

Эта статья описывает реализацию 64–битных счётчиков транзакций (XID, ксидов) в СУБД Postgres Pro Enterprise, которая создана на основе свободной, опенсорсной объектно–реляционной СУБД Postgres. Она ориентирована на тех, кто имеет практический опыт в работе с СУБД Postgres Pro Enterprise, но будет интересна и тем, кто интересуется развитием СУБД Postgres, так как описывает сравнение этих двух систем. Статья также описывает устройство таблиц на диске и организацию формата хранения данных отношений.

Postrges старается быть максимально гибким в конфигурации, чтобы удовлетворить запросы как можно большего числа своих пользователей. Большинство параметров, например, таких, как: размер страницы BLCKSZ (по умолчанию 8 кБ), размер сегмента SEGSIZE (по умолчанию 1 Гб), могут быть изменены при сборке Postgres.

Хотелось бы сразу обозначить, что мы будем рассматривать 64–битный вариант сборки Postrges, в котором все параметры имеют значение по умолчанию. Также мы не будем углубляться в мультитранзакции. Для целей этой статьи будет достаточным предположения, что они в данном контексте аналогичны "обычным" транзакциям.

Мы выложили наш вариант реализации в сообщество, а также занимаемся активным продвижением его в сообществе разработчиков Postgres. Он не на 100% идентичен коду, используемому в Postgres Pro Enterprise (в частности, там ксиды всё ещё образуют кольцо), но общая идея такая же, как изложена в статье. На текущий момент патч ожидает ревью. Мы верим, что этот патч положительно скажется на удобстве использования и устойчивости Postgres, надеемся, что он будет принят сообществом в ближайшем будущем. Тем не менее по этому вопросу предстоит ещё много работы. Поэтому мы будем благодарны всем желающим и небезразличным за посильное участие в его развитии.

Я люблю давать простые задачки студентам на лекции. Во-первых, понятно, скольких мы потеряли, во-вторых, это переключение из режима потребления информации в режим выдачи результатов, в третьих — возможность проявить себя для шустрых. Сплошные плюсы!

Одна из простых задач звучит так: «При переводе картинки из цветового пространства RGB в YUV мы выполняем прореживание, то есть выкидываем каждый четный столбец и каждую четную строку в компонентах U и V (все компоненты пикселя по 1 байту). Вопрос: во сколько раз меньше данных у нас стало?» Эта операция называется chroma subsampling и широко используется при сжатии видео, например.

Забавно, что когда-то давно, когда винчестеры были меньше, а дискеты больше, студенты реально отвечали на этот вопрос быстро. А в последние годы регулярно народ в ступор впадает. Приходится разбирать по частям: «Если выкинуть каждую четную строку и каждый четный столбец, во сколько раз меньше данных будет у компоненты?» Почти хором: «В четыре». Начинаю подкалывать: «Отлично! У нас было 3 яблока, первое осталось как есть, а от второго и третьего осталось по четвертинке. Во сколько раз меньше яблок у нас стало?» Народ ржет, но, наконец-то, дает правильный ответ (заметим, не все). 

Это было бы смешно, если бы от способности быстро в уме прикинуть результат не зависела способность быстрее создавать сложные алгоритмы. 

И хорошо видно, как эта способность в широких массах студентов заметно плавно падает. Причем не только в нашей стране. Придуман даже специальный термин: «цифровое слабоумие» ("digital dementia") — снижение когнитивных способностей, достаточно серьезное, чтобы повлиять на повседневную деятельность человека. 

Кому интересно как теряют мозг студенты масштабы бедствия и что с этим делать — добро пожаловать под кат!