1
| Robert | 켈리 |
감독 |
마케팅 |
|
2
| Tom |
Burke |
대표 |
판매 |
|
3
| John |
Smith |
부사장 | 판매 |
|
더 지루한 내용을 읽을 수 있나요? 이것이 모두 데이터베이스에 관한 것이라면 나는 그들과 아무 관련이 없습니다. 요점은 무엇입니까? 소프트웨어는 이것보다 훨씬 멋지죠? 그래서 나는 오랫동안 데이터베이스와 관련된 모든 것을 완전히 피했습니다.
첫 번째 CRUD 애플리케이션을 결코 잊지 못할 것입니다.
2009년, 수년간 임베디드 소프트웨어, Linux 장치 드라이버 및 웹 소프트웨어를 작성한 후 나는 다음과 같은 팀을 이끌었습니다. 웹 기반 시스템을 구축합니다. 보시다시피 AWS 클라우드가 도래했으며 클라우드 기반 라이선스 기술 MAC 주소는 더 이상 유효하지 않습니다. 우리 팀은 새로운 EC2 기반 소프트웨어 어플라이언스를 위한 라이선스 포털을 구축해야 합니다. Python에 대한 경험이 많았기 때문에 MySQL에서 실행되는 Django를 선택했습니다. 실제로 데이터베이스 작업을 시작했습니다.
우리나라 평원에서 CRUD 애플리케이션 개발이 계속되면서 저는 데이터베이스가 얼마나 중요한지, 즉 우리 시스템에 얼마나 필수적인지 깨닫기 시작했습니다. 데이터베이스를 잃으면 소프트웨어 개발이 헛된 것입니다. 데이터베이스가 데이터를 손상시키는 경우 고객의 장치에 대한 라이선스가 취소될 수 있으며 해당 네트워크의 작동이 중단됩니다. 데이터베이스가 제대로 작동하지 않으면 수천 명의 사람들이 동시에 영향을 받게 됩니다. 하지만 이런 일은 전혀 일어나지 않았습니다. 데이터베이스 는 항상 작동합니다 . 결코 우리를 실망시키지 않습니다. 나는 감동했다.
나중에 외래 키 제약 조건, 고유 제약 조건, 참조 무결성, 인덱스 등을 발견했습니다. (당시에는 이러한 사항에 대해 아무것도 몰랐다는 점을 기억하세요.) 데이터베이스는 다양한 방식으로 더욱 강력한 시스템을 구축하는 데 도움이 될 수 있습니다. 나는 마침내 최신 데이터베이스가 놀랍다는 것을 깨달았습니다. 데이터베이스는 실제로 시스템을 구축하기 전까지는 세상에서 가장 지루한 것입니다 .
첫 번째 검색 시스템도 잊지 마세요
2012년까지 저는 탄력적 검색을 핵심으로 하는 대규모 키-값 데이터베이스를 기반으로 대규모 인덱싱 및 검색 시스템을 구축하는 팀을 이끌고 있었습니다. Elasticsearch와 같은 시스템(세계적 수준의 인덱싱을 기반으로 구축된 기술)이 테라바이트 규모의 로그 데이터를 가지고 있더라도 무엇을 할 수 있는지 보는 것은 놀라운 일입니다.
지금까지 데이터베이스와 검색 시스템이 실패하는 것을 보아왔지만 데이터베이스 기술에 매료되었습니다. 2014년에 저는 [오픈 소스 시계열 데이터베이스](github.com/influxdata/influxdb)의 핵심을 개발하는 소규모 전담 팀에 합류했습니다.
제가 배운
알고리즘은 데이터베이스 개발에만 정말 중요합니다
중국에서만 Big O 분석이 실제로 생생하게 구현되었습니다. 데이터베이스는 프로그래머가 여전히 수백만 개의 개체를 반복하고, 정렬하고, 필터링해야 하는 몇 안 되는 애플리케이션 중 하나입니다. CS 수업에서 배운 지루한 내용이 많이 중요한 몇 안 되는 곳 중 하나입니다.
다른 많은 소프트웨어 개발에서는 그렇지 않습니다. 부트 ROM 펌웨어를 작성 중이신가요? 아니요, 알고리즘은 나에게 중요한 적이 없습니다. 튜너 장치 드라이버? 아니요, 상관없습니다. 네트워크 장치 관리 소프트웨어? CRUD 애플리케이션? 이러한 모든 분야에 서로 다른 기술과 지식이 필요한 경우는 거의 없습니다. 대부분의 경우 인터뷰에서 런타임 복잡성에 대해서만 논의했습니다.
하지만 데이터베이스가 발전하면서 이 모든 것이 바뀌었습니다. 실제로 시스템이 올바른 결과를 반환하는 것을 보는 것은 놀라운 일입니다. 하지만 알고리즘 변경으로 인해 아주 짧은 시간 동안만 발생하며, 여러분이 구축한 시스템에서 이러한 일이 발생하는 것을 보는 것도 중요합니다.
성능도 중요합니다
소프트웨어에는 다음과 같은 오래된 이야기가 있습니다. 프로그래머는 이전 버전보다 10배 빠르게 실행되는 코드를 작성합니다. 보여줬는데, 누군가는 그것이 생산한 데이터가 정확한 데이터와 약간 다르다는 점을 지적했습니다. "그러나 그것은 10배 더 빠르다"고 프로그래머는 지적했다. "음, 정확할 필요가 없다면 공간을 전혀 차지하지 않고 무한히 빠르게 실행되는 버전을 만들 수 있습니다."라고 다른 사람이 대답했습니다.
이 도덕 이야기는 항상 나에게 큰 영향을 미쳤습니다. 옳은 것이 무엇보다 항상 중요합니다. 사실이에요. 그러나 그것은 또한 프로젝트가 단지 올바른 결과를 낳기 때문에 가치가 있다고 믿게 만듭니다.
데이터베이스의 경우에는 그렇지 않습니다.
성능은 단순한 기능 그 이상입니다. 요청입니다. 데이터베이스 비용을 기꺼이 지불하려는 사람들은 데이터 양이 많기 때문에 그렇게 하는 경우가 많습니다. 이 상황에서 데이터베이스가 제대로 작동하지 않으면, 즉 빠르고 효율적으로 결과를 반환하지 않으면 전혀 작동하지 않을 수 있습니다.
글쓰기 시스템이 복잡하다고 생각하시나요?
데이터베이스를 개발하면서 가장 충격을 받았던 점은 쿼리 엔진이 얼마나 복잡해졌는가 하는 점이었습니다. 저는 디스크에 데이터를 쓰고 저장하는 시스템을 구축한 경험이 많습니다. 이러한 시스템을 제대로 작동시키는 것은 중요한 과제가 될 수 있습니다.
그러나 이러한 복잡성은 일반적으로 쿼리 엔진의 복잡성보다 훨씬 적습니다. 유연한 쿼리 시스템(질문이 무엇인지 모를 때 질문에 답하는 시스템을 효과적으로 구축하려면)에는 진지한 디자인 사고가 필요합니다. 쿼리 플래너가 유효해야 합니다. 쿼리 시스템은 특정 차원별 필터링, 다른 차원별 그룹화, 여러 테이블의 데이터 조인, 때로는 외부 소스의 데이터 지원 등 다양한 직교 요구 사항을 지원해야 합니다. 마지막으로, 쿼리 시스템은 반드시 효율적이고 잘 작동해야 합니다. 이는 설계와 구현에서 추상화와 최적화 사이의 긴장으로 이어지며, 이를 잘 관리하려면 실제 기술이 필요합니다.
실제 환경에서는 운영되어야 합니다
중요한 데이터베이스라면 백업, 복구, 조각화 관리, 모니터링 등 기본 작업을 지원해야 합니다.
진지한 운영자인 내가 데이터베이스를 백업할 수 없다면 데이터베이스를 사용할 수도 없습니다. 그렇게 간단합니다. 데이터베이스가 쓰기를 얼마나 빨리 받아들이는지는 중요하지 않습니다. 쿼리 중에는 메모리 공간이 얼마나 작은지는 중요하지 않습니다. 데이터베이스를 만든 사람인 당신이 통제할 수 없는 장애로부터 데이터베이스의 데이터를 보호하지 못한다면 나는 결코 데이터베이스를 편안하게 운영할 수 없을 것입니다.
물론, 데이터베이스의 협조 없이 데이터베이스를 백업하는 방법은 여러 가지가 있습니다. 그러나 일반적으로 내장된 방법이 가장 좋습니다. 이것은 rqlite v2.0에 대한 나의 권장사항이기도 합니다. 누군가가 rqlite를 진지하게 사용하기를 원한다면 시스템이 완전히 실패하고 매우 오랫동안 데이터보다 뒤처질 수 있는 현실 세계의 문제를 해결해야 합니다.
그러므로 데이터베이스를 설계하고 구현할 때 처음부터 운영 지원을 구축하세요. 디자인의 기본 부분으로 만드세요. 사용자는 이에 대해 감사할 것입니다.
대개 대답은 "상황에 따라 다릅니다"입니다.
처음 데이터베이스 작업을 시작할 때, 특히 운영자로서 다음과 같은 질문을 자주 합니다. 시스템을 어느 속도로 인덱싱할 수 있습니까? 쿼리에 얼마나 빨리 응답합니까? 얼마나 많은 디스크 공간이 필요합니까? 잔해 조각은 얼마나 커도 여전히 작동할 수 있나요? 어떻게 속도를 높일 수 있나요? 모두 예약 없이 요청했습니다. 나는 그것을 직접 만들곤 했다.
데이터베이스 프로그래머에게 이런 질문을 할 수도 있습니다. 그리고 여러분이 자주(아마도) 얻게 될 대답은 다음과 같습니다. 그것은 여러분에게 달려 있습니다. 벤치마킹해야 하고 측정해야 합니다 . 이 말을 들으면 짜증이 날 수도 있고 책임을 회피하는 것처럼 보일 수도 있습니다.
하지만 그렇지 않습니다.
이제 이런 질문을 들으면 웃음이 나네요. 너무 순진해요.
인덱싱 속도는 문서 수나 데이터 포인트 수뿐만 아니라 데이터 크기에 따라 달라질 수 있습니다. 이는 일괄 처리, 데이터의 카디널리티, 데이터베이스가 클러스터링되었는지 여부, 데이터의 어떤 열과 필드가 인덱싱되는지, 새 데이터인지 기존 데이터에 대한 업데이트인지, 데이터베이스가 실행 중인 머신에 따라 달라질 수 있습니다. RAM, IO 성능 및 사용된 복제입니다.
성과를 좌우하는 변수는 끝이 없습니다.
쿼리의 경우 시계열 데이터의 시간 범위에 따라 달라질 수 있습니다. 적중된 레코드 수, 쿼리된 필드 수, 범위 스캔 포함 여부, 데이터 인덱싱 여부, 사용된 인덱스 유형, 액세스할 수 있는 샤드 수 및 데이터가 로컬인지 여부에 따라 달라집니다. 그리고 기계 특성. 재고가 있나요? 유지보수 중인가요? 네트워크가 바쁜가요?
그래서 대답은 항상 상황에 따라 다릅니다입니다. 데이터베이스 디자이너는 정직합니다. 그들은 자신이 구축한 시스템에 대한 모든 것을 알 수 있지만 여전히 귀하의 질문에 대한 답은 모릅니다.
프로그래밍 버킷 리스트
프로그래밍 기술을 향상시키고 싶은 개발자에게 한 가지 조언이 있다면 데이터베이스 개발팀에 합류하라는 것입니다. 데이터베이스 개발로 인해 저의 프로그래밍 기술이 엄청나게 향상되었습니다. 정말 멋진 코딩 경험이었습니다.
원본 주소: https://www.philipotoole.com/what-i-learned-from-programming-a-database/
번역 주소: https://learnku.com/go/t/64605
