SQL *

В мире .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. Акцент сделан на тех различиях, которые позволили обеспечить максимальную эффективность и универсальность виртуальной СУБД.

Виртуальная СУБД. Язык определения данных (DDL).

Эта статья является продолжением серии статей посвященной новой системе разработки клиентских приложений KISS Virtual XML RDBMS.

Виртуальная СУБД - это чисто объектная система управления реляционной XML базой данных. Язык определения данными представлен в виртуальной СУБД базовым классом tblschema (схема виртуальной таблицы). Этот класс предназначен для объектного представления словарей (метаданных) различных физических СУБД. Одной из главных целей создания виртуальной СУБД было обеспечение ее независимости от конкретных физических СУБД, поэтому потребовалось создать собственный универсальный объектный инструмент для определения и корректировки стандартизированных метаданных, совместимый со всеми реляционными СУБД.

В статье описаны основные понятия, возможности и особенности этого объектного языка.Акцент сделан на тех особенностях схемы виртуальной таблицы, которые позволили обеспечить максимальную эффективность, гибкость и универсальность виртуальной СУБД. Также появились уникальные возможности виртуальной СУБД, которые стали доступны для всех физических СУБД.

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

Сегодня поговорим про одну из тех тем, что вроде бы тривиальна, но до последней капли грязи тащит за собой внушительный пласт вопросов. Речь пойдёт про COUNT(*) и COUNT(col) в PostgreSQL.

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

Сегодня рассмотрим, как использовать F()-экспрессии и Func()-обёртки в Django для того, чтобы выполнять арифметику, условия и преобразования не в Python, а на стороне базы данных. Один SQL-запрос может заменить десятки строк кода не теряя в качестве кода.

На этот раз более простая и красивая визуализация. Речь пойдет о том, как нарисовать историю выполнения SQL Agent jobs — как раз тех, с которыми все время имеет дело DBA.

Привет, Хабр! Это Ахмед Шериев, сооснователь стартапа VoxOps, а сегодня — еще и гостевой автор блога Friflex. Моя статья — про опыт разработки офлайн-приложений. 

Я делал офлайн-поддержку в приложениях на самых разных языках. Как вовремя и успешно, так и с факапами. Например, обещал за две недели внедрить офлайн, а потом появлялись скрытые кейсы, и разработка затягивалась до месяца, двух, трех… 

Здесь постараюсь поделиться, как не зарыться в тонну инфраструктурного кода и избежать некоторых других ошибок.    

Я внедрял поддержку offline как в роли разработчика, так и в роли руководителя и директора по разработке. Поэтому тема мне хорошо знакома с обеих сторон. Кто помнит, с ней я выступал на CrossConf.

В статье рассматривается использование теста TPC-H с PostgreSQL и проблемы, связанные с запросами Q17-Q20 теста.

Введение

Вместе с PostgreSQL поставляется утилит pg_bench с "TPC-B like" тестом. Кроме этого теста были созданы тесты TPC-R для отчётов, TPC-D для OLAP, TPC-W для заказов в веб-магазине, которые не получили распространения. На основе TPC-D был создан более удачный тест TPC-H для хранилищ данных и аналитических запросов ("OLAP нагрузка"). В тесте используется 8 таблиц и 17 ограничений целостности. В TPC-H выделены номинации по размерам обрабатываемых данных от "до 100Гб" до  30-100Тб. Тест TPC-H предназначен для хранилищ данных, включает в себя 22 запроса, которые называют Q1 ... Q22.

Запросы теста TPC-H не меняют данные в таблицах, а значит, для повторных тестирований не нужно пересоздавать или вакуумировать таблицы. В тестах TPC-B, TPC-C, TPC-E запросы довольно простые. В реальных приложениях запросы более сложные, чем в этих тестах. Поэтому для тестирования того, как СУБД выполняет запросы, которые могут встретиться в реальных приложениях, можно использовать все или отдельные запросы из теста TPC-H. Для быстрого аудита производительности различных СУБД используют вариант с 1Гб данных. В этом варианте запросы выполняются быстро, не нужно много памяти под экземпляр СУБД и много места на диске. Можно найти программы или скрипты для большинства СУБД, например, для PostgreSQL, Oracle Database, MySQL. После теста TPC-H появился тест TPC-DS с 99 запросами, но он менее популярен.

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

Сегодня рассмотрим, как на голом SQL построить полноценный когортный анализ: определим дату первой покупки, сгруппируем пользователей по когортам, посчитаем удержание (retention), оценим LTV по месяцам жизни и сделаем RFM-сегментацию.

Я уже не раз поднимал в статьях тему [не]эффективной работы с json[b] в PostgreSQL — и как его лучше превращать в выборку, и как можно «транспонировать». Сегодня же рассмотрим некоторые возможности по его генерации на стороне базы.

В моей предыдущей статье я отображал метрики из записанного SQL profiler trace на листинг stored процедуры. Это идеально подходит к тестовым окружениям, но в production надо быть осторожным, и запись "частых" событий могут увеличивать CPU сервера и замедлять его работу.

@speshuric предложил использовать данные из Query Store. Там, правда, нет номеров строк. Но можно выкрутиться, так как есть смещения и можно посчитать количество переводов строки до смещения. Итак, сказано - сделано!

Привет! Меня зовут Андрей Дорожкин, и я руковожу командой администрации баз данных в Hybrid. В этом материале я поделюсь опытом работы с ClickHouse — колоночной БД, разработанной специально для аналитических запросов, которая позволяет получать результаты в разы быстрее традиционных решений. Также я подсвечу, как устроен этот продукт, чем он отличается от реляционных баз данных, и в каких сценариях его использование может дать бизнесу реальное преимущество.

Пара слов о компании Hybrid. Мы — независимая AdTech-экосистема с собственным стеком технологий и решений для любых рекламных целей. Развиваем собственные технологии благодаря in-house отделу разработки, который каждый день работает над их улучшением. ClickHouse — инструмент, который мы выбираем для хранения данных за высокую скорость обработки запросов, эффективное сжатие данных и масштабируемость.

Выбор облачного хранилища данных — задача не из простых: десятки решений, каждая со своими плюсами и подводными камнями. В этой статье — результаты масштабного практического исследования, в ходе которого команда Agritask сравнила производительность, масштабируемость, стоимость и совместимость SQL ведущих платформ: от ClickHouse и BigQuery до Druid и Firebolt. Без маркетинговых обещаний — только реальные тесты, живые выводы и нюансы, которые неочевидны до момента внедрения.