#12-Как устроены базы данных: где хранятся все данные интернета. Правка

Что такое REST API: как общаются фронтенд и бэкенд

Идентификатор ссылки (англ.)	kak-rabotaet-klient-servernaya-model
Статус:	Активен

Описание:

Идентификатор ссылки (англ.)	chto-takoe-rest-api-kak-obshchayutsya-frontend-i-bekend
Статус:	Активен

Описание:

'#8. Посты : posts';

'Blog_PostController_actionUpdate_';

'#blog_post_update';

Как устроены базы данных: где хранятся все данные интернета. Правка

Активен

Почистить кэш постов Экспресс-правка Разметка ред. Summernote ред. Quill ред. CKEditor ред. Trumbowyg ред. Imperavi ред. Jodit

Общая информация

Сменить блог

Название

Рейтинг SEO (от 1 до 100)

Всего знаков в посте: 26095

id (статус)	749 (3)
Идентификатор ссылки (англ.)	kak-ustroeny-bazy-dannykh-gde-khranyatsya-vse-dannye
Сайт (ID сайта)	seo.qwetru.ru. #44
Смотреть на сайте	https://seo.qwetru.ru/posts/web/kak-ustroeny-bazy-dannykh-gde-khranyatsya-vse-dannye/
Время последнего обновления	22-11-2025 в 19:03:10
Ссылка в БД	https://panel25.seowebdev.ru/seowebdev.ru/posts/web/kak-ustroeny-bazy-dannykh-gde-khranyatsya-vse-dannye/
Картинка	https://static.seowebdev.ru/cache/8/749-kak-ustroeny-bazy-dannykh-gde-khranyatsya-vse-dannye_col-12.webp

Текст поста

Ключевое слово отсутствует

Полный текст < > & " ' « » – — … • · ← → ↑ ↓ ↔

Валюты: € £ ¥ ¢

Типографика: § ¶ ° ± × ÷

Дроби: ½ ⅓ ⅔ ¼ ¾ ⅛ ⅜ ⅝ ⅞

Греческие: α β γ δ ε λ μ π σ ω Δ Σ Ω

Математические: ≈ ≠ ≤ ≥ ∞ √ ∑ ∫ ∂ ∇

Каждый раз, когда вы регистрируетесь на сайте, публикуете пост, добавляете товар в корзину или ставите лайк &ndash; где-то сохраняется информация об этом. Но где именно? И как сайт потом находит ваши данные среди миллионов других?
Ответ: в базе данных. Это специальное хранилище, организованное так, чтобы данные можно было быстро сохранять, находить, изменять и удалять. Без баз данных современный интернет просто не существовал бы.
Давайте разберёмся, что такое база данных, как она устроена и почему это так важно для веб-разработки.
<h2>Что такое база данных?</h2>
База данных (БД) &ndash; это организованное хранилище информации, где данные структурированы таким образом, чтобы их было легко сохранять, искать и обрабатывать.
Можно сравнить базу данных с:
<ul>
<li>Библиотекой &ndash; книги стоят на полках по разделам, есть каталог для поиска. Вы не ищете нужную книгу вслепую среди тысяч &ndash; вы знаете, где искать.</li>
<li>Складом &ndash; товары разложены по стеллажам, каждому присвоен номер, есть система учёта. Вы можете быстро найти нужный товар, проверить остатки, забрать со склада.</li>
<li>Картотекой в больнице &ndash; карточки пациентов упорядочены по фамилиям, можно быстро найти историю болезни конкретного человека.</li>
</ul>
База данных работает так же: данные организованы, имеют структуру, к ним можно обращаться по запросу.
<h2>Зачем нужны базы данных на сайтах?</h2>
Современный веб-сайт &ndash; это не просто статичные HTML-страницы. Сайты хранят огромные объёмы информации:
<ul>
<li>Интернет-магазин: товары, категории, цены, остатки на складе, заказы, клиенты, история покупок</li>
<li>Социальная сеть: профили пользователей, посты, лайки, комментарии, друзья, сообщения</li>
<li>Блог: статьи, авторы, категории, теги, комментарии</li>
<li>Сервис бронирования: отели, номера, брони, доступность, цены по датам</li>
</ul>
Все эти данные нужно где-то хранить, и база данных &ndash; идеальное решение. Она позволяет:
<ul>
<li>Сохранять большие объёмы данных &ndash; миллионы записей без проблем</li>
<li>Быстро искать нужное &ndash; найти товар по названию за миллисекунды</li>
<li>Обновлять информацию &ndash; изменить цену товара, статус заказа</li>
<li>Связывать данные между собой &ndash; заказ связан с клиентом, товаром, адресом доставки</li>
<li>Обеспечивать безопасность &ndash; контролировать, кто и к каким данным имеет доступ</li>
</ul>
<h2>Реляционные базы данных: таблицы, строки, столбцы</h2>
Самый распространённый тип баз данных &ndash; реляционные. Они организуют данные в виде таблиц, похожих на таблицы Excel.
<h3>Как устроена таблица?</h3>
Представьте таблицу в Excel:
<ul>
<li>Столбцы (поля) &ndash; это характеристики, атрибуты. Например: ID, Имя, Email, Телефон.</li>
<li>Строки (записи) &ndash; это конкретные объекты. Например: один пользователь, один товар, один заказ.</li>
</ul>
Пример таблицы "Пользователи":
<table border="1" cellpadding="5">
<tbody>
<tr>
<th>ID</th>
<th>Имя</th>
<th>Email</th>
<th>Дата регистрации</th>
</tr>
<tr>
<td>1</td>
<td>Иван Иванов</td>
<td>ivan@example.com</td>
<td>2024-01-15</td>
</tr>
<tr>
<td>2</td>
<td>Мария Петрова</td>
<td>maria@example.com</td>
<td>2024-02-20</td>
</tr>
<tr>
<td>3</td>
<td>Алексей Сидоров</td>
<td>alex@example.com</td>
<td>2024-03-10</td>
</tr>
</tbody>
</table>
Каждая строка &ndash; это один пользователь. Каждый столбец &ndash; это информация о пользователе.
<h3>Первичный ключ (Primary Key)</h3>
ID в таблице &ndash; это первичный ключ. Это уникальный идентификатор каждой записи. Не может быть двух пользователей с одинаковым ID. Благодаря первичному ключу можно точно указать на конкретную запись.
Зачем это нужно? Имена могут повторяться (два Ивана Ивановых), email может измениться, а ID всегда уникален и неизменен.
<h3>Связи между таблицами</h3>
Реляционные базы называются так потому, что таблицы связаны друг с другом через отношения (relations).
Пример: интернет-магазин
У нас есть три таблицы:
Таблица "Товары":
<table border="1" cellpadding="5">
<tbody>
<tr>
<th>ID</th>
<th>Название</th>
<th>Цена</th>
<th>Остаток</th>
</tr>
<tr>
<td>101</td>
<td>Ноутбук Dell</td>
<td>50000</td>
<td>15</td>
</tr>
<tr>
<td>102</td>
<td>Мышь Logitech</td>
<td>1500</td>
<td>200</td>
</tr>
</tbody>
</table>
Таблица "Клиенты":
<table border="1" cellpadding="5">
<tbody>
<tr>
<th>ID</th>
<th>Имя</th>
<th>Email</th>
</tr>
<tr>
<td>1</td>
<td>Иван Иванов</td>
<td>ivan@example.com</td>
</tr>
<tr>
<td>2</td>
<td>Мария Петрова</td>
<td>maria@example.com</td>
</tr>
</tbody>
</table>
Таблица "Заказы":
<table border="1" cellpadding="5">
<tbody>
<tr>
<th>ID заказа</th>
<th>ID клиента</th>
<th>ID товара</th>
<th>Количество</th>
<th>Дата</th>
</tr>
<tr>
<td>5001</td>
<td>1</td>
<td>101</td>
<td>1</td>
<td>2024-11-20</td>
</tr>
<tr>
<td>5002</td>
<td>2</td>
<td>102</td>
<td>3</td>
<td>2024-11-21</td>
</tr>
</tbody>
</table>
Обратите внимание: в таблице "Заказы" есть ID клиента и ID товара. Это внешние ключи (Foreign Keys) &ndash; ссылки на другие таблицы.
Заказ 5001 сделал клиент с ID = 1 (Иван Иванов), купил товар с ID = 101 (Ноутбук Dell).
Благодаря связям мы можем:
<ul>
<li>Получить все заказы конкретного клиента</li>
<li>Узнать, кто покупал определённый товар</li>
<li>Посчитать общую сумму заказов клиента</li>
</ul>
Это и есть суть реляционных баз &ndash; таблицы связаны между собой через ключи.
<h2>SQL: язык общения с базой данных</h2>
Чтобы работать с реляционной базой данных, используется специальный язык &ndash; SQL (Structured Query Language).
SQL позволяет:
<ul>
<li>SELECT &ndash; получить данные (выбрать)</li>
<li>INSERT &ndash; добавить новые данные</li>
<li>UPDATE &ndash; обновить существующие данные</li>
<li>DELETE &ndash; удалить данные</li>
</ul>
<h3>Примеры SQL-запросов</h3>
Получить всех пользователей:
<pre>SELECT * FROM users;</pre>
Найти пользователя по email:
<pre>SELECT * FROM users WHERE email = 'ivan@example.com';</pre>
Добавить нового пользователя:
<pre>INSERT INTO users (name, email, registered_at)
VALUES ('Пётр Петров', 'petr@example.com', '2024-11-22');</pre>
Обновить цену товара:
<pre>UPDATE products SET price = 48000 WHERE id = 101;</pre>
Удалить заказ:
<pre>DELETE FROM orders WHERE id = 5001;</pre>
Получить все заказы клиента с именем:
<pre>SELECT orders.id, users.name, products.title, orders.quantity
FROM orders
JOIN users ON orders.user_id = users.id
JOIN products ON orders.product_id = products.id
WHERE users.id = 1;</pre>
Последний пример показывает JOIN &ndash; объединение данных из нескольких таблиц. Это мощная возможность реляционных баз.
<h3>Популярные реляционные СУБД</h3>
СУБД (Система Управления Базами Данных) &ndash; это программа, которая управляет базой данных: хранит файлы, обрабатывает запросы, контролирует доступ.
Популярные реляционные СУБД:
<ul>
<li>MySQL &ndash; самая распространённая, бесплатная, используется на миллионах сайтов</li>
<li>PostgreSQL &ndash; более продвинутая, с богатыми возможностями</li>
<li>SQLite &ndash; лёгкая, встраиваемая база, для небольших проектов</li>
<li>Microsoft SQL Server &ndash; от Microsoft, для корпоративных проектов</li>
<li>Oracle Database &ndash; мощная, дорогая, для крупного бизнеса</li>
</ul>
<h2>NoSQL: альтернатива реляционным базам</h2>
Реляционные базы отлично работают, когда данные имеют чёткую структуру: товары, заказы, пользователи. Но что если данные более гибкие, неструктурированные?
Появились NoSQL-базы (Not Only SQL) &ndash; базы данных без жёстких таблиц и схем.
<h3>Типы NoSQL-баз</h3>
1. Документо-ориентированные (Document-based)
Данные хранятся в виде документов (обычно JSON-формат). Каждый документ &ndash; самостоятельная единица, может иметь свою структуру.
Пример (MongoDB):
<pre>{
 "id": 1,
 "name": "Иван Иванов",
 "email": "ivan@example.com",
 "address": {
 "city": "Москва",
 "street": "Ленина 10"
 },
 "orders": [101, 102, 105]
}</pre>
Не нужно создавать отдельные таблицы для адресов и заказов &ndash; всё в одном документе.
Популярные: MongoDB, CouchDB
2. Ключ-значение (Key-Value)
Самая простая структура: есть ключ (уникальный идентификатор) и значение (любые данные).
Пример:
<pre>user:123 &rarr; {"name": "Иван", "email": "ivan@example.com"}
session:abc456 &rarr; {"user_id": 123, "expires": "2024-11-23"}</pre>
Очень быстрые для чтения/записи, используются для кэширования.
Популярные: Redis, Memcached
3. Колоночные (Column-family)
Данные хранятся по столбцам, а не по строкам. Эффективно для аналитики больших данных.
Популярные: Cassandra, HBase
4. Графовые (Graph)
Данные представлены в виде графа: узлы (объекты) и связи между ними. Идеально для социальных сетей, рекомендательных систем.
Пример: пользователь &rarr; дружит с &rarr; другим пользователем &rarr; лайкнул &rarr; пост.
Популярные: Neo4j, ArangoDB
<h3>Когда использовать NoSQL?</h3>
<ul>
<li>Гибкая структура данных &ndash; не все объекты имеют одинаковые поля</li>
<li>Огромные объёмы &ndash; миллиарды записей, петабайты данных</li>
<li>Высокая скорость записи &ndash; нужно быстро сохранять данные без сложных проверок</li>
<li>Горизонтальное масштабирование &ndash; легко добавить ещё серверов</li>
<li>Кэширование &ndash; временное хранение часто запрашиваемых данных (Redis)</li>
</ul>
<h3>Когда использовать реляционные базы?</h3>
<ul>
<li>Чёткая структура &ndash; данные имеют предсказуемую схему</li>
<li>Связи важны &ndash; нужно объединять данные из разных таблиц</li>
<li>ACID-требования &ndash; важна согласованность данных (банки, финансы)</li>
<li>Сложные запросы &ndash; нужны JOIN, GROUP BY, агрегации</li>
</ul>
<h2>Как база данных работает на практике?</h2>
Давайте проследим путь данных на примере регистрации пользователя:
<ol>
<li>Пользователь заполняет форму регистрации Имя: Иван Иванов Email: ivan@example.com Пароль: &bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull; Нажимает кнопку "Зарегистрироваться"</li>
<li>Фронтенд отправляет данные на бэкенд POST-запрос с JSON:
<pre>{
 "name": "Иван Иванов",
 "email": "ivan@example.com",
 "password": "mypassword123"
}</pre>
</li>
<li>Бэкенд получает данные и проверяет - Email корректный? - Пароль достаточно сложный? - Такой email уже зарегистрирован?</li>
<li>Бэкенд хэширует пароль Нельзя хранить пароли в открытом виде! Пароль преобразуется в хэш (необратимое шифрование):
<pre>mypassword123 &rarr; $2y$10$eImiTXu...</pre>
</li>
<li>Бэкенд формирует SQL-запрос 
<pre>INSERT INTO users (name, email, password, created_at)
VALUES ('Иван Иванов', 'ivan@example.com', '$2y$10$eImiTXu...', NOW());</pre>
</li>
<li>СУБД выполняет запрос - Открывает файл базы данных - Добавляет новую строку в таблицу users - Присваивает автоматический ID (например, 123) - Обновляет индексы для быстрого поиска - Записывает изменения на диск</li>
<li>СУБД возвращает результат бэкенду "Успешно добавлена запись с ID = 123"</li>
<li>Бэкенд отправляет ответ фронтенду 
<pre>{
 "status": "success",
 "user_id": 123,
 "message": "Регистрация прошла успешно"
}</pre>
</li>
<li>Фронтенд показывает сообщение пользователю "Добро пожаловать, Иван! Вы успешно зарегистрированы."</li>
</ol>
Весь процесс занимает доли секунды.
<h2>Индексы: как база данных ищет быстро</h2>
Представьте книгу на 1000 страниц. Как найти упоминание слова "клиент-серверная модель"?
Без индекса: придётся читать все 1000 страниц подряд, пока не найдёте. Долго.
С индексом (алфавитным указателем в конце книги): смотрите в указатель &rarr; "К" &rarr; "Клиент-серверная модель &ndash; стр. 42, 89, 156". Открываете нужную страницу. Быстро.
Индекс в базе данных работает так же: это дополнительная структура, которая ускоряет поиск по определённым полям.
Пример: если часто ищете пользователей по email, создаёте индекс на поле <code>email</code>. Теперь поиск занимает миллисекунды вместо секунд.
Но индексы:
<ul>
<li>Плюс: ускоряют чтение (SELECT)</li>
<li>Минус: замедляют запись (INSERT, UPDATE) и занимают дополнительное место</li>
</ul>
Поэтому индексы создают только на те поля, по которым часто ищут.
<h2>Транзакции: всё или ничего</h2>
Транзакция &ndash; это группа операций, которые должны выполниться все вместе или не выполниться вообще.
Пример: перевод денег
<ol>
<li>Снять 1000₽ со счёта Ивана</li>
<li>Добавить 1000₽ на счёт Марии</li>
</ol>
Что если после шага 1 произошёл сбой? Деньги списались с Ивана, но не дошли до Марии. Катастрофа!
Транзакция решает проблему:
<ul>
<li>Если обе операции прошли успешно &rarr; COMMIT (зафиксировать изменения)</li>
<li>Если хотя бы одна упала &rarr; ROLLBACK (откатить всё назад, как будто ничего не было)</li>
</ul>
Банки, финансовые системы, e-commerce &ndash; везде критически важны транзакции.
<h2>ACID: гарантии надёжности</h2>
Реляционные базы данных гарантируют ACID:
<ul>
<li>Atomicity (Атомарность) &ndash; транзакция выполняется полностью или не выполняется вообще</li>
<li>Consistency (Согласованность) &ndash; база данных всегда остаётся в корректном состоянии</li>
<li>Isolation (Изолированность) &ndash; параллельные транзакции не влияют друг на друга</li>
<li>Durability (Долговечность) &ndash; после COMMIT данные сохранены навсегда, даже если сервер упал</li>
</ul>
ACID &ndash; это причина, почему банки используют реляционные базы. Надёжность превыше всего.
<h2>Масштабирование баз данных</h2>
Что делать, когда пользователей стало миллионы, а база данных не справляется?
<h3>Вертикальное масштабирование</h3>
Купить более мощный сервер: больше оперативной памяти, быстрее диски (SSD), мощнее процессор. Простой способ, но есть предел &ndash; самый мощный сервер когда-то закончится.
<h3>Горизонтальное масштабирование</h3>
Репликация (копирование): создать несколько копий базы. Один сервер &ndash; мастер (принимает запись), остальные &ndash; реплики (отдают данные на чтение). Ускоряет чтение.
Шардирование (разделение): разделить данные между несколькими серверами. Например, пользователи с ID 1-1000000 на первом сервере, 1000001-2000000 &ndash; на втором. Каждый сервер хранит часть данных.
<h3>Кэширование</h3>
Часто запрашиваемые данные хранятся в быстрой памяти (Redis). Вместо похода в базу данных &ndash; берём из кэша. В 10-100 раз быстрее.
<h2>Главное из статьи</h2>
<ul>
<li>База данных &ndash; организованное хранилище информации для быстрого сохранения, поиска и обработки</li>
<li>Реляционные БД &ndash; данные в таблицах (строки, столбцы), связи через ключи, язык SQL</li>
<li>NoSQL &ndash; альтернатива для гибких структур: документы, ключ-значение, графы</li>
<li>SQL &ndash; язык для работы с реляционными базами (SELECT, INSERT, UPDATE, DELETE)</li>
<li>Индексы &ndash; ускоряют поиск, но замедляют запись</li>
<li>Транзакции &ndash; группа операций "всё или ничего"</li>
<li>ACID &ndash; гарантии надёжности реляционных баз</li>
<li>Масштабирование &ndash; вертикальное (мощнее сервер), горизонтальное (больше серверов)</li>
</ul>
Теперь вы понимаете, где и как хранятся данные на веб-сайтах. В следующих статьях мы разберём REST API, фреймворки для веб-разработки, и наконец перейдём к практике &ndash; как всё это реализовано в платформе Shop'n'SEO!

Скопировано в буфер!

Вставлено из буфера!

Как устроены базы данных: где хранятся все данные интернета. Правка

Дополнительные символы