БигДата всегда звучит красиво — пока не нужно по ним искать и за нее платить.
Когда данные перестают влезать в индекс, а поиск тормозит — дело не в БД, а в архитектуре.Рассказываю, как мы перестроили систему на связке PostGIS + OpenSearch и добились отклика в десятки миллисекунд.
Привет, Хаброжители! В наши дни приложения реального времени стали нормой. Но для построения корректно работающей модели требуется, чтобы данные обрабатывались на лету и анализировались с низкой задержкой. Из этой практической книги инженеры, архитекторы и аналитики данных узнают, как использовать потоковые базы данных для создания решений, действующих в режиме реального времени.
Привет, Хабр!
Меня зовут Сергей Соловьёв, я руководитель отдела методологии в компании BPMSoft. Мы являемся разработчиком одноименной CRM-системы на базе low-code платформы со встроенными ИИ-инструментами. По версии Фонда Сколково и аналитического центра TAdviser, а также консалтинговой компании «Технологии доверия» – лучшей на российском рынке в 2024 году. В этой статье я расскажу, как мы управляем данными в собственной CRM и как это повышает эффективность бизнес-процессов.
Как появляется хаос
Разные подразделения компании работают с разными данными. Бухгалтерии важны название юридического лица и банковские реквизиты, отделу продаж — история взаимодействия с ним и потенциал кросс-продаж. При этом информация в CRM не всегда вносится корректно, что затрудняет поиск и работу с карточками клиентов. В результате данные оказываются фрагментированными и разрозненными: одному контрагенту нередко могут соответствовать две разные карточки.
Дубли контрагентов приводят к организационным проблемам. Если в CRM заведены две карточки одного клиента, разные менеджеры могут вести с ним параллельные переговоры, даже не подозревая об этом.
Проблема становится критичной по мере роста бизнеса и увеличения числа ошибок, связанных с некорректным ведением данных. Когда такие ситуации приобретают массовый характер, компании осознают необходимость системного управления. Однако на ранних этапах этому, как правило, не придают значения — в фокусе остается выбор и использование решений для автоматизации продаж и маркетинга. Чтобы эти процессы автоматизации работали точно, как швейцарские часы, нужно уделить внимание порядку в данных, от которого напрямую зависит эффективность использования новых систем и решений.
База данных — это сердце системы. И в какой-то момент это сердце начинает давать сбои. Не от объема данных, а от их разнородности. Таблица users разрастается до 200 колонок. Одни нужны для логина каждую секунду, другие — для годового отчета раз в год. В итоге, чтобы прочитать два "горячих" поля, база тащит с диска целый блок с "холодными" данными. Это неэффективно.
Один запрос выполняется 100 мс, другой — меньше 1 мс. Оба делают одно и то же, но второй написан на странном, почти алхимическом SQL. В чём подвох? Первый использует OR, а второй — хитрую комбинацию AND. Этот перевод — расследование того, почему условие OR так дорого обходится вашей базе данных, и практическое руководство по тому, как проектировать схемы, чтобы избежать этой ловушки производительности.
Когда в инфраструктуре десятки сервисов и баз данных разных типов, ручное резервное копирование превращается в кошмар.
Один сервер использует PostgreSQL, другой — MySQL, третий — MongoDB, и для каждого нужны свои команды (pg_dump, mysqldump, mongodump) и свои скрипты.
Проект Dumper решает эту проблему он объединяет все типы баз в один универсальный инструмент.
Dumper написан на Go и работает через CLI, конфигурация задаётся в YAML — поэтому его легко встроить в cron, CI/CD pipelines, GitHub Actions или Docker-окружение.
В сегодняшней, уже третьей по счету, публикации я продолжу делится результатами нагрузочных испытаний вычислительных технологий массивных параллельных вычислений (на Habr уже представлены мои материалы, посвященные сравнению Impala, Trino и Greenplum, в том числе по методике TPC-DS). В этот раз в список решений добавляется Spark, включая работающий с технологией нативных вычислений DataFusion Comet, и набирающий популярность StarRocks.
Базы данных превращаются в «открытую книгу», когда конфиденциальная информация из них становится доступна злоумышленникам или широкой публике из-за утечек. К сожалению, 2024-2025 годы принесли множество таких утечек – в самых разных отраслях. Согласно данным Роскомнадзора, только в России за 2024 год было зафиксировано 135 утечек баз данных, затронувших более 710 млн записей о россиянах. Лидерами по количеству утечек стали торговый сектор и государственные организации. В мире тенденция схожая: глобально число утечек и скомпрометированных записей бьёт рекорды. В этой статье будут разобраны недавние громкие кейсы утечек по секторам (энергетика, госсектор, e-commerce и др.), проанализируем технические причины: от открытых портов NoSQL и слитых резервных копий до уязвимых CI/CD-пайплайнов, а также практические рекомендации, как не допустить, чтобы ваша база данных стала общедоступной библиотекой. Мы в Security Vision также рассматриваем эти задачи как ключевые в разработке решений нового поколения, в том числе в области автоматизации защиты баз данных и безопасной разработки.
Как вы думаете, сколько человек документирует продукты в Postgres Professional? 50? 100? А вот и нет — всего десять. Рассказываем, как команде техписателей удается управлять сотнями файлов, почему их работа — это квест, и как они успевают контрибьютить в ванильный PostgreSQL.
Предстоящий релиз Valkey 9.0 несёт в себе значительные улучшения в отказоустойчивости больших кластеров, позволяя масштабироваться до 2000 узлов и достигать производительности свыше 1 миллиарда запросов в секунду, и всё это с гарантированно ограниченным временем восстановления. В этой статье мы рассмотрим, как работает система кластеризации Valkey, а также архитектурные усовершенствования и тщательное тестирование, которые сделали возможным такой уровень масштабирования.
Всем привет! Меня зовут Анастасия Козлова, я Senior BI Analyst в маркетинге Skyeng. Сегодня хочу рассказать, как мы научились справедливо оценивать вклад каждого рекламного канала с помощью кастомной мультиканальной модели атрибуции, что нас к этому подтолкнуло и как мы её настроили технически.
ClickHouse — одна из самых популярных систем для анализа данных. По информации TheirStack, этот инструмент использует более 3 700 компаний по всему миру.
У ClickHouse быстрая аналитика, эффективное сжатие и отличное масштабирование. Но у системы есть и недостатки — ограниченная поддержка UPDATE и DELETE, а также сложная миграция.
Привет, Хабр! Меня зовут Михаил Филимонов, я руковожу разработкой хранилища данных в группе Магнит OMNI. В этой статье я расскажу о проблемах работы с ClickHouse, как их решать и какие инструменты для этого потребуются.
Миграция PostgreSQL — редкий проект, где «быстро и безболезненно» почти никогда не совпадают. Дамп/восстановление годится для сотен гигабайт, потоковая репликация по WAL — для тех, у кого есть к ней доступ. Но когда простоя не хочется, а WAL недоступен, остаётся третий путь — логическая репликация.
В этом материале — практический сценарий: как заранее перенести схему, обеспечить уникальную идентификацию строк (PK/уникальный индекс/REPLICA IDENTITY FULL), настроить публикации и подписки, следить за первичной загрузкой через pg_stat_subscription, корректно остановить запись на источнике и синхронизировать последовательности.
Интеграции и обмен данными сегодня — это не просто техническая задача, а фундамент цифровой зрелости бизнеса. Российский рынок переживает быстрые изменения: уход западных вендоров, рост требований к надёжности и безопасности, распространение микросервисных архитектур. Как компании справляются с вызовами, когда стоит менять старую интеграционную платформу, зачем бизнесу API Gateway и брокеры сообщений, и можно ли обойтись без интеграционной шины?
Лайфхаки для миграций, оптимизации и избегания граблей
Реальные лайфхаки и проверенные практики по миграциям, оптимизации запросов, управлению индексами и обратной совместимости кода. Узнайте, как:
• Не сломать прод при миграции.
• Избежать N+1 и других проблем SQL-запросов.
• Планировать откаты и работать безопасно на высоконагруженных БД.
Говоря о серьезных кластерах в компаниях, нам часто приходится взаимодействовать со сторонними отделами и их данными. И зачастую, когда речь идет об ad-hoc, самый эффективный инструмент - Trino. Он удобен тем, что в платформе данных можно добавить каталог, который позволит по сути избежать настройки коннекшена для конечного пользователя. Просто в запросе указываешь название каталога данных и трино сам понимает, что нужно взять данные со сторонней базы данных. Но все меняется, когда выразительности SQL нам перестает хватать для выполнения поставленных задач и мы переходим в Spark. Точнее, менялось. С релизом Spark 3.0 появилась возможность взаимодействовать с внешними источниками так же просто, как в Trino.
Давно прошло то время, когда люди стояли в длинных очередях для покупки билетов на концерты, авиарейсы, фильмы, матчи и другие события.
Технологические компании наподобие Ticketmaster, BookMyShow, Airbnb, Delta Airlines и так далее сделали бронирование делом одного клика, позволившим покупать билеты из дома.
Эта простота стала возможной благодаря технологическим платформам и сервисам, которые прячут от пользователей всю сложность и решают неординарные инженерные задачи. Одна из таких задач — предотвращение бронирования одного места несколькими пользователями.
Представьте, в каком положении окажутся два пользователя, купившие одно и то же место на мероприятие и осознавшие это только перед его началом. Из-за этого организатор теряет доверие покупателей, а пользователи дважды задумаются, прежде чем покупать билеты на следующее мероприятие.
Поэтому важно создать надёжное решение классической задачи — двойного букинга.
Из этой статьи вы узнаете, как эту задачу решают разные технологические компании. У каждой компании свои особенности, поэтому единого универсального решения нет.
Мы рассмотрим различные архитектурные паттерны и разберёмся в их плюсах и минусах. Статья поможет вам обрести глубокое понимание и наработать знания в системном мышлении.
Давайте честно – пока что Postgres редко используется для действительно больших и нагруженных баз. Этому множество причин, но главная формулируется просто: «не тянет».
У каждого есть своя граница, где Postgres ещё применим, а дальше —уже нет. Обычно это где-то между одним и пятью терабайтами, дальше жить с этим «больно».
База просто не может обработать большой объем данных с той скоростью, которую способны выдать диски.
И вот — Postgres 18, впервые за долгое время, предлагает не косметическую, а фундаментальную новинку. То, что в Oracle есть уже 20+ лет — асинхронный ввод-вывод (аsync IO).
Попробуем посмотреть async IO и ответить на вопрос - стал ли Postgres ближе к «взрослым» нагрузкам?
Примечание: Статья посвящена формату XBRL-CSV2 (тэг "@context":"www.cbr.ru/xbrl_csv2").
Авторство формата принадлежит Банку России.
Автор статьи — архитектор, принимавший участие в разработке формата в качестве технического специалиста.
Введение.
Банк России использует стандарт XBRL для сбора отчетности от некредитных финансовых организаций. Несмотря на всю продуманность XBRL, при формировании и обработке отчетности возникает проблема, связанная с реестровыми формами.
Эти формы содержат гиперкубы с открытыми осями. При большой вариативности значений таких осей реестровые отчеты становятся чрезвычайно объемными.
Решение этой проблемы — создание производного от XBRL-XML формата: XBRL-CSV.
Основная предпосылка: CSV органически приспособлен для хранения реестровых форм. Открытые оси выносятся в начальные колонки, а комбинации значений ячеек открытых осей в каждой строке образуют составной открытый ключ, однозначно идентифицирующий запись.
Остальные колонки — это данные, которые определяют три аспекта показателя:
В прошлый раз, в первой части нашего гида по Apache Cloudberry™, мы поговорили об истории проекта, его архитектуре, ядре СУБД и функциях платформы.
Но помимо ядра СУБД, мы также хотим использовать data‑lakehouse‑запросы. В Data Lakehouse есть некоторые проблемы: мы не можем получать данные оттуда напрямую. В Cloudberry разработана технология, с помощью которой можно это делать, так что поговорим об этом подробнее. А также рассмотрим ещё несколько интересных возможностей и расскажем о планах проекта.
