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

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

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

Компания Postgres Professional занимается разработкой и поддержкой СУБД с 2015 года. Это серьёзный срок для компании в ИТ-сфере, и за это время мы видели много случаев, когда клиенты сталкивались с неоптимальным выполнением запросов. Обычно оптимизатор PostgreSQL неплохо справляется и строит хорошие планы, если количества джойнов в запросе не больше 10 и данные в таблицах распределены равномерно. Однако в даже на изначально тщательно продуманной базе данных, оптимизатор может сгенерировать настолько неоптимальный план, что его время выполнения может увеличиться в разы. В некоторых особо экстремальных случаях даже практически невозможно дождаться окончания выполнения запроса и понять при помощи EXPLAIN ANALYZE, что пошло не так. Усугубляющим фактором является то, что оптимизатор PostgreSQL никак не запоминает допущенные ошибки выполнения. Построив неоптимальный план один раз, он с большей долей вероятности будет делать это снова и снова до тех пор, пока что-то не изменится: статистика, настройки оптимизатора или какое-то внутреннее состояние СУБД.

Другая не менее важная тенденция в области баз данных — уход в облака, где у DBA остается незначительный набор инструментов для исправления проблемных ситуаций и диагностики причин.

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

Однако все эти методы или имеют мало предсказуемый результат (AQO), или требуют глубокого понимания причин возникшей проблемы с ручной донастройкой СУБД. В своей новой разработке мы решили взглянуть на проблему исправления ошибок оптимизации с другой стороны. Основная идея в том, чтобы добавить возможность перепланирования на основе полезных сведений, которые можно получить из уже частично выполненного запроса. Помимо этого нужно сформулировать критерии для плохо спланированных запросов, для которых необходимо провести перепланирование.

В 2017 году я начал изучать Java. И, чтобы как-то визуализировать результат трудов, я решил сделать десктопное приложение (функционал продублирован в Telegram боте).

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

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

Привет!

Пока мы разрабатывали продукты по кибербезопасности, на нас самих напали мошенники. 

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

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

В начале рассказываем, откуда пришла новая схема телефонного мошенничества. Если хотите сразу услышать разговор Леши, листайте до раздела «Мошенник звонит из "правоохранительных органов" и напоминает об уголовной ответственности».

Этим постом я запускаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В программе: рассказ об основах SQL, возможностях простых и сложных SELECT, анализ производительности запросов, разбор [не]эффективного применения индексов и особенностей работы транзакций и блокировок в этой СУБД.

Курс не претендует на лавры "войти в айти", поэтому подразумевает наличие у слушателя опыта программирования или работы с другими СУБД, и, главное, желания самостоятельно изучать тему работы с PostgreSQL глубже.

Для тех, кому комфортнее смотреть и слушать, а не читать - доступна видеозапись.

В этой статье мы разберем новые удивительные способности последней языковой модели из семейства GPT (от понимания мемов до программирования), немного покопаемся у нее под капотом, а также попробуем понять – насколько близко искусственный интеллект подошел к черте его безопасного применения?

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

Для пользователей explain.tensor.ru - нашего сервиса визуализации PostgreSQL-планов, мы создали плагин "Explain PostgreSQL" для всех IDE от JetBrains, теперь есть возможность форматировать запросы и анализировать планы непосредственно в IDE.

Как использовать плагин и детали о его разработке читайте ниже.

Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.

Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.

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

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

Как результат, разработка шла с большими накладными расходами (все делали долго), и с высокими рисками (выкатили и разломали прод). А команда при этом работала на износ.

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

История начинается с несложной задачи и небольшого Python приложения.

Несложная задача это периодическое удаление дубликатов файлов из указанных каталогов. Изначально она возникла из следующих условий. Есть домашнее хранилище фотографии и видео, в котором определен порядок хранения файлов по тематике, датам и т. д. И есть источники для пополнения этого хранилища: смартфоны, фотоаппараты, контент из сети, электронной почты и т. д. Синхронизации источников контента и хранилища нет. Периодически со смартфонов и фотоаппаратов скидываются все хранящиеся там файлы на жесткий диск компьютера, и получается набор каталогов, в которых оказываются как те файлы, что уже есть в хранилище, так и новые файлы. И чтобы поместить в хранилище новые файлы, их нужно каким‑то образом отделить их от тех, что уже сохранены. Самый простой способ, который пришел в голову, это удалить дубликаты из каталогов «пополнения», а с остатком уже работать.

С источников файлы не удаляются пока в этом не появится острая необходимость, в первую очередь потому, что это «естественная» резервная копия. Ну и бывает удобно иметь какие‑то фотографии и видео у себя под рукой.

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

Мы часто сталкиваемся с задачами, которые требуют работы нашего кода дольше, чем длится простой HTTP-запрос. Это могут быть как выгрузки данных для интеграции с партнёрами, так и просто приложения, которые должны реагировать на события в системе в момент их появления. Конечно, можно использовать другие языки программирования, но это увеличит стек и усложнит систему.

Меня зовут Александр Пряхин, я TechUnit Lead в Авито. В IT работаю уже 14 лет. Из них 8 лет руковожу командами. Параллельно с этим преподаю и менторю. Сегодня разберём, как готовить демонов на PHP — от А до Я, и почему это актуально.

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

Эта статья посвящена двум более сложным миграциям:

- обновление большой таблицы
- разделение таблицы на две

Рассмотрим подходы, которые позволяют провести миграции с минимальным простоем для приложения.

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

Меня зовут Дарморезов Вадим, я Data Scientist и участник профессионального сообщества NTA. Актуальность работы с большими объемами текстовой информации ещё долгое время (а может быть и всегда) будет неоспорима. При этом спектр задач весьма вариативен – от задач по поиску именованных сущностей, до классификации и кластеризации текстов обрабатываемых документов.

Представим ситуацию. Перед вами важная задача – классифицировать огромный поток входящих обращений сотрудников/клиентов для дальнейшего анализа профильными сотрудниками на предмет отклонений и для построения интересующих статистик. Первое решение, приходящее в голову – в ручном режиме просматривать обращения и проводить их классификацию. Спустя пару часов, приходит осознание того, что решение было не самым правильным и так задачу не выполнить в срок. Как же тогда поступить? Именно об этом будет следующий пост.

На настоящий момент фирма 1С предоставляет возможность установки своего основного программного продукта на ОС Windows, Linux и MacOS (только клиентского приложения).

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

Однако, сама фирма 1С в своей документации и справочных материалах довольно прозрачно намекает, что ОС Windows далеко не единственный вариант установки ПО, в особенности серверной части и что ОС Linux гораздо более предпочтительна в качестве серверной ОС.

На портале 1С мы можем найти разные наборы установочных пакетов для 64-битных и 32-битных систем, для систем из семейства Linux, основанных на deb-пакетах (для системы Debian и её производных — Ubuntu, Mint и других) и основанных на rpm-пакетах (для ОС RedHat и её производных — CentOS, Suse, Fedora и других).

Но при более тщательном изучении документации, можно столкнуться со следующим интересным моментом.

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

Вариантов для выбора СУБД весьма немного. Система 1С может работать всего лишь с 4-мя различными СУБД: Microsoft SQL Server, PostgreSQL, IBM DB2 и Oracle Database. Все эти СУБД могут быть установлены на Linux, однако в полноценном варианте Microsoft SQL Server, IBM DB2 и Oracle Database являются платными коммерческими продуктами с немалой стоимостью. А на настоящий момент все эти три корпорации с РФ не работают (Microsoft, IBM, Oracle). У PostgreSQL тоже есть платная версия, но той версии, которая распространяется как свободный и открытый программный продукт, вполне достаточно для работы с сервером 1С. Поэтому при использовании свободной ОС Linux выбор в первую очередь, конечно, падает на PostgreSQL.

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

Как обычно, я буду приводить примеры из демобазы. В этой статье будет довольно много планов выполнения, но про их составные части я буду рассказывать только в следующих статьях. Здесь же нас в первую очередь будут интересовать оценки количества строк (кардинальности), то есть числа, указанные в верхней строке плана в позиции rows.

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

И уж конечно, никогда при написании a * b мы не задумываемся о том, как реализовано умножение чисел a и b в нашем языке. Какие вообще есть алгоритмы умножения? Это какая-то нетривиальная задача?

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

Привет! Я работаю в компании Bercut, которая более 20 лет занимается разработкой и поддержкой ПО для операторов сотовой и фиксированной связи. Сегодня я хочу рассказать о наших подходах к сокращению времени простоя продуктивного комплекса при установке обновлений схемы данных на СУБД Oracle. Целевая аудитория — начинающие и продолжающие разработчики, которым интересно узнать о различных вариантах распараллеливания и ускорения работы DDL, DML и прочих штуках, облегчающих процесс отладки и установки.

Когда человек раньше говорил что он контролирует весь мир, то его обычно помещали в соседнюю палату с Бонапартом Наполеоном. Надеюсь, что эти времена остались в прошлом и каждый желающий может анализировать геоданные всей земли и получать ответы на свои глобальные вопросы за минуты и секунды. Я опубликовал Openstreetmap_h3 — свой проект, который позволяет производить геоаналитику над данными из OpenStreetMap в PostGIS или в движке запросов, способном работать с Apache Arrow/Parquet.

Первым делом передаю привет хейтерам и скептикам. То что я разработал — действительно уникально и решает проблему преобразования и анализа геоданных используя обычные и привычные инструменты доступные каждому аналитику и датасаенс специалисту без бигдат, GPGPU, FPGA. То что выглядит сейчас простым в использовании и в коде — это мой личный проект в который я инвестировал свои отпуска, выходные, бессонные ночи и уйму личного времени за последние 3 года. Может быть я поделюсь и предысторией проекта и граблями по которым ходил, но сначала я все же опишу конечный результат.

Первый пост не претендует на монографию, начну с краткого обзора...