Базы данных *

Привет, Хабр! С вами Александр Константинов, технический эксперт по облачным технологиям из Cloud.ru. Сегодня хочу показать вам наглядно, как можно оптимизировать производительность веб-приложения. Рассмотрим это на усредненном примере кейса, который типичен для многих наших клиентов, пройдем весь путь настройки, выполним нагрузочное тестирование и сравним до/после.

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

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

Обновление версии php в legacy-проекте — это часто настоящий квест. То времени нет, то бизнес-фичи надо пилить, то еще какие-то причины. И часто бывает, что обновление версии php в командах откладывается на потом.

Данные без информации — это просто цифры. Чтобы они «заговорили», их нужно извлечь и преобразовать. Для этого существуют ETL‑системы, а для анализа данных и визуализации — BI и Data Science.

Сегодня бизнес выбирает между тремя классами ETL-решений...

150 млн чтений в секунду — итог скрупулёзной инженерии кэша. В этом кейсе Uber — как ужесточить консистентность без удушения записи: инвалидация «по пути записи» из слоя запросов, дедупликация по commit-timestamp из БД, сочетание TTL и CDC на бинлогах, плюс измерение «черствости» через Cache Inspector. Разобраны реальные источники stale-данных (лаг CDC, реплики, негативное кэширование) и компромиссы вроде read-your-writes — с практическими схемами, которые масштабируются до сотен миллионов RPS.

Одна из открытых пока задач в области баз данных - поддержание базы данных в консистентном состоянии одновременно на нескольких экземплярах СУБД (узлах), принимающих клиентские соединения независимо друг от друга. Суть проблемы заключается не в том, чтобы синхронизировать состояние удалённо по сети, а в том, что в случае отказа одного из узлов такой системы остальные должны продолжить свою работу без перерыва: принимать соединения, коммитить транзакции не потеряв при этом консистентность. Аналогией для случая одного экземпляра СУБД здесь может быть, к примеру, обеспечение работы при отказе планки оперативной памяти или прерывающемся доступе к нескольким ядрам процессора.

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

В статье я расскажу о практических кейсах и сложностях, возникающих (и возникавших) в процессе миграции данных между СУБД (Oracle -> Postgres), а также о собственном инструменте миграции данных, который вы также можете попробовать.

Недавно рассказывал про мониторинг истории активных сессий в базах данных Oracle, PostgreSQL, ClickHouse и MS SQL Server с использованием desktop-приложения Dimension-UI (link). В комментариях @KPSB92 задал вопрос о преимуществах/отличиях связки exporter Prometheus/Grafana и Dimension-UI, решил оформить ответ в эту небольшую статью.

Итак, возьмем для примера просмотр данных активных сессий в базе данных PostgreSQL и сравним визуализацию в Grafana и Dimension-UI. Посмотрим работу с интерфейсами обоих систем в динамике с помощью скринкастов.

... писать без транзакций?
... сохранять без кворума?
... стирать прод без бэкапов?
... сливать базу самому?

И всё это безопасно, надёжно, доступно!

Приветствуем, коллеги. На связи Олег Сивченко @OlegSivchenko.

Уместен и закономерен ваш интерес, как мы обзаводимся правами на перевод зарубежных книг и где берём новинки. Такой вопрос задал нам читатель @PopovGP. Действительно, книгоиздательская отрасль не один год приспосабливалась к современным реалиям, но один интересный новый тренд действительно стоит раскрыть подробнее: мы стали активнее искать и рассматривать небольшие издательства, настроенные на сотрудничество. Так, уважаемый коллега @Holmogorov завершил длительный поиск базовой книги по Jetpack Compose, найдя в небольшом американском издательстве «Payload Publishing» отличный труд Нила Смита «Основы JetPack Compose: Разработка приложений для Android с помощью Jetpack Compose, Android Studio и Kotlin». Эта книга вышла в августе.

О другой очень похожей находке я хочу рассказать вам сегодня. Это совсем свежая новинка «Программирование бэкенда на Python. Практическое руководство» под авторством Тима Питерса. Обнаружили мы её в каталоге маленького индийского издательства «GitForGits».

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

В этой статье я расскажу, как правильно создать сервис для конкурентных обновлений остатков данных в базе данных. Буду использовать .NET, C#, Entity Framework и PostgreSql.

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

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

И вроде не велика проблема - делаем структуру в нашем любимом языке, такую же, как в БД и из наших кубиков складывается слово "счастье". Складываться-то оно складывается, но ненадолго. Очень быстро структура БД и структура в коде начинают разъезжаться. А если не начинают, то потыкайте в свой проект палочкой - скорее всего он уже умер. Как говорится "не щебечет дохлый щегол, а мёртвый проект не меняет свою структуру". Ну и далее по тексту...

Здравствуйте. Меня зовут Олег Юрченко. Расскажу о своём опыте создания хранилища данных для отчётов с синхронизацией близкой реальному времени.

В мире, где абстракции правят бал, а скорость важнее эффективности, говорить о C — значит идти против течения. Для многих это «устаревший» язык с ручным управлением памятью и «опасными» указателями. Но что, если именно эти его особенности — не минусы, а ключи к системному программированию, где нет права на ошибку? Программистом Postgres Professional с 22-летним стажем Максим Орлов убеждён, что C — не про мгновенный дофамин и быстрые прототипы, а про суть, контроль и философское понимание того, как действительно работает железо. Погрузитесь в историю любви к C, которая началась с раздражения на Pascal, и узнайте, почему этот «бастион спокойствия» актуален и сегодня.

Ещё в 2009 году Тим Бернерс-Ли написал веб-спецификацию под названием «Socially Aware Cloud Storage», ориентированную на защиту общественных интересов при реализации облачных хранилищ:

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

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

Несколько таких идей активно обсуждались в цифровой среде в конце 2000-х, вскоре после взрывного развития монолитных платформ эпохи Web 2.0 вроде Facebook*.

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

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

В этой статье я расскажу про данные Whatsapp и Telegram для ML-моделей: какие данные доступны, насколько они ценны и насколько легальны.

Статья описывает методику миграции приложения, содержащего множество SQL запросов из базы данных Oracle в Postgres. Будет интересна всем, кто собирается мигрировать или уже мигрировал приложение из Oracle в Postgres.

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

На связи Артемий Новожилов, архитектор систем ИБ и автор ТГ-канала Data Security и Дмитрий Ларин, руководитель продуктового направления по защите баз данных, группа компаний «Гарда». С нами вы могли познакомиться по таким статьям как маскирование и Apache Kafka. И сегодня мы хотим продолжить тему маскирования данных.

Современные компании обрабатывают огромные объемы конфиденциальных данных: персональные данные (как сотрудников, так и партнеров и клиентов), информацию о клиентах и их заказах, финансовые и бухгалтерские сведения, данные, относящиеся к коммерческой тайне и интеллектуальной собственности, а также технические настройки и доступы. В связи с этим возникают повышенные риски утечки данных, сложности с соблюдением требований законодательства (например, ФЗ-152 и GDPR), угроза инсайдерских атак, а для тестов или аналитики приходится создавать отдельные копии баз данных (БД).

Один из эффективных способов защиты данных – динамическое маскирование (Dynamic Data Masking, DDM).

Сегодня проверим Dimension‑UI на задаче мониторинга истории активных сессий в базах данных Oracle, PostgreSQL, ClickHouse и MS SQL Server в режиме реального времени.

История активных сессий (Active Session History, ASH) — очень удобный способ получения информации о работе БД в кратком виде. Когда важно максимально быстро отследить, что происходит с системой в настоящее время, оценить развитие текущей ситуации — это рабочая активность или начало каких‑либо проблем — в том числе, через быстрый просмотр baselines в недавнем прошлом системы и сравнить их с текущими данными.

Изначально, данный подход был разработан и применен в СУБД Oracle начиная с 10g версии. Архитектурно в Oracle это выглядит как плоская таблица в памяти V$ACTIVE_SESSION_HISTORY, в которую с определенным интервалом (стандартно 1 секунда, но его значение можно изменять) записывается состояние каждой активной сессии: идентификатор сессии, SQL‑запроса, процесса операционной системы, текущий статус сессии — в работе или ожидании получения доступа к ресурсу, статистики потребления памяти и проч.. Периодически информация из таблицы в памяти сбрасывается на диск в таблицу DBA_HIST_ACTIVE_SESS_HISTORY репозитория рабочей нагрузки AWR.

Привет! Меня зовут Бромбин Андрей. За последние годы у меня накопилось достаточно материалов, практик и ошибок — иногда красивых, но всё же ошибок. Этого хватило, чтобы собрать маршрут до грейда Middle.

Это не «большая книга всего на свете для джуна» и не выдуманный субъективный маршрут. Мне удалось привлечь к созданию этой статьи ведущих разработчиков крупных российских компаний — от каждого я получил честный фидбэк: где перегнул, где недосказал, чего не хватает на практике. Приоритеты были сверены, лишнее вычищено и оставлено только то, что реально двигает.

Признаться, честно: тут и для меня нашлось, что подтянуть.

Представьте: Один неоптимизированный запрос от неопытного коллеги - и вот уже 40 ТБ SPILL-файлов парализуют систему.

Срабатывает лимит на уровне Greenplum, запрос завершён. Никто ничего не знает.

Создаются заявки, пишутся письма, пользователь недоволен.

Это не какая-то выдуманная история, а обычный будний день в большом Greenplum. Вернее, так было раньше.