Please enable JavaScript.

Coggle requires JavaScript to display documents.

Общие сведения - Coggle Diagram

- - - - Синтаксис SQL, объекты БД, встроенные функции
      - Структура системного каталога
      - Механизм реализации транзакций
      - Ролевая модель
      - Работа драйвера для PostgreSQL
    - - Иная функциональность, специфичные изменения в системном каталоге
      - Некоторая функциональность PostgreSQL недоступна в Greenplum
      - Все механизмы PostgreSQL переписаны под MPP архитектуру
  - - - Несмотря на то, что управление кластером и запросы пользователя идут через мастер, загрузка-выгрузка данных из внешних источников в Greenplum может осуществляться через сегменты. Так обеспечивается распараллеливание процессов загрузки-выгрузки и кратное увеличение производительности.
        
        Со стороны клиента параллельная загрузка данных в Greenplum выглядит как SELECT из таблицы, которая ссылается на внешний источник, а выгрузка данных из Greenplum — как INSERT в неё. Такие таблицы для загрузки называются внешними и не содержат данных, но содержат путь до данных во внешнем источнике в своём DDL. Под капотом этого механизма используются сервисы PXF или gpfdist, входящие в состав Greenplum.
        
        Для работоспособности Greenplum необходимо, чтобы были доступны все сегменты или их зеркала.
    - - В целях отказоустойчивости, все сегменты в кластере дублируются, т.е. у каждой порции данных в Greenplum есть копия (реплика) на другом хосте
        
        Типы сегментов
        
        Мастер. Присутствует в кластере в единственном экземпляре, резервируется standby мастером и располагается на мастер-хосте. Принимает подключения клиентов, выдает результаты запросов, обеспечивает координацию работы всего кластера
        
        Резервный мастер. Принимает поток репликации с мастера. Располагается на отдельном резевном мастер-хосте. К нему можно подключиться только в случае отказа основного мастера
        
        Первичные сегменты. Этих сегментов в кластере несколько. Они располагаются на сегмент-хостах. В своих директориях первичные сегменты хранят пользовательские данные и реплику каталога БД. На первичных сегментах обрабатываются SQL- и DML-операции, они несут основную пользовательскую нагрузку.
        
        Сегменты-зеркала. Этих сегментов в кластере столько же, сколько и первичных. Зеркала располагаются на сегмент-хостах и хранят реплики данных с первичных сегментов. Они не обрабатывают запросы, а только принимают поток репликации данных, поэтому почти не создают нагрузку на процессор и память. Репликация на зеркалах синхронная: при записи данных на первичный сегмент транзакция не закончится, пока данные не реплицируются на зеркало.
      - Количество сегментов на сегмент-хостах всегда одинаково для обеспечения равномерности нагрузки по хостам.
      - У одного первичного сегмента одно и только одно зеркало, которое располагается на другом сегмент-хосте. Количество зеркал совпадает с количеством первичных сегментов.
      - Вы можете посмотреть список всех сегментов вместе с мастером и резервным мастером в системной таблице gp_segment_configuration
      - Представь, что у нас есть кластер Greenplum, состоящий из 10 серверов. Один сервер — мастер, ещё один сервер — реплика мастера и 8 сегментных серверов. При инициализации кластера мы сконфигурировали 4 сегмента на хост. Получается, у нас есть 8 сегментных серверов x 4 сегмента на хост = 32 сегмента. Помимо этих 32 сегментов у нас обязательно есть 32 зеркала, располагающихся на тех же хостах, а также сегменты мастера и резервного мастера.
        Всего в кластере фактически 32+32+1+1 = 66 сегментов. Их можно увидеть в конфигурационной таблице gp_segment_configuration. Однако данные обрабатываются на 32 первичных сегментах. В этом случае мы говорим, что у нас в кластере 32 сегмента, оставляя зеркала и мастера за скобками как сами собой разумеющиеся.