🥇오픈 소스 데이터베이스에서 우리가 하는 일과 이유. 안드레이 보로딘(Yandex.Cloud)

다음 데이터베이스에 대한 Yandex의 기여도가 검토됩니다.

클릭 하우스
오디세이
특정 시점으로 복구(WAL-G)
PostgreSQL(logerrors, Amcheck, heapcheck 포함)
그린플럼

비디오 :

안녕하세요! 내 이름은 안드레이 보로딘입니다. 제가 Yandex.Cloud에서 하는 일은 Yandex.Cloud 및 Yandex.Cloud 고객의 이익을 위해 개방형 관계형 데이터베이스를 개발하는 것입니다.

이 강연에서는 규모에 따른 개방형 데이터베이스가 직면한 과제에 대해 이야기하겠습니다. 왜 중요 함? 모기처럼 나중에 코끼리가 되는 아주 작은 문제들 때문입니다. 클러스터가 많으면 크기가 커집니다.

그러나 그것은 중요한 것이 아닙니다. 믿을 수 없는 일이 일어납니다. 백만분의 일에 한 번씩 일어나는 일들. 그리고 클라우드 환경에서는 이에 대비해야 합니다. 왜냐하면 무언가 대규모로 존재하면 놀라운 일이 일어날 가능성이 매우 높기 때문입니다.

하지만! 개방형 데이터베이스의 장점은 무엇입니까? 사실은 어떤 문제라도 해결할 수 있는 이론적 기회가 있다는 것입니다. 소스 코드가 있고 프로그래밍 지식이 있습니다. 우리는 그것을 결합하면 작동합니다.

오픈 소스 소프트웨어 작업에는 어떤 접근 방식이 있나요?

가장 간단한 접근 방식은 소프트웨어를 사용하는 것입니다. 프로토콜을 사용하고, 표준을 사용하고, 형식을 사용하고, 오픈 소스 소프트웨어에서 쿼리를 작성한다면 이미 이를 지원하고 있는 것입니다.
생태계를 더 크게 만들고 있습니다. 버그를 조기에 발견할 가능성이 높아집니다. 이 시스템의 신뢰성이 향상됩니다. 시장에서 개발자의 가용성이 높아집니다. 당신은 이 소프트웨어를 개선합니다. 스타일을 완성하고 뭔가를 손봤다면 당신은 이미 기여자입니다.
또 다른 이해 가능한 접근 방식은 오픈 소스 소프트웨어를 후원하는 것입니다. 예를 들어, 잘 알려진 Google Summer of Code 프로그램은 Google이 특정 라이센스 요구 사항을 충족하는 개방형 소프트웨어 프로젝트를 개발할 수 있도록 전 세계의 많은 학생들에게 이해할 수 있는 돈을 지불하는 경우입니다.
이는 초점을 커뮤니티에서 벗어나지 않고도 소프트웨어를 발전시킬 수 있다는 점에서 매우 흥미로운 접근 방식입니다. 거대 기술 기업인 Google은 우리가 이 기능을 원한다고 말하는 것이 아니라 이 버그를 수정하고 싶고 이것이 바로 우리가 파헤쳐야 할 부분입니다. 구글은 “당신이 하는 일을 하세요. 지금까지 해오던 방식대로 계속 노력하면 모든 것이 잘 될 것입니다.”
오픈소스 참여에 대한 다음 접근 방식은 참여입니다. 오픈 소스 소프트웨어에 문제가 있고 개발자가 있으면 개발자가 문제 해결을 시작합니다. 그들은 귀하의 인프라를 더욱 효율적으로 만들고, 프로그램을 더 빠르고 안정적으로 만들기 시작합니다.

오픈 소스 소프트웨어 분야에서 가장 유명한 Yandex 프로젝트 중 하나는 ClickHouse입니다. 이는 Yandex.Metrica가 직면한 과제에 대한 대응으로 탄생한 데이터베이스입니다.

그리고 데이터베이스로서 생태계를 만들고 (Yandex 내뿐만 아니라) 다른 개발자와 함께 개발하기 위해 오픈 소스로 만들어졌습니다. 그리고 이제 이것은 다양한 회사가 참여하는 큰 프로젝트입니다.

Yandex.Cloud에서는 Yandex Object Storage, 즉 클라우드 스토리지 위에 ClickHouse를 만들었습니다.

클라우드에서 이것이 왜 중요한가요? 모든 데이터베이스는 이 삼각형, 피라미드, 메모리 유형 계층 구조에서 작동하기 때문입니다. 빠르지만 작은 레지스터와 값싸고 크지만 느린 SSD, 하드 드라이브 및 기타 블록 장치가 있습니다. 그리고 피라미드 꼭대기에서 효율적이라면 데이터베이스가 빠른 것입니다. 이 피라미드의 맨 아래에서 효율적이라면 확장된 데이터베이스를 갖게 됩니다. 그리고 이런 점에서 아래에서 또 다른 레이어를 추가하는 것은 데이터베이스의 확장성을 높이는 논리적인 접근 방식입니다.

어떻게 할 수 있었나요? 이것이 이 보고서의 중요한 포인트입니다.

MDS를 통해 ClickHouse를 구현할 수 있습니다. MDS는 내부 Yandex 클라우드 스토리지 인터페이스입니다. 일반적인 S3 프로토콜보다 더 복잡하지만 블록 장치에 더 적합합니다. 데이터를 기록하는 것이 더 좋습니다. 더 많은 프로그래밍이 필요합니다. 프로그래머는 프로그래밍을 할 것이고 심지어 훌륭하고 흥미로울 수도 있습니다.
S3는 특정 유형의 워크로드에 덜 적응하는 비용으로 인터페이스를 더 단순하게 만드는 보다 일반적인 접근 방식입니다.

당연히 전체 ClickHouse 생태계에 기능을 제공하고 Yandex.Cloud 내부에 필요한 작업을 수행하기 위해 우리는 전체 ClickHouse 커뮤니티가 이로부터 혜택을 받을 수 있는지 확인하기로 결정했습니다. 우리는 MDS를 통한 ClickHouse가 아닌 S3를 통해 ClickHouse를 구현했습니다. 그리고 이것은 많은 작업입니다.

링크 :

클릭하우스에서 가상 파일 시스템을 구현하기 위한 풀 리퀘스트 목록입니다. 이것은 많은 수의 끌어오기 요청입니다.

링크 :

https://github.com/ClickHouse/ClickHouse/pull/9760 "DiskS3 하드링크 최적 구현"
https://github.com/ClickHouse/ClickHouse/pull/11522 "S3 HTTP 클라이언트 - 응답 스트림을 메모리에 복사하지 마세요"
https://github.com/ClickHouse/ClickHouse/pull/11561 “S3 HTTP에서 전체 응답 스트림을 메모리에 복사하지 마세요.
고객"
https://github.com/ClickHouse/ClickHouse/pull/13076 “S3 디스크에 대한 마크 및 인덱스 파일을 캐시하는 기능”
https://github.com/ClickHouse/ClickHouse/pull/13459 "DiskLocal에서 DiskS3으로 부품을 병렬로 이동"

그러나 일은 여기서 끝나지 않았습니다. 기능이 만들어진 후 이 기능을 최적화하려면 몇 가지 추가 작업이 필요했습니다.

링크 :

https://github.com/ClickHouse/ClickHouse/pull/12638 "SelectedRows 및 SelectedBytes 이벤트 추가"
https://github.com/ClickHouse/ClickHouse/pull/12464 "S3 요청의 프로파일링 이벤트를 system.events에 추가"
https://github.com/ClickHouse/ClickHouse/pull/13028 "QueryTimeMicroseconds, SelectQueryTimeMicroseconds 및 InsertQueryTimeMicroseconds 추가"

그리고 이를 진단하고, 모니터링을 설정하고, 관리할 수 있게 만드는 것이 필요했습니다.

그리고 이 모든 작업은 전체 커뮤니티, 전체 ClickHouse 생태계가 이 작업의 결과를 받을 수 있도록 수행되었습니다.

개인적으로 더 가까운 트랜잭션 데이터베이스, OLTP 데이터베이스로 넘어가 보겠습니다.

오픈소스 DBMS 개발 부서입니다. 이 사람들은 트랜잭션 개방형 데이터베이스를 개선하기 위해 거리 마술을 하고 있습니다.

우리가 수행하는 방법과 작업에 대해 이야기할 수 있는 예를 사용하는 프로젝트 중 하나는 Postgres의 연결 풀러입니다.

Postgres는 프로세스 데이터베이스입니다. 이는 데이터베이스에 트랜잭션을 처리하는 네트워크 연결이 가능한 한 적어야 함을 의미합니다.

반면, 클라우드 환경에서는 한 클러스터에 수천 개의 연결이 동시에 들어오는 경우가 일반적인 상황입니다. 그리고 연결 풀러의 임무는 수천 개의 연결을 소수의 서버 연결로 묶는 것입니다.

연결 풀러는 바이트가 데이터베이스에 효율적으로 도달할 수 있도록 바이트를 재배열하는 전화 교환원이라고 말할 수 있습니다.

불행하게도 연결 풀러에 대한 적절한 러시아어 단어는 없습니다. 때로는 멀티플렉서 연결이라고도 합니다. 연결 풀러를 무엇이라고 부를지 알고 계시다면 꼭 말씀해 주십시오. 제가 올바른 러시아어 기술 언어를 기꺼이 구사해 드리겠습니다.

https://pgconf.ru/2017/92899

관리형 Postgres 클러스터에 적합한 연결 풀러를 조사했습니다. 그리고 PgBouncer는 우리에게 최고의 선택이었습니다. 그러나 PgBouncer에서는 여러 가지 문제에 직면했습니다. 수년 전 Volodya Borodin은 우리가 PgBouncer를 사용하고 있으며 모든 것을 좋아하지만 뉘앙스가 있고 작업할 것이 있다는 보고서를 제공했습니다.

https://pgconf.ru/media/2017/04/03/20170316H1_V.Borodin.pdf

그리고 우리는 일했습니다. 우리는 발생한 문제를 해결하고 Bouncer를 패치하고 풀 요청 업스트림을 푸시하려고 시도했습니다. 그러나 기본적인 단일 스레딩은 작업하기가 어려웠습니다.

우리는 패치된 바운서로부터 캐스케이드를 수집해야 했습니다. 단일 스레드 바운서가 많은 경우 최상위 레이어의 연결은 바운서의 내부 레이어로 전송됩니다. 이는 구축 및 확장이 어려운 제대로 관리되지 않는 시스템입니다.

우리는 Odyssey라는 자체 연결 풀러를 만들었다는 결론에 도달했습니다. 우리는 처음부터 그것을 썼습니다.

https://www.pgcon.org/2019/schedule/events/1312.en.html

2019년 PgCon 컨퍼런스에서 저는 이 풀러를 개발자 커뮤니티에 선보였습니다. 이제 GitHub에는 2개 미만의 별이 있습니다. 즉, 프로젝트가 살아 있고 프로젝트가 인기가 있다는 뜻입니다.

그리고 Yandex.Cloud에서 Postgres 클러스터를 생성하면 클러스터를 앞뒤로 확장할 때 재구성되는 Odyssey가 내장된 클러스터가 됩니다.

이 프로젝트에서 우리는 무엇을 배웠나요? 경쟁 프로젝트를 시작하는 것은 항상 공격적인 단계이며, 충분히 빨리 해결되지 않고 우리에게 적합한 시간 간격 내에 해결되지 않는 문제가 있다고 말할 때 이는 극단적인 조치입니다. 그러나 이것은 효과적인 조치입니다.

PgBouncer가 더 빠르게 개발되기 시작했습니다.

그리고 이제 다른 프로젝트가 나타났습니다. 예를 들어 Red Hat 개발자가 개발한 pgagroal이 있습니다. 그들은 유사한 목표를 추구하고 유사한 아이디어를 구현하지만 물론 Pgagroal 개발자에게 더 가까운 고유한 세부 사항을 가지고 있습니다.

Postgres 커뮤니티와 협력하는 또 다른 사례는 특정 시점으로 복원하는 것입니다. 이는 장애 후 복구이고 백업에서 복구하는 것입니다.

많은 백업이 있으며 모두 다릅니다. 거의 모든 Postgres 공급업체에는 자체 백업 솔루션이 있습니다.

모든 백업 시스템을 사용하여 기능 매트릭스를 만들고 농담으로 이 매트릭스의 행렬식을 계산하면 XNUMX이 됩니다. 이것은 무엇을 의미 하는가? 특정 백업 파일을 가져오면 다른 모든 파일의 조각들로 구성할 수 없습니다. 그것은 구현이 독특하고, 목적이 독특하며, 그 안에 포함된 아이디어가 독특합니다. 그리고 그것들은 모두 구체적입니다.

https://www.citusdata.com/blog/2017/08/18/introducing-wal-g-faster-restores-for-postgres/

이 문제를 해결하는 동안 CitusData는 WAL-G 프로젝트를 시작했습니다. 클라우드 환경을 염두에 두고 만들어진 백업 시스템입니다. 이제 CitusData는 이미 Microsoft의 일부입니다. 그 순간 우리는 WAL-G의 초기 릴리스에 제시된 아이디어가 정말 마음에 들었습니다. 그리고 우리는 이 프로젝트에 기여하기 시작했습니다.

https://github.com/wal-g/wal-g/graphs/contributors

현재 이 프로젝트에는 수십 명의 개발자가 있지만 WAL-G의 상위 10명의 기여자에는 6명의 Yandexoids가 포함됩니다. 우리는 거기에 많은 아이디어를 가져왔습니다. 그리고 물론 우리는 직접 구현하고, 테스트하고, 프로덕션에 출시하고, 직접 사용하고, 대규모 WAL-G 커뮤니티와 상호 작용하면서 다음 단계로 이동할 위치를 스스로 파악합니다.

그리고 우리의 관점에서 보면 이제 우리의 노력을 고려한 이 백업 시스템은 클라우드 환경에 최적이 되었습니다. 이는 클라우드에서 Postgres를 백업하는 데 드는 최고의 비용입니다.

무슨 뜻이에요? 우리는 백업이 안전하고, 운영 비용이 저렴하며, 복원 속도가 최대한 빨라야 한다는 상당히 큰 아이디어를 추진하고 있었습니다.

왜 운영 비용이 저렴해야 합니까? 손상된 것이 없으면 백업이 있다는 것을 알 수 없습니다. 모든 것이 잘 작동하고, CPU 낭비를 최소화하고, 디스크 리소스를 최대한 적게 사용하며, 귀중한 서비스의 페이로드를 방해하지 않도록 가능한 한 적은 바이트를 네트워크에 전송합니다.

예를 들어 관리자가 데이터를 삭제하고 문제가 발생하여 긴급하게 과거로 돌아가야 하는 경우와 같이 모든 것이 중단되면 데이터를 신속하고 온전하게 되찾기를 원하기 때문에 모든 돈으로 복구할 수 있습니다.

그리고 우리는 이 간단한 아이디어를 홍보했습니다. 그리고 우리는 그것을 구현한 것 같습니다.

하지만 그게 전부는 아닙니다. 우리는 작은 것을 하나 더 원했습니다. 우리는 다양한 데이터베이스를 원했습니다. 모든 고객이 Postgres를 사용하는 것은 아닙니다. 어떤 사람들은 MySQL, MongoDB를 사용합니다. 커뮤니티에서는 다른 개발자들이 FoundationDB를 지원했습니다. 그리고 이 목록은 지속적으로 확장되고 있습니다.

커뮤니티는 데이터베이스가 클라우드의 관리 환경에서 실행된다는 아이디어를 좋아합니다. 또한 개발자는 당사의 백업 시스템을 통해 Postgres와 함께 균일하게 백업할 수 있는 데이터베이스를 유지 관리합니다.

우리는 이 이야기에서 무엇을 배웠습니까? 개발 부서로서 우리 제품은 코드 라인도, 명령문도, 파일도 아닙니다. 우리 제품은 풀 리퀘스트가 아닙니다. 이것이 우리가 커뮤니티에 전달하는 아이디어입니다. 이것이 기술적 전문성이자 클라우드 환경을 향한 기술의 움직임입니다.

Postgres와 같은 데이터베이스가 있습니다. 저는 Postgres 코어를 가장 좋아합니다. 저는 커뮤니티와 함께 Postgres 코어를 개발하는 데 많은 시간을 보냅니다.

그러나 여기서는 Yandex.Cloud에 관리형 데이터베이스가 내부에 설치되어 있다고 말해야 합니다. 그리고 그것은 Yandex.Mail에서 오래 전에 시작되었습니다. 이제 Managed Postgres로 이어진 전문성은 메일이 Postgres로 이동하려고 할 때 축적되었습니다.

메일의 요구 사항은 클라우드와 매우 유사합니다. 데이터의 어느 지점에서든 예상치 못한 기하급수적 증가로 확장할 수 있어야 합니다. 그리고 메일에는 끊임없이 많은 요청을 보내는 수많은 사용자의 수억 개의 사서함이 이미 로드되어 있었습니다.

그리고 이것은 Postgres를 개발하는 팀에게 상당히 심각한 도전이었습니다. 당시에는 우리가 직면한 모든 문제가 커뮤니티에 보고되었습니다. 그리고 이러한 문제는 일부 다른 데이터베이스에 대한 유료 지원 수준에서도 심지어 더 나은 수준에서도 일부 장소에서 커뮤니티에 의해 수정되고 수정되었습니다. 즉, PgSQL 해커에게 편지를 보내고 40분 이내에 응답을 받을 수 있다. 일부 데이터베이스의 유료 지원에서는 버그보다 우선순위가 더 높다고 생각할 수 있습니다.

이제 Postgres의 내부 설치에는 페타바이트 규모의 데이터가 포함됩니다. 이는 초당 수백만 건의 요청입니다. 이들은 수천 개의 클러스터입니다. 매우 대규모입니다.

그러나 뉘앙스가 있습니다. 고급 네트워크 드라이브가 아닌 상당히 단순한 하드웨어에 존재합니다. 그리고 흥미로운 새로운 것들을 위한 테스트 환경이 있습니다.

그리고 테스트 환경의 특정 순간에 데이터베이스 인덱스의 내부 불변성이 위반되었음을 나타내는 메시지를 받았습니다.

불변성은 우리가 항상 유지하기를 기대하는 일종의 관계입니다.

우리에게는 매우 중요한 상황입니다. 일부 데이터가 손실되었을 수 있음을 나타냅니다. 그리고 데이터 손실은 그야말로 재앙입니다.

관리형 데이터베이스에서 우리가 따르는 일반적인 생각은 노력을 기울여도 데이터를 잃기는 어렵다는 것입니다. 의도적으로 제거하더라도 오랜 기간 동안 부재를 무시해야 합니다. 데이터 보안은 우리가 매우 열심히 따르는 종교입니다.

그리고 여기서 우리가 대비할 수 없는 상황이 있을 수 있음을 암시하는 상황이 발생합니다. 그리고 우리는 이런 상황에 대비하기 시작했습니다.

https://commitfest.postgresql.org/23/2171/

우리가 가장 먼저 한 일은 수천 개의 클러스터에서 로그를 묻는 것이었습니다. 데이터 페이지 업데이트가 손실되는 문제가 있는 펌웨어가 있는 디스크에 어떤 클러스터가 있는지 발견했습니다. 모든 Postgres 데이터 코드를 마크업했습니다. 그리고 데이터 손상을 감지하도록 설계된 코드로 내부 불변성 위반을 나타내는 메시지를 표시했습니다.

이 패치는 커뮤니티에서 별다른 논의 없이 사실상 승인되었습니다. 왜냐하면 각각의 특정 사례에서 뭔가 나쁜 일이 발생했고 로그에 보고되어야 한다는 것이 명백했기 때문입니다.

그 후, 로그를 스캔하는 모니터링이 가능해졌습니다. 그리고 의심스러운 메시지가 있을 경우 당직담당자를 깨우고, 당직담당자는 이를 수리한다.

하지만! 로그 스캔은 하나의 클러스터에서는 저렴한 작업이고, 수천 개의 클러스터에서는 엄청난 비용이 듭니다.

우리는 다음과 같은 확장 기능을 작성했습니다. 로그 오류. 과거 오류에 대한 통계를 저렴하고 빠르게 선택할 수 있는 데이터베이스 보기를 생성합니다. 그리고 근무자를 깨워야 하는 경우에는 기가바이트 파일을 스캔하지 않고 해시 테이블에서 몇 바이트를 추출하여 이에 대해 알아낼 수 있습니다.

이 확장은 예를 들어 다음 저장소에 채택되었습니다. CentOS에. 사용하고 싶으시면 직접 설치하셔도 됩니다. 물론 오픈소스입니다.

https://www.postgresql.org/message-id/flat/[이메일 보호]

하지만 그게 전부는 아닙니다. 우리는 인덱스에서 불변 위반을 찾기 위해 커뮤니티에서 구축한 확장 프로그램인 Amcheck를 사용하기 시작했습니다.

그리고 대규모로 운영하다 보면 버그가 있다는 사실도 알게 되었습니다. 우리는 그것들을 고치기 시작했습니다. 우리의 수정 사항이 승인되었습니다.

https://www.postgresql.org/message-id/flat/[이메일 보호]

우리는 이 확장 프로그램이 GiST 및 GIT 인덱스를 분석할 수 없다는 것을 발견했습니다. 우리는 그들을 지원하게 만들었습니다. 하지만 이 지원은 비교적 새로운 기능이고 세부 사항이 많기 때문에 여전히 커뮤니티에서 논의되고 있습니다.

https://commitfest.postgresql.org/29/2667/

또한 복제 리더, 마스터의 위반에 대한 인덱스를 확인할 때 모든 것이 잘 작동하지만 복제본, 팔로어에서는 손상 검색이 그다지 효과적이지 않다는 것도 발견했습니다. 모든 불변성이 검사되는 것은 아닙니다. 그리고 하나의 불변성은 우리를 매우 괴롭혔습니다. 그리고 우리는 복제본에 대한 이러한 확인을 가능하게 하기 위해 커뮤니티와 소통하는 데 XNUMX년 반을 보냈습니다.

우리는 모든 can... 프로토콜을 따라야 하는 코드를 작성했습니다. 우리는 Crunchy Data의 Peter Gaghan과 이 패치에 대해 오랫동안 논의했습니다. 그는 이 패치를 적용하기 위해 Postgres의 기존 B-트리를 약간 수정해야 했습니다. 그는 받아 들여졌습니다. 이제 복제본의 인덱스를 확인하는 것 또한 우리가 직면한 위반을 감지할 만큼 충분히 효과적이게 되었습니다. 즉, 디스크 펌웨어 오류, Postgres 버그, Linux 커널 버그, 하드웨어 문제로 인해 발생할 수 있는 위반 사항입니다. 우리가 준비하고 있던 문제의 원인에 대한 상당히 광범위한 목록입니다.

https://www.postgresql.org/message-id/flat/38AF687F-8F6B-48B4-AB9E-A60CFD6CC261%40enterprisedb.com#0e86a12c01d967bac04a9bf83cd337cb

그러나 인덱스 외에도 힙과 같은 부분, 즉 데이터가 저장되는 장소가 있습니다. 그리고 확인할 수 있는 불변값이 많지 않습니다.

Heapcheck라는 확장 프로그램이 있습니다. 우리는 그것을 개발하기 시작했습니다. 동시에 EnterpriseDB 회사도 우리와 함께 Heapcheck라는 모듈을 작성하기 시작했습니다. 우리는 그것을 PgHeapcheck라고 불렀고 그들은 단지 Heapcheck라고 불렀습니다. 기능은 비슷하고 시그니처는 약간 다르지만 아이디어는 동일합니다. 그들은 어떤 곳에서는 그것들을 조금 더 잘 구현했습니다. 그리고 그들은 전에 그것을 오픈 소스에 게시했습니다.

그리고 이제 우리는 그들의 확장을 개발하고 있습니다. 왜냐하면 그것은 더 이상 그들의 확장이 아니라 커뮤니티의 확장이기 때문입니다. 그리고 이는 앞으로 모든 사람들에게 미래의 문제를 미리 알 수 있도록 제공될 커널의 일부입니다.

https://www.postgresql.org/message-id/flat/fe9b3722df94f7bdb08768f50ee8fe59%40postgrespro.ru

어떤 곳에서는 모니터링 시스템에 오탐지가 있다는 결론에 도달하기도 했습니다. 예를 들어 1C 시스템입니다. 데이터베이스를 사용할 때 Postgres는 때때로 읽을 수 있는 데이터를 기록하지만 pg_dump는 읽을 수 없습니다.

이 상황은 우리의 문제 감지 시스템이 손상된 것처럼 보였습니다. 담당관이 깨어났습니다. 담당관은 무슨 일이 일어나고 있는지 살펴 보았습니다. 얼마 후 고객이 와서 문제가 있다고 말했습니다. 승무원은 문제가 무엇인지 설명했습니다. 그러나 문제는 Postgres 코어에 있습니다.

이 기능에 대한 토론을 찾았습니다. 그리고 그는 우리가 이 기능을 접했고 그것이 불쾌했다고 썼습니다. 한 사람이 그것이 무엇인지 알아내기 위해 밤에 일어났습니다.

https://www.postgresql.org/message-id/flat/fe9b3722df94f7bdb08768f50ee8fe59%40postgrespro.ru

커뮤니티에서는 “아, 정말 고쳐야 한다”는 반응을 보였습니다.

나는 간단한 비유를 가지고 있습니다. 모래알이 들어있는 신발을 신고 걷고 있다면 원칙적으로 계속 나아갈 수 있습니다. 문제 없습니다. 수천 명에게 부츠를 판다면 모래가 전혀 없는 부츠를 만들어보자. 그리고 신발 사용자 중 한 명이 마라톤을 뛸 예정이라면 아주 좋은 신발을 만들고 이를 모든 사용자에게 확장하고 싶을 것입니다. 그리고 이러한 예상치 못한 사용자는 항상 클라우드 환경에 있습니다. 원래의 방식으로 클러스터를 이용하는 사용자가 항상 있습니다. 항상 이에 대비해야 합니다.

우리는 여기서 무엇을 배웠나요? 우리는 간단한 것을 배웠습니다. 가장 중요한 것은 문제가 있다는 것을 커뮤니티에 설명하는 것입니다. 커뮤니티가 문제를 인식하면 문제를 해결하기 위한 자연스러운 경쟁이 발생합니다. 모두가 중요한 문제를 해결하고 싶어하기 때문입니다. 모든 공급업체, 모든 해커는 자신이 이 갈퀴를 밟을 수 있다는 것을 이해하고 있으므로 이를 제거하고 싶어합니다.

당신이 문제를 해결하고 있는데 당신 외에는 아무도 괴롭히지 않지만 체계적으로 문제를 해결하고 그것이 궁극적으로 문제로 간주된다면 당신의 풀 요청은 확실히 받아들여질 것입니다. 패치가 승인되고 개선 사항이나 개선 요청도 커뮤니티에서 검토됩니다. 결국 우리는 서로를 위해 더 나은 데이터베이스를 만듭니다.

흥미로운 데이터베이스는 Greenplum입니다. 이는 제가 매우 잘 알고 있는 Postgres 코드베이스를 기반으로 한 고도의 병렬 데이터베이스입니다.

https://greenplum.org/greenplum-database-tables-compression/

그리고 Greenplum에는 최적화된 테이블을 추가하는 흥미로운 기능이 있습니다. 빠르게 추가할 수 있는 테이블입니다. 열 형식이거나 행 형식일 수 있습니다.

하지만 클러스터링이 없었습니다. 즉, 인덱스 중 하나에 있는 순서에 따라 테이블에 있는 데이터를 정렬할 수 있는 기능이 없었습니다.

택시에서 온 사람들이 나에게 와서 말했습니다. “Andrey, 당신은 Postgres를 알고 있습니다. 그리고 여기는 거의 동일합니다. 20분으로 전환하세요. 당신은 그것을 가지고 그것을 수행합니다.” 나는 Postgres를 알고 있으며 20분 동안 전환해야 한다고 생각했습니다.

https://github.com/greenplum-db/gpdb/commit/179feb77a034c2547021d675082aae0911be40f7

하지만 아니, 20분이 아니고 몇 달에 걸쳐 썼습니다. PgConf.Russia 컨퍼런스에서 저는 Pivotal의 Heikki Linakangas에게 접근하여 이렇게 물었습니다. “이것에 문제가 있습니까? 추가 최적화 테이블 클러스터링이 없는 이유는 무엇입니까?” 그는 이렇게 말합니다. “데이터를 가져가세요. 정렬하고 재배열하세요. 그냥 직업일 뿐이야." 나: “아, 네, 그냥 가져가서 하시면 됩니다.” 그는 이렇게 말합니다. “그렇습니다. 이 일을 하려면 손이 자유로워야 합니다.” 이건 꼭 해야겠다는 생각이 들었습니다.

그리고 몇 달 후 저는 이 기능을 구현하는 풀 요청을 제출했습니다. 이 풀 요청은 커뮤니티와 함께 Pivotal에서 검토되었습니다. 물론 버그도 있었습니다.

https://github.com/greenplum-db/gpdb/issues/10150

그런데 가장 흥미로운 점은 이 풀 리퀘스트를 병합했을 때 Greenplum 자체에서 버그가 발견되었다는 것입니다. 우리는 힙 테이블이 클러스터링될 때 트랜잭션이 중단되는 경우가 있다는 것을 발견했습니다. 그리고 이것은 바로잡아야 할 문제입니다. 그리고 그녀는 내가 방금 만진 곳에 있습니다. 그리고 나의 자연스러운 반응은 – 알았어, 나도 해보자.

https://github.com/greenplum-db/gpdb/pull/10290

이 버그를 수정했습니다. 해결사에게 풀 요청을 보냈습니다. 그는 살해 당했다.

https://github.com/greenplum-db/gpdb-postgres-merge/pull/53

그 후 이 기능은 PostgreSQL 12용 Greenplum 버전에서 얻어야 한다는 것이 밝혀졌습니다. 즉, 20분간의 모험은 새로운 흥미로운 모험으로 계속됩니다. 커뮤니티가 새롭고 가장 중요한 기능을 삭제하고 있는 현재 개발을 접하는 것은 흥미로웠습니다. 그것은 얼었다.

https://github.com/greenplum-db/gpdb/pull/10565

하지만 거기서 끝나지 않았습니다. 결국 우리는 이 모든 것에 대한 문서를 작성해야 한다는 것이 밝혀졌습니다.

나는 문서를 작성하기 시작했습니다. 운 좋게도 Pivotal의 다큐멘터리 작가들이 함께 왔습니다. 영어는 그들의 모국어입니다. 그들은 문서 작성에 도움을 주었습니다. 사실, 그들은 내가 제안한 것을 실제 영어로 다시 썼습니다.

그리고 여기서 모험은 끝난 것 같습니다. 그리고 그때 무슨 일이 일어났는지 아시나요? 택시에서 온 사람들이 나에게 와서 말했습니다. "아직 10분 동안 두 가지 모험이 있습니다." 그리고 나는 그들에게 무엇을 말해야 합니까? 이제 규모에 대한 보고서를 제출하고 나서 당신의 모험을 지켜보겠다고 말했습니다. 왜냐하면 이것은 흥미로운 일이기 때문입니다.

이 사건에서 우리는 무엇을 배웠습니까? 오픈 소스를 사용하여 작업하는 것은 항상 특정 사람과 작업하는 것이므로 항상 커뮤니티와 작업하는 것입니다. 왜냐하면 매 단계마다 개발자, 테스터, 해커, 다큐멘터리 작가, 설계자와 함께 일했기 때문입니다. 저는 Greenplum과 함께 일한 것이 아니라 Greenplum 주변 사람들과 함께 일했습니다.

하지만! 또 다른 중요한 점이 있습니다. 그것은 단지 일입니다. 즉, 와서 커피를 마시고 코드를 작성하는 것입니다. 모든 종류의 단순 불변성이 작동합니다. 평소대로 하세요 - 괜찮을 거예요! 그리고 그것은 꽤 흥미로운 직업입니다. Yandex.Cloud 클라이언트, Yandex 내부 및 외부 클러스터 사용자로부터 이 작업에 대한 요청이 있습니다. 그리고 우리가 참여하는 프로젝트의 수도 늘어나고 참여의 깊이도 커질 것이라고 생각합니다.

그게 다야. 질문으로 넘어가겠습니다.

질문 세션

안녕하세요! 또 다른 질문과 답변 세션이 있습니다. 그리고 스튜디오에서 Andrei Borodin. 방금 Yandex.Cloud와 Yandex가 오픈 소스에 기여한 것에 대해 말씀드린 사람입니다. 이제 우리 보고서는 전적으로 클라우드에 관한 것이 아니지만 동시에 그러한 기술을 기반으로 합니다. Yandex 내부에서 수행한 작업이 없었다면 Yandex.Cloud에 서비스가 없었을 것이므로 개인적으로 감사드립니다. 그리고 방송에서 나온 첫 번째 질문은 “당신이 언급한 각 프로젝트에는 어떤 내용이 적혀있나요?”였습니다.

WAL-G의 백업 시스템은 Go로 작성되었습니다. 이것은 우리가 작업한 최신 프로젝트 중 하나입니다. 그는 말 그대로 겨우 3 살입니다. 그리고 데이터베이스는 종종 신뢰성에 관한 것입니다. 이는 데이터베이스가 꽤 오래되었고 일반적으로 C로 작성된다는 것을 의미합니다. Postgres 프로젝트는 약 30년 전에 시작되었습니다. 그렇다면 C89가 올바른 선택이었습니다. 그리고 그 위에 Postgres가 작성되었습니다. ClickHouse와 같은 최신 데이터베이스는 일반적으로 C++로 작성됩니다. 모든 시스템 개발은 C와 C++를 기반으로 합니다.

Cloud에서 비용을 담당하는 재무 관리자의 질문: "Cloud가 오픈 소스 지원에 돈을 쓰는 이유는 무엇입니까?"

여기에 재무 관리자를 위한 간단한 대답이 있습니다. 우리는 더 나은 서비스를 만들기 위해 이렇게 합니다. 우리는 어떤 방법으로 더 잘할 수 있나요? 우리는 일을 더욱 효율적이고 빠르게 처리하며 일의 확장성을 높일 수 있습니다. 하지만 우리에게 있어 이 이야기는 주로 신뢰성에 관한 것입니다. 예를 들어, 백업 시스템에 적용되는 패치를 100% 검토합니다. 우리는 코드가 무엇인지 알고 있습니다. 그리고 새 버전을 프로덕션에 출시하는 것이 더 편안해졌습니다. 즉, 우선 자신감, 개발 준비 상태 및 신뢰성에 관한 것입니다.

또 다른 질문: "Yandex.Cloud에 거주하는 외부 사용자의 요구 사항은 내부 클라우드에 거주하는 내부 사용자의 요구 사항과 다릅니까?"

물론 로드 프로필은 다릅니다. 하지만 우리 부서의 관점에서 볼 때 특별하고 흥미로운 사례는 모두 비표준 부하에서 생성됩니다. 상상력이 있는 개발자, 예상치 못한 일을 해내는 개발자는 내부적으로나 외부적으로나 발견될 가능성이 높습니다. 이 점에서 우리는 모두 거의 동일합니다. 그리고 아마도 Yandex 데이터베이스 작업에서 유일하게 중요한 기능은 Yandex 내부에 교육이 있다는 것입니다. 어느 시점에서 일부 가용성 영역은 완전히 섀도우 상태가 되며 모든 Yandex 서비스는 그럼에도 불구하고 어떻게든 계속 작동해야 합니다. 이것은 작은 차이입니다. 그러나 이는 데이터베이스와 네트워크 스택의 인터페이스에서 많은 연구 개발을 창출합니다. 그렇지 않으면 외부 및 내부 설치에서 동일한 기능 요청과 안정성 및 성능 개선에 대한 유사한 요청이 생성됩니다.

다음 질문: “당신이 하는 일 중 많은 부분이 다른 클라우드에서 사용되고 있다는 사실에 대해 개인적으로 어떻게 생각하시나요?” 구체적인 이름을 밝히지는 않겠지만 Yandex.Cloud에서 수행된 많은 프로젝트가 다른 사람의 클라우드에서 사용되고 있습니다.

이것은 멋지다. 첫째, 이는 우리가 옳은 일을 했다는 표시입니다. 그리고 그것은 자아를 긁습니다. 그리고 우리는 올바른 결정을 내렸다고 더욱 확신합니다. 반면에 이것은 앞으로 우리에게 새로운 아이디어와 제30자 사용자의 새로운 요청을 가져올 것이라는 희망입니다. GitHub의 대부분의 문제는 개별 시스템 관리자, 개별 DBA, 개별 설계자, 개별 엔지니어에 의해 생성되지만 때로는 체계적인 경험을 가진 사람들이 와서 특정 사례의 XNUMX%에서 이 문제가 있다고 말하고 해결 방법을 생각해 봅시다. 이것이 우리가 가장 기대하는 것입니다. 우리는 다른 클라우드 플랫폼과 경험을 공유하기를 기대합니다.

마라톤 얘기를 많이 하더군요. 나는 당신이 모스크바에서 마라톤을 뛴 것을 알고 있습니다. 결과적으로? PostgreSQL의 사람들을 능가했나요?

아니요, Oleg Bartunov는 매우 빠르게 달립니다. 그는 나보다 한 시간 먼저 일을 마쳤다. 전반적으로 나는 지금까지 도달한 것에 만족합니다. 나에게는 마무리하는 것만으로도 성과였다. 전반적으로 Postgres 커뮤니티에 실행자가 너무 많다는 것은 놀라운 일입니다. 제가 보기에는 에어로빅 스포츠와 시스템 프로그래밍에 대한 욕구 사이에 일종의 관계가 있는 것 같습니다.

클릭하우스에 주자가 없다는 겁니까?

나는 그들이 거기에 있다는 것을 확실히 알고 있습니다. ClickHouse는 데이터베이스이기도 합니다. 그건 그렇고, Oleg는 지금 나에게 편지를 쓰고 있습니다. "보고 후 달리기하러 갈까요?" 이것은 좋은 생각입니다.

Nikita의 방송에서 나온 또 다른 질문: "왜 Greenplum의 버그를 직접 수정하고 후배들에게 주지 않았나요?" 사실, 버그가 무엇인지, 어떤 서비스에 있는지는 명확하지 않지만 아마도 당신이 말한 버그를 의미할 것입니다.

네, 원칙적으로는 누군가에게 주어질 수도 있었습니다. 방금 변경한 코드였습니다. 그리고 곧바로 그 일을 계속하는 것은 당연했다. 원칙적으로는 팀과 전문 지식을 공유하는 아이디어가 좋습니다. 우리 부서의 모든 구성원은 Greenplum 작업을 반드시 공유할 것입니다.

후배 얘기니까 질문 하나 드립니다. 그 사람은 Postgres에서 첫 번째 커밋을 만들기로 결정했습니다. 첫 번째 커밋을 하려면 어떻게 해야 합니까?

이것은 흥미로운 질문입니다. “어디서부터 시작해야 할까요?” 일반적으로 커널에서 무언가를 시작하는 것은 매우 어렵습니다. 예를 들어 Postgres에는 할 일 목록이 있습니다. 그러나 사실 이것은 그들이 시도했지만 성공하지 못한 것에 대한 시트입니다. 이것들은 복잡한 것들입니다. 그리고 일반적으로 커널 개발자의 관심을 덜 끄는 일부 유틸리티, 개선할 수 있는 확장 기능을 생태계에서 찾을 수 있습니다. 따라서 거기에는 더 많은 성장 포인트가 있습니다. Google Summer of Code 프로그램에서 매년 Postgres 커뮤니티는 다룰 수 있는 다양한 주제를 제시합니다. 올해에는 학생이 세 명 있었던 것 같아요. 한 사람은 Yandex에 중요한 주제에 대해 WAL-G에 글을 쓰기도 했습니다. Greenplum에서는 Greenplum 해커가 풀 요청을 매우 잘 처리하고 즉시 검토를 시작하기 때문에 Postgres 커뮤니티보다 모든 것이 더 간단합니다. Postgres에 패치를 보내는 것은 몇 달이 걸리지만 Greenplum은 하루 안에 와서 여러분이 수행한 작업을 확인할 것입니다. 또 다른 점은 Greenplum이 현재의 문제를 해결해야 한다는 것입니다. Greenplum은 널리 사용되지 않으므로 문제를 찾는 것이 매우 어렵습니다. 그리고 무엇보다도 먼저 문제를 해결해야 합니다.

출처 : habr.com

우리가 오픈 소스 데이터베이스에서 무엇을 왜 하는지. 안드레이 보로딘(Yandex.Cloud)