차례:
작성자 : Techopedia Staff, 2016 년 10 월 5 일
테이크 아웃 : 호스트 Eric Kavanagh는 Dr. Robin Bloor, Dez Blanchfield 및 IDERA의 Bert Scalzo와의 데이터베이스 색인 작성에 대해 설명합니다.
현재 로그인하지 않았습니다. 비디오를 보려면 로그인 또는 가입하십시오.
Techopedia 컨텐츠 파트너
Techopedia 직원은 Bloor Group과 제휴하여 오른쪽 옵션을 사용하여 연락 할 수 있습니다. 업계 파트너와 협력하는 방법에 대한 자세한 내용을 보려면 여기를 클릭하십시오.- 프로필
- 웹 사이트
에릭 카바나 흐 : 신사 숙녀 여러분 안녕하세요, 다시 한 번 환영합니다. 수요일 오전 4시 동부에, 프로그램을 아는 사람들은 그 의미가 무엇인지 알고 있습니다. 이제 핫 테크놀로지의 또 다른 에피소드가 나옵니다. 네 확실합니다. 제 이름은 Eric Kavanagh입니다. 오늘 세션의 중재자는 "Index Insanity : How to Prevent Database Chaos"입니다. 마지막 이메일 폭발에서 언급 한 것처럼 "데이터베이스 랭 글링"요즘 "뜨거운 랭 글링"이라는 용어는 모두 그렇게합니다. 당신에 대한 슬라이드가 있습니다. 그리고 나에 대해 충분합니다.
따라서 Hot Technology 시리즈는 실제로 일대일 라이브 분석 브리핑 인 브리핑 룸과 달리 특정 공간을 정의하도록 설계되었습니다. Hot Tech의 경우 두 명의 분석가가 있습니다. 오늘은 우리의 의사 Robin Bloor와 데이터 과학자 Dez Blanchfield가 될 것입니다. 그리고 우리는 오늘날 시장에서 일어나고있는 일을 실제로 상징하는 주제에 대해 이야기하고 있습니다.
결론은 요즘 우리가 복잡한 세상에 있다는 것입니다. 실제로 15 년 또는 20 년을 생각하면, 특히 데이터베이스 기술과 관련하여 당시와는 매우 다른 세상이었습니다. 데이터베이스는 매우 단순했습니다. 그들 중 소수만이 있었다. 그들 대부분은 관계형이었습니다. 이제 우리는 데이터베이스 기술에 대한 전체적인 정보를 얻었습니다. 문자 그대로 애플리케이션을 구축하거나 데이터로 무언가를 원하는 사람을위한 표의 옵션 점수. 모든 것이 변화하고 있으며 이러한 시스템을 관리하려는 사람들에게 영향을 미칩니다. 오늘이 분야의 전문가 인 Bert Scalzo와 이야기를 나눌 것입니다. 그는 모든 데이터를 처리하기 위해 할 수있는 일에 대해 IDERA의 선임 제품 관리 책임자입니다. 그걸로 닥터 로빈 블로어에게 건네 주겠습니다. 로빈, 바닥은 네 꺼야
Robin Bloor : 소개해 주셔서 감사합니다. 저는 그것이 양손이기 때문에이 Hot Tech 쇼에 대한 소개로서 일반적으로 데이터베이스 최적화에 대해 이야기 할 것이라고 생각합니다. 기술과 분석 분야에서 일을 시작했습니다. DEC VAX 플랫폼에서 데이터베이스의 기능에 대한 기사를 작성했기 때문에 이러한 일을 시작했습니다. 그런 이유로 데이터베이스 사용자는 저를 간략하게 설명했습니다. 그리고 나에게 이런 종류의 일이 일어난 이유는, 왜 데이터베이스를 가질 것입니까? 그 당시에는 많은 사람들이 핵심 가치 파일을 생성하고 우리가 호출 할 때 일종의 색인 순차 오류를 갖기 위해 사용했지만 일종의 데이터베이스 기능을 생성하는 데 사용했습니다. 다른 거요?
마이클 스톤 브레이커 (Michael Stonebraker)는 이에 대한 최선의 답변을했다고 생각합니다. "데이터베이스는 데이터가 어디에 있는지, 얼마나 빨리 얻을 수 있는지, 어떤 프로그램보다 더 빨리 알 수 있습니다." 그리고 나는 그것이 재미 있다고 생각합니다. 게임의 본질입니다. 그러나 19 년 – 1989 년경에 기술 분석을 시작했으며 그 시점에서 데이터베이스는 매우 단순하고 관계형 데이터베이스는 매우 단순했습니다. 그들은 기능이 거의 없었기 때문에 데이터를 저장할 수 있었고 분명히 백업 할 수 있었고 ACID를 준수했지만 최적화 기능이 매우 약했습니다. 실제로 최적화 기능이 전혀 없다고 주장하기는 어려울 것입니다.
나중에 그들은 점점 더 좋아졌지만 데이터베이스가 작동하지 않을 때 (이 캥거루가 어떤 식 으로든 다른 표시로 보이는 것처럼) 느리게 진행되는 많은 이유가있을 수 있습니다. 데이터베이스가 많은 기능을 가지고 있지만 가장 중요한 것은 쿼리 최적화입니다. 그들이 그렇게하지 않으면, 당신은 그것들을 사용하지 않을 것입니다. 정보를 빠르게 얻는 것과 동시 사용자가 많을 때 수행 할 수있는 능력에 관한 것입니다. 이는 어려운 문제입니다. 그리고 실제로 살펴보면, 수십 년 동안이 데이터베이스의 최적화 프로그램을 보유한 Microsoft SQL Server, 확실히 Teradata 및 DB2를 원한다면 성숙한 데이터베이스라고하겠습니다. 건물. 아시다시피, 그들은 두 사람, 년, 프로젝트에 6 명의 녀석이 앉아 있지 않았습니다. 그런 식으로 작동하지 않습니다. 최적화 기능이 점차 커지고 있으며 많은 시간이 걸립니다. 어쨌든 데이터베이스의 배경에 대해 이야기 해 봅시다. 글쎄, 지금 NoSQL 데이터베이스에 대해 많은 이야기가 있으며 그래프 데이터베이스에 대한 열정도 많습니다. 그리고 Hadoop을 통한 SQL 사용 및 이와 유사한 것들. 그러나 문제의 진실은 지금 당장 데이터베이스를 원한다면 완벽하게 기능적이며 OLTP 및 대용량 쿼리 트래픽이 가능한 기능을 원한다면 관계형 데이터베이스이거나 아무것도 아니라는 것입니다.
관계형 데이터베이스 중에서 Oracle이 지배적입니다. 제 생각에 Microsoft SQL Server는 두 번째입니다. 둘 다 OLTP 및 쿼리 워크로드에 사용할 수 있지만 실제로는 해당 워크로드를 혼합하여 벗어날 수 없습니다. OLTP 워크로드와 쿼리 워크로드에 대해 서로 다른 인시던트가 필요합니다. SQL과 그래프에 대한 대안이 있습니다. 대부분의 회사는 하나의 특정 데이터베이스를 표준화하므로 그 이유는 다른 모든 플레이어와 수십 년 동안 싸운 후 Oracle이 가장 지배적 인 데이터베이스가 된 것입니다. 단순히 기업 라이센스를 판매 할 수있게 되었기 때문에 기업은 오라클이하지 않는 예외적 인 제품에만 대체 제품을 사용할 것입니다. 그리고 데이터베이스는 또한 진화한다는 점에서 전략적입니다. 그리고 여러분은 제가이 프리젠 테이션에 대해 약간의 연구를했다고 알고 있습니다. 그리고 그것은 일종의 – 한동안 올 것입니다. 그러나 그것은 DBA의 입장에서 볼 때 그것들이 어떻게 진화하는지 흥미 롭습니다. 이것이 내가 보이지 않는 경향이라고 부릅니다. 무어의 법칙은 입방체입니다. 대략 다음과 같습니다. 가장 큰 데이터베이스는 새 데이터베이스이며 더 많은 데이터를 수집 할 수있는 오래된 데이터베이스는 없습니다. 일반적으로 새로운 문제에 적용되는 데이터베이스입니다. 그리고 실제로 데이터 양 측면에서 성장합니다. 대략 무어 큐브에서 법. 무어의 법칙은 6 년마다 10 배입니다. VLDB는 6 년마다 1, 000 배씩 증가하는 경향이 있습니다. 1991 년, 1992 년에 큰 데이터베이스는 MB 단위로 측정됩니다. 97 년과 98 년에 기가 바이트 2003 년 '4 년, 테라 바이트. 2009 년 '10 년, 페타 바이트 데이터베이스를보기 시작했습니다. 지금은 1 ~ 2 개의 엑사 바이트 데이터베이스가 있다고 생각하지만 지금까지 들어 본 최대 규모는 200 페타 바이트이며 페타 바이트 데이터베이스로 데이터를 가져 오지 않습니다. 그러나 그것은 대부분 새로운 빅 웹 2.0 회사가 될 것입니다. 아마도 페이스 북이 그 방향으로 향하고있을 것입니다.
그러나 어쨌든 실제로 볼 때 데이터베이스가 이러한 종류의 에스컬레이션을 거치기를 기대하면 많은 것을 요구합니다. 그리고 확실히 페타 바이트 수준까지는 상당히 합리적으로 이루어진 것으로 보입니다. 나는 새로운 것이 아니라 오래된 제품에 대해 이야기하고 있습니다. 그들은 엄청나게 잘한 것 같습니다. 데이터베이스 성능, 병목 현상을 살펴보면 실제로 데이터베이스 관리에 사용했던 시간으로 되돌아 가서 걱정해야했습니다. 이것이 기본적으로 하드웨어 고장이라는 것을 알고 있습니다. CPU 병목 현상이 있거나 메모리 병목 현상이 있거나 디스크 병목 현상이있을 수 있습니다. 그것은 슬픔을 유발하는 네트워크 일 수 있으며, 수행중인 작업에 따라 잠금에 문제가 발생할 수 있지만 일반적으로 프로그램은 누가 잠금을 호출 해야하는지 알기 때문입니다. 따라서 데이터베이스를 조정하려는 경우 실제로 가능한 5 가지 병목 현상 사이에서 춤을 추도록 조정하려고합니다. 주어진 서버에서 구성 할 수있는 메모리 양이 크게 증가하기 때문에 이는 쉬운 일이 아닙니다. 그런 다음 CPU는 멀티 코어, 디스크가되었습니다. 이제 우리는 할 수 있습니다. 상품 서버에서도 수백과 수백 테라 바이트, 1/4 페타 바이트, 심지어는 상품 서버에서도 가능하다고 생각합니다. 따라서, 이 모든 것 중에서도, 네트워크는 다른 속도로 진행될 수 있지만, 대부분 데이터베이스를 다룰 때 서버 사이에 광섬유 케이블을 갖고 싶을뿐입니다. 그런 식으로.
데이터베이스 성능 요소. 나는 Dez가 그것에 대해 이야기 할 것이라는 것을 알고 있기 때문에 이것이 무엇에 관한 것인지를 생략하고 있지만 나쁜 데이터베이스 디자인은 성능이 좋지 않은 데이터베이스를 의미합니다. 프로그래밍 디자인이 잘못되면 데이터베이스에 매우 어리석은 SQL을 던질 수 있습니다. 동시성과 워크로드 혼합, 동시성이 너무 많으면 병목 현상 문제가 발생합니다. 작고 짧고 예리한 쿼리가 포함 된 큰 쿼리가있을 경우 작업 부하가 혼합되어 문제가 발생합니다. 로드 밸런싱 문제가 있습니다. 대부분의 데이터베이스가이를 처리하지만 정교한 제품이없는 경우 몇 개의 서버 만 추가하면 실제로 클러스터의 크기를 늘리려는 경우가 아닙니다. 최적의 성능을 얻기 전에 실제로로드 밸런스를 수행해야합니다. 용량 계획을 수행해야합니다. 물론. 특히 오늘날에는 데이터 볼륨이 데이터베이스에 사용 된 것보다 훨씬 급격히 증가 할 때와 같습니다. 또한 데이터 수집 방법, 데이터 이동 방법에 대한 전체 데이터 계층 문제가 있습니다. 제 시간에 데이터베이스에 데이터를 가져 오지 않으면 나중에 Windows에서 작동하는 데이터베이스에서 24 x 75 x 75로 작동하고 속도를 늦출 수있는 창이 없기 때문에 성능 문제가 발생할 수 있습니다. 데이터베이스가 다운되었거나 요즘에는 없을 것입니다.
Oracle DBA 문제 이것이 내가 생각한 것입니다. Oracle 7과 함께 Oracle의 DBA에 있었고 튜닝 방법을 기억합니다. 그리고 실제로 지금 Oracle을 살펴보면 방법, 기능이 향상되었습니다. 비트 맵 인덱싱과 그와 같은 것들이 있지만 실제로 Oracle 데이터베이스에 실제로 얼마나 많은 튜닝 매개 변수가 있는지보고 확인하는 데 시간이 걸렸습니다. 또한 300 개가 넘는 50 개의 튜닝 매개 변수가 있으며 전문 DBA가 알고 있지만 100 개의 숨겨진 매개 변수가 있지만 일반적인 Oracle DBA는 알지 못합니다. 이는 이런 종류의 데이터베이스를 조정하는 것이 쉽지 않다는 것을 의미합니다. 전혀 간단한 것이 아닙니다. 당신은 그것을 느끼고, 오랫동안, 오랫동안 해왔어야하며, 당신이 해결하고 있다고 생각하는 문제가 무엇인지 정확히 알아야합니다. 성능이 떨어지지 만 모든 성능이 아닐 수도 있습니다. 중요한 특정 쿼리의 성능 일 수 있으며 특정 데이터와 메모리를 고정하여이를 수정하거나 인덱싱으로 수정해야하거나 다른 방식으로 파티셔닝을 시작해야 할 수도 있습니다. 할 수있는 일이 많이 있습니다. 요점입니다. 따라서 DBA에는 도구가 필요합니다. 색인 작업에 대해 알려줄 Dez에게 전달하겠습니다.
에릭 카바나 : 알았어.
Dez Blanchfield : 감사합니다. Robin, 표지를 좋아합니다. 나는 당신이 저 건틀릿을 던져서 그 흥미 진진한 것에 가까이 오지 않았다고 생각합니다. 그러나 나는 데이터베이스 관리자에 대한 오늘날의 도전에 대한 나의 견해가 바뀌었기 때문에 우리의 작은 은하의 이미지를 사용했습니다. 이것이 환경에 들어갔을 때 혼란스러워하고 더 이상은 아닙니다. 더 이상 데이터베이스를 관리하거나 해당 레벨의 데이터베이스를 설계하는 세계에서 그러나 자신과 마찬가지로 Robin과 저는 관리자 또는 개발자 또는 궁극적으로 설계자로서 데이터베이스 세계에 수년 동안 참여해 왔으며, 지각을 얻기 위해 더 나은 일을 할 수 있다는 것을 깨달았습니다. 그러나 당신이이 은하의 데이터를 응시하는 것처럼 느껴지는 경향이 있습니다. 오늘날 우리가 출발했을 때, 우리가 간략히 설명하자면, 우리는 메가 바이트에서 페타 바이트로 그리고 엑소 규모로 매우 짧은 시간 안에갔습니다., 위대한 사물의 계획에서. 그러나 제 생각에는 데이터베이스 인덱스는 이제 암흑 예술이며 엔터프라이즈 급 비즈니스 응용 프로그램 및 공식화 유형을 위해 필사자 만이 다루어야 할 내용이 아닙니다. 그냥 얘기하고 있었어 그러나 나는 데이터베이스 세계와 함께했던 역사의 유형에 대해 간략히 살펴보고 결론을 도출 할 위치를 파악한 다음 오늘 친구와 함께 자료를 살펴보고 싶었습니다. IDERA는 데이터베이스 성능 조정을 얻는 방법에 대해 많은 다른 생각이 있고 그 중 하나가 문제를 일으키고 있다고 생각하기 때문입니다. 내가 만나는 많은 상점의 경우 데이터베이스 계층과 특히 인덱스 계층에서 성능 조정을 수행하는 시점에 도달하지 못합니다. .
많은 사람들이 내 마음에 큰 아이언 접근 방식을 취하고 있습니다. 여기서 플래시와 함께 오래된 영화 나 최신 TV 쇼를 본 적이 있다면 플래시 사진을 볼 수 있습니다. 플래시 고든은 오래된 캐릭터 였고 이제는 "플래시"라고 불렀습니다. 그는 매우 빠르며 항상 에너지가 부족한 경향이 있습니다. 그리고 이것이 데이터베이스 성능에 큰 영향을 줄 때 일어나는 일입니다. 필자의 경험으로는 항상 게임에 고성능의 노력을 기울이고 운영 체제를 최적화하고 특정 지점에 맞게 조정할 수 있습니다. 빠른 멀티 코어, 멀티 스레딩 CPU를 사용하여 응용 프로그램을 더 빠르게 실행하고, 많은 RAM을 처리 할 수 있으며, 많은 백플레인을 가질 수 있으며, 하드 드라이브에서 하드 드라이브 캐싱, 솔리드 스테이트로 전환 할 수 있습니다. 고성능 스토리지 어레이. 그리고 지금도 사람들은 데이터베이스 엔진에 플래시 및 NVMe와 같은 것들을 던져 로그인 시간이 두 배로 늘어날 것이라고 생각했습니다. 그리고 그들은 항상 이익을 얻습니다. 그러나 모두 동일한 기본 성능 조정 문제로 돌아옵니다. 대기 시간이 짧은 네트워킹 연결이 많으므로 클러스터가 빠르게 작동합니다. 또한 데이터베이스 인프라 클러스터링을 통해 모든 작업을 수행하는 머신이 두 대 이상 있습니다. 그러나 동일한 기본 성능 문제로 돌아가는 경향이 있으며 이는 데이터를 읽는 것입니다. 데이터를 작성하는 것은 대부분 선형 적으로 어려운 문제이며 제대로 수행되지 않는 한입니다.
그리고 오늘날 우리는 모든 데이터베이스가 똑같이 생성되는 것은 아닙니다. 데이터베이스와 인용 부호 "데이터베이스"가 있습니다. 그리고 데이터베이스 엔진에 대해 생각할 때 사람들은 종종 SQL 세계에서와 같이 일반적인 일반적인 용의자에 대해 생각합니다. 우리는 Oracle과 Microsoft SQL Server를 보유하고 있으며 현재 Oracle이 소유하고있는 MySQL을 사용하는 오픈 소스 세계에는 몇 가지가 있지만 여전히 오픈 소스입니다. 그리고 색인 생성 및 성능 관리와 관련하여 여전히 문제가있는 NoSQL 엔진 인 NoSQL 엔진이 있습니다. 자세한 내용은 다루지 않겠습니다. 매일 나타나고 개발자의 관점과 성능의 관점에서 데이터베이스 엔진처럼 보이고 느껴지지만, 매우 다른 짐승이며 세계에 작은 틈새가 있습니다. 디스크 내 메모리 성능 또는 선형 스케일. 그러나 이것이 데이터베이스 세계에서 세상이 어떻게 생겼는지입니다. 이것은 2016 년입니다. 이것은 데이터베이스의 모습에 대한이 지속적인 풍경 맵을 생성하는 다양한 사람들에 의한 맵의 버전 3입니다. 그리고 이것은 초 인간적인 데이터베이스 아키텍트 나 데이터베이스 관리자조차도 이해할 수없는 곳입니다. 그것의. 말 그대로 수백, 수백, 수백 가지의 서로 다른 제조사, 모델, 데이터베이스 제조업체는 항상 SQL을 준수합니다. 흥미로운 점은 모두 같은 도전으로 돌아온다는 것입니다. 데이터베이스 엔진을 중심으로하는 성능 및 성능 조정, 특히 데이터 색인 생성 방법에 따라.
흥미로운 주제이기 때문에 데이터베이스 인덱싱을 빠르게 다루도록하겠습니다. 데모를 통해 더 자세히 설명해야합니다. 그러나 데이터베이스 인덱스 성능 조정은 데이터를 빠르고 빠른 형식으로 액세스 할 수있는 한 세계가 시작되고 끝나는 곳이라는 것이 상당히 잘 받아 들여지고 표준 업계 관행이라고 생각합니다. 그러나 데이터베이스 인덱싱이란 무엇입니까? 우리가 일상적인 인간에게 익숙한 형태의 색인 생성을 생각한다면, 책에서 색인 페이지를 생각하십시오. 책에서 무언가를 찾고 싶다면 (특히 백과 사전과 같은 것 또는 어떤 형태의 참조 자료와 같은)이 페이지와 같은 것을 찾고 있다면 여기서 댐의 주제와 같은 것을 찾고 있습니다 백과 사전에서. 나는 일반적으로 인공으로 만든 댐, 물의 집수 및 대형 건축 면적에 대한 모든 참조를 찾고 싶습니다. 나는 뒤쪽으로 가서 알파벳순으로 정렬 된 목록에서 A부터 Z까지, 왼쪽에서 오른쪽으로, D를 찾을 것입니다. 나는 "dams"라는 단어를 찾을 수 있습니다. 16, 38, 41쪽에 그것들에 대한 참조가 있고, 그 페이지로 가면 눈을 스캔 할 수 있고“dam”이라는 단어에 대한 참조를 찾을 것입니다. 이것은 데이터베이스에서 본질적으로 동일한 개념입니다. 하지만 지금은 여러 가지면에서 로켓 과학입니다. 실제로 내가 아는 모든 데이터베이스 관리자는 인덱스가 경험에 관계없이 데이터베이스 환경에서 성능 조정을위한 가장 중요한 도구라고 생각합니다. 사건이 무엇이든간에.
일반적으로 데이터베이스 인덱싱에 대해 이야기 할 때 여러 가지 일반적인 접근 방식이 있습니다. 그리고 데이터베이스 인덱스가 복잡할수록 데이터 인덱싱에 대한 접근이 더욱 복잡해집니다. 그러나 데이터 인덱싱에 대해 생각할 때 – 이름 목록이있는 파일이 있다고 상상해보십시오. 알파벳 순서로 정렬되지 않을 수 있습니다. 20 개가 있다고 상상해 봅시다. 정렬 할 경우 – 목록에서 데이터를 위에서 아래로 검색하려고한다면 이름 목록이라고하겠습니다. 임의의 이름을 선택하고 해당 목록을 위에서 아래로 선형 형식으로 스크롤하기 시작하고 순서가없는 목록 인 경우 평균 검색 시간과 최대 검색 시간으로 생각할 수있는 두 가지 기준이 있습니다. 두 번째 줄에 오타가 있고 '최대 검색 시간'이어야합니다. 죄송합니다. – 평균 검색 시간은 기본적으로 N 더하기 1을 2로 나눈 값이며, 평균적으로 시간의 50 %가 걸립니다. 목록 상단에서 목록 하단으로 스캔하여 해당 목록에서 임의의 항목을 찾습니다. 그리고 두 번째 줄은 선형으로 "최대 검색 시간"이어야합니다. 그러나 최대 검색 시간은 기본적으로 항목 수이며, 즉 내가 20 개의 목록이 있으면 가장 많은 시간이 소요될 수 있습니다. 해당 데이터베이스에서 무언가를 검색하는 것은 위에서 아래로 이동하는 것입니다.이 간단한 예제에서 20 개의 항목을 가정 해 봅시다. 그리고 그것은 매우 느린 과정이며 실제로 성능을 조정할 방법이 없습니다. 그런 다음 해당 데이터를 가져오고 인덱스를 만드는 다른 유형의 방법이 있습니다.이 방법은 실제로 이진, B- 트리, 비트 맵, 해싱, 클러스터 및 비 클러스터 같은 실제 데이터 위치에 대한 간단한 포인터 목록입니다. 공간, 필터링, XML 및 전체 텍스트와 같은 다른 유형의 데이터가 있습니다.
이진은 데이터가 데이터를 빌려주는 데 매우 일반적으로 사용되는 것입니다. B- 트리는 일반적으로 데이터의 형태에 따라 인덱스를 구성하는 일반적인 방법이며 로거, 선택 및 삽입 및 삭제가 상대적으로 쉽습니다. 포인터, 포인트를 참조하십시오. 비트 맵과 같은 다른 유형이 있는데, 여기서 우리는 어떤 형식의 관련 범위가있는 경우 데이터 유형이 중요합니다. 해싱은 대형 객체, 특히 블로그 및 이미지에 매우 효과적입니다. 그리고 데이터 인덱싱에는 여러 가지 유형의 과학적 접근 방식, 수학적 접근 방식이 있음을 알 수 있습니다. 단순한 필사자에게는이 수준에서 이야기해야 할 흥미로운 도전입니다. 데이터베이스 관리자를 위해 성능 수준에서 이야기 할 때, 그들은 실제로 로켓 과학자가되고 사람들은 학위를 얻습니다 .Robin Bloor 박사는 확실히 그렇게했으며 IBM과 같은 사람들을 위해 책을 썼습니다. 지난 수십 년 동안 다른 대형 브랜드. 그리고 – 내 견해는, 우리가 실제로 시스템 앞에 앉을 수 있고, 그것을 분리하여 보여줄 수있는 시간을 이미 알고 있다는 것입니다. 성능 문제가 명령 행 또는 그래픽 사용자 인터페이스 시작 도구에서 정확히 어디에 있었는지 확인하고 데이터를 조사하고 문제가 발생한 위치를 알려주고 색인, 하위 색인 또는 기본 및 보조 색인을 빌드하십시오. 데이터를 찾고 그것을 사용하여 물건을 찾으십시오. 그러나 그 풍경에 대해 생각할 때 수백, 수백 개의 브랜드, 제조사 및 모델, 제조업체 및 유형의 데이터베이스를 보유한 곳에서 보여 드렸습니다. 우리는 인간이 만들 수있는 지금 그 시간을 지났으며 현재는 과거입니다. 우리가 가진 데이터베이스 엔진의 유형에 대한 감각. 특히, 요즘은 관계형 데이터베이스 플랫폼에서 오라클과 같은 유명 브랜드로 돌아온 경우에도 마찬가지입니다.
ERP 또는 HR 또는 재무 시스템과 같은 독점 플랫폼에서 처리해야하는 데이터베이스 수 또는 여러 가지 이유로 홈 베이크 플랫폼인지 여부, 데이터베이스 및 데이터베이스 테이블 및 레코드 수 다루는 것은 천문학적이며 육체적으로는 손으로 할 수 없습니다. 그리고 우리는 이제 한 번에 데이터베이스 서버가 책상 아래 앉아있을 수있는 추가적인 문제를 겪었습니다. 방과 후 어린 시절, 원래는 Apple IIes에서 데이터베이스 소프트웨어 작업을하고 dBase II, dBase III와 같은 DOS PC 기반 시스템은 메인 프레임과 중반의 시대를 겪었습니다. VAX, PDP 및 로그 파일까지 포함됩니다. 그리고 Sabre와 비슷 해졌고 결국에는 일부 SQL 데이터베이스가 등장했습니다. 그러나 요즘 데이터베이스 엔진에 대해 생각할 때 왼쪽 하단처럼 보입니다. 데이터베이스 서버는 더 이상 책상 아래 바닥에 앉아있는 기계가 아닙니다. 데이터베이스 엔진과 클러스터의 복사본을 실행하는 수백 대의 시스템이며 페타 바이트 규모의 데이터가 아니라면 수백 테라 바이트의 데이터로 확장됩니다 (수천 테라 바이트). Robin Bloor 박사가 언급했듯이 항공사, 특히 정부 기관과 같은 특정 사용 사례는 엑사 바이트에이를 수 있습니다. 그들은 여전히 틈새 시장이지만 수백 테라 바이트 및 수십 페타 바이트는 더 이상 드문 일이 아닙니다. 특히 닷컴 붐에서 지금까지 우리가 웹 2.0 회사, Facebook, Google, Yahoo와 같은 회사라고 부르는 것 기타 등등.
우리는 이제 일이 외부 서비스로 옮겨 가고 있다는 합병증이 있습니다. 인프라를 제공하는 서비스 접근 방식으로 인프라 플랫폼과 소프트웨어가 있습니다. 특히 오라클과 같은 클라우드 플랫폼, 데이터베이스 및 서버를 구매할 수없는 플랫폼 서비스입니다. 이를 통해 애플리케이션을 매우 빠르게 개발하고 데이터베이스를 서버에 다시 연결할 수 있습니다. 우리는 후드 아래에 무엇이 있는지 생각할 필요가 없습니다. 단점은 데이터베이스가 손상되기 시작하고 성능이 문제가 될 때까지 데이터베이스를 설계하고 구현하는 방법에 대해 종종 생각하지 않는다는 것입니다. 그리고 데이터베이스가 손상된 이유를 진단 할 수있는 올바른 도구를 찾아야합니다. 성능 문제가있는 곳 그리고 그것은 우리가 그 데이터를 어떻게 색인화했는지와 그 데이터를 위해 우리가 사용했던 색인의 유형에 대한 일반적인 문제로 돌아 가게하고, 그 결과 우리는 초인적 성능 요구 사항으로 되돌아갑니다. 올바른 시스템에 액세스하고 엔진을 성능 조정하는 데 적합한 도구를 갖춘 사람은 핫스팟을 찾기 시작하고 쿼리의 위치, 데이터의 이동 위치, 쿼리 유형, 쿼리 구성 방법, 쿼리를 수행하는 사람 및 쿼리가 큐에 대기 중인지 캐시해야하는지 여부 어떤 복제를 찾으십니까?
따라서 세계 최고의 데이터베이스 전문가, 기본적으로 데이터베이스 아키텍트, 데이터베이스 관리자 및 성능 기반까지도 올바른 툴을 활용해야합니다. 모든 데이터베이스 엔진에 최적의 성능 인덱스 튜닝을 제공합니다. 우리가 다루고있는 규모와 사물이 이동하는 속도 때문에 손으로 할 수 없으며, 그렇게하려고 시도하면 다른 성능 문제가 발생할 수 있습니다. 우리는 문제를 해결하려고 노력하고 있습니다. 그리고 그것이 바로 우리가 Bert에게 전해야 할 곳이라고 생각합니다. 그리고 우리는 그들이이 다양한 문제를 어떻게 해결했는지와 그들의 도구가 할 수있는 것들의 유형에 대해 이야기하려고합니다. 특히 오라클 세계에 적합합니다. 그리고 거기에서, 버트, 나는 너에게 넘겨 줄 것이다.
버트 스 칼조 : 감사합니다. 모두 환영합니다. 제 이름은 Bert Scalzo입니다. 저는 IDERA에서 일합니다. 일부 데이터베이스 제품의 선임 제품 관리자입니다. 오늘 그 중 일부를 시연 할 것입니다. 그러나 인덱스에 대해 이야기하고 싶습니다. 모든 사람들이 여기에서 말한 모든 내용, 특히 마지막 슬라이드에 동의하기 때문에 인덱스가 너무 복잡하여 도구가 필요하므로 확신을 드리고 싶습니다. 따라서 Oracle 인덱스 디자인은 예전처럼 쉽지 않았습니다. 많은 사람들이 선택 사항을 볼 때 자신을 확신하지 못할 것입니다. 나는 역사에서 뽑아 낸“이러한 점에서 유일한 것은 확실하지 않습니다.”라는 말을 좋아합니다. X, Y 또는 Z의 색인을 작성해야한다는 답을 알고 있다고 생각하더라도 시도 할 때까지는 확신 할 수 없습니다. 최적화 프로그램이 때때로 예상과 다르게 동작하기 때문입니다. 인덱스 디자인에는 많은 시행 착오가 있습니다. 좋은 옛날에는 색인이 필요한 경우 일반적으로 두 가지 질문 또는 한 가지 질문 만있었습니다. 독특 했습니까, 아니면 독특하지 않습니까? 인덱스가 너무 많으면 삽입, 업데이트 및 삭제 속도가 느려지기 때문에 "단일 테이블에서 최대 인덱스 수는 몇 개입니까?"와 같은 다른 사항을 생각했을 수도 있습니다. 데이터베이스 시스템에 있었거나 다중 열 인덱스에있을 수있는 열 수에 대한 제한이있을 수 있습니다. 데이터베이스 엔진의 페이지 또는 블록 크기에 따라 제한이 있었지만 실제로는 매우 간단했습니다. 좋은 옛날에. 색인을 작성했거나 작성하지 않았습니다. 그리고 실제로 모든 것이 B- 트리에있었습니다. 우리는 복제물을 허용 할 수도 있고 그렇지 않을 수도 있습니다. 인생은 좋았고 인생은 단순했습니다.
오늘날의 삶은 그리 좋지 않거나 단순하지 않습니다. B- 트리 대 비트 맵 대 비트 맵 조인이 있으므로 빨간색 Ghostbuster 기호를 이전과 같은 방식으로 사용했습니다. 그리고 나는 이것들 중 일부가 순간에 무엇인지 설명 할 것입니다. 클러스터 및 비 클러스터, 고유 또는 복제, 순방향 또는 역순, 기능 기반, 분할 또는 분할되지 않은. 파티셔닝이 관련된 경우 글로벌 또는 로컬 파티셔닝입니까? 나는 또한 그것을 설명 할 것이다. 그리고 인덱스 구성 테이블이라고도합니다. 그리고 제가 여기에서 그만 두었던 다른 사람들이 실제로 6 개가 있습니다. 지금 여기에 충분하다고 생각하기 때문에 당신이 생각했던 것보다 색인이 훨씬 더 강하다는 것을 확신시켜 줄 것입니다. 이 특정 슬라이드에서는 다이어그램의 왼쪽 상단에서 시작하여 테이블이 있습니다. 그리고 가장 먼저 결정해야 할 것은 데이터베이스 버전과 데이터베이스 공급 업체에 따라 개체 테이블을 허용합니까, 아니면 관계형입니까? 나는 오른쪽으로 내려 가서 관계형 테이블을 만들고 있다고 말할 것입니다. 자, 제가 물어야 할 다음 질문은 클러스터에 있습니까? 그리고 한동안 Oracle을해온 많은 분들이 클러스터가 Oracle 6 일 동안 돌아 왔음을 기억할 것입니다. 아마도 오늘날에는 더 이상 많이 사용되지는 않지만 먼저 그 지점으로 내려가겠습니다.
테이블을 클러스터에 넣으려면 해당 테이블에 클러스터형 인덱스가 있어야합니다. 이제 Oracle에서는 테이블을 클러스터링 할 때 기본적으로 행을 저장했거나 값이 비슷한 행이 서로 가깝습니다. 따라서 클러스터 된 인덱스가 있어야하며 해당 클러스터 된 인덱스는 파티션되지 않을 수 있습니다. 다시 말해, 클러스터 된 테이블을 수행하는 방법에 대한 파티션 방법은 실제로 없었습니다. 엄격하게 파티션되지 않았습니다. 그리고 파티션되지 않았기 때문에 글로벌이었습니다. 나는 전 세계가 1 분 안에 무엇인지 설명 할 것이다. 그리고 항상 B- 트리였습니다. 다시 말해, 내가 그 지점을 넘어 갔을 때, 그것은 아주 간단했습니다. 많은 선택이 없었습니다. 이제 일부 버전에서 허용 된 클러스터 테이블에서 비 클러스터형 인덱스를 수행 한 경우 다시 파티션되지 않았습니다. 분할되지 않은 경우 유일한 선택은 전역입니다. 따라서 B- 트리 또는 비트 맵을 선택할 수 있습니다. 다시 말하지만, 데이터베이스 버전에 따라 다릅니다. 그러나 이제 관계형 테이블로 돌아가서 다시 오른쪽으로 내려 가기 시작하면 이제 평범하고 오래된 일반 규칙적인 테이블이 있습니다. 관계형. 테이블 스페이스에있을 것입니다. 우선 여기 오른쪽으로 내려갑니다. 그래서 그것은 조직입니다. 다음으로 스스로에게 물어봐야 할 다음 질문은“이 테이블을 분할하고 싶거나하지 않습니까?”입니다. 이제 때때로“최적화 프로그램이 쿼리를 최적화하는 방법에 대해 더 현명 할 것입니다. ”그러나 많은 DBA는 귀하가 그 이유를 관리 목적으로한다고 말할 것입니다. 수십억 행의 테이블이있는 경우 테이블을 파티션 또는 버킷으로 나누면 마지막 버킷에 데이터를 추가 할 때 몇 백만 행에 불과한 인덱스를 삭제하고 인덱싱 할 수 있습니다. 해당 데이터를 삽입 한 다음 해당 버킷에서만 해당 인덱스를 재 구축 할 수 있습니다.
파티션 제거와 같은 일부 최적화 기술에는 좋은 기술 이었지만 실제 가치는 더 작은 조각에 대해 관리 작업을 수행하거나 수행 할 수있었습니다. 조직 힙으로 이동할 때 첫 번째 질문은“파티션을 분할 했습니까?”였습니다. 왼쪽으로 이동하면 테이블을 분할하지 않겠습니다. 이제 말하면 이상한 것처럼 보일 수 있지만 파티션되지 않은 테이블을 가질 수 있으며 익숙한 것처럼 인덱스를 분할 할 수 없거나 인덱스를 분할 할 수 있습니다. 멈추고 생각하십시오. 테이블에는 기본적으로 항상 생각했던 것처럼 하나의 버킷이 있지만 인덱스에는 여러 개의 버킷이 있습니다. 이 경우 버킷 수와 테이블이 불일치하고 인덱스의 버킷 수가 일치하는 경우 전역이 의미합니다. 따라서 테이블이 분할되지 않고 인덱스가 분할 된 경우 불일치가 있으므로 전역으로 간주됩니다. 이제 조직 힙으로 돌아가서 파티션 쪽에서 내려 오겠습니다. 이제 파티션 테이블이 있고 테이블에 네 개의 버킷과 네 개의 파티션이 있다고 가정하면 인덱스에 네 개의 버킷이있어 인덱스가 테이블 디자인과 일치 할 수 있습니다. 그래서 그것은 끝났습니다. 그것은 로컬로 간주됩니다. 로컬 인덱스는 기본적으로 테이블과 인덱스의 분할이 동일한 방식으로 수행되고 동일한 버킷 수를 갖음을 의미합니다. 그런 다음 로컬 인덱스가 있으면 B- 트리 또는 비트 맵일 수 있으며, 초록색 화살표가 올라가면 B- 트리 일지라도 여전히 선택할 수있는 옵션이 있음을 알 수 있습니다. 함수 기반 일 수 있습니다. 또한 비트 맵 인 경우 다른 유형의 비트 맵이 있습니다. 비트 맵 조인 인덱스라는 것이 있습니다. 데이터웨어 하우징을 수행하는 경우 스타 스키마 또는 디자인에 매우 널리 사용되는 인덱스입니다. 무슨 일이 일어나는지 인덱스는 테이블에서 가리키는 것에 대한 행 ID를 가지고 있지만 부모 테이블에 대한 행 ID도 가지고 있으므로 스키마 디자인에 별표를 표시해야합니다. 팩트 테이블에서 팩트 테이블의 해당 인덱스는 관심있는 데이터를 가리키고 차원의 모든 행을 가리 키므로 하나의 인덱스 만 있으면됩니다.
실제로 이것은 몇 년 전 데이터베이스 인 레드 브릭 (Red Brick)으로 인해 생겨났습니다. 많은 사람들이 그것을 기억할 것입니다. 따라서이 그림을보고 – 그림이 더 클 수 있기 때문에이 그림에 모든 것을 넣지 않았다는 점을 명심해야합니다. 여전히 오른쪽 상단 부분의 텍스트에 추가 문제가 있습니다. . 역순 인덱스입니까? “왜 역차 수 지수를 원할까요? Oracle의 클러스터 환경에있는 경우, 실제 응용 프로그램 클러스터를 사용하는 경우 인덱스를 순서대로 유지하고 역순으로 처리하지 않으면 처리량이 많은 경우 동일한 값 또는 동일한 인덱스 값을 사용하면 B- 트리의 핫 영역이 생깁니다. 그것은 당신이 그 물건에 접근하려고 시도하는 경합과 잠금을 가지고 있고 네트워크의 노드 전체에서 그것을 할 것임을 의미합니다. 음, 역순 색인을 넣으면 이제 취소 할 수 있습니다. "음, 비슷한 값이 나무의 다른 부분에 있기 때문에 나무의 더운 지역과 경쟁하는 별도의 노드가 없습니다."라고 말하면 고유 한 옵션이 일부 옵션에서 작동하지 않습니다. . 당신이 보면, 나는 3, 5, 8 및 11의 번호를 매겼으므로 고유 색인을 가질 수없는 경우가 있습니다. 마찬가지로 역 인덱스를 가질 수없는 경우가 있으며 로깅 또는 로깅 없음, 병렬 및 비 병렬과 같은 추가 문제가 있습니다. 메모리의 특정 영역에 항목을 할당 할 수 있습니다.
그리고 이것은 여전히 Oracle의 많은 기능을 생략합니다. Oracle 12를 살펴보면이 그림에 추가 할 수있는 6 가지가 또있을 것입니다. 인덱싱은 정말 복잡하고 이전 연설자와 동의합니다.이를 탐색하고 좋은 선택을하려면 도구가 필요합니다. 이런 종류의 그림이 필요하고 물건을 선택하는 방법에 대한 방법론이 필요하며 도구가 도움이 될 것입니다. 그리고 시행 착오가 될 것입니다. 나는 항상 사람들에게 색인 생성에 대해 이야기합니다.“도약하기 전에 봐요.”그러면 작은 개를 볼 수 있습니다. 그는 보지 않고 뛰어 오르고, 상어와 함께 물에 빠질 것입니다. 그리고 그는 자신을 찌를 것입니다. 색인을 생성한다고해서 항상 상황이 좋아지는 것은 아니기 때문에 색인에 대해 생각해야합니다. 실제로 인덱스를 만들면 속도가 느려질 수 있습니다. 또한 쿼리 성능은 한 가지 선택만으로도 훨씬 더 나을 수 있습니다. 좋은 예를 들겠습니다. 스타 디자인의 스키마를 수행하고 차원 테이블에서 비트 맵 인덱스를 사용하고 다른 경우에는 "B- 트리 인덱스를 사용하겠습니다"라고 말하면 비트 맵과 B- 나무. 하나의 솔루션이 다른 솔루션보다 수십 배나 빠를 수 있다고 말할 수 있습니다. 그러나 데이터웨어 하우징 환경과 같이 한 환경에서 작동하는 것이 OLTP 환경에서는 적합하지 않을 수 있습니다.
예를 들어, 트랜잭션 테이블을 가져 와서 트랜잭션 테이블에 비트 맵 인덱스를 넣는 경우 비트 맵, 이러한 긴 문자열 등을 계산하고 재설정하는 데 많은 비용이 듭니다. OLTP 테이블에서 비트 맵이 너무 높아 테이블에 부딪 힐 수 있습니다. 색인은 단지 업데이트 용이 아니기 때문에 손상되어 시스템 속도를 늦출 수 있습니다. 빠른 액세스에는 좋지만 업데이트에는 적합하지 않습니다. 인덱스에 시행 착오가 걸린다고 생각합니다. 더 이상 황금률이 없습니다.이 방정식에는 너무 많은 변수가 있습니다. 궁극적으로 데이터베이스에서 실행을 보거나 계획을 설명하여 선택을 잘하고 있는지 확인해야합니다. 때로는 계획 분석이 과학 자체가 될 수도 있습니다. 오늘은 다루지 않겠습니다. 또 다른 주제입니다. 그러나 인덱스 디자인은 당연한 것으로 생각하지 않습니다. 이전 그림에서 내가 보여준 모든 미친 색인 유형이 있고 합법적 인 이유가 이전의 발표자가 이야기 한 이유가 있습니다. 이것들은 데이터베이스 벤더를위한 체크리스트를 작성하는 깔끔한 기능이기 때문에 만들어진 것이 아닙니다. 이러한 인덱스가 중요하고 큰 차이를 만들 수있는 사용 사례 또는 시나리오가 있습니다. 이제 도구 중 하나에서 다양한 유형의 인덱스에 대한 몇 가지 예를 보여 드리겠습니다. 화면을 띄워서 볼 수있게하겠습니다. 자, 이제 여기에 앉아 있습니다.이 응용 프로그램을 최소화하겠습니다. VMware에 앉아 있고 Windows Server 2012 VM을 실행하고 있습니다.
보시다시피, 나는 사람에게 알려진 모든 도구를 가지고 있습니다. 제품 관리자는 경쟁에 대한 인식을 유지해야하므로 도구는 무엇 일뿐 아니라 경쟁 업체는 어떻게해야합니까? 그리고 우리는이 도구를 DBArtisan이라고합니다.이 도구는 이미 실행 중이지만 계속 진행할 것입니다. 보시다시피 Oracle 및 SQL Management Studio for SQL Server, MySQL Workbench for MySQL 및 우리가 지원하는 12 개의 다른 데이터베이스를 사용해야하는 대신이 도구는 정말 훌륭한 도구입니다. 글쎄, 나는이 하나의 도구에 모든 데이터베이스를 내장했다. DB2, MySQL, Oracle, Postgres, SQL Server 및 Sybase가 있습니다.이 도구는 할 수 없기 때문에이 데이터베이스에는 6 개의 데이터베이스 만 있습니다.이 도구는 12 개의 데이터베이스를 지원하지만 열악한 VM은 6 개의 데이터베이스를 동시에 실행하고 시도합니다. 데모를하려면 하드웨어가 최대한 활용하는 정도입니다. 자 이제 오라클로 돌아가 보자.이 모든 것들이 같다. DB2에서 성능을 측정하려면 Oracle에서와 동일한 선택입니다. 이제 덮개 아래에서 다양한 작업을 수행하므로 진행 상황을 알 필요는 없지만 일관된 인터페이스를 제공하므로 여러 데이터베이스 플랫폼 전문가가 될 수 있습니다. 그리고 여기에는이 논의의 주제 인 인덱스 작업이 포함됩니다.
여기에 와서 몇 가지 테이블을 살펴보면서 시작하겠습니다. 몇 개의 테이블이있는 영화 데이터베이스가 있습니다. 그리고 고객 테이블과 같은 특정 테이블을 보면 여기를 가져올 때 테이블 디자인, 테이블의 열 및 각 열에 대한 정보를 볼 수 있습니다. 테이블의 속성이 있지만 여기에 인덱스 탭이 있으며 여기에 테이블의 인덱스가 있음을 알 수 있습니다. 이 인덱스 중 하나는 기본 키인 PK 인덱스입니다. 이 다른 것들은 쿼리 액세스를 개선하기위한 인덱스 일뿐입니다. 이름이나 성으로 쿼리하거나 전화 및 우편 번호를 볼 수도 있습니다. 이 우편 번호와 같은 특정 색인을 선택하고 두 번 클릭하면 고유하지 않은 색인이며 비트 맵, 고유하지 않은 다른 유형, 고유 여부, 정렬 여부, 해당 로깅 여부, 역순 여부, 함수 기반인지 여부. 아, 내가 다루지 않은 재미있는 것이 있습니다. 실제로 보이지 않는 인덱스를 가질 수 있습니다. “음, 왜 보이지 않는 인덱스를 만들고 싶을까요?”글쎄, 좋은 예를 들겠습니다. 프로덕션 시스템에 있고 성능 문제가 있으며 인덱스를 작성하면 문제가 해결되는지 확실하지 않으므로 인덱스를 작성하지 않고 프로덕션 속도를 낮추고 싶지 않지만 어쨌든 원하는 다른 그것을 테스트 할 수 있습니다. 프로덕션에서 인덱스를 보이지 않게 만들 수 있습니다. 즉, 옵티 마이저를 호출하는 많은 애플리케이션 코드가 해당 인덱스를 사용하지 않습니다. 작성되었지만 유효하지만 사용되지 않습니다. 그런 다음이 인덱스가 도움이 될 것으로 생각되는 쿼리 또는 일련의 쿼리를 수행 할 수 있습니다.“이봐, 옵티 마이저, 보이지 않는 인덱스가 있습니다. 이제 더 나은 제품을 만들 었는지 알 수 있습니다.”이제 프로덕션 환경에서 무언가를 테스트했지만 프로덕션 환경에서 응용 프로그램을 중단하지 않았습니다. 그것은 보이지 않는 인덱스를 사용합니다. 처음 들었을 때 어리석은 소리가 나지만, 사용하고 있습니다.
또한 인덱스에서 병렬인지 여부와 병렬 인 인스턴스 수를 정의 할 수도 있습니다. 이제 비 클러스터 또는 비 실제 응용 프로그램 클러스터 환경에서 랙이 아닌 병렬은 쿼리에서 시도 할 수있는 하위 프로세스 수와 작업자 프로세스가 더 빠르고 더 빠르게 작업을 수행 할 수있는 하위 프로세스 수를 의미합니다. . 실제 응용 프로그램 클러스터에 있다면 병렬 인스턴스는 10 개의 노드가 있다고 가정하면 몇 개의 노드로 작업을 분할 할 수 있습니까? 어쩌면 10 개 중 4 개일 수도 있고 각각에 4 개의 하위 프로세스 일 수도 있습니다. 그게 예입니다. 그리고 키 압축이 있습니다. 실제로 인덱스를 압축 할 수 있습니까? 예 혹은 아니오. 물론 인덱스에 지정할 수있는 스토리지 매개 변수가 있습니다. 이제는 인덱스 문제보다 스토리지 매개 변수가 더 많기 때문에 다루지 않았습니다. 그리고 마지막으로, 분할 또는 비분 할 여부를 결정합니다. 여기에 잠시 떨어 뜨리겠습니다. 다른 스키마로갑니다. 이것은 스타 스키마이며 예를 들어이 기간 테이블은 차원 테이블입니다. 스타 스키마 디자인을 해본 적이 있다면 일반적으로이 데이터베이스와이 스타 스키마에서 시간에 대한 차원이 있으므로 기간은 시간 차원입니다. “재밌게 보일 것입니다.“이 모든 열을보십시오 – 정규화에 대해 들어 본 적이 있습니까?”데이터웨어 하우스 나 스타 스키마 디자인에있을 때 일반적으로 비 사람이 있습니다. 일반적인 사람이 "Gee, 이들은 잘 설계되지 않았습니다."라는 표를 가지고 있습니다. 그러나 이것이 데이터웨어 하우징 환경에서 수행하는 방식입니다.
자, 이 모든 열이 있기 때문에 어떤 일이 일어날 지 지켜보십시오. 모든 열에 대한 색인이 있습니다. 이제는 OLTP 환경에서 그럴 필요가 없습니다. 모든 작업이 느려질 것입니다. 데이터웨어 하우징 환경에서는 배치로드주기 중에 삭제합니다. 오버 헤드 나 인덱스없이로드하고 인덱스를 다시 만듭니다. 그리고 테이블을 분할 한 경우 테이블의 모든 버킷에 대한 인덱스를 삭제하지 않고 해당 배치로드주기 동안 데이터가 들어갈 버킷 또는 버킷에서 인덱스를 삭제할 수 있습니다. 그런 다음 해당 버킷의 인덱스 부분 만 다시 생성하십시오. 따라서 관리가 매우 쉽습니다. 그리고 제가 살펴보면 – "Holiday Flag"라는 열이 있는데 기본적으로 그렇습니다. 이것은 비트 맵 인덱스이며, 대부분의 경우 "음, 이해합니다"라고 말할 것입니다. 예 또는 아니요, Y 또는 N에는 의미가있는 값이 두 개뿐입니다. 비트 맵 인덱스에 대한 설명서를 읽을 때 항상 카디널리티가 낮은 것을 선택하라는 메시지가 표시되기 때문입니다.
이제 팩트 테이블 중 하나에 들어가서 여기에 명령이 있습니다. 그리고 이것은 나의 일일 주문입니다. 그리고 여러분은 지금 볼 것입니다. 다시 한 번 열이 몇 개 있고, 다시 몇 개 이상의 색인이있을 것입니다. 그리고 바로 여기에 범용 가격 코드라는 것이 있습니다. 이것은 소매점을위한 것이기 때문에 상점에서 무언가를 구입할 때 작은 바코드를 알고 있습니다. 이것이 보편적 인 가격 코드입니다. 현재 수백만 가지의 범용 가격 코드가 있습니다. 이제 물건을 팔고있는이 특정 회사의 경우, 범용 가격 코드는 170 만에서 2 백만 사이 였을 것입니다. 따라서 170 만 개의 고유 한 값이 높은 카디널리티처럼 들리기 때문에 이것이 비트 맵 인덱스가 아닐 것으로 예상됩니다. 그러나 실제로 데이터웨어 하우징 환경에서는 비트 맵이되기를 원합니다. 이제 그 이유를 설명하겠습니다. 이 범용 가격 코드에는 170 만 개의 고유 값이있을 수 있습니다.이 주문 테이블의 행 수는 수억에서 수십억 행에 있습니다. 내 인덱스는 테이블의 크기 또는 카디널리티와 비교할 때 카디널리티가 낮습니다. 그것은 카디널리티를 낮게 만듭니다. 비트 맵 인덱스는 여기에서 비트 맵을 선택하는 170 만 개의 고유 값으로 반 직관적이지만 유용합니다. 이제 비트 맵 조인 인덱스를 사용하고 싶다는 것을 알고 있다면 현재 제품에서 지원하지 않으므로 다음 릴리스에 추가 할 예정이지만 다른 대안이 될 것입니다. 스타 스키마에서 비트 맵 인덱스는 팩트 테이블에 있고 B- 트리의 한 인덱스는 팩트 테이블의 행을 가리킨 다음 해당 팩트에 대한 차원 테이블에있는 모든 행을 가리 킵니다. . 그리고 또 다른 옵션이 있습니다. 보시다시피, 저는 이제 테이블에서 나오고 싶습니다. 인덱스 아래에 동일한 정보가 있고 동일한 기본 작업을 수행 할 것임을 신속하게 보여 드리고자합니다.
자, 내가 이것을 제기 한 이유는 여기에 기본 키가 없다는 것을 알 수 있기 때문입니다. 기본 키는 키 제약 조건으로 수행되므로 실제로 제약 조건 정의에 포함됩니다. 이들은 제약 조건의 일부가 아닌 인덱스입니다. 이제 "잠깐만 요, 외래 키처럼 보일 수 있고 외래 키가 제약 조건입니다"라고 말할 수 있지만 외래 키와 대부분의 데이터베이스는 외래 키 열에 인덱스를 자동으로 만들지 않습니다. 좋습니다, 그리고 당신은 간다 – 나는 모두 같은 선택을 다시 얻었다. 압축되도록 변경하고 싶다면 그렇게 할 수 있습니다.
이제 압축은 B- 트리 인덱스에서만 작동합니다. B- 트리의 다양한 노드를 볼 때 일부 값을 압축 할 수 있습니다. 실제로 테이블 압축과 같은 압축이 아니며 비 리프 노드의 B- 트리에 저장된 내용을 압축 한 것입니다. 많은 공간을 절약하지는 않지만 차이를 만들 수 있습니다. 그리고 나는 거의 시간이 가까워지고 있음을 알았습니다. 그래서하고 싶은 것은 돌아가서 공유를 중단하고 싶습니다. 그리고 idera.com에서 14 일 동안 사용할 수있는 제품이 있습니다. 특히 여러 데이터베이스 플랫폼으로 작업하는 경우 매우 좋은 제품입니다. 2 ~ 3 개의 다른 데이터베이스로 작업하는 경우이 도구를 사용하면 훨씬 쉽게 생활 할 수 있습니다. 인덱스 디자인 및 선택에 도움이되는 도구가 있으며 DB Optimizer라는 도구가 있습니다. 나는 오늘 그것을 막을 수 없었습니다. 저에게 연락하려면 내 이메일 주소가 있습니다. 또는 개인 이메일로 연락 할 수 있으며 블로그, 웹 사이트 및 블로그, LinkedIn 프로필이 있습니다. 따라서 제품과 관련이 없더라도 데이터베이스에 대해 이야기하고 싶을 때 마음에 드는 괴짜이며 technobabble에 대해 개그 러워하는 것을 좋아합니다.
Eric Kavanagh : 좋습니다. Dez, Robin, 적어도 두 가지 질문이 있습니다. 여기 몇 분 남았습니다. 데즈, 어떻게 생각해?
Dez Blanchfield : 물어보아야 할 중요한 질문이 하나 있는데, 그것은 내 마음 뒤에 앉아있었습니다. 가장 열악한 시나리오는 무엇입니까? 나는 당신의 블로그를 읽고, 당신을 잘 따라 가고 있습니다 – 당신은 아마 거의 모든 곳에 살지 않은 소수의 사람들 중 한 사람 일 것입니다. 그리고 Dr. Robin Bloor는 제가 만난 두 번째 사람이라고 생각합니다 내 평생. 그러나, 당신은 아마 모든 미친 시나리오를 보았을 것입니다, 당신이 본 가장 미친 시나리오, 당신이 겪은 것, 그리고 대처할 수 없었던 인간처럼, 당신은 걸을 수있었습니다. 이 DBArtisan 전체로 Jedi 마인드 트릭을 수행합니까?
Bert Scalzo : 데이터베이스 설계에서 파일 레이아웃 설계에서 생각할 방식을 매우 많이 생각한 고객이있었습니다. 데이터베이스를 정규화 할 때 가장 먼저 시도하는 것은 제거하는 것입니다. 반복 그룹. 글쎄, 그들은 열을 가지고 있었고, 그것을 길게 만들거나 BLOB 또는 CLOB로 만들었습니다. 그리고 그 안에 값, 숫자 1, 세미콜론, 값 2, 세미콜론, 값 번호, 세미콜론을 넣고 수천 개의 값을 갖습니다 저기서 열을 검색해야했는데 "왜이게 너무 느리게 실행됩니까?"와 비슷합니다. 그래서 우리는 실제로 계획을 사용하여 그들이해야 할 일은 그 표를 정규화하는 것임을 보여주었습니다. 정규화는 일을 더 잘하는 학문적 운동이 아니라 해당 필드에 대한 쿼리를 원했기 때문에 색인을 생성 할 수 있기를 원하기 때문에 반복 그룹에서 색인을 생성 할 수 없거나 적어도 쉽지 않습니다. . 그리고 그것은 내가 본 것 중 최악의 것입니다.
Dez Blanchfield : 네, 얼마나 자주 겪는 지 흥미 롭습니다. 데이터베이스의 문제는 사람들이 과학이라는 사실을 잊어 버리는 것 같습니다. 그리고이 전체 공간에서 학위와 박사 학위를 받고 종이에 글을 쓰는 사람들이 있으며 TOAD 핸드북과 메모리의 다른 것들을 포함한 전체 책자를 썼습니다. 인용 부호가 인용 된 "빅 데이터"에 대한 추세 – 많은 사람들이 원한다면 데이터베이스 아키텍처와 데이터베이스 기술, 데이터베이스 과학의 기본을 잊어 버리고 있습니다. 기존 데이터베이스 플랫폼 및 기존 데이터베이스에서 벗어나 기존에 효과적으로 착수했다는 생각만으로 현장에서 무엇을보고 있습니까? 성능 조정 및 확장의 경우 일뿐입니다. 많은 사람들이 재 학습하고 그들이 그곳에 앉아 유레카 순간처럼“a-ha”순간을 경험 한 경험을 가지고 있습니까?이 빅 데이터는 실제로 일종의 큰 데이터베이스 일 뿐입니 까? 저것과 사람들이 당신에게 대답하고, "우리가 알고있는 것을 잊어 버렸고, 우리를 어두운 곳에서 데려 올 수 있습니까?"
Bert Scalzo : 아닙니다. 그리고 이것은 일종의 인정이 끔찍한 일이지만, 관계형 데이터베이스 벤더는 Kool-Aid도 마 셨습니다. 약 10 년 전, 우리는 구조화되지 않은 데이터를 관계형 데이터베이스에 배치하기 시작했습니다. 이는 일종의 이상한 일이었습니다. 관계형 데이터베이스는 이제 NoSQL 유형을 추가하고 있습니다. 물건. 사실, Oracle 12, CR2에서 – 아직 나오지 않았다는 것을 알고 있습니다. – 베타 버전을보고 있다면 베타 프로그램을 사용하는 경우 샤딩을 지원합니다. 이제 NoSQL 샤딩의 개념이 추가되지 않은 관계형 데이터베이스가 생겼습니다. 따라서“a-ha”순간은“a-ha”를 가고있는 관계 측면의 사람들에게는 더 많은 것 같습니다. 데이터베이스 관리자조차도 아무도 다시는 제대로하지 않을 것입니다. 가서 어두운면에 합류했습니다.
Dez Blanchfield : 맞습니다. 여러분이 이해한다면, 우리가 지금 빅 데이터 플랫폼이라고 부르는 것에 대해 많은 지저분한 데이터로의 전환을 말하는 것입니다. 그렇게 오래되지는 않았지만, 그들이 관계형 데이터베이스로 무엇을하고 있는지에 초점을 맞추고 있다는 것을 의미하지 않습니까?
Bert Scalzo : 아니요. 일반적으로 "큰 데이터 유형 요구"라고 할 필요가있는 경우 다른 데이터베이스 플랫폼으로 이동하여 관계형 방식으로, 데이터베이스 공급 업체는 이제 관계형 데이터베이스 내에서 동일한 비 관계형 기술을 제공하여 이러한 작업을 수행합니다. 좋은 예는 JSON 데이터 형식이나 데이터 자체에 포함 된 다른 복잡한 데이터 형식과 같이 구조화되지 않은 데이터가있는 경우 데이터베이스 공급 업체가이를 지원할뿐만 아니라 ACID를 제공한다는 것입니다. 비정형 데이터 준수. 관계형 데이터베이스는 새로운 기술과 기술을 받아들 였으므로 다시“a-ha”는“응용 프로그램 개발자 인 우리는 무언가를 배우지 않았으므로 다시 배워야합니다.”라고 말합니다., 우리는 지금 이렇게하고 있습니다. 기존의 관계형 데이터베이스에서 어떻게하면됩니까? 그리고이 데이터베이스 에서처럼 그렇게 할 수 있습니까?”그리고 점점 더 널리 퍼져 가고 있습니다. 그.
Dez Blanchfield : DBArtisan 도구를위한이 분야의 전통적인 용의자는 누구입니까? 최근에 작성한 것에 대해 약간의 숙제를했으며 메모리에서 무언가를 썼을 때 오라클 세계의 극한 데이터베이스 성능에 대한 블로그 중 하나라고 생각합니다. 나는 그것이 언제 였는지 기억할 수 없다. 나는 그것이 올해 기억력에서 왔거나 작년 말에 당신이 이것을 쓴 것이라고 생각한다. 그리고 오늘날 우리가 이야기하고있는 주제의 유형에 대해 사람들이 매우 큰 규모의 데이터베이스 환경으로 가서 당신이 무엇을 얻는 지 찾아 볼 것입니다. DBArtisan을 사용하고 잘 활용하고있는 사람을보고있는 일반적인 용의자는 누구입니까?
버트 스 칼조 (Bert Scalzo) : 사실, 많은 고객이 있습니다. 사실 저는 오늘날 매우 큰 정부 기관과 계약을 맺었습니다. 사람들은 실제로 소프트웨어 사본을 1, 000 개 가까이했을 것입니다. 사람들이 원하는 것에 집중할 수 있기 때문입니다. 하는 방법이 아니라 모든 사람이 무언가를하는 방법을 알고 있어야하지만 생산성은 "무엇을"하고 있는지 잘 알고 있습니다. 회사에서 업무 수행을 요구하면 그것이 전부 관심사입니다. 업무가 언제 완료되었다는 확인 표시를 언제 받았습니까? 거기에 도달하기 위해 어떤 기술이나 어떤 테크노 밥을 사용하지 않았습니다. 따라서 우리 도구를 사용하면 무엇에 초점을 맞추고 생산성을 높일 수 있으며, 이것이 실제로 큰 이점입니다. 앞에서 말했듯이 일부 데이터베이스는 데이터베이스 플랫폼 전용 도구를 제공합니다. 12 개의 데이터베이스 플랫폼에 제공합니다. 동일한 워크 플로, 동일한 그래픽 사용자 인터페이스, 동일한 탐색 기능이 있습니다. 사용자에게 권한을 부여하는 방법이나 테이블을 만들거나 데이터베이스에서 인덱스를 만드는 방법을 알고 있다면 모양과 느낌이 같고 워크 플로가 동일하기 때문에 열두 번에 할 수 있습니다. 그것은 우리 고객에게 큰 가치가 있습니다.
데즈 블란 치 필드 : 예, 사람들은 인적 자원으로 많은 돈을 벌고 싶어합니다. 그리고 Oracle, Ingres 및 DB2에 개별 전문가를 둔 시대는 모두 끝났습니다. 사람들은 모든 거래의 잭이 될 것으로 예상 되므로이 일이 절대적으로 생명을 구했다고 생각합니다.
닥터 로빈 블로어에게 건네주기 전에 마지막 한가지 만. 14 일 동안 무료로 다운로드 할 수 있다고 언급했습니다. 어떻게해야합니까? 앞으로 계속해서 Bloor 기술 연구소에 넣고이 작업을 진행하겠습니다. 직접 손에 들고 – 오늘 전에는 그렇게 할 기회가 없었습니다. 14 일 간의 평가판을 언급했는데 컴퓨터의 VM에서 실행 중이라고 말했는데 랩탑이라고 가정합니다. Robin에게 질문을 보내기 직전에 14 일 평가판을 사용하는 사람을위한 엔트리 레벨 설정은 무엇입니까?
Bert Scalzo : 모든 Windows 환경, 즉 CPU 1 개와 메모리 4 기가있는 Windows 7 가상 머신. 우리는 정말 뚱뚱하거나 비싼 도구가 아닙니다. 이제 동일한 Windows에서 동일한 VM에서 데이터베이스 서버를 실행하려면 더 추가해야하지만 데이터베이스 서버 또는 별도의 VM에서 데이터베이스를 실행하는 경우 VM을로드하고 우리 제품은 매우 가볍습니다 : 하나의 CPU, 4 개의 메모리, 거의 모든 Windows 버전 – 우리는 32 비트 및 64 비트 설치를 모두 지원합니다. 그러나 데이터베이스 공급 업체의 클라이언트를 설치해야합니다. 따라서 Oracle에 연결하려면 데이터베이스와 통신하기 위해 Oracle이 필요로하는 SQL net 클라이언트를 설치해야합니다.
Dez Blanchfield : 아주 간단하게 들립니다. 나는이 도구가 생명을 구할 것이라는 인식 외에 사람들이 빼앗길 바라고있는 것 이상으로 이것의 한 가지는 그들이 가서 다운로드해서 가지고 놀아야한다는 것입니다. 14 일 무료 평가판을 제공한다고 가정 해 보겠습니다. 추가 데이터베이스를 설치하지 않고도 현재 랩톱에서 실행할 수 있습니다. 이미 데이터베이스 관리를 수행하는 경우 이미 데이터베이스를 사용하고 있으므로 로컬 VM에서 실행되는지 또는 로컬 VM에서 실행되는지에 관계없이 모든 도구가 준비되어 있기 때문입니다. 로컬 데스크톱의 경우 설치가 쉽고 게임을 즐기는 것처럼 들립니다. 그래서 저는 사람들이 그렇게 할 것을 적극 권장합니다.
로빈, 질문을 받았을 거라고 확신하고 에릭, 아마 청중으로부터 몇 가지를 얻었을 것 같아, 로빈
Robin Bloor : 예, 알겠습니다. 할 말이 있습니다. 저는이 영역이 항상 매력적이기 때문에 이빨을 잘라 냈습니다. 그러나 진실은 아마 1998 년, 1999 년 이래로 오라클이 실제로 할 수있는 것을 표적으로 삼았다는 것입니다. 그리고 Sybase와 Microsoft SQL Server를 알고있었습니다. 둘 다 Oracle이 할 수있는 것과 비교할 때 매우 간단합니다. 샤딩에 대해 이야기하기 시작했을 때, 나는 내 입을 가렸다. 오라클은 전에 이것을했습니다. 오라클은 어느 시점에 도입되어 객체 관계형 아이디어에 신경을 썼기 때문에 오라클에서 일종의 객체 표기법 및 객체 스토리지를 생성하는 기능을 도입했으며 엔지니어 중 한 명에게 그들이 소개한지 몇 년 후 나는 그것을 얼마나 많은 사람들이 사용했는지 물었고, 그는 두 명의 고객이 그것을 시도했다고 생각했다. 그리고 그들이 NoSQL 일을 시도하고 시도하기 시작하면 같은 일이 일어날 것이라고 생각합니다. 알다시피, 나는 그것이 실수라고 생각합니다. 저는 당신의 생각에 관심이 있습니다. 확실히, 그들은 – 쿨 에이드를 마신다. 그들은 Cassandra와 같은 큰 NoSQL 데이터베이스와 비슷한 주장을 할 수 있다고 생각하지만, 당신에게 이해가 되십니까?
Bert Scalzo : 아니요, 머리에 바로 못을 박았습니다. 나에게 관계형 일을하려고한다면 Oracle, SQL Server, DB2 또는 Postgres와 같은 관계형 벤더를 선택 하겠지만 관계가없는 일을하려고한다면 빅 데이터 공간 또는 NoSQL 공간에서 올바른 작업에 적합한 도구를 선택하겠습니다. 그리고 나는 그것이 내 관계형 데이터베이스 공급 업체에 먼저 갈 것이라고 생각하지 않습니다. 그런 다음 다른 주름을 추가합니다. 즉, 클라우드에서 사용할 수있는 것은 무엇입니까? 많은 사람들이 데이터베이스를 전제로하고 싶어합니다. 그런 다음 클라우드 제공 업체를보고“좋아요, 어떤 서비스 제공 업체, 어떤 요구 사항에 맞는 데이터베이스를 제공합니까? 그리고 그 데이터베이스를 사용하는 비율과 요금은 솔직합니다. 시간당 또는 하루에 클라우드에서 그리고 기가 바이트 또는 테라 바이트 당?”그리고 여러분이 찾을 수있는 것은 아마도 몽고 나 카산드라와 같은 비교적 새로운 데이터베이스 중 하나 일 것입니다. 아마도 그 요금이 더 저렴할 것입니다. 따라서 멀티 페타 바이트 유형의 빅 데이터를한다면, 비용 측면에서 볼 때 클라우드에서 NoSQL 데이터베이스가 가장 비용 효율적인 방법이기 때문에 클라우드의 NoSQL 데이터베이스를 고려해야합니다.
로빈 블로어 : 그렇습니다. 내 경험에 관계된 관계형 데이터베이스에 관한 것 – 상처를 입을 정도로 충분히 길다. 확실히 – 적용하기 시작하면 관계형이 실제로 무엇인지 이해한다는 많은 상식이있다. 즉, 한 고객과 한 번 상담을 한 후 기억으로 나를 방으로 안내하고 일종의 엔터티 다이어그램을 작성하고 회사의 기본 시스템과 같은 모델 인 세 번째 일반 양식을 만들었습니다. 약 이백 사십 대의 테이블이 있었으며 그들은 말했습니다.“음, 어떻게 생각하세요? 우리는 이것에 대한 데이터베이스를 구축 할 것입니다.”라고 말했습니다.“그것에 대해 어떻게 생각하십니까?”나는 말했습니다.“나는 그것이 작동 할 것이라고 생각하지 않습니다.”그리고 그들이 끝났기 때문에 정확히 맞습니다. 11 방향 조인 내에 특정 구조를 작성하기 위해 그리고 그것은 관계에 대해 이해해야 할 것입니다. 디자인이 얼마나 나쁜지에 관심이 있습니다. DBArtisan에는 아무런 문제가 없습니다. 매우 현명한 일을하고 있으며 실제로 여러 플랫폼에 표시 할 수 있다는 사실은 훌륭합니다.하지만 디자인이 문제가되는 곳에서 얼마나 많이 만나게됩니까? 사람들이 눈송이에 얽매이지 않고 별 모양으로 내려 가면 온갖 종류의 상심을 해결할 수있는 곳이 어디죠?
버트 스 칼조 (Bert Scalzo) : 음, 뻔뻔 스럽거나 거만하게 들리고 싶지는 않지만 더 자주 말하고 싶습니다. 분명히 내가 거기에 관여하는 대부분의 데이터베이스에는 문제가 있습니다. 데이터베이스 최적화 도구와 같은 도구는 이러한 문제를 해결하는 데 도움이 될 수 있지만 정말 재미있는 점은 많은 문제가 반복해서 동일한 단순한 문제라는 것입니다. 나는 며칠 전 11 자 조인 쿼리를 한 고객과 일하고 있었는데, "좋아요, 왜 with 절을 사용하지 않았습니까?"와 같았습니다. "글쎄요. 그리고 그것이 무엇인지 모릅니다.”그리고 나는 말했습니다.“그리고 당신의 하위 선택을 당신의 상관 관계와 비 상호 관계에서 살펴보십시오. 나는 테이블 바깥 쪽을 참조한다.”라고 말했다.“이것은 올바른 레벨로 옮기고, 필요한 것보다 더 깊이 삽입하지 않으면 옵티 마이저를 혼동하게 될 것입니다.” 약 2 시간 동안 실행되는 것을 가져와 10 분으로 줄였습니다.이 경우에는 작성된 SQL을 개선하는 것 외에는 아무것도하지 않았습니다. 문제는 비 학술적 환경에서 프로그래밍을 배우는 많은 대학과 많은 사람들이 기록 시간 프로세스 또는 행 지향 프로세스로 배우고 관계는 본질적으로 지향되는 세트이므로 좋은 SQL을 작성하려면 세트로 생각해야합니다.
로빈 블로어 : 예, 그렇습니다. 그리고 여러분은 이해해야합니다. 사람들은 이와 같은 것들의 ABC를 알아야합니다. 중요하지 않습니다. 잘 디자인되고 모델링 된 데이터베이스라도 조인에 시간이 걸리고 정렬에 시간이 걸린다는 것을 모르면 합리적인 일을 할 수 없을 것입니다. 그들은 세상 사람들이 빨리 갈 수있는 방법을 찾지 못했기 때문에 그렇게합니다. 그들은 데이터를 구성하는 방법을 찾았으므로 그렇지 않은 것보다 빠르게 진행됩니다. NoSQL 데이터베이스에 대해 말해야 할 열정은 단순히 조인을 피하는 것입니다. NoSQL 데이터베이스에 조인하면 크게 빨라지기 때문에 동일한 데이터 분산으로 데이터베이스를 구축하기 시작합니다. 당신은 생각하지 않습니까?
버트 스 칼조 : 아, 물론입니다. 관계형 데이터베이스 이전과 Ingres가 Relational Technology Institute 인 RTI 였을 때, SQL이 없었기 때문에 SQL 이전에 관계형 언어가 있었기 때문에 나는 웃어야합니다. 저는 당시 Ingres에서 Quel이라고 불렀습니다. 그래서 당신은 네트워크와 같은 오래된 데이터베이스 패러다임과 더 높은 그래픽 또는 계층 적에서 얻었고, 당신은 수십 년 후에 관계형 패러다임을 겪었고 지금은 우리가 거의 다시 계층 적이라고 생각합니다. 마치 우리가 되 돌린 것과 거의 같습니다.
로빈 블로어 : 그렇습니다. 에릭에게 좀 더 손을 대면 시간이 너무 많이 걸리지 만 청중으로부터 질문이 있으신가요? 에릭?
Eric Kavanagh : 우리는 몇 가지를 가지고 있습니다. 우리는 여기에 조금 오래 가고 있지만 나는 당신에게 몇 가지를 던져 것입니다. 보이지 않는 인덱스에 대해 몇 가지 질문이있었습니다. 한 가지 질문은 "누군가가 도구를보기 위해 도구를 사용해야합니까?"였습니다.
Bert Scalzo : 좋은 일입니다.
에릭 카바나 흐 : 궁금한 질문도 있습니다.
Bert Scalzo : 아니요, 툴이 필요하지 않습니다. 이것이 보이지 않는 인덱스 인 Oracle 기능입니다. 기본적으로 데이터 딕셔너리에서 Oracle은“Optimizer는이 인덱스를 무시합니다. 여기에 있지만 SQL 명령의 옵티 마이저 힌트에있는 힌트를 통해 실제로 지시를받지 않는 한이 명령을 사용하지 마십시오.”따라서 툴을 사용할 필요가 없으며 모든 측면에서 평범한 오래된 인덱스입니다. 어떤 도구에서나 볼 수 있습니다. 옵티마이 저는 "일반적인 쿼리 처리에서는 무시할 것입니다."라고 말합니다. 사용하려는 경우 직접 지정해야합니다. 프로덕션에서 인덱스를 작성하고 싶지만 보고서 나 보고서를 중단 할 위험은 없지만 테스트하고 싶었던 시나리오에 매우 유용합니다. 그것이 가장 유용한 것입니다.
에릭 카바나 흐 : 좋은 점이 있고 또 다른 좋은 질문이 있습니다. “이 새로운 메모리 내 데이터베이스는 어떻습니까? 인 메모리 데이터베이스 기술은 인덱싱과 관련하여 게임을 어떻게 변화 시키는가?”
버트 스 칼조 (Bert Scalzo) : 소년, 잘 우리 – 이제는 좋았습니다. 누군가 그 질문을해서 기쁘다. 우리는 30 분 더 가야 할 것이다. 아니요, 인 메모리는 데이터베이스 공급 업체에 따라 다릅니다. 일반적으로 저는 오라클이 만든 기술이 놀랍기 때문에 오라클이하는 일에 대해 칭찬 만합니다. 그러나 커버를 뜯어 내고 오라클의 오라클 내 메모리가 무엇인지 살펴보면 실제로 데이터베이스는 행 저장소를 디스크에 보관하고 열 저장소를 메모리에로드하고 전체 테이블을 보유하기에 메모리가 충분하지 않으면 부분으로 되돌아갑니다. 메모리에, 행 저장소를 수행하는 데 적합하지 않으므로 실제로 테이블에 대해 선택하고 테이블의 절반에 대해 테이블에서 전통적인 행을 타격하는 인덱싱을 사용하고 나머지 절반은 실제로는 나가고 메모리 내 검색에서 모든 것을 포착하는 선택이므로 SQL Server가 Hekaton 기술, 구현 및 SQL 2014로 구현하는 방식이 다릅니다. SQL 2016에서는 일부 측면에서 더 실제 버전의 인 메모리가 있지만 각 구현에는 장단점이 있지만 각기 다른 내용을 살펴보고 깨달아야합니다. “이 테이블의 메모리는 – 모든 인덱스를 작성하려고합니다.”라고 말한 고객이 있었기 때문에“테이블은 서버에있는 메모리보다 큽니다. 어느 시점에서 쿼리의 일부가 디스크에 도달해야합니다.”
Eric Kavanagh : 좋은 설명입니다. 좋은 것입니다. 글쎄, 여러분, 우리는 올해 남은 시간 동안이 사람들과 웹 캐스트를 몇 개 더 할 예정입니다. Bert가 자신의 것을 알고 있다는 사실을 알고 있기 때문에 프레젠테이션에 관한 소식을들을 때마다 다시 오십시오. 전문가들과 이야기하는 것은 항상 재미 있습니다. 나중에 볼 수 있도록 모든 웹 캐스트를 보관합니다. 여기 Bert의 연락처 정보가 다시 있습니다. 다운로드를 위해 해당 링크를 찾아 전자 메일로 보내려고하지만 항상 귀하의 이메일을 보낼 수는 있습니다., 더 많은 웹 캐스트가 준비되어 있습니다. 내년에 우리는 지금 에드 칼을하고 있습니다. 여러분, 내년에 정말로 듣고 싶은 주제가 있다면, 부끄러워하지 마십시오 : 조심하십시오, 다음에 우리는 당신에게 이야기 할 것입니다. 안녕.
Techopedia 컨텐츠 파트너
Techopedia 직원은 Bloor Group과 제휴하여 오른쪽 옵션을 사용하여 연락 할 수 있습니다. 업계 파트너와 협력하는 방법에 대한 자세한 내용을 보려면 여기를 클릭하십시오.- 프로필
- 웹 사이트
