Всем привет! В данной статье я поделюсь своим опытом написания сервиса. Я не являюсь опытным или профессиональным разработчиком, я пишу свой проект и мои решения могут быть не самыми оптимальными. Эта статья состоит в основном из ошибок, которые я совершил. Мой путь не является правильным и потому - судите "строго".
Всем привет! Меня зовут Илья Криволапов, тружусь системным аналитиком в SENSE на проекте одного из цветных банков РФ. В профессии я уже пятый год и, несмотря на фамилию, ломал прод всего лишь несколько незначительных раз (надеюсь).
На досуге я преподаю в университете дисциплину «Хранение и обработка больших объемов данных» и за все время у меня накопилось много полезной информации. Непростительно хранить такой клад у себя в столе, поэтому я подготовил для читателей Хабра ультимативный гайд по оптимизации или хорошему такому, грамотному проектированию баз данных с расчетом на масштабирование.
Всего в цикле будет 3 статьи. В первой поговорим о двух разных подходах масштабирования БД и о том, как лучше его делать и как лучше не делать (Никогда. Пожалуйста).
Кому будет полезно? Всем отвечающим за «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.
Согласны? Узнали? Тогда поехали!
В современных компаниях корпоративные хранилища данных (Data Warehouse) играют критически важную роль, обеспечивая централизованное хранение и обработку больших объёмов информации. Данные поступают из разнообразных источников: операционных систем, CRM, ERP, IoT-устройств, веб-аналитики, мобильных приложений и других платформ, отражая все аспекты деятельности организации. На основе этой информации компании формируют разного рода отчётность, отслеживают ключевые показатели эффективности (KPI), оптимизируют бизнес-процессы, прогнозируют рыночные тенденции и принимают стратегические решения.
Эффективная работа с хранилищем невозможна без участия бизнес- и системных аналитиков, которые проектируют структуры данных, очищают и объединяют информацию, адаптируя решения под меняющиеся задачи. С ростом объёмов данных и требований к скорости анализа даже опытные команды сталкиваются с вызовами. Рутинные операции — проектирование схем, поиск таблиц, проверка качества данных — требуют не только технических навыков, но и глубокого понимания бизнес-контекста. Большую часть времени занимает написание и оптимизация SQL-запросов, что становится «узким местом» в условиях динамично меняющихся требований.
Ошибки в SQL-запросах или недостаточное знание структуры данных приводит к потерям времени и снижению точности аналитики. Для решения этих проблем на помощь приходят технологии на основе больших языковых моделей (LLM), таких как GigaChat, GPT, BERT или DeepSeek. Обученные на исторических данных и журналах запросов, они способны автоматизировать подбор таблиц, JOIN-условий и шаблонов SQL.
Давайте честно: совместный доступ к документам — одна из главных «болей» для всех, кто хоть как-то связан с базами данных. Вроде бы оба пользователя могут работать с файлом, но есть один нюанс: например, количество предоставленных доступов может быть больше, чем их есть на самом деле. Или у документа и вовсе появляется несколько владельцев. Для всего этого требуется решение – и мы его нашли!
Меня зовут Владимир Ревякин, я старший инженер-программист компании «МойОфис», и вместе с QA-инженером Анной Рукавицыной мы подготовили этот материал, чтобы поделиться опытом реализации функции шаринга данных через графовую базу ArangoDB в рамках разработки платформы «Документы Онлайн». Если коротко — это продукт для совместной работы и хранения документов в рамках единой мультипродуктовой экосистемы.
В российских источниках не так много полезной информации по ArangoDB, и наша задача — исправить это недоразумение. Разберем главные нюансы работы с этой системой БД в разработке и тестировании, вспомним ее плюсы, минусы и потенциальные баги. Текст будет полезен как инженерам любых грейдов, которые связаны с работой над базами данных (сил вам...), так и классическим разработчикам продуктов.
Задачи на собеседованиях. Денежные переводы в SQL. Обновление счетов и уровни изоляций
Задача перевода денег в первом приближении сводится к обновлению пары строк и кажется простой — но обеспечение корректности при параллельном доступе может быть неожиданно сложным для только знакомящихся с уровнями изоляций БД.
Большие языковые модели (Large Language Model, LLM) используют в разных областях: с их помощью генерируют программный код, ищут информацию, озвучивают реплики чат-ботов. А вот при работе с реляционными данными языковые модели часто ошибаются.
Чтобы справиться с этими ошибками, в мы разработали три пайплайна для работы с базами данных. Эти пайплайны представляют собой цепочку связанных между собой языковых моделей: каждая из них генерирует свой ответ, и следующая модель работает с ответом предыдущей. Таким образом мы получаем дополнительный контекст, и запрос к базе данных становится точнее.
Привет, Хабр!
Меня зовут Сергей Аладышев, работаю системным аналитиком на протяжении 10 лет, и в работе часто сталкиваюсь с задачами, в том числе типовыми, решения для которых выглядят понятными, но не всегда оптимальными, а главное затратными по времени.
Появляется непреодолимое желание их оптимизировать. Сегодня хочу обсудить похожую задачу: «поиск разрывов истории записей», она же: «поиск разрывов истории SCD2 в SQL». С задачей сталкивался несколько раз, но статей с её разбором не нашел, поэтому решил, что тема актуальна.
Началось все, как и всегда, с получения исчерпывающих требований от заказчика:
Вопрос оптимального количества индексов часто становится предметом горячих дискуссий среди разработчиков и администраторов баз данных. Одни утверждают, что больше индексов означает лучшую производительность, другие предупреждают о рисках избыточности и снижении эффективности операций записи. Но как определить золотую середину?
Далее предлагаем вашему вниманию перевод оригинальной статьи “How Many Indexes Is Too Many?”, который подготовила специалист «Автомакона». В статье детально рассматривается данная проблема и приводятся практические рекомендации по выбору подходящего количества индексов для повышения производительности.
Для начала давайте рассмотрим простой эксперимент. Возьмем популярную базу данных Stack Overflow любого размера, уберем все индексы из таблицы Users и запустим удаление одной строки командой DELETE.
Привет! Меня зовут Кирилл Львов, я fullstack-разработчик в компании СберАналитика. В этой статье хочу рассказать про мощный инструмент трансформации данных — DBT (Data Build Tool).
Сегодня любой средний и крупный бизнес хранит множество данных в разрозненных источниках (CRM, ERP, HRM, базы данных, файловые хранилища и т.д.). Каждая из этих систем самодостаточна и закрывает определённую боль бизнеса, но собрав данные из таких источников и стандартизировав их, нам открывается возможность анализировать данные, строить модели машинного обучения и принимать на основе этих данных управленческие решения. Для того чтобы реализовать такой подход строятся ELT (или ETL) процессы. ELT (Extract, Load, Transform) — это процесс, состоящий из трех этапов:
Привет, Хабр!
Сегодня поговорим про ретеншн — ту самую метрику, от которой часто пляшут все продуктовые команды. Вы знаете: «вернулся через 7 дней» (D7) — и сказано, что мы класс
Но на деле класс ломается, как только продукт усложняется. В этой статье рассмотрим, почему классический D7 retention не работает, как построить настоящие кривые удержания через когорты, в чём разница между recurring vs one-shot поведением, какие есть альтернативные метрики и сравним три метода.
Информационный ландшафт современного мира стремительно меняется, что порождает новые вызовы и риски для организаций любого масштаба. В частности, в финансовом секторе зависимость от современных технологий достигла беспрецедентного уровня, делая жизненно важным поддержание операционной устойчивости информационных систем и коммуникаций.
В свете указанных обстоятельств Совет Европейского союза разработал специальный нормативно-правовой акт — Закон о цифровой операционной устойчивости (Digital Operational Resilience Act, сокращенно — DORA). Принятый в ноябре 2022 года, данный закон направлен на создание единой правовой основы, способствующей усилению защиты финансовых учреждений и иных операторов рынка от различных видов угроз, связанных с работой информационных и телекоммуникационных технологий (ИКТ).
Четыркина Дарья перевела статью, в которой детально рассмотрели положения Закона о цифровой операционной устойчивости, проанализировали его влияние на архитектуру и эксплуатацию баз данных, а также предложить практические подходы и рекомендации по подготовке организаций к выполнению предъявленных требований.
В мире .NET разработки, работа с базами данных – неотъемлемая часть. Entity Framework Core (EF Core) предоставляет удобный способ взаимодействия с данными, но при работе с SQL Server, особенно в сложных сценариях, LINQ запросы могут уступать в производительности и гибкости T-SQL. Статья рассматривает эту дилемму, предлагая гибридный подход. Мы погрузимся в проблему: как эффективно использовать мощь T-SQL, не отказываясь от преимуществ EF Core? Обсудим интеграцию T-SQL через Raw SQL, Views, UDF и Stored Procedures. Раскроем лучшие практики: разделение ответственности, оптимизацию запросов, безопасность и тестирование. Поймем, как сочетать удобство ORM с производительностью SQL Server, применяя Data-Driven Design и, при необходимости, Domain-Driven Design. Статья – руководство для .NET разработчиков, стремящихся к оптимальному балансу между производительностью, гибкостью и удобством разработки при работе с SQL Server и EF Core.
Привет, Хабр!
Скользящие метрики — это must-have в аналитике, но даже простые на первый взгляд вычисления могут парализовать вашу СУБД. Сегодня рассмотрим, почему стандартные оконные функции зачастую тормозят, как их можно оптимизировать через явные фреймы, когда выгоднее писать агрегаты вручную, как использовать предагрегированные таблицы и как проверять корректность расчётов на границах окон.
Привет, Хабр.
Сегодня рассмотрим, как разреженный временной ряд ломает оконные функции (LAG, LEAD, SUM OVER и др.), посмотрим как находить дыры и заполнять их, чтобы метрики не сыпались и строки не дублировались.
Supabase с оценкой в $2 млрд стремительно становится технологическим фундаментом современного вайб-кодинга. Почему разработчики массово переходят на этот бэкенд с открытым исходным кодом, и как PostgreSQL-решение превратилось в незаменимый инструмент для AI-приложений, используемый в 29% стартапов последнего набора Y Combinator? История компании, чья ценность оказалась настолько высокой, что инвестор пролетел 17 часов до отдалённого уголка Новой Зеландии для встречи с её основателем.
Продолжаем обсуждать серверы в контуре высоконагруженных 1С-систем. В предыдущей статье я рассматривал типичные проблемы с серверами СУБД, а сегодня перейдем к серверам 1С. Причем не хочется, чтобы пост превратился в очередной универсальный перечень настроек сервера 1С на все случаи жизни. Поэтому будем смотреть на задачу через призму производительности системы. Главное, сначала увидеть картину целиком, понять причину и, исходя из этого, менять пусть те же самые настройки 1С.
Цель статьи — подсветить несколько достаточно распространенных, но не всегда очевидных проблем производительности ИТ-системы, находящихся на стороне сервера(ов) 1С.
Естественно, я не планирую разбирать очевидные вещи из серии «Хьюстон у нас проблемы. Нагрузка на CPU — 100%, пользователи в истерике». Но начну как раз с процессора :-). Тут есть что рассказать.
Привет, Хабр! Меня зовут Николай Литковец, я инженер-разработчик в СберТехе, развиваю СУБД Pangolin — это реляционная СУБД, целевая в Сбере и не только. До недавнего времени у нас было два типа обновлений СУБД — минорное и мажорное. Минорное обновление — быстро и сравнительно просто, мажорное — долго, муторно, со значительными затратами ресурсов сервера. Мы стали думать, можем ли мы где-то обойтись без перехода на мажорные версии? Нашли сценарий, где это было возможным и через время у нас появилось минорно-мажорное обновление, которое теперь экономит нам силы и время. В этой статье расскажу про создание инструмента, который позволил нам устроить эту реформу, как мы его делали и обходили риски и что нам это дало.
Привет, Хабр! Это Ахмед Шериев, сооснователь стартапа VoxOps, а сегодня — еще и гостевой автор блога Friflex. Это вторая статья про мой опыт разработки офлайн-приложений — первая была про кэширование.
Если пользователи в офлайне должны менять данные, а потом синхронизировать изменения с сервером, есть два основных подхода. Первый — синхронизировать сами данные. Второй — синхронизировать команды или события.
В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos, Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.
Виртуальная СУБД. Язык манипулирования данными (DML)
Эта статья является продолжением серии статей посвященной новой системе разработки клиентских приложений KISS Virtual XML DBMS.
Виртуальная СУБД является чисто объектной и не использует явным образом язык SQL, но это не означает, что она является NoSQL СУБД. Виртуальная СУБД - это чисто объектная система управления реляционной XML базой данных. Язык SQL реализован исключительно объектными средствами.
Язык манипулирования данными представлен в виртуальной СУБД базовым классом recset (набор записей). В статье описаны основные понятия, возможности и особенности этого объектного языка. При этом рассматривается их связь с понятиями и возможностями языка SQL. Акцент сделан на тех различиях, которые позволили обеспечить максимальную эффективность и универсальность виртуальной СУБД.
