GN⁺: SQL의 문제점과 해결 방안: SQL의 파이프 문법
(research.google)- SQL은 50년 동안 구조적 데이터 처리의 기본 언어로 자리 잡았지만 배우기 어렵고, 사용하기 까다로우며, 확장하기 어려움
- 기존 SQL의 문제점 : 구문 순서의 강제성, 중복된 구문, 서브쿼리 사용 필요성, '안쪽에서 바깥쪽으로'의 데이터 흐름, 확장성의 부족 등
- GoogleSQL에서는 SQL의 문제를 해결하기 위해 SQL을 확장하는 접근 방식을 채택
- 파이프 구조의 데이터 흐름 구문을 SQL에 도입하여 기존 SQL의 문제를 해결하고자 함
- SQL을 기존의 생태계를 유지하면서도 보다 유연하게 학습하고 사용할 수 있으며, 기존 SQL과의 완전한 호환성을 유지함
- 기존 SQL 연산자를 재사용하고 파이프로 임의의 순서로 구성할 수 있게 함
- 각 파이프 연산자는 입력 테이블만 볼 수 있어 범위가 명확함
- 선언적 의미론을 유지함
- 관계 대수와 일대일 대응이 가능해짐
- 테이블 값 함수를 이용한 확장성이 개선됨
- 예를 들어, 다단계 집계를 서브쿼리 없이 연속적으로 표현할 수 있음
- 파이프 구문을 사용한 SQL은 학습과 사용이 더 쉽고, 다양한 연산자들을 임의의 순서로 적용할 수 있어 유연성이 크게 향상됨
- 파이프 연산자는 순차적으로 작동하며, 이를 통해 사용자는 데이터를 보다 쉽게 필터링, 집계, 정렬할 수 있음
- GoogleSQL에서의 사용 경험
- 사용자들의 꾸준한 채택과 긍정적인 피드백을 받음
- 복잡한 쿼리도 선형적으로 표현 가능
- 편집과 디버깅 작업에 용이함
- IDE 도구 지원이 개선됨
- SQL 코드 생성기와 변환기에 유리함
- AI 적용에 잠재적 장점이 있음
- 구현과 향후 계획
- GoogleSQL에서 파이프 문법을 공유 컴포넌트로 구현함
- 기존 쿼리 엔진들은 파이프 문법을 쉽게 활성화할 수 있음
- BigQuery와 Spanner에서 외부적으로 지원하는 것을 검토 중
- 향후 SQL 표준에 포함되는 것을 모색할 만한 가치가 있음
GN⁺의 의견
- 파이프 구문의 장점: SQL의 복잡성을 해결할 수 있는 강력한 도구로 작용하며, 특히 데이터 흐름을 직관적으로 표현할 수 있어 SQL 사용성을 크게 개선할 수 있음.
- 기존 SQL과의 호환성: 기존 SQL을 대체하는 것이 아닌, SQL을 개선하는 방향으로 접근하여 학습 곡선을 줄이고, 기존 코드와의 호환성을 유지할 수 있음.
- 도입 시 고려 사항: 파이프 구문을 채택할 때는 성능에 미치는 영향과 도구 지원 수준을 고려해야 하며, 특히 대규모 쿼리에서 파이프 구문의 장점을 최대한 활용할 수 있음.
- 유사 프로젝트와의 비교: Pandas와 같은 DataFrame API에서도 파이프 구조가 사용되지만, SQL과의 차별점은 SQL의 선언적 의미론과의 결합임. SQL 시스템의 확장성과 성능을 유지하면서 이러한 기능을 사용할 수 있음.
파이프에 캐럿이라니 뭔가 오른손이 아플것같은 조합🤣
지금 SQL에 뭔가 개선이 필요하긴 하죠
한 3-40년간 개선안을 못찾은게 문제이긴 한데요..
페이퍼의 아래 예제만 봐도 확실히 google sql이 읽기 편하긴 하네요.
standard sql
SELECT c_count, COUNT(*) AS custdist
FROM
( SELECT c_custkey, COUNT(o_orderkey) c_count
FROM customer
LEFT OUTER JOIN orders ON c_custkey = o_custkey
AND o_comment NOT LIKE '%unusual%packages%'
GROUP BY c_custkey
) AS c_orders
GROUP BY c_count
ORDER BY custdist DESC, c_count DESC;
google sql
FROM customer
|> LEFT OUTER JOIN orders ON c_custkey = o_custkey
AND o_comment NOT LIKE '%unusual%packages%'
|> AGGREGATE COUNT(o_orderkey) c_count
GROUP BY c_custkey
|> AGGREGATE COUNT(*) AS custdist
GROUP BY c_count
|> ORDER BY custdist DESC, c_count DESC;
C#의 LINQ가 생각나네요. SQL 쓸 때마다 항상 SELECT 순서가 FROM, WHERE 뒤로 바뀌었으면 좋겠다는 생각을 했었는데....
처음엔 익숙하지 않아서 어색해도 천천히 읽어보면 흐름이 훨씬 자연스럽게 느껴집니다.
Hacker News 의견
- SQL 파이프 구문이 더 읽기 쉬워졌음
- Google에서 SQL 쿼리를 작성할 때 파이프 구문이 유용했음
- SQL 파이프 구문이 일반화되기를 희망함
- Google AI Studio에서 PDF를 HTML로 변환해본 결과가 좋았음
- 20년 넘게 SQL을 사용해왔지만 여전히 특정 쿼리를 표현하는 데 어려움이 있음
- Google의 오픈 소스 ZetaSQL 프로젝트가 파이프 구문 문서를 추가했음
- SQL의 구문 불만은 우선순위가 낮음
- 대수적 데이터 타입, 진정한 불리언 논리, 함수형 구성 등의 기능이 필요함
- SQL 작성의 어려움을 줄이기 위한 많은 시도가 있었지만 성공하지 못했음
- 저자들의 접근 방식은 점진적이고 기존 SQL 사용자에게 적합함
- 파이프라인 구문은 현재 상태보다 나음
- 쿼리 실행을 작업의 방향 그래프로 모델링하는 구문이 더 좋을 것임
- 조인은 두 개 이상의 데이터 스트림을 소비하고 하나의 데이터 스트림을 생성하는 "교차 참조" 작업으로 모델링할 수 있음
- CTE는 여러 데이터 스트림을 생성하는 것으로 모델링할 수 있음
- 재귀 CTE는 실행 그래프의 사이클로 모델링할 수 있음
- 쿼리 실행을 작업의 방향 그래프로 모델링하는 구문이 더 좋을 것임
- Elixir와 유사함
- 기존 SQL 구문이 지원된다면 괜찮지만, 여러 JOIN, 서브쿼리 및 집계가 포함된 쿼리는 가독성이 떨어질 수 있음
- PRQL과 Splunk의 SPL을 떠올리게 함