>> [음악 재생]
릭 리한 (Houlihan) : 좋아.
안녕하세요, 여러분.
내 이름은 릭 리한 (Houlihan)입니다.
나는 수석 교장 해요 AWS에서 솔루션 설계자.
내가 NoSQL에에 초점 DynamoDB의 기술.
나는 얘기를 오늘 여기있어 당신이 이들에 대해 조금.
>> 내 배경은 주로 데이터 층.
나는 반 내 개발을 보냈다 경력, 데이터베이스를 작성
데이터 액세스 솔루션 다양한 응용 프로그램.
나는 클라우드 가상화에 있었어요 약 20 년 동안.
클라우드는 클라우드 전에 그래서, 우리는 유틸리티 컴퓨팅을 호출하는 데 사용.
그리고 생각, 그것은처럼되었다 PG & E는, 당신은 당신이 무엇을 사용 비용을 지불합니다.
오늘 우리는 클라우드를 호출합니다.
>> 그러나 지난 몇 년 동안, 나는 일했다 회사의 커플
당신은 아마 들어 본 적이없는.
하지만 기술의 목록을 뽑아 봤어요 업적, 나는 당신이 말하는 것 같아요.
나는 클라우드 시스템에 여덟 개의 특허를 가지고 가상화, 마이크로 프로세서 설계,
복합 이벤트 처리, 다른 지역뿐만 아니라.
>> 요즘 그래서, NoSQL에에 주로 초점 기술 및 차세대
데이터 베이스.
그리고 내가 갈거야 무엇 일반적이다 에 대해 오늘 이야기를 여기에.
그래서 당신은 무엇을 기대할 수 이 세션에서,
우리는 간단한 통과합니다 데이터 처리의 이력.
그것은 항상 도움 우리가 어디에서 왔는지 이해
우린 왜 우리가있는 곳.
그리고 우리는 조금 얘기하자 NoSQL에 기술에 대한 비트
기본적인 관점에서.
>> 우리는 몇 가지로 얻을 것이다 DynamoDB의 내부.
DynamoDB의는 AWS의 더 맛이 없다.
그것은 완벽하게 관리 그리고 호스팅 NoSQL에 솔루션을 제공합니다.
그리고 우리는 테이블에 대해 조금 얘기하자 구조의 API, 데이터 형식, 인덱스
그리고 내부의 일부 그 DynamoDB의 기술.
우리는 디자인의 일부에 얻을 것이다 패턴 및 모범 사례.
우리는 방법에 대해 얘기하자 일부 이러한 기술을 사용하여
오늘의 응용 프로그램.
그리고 우리는 조금 얘기하자 진화 또는 출현에 대한
프로그래밍의 새로운 패러다임 라는 이벤트 기반 응용 프로그램
및 DynamoDB의뿐만 아니라 그에서 재생하는 방법.
그리고 우리는 당신에게 약간을 떠날거야 참조 아키텍처 토론
그래서 우리는 몇 가지에 대해 이야기 할 수 있습니다 방법 당신은 DynamoDB의를 사용할 수 있습니다.
>> 그래서 먼저이 질문은 off-- 나는 많은 데이터베이스 무엇이다 듣는다.
많은 사람들은 생각 데이터베이스가 무엇인지 알고있다.
구글 당신, 당신은이를 볼 수 있습니다.
그것은 보유 데이터의 구조화 된 집합이다 컴퓨터, 특히 하나의 그
다양한 방법으로 액세스 할 수 있습니다.
그게 좋은 생각 현대 데이터베이스의 정의.
그러나 나는 때문에 그것을 좋아하지 않아 그것은 몇 가지를 의미한다.
이 구조를 의미한다.
그리고 그것이 컴퓨터에 있다는 것을 의미한다.
그리고 데이터베이스는하지 않았다 컴퓨터에 항상 존재한다.
데이터베이스는 실제로 다양한 방식으로 존재하고 있었다.
>> 그렇게 더 나은 정의 데이터베이스는이 같은 것입니다.
데이터베이스는 구성되어 있습니다 저장, 관리하기위한 메커니즘,
및 정보를 검색.
이 About.com에서입니다.
그래서 난 정말 회담 그것 때문이 좋아 대한 데이터베이스 저장소되고,
의 저장소 정보, 반드시
컴퓨터에 앉아 뭔가.
그리고 역사를 통해, 우리 항상 컴퓨터를 없었어요.
>> 지금, 나는 평균을 요구하는 경우 무엇 개발자 오늘
데이터베이스, 그건 내가 할 대답.
어딘가에 나는 물건을 부착 할 수 있습니다.
권리?
그리고 그것은 사실입니다.
그러나 그것은 불행한 일.
데이터베이스가 정말 때문에 현대 응용 프로그램의 기초.
이 재단의 모든 응용 프로그램입니다.
그리고 당신은 그 구축 방법 데이터베이스, 어떻게 구조
데이터는 어떻게을 지시 할 것입니다 당신이 확장으로 응용 프로그램을 수행한다.
>> 그래서 내 일 오늘의 많은 다루는 무엇
때 개발자 발생 이 접근 방식을
과 여파 처리 응용 프로그램의
이제 원래의 이상으로 확장된다 나쁜 디자인의 의도와 고통.
그래서 희망이 때를 오늘 도보 거리에, 당신은거야
도구의 몇가 당신하겠습니다 벨트
그 같은 실수에서.
괜찮아.
그럼 약간에 대해 이야기하자 데이터베이스 기술의 타임 라인.
내가 읽기 생각 기사없는 그 오래 전
그것은 lines--에 뭔가를 말했다 그것은 매우 시적인 문장이다.
그것은 말했다 역사 데이터의 처리는
하이 워터 마크의 전체 데이터의 풍요 로움.
그래.
지금, 나는 그 종류의 사실 것 같아요.
하지만 실제로에서있는 그대로 봐 역사는 실제로 가득
데이터 압력 높은 워터 마크.
의 데이터 레이트 때문에 섭취 다운되지 않습니다.
그것은 단지 올라갑니다.
>> 그리고 혁신은 때 발생 우리는 데이터를 압력을 참조한다
데이터의 양은 지금 시스템으로 오는.
그리고 처리 할 수​​ 없습니다 효율적으로 시간이나 비용 중 하나.
우리가 시작할 때 그리고 그건 데이터 압력에서 볼 수 있습니다.
>> 그래서 우리는 볼 때 첫 번째 데이터베이스,이
우리의 귀 사이에 있었던 것입니다.
우리는 모든 그것으로 태어난 것입니다.
그것은 좋은 데이터베이스입니다.
그것은 높은 가용성을 가지고있다.
그것은 항상이다.
당신은 항상 그것을 얻을 수 있습니다.
>> 그러나 단일 사용자입니다.
당신과 함께 내 생각을 공유 할 수 없습니다.
당신은 내 생각을 얻을 수 없다 당신이 그들을 원하는 경우.
그리고 그들의 abilitiy 그렇게 좋지 않다.
우리는 일을 잊어 버려.
모든 이제 다음, 우리 중 하나 잎 다른 존재로 이동
우리는 모든 것을 잃을 즉, 해당 데이터베이스에 있었다.
그래서 모두 좋지 않다.
>> 그리고이 시간이 지남에 잘 작동 우리는 하루에 다시있을 때
때 우리가 정말 알고하는 데 필요한 모든가 여기서 우리는 내일 갈거야
또는 우리는 최고의 음식을 수집한다.
그러나 우리는 시작으로로 성장하기 문명과 정부가 시작
존재에 와서하기 기업은 진화하기 시작했다
우리는 우리를 실현하기 시작 보다 조금 더 필요
우리는 우리의 머리에 넣어 수 있습니다.
괜찮아?
>> 우리는 기록의 시스템을 필요로했다.
우리는 수 데이터를 저장 할 곳이 필요했다.
그래서 우리는 서면으로 문서를 시작 도서관과 아카이브를 생성.
우리는 개발을 시작 시스템 원장 회계.
그리고 원장 계수의 시스템 여러 세기 동안 세계를 실행
어쩌면 천년으로 우리는 종류의 점에 성장
여기서, 그 데이터로드 능가 이러한 시스템의 능력
를 포함 할 수 있습니다.
>> 그리고이 사실은 1880 년대에 일어났다.
권리?
1880 미국 인구 조사에서.
이 곳 터닝 정말 현대의 데이터 처리를 가리.
이 지점에서이다 데이터의하는 양
그가에 의해 수집되고 있었다 미국 정부는 지점에 도착
그것은 어디에서 처리 할 팔년했다.
>> 이제 여덟 years--으로 당신은 인구 조사를 알고
실행 매 10 years--을가 그래서 꽤 분명 그 시간에 의해 우리
, 1890 년 인구 조사를 얻었다 데이터의 양은 그
처리 할 거라고 정부이었다
10 년을 초과하는 것 그것이 그 발사 된 새로운 인구 조사에 걸릴 것이다.
이 문제였다.
>> 그래서 사람은 허먼 이름 홀러리스는 따라왔다
그는 단위 기록 펀치를 발명 카드, 펀치 카드 판독기, 펀치 카드
도표 작성 및 데이터 정렬 이 기술에 대한 메커니즘.
그리고 그는 형성 그 회사 시간, 다른 사람의 부부와 함께,
실제로되었다의 기둥 중 하나 오늘날 우리가 알고있는 작은 회사는 IBM이라고합니다.
>> 그래서 IBM은 원래 있었다 데이터베이스 사업.
그리고 그들이 무슨 짓을했는지 정말.
이들은 데이터 처리를했다.
>> 펀치의 확산 않도록 카드, 독창적 인 메커니즘
의를 활용할 수있는 기술은 정렬 된 결과 세트를 폴링합니다.
이 그림에서 볼 수 있습니다 거기에서 우리는 little--이
그것은 조금 small--입니다하지만 당신은 볼 수 있습니다 매우 정교한 기계기구
우리는 펀치 카드 덱을한다.
그리고 누군가의 촬영 작은 드라이버
그리고 통해 나와 슬롯을 들어 올려
그 경기를 얻을 것과 분류 결과를 설정합니다.
>> 이는 집합이다.
우리는 모든 시간을 컴퓨터의 오늘,
데이터베이스에서이를 수행한다.
우리는 바로 수동으로 수행하는 데 사용?
사람들은 함께이 일을 시작했습니다.
그리고 그것은 확산했다 이 펀치 카드의
우리가 이른바 데이터 드럼에 데이터 릴, 종이 테이프.
>> 데이터 프로세싱 업계했다 플레이어 피아노에서 교훈.
플레이어는 다시 피아노 세기의 전환기
슬롯에 용지 릴을 사용하는 데 사용 에 그것을 재생하려면 어떤 키를 알 수 있습니다.
이 기술은 적응했다 그래서 결국, 디지털 데이터를 저장할
그들은 데이터를 넣을 수 있기 때문에 그 종이 테이프 릴 위에.
>> 이제, 그 결과, 데이터 어떻게 ... 사실상되었다
이 데이터는 직접했다 액세스 당신이 그것을 저장 방법에 따라 다릅니다.
그래서 테이프에 데이터를 배치하는 경우, I는 선형 데이터를 액세스 하였다.
나는 전체를 출시했다 테이프는 모든 데이터에 액세스 할 수 있습니다.
나는 펀치에 데이터를 배치하는 경우 카드, 나는 그것을 액세스 할 수
좀 더 임의의 패션, 아마 빨리.
>> 그러나 방법에 한계가 있었다 우리 저장된 방법에 따라 데이터에 액세스 할 수 있습니다.
그래서이 문제였다 50 년대에 가고.
다시 말하지만, 우리는 같은 것을 볼 시작할 수 있습니다 처리 할 수​​있는 새로운 기술을 개발
데이터는, 바로 그것이 연다 새로운 솔루션에 대한 문,
새로운 프로그램, 새로운 해당 데이터에 대한 응용 프로그램.
그리고 정말, 지배 이유일지도 모른다
왜 우리는이 시스템의 일부를 개발했다.
그러나 사업은 급속하게되었다 진화 뒤에 드라이버
현대 데이터베이스 및 현대 파일 시스템.
>> 다음 일은 있도록 50 년대에 등장했다
파일 시스템이었다 랜덤 액세스 저장 장치의 개발.
이 아름다웠다.
이제, 갑자기, 우리는 넣을 수 있습니다 우리의 이 하드 드라이브의 어느 곳에서나 파일
우리는 무작위로이 데이터에 액세스 할 수 있습니다.
우리는 그것을 분석 할 수 파일 중 정보.
그리고 우리는 세계의 모든 해결 데이터 처리 문제.
>> 그리고 그 지속에 대한 20 진화 될 때까지 삼십년
관계형 데이터베이스, 어떤 세계는 지금​​ 우리를 결정했을 때입니다
패배 저장소가 필요합니다 파일에서 데이터의 무분별한 확산
우리가 구축 한 시스템. 권리?
너무 많은 분포 너무 많은 데이터 장소, 데이터의 중복,
스토리지의 비용은 엄청난이었다.
>> 70 년대에, 가장 비싼 자원 컴퓨터가 가진 것을 기억했다.
프로세서이었다 고정 비용으로 간주.
나는 상자를 구입하면, CPU는 몇 가지 작업을 수행합니다.
그것은 여부를 회전 할 것 실제로 작동 여부입니다.
그건 정말 고정 비용이다.
>> 그러나 나를 비용 비즈니스 스토리지입니다.
나는 옆에 더 디스크를 구입해야하는 경우 월, 그게 내가 지불하는 실제 비용입니다.
그리고 그 기억은 비싸다.
>> 이제 우리는 빨리 감기 40년 그리고 우리는 다른 문제가있다.
계산은 지금이다 가장 비싼 자원.
스토리지는 저렴합니다.
나는 우리가 아무 곳이나 갈 수있는, 의미 구름과 우리는 저렴한 스토리지를 찾을 수 있습니다.
하지만 내가 무엇을 찾을 수없는 것은 싼 계산이다.
>> 오늘날의 진화 그래서 기술, 데이터베이스 기술,
정말 주위에 초점을 맞추고 있습니다 분산 데이터베이스
그 고생하지 않는다 규모의 동일한 유형
관계형 데이터베이스의 한계.
우리에 대해 조금 얘기하자 그 사실은 무엇을 의미하는지.
>> 그러나 이유 중 하나는 이 항아리 우리 뒤에 드라이버
데이터 압력에 대해 이야기했다.
데이터 압력은 뭔가 그 혁신을 주도합니다.
그리고 당신은에서를 통해 보면 지난 5 년 동안,
이것은 무엇 데이터의 차트 일반 기업에서 부하
지난 5 년처럼 보인다.
>> 그리고 엄지 손가락의 일반적인 규칙 이 days-- 당신은 Google-- 가면
데이터의 90 %는 그 우리는 현재 저장하고 있었다
지난 2 년 이내에 발생.
그래.
지금,이 새로운 추세는 아니다.
이되었습니다 추​​세 100 년 외출.
적 허먼 홀러리스 이후 펀치 카드를 개발
우리는 데이터 저장소를 구축했습니다 그리고 놀라운 속도로 데이터를 수집.
>> 그래서 지난 100 년 동안, 우리는이 추세를 보았다.
즉, 변경 않을거야.
앞으로 우리가 보게 될 것입니다 이 아니더라도 가속 추세.
그리고 당신은 그 모습을 볼 수 있습니다.
>> 2010 년 사업은 하나를 가지고 있다면 관리에서 데이터의 테라 바이트,
그들이있어 의미 오늘 데이터의 6.5 페타 바이트를 관리.
즉 6,500 배 더 많은 데이터를합니다.
그리고 나는 이것을 알고있다.
나는 매일이 기업과 함께 작동합니다.
5 년 전, 회사 이야기 것
어떤 고통에 대해 나에게 사람을 이야기 할 이 테라 바이트의 데이터를 관리하는 것입니다.
그리고 그들은 말할 것이다 우리가 보는 방법에 대해 나에게
이 것이 아마 것입니다 페타 바이트 또는이 될
몇 년 이내.
>> 이 같은 회사 내가 만나고있어 오늘,
그들은 대해 나에게 얘기 문제는 관리가 데
수십, 데이터의 20 페타 바이트.
의 폭발 그래서 산업 데이터
거대한를 운전 더 나은 솔루션이 필요합니다.
그리고 관계형 데이터베이스입니다 단지 수요에 부응하지.
>> 그래서 선형있다 데이터 압력 사이의 상관 관계
기술 혁신.
역사는 우리에게 보여 주었다 이, 그 시간에,
마다 데이터의 양 즉, 처리해야
시스템의 용량을 초과 적당한 시간에 그것을 처리하는
또는 합리적인 비용, 다음 새로운 기술
이러한 문제점을 해결하기 위하여 창안된다.
이러한 새로운 기술, 차례로 문을 열어
문제의 또 다른 세트에있는 더 많은 데이터를 수집한다.
>> 이제, 우리는이 중지하지 않을거야.
권리?
우리는이 중지하지 않을거야.
왜?
당신은 모든 것을 알 수 있기 때문에 우주에서 알 수있다.
그리고 한 우리는 살아 봤는데으로 인간의 역사를 통해,
우리는 항상 더 많은 것을 알고 주도했다.
>> 그래서 우리가 이동 구석 구석 것 같아 과학적 발견의 경로 아래로,
우리는 데이터의 양을 승산되고 우리는 기하 급수적으로 처리 할 필요가 있음
우리는 점점 더 많은을 밝히기로 생명의 내부 동작에 대한,
우주의 작동 방식에 대한 약 과학적 발견을 운전,
본 발명 그 우리는 오늘 일을하고 있습니다.
데이터 볼륨 단지 지속적으로 증가한다.
그래서 다룰 수 있다는 이 문제는 거대하다.
>> 것들 중 하나 그래서 우리는 NoSQL에 왜으로 보면?
어떻게 NoSQL에이 문제 해결에 도움이 되었습니까?
음, 관계형 데이터베이스, 구조적 쿼리 언어,
SQL-- 그건 정말의 구조이다 관계는 이런 일이 database--
스토리지에 최적화.
>> 위로 70 년대에, 다시, 디스크가 비싸다.
스토리지 프로비저닝 운동 기업의 끝없는입니다.
알아.
나는 그것을 살았다.
나는에 대한 스토리지 드라이버를 썼다 enterprised 슈퍼 회사
다시 90 년대.
그리고 결론은 서로를 건 드리는됩니다 스토리지 배열은 그냥 뭔가였습니다
기업에서 매일 일어났다.
그리고 그것은 결코 멈추지 않았다.
고밀도 저장 수요 고밀도 저장을 위해,
보다 효율적인 저장을위한 이 중지 결코 devices--.
>> 그리고 NoSQL에 좋은 기술입니다 이는 데이터를 정규화하기 때문이다.
이는 데이터를 디 - 복제.
그것은 구조에 그 데이터를 둔다 모든 액세스 패턴에 얽매이다.
여러 응용 프로그램이 충돌 할 수 있습니다 SQL 데이터베이스, 임시 쿼리를 실행,
과 모양 데이터를 얻을 그들이 자신의 워크로드 처리해야합니다.
즉, 환상적인 소리.
그러나 결론은 함께 시스템은 모든 것에 얽매의 경우,
그것은 아무것도에 최적화되어 있습니다.
그래?
>> 그리고 그것은 우리가 무엇을 얻을 관계형 데이터베이스.
그것은 스토리지에 최적화 된.
그것은 정규화입니다.
그것은 관계입니다.
그것은 임시 쿼리를 지원합니다.
그리고 그것은 수직으로 확장 할 수 있습니다.
>> 나는 더 큰 SQL 데이터베이스를 얻을 필요가있는 경우 또는보다 강력한 SQL 데이터베이스,
나는 철의 더 큰 조각을 구입 이동합니다.
그래?
나는 많은 고객과 함께 일했다 주요 업그레이드를 통해되었는지
자신의 SQL 인프라 만 6 개월 후 확인하려면,
그들은 다시 벽을 치는 것입니다.
그리고 Oracle 또는 MSSQL에서 대답 또는 다른 사람은 더 큰 상자를 얻을 수있다.
그럼 조만간, 당신은 살 수 없습니다 상자 더 큰, 그리고 진짜 문제입니다.
우리는 실제로 물건을 변경해야합니다.
어디이 일을합니까?
그것은 오프라인 잘 작동 분석, OLAP 형 워크로드.
SQL이 속한 곳 그리고 정말입니다.
지금, 그것은 많은 온라인 오늘날 사용되는 트랜잭션 처리 형
응용 프로그램.
그리고 그것은에서 잘 작동합니다 이용 일정 수준의,
하지만 그것은 단지 확장되지 않습니다 NoSQL에가하는 방법.
그리고 우리는 조금 얘기하자 그 이유에 대한 비트.
>> 이제 NoSQL에, 다른 한편으로는, 더 많은 컴퓨팅에 최적화되어 있습니다.
그래?
그것은에 무관하지 않다 액세스 패턴.
우리가 탈 정규화라고 부릅니다 구조 또는 계층 적 구조.
관계형 데이터베이스의 데이터는 여러 테이블에서 함께 결합
당신이 필요로하는 뷰를 생성한다.
NoSQL에 데이터베이스의 데이터 문서에 저장되는 것을
계층 구조가 포함되어 있습니다.
일반적으로 될 것이라고 모든 데이터 그 뷰를 생성하기 위해 서로 결합
단일 문서 내에 저장된다.
그리고 우리에 대해 조금 얘기하자 어떻게 차트의 몇 작품을.
>> 그러나 여기에서 아이디어는 당신이 저장하는 것이있다 이러한 인스턴스 뷰와 같은 데이터.
그래?
당신은 수평으로 확장 할 수 있습니다.
권리?
나는이 증가해야하는 경우 내 NoSQL에 클러스터의 크기,
나는 더 큰 상자를 얻을 필요가 없습니다.
나는 또 다른 상자를 얻을.
그리고, 함께 그 클러스터 나는 그 데이터를 샤딩 할 수 있습니다.
우리에 대해 조금 얘기하자 샤딩이 무엇인지, 할 수
해당 데이터베이스를 확장 할 수 여러 물리적 장치에 걸쳐
과 장벽을 제거하는 수직으로 확장 할 날이 필요합니다.
>> 그래서 정말 온라인을 위해 만들어진 것 트랜잭션 처리 및 규모.
큰 차이가있다 여기에보고 사이에, 오른쪽?
보고, 나는 몰라 질문은 물어거야.
권리?
Reporting-- 사람의 경우 내 마케팅 부서
내 고객의 얼마나 많은 그냥 ...하고자 이 특정 특성이있는 사람
나도 몰라이 day--에 구입 어떻게 그들이 물어거야 쿼리합니다.
그래서 나는 불가지론 할 필요가있다.
>> 이제 온라인에서 트랜잭션 응용 프로그램,
내가 부탁 해요 어떤 질문을 알고있다.
나는에 대한 응용 프로그램을 구축 매우 구체적인 워크 플로우.
그래?
I는 데이터를 최적화한다면 그 워크 플로우를 지원하기 위해 저장,
더 빨리 될 것.
그리고 그 이유는 NoSQL에 할 수 있어요 실제로 전달을 가속화
서비스의 이러한 종류의.
괜찮아.
>> 그래서 우리는에받을거야 여기에 이​​론의 약간.
그리고 당신의 일부, 눈 조금 롤백 할 수 있습니다.
그러나 나는 그것을 유지하려고합니다 내가 할 수있는만큼 높은 수준.
당신이 프로젝트에있어 경우에 따라서 관리는있다
구조는 전화 제약 조건의 삼각형.
그래.
구속의 지시의 삼각형 당신은 모든 것을 모든 시간을 가질 수 없습니다.
당신의 파이가 너무 먹을 수 없습니다.
그래서 프로젝트 관리, 그 삼각형 제약, 당신이 싼 가질 수있다
당신은 그것을 빨리 할 수​​ 있습니다 또는 당신은 잘 할 수 있습니다.
두 가지를 선택합니다.
당신은 세 가지를 모두 가질 수 없습니다 때문입니다.
권리?
그래.
>> 그래서이 많이 듣고.
그것은, 트리플 제약의 트리플 제약의 삼각형,
또는 철의 삼각형 oftentimes--입니다 당신은 프로젝트 관리자에 이야기 할 때,
그들은 이것에 대해 얘기하자.
이제 데이터베이스가 자신의 철의 삼각형.
및 데이터의 철 삼각형 우리는 CAP 정리라고 부릅니다.
그래?
>> CAP 정리의 지시 어떻게 데이터베이스 운영
매우 구체적인 조건.
그리고 우리는 얘기하자 그 조건은 무엇인지.
그러나 삼각형의 세 점, 그래서, C는, 일관성 말을합니다.
그래?
그래서 모자, 일관성은 모든 것을 의미합니다 데이터베이스에 액세스 할 수있는 클라이언트
항상 매우있을 것이다 데이터의 일관성을 볼 수 있습니다.
아무도거야 다른 두 가지를 참조하십시오.
그래?
나는 데이터베이스를 참조하는 경우, 나도 같은보기를보고 있어요
내 파트너로 누가보고 동일한 데이터베이스.
즉 일관성이다.
>> 가용성을 의미하는 경우 데이터베이스, 온라인이 도달 할 수있는 경우,
모든 클라이언트가 항상 것 읽고 쓸 수 있습니다.
그래?
그래서 모든 클라이언트가 데이터베이스를 읽을 수 있습니다
항상있게 읽을 수 있습니다 데이터 쓰기 데이터.
그리고 그런 경우, 그것은 사용할 수있는 시스템이다.
>> 그리고 세 번째 점은 무엇입니까 우리는 파티션 허용 오차를 호출합니다.
그래?
파티션 허용 수단 시스템이 잘 작동하는
실제 네트워크에도 불구하고 노드들 사이의 파티션.
그래?
따라서 클러스터의 노드 수 없습니다 서로 대화, 어떻게됩니까?
괜찮아.
>> 그래서 관계형 데이터베이스는 choose-- 당신은이 두 가지를 선택할 수 있습니다.
그래.
그래서 관계형 데이터베이스 선택 일관되고 사용할 수 있습니다.
파티션 사이에 발생하는 경우 데이터 저장소의 데이타 노드,
데이터베이스가 충돌합니다.
권리?
그냥 내려갑니다.
그래.
>> 그리고 이것은 그들이 가지고있는 이유 큰 상자와 함께 성장합니다.
권리?
말아요 - 일반적으로, 클러스터가 존재하기 때문에 데이터베이스는, 그들 중 매우 많은이 아니다
그것은 그런 식으로 작동합니다.
그러나 대부분의 데이터베이스 확장 수직으로 하나의 상자 내.
그들은 할 필요가 있기 때문에 일관성 있고 사용할 수 있습니다.
파티션을 주입했다, 당신은 선택을해야 할 것입니다.
당신은 사이에서 선택을해야 일관성 있고 사용할 수있는.
>> 그리고 그 NoSQL에 데이터베이스가하는 일입니다.
괜찮아.
그래서 NoSQL에 데이터베이스를 두 가지 유형이있다.
우리는 잘 잔 마셔요 여러 가지 유형이있다,
하지만 두 가지 기본 제공됩니다 무엇을 특징 만
우리는 CP 데이터베이스 또는를 호출 일관성 및 파티션 허용
체계.
이 사람들은 선택을 할 때 노드들은 서로 접촉을 상실
우리는 허용하지 않을거야 사람들은 더 이상 쓸 수 있습니다.
그래?
>> 해당 파티션이 제거 될 때까지, 쓰기 액세스가 차단됩니다.
즉이 사용 가능하지 않은 것을 의미한다.
그들은 일관성입니다.
우리가 볼 때 파티션 자체를 주입,
우리는 지금 일치 우리는하지 않을거야 때문에
두 데이터에 대한 변경을 허용하도록 독립적으로 파티션의 측면
서로.
우리는해야합니다 통신을 다시
어떤 갱신 전에 데이터가 허용됩니다.
그래?
>> 다음 맛, AP 시스템이 될 것입니다 또는 사용할 수 있으며 분할
허용 오차 시스템.
이 사람은 걱정하지 않는다.
권리?
를 얻을 모든 노드 우리가 할게요, 쓰기.
그래서 난 내 데이터를 복제하고있어 여러 노드에서.
이러한 노드는 클라이언트, 클라이언트 제공받을 , 말씀에, 나는 몇 가지 데이터를 쓸거야.
노드는 아무 문제 말한다.
노드 그를 가져 옆에 동일한 레코드에 대한 쓰기,
그는 문제를 말할거야.
어딘가에 다시 백 엔드에, 그 데이터를 복제하는 것입니다.
그리고 누군가가 실현거야 어 - 오, 깨달을 것이다 그들은 시스템, 어 - 오,
양측에 업데이트가되었습니다.
우리는 무엇을해야합니까?
그리고 그들이 다음 할 것은 그들은 무언가를하는
그들이 그 데이터 상태를 해결 할 수 있습니다.
그리고 우리는 얘기하자 다음 차트에서 해당.
>> 일이 여기에 지적한다.
그리고 너무 얻을 않을거야 많은이에,이 때문에
깊은 데이터 이론으로 가져옵니다.
그러나 트랜잭션있다 프레임 워크가
관계형 시스템에서 실행 나를 안전하게 업데이트 할 수 있습니다
데이터베이스 내의 여러 엔티티.
그리고 이러한 업데이트가 발생합니다 한 번에 또는 전혀.
그리고이는 ACID 트랜잭션이라고합니다.
그래?
>> 산은 우리에게 일관성을 원 자성을 제공, 격리 및 내구성.
그래?
즉 모든 원자, 트랜잭션을 의미 내 업데이트 발생하거나 또는하지 않습니다.
일관성이 있음을 의미합니다 데이터베이스 항상 것
일관하게 될 업데이트 후 상태.
나는에서 데이터베이스를 떠나지 않을 것이다 업데이트를 적용한 후 나쁜 상태.
그래?
>> 그래서 조금 다르다 CAP의 일관성보다.
CAP의 일관성을 의미 내 모든 클라이언트는 항상 데이터를 볼 수있다.
ACID 일관성을 의미 때 트랜잭션 데이터의 좋은 이루어집니다.
나의 관계는 모두 좋다.
나는 부모 행을 삭제하지 않을거야 고아 아이들의 무리를 떠나
다른 테이블.
내가 일치 해요 경우가 발생할 수 없습니다 산 거래.
>> 격리 거래 있음을 의미한다 항상 하나씩 발생한다.
데이터의 최종 결과 같은 상태가 될 것입니다
이러한 트랜잭션 마치 그 동시에 발행 된
순차적으로 실행되었다.
그래서 동시성이다 데이터베이스에 제어 할 수 있습니다.
그러니까 기본적으로, 나는를 증가 할 수 두 번 두 가지 작업과 같은 값.
>> 하지만이 값에 1을 추가 말한다면, 두 개의 트랜잭션이 와서
하나는, 그것은을하려고 먼저 거기에 도착 예정
다른 하나의 후 거기에 도착하는 것.
그래서 결국, 나는 두 가지를 추가했다.
당신은 내가 무슨 뜻인지 볼?
그래.
>> 내구성은 매우 간단합니다.
때 트랜잭션 인정, 그건
심지어이 될 것 시스템이 충돌하는 경우.
해당 시스템이 복구되면, 그 커밋 트랜잭션
실제로이 될 것입니다.
그래서 보장의 ACID 트랜잭션의.
사람들은 꽤 좋은 보장입니다 데이터베이스에 미칠합니다,
그러나 그들은 그 비용으로 제공됩니다.
권리?
>> 문제 때문에 이 프레임 워크가와
데이터 파티션이있는 경우 세트, 나는 결정을해야합니다.
나는 수 있도록해야 할거야 한 쪽 또는 다른에 업데이트됩니다.
그리고 그 일이 생기면, 나는 더 이상 진행 해요
유지할 수 있어야합니다 그 특성.
그들은 일치하지 않습니다.
그들은 고립되지 않습니다.
이 고장 곳이다 관계형 데이터베이스.
이 이유이다 관계형 데이터베이스는 수직으로 확장 할 수 있습니다.
>> 반면에, 우리가 무슨 일이 기반 기술을 불렀다.
그리고이는 NoSQL에 데이터베이스입니다.
괜찮아.
그래서 우리는 우리의 CP, AP 데이터베이스를 가지고있다.
그리고 이들은 당신이 기본적으로 부르는 있습니다 가능한, 부드러운 상태, 결국
일관된.
그래?
>> 기본적으로 사용할 수 있기 때문에 그들은 파티션 허용입니다.
그들은 항상있을 것입니다 이,이 경우에도
노드 간의 네트워크 파티션.
내가 노드로 이야기 할 수 있다면, 나는 해요 데이터를 읽을 수있을 것.
그래?
난 항상 기록하지 못할 수 있습니다 데이터 나는 일관성있는 플랫폼이야합니다.
하지만 데이터를 읽을 수 있습니다.
>> 부드러운 상태를 나타냅니다 내가 그 데이터를 읽을 때,
그것은 다른 노드와 동일하지 않을 수 있습니다.
권리는 노드에서 발급 된 경우 클러스터의 다른 곳
그것은을 통해 복제되지 않은 클러스터는 아직 난, 그 데이터를 읽을 때
그 상태가 일치하지 않을 수 있습니다.
그러나 것 결국 일관성,
의미 할 때 작성하는 것이 시스템에 구성되어,
이 노드에 복제합니다.
그리고 결국, 그 상태 주문하게 될 것입니다,
그리고 일관성있는 상태 일 것이다.
>> 이제, CAP 정리 정말 하나의 조건 만 재생됩니다.
이러한 상황이 발생하면 해당 조건이다.
때마다 자신의 운영 때문에 일반 모드, 어떤 파티션이 없다,
모두의 일관성 및 사용할 수 있습니다.
당신은 CAP 걱정 우리는 그 파티션이있는 경우.
그래서 사람들은 드물다.
그러나 시스템이 때 사람들을 어떻게 반응 시스템의 유형을 지시 발생
우리가 상대하고.
>> 그럼 살펴 보자 무엇 즉, AP 시스템처럼 보인다.
그래?
AP 시스템은 두 가지 종류로 왔습니다.
그들은 인 맛에 와서 마스터 마스터, 항상 사용할 수 100 %.
그리고 그들은 올 라고 다른 맛,
당신은, 내가 걱정하는거야 알고 이 파티션 일에 대한
때 실제 파티션이 발생합니다.
그렇지 않으면, 차있을거야 권리를 걸릴 거예요 노드.
그래?
>> 카산드라 같은 우리가 어떤 경우에 따라서.
카산드라는 마스터 것 마스터, 내가 모든 노드에 기록하자.
그래서 무슨 일이?
그래서에서 개체가 두 개의 노드에 존재하는 데이터베이스.
의 해당 개체 (S)를 부르 자 그래서 우리는 (S)에 대한 상태를
우리는 일부 작업을 S에 진행됩니다.
카산드라에 날 수 있습니다 여러 노드에 쓰기.
그래서 내가 얻을 가정 해 봅시다 두 개의 노드로 초 동안 물품.
글쎄, 무슨 일이 일어나고있는 것입니다 끝 우리는 분할 이벤트 있음을 호출합니다.
가되지 않을 수 있습니다 물리적 네트워크 파티션.
그러나 때문에 디자인의 시스템, 그것은이다
실제로 즉시 분할 나는 두 개의 노드에 쓰기를 얻을 수있다.
그것은 저를 강요 아니에요 하나의 노드를 통해 모든 물품.
나는 두 개의 노드에 쓰고 있어요.
그래?
>> 그래서 지금은 두 가지 상태가있다.
그래?
무슨 일이 일어날 조만간입니다
복제 이벤트가있을 것입니다.
있을 무슨 일이 일어나고 있는지 우리 파티션 복구,라고하는
여기서이 두 가지입니다 상태는 함께 돌아와
및 알고리즘이있을거야 즉, 데이터베이스 내에서 실행
무엇을 결정한다.
그래?
기본적으로, 마지막 업데이트 대부분의 AP 시스템에서 이긴다.
그래서 일반적으로있다 기본 알고리즘 어떤
그들은 콜백을 호출 기능, 뭔가 그
때이 조건이 호출됩니다 일부 로직을 실행하기 위해 검출되고
그 충돌을 해결합니다.
그래?
기본 콜백 및 기본 대부분의 AP 데이터베이스에 해결
이며, 타임 스탬프 승리 어떻게 됐을까.
이 마지막 업데이트했다.
나는 거기에 해당 업데이트를 넣어거야.
나는이 레코드를 덤프 수 나는 복구 로그에 떨어져 버려
사용자가 나중에 다시 올 수 있도록 말하기, 헤이, 충돌이 있었다.
어떻게 된 거예요?
그리고 당신은 실제로 기록을 덤프 할 수 모든 충돌과 롤백
그리고 무슨 일이 일어 나는지.
>> 이제, 사용자로, 당신은 또한 수 그 콜백에 로직을 포함한다.
그래서 당신은을 변경할 수 있습니다 콜백 작업.
당신은 이봐, 내가 원하는 말할 수 이 데이터를 교정합니다.
내가 시도하려는 및 두 레코드를 병합.
그러나 그것은 당신에게 달려 있습니다.
데이터베이스는 모르는 방법 기본적으로 그렇게. 대부분의 시간,
유일한 데이터베이스 어떻게 말을 할 일은 알고
이 사람은 마지막 기록했다.
즉, 이길 것 하나 그리고 내가 넣어거야 값입니다.
파티션 복구되면 복제가 발생
우리는 우리의 상태를 가지고있는 지금 인 프라임 S
모든 개체의 병합 상태.
그래서 AP 시스템이 있습니다.
CP 시스템은 필요하지 않습니다 이것에 대해 걱정합니다.
즉시 파티션이 온다 때문에 놀이로, 그들은 단지 복용을 중단
기록합니다.
그래?
그래서 아주 쉽게 일관성있는 처리
때 업데이트를 허용하지 않습니다.
CP 시스템은 수행과 함께 때문이다.
괜찮아.
>> 그래서 조금 이야기하자 액세스 패턴에 대한 비트.
우리는 NoSQL에 대해 이야기 할 때이다 모든 액세스 패턴에 대한.
이제, SQL은 임시 쿼리입니다.
그것은 관계를 저장합니다.
우리는 걱정할 필요가 없습니다 액세스 패턴에 대한.
나는 매우 복잡한 쿼리를 작성.
이는 이동하고 데이터를 얻는다.
즉,이 보이는거야 같은 정규화.
>> 이 특정 구조에 따라서 우리는 제품 카탈로그에서 찾고 있습니다.
I는 서로 다른 종류의 제품이있다.
나는 책이있다.
나는 앨범을 가지고있다.
나는 동영상이.
제품 간의 관계 그리고이 책, 앨범 중 하나,
및 비디오 테이블은 1 : 1입니다.
괜찮아?
나는 제품 ID를 가지고있어, 그 ID의 대응
책, 앨범, 또는 비디오.
그래?
1 관계 : 즉 1의 그 테이블에서.
>> 이제, 모든 사람들을 books-- 이 루트의 숙박 시설이다.
문제 없어.
잘 됐네요.
일대일 관계, I는 모두 얻을 데이터가 그 책을 설명 할 필요가있다.
Albums-- 앨범 트랙이있다.
이것은 우리가 많은 하나를 호출 할 것입니다.
모든 앨범은 많은 트랙을 가질 수있다.
의 모든 트랙에 대한 그래서 앨범은, 내가 할 수
이 자식 테이블에서 다른 레코드.
그래서 하나의 레코드를 생성 내 앨범 테이블.
여러 개의 레코드를 만들 트랙 테이블.
일대 다 관계.
>> 이 관계는 무엇입니까 우리는 다 대다를 호출합니다.
그래?
당신은 배우가 될 수 있다고 볼 수 많은 영화, 많은 비디오에서.
그래서 우리가 우리가이 매핑을 넣어 그 사이에 테이블, 어떤 이는 단지
비디오 ID로 배우 ID를 매핑합니다.
지금은 조인 쿼리를 만들 수 있습니다 배우로 배우 비디오를 통해 동영상,
그것은 나에게의 좋은 목록을 제공 모든 영화와 모든 배우
누가 그 영화에 있었다.
>> 그래.
그래서 여기에 우리가 간다.
일대일 최상위이며 관계; 일대
트랙 앨범; 대다.
사람들은 세 가지 최상위 있습니다 데이터베이스의 관계.
당신은 어떻게 사람들을 알고있는 경우 관계는 협력​​,
당신은 많이 알고 이미 데이터베이스에 대한.
그래서 NoSQL에는 약간 다르게 작동합니다.
의는 잠시 생각하자 무엇을 외모는 내 모든 제품을 얻을 가고 싶어.
>> 관계형 상점에서, 나는 내 모든 제품을 얻으려면
내 모든 제품의 목록.
즉, 쿼리가 많이 있습니다.
내 모든 책에 대한 쿼리를 얻었다.
내 앨범에서 쿼리를 얻었다.
그리고 나는 내 모든 동영상에 대한 쿼리를 얻었다.
그리고 나는 그것을 넣어 가지고 모두 함께 목록에서
그리고까지 다시 봉사 그것을 요​​구하고있는 응용 프로그램입니다.
>> 내 책을 얻으려면, 내가 가입 제품 및 책.
내 앨범을 얻으려면, 내가 가입있어 제품, 앨범, 트랙.
그리고 내가 가지고, 내 동영상을 얻을 수 동영상에 제품을 결합하고,
배우 동영상을 통해 가입, 그리고 배우에 가져.
그래서 세 가지 질의를합니다.
매우 복잡한 쿼리 하나의 결과 세트를 조립한다.
>> 즉 최적 미만이다.
이것은 우리가 얘기를 왜 때입니다 데이터의 구조에 대한
액세스 불가지론로 내장 pattern-- 잘 그게 좋아요.
그리고 당신이 정말 볼 수 있습니다 우리가 데이터를 조직 한 방법 좋은.
그리고 당신은 무엇을 알아?
난 단지 배우에 대해 하나의 기록을 가지고있다.
>> 그건 괜찮아요.
내 모든 배우 중복 제거했습니다, 그리고 나는 나의 연결을 유지
이 매핑 테이블.
그러나, 데이터를 받고 밖으로 비싼된다.
나는 모든 시스템을 통해 CPU를 보낸다 함께 이러한 데이터 구조를 합류
해당 데이터를 다시 끌어 할 수 있습니다.
>> 그래서 내가 어떻게 그 주위에받을 수 있나요?
NoSQL에 그것은에 관하여 집계하지 정상화.
그래서 우리는 우리가 원하는하고 싶은 말 액세스 패턴을 지원합니다.
액세스 패턴이면 응용 프로그램,
내 모든 제품을 얻을 필요가있다.
의 한 표에 모든 제품을 넣어 보자.
나는 하나의 테이블에 모든 제품을 두는 경우에, 난 그냥 모든 제품을 선택할 수 있습니다
그 테이블에서 나는 모든 것을 얻을.
그럼 난 어떻게해야합니까?
그럼 NoSQL에에 더 없다 테이블 구조.
우리에 대해 조금 얘기하자 방법이 디나모 DB에서 작동합니다.
하지만 당신은 같은이 없습니다 속성과 같은 속성
하나 하나의 모든 단일 행에 항목, 당신은 SQL 테이블에서처럼.
그리고 무엇이 날 수 있습니다 할 것은 많은 것들을입니다
나에게 많은 유연성을 제공합니다.
특히이 경우, I 내 제품 문서가 있습니다.
그리고이 특히 예를 들어, 모든
제품 테이블의 문서이다.
그리고 책의 제품은 수도 책을 지정하는 유형 ID를 가지고 있습니다.
그리고 응용 프로그램 그 ID를 전환 할 것입니다.
>> 응용 프로그램 계층에서, 나는거야 아,이 무슨 레코드 유형 대답?
아,이 책의 기록이다.
예약 기록은 이러한 속성을 가지고있다.
내가 책 객체를 생성 할 수 있습니다.
그래서 난을 채울거야 이 항목을 가지고있는 책 객체입니다.
다음 항목이 온다 이 항목은 무엇입니까,라고?
그럼이 항목은 앨범이다.
아, 나는 완전히 다른있어 그에 대한 처리 루틴,
이 앨범이기 때문에.
당신은 내가 무슨 뜻인지 볼?
>> 그래서 응용 프로그램 tier-- 내가 다만이 모든 기록을 선택합니다.
그들은 모두에 오는 시작합니다.
그들은 모두 서로 다른 종류의 수 있습니다.
그리고 응용 프로그램의 로직의 그는 그 유형에 걸쳐 전환
및 이들의 처리 방법을 결정한다.
>> 다시 말하지만, 우리가 최적화하고 액세스 패턴에 대한 스키마.
우리가 그 일을하고 그 테이블을 축소.
우리는 기본적으로 취하고있어 이러한 표준화 된 구조,
우리가 만들고 있어요 계층 구조.
이러한 기록의 각 내부 나는 배열 속성을 볼거야.
>> 앨범이 문서 내부, 나는 트랙의 배열을보고 있어요.
그 트랙은 지금 그것의 become-- 기본적으로이 자식 테이블이
바로 여기에이 구조에 존재한다.
그래서 당신은 DynamoDB의에서이 작업을 수행 할 수 있습니다.
당신은 MongoDB가이 작업을 수행 할 수 있습니다.
당신은 어떤 NoSQL에 데이터베이스에서이 작업을 수행 할 수 있습니다.
이러한 유형의 작성 계층 적 데이터 구조
당신은 데이터를 검색 허용하는지 매우 빠르게 해주기 때문에
준수 할 필요가 없습니다.
나는 트랙에 행을 삽입 할 때 테이블, 또는 앨범 테이블에 행,
그 스키마를 준수해야합니다.
I는 속성 또는 있어야 해당 테이블에 정의 된 속성입니다.
그들 모두, 그 행을 삽입 할 때.
즉, NoSQL에의 경우이 아니다.
>> 나는 완전히 다른 수 있습니다 모든 문서의 속성
나는 컬렉션에 삽입있다.
그래서 매우 강력한 메커니즘.
그리고 정말 방법을이다 시스템을 최적화한다.
대신 지금 쿼리 때문에 모든 테이블을 조인의
반 다스 쿼리를 실행 내가 필요한 데이터를 철수하고,
나는 하나의 쿼리를 실행하고 있습니다.
그리고 반복 해요 결과 집합에서.
그것은 당신에게 아이디어를 제공합니다 NoSQL에의 힘.
나는 종류의 옆으로 여기거야 그리고 이것에 대해 조금 이야기.
이 종류의 더욱 마케팅이나 technology--
기술 마케팅 토론의 유형입니다.
그러나 이해하는 것이 중요합니다 우리가 상단에 보면 때문에
여기에이 차트에서, 우리가보고있는
우리가 부르는 것이다 기술 과대 광고 곡선.
그리고 이것이 의미하는 것은 새로운 물건이 활동하기 시작한다.
사람들은 좋은 것 같아요.
내 모든 문제를 해결했습니다.
>> 이 마지막이 될 수 모든 모든 모든을합니다.
그리고 그들은 그것을 사용하기 시작.
그리고 그들은이 물건이 작동하지 않습니다 말한다.
이것은 옳지 않다.
오래된 물건은 더 좋았다.
그리고 그들은 일에 돌아가 가지가 있었다 방법.
그리고 결국 그들은 당신이 무엇을 알고, 이동?
이 물건은 그렇게 나쁘지 않다.
아, 그것이 작동하는 방법.
그리고 그들은 어떻게 알아낼 번 작품, 그들은 좋아지고 시작합니다.
>> 그리고 그것에 대해 재미있는 것은 그것까지, 선 종류 무엇
우리는 기술 채용 곡선을 호출합니다.
그래서 우리가 무슨 일입니다 어떤 종류의 기술 트리거.
베이스의 경우, 이 데이터 압력이다.
우리는 높은 물 점에 대해 이야기 시간에 걸쳐 데이터의 압력.
그 데이터는 소정의 압력을 안타 점, 즉 기술 트리거입니다.
>> 그것은 너무 비싸지고있다.
데이터를 처리하는 데 너무 오래 걸린다.
우리는 더 나은 뭔가를해야합니다.
당신은 혁신을 얻을 거기에 주위를 실행,
솔루션의 무엇을 찾기 위해 노력.
새로운 아이디어는 무엇입니까?
>> 가장 다음은 뭐지 이 일을 할 수있는 방법은?
그리고 그들은 무엇인가 생각해.
그리고 진짜 고통과 사람들, 출혈 가장자리에 사람,
그들은 그 위에 모든 점프 것이다, 그들은 대답을해야하기 때문이다.
이제 필연적으로 happens-- 무엇을 그것은 NoSQL에에서 지금 무슨 일이 일어나고.
나는 모든 시간을 참조하십시오.
>> 어떤 필연적으로 발생하는 것은 사람들은 새로운 도구를 사용하여 시작
동일한 방법은 이전 도구를 사용했다.
그리고 그들은 그것을 알아 잘 작동하지 않습니다.
나는 내가 누군지 기억이 안나요 오늘 아침에 얘기합니다.
하지만, 때 등이다 착암기가 발명되었다,
사람들은 그것을 통해 스윙을하지 않았다 그들의 머리는 콘크리트를 분쇄합니다.
>> 하지만 그 무엇이다 오늘 NoSQL에 일어나고.
당신은 대부분의 상점에 걸 으면, 그들은 NoSQL에 상점으로 노력하고 있습니다.
그들이하고있는 것은 그들은, NoSQL에를 사용하는
그리고 그들은 그것을로드하는 관계형 스키마의 전체.
그 방법이기 때문에 그들은 데이터베이스를 설계합니다.
그리고 그들은 왜, 궁금해 아주 잘 수행하지?
소년이 일이 냄새.
나는 모든을 유지했다 나의 그것은 아니, 아니, 같은입니다 in-- 합류했다.
조인 유지?
왜 당신은 데이터에 합류?
당신은 NoSQL에 데이터를 조인하지 않습니다.
당신은 그것을 집계.
>> 당신이이 문제를 방지하려면, 배울 그래서 이 도구는 실제로 전에 작동하는 방법
그것을 사용하기 시작.
시도하고 새로운 도구를 사용하지 마십시오 같은 방법으로 당신은 기존의 툴을 사용했다.
당신은 나쁜 경험이 될 것입니다.
그리고 매번 즉,이에 대해 무엇이다.
우리가 여기에 오는 시작할 때, 사람들이 알아 낸 때문입니다
어떻게 도구를 사용합니다.
>> 그들은 때 같은 일을했다 관계형 데이터베이스가 발명되었다,
그들이 파일 시스템을 대체 하였다.
이들 파일 시스템을 구축하려고 관계형 데이터베이스와
그 사람들이 이해 무엇 때문입니다.
그것은 작동하지 않았다.
모범 사례를 이해 그래서 기술을 사용하면 작업중인
거대하다​​.
매우 중요.
>> 그래서 우리는 DynamoDB의에 들어갈 것입니다.
DynamoDB의는 AWS의의입니다 NoSQL에 플랫폼을 완벽하게 처리했다.
무엇을 의미를 완벽하게 관리 하는가?
그것은 당신이 할 필요가 없습니다 의미 정말 아무것도 걱정.
>> 당신은 와서, 당신이 말해 우리는, 나는 테이블이 필요합니다.
그것은이 많은 용량을 필요로한다.
당신은 버튼을 누르면, 우리 제공 장면 뒤에 모든 인프라를 제공합니다.
지금은 거대하다.
>> 당신이 말할 때 때문에 데이터베이스에 대한 스케일링,
NoSQL에 데이터 클러스터에 규모, 실행 페타 바이트,
수백만을 실행 초당 트랜잭션,
이런 일들은 작은 클러스터되지 않습니다.
우리는 인스턴스의 수천을 얘기.
인스턴스의 수천을 관리, 심지어 가상 인스턴스
엉덩이에 진짜 고통이다.
나는 모든 시간에 대해 생각 의미 운영체제 패치 나온다
또는 데이터베이스의 새로운 버전.
그게 무슨 뜻 이죠 당신에게 운영 체제는?
즉, 1,200있어 의미 필요가 서버를 업데이트 할 수 있습니다.
지금도 자동화, 즉, 시간이 오래 걸릴 수있다.
즉 많이 발생할 수 운영 두통,
나는 서비스를해야 할 수도 있기 때문이다.
>> 나는 이러한 데이터베이스를 업데이트 할 때, 나는 푸른 녹색 배포 할 수 있습니다
어디 배포 및 업그레이드 반 내 노드는 다음 나머지 절반을 업그레이드.
그 아래로 가라.
그래서 인프라 관리 규모는 엄청난 고통이다.
그리고 AWS는 그것의 고통을.
그리고 NoSQL에 데이터베이스를 수 매우 고통
그들이 확장 방식 때문이다.
>> 수평으로 확장 할 수 있습니다.
당신은 더 큰 NoSQL에를 얻고 싶다면 데이터베이스는, 당신은 더 많은 노드를 구입할 수 있습니다.
당신이 살 모든 노드는 다른 운영 두통.
그래서 다른 사람이 당신을 위해 그렇게 할 수 있습니다.
AWS는 그 작업을 수행 할 수 있습니다.
>> 우리는 문서의 키 값을 지원합니다.
이제 우리는 너무 많이 가지 않았다 다른 차트에.
다른 많은있다 NoSQL에의 맛.
그들은 점점 모든 종류의 것 이 시점에서 함께 munged.
당신은 DynamoDB의보고 예라고 할 수 있습니다 우리는 문서와 키 값 모두에있어
이 점을 저장합니다.
그리고 당신은 기능을 주장 할 수 있습니다 다른 통해 하나.
나에게,이 많은 정말 여섯입니다 반 다른 다스의.
이 기술 하나 하나가 좋은 기술과 좋은 솔루션입니다.
나는 MongoDB를 더 나은 또는이다 언급하지 않았다 다음 소파, 카산드라보다 더,
다음 디나모, 또는 그 반대.
나는이 그냥 옵션입니다, 의미한다.
>> 그것은 빠르고 그리고 그것은이다 어떤 규모의 일관.
그래서이 가장 큰 중 하나입니다 보너스 당신은 AWS로 얻을.
DynamoDB의와 능력이다 낮은 한 자리를 얻을 수 있습니다
어떤 규모의 밀리 초 대기 시간.
즉, 시스템의 설계 목표였다.
그리고 우리가하고있는 고객이 초당 트랜잭션의 수백만.
>> 지금은 그 중 몇 가지를 통해 갈거야 여기에 몇 분의 경우를 사용합니다.
통합 액세스 control-- 우리는 우리가 부르는이
신원 접근 관리, 또는 IAM.
그것은 모든 시스템을 침투, AWS가 제공하는 모든 서비스를 제공합니다.
DynamoDB의 예외는 아니다.
당신은 액세스를 제어 할 수 있습니다 DynamoDB의 테이블에.
당신의 AWS에 의해 계정 모두에 걸쳐 액세스 역할 및 권한을 정의
IAM 인프라.
>> 그리고 그것은의 키와 필수 구성 요소이다 우리는 기반 프로그래밍 이벤트를 부르는 것.
지금 이것은 새로운 패러다임이다.
>> 청중 : 어떻게 진정한 당신의 속도입니다 위음성 대 양성
액세스 제어 시스템?
릭 리한 (Houlihan) : 참 긍정적 위음성 대?
청중 : 무엇을 반환 당신은 반환되어야 하는가?
한 번에 한 동안 반대로로 이 확인해야 할 때 반환하지 않습니다?
>> 릭 리한 (Houlihan) : 나는 당신에게 그렇게 말할 수 없습니다.
어떤 실패가 있다면 무엇이든지 그에,
내가 요청하는 사람이 아니에요 특정 질문입니다.
그러나 그것은 좋은 질문이다.
알고 궁금 할 것이다 나 자신이, 실제로.
>> 그리고 다시, 새로운 패러다임 이벤트 기반의 프로그램이다.
이것은 당신이 할 수있는 생각이다 복잡한 응용 프로그램을 배포하는
매우, 매우 높은 규모를 조작 할 수 있습니다 어떠한 인프라없이.
어떤 고정하지 않고 어떠한 인프라입니다.
그리고 우리는 조금 얘기하자 즉 우리로 무엇을 의미하는지에 대한
차트의 다음 커플에 도착.
>> 우리가 할 것 먼저 우리는 테이블에 대해 이야기 할 것입니다.
디나모에 대한 API 데이터 유형.
먼저 당신은거야 당신이 볼 때 알,
당신이 데이터베이스에 익숙하다면, 데이터베이스 API를 정말 두 종류가
나는 그것을 호출 할 것입니다.
또는 API의 두 세트.
그 중 하나가 될 것이다 관리 API.
>> 그들이 알아서 일 데이터베이스 기능한다.
스토리지 엔진을 구성, 설정 및 테이블을 추가.
만드는 데이터베이스 카탈로그 및 인스턴스.
DynamoDB의에서이 things--, 당신 매우 짧은, 짧은 목록을 가지고있다.
>> 그래서 다른 데이터베이스에서, 당신은 수십 볼 수 있습니다
행정의 명령, 명령, 구성
이러한 추가 옵션.
DynamoDB의 당신 때문에 그 필요하지 않습니다 시스템을 구성하지, 우리가 할.
그래서 당신이해야 할 유일한 일이다 내가 필요로 하는가의 사이즈 표 말해.
그래서 당신은 매우를 얻을 수 명령의 제한을 설정합니다.
>> 당신은 표 업데이트를 작성 얻을, 표, 테이블을 삭제하고 테이블을 설명하십시오.
사람들은 유일한 것들 당신은 DynamoDB의를 위해 필요합니다.
당신은 저장이 필요하지 않습니다 엔진 구성.
나는 복제에 대해 걱정할 필요가 없습니다.
나는 샤딩에 대해 걱정할 필요가 없습니다.
>> 나는 걱정할 필요가 없습니다 이 물건의 약.
우리는 당신을 위해 모든 작업을 수행 할 수 있습니다.
그래서 오버 헤드의 엄청난 금액이다 그것은 단지 당신의 접시를 해제합니다.
그 다음 우리는 CRUD 사업자가 있습니다.
CRUD 뭔가 우리입니다 데이터베이스의 전화
, 업데이트, 연산자를 삭제 만듭니다.
다음은 일반적인 데이터베이스 작업.
풋 항목 같은 것들, 항목, 업데이 트를 얻을 항목, 항목을 삭제, 일괄 조회, 검사.
당신은 전체 테이블을 스캔합니다.
테이블 오프 모두를 당깁니다.
DynamoDB의 좋은 점 중 하나 이 병렬 검색을 할 수 있습니다.
그래서 당신은 실제로 얼마나 많은 알려 수 있습니다 스레드는 해당 검사에서 실행합니다.
그리고 우리는 그 스레드를 실행할 수 있습니다.
우리는 최대 스캔 회전 수 여러 스레드에서
그래서 당신은 전체 테이블을 스캔 할 수 있습니다 매우, 매우 빠르게 DynamoDB의 공간.
>> 우리가 다른 API입니다 우리는 우리의 스트림 API를 부르는 것.
우리는 너무 얘기하지 않을거야 지금 이것에 대해 많은.
나는 일부 콘텐츠 나중에있어 이 약 갑판에.
그러나 스트림 정말 running--입니다 시간 순서로 생각
및 파티션 변경 로그.
에 일어나는 모든 테이블이 스트림에 표시됩니다.
>> 모든 테이블에 기록 스트림에 표시됩니다.
당신은 그 흐름을 읽고, 수 당신은 그것으로 일을 할 수있다.
우리는 얘기하자 무슨 가지 타입의
복제 같은 것들과는, 보조 인덱스를 생성.
정말 멋진 모든 종류의 이것은 당신이 그와 함께 할 수 있습니다.
>> 데이터 유형.
DynamoDB의, 우리는 모두 키를 지원 가치와 문서 데이터 유형.
화면 왼쪽 여기에, 우리는 우리의 기본 유형을 가지고있다.
키 값 유형.
다음은 문자열, 숫자, 바이너리.
>> 그러니 세 가지 기본 유형.
그리고 당신은 그 세트를 가질 수 있습니다.
좋은 것들 중 하나 NoSQL에이 약 당신은 속성으로 배열을 포함 할 수 있습니다.
그리고 DynamoDB의 당신은 배열을 포함 할 수 있습니다 루트 속성으로 기본 유형의.
>> 그리고 문서 유형이있다.
얼마나 많은 사람들이 JSON을 잘 알고있는?
너무 많은 JSON을 잘 알고 너희들?
그것은 기본적으로 자바 스크립트의 개체 표기법.
그것은 당신이 기본적으로 할 수 있습니다 계층 구조를 정의한다.
>> 당신은에 JSON 문서를 저장할 수 있습니다 DynamoDB의 공통 부품을 사용하여
또는 빌딩 블록을 사용할 수 있습니다 대부분의 프로그래밍 언어이다.
당신이 자바를 가지고 있다면, 당신은있어 지도와 목록을보고.
그 지역지도 개체를 만들 수 있습니다.
키 값으로지도 속성으로 저장.
그리고 목록이있을 수 있습니다 이러한 속성 내에서 값.
이 복잡​​한 저장할 수 있습니다 계층 구조
하나의 특성으로 DynamoDB의 항목.
>> DynamoDB의의 테이블 그래서, 가장 좋아하는 NoSQL에 데이터베이스는 테이블 항목이있다.
MongoDB를 당신은 것 이러한 문서를 호출합니다.
그리고 소파의 기본이 될 것이다.
또한 문서 데이터베이스.
당신은이 문서를 호출합니다.
문서 또는 항목 속성이 있습니다.
속성이 존재하거나 항목에 존재하지.
DynamoDB의에서, 거기에 하나의 필수 특성입니다.
그냥 관계형 데이터베이스처럼, 당신은 테이블에 기본 키를 가지고있다.
>> DynamoDB의 우리가 해시 키를 부르는 있습니다.
해시 키는 고유해야합니다.
그래서 해시 테이블을 정의 할 때, 기본적으로 무슨 말인지
모든 항목들이 해시 키를 가질 것이다.
그리고 모든 해시 키는 고유해야합니다.
>> 모든 항목이 정의된다 그 고유의 해시 키에 의해.
하나만이있을 수있다.
이 확인을하지만, 자주 어떤 사람들이 필요
그들이 원하는 것은이 해시 더 조금 할 키
보다 그냥 고유 식별자.
때때로 우리는 해시 키를 사용할 최고 수준의 통합 버킷있다.
그리고 우리는 그렇게 할 방법입니다 우리는 다양한 키를 부르는 덧붙였다.
>> 그것은 단지 해시의 경우에 따라서 테이블이 고유해야합니다.
이 해시 및 범위 테이블이 있다면, 해시 및 범위의 조합
고유해야합니다.
그래서 이런 식으로 그것에 대해 생각합니다.
나는 포럼이있는 경우.
그리고 형태는이 주제를 가지고 포스트 및 그 응답을 갖는다.
>> 그래서 해시가있을 수 있습니다 주제 ID입니다 키.
그리고 다양한 키가있을 수 있습니다, 이는 응답 ID입니다.
그런 식으로 나는 모든을 얻으려면 특정 주제에 대한 응답,
난 그냥 해시를 조회 할 수 있습니다.
나는 나에게 모든 것을 줄 말을 바로 할 수 있습니다 이 해시가 상품.
그리고 나는 모든 질문을받을거야 또는 특정 주제를 게시합니다.
이러한 최고 수준의 집계 매우 중요하다.
그들은 기본 액세스를 지원 응용 프로그램의 패턴.
일반적으로,이 말하기 우리가하고 싶은 것입니다.
우리는 table--을 원하는 사용자가 테이블을로드로서,
우리는 데이터를 구조화 할 이러한 방식으로 테이블 내의
즉, 응용 프로그램은 매우 수 빨리 그 결과를 검색 할 수 있습니다.
그리고 자주 그렇게 할 수있는 방법입니다 우리는 이러한 집계를 유지하기 위해
데이터를 삽입.
기본적으로, 우리는 데이터를 확산하고 밝은 양동이로는에 온다.
>> 범위 키는 가구 있구만 해시를 허용 키는 평등해야한다.
내가 해시를 조회 할 때, 나는 말을해야 나에게이 동일 해시를 제공합니다.
나는 범위를 조회 할 때, 나에게 범위를 제공 말할 수있다
그 어떤 종류의를 사용하고 있습니다 우리가 지원하는 풍부한 연산자.
나에게 해시에 대한 모든 항목을 지정합니다.
또한,보다 큰 같다 그 시작 않습니다 미만,
이들 두 값 사이에 존재 하는가?
범위 쿼리 그래서 이러한 유형의 우리는 항상 관심이있다.
이제 데이터에 대한 한 가지, 때 당신이 때 데이터에 액세스 보면
사용자가 데이터에 액세스, 그건 항상 집계에 대한.
이 기록에 대해 항상 즉,이 관련되어있다.
여기에 나에게 모든 것을주고 모든 that's-- 이 신용 카드의 거래
지난 달.
즉, 집합입니다.
>> 거의 모든 당신은에서 할 데이터베이스는 집계의 일종이다.
정의 할 수있을 그래서 인 수 이 버킷 당신에게 이러한 범위를 제공
에 쿼리 할 수​​ 속성, 그 풍부한 쿼리는, 많은 지원
많은, 많은 응용 프로그램의 액세스 패턴.
>> 다른 것은 해시 키 그래서 합니까는 우리에게 메커니즘을 제공하다
주위에 데이터를 분산 할 수 있습니다.
NoSQL에 데이터베이스가 최고의 작품 언제 데이터가 균등하다
클러스터에 분산.
얼마나 많은 사람들이 잘 알고있는 해시 알고리즘과?
나는 해시 hashing--를 말할 때 해싱 알고리즘 때문에
생성 할 수있는 하나의 방법은 주어진 값에서 임의의 값입니다.
이 특정한 경우에 따라서, 우리는 실행될 해시 알고리즘 기반 ND 5이다.
>> 그리고 ID를 가지고 있고,이 경우 내 해시 키이며, I는 1, 2, 3을 갖는다.
내가 해시 알고리즘을 실행하면, 그것은, 다시 와서 말 것
도 1, 2와 동일 7B 48 같다 3 CD는 같습니다.
그들은 모든 주요 공간에 걸쳐있어.
그리고 왜 당신이해야합니까?
그 확실하게 그 때문에 내가 할 수있는 여러 노드에 기록을했습니다.
>> 나는이 일을 해요 경우 점진적으로, 1, 2, 3.
그리고 해시 범위가 그 이 특정한 경우에 실행,
작은 해시 공간 그것은, FF 00에서 실행
다음 기록은 올거야 그들이 가려고하는 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12.
무슨 일이야?
모든 인서트는 동일한 노드로 이동된다.
당신은 내가 무슨 뜻인지 볼?
>> 내가 공간을 분할 할 때 때문에, 나는 걸쳐 이러한 레코드를 확산
그리고 파티션, 내가 말할거야 파티션 1은 54 키 공간 0이 있습니다.
파티션 2는 55-89이다.
파티션 3은 FF에 AA입니다.
내가 증가 선형 적으로 사용하고 있다면 ID는, 당신은 무슨 일이 일어나고 있는지 볼 수 있습니다.
1, 2, 3, 4, 5, 6, 54 행까지 모든 방법.
나는 망치거야 그래서 시스템에 기록,
모든 것이 하나의 노드에가는 끝납니다.
>> 그 좋지 않다.
즉 반 패턴입니다.
MongoDB를 그들은이 문제가 당신은 해시 키를 사용하지 않을 경우.
MongoDB를 당신에게 옵션을 제공합니다 의 키 값을 해싱​​.
당신은 항상 경우, 그렇게해야 당신은 증가하는 해시를 사용하고
MongoDB의 핵심은, 또는 당신이있을거야 하나의 노드에 모든 기록을 못 박는,
당신은 제한 될 것 심하게 당신의 쓰기 처리량.
>> 청중 : 소수에 그 A9 169인가?
>> 릭 리한 (Houlihan) : 그래, 그것의 어딘가에 주변.
A9, 나도 몰라.
당신은 내 바이너리를 얻을 수있는 것 소수점 계산한다.
나의 뇌는 그런 식으로 작동하지 않습니다.
청중 : 그냥 빨리 하나 당신의 몽고 코멘트.
그래서 제공되는 오브젝트 ID입니다 기본적으로 몽고에 해당합니까?
릭 리한 (Houlihan) : 그것은 그렇게합니까?
당신은 그것을 지정합니다.
MongoDB를 사용하면 옵션이 있습니다.
당신은에있는 모든 문서를 specify-- 수 있습니다 MongoDB를 밑줄 ID를 가지고 있습니다.
즉, 고유 한 값입니다.
>> MongoDB를에서 지정할 수 있습니다 그것을 해시 여부를.
그들은 단지 당신에게 옵션을 제공합니다.
당신은 그것의 알고있는 경우 랜덤, 아무 문제 없습니다.
당신은 그렇게 할 필요가 없습니다.
당신은 것으로, 임의 아니라고 알고있는 경우 이 증가있어, 다음 해시를 수행.
>> 이제 일에 대한 당신이 해시하면, 해시
value--이입니다 왜 해시 키는 항상
독특한 쿼리, 나는 변경했기 때문에 값은, 지금은 범위 쿼리를 수행 할 수 없습니다.
나는이는 말할 수 없다 이 또는 그 사이에,
해시 값이 진행되지 않기 때문에 실제 값에 해당합니다.
그래서 그 해시 때 키, 그것은 단지 평등이다.
이것은 왜 DynamoDB의 해시 키에 쿼리는 항상 유일한 평등이다.
>> 그래서 지금 범위 key-- 그 범위 키를 추가 할 때,
그 범위 키 기록이 모두 와서 그들은 같은 파티션에 저장 얻을.
그래서 그들은 쉽게 매우 빠르게 아르 이 때문에 해시 검색된
이는 범위이다.
그리고 당신은 모든 것을 볼 같은 해시
같은 파티션 공간에 저장됩니다.
당신은 수 있도록 그 범위의 키를 사용할 수 있습니다 부모에 가까운 데이터를 찾습니다.
그래서 난 정말 여기서 뭐하는 거지?
이것은 많은 관계입니다.
해시 키 간의 관계 및 범위 키가 많은 하나입니다.
나는 여러 해시 키를 가질 수 있습니다.
난 단지 여러 범위를 가질 수있다 모든 해시 키 내에서 키.
>> 해시는 부모를 정의, 범위는 어린이를 정의합니다.
그래서 당신이 볼 수있는 아날로그는 여기에있다 관계형 구조 사이
및 동일한 유형 NoSQL에에 구성한다.
사람들은 이야기 비 관계형으로 NoSQL에.
그것은 비 관계형 아니다.
데이터는 항상 관계를 맺고있다.
그 관계 단지 다른 모델링된다.
의 조금 얘기하자 내구성에 대한 비트.
당신이 DynamoDB의에 쓸 때, 기록 항상 세 방향 복제됩니다.
우리는 세 개의 알파벳 순의가 있음을 의미한다.
AZ의 가용성 영역입니다.
당신은 가용성 생각할 수 데이터 센터로서 존
데이터 센터 또는 모음.
이런 일들은 지리적으로 있습니다 서로 분리
다른 장애 영역에 걸쳐 가로 질러 전력망과 범람원 다른.
하나 AZ의 실패는 아니다 다른를 걸릴 것.
또한 연결되어 함께 다크 파이버와.
그것은 하나의 서브 지원 1 AZS 사이의 밀리 초 대기 시간.
따라서 실시간 데이터 복제 멀티 AZS에서 할 수.
>> 그리고 자주 다중 AZ 배포 고 가용성 요구 사항을 충족
대부분의 기업 조직의.
그래서 DynamoDB의 확산된다 기본적으로 세 가지 AZS에서.
우리는 지식 쓰기에가는거야 그 세 개의 노드의 두 돌아올 때
내가 그것을 가지고, 그래, 말한다.
그 이유는 무엇입니까?
읽기 측에 우리가이기 때문에 단지 때 다시 당신에게 데이터를 제공하는 것
우리는 두 개의 노드에서 그것을 얻을.
>> 나는 걸쳐 복제하고있어 경우 세, 나는 두에서 읽고 있어요,
나는 항상 보장 해요 적어도 하나를 갖도록
그은을로 읽는의 데이터의 최신 사본.
즉 DynamoDB의 일관성을 만드는거야.
이제 설정을 선택할 수 있습니다 그 일관성이 꺼 읽습니다.
이 경우 내가 말할거야, 나는 단지 하나의 노드에서 읽을 수 있습니다.
그리고 나는거야 보장 할 수 없습니다 가장 최근의 데이터가 될 수 있습니다.
>> 쓰기에오고 있다면, 그것은 아직 복제되지 않은
당신은 그 사본을 얻을 것입니다.
즉, 결국 일관된 읽기입니다.
그리고 무엇 즉 것은 절반의 비용입니다.
그래서이 생각하는 무언가이다.
언제 DynamoDB의를 판독하고있어 당신은 당신의 읽기 능력을 설정하는
단위는, 당신은 결국 선택하는 경우 일관성, 그것은 훨씬 저렴 읽기
그것은 약 절반의 비용입니다.
>> 그리고 그것은 당신이 돈을 절약 할 수 있습니다.
그러나 그것은 당신의 선택이다.
일관된 읽기를 원하는 경우 또는 결국 일관된 읽기.
그것은 당신이 선택할 수있는 일입니다.
>> 의 인덱스에 대해 얘기하자.
그래서 우리는 언급 최고 수준의 통합.
우리는 해시 키를 얻고, 한 우리는 범위 키를 가지고있다.
그건 좋은 데요.
그리고는, 기본 테이블에의 I 하나의 해시 키를 가지고, 나는 1 범위 키를 얻었다.
>> 그게 무슨 뜻 이죠?
나는 하나의 속성을 가지고 그 나는 에 대한 풍부한 쿼리를 실행할 수 있습니다.
그것은 범위 키입니다.
그 item--에 다른 속성 나는 그 속성을 필터링 할 수 있습니다.
하지만, 그것을 일을 같이 할 수 없어 로 시작하거나보다 크다.
>> 나는 어떻게해야합니까?
나는 인덱스를 만들 수 있습니다.
두 가지 유형의 DynamoDB의에서 인덱스.
인덱스는 정말 테이블의 다른보기.
그리고 로컬 보조 인덱스.
>> 우리가 얘기하자 첫 번째.
그래서 지역의 보조가 공존 데이터와 동일한 파티션.
등과 같은, 그들에 아르 동일한 물리적 노드입니다.
그들은 우리가 일관 부르는 있습니다.
의미, 그들은 인정합니다 테이블과 함께 쓰기.
기록이 들어 오면, 우리는 색인을 통해 쓸 것이다.
우리는 테이블에 쓸 수 있습니다 그리고, 우리는 인정한다.
그래서 일관성이다.
쓰기되면 테이블에서 인정
그것은 보장이야 로컬 보조 인덱스
데이터의 동일한 시야를 가질 것이다.
하지만 그들이 할 수 당신이 할 것은 대체 범위 키를 정의합니다.
>> 동일한 해시를 사용해야합니다 기본 테이블로 키,
그들이 있기 때문에에 함께 배치 같은 파티션, 그들은 일관성입니다.
하지만 인덱스를 만들 수 있습니다 다른 범위 키.
그래서 예를 들어,에게 나는 제조업체를했다 즉 원시 부품 테이블이오고 있었다.
그리고 원시 부분에오고, 그들은 조립하여 집계하고 있습니다.
그리고 어쩌면 리콜있다.
>> 이에 의해 만들어진 모든 부분 이 날짜 이후 제조 업체,
내 선에서 당겨해야합니다.
나는 인덱스를 회전 할 수 있습니다 즉,보고 할 것
일에 집계 특정 부품의 제조.
내 최고 수준의 테이블이 있다면 그래서 이미 제조 업체에서 해시,
어쩌면 그것은 내가, 부품 ID에 배치되었다 해당 테이블 오프 인덱스를 만들 수 있습니다
제조업체에서 해시로 및 제조 날짜였다.
그리고 내가 말할 수있는 방법, 아무것도 그 이 날짜 사이에 제조 된,
나는 선에서 당겨해야합니다.
그래서 로컬 보조 인덱스입니다.
>> 이들의 효과를 가질 당신의 해시 키 공간을 제한.
그들이 있기 때문에 공존 동일한 스토리지 노드,
이들은 해시 키를 제한 10기가바이트에 공간.
DynamoDB의, 아래 테이블은 파티셔닝
테이블마다 10기가바이트.
당신은 데이터의 10 기가에 넣을 때, 우리 [PHH]을 가고, 우리는 또 다른 노드를 추가 할 수 있습니다.
>> 우리는 LSI를 분할하지 않습니다 여러 파티션에서.
우리는 테이블을 분할합니다.
그러나 우리는 LSI를 분할하지 않습니다.
그 뭔가 그래서 이해하는 것이 중요합니다
당신은 매우 일을하는 경우입니다, 매우, 매우 큰 집계,
당신은 제한 될거야 당신의 LSI에 10 기가 바이트.
>> 그 경우, 우리는 할 수 글로벌 보조를 사용합니다.
글로벌 보조은 정말 다른 테이블.
그들은에 떨어져 완전히 존재 기본 테이블의 측면.
그리고 그들은 저를 찾을 수 완전히 다른 구조.
데이터가 삽입되고 그래서 그것을 생각 두 개의 서로 다른 테이블로, 구조화
두 가지 방법으로.
>> 나는 완전히를 정의 할 수 있습니다 다른 해시 키.
나는 완전히를 정의 할 수 있습니다 다른 범위의 키.
그리고 나는 이것을 실행할 수 있습니다 완전히 독립적으로.
사실, 나는했습니다 내 읽기 능력을 프로비저닝
및 용량을 쓰기 내 글로벌 보조 인덱스
완전히 독립적으로 내 기본 테이블.
내가 그 인덱스를 정의하면, 알 그것은 얼마나 많은 읽기 및 쓰기
용량은 사용하는 것입니다.
>> 그리고는 별도입니다 내 기본 테이블에서.
이제 인덱스 모두에 우리를 수 뿐만 아니라, 해시 및 범위 키를 정의
그러나 그들은 우리를 수 값을 추가로 예상된다.
내가 인덱스를 읽어들이는 경우 그래서, 나는 일부 데이터 세트를 얻으려면,
나는 주에 다시 갈 필요가 없습니다 표는 추가 속성을 얻을 수 있습니다.
나는 그 추가를 투사 할 수 있습니다 테이블에 속성
액세스 패턴을 지원합니다.
나는 우리가 아마 들어갈 거 알아 정말, 잡초로 점점 really--
여기에이 물건의 일부에.
지금은이 밖으로 표류하게되었다.
>> 청중 : [들리지] --table 키 해시는 것을 의미했다?
원래 해시?
멀티 칸막이?
>> 릭 리한 (Houlihan) : 예.
네.
테이블 키 기본적으로 다시 항목을 가리 킵니다.
그래서 인덱스는 포인터로 돌아 테이블에 원래 항목.
지금 당신을 구축하도록 선택할 수 있습니다 단지 테이블 키가 인덱스
및 다른 속성.
그리고 나는 그 이유를 할 수 있는가?
글쎄, 어쩌면 내가 매우 큰 항목이 있습니다.
>> 정말 만 알 필요가 which-- 내 액세스 패턴은 말할 수
어떤 항목이 속성을 포함?
항목을 반환 할 필요가 없습니다.
난 그냥 알아야 어떤 항목이 포함되어 있습니다.
그래서 당신은 인덱스를 구축 할 수 있습니다 만 테이블 키가 있습니다.
>> 하지만 주로 무엇을의 데이터베이스의 인덱스입니다.
그것은 신속하게 할 수있는 대한의 , 레코드를 식별
행을, 어떤 테이블의 항목이
내가 찾고 있어요 속성.
>> 국제 대학원, 그래서 그들은 어떻게 작동합니까?
국제 대학원은 기본적으로 비동기.
이 업데이트는 테이블에 온다, 테이블은 비동기 적으로 업데이트됩니다
당신의 국제 대학원의 모든.
국제 대학원은 이유입니다 결국 일관성.
>> 이 점에 유의하는 것이 중요하다 때 국제 대학원을 구축하고,
당신은 당신이 만드는 이해 aggregation--의 또 다른 차원
지금의 좋은 예를 가정 해 봅시다 여기에 제조 업체입니다.
내가 이야기 한 것 같아요 의료 기기 제조업체.
의료 기기 제조업체 자주 직렬화 된 부분이있다.
에 들어갈 부품 고관절 교체 모든
그들에 약간의 일련 번호를 가지고있다.
그리고 그들은 수백만을 가질 수 및 수백만 및 부품 수십억
그들이 제공하는 모든 장치에서.
글쎄, 그들은에서 집계 할 필요가 다른 치수, 모든 부품
어셈블리의 모든 만들어진 부품
특정 라인에, 모든 제공된 부품
특정 제조업체에 특정 날짜에.
때때로 그리고이 집계 수십억에 일어나.
>> 그래서 몇 가지 작업 고통이 녀석
그들이 만드는 때문에 이 ginormous 한 집계
자신의 보조 인덱스에서.
그들은 원시 부분이있을 수 있습니다 만 해시로 제공 테이블.
각 부분은 고유 한 일련 번호가 있습니다.
나는 해시로 일련 번호를 사용합니다.
그것은 아름답다.
내 원 데이터 테이블 퍼진다 모든 주요 공간에서.
나의 [? 쓰다 ?] [? 섭취는?] 굉장합니다.
I는 많은 데이터를 가지고.
그런 다음 그들이 그들이 GSI를 만들 수 있습니다.
그리고 내가 볼 필요가, 당신은 무엇을 알고, 말 이 제조업체에 대한 모든 부분.
그런데, 갑자기 내가 해요 억 행을 복용,
과에 그들을 물건 하나의 노드, 때 때문에
나는로 집계 해시 등의 제조 업체 ID,
및 범위 등의 부품 번호, 그때 난 갑자기
에 억 부분을 넣어 무엇을 이 업체는 나에게 전달하고있다.
>> 즉 많이 발생할 수 있습니다 GSI에 압력,
다시, 나는 하나의 노드를 망치 야하기 때문이다.
나는 모든이를 걸었습니다 하나의 노드에 삽입합니다.
그리고 진짜 문제가 유스 케이스입니다.
지금, 나는 좋은 디자인을 가지고 당신이를 방지하는 방법에 대 한 패턴입니다.
그리고 그 문제 중 하나 나는 항상 작동있다.
무슨 일하지만, GSI는 할 수있다 충분한 기록 용량을 가지고 있지
모든 사람을 밀어 수 있도록 단일 노드에 행.
그리고 무엇 다음 발생하는 것은 일차, 클라이언트 테이블
기본 테이블이 조절됩니다 GSI는 유지할 수 없기 때문에.
그래서 내 삽입 속도는 것 기본 테이블에가
내 GSI는 계속 시도로.
>> 좋아, LSI의, GSI의 때문에, 나는 어느 하나를 사용해야합니까?
LSI의는 일치한다.
GSI의 결국 일치한다.
그 괜찮아, 난을 사용하는 것이 좋습니다 GSI는 이들이 훨씬 더 유연한 것.
LSI의은 GSI 같이 모델링 될 수있다.
그리고 만약 해시 키 당 데이터 크기 컬렉션 10 기가 바이트 초과
당신은 것을 사용하려는거야 GSI 그냥 하드 제한 왜냐하면.
>> 좋아요, 스케일링.
디나모 DB에서 처리량, 당신 캔 제공 [들림]
테이블에 처리량.
우리는이 고객이 비전 60 billion--
정기적으로, 600 억 요청을하고있다 만 이상의 요청을 실행
우리의 테이블에 초.
아니 정말로있다 에 대한 이론적 인 한계 얼마나
그리고 얼마나 빨리 테이블 디나모 DB에 실행할 수 있습니다.
일부 부드러운 있습니다 귀하의 계정에 대한 제한
우리가 거​​기에 넣어 그 것을 당신은 미쳐하지 않습니다.
당신은 이상합니다 즉, 문제가되지 않는다.
당신은 우리에게 온다.
우리는 다이얼을 설정합니다.
>> 모든 계정은 일정 수준으로 제한된다 모든 서비스에 바로 박쥐
그래서 사람들은 미쳐하지 않습니다 곤경에 자신을 얻을.
크기에 제한 없음.
당신은 어떤 수를 넣을 수 있습니다 테이블의 항목.
아이템의 크기는 4백킬로바이트 각각 한정
그 항목이 아닌 속성이 될 것이다.
모든 속성의 합계 그래서 400킬로바이트로 제한됩니다.
그리고 다시, 우리가 그 작은 LSI 문제
해시 당 10 기가 바이트 한계.
청중 : 소수, 나는 실종 해요 무엇 당신은 나를 말하는 거 is--
청중 : 아, 4백킬로바이트 항목 당 최대 크기이다.
그래서 항목은 모든 특성을가집니다.
그래서 400 K는 전체 크기는 해당 항목의, 4백킬로바이트.
모든 속성의 그래서 결합 된 모든 데이터
그 모든 속성에있어, 전체 크기로 올리고,
오늘 현재 항목 제한은 400 K이다.
그래서 달성, 다시 확장 파티셔닝을 통해.
처리량 프로비저닝 테이블 수준에서.
정말 두 개의 손잡이가있다.
우리는 용량을 읽고 용량 물품.
>> 그래서 이러한 조정 서로 독립적.
RCU의 조치는 엄격하게 일관성을 읽습니다.
좋아, 그래서 만약 내가 1000을 원하는 말을하는지 RCU의 사람들은, 엄격하게 일치
사람들은 일관된 읽기입니다.
당신은 내가 원하는 말한다면 일관된 결국은 읽고
당신이 제공 할 수있는 1,000 RCU의, 당신은거야
결국 2,000을 얻을 수 일관성을 읽습니다.
그리고 그 절반 가격 결국에 읽기로 구성되어 있습니다.
>> 다시 말하지만, 조정 서로 독립적.
그리고 그들은 throughput--이 당신이 당신의 RCU의 100 %를 소비하는 경우,
당신은 영향을하지 않을거야 권리의 가용성.
그래서 그들은 완전히 있습니다 서로 독립적.
좋아, 그래서 것들 중 하나가 나는 간단히 조절 있다고 말했습니다.
스로틀은 나쁘다.
스로틀은 SQL을 나쁜 나타냅니다.
우리가 도울 수있는 일이있다 당신은 제한을 완화 당신을
경험하고 있습니다.
그러나 가장 좋은 방법 이것의가 보자입니다
때문에, 당신이 무슨 일을하는지 살펴 여기에 연극에서 반 패턴이있다.
>> 이러한 것들은, 비 균일 같은 것들 워크로드, 핫 키, 핫 파티션.
나는 특정 키 공간을 치는거야 열심히 어떤 특별한 이유.
내가 왜이 일을하고있다?
의 그 알아낼 수 있습니다.
나는 감기 데이터를 내 뜨거운 데이터를 혼합하고 있습니다.
나는 나의 표를 얻을시키는거야 거대한, 그러나 거기에 정말
데이터의 일부 서브 세트 그는 나에게 정말 흥미.
그래서의 로그 데이터를, 예를 들면, 많은 고객, 그들은 매일 로그 데이터를 얻을.
그들은 로그 데이터의 엄청난 금액을 얻었다.
>> 당신은 모든 로그를 덤프하는 경우 시간이 지남에 따라 하나의 큰 테이블에 데이터,
그 표는 대규모 얻을 것입니다.
하지만 난 정말에만 관심이 있어요 지난 24 시간, 지난 7 일
지난 30 일.
시간의 무엇이든간에 창 나는보고에 관심이 있음
날 귀찮게하거나 이벤트 나에게 흥미로운 이벤트,
그게 내가 필요한 유일한 창 시간이다.
그래서 왜 10 년을 걸었습니다 테이블에 로그 데이터의 가치?
무슨이 발생하는 것입니다 테이블 조각.
>> 그것은 거대한 가져옵니다.
그것은 밖으로 확산 시작 수천 개의 노드에서.
그리고 용량부터 당신은, 그래서 낮
실제로 각 제한 속도 그 각각의 노드 중 하나.
그럼 어떻게보고 시작하자 우리가 이상 해당 테이블을 롤백 할.
우리는 데이터 조금을 관리하는 방법 더 나은 이러한 문제를 방지 할 수 있습니다.
그리고 그 무엇처럼 보이나요?
이 그 모습이다.
이것은 나쁜 NoSQL에의 모습입니다.
>> 여기 핫 키를 얻었다.
여기 측면에 보면, 이러한 내 모든 파티션입니다.
여기 16 파티션을 가지고 이 특정 데이터베이스에.
우리는이 모든 시간을.
나는 고객을 위해 모든 시간을이 작업을 실행합니다.
그것은 열지도라고.
열지도 당신이있어 어떻게 나에게 말한다 키 공간에 접근.
그리고 이것이 나에게 말하고 것은 하나의 특정 해시가 있음
이 사람을 좋아하는 엄청 많이, 그 때문에
정말 열심히, 정말 타격.
>> 그래서 파란색 좋은 것입니다.
우리는 푸른 좋아한다.
우리는 붉은 좋아하지 않는다.
레드의 경우 압력 100 %까지 가져옵니다.
100 %가, 지금은 스로틀 될 것입니다.
그래서 당신은 같은 어떤 빨간색 선을 볼 때마다 이 항아리와 단지 디나모 DB-- 아니다
모든 NoSQL에 데이터베이스가이 문제를 가지고있다.
안티 패턴은 할 수있다 조건 이러한 유형의 드라이브.
내가하는 일은 내가 고객과 함께 작업입니다 이러한 조건을 완화합니다.
>> 그리고 그 무엇처럼 보이나요?
그리고 이것은 가장을 받고있다 디나모 DB 처리량 중,
하지만 정말 점점 NoSQL에 최대한.
이것은 디나모에 제한되지 않는다.
이 definitely-- 내가있다 몽고에서 일을하는 데 사용됩니다.
나는 많은 NoSQL에 플랫폼에 익숙 해요.
모든 사람은 이러한 유형이 있습니다 핫 키 문제.
어떤 NoSQL에 최대한 활용하려면 데이터베이스, 특히 디나모 DB,
당신은 테이블을 만들려면 여기서 해시 키 요소 갖는다
고유 값 다수 기수의 높은 수준.
그게 내가 쓰고 있어요 의미하기 때문에 다른 버킷을 많이합니다.
>> 난 더 버킷 , 가능성에 쓰기
나는 그 쓰기로드를 분산하기 위해 오전 또는 여러 노드에 걸쳐로드 읽기,
가능성이 난을 가지고입니다 테이블에 높은 처리량.
그리고 나는 값이 원하는 시간이 지남에 따라 상당히 고르게 요청
균일하게 무작위로 가능.
글쎄, 그건, 가지 흥미로운 때문에 내가 할 수없는 정말
제어 사용자가 올 때.
우리가 퍼져 있다면, 말을 충분 키 공간에서 일 밖으로,
우리는 아마 더 나은 모양에있을 것이다.
>> 어떤이있다 시간 배달의 양
당신은하지 않을거야 것을 수 제어 할 수 있습니다.
하지만 그 정말입니다 우리는이 두 가지 차원,
공간, 액세스 균일 확산, 시간, 요청
균등하게 시간 간격으로 도착.
그리고 그 두 가지 경우 조건이 충족되고,
그 다음은 무엇입니다 처럼 보이는 것.
이 훨씬 좋네요.
우리는 여기에 정말 행복합니다.
우리는 매우에도 액세스 패턴을 가지고있다.
그래, 어쩌면 당신이 있어요 작은 압력 이제 다음 각,
하지만 아무것도 정말 너무 광범위한.
그래서, 몇 번 놀라운 나는 고객과 작업 할 때,
큰 빨간 첫 번째 그래프 바, 모든 즉, 노란색의 추한
도처에, 우리 운동으로 완수
몇 달 후 재 건축,
그들은 동일한를 실행하는 동일한 부하에서 부하.
그리고 이것은 지금처럼 찾고 것입니다.
그래서 당신은 NoSQL에 함께 얻을 것은 절대적 데이터 스키마
액세스 패턴에 묶여.
>> 그리고 당신은 그 데이터 스키마를 최적화 할 수 있습니다 그 액세스 패턴을 지원합니다.
그렇지 않으면, 당신은거야 이런 종류의 문제를 볼 수 있습니다
그 뜨거운 키.
>> 청중 : 음, 불가피하게 일부 지역 다른 사람보다 더 뜨거운 될 것입니다.
>> 릭 리한 (Houlihan) : 항상.
항상.
그래, 난 항상 거기에 의미 그럼하지 머 다시, 거기에
어떤 디자인 패턴은 우리를 통해 얻을 것이다 즉, 처리 방법에 대해 이야기합니다
이러한 초대형 집계와.
내 말은, 나는 그들을 가지고있어 우리는 그들과 함께 어떻게 처리합니까?
나는 꽤 좋은 유스 케이스를 가지고 우리는 그것에 대해 이야기거야.
>> 좋아, 그렇게하자의 이야기 지금에 대한 일부 고객.
이 녀석은 AdRoll 있습니다.
당신이 있다면 나도 몰라 AdRoll을 잘 알고.
당신은 아마 그들을 볼 브라우저에 많은.
그들은있어, 광고 재 타겟팅 가장 큰 광고 재 대상 사업
저 밖에.
그들은 일반적으로 정기적으로 이상 실행 하루에 600 억 거래.
그들은 백만 이상의 일을하는지 초당 트랜잭션.
그들은 아주 간단한 테이블을 가지고 구조, 가장 바쁜 테이블.
그것은 기본적으로 그냥 해시 키, 쿠키입니다
범위는 인구 통계 학적이다 카테고리 다음
세 번째 속성은 점수입니다.
>> 그래서 우리 모두는 쿠키를 이 사람들로부터 우리의 브라우저.
그리고 당신은에 갈 때 상인 참여,
그들은 기본적으로 가로 질러 당신 점수 다양한 인구 통계 학적 범주.
당신이 웹 사이트에 갈 때와 당신은 내가이 ad--를 참조하고 싶은 말은
또는 기본적으로 당신은 that--을 말하지 않는다 그러나 당신은 웹 사이트를 방문 할 때
그들은 당신이 광고를보고 싶지 말한다.
그리고 그들은 AdRoll에서 해당 광고를 가서.
AdRoll은 테이블에 당신을 보인다.
그들은 당신의 쿠키를 찾을 수 있습니다.
이야기 광고주 그들, 나는 누군가를 원한다
누가, 중년의 스포츠에 40 세의 남자.
그리고 그들은 그 인구 통계에 당신을 점수 이들은 여부를 결정
그것은 당신을 위해 좋은 광고입니다.
>> 이제 그들은 SLA와이 자신의 광고 제공
서브 10 밀리 초를 제공하는 모든 단일 요청에 응답.
그래서 그들은이에 대한 디나모 DB를 사용하고 있습니다.
그들은 우리를 타격하고 초당 만 요청.
그들은 모든 일을 할 수있어 자신의 조회, 환자 분류 모든 데이터,
그리고 다시 그 추가 링크를 얻을 10 밀리 초 아래에서 광고주.
정말 꽤 놀라운이다 구현 자신이 갖고있다.
>> 이 녀석은 ... 사실상 사람이 있습니다.
나는이 사람들을 만약 확실하지 않다.
이 녀석 될 수 있습니다.
기본적으로 나는, 아니 us-- 말했다 그것은 그들을 생각하지 않습니다.
나는 다른 사람 생각.
나는 함께 일하는 고객이 나에게 말했다 그
이제 그들은했는지 디나모 DB에 갔다, 그들이있어
간식에 더 많은 돈을 지출 자신의 개발 팀 매월
그들의 데이터베이스에 대한 지출보다.
그래서 당신에게 줄거야 비용 절감의 아이디어
당신은 디나모 DB에 얻을 수있는 것은 거대하다.
좋아, dropcam 다른 회사입니다.
이 사람은 종류의 동행입니다 당신이 생각하는 경우이다 사물의 인터넷, dropcam의
기본적으로 인터넷 보안 비디오이다.
당신은 거기에 카메라를 넣어.
카메라는 동작 감지기가 있습니다.
누군가가 따라 온다 큐 포인트를 트리거합니다.
카메라가 잠시까지 녹음을 시작합니다 그것은 더 이상 어떤 움직임을 감지하지 않습니다.
인터넷에 그 동영상을 넣습니다.
>> Dropcam는 기업이었다 기본적으로 디나모 DB로 전환
그들이 경험하고 있기 때문에 엄청난 성장통.
그리고 그들은 우리에게 무엇을, 갑자기 페타 바이트의 데이터.
그들은 아무 생각이 그들의 서비스를 없었다 그렇게 성공적이 될 것이다.
유튜브보다 인바운드 비디오 이 사람들이 점점 것입니다.
그들은 모두를 DynamoDB의 추적을 사용 모든 비디오 주요 지점에 메타 데이터.
>> 그래서 그들은 밀어 S3 버킷을 모든 이진 유물에.
그리고 그들은이 디나모 DB 기록 그
그 S3 세 개체에 사람을 가리 킵니다.
그들은 비디오를보고해야하는 경우, 그들은 디나모 DB에서 레코드를 찾습니다.
그들은 링크를 클릭합니다.
그들은 S3에서 비디오를 아래로 당깁니다.
그래서이 어떻게 생겼는지 가지입니다.
그리고 이것은 자신의 팀에서 직접입니다.
>> 디나모 DB는 감소 비디오 이벤트에 대한 배달 시간
5 ~ 10 초.
그들의 오래된 관계 상점에서, 그들은 가서 실행해야하는 데 사용
그림에 여러 복잡한 쿼리 알아 비디오는, 아래로 당겨
미만 50 밀리 초.
그래서 놀라운, 놀라운 얼마나 성능
당신이 최적화 할 때 당신이 얻을 수 있으며, 를 조정 기본 데이터베이스
액세스 패턴을 지원합니다.
그것을 무엇 Halfbrick,이 사람, 내가 추측 과일 닌자는 것입니다.
디나모 DB에있는 모든 실행되는지.
그리고이 사람들, 그들은 좋은 개발 팀, 큰 발전
가게.
>> 아니 좋은 작전 팀.
그들은 많이하지 않았다 연산 리소스.
그들은 유지하려고 애 쓰고 있었다 자신의 애플리케이션 인프라까지
실행.
그들은 우리에게왔다.
그들은 그 디나모 DB를 바라 보았다.
그들은 그것이 우리의 고 말했다.
그들은 전체를 구축 그것에 응용 프로그램 프레임 워크.
여기에 몇 가지 정말 좋은 코멘트 자신의 능력에 팀
지금 건물에 초점을 게임이 아닌
유지하는 데 인프라, 어떤
엄청난 양의되고 있었다 자신의 팀에 대한 오버 헤드.
그래서이 뭔가 that-- 당신은 디나모 DB에서 얻을 혜택을 누릴 수 있습니다.
>> 좋아,에 점점 여기에 데이터 모델링.
그리고 우리에 대해 조금 이야기 하나이 하나, 많은 하나,
많은 유형의 관계에 많은.
그리고 당신은 어떻게 디나모 사람들을 유지 않습니다.
디나모 DB에서 우리는 사용 인덱스는, 일반적으로,
로부터 데이터를 회전 다른 하나의 맛.
해시 키, 범위 키 및 인덱스.
>> 이 특히 예를 들어, 대부분의 주와 같은
라이선스 요구 사항이 그 사람 당 하나의 운전 면허증.
두 드라이버의를 얻을 갈 수 없어 보스턴의 상태에 라이센스.
나는 텍사스에서 그것을 할 수 없습니다.
즉,이 방법 가지이다.
그래서 운전 면허 시험장에서, 우리는 조회를, 우리 운전 면허증을보고 싶다
사회 보장 번호.
나는 사용자 정보를 조회 할 운전 면허증 번호.
>> 그래서 우리는 사용자의 테이블이있을 수 있습니다 그 일련 번호는 해시 키가,
또는 사회 보장 번호, 다양한 속성은 항목을 정의했다.
이제 테이블 I에 GSI를 정의 할 수있는
그 말한다 주위에 내가 원하는 것을 뒤집 다음 라이센스 및에 해시 키
다른 모든 항목.
지금은 쿼리를 찾으려면 주어진 사회에 대한 라이센스 번호
보장 번호, 내가 할 수있는 기본 테이블을 쿼리합니다.
>> 나는 조회 할 내가 원하는 경우 사회 보장을받을
숫자 나에 의해 다른 속성 라이센스 번호, 나는 GSI를 조회 할 수 있습니다.
이 모델은 하나입니다 한 관계.
그냥 아주 간단한 GSI, 주위 상황을 뒤집습니다.
지금, 많은 약을 말한다.
많은에 하나는 기본적으로 당신의 해시 범위 키.
우리는이와 함께 많이 얻을 경우 사용 사례는 모니터 데이터입니다.
모니터 데이터는 정기적으로 제공 사물의 인터넷과 같은 간격.
우리는 항상 모든이를 얻을 수 기록은 모든 시간에 오는.
>> 그리고 나는 모든 측정 값을 찾으려면 특정 시간주기 사이.
그것은 매우 일반적인 질문입니다 모니터링 인프라.
그것에 대해 방법의 이동을 찾을 수 있습니다 간단한 테이블 구조, 하나의 테이블.
나는 장치 측정 테이블을 가지고 장치 ID에 해시 키.
그리고 난의 범위 키가 타임 스탬프, 또는이 경우, 서사시.
그리고 그 날은 복잡한 실행 허용 그 범위 키에 대한 쿼리
그 레코드를 반환하는 결과를 기준으로합니다
내가 찾는 것을 설정합니다.
그리고 그것은 하나를 구축 많은 관계
를 사용하여 기본 테이블에 해시 키, 범위 키 구조.
>> 그래서 종류의 내장 것 디나모 DB의 테이블에.
나는 해시를 정의 할 때 및 범위 T 테이블, 내가 해요
많은 관계를 형성 할 수있다.
그것은 부모 - 자식 관계이다.
>> 의 많은 대해 얘기하자 많은 관계.
이것은 특히 예를 들어, 다시, 우리는 GSI의를 사용하는 것입니다.
그리고의이 게임에 대해 이야기하자 나는 주어진 사용자가 시나리오.
나는 모든 게임을 찾을 수 원하는 그는 또는 재생 등록합니다.
그리고 주어진 게임, 내가 모든 사용자를 찾고 싶어요.
그래서 내가 어떻게 그렇게 할 수 있습니까?
내 사용자의 게임 테이블, 내가 갈거야 사용자 ID의 해시 키를 갖도록
게임의 범위 키.
>> 따라서 사용자는 여러 게임을 할 수 있습니다.
이 사이에 많은 관계로 하나 사용자와 그가 연주 게임.
그리고 GSI에, 그 주위 플립 것이다.
나는 게임에 해시 테니 나는 사용자에 다양합니다.
나는 모든을 얻고 싶은 경우에 따라서 게임 사용자는, 재생
나는 기본 테이블을 조회 할 수 있습니다.
나는 모든 사용자를 얻고 싶다면 즉, 특정 게임을하고,
나는 GSI를 쿼리합니다.
그래서 우리는이 작업을 수행하는 방법을 참조하십시오?
이러한 GSI는의를 지원하기 위해 구축 사용 사례, 응용 프로그램, 액세스
패턴, 애플리케이션.
>> 나는 쿼리를해야하는 경우 이 차원은하자
내게는 그 차원에 인덱스를 만들 수 있습니다.
내가하지 않으면, 난 상관 없어.
그리고 사용 사례에 따라, 나는 인덱스를 필요로하거나 그럴 수도 있습니다.
그것은 간단한 일이 많은이라면, 기본 테이블은 괜찮습니다.
나는 이러한 많은 작업을 수행해야하는 경우 많은의가, 또는 나는 것들 하나를 수행해야합니다
어쩌면 내가 필요합니까 두 번째 인덱스.
그래서 모두에 따라 달라집니다 난 할 노력하고있어
나는 달성 얻기 위해 노력하고있어.
>> 아마 너무 지출하지 않을거야 많은 시간을 문서에 대해 이야기.
이것은, 아마, 조금 얻는다 깊은 우리에 갈 필요가보다.
의 조금을 얘기하자 대한 풍부한 쿼리 식.
그래서 디나모 DB에 우리는이 만들 수있는 능력
우리는 투사 식을 부르는 것.
프로젝션 표현은 단순히 필드 또는 값을 따기
당신은 표시하도록.
좋아, 그럼 난을 선택합니다.
나는 디나모 DB에 대한 쿼리를 확인합니다.
그리고, 쇼 당신은 무엇을 알고, 말 날에만 5 성급 리뷰
이 특정 제품에 대한.
그래서 내가보고 싶은 모든이다.
나는 모든을보고 싶지 않아 행의 다른 속성,
난 그냥이보고 싶어.
그것은 바로 그 때 SQL에서처럼 당신 선택 스타 또는 테이블에서 말을,
당신은 모든 것을 얻을.
나는에서 선택 이름을 말할 때 표, 나는 단지 하나의 속성을 얻을.
이 물건의 같은 종류의 디나모 DB 또는 다른 NoSQL에 데이터베이스.
필터 표현에 날 수 있습니다 기본적으로 아래로 결과 세트를 잘라.
그래서 쿼리를 확인합니다.
쿼리는 500 항목으로 돌아올 수 있습니다.
그러나 나는 항목 만 원하는 이라는 속성을 가지고있다.
좋아, 그래서 그 항목을 필터링 할 수 즉, 특정 쿼리와 일치하지 않습니다.
그래서 우리는 필터 식을 가지고있다.
>> 필터 식 수 모든 속성에서 실행.
그들은 범위 쿼리를 좋아하지 않을 것입니다.
올리 쿼리는 더 선택적입니다.
필터 쿼리 가라고 요구 전체 결과는 다음 설정 및 취득
내가 원하지 않는 데이터를 개척.
왜 중요한가?
나는 모두를 읽을 수 있기 때문에.
쿼리에서, 내가 읽은거야 및 이 데이터에 대한 거대한 될 것.
그리고 나는 갈거야 내가 필요한 개척.
그리고 나는 단지 밖으로 조각 해요 경우 행의 부부, 그 괜찮아요.
너무 비효율적이 아니다.
>> 하지만 난의 전체 더미를 읽고 있어요 경우 데이터는 단지 하나의 항목을 개척
나는 더 좋을거야 범위 쿼리를 개시,
훨씬 더 선택적 왜냐하면.
그것은 나에게 많이 저장할 것 돈, 내가 그 읽기를 지불하기 때문이다.
어디에서 돌아 오는 결과 작은 수 있습니다 그 선을 넘어,
그러나 나는 읽기를 지불하고있다.
그래서 방법을 이해 당신은 데이터를 가져 오는 것입니다.
즉 디나모 DB에 매우 중요합니다.
>> 조건부 표현이 무엇을이다 당신은 낙관적 잠금을 호출 할 수 있습니다.
업데이트하는 경우가 존재, 또는이 값의 경우 내가 지정하는 것과 동일합니다.
그리고 난에 타임 스탬프가있는 경우 기록, 나는 데이터를 읽을 수 있습니다.
그 데이터를 변경할 수 있습니다.
나는 쓰기를 갈 수도 그 데이터베이스에 데이터 다시.
누군가가 레코드를 변경하는 경우, 타임 스탬프는 변경 될 수 있습니다.
그리고 그런 식으로 내 조건 업데이트는 업데이트를 말할 수
소인이 동일한 경우.
또는 업데이트는 사람 때문에 실패합니다 그 동안의 기록을 갱신했습니다.
>> 그것은 우리가 낙관적 잠금을 부르는.
그것은 그 사람을 의미합니다 와서 변경할 수 있습니다,
나는 그것을 감지하는거야 내가 돌아 갈 때 씁니다.
그리고 나는 실제로 그것을 읽을 수 있습니다 데이터 및 오, 그가이 바뀌 말한다.
나는 그것을 설명하기 위해 필요합니다.
그리고 난의 데이터를 변경할 수 있습니다 내 기록과 다른 업데이트를 적용.
그래서 당신은 그 증가분을 잡을 수 있습니다 시간 사이에 발생하는 업데이트
당신은 데이터를 읽어 시간 당신은 데이터를 쓸 수 있습니다.
>> 청중 : 그리고 필터 표현은 실제로하지 의미
번호 또는 싫든에서
>> [목소리를 개재]
릭 리한 (Houlihan) : 나는하지 않습니다 이에 너무 많이 얻을.
이 예약 된 키워드입니다.
파운드보기는 예약되어 있습니다 디나모 DB의 키워드.
모든 데이터베이스가 자신의 소유 당신이 사용할 수없는 컬렉션의 이름.
디나모 DB를 지정할 경우 이 앞의 파운드,
당신은 위의 그 이름을 정의 할 수 있습니다.
이 참조 된 값입니다.
아마 가장 구문 아니다 이 설명은 거기있다,
그것은 몇 가지 real--에 도착하기 때문에 내가 얘기 한 것보다
더 깊은 수준에서 그것에 대해.
>> 그러나 말을 충분,이 수 그들이 views-- 경우 검색 쿼리 수
나 파운드 뷰는 10보다 크다.
그것은 네, 수치이다.
당신이 원하는 경우에, 우리는 이야기 할 수 있습니다 토론 후 그.
좋아, 그래서 우리는에 있어요 모범 사례에서 몇 가지 시나리오
여기서 우리가 이야기하는거야 여기에 몇 가지 응용 프로그램에 대한.
디나모 DB에 대한 사용 사례는 무엇인가.
디자인은 무엇입니까 디나모 DB에 패턴.
>> 그리고 첫 번째는 우리가 갈거야 에 대한 이야기​​는 사물의 인터넷이다.
내가 추측 동행입니다 그래서 우리는 많이 얻을, 그건 ... 50 % 이상 것입니다
요즘 인터넷에서 트래픽 실제로 기계에 의해 생성된다,
아니 인간이 자동화 된 프로세스.
나는이 일이 일을 의미하는 당신은, 당신의 주머니에 다니는
얼마나 많은 데이터가 그 일이라고 실제로 않고 주위에 전송
그것을 아는 것은 절대적으로 놀랍습니다.
귀하의 위치 정보 얼마나 빨리에 대해 당신은 것입니다.
Google지도 일을 생각하는 방법 그들이 당신을 말할 때 트래픽은 무엇인지.
수백만이 있기 때문에 그것은이고 주위에 운전 수백만의 사람들
보내는 전화와 모든 모든 시간을 여기 저기 데이터.
것들 중 하나 그래서 이러한 유형의 데이터에 대한
즉 오면, 모니터 데이터, 로그 데이터, 시계열 데이터는, 그것의 인
보통 재미 약간의 시간을 위해.
그 시간 후,이를있어 그렇게 재미 있지.
그래서 우리는 할 수없는, 이야기 그 테이블은 무제한으로 증가.
여기에 아이디어는 어쩌면 내가 24을 가지고 있다는 것입니다 내 뜨거운 테이블에서 이벤트의 가치가 시간.
그리고 그 뜨거운 표가 될 것입니다 매우 높은 속도로 프로비저닝,
이 많은 양의 데이터를 가지고 있기 때문에.
이것은 많은 양의 데이터를 복용 그리고 나는 그것을 많이 읽고 있어요.
나는 운전을 많이 가지고 데이터에 대해 실행 쿼리.
>> 24 시간 후 이봐, 당신 난 상관 없어 무엇을 알고있다.
그래서 어쩌면 모든 자정 내가 롤 새 테이블 위에 내 테이블
나는이 테이블을 관리 취소.
내가 할게요 RCU의과 WCU의 아래로 인해 24시간 이상
나는 많은 사람을 운영하지 않는 경우 해당 데이터에 대한 쿼리.
그래서 돈을 절약 할거야.
그리고 어쩌면 삼십일 나중에 내가하지 심지어 모든 걱정 할 필요가있다.
나는 WCU의 걸릴 수 있습니다 하나에 이르기까지 모든 방법,
당신이 알고 있기 때문에, 그것은 무엇 결코 기록 얻을 것 없다.
데이터 30 일 이전입니다.
그것은 변화하지 않았다.
>> 그리고, 읽어 얻기 위하여려고 거의 절대 것 그래서 그냥 10까지 그 RCU 보자.
그리고이 돈의 톤을 절약 해요 데이터는, 단지 내 핫 데이터 지불.
그래서 보는 중요한 일이 한 번 시리즈에서 볼 때의
데이터 볼륨에 들어오는.
이러한 전략이다.
지금, 나는 단지 그것을 할 수 모두 동일한 테이블로 이동
단지 그 테이블 성장 할 수 있습니다.
결국, 내가 갈거야 성능 문제를 참조하십시오.
내가 보관하기 시작해야 할거야 테이블 오프 데이터의 일부,
선반.
>> 의 훨씬 더하자 응용 프로그램을 설계
그래서 당신은 바로 이런 식으로 작동 할 수있다.
그래서 그냥 자동의 애플리케이션 코드.
자정 매일 밤에서 그 테이블 롤.
어쩌면 내가 필요한 것은 슬라이딩입니다 데이터의 24 시간 창.
그리고 정기적으로 나는 해요 테이블 오프 데이터를 호출.
나는 그것을 트리밍 해요 cron 작업과 내가 넣었 어
이러한 다른 테이블 위에, 당신은 무엇을해야.
롤오버가 작동한다면, 그것은 좋아요.
그렇지 않은 경우, 그것을 잘라.
그러나의 그 뜨거운 데이터를 유지하자 멀리 추운 데이터에서.
그것은 당신에게 많은 돈을 절약 할 수 및 당신의 테이블에 더 많은 공연을합니다.
그래서 다음 일은 우리가 얘기하자 에 대한 제품 카탈로그입니다.
제품 카탈로그입니다 꽤 일반적인 사용 사례.
이것은 실제로 매우 일반적인 패턴이다 우리는 사물의 다양한 볼 수있다.
당신을 위해, 트위터를 알고 예를 들어, 뜨거운 트윗.
모두가오고 및 그 트윗을 잡아.
제품 카탈로그, 나는 판매를 얻었다.
나는 뜨거운 판매를 얻었다.
나는 당 70,000 요청을 받았습니다 두 번째 제품에 오는
내 제품 카탈로그 중 설명.
우리는 소매에이 참조 작업 꽤.
그렇다면 우리는 그 처리합니까?
그 다루는 방법은 없습니다.
내 모든 사용자가보고 싶어 동일한 데이터 조각.
그들은 동시에에서 오는 것입니다.
그리고 그들은 모든 요청을 만들고있어 데이터의 동일한 부분에 대한.
이 날을 제공하는 핫 키가 큰 빨간 우리가 좋아하지 않는 내 차트에 스트라이프.
그리고 그 모습이다.
내 키 공간을 통해 내가 받고 있어요 그래서 판매 상품에 망치.
나는 다른 곳에서는 아무것도 받고 없습니다 해요.
>> 이 문제를 어떻게 완화 하는가?
음, 우리는 캐시와이를 완화.
캐시, 당신은 인 메모리 기본적으로 넣어 데이터베이스의 앞에 파티션.
우리는 관리해야 [들림] 캐시, 방법을
자신의 캐시를 설정할 수 있습니다, [들림] 은닉처 [? D,?] 당신이 원하는대로.
데이터베이스의 앞에 그 차 넣었습니다.
그리고 그 방법은 해당 데이터를 저장할 수 있습니다 이 캐시에 최대 사람들 핫 키에서
공간과 캐시를 읽어.
>> 그리고 다음의 대부분은 당신의 읽기 이처럼 보이는 시작합니다.
나는이 캐시는 여기에 모두를 명중있어 나는 아무것도 아래로 여기에 않을있어
데이터베이스는 뒤에 앉아 있기 때문에 캐시와는 나오지 않을 읽습니다.
나는의 데이터를 변경하는 경우 데이터베이스, 나는 캐시를 업데이트해야합니다.
우리는 뭔가를 사용할 수 있습니다 같은 그렇게 하네.
그리고 그 작동 방법을 설명 할 것이다.
좋아, 메시징.
이메일, 우리 모두가 이메일을 사용합니다.
>> 이것은 꽤 좋은 예입니다.
우리는 메시지 테이블의 일종을 가지고있다.
그리고 우리는받은 편지함과 보낸 편지함을 얻었다.
이것은 어떤 SQL을 것입니다 그받은 편지함을 구축하는 모습.
우리는 가지 같은 종류를 사용 GSI의를 GSI의를 사용하는 전략
받은 편지함 내 보낼 편지함에 대한.
그래서 원시 메시지가오고있어 내 메시지 테이블에.
그리고 이것에 첫 번째 방법 수도, 확인 문제, 말을하지 않습니다.
나는 원시 메시지를 가지고있다.
오는 메시지 [들림], 메시지 ID, 그건 좋아요.
그게 내 유일한 해시입니다.
나는 두 GSI의를 만드는 일을하려고 해요 받은 편지함, 내 보낼 편지함에 대한 하나.
그리고 제일 먼저 내가 할거야 내 해시 키는 말할 것입니다
받는 사람이 될 것와 나는 날짜에 배치하는거야.
이 환상적이다.
나는 여기에 내 좋은 전망을 얻었다.
하지만 약간의 문제가 여기에있다.
그리고 당신이로 실행 관계형 데이터베이스뿐만 아니라.
그들은 수직 분할을했다.
당신은 당신의 빅 데이터를 유지하려면 멀리 작은 데이터에서.
>> 내가 해 있기 때문에 이유는 이유 속성을 얻을 수있는 항목을 읽을 이동합니다.
그리고 내 몸은 여기에 모두에있는 경우, 다음 몇 가지 항목을 읽고
몸 길이이면 256킬로바이트 각각의 평균,
수학은 매우 추한 가져옵니다.
그래서 다윗의받은 편지함을 읽을 수 말한다.
다윗의받은 편지함은 50 항목이 있습니다.
평균 크기 256 킬로바이트.
여기 내 전환 비율이다 RCU의에 대한 사킬로바이트입니다.
>> 확인의 함께 가자 결국 일관성을 읽습니다.
나는 아직도 1600 RCU의 먹는거야 바로 다윗의받은 편지함을 읽을 수 있습니다.
아야.
좋아, 이제 생각해 봅시다 응용 프로그램의 작동 방식에 대한.
나는 이메일 응용 프로그램에있어 경우 나는 나의받은 편지함에서 찾고 있어요
나는 모든 메시지의 본문에 보면, 아니, 요약 찾고 있어요.
난 단지 헤더에서 찾고 있어요.
그래서 테이블 구조를 만들어 보자 그것은 더 그렇게 보인다.
>> 그래서 여기에 정보입니다 내 워크 플로우는 필요하다고.
그것은 내받은 편지함 GSI에 있어요.
그것은 날짜의, 보낸 사람, 주제, 다음
가리키는 메시지 ID, 다시 메시지 테이블에
어디 몸을 얻을 수 있습니다.
음,이 레코드 ID가 될 것입니다.
그들은 다시 가리키는 것 디나모 DB 테이블에 항목 ID.
모든 인덱스는 항상 creates-- 항상 아이템을 보유
그 동행입니다 일환으로 ID 인덱스와 함께 제공됩니다.
>> 괜찮아.
청중 : 그것을 지시가 저장된?
릭 리한 (Houlihan) : 네, 알려줍니다 exactly-- 즉 않습니다 정확히입니다.
그것은 여기 말한다 내 다시 기록이다.
그리고 그것은 내 다시 기록에 다시 지적 할 것이다.
정확하게.
좋아, 그럼 지금 내받은 편지함입니다 실제로 훨씬 작은.
그리고 이것은 실제로 지원 이메일 응용 프로그램의 워크 플로우.
받은 편지함 그래서, 난을 클릭합니다.
내가 따라 가서 내가 메시지를 클릭 나는 몸을 가서 할 필요가있을 때 즉,이다
내가 갈거야 때문에 다른보기로 이동합니다.
당신의 MVC 유형에 대해 생각 그래서 경우 프레임 워크, 모델 뷰 컨트롤러.
>> 이 모델에 포함 된 데이터 뷰의 요구는
상기 제어기와 상호 작용한다.
나는 프레임을 변경하면 때 나는 관점을 변경,
그것은로 돌아갈 괜찮아요 서버 및 모델을 다시 채 웁니다,
즉, 사용자가 무엇을 기대하고 있기 때문에.
그들이보기를 변경하면, 그 때의 우리는 데이터베이스에 다시 갈 수 있습니다.
그래서 이메일을 클릭합니다.
나는 몸을 찾고 있어요.
왕복 여행.
몸을 얻을 이동합니다.
>> 나는 훨씬 덜 데이터를 읽을.
나는 단지 몸을 읽고 있어요 그 그가 그들을 필요로 할 때 다윗이 필요합니다.
그리고 1600 년 구울 아니에요 RCU의는 자신의받은 편지함을 표시합니다.
그래서 지금이 방법 that-- LSI 또는 GSI-- 미안 것을,
GSI는, 밖으로 작동합니다.
우리는받는 사람에 대한 우리의 해시를 가지고있다.
우리는 날짜 범위 키를 가지고있다.
그리고 우리는 예상 특성을 가지고있어 우리가보기를 지원하기 만하면 것을.
>> 우리는 보낼 편지함에 대한 그 돌립니다.
보낸 사람에 해시.
그리고 본질적으로, 우리가 아주 좋은, 깨끗한보기.
그리고 그것은 basically-- 우리의 이 좋은 메시지가
잘 때문에 확산되고있어 테이블 이 해시 만, 해시 메시지 ID입니다.
그리고 우리는 두 개의 인덱스가 그 해당 테이블의 떨어져 회전된다.
좋아, 그래서 여기에 생각은 할 수 없습니다 빅 데이터와이 작은 데이터를 유지
함께.
수직 분할, 그 테이블을 분할.
데이터를 읽을하지 마십시오 당신은 할 필요가 없습니다.
좋아, 게임.
우리는 모두 게임을 좋아한다.
적어도 나는 그 게임을 좋아한다.
몇 가지 그래서 우리는 때를 다루는 것을
우리는 바로, 게임에 대한 생각?
요즘 게임, 특히 모바일 게임, 모든 사고에 대해서입니다.
그리고 여기에 회전거야 멀리 DynamoDB의에서 조금.
나는에 데려 갈거야 토론의 일부
일부 주변 다른 AWS 기술.
>> 하지만 게임에 대한 아이디어가 생각하는 것입니다 API를 측면에서 약이다 API를,
일반적으로, HTTP 및 JSON을 말하기.
그것은 얼마나 모바일 게임의 종류 자신의 백 엔드와 상호 작용합니다.
그들은 JSON 포스팅을한다.
그들은 데이터를 얻을, 그것은 전부, 일반적으로 좋은 JSON API를에, 말하기.
>> 친구를 얻을 수 같은 것들, 수 리더, 데이터 교환,
사용자가 컨텐츠를 생성, 시스템에 백업을 밀어
이 물건의 종류 우리가 할 거라고.
이진 자산 데이터, 이러한 데이터 데이터베이스에 앉아하지 않을 수 있습니다.
이 앉아 있습니다 객체 저장소, 오른쪽?
그러나 데이터베이스에 가고 시스템을 말하고 결국,
응용 프로그램을 이야기 어디를 가서.
그리고 필연적으로, 멀티 서버 백엔드 인프라,
높은 위해 설계 가용성 및 확장 성을 제공합니다.
그래서 이러한 우리 모두가 원하는 일을하다 게임 인프라 오늘.
>> 그럼 살펴 보자 어떤이는 것 같습니다.
코어 백 엔드있어 매우 간단합니다.
우리는 여기있는 시스템을 가지고있어 여러 가용 영역.
생각 being--로 우리는 AZS에 대해 이야기 그들 중 별도의 데이터 센터와 같은.
하나 이상의 데이터 센터 AZ 당,하지만, 괜찮아요
다만 별도의 데이터로 생각 지리적으로있다 센터
및 장애 격리합니다.
>> 우리는이 겁니다 몇 EC2 인스턴스.
우리는 할 겁니다 몇 백 엔드 서버.
당신은 기존있어 어쩌면 경우 아키텍처, 우리는있어
우리가 RDS를 부르는 것을 사용하여, 관계형 데이터베이스 서비스를 제공합니다.
MSSQL, MySQL을 수 있을까, 또는 그런 일.
이 방법으로 많은 응용 프로그램입니다 오늘 설계되었습니다.
>> 그런데 우리는 함께 가야 할 수 있습니다 우리가 확장 할 때이다.
우리는 가서 놓을 게요 거기 S3 버킷.
그리고 S3 버킷 대신은 봉사 우리의 servers--에서 해당 개체까지
우리는 그렇게 할 수 있습니다.
당신은 당신의 바이너리를 넣어 서버의 개체
당신은 그 서버를 사용할 수 있습니다 인스턴스는 해당 데이터까지 서비스를 제공한다.
하지만 꽤 비싸다.
>> 할 수있는 더 좋은 방법이 가서입니다 S3 버킷에있는 그 물건을 올려.
S3는 객체 저장소입니다.
그것은을 위해 특별히으로 구축 사물의 이러한 유형을 제공.
그리고 그 클라이언트가 요청하자 직접 그 객체 버킷에서,
서버를 오프로드.
그래서 우리는 여기 확장하기 시작하고 있습니다.
>> 이제 우리는 전 세계의 사용자를 얻었다.
나는 사용자를 얻었다.
나는 로컬 콘텐츠를 필요 바로 이러한 사용자 가까이에있는?
나는 S3 버킷을 만들었습니다 내 소스 저장소로.
그리고 전면거야와 그 CloudFront를 배포.
>> CloudFront를은 CD 및 인 콘텐츠 전송 네트워크.
기본적으로 사용자가 지정한 데이터를한다 인터넷을 통해 모든 캐시
사용자는 어디서나 할 수 있도록 매우 빠른 응답 할 때
그들은 이러한 개체를 요청합니다.
>> 그래서 당신은 아이디어를 얻을.
당신은 가지 활용하고 모든 AWS의 측면 여기이 끝내야합니다.
그리고 결국, 우리는 던져 오토 스케일링 그룹.
우리의 AC2 인스턴스 그래서 우리의 게임 서버,
그들은 혼잡 얻을 시작으로 및 혼잡과 혼잡,
그들은 또 다른 스핀합니다 예, 다른 인스턴스를 회전
다른 인스턴스를 회전.
AWS, 그것은이 기술 그래서 당신은 매개 변수를 지정 허용
이는 주위에 당신의 서버는 성장할 것이다.
그래서 당신은 서버의 N 번호를 가질 수있다 주어진 시간에 거기.
당신의 부하가 사라질 경우, 그들은거야 축소, 수는 줄어들 것입니다.
그리고 부하가 돌아 오면, 그것은 탄성, 밖으로 다시 자랄거야.
>> 그래서이 멋지다.
우리는 EC2 인스턴스를 많이 가지고있다.
우리는에 캐시를 넣을 수 있습니다 데이터베이스 앞
시도하고 데이터베이스를 가속화 할 수 있습니다.
다음 압력 점 일반적으로 사람들은 참조
그들이를 이용 게임 스케일 관계형 데이터베이스 시스템.
이름 : Jeez, 데이터베이스 성능은 끔찍한입니다.
우리는 어떻게 개선 할 수 있습니까?
의 퍼팅 해보자 그 앞에 캐시.
>> 음, 캐시가 작동하지 않습니다 게임에 너무 큰, 오른쪽?
게임, 쓰기는 고통이다.
게임은 매우 무거운 쓰기된다.
당신이있을 때 캐시가 작동하지 않습니다 당신은 항상했습니다 때문에 무거운 쓰기
캐시를 업데이트 할 수있어.
사용자는 그것의 캐시를 업데이트 관련이없는 캐싱합니다.
실제로 단지 추가 작업입니다.
>> 그래서 우리는 여기 어디?
당신은 큰 병목있어 거기 데이터베이스에.
그리고 장소 이동 분명히 분할된다.
파티셔닝은 아니다 당신이있을 때 쉽게 할 수
관계형 데이터베이스를 다루는.
관계형 데이터베이스로, 당신은있어 관리에 대한 책임, 효과적으로,
키 공간.
당신은 A와 M 사이에 사용자가 말을하는지 N 및 Z는 거기 사이에, 여기.
그리고 당신은 전환하고 응용 프로그램에서.
그래서 당신은 상대하고 이 분할 데이터 소스.
당신은 트랜잭션 제약이 그 파티션에 걸쳐 없습니다.
당신은 모든 종류의있어 당신이있어 어지러움
이 아래로 노력을 다루는 스케일 아웃 처리합니다
더 큰 인프라를 구축.
그냥 재미 없다.
>> 청중 : 그래서 당신이 그 말을 소스 포인트를 증가시키는 속도
과정?
릭 리한 (Houlihan) : 증가?
청중 : 소스 점.
릭 리한 (Houlihan) : 소스 점?
청중 : 정보에서, 어디에서 정보가오고있다?
릭 리한 (Houlihan) : 아니오.
무슨 말인지를 증가 데이터 저장소의 파티션 번호
처리량을 향상시킨다.
그래서 여기에 무슨 일이 일어나고 사용자입니다 여기까지 EC2 인스턴스에오고,
글쎄, 난 사용자가 필요로하는 경우 즉 M에있어, 내가 여기 있습니다.
N에서 P로, 나는 여기 있습니다.
Z까지 P에서, 나는 여기 있습니다.
>> 청중 : OK, 그 때문에 사람들은 모든 다른 노드에 저장?
>> 릭 리한 (Houlihan) : 예.
이들의로 생각 다른 데이터 사일로.
그래서 당신은이 작업을 수행하는 데있어.
당신은 일을하려고하는 경우 이, 당신이하려고하는 경우
관계형 플랫폼을 확장하기 위해, 이것은 당신이 무슨 일을하는지입니다.
당신은 데이터를 복용하고 있고 당신은 그것을 아래로 절단하고 있습니다.
그리고 당신은 그것을 걸쳐 분할하고 데이터베이스의 여러 인스턴스.
그리고 당신은 모든 것을 관리하고 그 응용 프로그램 계층에서.
그것은 재미 없다.
그래서 우리가 가고 싶어합니까?
우리는 DynamoDB의, 완벽하게 관리 가고 싶어, NoSQL에 데이터 저장, 제공 처리량.
우리는 보조 인덱스를 사용합니다.
그건 기본적으로 HTTP API와 문서 지원이 포함되어 있습니다.
그래서 당신은 걱정할 필요가 없습니다 그 분할의 약.
우리는 당신을 위해 모든 작업을 수행 할 수 있습니다.
그래서 지금, 대신, 그냥 테이블에 기록.
테이블을 분할 할 필요가있을 때에는 그 장면 뒤에 발생합니다.
당신은 완전히 절연하고 개발자로서 그에서.
그럼 대해 얘기하자 사용 사례의 일부
우리는 게임에서 공통으로 실행하는 것이 게임 시나리오, 리더.
그래서 당신은, 사용자가오고있어 그들이있어 BoardNames
에,이 사용자에 대한 기록했다.
우리는 사용자 ID에 해시 될 수 있습니다 그리고, 우리는 게임의 범위가 있습니다.
그래서 모든 사용자가보고 싶어 그가 연주있어 모든 게임
모든 자신의 최고 점수 모든 게임에서.
그래서 자신의 개인 리더입니다.
>> 지금은에 가고 싶어 나는이거나 먹어하려면 그래서 나는이 개인 순위표를 얻을.
내가 뭘 원하는 가서입니다 모든 사용자에 걸쳐 최고 점수.
그래서 내가 어떻게 그렇게 할 수 있습니까?
내 기록은 (는) 해시 때 사용자 ID는 게임에 원거리,
잘 나는 앞서 갈거야 및 구조 조정, GSI를 만들
나는 그 데이터를 재구성거야.
>> 지금은에 해시거야 게임 BoardName.
그리고 최고 점수에 대한 범위거야.
그리고 지금은 다른 버킷을 만들었습니다.
나는 동일한 테이블을 사용하고, 같은 항목 데이터.
그러나 나는주는 버킷을 만드는거야 나 게임에서 최고 점수의 집계.
>> 그리고 그 테이블을 조회 할 수 있습니다 그 정보를 얻을 수 있습니다.
그래서 나는까지 해당 쿼리 패턴을 설정 한 보조 인덱스에 의해 지원 될 수있다.
이제 그들은 BoardName으로 분류 할 수있다 과에 따라, TopScore으로 분류.
당신이 볼 수 있도록, 이러한 유형은 의 당신은 게임에 들어갈 경우에 사용합니다.
우리가 게임에 들어갈 또 다른 좋은 활용 사례 상 누가 상을 수상 것입니다.
그리고 이것은 좋은 유스 케이스입니다 우리는 스파 스 인덱스를 호출한다.
스파 스 인덱스는 있습니다 생성 할 수있는 능력
필요하지 않는 인덱스 테이블에있는 모든 단일 항목이 포함되어 있습니다.
그리고 왜 안돼?
때문에되고있는 속성 인덱스는 모든 항목에 존재하지 않습니다.
>> 이 특히 이렇게 케이스를 사용하여, 나는 말하고,
당신은 무엇을, 내가 갈거야 알고 상이라는 속성을 만듭니다.
그리고 모든 사용자를 줄거야 그 속성 상을 가지고있다.
사용자 수상은하지 않아도 그 속성을하지 않을.
그래서 만들 때 인덱스, 사용자 만
그 표시거야 인덱스에 있습니다
실제로 상을 수상 한 것.
그래서 할 수있는 좋은 방법입니다 필터링 된 인덱스를 만들려면 그
그렇지 않은 매우 선택적이다 인덱스에 전체 테이블을 가지고있다.
>> 그래서 우리는 여기에 시간이 부족 있어요.
내가 가서 건너 뛸거야 아웃이 시나리오를 건너 뜁니다.
조금 이야기 비슷해
>> 청중 : 나는 빠른 질문을 할 수 있습니까?
하나는 무거운 쓰기인가?
릭 리한 (Houlihan) : 무슨 일입니까?
청중 : 무거운 쓰기.
릭 리한 (Houlihan) : 무거운 쓰기.
어디 보자.
>> 청중 : 아니면은 아니다 뭔가 당신은 할 수 있습니다
초 만에에 음성?
릭 리한 (Houlihan) : 우리는 이동 투표 시나리오를 통해.
그것은 나쁜 아니다.
너희들은 몇 분 있습니까?
그래.
>> 그래서 우리는 투표에 대해 이야기 할 것입니다.
그래서 실시간 투표, 우리가 투표 요구 사항에 대해 설명합니다.
요구 사항은 우리가 허용한다는 것이다 각 사람은 한 번만 투표 할 수 있습니다.
우리는 아무도 할 수 없습니다 할 자신의 투표를 변경합니다.
우리는 실시간 집계 할 인구 통계에 대한 분석
우리는 될 거라고 사이트에서 사용자에게 보여.
>> 이 시나리오의 생각.
우리는 현실의 많은 작업 그들이있어 어디 TV 프로그램
사물의 이러한 정확한 유형을하고.
그래서 시나리오를 생각할 수있는, 우리는 수백만이
거기의 십대 소녀 자신의 휴대 전화와
투표, 투표, 그리고 그들이 누구를 위해 투표
가장 인기를 찾을 수 있습니다.
따라서 이들 중 일부 요구 사항은 우리이 다.
>> 그래서 첫 번째 걸릴 이 문제를 해결
를 구축하는 것입니다 매우 간단한 응용 프로그램입니다.
그래서 나는이 응용 프로그램을 가지고있다.
나는 거기에 일부 유권자을 가지고있다.
그들은이 투표 응용 프로그램 충돌, 올.
나는 일부 원시 표 테이블을 가지고 난 그냥 그 투표에 덤프합니다.
나는 약간의 집합이있을 것이다 표 테이블이
내 분석 및 인구 통계를 할 것입니다, 우리는 거기에 모든 것을 놓을 게.
>> 그리고 이것은 중대하다.
인생은 좋은 것입니다.
인생은 우리가 찾을 때까지 좋은 항상 하나 또는 두 개의있다
선거에서 인기있는 사람들.
하나 또는 두 가지가있다 사람들이 정말 걱정 것을.
그리고 당신은에 투표하는 경우 규모, 난 갑자기
의 지옥을 망치 될 것 두 후보, 하나 또는 두 개의 후보.
상품의 수가 매우 제한 사람들은 인기를 찾을 수 있습니다.
>> 이것은 좋은 디자인 패턴이 아니다.
이것은 사실입니다 아주 나쁜 디자인 패턴
그것은 만들기 때문에 정확히 우리 핫 키이었다에 대해 이야기했다.
핫 키는 우리가 좋아하지 않는 일이다.
>> 그렇다면 우리는 그 문제를 해결합니까?
정말,이 문제를 해결하는 방법은 그 후보 버킷을 취함으로써
그리고 우리가 가지고있는 각각의 후보, 우리는 임의의 값을 추가하는거야,
임의 우리가 알고있는 무엇인가, 하나에서 100 사이의 값,
100과 1000 사이에, 또는 1과 1,000 사이,
그러나 많은 임의의 값은 당신이 원하는 그 후보의 끝에 추가합니다.
>> 그리고 난 정말 그때 무슨 짓을 한거야?
나는 후보 ID로 사용하고있는 경우 총 투표에 양동이,
나는 임의을 추가 한 경우 그 말에 수,
내가 만든 지금 10 양동이, 백 양동이, 천 버킷
것을 나는 걸쳐 투표를 집계하고있다.
>> 그래서, 수백만, 수백만이 와 기록의 수백만오고
이 후보, 지금 확산하고 후보 A_1에서 그 투표
후보 A_100 통해 때문에 투표에 온다 때마다,
나는 무작위로 발생하고있어 하나에서 100 사이의 값입니다.
나는이 말에 그것을 시침 해요 사람의가 투표 후보.
나는 양동이로 덤핑하고있다.
>> 이제 뒷면에, 나는 알고있다 것을 나는 백 버킷을 얻었다.
그래서 나는 진행하고자 할 때 그리고 투표를 집계,
나는 모든 버킷에서 읽을.
그래서 내가 가서 추가 할 수 있습니다.
그리고 나는 분산은 수집 않는다 내가 나가서 헤이 말할 경우,
당신은 무엇을 알고,이 후보의 키 공간은 백 이상 버킷입니다.
나는 모든를 수집하는거야 그 백 버킷에서 투표.
나는 집계거야 그들과 나는 말을하려고 해요
후보는 지금이 X의 총 투표 수입니다.
>> 이제 쓰기 모두 질의 및 판독 질의
잘 분산되어 나는 걸쳐 쓰고 있어요 때문에
나는 키의 수백에 걸쳐 읽고 있어요.
내가 쓰는 아니에요과 지금은 하나의 키를 통해 읽기.
그래서 좋은 패턴입니다.
>> 이 사실은 아마 하나입니다 가장 중요한 설계
NoSQL에 규모에 대한 패턴.
당신은이 유형을 볼 수 모든 맛의 디자인 패턴.
MongoDB를, Dy​​namoDB의, 그렇지 않습니다 문제, 우리 모두가이 작업을 수행 할 수 있습니다.
당신이 취급 할 때 때문에 그 거대한 집계와,
당신은 방식을 파악해야 버킷에 걸쳐 그들을 밖으로 퍼졌다.
그래서 이것은 당신이 그것을 할 방법입니다.
좋아, 그럼 당신이 지금하고있는
당신은 읽기를 거래하고있다 쓰기 확장 성을위한 비용.
내 판독의 비용은 좀 더 복잡한
내가 읽어 가야 백 버킷 대신 중 하나.
그러나 나는 쓸 수 있어요.
그리고 내 처리량, 내 쓰기 처리량은 믿을 수 없다.
그래서 일반적으로 귀중 DynamoDB의 크기 조정을위한 기술,
또는 그 문제에 대한 모든 NoSQL에 데이터베이스.
그래서 우리는 그것을 확장하는 방법을 알아 냈다.
그리고 우리는 생각하는 방법을 우리의 핫 키를 제거 할 수 있습니다.
그리고 이것은 환상적이다.
그리고 우리는이 좋은 시스템을 얻었다.
그리고 그것은 우리에게 매우 올바른 투표를 주어진 것 우리는 기록적인 투표 드 속는을 가지고 있기 때문에.
그것은 DynamoDB의에 내장.
우리는 조건부 권리에 대해 이야기했다.
>> 유권자가 오면, 풋 테이블에 삽입,
그들은 그들의 유권자 ID로 삽입 그들은 또 다른 투표를 삽입 할 경우,
나는 조건부 쓰기 작업을 수행.
이 쓰기 만 말 이없는 경우.
그래서 최대한 빨리 볼로 그 투표의 테이블에 충돌,
아무도 다른 사람이 될 것 없습니다 것 자신의 투표를 둘 수.
그리고 그 환상적이다.
그리고 우리는 증가하고 우리의 후보 카운터.
그리고 우리는 우리의 일을하고 인구 통계와 모든 것을.
그러나이 경우 어떻게 내 응용 프로그램은 쓰러져서?
지금 갑자기 투표의 모든 오고 있으며, 나는
그들은 처리지고 있다면 모른다 내 분석 및 인구 통계에
더 이상.
그리고 때 응용 프로그램 최대 어떻게 다시 온다
도대체 내가 투표는 무엇을 알 수 있습니까 처리 어디서부터 시작 할까?
>> 그래서 이것은 진짜 문제 때입니다 이러한 유형의 시나리오를보고 시작합니다.
어떻게 우리는 그것을 해결합니까?
우리는 무엇으로 그것을 해결 우리 DynamoDB의 스트림을 호출합니다.
스트림은 한 번 주문하고, 모든 액세스의 분할 변경 로그
테이블에 모든 쓰기 테이블에 액세스 할 수 있습니다.
기록 상관 없음 데이터 표는 스트림에 표시됩니다.
>> 그것은 기본적으로 24 시간 대기 행렬입니다.
항목은 스트림을 명중, 그들은 24 시간 동안 살고 있습니다.
이들은 여러 번 판독 할 수있다.
배달 보장 단지 스트림에 한 번,
n 번 판독 될 수있다.
그래서 그러나 많은 프로세스 당신이 원하는 그 데이터를 사용, 당신은 그것을 소비 할 수 있습니다.
그것은 모든 업데이트가 나타납니다.
모든 쓸 것입니다 만 스트림에 한 번 나타납니다.
그래서 당신은 걱정할 필요가 없습니다 두 번 처리에 대한
동일한 프로세스에서.
>> 그것은 엄격하게 항목별로 정렬합니다.
우리는 시간을 말할 때 주문 및 분할,
당신은 스트림에 파티션별로 확인할 수 있습니다.
당신은 순서대로 항목 업데이트를 볼 수 있습니다.
우리는 보장되지 않습니다 당신이있어 스트림
모든 트랜잭션을 얻을 것 항목에 걸쳐 순서대로.
>> 그래서 스트림 나무 등이다.
우리 모두는 나무 등의 의미를 아십니까?
나무 등은 당신이 그것을 할 수 있다는 것을 의미합니다 이상, 이상, 또 다시.
그 결과는 동일 할 것.
>> 스트림, 나무 등이다 하지만 그들은해야
출발점에서 연주 당신이 선택하는 곳, 끝으로,
또는이 발생하지 않습니다 같은 값에.
>> MongoDB를와 같은 일.
MongoDB가이 구조를 가지고 그들은 oplog를 호출합니다.
그것은 동일한 구조이다.
많은 NoSQL에 데이터베이스 이 구조를 가지고있다.
그들은 일을하는 데 사용 같은 복제하는
정확히 우리가 스트림을 함께 할 것입니다.
청중 : 아마 이단 문제,하지만
앱 등을 다운 일에 대해 이야기.
스트림은 보장됩니다 아마도 아래로 갈 수 없다?
릭 리한 (Houlihan) : 네, 스트림 아래로 가지 않을 보장됩니다.
우리는 인프라를 관리 뒤에. 자동 스트림
그들의 오토 스케일링 그룹에 배포합니다.
우리는 조금을 통해 갈거야 무슨 일에 대한 비트.
>> 나는 그들이하지 않은 말을 안 아래로 가지 않을 보장.
요소는 보장 스트림에 표시합니다.
그리고 스트림에 액세스 할 수 있습니다.
그래서 무슨 일이 다운되거나 다시 온다 위로는, 그 아래에 발생합니다.
그것은 괜찮아요 covers--.
좋아, 당신이 다른 수 있도록 화면 오프보기 유형.
에 중요한보기 유형 프로그래머는 일반적으로 그 무엇이었다입니까?
나는 이전보기를 얻을.
업데이트가 테이블 안타 때거야 스트림에 이전보기를 밀어
그래서 데이터를 보관, 또는 변경 할 수 있습니다 제어, 변경 확인, 변경
조치.
>> 그 후 지금의 새로운 이미지, 보기의 또 다른 유형의 업데이트,
당신은 얻을 수 있습니다.
당신은 과거와 이미지 모두를 얻을 수 있습니다.
어쩌면 둘 다 할 수 있습니다.
나는 그것이 무엇인지보고 싶어요.
나는 그것이로 변경 무엇을보고 싶어요.
>> 나는 준수의 유형이 프로세스의 실행됩니다.
그것은을 확인해야 이런 일들은 변경할 때,
그들은 특정 한도 내에서 걸 또는 특정 매개 변수 내에서.
>> 그리고 어쩌면 내가 만 변경된 것을 알 필요가있다.
나는 변경 어떤 항목을 걱정하지 않는다.
내가 알아야 할 필요가 없습니다 무슨 일이 변경된 속성.
난 그냥 것을 알 필요가 항목이 감동되고있다.
그래서 이들은 뷰의 종류 당신은 스트림을 얻을
당신은 상호 작용할 수 있습니다.
>> 응용 프로그램이 스트림을 소비
이것은이 작동하는 방식 가지입니다.
DynamoDB의 클라이언트에 요청 테이블에 데이터를 밀어 넣습니다.
스트림은 우리가 파편을 부르는에 배포 할 수 있습니다.
파편의 크기가 조절된다 독립적으로 테이블.
그들은 완전히 일치하지 않습니다 테이블의 파티션.
그리고 그 이유는 이유 그들은 줄 때문에
용량, 전류 테이블의 용량.
>> 그들은에서 배포 자신의 자신의 오토 스케일링 그룹,
그들은 따라 밖으로 회전하기 시작 들어오는 얼마나 많은 쓰기에,
얼마나 많은 re​​ads-- 정말 것은 씁니다.
거기에 더 reads--하지만없는 방법 많은 쓰기가오고있다.
>> 그리고 뒷면에 결국, 우리는 무엇을 우리
KCL, 또는 운동성 클라이언트 라이브러리를 호출합니다.
운동성은 스트림 데이터 인 아마존에서 가공 기술.
그리고 스트림은 그에 내장되어 있습니다.
>> 그래서 당신은 KCL이 활성화 사용 응용 프로그램은 스트림을 읽을 수 있습니다.
운동성 클라이언트 라이브러리 실제로 당신을 위해 노동자를 관리합니다.
그리고 그것은 또한 몇 가지를 않습니다 흥미로운 것들.
그것은 몇 가지 테이블을 생성합니다 당신의 DynamoDB의 테이블에
어느 아이템을 추적 처리되었다.
따라서이 방법은이 경우, 다시 떨어지는 경우 그것은 이상 떨어지고 와서 가져
백업을 서서 어디 확인할 수 있습니다 스트림 처리에이었다.
>> 그 때 매우 중요합니다 당신이 복제에 대해 얘기하고.
나는 무엇을 알 필요가 데이터가 처리 된
어떤 데이터가 아직 처리해야합니다.
그래서 스트림에 대한 KCL 라이브러리는 것 당신에게 그 많은 기능을 제공합니다.
그것은 모든 가사의 처리합니다.
그것은 모든 파편을위한 노동자를 의미합니다.
이 관리 테이블을 생성 모든 노동자에 대한 모든 파편을위한.
그리고 그 노동자의 화재로, 그들은 그 테이블을 유지 보수
그래서 당신은이 기록을 알고 읽고 처리되었습니다.
그리고 그런 식으로 처리하는 경우 , 죽으면 다시 온라인
이 이륙 곳은 권리를 재개 할 수 있습니다.
>> 그래서 우리는이를 사용 교차 영역 복제.
고객의 많은 필요성이 데이터 테이블의 데이터를 이동 또는 부품
주위에 다른 지역으로.
구 지역이 있습니다 전 세계.
그래서 분명히 .. 내가있을 수 있습니다 아시아에서 사용자가있을 수 있습니다, 사용자
미국의 동부 해안에.
서로 다른 데이터가 그 지역적으로 분산 될 필요가있다.
그리고 어쩌면 사용자는 출발 항공사 미국을 통해 아시아,
나는 복제 할 그와 함께 자신의 데이터.
그는 비행기를 얻을 때, 그는이 자신의 모바일 앱을 사용하여 좋은 경험.
>> 당신은 교차 영역을 사용할 수 있습니다 복제 라이브러리는이 작업을 수행합니다.
기본적으로 우리는이 두 가지 기술을 제공했다.
하나는 당신이 할 수있는 콘솔 응용 프로그램의 자신의 EC2 인스턴스에 서서.
그것은 순수한 복제를 실행합니다.
그리고 우리는 당신이 라이브러리를했다.
라이브러리를 구축하는 데 사용할 수있는 자신의 응용 프로그램 사용자의 경우
그와 함께 미친 일을 할 data-- 필터는 그것의 일부만을 복제
데이터를 회전으로 ​​이동 다른 테이블, 등등 등등.
그래서 그 모양을 가지입니다.
>> DynamoDB의 스트림이 될 수 있습니다 우리는 람다를 부르는 처리.
우리는 이벤트에 대해 조금 언급 구동 애플리케이션 아키텍처.
람다는의 핵심 구성 요소입니다.
람다는 수요에 발생 코드 특정 이벤트에 대한 응답으로.
이러한 이벤트들 중 하나가 될 수있다 스트림에 나오는 기록.
기록 스트림에 나타나는 경우, 우리는이 자바 함수를 호출합니다.
음,이 자바 스크립트 및 람다입니다 Node.js, 자바, 파이썬 지원
곧 지원 다른 언어뿐만 아니라.
그리고 그것은 순수한 코드의 말에 충분하다.
자바에서 쓰기, 당신은 클래스를 정의합니다.
당신은 람다에 JAR를 위로 밀어 넣습니다.
그리고 당신은 어떤 클래스 지정 이벤트에 대한 응답으로 호출합니다.
그리고 람다 인프라 그 뒤에 그 코드를 실행합니다.
>> 그 코드를 처리 할 수​​ 있습니다 스트림 오프 기록.
그것은 그것으로 원하는 모든 작업을 수행 할 수 있습니다.
이 특정 예에서, 모든 우리는있어 정말 속성을 로깅하고.
그러나 이것은 단지 코드입니다.
코드는 바로, 아무것도 할 수 있습니까?
>> 그래서 당신은 그 데이터를 회전 할 수 있습니다.
당신은 파생 뷰를 생성 할 수 있습니다.
이 문서 구조 인 경우에, 당신은 구조를 평평하게 할 수 있습니다.
당신은 대체 인덱스를 생성 할 수 있습니다.
모든 종류의 것들을 당신이 할 수있는 DynamoDB의 스트림으로한다.
>> 정말, 그 그 모습이다.
그래서 당신은 이러한 업데이트는 오는 얻는다.
그들은 문자열을오고있어.
그들은 람다 함수에 의해 판독하고 있습니다.
그들은 데이터를 회전하고 있고 파생 테이블에 그것을 밀어,
변화의 외부 시스템에 통지, 및 ElastiCache로 데이터를 밀어.
>> 우리는 캐시를 넣어하는 방법에 대해 이야기 그 판매에 대한 데이터베이스의 앞에
대본.
그럼 무슨 일이 있다면 항목 설명을 업데이트?
글쎄, 내가 가진 경우 람다 함수는 해당 테이블에서 실행
내가 항목에 대한 설명을 업데이트 할 경우, 그것은거야 스트림 오프 레코드를 선택,
그리고 ElastiCache를 업데이트 할 것이다 새 데이터 인스턴스입니다.
그래서 많은입니다 우리는 람다와 함께 무엇을 할.
그것은, 커넥터 연결 코드입니다.
그리고 실제로 제공 발사 할 수있는 능력
매우 복잡한 응용 프로그램을 실행하는 데 전용 서버없이
정말 멋진 인프라.
>> 그럼으로 돌아 가자 우리 실시간 투표 아키텍처.
이 새로운 및 향상 우리의 스트림과 KCL은 응용 프로그램을 활성화.
같은, 우리가 할 수있는 이전과 선거의 규모를 처리 할 수​​ 있습니다.
우리는이를 좋아한다.
우리는 분산 집결을하고있는 여러 버킷에서.
우리는 낙관적 잠금이 일어나고 있어요.
우리는 우리의 유권자를 유지할 수 있습니다 그들의 표를 변경하는.
그들은 단지 한 번만 투표 할 수 있습니다.
이 환상적이다.
실시간 내결함성 이제 확장 가능한 통합.
일이 넘어지면, 그것을 그 자체를 다시 시작 위치를 알고
이 때문에 백업을 때 우리는 KCL 응용 프로그램을 사용하고 있습니다.
그리고 우리는 또한 사용할 수 있습니다 KCL 애플리케이션은 데이터를 밖으로 밀어
기타에 대한 적색 편이하기 응용 프로그램 분석, 또는 사용
탄성 MapReduce를 실행합니다 오프 실시간 스트리밍 집계
데이터의.
>> 그래서 이러한 것들을 우리는 많은 이야기하지 않았습니다.
그러나 그들은 추가있어 올 기술
당신이 찾고있는 경우에 부담하는 이러한 유형의 시나리오에서.
>> 좋아, 그 약 그래서 DynamoDB의 스트림을 분석.
당신은 드 속는를 수집 할 수 있습니다 데이터, 모든 종류의 작업을 수행
좋은 물건, 집계 데이터 메모리는, 그 파생 테이블을 만들 수 있습니다.
즉 거대한 사용 사례이다 그 많은 고객
중첩을 고려하여 참여 그 JSON 문서의 속성
추가 인덱스를 작성.
>> 우리는 끝이야.
나와 함께 베어링 주셔서 감사합니다.
그럼 대해 얘기하자 참조 아키텍처.
DynamoDB의 지금의 중앙에 앉아 AWS 인프라의 많은.
기본적으로 당신은 그것을 연결할 수 있습니다 아무것도까지 당신이 원하는.
응용 프로그램은 디나모 포함하여 내장 람다, ElastiCache, CloudSearch,
탄성 속으로 데이터를 푸시 맵리 듀스, DynamoDB의에서 수입 수출
(S3), 워크 플로우의 모든 종류의에.
그러나 아마 최고의 에 대해 이야기하는 것은,
이것은 정말 무엇인가 흥미로운 때입니다
이벤트 기반 응용 프로그램에 대해 얘기.
>> 이 예입니다 내부 프로젝트
우리는 우리가 실제로있어 어디에 있는지 출판은 설문 조사 결과를 수집합니다.
이메일 링크 그래서 우리는 거기거야, 보내
작은 링크 말하는 클릭 수 여기에 설문 조사에 응답한다.
그리고 때 사람이 클릭 링크는 어떻게됩니까
그들은 안전한 풀다운입니다 (S3)에서 HTML 설문 조사 양식.
어떤 서버가 없습니다.
이것은 단지 S3 객체입니다.
>> 그 형태는 온다 브라우저에서로드합니다.
그것은 백본 있어요.
그것은 복잡한 자바 스크립트있어 그것이 실행합니다.
그래서 그것은 매우 풍부한 응용 프로그램입니다 클라이언트의 브라우저에서 실행.
그들은 아니에요 모르겠어요 백 엔드 서버와 상호 작용.
이 시점에서, 모든 브라우저입니다.
>> 그들은에 결과를 게시 무엇 우리는 아마존 API 게이트웨이를 호출합니다.
API 게이트웨이는 단순히 웹 API입니다 당신은 정의하고 후크 할 수
무엇에 당신이 원하는.
이 특정한 경우에, 우리는있어 람다 함수에 매여.
>> 그래서 내 POST 동작은 아무 서버에서 일어나는.
기본적으로 그 API 게이트웨이가 앉아있다.
그것은 나에게 사람들까지 비용이 들지 않습니다 바로 여기에 올리기 시작?
람다 함수는 단지 거기에 앉아있다.
그리고 그것은 때까지 나에게 아무것도 비용이 없습니다 사람들은 타격 시작합니다.
그래서 당신은 볼륨으로 볼 수 있습니다 요금이 올 때 증가, 그건.
나는 서버 7/24을 운영하지 않는 경우.
>> 그래서 양식을 당겨 아래 버킷 중,
내가 API를 통해 게시 람다 함수에 게이트웨이.
그리고 람다 기능은 당신이 알고 말한다
무엇을, 나는 몇 가지 PIIS있어, 일부 개인 식별 정보
이러한 응답에.
나는 사용자에서 오는 의견을 얻었다.
나는 이메일 주소를 가지고있다.
나는 사용자 이름을 가지고있다.
>> 날이를 분할 할 수 있습니다.
나는 몇 가지를 생성하는거야 이 기록 오프 메타 데이터.
그리고 밀어거야 DynamoDB의에 메타 데이터.
그리고 나는 모든 데이터를 암호화 할 수 내가 원하는 경우 DynamoDB의에 밀어 넣습니다.
하지만이에, 나를 위해 쉽게 앞서 말을 이동, 케이스를 사용하여,
나는 원시 데이터를 밀어거야 암호화 된 S3 버킷에.
그래서 나는 S3 서버 측에 내장 사용하십시오 암호화 및 아마존의 키 관리
그래서 서비스 나는 키가 그 일정한 간격으로 회전 할 수 있습니다,
나는 그 PII 데이터를 보호 할 수 있습니다 이 모든 워크 플로우의 일환으로.
>> 그래서 내가 무슨 짓을 한거야?
난 그냥 전체를 배치했습니다 응용 프로그램, 그리고 나는 어떤 서버가 없습니다.
그래서 이벤트가 응용 프로그램을 구동 무엇인가 아키텍처는 당신을 위해 않습니다.
>> 지금 당신이 생각하는 경우 이 항아리에 대한 사용 사례
우리는 내가 이야기하고 다른 고객이 약이 정확한 아키텍처 사람
급격하게 큰 캠페인을 실행하는 사람들 이보고 오, 갈 수 있습니다.
지금, 그들이 할 수 있기 때문에 기본적으로 그것을 밀어,
그냥 앉아 그 캠페인을하자 거기 시작, 그리고까지
에 대한 그림을 걱정할 필요가 기반 시설의 종류
이를 지원하기 위해이 될 것입니다.
그리고 가능한 한 빨리 이 캠페인은, 이루어집니다
그것은 인프라처럼 다만 즉시 사라집니다
정말이 때문에 어떤 인프라가 없습니다.
그것은 람다에 앉아 그냥 코드입니다.
그것은 DynamoDB의에 앉아 그냥 데이터입니다.
그것은 놀라운 방법입니다 응용 프로그램을 구축 할 수 있습니다.
>> 청중 : 그래서 더 그것을이다 임시는 것보다
그것은 실제의 서버에 저장 되었다면?
>> 릭 리한 (Houlihan) : 물론입니다.
해당 서버 인스턴스 때문에 7/24 일해야 할 것입니다.
그것은 사용할 수있다 누군가에 응답 할.
그럼 어떻게 됐을까?
(S3)는 7/24 사용할 수 있습니다.
S3는 항상 응답합니다.
그리고 S3는 아주, 아주 좋은 것입니다 개체를 제공하는시.
그 객체는 HTML 파일, 또는 수 자바 스크립트 파일, 또는 무엇이든 당신이 원하는.
당신은 매우 풍부한 웹 응용 프로그램을 실행할 수 있습니다 S3 버킷에서, 사람들은 않습니다.
>> 그리고 그 생각은 여기 멀리 방법에서 얻을 수 있습니다
우리는 그것에 대해 생각하는 데 사용됩니다.
우리 모두가 생각하는 데 사용 서버와 호스트의 조건.
그것은 더 이상 그것에 대해 아니에요.
그것은 코드와 인프라에 관​​하여이다.
클라우드로 코드를 배포하고 구름이 당신을 위해 그것을 실행하자.
그리고 그 AWS가해야 할 노력거야.
>> 청중 : 중간에서 골드 박스 그래서 API의 게이트웨이, 서버와 같은 아닙니다
대신 그냥 ...입니다
>> 릭 리한 (Houlihan) : 당신은 생각할 수 서버 외관으로의.
이 모두는 HTTP를 취할 것입니다 요청하고 다른 프로세스에 매핑.
즉,이하는 모두이다.
이 경우, 우리는 매핑하는 그 람다 함수.
좋아, 그래서 내가 가진 전부입니다.
대단히 감사합니다.
감사합니다.
나는 우리가 시간이 지남에 조금 원하는 것을 알고있다.
그리고 희망 너희들은있어 정보의 조금
오늘 멀리 걸릴 수 있습니다.
내가 간다면 내가 사과 당신의 머리의 일부를 통해,
하지만 좋은 많이있다 기본적인 기초 지식
내가 생각하는 당신을 위해 매우 중요합니다.
그래서 저를 갖는 주셔서 감사합니다.
[박수 갈채]
청중 : [들리지] 당신이 말하는 때이다
당신은 일을 통해 가야했다 처음부터 끝까지
오른쪽 값을 얻을 수 또는 동일한 값,
방법 것 값 [들리지] 경우 변경합니다.
>> 릭 리한 (Houlihan) : 아, 멱등?
값은 어떻게 변경할 것인가?
음, 때문에에게 나는 실행되지 않은 경우 그 모든 길의 끝,
그때 나는 변화 모르겠어요 마지막 마일에 만들어졌다.
그것은을 할 수 없을거야 내가 본 것과 같은 데이터.
청중 : 아, 그래서 그냥 전체 입력을 못 했어.
릭 리한 (Houlihan) : 오른쪽.
당신은 처음부터 가야 끝으로, 다음 그건
일관성있는 상태가 될 것.
시원한.
>> 청중 : 당신이 우리를 보였다 그래서 DynamoDB의 문서 나 키 값을 수행 할 수 있습니다.
그리고 우리는 많은 시간을 보냈다 해시 및 방법과 키 값
그것을 주변 플립합니다.
당신이 그 테이블에서 보았을 때,이다 문서 접근 남기고?
>> 릭 리한 (Houlihan) : 나는 않을 것 를 뒤에두고 말한다.
>> 청중 : 그들은 짓이야에서 분리
>> 릭 리한 (Houlihan) : 문서로 접근, DynamoDB의에서 문서 유형
또 다른 속성으로 생각된다.
그것은 포함 된 속성의 계층 적 데이터 구조.
그리고 쿼리, 당신은 속성을 사용할 수 있습니다
객체 표기법을 사용하여 해당 개체의.
그래서 중첩 필터링 할 수 있습니다 JSON 문서의 속성입니다.
청중 : 그래서 어떤 시간 전 문서 접근을,
나는 종류의 tabular--에 도달 할 수 있습니다
청중 : 물론입니다.
청중 : --indexes과 당신은 단지 이야기 일.
릭 리한 (Houlihan) : 네, 인덱스와 모든 것을,
때 인덱스 원하는 JSON의 특성,
우리가 그렇게 할 거라고 방법은 경우입니다 당신은 JSON 객체 또는 문서를 삽입
디나모으로, 당신은 스트림을 사용합니다.
입력 스트림을 판독한다.
당신은 JSON 것을 얻을 것 개체 및 확인을 말하고 싶지만,
내가 인덱싱 할 속성은 무엇인가?
>> 당신은 파생 테이블을 만듭니다.
이제 그것이 지금 작동하는 방식이다.
우리는 색인을 허용하지 않습니다 직접 그 속성.
>> 청중 : 문서를 Tabularizing.
>> 릭 리한 (Houlihan) : 정확히, 평탄화 그것은 정확히 그것을 tabularizing.
그것은 당신이 함께 할거야.
>> 청중 : 감사합니다.
>> 릭 리한 (Houlihan) : 그래, 절대적으로, 감사합니다.
청중 : 그래서 가지의 몽고는 레디 스의 classifers을 준수합니다.
>> 릭 리한 (Houlihan) : 네, 이 같은 많은입니다.
즉,에 대한 좋은 설명이다.
시원한.