SQL *

Загрузить миллион записей в питон за секунду?
Нет. Получилось еще быстрее!

У меня есть небольшое хобби - я экспериментирую с машинным обучением применительно к торговле на бирже, в частности, с криптовалютами. После различных наколенных экспериментов я захотел создать удобный инструмент - базу торговых котировок. В процессе работы необходима быстрая загрузка достаточно большого количества данных. Это необходимо для расчетов, генерации данных для обучения, бэк-тестинга и других задач. Количество записей, которые нужно загрузить в питон довольно велико - речь может идти о миллионах и более записей.

Продолжаем следить за новинками будущей 16-й версии. В начале декабря завершился третий коммитфест и вот его результаты.

Самое интересное из первых коммитфестов можно прочитать в предыдущих статьях серии: 2022-07, 2022-09.

Расскажу о такой важной особенности работы СУБД TERADATA, как сбор и использование статистик при выполнении запросов и как их наличие или отсутствие может повлиять на скорость выполнения таких запросов. Попытаюсь объяснить, что представляют собой статистики и для чего они нужны TERADATA.

Достаточно часто при проектировании схемы БД возникает задача сохранить по основной сущности некоторый набор простых второстепенных данных.

Например, это могут быть ФИО сотрудников, принимающих участие во встрече, список приложенных к сообщению файлов или перечень отгружаемых по документу позиций.

Во всех этих случаях мы заранее понимаем, что список этот меняется редко и ни индексировать эти данные, ни искать по ним, ни извлекать отдельно от основной сущности (встречи, сообщения или документа), мы не захотим.

Давайте посмотрим, какие варианты хранения таких данных мы можем использовать в PostgreSQL, и какой из них окажется в разы более эффективным.

Привет, Хабр! Меня зовут Антон, я – старший разработчик в отделе разработки баз данных в IBS. В этой статье я расскажу о том, как нашей командой была решена задача по сохранению в ClickHouse большого количества данных, генерируемых веб-приложением, с последующим получением сохранённых данных в агрегированном виде.

Решение задачи, описанной выше, было бы простым и вряд ли заслуживающим отдельной статьи на Хабре. Но наш случай представлял собой ряд нюансов: здесь есть технические дубли записей и бизнес-дубли (обновления), есть агрегированные данные и необходимость обновления агрегированных данных. А это уже пример не совсем типичного использования ClickHouse, которым мы и хотим поделиться.

Некоторые базы данных такие, как Microsoft SQL Server, IBM Db2, а также PostgreSQL начиная с 11 версии – предлагают прибегнуть к оператору include для генерации индекса. Представление данного функционала в PostgreSQL (исходная статья вышла 30.04.2019) послужило поводом для этого объёмного рассуждения о работе с оператором include.

Содержание:

1)    Напоминание: btree-индексы

2)    Напоминание: Index-only сканирование

3)    Оператор include

4)    Фильтрация по полям в include

5)    Уникальные индексы при использовании include

6)    Сравнение

7)    PostgreSQL: Никакой фильтрации до проверки области видимости

Представим, что у вас есть некоторая табличка статистики, куда вы периодически скидываете таймстамп последнего "текущего" состояния в паре координат - например, (ID организации, ID сотрудника).

Как больно наступить на грабли в совсем простом, казалось бы, запросе?

Навскидку многим кажется, что они знакомы с поведением NULL-значений в PostgreSQL, однако иногда неопределённые значения преподносят сюрпризы. Предлагаем вашему вниманию расшифровку доклада Алексея Борщева с PGConf.Russia 2022 — он был полностью посвящён особенностям NULL-значений в Postgres.

NULL простыми словами

Что такое SQL база данных? Согласно одному из определений, это просто набор взаимосвязанных таблиц. А что такое NULL? Обратимся к простому бытовому примеру: все мы задаём друг другу дежурный вопрос: «Как дела?». Часто мы получаем в ответ: «Да ничего...» Вот это «ничего» нам и нужно положить в базу данных — NULL, неопределённое, некорректное или неизвестное значение.

Разработка отчета, как и обычная разработка, стоит времени программиста. Информация о количестве просмотров отчетов, количестве активных пользователей и многих других метрик, связанных с BI, может повысить эффективность вашей команды аналитики и помочь правильно отслеживать КПД вашей аналитики. Такие метрики каждая команда определяет для себя сама. Чаще всего они связанны с использованием отчетов и пользователями, которые их просматривают. Метрики, которые используются в нашей команде, и как реализовать отчет с ними в Metabase, рассмотрим в этой статье.

PostgreSQL 15 уже вышел официально. И в сети появилось множество информации о новинках версии.

А мы продолжаем знакомить с новинками будущей 16-й версии. В начале октября завершился второй коммитфест и есть что обсудить.

Самое интересное из первого, июльского, коммитфеста можно прочитать в предыдущей статье серии: 2022-07.

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

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

Сегодня я рассмотрю основные возможности BI-инструмента с открытым исходным кодом Metabase.

Мне всегда было интересно (и не только мне) есть ли смысл запуска 1С в диске из оперативной памяти, потому что если посмотреть на графики скорости чтения различных типов накопителей, то преимущества  очевидны:

Как быть, если случайно удалил или повредил таблицу в BigQuery? Первое о чем нужно помнить: BigQuery хранит состояние вашей существующей таблицы на любой момент времени в течение прошедших 7 дней + у вас есть 2 суток, чтобы восстановить случайно удаленную таблицу. Рассмотрим, как это все провернуть.

В середине 2015 года, в MySQL 5.7.8 появился тип данных JSON. С тех пор он применяется, чтобы избегать жёстких определений столбцов и сохранять документы JSON всех форм и размеров: логи аудита, параметры конфигурации, сторонние полезные нагрузки, пользовательские поля и др. Подробности — к старту нашего курса по анализу данных.

Писать SQL руками или использовать ORM — тема очень спорная, и я опишу, как использовать первый подход максимально эффективно. А какой из подходов выбрать, думаю, каждый сам для себя уже решил.

Учу SQL и понимаю, что схема Join-ов основанная на пересекающихся кругах не корректна. Результатом джойнов всегда идет увеличение таблицы в ширь. А по схеме с кругами площадь кругов почти везде не увеличивается. И также круговая схема не показывает заполнение NULL-ами при LEFT и RIGHT джойнах. Предлагаю схему на прямоугольниках, где закрашенный красный это результирующие данные в таблице после джойнов, черный это заполнение NULL-ами. Серые прямоугольники оставлены просто для наглядности и ничего не означают.