41 ТБ/сутки по маршруту Oracle → Postgres Pro без остановки исходной системы — это не теория, а цифры последних тестов. Мы разложили миграцию на три этапа: быструю начальную загрузку, CDC из redo-логов и валидацию, и собрали их в ProGate. Как устроен конвейер, почему Go и где прячутся узкие места — расскажем в статье.
Представьте, что в основе вашего коммерческого продукта используется компонент с исходным кодом, который написан на смеси языка С и самописного ассемблера. Из-за слабой детерминированности поиск репродьюсеров сложен, а без репродьюсера мейнтейнер проекта заявляет: «Сделайте так, чтобы я про вас больше не слышал». Я расскажу, как мы построили процесс активной поддержки LuaJIT в СУБД Tarantool, сократили количество инцидентов в продакшене, сократили затраты на бэкпорт патчей из основного проекта и какую роль во всем этом сыграл фаззинг и его специфика.
Команда разработки продукта полностью отвечает за весь код этого продукта, в том числе за компоненты с открытым исходным кодом от третьих лиц. К сожалению, не все мейнтейнеры проектов с открытым исходным кодом готовы сотрудничать с разработчиками или их сотрудничество ограничивается жесткими рамками, что усложняет использование этих компонентов в коммерческих продуктах.
В СУБД Tarantool используется LuaJIT в качестве языкового рантайма, но в Tarantool используется не оригинальный проект, а его форк. Я расскажу, как мы прошли путь от пассивного использования кода LuaJIT к процессу поддержки форка, с которым количество инцидентов на продакшене установилось около нуля, сократились усилия по бэкпортингу патчей из основного проекта, а основной проект получил активных контрибьюторов.
Я рассмотрю специфику работы с проектом исходного кода на примере LuaJIT, расскажу, как устроено тестирование в нашем форке и какую роль там играет фаззинг. Расскажу о специфике фаззинга LuaJIT и о том, каких результатов мы в этом достигли за последние два года.
Привет! Меня зовут Антон Головенко и я backend-разработчик команды Search-Quality в Авито. Вот уже полтора года я ускоряю производительность поиска и повышаю его надежность, а также участвую в интеграции новых продуктов. В статье расскажу о том, как мы тестировали Redis под нагрузкой, с какими проблемами столкнулись, как их решали и какие выводы сделали. Заголовок звучит кликбейтно — но вы скоро поймёте, что он полностью оправдан.
В первой части мы разбирались, как Firebird забирает строку таблицы с диска. Во второй и третьей частях мы разбирались, что происходит с прочитанной строкой в процессе выполнения SELECT-запроса. Но остался неотвеченным такой вопрос: а как указать на строку таблицы, которую надо прочитать? Этим вопросом мы и займёмся.
Если вы когда‑либо занимались построением отчётов в Power BI, то наверняка сталкивались с просьбой «заменить пустые значения на ноль — чтобы было красиво». Кажется, мелочь. Но на самом деле это решение может незаметно убить производительность модели, превратить быстрый отчёт в тормозящий интерфейс, а оптимизатор — в беспомощного наблюдателя. В этой статье — разбор того, что происходит под капотом VertiPaq, как DAX на самом деле обрабатывает BLANK, и почему иногда лучше оставить пустое значение пустым.
ClickHouse не тормозит, но теряет данные. Набор простых действий с объяснениями, позволяющий избежать потери данных.
В современной цифровой экономике самый ценный ресурс — данные. Случается так, что инфраструктура для управления ими стремительно превращается из инструмента роста в причину трат, источник рисков и препятствие на пути к дальнейшему росту. Руководители сталкиваются с противоречием: с одной стороны ценность информации нужно приумножать, с другой — не утонуть в сложности и расходах. Решение этой дилеммы определяет не просто IT-стратегию, а конкурентоспособность и долгосрочную жизнеспособность бизнеса.
В этой статье мы проведем сравнительный анализ самостоятельного развертывания баз данных и управляемых DBaaS-решений. Посмотрим, какая модель дает стратегическое преимущество. Подробности под катом!
Будучи разработчиками, мы постоянно стремимся создавать системы, которые не просто работают, но и отличаются эффективностью и масштабируемостью. В мире, где пользователи ожидают всё более быстрые и точные результаты, оптимизация производительности поиска становится ключевым приоритетом в современной разработке приложений.
Эта статья основана на нашем выступлении на конференции QCon San Francisco 2024, где мы рассмотрели эволюцию подходов к индексированию данных, их извлечению и ранжированию. Для платформ вроде Uber Eats, обрабатывающих сложные запросы на больших объёмах данных, оптимизация поиска — это серьёзный вызов, требующий продвинутых стратегий: индексирования, шардинга и параллельной обработки запросов.
Сложность поисковых систем продолжает расти, и необходимость соблюдения баланса между скоростью, релевантностью и масштабируемостью становится как никогда актуальной. В этой статье мы рассматриваем ключевые техники таких оптимизаций и их влияние на пользовательский опыт и производительность системы.
Когда имеется несколько индексов с одинаковыми ведущими столбцами, иногда выбирается не лучший индекс, и время выполнения запроса увеличивается на порядки. Такие ситуации встречаются в сложных приложениях, но чаще всего в 1С:ERP, поскольку это приложение наиболее распространено. Как это обычно бывает: после миграции приложения на СУБД PostgreSQL часть запросов начинает выполняться медленнее. Планировщик выбирает индекс, созданный по меньшему числу столбцов, время выполнения увеличивается, потому что при использовании такого индекса индексные записи указывают на строки таблицы, которые не соответствуют условиям соединения. При выборе же индекса по большему числу задействованных в запросе столбцов время выполнения становится существенно ниже и практически не зависит от размера таблиц.
В статье детализируется часть доклада Максима Старкова на конференции PG BootCamp, которая прошла в апреле в Екатеринбурге. Описываются признаки таблиц и индексов, при работе с которыми может возникнуть проблема выбора худшего индекса, а также рассматривается пример, демонстрирующий, что строка "Buffers" характерна для определения эффективности выполнения запроса (в 18 версии PostgreSQL "Buffers" будет показываться в планах по умолчанию).
Привет, Хабр!
Сегодня мы рассмотрим Resource Groups в MySQL — и перестанем жить на одной CPU.
Resource Groups — это контроль над CPU прямо из SQL. Вы создаёте логическую группу, говорите «эта группа может использовать только 2 CPU и работать на низком приоритете», и назначаете туда тяжелые, но второстепенные задачи. Всё. Дальше MySQL сам всё регулирует.
Что общего у систем видеоконференцсвязи (ВКС), финансовых транзакций и авиаперевозок? Все они должны работать всегда, когда нужны людям. Сегодня расскажем, как мы строили георезервирование для инфраструктуры, что пошло не так и какие выводы сделали. Перед вами — true story, как мы помогаем одному из наших заказчиков сопровождать инфраструктуру большого критичного сервиса.
Привет, Хабр! Это Никита Турцаков и Алексей Кузьмин из К2.
В этой статье расскажем:
• зачем и для чего нужно георезервирование для системы ВКС;
• как мы подошли к выбору архитектуры;
• с чем столкнулись при реализации;
• и что бы сделали по-другому, если бы начинали сейчас.
Готовьтесь: будет много практики и немного боли — потому что как без неё в масштабных и амбициозных задачах.
ScyllaDB — это высокопроизводительная NoSQL база данных, созданная как улучшенная версия Apache Cassandra на C++. Она способна обрабатывать миллионы операций в секунду, что делает ее лидером среди распределенных баз данных. Такая производительность достигается благодаря особой архитектуре хранения данных, в центре которой находится процесс компактизации данных. Правильный выбор стратегии компактизации данных и ее оптимизация - это ключ к высокой производительности и отказоустойчивости распределенной базы данных ScyllaDB.
В этой статье рассмотрены все стратегии компактизации, их преимущества и недостатки, а также приведен детальный алгоритм выбора стратегии компактизации под конкретные use cases.
1. Назначение
CJON – это легковесный, компактный и человекочитаемый формат, предназначенный для использования в условиях ограниченных каналов связи, таких как SMS, DTMF, и низкоскоростная радиосвязь. Его основное назначение – передача структурированных телеметрических или управляющих данных в случаях, когда традиционный JSON слишком объёмен, а бинарные форматы непрактичны или плохо читаемы.
2. Области применения
• Дистанционная телеметрия для сельского хозяйства и промышленного оборудования
• Аварийные сообщения и тревоги
• Автоматизация в условиях низкоскоростной или оффлайн-связи
• Мобильные устройства, передающие структурированные данные через SMS или голосовую связь
• Передача данных по DTMF через GSM-сети
Всех постоянно интересует, как сделать Postgres быстрее, эффективнее и всё такое, но никто не задумывался, как её замедлить. Да, большинству этих людей платят за то, чтобы они повышали скорость, но ко мне это не относится. Недавно я писал более полезное руководство, и мне вдруг пришла мысль, что кто-то должен попробовать создать такую конфигурацию Postgres, которая будет настроена на максимально медленную обработку запросов. Зачем? Сложно сказать, но вот такая возникла мысль.
Процессная аналитика (Process Mining) — это методология сбора и анализа информации о бизнес-процессах. Она помогает составить реальную схему процессов, разобраться в их работе и найти узкие места, требующие вашего внимания. Также процессная аналитика помогает выявлять «нетипичные» пути прохождения и прогнозировать работу бизнес-процессов.
Мы рассмотрим подробнее эту методологию и особенности её применения. А также на нескольких примерах из практики М.Видео-Эльдорадо и Т1 покажем, чем процессная аналитика может быть полезна в компании.
Время от времени приходится слышать мнение, что Postgres никуда не годится для решения задач аналитики. При при этом, в качестве аргументации приводятся в пример результаты тестирования на TPC‑H или ClickBench. Что ж, когда стоит простая задача перебрать 100 млн строк на диске и посчитать набор агрегатов над ними — формат хранения и распараллеливания действительно сильно ограничивают нас в возможностях оптимизации СУБД. Однако когда запросы высоко селективны, им по факту требуется не так много строк таблицы и фокус внимания смещается на порядок JOINов, кэширование промежуточных результатов и минимизацию операций сортировки. В этом случае Postgres, имеющий весьма широкий выбор различных стратегий выполнения запроса, может получить преимущество...
Предлагается к рассмотрению метод динамического определения форматов хранения и типов индексации в таблицах аналитической базы данных Dimension DB. На основе метаданных из источников данных (SQL-запросов, таблиц или представлений) определяется формат хранения или представления данных, а по текущему распределению данных, автоматически определяется тип индексирования.
Когда ресурсы сервера уже на пределе, вертикальное масштабирование рано или поздно перестаёт работать — остаётся горизонтальный подход. В этой статье подробно разбираем два способа шардирования в Postgres Pro: Shardman и внешнее расширение Citus. Сравним архитектуры, межузловое взаимодействие, схемы распределения данных и сценарии, в которых каждое решение раскрывается по‑максимуму.
В современных условиях возрастает актуальность выгрузки данных из SAP ERP в хранилища данных DWH или Data Lakehouse сторонних вендоров. Интеграция с системами, не входящими в экосистему SAP, зачастую сопровождается сложностями: поставщики программного обеспечения, как правило, не поддерживают использование конкурентных продуктов. Нативный механизм выгрузки данных в SAP BW (Business Warehouse) не может быть применен к системам, не принадлежащим к экосистеме SAP.
На нашем проекте внедрения хранилища данных на основе Arenadata DB для одного из крупных банков мы столкнулись со сложностями при интеграции с SAP S/4HANA.
В статье рассматривается решение, которое позволяет быстро и надежно производить выгрузку больших объемов данных.
Event Sourcing и CQRS — это мощные архитектурные подходы, которые заменяют традиционное CRUD-управление состоянием на журналирование событий и разделение операций записи и чтения для масштабируемости и надежности. Вместо прямого изменения данных система сохраняет каждое изменение как событие, что обеспечивает полный аудит, контроль конкурентности и гибкость в обработке данных.
