2135
Канал от Python-разработчиков: — востребованные инструменты — system design — softskills — лучшие практики разработки — подготовка к собеседованиям Увеличим твою ценность на рынке IT Для связи @sa_bul
Пятничное развлекательное
Столкнулся с удивительным случаем, который вызвал смех и удивление. Проводили собеседование. Заходим в зум, включаем камеры и тут включает камеру кандидат с мобильного. И что мы видим... Сидит чувак на улице, на лавочке, с сигой в зубах и готов проходить собес. Занавес.
Сама ситуация комична и вызывает смех, а удивление вызывает отношение к собеседованию. При этом кандидат слёзно заявлял, что очень хочет сменить текущую работу. Искренне не понимаю наличие желания и отсутствие реальных действий, чтобы это желание удовлетворить.
Не только развлекательное, но и полезное: у нас в канале есть тег #резюме о подготовке к собеседованиям с личным опытом.
Было что-то запоминающееся в вашей практике?
Работа с json в PostgreSQL
Цикл супер-полезных практических заметок о работе с json в PostgreSQL.
Затрагиваются вопросы:
— чем json отличается от jsonb
— как парсить json. В том числе: извлечение поля из json-объекта, получение тип данных, проверка существования поля или значения
— как разложить json по колонкам
— как конвертировать в json. В том числе: перевод строки в json, создание json-объекта из наборов ключей и значений
— как индексировать json. В том числе: всю колонку или отдельно взятое поле
— как сделать красивый вывод json
— как изменять json. В том числе: конкатенация двух json, удаление определенных полей или null-значений
Для более глубокого изучения того или иного вопроса автор даёт ссылки на документацию, другие статьи и SO.
#database
Пятничное развлекательное
Хочется порекомендовать замечательный курс для небиологов от Стэнфордского университета Биология поведения человека, который ведет Роберт Сапольски. Курс аж на 27 лекций будет интересен увлекающимся подобной тематикой.
И абсолютно всем рекомендую посмотреть лекцию курса, посвященную депрессии. Что наука говорит на эту тему. После просмотра, возможно, посмотрите на мир другими глазами. И порой человеку не помочь, просто дав отдохнуть и сказав подбадривающее "крепись".
#fun
Межсервисное взаимодействие
Базовая практическая статья с примерами на python по организации взаимодействия между несколькими сервисами.
Автор приводит три способа взаимодействия. Переходя от одного способа к другому, даёт небольшие вводные, почему имеет смысл усложнять.
– синхронный, с использованием http-запросов
– асинхронный, с внедрением брокера сообщений, но в некоторых местах все ещё остаются http-запросы
– усовершенствованный асинхронный, когда всё взаимодействие осуществляется через брокера
Мне кажется, важная мысль при чтении статьи – в первую очередь анализируйте требования. Не нужно накручивать сложные паттерны взаимодействия там, где это не обосновано. Просто потому что "ну вроде все так делают, на хайлоаде слышал".
Проектировать и закладывать гибкость имеет смысл ровно на обозримое будущее. Потому что лишняя сложность – это больше потенциальных мест для отказа и больше вероятность завязнуть с решением задачи. А самое забавное может случиться, когда новая бизнес-хотелка не уложится в ту самую заложенную гибкость. Вот тут то и начнётся натягивание совы на глобус.
Иногда бывает, что требований особо нет, никто их явно не предоставил. В этом случае важно очертить требования для себя и команды самостоятельно, и на их основании проектировать.
А ещё на тему "не переусложнять" была отличная статья, где ребята адаптировали паттерн Сага под свои реалии.
Рисование схемок
А чем вы пользуетесь для рисования всякого? Частенько же возникает необходимость накидать схему взаимодействия сервисов, какой-нибудь алгоритм или полноценно нарисовать архитектуру.
Конечно, на первом месте классический draw.io – очень разухабистая рисовалка.
Много шаблонных блоков для рисования любых схем. Возможность совместной работы. И, пожалуй, самое главное преимущество – возможность интеграции во множество сервисов ведения документации. Например, в Confluence и Obsidian, которыми активно пользуемся.
Недавно коллега показал удобную фичу – работу со слоями. Когда нужно что-то сложное изобразить на одном рисунке в разных разрезах. Например, схему инфраструктуры одним слоем, прописанные DNS-записи вторым, серверные мощности третьим.
Или при рефакторинге архитектуры – наглядно изобразить было/стало, просто переключая слои.
В draw.io порой напрягает слишком большое количество настроек, в которых можно запутаться и на которые совсем не хочется отвлекаться.
Недавно открыл для себя Excalidraw. Очень приятный и понятный интерфейс, совместная работа, также наличие шаблонных элементов на все случаи жизни.
А еще интересный стиль рисунков, как будто "от руки" добавляет особый шарм. Использую теперь, когда нужно что-то накидать, обсудить совместно с коллегами.
#tools
Поиск недокументированных API
Несложная практическая статья, посвящённая поиску недокументированных API. Ну вы знаете, частенько бывает нужно откуда-то что-то спарсить, создать датасетик в исследовательских целях.
Автор начинает просто – что такое недокументированные api, для чего могут пригодиться.
Важное отличие недокументированных api от класссического html-парсинга в том, что api более стабилен и зачастую содержит больше информации.
На простом примере показывается, как посмотреть нужные запросы, изолировать их и воспроизвести на python для автоматизации сбора информации.
Ещё по статье раскиданы ссылки на интересные детективные расследования, например, Google Has a Secret Blocklist that Hides YouTube Hate Videos from Advertisers—But It’s Full of Holes с методологией исследования. А в конце даются ссылки на практические статьи со схожей тематикой.
Может пригодиться интересный инструмент, который конвертирует curl-команду в запрос на самых разных языках программирования.
#skills
Airflow или что-то ещё?
Если у вас есть много разных обработчиков данных со сложной логикой, каждый из которых надо периодически запускать и мониторить, то удобным средством оркестрации этого зоопарка будет Apache Airflow.
Airflow — это такой cron на ультра-стероидах.
Статья Как мы оркестрируем процессы обработки данных с помощью Apache Airflow и доклад Как решить проблемы оркестрации сотен задач по обработке данных с помощью Apache Airflow будут отличным введением в тему. Помимо знакомства с технологией и её основными концепциями, ещё можно узнать, для чего её применяют на практике и с какими проблемами сталкиваются.
Несмотря на то, что airflow — достаточно разухабистая штука, её можно развернуть у себя локально и попробовать разные сценарии использования, руководствуясь туториалом в документации и примерами.
У себя на проекте мы прорабатываем вопрос использования чего-то подобного. Рассматриваем airflow и prefect. Конечно, ещё есть соблазн написать свой велосипедик, но, думаю, сможем удержаться.
Кто что использовал? Для каких задач? Помимо комментариев к постами у нас есть чат канала – залетайте.
#skills
А что, если достижение карьерных высот без жертв – это не миф? На канале «Не по головам» ведутся поиски способов добиться профессионального успеха в гармонии с собой.
Здесь вы узнаете, как облегчить ранние подъемы и спасти своё утро.
А ещё выясните, как мы сами себе мстим прокрастинацией.
Ещё уменьшите экранное время и залипание в смартфонах с помощью простого лайфхака.
В общем, если идти не по головам, то можно достичь профессиональных высот без жертв для нервной системы. И найти тот самый баланс между работой и личной жизнью.
Присоединяйся!
Пятничное развлекательное
Уже давно существует тренд на механические клавиатуры. Приятный звук, тактильные ощущения. Хочется стукать по ней всеми пальчиками. Но, даже если механической клавиатуры нет, в интернете всегда есть кто-то неправый и хочется побыстрее ему объяснить.
monkeytype – замечательный сервис, с отличным дизайном где можно позалипать и потренировать слепую печать.
#fun
Если на языке не пишут, то его и не знают
Разработчики-преподаватели из «Девман» понимают, как важно начинающему специалисту обучаться на реальных проектах из практики коммерческой разработки.
Именно поэтому ребята создали авторскую методику обучения Python программированию «От Новичка до Мидла». Ученик на «Девмане» осваивает материалы в состоянии высокой озадаченности: строит гипотезы, ищет решения, исправляет ошибки, пытается сделать так, чтобы проект заработал. Все это похоже на то, что мы делаем на работе.
Обучение стартует 27 марта. Первая неделя курса – пробная. На ней каждый может ощутить себя Python разработчиком.
На пробной неделе:
▫️Новички сделают сервис, который показывает погоду в разных городах.
▫️Более опытные успеют написать и собственный сервис по сокращению ссылок.
▫️Джуны создадут своего чат бота или сделают собственный сайт с афишей мероприятий.
Не упустите возможность сделать свой первый проект на Python!
Для записи переходите в бота → http://bit.ly/3JtDJWX
Реклама ООО «Девман» Pb3XmBtzswa5YFKKCL4y5KkHvFtEmwUx2EYWqUU
Итерируем всякое
Статья с кликбейтным названием – 10 итераторов, о которых вы могли не знать и реально интересным содержанием.
Автор начинает по классике, объясняя, что такое итератор, как реализовать собственный итератор, проходится по генераторам, протоколу последовательностей и перечислениям.
Кстати, бывают собеседования, где реально просят реализовать свой итератор. Ситуация неоднозначная: с одной стороны, знать внутреннее устройство итератора полезно, и вопрос может быть подходящим для выявления понимания у джуна. С другой стороны, на практике редко требуется лезть туда ручками. Если нужно – всегда можно посмотреть в доку, запоминать смысла нет. В итоге по бесполезности напоминает вопрос о тестировании карандаша.
Из действительно любопытного отметим:
– iter может принимать два аргумента. Второй аргумент – элемент, на котором будет сгенерировано исключение StopIteration
– можно итерироваться по стандартному потоку ввода. Объект stdin итерируемый
– можно итерироваться по содержимому каталога. В модуле pathlib есть итератор iterdir
– можно итерироваться по строкам csv-файла, применив функцию iter к объекту csv_reader
Итераторы окружают питонистов. Даже если постоянно используете Python в профессиональной деятельности, найдете что-то интересное. Статья исключительно практическая. Бери и используй.
#python
Делай нейминг как сеньор
Все мы знаем, что нужно правильно и понятно именовать переменные. Правильно, понятно – а это как?
Ребята написали отличную статью, где комплексно, с разных сторон подошли к вопросу нейминга.
На самом деле проработанный, качественный нейминг очень важен. Один раз где-то, что-то плохо назовешь, а через месяц-другой эти наименования просочатся в документацию, аналитику, тесты, внешние api.
Неправильно именование приводит к неправильному пониманию, а дальше – к некорректному использованию.
Чтобы детальнее разобраться, автор выделяет несколько распространенных проблем: слишком общие название, избыточные названия, названия без контекста, названия с некорректным переводом или калькой со своего языка, абстрактные названия. Каждая из проблем сопровождается примерами.
К решению проблемы автор также подходит комплексно, отталкиваясь от понимания предметной области и того, как выстроить работу с неймингом на уровне команды и продукта.
Заканчивается статья набором конкретных практических советов, которые можно брать и применять.
#procode
Работаем с аудиторией на выступлении – TEDx
Вы уверены, что лучше всего использовать технологию А, но команда планирует использовать технологию Б. Сможете ли вы донести свою мысль до коллектива?
Выступить даже на митапе для несколько человек непросто. А от качества выступления зависит степень донесения мыслей. Недостаточно быть просто правым, надо хорошо донести мысль и увлечь людей за собой. Если посмотреть шире, то площадки бывают разные:
– люди на конференциях делятся результатами, технологиями и опытом
– бизнес презентует что-то новое, можно вспомнить WWDC от Apple
– преподаватель на лекциях доносит знания
Для создания хорошего выступления нужен опыт, и с этим всё сложно. Мы не встречали годного материала про выступления. Поделимся своими мыслями. Как обычно, следует тянуться за лучшими практиками.
TED (technology, entertainment, design) – это известный организатор крутых конференций, и у него есть дочерний проект TEDx. TEDx создаёт локальные конференции в стиле TED.
В коротком видео How to use one paper towel докладчик рассказывает о важности экономии бумажных полотенец для сохранения деревьев. Предлагается простая схема – 12 раз стряхнуть влагу с рук (shake), после чего сложить полотенце вдвое (fold) и вытереть руки им. Очень круто поставлено взаимодействие с аудиторией – половина зала по указанию выступающего повторяет shake, вторая половина fold.
Выступление построено классически:
– формулировка проблемы
– презентация решения, обоснование и сравнение результатов
– связь результатов с проблемой
Внутри презентации решения много интересного:
– оценка результата "даже с одним полотенцем руки сухие"
– рассмотрение вариантов на примере "почему именно 12"
– шутки для повышения внимания к докладу
– технические внутренности "interstitial suspension" для демонстрации важности складывания полотенца вдвое
– пример из жизни "получить половинку полотенца из автоматического диспенсера"
Всё это в сумме образует очень крутое выступление по форме и содержанию, с которого можно брать пример.
У вас есть любимые TEDx-выступления?
#edu
Teamlead roadmap
В разработке нужны не только разработчики. В зависимости от размера, для проекта могут требоваться тимлид, CTO, PM и ещё десяток разных аббревиатур. Чёткого деления по задачам нет, и в разных компаниях разное видение ответственности каждого из работников. И один человек может брать одновременно тимлидом и CTO.
В итоге тимлиды в команде часто выполняют достаточно уникальный набор задач, являющийся миксом из множества ролей. В предлагаемом роадмапе детализированы личные навыки тимлида и различные управленческие роли:
– administrator, ответственный за управление циклом разработки проекта
– integrator, понимающий потребности бизнеса и его долгосрочной стратегии, способный донести эти потребности до команды
– people manager, занимающийся людьми, организацией работы команды в самом широком смысле включая найм, мотивацию, поддержку процесса работы и увольнения
– product owner, способный стратегически мыслить в рамках продукта
– technical lead, стратегически отвечающий за техническую часть
Каждое из направлений состоит из множества навыков. По большинству навыков есть подробное описание и дополнительные материалы для изучения, статьи и книги. Например, мы обсуждали code review из роли technical lead.
Топовый роадмап для разработчиков был раньше.
#edu
ngrok
Бывают случаи, когда хочется расшарить функционал, ещё не доставленный в девелоперский контур, что-то протестировать. И вообще могут быть разные причины, когда нужно обеспечить доступность извне вашей машинке или сервису.
Для этого есть замечательная утилита ngrok. Одна команда и готово.
У ребят всё сделано по-человечески – можно поднять в докере и настроить end-to-end шифрование. На этом возможности не заканчиваются. Есть качественная документация, можно узнать, как воплотить в жизнь самые разные хотелки.
Не пугайтесь раздела pricing на сайте. Для подобного базового использования – всё бесплатно.
А чтобы объединить разные устройства на хозяйстве в одну сеть и иметь отовсюду к ним доступ, пользуюсь еще одной замечательной утилитой tailscale. Примечательно, что у ребят тоже хорошая документация и блог, где они описывают различные хитрые сценарии применения. Например, как кодить на айпаде в vscode.
#tools
Вариантность типов
Интересная тема из теории программирования. В языках программирования существуют типы данных, и они могут образовывать сложную иерархию.
Простой пример: тип Natural является подтипом Integer и Positive. И все трое одновременно являются подтипами Real. А тип Prime является подтипом всех вышеперечисленных.
Есть у нас функция, которая в качестве параметра принимает на вход определённый тип данных. А можем ли мы передать в качестве параметра подтип или надтип исходного типа данных? За это как раз отвечает вариантность типов.
Контравариантность, ковариантность, инвариантность — в статье все эти замечательные термины рассматриваются на конкретных понятных примерах.
Также прочтение статьи позволит более глубокого понять принцип подстановки Барбары Лисков (LSP), который фигурирует в известной аббревиатуре soLid.
В конце рассматривается реализация вариантности в различных языках программирования –TypeScript, C#, Java, C++.
А на тему вариантности в python у Диджи было замечательное видео.
#procode
Асинхронность в браузере
Классная обширная статья на тему асинхронности в браузере. Даже если далеки от мира фронтенда, рекомендуем к прочтению, чтобы представлять как у них там все устроено. Автор рассказывает о циклах событий, об очередях задач (оказывается, их несколько), функциях обратного вызова, промисах и корутинах. Всё повествование сопровождается наглядными иллюстрациями и кодом.
Для людей, связанных с фронтендом, статья также будет полезна. Автор собирает многие знания воедино, рассказывает о некоторых экспериментальных функциях, а также даёт множество ссылок для более глубокого изучения. Нам показались интересными: Оптимизация производительности фронтенда и Визуализация промисов и Async/Await
Выбор брокера сообщений
Для асинхронного взаимодействия сервисов используются брокеры сообщений. Читая книгу о микросервисах, нашел набор факторов, которые нужно учесть, выбирая брокер для той или иной задачи.
— Поддерживаемые языки программирования. Пункт достаточно банальный, но лучше выбрать брокер с поддержкой широкого диапазона языков программирования.
— Поддерживаемые стандарты обмена сообщениями. Поддерживает ли брокер сообщений стандарт вроде AMQP или STOMP? Использует ли он свой закрытый протокол?
— Порядок следования сообщений. Сохраняет ли брокер порядок следования сообщений? Кстати неплохой вопрос на собеседовании: гарантирует ли Кафка упорядоченность сообщений и за счёт чего?
— Гарантии доставки. Какие гарантии доставки даёт брокер сообщений?
— Постоянное хранение. Сохраняются ли сообщения на диск? Могут ли они пережить сбой брокера?
— Устойчивость. Если потребитель переподключится к брокеру, получит ли он сообщения, отправленные, пока он был отключен?
— Масштабируемость. Насколько масштабируем брокер сообщений?
— Латентность. Каковы задержки при передачи информации?
— Конкурирующие потребители. Поддерживает ли брокер сообщений конкурирующих потребителей?
#skills
Postgres – как хранить строки?
Если каждый раз при проектировании базы данных задаётесь вопросом, чем отличаются char, varchar или text и какой тип данных использовать для хранения строк, то эта заметка для вас.
Автор рассказывает о каждом типе данных, отмечает важные моменты:
– тип данных не влияет на производительность
– при ограничении длины текстового поля лучше использовать check constraint
В сухом остатке: используйте для хранения строк text.
#database
Backup: март
В этом месяце было много инструментов, баз данных, инфраструктуры и софт-скиллов. Питон тоже не забыт, вспоминали итераторы, FastAPI и именование переменных.
Работаем с проектом
Постигаем gRPC
Снова о микросервисах
Поиск недокументированных API
Софт-скиллы
Teamlead roadmap
Работаем с аудиторией на выступлении – TEDx
Базы данных
Следим за PostgreSQL
Проектируем БД в DB Designer
Где бы ещё сохранить данные? В Greenplum
Python
Итерируем всякое
Как ускорить приложение на FastAPI
Делай нейминг как сеньор
Инструменты
Доступность компа извне с помощью ngrok
Комментарии в маркдауне
Airflow или что-то ещё?
Нас тепло приняли на хабре со статьёй Реверс инжиниринг для самых маленьких на практике
Если пропустили, то подборка за февраль
#backup
Пятничное развлекательное
Казалось бы, скроллбар и скроллбар, что в нём такого. Нашли прикольный сайт Evolution of the Scrollbar, где продемонстрирована история развития этой незамысловатой штуки.
В традициях лучших музеев все скроллбары можно потрогать, поностальгировать.
И на всякий случай: горизонтально скроллить можно с помощью shift+колёсико мышки.
#fun
Комментарии в маркдауне
В ворде есть замечательная функция ревью, с помощью которой можно оставить комментарии к тексту. Обычно это нужно при совместной работе над текстом.
На нашей практике часто приходится работать с маркдаун-файлами. И, порой, тоже хочется оставить комментарий, чтобы это не влияло на внешний вид документа.
Оказалось, есть возможность оставлять комментарии, которые видны только в режиме редактирования и не видны в режиме просмотра.
<!-- Этого текста в режиме просмотра не будет видно. --> – проверено в gitlab, github и pycharm.
Конечно, вводить каждый раз вручную эту конструкцию не нужно, везде есть горячие клавиши.
В ворде удобно итерироваться по комментариям, а так как конструкция для <!-- достаточно уникальная, то можно просто ввести её в поиске и также итерироваться по найденным совпадениям.
Оказалось очень удобно, когда ревьюили статью на хабр по реверсу.
#edu
Реверс инжиниринг для самых маленьких на практике
Не ограничиваем область своих интересов только разработкой, поэтому совместно с нашим хорошим другом и подписчиком подготовили статью на тему реверса.
В статье мы берём все наши скромные знания, дизассемблер, несложную задачку и идём в бой.
В процессе разбираем, какие инструменты использовать, с какой стороны подходить к решению подобных задач, где-то углубляемся в теорию и даём полезные ссылки для более детального изучения.
Если посматривали на реверс, но не знали с чего начать – велкам.
Как ускорить приложение на FastAPI
Важно понимать потенциальные узкие места вашего приложения, и что можно подкрутить в том или ином случае.
Отличная практическая статья, показывающая, как можно ускорить своё приложение. Примеры из статьи выложены на github, поэтому можно потрогать ручками.
Ребята не открывают ничего супер нового, просто берут приложение на fastapi и показывают набор классических приёмов для ускорения работы.
Рассматриваются:
– многопоточность
– асинхронность
– redis для кеширования
А в качестве бонуса – статья о KeyDB, интересной альтернативе привычному всем редису, на которую стоит посмотреть.
#python
Где бы ещё сохранить данные?
Greenplum – распределённая база данных на основе postgres с открытым исходным кодом.
Статья Introduction To Greenplum Architecture будет отличным введением для понимания, что это за зверь такой.
Автор начинает с довольно скучного введения, так что сразу переходите к разделу Greenplum Overall Architecture.
По сути, Greenplum – это кластер баз данных, состоящий из отдельных Postgres. Кластер состоит из:
– master-ноды, которая является входной точкой для всей БД и обеспечивает единый интерфейс для взаимодействия с кластером
– standby-ноды – резервного мастера для обеспечения высокой доступности
– нескольких segment-нод – рабочих лошадок, где хранятся и обрабатываются данные
Статья расскажет, как это всё вместе взаимодействует. Затрагиваются вопросы:
– физической организации хранения данных
– порядка и способов взаимодействия всех участников кластера
– выполнения запросов с различными джоинами
– обеспечения атомарности и изоляции
– механизма двухфазного коммита для подтверждения распределённых транзакций
Вводная статья, конечно, не расскажет о практическом применении гринплама и не подсветит проблемные места. Чтобы изучить, как эта махарайка применяется на практике, рекомендуем прочитать статью Как мы используем Greenplum в платформе данных Тинькофф
#skills #database
Пятничное развлекательное
Захватывающее пятничное чтиво INSIDE PORNHUB о внутренней кухне от лица бывшего сотрудника.
Быстрый рост компании, конфликты внутри индустрии. Проблемы, с которыми сталкивались и как решали. Особое внимание уделяется тому, как модерировался контент.
Почитайте, очень любопытно :)
#fun
Проектируем БД в DB Designer
При проектировании архитектуры приложения часто нужно набросать схему базы данных. Хочется такой инструмент, где это можно сделать быстро и удобно. Думать только о сути, а не о том, как добавить поле или как соединить таблицы.
Для себя давно нашел такой инструмент – DB Designer.
Из приятных штук могу выделить:
– всё делается в браузере
– очень просто накликать нужные таблицы и связи
– стрелочки-связи между таблицами красиво и понятно располагаются
– явно видно, по каким полям соединяются таблицы
– можно работать в коллаборации с коллегами, оставлять комментарии
– для дальнейших экспериментов схему можно экспортировать в SQL-файлик
Если пользуетесь чем-то подобным – делитесь в комментариях.
#tools
Пятничное развлекательное
Есть такое хобби – экстраполировать. В шуточной статье Python 3.14 Will be Faster than C++ демонстрируется результат бенчмарка производительности питона от версии 3.5 до версии 3.11. Изложение приправлено изрядной долей юмора, have fun.
#fun
Следим за Postgres
Иногда что-то случается в Postgres, и с ходу даже не знаешь, куда смотреть. Начинается брожение по специализированным ресурсам в поиске хитрого запроса на получение необходимых диагностических данных.
Автор провел большую работу и собрал в статье набор полезных запросов для postgres. Статья будет отличной шпаргалкой, потому что многие запросы без пол литра не разобрать.
Для отслеживания размера БД автор приводит запросы для получения:
– размера табличных пространств
– размера базы данных
– размера схем в базе данных
– размера таблиц
Это всё цветочки и, как правило, можно посмотреть в любом клиенте.
А когда не проходит какой-нибудь запрос или миграция виснет, тут уже становится интереснее. Где-то что-то блокируется.
Для отслеживания блокировок автор приводит запрос для получения заблокированных запросов и снятия блокировок.
Для отслеживания эффективности можно узнать:
– коэффициент кеширования, показывающий долю чтения из кеша по сравнению с общим количеством операций чтения как с диска, так и из кеша
– процент времени использования индексов по сравнению с чтением данных без индексов и, таким образом, найти кандидатов на добавление индекса
– наоборот, неиспользуемые индексы
– величину раздувания базы. Это когда дисковое пространство использовалось таблицей или индексом, доступно для повторного использования, но не было освобождено. Для решения этой проблемы есть команда VACUUM.
Также среди полезных запросов автор приводит получение:
– количества открытых подключений
– выполняющихся запросов и их длительность
Рекомендуем также заглянуть в комментарии, там делятся интересным опытом. Например, запрос для отладки блокировок. Или совсем специфичное – запрос, который позволит прикинуть сколько занимает одна запись на диске.
#skills #database
Микросервисы. Очередное рассуждение
В последнее время активно исследую вопросы, связанные с микросервисной архитектурой. Наткнулся на статью-рассуждение Микросервисы и неизбежная боль?
Автор начинает с того, что сам термин "микросервис" неоднозначен и приводит разные определения. Я с ним согласен. Думаю, что чересчур много внимания уделяется микро. Мне же нравится обобщённое определение, что микросервисная архитектура – это стиль проектирования, который разбивает приложение на отдельные сервисы с разными функциями. И важно, что в нём ни слова о размере.
Далее по классике микросервисы сравниваются с service-oriented architecture (SOA) и монолитом. Тут нет ничего нового. Выделю отличия микросервисов от SOA:
– в SOA, как правило, сервис – это крупное монолитное приложение. Возможно, даже ставшее отдельным сервисом не по архитектурной задумке, а в силу исторических причин
– в SOA используется глобальная модель данных и общая БД
– в SOA для межсервисного взаимодействия используются умные и тяжеловесные протоколы вроде SOAP
Доходим наконец-то до боли, обозначенной в заголовке. Автор говорит о том, что часто видел:
– огромное количество разрозненных, отличающихся друг от друга репозиториев, созданных разными людьми
– большие усилия на поддержание обратной совместимости api, невозможность определить во всем зоопарке сервисов, кто это api использует и нужно ли оно вообще
– размывание технологического стека среди команд и сервисов, разные системы сборки и деплоя
– новые сервисы на каждый чих, дублирование кода
Что ж, у меня двоякое отношение к сказанному. Могу лишь сделать вывод, что любую архитектуру можно испортить. Ничего удивительного, микросервисы – не золотая пуля, они несут в себе набор проблем и ограничений. Важность перечисленных проблем в том, что о них нужно знать заранее, тщательно отслеживать и вовремя реагировать. Предупрежден – значит вооружён.
Возвращаясь к проблемам, для организации микросервисной архитектуры должны быть выстроены процессы и инженерная культура, созданы шаблонные сервисы, особое внимание должно уделяться CI/CD и observability.
Рассуждая о золотой середине, автор даёт, как мне кажется, вредные советы. Всё сводится к тому, что делаем условно монолитно, но, когда понадобится, легко сможем разбить на микросервисы. Предлагается использовать единый репозиторий с делением на директории посервисно, одну базу данных без связей между таблицами разных сервисов.
Не думаю, что это хорошая практика. Применение таких половинчатых мер незаметно приведет к появлению распределенного монолита, которому будут присущи проблемы как микросервисов так и монолита.
В конце банальный, но, кажется, работающий совет: перед принятием решения – думайте, приземляйте на свои реалии, не следуйте просто написанному в умных книгах. Помните о плюсах, которые предоставляет микросервисная архитектура, и думайте о том, чтобы не потеряться их, принимая то или иное решение. Хорошим примером может служить пост о том, как сложный паттерн Сага был адаптирован в более простую версию, исходя из требований конкретной задачи.
#skills