Реляционные СУБД и распределенные системы: конфликт архитектур

Рождение монолита: как реляционные СУБД захватили мир

Ключевые принципы реляционной модели vs масштабируемость

Почему декомпозиция реляционных СУБД - столь сложная задача

Нормализация против шардирования: непримиримые противоречия

Ключевые причины ограниченности реляционных баз данных в распределенных средах и последствия для современных систем

Реляционные СУБД
Помогите разобраться, не могу найти информацию о том, какие из данных реляционных СУБД обладают...

Сетевые и реляционные базы данных
Всем доброго времени суток.!) Существует ли и возможен ли в принципе алгоритм однозначного...

реляционные базы данных
в базах совсем новичок. кто подскажет, как хранить статьи типа:...

Создать реляционные таблицы на основе концептуальной модели
Требуется на основе концептуальной модели прикрепленной к теме, создать реляционные таблицы с...

Фундаментальные противоречия

ACID vs CAP: непримиримые соперники

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

/* Упрощённая иллюстрация конфликта CAP в коде */
// Реляционный подход (CA-система)
try {
    beginTransaction();
    // Операции, требующие согласованности
    // Если какая-то нода недоступна - транзакция откатывается
    commitTransaction();
} catch (NodeUnavailableException e) {
    // Система предпочитает отказать в обслуживании,
    // чем допустить несогласованность
    rollbackTransaction();
    throw new ServiceUnavailableException();
}
 
// Распределённый подход (AP-система)
try {
    writeDataToAvailableNodes();
    scheduleConsistencyReconciliation();
    // Система предпочитает временную несогласованность,
    // но остаётся доступной
    return success();
} catch (Exception e) {
    // Даже при частичном успехе считаем операцию выполненной
    logForLaterResolution(e);
    return partialSuccess();
}

Транзакционная модель: тяжёлое наследие

Проблема глобальных взаимоблокировок

1
2
3
4
5
6
7
8
9
10
11
12
13

-- Распределённая взаимоблокировка между двумя узлами
-- На узле A:
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1; -- блокирует запись 1
-- Ждём блокировки записи 2 на узле B
 
-- На узле B (одновременно):
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 200 WHERE id = 2; -- блокирует запись 2
-- Ждём блокировки записи 1 на узле A
 
-- Результат: взаимная блокировка между узлами, 
-- которую сложно обнаружить автоматически

Эволюция без революции

Теорема CAP на практике: когда теория становится болью

• Заблокировать операции записи в одном из датацентров, обеспечив согласованость (CP-система)
• Разрешить записи в обоих датацентрах, рискуя временной несогласованностью (AP-система)

1
2
3
4
5
6
7
8
9
10
11
12

# Пример реализации AP-подхода с последующим разрешением конфликтов
def process_order(product_id, user_id, datacenter_id):
    # Локальная запись заказа - работает даже при сетевом разделении
    local_inventory = get_local_inventory(product_id, datacenter_id)
    if local_inventory > 0:
        create_order(product_id, user_id)
        decrement_local_inventory(product_id, datacenter_id)
        # Асинхронная репликация и разрешение конфликтов
        schedule_inventory_reconciliation(product_id)
        return "Order placed"
    else:
        return "Product unavailable locally"

Двухфазная фиксация: когда лекарство хуже болезни

• На каждом этапе протокола требуется сетевой обмен между участниками, что многократно увеличивает латентность.
• Ресурсы остаются заблокированными до завершения всей процедуры.
• Даже при минимальном количестве участников (два узла) требуется минимум три сетевых взаимодействия.

Глобальные взаимоблокировки: охота на невидимого зверя

Технические ограничения

Централизованная архитектура и её последствия

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// Упрощенная имитация глобального менеджера блокировок в распределенной среде
public class GlobalLockManager {
    private Map<String, Lock> resourceLocks = new ConcurrentHashMap<>();
    
    public synchronized boolean acquireLock(String resourceId, String transactionId) {
        // Этот метод должен быть вызван ВСЕМИ узлами распределенной системы
        // Что создает огромную нагрузку на центральный компонент
        Lock lock = resourceLocks.computeIfAbsent(resourceId, k -> new Lock());
        return lock.acquire(transactionId);
    }
    
    public synchronized void releaseLock(String resourceId, String transactionId) {
        Lock lock = resourceLocks.get(resourceId);
        if (lock != null) {
            lock.release(transactionId);
        }
    }
}

Согласованность кэша: проблема "невидимой руки"

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// Пример проблемы с кэшированием в распределенной среде
// Узел А выполняет:
void UpdateRecordOnNodeA(int recordId, string newValue) {
    // Обновляем запись в базе данных
    ExecuteUpdate($"UPDATE records SET value = '{newValue}' WHERE id = {recordId}");
    
    // Отправляем уведомление об инвалидации кэша другим узлам
    // Но что если это сообщение задержится или потеряется?
    BroadcastCacheInvalidation("records", recordId);
}
 
// А в это время на узле B:
string GetRecordFromNodeB(int recordId) {
    // Проверяем кэш
    if (cache.ContainsKey($"records:{recordId}")) {
        // Возвращаем устаревшие данные!
        return cache.Get($"records:{recordId}");
    }
    
    // Загружаем из базы
    return ExecuteQuery($"SELECT value FROM records WHERE id = {recordId}");
}

JOIN в распределённой среде: цена "перекрёстных" запросов

1
2
3
4

SELECT u.name, o.order_date, o.total_amount
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.total_amount > 1000;

Проблема "горячих" таблиц: шардирование не всегда спасает

1. Справочники и каталоги товаров.
2. Таблицы настроек и конфигураций.
3. Таблицы со счётчиками и агрегированной статистикой.

1
2
3
4
5
6
7
8

# Пример неравномерного распределения нагрузки при наивном шардировании
def route_query_to_shard(user_id):
    # Простое шардирование по хешу идентификатора
    shard_id = hash(user_id) % NUM_SHARDS
    
    # Проблема: если распределение user_id неравномерно или некоторые
    # пользователи гораздо активнее других, шарды будут нагружены неравномерно
    return shards[shard_id]

Индексы в распределенной среде: сложность поддержания согласованности

1
2
3
4
5
6
7
8
9
10
11
12

-- Допустим, данные шардированы по user_id
-- Но нам часто нужно искать по email
 
-- На шарде 1:
CREATE INDEX idx_email_shard1 ON users_shard1(email);
 
-- На шарде 2:
CREATE INDEX idx_email_shard2 ON users_shard2(email);
 
-- Проблема: при поиске по email придётся опрашивать ВСЕ шарды
-- или поддерживать глобальный индекс, что сложно
SELECT * FROM users WHERE email = 'user@example.com';

Проблемы миграции схемы данных

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// Пример обработки разных версий схемы на уровне приложения
public void processRecord(Record record) {
  // Проверяем, есть ли у записи новое поле
  if (record.hasField("new_column")) {
    // Обработка по новой схеме
    processWithNewSchema(record);
  } else {
    // Обработка по старой схеме
    processWithOldSchema(record);
    
    // Возможно, нужно мигрировать запись на новую схему
    migrateRecordToNewSchema(record);
  }
}

Оптимизация запросов: поиск иголки в стоге сена

1
2
3
4
5
6
7
8
9
10
11
12
13
14

-- Один и тот же запрос может иметь кардинально разные планы выполнения
-- в зависимости от распределения данных
 
-- План 1: если tables A и B на одном узле, а C на другом
-- Сначала выполним JOIN A и B локально, затем отправим результат на узел с C
 
-- План 2: если таблицы A и C на одном узле, а B на другом
-- Сначала отправляем нужные данные из B на узел с A и C, 
-- затем выполняем все соединения локально
 
EXPLAIN SELECT A.col1, B.col2, C.col3
FROM A JOIN B ON A.id = B.id
JOIN C ON B.id = C.id
WHERE A.date > '2023-01-01';

Мониторинг и диагностика: чёрная магия распределённого дебагинга

1
2
3
4
5
6
7
8
9
10
11

# Пример проблемы диагностики в распределенной среде
# На узле A видим:
ERROR: Transaction aborted due to timeout waiting for lock
 
# На узле B в то же время:
WARNING: Network latency to node C exceeds threshold
 
# На узле C:
INFO: High CPU usage due to background vacuum process
 
# Корреляция этих событий требует специализированных инструментов и навыков

Скрытая стоимость распределенных решений

Современные альтернативы и гибридные подходы

NoSQL: когда SQL становится лишним грузом

1. Документоориентированные СУБД (MongoDB, CouchDB) отказались от жёсткой схемы и реляционных связей в пользу гибких документов, которые можно легко шардировать.
2. Столбцовые базы данных (Cassandra, HBase) перевернули традиционную модель с ног на голову, сгруппировав данные по столбцам вместо строк, что дало значительный выигрыш в производительности для определённых видов аналитических запросов.
3. Графовые базы данных (Neo4j, JanusGraph) сфокусировались на эффективном представлении и обходе связей между сущностями — задаче, с которой реляционные СУБД справляются неиделаьно.
4. Key-Value хранилища (Redis, Riak) довели простоту до предела, сосредоточившись на сверхбыстром доступе к данным по ключу, жертвуя сложными запросами.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// Пример работы с MongoDB - документоориентированной СУБД
// Вставка документа без необходимости предварительного создания схемы
db.users.insertOne({
  name: "Алексей",
  email: "alex@example.com",
  preferences: {
    theme: "dark",
    notifications: ["email", "push"],
    languages: ["ru", "en"]
  },
  lastLogin: new Date()
});
 
// Запрос с вложенными полями - естественно для документной модели
db.users.find({
  "preferences.theme": "dark",
  "preferences.languages": "en"
});

NewSQL: старый добрый SQL в новой обёртке

1. Google Spanner — глобально распределённая система с линеаризуемыми транзакциями, использующая атомные часы для минимизации проблем согласованности.
2. CockroachDB — открытая СУБД, вдохновлённая Spanner, автоматически шардирует и реплицирует данные, сохраняя ACID-свойства.
3. VoltDB — распределённая in-memory СУБД с высокой производительностью, оптимизрованная для OLTP-нагрузок.
4. TiDB — совместимая с MySQL распределённая СУБД с горизонтальным масштабированием.

Полиглотное персистентное хранение: лучший инструмент для каждой задачи

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# Пример архитектуры с полиглотным хранением
class UserService:
    def __init__(self):
        # Профили пользователей в документной БД для гибкости
        self.profile_db = MongoClient().profiles
        
        # Сессии в key-value хранилище для скорости
        self.session_store = redis.Redis()
        
        # Транзакционные данные в реляционной БД для согласованости
        self.orders_db = psycopg2.connect("dbname=orders")
        
        # Аналитические данные в столбцовой БД для аггрегации
        self.analytics_db = cassandra.cluster.Cluster().connect("analytics")
 
    def get_user_dashboard(self, user_id):
        # Собираем данные из разных источников
        profile = self.profile_db.users.find_one({"_id": user_id})
        active_session = self.session_store.get(f"session:{user_id}")
        
        with self.orders_db.cursor() as cursor:
            cursor.execute("SELECT * FROM recent_orders WHERE user_id = %s", (user_id,))
            recent_orders = cursor.fetchall()
        
        user_stats = self.analytics_db.execute(
            "SELECT * FROM user_activity WHERE user_id = %s", (user_id,)
        ).one()
        
        # Объединяем данные из разных источников
        return {
            "profile": profile,
            "session": active_session,
            "recent_orders": recent_orders,
            "stats": user_stats
        }

• Поддержание согласованости между разными системами.
• Управление метаданными и схемами в разных хранилищах.
• Повышенная сложность операционного управления.

Потоковая обработка: данные как бесконечный поток

• Данные представляются как непрерывный поток событий.
• Обработка происходит инкрементально, по мере поступления данных.
• Состояние системы формируется как результат обработки всего потока.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// Пример обработки потока данных с помощью Kafka Streams
StreamsBuilder builder = new StreamsBuilder();
 
// Считываем поток транзакций
KStream<String, Transaction> transactions = builder.stream("transactions-topic");
 
// Группируем по аккаунту и считаем баланс
KTable<String, Double> balances = transactions
    .groupByKey()
    .aggregate(
        () -> 0.0,
        (key, transaction, balance) -> balance + transaction.getAmount(),
        Materialized.as("balances-store")
    );
 
// Отправляем обновленные балансы в другой топик
balances.toStream().to("account-balances");

Event Sourcing и CQRS: архитектурная эволюция

• Event Sourcing сохраняет не текущее состояние, а последовательность событий, которые привели к этому состоянию.
• CQRS разделяет операции чтения и записи, позволяя оптимизировать их независимо.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

// Пример Event Sourcing для банковского аккаунта
public class AccountAggregate {
    private double balance = 0;
    private List<DomainEvent> uncommittedEvents = new List<DomainEvent>();
    
    // Применение команды генерирует события
    public void Process(DepositeCommand cmd) {
        if (cmd.Amount <= 0) throw new ArgumentException("Amount must be positive");
        
        // Генерируем событие
        var evt = new DepositedEvent(cmd.AccountId, cmd.Amount, DateTime.Now);
        
        // Применяем событие к текущему состоянию
        Apply(evt);
        
        // Сохраняем для последующей записи в event store
        uncommittedEvents.Add(evt);
    }
    
    // Обновление состояния на основе события
    private void Apply(DepositedEvent evt) {
        balance += evt.Amount;
    }
    
    // Восстановление состояния из истории событий
    public void LoadFromHistory(IEnumerable<DomainEvent> events) {
        foreach (var evt in events) {
            switch (evt) {
                case DepositedEvent dep: Apply(dep); break;
                case WithdrawnEvent wit: Apply(wit); break;
                // Другие типы событий
            }
        }
    }
}

Микросервисная архитектура: данные в эпоху декомпозиции

• Локализация данных — каждый сервис работает преимущественно со "своими" данными, минимизируя распределенные запросы.
• Технологическая гетерогенность — сервисы могут использовать разные СУБД в зависимости от характера данных.
• Независимое масштабирование — хранилища масштабируются вместе с сервисами, которые они обслуживают.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

// Пример организации микросервисов с различными хранилищами
@Service
public class OrderProcessingService {
  private final OrderRepository orderRepository; // PostgreSQL
  private final InventoryClient inventoryClient; // gRPC клиент к другому сервису
  private final PaymentClient paymentClient; // REST клиент к платёжному сервису
  
  public OrderResult processOrder(Order order) {
      // Проверка доступности товаров через API другого сервиса
      InventoryStatus inventoryStatus = inventoryClient.checkAvailability(
          order.getItems()
      );
      
      if (!inventoryStatus.isAvailable()) {
          return OrderResult.unavailable(inventoryStatus.getUnavailableItems());
      }
      
      // Резервирование товаров через API
      inventoryClient.reserve(order.getItems());
      
      // Обработка платежа через платёжный сервис
      PaymentResult payment = paymentClient.processPayment(
          order.getPaymentDetails(), 
          order.getTotalAmount()
      );
      
      if (!payment.isSuccessful()) {
          // Откат резервирования при неудачном платеже
          inventoryClient.cancelReservation(order.getItems());
          return OrderResult.paymentFailed(payment.getErrorMessage());
      }
      
      // Сохранение заказа локально
      orderRepository.save(order.withStatus(OrderStatus.PAID));
      
      return OrderResult.success(order.getId());
  }
}

Распределенная SAGA: хореография vs. оркестрация

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

// Пример Saga с оркестрацией в TypeScript
class OrderSaga {
  private readonly orderService: OrderService;
  private readonly inventoryService: InventoryService;
  private readonly paymentService: PaymentService;
  private readonly shipmentService: ShipmentService;
  
  async executePlaceOrder(orderId: string): Promise<void> {
      try {
          // Шаг 1: Создаём заказ
          await this.orderService.createOrder(orderId);
          
          try {
              // Шаг 2: Резервируем товары
              await this.inventoryService.reserveItems(orderId);
              
              try {
                  // Шаг 3: Обрабатываем платёж
                  await this.paymentService.processPayment(orderId);
                  
                  try {
                      // Шаг 4: Создаём отгрузку
                      await this.shipmentService.scheduleShipment(orderId);
                      
                      // Успешное завершение
                      await this.orderService.completeOrder(orderId);
                  } catch (e) {
                      // Компенсация: Отмена платежа
                      await this.paymentService.refundPayment(orderId);
                      // Продолжаем распространение ошибки
                      throw e;
                  }
              } catch (e) {
                  // Компенсация: Освобождение товаров
                  await this.inventoryService.releaseItems(orderId);
                  throw e;
              }
          } catch (e) {
              // Компенсация: Отмена заказа
              await this.orderService.cancelOrder(orderId);
              throw e;
          }
      } catch (e) {
          // Финальная обработка ошибки
          console.error(`Failed to process order ${orderId}:`, e);
          throw e;
      }
  }
}

Федеративные базы данных: объединяя разрозненные источники

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# Пример федеративного GraphQL API
# Схема сервиса "Пользователи"
type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
}
 
# Схема сервиса "Заказы"
type Order {
  id: ID!
  user: User! @provides(fields: "id")
  items: [OrderItem!]!
  totalAmount: Float!
}
 
# Объединенная схема позволяет делать запросы через границы сервисов
# Пример запроса, затрагивающего оба сервиса:
# {
#   orders {
#     id
#     totalAmount
#     user {
#       name
#       email
#     }
#   }
# }

Ситуационный анализ: выбор правильной технологии

1. Финансовые системы с жёсткими требованиями к консистентности могут предпочесть NewSQL решения или классические реляционные СУБД с ограниченным шардированием.
2. Социальные сети с высокими нагрузками на запись и гибкими требованиями к согласованности выигрывают от использования распределённых NoSQL систем.
3. E-commerce платформы часто применяют полиглотный подход: реляционные СУБД для транзакционных данных, документные хранилища для каталогов товаров, кэшировние для сеансов и корзин.

Экспертное заключение с рекомендациями по выбору архитектуры

Когда реляционные СУБД всё ещё выигрывают

Ключевые критерии выбора архитектуры

Гибридный подход как золотая середина

• Основные транзакционные данные в PostgreSQL с мастер-реплика конфигурацией.
• Сессионные данные и кэширование в Redis.
• Полнотекстовый поиск в Elasticsearch.
• События и логи в Kafka с последующей аггрегацией в аналитическое хранилище.

Заключительная мысль

Реляционные оперции
Запишите результат выполнения следующих реляционных операций: 1) E = ОценкиИнформатика UNION...

Реляционные операции
Здравствуйте есть три запроса SELECT first_name,last_name,address from customer left JOIN address...

Реляционные операторы и преобразования
Какие реляционные операторы осуществляют следующие преобразования: а) преобразование отношения в...

Что проще изучить - Реляционные или Нереляционные Базы данных?
Скажите, если изучать Базы данных с нуля, что проще изучить и Почему? Я студент, мне на выбор...

Распределенные системы
Пожалуйста, помогите выполнить задание с помощью программы Windows Azure Queue по теме:...

Импортирование из СУБД Linter в СУБД PostgreSQL
Други, кто-нибудь может помочь с импортированием из СУБД Linter в СУБД PostgreSQL

СУБД Oracle vs СУБД SAP HANA
Коллеги, в России появилась новая СУБД, которая создавалась компанией SAP AG с целью замены СУБД,...

Метрика производительности СУБД и статистический анализ производительности СУБД
Добрый день, коллеги. Интересует вопрос , кто-то ещё рассчитывает метрику производительности...

Распределенные транзакции в триггере (7391)
Добрый день. Вопрос такой: На Win2003 Ent. edition поставлены 2 экземпляра SQL Server2000 Ent....

Распределенные базы данных в С++ Builder
Нужна информация по распределенным базам данных в С++ Builder. Подскажите какой-нибудь ресурс....

ORA-02064: распределенные операции не поддерживаются
Всем привет. Граждане спецы оракла, помогите!!! Возникла ошибка, не знаю как исправить. суть...

распределенные базы данных
Здравствуйте! Я создал распределенною базу данных, в SQL Server 2008, с 3-мя узлами. Какие...