В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – 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. Без маркетинговых обещаний — только реальные тесты, живые выводы и нюансы, которые неочевидны до момента внедрения.

Вам интересно, какие индексы используются больше или меньше? Какие не используются вовсе? Какие таблицы и индексы самые большие? Очень легко создать такие диаграммы. Это и красиво, и полезно.

Привет, Хабр! Когда-то я проверяла завещания и готовила доверенности, а теперь проверяю витрины данных, ищу дубли и считаю доходность по инвестиционным инструментам. Меня зовут Арина Шахтарина, и я — Data Quality-инженер в Сбере. Это история о том, как любовь к данным и таблицам превратилась в новую профессию, и почему SQL — лучший универсальный язык после русского. Тут будет про карьерные повороты, боли с форматами данных, проверки данных и немного про мечты, которые сбываются (даже если ты не в отпуске).

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Сегодняшней статьей с простым использованием агрегирующих функций завершаем цикл. В итоге, PostgreSQL показал себя как очень удобное средство для решения разных алгоритмических задач, лишь несколько раз заставив нас изобретать совсем уж нетипичные подходы к написанию SQL-запросов.

Бум No-code начался в 2022 году, и сейчас многие компании стараются так или иначе внедрить функционал «low-code» в свои продукты. У участников IT-индустрии пока нет согласия о границах применимости технологий «без кода», хотя адепты этих технологий обещают, что они позволят создавать практически любые приложения.

В этой заметке мы рассмотрим один из основных аспектов создания приложений – его масштабируемость в средней и дальней перспективе. Для этого сам продукт под капотом должен быть построен на чем-то более мощном, чем MS Excel, Airtable, Notion и Make, и такие продукты уже есть на рынке.

Фатальные проблемы масштабируемости проявляются с ростом объемов данных и количества пользователей, которые с ними работают – с этого мы и начнём.

Выбор облачного хранилища данных — задача не из тривиальных, особенно когда речь идёт о миллиардах полуструктурированных записей, геоаналитике и требованиях к отклику в доли секунды. В Agritask мы провели масштабное исследование: протестировали популярные DWH-платформы на реальных кейсах, сравнили производительность, параллелизм и затраты. В первой части делимся подходом к оценке, техническими требованиями и тем, почему PostgreSQL и Snowflake перестали справляться с нашими задачами.

Предлагаю вашему вниманию немного дополненный доклад, который я делал на конференции PGConf.СПб 2024. В нем я рассказываю о том, как появились первые реляционные системы, как возник и всех победил язык SQL.

Приветствую всех хаброжителей и тех, кто читает мою статью. Меня зовут Александр, я являюсь ИТ директором с более 15-летним стажем, начинал в 2002 году обычным программистом в международной FMCG компании, что сильно повлияло на меня как человека и как ИТ специалиста.

Но статья не об этом, повествование пойдет о другом, об 1С и SQL, а именно о том, как быть если нужно выгружать данные из этой самой 1С, да еще, когда она не одна, да и в разных городах и странах. Трудился я в международной алкогольной компании и достался мне «зоопарк» ИТ систем (думаю, что многим понятно и известно, о чем я говорю). Среди этих систем была самописная ERP система с подчиненными базами (больше 100 штук) на базе СУБД Firebird и клиенты, написанные на Delphi и Microsoft С#, годами пока это все развивалось и росло, появились запросы и потребность в анализе данных и стали реализовываться различные выгрузки данных. Получаемые данные как тогда водилось стали выгружать в MS SQL в специально созданную базу (DWH) используя MS SSIS и потом трансформировались в OLAP кубы в MS SSAS. Еще была систем именуемая как «Бизнес-процессы» на базе 1С Бухгалтерия 1.6, с последующим обновлением и совместимостью, чтобы запустится на платформе 1С 8.3, на обычных формах с многокилометровыми модулями кода. Обшито все это было микросервисами (как сейчас это принято называть) и обменивалось между собой как-то, никому 100% не известно как.