Написание минимальной подсистемы хранения данных в памяти для MySQL/MariaDB

Я потратил неделю, копаясь во внутренностях MySQL/MariaDB вместе с ещё примерно 80 разработчиками. Хотя MySQL и MariaDB — это, по большей части, одно и то же (я ещё к этому вернусь), я сосредоточился именно на MariaDB.

Раньше я никогда сам не собирал MySQL/MariaDB. В первый день «недели хакерства» я смог наладить локальную сборку MariaDB и твикнул код так, что запрос SELECT 23 возвращал 213. Сделал я и другой твик — такой, что запрос SELECT 80 + 20 возвращал 60. На второй день я смог заставить заработать простую UDF на C, благодаря которой запрос SELECT mysum(20, 30) давал 50.

Остаток недели я потратил, пытаясь разобраться с тем, как сделать минимальный движок для хранения данных в памяти. Именно о нём я и расскажу. Это — 218 строк кода на C++.

Мой движок поддерживает команды CREATE, DROP, INSERT и SELECT для таблиц, поля которых могут хранить только данные типа INTEGER. Он не является потокобезопасным. Я таким его и делал, так как у меня не было времени для того чтобы разобраться с блокировочными примитивами MariaDB.

Здесь я расскажу и о том, как API MariaDB для создания пользовательских хранилищ информации соотносится с подобным API Postgres. Это сравнение я смог провести на основании опыта, полученного при создании проекта на предыдущей хак‑неделе.

Весь код для этого материала можно найти в моём форке MariaDB на GitHub.

https://habr.com/ru/companies/wunderfund/articles/789640/

original https://notes.eatonphil.com/2024-01-09-minimal-in-memory-storage-engine-for-mysql.html

#db

👉 @database_info

Как в СУБД реализовать администратора без прав доступа к данным

В СУБД-строении есть не новая, но не теряющая актуальности задача. Сформулировать её можно примерно так: как убрать возможность суперпользователя взаимодействовать с данными, но оставить ему все возможности по управлению СУБД? Эта функция затребована не только большими компаниями с жёсткими требованиями к информационной безопасности, но и крайне нужна всем, кто попадает под различного вида государственные регуляции, вроде приказа ФСТЭК №64 или страшного GDPR.

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

В этой статье мы хотим поговорить о том, какие есть подходы к решению этой проблемы, какие можно найти реализации на рынке, и что решили сделать мы в Postgres Professional.

Одним из возможных решений данной задачи является введение классической ролевой модели, в рамках которой нас интересует выделение следующих ролей:

Администратор СУБД;
Администратор БД (он же владелец данных);
Администратор безопасности.

https://habr.com/ru/companies/postgrespro/articles/788268/

#db

👉 @database_info

Пошаговое руководство по чтению и пониманию SQL-запросов

SQL, или язык структурированных запросов, - это язык программирования для управления и обработки данных в реляционной системе управления базами данных (РСУБД). Это стандартный язык, используемый во многих компаниях для обеспечения беспрепятственного доступа к данным. Поскольку он широко используется, при приеме на работу SQL обычно указывается в качестве одного из необходимых навыков. Поэтому изучать SQL просто необходимо.

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

В этой статье мы рассмотрим пошаговый процесс чтения и понимания SQL-запросов. Как это сделать? Давайте разберемся в этом.

https://www.kdnuggets.com/a-step-by-step-guide-to-reading-and-understanding-sql-queries

#db

👉 @database_info

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

#db

👉 @database_info

Типы SQL Joins

#db

👉 @database_info