미래로 : 인 메모리 컴퓨팅을위한 온 램프

작성자 : Techopedia Staff, 2017 년 1 월 25 일

테이크 아웃 : 호스트 Eric Kavanagh는 인 메모리 컴퓨팅 및 SAP HANA에 대해 Dr. Robin Bloor, Dez Blanchfield 및 IDERA의 Bill Ellis와 논의합니다.

현재 로그인하지 않았습니다. 비디오를 보려면 로그인 또는 가입하십시오.

에릭 카바나 흐 : 좋아, 신사 숙녀 여러분. 다시 한번 환영합니다. 수요일과 지난 몇 년간 동부 표준시 기준으로 4시입니다. 이는 다시 한번 Hot Technologies의 시간입니다. 그렇습니다. 제 이름은 Eric Kavanagh입니다. 오늘 대화의 호스트가 되겠습니다.

그리고 여러분, 오늘 우리는 멋진 것들에 대해 이야기 할 것입니다. 우리는 인 메모리의 세계로 뛰어들 것입니다. 정확한 제목은“미래에 대한 것 : 인 메모리 컴퓨팅을위한 온 램프”입니다. 요즘은 모든 분노에 시달리고 있습니다. 회전하는 디스크에 의존하는 것보다 메모리가 훨씬 빠릅니다. 그러나 문제는 많은 소프트웨어를 다시 작성해야한다는 것입니다. 오늘날의 소프트웨어는 대부분 디스크를 염두에두고 작성되었으므로 실제로 애플리케이션의 아키텍처를 변경하기 때문입니다. 회전 디스크를 기다리도록 응용 프로그램을 설계하는 경우 인 메모리 기술의 모든 기능을 사용하는 것과는 다른 방식으로 작업을 수행하면됩니다.

당신의 진실에 대한 자리가 있습니다. Twitter, @eric_kavanagh에서 저를 때리십시오. 나는 항상 뒤를 따르고 누군가가 나를 언급 할 때마다 리트 윗을 시도합니다.

내가 말했듯이, 우리는 오늘 메모리 내, 특히 SAP HANA에 대해 이야기하고 있습니다. 작년에 여러분은 SAP 커뮤니티를 정말 잘 아는 데 보냈습니다. 매혹적인 환경입니다. SAP는 엄청나게 좋은 작업이기 때문에 해당 작업을 실행하고 최전선에서는 사람들을 싫어합니다. 그들이 정말 잘하는 것은 사업을하는 것입니다. 물론 기술도 뛰어나고 HANA에 많은 투자를했습니다. 사실, 아마도 6 ~ 7 년 전쯤에 우리는 실제로 미 공군을 위해 일을하고 있었으며 SAP에서 온 누군가가 와서 하나와 계획된 것. 그리고 SAP Labs 직원들은 메모리에 모든 것이 있기 때문에 전통적인 환경과 완전히 다른 아키텍처를 구축하는 방법을 이해하는 데 많은 시간과 노력을 기울였습니다. 그래서 그들은 기존의 방식과 달리 메모리 내에서 동일한 데이터에 대해 트랜잭션 및 분석을 수행하는 것에 대해 이야기하고 있습니다. 매우 다른 방식으로 발생합니다.

이것은 흥미로운 공간이며 우리는 실제로 다른 공급 업체 인 IDERA에서 그 모든 것들이 어떻게 작동 할 것인지, 그리고 온-램프가 솔직하게 무엇인지에 대해 조금 알아볼 것입니다. 여기 Bloor Group의 최고 분석가 인 Robin Bloor 박사의 의견을들을 수 있습니다. 데이터 과학자이자 IDERA의 친구 Bill Ellis 인 Dez Blanchfield. 그래서 그걸로 열쇠를 빼앗아 로빈 블로어 박사에게 건네 주겠습니다.

로빈 블로어 박사 : 네, 에릭이 말한 것처럼 SAP HANA가 처음 브리핑 한 시간은 몇 년 전입니다. 그러나 그것은 매우 흥미로웠다. 그 특별한 시간은 매우 흥미로웠다. 우리는 인 메모리 기술을 제공하는 하나 또는 두 개의 회사에갔습니다. 인 메모리가 올 것이라는 것은 분명했습니다. 그리고 SAP가 일어나서 갑자기 HANA를 시작하기 전까지는 그렇지 않았습니다. SAP가 그렇게하는 것을보고 충격을 받았습니다. 마치 다른 곳에서 나올 것으로 예상했기 때문에 충격이었습니다. 나는 그것이 마이크로 소프트 나 오라클, IBM 또는 그런 누군가가 될 것이라고 예상했다. SAP가 그렇게하고 있다는 생각은 정말 놀랍습니다. SAP가 전략적 공급 업체 중 하나이기 때문에 그랬어 야한다고 생각합니다. 업계에서 일어나는 모든 일은 그 중 하나에서 비롯된 것입니다.

어쨌든, 인 메모리에 대한 요점은, 우리는 실제로 메모리에 들어가 자마자 데이터를 메모리에 넣는 것이 아니라 메모리 계층이 시스템 레코드라는 생각 – 시스템 레코드를 메모리로 마이그레이션하자마자 디스크는 일종의 핸드 오프 매체가되기 시작하여 다른 것이됩니다. 그리고 나는 그것이 일어날 때 매우 흥미 로웠다고 생각했습니다. 디스크 회전이 끝났습니다. 회전 디스크는 곧 박물관에만 존재합니다. 얼마나 빠른지 확실하지 않지만, 기본적으로 솔리드 스테이트 디스크는 이제 무어의 법칙 곡선에 있습니다. 이제 전화하는 것처럼 녹이 녹는 것보다 이미 10 배 빠릅니다. 이는 디스크 사용 사례가 점점 줄어드는 것을 의미합니다.

그리고 흥미로운 사실 ​​인 전통적인 DBMS는 실제로 많은 회전 소프트웨어가 회전 디스크를 위해 만들어 졌기 때문에 회전 디스크라고 가정했습니다. 회전 디스크를 활용하여 데이터를 최대한 빨리 검색 할 수 있도록 모든 종류의 물리적 수준의 기능을 힘들게 프로그래밍했습니다. 그리고 그 모든 것이 씻겨 나가고 있습니다. 그냥 사라져요 그런 다음 분명히 큰 성공을 거두었습니다. 잘 모르겠습니다. 수익성이 높으며 결국에는 큰 데이터베이스, Oracle 및 Microsoft, SQL의 위치를 ​​차지하려는 인 메모리 데이터베이스를 열었습니다. 서버와 IBM의 DB2는 메모리 내 공간을 차지했으며 앞으로 나아갈 것을보고 매우 흥미로 웠습니다.

메모리 캐스케이드에 대해 이야기합시다. 언급 할 가치가 있습니다. 또한, 이것을 언급 한 이유, 제가 이것을 던진 이유는, 제가 여기 메모리에 관해 이야기 할 때, 제가 이야기하고있는 모든 레이어가 실제로 메모리에 있다는 것을 모두에게 알리는 것이 었습니다. 그러나 당신은 이것을 볼 때 갑자기 기억합니다. 이것은 계층 적 저장소이며, 단순한 메모리가 아닙니다. 따라서 계층 구조 저장소에 대해 오랫동안 오래 전에 배운 모든 것이 적용됩니다. 또한 모든 인 메모리 데이터베이스 가이 과정을 탐색해야한다는 것을 의미합니다. 일부는 RAM 자체에서 데이터베이스를 통과합니다. 그리고 점점 커지고 있으며 지금은 메가 바이트 단위로 측정됩니다. 그러나 메모리보다 100 배 빠른 L1 캐시, 메모리보다 30 배 빠른 L2 캐시 및 메모리보다 약 10 배 빠른 L3 캐시가 있습니다. 알다시피, 많은 기술이 있습니다. 상당한 양의 기술이 이러한 캐시를 일종의 스토리지 공간으로 사용하는 전략, 특히 데이터베이스 기술을 실행하는 방식으로 채택했습니다. 알다시피, 그것은 하나의 영향입니다.

그런 다음 3D XPoint와 IBM PCM이 등장했습니다. 그리고 거의 RAM 속도이며 기본적 으로이 두 공급 업체가 자랑하는 것입니다. 사용 사례가 다를 수 있습니다. 이에 대한 초기 실험은 아직 완료되지 않았습니다. 우리는 그것이 RAM 사용과 그 문제에 대한 인 메모리 데이터베이스 기술에 어떤 영향을 미칠지 모릅니다. 그러면 RAM과 SSD가 있습니다. 현재 RAM은 약 300 배 빠르지 만 물론 그 배수는 줄어들고 있습니다. 그리고 SSD 대 디스크는 내가 이해하면 약 10 배 빠릅니다. 이것이 바로 여러분이 처한 상황입니다. 계층 적 저장소입니다. 메모리에서 다른 방법으로 보는 것은 물론 완전히 다릅니다. 따라서 맨 위 다이어그램은 두 가지 응용 프로그램을 보여줍니다. 두 응용 프로그램은 모두 데이터베이스에 액세스하지만 녹이 슬 때 데이터에 액세스하는 것입니다. 그리고 종속 관계에 따라 네트워크를 통해 실제로 흐름을 만드는 방법은 ETL입니다. 즉, 데이터가 회전 녹에 들어간 다음 어디에서든 회전 녹에 빠지면서 회전 녹에 돌아가는 곳은 세 가지 움직임입니다. 메모리는 디스크 회전보다 수십만 배 더 빠를 수 있다는 점을 명심하십시오. 데이터를 가져 와서 메모리에 넣는 것만으로도 모든 것이 실제로는 다르다는 것을 알고 있습니다.

따라서, 화면의 현재 상황이 어떻게 될지 생각했을 수도 있습니다. 실제로 ETL은 실제로는 메모리의 데이터에서 데이터로 이동할 것이라고 생각했을 것입니다. 그러나 실제로는 그렇지 않을 수도 있습니다. 실제로 두 응용 프로그램이 실제로 동일한 메모리를 해제 할 수있는 상황이 여기에있을 수 있습니다. 확실히 인 메모리 데이터베이스는 잠금 기능과 그 밖의 모든 요소가 조정되어있는 한 해당 기능을 제공 할 수 있습니다. 따라서 이것은 단지 속도를 변경하는 것이 아니라 실제로 응용 프로그램 및 전체 데이터 흐름을 구성하는 방법을 변경합니다.

따라서 큰 영향을 미칩니다. 따라서 인 메모리는 파괴적입니까? 그리고 우리는 내가 한 말에서 그것을 얻어야합니다. 인 메모리 처리는 현재 가속기이지만 표준이 될 것입니다. 응용 프로그램 값에 따라 적용되므로 SAP는 실제로 메모리에있는 ERP 소프트웨어 버전을 제공한다는 것이 매우 흥미 롭습니다. 또한 대기 시간은 최대 3 배까지 향상 될 수 있으며 실제로는 수행 방식에 따라 가능할 수 있습니다. 따라서 인 메모리로 이동하면 속도가 크게 향상됩니다. 그리고 결론적으로 SAP HANA의 S / 4는 사람들이 여전히 출시되고 있다고 말하지만 작년에 출시 된 것은 SAP 고객 기반을 고려한 게임 체인저입니다. SAP ERP를 사용하는 회사는 10, 000 곳에 있으며 대부분은 대기업입니다. 따라서 ERP는 거의 항상 비즈니스가 운영하는 기본 응용 프로그램이기 때문에 메모리에 들어가고 기본을 사용하는 인센티브가 있다는 아이디어는 매우 큰 게임 체인저이며 매우 흥미로울 것입니다. 물론 모든 소리는 매우 좋지만 지능적으로 구성해야하며 잘 모니터링해야합니다. 들리는 것처럼 간단하지 않습니다.

내가 말했듯이, 나는이 사람이 누구에게 공을 전달할 것 같아? 오, 호주 사람 데즈 블랜치 필드

Dez Blanchfield : 아주 재밌어요. 항상 따라야 할 힘든 행동입니다, 로빈 블로어 박사 오늘 저를 주셔서 감사합니다. 큰 주제이지만 흥미 진진한 주제입니다. 그래서 현대 데이터 레이크와 엔터프라이즈 데이터웨어 하우스 및 작은 데이터 보석에 대해 생각할 때 종종 떠오르는 이미지를 선택했습니다. 여기 산과 파도로 둘러싸인 아름다운 호수가 있는데 파도가이 바위 위로 부서지고 있습니다. 이것은 요즘 큰 데이터 레이크 내에서 어떻게 보이는지를 정신적으로 시각화하는 방법입니다. 일괄 작업이 진행되는 물결과 실시간 분석이 데이터에서 발생하고 있습니다. 물리적 호수라고 생각할 때, 우리가 지금 구축하고있는 데이터웨어 하우스의 규모, 우리가이 주화를 만든 이유와 데이터 레이크는 매우 크고 깊이가 있으며 때로는 폭풍이 발생할 수 있다는 것입니다. 그리고 우리가 할 때, 당신은 항상 폭풍을 일으키는 것을 해결해야합니다.

따라서이 주제를 고려할 때, 메모리 내 컴퓨팅에 대한이 사이렌 호출은 실제로 매우 강력하고 정당한 것으로 보입니다. 그것은 많은 상업적 및 기술적 이익을 가져옵니다. 그것은 다른 날 두 시간 동안의 토론입니다. 그러나 인 메모리 컴퓨팅으로의 일반적인 전환은, 우선 우리가 어떻게 여기에 왔는지, 그리고 그것이 가능한지, 어떤 종류의 과제가 먼저 놓여질 수 있는지, 그리고인지해야 할 것이 무엇인지에 대한 토대를 설정하기 때문에 가능한 이유를 다루고 싶습니다. 데이터를 보유하고 디스크에서 메모리로, 메모리에서 그리고 메모리로 그리고 CPU로 페이징되고있는 기존의 오래된 회전 디스크에서 벗어나는 세상에서 이제는 전체 레이어 중 거의 하나만 제거하고 있습니다. 회전하는 디스크입니다. 아키텍처 초기에는 컴퓨팅 초기에 우리가 코어 메모리와 드럼 스토리지로 생각했던 메인 프레임이나 미드 레인지 세계에서 오랫동안 움직이지 않았다는 것을 기억하십시오.

Robin Bloor 박사가 말했듯이, 컴퓨터 아키텍처를 중심으로 데이터를 이동하는 데 사용한 접근 방식은 실제로 수십 년 동안 한동안 크게 바뀌지 않았습니다. 기술적으로 현대 컴퓨팅이 주변에 있다는 사실에 대해 생각한다면, 60 년 이상 동안 말장난을 용서한다면 60 년 이상을 알 수 있습니다. 상자를 그대로 선반에서 구입하십시오. 메인 프레임과 미드 레인지, 코어 메모리 및 드럼 스토리지 아키텍처, 특히 용감한 또는 슈퍼 컴퓨팅, 특히 크로스바 백플레인과 같은 Seymour Cray와 같은 메인 프레임 및 미드 레인지 관련 생각에서 벗어나 새로운 아키텍처로의 전환이 떠 올랐습니다. 일이되었습니다. 요즘에는 백플레인이나 마더 보드를 통해 데이터를 이동하는 경로가 하나뿐입니다. 그리고 인라인 메모리는 요즘 사람들이 DIMM과 SIMM을 말할 때 실제로 의미하는 바에 대해 생각하지 않습니다. 그러나 SIMM은 단일 인라인 메모리이고 DIMM은 듀얼 인라인 메모리이므로 그보다 더 복잡해졌습니다. 비디오 용 메모리, 일반 응용 프로그램 용 CPU, 내장형 CPU 용 메모리 유형이 수십 가지가 있습니다.

따라서 데이터가 저장되고 액세스되는 새로운 방식으로 이러한 큰 변화가있었습니다. 우리는 다른 세대 전체에서 동일한 변화를 겪을 것이지만 하드웨어 자체가 아니라 비즈니스 논리 및 데이터 논리 계층에서 하드웨어를 채택함에 따라 다른 패러다임 전환이 이루어지고 있습니다. .

그러나 우리가 여기에 어떻게 왔는지 간략하게 설명합니다. 하드웨어 기술이 향상되고 크게 향상되었습니다. 우리는 CPU를 갖지 않고 핵심 아이디어는 상당히 현대적인 개념이었습니다. 전화기에는 2 개 또는 4 개의 코어가 있고 컴퓨터에는 2 개 또는 4 개 또는 8 개의 코어가 있으며 데스크탑에는 8 개 및 12 개 이상이 있으며 서버 플랫폼에서도 16 개 및 32 개가 있습니다. . 그러나 실제로 코어가 CPU 내에서 기능이되었으며 32 비트에서 64 비트로 전환 한 것은 실제로 매우 현대적인 것입니다. 몇 가지 큰 일이 발생했습니다. 여러 코어에서 더 높은 클럭 속도를 얻었으므로 병렬로 작업을 수행 할 수 있으며 각 코어는 여러 스레드를 실행할 수 있습니다. 갑자기 우리는 같은 데이터에서 동시에 많은 것들을 실행할 수있었습니다. 64 비트 주소 간격으로 인해 최대 2 테라 바이트의 RAM이 생겼는데 이는 놀라운 개념이지만 지금은 중요한 일입니다. 이 다중 경로 백플레인 아키텍처 (마더 보드)는 한 번에 한 방향으로 만 수행 할 수 있습니다. 그리고 오늘날 크레이 컴퓨팅과 그 당시의 슈퍼 컴퓨터 디자인의 시대와 마찬가지로, 오늘날에는 데스크탑 컴퓨터와 일반형의 일반 데스크탑 등급 랙 마운트 PC에 있습니다. PC는 이제이 메인 프레임, 미드 레인지, 마이크로 데스크탑 시대를 거쳐 서버로 다시 전환했습니다.

그리고 그 수퍼 컴퓨터 수준의 디자인 인 수퍼 컴퓨터 능력의 많은 부분이 일반적인 상용 구성 요소로 밀려났습니다. 요즘에는 아주 싼 랙 마운트 PC를 가져 와서 수천 대가 아닌 수백 대씩 랙에 꽂아 리눅스처럼 오픈 소스 소프트웨어를 실행하고 SAP HANA와 같은 것을 배치한다는 아이디어를 알고 있습니다. 우리는 종종 당연하다고 생각합니다. 그러나 이것은 매우 흥미로운 일이며 복잡성도 있습니다.

소프트웨어, 특히 메모리 관리 및 데이터 파티셔닝이 향상되었습니다. 그에 대한 자세한 내용은 다루지 않겠지 만 지난 15 년 정도 또는 그 이하의 기간 동안 큰 변화를 보더라도 메모리 관리 방법, 특히 RAM의 데이터와 RAM에서 데이터가 분할되는 방식, 로빈 블로어 (Robin Bloor) 박사가 이전에 언급했거나 언급 한 것처럼, 대기 시간이 아닌 서로에게 영향을주지 않고 동시에 읽고 쓸 수 있습니다. 압축 및 암호화 온칩과 같은 매우 강력한 기능이 많이 있습니다. 암호화는 더욱 중요한 일이되고 있으며, 소프트웨어, RAM, CPU 공간에서 반드시 그렇게 할 필요는 없습니다. 이제는 실제로 칩에서 발생합니다. 그것은 일을 극적으로 가속화합니다. 그리고 분산 데이터 저장 및 처리, 다시 한 번 우리가 슈퍼 컴퓨터와 병렬 처리의 것으로 가정했던 것은 이제 SAP HANA, Hadoop and Spark 등의 공간에서 당연한 것으로 간주합니다.

따라서이 고성능 컴퓨팅의 핵심은 HPC 기능이 기업에 제공되었으며 이제 기업은 성능 향상 및 기술 공간, 기술 이점 및 상업적 이점에서 얻을 수있는 이점을 누리고 있습니다. 가치 실현 시간이 대폭 단축됩니다.

그러나 저는 레고에서 PC 케이스를 제작 한 신사에 대해 얼마 전에 읽은 이야기의 이미지를 사용합니다. 이러한 것들 중 일부에 대해 생각할 때 항상 염두에두기 때문입니다. 그리고 그것은, 그것이 당신이 그것을 짓기 시작할 때 좋은 생각 인 것 같습니다. 그리고 당신은 그것을 반쯤 밟아서 실제로 모든 레고 비트를 모아서 견고하고 견고하게 만드는 것은 실제로 까다 롭다는 것을 깨달았습니다. 마더 보드 등을 넣으면 개인용 컴퓨터의 케이스가 만들어집니다. 그리고 결국 당신은 모든 작은 비트가 제대로 붙어 있지 않다는 것을 알고 있으며, 어떤 작은 비트를 고집하여 단단하게 만들지에 대해 약간주의를 기울여야합니다. 그리고 그것은 매우 귀여운 생각이지만, 반쯤지나 가면 깨달았습니다.“흠, 아마도 300 달러짜리 PC 케이스를 사야했을 것입니다. 그러나 지금 끝내서 뭔가를 배울 것입니다.”

나에게는 이것이 매우 복잡한 플랫폼을 구축하는 것과 비슷한 점이 있습니다. 왜냐하면 플랫폼을 구축하고 라우터와 스위치, 서버 및 랙이있는 환경으로 끝나는 것이 좋기 때문입니다. 그리고 CPU와 RAM 및 운영 체제가 함께 클러스터되어 있습니다. 그리고 분산 인 메모리 프로세싱, 데이터 스토리지 및 데이터 관리를 위해 HANA와 같은 것을 배치했습니다. 그 위에 SAP 스택을 구축하고 데이터베이스 기능을 얻은 다음 데이터와 비즈니스 로직을로드하고 읽기 및 쓰기 및 쿼리 등을 적용하기 시작합니다. I / O를 유지하고 작업을 예약하고 워크로드 및 다중 테넌시 등을 관리해야합니다. 이 스택은 매우 복잡하고 빠르게 진행됩니다. 하나의 시스템에 있다면 복잡한 스택입니다. 16 대 또는 32 대의 기계를 곱하면 매우 사소하지 않습니다. 100 테라 바이트에서 페타 바이트 규모로 최대 수백 대의 머신을 곱하면 무서운 개념이며, 이것이 우리가 지금 다루고있는 현실입니다.

따라서 세상을 변화시키는 데 도움이되는 몇 가지 사항이 생겨 디스크 공간이 엄청나게 저렴 해졌습니다. 한때 당신은 기가 바이트의 하드 디스크에 380 ~ 4 억 달러를 소비했을 것입니다. 요즘은 기가 바이트의 상용 디스크 공간 당 1 ~ 2 센트 정도입니다. 그리고 RAM도 같은 일을했습니다. 그런데이 두 그래프에서이 두 개의 J- 곡선은 각각 10 년입니다. 다시 말해, 우리는 10 년, 20 년의 가격 인하 두 블록을보고 있습니다. 그러나 나는 오른쪽에있는 것이 점선이되어 세부 사항을 볼 수 없으므로 크기를 조정하여 두 개의 J- 커브로 파산했습니다. 20 년 전의 기가 바이트 RAM은 6 백 5 십만 달러 정도였습니다. 요즘 상용 하드웨어의 기가 바이트 RAM에 3-4 달러 이상을 지불하면 강 탈당합니다.

지난 20 년 동안 가격이 급격히 하락함에 따라 이제는 메가 바이트 수준뿐만 아니라 테라 바이트 수준에서 디스크 공간을 넘어 RAM으로 바로 이동할 수있게되었습니다. 그럼에도 불구하고, RAM은 기본적으로 일시적이라는 것이 었습니다. 즉, 짧은 기간 동안 지속되는 것을 의미합니다. 따라서 우리는 그 공간에 탄력성을 제공 할 수있는 방법을 찾아야했습니다.

그리고 여기서의 요점은 메모리 내 컴퓨팅이 희미한 마음을위한 것이 아니라는 것입니다. 이 대규모 인 메모리 데이터를 처리하고 처리하는 것은 흥미로운 과제입니다. 앞서 지적했듯이, 희미한 마음이 아닙니다. 따라서 대규모의 고밀도 인 메모리 컴퓨팅을 통해이 경험을 통해 얻은 한 가지 사실은 우리가 구축하는 복잡성이 여러 영역에서 위험을 초래한다는 것입니다.

그러나 모니터링 및 응답 관점에서 살펴 보겠습니다. 데이터를 생각하면 데이터는 디스크 공간에서 시작하여 디스크의 데이터베이스에 저장되고 메모리로 푸시됩니다. 일단 메모리에 있고 배포되고 사본이 있으면 많은 사본을 사용할 수 있으며, 변경 사항이 있으면 백플레인을 켜고 끄는 대신 메모리 수준에서 반영 할 수 있습니다. 서로 다른 두 가지 수준에서 메모리로 들어오고 나갑니다. 이제이 작업을 수행 할 수있는이 하이퍼 스케일 하드웨어 플랫폼이 완성되었습니다. 하이퍼 스케일링에 대해 이야기 할 때, 엄밀하게 조밀 한 수준, 매우 높은 밀도의 메모리, 매우 높은 밀도의 CPU 및 코어 및 스레드에서는 더 어렵습니다. 노드와 클러스터 사이를 이동할 경우 데이터가 어느 시점에서 네트워크를 통해 이동해야하기 때문에이를 지원하기 위해 매우 복잡한 네트워크 병리가 생겼습니다.

따라서 장치 결함 중복이 문제가되고 장치와 장치를 모니터링해야합니다. 우리는 해당 플랫폼에 탄력적 인 데이터 장애 중복성을 구축하고 모니터링해야합니다. 분산 데이터베이스 복원력이 내장되어 있어야 데이터베이스 플랫폼을 모니터링하고 그 안에 스택 할 수 있습니다. 분산 처리 스케줄링, 폴링 및 쿼리에 이르기까지 일부 프로세스에서 발생하는 상황, 쿼리가 수행하는 경로 및 쿼리가 구성 및 실행되는 방식을 모니터링해야합니다. 어떤 사람이“blah”에 대해 SELECT *를 수행했거나 실제로 백플레인의 아키텍처를 통해 전달되는 명목상의 최소량의 데이터를 얻을 수있는 매우 똑똑하고 체계적인 쿼리를 수행 했습니까? 멀티 테넌시 워크로드, 여러 사용자 및 동일하거나 여러 워크로드를 실행하는 여러 그룹과 일괄 작업 및 실시간 예약이 있습니다. 그리고 일괄 처리와 실시간 처리가 혼합되어 있습니다. 매시간, 매일, 매주 또는 매월 정기적으로 실행되는 항목도 있습니다. 누군가가 실시간으로보고 싶어하는 태블릿을 가지고 앉아있을 수 있습니다.

그리고 다시, 우리는 요점에 이르렀습니다. 이것들에서 발생하는 복잡성은 이제 도전이 아니라 매우 무섭습니다. 그리고 우리는 현실적으로 하나의 성능 문제, 그 자체로 하나의 성능 문제만으로 전체 생태계에 영향을 줄 수 있음을 확인했습니다. 그래서, 우리는 그 결과가 어디에 영향을 미치는지에 대한이 매우 재미있는 도전으로 끝납니다. 그리고 우리는 이러한 도전에 직면하고 있습니다. 우리는 물건을 실시간으로보고 무언가가“강타”하고 반응하는 것을보고 있습니까? 아니면 어떤 형태의 트렌드를 보았고 우리가 능동적으로 대처해야한다는 것을 깨달았습니까? 열쇠는 모두가 빠르고 싸고 쉬운 것을 원하기 때문입니다. 그러나 우리는이 시나리오들, 내가 언급하고 싶은 것, 그리고 내가 좋아하는 Donald Rumsfeld 수수께끼의 선로에 대해 생각합니다.-이 생각은 매우 복잡하고이 모든 시나리오에 적용됩니다. 즉, 우리는 알려진 것으로 알려져 있습니다. 우리는 설계하고 건축했으며 계획대로 작동합니다. 우리는 누가 언제, 어디서, 언제 주문을하고 있는지 알지 못한다는 사실을 알고 있습니다. 그리고 우리는 알려지지 않은 미지의 것을 가지고 있으며 그것들은 우리가 모니터링하고 점검해야 할 것들입니다. 우리 모두 알고 있듯이 현실은 측정 할 수없는 것을 관리 할 수 ​​없습니다.

따라서 CPU 스케줄링을 모니터링 할 수있는 올바른 도구와 기능을 갖추려면 대기 시간을 찾고 파이프 라인의 스케줄 큐에서 대기해야하는 이유를 찾으십시오. 메모리에서 무슨 일이 일어나고 있는지, 어떤 종류의 활용이 수행되고 있는지, 어떤 종류의 성능이 메모리에서 벗어나고 있습니까? 물건이 올바르게 파티셔닝되고, 분배되고 있습니까, 우리는 그것에 던져지는 워크로드에 대처하기 위해 사본을 보유하는 충분한 노드가 있습니까? 운영 체제 프로세스 외부에서 프로세스를 실행하면 어떻게됩니까? 작업 자체, 개별 앱 및이를 지원하는 데몬이 실행되고 있습니까? 프로세스 내부에서 일어나는 일, 특히 쿼리 구조화 및 이러한 쿼리는 어떻게 실행되고 컴파일됩니까? 그리고 그 프로세스들의 건강은 쌓여 있습니까? 다시, 다시 대기 시간으로 돌아가서, 올바르게 스케줄링되고, 대기해야합니까, 어디에서 대기하고 있습니까? 네트워크 읽기를 통해 최종 사용자에게 메모리 읽기, I / O, CPU, I / O를 기다리는 것입니다 ?

그리고 그 시점으로 돌아가서 바로 마무리하기 전에 방금 언급했습니다. 즉, 우리는 어떻게 문제 해결 및 대응 시간에 접근하고 있습니까? 가장 이상적인 시나리오 인 실시간으로보고 사물에 반응하고 있습니까? 그러나 헬프 데스크에 전화를 걸고 무언가 잘못되었다는 것을 알지 못하는 것보다 더 잘하는 것이 좋습니다. ? 아니면 우리는 적극적으로하고 있습니까? 다시 말해, 메모리가 부족하여 노드를 더 추가해야한다는 것을 알 수 있습니까? 트렌드 분석을하고 있습니까, 용량 계획을하고 있습니까? 그리고이 모든 것에서, 과거 실행 시간을 모니터링하고 용량 계획에 대해 생각하고 있습니까? 아니면 실시간으로보고 일정을 미리 예약하고로드 밸런싱을 수행하고 있습니까? 그리고 우리는 처음부터 실행되는 워크로드를 알고 있습니까? 클러스터에서 누가 무엇을하고 있는지, 왜 그런지 알고 있습니까?

인 메모리 컴퓨팅은 매우 강력하지만, 그 힘으로 장전 된 총과 같은 것 중 하나이며 라이브 탄약을 가지고 노는 것입니다. 조심하지 않으면 결국 발에 쏠 수 있습니다. 따라서 인 메모리 컴퓨팅의 힘은 분산되고 별개의 데이터 세트에서 훨씬 더 빠르게 많은 것을 실행할 수 있음을 의미합니다. 하지만 최종 사용자의 요구가 높아지고 있습니다. 그들은 그 힘에 익숙해지고 그것을 원합니다. 더 이상 작업을 실행하는 데 몇 주가 걸리고 보고서는 일반 용지로 나올 것으로 기대하지 않습니다. 그리고 그 아래에는 패치, 업데이트 및 업그레이드를 둘러싼 일상적인 유지 관리 기능이 있습니다. 그리고 인 메모리 컴퓨팅을 통한 24/7 처리, 데이터 관리, 전체 워크로드 관리에 대해 생각한다면 패치 및 업데이트 및 업그레이드 적용을 시작할 예정이라면 기술적으로 임시 플랫폼에서 인 메모리입니다. 거기에는 다른 모든 관리 및 모니터링 문제와 함께 제공됩니다. 오프라인 상태, 업그레이드 가능시기 및 온라인 상태로 전환 할 때 알아야 할 사항이 있습니다. 그리고 그것은 저의 마지막 요점으로 연결됩니다. 즉, 우리가이 시스템에서 점점 더 복잡 해짐에 따라 인간은 엄지 손가락을 빨고 귀를 더 이상 당기는 것만으로는 할 수있는 것이 아닙니다. 더 이상 종류의 직감이 없습니다. 컴퓨팅 및 데이터 관리에서 이러한 높은 수준의 성능을 관리하고 제공하려면 적절한 도구가 필요합니다.

그리고이를 염두에두고 IDERA에서 친구에게 인계하여 그들이 어떻게이 도전에 접근했는지 들어 보겠습니다.

빌 엘리스 : 대단히 감사합니다. 화면을 공유하고 있습니다. 따라서 2017 년에 제공되는이 기술을 제공하기 위해 모든 기술과 우리 앞에 온 모든 사람들을 고려하는 것은 정말 겸손합니다. 포괄적 인 에이전트없는 데이터베이스 모니터링 솔루션 인 기본적으로 데이터베이스 모니터링 솔루션 인 SAP HANA의 워크로드 분석에 대해 이야기 할 것입니다. 실시간으로 기록을 작성하여 과거에 발생한 상황을 확인할 수 있습니다. SAP S / 4 HANA는 더 빠르고 빠르며 저렴할 수있는 잠재력을 제공합니다. 나는 그것이 비싸지 않다고 말하는 것이 아니라, 덜 비싸다고 말하는 것입니다. 전통적으로 발생한 일은 주로 대규모 서버, 잠재적으로 SQL Server의 Oracle에서 실행되는 주요 프로덕션 인스턴스를 보유한 다음 해당 ETL 프로세스를 사용하고 여러 종류의 진실을 갖는 것이 었습니다. . 그리고 이러한 개별 환경 각각에 대해 하드웨어, 운영 체제, Oracle 라이센스 비용을 지불했기 때문에 비용이 매우 비쌉니다. 그리고 그 위에는 한 가지 버전의 진실을 다음 버전의 진실과 조화시켜야 할 사람들이 필요합니다. 따라서이 다중 버전 ETL 처리는 느리고 매우 번거로 웠습니다.

따라서 기본적으로 하나의 HANA 인스턴스 인 HANA는 다른 모든 인스턴스를 대체 할 수 있습니다. 따라서 여러 개의 하드웨어 대신 하나의 운영 체제 인 하나의 하드웨어 플랫폼이기 때문에 저렴합니다. 따라서 S / 4 HANA는 실제로 모든 것을 변경하며 기본적으로 다양한 향상 팩인 R / 2에서 R / 3으로 SAP의 진화를보고 있습니다. 이제 레거시 시스템은 2025 년까지 사용할 수 있으므로 실제로 마이그레이션해야 할 때까지 8 년이 걸립니다. ECC가 HANA에서 운영 될 것임을 알고 있기 때문에 우리는 사람들이 이것에 발을 내딛는 것을보고 있지만 실제로는이를 준비하고 기술을 이해해야합니다.

따라서 하나의 데이터베이스, ETL 프로세스 및 조정해야 할 사본이 없습니다. 다시 한 번, 더 빠르고, 더 좋고, 저렴합니다. HANA는 메모리에 있습니다. SAP는 소프트웨어를 제공하고 하드웨어를 제공합니다. 집계 테이블이 없습니다. 그들이 당신이 이것에 대해 생각할 때 제안하는 것들 중 하나는 당신이 이것에 들어가고 싶지 않다는 것입니다. 우리는 사용 가능한 가장 큰 서버를 구입할 것입니다. 이들은 SAP 환경의 크기를 사전에 적절한 크기로 제안하고 기본적으로 20 년 분량의 데이터를 마이그레이션하지 않는다고 말합니다. 아카이빙은 SAP 매장뿐만 아니라 IT 전반에서 활용률이 낮은 것으로 생각합니다. 그리고 다음으로 SAP는 실제로 SELECT *를 사용하지 않도록 네이티브 코드를 다시 작성하는 데 많은 시간을 소비했습니다. SELECT *는 테이블에서 모든 열을 반환하며 특히 열 데이터베이스에서 비쌉니다. 따라서 SAP HANA에게는 좋지 않습니다. 따라서 사용자 정의가 많고 보고서가 많은 상점의 경우 이는 찾고자하는 것이며 HANA로 모든 것을 마이그레이션 할 때 열 이름을 지정하려고합니다.

우리는 HANA가 만병 통치약이 아니라고 말하고 싶습니다. 모든 데이터베이스와 마찬가지로 모든 기술과 마찬가지로 데이터베이스를 모니터링해야하며 앞에서 언급했듯이 측정으로 초과 측정을 관리하려면 숫자가 필요합니다. 제가 IDERA 영역에서 이야기하는 것 중 하나는 모든 비즈니스 트랜잭션이 레코드 시스템과 상호 작용한다는 것입니다.이 경우에는 HANA가됩니다. 따라서 HANA는 최종 사용자 경험 인 SAP 트랜잭션의 성능을위한 기반이됩니다. 따라서 최고 속도로 계속 실행하는 것이 중요합니다. 단일 실패 지점이되고 사람들과 대화 할 때 이는 최종 사용자가있는 곳에서 발생할 수 있고 실시간 데이터를 사용하고있을 수 있으며 잠재적으로 그렇지 않은 임시 쿼리가있는 것입니다. 권리. 어쩌면 그들은 테이블을 조인하지 않고 외부 조인 (partisan product)을 만들었으며 기본적으로 많은 리소스를 소비하고 있습니다. 이제 HANA는이를 인식하고 해당 세션을 종료합니다. 그리고 우리 아키텍처의 중요한 부분은 역사에서 실제로 그것을 포착하여 과거에 일어난 일을보고 그 상황을 인식 할 수있게하는 것입니다.

SAP HANA의 워크로드 분석을 살펴 보겠습니다. 이것은 버전 1이므로 여행에 우리를 초대합니다. 이것은 IDERA의 제품입니다. 포괄적이지만 간단합니다. 트렌드와 실시간. 호스트 상태, 인스턴스 상태 대기 상태, SQL 쿼리, 메모리 소비자 및 서비스를 추적합니다. 그래서 이것은 GUI의 모습이며 웹에서 사용 가능하다는 것을 즉시 알 수 있습니다. 나는 실제로 내 시스템에서 실행중인이 솔루션을 열었습니다. 살펴보고 싶은 몇 가지 중요한 사항이 있습니다. 우리는 서로 다른 작업 공간으로 세분화되었습니다. 가장 중요한 것은 CPU 사용률 및 메모리 사용률에서 호스트 수준에서 일어나는 일입니다. 당신은 확실히 스와핑 또는 스 래싱 관점에 가고 싶지 않습니다. 그런 다음 기본적으로 응답 시간, 사용자, SQL 문, 즉 시스템 활동을 유발하는 경향에서 발생하는 추세에 대해 작업합니다.

IDERA를 사용하는 것 중 하나는 활동이있을 때까지 데이터베이스에서 아무 일도 일어나지 않는다는 것입니다. 그리고 해당 활동은 응용 프로그램에서 제공되는 SQL 문입니다. 따라서 근본 원인을 감지하려면 SQL 문을 측정하는 것이 절대적으로 중요합니다. 이제 호스트 수준에서 실제로 메모리를 살펴보고 시간이 지남에 따라 추적하며 호스트 CPU 사용률을 확인할 수 있습니다. 뒤로 물러 나면 COBSQL 문을 볼 수 있습니다. 이제 아키텍처 측면에서 보게 될 것 중 하나는이 정보가 HANA에 저장되어 있기 때문에 HANA에 무언가가 발생하면 기본적으로 정보를 캡처하는 것입니다. . 또한 명확한 가시성을 확보하기 위해 시스템에서 발생하는 모든 것을 캡처 할 수 있습니다. 그리고 우리가해야 할 것 중 하나는 가중 순서로 SQL 문을 제시한다는 것입니다. 따라서 실행 횟수를 고려하여 집계 된 리소스 소비입니다.

SQL 문은 언제 실행 되었습니까? 그리고 리소스 소비는 주로 실행 계획에 따라 결정되므로 지속적으로이를 활용할 수 있습니다. HANA는 메모리에 있습니다. 매우 평행합니다. 모든 테이블에 1 차 색인이 있으며 일부 상점은 특정 성능 문제를 해결하기 위해 2 차 색인을 작성하도록 선택합니다. 따라서 특정 SQL 문에 대한 실행 계획에서 어떤 일이 발생했는지 아는 것은 매우 가치가 있습니다. 또한 시간이 지남에 따라 차트로 표시된 서비스, 메모리 소비를 다시 한 번 살펴 보겠습니다. 아키텍처 : 따라서 웹 사이트에서 다운로드 할 수있는 독립형 솔루션이며 웹 기반 아키텍처입니다.

여러 사용자가 특정 인스턴스에 연결하도록 할 수 있습니다. SAP HANA의 로컬 인스턴스를 모니터링 할 수 있습니다. 그리고 우리는 저장소에 4 주간의 롤링 기록을 유지하며 자체 관리됩니다. 이것을 배포하는 것은 다소 간단합니다. Windows Server가 필요합니다. 다운로드해야합니다. 대부분의 Windows Server에는 기본 제공 .NET 프레임 워크가 있으며 라이센스와 함께 제공됩니다. Setup.exe로 구동되는 설치 마법사로 이동하면 실제로 화면과 라이센스 계약이 열리 며“Next (다음)”를 클릭하여이 개요를 간단히 설명하면됩니다. 설치되어 있습니까? 다음은 데이터베이스 속성이며 이것이 SAP HANA에 대한 연결이므로 HANA 인스턴스의 에이전트없는 모니터링입니다. 기본적으로 미리보기를 제공합니다. 기본적으로 통신하는 포트입니다. “Install”을 클릭하면 기본적으로 HANA가 시작되고 히스토리 작성이 시작됩니다. 따라서 약간의 사이징 차트 정보 만 있습니다. 최대 45 개의 HANA 인스턴스를 모니터링 할 수 있으며, 필요한만큼의 코어, 메모리, 디스크 공간 수를 결정하기 위해 슬라이딩 방식으로이 유형을 사용하려고합니다. 그리고 이것은 4 주간의 롤링 이력이 있다고 가정합니다.

요약하자면, 우리는 서버 상태, 인스턴스 상태, CPU / 메모리 사용률을보고 있습니다. 메모리 소비자, 활동 동인, 서비스는 무엇입니까? SQL 문은 매우 중요합니다. 실행 상태는 무엇입니까? 실행 계획이 언제 실행 되었는가 트렌드를 보여줄 수 있습니까? 이것은 당신에게 실시간으로 그리고 일어난 일의 역사를 줄 것입니다. 제가 언급 한 바와 같이, 우리의 역사는 HANA와 분리되어 있기 때문에 시간이 초과되어 HANA의 역사에서 사라진 것들을 포착 할 것입니다. 별도의 히스토리로 인해 시스템에서 실제 자원 소비를 볼 수 있습니다.

IDERA의 웹 사이트에서 언급했듯이 Products 아래에서 쉽게 찾을 수 있습니다. 당신이 이것을 시도하고 싶다면, 당신은 확실히 환영합니다. 귀하에게 정보를 제공하는 방법과 해당 웹 사이트에 대한 추가 정보가 있는지 확인하십시오. 따라서 관심있는 모든 당사자는 기꺼이 참여할 수 있습니다. 이제 IDERA가 제공하는 포트폴리오 제품에는 SAP ECC 트랜잭션 모니터도 있으며이를 Precise for SAP라고합니다. 포털을 사용하든 직접 ECC를 사용하든 관계없이 실제로는 클릭에서 디스크까지 최종 사용자 트랜잭션을 SQL 문까지 캡처하여 발생하는 상황을 보여줍니다.

이제 요약 화면 하나만 보여 드리겠습니다. 이 요약 화면에는 몇 가지 테이크 아웃이 있습니다. Y 축의 응답 시간, X 축의 시간 + 요일이며이 트랜잭션보기에서 클라이언트 시간, 대기열 시간, ABAP 코드 시간, 데이터베이스 시간을 보여줍니다. 우리는 최종 사용자 ID, T 코드를 캡처 할 수 있으며 트래버스 된 특정 트랜잭션을 통해 서버를 실제로 필터링하고 표시 할 수 있습니다. 따라서 많은 상점에서 VMware 환경의 프런트 엔드를 실행하므로 실제로 각 서버에서 발생하는 상황을 측정하고 매우 자세한 분석을 수행 할 수 있습니다. 따라서이 트랜잭션보기는 전체 SAP 환경을 통한 최종 사용자 트랜잭션을위한 것입니다. 또한 당사 웹 사이트의 제품 APM 도구에서이를 찾을 수 있으며 이것이 SAP 솔루션 일 것입니다. 이 설치는 조금 더 복잡하므로 HANA와 마찬가지로 다운로드하여 사용해 보는 것이 아닙니다. 이것은 우리가 당신을 위해 전반적인 거래를하고, 설계하고, 구현하기 위해 함께 노력할 것입니다.

따라서 포괄적이고 에이전트가없는 실시간 인 SAP HANA에 대한 세 번째 빠른 요약, 워크로드 분석은 기록을 제공합니다. 우리는 귀하의 사이트에 다운로드하여 사용해 볼 수있는 기능을 제공합니다.

그래서 저는 그 시간을 Eric, Dez, Dr. Bloor에게 다시 전달할 것입니다.

에릭 카바나 흐 : 네, 아마도 로빈, 당신에게서 질문이 있고, 로빈 이후 데즈?

로빈 블로어 박사 : 좋습니다. 내 말은, 내가 말하고자하는 첫 번째 것은 트랜잭션 뷰를 정말 좋아한다는 것입니다. 그것이 바로 그 상황에서 원하는 것이기 때문입니다. 저는 많은 시간을 보냈습니다. 지금은 오래 전부터 성능 모니터링을하고있었습니다. 그것은 일종의 일이었습니다. 당시에는 그래픽이 없었지만, 제가 특히하고 싶었던 일이었습니다. 어떤 식 으로든 문제가 발생하는 곳에 자신을 주입 할 수 있습니다.

내가 가진 첫 번째 질문은 대부분의 사람들이 S / 4를 어떤 방식 으로든 구현하고 있다는 것입니다. 특정 S / 4 구현에 관여 할 때, S / 4가 제대로 구현되었음을 알게되었거나 결국 고객이 재구성하기 원하는 것을 발견 했습니까? 내 말은, 그 모든 것이 어떻게 진행됩니까?

빌 엘리스 : 글쎄, 모든 상점은 조금 다릅니다. 사용 패턴이 다르고 보고서도 다릅니다. 임시보고 기능이있는 사이트의 경우 실제로는 시스템의 와일드 카드와 유사합니다. 따라서 중요한 것 중 하나는 측정을 시작하고 기준선이 무엇인지, 특정 사이트에 대해 정상적인 지, 사용 패턴에 따라 해당 사이트가 어디에 있는지, 시스템을 강조하는 것입니다. 그런 다음 거기에서 조정하십시오. 일반적으로 모니터링 최적화는 한 번만 수행되는 것이 아니라 실제로 최종 사용자 커뮤니티가 비즈니스를보다 효과적으로 제공 할 수 있도록 시스템을 개선하고 모니터링, 조정, 호닝하는 실제적인 방법입니다.

Robin Bloor 박사 : 좋습니다. 구현할 때 – 구현 크기에 따라 달라지기 때문에이 질문에 대답하기 어려운 질문이라는 것을 알고 있습니다. ? 다른 점이 있습니까? 아니면 방해하지 않습니까? 어떻게 작동합니까?

Bill Ellis : 예, 오버 헤드가 약 1 ~ 3 %라고 말하고 싶습니다. 많은 상점들이 잠재적으로 최적화 측면에서 다시 구매할 수 있기 때문에 많은 것을 기꺼이 희생합니다. 사용 패턴에 따라 다릅니다. 전체 환경을 수행하는 경우 모니터링되는 개별 기술에 따라 다릅니다. 따라서, 마일리지는 다양하지만, 우리가 이야기했듯이, 맹인을 달리는 것보다 무슨 일이 일어나고 있는지 아는 데 조금 더 쓰는 것이 좋습니다. 특히, 우리는 1 월에 있고 연말 처리를 시작하고 12 개월 분량의 데이터를 집계하고있을 것입니다. 성과를 거두고 규제 기관, 은행, 주주에게 보고서를 제공하는 것은 중요한 비즈니스 성과에 절대적으로 중요합니다.

로빈 블로어 박사 : 그렇습니다 . 전체 SAP 사이트와 관련이 있다고 생각하기 때문에 SAP 고객 기반 간의 S / 4 이동이 얼마나 큰가? 내 말은, 열광적 인 고객들이 눈에 띄는 것일까, 아니면 꾸준한 속임수인가? 당신은 그것을 어떻게 보십니까?

빌 엘리스 : 몇 년 전에는 발가락이라고 생각합니다. 저는 사람들이 무릎을 꿇고 있다고 말합니다. 앞으로 몇 년 동안 사람들이 HANA에 몰입 할 예정이라고 생각합니다. 모니터링, 전환, 고객의 대부분은 일종의 학습 곡선에 있다고 생각합니다. 그리고 우리는 당신이 언급 한 것처럼 눈사태가 아니라고 생각하지만, 우리는 HANA 로의 주요 전환의 중심에 있다고 생각합니다.

로빈 블로어 박사 : 좋아, 당신이 본 사이트의 관점에서, 그들은 다른 응용 프로그램에 HANA를 적용하거나, 어떤 식 으로든이를 만드는 데 완전히 소비되고 있습니까? 물건이 작동합니까? 거기 사진이 뭐야?

Bill Ellis : 예, 종종 사람들은 어떤 모듈 등에 따라 SAP를 다른 시스템과 통합하기 때문에 약간의 차이가 있습니다. 실제로 HANA에 다른 애플리케이션을 배포하는 사람들은 아직 없습니다. 확실히 할 수 있습니다. 따라서 SAP 인프라 주변 환경에 더 가깝습니다.

로빈 블로어 박사 : 데즈에게 건네주는 것이 좋을 것 같습니다 . 나는 당신의 시간을 비웃고 있습니다. 데즈?

Dez Blanchfield : 감사합니다. 아니, 다 괜찮아 테마를 설정하려는 두 가지 매우 빠른 것. SAP HANA는 몇 년 동안 외출 해 왔으며 사람들은 그것을 고려할 기회를 얻었습니다. 만약 당신이 우리에게 그것을 운영하는 사람들의 대략적인 추정치를 주어야한다면 –이 물건들을 운영하는 많은 사람들이 있기 때문에 – 당신이 알고있는 시장의 비율이 현재 사라 졌다고 생각하는 것은 전통적인 SAP 구현부터 HANA의 SAP까지? 50/50, 30/70을보고 있습니까? 시장의 어떤 종류의 비율이 지금 전환하고 움직 인 사람들에 대해보고 있고, 단지 물러서 고 개선 또는 개선 또는 변화를 기다리는 사람들 또는 사건이 무엇이든 기다리는 사람들에 대해보고 있습니까?

Bill Ellis : 예, 저는 실제로 제 관점에서 백분율을 20 % 정도로했을 것입니다. SAP는 전통적인 비즈니스 경향이 있습니다. 사람들은 매우 보수적 인 경향이 있으므로 사람들은 발을 끌 것입니다. 또한 SAP를 오랫동안 운영해 왔거나 최근에 SAP를 배포 한 SMB에 의존하고 있다고 생각합니다. 그리고 여러 가지 요인이 있지만 전반적으로 백분율이 50/50이라고 생각하지 않습니다. 나는 50 %가 최소한 손해를 입었고 HANA가 데이터 센터 어딘가에서 실행되고 있다고 말합니다.

Dez Blanchfield : 당신이 이전에 우리에게했던 흥미로운 테이크 아웃은 이것이 어떤 의미에서 볼 때 만족스럽고 시계가 물리적으로 말 그대로 전환 시간에 똑딱 거리고 있다는 것입니다. 그렇게하는 과정에서 사람들이 그것을 고려했다고 생각합니까? 이것이 플랫폼의 과도기적 전환이라는 점에 대한 일반적인 이해는 무엇입니까? 단순한 옵션이 아니라 기본이되고 있습니까?

그리고 SAP의 관점에서 볼 때, 성능면에서 경쟁 우위가 상당히 높기 때문에 그 방법을 추진하고 있다고 확신하지만, 그들은 플랫폼의 제어권을 세 번째가 아닌 파티 데이터베이스를 통해 이제 자체 플랫폼으로 가져 왔습니다. 회사가 실제로 그 메시지를 받았다고 생각하십니까? 당신은 사람들이 그것을 이해하고 있다고 생각하고 있습니까? 아니면 시장에서 여전히 불분명 한 것입니까?

Bill Ellis : SAP가 의사 소통하기를 부끄럽게 생각하지 않으며 SAPPHIRE를 방문한 사람들은 어디에서나 HANA를 보았습니다. 저는 사람들이 잘 알고 있다고 생각하지만, 인간의 본성은 그것이 무엇인지, 어떤 사람들은 발을 조금 끌고 있습니다.

Dez Blanchfield : 제가 그 질문을하는 이유를 생각하기 때문에 당신은 저를 용서해야 할 것이지만, 나는 동의합니다. 나는 그들이 의사 소통을하는 데 부끄러워하지 않았다고 생각합니다. 신호는 여러 가지 방법으로 사라 졌다고 생각합니다. 그리고 나는 당신에 동의합니다 – 나는 모두가 아직 뛰어 내렸다는 것을 모른다. 아시다시피, 전통적인 엔터프라이즈, 이것을 실행하는 매우 큰 엔터프라이즈는 여전히 여러 가지 방법으로 발을 끌지 않고 변화의 복잡성을 극복하려고합니다. 여러분의 툴과 오늘의 데모가 강조한 한 가지가 있다고 생각하기 때문에, 오늘 들어보고 조정하는 모든 사람들이 앉아서 반사적으로주의를 기울이기를 원합니다. 도구는 이제 그 과정이 간단합니다. “저는 수십 년 동안 알려진 기존의 RDBMS 관계형 데이터베이스 관리 시스템에서 완전히 새로운 컴퓨팅 패러다임으로 전환하는 방법을 생각하는 매우 긴장된 CIO와 그 팀이 있다고 생각합니다. 여전히 비교적 용감한 공간에서의 스토리지 관리?” 그러나 그것은 여러 가지면에서 알려지지 않았으며 다른 영역에서 그러한 변화를 일으킨 사람은 거의 없으며, 이미 메모리 내 컴퓨팅으로 이동 한 또 다른 비즈니스 섹션이없는 것과는 다릅니다. 그래서, 그것은 그들의 마음에 전부 또는 아무것도 움직이지 않습니다.

그래서, 제가 이것보다 더 많이 빼앗아 간 것 중 하나 – 잠시 후에 질문을 할 것입니다 – 지금, 두려움은 여러 가지 방법으로, 그리고 오늘 전에는 만약 내가 CIO 청취라면, “어떻게이 전환을하게 될까요? 관계형 데이터베이스 관리 플랫폼과 수년간의 DBA 경험과 동일한 기능을 현재 기술이없는 새로운 플랫폼에 어떻게 보장 할 수 있을까요?”그래서 내 질문은, 사람들은 도구가 현재 제공하는 도구와 함께 있으며 전환이 이전보다 무섭지 않다는 깊은 숨을 쉬고 안심할 수 있음을 이해했다고 생각하십니까? 이 도구를 사용할 수 있습니까? 사람들이 NVMe, 플래시 및 디스크의 구식 조합과 비교하여 메모리 내 컴퓨팅 및 메모리 내 스토리지로의 전환으로 인해 어려움을 겪고 있다는 것을 사람들이 이해했거나 여전히 그렇게 생각하고 있습니까?

Bill Ellis : 네, 의심 할 여지없이 이것을 그래픽으로 표시 할 수있는 많은 기술과 도구가 있습니다. 현재 진행 상황을 파악하고 최고의 리소스 소비자를 매우 쉽게 찾아 낼 수 있습니다. 즉, 일을 단순화하는 데 도움이되며 기술 직원이 실제로 잘 처리하는 데 도움이됩니다. 그들은 무슨 일이 일어나고 있는지 알 수 있고 모든 복잡성을 이해할 수있을 것입니다. 따라서 시장의 도구는 절대적으로 도움이되므로 SAP HANA에 대한 워크로드 분석을 제공합니다.

Dez Blanchfield : 예, 오늘 보여 드린 것의 가장 큰 장점 은 하드웨어 부분과 운영 체제 부분을 모니터링 할 때, 어떤 워크로드를 모니터링하는 것까지 말입니다. 한동안 거기에 있었다. 나를 위해, 특히 HANA의 마음에 드는 부분은 돋보기를 가져 와서 들여다 볼 수있는 기능을 가지고 있지 않았으며 쿼리에서 발생하는 작업으로 인해 도구가 수행하는 작업과 쿼리가 수행되는 방식을 바로 볼 수있는 능력이 없었습니다. 구조화되고 그 하중이있는 위치.

지금까지 살펴본 배치를 사용하면 전 세계 플랫폼에서이 공간에서 문자 그대로 가장 권위있는 사용자라는 점을 감안할 때 몇 가지 빠른 승리가 있습니다. 공유 할 수있는 일화 지식이 있습니까? 사람들이 IDERA 툴셋을 배포 한 유레카 순간, 아하 순간에 대해 우리는 플랫폼과 성능에 대해 알지 못하는 것을 발견했습니다. 사람들이 실제로 무엇을 가지고 있었는지 모르고 갑자기 사라진“화려한 사실을 알지 못했습니까?”라는 사람들이 방금 배포 한 장소에 대한 훌륭한 일화적인 사례를 보았습니까?

Bill Ellis : 예. 기본 도구의 큰 한계는 런 어웨이 쿼리가 취소되면 정보를 플러시하므로 기본적으로 히스토리가 없다는 것입니다. 런 어웨이 쿼리처럼 히스토리를 오프라인으로 저장하면 히스토리가 생겼으며, 무슨 일이 있었는지 알 수 있으며 실행 계획 등을 볼 수 있습니다. 따라서 최종 사용자 커뮤니티가 기본적으로 더 잘 작동하고 보고서를 더 잘 작성할 수 있도록 도와줍니다. 그래서 역사는 정말 좋은 것입니다. 제가 보여 주어야 할 것 중 하나는 최대 4 주까지 실시간으로 볼 수 있으며 관심있는 시간대를 쉽게 확대 한 다음 기본 운전 활동을 노출 할 수 있다는 것입니다. 가시성을 확보하는 것은 어떤 병목 현상이 발생했는지 아는 데 매우 도움이됩니다.

Dez Blanchfield : 일단 배포되면 멀티 유저라고 언급했는데, 에이전트가없고 효과적으로 여러 가지면에서 제로 터치라는 사실에 깊은 인상을 받았습니다. NOC 감시 핵심 인프라의 네트워크 운영 센터에서 모든 사람이 툴을 한 번에 배포하여 애플리케이션 및 개발 팀까지 클러스터를 지원하는 것이 정상입니까? 그것은 표준입니까, 한 번 배포하면 공유 할 것입니까, 아니면 사람들이 스택의 다른 부분을 보는 모델 인스턴스가있을 것으로 예상합니까? 그것은 어떻게 생겼습니까?

Bill Ellis : 기본 팀은 일반적으로 SAP에서 발생하는 기술의 토대가되는 기술에 큰 관심을 가지고 있습니다. 분명히 전체 환경을 지원할 여러 팀이 있습니다. HANA 작품은 그에 중점을 둡니다. 정보의 기본 소비자로 SAP 기본 팀을 기본값으로 설정하려고합니다.

Dez Blanchfield : 그렇습니다 . 그러나 개발 팀이 있거나 코드 수준이 아니라면 데이터 과학자 또는 분석가 팀이 데이터 세트에 대한 분석 작업을 수행하는 경우 특히 데이터 과학이 현재 조직 내부의 모든 것에 적용되고, 내가 틀렸다면 바로 고쳐야한다는 중대한 진전은 여러 가지면에서 하나이기 때문에 이것이 그들에게도 큰 관심을 가질 것으로 보입니다. 데이터웨어 하우스 환경에서 수행 할 수있는 심각한 작업 중 하나는 데이터 과학자에게 활력을 불어 넣어 임시 쿼리를 시작하는 것입니다. 상점들이 당신을 렁 거리는 곳에서 일어나고있는 이런 종류의 일에 대한 예를 들어 보았으며, “우리는 데이터 과학 팀을 던져 버렸습니다. 정말 아 ing습니다. 전통적인 운영 모니터링 및 관리?”

Bill Ellis : 글쎄요, 예, 약간의 전환을하여 성능을보고 QA 생산을 개발할 때 성능을 인식하고 있다는 사실을 알게 될 것입니다. 놀랍습니다. 절대적으로

Dez Blanchfield : 그 이후로, 내가 경험 한 많은 도구들 – 그리고 로빈이 동의 할 것이라고 확신합니다 – 만약 당신이 큰 RDBMS를 가지고 있다면 당신은 정말로 숙련되고 깊이있는 지식을 갖춘 숙련 된 DBA. SAP HANA와 함께 제공되는 일부 인프라 및 플랫폼 요구 사항은 현재 특정 하드웨어 등의 특정 배포판에서 내가 아는 한도 내에서 지원되기 때문에 SAP HANA와 함께 제공됩니다. 수십 년의 경험을 가진 사람들이 같지 않습니다. 그러나 내가보고있는 것은 이것이 반드시이 도구의 요구 사항은 아니라는 것입니다. 도구를 배포하고 상당히 새로운 얼굴에 도구를 제공하고 성능이 좋지 않은 것을 찾을 수있는 힘을 줄 수있는 것 같습니다. 이것으로 속도를 높이고 그것을 배포하여 가치를 얻는 데 꽤 짧은 학습 곡선이있는 경우입니까? 알다시피, 내 일반적인 의미는 가치를 즉시보기 위해 도구를 운전 한 20 년의 경험이 필요하지 않다는 것입니다. 그 경우에 동의하십니까?

Bill Ellis : 아, 그리고 지금까지는 배포의 성공이 SAP HANA 환경의 계획 및 설계에 달려 있다고 생각합니다. 그리고 의심 할 여지없이 많은 복잡성, 그리고 그 기반 위에 구축 된 많은 기술이 존재하지만, 그것은 일어나고있는 상황의 사용 패턴을 모니터링하는 것입니다. 따라서 더 복잡하지만 패키지 방식과 다소 단순화 된 방식입니다. 그것은 매우 가난합니다.

Dez Blanchfield : 네, Eric에게 돌아 가기 전에 몇 가지 질문이 있다는 것을 알고 있기 때문에, 특히 흥미로운 Q & A를 통해 얻은 질문에 대한 답을 듣고 싶습니다. 다른 사람을위한 전통적 여정 - 앞서 언급 한대로 다운로드하여 사용해 볼 수 있습니다. 오늘 또는 나중에 다시 연주 할 수있는 사람들의 의견을 듣고 자하는 사람들을 위해 그 점을 간단히 생각해 볼 수 있습니까? 사본을 손에 넣고 배포하여 구매하기 전에 자신의 환경에서 사용해 보는 빠른 2-3 단계는 무엇입니까? 그것은 어떻게 생겼습니까? 그 단계는 무엇입니까?

빌 엘리스 : 예. 따라서 IDERA.com에서 제품으로 이동하면 Workload Analysis for SAP HANA가 표시됩니다. 다운로드 페이지가 있습니다. 나는 그들이 당신에게 연락 정보를 요구하고 제품은 라이센스 키와 함께 포장되어 Setup.exe로 설치하고 롤링 할 수 있다고 생각합니다.

Dez Blanchfield : 웹 사이트로 가서 다운로드 할 수 있습니다. 얼마 전에 그것을보고 기억하고 어제 밤에 다시 확인, 당신은 당신의 팀에 누군가가, 당신을 통해 그것을 어디에서 메모리, 데모를 요청할 수 있습니까? 그러나 실제로 무료로 다운로드하여 자신의 시간에 로컬 환경에 배포 할 수 있습니까?

빌 엘리스 : 예.

Dez Blanchfield : 훌륭합니다. 글쎄, 그게 내가 생각하기에 아마도 사람들에게 개인적으로 조언해야 할 것은 웹 사이트에서 사본을 가져 와서 거기에 대한 좋은 내용이 많이 있다는 것을 알고 있기 때문에 웹 사이트에서 문서를 가져 오는 것입니다. 그리고 그것을 시도하십시오. 환경에 넣고 찾은 것을보십시오. IDERA 도구를 사용하여 SAP HANA 환경을 살펴보면 실제로 알지 못하는 것을 찾을 수 있습니다.

봐 주셔서 감사합니다. Robin과 I. Eric과의 Q & A에 대해 감사합니다. 일부 Q & A가 참석자로부터 나왔음을 알고 있으므로 다시 연락 드리겠습니다.

에릭 카바나 흐 : 예, 여기서 아주 빠른 것입니다. 따라서 참석자 중 한 명이 여기서 상황이 어떻게 바뀌는 지에 대해 이야기하는 것에 대해 정말 좋은 의견을 제시합니다. 과거에는 메모리가 질식되어 빈번한 페이징으로 인해 속도가 느려졌으며 현재 CPU는 너무 많은 인 메모리 데이터로 질식하고 있습니다. 네트워크 문제가 있습니다. 항상 움직이는 목표가 될 것입니다. 병목 현상이 발생하는 위치와주의를 집중해야하는 위치에서 요즘 궤적으로 무엇을보고 있습니까?

빌 엘리스 : 예. 측정하기 전에는 알기가 어렵습니다. SQL 문에 대한 것 중 하나는 자원 소비의 원동력이 될 것입니다. 따라서 많은 메모리 소비 또는 CPU 소비와 같은 환경에서 해당 리소스 소비의 원인을 파악할 수 있습니다. 자, 당신은 반드시 그것을 죽이고 싶지 않을 것입니다. 그러나 당신은 또한 그것을 죽이고 싶어합니다. 그리고 어떤 일이 일어나고 있는지, 얼마나 자주 발생하는지 등을 알고 싶습니다. 우리는 다른 상황에 대한 반응의 전체 세트 또는 요리 책을 다루는 측면에서 여전히 새롭습니다. 그리고 그것은 훌륭한 질문이며 시간이 말해 줄 것입니다. 시간이 지남에 따라 더 많은 정보를 얻을 수 있습니다.

에릭 카바나 흐 : 그게 다야. 글쎄, 너희들은 매우 흥미로운 공간에 있습니다. 콘텐츠 호출에서 제안한대로 SAP가 전환을위한 긴 대기 시간을 제공했음을 알고 있기 때문에 앞으로 몇 달과 몇 년 동안 많은 활동을 보게 될 것입니다. 하나에. 그러나 그럼에도 불구하고 그 경사로에는 결말이 있으며 어떤 시점에서 사람들은 심각한 결정을 내려야 할 것이므로 더 빠를수록 좋습니다.

빌 엘리스 : 물론입니다.

Eric Kavanagh : 좋습니다. Hot Technologies에서 또 다른 시간을 보냈습니다. insideanalysis.com, techopedia.com에서 온라인으로 정보를 찾을 수 있습니다. 과거 웹 캐스트의 모든 아카이브 목록을 포함하여 많은 흥미로운 정보를 얻으려면 해당 사이트에 집중하십시오. 하지만 여러분, IDERA의 친구들, 로빈, 물론 데즈에게 감사합니다. 그리고 다음 주에 catch겠습니다. 시간과 관심에 다시 한번 감사드립니다. 조심해 안녕.