Компания Skype планирует обслуживать миллиард пользователей с PostgreSQL

Компания 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, который делает похожее но немного по другому. - Сообщает Opennet.ru



Опубликовал admin
15 Апр, Вторник 2008г.



Программирование для чайников.