저자: Ni Demai는 NineData 데이터베이스 제품 전문가로, Alibaba Cloud 데이터베이스 국제 제품 총책임자, Huawei GaussDB 창립 팀의 핵심 설계자, IBM Db2 수석 R&D 엔지니어였습니다. Demai는 클라우드 네이티브 데이터베이스 아키텍처 설계, 분석 MPP, 엔터프라이즈 데이터베이스 개발 및 생태학에 중점을 두고 있으며 오픈 소스 커뮤니티 구축 및 개발에 적극적으로 참여하고 있습니다.
OpenAI의 획기적인 발전은 반년 넘게 전체 시장을 충격에 빠뜨렸고, 초기 충격 이후 전체 공연은 무릎 반사 반응을 보이며 모두가 동참하고 있습니다. 일부는 대형 모델을 훈련하고 일부는 빠르게 재고를 확보하며 대부분은 BP를 직접 변경합니다.
수년간 데이터베이스에 의존해 왔지만 생각의 소용돌이에 갇혀있습니다. AI 기반 옵티마이저[1]는 수년 전 프로젝트 애플리케이션의 PPT에 작성됐는데, (3년간 자금을 조달할 수 있도록) 세심하게 고민한 3단계 과정이었다. 이후 DB용 AI, AI용 DB가 차례로 등장했는데, 어느 회사의 기획 전략에 들어갔는지는 기억나지 않는다. 아마 둘 다 갖고 있었을 것이다. NLP에서 SQL까지(지금은 너무 많습니다[2]), ML 기반 뷔페 풀 튜닝, 물론 끊임없이 변화하는 옵티마이저와 같은 DB용 AI: DB for AL: ML 계산을 데이터베이스에서 또는 직접 제공하는 것입니다. 협소한 관계형 데이터베이스에서 벗어나 그래프 데이터베이스를 계속해서 활용하고 있는 임베디드 DB(즉, 벡터 데이터베이스)[3]의 인기를 따라잡아야 한다[4].
그는 스포트라이트를 받는 수천 명 중 한 명이 되기를 갈망하지만, 그의 생각은 여전히 자신의 고치 안에 갇혀 있습니다. 위의 사항들은 지난 6, 7년 동안 수없이 논의되어 왔고, 모두 장점이 있지만, 실행해 보면 여전히 신뢰성이 떨어지는 느낌이 듭니다. 예를 들어, NLP2SQL(링크: https://github.com/nidmgh/techTrend/blob/main/NLP2SQL.py.), 저자가 내 인생에서 2시간 동안 쓴 것은 이번이 처음(어쩌면 두 번째?)입니다. .) Python 코드를 사용하기 위해 브라우저에서 대화형 대화 상자를 여는 방법을 배우는 데 30분을 보냈습니다. 일반 프로그래머가 주류에서도 2시간의 상업적 가치를 깨닫는 것은 어렵다.
몇 달 동안 고민한 후에도 여전히 답을 찾지 못해서 탐험을 멈추지 않습니다. 세 사람이 함께 있으면 나라는 선생님이 꼭 계실 텐데요, 흔히 '숙제 복사해 주세요'라고 합니다. 오늘은 구글의 AI 협업 도구인 DuetAI[5]를 이용해 제 생각을 이야기해보겠습니다.
1. NLP2SQL 이후에는 어떻게 되나요?
자연어부터 SQL까지 고객이 해결하고자 하는 문제는 분명합니다. 고객은 더 이상 SQL 작성 방법을 배울 필요가 없습니다. 그리고 나서? SQL을 꼭 알아야 하는 것 아닌가요? 구글은 이 문제에 대해 이야기할 때 화장품 설계사 로레알(L'Oréal)의 한 구절을 인용했습니다. 저자는 싱가포르에 있는 세포라 아시아 본사를 직접 방문하기도 했다. 다른 사람의 입장에서 생각해 보면 립스틱의 색깔을 알려줄 수 있는 독자가 몇 명 있습니다. 명확하게 설명할 수 없기 때문에 영업사원이 YSL 소형 금괴 1966[6]을 추천한다면 제 생각에는 양자역학보다 더 어렵습니다.
마찬가지로 성능 튜닝 문제는 말할 것도 없고 자연어를 통해 SQL이 생성됩니다. 최종 사용자가 쿼리의 정확성을 판단할 수 있습니까? 결과를 어떻게 해석할 수 있습니까? SQL에 대한 자연어는 이 문제를 실제로 해결하는 것이 아니라, SQL 쿼리의 결과를 구문 분석하고 사용자가 이해할 수 있는 보고서를 생성하는 것이 필요합니다. AIGC는 자체 폐쇄 루프를 완료합니다. Google Cloud의 Duet AI - 데이터 분석 및 시각화(링크: https://www.youtube.com/watch?v=gtehwj1G4tU)는 Google Next 23 기조 연설의 예입니다. NLP+BigQuery+Looker, 자연어가 입력이고 PPT가 출력입니다.
PPT를 통해 리더에게 보고하는 실무적인 작업을 완료하면서 핵심적인 기술적인 문제도 해결되었다는 점을 참고하세요. 즉, 고객이 도메인 지식을 사용하여 출력 결과를 진정으로 이해할 수 있도록 하는 것입니다. 차트 보고서의 정확성과 부정확성은 고객의 전문 지식, 전문적 경험, 일상적 감각의 상호작용을 통해 판단됩니다. 왜냐하면 콜드 데이터베이스 쿼리 결과가 아닌 이러한 고객만이 비즈니스의 실제 상황을 이해하기 때문입니다. 하나님의 것은 하나님의 것이요, 가이사의 것은 가이사의 것, SQL은 데이터베이스 코더의 것, 립스틱 번호는 메이크업 전문가의 것, 모두가 자기의 직무를 수행하고 전문 지식을 공헌하는 것입니다.
- 기술 경로: NPL2SQL + 데이터 웨어하우스 + Marp [7]
2. 데이터베이스 마이그레이션: 500마일, 90년
데이터베이스 마이그레이션은 수십 년 된 주제입니다. 그중에서도 데이터베이스 호환성, 데이터 마이그레이션, 스키마 변환, 애플리케이션 재작성(장기 COBOL) 등이 짜증스러웠습니다. 그러나 모든 CIO 상사 예산의 40%를 차지하는 문제와 비즈니스는 여전히 존재합니다(죄송합니다. 어디에 있는지 기억이 나지 않습니다). 그 중 간단한 것들은 데이터베이스 커널의 호환성[8]이든 변환 도구의 혁신과 업그레이드이든 다양한 도구로 해결되어 임계값을 95%로 높였습니다. 이 데이터는 저자가 초등학교 1학년 때 덧셈과 뺄셈을 하면서 나온 데이터다. 4년 전 쿠알라룸푸르 한구석 회의실에서 클라이언트의 비즈니스를 분석한 결과다. 이는 말레이시아 전자상거래 회사가 Oracle RAC에서 PolarDB로 마이그레이션하는 것을 돕는 사례였습니다. 우리의 마지막 어려움도 이 5%였습니다. 고객 정보 존중의 관점에서 "Goodbye Oracle! PrestoMall의 Alibaba Cloud 전환에 대한 독점 통찰력"(링크: https://alibaba-cloud.medium.com/goodbye-oracle-exclusive-insights- into)에서는 공개 자료만 공유됩니다. -prestomalls-transition-to-alibaba-cloud-d24b05058777), 코드의 80%는 Oracle에서 PG로 수동으로 수정해야 하며, 이는 당시 자동화된 도구(프로그래밍 언어 및 스키마 변환)를 사용하여 10%로 줄일 수 있습니다. , O 당시 버전의 PolarDB와 호환되어 5%로 감소되었습니다. ,
예, 고객 CTO와 저는 데이터베이스 마이그레이션의 마지막 5%가 얼마나 어려운지 알고 있습니다. 다행히 우리는 성공했습니다. 좋은 도구와 많은 인력으로 작업할 수 있습니다. 이 5%가 AIGC가 가져올 수 있는 혁신 포인트입니다.
데이터베이스 개발자를 위한 보조 도구인 Duet AI를 사용하면 2~3% 더 발전할 수 있습니다. 기존 CPP[9]를 새로운 트렌드를 대표하는 GO로 변환하는 것 외에도 적응형 원본 측 데이터베이스 API를 대상 측 데이터베이스 API로 변환할 수도 있습니다.물론 대상 측은 GCP 자체 클라우드 데이터베이스인 AlloyDB입니다. . 더 흥미로운 악마는 디테일에 있습니다.이것은 혁명이 아니라 나사를 하나씩 조이는 혁신입니다. Google Cloud의 Duet AI - 데이터베이스 관리(링크: https://www.youtube.com/watch?v=u6489QehgdQ)는 Oracle에서 AlloyDB(PG 기반 클라우드 데이터베이스)로 표시되며, localtimestamp()에서 clock_timestamp( )까지 자동으로 식별됩니다. , 한 가지 예에서 추론을 도출하여 전역 수정을 수행합니다. 이것은 반나절의 작업을 30분으로 단축하는 작은 조치입니다(영업사원은 1분으로 줄이라고 합니다...저는 좋은 영업사원이 아닙니다).
이 작은 개선은 데이터베이스 마이그레이션에만 국한되지 않지만 이 시나리오에서는 데이터베이스 마이그레이션의 애플리케이션 변환에서 비용 대비 수익이 가장 효과적입니다. 마이그레이션 기술자와 원래 애플리케이션 개발 엔지니어가 n명의 프로그래머로 분리되었을 수 있기 때문에 고객 기술 직원은 원래 프로그램을 이해하는 데 관심도 없고 능력도 없습니다. 원래 애플리케이션에는 수년에 걸쳐 축적된 반복적인 논리 조각이 있을 것입니다. 머신러닝은 복사/붙여넣기에서 프로그래머의 가장 좋은 친구입니다.
- 구현 경로: 기존 데이터 복제 및 스키마 대화 도구 + 클라우드 데이터베이스용 드라이버 + GitHub co-pilot(copilot이 핵심 기술입니다. 데이터베이스 애플리케이션에 맞게 사용자 정의해야 함)
3. 데이터베이스 알람에 대한 DBA의 무관심
처음 클라우드 고객 비즈니스를 접했을 때 선임 기술 리더와 약속을 잡았습니다. 그는 예, 우연히 밤에 근무했기 때문에 자유로웠다. "저녁 9시에 하자. Saiyin International에 바가 있는데 꽤 좋다." 저도 당직자로 일한 적이 있는데, 당직할 때마다 적과 마주하는 느낌이 들고 긴장이 많이 됐어요. 우리는 큰 고객을 지원하기 때문에 "운이 좋다"면 뉴스의 첫 페이지에 나올 수 있습니다.
수년 동안 그룹 내외부에서 기술 지원 업무를 담당해 온 아주 고위직의 직원입니다. 자리에 앉아 와인 한 잔을 주문한 뒤, 보통 하루는 둘이 번갈아 가며 일하는데, 차라리 24시간 혼자 근무하는 게 낫다고 말했다. 하루만 낭비하는 셈이다. 2시간 동안 통화하는 동안 그의 휴대전화는 시종일관 진동했다. 그는 또한 때때로 경찰을 쳐다보아야 했고 때로는 자세한 정보를 읽기 위해 우리의 열정적인 소문을 방해하기도 했습니다. 2년 후, 팬데믹 기간 동안 저는 근무 중인 또 다른 동료를 만났습니다. 술집은 폐쇄된 것 같지만(일시적인 것인지는 모르겠습니다), 직무 수행 방식과 과정에는 변함이 없습니다. 제 심리일지도 모르지만, 달라진 점은 경찰에 더 자주 신고한다는 것뿐입니다.
내가 이전에 맡았던 임무에 비하면 이 사람은 참으로 차분하고 차분한 사람이었다. 하지만 반면에 교대근무당 2번의 통화만 하면 매우 바빠집니다. 왜냐하면 고객의 DBA가 우리의 가장 최첨단 보호이기 때문입니다. 그의 손에 있는 스크립트와 그의 경험은 알람의 높은 품질을 보장합니다. 내 휴대폰으로 직접 푸시됩니다. 그리고 이 남자의 휴대전화로 소위 알람이 수천 통씩 울리는 이유는 무엇일까? 고객은 클라우드 호스팅을 통해 IT 서비스를 클라우드 공급업체에 "아웃소싱"합니다. 실제로 윤의 기술진은 고객의 업무를 이해하지 못하고, 알람의 분류와 처리방법을 제대로 판단하지 못합니다. 따라서 해를 거듭할수록 알람 횟수가 계속 늘어나(이것도 큰 이유이기도 한 면역력을 위해) 99.x%의 쓸모없는 정보가 발생하게 됩니다. 그러나 많은 수작업이 소모되고, 시스템 알람이 심각하게 오염되며, 소위 무결성이 실제 서비스 효율성을 소모하게 된다. 그 선배는 근무하는 동안 의미 있는 일, 즉 회사에서 일하거나 가족과 함께 시간을 보낼 수 없었습니다. 아마도 나와 함께 험담을 나누는 것이 가장 생산적인 결과일 것입니다.
Google은 Google Cloud에 Duet AI를 제안했습니다. 문제 해결(링크: https://www.youtube.com/watch?v=MBAuTQdtZ0o) 사실 이것은 새로운 것이 아닙니다. Snowflake의 성공은 주로 확장성을 갖춘 서비스에 기인합니다. Snowflake의 운영 및 유지 관리로 인해 매일 수십 테라바이트에 달하는 로그 데이터가 생성되며, 해당 비즈니스는 꾸준히 성장을 이어가고 있습니다. 스타트업에 사람(엔지니어)을 추가하지 않고도 서비스(비즈니스)를 추가하는 문턱을 넘을 수 있었던 이유는 로그 자동화를 효과적으로 완성했기 때문입니다. 현재 국내 주요 클라우드 서비스 제공업체를 포함해 많은 기업이 이 한계점에 도달했습니다.
데이터베이스 시스템에 대한 이전 문제 해결 방법 중 일부는 SQL 오류 메시지의 보다 미래 지향적인 설계에 크게 의존했습니다. 예를 들어 MySQL 8.0 오류 메시지 참조(링크: https://downloads.mysql.com/docs/mysql-errors-8.0-en.a4.pdf)는 30년간의 축적을 반영하여 786페이지로 구성되어 있습니다. 이제 AI 대형 모델 도움말을 통해 시스템 오류를 더 빠르게 요약하고 주요 시스템 문제 N시간 전의 상태, 특히 당시에 인지하지 못했던 알람을 분석할 수 있습니다(당직 동생이 잘못된 알람을 제거하도록 도와줌). . 이것은 오래된 장면의 혁신에 직면한 새로운 기술입니다.
기술 경로: 시계열 데이터베이스(일반 데이터 웨어하우스로 충분) + 데이터베이스 로그를 위한 대규모 모델 훈련 + 피드백 메커니즘[10].
4. 꼬리 쓰기
물론 위의 두 가지 방향인 DB용 AI와 AI용 DB에는 각자의 이야기가 있는데, 저는 둘 다 이야기했습니다. 개인적으로 데이터베이스 커널은 충분히 성숙했고 수년 동안 수동으로 최적화해 왔다고 생각합니다. 현재 AL 수준은 실질적인 개선을 제공할 수 없습니다(저는 이 분야의 학문적 작업이나 주요 제조업체의 연구실에 반대하지 않습니다). 핵심적인 개선은 아직 지켜봐야 할 것 같습니다. 일상적인 IT 업무와 관련된 DMaaS를 먼저 시작하고 오늘날의 AI 기술을 사용하여 혁신적인 것을 생산할 수 있습니다. 위의 세 가지 획기적인 지점에 대한 기술 경로는 즉시 실행될 수 있습니다.
위의 아이디어는 Bodega Bay에서 형성되었습니다.
참고
- 실제 아이디어는 현재 국내 최고 데이터베이스의 엔지니어링 책임자인 팀의 최적화 전문가로부터 나왔습니다. 방금 프런트에서 PPT를 훑어봤습니다.
- "LLM이 데이터베이스를 만났을 때: Alibaba DAMO Academy와 HKU가 새로운 Text-to-SQL 벤치마크를 출시했습니다"(Alibaba: https://developer.aliyun.com/article/1262738), TiDB Chat2Query(https://www.pingcap . com/chat2query-an-innovative-ai-powered-sql-generator-for-faster-insights/), "데이터베이스 개발 도구 세계의 ChatGPT가 등장합니다"(https://www.bilibili.com/video/BV1XT411r7HQ/) ;나인데이터 : AI 기반 SQL 최적화(GPT), 사제품이 포함되어 아쉽습니다)
- Ali는 최근 PGVector 및 오픈 소스 크로마(https://github.com/chroma-core/chroma)를 홍보했습니다.
- NebulaGraph 및 TigerGraph
- 정보의 일부 출처는 https://cloud.google.com/blog/products/ai-machine-learning/duet-ai-in-google-cloud-preview입니다. Duet AI는 많은 일을 할 수 있다고 주장합니다. 저자의 지식 범위를 고려하여 데이터베이스/데이터 처리/클라우드 데이터 관련 내용만 탐구합니다. 이번 글에서는 구글의 Duet AI에 초점을 맞추지 않고, 서비스 시나리오를 활용하여 저의 생각을 이야기해보겠습니다. 원문을 참고하셔서 Duet AI를 직접 사용해 보시는 것을 추천드리며, 결국 '원본 자료'가 훨씬 더 신뢰도가 높습니다.
- 유명 브랜드의 클래식 립스틱 색상 10가지라고 하는데, 도저히 이해가 안 되네요. https://www.zhihu.com/tardis/zm/art/565109678?source_id=1003
- PPT 도구에 대한 Markdown. 저는 지난 10개월 동안 이 도구를 사용해 왔습니다. 재미는 있지만 미숙합니다.
- PG 생태학적 EDB(일명 Enterprise DB), 국내 PolarDB-O, Oceanbase-O
- 메인프레임에 앉아 있는 COBOL은 수염을 쓰다듬으며 말했습니다: 오실 건가요?
- 중국인이 개발한 시계열 데이터베이스에는 TDEngine과 Timeplus가 포함되며 누구나 Meta의 오픈 소스 Llama에 대해 들어봤을 것입니다. 피드백 메커니즘은 특별히 설계되어야 하며 현재로서는 계획이 없습니다.