← Назад к вопросам

Где не стоит использовать реляционную БД?

2.0 Middle🔥 111 комментариев
#Базы данных (NoSQL)#Базы данных (SQL)

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI22 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Где не стоит использовать реляционную БД

Реляционные базы данных (PostgreSQL, MySQL, Oracle) — это универсальный инструмент, но они не идеальны для всех сценариев. Важно понимать, когда нужны альтернативы.

1. Иерархические и графовые структуры

Проблема

-- Для древовидной структуры организации нужны сложные запросы
SELECT * FROM employees e1
JOIN employees e2 ON e1.manager_id = e2.id
JOIN employees e3 ON e2.manager_id = e3.id
JOIN employees e4 ON e3.manager_id = e4.id
WHERE e1.id = 123;
-- Нужна рекурсия, сложные запросы

Решение: Graph Database (Neo4j, ArangoDB)

# Neo4j — работать с графами естественнее
from neo4j import GraphDatabase

driver = GraphDatabase.driver('bolt://localhost:7687')

with driver.session() as session:
    # Просто найти всех начальников сотрудника
    result = session.run(
        'MATCH (e:Employee)-[:MANAGED_BY*]->(boss:Employee) '
        'WHERE e.id = $employee_id RETURN boss',
        employee_id=123
    )

Примеры:

  • Социальные сети (друзья, подписчики, рекомендации)
  • Организационные иерархии
  • Знаниевые графы
  • Системы рекомендаций

2. Документы с непредсказуемой структурой

Проблема

Если каждый документ имеет разную структуру (разные поля, разная вложенность), использование таблиц неэффективно:

-- Нужно создавать колонки для всех возможных полей
CREATE TABLE documents (
    id INT,
    title VARCHAR(255),
    author VARCHAR(255),
    field1 VARCHAR(255),
    field2 VARCHAR(255),
    field3 VARCHAR(255),
    -- ... сто полей, но каждый документ использует только 10
);

Решение: NoSQL Document Database (MongoDB, CouchDB)

from pymongo import MongoClient

client = MongoClient('mongodb://localhost:27017')
db = client['articles']
collection = db['documents']

# Каждый документ может иметь разную структуру
collection.insert_many([
    {'title': 'Article 1', 'author': 'Alice', 'tags': ['python', 'async']},
    {'title': 'Article 2', 'tags': ['javascript'], 'rating': 4.5},
    {'title': 'Article 3', 'content': '...very long text...', 'metadata': {}},
])

Примеры:

  • CMS (блоги, новости с разными типами контента)
  • JSON API responses
  • Event logs с разными схемами
  • IoT сенсорные данные

3. Высокая скорость записи (Time-series data)

Проблема

Реляционные БД не оптимизированы для миллионов событий в секунду:

# Медленно в PostgreSQL
import asyncpg

for metric in metrics:  # Миллионы событий
    await db.execute(
        'INSERT INTO metrics (timestamp, value) VALUES ($1, $2)',
        metric['timestamp'], metric['value']
    )

Решение: Time-Series Database (InfluxDB, TimescaleDB, Prometheus)

from influxdb_client import InfluxDBClient

client = InfluxDBClient(url='http://localhost:8086')
write_api = client.write_api()

# Очень быстрая запись миллионов точек
for metric in metrics:
    point = Point('cpu_usage') \
        .time(metric['timestamp']) \
        .field('value', metric['value']) \
        .tag('host', metric['host'])
    write_api.write(bucket='metrics', record=point)

Примеры:

  • Метрики мониторинга (Prometheus, Grafana)
  • Температурные датчики
  • Финансовые тики
  • Web analytics

4. Очень большие объемы неструктурированных данных

Проблема

Для больших файлов и мультимедиа нужно хранить в файловом хранилище, а не в БД:

-- ❌ Плохо
CREATE TABLE videos (
    id INT,
    title VARCHAR(255),
    content LONGBLOB  -- Хранить весь видеофайл в БД
);

Решение: Object Storage (S3, Google Cloud Storage)

import boto3

s3 = boto3.client('s3')

# Хранить только метаданные в БД
db.execute(
    'INSERT INTO videos (id, title, s3_key) VALUES (?, ?, ?)',
    (video_id, 'My Video', f's3://bucket/videos/{video_id}.mp4')
)

# Сам файл в S3
s3.upload_file('video.mp4', 'bucket', f'videos/{video_id}.mp4')

Примеры:

  • Видео и аудио файлы
  • Изображения (использовать S3 + CDN)
  • Логи большого объема
  • Резервные копии

5. Кеш и сессии

Проблема

Создание индексов и запросов для временных данных неэффективно:

-- ❌ Медленно
SELECT session_data FROM sessions WHERE user_id = 123;
-- Индекс, блокировки, disk I/O

Решение: In-Memory Cache (Redis, Memcached)

import redis

redis_client = redis.Redis(host='localhost', port=6379)

# Очень быстро (в памяти)
redis_client.setex(f'session:{user_id}', 3600, session_data)
data = redis_client.get(f'session:{user_id}')

Примеры:

  • Сессии пользователей
  • Кеш результатов запросов
  • Очереди задач
  • Rate limiting counters
  • Realtime counters

6. Очереди сообщений

Проблема

использовать таблицу как очередь — антипаттерн:

-- ❌ Плохо
SELECT * FROM queue LIMIT 1 FOR UPDATE;
DELETE FROM queue WHERE id = ?;
-- Конфликты, блокировки

Решение: Message Queue (RabbitMQ, Kafka, AWS SQS)

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.queue_declare(queue='tasks', durable=True)

# Опубликовать задачу
channel.basic_publish(
    exchange='',
    routing_key='tasks',
    body='task_data'
)

# Потребить задачу
def callback(ch, method, properties, body):
    print(f'Processing {body}')
    ch.basic_ack(delivery_tag=method.delivery_tag)

channel.basic_consume(queue='tasks', on_message_callback=callback)
channel.start_consuming()

Примеры:

  • Обработка задач в фоне
  • Event streaming
  • Microservices communication
  • Fan-out паттерны

7. Полнотекстовый поиск

Проблема

ПОПА LIKE '%text%' очень медленная для больших объемов:

-- ❌ Медленно для миллионов документов
SELECT * FROM articles WHERE content LIKE '%python%';

Решение: Search Engine (Elasticsearch, Meilisearch)

from elasticsearch import Elasticsearch

es = Elasticsearch(['http://localhost:9200'])

# Очень быстрый и релевантный поиск
results = es.search(
    index='articles',
    body={
        'query': {
            'multi_match': {
                'query': 'python async',
                'fields': ['title', 'content']
            }
        }
    }
)

Примеры:

  • Поиск по статьям и контенту
  • E-commerce каталоги
  • Поиск в документах
  • Подсказки и автодополнение

Таблица сравнения

ТребованиеНеправильный выборПравильный выбор
Графы и связиРеляционная БДGraph DB (Neo4j)
Гибкая схемаРеляционная БДDocument DB (MongoDB)
Time-seriesРеляционная БДInfluxDB, TimescaleDB
КешРеляционная БДRedis
ОчередиТаблица в БДRabbitMQ, Kafka
Полнотекстовый поискLIKE запросыElasticsearch
Большие файлыBLOB в БДObject Storage (S3)

Вывод

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

Где не стоит использовать реляционную БД? | PrepBro