Всем привет, меня зовут Александр Даниленко, я – ведущий разработчик отдела «Бюджет-Online». В компании «БАРС Груп» работаю уже 5 лет. За это время нам удалось успешно исправить некоторые сложности процесса разработки. Первая проблема, с который мы столкнулись – развороты больших баз данных (БД) у разработчиков на локальных машинах. Сегодня мы расскажем об инструменте «Databaser», который на 100% позволяет ее решить.
За время жизни продукта, безусловно, приходится собирать большое количество данных, анализировать и принимать на их основе решения.
Но как сделать так, чтобы всеми метриками было удобно пользоваться? Чтобы не приходилось собирать всё вручную, а была бы единая точка входа к данным, и сама полученная информация помогала контролировать состояние дел и проводить верную оценку.
Мы нашли для себя удобный способ сбора и отображения данных о проектах и сотрудниках, которые в них задействованы, и хотим поделиться этим способом в статье. Как всегда, мы открыты к диалогу и надеемся, что это решение пригодится в работе или вы адаптируете его по-своему.
## Prisma - установка в проект
Установка поддержки Prisma в NestJS-проекте выполняется очень просто - при помощи двух команд.
Первая - устанавливает клиентскую часть Prisma:
$ npm i @prisma/client
... вторая команда - устанавливает cli-часть Prisma:
$ npm i -D prisma
После этого - нужно запустить команду для инициализации Prisma в текущем проекте:
$ npx prisma init
В результате в корне проекта будет создана папка prisma, внутри которой будет находиться файл schema.prisma для настройки подключения Prisma к базе данных (и не только).
Содержимое файла schema.prisma очень простое:
Вы когда-нибудь задумывались о том, чтобы перенести крупномасштабное программное решение с Oracle на PostgreSQL, а затем развернуть его в общедоступном облаке? Если Вы планируете реализовать подобное, возможно, Вам поможет наш опыт. Данная статья подробно рассказывает о нашем опыте настройки облачного хранилища, используемого PostgreSQL и оптимизации его производительности.
Сегодня SQL используют уже буквально все на свете: и аналитики, и программисты, и тестировщики, и т.д. Отчасти это связано с тем, что базовые возможности этого языка легко освоить.
Однако работая с большим количеством junior-ов, мы раз от раза находим в их решениях одни и те же ошибки. Реально — иногда просто создается ощущение, что они копируют друг у друга код.
Кстати, иногда такая же участь постигает и специалистов более высокого полета.
Сегодня мы решили собрать 7 таких ошибок в одном месте, чтобы как можно меньше людей их совершали.
В современной микросервисной разработке очень популярна чистая архитектура (она же луковая). Этот подход ясно отвечает на много архитектурных вопросов, а также хорошо подходит для сервисов с небольшой кодовой базой. Другая приятная особенность чистой архитектуры состоит в том, что она отлично сочетается с Domain Driven Development — они отлично дополняют друг друга.
Одной из прикладных реализаций чистой архитектуры является гексагональная архитектура — подход, явно выделяющей слои, адаптеры и прочее. Данный подход заслуженно сыскал любовь среди разработчиков на Go — он не требует сложных абстракций или зубодробительных паттернов, а также почти ни в чем не противоречит сложной идиоматике языка — так называемому Go way.
Но есть проблема, которую я часто вижу во многих командах, адаптирующих гексагоны, и с которой я сам столкнулся и успешно решил — реализация транзакций базы данных в рамках DDD и пресловутого гексагона. Что у меня вышло я и расскажу в этой заметке.
В моей практике ускорения SQL-запросов для PostgreSQL, в большинстве случаев, все сводится к применению типовых методик - их не особенно-то и много, и прочитать про большинство из них можно в моем профиле.
Но иногда обнаруживаются очень странные вещи в поведении этой, безусловно, отличной СУБД.
Все началось с запроса, который мне показали с диагнозом "необъяснимо тормозит"...
В "Тензоре" мы разрабатываем множество сервисов для управления бизнесом. А в бизнесе очень часто возникает желание немного "заглянуть в будущее" - спрогнозировать и увидеть на графике значение каких-то величин, которые мы можем только предполагать на основании данных предыдущих периодов. Например, на какую примерно выручку мы сможем рассчитывать в следующем месяце или сколько продуктов стоит закупить в столовую на следующую неделю.
Для решения этой задачи можно строить сложные математические модели и проверять их на "кластерах с бигдатой", но мы попробуем найти вариант попроще - когда есть всего одна метрика, SQL и немного житейской логики.
Для таргетинга мы в Ozon используем сегменты, в которые группируем пользователей по интересам. Интересы могут быть определены через систему трекинга событий. Последние в свою очередь формируются в процессе взаимодействия пользователя с маркетплейсом Ozon. На основе сегментов мы отправляем нотификации, рассылаем письма, показываем рекомендации, баннеры, страницы с товарами и цены на товары, участвующие в маркетинговых акциях. В принципе, на сегменты можно завязать любую механику. Мы даже А/В тесты иногда проводим с ними.
Первоначально сегменты создавались вручную: поступал запрос от заказчика, после чего проводилась аналитическая работа по сбору требований. Количество заявок на создание сегментов со временем только увеличивалось. Чтобы автоматизировать процесс создания сегментов мы решили сделать конструктор сегментов для DMP — Data Management Platform. Это относительно молодой проект, ему чуть больше двух лет, но он полностью себя оправдал. Сегодня расскажу вам о нашем опыте. Меня зовут Евгений Чмель, и я руковожу командой DMP & CDP.
«А кто отвечает за эту базу данных?»
Народ из команды администраторов баз данных пожал плечами, и кто-то спросил: «А сервер Oracle или SQL?»
«По-моему, это My SQL», — сказал руководитель отдела разработки.
За 20 лет работы администратором баз данных зачастую именно в таких ситуациях передо мной возникала необходимость изучения новых RDBMS (система управления реляционными базами данных). В результате я не понаслышке знаю, с какими сложностями вы можете столкнуться, когда приходится с головой погружаться в омут другой системы.
Для приготовления отправки электронных писем с отчётом о доставке (а точнее с подтверждением о принятии или отклонении писем почтовым сервером получаетеля) нам понадобится сам postgres и его плагины планировщик асинхронных задач и cURL, а также локальный почтовый сервер, gawk и его плагин. Можно также воспользоваться docker-compose.
Использовать стандартные библиотеки и общеизвестные реализации алгоритмов — признак хорошего тона. Вместо изобретения своего алгоритма шифрования данных или своей хэш функции лучше взять уже готовое решение. Избегаем ошибок и не изобретаем велосипед заново. Но что если готового решения нет? В наше время это что-то невероятное. Есть github.com, есть набор платных решений.Тем интереснее обсудить необычную проблему. В данной статье расскажу о своем опыте оптимизации работы с данными, которые по своей природе представляют граф. А точнее сеть — разновидность графов.
PostGIS 3.2 зарелизили в самый последний момент прошлого месяца, чтобы он успел увидеть свет в 2021 году. Эта новая версия PostGIS также поддерживает GEOS последней версии 3.10, благодаря чему мы получили несколько новых фич.
Примитивный запрос - простой джойн и группировка. Традиционные методы оптимизации - казалось бы, что могло пойти не так?..
Небольшой эксперимент, на тему необходимости проверки любых гипотез в конкретных условиях.
Развитие происходит по спирали: когда-то люди не умели правильно индексировать, потом (в основном) научились, потом пришли noSQL и все снова забыли знание древних. Что вы будете делать, когда последние из старых DBA отплывут в Валинор?
Снова и снова и сталкиваюсь с полным набором антипаттернов индексирования. Я их перечислю, но! Для каждого антипаттерна есть исключение, когда именно это и стоит делать. Поэтому кликбейтно сформулированное правило верно в 95% случаях, но если вы хотите копнуть глубже, то прочитайте про исключения.
И в конце полезные скрипты для MSSQL, Postgres и MySQL.
Данная статья представляет собой решение проблемы с network latency между прикладом и бд. Поэтому скорее всего она будет интересна людям имеющие схожие симптомы. В материале описаны основные моменты kubernetes и пляски с бубном на python. Примеры кода приведены из реального приложения.
О чем статья
В этой статье речь пойдет о БАЗОВЫХ подходах и принципах к такому quality attribute (QA) как Availability. Никаких сложных случаев, ничего слишком сложного, только теория с двумя примерами, скипайте, если искали что-то эдакое.
Вся информация основана на парах книг, статей, и моем опыте. В конце статьи я покажу, какие именно. Также, эта статья - по суть перевод моей же статьи, только написанной на английском.
Что такое Availability?
Перед тем, как рассматривать паттерны и техники для обеспечения availability мы должны определить сам термин.
