С какими БД работал

Базы данных в моей практике

В своей карьере я работал с разнообразным спектром БД, от реляционных до NoSQL, облачных хранилищ. Каждая имеет свои преимущества.

1. PostgreSQL (основная БД)

Опыт: 5+ лет, production системы с миллионами записей

Чем работаю:

-- Сложные запросы с CTEs
WITH user_orders AS (
  SELECT 
    u.user_id,
    u.name,
    COUNT(o.id) as order_count,
    SUM(o.amount) as total_spent
  FROM users u
  LEFT JOIN orders o ON u.user_id = o.user_id
  WHERE o.created_at >= NOW() - INTERVAL '90 days'
  GROUP BY u.user_id, u.name
),
user_ranking AS (
  SELECT 
    *,
    ROW_NUMBER() OVER (ORDER BY total_spent DESC) as rank,
    PERCENT_RANK() OVER (ORDER BY total_spent) as percentile
  FROM user_orders
)
SELECT * FROM user_ranking WHERE rank <= 100;

-- Window functions для когортного анализа
SELECT 
  DATE_TRUNC('month', created_at)::date as cohort_month,
  DATE_PART('month', current_date::date - created_at::date) as months_since_signup,
  COUNT(DISTINCT user_id) as active_users
FROM user_activity
GROUP BY cohort_month, months_since_signup
ORDER BY cohort_month DESC, months_since_signup;

-- JSON работа для unstructured данных
SELECT 
  user_id,
  properties->>'device_type' as device,
  (properties->>'price')::numeric as price,
  properties->'metadata'->>'experiment_id' as experiment
FROM events
WHERE properties ? 'experiment_id';

-- Индексирование для производительности
CREATE INDEX idx_orders_user_date 
ON orders(user_id, created_at DESC);

EXPLAIN ANALYZE
SELECT * FROM orders WHERE user_id = 123 
ORDER BY created_at DESC LIMIT 100;

Сильные стороны:

• Надёжный ACID
• Мощные аналитические функции (Window Functions, CTEs)
• JSON поддержка
• Оптимизация запросов через EXPLAIN
• Full-text search

Когда использую: Основная БД для трансакционных систем и аналитики среднего объёма

2. BigQuery (Google Cloud)

Опыт: Облачная аналитика для больших объёмов (10TB+)

Сценарии использования:

-- Стандартный SQL с расширениями BigQuery
-- Работа с partition и cluster для оптимизации

CREATE OR REPLACE TABLE `project.dataset.daily_summary` 
PARTITION BY DATE(event_date)
CLUSTER BY user_id, event_type
AS
SELECT 
  event_date,
  user_id,
  event_type,
  COUNT(*) as event_count,
  COUNT(DISTINCT session_id) as sessions,
  APPROX_QUANTILES(event_value, 100)[OFFSET(50)] as median_value
FROM `project.dataset.events`
WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY)
GROUP BY event_date, user_id, event_type;

-- ARRAY и STRUCT для complex data
SELECT 
  user_id,
  ARRAY_AGG(STRUCT(
    event_type,
    event_value,
    event_timestamp
  ) ORDER BY event_timestamp DESC LIMIT 10) as last_10_events,
  ARRAY_LENGTH(ARRAY_AGG(event_type)) as total_events
FROM `project.dataset.events`
GROUP BY user_id;

-- Machine learning в SQL
CREATE OR REPLACE MODEL `project.dataset.churn_model`
OPTIONS(
  model_type='linear_reg',
  input_label_cols=['churned']
) AS
SELECT 
  days_since_signup,
  total_purchases,
  avg_purchase_value,
  days_last_active,
  churned
FROM `project.dataset.training_data`;

-- Предсказание
SELECT 
  user_id,
  predicted_churn,
  predicted_churn_prob
FROM ML.PREDICT(MODEL `project.dataset.churn_model`,
  SELECT 
    user_id,
    days_since_signup,
    total_purchases,
    avg_purchase_value,
    days_last_active
  FROM `project.dataset.users_to_score`
) 
WHERE predicted_churn_prob > 0.8
ORDER BY predicted_churn_prob DESC;

Преимущества:

• Масштабируемость без управления инфраструктурой
• Скорость на больших объёмах (SQL оптимизирует автоматически)
• ML встроенный в SQL
• Партиционирование и кластеризация для дешевизны
• Интеграция с Data Studio и Looker

Когда использую: Аналитика больших объёмов данных, дашборды для stakeholders

3. MySQL

Опыт: 4+ года, e-commerce системы

-- Немного другой синтаксис чем PostgreSQL
-- Работаю с индексами и JOIN оптимизацией

SELECT 
  o.order_id,
  c.customer_name,
  SUM(oi.quantity * oi.price) as total
FROM orders o
INNER JOIN customers c ON o.customer_id = c.customer_id
LEFT JOIN order_items oi ON o.order_id = oi.order_id
WHERE o.order_date >= DATE_SUB(NOW(), INTERVAL 30 DAY)
GROUP BY o.order_id, c.customer_name
HAVING total > 100
ORDER BY total DESC
LIMIT 1000;

-- JSON работа (добавлена в MySQL 5.7)
SELECT 
  order_id,
  JSON_EXTRACT(metadata, '$.shipping_address.city') as city,
  JSON_LENGTH(JSON_EXTRACT(metadata, '$.items')) as item_count
FROM orders
WHERE JSON_CONTAINS(metadata, '"express":true', '$.shipping');

Отличия от PostgreSQL:

• Немного менее мощные аналитические функции
• Но достаточно для большинства задач
• InnoDB обеспечивает ACID

Когда использую: Legacy системы, e-commerce, где требуется высокая скорость чтения

4. MongoDB (NoSQL)

Опыт: 3 года, event tracking и user profiles

from pymongo import MongoClient
from bson.objectid import ObjectId
from datetime import datetime, timedelta

client = MongoClient('mongodb://user:pass@localhost:27017')
db = client['analytics_db']

# Работаю с документами, а не таблицами
users_collection = db['users']
events_collection = db['events']

# Найти пользователей, активных за последние 30 дней
active_users = users_collection.find({
    'last_activity': {
        '$gte': datetime.now() - timedelta(days=30)
    },
    'status': 'active'
}).limit(1000)

# Агрегация (MongoDB аналог GROUP BY)
pipeline = [
    {
        '$match': {
            'event_date': {
                '$gte': datetime.now() - timedelta(days=7)
            }
        }
    },
    {
        '$group': {
            '_id': '$user_id',
            'event_count': {'$sum': 1},
            'unique_events': {'$addToSet': '$event_type'},
            'total_value': {'$sum': '$event_value'}
        }
    },
    {
        '$sort': {'total_value': -1}
    },
    {
        '$limit': 100
    }
]

top_users = list(events_collection.aggregate(pipeline))

# Обновление с условиями
users_collection.update_many(
    {'cohort': 'early_adopters'},
    {'$set': {'vip_status': True, 'updated_at': datetime.now()}}
)

# Bulk операции для производительности
from pymongo import UpdateOne

requests = [
    UpdateOne(
        {'_id': user['_id']},
        {'$set': {'last_score': calculate_score(user)}}
    )
    for user in users_collection.find()
]

users_collection.bulk_write(requests)

Преимущества:

• Гибкая схема (документы могут отличаться)
• Быстрая запись
• Встроенная репликация
• Хороша для event tracking

Недостатки:

• Медленнее для сложных аналитических запросов
• Требует денормализации

Когда использую: Event tracking, user profiles, real-time данные

5. Redis

Опыт: 2 года, кэширование и real-time метрики

import redis
import json
from datetime import datetime, timedelta

r = redis.Redis(host='localhost', port=6379, db=0)

# Кэширование результатов запроса
def get_user_stats(user_id, cache_ttl=3600):
    cache_key = f'user_stats:{user_id}'
    
    # Проверь кэш
    cached = r.get(cache_key)
    if cached:
        return json.loads(cached)
    
    # Если нет — запрос к БД
    stats = db.query('SELECT ... WHERE user_id = %s', user_id)
    
    # Сохрани в Redis на 1 час
    r.setex(cache_key, cache_ttl, json.dumps(stats))
    return stats

# Счётчики в real-time
r.incr('daily_signups')  # Инкрементирование
r.incrby('total_revenue', 1250)  # На количество

# Сортированные множества (leaderboards)
r.zadd('user_scores', {'user_1': 1000, 'user_2': 950})
top_10 = r.zrevrange('user_scores', 0, 9, withscores=True)

# Сессии и real-time флаги
r.setex(f'session:{session_id}', 3600, user_id)  # Сессия на 1 час
r.setnx(f'user_online:{user_id}', True)  # Только если не существует

# Списки (очереди обработки)
r.rpush('processing_queue', job_id)
job = r.lpop('processing_queue')

Использую для:

• Кэширование горячих данных
• Real-time счётчики
• Leaderboards
• Session store
• Очереди задач

6. Snowflake (облачное хранилище)

Опыт: 1 год, enterprise аналитика

-- Snowflake SQL похож на PostgreSQL
-- Но оптимизирован для analytics на масштаб

-- Работа с временными таблицами
CREATE TEMPORARY TABLE temp_cohort AS
SELECT 
  user_id,
  DATEADD(month, -MONTH(CURRENT_DATE()), DATE_TRUNC('month', signup_date)) as cohort_month
FROM users
WHERE signup_date >= '2023-01-01';

-- Задача с автоматическим расписанием
CREATE TASK update_daily_metrics
  WAREHOUSE = compute_wh
  SCHEDULE = 'USING CRON 0 2 * * * UTC'
  AS
CALL update_metrics_procedure();

-- Таблица с историей изменений (Time Travel)
SELECT * FROM users
  AT(TIMESTAMP => '2024-01-01 12:00:00'::timestamp_tz);

-- Semi-structured data (Variant type)
SELECT 
  user_id,
  event_data:event_type as event_type,
  event_data:properties.value::number as value
FROM events
WHERE event_data:event_type = 'purchase';

Преимущества:

• Масштабируемость (теоретически неограниченная)
• Отделение вычисления от хранения
• Time Travel для восстановления
• Sharing данных между компаниями

Когда использую: Enterprise аналитика, cross-company insights

7. Elasticsearch

Опыт: 1 год, полнотекстовый поиск и логирование

from elasticsearch import Elasticsearch

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

# Индексирование документов
es.index(index='products', id=1, body={
    'name': 'iPhone 15',
    'price': 999,
    'category': 'electronics',
    'description': 'Latest Apple smartphone',
    'created_at': datetime.now()
})

# Поиск с фильтрами
results = es.search(index='products', body={
    'query': {
        'bool': {
            'must': [
                {'match': {'description': 'smartphone'}}
            ],
            'filter': [
                {'range': {'price': {'gte': 500, 'lte': 1500}}},
                {'term': {'category': 'electronics'}}
            ]
        }
    },
    'aggs': {
        'avg_price': {'avg': {'field': 'price'}},
        'categories': {'terms': {'field': 'category'}}
    }
})

# Агрегации для анализа
for hit in results['hits']['hits']:
    print(f"{hit['_source']['name']}: ${hit['_source']['price']}")

Используется для:

• Быстрый поиск (полнотекстовый)
• Логирование и анализ логов
• Time-series данные

Сравнительная таблица

Как выбираю БД для проекта

Вопросы, которые задаю:

1. Объём данных?

   • < 1TB → PostgreSQL

   • 1TB → BigQuery/Snowflake

2. Тип операций?

   • OLTP → MySQL/PostgreSQL
   • OLAP → BigQuery/Snowflake
   • Real-time → Redis

3. Структура данных?

   • Таблицы → PostgreSQL
   • Документы → MongoDB
   • Text search → Elasticsearch

4. Budget?

   • Ограничен → PostgreSQL (open-source)
   • Щедрый → BigQuery (pay-as-you-go)

Вывод

В моём опыте идеального решения нет. Выбираю инструмент под задачу:

• PostgreSQL для надёжной аналитики и транзакций
• BigQuery для масштабируемой аналитики без операционного overhead
• MongoDB когда нужна гибкость схемы
• Redis для real-time метрик и кэша
• Комбинирую несколько для максимальной эффективности