С какими базами данных работал

Базы данных с которыми я работал

В течение 10+ лет я работал с различными типами баз данных. Расскажу о опыте в каждой и когда их использовать.

1. PostgreSQL

Опыт: Использовал в 3 компаниях, включая стартапы и mid-size компании.

Основное назначение в моей работе:

• Transactional database для production приложений
• OLTP (Online Transaction Processing)
• Source of truth для business данных

Что я делал:

• Писал SQL queries для анализа product metrics
• Создавал views для analytics team
• Дебажил issues когда данные не совпадают
• Помогал DevOps с оптимизацией queries

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

• ACID compliance — данные всегда consistent
• Хорошо оптимизирует queries
• JSON поддержка (jsonb) — очень полезно для nested data
• Window functions, CTEs (Common Table Expressions) — мощные для анализа
• Полностью открыт (open-source)
• Соревнуется с MySQL, но PostgreSQL лучше для analytics запросов

Когда использовать:

-- Пример сложного запроса с window functions и CTE
WITH daily_revenue AS (
  SELECT
    DATE_TRUNC('day', order_time) as day,
    SUM(amount) as revenue,
    COUNT(*) as orders
  FROM orders
  WHERE status = 'completed'
  GROUP BY 1
)
SELECT
  day,
  revenue,
  SUM(revenue) OVER (ORDER BY day ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) as moving_avg_7days
FROM daily_revenue
ORDER BY day DESC;

Недостатки:

• Не масштабируется горизонтально так легко как некоторые NoSQL
• Для очень больших датасетов (петабайты) может быть медленнее
• Single machine limitation

2. MySQL

Опыт: Работал с MySQL в 1 компании, которая использовала его для production.

Основное назначение:

• OLTP database
• Более легкий и быстрый чем PostgreSQL для simple queries

Различия от PostgreSQL:

• Меньше features (нет JSONB в ранних версиях, нет CTE)
• Немного быстрее для simple SELECT
• Менее надежен (InnoDB vs MyISAM debates)
• Не поддерживает некоторые advanced SQL features

Мой опыт:

• Преимущественно читал из MySQL для reports
• Писал простые queries
• Для сложного анализа мы выгружали данные в Data Warehouse

Вывод: PostgreSQL > MySQL для аналитики, но MySQL хорош для простых операций.

3. Redis

Опыт: Работал с Redis как с кэшем и для real-time данных.

Основное назначение:

• In-memory cache
• Real-time metrics storage
• Leaderboards, rankings

Что я делал:

• Анализировал real-time user activity (Redis содержит сеансы)
• Смотрел на leaderboards (top users by score/purchases)
• Работал с Sorted Sets для ranked data

Пример использования:

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

# Top 10 users by purchases
top_users = r.zrange('user_purchases', -10, -1, withscores=True, desc=True)

# Current active users (last 5 minutes)
active_users = r.smembers('active_users:5min')

# Session data
user_session = r.hgetall(f'session:{user_id}')

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

• Очень быстро (in-memory)
• Отлично для real-time use cases
• Хорошо для leaderboards и rankings
• Поддерживает разные структуры данных (strings, sets, sorted sets, hashes)

Недостатки для анализа:

• Не подходит для heavy analytics
• Данные теряются если упадет сервер (if not persisted)
• Нет query language как SQL

Когда использовать:

• Real-time dashboards
• Leaderboards
• Session storage
• Rate limiting

4. Snowflake (Cloud Data Warehouse)

Опыт: Работал в компании которая мигрировала на Snowflake. Это был наиболее интенсивный опыт с DW.

Основное назначение:

• OLAP (Online Analytical Processing)
• Central repository для всех аналитических данных
• Масштабируемое хранилище для big data

Что я делал:

• Писал SQL queries для анализа (похоже на PostgreSQL синтаксис)
• Создавал marts для разных departments (product, marketing, sales)
• Оптимизировал queries (тупые queries стоят денег в Snowflake!)
• Работал с Data Engineers на создание ETL pipelines
• Анализировал usage и compute costs

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

-- Пример: Snowflake отлично оптимизирует большие JOIN'ы
SELECT
  u.user_id,
  u.name,
  COUNT(DISTINCT o.order_id) as total_orders,
  SUM(o.amount) as lifetime_value,
  MAX(o.order_time) as last_order_date
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
LEFT JOIN products p ON o.product_id = p.product_id
GROUP BY 1, 2
HAVING COUNT(DISTINCT o.order_id) > 0
ORDER BY lifetime_value DESC;

Уникальные фишки:

• Time travel: можно смотреть данные из прошлого (BEFORE, AT, OFFSET)
• Zero-copy clone: легко создавать dev/prod copies
• Query result caching: результаты кэшируются автоматически
• Масштабируемость: можно запустить запрос на петабайты данных
• Динамичное масштабирование: можно менять вычислительные ресурсы on-the-fly

Недостатки:

• Дорого: платишь за данные которые сканируешь (не за storage)
• Slow queries стоят денег
• Learning curve на оптимизацию
• Нужно перестроить архитектуру (денормализованные tables vs normalized)

Мой совет: Писать хорошие queries критично:

-- ПЛОХО: сканирует весь table, стоит дорого
SELECT * FROM large_table WHERE event_date >= '2024-01-01';

-- ХОРОШО: используй partition pruning
SELECT user_id, event_type FROM large_table 
WHERE event_date >= CURRENT_DATE - INTERVAL 7 DAY
AND event_type = 'purchase';

5. BigQuery (Google Cloud)

Опыт: Работал в 1 компании на Google Cloud.

Основное назначение:

• Cloud Data Warehouse
• Analytics на big data
• Интеграция с Google Workspace и Analytics 360

Различия от Snowflake:

• Бесплатный tier (1TB месячно)
• Лучше интегрируется с Google Workspace (GA, Google Ads, etc.)
• Читает данные напрямую из Google Cloud Storage (Parquet files)
• SQL dialect немного отличается (ARRAY, STRUCT типы)

Пример (BigQuery specific):

-- BigQuery ARRAY_AGG и UNNEST
SELECT
  user_id,
  ARRAY_AGG(STRUCT(event_name, event_time) ORDER BY event_time LIMIT 10) as recent_events
FROM events
WHERE event_date >= CURRENT_DATE() - 30
GROUP BY user_id;

-- UNNEST для распаковки массивов
SELECT
  user_id,
  event.event_name,
  event.event_time
FROM (
  SELECT user_id, ARRAY_AGG(STRUCT(event_name, event_time)) as events FROM events GROUP BY user_id
) t,
UNNEST(t.events) as event;

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

• Простое масштабирование
• Хорошо работает с nested data (ARRAY, STRUCT)
• Cheap при низком usage
• Отлично для event data analytics

Недостатки:

• Медленнее чем Snowflake для interactive queries (по моему опыту)
• Меньше гибкости с индексами
• Learning curve на ARRAY/STRUCT синтаксис

6. MongoDB (NoSQL)

Опыт: Работал в компании которая использовала MongoDB для product. Анализировал данные из MongoDB.

Что нужно знать для анализа:

• Не реляционная база
• Данные в JSON-like формате (BSON)
• Нет SQL, есть MongoDB Query Language
• Хорошо для nested/unstructured data

Как я анализировал:

// MongoDB Aggregation Pipeline (аналог SQL GROUP BY)
db.orders.aggregate([
  { $match: { status: "completed", created_at: { $gte: ISODate("2024-01-01") } } },
  { $group: { _id: "$customer_id", total_spent: { $sum: "$amount" }, count: { $sum: 1 } } },
  { $sort: { total_spent: -1 } },
  { $limit: 10 }
])

Когда полезна для анализа:

• Когда нужно анализировать nested data
• Гибкая schema (разные документы разная структура)
• Event data с rich context

Недостатки:

• Медленнее чем SQL для аналитики
• Нет join'ов (нужно используемых $lookup что медленно)
• Harder для complex анализа

7. Elasticsearch

Опыт: Работал в компании которая использовала Elasticsearch для логов и metrics.

Основное:

• Full-text search engine
• Большой объём данных
• Quasi-real-time анализ

Использование для анализа:

// Elasticsearch Query DSL (похож на JSON)
GET /logs/_search
{
  "query": {
    "range": {
      "timestamp": { "gte": "2024-01-01" }
    }
  },
  "aggs": {
    "errors_per_hour": {
      "date_histogram": {
        "field": "timestamp",
        "interval": "1h"
      },
      "aggs": {
        "error_count": { "value_count": { "field": "error_id" } }
      }
    }
  }
}

Когда использовать:

• Анализ логов
• Search analytics
• Time-series data (но есть лучше альтернативы)

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

Как я это расскажу на интервью

"Я работал с несколькими базами данных в разных контекстах.

Основная работа была с PostgreSQL и MySQL — production баз где хранилась business data. Я писал SQL queries для анализа, создавал views для analytics team.

В больших компаниях я работал с Snowflake и BigQuery — это cloud data warehouses где хранится все аналитические данные. Я писал сложные запросы для анализа, оптимизировал их (потому что неправильный запрос стоит денег в облаке), и сотрудничал с Data Engineers.

Также работал с Redis для real-time data (leaderboards, active users) и MongoDB когда нужно анализировать nested JSON-like data.

Мой опыт показывает, что нужно понимать разницу между OLTP (production databases) и OLAP (data warehouses). Для аналитики лучше использовать DW, потому что production базы оптимизированы для writes, а не complex analytics queries.

Мой most опыт с PostgreSQL и Snowflake, потому что они лучшие для product analytics."

SQL Skills

Мой SQL level: Advanced. Я могу писать:

• Complex queries с JOINs, subqueries, CTEs
• Window functions (ROW_NUMBER, RANK, LAG, LEAD)
• Aggregation и GROUP BY
• Case statements и conditionals
• Stored procedures и functions
• Query optimization (EXPLAIN PLAN, indexes)
• Handling NULLs правильно

Это критично для Product Analyst роли.