Развитие артиллерии в Холодную войну настолько переплелось со всеми видами деятельности человека, что в двух словах не объяснишь. Сейчас артиллерия — это сплав механики, физики, химии, материаловедения, машиностроения и металлообработки и, конечно же, электроники. И начну я издалека, мы отправимся в далёкие годы, когда новейшие японские броненосцы отстрелялись гораздо лучше русских.

Если во время сражения в Жёлтом море наши броненосцы имели вполне себе нормальный процент попаданий, то в Цусиме эскадра, выдержавшая плавание аж через весь шарик, выдала почти в два раза худшую стрельбу, чем японцы. Но примечательно во всём этом было то, что точность стрельбы оказалась крайне низкой, а дистанции, с которых открывали огонь, перескочили отметку в 6 км (броненосец «Asahi» открыл огонь с 7 км, «Mikasa» — с 6,4 км), тогда как те же хозяева морей англичане старались не стрелять дальше 2,5-3 км. Это привело к огромному расходу боезапаса (маячил неиллюзорный шанс, что в сражении мог закончиться БК) и невысокой точности стрельбы. Дальномеры Barr&Stroud FA3, стоявшие на кораблях противоборствующих эскадр, были недостаточны для точной стрельбы на таких дистанциях, а ведь сами пушки били уже под 20 км.

Как заметил один неравнодушный читатель, математика – это «бред повернутых на абстракциях». Что ж, наверное, он прав, и все математики должны быть немного не в себе, чтобы, отказавшись от такой родной и очевидной реальности, посвятить свою жизнь формулам и графикам. Но если вы все же не «сломали голову на интегралах» и знаете, для чего нужно «минус одно яблоко» (и вообще понятие отрицательных чисел), то заваривайте чаëк и присаживайтесь.

Сегодня мы поговорим о том, что общего у береговой линии и барабанщика рок-группы, и как сэкономить на аниматорах, зная математику.

Привет, Хабр!

Сегодня мы прокачаем PostgreSQL, добавив в него Python. А именно — PL/Python. Это расширение позволяет писать функции на Python прямо внутри базы данных. Лично для меня это как объединение двух лучших миров: любимого PostgreSQL и могучего Python.

PL/Python — это про то, когда стандартного SQL мало. Когда надо сделать что-то действительно интересное: сложные расчеты, массивы данных, или интеграция с аналитикой прямо в базе. А самое крутое — можно тянуть любые Python-библиотеки.

Для начала нужно просто установить расширение в PostgreSQL.

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

Есть бесконечно висящий в воздухе вопрос — почему при наличии шикарного образования, желания достичь результата и реальных усилиях  по достижению результата, полученный личный результат может быть более чем скромным или он может быть, но уже совсем-совсем не ваш.

И наконец,  мемом начала примерно 2010 года стала на просторах интернета запись какого-то реального технического совещания, закончившегося воплями - «...Проср*ли все полимеры !!..»

Откуда все это?  Анекдоты рассказываются, вопли стихают… а далее  следует пустота и молчание..Есть некоторое табу молчания на углубление в  «механику» из шкурных интересов, которые создают проблемы и реинкарнируют их снова, снова и снова. 

Сегодняшняя тема посвящена нелегким взаимоотношениям клиентского приложения и сервера PostgreSQL: как на ровном месте, неудачной архитектурой приложения, можно обеспечить себе хронические проблемы производительности.

Рассмотрим классические ситуации, когда разработчики начинают жаловаться на производительность БД - а виновата-то и не она!

Процесс-зомби (zombie process) — дочерний процесс в Unix-системе, завершивший своё выполнение, но ещё присутствующий в списке процессов операционной системы, чтобы дать родительскому процессу считать код завершения. Обычно, когда процесс завершает выполнение и работу, операционная система собирает статус завершения дочернего процесса с помощью системных вызовов wait() или waitpid(), выполненные родительским процессом. Если родительский процесс не вызывает эти функции вовремя, информация о состоянии дочернего процесса не может быть удалена из ядра, что приводит к тому, что процесс остается в состоянии "зомби". Попытка удалить зомби-процесс с помощью kill -9 неэффективна, поскольку он не занимает ресурсов CPU или памяти, а лишь сохраняет номер процесса (PID) и небольшое количество информации о состоянии.

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

Вопрос о свободе воли – один из самых фундаментальных и сложных в философии. Под свободой воли обычно понимается способность человека делать осознанный выбор и принимать решения независимо от внешних обстоятельств или предопределенности. Это понятие лежит в основе наших представлений о моральной ответственности, личности и человеческом достоинстве.

В философии сформировались несколько основных позиций по этому вопросу: либертарианство, детерминизм, компатибилизм и жесткий инкомпатибилизм. Каждый из этих подходов основывается на своих предпосылках и гипотезах, предлагая различные интерпретации свободы воли.

Либертарианство утверждает полную свободу воли, постулируя, что люди способны делать выбор, не полностью обусловленный предшествующими причинами. Детерминизм, напротив, рассматривает все события, включая человеческие решения, как предопределенные предыдущими состояниями и законами природы. Компатибилизм пытается примирить идею свободы воли с детерминизмом, предлагая пересмотреть наше понимание свободы. Жесткий инкомпатибилизм идет еще дальше, отрицая свободу воли независимо от истинности детерминизма.

На мой взгляд, ключевыми аспектами в определении свободы воли являются две фундаментальные проблемы:

Недавно, на хабре вышла статья про один нюанс в оптимизаторе PostgreSQL [1]. Будучи предельно технической и скучной по-определению, она триггернула интересную дискуссию в комментах и дала мне, как разработчику систем баз данных, возможность взглянуть на систему с точки зрения разработчика приложений. Это оказалось крайне продуктивным и даже привело к патчу и треду в сообществе. Возможно, нам нужно больше таких небольших и узко-специализированных постов? Данная статья - попытка развить это направление.

[1] Странное поведение планировщика запросов PostgreSQL

Хабр, привет!

В этом материале будем настраивать кластер PostgreSQL с Patroni и etcd. Видели множество статей на эту тему, но наше отличие в том, что мы устанавливаем кластер в виртуальной среде, используя новые компоненты.

Немного теории. Patroni — это инструмент для управления высокодоступными кластерами PostgreSQL. Он упрощает настройку и управление репликацией благодаря автоматическому переключению на резервные узлы и восстановлению после сбоев.

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

Зачем мы это делаем?

Во-первых, интересно. Во-вторых, это нам позволит установить последние версии пакетов без открытого доступа в интернет с серверов. Во многих компаниях изолированная сетевая среда — поэтому вот вам памятка по такой задаче.:)

Итак, приступим.

Цель работы: на примере статистики регистрации фоновых космических частиц изучить статистические закономерности однородного во времени случайного процесса; проверить возможность описания исследуемого процесса статистическими законами Пуассона и Гаусса; измерить среднее число регистрируемых космических лучей в секунду и определить погрешность результата.

Оборудование: счётчик Гейгера—Мюллера, компьютер с интерфейсом для связи со счётчиком, расчётная программа.

Недавно попался на глаза запрос, которым хотели отобрать в таблице (очевидно, для последующего удаления) все id записей интервалов, которые полностью перекрыты каким-то другим интервалом того же owner'а.

Но self-JOIN показал себя не лучшим образом...

Данная статья посвящена описанию базы математической статистики.

Описывается суть матстатистики от постановки задачи до рассмотрения инструментов её решения.

Всем привет! A/B тестирование уже давно стало стандартом в проверке гипотез и улучшении продуктов в X5. Но, как ни странно, многие из «модных» техник, которые применяются в A/B тестировании, на самом деле, не что иное, как вариации старой доброй линейной регрессии. 

Основная идея здесь проста: правильное добавление новых переменных в модель помогает лучше контролировать внешние факторы и уменьшать шум в данных. Это позволяет точнее оценить эффект от воздействия и объединить разные статистические подходы, которые обычно рассматриваются отдельно. Но почему это работает? Почему всё сводится к тому, что добавление переменных помогает объединить, казалось бы, разрозненные техники? 

Чтобы разобраться в этом, для начала вспомним основы линейной регрессии, после чего перейдём к различным статистическим методам снижения дисперсии и покажем, как они сводятся к линейной регрессии. Затем объединим все техники вместе и на примере покажем, как они работают на практике.

С ростом объёмов данных и увеличением популярности распределённых систем необходимость в анализе распределённых данных становится всё более актуальной. PostgreSQL, благодаря своему мощному функционалу и гибкости, предлагает инструмент, который значительно облегчает эту задачу — Foreign Data Wrappers (FDW).

FDW позволяет подключаться к удалённым базам данных, как если бы они были локальными таблицами. Это удобно для аналитики, интеграции данных из различных источников и упрощает работу с распределёнными системами. FDW поддерживает не только PostgreSQL, но и другие базы данных, такие как MySQL, SQLite и даже API.

В мире управления базами данных от эффективного хранения больших объемов информации зависит оптимизация производительности и использования дискового пространства. В этой статье разберем основные методы сжатия данных в TOAST, их эволюцию, плюсы и минусы PGLZ и LZ4 и продемонстрируем базовую работу с TOAST в Postgres. В завершение обсудим, как данные с различными методами сжатия могут храниться в одной TOAST-таблице.

Некоторые головоломки можно решать на SQL just for fun, а часть получается выразить на этом декларативном языке даже эффективнее других, императивных.

Попробовать сделать более наглядное решение, а заодно познакомить с некоторыми нетривиальными возможностями PostgreSQL меня натолкнул пост о решении на Python задачи Black and White.

Повышение производительности PostgreSQL после настройки параметров

Меня зовут Антон Сорока, я математик и аналитик данных.

Я хотел бы рассказать об алгоритме, который выделяет кусочно-линейный тренд из временного ряда и сам определяет точки изменения тренда. Другими словами, это алгоритм для автоматического кусочно-линейного приближения любой функции. Это может понадобиться, если вам важно анализировать линейные тренды ряда, но единственная линия явно недостаточно точно описывает ряд, и самостоятельно искать точки, где тренд менялся, неудобно. Реализация этого алгоритма есть в open-source библиотеке для анализа изменений временных рядов, написанной на Python.

От редакции: Майкл Стоунбрейкер - один из самых известных в IT мире ученых и отец-основатель Postgres. В соавторстве с Энрю Павло, недавно опубликовал большой обзор всех актуальных технологий систем управления базами данных. В этом материале — подробно обо всем, что произошло в мире баз данных за последнее время, а также прогнозы. Мы посчитали что нельзя лишать нашу аудиторию возможности ознакомиться с этим обзором, поэтому подготовили данный перевод.