Компания Skype использует PostgreSQL в качестве главной СУБД. В Skype для масштабирования применяется традиционный интерфейс с использованием хранимых процедур для доступа к данным, поверх хранимых процедур, организован слой прокси серверов, которые распределяют SQL запросы по серверам БД.

Ниже, перевод заметок из блога highscalability.com, касающихся архитектуры Skype:

• Целью является архитектура, способная одновременно обслуживать более миллиарда клиентов. Непрактично решать такую задачу одним достаточно большим компьютером, поэтому применяется горизонтальное масштабирование.
• Применены серверы dual Opteron или quad Opteron со SCSI RAID;
• Используется стандартный подход к масштабированию: начать с одной БД. Добавляемые новые базы данных разделяются по функциональности. Реплицируются наиболее часто читаемые данные для увеличения скорости доступа. Затем данные горизонтально распределяются по множественным узлам.
• Skype использует традиционную архитектуру хранения данных в которой весь доступ к БД инкапсулирован в хранимых процедурах. Это позволяет осуществлять оптимизацию производительности не затрагивая фронтэндовые серверы. И это четко вписывается в их стратегию кластеризации с помощью PL/Proxy.
• PL/Proxy используется для масштабирования онлайновой обработки транзакций, путем создания горизонтально распределенного кластера:
  • Запросы к БД маршрутизируются через прокси на набор серверов БД. Прокси распределяет запросы по значению поля, обычно по первичному ключу.
  • Например, вы можете распределить пользователей по кластеру по имени. Хеширующая функция определяет на какой сервер попадут данные пользователя.
  • Запросы к удаленной БД выполняются на новом языке СУБД PostgreSQL, называемом plproxy. Пример из блога Кристо Кейва (Kristo Kaiv):

    Вначале код для вставки в БД:
    
    CREATE OR REPLACE FUNCTION insert_user(i_username text) RETURNS text AS $$
    BEGIN
    PERFORM 1 FROM users WHERE username = i_username;
    IF NOT FOUND THEN
    INSERT INTO users (username) VALUES (i_username);
    RETURN 'user created';
    ELSE
    RETURN 'user already exists';
    END IF;
    END;
    $$ LANGUAGE plpgsql SECURITY DEFINER;
    
    А это код определяет ноду в которой находится пользователь:
    
    queries=#
    CREATE OR REPLACE FUNCTION insert_user(i_username text) RETURNS TEXT AS $$
    CLUSTER 'queries'; RUN ON hashtext(i_username);
    $$ LANGUAGE plproxy;
    
    SQL запрос выглядит как обычно:
    
    SELECT insert_user("username");
    
    

  • Результат запроса точно такой, как если-бы запрос был исполнен прямо на удаленной БД.
  • Сейчас удается маршрутизировать 1000-2000 запросов в секунду на 16-узловой кластер используя машины Dual Opteron.
• Разработчикам Skype нравится подход PL/Proxy к онлайновой обработке транзакций потому что:
  • PL/Proxy сереверы образуют масштабируемую и единообразную "БД-шину". Прокси надежны, благодаря избыточной конфигурации, если один сломается вы сможете просто присоединиться к другому. И если слой прокси станет медленным, можно добавить еще прокси серверов и распределить загрузку между ними.
  • Для улучшения производительности можно добавить еще узлы.
  • Только данные сбойной секции недоступны во время аварийного переключения (failover). Все другие секции функционируют нормально.
• В качестве менеджера соединений используется PgBouncer. PL/Proxy "некоторым образом тратит впустую соединения, поскольку открывает новое соединение к каждой секции от каждого процесса", менеджер соединений помогает уменьшить число соединений.
• Серверы горячего резервирования создаются через передачу лога транзакций (WAL, Write Ahead Log), но они, как правило, простаивают;
• Более изощренные организации часто используют специальную транзакционную СУБД, именно для удовлетворения нужд высокопроизводительной обработки транзакций (OLTP), плюс делают отдельные системы для нетранзакционных задач. Например, для обработки аналитической информации и обнаружения проблем часто используются системы аналитической обработки в реальном времени (OLAP, online analytical processing). Они отличаются от OLTP схемой, индексами, прочим. Skype также использует отдельные системы для презентационного уровня веб приложений, отправки почты и печати чеков. Это требует организации передачи данных из OLTP в другие системы.
• Первоначально для передачи данных в другие системы использовалась Slony1, но "по мере роста сложности и нагрузки, Slony1 начала создавать все большие и большие проблемы.";
• Для решения этих проблем разработчики Skype разработали собственный легковесный менеджер очередей и набор инструментов репликации SkyTools.

Подход с использованием прокси интересен и является архитектурой, которую ранее не рассматривали в блоге highscalability.com. Его сила в косвенном решении проблем, что имеет такие преимущества:

• Приложения независимы от структуры серверов БД, которая спрятана за прокси-серверами.
• Не нужно изменять приложения при изменении секционирования, меппинга или при других изменениях.
• Балансировка нагрузки, горячее резервирование и разделение чтения/записи невидимы для приложений.

Недостатки:

• Сниженная производительность. Добавлен дополнительный шаг в обработке запросов и требуются отдельные ресурсы на обработку магии прозрачности.
• Невозможно делать объединения и другие операции использующие данные на разных серверах.
• Дополнительные сложности в конфигурации из-за работы через прокси серверы и дополнительная работа по администрированию прокси-серверов и их горячему резервированию.

В некоторых ситуациях недостатки могут перевесить преимущества. Если вы используете MySQL и этот подход вас заинтересовал, Тодд Хофф считает, что вам стоит посмотреть на MySQL Proxy, который делает похожее но немного по другому.