Слияние кода завершено, страница обновится автоматически
Concourse Pipeline
|
Travis Build
Greenplum Database (GPDB) — это продвинутое, полнофункциональное хранилище данных с открытым исходным кодом, основанное на PostgreSQL. Оно обеспечивает мощную и быструю аналитику для объёмов данных размером в петабайт. Уникально ориентированное на аналитику больших данных, Greenplum Database работает на базе самого передового в мире оптимизатора запросов на основе стоимости, обеспечивая высокую производительность аналитических запросов для больших объёмов данных.
Проект Greenplum выпущен под лицензией Apache 2 (http://www.apache.org/licenses/LICENSE-2.0). Мы хотим поблагодарить всех наших прошлых и настоящих участников сообщества и очень заинтересованы во всех новых потенциальных вкладах. Для сообщества Greenplum Database нет слишком маленького вклада, мы поощряем все типы вкладов.
Кластер Greenplum состоит из сервера-координатора и нескольких серверов сегментов. Все пользовательские данные находятся в сегментах, координатор содержит только метаданные. Сервер-координатор и все сегменты используют одну и ту же схему.
Пользователи всегда подключаются к серверу-координатору, который разбивает запрос на фрагменты, выполняемые в сегментах, и собирает результаты.
Более подробную информацию можно найти на веб-сайте проекта (https://greenplum.org/).
GPORCA — это оптимизатор на основе затрат, который используется базой данных Greenplum совместно с планировщиком PostgreSQL. Он также известен как просто ORCA и Pivotal Optimizer. Код для GPORCA находится в src/backend/gporca. По умолчанию он собирается автоматически.
Следуйте шагам macOS (README.macOS.md), чтобы подготовить вашу систему к работе с GPDB.
Следуйте соответствующим шагам Linux (README.Linux.md), чтобы подготовить вашу систему к работе с GPDB.
# Инициализация и обновление подмодулей в репозитории
git submodule update --init
# Настройка среды сборки для установки в /usr/local/gpdb
./configure --with-perl --with-python --with-libxml --with-gssapi --prefix=/usr/local/gpdb
# Компиляция и установка
make -j8
make -j8 install
# Добавление greenplum окружения в текущую работающую оболочку
source /usr/local/gpdb/greenplum_path.sh
# Запуск демонстрационного кластера
make create-demo-cluster
# (gpdemo-env.sh содержит значения __PGPORT__ и __COORDINATOR_DATA_DIRECTORY__)
source gpAux/gpdemo/gpdemo-env.sh
Каталог, TCP-порты, количество сегментов и наличие резервных копий для сегментов и координатора для демонстрационного кластера можно изменить на лету. Вместо make create-demo-cluster рассмотрите:
DATADIRS=/tmp/gpdb-cluster PORT_BASE=5555 NUM_PRIMARY_MIRROR_PAIRS=1 WITH_MIRRORS=false make create-demo-cluster
TCP-порт для теста регрессии можно изменить на лету:
PGPORT=5555 make installcheck-world
Чтобы отключить GPORCA и использовать планировщик Postgres для оптимизации запросов:
set optimizer=off;
Если вы хотите очистить все сгенерированные файлы:
make distclean
make installcheck-world
Основная цель installcheck-world запустит все тесты регрессии в GPDB против работающего кластера. Для тестирования отдельных частей можно запускать соответствующие цели отдельно.
Цель PostgreSQL check не работает. Настройка кластера Greenplum более сложна, чем установка одного узла PostgreSQL, и никто не проделал работу по созданию кластера с помощью make check. Создайте кластер вручную или используйте gpAux/gpdemo/(пример ниже) и запустите основную цель make installcheck-world против него. Патчи приветствуются!
Цель PostgreSQL installcheck работает. Инструменты Git и рабочий процесс
Также рекомендуется подписаться на список рассылки разработчиков, так как некоторые из вкладов могут вызвать более подробные обсуждения там.
После создания учётной записи GitHub необходимо разветвить этот репозиторий, чтобы иметь свою личную копию для начала работы и использовать её в качестве источника запросов на вытягивание.
Любой участник проекта Greenplum должен быть охвачен Корпоративным или Лицензионным соглашением индивидуального участника. Если вы ещё этого не сделали, пожалуйста, заполните и отправьте Лицензионное соглашение участника (Contributor License Agreement). Обратите внимание, что мы допускаем внесение действительно тривиальных изменений без CLA, если они подпадают под категорию очевидных исправлений. Однако, поскольку наш рабочий процесс GitHub по умолчанию проверяет наличие CLA, вам может быть проще отправить его вместо того, чтобы претендовать на исключение «очевидного исправления».
Если ваш вклад является оригинальной работой, можно предположить, что Pivotal выпустит его как часть общего релиза Greenplum, доступного для конечных потребителей под лицензией Apache версии 2.0. Однако в дополнение к этому Pivotal также может принять решение выпустить его под другой лицензией (например, PostgreSQL License для вышестоящих потребителей, которые в этом нуждаются. Типичным примером здесь может быть то, что Pivotal отправляет ваш вклад обратно в сообщество PostgreSQL (что можно сделать либо дословно, либо ваш вклад отправляется как часть более крупного набора изменений).
Если вносимый вами вклад НЕ является оригинальной работой, вы должны указать название лицензии и убедиться, что она аналогична лицензии Apache 2.0. Apache Software Foundation ведёт список этих лицензий в категории A. В дополнение к этому от вас может потребоваться сделать надлежащее указание авторства в файле NOTICE аналогично этим примерам.
Наконец, имейте в виду, что НИКОГДА не рекомендуется удалять лицензионные заголовки из работы, которая не является вашей оригинальной. Даже если вы используете части файла, изначально имевшего лицензионный заголовок вверху, следует придерживаться сохранения его. Как всегда, если вы не совсем уверены в лицензионных последствиях своих вкладов, не стесняйтесь обращаться к нам через список рассылки разработчиков.
Ваши шансы получить обратную связь и увидеть, как ваш код объединён с проектом, во многом зависят от того, насколько детализированы ваши изменения. Если у вас есть большие изменения, мы настоятельно рекомендуем сначала обратиться к списку рассылки разработчиков и поделиться с нами своим предложением, прежде чем тратить много времени на написание кода. Даже когда ваше предложение будет одобрено сообществом, мы всё равно рекомендуем выполнять фактическую работу в виде серии небольших, автономных коммитов. Это значительно упрощает работу рецензента и увеличивает своевременность обратной связи.
Что касается частей C и C++ в Greenplum, мы стараемся следовать соглашениям о кодировании PostgreSQL. Кроме того, мы требуем, чтобы:
Мы рекомендуем использовать git diff --color при просмотре ваших изменений, чтобы у вас не было проблем с пробелами в коде, который вы отправляете.
Вся новая функциональность, внесённая в Greenplum, должна быть покрыта регрессионными тестами, которые вносятся вместе с ней. Если вы не уверены, как тестировать или документировать свою работу, пожалуйста, задайте вопрос в списке рассылки gpdb-dev, и сообщество разработчиков сделает всё возможное, чтобы помочь вам.
Как минимум, вы всегда должны запускать make. ### Проверка установки (installcheck-world)
Это нужно, чтобы убедиться, что вы ничего не нарушаете.
Если изменения, над которыми вы работаете, затрагивают функциональность, общую для PostgreSQL и Greenplum, вас могут попросить перенести их в PostgreSQL. Это делается не только для того, чтобы мы продолжали сокращать разницу между двумя проектами, но и для того, чтобы любые изменения, относящиеся к PostgreSQL, могли получить пользу от гораздо более широкого обзора сообщества основного PostgreSQL. В целом, рекомендуется иметь под рукой оба кода, чтобы вы могли быть уверены, нужно ли переносить ваши изменения.
Чтобы повысить шансы на правильное обсуждение вашего патча или идеи, обратите внимание на рабочий цикл сообщества. Например, если вы отправите совершенно новую идею на этапе бета-версии выпуска, мы можем отложить проверку или нацелить её включение на более позднюю версию. Не стесняйтесь спрашивать в списке рассылки, чтобы узнать больше о политике и сроках выпуска Greenplum.
Как только вы будете готовы поделиться своей работой с основной командой Greenplum и остальным сообществом Greenplum, вы должны отправить все коммиты в ветку в вашем собственном репозитории, разветвлённом от официального Greenplum, и отправить нам запрос на вытягивание (pull request).
Мы приветствуем незавершённые работы, чтобы получить обратную связь на ранней стадии процесса разработки. При открытии запроса на вытягивание выберите «Черновик» в раскрывающемся меню при создании PR, чтобы чётко обозначить цель запроса на вытягивание. Также хорошей практикой является добавление префикса «WIP:» к заголовку.
Все новые функции должны быть отправлены против основной ветки. Исправления ошибок также должны отправляться против основной, если они существуют только в поддерживаемой обратной ветке. Если ошибка существует как в основной, так и в обратной ветвях, объясните это в описании PR.
После отправки запроса на вытягивание вы сразу увидите ряд проверок валидации, выполненных нашими автоматизированными конвейерами CI. Также будет проверка CLA, сообщающая вам, был ли ваш CLA распознан. Если какая-либо из этих проверок не пройдёт, вам нужно будет обновить свой запрос на вытягивание, чтобы решить проблему. Запросы на вытягивание с неудачными проверками валидации вряд ли получат дальнейшую экспертную оценку от членов сообщества.
Имейте в виду, что наиболее распространённой причиной неудачной проверки CLA является несоответствие между электронной почтой в файле и электронной почтой, записанной в коммитах, отправленных как часть запроса на вытягивание.
Если вы не можете понять, почему определённая проверка валидации не удалась, не стесняйтесь спросить в списке разработчиков, но обязательно включите прямую ссылку на запрос на вытягивание в своём электронном письме.
Отправленный запрос на вытягивание с успешными проверками валидации считается доступным для экспертной оценки. Экспертная оценка — это процесс, который гарантирует, что вклад в Greenplum имеет высокое качество и хорошо соответствует дорожной карте и ожиданиям сообщества. Каждому члену сообщества Greenplum рекомендуется просматривать запросы на вытягивание и оставлять отзывы. Поскольку вам не нужно быть членом основной команды, чтобы сделать это, мы рекомендуем следить за потоком обзоров запросов всем, кто заинтересован стать долгосрочным участником Greenplum. Как сказал бы Линус, «при достаточном количестве глаз все ошибки поверхностны».
Одним из результатов экспертной оценки может быть консенсус о том, что вам необходимо изменить свой запрос определённым образом. GitHub позволяет отправлять дополнительные коммиты в ветвь, из которой был отправлен запрос на вытягивание. Эти дополнительные коммиты будут видны всем рецензентам.
Экспертная оценка завершается, когда она получает хотя бы один голос +1 и ни одного голоса -1 от участников. На этом этапе вы можете ожидать, что один из членов основной команды включит ваши изменения в проект.
Greenplum гордится тем, что является совместной средой, ориентированной на консенсус. Мы не верим в вето, и любой голос -1, поданный в рамках экспертной оценки, должен иметь подробное техническое объяснение того, что не так с изменением. В случае возникновения серьёзных разногласий может быть целесообразно вынести вопрос в список рассылки, поскольку это обеспечивает более естественный ход обсуждения.
В любой момент во время проверки исправления могут возникнуть задержки из-за доступности проверяющих и членов основной команды. Пожалуйста, проявите терпение. При этом не стоит отчаиваться. Если вы не получаете ожидаемую обратную связь в течение нескольких дней, добавьте комментарий с просьбой обновить информацию о запросе на извлечение или отправьте электронное письмо в список рассылки.
Иногда вы будете видеть, как члены основной команды делают прямые коммиты в репозиторий без использования процесса запроса на извлечение. Это предназначено только для небольших изменений, и мы руководствуемся следующим правилом: если изменение затрагивает функциональность, которая может привести к сбою теста, оно должно пройти через процесс запроса на извлечение. С другой стороны, если изменение касается нефункциональной части кодовой базы (например, исправление опечатки внутри блока комментариев), члены основной команды могут решить просто сделать прямой коммит в репозиторий.
Для документации по Greenplum Database, пожалуйста, обратитесь к онлайн-документации.
Дополнительную информацию, выходящую за рамки этого README, можно найти на нашей вики.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Комментарии ( 0 )