Совет по работе с базой данных ⚡️

Иногда требуется получить, например, три последних заказа для *каждого* клиента. Обычные объединения не могут этого сделать. Приходится выполнять n+1 запросов в коде, что очень медленно!

Но с помощью lateral joins можно сделать циклическое соединение for-each в SQL


MySQL / PostgreSQL

SELECT customers.*, recent_sales.*
FROM customers
LEFT JOIN LATERAL (
SELECT *
FROM sales
WHERE sales.customer_id = customers.customer_id
ORDER BY created_at DESC
LIMIT 3
) AS recent_sales ON true;



https://sqlfordevs.com/for-each-loop-lateral-join

#db

👉 @database_info

Как получить id вставленной записи в mysql?

Вы можете использовать LAST_INSERT_ID() чтобы получить id последней вставленной записи в MySQL, ниже пример запроса на MySQL:

# INSERT INTO your_table (col1, col2,...) VALUES ('val1', 'val2'...);
SELECT LAST_INSERT_ID();

#db

👉 @database_info

Основные команды SQL

#db

👉 @database_info

SQL

С помощью всего нескольких базовых команд можно решить 80% повседневных задач, связанных с данными.
Сосредоточьтесь на понимании JOIN, SELECT, UPDATE, DELETE и некоторых других фундаментальных команд.

#db

👉 @database_info

Это база: нюансы работы с Redis. Часть 1

Cерия статей про неочевидные нюансы работы с Redis.

В первой части Петр, DevOps-инженер компании Nixys, подробно рассказал об основных концепциях и понятиях этой БД и подготовил чек-лист, который может помочь вам в оптимизации этого NoSQL решения.

Приятного чтения!

Команды SQL в двух словах

#db

👉 @database_info

Облачная нативная база данных на основе PostgreSQL, разработанная компанией Alibaba Cloud.

PolarDB for PostgreSQL (далее PolarDB) - это сервис облачных баз данных, разработанный компанией Alibaba Cloud. Этот сервис на 100% совместим с PostgreSQL и использует архитектуру с общим хранилищем, в которой вычисления отделены от хранения данных. Этот сервис отличается гибкой масштабируемостью, задержками на уровне миллисекунд и возможностями гибридной транзакционной/аналитической обработки (HTAP).

https://github.com/ApsaraDB/PolarDB-for-PostgreSQL

#db

👉 @database_info

SQL. Решаем ТЕСТОВЫЕ ЗАДАНИЯ из AMAZON и FACEBOOK (подробный разбор)

00:00 - Где искать задачи с собеседований IT-компаний?
00:53 - Решаем задачу из Amazon
09:36 - Решаем задачу из Facebook
20:44 - Задача со звездочкой из моей работы. Пишите ваши решения в комментарии!

источник

#db

👉 @database_info

Новое в SQL Server 2022: Обзор использования Intel QuickAssist

В SQL Server 2008 Enterprise Edition в команду резервного копирования T-SQL была добавлена опция сжатия резервных копий, в команде для этого нужно прописать WITH COMPRESSION. Эта опция обеспечивает возможность сжатия для всех типов потокового резервного копирования SQL Server — полного, разностного и копий журнала транзакций. Инструкция RESTORE распаковывает сжатые файлы резервной копии используя метаданные в заголовке файла копии. Сжатие данных в резервных копиях выгодно по двум причинам: во-первых, файлы резервных копий будут занимать меньше места, а во-вторых, поскольку передается меньше байтов, резервное копирование выполняется быстрее, чем для несжатых резервных копий. По умолчанию в SQL Server резервные копии не сжимаются, но многие меняют это значение по умолчанию сразу глобально, используя sp_configure.

Rus https://habr.com/ru/articles/773564/

Eng https://cloudblogs.microsoft.com/sqlserver/2023/03/09/sql-server-2022-intel-quickassist-technology-overview/

#db

👉 @database_info

Типы баз данных

#db

👉 @database_info

Ключевые понятия для понимания разделения баз данных

Разделение баз данных на несколько серверов означает разделение данных на несколько серверов баз данных и обычно используется для масштабирования. Однако при этом возникают значительные операционные и инфраструктурные сложности, которых следует избегать до тех пор, пока это не станет абсолютно необходимым.


Подходы, позволяющие отложить шардинг

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

Оптимизация SQL: Настройка SQL-запросов и схемы базы данных для достижения максимальной производительности на одном сервере. Требуются соответствующие индексы, эффективный SQL и т.д.

Кэширование: использование кэшей in-memory, например Redis, для снижения нагрузки на базу данных за счет отсутствия необходимости обращаться к ней при каждом запросе.

Реплики чтения + балансировщик нагрузки: Добавляет горизонтальную масштабируемость чтения без полной сложности шардинга. Направляет чтение между репликами.

Эти подходы к оптимизации должны быть исчерпаны перед шардингом, учитывая его сложность.

#db

👉 @database_info

Горизонтальное и вертикальное шардирование

Существует два высокоуровневых подхода:

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

Горизонтальное разделение: Разделение базы данных на разделы строк, равномерно распределенные по нескольким серверам.

Некоторые методы горизонтального разделения:

1. На основе диапазона: Сегментирование строк на основе диапазона значений, например возрастных групп. Может привести к неравномерному распределению данных и появлению "горячих точек".

2. На основе каталога: Использование каталога для поиска строк. Обеспечивается гибкость, но возникает риск возникновения единой точки отказа.

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

#db

👉 @database_info

Как базы данных выполняют SQL-запросы?

Процесс выполнения SQL-запросов в базе данных включает в себя несколько компонентов, взаимодействующих между собой. Хотя конкретная архитектура различных систем баз данных может отличаться, ниже описана общая последовательность действий.

1. Оператор SQL запускается в клиентской программе и передается по сети на сервер базы данных.

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

3. Оптимизатор запросов просматривает дерево запросов и определяет наиболее эффективный способ выполнения SQL-оператора, создавая план выполнения.

4. План выполнения передается исполнителю запроса, который использует его для координации получения или изменения данных в соответствии с запросом SQL. Для доступа к данным исполнитель взаимодействует с движком хранилища.

5. Движок хранилища использует методы доступа - протоколы чтения и записи данных, наиболее эффективные для выполнения различных операций.

6. При чтении данных менеджер буферов проверяет, кэшированы ли нужные данные в памяти, и при необходимости извлекает их с диска. Это ускоряет последующий доступ.

7. При записи данных со вставкой или обновлением менеджер транзакций следит за тем, чтобы изменения происходили атомарно и сохраняли целостность базы данных.

8. В то же время менеджер блокировок накладывает блокировки, чтобы несколько транзакций могли выполняться одновременно, не конфликтуя между собой. Таким образом, обеспечивается изоляция и согласованность.

Работая вместе, эти компоненты обеспечивают надежную и эффективную обработку SQL-запросов в системе управления базами данных.

#db

👉 @database_info

Шпаргалка по MSSQL

#db

👉 @database_info