1 00:00:00,000 --> 00:00:04,969 >> [MUSIC CHƠI] 2 00:00:04,969 --> 00:00:06,010 RICK Houlihan: Tất cả các quyền. 3 00:00:06,010 --> 00:00:06,600 Chào mọi người. 4 00:00:06,600 --> 00:00:07,670 Tên tôi là Rick Houlihan. 5 00:00:07,670 --> 00:00:10,330 Tôi là một chính cao cấp các giải pháp kiến ​​trúc sư tại AWS. 6 00:00:10,330 --> 00:00:14,070 Tôi tập trung vào NoSQL và Công nghệ DynamoDB. 7 00:00:14,070 --> 00:00:16,930 Tôi ở đây ngày hôm nay để nói chuyện với bạn một chút về những người. 8 00:00:16,930 --> 00:00:18,970 >> Nền của tôi là chủ yếu ở lớp dữ liệu. 9 00:00:18,970 --> 00:00:21,390 Tôi đã dành một nửa phát triển của tôi sự nghiệp bằng văn bản cơ sở dữ liệu, 10 00:00:21,390 --> 00:00:25,930 truy cập dữ liệu, các giải pháp cho các ứng dụng khác nhau. 11 00:00:25,930 --> 00:00:30,000 Tôi đã ở trong đám mây ảo hóa trong khoảng 20 năm. 12 00:00:30,000 --> 00:00:33,460 Vì vậy, trước khi Cloud là Cloud, chúng tôi sử dụng để gọi nó là điện toán tiện ích. 13 00:00:33,460 --> 00:00:37,170 Và ý tưởng được, nó giống như PG & E, bạn phải trả cho những gì bạn sử dụng. 14 00:00:37,170 --> 00:00:38,800 Hôm nay chúng ta gọi nó là điện toán đám mây. 15 00:00:38,800 --> 00:00:41,239 >> Nhưng trong những năm qua, tôi đã làm việc cho một vài công ty 16 00:00:41,239 --> 00:00:42,530 có lẽ bạn đã không bao giờ nghe nói tới. 17 00:00:42,530 --> 00:00:47,470 Nhưng tôi đã biên soạn một danh sách các kỹ thuật thành tựu, tôi đoán bạn muốn nói. 18 00:00:47,470 --> 00:00:51,620 Tôi có tám bằng sáng chế trong hệ thống đám mây ảo hóa, thiết kế bộ vi xử lý, 19 00:00:51,620 --> 00:00:54,440 xử lý sự kiện phức tạp, và các khu vực khác. 20 00:00:54,440 --> 00:00:58,290 >> Vì vậy, những ngày này, tôi tập trung chủ yếu vào NoSQL công nghệ và các thế hệ tiếp theo 21 00:00:58,290 --> 00:00:59,450 cơ sở dữ liệu. 22 00:00:59,450 --> 00:01:03,370 Và đó là nói chung những gì tôi sẽ để được ở đây nói chuyện với bạn hôm nay về. 23 00:01:03,370 --> 00:01:06,030 Vì vậy, những gì bạn có thể mong đợi từ phiên giao dịch này, 24 00:01:06,030 --> 00:01:08,254 chúng ta sẽ đi qua một cách ngắn gọn lịch sử của xử lý dữ liệu. 25 00:01:08,254 --> 00:01:10,420 Nó luôn luôn hữu ích để hiểu, nơi chúng tôi đến từ 26 00:01:10,420 --> 00:01:12,400 và lý do tại sao chúng tôi, nơi chúng tôi đang có. 27 00:01:12,400 --> 00:01:15,600 Và chúng ta sẽ nói một chút chút về công nghệ NoSQL 28 00:01:15,600 --> 00:01:17,500 từ một quan điểm cơ bản. 29 00:01:17,500 --> 00:01:19,870 >> Chúng tôi sẽ nhận được vào một số internals DynamoDB. 30 00:01:19,870 --> 00:01:24,350 DynamoDB là AWS của không có hương vị. 31 00:01:24,350 --> 00:01:27,340 Đó là một hoàn toàn quản lý và lưu trữ giải pháp NoSQL. 32 00:01:27,340 --> 00:01:32,420 Và chúng ta sẽ nói một chút về bảng cấu trúc, các API, các kiểu dữ liệu, lập chỉ mục, 33 00:01:32,420 --> 00:01:35,177 và một số các internals của công nghệ DynamoDB. 34 00:01:35,177 --> 00:01:37,760 Chúng tôi sẽ nhận được vào một số thiết kế mô hình và thực hành tốt nhất. 35 00:01:37,760 --> 00:01:39,968 Chúng tôi sẽ nói về cách bạn sử dụng công nghệ này cho một số 36 00:01:39,968 --> 00:01:41,430 các ứng dụng ngày nay. 37 00:01:41,430 --> 00:01:44,820 Và sau đó chúng tôi sẽ nói một chút về sự tiến hóa hay sự xuất hiện 38 00:01:44,820 --> 00:01:48,980 của một mô hình mới trong lập trình gọi là ứng dụng hướng sự kiện 39 00:01:48,980 --> 00:01:51,580 và làm thế nào DynamoDB đóng ở đó là tốt. 40 00:01:51,580 --> 00:01:54,690 Và chúng tôi sẽ để lại cho bạn một chút một cuộc thảo luận kiến ​​trúc tham khảo 41 00:01:54,690 --> 00:01:59,540 vì vậy chúng tôi có thể nói về một số những cách bạn có thể sử dụng DynamoDB. 42 00:01:59,540 --> 00:02:04,116 >> Vì vậy, đầu tiên off-- này là một câu hỏi Tôi nghe rất nhiều là, một cơ sở dữ liệu là gì. 43 00:02:04,116 --> 00:02:06,240 Rất nhiều người nghĩ rằng họ biết những gì một cơ sở dữ liệu là. 44 00:02:06,240 --> 00:02:08,360 Nếu bạn Google, bạn sẽ thấy điều này. 45 00:02:08,360 --> 00:02:11,675 Đó là một tập cấu trúc dữ liệu được tổ chức trong một máy tính, đặc biệt là một trong những 46 00:02:11,675 --> 00:02:13,600 có thể truy cập trong nhiều cách khác nhau. 47 00:02:13,600 --> 00:02:16,992 Tôi cho rằng đó là một tốt định nghĩa của một cơ sở dữ liệu hiện đại. 48 00:02:16,992 --> 00:02:19,450 Nhưng tôi không thích nó, bởi vì nó ngụ ý một vài điều. 49 00:02:19,450 --> 00:02:20,935 Nó bao hàm cấu trúc. 50 00:02:20,935 --> 00:02:23,120 Và nó ngụ ý rằng nó trên một máy tính. 51 00:02:23,120 --> 00:02:25,750 Và cơ sở dữ liệu không luôn tồn tại trên máy tính. 52 00:02:25,750 --> 00:02:28,020 Cơ sở dữ liệu thực sự tồn tại trong nhiều cách. 53 00:02:28,020 --> 00:02:32,000 >> Vì vậy, một định nghĩa rõ hơn về một cơ sở dữ liệu là một cái gì đó như thế này. 54 00:02:32,000 --> 00:02:34,786 Một cơ sở dữ liệu là một tổ chức cơ chế để lưu trữ, quản lý, 55 00:02:34,786 --> 00:02:35,910 và lấy thông tin. 56 00:02:35,910 --> 00:02:36,868 Đây là từ About.com. 57 00:02:36,868 --> 00:02:42,080 Vì vậy, tôi thích điều này vì nó thực sự đàm phán về một cơ sở dữ liệu là một kho lưu trữ, 58 00:02:42,080 --> 00:02:44,800 một kho lưu trữ của thông tin, không nhất thiết phải 59 00:02:44,800 --> 00:02:46,780 một cái gì đó mà ngồi trên một máy tính. 60 00:02:46,780 --> 00:02:49,290 Và trong suốt lịch sử, chúng ta không phải lúc nào có máy tính. 61 00:02:49,290 --> 00:02:52,110 >> Bây giờ, nếu tôi yêu cầu trung bình phát triển ngày hôm nay có gì 62 00:02:52,110 --> 00:02:54,770 một cơ sở dữ liệu, đó là câu trả lời tôi nhận được. 63 00:02:54,770 --> 00:02:56,070 Một nơi nào đó tôi có thể dính thứ. 64 00:02:56,070 --> 00:02:56,670 Bên phải? 65 00:02:56,670 --> 00:02:58,725 Và đó là sự thật. 66 00:02:58,725 --> 00:02:59,600 Nhưng nó không may. 67 00:02:59,600 --> 00:03:02,700 Bởi vì cơ sở dữ liệu thực sự là nền tảng của các ứng dụng hiện đại. 68 00:03:02,700 --> 00:03:04,810 Nó là nền tảng của mỗi ứng dụng. 69 00:03:04,810 --> 00:03:07,240 Và làm thế nào bạn xây dựng mà cơ sở dữ liệu, làm thế nào bạn cấu trúc 70 00:03:07,240 --> 00:03:11,750 dữ liệu có nghĩa là sẽ sai khiến thế nào mà ứng dụng thực hiện quy mô như bạn. 71 00:03:11,750 --> 00:03:14,640 >> Vì vậy, rất nhiều công việc của tôi ngày hôm nay là đối phó với những gì 72 00:03:14,640 --> 00:03:17,180 xảy ra khi các nhà phát triển cách tiếp cận này 73 00:03:17,180 --> 00:03:19,510 và đối phó với hậu quả của một ứng dụng 74 00:03:19,510 --> 00:03:24,966 hiện đang mở rộng quy mô vượt ra ngoài gốc ý định và đau khổ từ thiết kế xấu. 75 00:03:24,966 --> 00:03:26,840 Vì vậy, hy vọng khi bạn đi bộ ngày hôm nay, bạn sẽ 76 00:03:26,840 --> 00:03:29,010 có một vài công cụ trong vành đai của bạn mà sẽ giữ cho bạn 77 00:03:29,010 --> 00:03:32,566 từ làm cho những sai lầm tương tự. 78 00:03:32,566 --> 00:03:33,066 Được rồi. 79 00:03:33,066 --> 00:03:36,360 Vì vậy, chúng ta hãy nói về một chút các mốc thời gian của công nghệ cơ sở dữ liệu. 80 00:03:36,360 --> 00:03:38,830 Tôi nghĩ rằng tôi đọc một bài viết cách đây không lâu 81 00:03:38,830 --> 00:03:43,020 và nó nói cái gì đó trên lines-- đó là một tuyên bố rất thơ mộng. 82 00:03:43,020 --> 00:03:46,590 Nó nói lịch sử xử lý dữ liệu là 83 00:03:46,590 --> 00:03:49,350 đầy đủ các hình chìm cao dữ liệu phong phú. 84 00:03:49,350 --> 00:03:49,920 ĐƯỢC. 85 00:03:49,920 --> 00:03:52,532 Bây giờ, tôi đoán đó là loại đúng. 86 00:03:52,532 --> 00:03:54,990 Nhưng tôi thực sự nhìn vào là như lịch sử được thực sự đầy 87 00:03:54,990 --> 00:03:56,820 với watermark cao áp dữ liệu. 88 00:03:56,820 --> 00:04:00,040 Bởi vì tốc độ dữ liệu của ăn bao giờ đi xuống. 89 00:04:00,040 --> 00:04:01,360 Nó chỉ đi lên. 90 00:04:01,360 --> 00:04:03,670 >> Và đổi mới xảy ra khi chúng ta thấy áp lực dữ liệu, 91 00:04:03,670 --> 00:04:07,825 là số lượng dữ liệu đó là bây giờ trong đi vào hệ thống. 92 00:04:07,825 --> 00:04:12,027 Và nó không thể được xử lý hiệu quả hoặc trong thời gian hoặc trong chi phí. 93 00:04:12,027 --> 00:04:14,110 Và đó là khi chúng ta bắt đầu nhìn ở áp suất dữ liệu. 94 00:04:14,110 --> 00:04:15,920 >> Vì vậy, khi chúng ta nhìn vào cơ sở dữ liệu đầu tiên, điều này 95 00:04:15,920 --> 00:04:17,180 là một trong đó là giữa đôi tai của chúng tôi. 96 00:04:17,180 --> 00:04:18,310 Chúng tôi đều sinh ra với nó. 97 00:04:18,310 --> 00:04:19,194 Đó là một cơ sở dữ liệu tốt đẹp. 98 00:04:19,194 --> 00:04:21,110 Nó có tính sẵn sàng cao. 99 00:04:21,110 --> 00:04:21,959 Nó luôn luôn trên. 100 00:04:21,959 --> 00:04:23,930 Bạn luôn có thể có được nó. 101 00:04:23,930 --> 00:04:24,890 >> Nhưng đó là người dùng duy nhất. 102 00:04:24,890 --> 00:04:26,348 Tôi không thể chia sẻ những suy nghĩ của tôi với bạn. 103 00:04:26,348 --> 00:04:28,370 Bạn không thể có được những suy nghĩ của tôi khi bạn muốn họ. 104 00:04:28,370 --> 00:04:30,320 Và abilitiy của họ không phải là quá tốt. 105 00:04:30,320 --> 00:04:32,510 Chúng ta quên mất điều này. 106 00:04:32,510 --> 00:04:36,540 Tất cả bây giờ và sau đó, một người trong chúng ta lá và chuyển vào để tồn tại khác 107 00:04:36,540 --> 00:04:39,110 và chúng ta mất tất cả mọi thứ đó là trong cơ sở dữ liệu đó. 108 00:04:39,110 --> 00:04:40,640 Vì vậy, đó không phải là tất cả những gì tốt. 109 00:04:40,640 --> 00:04:43,189 >> Và điều này đã làm việc tốt theo thời gian khi chúng tôi đã trở lại trong ngày 110 00:04:43,189 --> 00:04:46,230 khi tất cả chúng ta thực sự cần phải biết là Chúng ta đi đâu để đi vào ngày mai 111 00:04:46,230 --> 00:04:49,630 hoặc nơi mà chúng tôi thu thập các thực phẩm tốt nhất. 112 00:04:49,630 --> 00:04:52,820 Nhưng khi chúng tôi bắt đầu phát triển như một nền văn minh và chính phủ bắt đầu 113 00:04:52,820 --> 00:04:55,152 để đi vào được, và các doanh nghiệp bắt đầu phát triển, 114 00:04:55,152 --> 00:04:57,360 chúng tôi bắt đầu nhận ra chúng tôi cần nhiều hơn một chút so với những gì 115 00:04:57,360 --> 00:04:58,210 chúng ta có thể đặt ở đầu của chúng tôi. 116 00:04:58,210 --> 00:04:58,870 Được rồi? 117 00:04:58,870 --> 00:05:00,410 >> Chúng tôi cần các hệ thống hồ sơ. 118 00:05:00,410 --> 00:05:02,220 Chúng tôi cần nơi để có thể lưu trữ dữ liệu. 119 00:05:02,220 --> 00:05:05,450 Vì vậy, chúng tôi bắt đầu viết văn, tạo các thư viện và lưu trữ. 120 00:05:05,450 --> 00:05:08,000 Chúng tôi bắt đầu phát triển một hệ thống một kế toán sổ cái. 121 00:05:08,000 --> 00:05:12,200 Và rằng hệ thống sổ kế toán đếm chạy thế giới trong nhiều thế kỷ, 122 00:05:12,200 --> 00:05:15,580 và thậm chí có thể là thiên niên kỷ chúng tôi loại đã tăng đến điểm 123 00:05:15,580 --> 00:05:18,420 nơi mà tải dữ liệu vượt qua khả năng của các hệ thống 124 00:05:18,420 --> 00:05:19,870 để có thể chứa nó. 125 00:05:19,870 --> 00:05:22,070 >> Và điều này thực sự xảy ra trong những năm 1880. 126 00:05:22,070 --> 00:05:22,570 Bên phải? 127 00:05:22,570 --> 00:05:24,390 Trong Tổng điều tra năm 1880 của Mỹ. 128 00:05:24,390 --> 00:05:26,976 Đây thực sự là nơi quay chỉ xử lý dữ liệu hiện đại. 129 00:05:26,976 --> 00:05:28,850 Đây là điểm mà tại mà số lượng dữ liệu 130 00:05:28,850 --> 00:05:32,060 đó đã được thu thập bởi các Chính phủ Mỹ đã đến điểm 131 00:05:32,060 --> 00:05:34,005 nơi mà nó mất tám năm để xử lý. 132 00:05:34,005 --> 00:05:36,350 >> Bây giờ, tám years-- như Bạn có biết, cuộc điều tra 133 00:05:36,350 --> 00:05:39,180 chạy mỗi 10 years-- vì vậy nó khá rõ ràng, theo thời gian chúng tôi 134 00:05:39,180 --> 00:05:41,419 đã điều tra dân số năm 1890, số lượng dữ liệu mà 135 00:05:41,419 --> 00:05:43,210 được sẽ được xử lý bởi chính phủ là 136 00:05:43,210 --> 00:05:46,335 sẽ vượt quá 10 năm mà nó sẽ có được để đưa ra điều tra dân số mới. 137 00:05:46,335 --> 00:05:47,250 Đây là một vấn đề. 138 00:05:47,250 --> 00:05:49,000 >> Vì vậy, một người tên là Herman Hollerith đến cùng 139 00:05:49,000 --> 00:05:52,640 và ông đã phát minh đơn vị lục đục lỗ thẻ, đầu đọc thẻ đục lỗ, thẻ đục lỗ 140 00:05:52,640 --> 00:05:58,420 lập bảng, và collation của các cơ chế cho công nghệ này. 141 00:05:58,420 --> 00:06:01,860 Và công ty mà ông thành lập tại thời gian, cùng với một vài người khác, 142 00:06:01,860 --> 00:06:05,450 thực sự đã trở thành một trong những trụ cột của một công ty nhỏ chúng ta biết ngày nay được gọi là IBM. 143 00:06:05,450 --> 00:06:08,417 >> Vì vậy, IBM ban đầu là trong kinh doanh cơ sở dữ liệu. 144 00:06:08,417 --> 00:06:09,750 Và đó thực sự là những gì họ đã làm. 145 00:06:09,750 --> 00:06:11,110 Họ đã xử lý dữ liệu. 146 00:06:11,110 --> 00:06:15,400 >> Như vậy sự gia tăng của cú đấm thẻ, một cơ chế tài tình 147 00:06:15,400 --> 00:06:18,560 của việc có thể tận dụng mà công nghệ thăm dò ý kiến ​​tập kết quả được sắp xếp. 148 00:06:18,560 --> 00:06:20,726 Bạn có thể nhìn thấy trong ảnh này chúng tôi đã có một little-- 149 00:06:20,726 --> 00:06:23,970 đó là một chút small-- nhưng bạn có thể nhìn thấy một cơ chế cơ học rất khéo léo 150 00:06:23,970 --> 00:06:26,970 nơi chúng tôi có một boong thẻ đục lỗ. 151 00:06:26,970 --> 00:06:28,720 Và lấy của ai đó một chút screwdriver 152 00:06:28,720 --> 00:06:31,400 và gắn bó qua khe và nâng nó lên 153 00:06:31,400 --> 00:06:34,820 để có được trận đấu đó, mà kết quả sắp xếp đặt. 154 00:06:34,820 --> 00:06:36,270 >> Đây là một tập hợp. 155 00:06:36,270 --> 00:06:38,690 Chúng tôi làm tất cả thời gian ngày hôm nay trong máy tính, 156 00:06:38,690 --> 00:06:40,100 nơi bạn làm điều đó trong cơ sở dữ liệu. 157 00:06:40,100 --> 00:06:41,620 Chúng tôi sử dụng để làm điều đó bằng tay, phải không? 158 00:06:41,620 --> 00:06:42,994 Người ta đặt những thứ cùng nhau. 159 00:06:42,994 --> 00:06:45,440 Và đó là sự gia tăng các thẻ đục lỗ 160 00:06:45,440 --> 00:06:50,070 vào những gì chúng ta gọi là trống dữ liệu và dây nối kéo dữ liệu, băng giấy. 161 00:06:50,070 --> 00:06:55,980 >> Các ngành công nghiệp xử lý dữ liệu mất một bài học từ những cây đàn piano chơi. 162 00:06:55,980 --> 00:06:57,855 Chơi đàn piano lại Bước sang thế kỷ 163 00:06:57,855 --> 00:07:02,100 sử dụng để sử dụng cuộn giấy với khe trên để cho biết các phím để chơi. 164 00:07:02,100 --> 00:07:05,380 Vì vậy, công nghệ đã được chuyển thể cuối cùng để lưu trữ dữ liệu kỹ thuật số, 165 00:07:05,380 --> 00:07:08,070 bởi vì họ có thể đưa dữ liệu vào những cuộn băng giấy. 166 00:07:08,070 --> 00:07:10,870 >> Bây giờ, kết quả là, dữ liệu được actually-- như thế nào 167 00:07:10,870 --> 00:07:14,960 bạn truy cập dữ liệu này là trực tiếp phụ thuộc vào cách bạn được lưu giữ nó. 168 00:07:14,960 --> 00:07:17,825 Vì vậy, nếu tôi đặt các dữ liệu trên băng, Tôi đã truy cập vào dữ liệu tuyến tính. 169 00:07:17,825 --> 00:07:20,475 Tôi đã phải tung toàn bộ băng để truy cập tất cả các dữ liệu. 170 00:07:20,475 --> 00:07:22,600 Nếu tôi đưa dữ liệu trong cú đấm thẻ, tôi có thể truy cập nó 171 00:07:22,600 --> 00:07:26,270 trong một ít ngẫu nhiên hơn thời trang, có lẽ không phải là một cách nhanh chóng. 172 00:07:26,270 --> 00:07:30,770 >> Nhưng cũng có những hạn chế trong cách chúng tôi truy cập vào dữ liệu dựa trên cách thức đã được lưu trữ. 173 00:07:30,770 --> 00:07:32,890 Và do đó, đây là một vấn đề đi sâu vào những năm 50. 174 00:07:32,890 --> 00:07:37,890 Một lần nữa, chúng ta có thể bắt đầu thấy rằng khi chúng ta Phát triển công nghệ mới để xử lý 175 00:07:37,890 --> 00:07:41,670 các dữ liệu, phải, nó mở ra cửa cho giải pháp mới, 176 00:07:41,670 --> 00:07:45,852 cho các chương trình mới, mới ứng dụng cho dữ liệu đó. 177 00:07:45,852 --> 00:07:47,810 Và thực sự, quản trị có thể có được lý do 178 00:07:47,810 --> 00:07:49,435 lý do tại sao chúng tôi phát triển một số các hệ thống này. 179 00:07:49,435 --> 00:07:52,290 Nhưng kinh doanh trở nên nhanh chóng người lái xe phía sau tiến hóa 180 00:07:52,290 --> 00:07:54,720 của cơ sở dữ liệu hiện đại và các hệ thống tập tin hiện đại. 181 00:07:54,720 --> 00:07:56,870 >> Vì vậy, điều tiếp theo mà đã đưa ra là vào những năm 50 182 00:07:56,870 --> 00:08:00,780 là hệ thống tập tin và các phát triển của lưu trữ truy cập ngẫu nhiên. 183 00:08:00,780 --> 00:08:02,050 Điều này thật là đẹp. 184 00:08:02,050 --> 00:08:06,230 Bây giờ, tất cả đều đột ngột, chúng tôi có thể đặt chúng tôi các tập tin bất cứ nơi nào trên các ổ đĩa cứng 185 00:08:06,230 --> 00:08:09,760 và chúng ta có thể truy cập dữ liệu ngẫu nhiên. 186 00:08:09,760 --> 00:08:11,950 Chúng ta có thể phân tích rằng thông tin ra các tập tin. 187 00:08:11,950 --> 00:08:14,920 Và chúng tôi giải quyết tất cả các thế giới của vấn đề với xử lý dữ liệu. 188 00:08:14,920 --> 00:08:17,550 >> Và kéo dài khoảng 20 hoặc 30 năm cho đến khi sự tiến hóa 189 00:08:17,550 --> 00:08:22,100 của các cơ sở dữ liệu quan hệ, mà là khi thế giới đã quyết định chúng tôi bây giờ 190 00:08:22,100 --> 00:08:27,940 cần phải có một kho lưu trữ có đánh bại sự mở rộng của dữ liệu trên tập tin 191 00:08:27,940 --> 00:08:29,540 hệ thống mà chúng tôi đã xây dựng. Bên phải? 192 00:08:29,540 --> 00:08:34,270 Quá nhiều dữ liệu phân tán trong quá nhiều nơi, de-sao chép dữ liệu, 193 00:08:34,270 --> 00:08:37,120 và chi phí lưu trữ là rất lớn. 194 00:08:37,120 --> 00:08:43,760 >> Vào những năm 70, các nguồn tài nguyên đắt nhất rằng một máy tính đã được lưu trữ. 195 00:08:43,760 --> 00:08:46,200 Các bộ xử lý được xem như là một chi phí cố định. 196 00:08:46,200 --> 00:08:49,030 Khi tôi mua hộp, CPU làm một số công việc. 197 00:08:49,030 --> 00:08:51,960 Nó sẽ được quay liệu nó thực sự làm việc hay không. 198 00:08:51,960 --> 00:08:53,350 Đó thực sự là một chi phí chìm. 199 00:08:53,350 --> 00:08:56,030 >> Nhưng những gì chi phí cho tôi như một kinh doanh là lưu trữ. 200 00:08:56,030 --> 00:09:00,020 Nếu tôi phải mua đĩa hơn tiếp theo tháng, đó là một chi phí thực tế mà tôi phải trả. 201 00:09:00,020 --> 00:09:01,620 Và lưu trữ đó là đắt tiền. 202 00:09:01,620 --> 00:09:05,020 >> Bây giờ chúng tôi nhanh chóng chuyển tiếp 40 năm và chúng tôi có một vấn đề khác nhau. 203 00:09:05,020 --> 00:09:10,020 Các tính toán bây giờ là tài nguyên đắt tiền nhất. 204 00:09:10,020 --> 00:09:11,470 Việc lưu trữ là rẻ. 205 00:09:11,470 --> 00:09:14,570 Tôi có nghĩa là, chúng ta có thể đi bất cứ nơi nào trên đám mây và chúng ta có thể tìm thấy lưu trữ giá rẻ. 206 00:09:14,570 --> 00:09:17,190 Nhưng tính giá rẻ những gì tôi không thể tìm thấy được. 207 00:09:17,190 --> 00:09:20,700 >> Vì vậy, sự tiến hóa của ngày hôm nay công nghệ, công nghệ cơ sở dữ liệu, 208 00:09:20,700 --> 00:09:23,050 đang thực sự tập trung xung quanh cơ sở dữ liệu phân tán 209 00:09:23,050 --> 00:09:26,960 mà không bị cùng một loại quy mô 210 00:09:26,960 --> 00:09:29,240 hạn chế của cơ sở dữ liệu quan hệ. 211 00:09:29,240 --> 00:09:32,080 Chúng tôi sẽ nói một chút về những gì mà thực sự có nghĩa. 212 00:09:32,080 --> 00:09:34,760 >> Nhưng một trong những lý do và người lái xe phía sau this-- chúng tôi 213 00:09:34,760 --> 00:09:38,290 nói về áp lực dữ liệu. 214 00:09:38,290 --> 00:09:41,920 Áp lực dữ liệu là một cái gì đó mà các ổ đĩa sự đổi mới. 215 00:09:41,920 --> 00:09:44,610 Và nếu bạn nhìn qua năm năm qua, 216 00:09:44,610 --> 00:09:48,180 đây là một biểu đồ về những gì các dữ liệu tải trên toàn doanh nghiệp nói chung 217 00:09:48,180 --> 00:09:49,640 trông giống như trong năm năm qua. 218 00:09:49,640 --> 00:09:52,570 >> Và quy luật chung của ngón tay những days-- nếu bạn đi Google-- 219 00:09:52,570 --> 00:09:55,290 là 90% dữ liệu mà chúng tôi lưu trữ ngày hôm nay, và nó đã được 220 00:09:55,290 --> 00:09:57,330 được tạo ra trong vòng hai năm qua. 221 00:09:57,330 --> 00:09:57,911 ĐƯỢC. 222 00:09:57,911 --> 00:09:59,410 Bây giờ, đây không phải là một xu hướng mới. 223 00:09:59,410 --> 00:10:01,230 Đây là một xu hướng đó là được đi ra ngoài trong 100 năm. 224 00:10:01,230 --> 00:10:03,438 Kể từ khi Herman Hollerith phát triển các thẻ đục lỗ, 225 00:10:03,438 --> 00:10:08,040 chúng tôi đã và đang xây dựng kho dữ liệu và thu thập dữ liệu với tốc phi thường. 226 00:10:08,040 --> 00:10:10,570 >> Vì vậy, trong vòng 100 năm qua, chúng tôi đã nhìn thấy xu hướng này. 227 00:10:10,570 --> 00:10:11,940 Điều đó sẽ không thay đổi. 228 00:10:11,940 --> 00:10:14,789 Tiến tới, chúng ta sẽ thấy này, nếu không phải là một xu hướng tăng nhanh. 229 00:10:14,789 --> 00:10:16,330 Và bạn có thể xem những gì mà trông như thế nào. 230 00:10:16,330 --> 00:10:23,510 >> Nếu một doanh nghiệp trong năm 2010 đã có một terabyte dữ liệu thuộc quyền quản lý, 231 00:10:23,510 --> 00:10:27,080 ngày nay có nghĩa là họ đang quản lý 6,5 petabyte dữ liệu. 232 00:10:27,080 --> 00:10:30,380 Đó là 6.500 dữ liệu nhiều lần. 233 00:10:30,380 --> 00:10:31,200 Và tôi biết điều này. 234 00:10:31,200 --> 00:10:33,292 Tôi làm việc với các doanh nghiệp mỗi ngày. 235 00:10:33,292 --> 00:10:35,000 Năm năm trước đây, tôi sẽ nói chuyện với các công ty 236 00:10:35,000 --> 00:10:38,260 người sẽ nói chuyện với tôi về những gì đau nó là để quản lý terabyte dữ liệu. 237 00:10:38,260 --> 00:10:39,700 Và họ sẽ nói chuyện với tôi về cách chúng ta nhìn 238 00:10:39,700 --> 00:10:41,825 rằng điều này có lẽ sẽ là một petabyte hoặc hai 239 00:10:41,825 --> 00:10:43,030 trong vòng một vài năm. 240 00:10:43,030 --> 00:10:45,170 >> Các công ty cùng Hôm nay tôi gặp gỡ, 241 00:10:45,170 --> 00:10:48,100 và họ đang nói chuyện với tôi về vấn đề đang có việc quản lý 242 00:10:48,100 --> 00:10:51,440 hàng chục, 20 petabyte dữ liệu. 243 00:10:51,440 --> 00:10:53,590 Vì vậy, sự bùng nổ của dữ liệu trong ngành công nghiệp 244 00:10:53,590 --> 00:10:56,670 là lái xe rất lớn cần giải pháp tốt hơn. 245 00:10:56,670 --> 00:11:00,980 Và các cơ sở dữ liệu quan hệ là chỉ là không sống theo nhu cầu. 246 00:11:00,980 --> 00:11:03,490 >> Và do đó, có một tuyến tính tương quan giữa áp suất dữ liệu 247 00:11:03,490 --> 00:11:05,210 và đổi mới kỹ thuật. 248 00:11:05,210 --> 00:11:07,780 Lịch sử đã chỉ cho chúng ta này, mà theo thời gian, 249 00:11:07,780 --> 00:11:11,090 bất cứ khi nào khối lượng dữ liệu mà cần phải được xử lý 250 00:11:11,090 --> 00:11:15,490 vượt quá khả năng của hệ thống để xử lý nó trong một thời gian hợp lý 251 00:11:15,490 --> 00:11:18,870 hoặc tại một chi phí hợp lý, công nghệ sau đó mới 252 00:11:18,870 --> 00:11:21,080 được phát minh ra để giải quyết những vấn đề đó. 253 00:11:21,080 --> 00:11:24,090 Những công nghệ mới, đến lượt nó, mở cửa 254 00:11:24,090 --> 00:11:27,840 đến một loạt vấn đề, trong đó là thu thập dữ liệu nhiều hơn. 255 00:11:27,840 --> 00:11:29,520 >> Bây giờ, chúng tôi sẽ không để ngăn chặn điều này. 256 00:11:29,520 --> 00:11:30,020 Bên phải? 257 00:11:30,020 --> 00:11:31,228 Chúng tôi sẽ không để ngăn chặn điều này. 258 00:11:31,228 --> 00:11:31,830 Tại sao? 259 00:11:31,830 --> 00:11:35,520 Bởi vì bạn không thể biết tất cả mọi thứ có biết trong vũ trụ. 260 00:11:35,520 --> 00:11:40,510 Và miễn là chúng tôi đã được sống, trong suốt lịch sử loài người, 261 00:11:40,510 --> 00:11:43,440 chúng tôi đã luôn luôn hướng để biết thêm. 262 00:11:43,440 --> 00:11:49,840 >> Vì vậy, nó có vẻ như mỗi inch chúng ta di chuyển xuống con đường khám phá khoa học, 263 00:11:49,840 --> 00:11:54,620 chúng tôi được nhân số lượng dữ liệu rằng chúng ta cần phải xử lý theo cấp số nhân 264 00:11:54,620 --> 00:11:59,920 như chúng tôi phát hiện ngày càng nhiều và nhiều hơn nữa về các hoạt động bên trong của cuộc sống, 265 00:11:59,920 --> 00:12:04,530 khoảng cách vũ trụ hoạt động, về lái xe các khám phá khoa học, 266 00:12:04,530 --> 00:12:06,440 và các sáng chế chúng ta đang làm hôm nay. 267 00:12:06,440 --> 00:12:09,570 Khối lượng dữ liệu chỉ liên tục tăng. 268 00:12:09,570 --> 00:12:12,120 Vì vậy, việc có thể để đối phó với vấn đề này là rất lớn. 269 00:12:12,120 --> 00:12:14,790 270 00:12:14,790 --> 00:12:17,410 >> Vì vậy, một trong những điều chúng ta nhìn như tại sao NoSQL? 271 00:12:17,410 --> 00:12:19,200 Làm thế nào để giải quyết vấn đề này NoSQL? 272 00:12:19,200 --> 00:12:24,980 Vâng, cơ sở dữ liệu quan hệ, Structured Query Language, 273 00:12:24,980 --> 00:12:28,600 SQL-- đó là thực sự là một cấu trúc của quan hệ database-- những điều này là 274 00:12:28,600 --> 00:12:30,770 tối ưu hóa cho việc lưu trữ. 275 00:12:30,770 --> 00:12:33,180 >> Trở lại những năm 70, một lần nữa, đĩa là tốn kém. 276 00:12:33,180 --> 00:12:36,990 Các tập thể dục dự phòng của các lưu trữ trong doanh nghiệp là bao giờ kết thúc. 277 00:12:36,990 --> 00:12:37,490 Tôi biết. 278 00:12:37,490 --> 00:12:38,020 Tôi sống nó. 279 00:12:38,020 --> 00:12:41,250 Tôi đã viết trình điều khiển lưu trữ cho một Công ty SuperServer enterprised 280 00:12:41,250 --> 00:12:42,470 trở lại trong những năm 90. 281 00:12:42,470 --> 00:12:45,920 Và dòng dưới cùng là kệ khác mảng lưu trữ chỉ là một cái gì đó 282 00:12:45,920 --> 00:12:47,600 xảy ra mỗi ngày trong các doanh nghiệp. 283 00:12:47,600 --> 00:12:49,030 Và nó không bao giờ dừng lại. 284 00:12:49,030 --> 00:12:52,690 Lưu trữ mật độ cao hơn, nhu cầu cho lưu trữ mật độ cao, 285 00:12:52,690 --> 00:12:56,340 và cho lưu trữ hiệu quả hơn devices-- nó không bao giờ dừng lại. 286 00:12:56,340 --> 00:13:00,160 >> Và NoSQL là một công nghệ tuyệt vời vì nó bình thường hóa dữ liệu. 287 00:13:00,160 --> 00:13:02,210 Nó de-trùng lặp dữ liệu. 288 00:13:02,210 --> 00:13:07,180 Nó đặt các dữ liệu trong một cơ cấu là độc lập với mỗi mô hình truy cập. 289 00:13:07,180 --> 00:13:11,600 Nhiều ứng dụng có thể đánh mà Cơ sở dữ liệu SQL, chạy truy vấn quảng cáo hoc, 290 00:13:11,600 --> 00:13:15,950 và nhận được dữ liệu trong hình dạng mà họ cần phải xử lý khối lượng công việc cho họ. 291 00:13:15,950 --> 00:13:17,570 Đó là âm thanh tuyệt vời. 292 00:13:17,570 --> 00:13:21,350 Nhưng mấu chốt là với bất kỳ hệ thống, nếu nó là bất khả tri đến tất cả mọi thứ, 293 00:13:21,350 --> 00:13:23,500 nó được tối ưu hóa cho không có gì. 294 00:13:23,500 --> 00:13:24,050 ĐƯỢC? 295 00:13:24,050 --> 00:13:26,386 >> Và đó là những gì chúng tôi nhận được với cơ sở dữ liệu quan hệ. 296 00:13:26,386 --> 00:13:27,510 Nó được tối ưu hóa cho việc lưu trữ. 297 00:13:27,510 --> 00:13:28,280 Đó là bình thường. 298 00:13:28,280 --> 00:13:29,370 Đó là quan hệ. 299 00:13:29,370 --> 00:13:31,660 Nó hỗ trợ các truy vấn quảng cáo hoc. 300 00:13:31,660 --> 00:13:34,000 Và nó và nó quy mô theo chiều dọc. 301 00:13:34,000 --> 00:13:39,030 >> Nếu tôi cần để có được một cơ sở dữ liệu SQL lớn hơn hoặc một cơ sở dữ liệu SQL mạnh mẽ hơn, 302 00:13:39,030 --> 00:13:41,090 Tôi đi mua một mảnh lớn của sắt. 303 00:13:41,090 --> 00:13:41,600 ĐƯỢC? 304 00:13:41,600 --> 00:13:44,940 Tôi đã làm việc với rất nhiều khách hàng đã được thông qua nâng cấp lớn 305 00:13:44,940 --> 00:13:48,340 cơ sở hạ tầng của họ chỉ SQL để tìm ra sáu tháng sau, 306 00:13:48,340 --> 00:13:49,750 họ nhấn tường một lần nữa. 307 00:13:49,750 --> 00:13:55,457 Và câu trả lời từ Oracle hoặc MSSQL hoặc bất kỳ ai khác là có được một hộp lớn hơn. 308 00:13:55,457 --> 00:13:58,540 Vâng sớm hay muộn, bạn không thể mua một Hộp lớn hơn, và đó là vấn đề thực sự. 309 00:13:58,540 --> 00:14:00,080 Chúng tôi cần phải thực sự thay đổi mọi thứ. 310 00:14:00,080 --> 00:14:01,080 Vì vậy, nơi làm việc này? 311 00:14:01,080 --> 00:14:06,560 Nó hoạt động tốt cho ẩn phân tích, OLAP loại khối lượng công việc. 312 00:14:06,560 --> 00:14:08,670 Và đó thực sự là nơi thuộc về SQL. 313 00:14:08,670 --> 00:14:12,540 Bây giờ, nó được sử dụng ngày hôm nay tại nhiều tuyến giao dịch xử lý loại 314 00:14:12,540 --> 00:14:13,330 các ứng dụng. 315 00:14:13,330 --> 00:14:16,460 Và nó làm việc tốt tại một số mức độ sử dụng, 316 00:14:16,460 --> 00:14:18,670 nhưng nó chỉ không quy mô cách mà NoSQL không. 317 00:14:18,670 --> 00:14:20,660 Và chúng ta sẽ nói một chút chút về lý do tại sao đó là. 318 00:14:20,660 --> 00:14:23,590 >> Bây giờ, NoSQL, mặt khác, được tối ưu hơn cho tính toán. 319 00:14:23,590 --> 00:14:24,540 ĐƯỢC? 320 00:14:24,540 --> 00:14:26,830 Nó không phải là bất khả tri đến các mô hình truy cập. 321 00:14:26,830 --> 00:14:31,620 Là những gì chúng ta gọi là de-bình thường hóa cấu trúc hoặc một cấu trúc phân cấp. 322 00:14:31,620 --> 00:14:35,000 Các dữ liệu trong cơ sở dữ liệu quan hệ là nối với nhau từ nhiều bảng 323 00:14:35,000 --> 00:14:36,850 để sản xuất các điểm mà bạn cần. 324 00:14:36,850 --> 00:14:40,090 Các dữ liệu trong cơ sở dữ liệu NoSQL một được lưu trữ trong một tài liệu 325 00:14:40,090 --> 00:14:42,100 chứa các cấu trúc phân cấp. 326 00:14:42,100 --> 00:14:45,670 Tất cả các dữ liệu bình thường có thể nối với nhau để tạo ra điểm cho rằng 327 00:14:45,670 --> 00:14:47,160 được lưu trữ trong một tài liệu duy nhất. 328 00:14:47,160 --> 00:14:50,990 Và chúng ta sẽ nói một chút về làm thế nào mà làm việc trong một vài bảng xếp hạng. 329 00:14:50,990 --> 00:14:55,320 >> Nhưng ý tưởng ở đây là bạn lưu trữ dữ liệu của bạn như là những quan điểm khởi tạo. 330 00:14:55,320 --> 00:14:56,410 ĐƯỢC? 331 00:14:56,410 --> 00:14:58,610 Bạn có quy mô theo chiều ngang. 332 00:14:58,610 --> 00:14:59,556 Bên phải? 333 00:14:59,556 --> 00:15:02,100 Nếu tôi cần phải tăng kích thước của cụm NoSQL của tôi, 334 00:15:02,100 --> 00:15:03,700 Tôi không cần phải nhận được một hộp lớn hơn. 335 00:15:03,700 --> 00:15:05,200 Tôi nhận được một hộp khác. 336 00:15:05,200 --> 00:15:07,700 Và tôi tụ họp những người với nhau, và tôi có thể Shard dữ liệu đó. 337 00:15:07,700 --> 00:15:10,780 Chúng tôi sẽ nói một chút về sharding là gì, để được 338 00:15:10,780 --> 00:15:14,270 thể quy mô cơ sở dữ liệu trên nhiều thiết bị vật lý 339 00:15:14,270 --> 00:15:18,370 và loại bỏ các rào cản đó đòi hỏi tôi phải có quy mô theo chiều dọc. 340 00:15:18,370 --> 00:15:22,080 >> Vì vậy, nó thực sự xây dựng cho online xử lý giao dịch và quy mô. 341 00:15:22,080 --> 00:15:25,480 Có một sự khác biệt lớn đây giữa báo cáo, phải không? 342 00:15:25,480 --> 00:15:27,810 Báo cáo, tôi không biết câu hỏi tôi sẽ hỏi. 343 00:15:27,810 --> 00:15:28,310 Bên phải? 344 00:15:28,310 --> 00:15:30,570 Reporting-- nếu một người nào đó từ bộ phận tiếp thị của tôi 345 00:15:30,570 --> 00:15:34,520 muốn just-- bao nhiêu khách hàng của tôi có đặc tính đặc biệt này người 346 00:15:34,520 --> 00:15:37,850 mua trên day-- này tôi không biết truy vấn những gì chúng tôi sẽ yêu cầu. 347 00:15:37,850 --> 00:15:39,160 Vì vậy, tôi cần phải được thuyết bất khả tri. 348 00:15:39,160 --> 00:15:41,810 >> Bây giờ, trong một trực tuyến ứng dụng giao dịch, 349 00:15:41,810 --> 00:15:43,820 Tôi biết những câu hỏi tôi hỏi. 350 00:15:43,820 --> 00:15:46,581 Tôi xây dựng các ứng dụng cho một công việc rất cụ thể. 351 00:15:46,581 --> 00:15:47,080 ĐƯỢC? 352 00:15:47,080 --> 00:15:50,540 Vì vậy, nếu tôi tối ưu hóa dữ liệu lưu trữ để hỗ trợ công việc đó, 353 00:15:50,540 --> 00:15:52,020 nó sẽ được nhanh hơn. 354 00:15:52,020 --> 00:15:55,190 Và đó là lý do tại sao NoSQL thể thực sự đẩy nhanh tiến độ giao hàng 355 00:15:55,190 --> 00:15:57,710 những loại hình dịch vụ. 356 00:15:57,710 --> 00:15:58,210 Được rồi. 357 00:15:58,210 --> 00:16:00,501 >> Vì vậy, chúng ta sẽ nhận được vào một chút về lý thuyết ở đây. 358 00:16:00,501 --> 00:16:03,330 Và một số các bạn, đôi mắt của bạn có thể quay trở lại một chút. 359 00:16:03,330 --> 00:16:06,936 Nhưng tôi sẽ cố gắng để giữ cho nó mức cao nhất có thể. 360 00:16:06,936 --> 00:16:08,880 Vì vậy, nếu bạn đang ở trong dự án quản lý, có 361 00:16:08,880 --> 00:16:12,280 một cấu trúc được gọi là tam giác của sự ràng buộc. 362 00:16:12,280 --> 00:16:12,936 ĐƯỢC. 363 00:16:12,936 --> 00:16:16,060 Các tam giác của sự ép mệnh lệnh bạn không thể có tất cả mọi thứ tất cả các thời gian. 364 00:16:16,060 --> 00:16:17,750 Không thể có chiếc bánh của bạn và ăn nó quá. 365 00:16:17,750 --> 00:16:22,310 Vì vậy, trong quản lý dự án, mà tam hạn chế là bạn có thể có nó rẻ, 366 00:16:22,310 --> 00:16:24,710 bạn có thể có nó nhanh, hoặc bạn có thể có nó tốt. 367 00:16:24,710 --> 00:16:25,716 Chọn hai. 368 00:16:25,716 --> 00:16:27,090 Bởi vì bạn không thể có tất cả ba. 369 00:16:27,090 --> 00:16:27,460 Bên phải? 370 00:16:27,460 --> 00:16:27,820 ĐƯỢC. 371 00:16:27,820 --> 00:16:28,920 >> Vì vậy, bạn nghe về điều này rất nhiều. 372 00:16:28,920 --> 00:16:31,253 Đó là một hạn chế ba, tam giác của sự ràng buộc ba, 373 00:16:31,253 --> 00:16:34,420 hoặc tam giác sắt là oftentimes-- khi bạn nói chuyện với các nhà quản lý dự án, 374 00:16:34,420 --> 00:16:35,420 họ sẽ nói về điều này. 375 00:16:35,420 --> 00:16:37,640 Bây giờ, cơ sở dữ liệu có tam giác sắt của riêng mình. 376 00:16:37,640 --> 00:16:40,350 Và tam giác sắt của dữ liệu là những gì chúng ta gọi là định lý CAP. 377 00:16:40,350 --> 00:16:41,580 ĐƯỢC? 378 00:16:41,580 --> 00:16:43,770 >> CAP mệnh lệnh lý cơ sở dữ liệu hoạt động như thế nào 379 00:16:43,770 --> 00:16:45,627 theo một điều kiện rất cụ thể. 380 00:16:45,627 --> 00:16:47,460 Và chúng ta sẽ nói về những điều kiện đó là. 381 00:16:47,460 --> 00:16:52,221 Nhưng ba điểm của tam giác, có thể nói, là C, nhất quán. 382 00:16:52,221 --> 00:16:52,720 ĐƯỢC? 383 00:16:52,720 --> 00:16:56,760 Vì vậy, trong CAP, nhất quán nghĩa là tất cả khách hàng có thể truy cập cơ sở dữ liệu 384 00:16:56,760 --> 00:16:59,084 sẽ luôn luôn có một rất điểm nhất quán của dữ liệu. 385 00:16:59,084 --> 00:17:00,750 Sẽ không ai xem hai việc khác nhau. 386 00:17:00,750 --> 00:17:01,480 ĐƯỢC? 387 00:17:01,480 --> 00:17:04,020 Nếu tôi thấy các cơ sở dữ liệu, Tôi thấy quan điểm tương tự 388 00:17:04,020 --> 00:17:06,130 là đối tác của tôi đã thấy cơ sở dữ liệu tương tự. 389 00:17:06,130 --> 00:17:07,470 Đó là nhất quán. 390 00:17:07,470 --> 00:17:12,099 >> Sẵn có nghĩa là nếu cơ sở dữ liệu trực tuyến, nếu nó có thể đạt được, 391 00:17:12,099 --> 00:17:14,760 rằng tất cả các khách hàng sẽ luôn luôn có khả năng đọc và viết. 392 00:17:14,760 --> 00:17:15,260 ĐƯỢC? 393 00:17:15,260 --> 00:17:17,010 Vì vậy, mỗi khách hàng mà có thể đọc các cơ sở dữ liệu 394 00:17:17,010 --> 00:17:18,955 sẽ luôn có thể đọc dữ liệu và ghi dữ liệu. 395 00:17:18,955 --> 00:17:21,819 Và nếu đó là trường hợp, nó là một hệ thống có sẵn. 396 00:17:21,819 --> 00:17:24,230 >> Và điểm thứ ba là những gì chúng ta gọi là khoan dung phân vùng. 397 00:17:24,230 --> 00:17:24,730 ĐƯỢC? 398 00:17:24,730 --> 00:17:28,160 Phương tiện khoan dung phân vùng rằng hệ thống hoạt động tốt 399 00:17:28,160 --> 00:17:32,000 mặc dù mạng vật lý phân vùng giữa các nút. 400 00:17:32,000 --> 00:17:32,760 ĐƯỢC? 401 00:17:32,760 --> 00:17:36,270 Vì vậy, các nút trong cluster có thể không nói chuyện với nhau, những gì sẽ xảy ra? 402 00:17:36,270 --> 00:17:36,880 Được rồi. 403 00:17:36,880 --> 00:17:39,545 >> Vì vậy, cơ sở dữ liệu quan hệ choose-- bạn có thể chọn hai trong số này. 404 00:17:39,545 --> 00:17:40,045 ĐƯỢC. 405 00:17:40,045 --> 00:17:43,680 Vì vậy, cơ sở dữ liệu quan hệ chọn để phù hợp và có sẵn. 406 00:17:43,680 --> 00:17:47,510 Nếu phân vùng xảy ra giữa các DataNodes trong các cửa hàng dữ liệu, 407 00:17:47,510 --> 00:17:48,831 cơ sở dữ liệu bị lỗi. 408 00:17:48,831 --> 00:17:49,330 Bên phải? 409 00:17:49,330 --> 00:17:50,900 Nó chỉ đi xuống. 410 00:17:50,900 --> 00:17:51,450 ĐƯỢC. 411 00:17:51,450 --> 00:17:54,230 >> Và đây là lý do tại sao họ có để phát triển với hộp lớn hơn. 412 00:17:54,230 --> 00:17:54,730 Bên phải? 413 00:17:54,730 --> 00:17:58,021 Bởi vì có no-- thường, một cụm cơ sở dữ liệu, không có rất nhiều người trong số họ 414 00:17:58,021 --> 00:17:59,590 hoạt động theo cách đó. 415 00:17:59,590 --> 00:18:03,019 Nhưng hầu hết các cơ sở dữ liệu quy mô theo chiều dọc trong một hộp duy nhất. 416 00:18:03,019 --> 00:18:05,060 Bởi vì họ cần phải được phù hợp và có sẵn. 417 00:18:05,060 --> 00:18:10,320 Nếu một phân vùng đã được tiêm, sau đó bạn sẽ phải thực hiện một sự lựa chọn. 418 00:18:10,320 --> 00:18:13,720 Bạn phải thực hiện một sự lựa chọn giữa là phù hợp và có sẵn. 419 00:18:13,720 --> 00:18:16,080 >> Và đó là những gì cơ sở dữ liệu NoSQL làm. 420 00:18:16,080 --> 00:18:16,580 Được rồi. 421 00:18:16,580 --> 00:18:20,950 Vì vậy, một cơ sở dữ liệu NoSQL, nó có hai hương vị. 422 00:18:20,950 --> 00:18:22,990 Chúng tôi have-- tốt, nó đi kèm trong nhiều hương vị, 423 00:18:22,990 --> 00:18:26,140 nhưng nó đi kèm với hai cơ bản characteristics-- gì 424 00:18:26,140 --> 00:18:30,050 chúng tôi sẽ gọi cho cơ sở dữ liệu CP, hoặc một khoan dung phù hợp và phân vùng 425 00:18:30,050 --> 00:18:31,040 hệ thống. 426 00:18:31,040 --> 00:18:34,930 Những anh chàng này làm cho sự lựa chọn đó khi các nút bị mất liên lạc với nhau, 427 00:18:34,930 --> 00:18:37,091 chúng tôi sẽ không cho phép người để viết nữa. 428 00:18:37,091 --> 00:18:37,590 ĐƯỢC? 429 00:18:37,590 --> 00:18:41,855 >> Cho đến phân vùng đó được lấy ra, truy cập ghi bị chặn. 430 00:18:41,855 --> 00:18:43,230 Điều đó có nghĩa là họ không có sẵn. 431 00:18:43,230 --> 00:18:44,510 Họ là phù hợp. 432 00:18:44,510 --> 00:18:46,554 Khi chúng ta thấy rằng phân vùng tiêm chính nó, 433 00:18:46,554 --> 00:18:48,470 bây giờ chúng tôi là phù hợp, bởi vì chúng tôi sẽ không 434 00:18:48,470 --> 00:18:51,517 để cho phép thay đổi dữ liệu trên hai bên của phân vùng độc lập 435 00:18:51,517 --> 00:18:52,100 của nhau. 436 00:18:52,100 --> 00:18:54,130 Chúng tôi sẽ phải tái lập truyền thông 437 00:18:54,130 --> 00:18:56,930 trước khi bất kỳ bản cập nhật để các dữ liệu cho phép. 438 00:18:56,930 --> 00:18:58,120 ĐƯỢC? 439 00:18:58,120 --> 00:19:02,650 >> Hương vị tiếp theo sẽ là một hệ thống AP, hoặc có sẵn và phân 440 00:19:02,650 --> 00:19:03,640 hệ thống khoan dung. 441 00:19:03,640 --> 00:19:05,320 Những anh chàng không quan tâm. 442 00:19:05,320 --> 00:19:06,020 Bên phải? 443 00:19:06,020 --> 00:19:08,960 Bất kỳ nút mà được một viết, chúng ta sẽ lấy nó. 444 00:19:08,960 --> 00:19:11,480 Vì vậy, tôi đang sao chép dữ liệu của tôi qua nhiều nút. 445 00:19:11,480 --> 00:19:14,730 Những nút có được một khách hàng, khách hàng đến trong, nói, tôi sẽ viết một số dữ liệu. 446 00:19:14,730 --> 00:19:16,300 Node nói, không có vấn đề. 447 00:19:16,300 --> 00:19:18,580 Các nút bên cạnh anh ta được một ghi trên cùng một kỷ lục, 448 00:19:18,580 --> 00:19:20,405 anh ta sẽ nói không có vấn đề. 449 00:19:20,405 --> 00:19:23,030 Một nơi nào đó lại trở lại vào cuối, dữ liệu đó sẽ nhân rộng. 450 00:19:23,030 --> 00:19:27,360 Và sau đó một người nào đó sẽ nhận ra, uh-oh, hệ thống họ sẽ nhận ra, uh-oh, 451 00:19:27,360 --> 00:19:28,870 đã có một sự cập nhật cho hai bên. 452 00:19:28,870 --> 00:19:30,370 Chúng ta làm gì? 453 00:19:30,370 --> 00:19:33,210 Và những gì họ làm sau đó là họ làm điều gì đó 454 00:19:33,210 --> 00:19:36,080 cho phép họ để giải quyết trạng thái dữ liệu. 455 00:19:36,080 --> 00:19:39,000 Và chúng ta sẽ nói về rằng trong biểu đồ tiếp theo. 456 00:19:39,000 --> 00:19:40,000 >> Điều cần chỉ ra ở đây. 457 00:19:40,000 --> 00:19:42,374 Và tôi sẽ không nhận được quá nhiều vào điều này, bởi vì đây 458 00:19:42,374 --> 00:19:43,510 được vào dữ liệu lý thuyết sâu sắc. 459 00:19:43,510 --> 00:19:46,670 Nhưng có một giao dịch khuôn khổ đó 460 00:19:46,670 --> 00:19:50,680 chạy trong một hệ thống quan hệ đó cho phép tôi để thực hiện cập nhật một cách an toàn 461 00:19:50,680 --> 00:19:53,760 đến nhiều đối tượng trong cơ sở dữ liệu. 462 00:19:53,760 --> 00:19:58,320 Và những bản cập nhật sẽ xảy ra tất cả cùng một lúc hoặc không gì cả. 463 00:19:58,320 --> 00:20:00,500 Và điều này được gọi là các giao dịch ACID. 464 00:20:00,500 --> 00:20:01,000 ĐƯỢC? 465 00:20:01,000 --> 00:20:06,570 >> ACID cho chúng ta nguyên tử, tính thống nhất, cô lập, và độ bền. 466 00:20:06,570 --> 00:20:07,070 ĐƯỢC? 467 00:20:07,070 --> 00:20:13,550 Điều đó có nghĩa là nguyên tử, giao dịch, tất cả cập nhật của tôi, hoặc xảy ra hoặc họ không. 468 00:20:13,550 --> 00:20:16,570 Tính nhất quán có nghĩa là cơ sở dữ liệu sẽ luôn luôn 469 00:20:16,570 --> 00:20:19,780 được đưa vào một cách nhất quán nhà nước sau khi cập nhật. 470 00:20:19,780 --> 00:20:23,900 Tôi sẽ không bao giờ rời khỏi cơ sở dữ liệu trong một trạng thái xấu sau khi áp dụng bản cập nhật. 471 00:20:23,900 --> 00:20:24,400 ĐƯỢC? 472 00:20:24,400 --> 00:20:26,720 >> Vì vậy, đó là một chút khác nhau hơn CAP nhất quán. 473 00:20:26,720 --> 00:20:29,760 CAP nhất quán nghĩa là tất cả của tôi khách hàng luôn luôn có thể xem dữ liệu. 474 00:20:29,760 --> 00:20:34,450 Nhất quán ACID có nghĩa là khi một giao dịch được thực hiện, của dữ liệu tốt. 475 00:20:34,450 --> 00:20:35,709 Mối quan hệ của tôi là tất cả tốt. 476 00:20:35,709 --> 00:20:38,750 Tôi sẽ không để xóa một hàng mẹ và để lại một loạt các trẻ em mồ côi 477 00:20:38,750 --> 00:20:40,970 trong một số bảng khác. 478 00:20:40,970 --> 00:20:44,320 Nó không thể xảy ra nếu tôi là phù hợp trong một giao dịch axit. 479 00:20:44,320 --> 00:20:49,120 >> Cách ly có nghĩa là giao dịch sẽ luôn luôn xảy ra sau khi một khác. 480 00:20:49,120 --> 00:20:51,920 Kết quả cuối cùng của dữ liệu sẽ là bang cùng 481 00:20:51,920 --> 00:20:54,770 như thể những giao dịch đã được ban hành đồng thời 482 00:20:54,770 --> 00:20:57,340 đã được thực hiện tuần tự. 483 00:20:57,340 --> 00:21:00,030 Vì vậy, nó đồng thời kiểm soát trong cơ sở dữ liệu. 484 00:21:00,030 --> 00:21:04,130 Vì vậy, về cơ bản, tôi không có thể tăng cùng một giá trị hai lần với hai hoạt động. 485 00:21:04,130 --> 00:21:08,580 >> Nhưng nếu tôi nói thêm 1 giá trị này, và hai giao dịch đi vào 486 00:21:08,580 --> 00:21:10,665 và cố gắng để làm điều đó, một là đi đến đó đầu tiên 487 00:21:10,665 --> 00:21:12,540 và một trong những khác của đi đến đó sau. 488 00:21:12,540 --> 00:21:15,210 Vì vậy, cuối cùng, tôi bổ sung thêm hai. 489 00:21:15,210 --> 00:21:16,170 Bạn thấy những gì tôi có ý nghĩa? 490 00:21:16,170 --> 00:21:16,670 ĐƯỢC. 491 00:21:16,670 --> 00:21:19,220 492 00:21:19,220 --> 00:21:21,250 >> Độ bền là khá đơn giản. 493 00:21:21,250 --> 00:21:23,460 Khi giao dịch được thừa nhận, đó là 494 00:21:23,460 --> 00:21:26,100 sẽ có ngay nếu hệ thống bị treo. 495 00:21:26,100 --> 00:21:29,230 Khi hệ thống mà phục hồi, mà giao dịch đã được cam kết 496 00:21:29,230 --> 00:21:30,480 là thực sự đang có mặt ở đó. 497 00:21:30,480 --> 00:21:33,130 Vì vậy, đó là những bảo đảm các giao dịch ACID. 498 00:21:33,130 --> 00:21:35,470 Đó là những đảm bảo khá tốt đẹp có trên một cơ sở dữ liệu, 499 00:21:35,470 --> 00:21:36,870 nhưng họ đến lúc chi phí đó. 500 00:21:36,870 --> 00:21:37,640 Bên phải? 501 00:21:37,640 --> 00:21:40,520 >> Bởi vì vấn đề với khuôn khổ này là 502 00:21:40,520 --> 00:21:44,540 nếu có một phân vùng trong các dữ liệu tập, tôi phải thực hiện một quyết định. 503 00:21:44,540 --> 00:21:48,000 Tôi sẽ phải cho phép cập nhật về mặt này hay mặt khác. 504 00:21:48,000 --> 00:21:50,310 Và nếu điều đó xảy ra, sau đó tôi không còn đi 505 00:21:50,310 --> 00:21:52,630 để có thể duy trì những đặc điểm. 506 00:21:52,630 --> 00:21:53,960 Họ sẽ không được nhất quán. 507 00:21:53,960 --> 00:21:55,841 Họ sẽ không bị cô lập. 508 00:21:55,841 --> 00:21:58,090 Đây là nơi mà nó phá vỡ cho cơ sở dữ liệu quan hệ. 509 00:21:58,090 --> 00:22:01,360 Đây là lý do quan hệ cơ sở dữ liệu quy mô theo chiều dọc. 510 00:22:01,360 --> 00:22:05,530 >> Mặt khác, chúng ta có những gì được gọi là công nghệ BASE. 511 00:22:05,530 --> 00:22:07,291 Và đây là những cơ sở dữ liệu NoSQL của bạn. 512 00:22:07,291 --> 00:22:07,790 Được rồi. 513 00:22:07,790 --> 00:22:10,180 Vì vậy, chúng tôi có CP của chúng tôi, cơ sở dữ liệu AP. 514 00:22:10,180 --> 00:22:14,720 Và đây là những gì bạn gọi cơ bản có sẵn, nhà nước mềm, cuối cùng 515 00:22:14,720 --> 00:22:15,740 phù hợp. 516 00:22:15,740 --> 00:22:16,420 ĐƯỢC? 517 00:22:16,420 --> 00:22:19,690 >> Về cơ bản có sẵn, vì họ phân vùng chịu. 518 00:22:19,690 --> 00:22:21,470 Họ sẽ luôn luôn được ở đó, thậm chí nếu có 519 00:22:21,470 --> 00:22:23,053 một phân vùng mạng giữa các nút. 520 00:22:23,053 --> 00:22:25,900 Nếu tôi có thể nói chuyện với một nút, tôi đi để có thể đọc dữ liệu. 521 00:22:25,900 --> 00:22:26,460 ĐƯỢC? 522 00:22:26,460 --> 00:22:30,810 Tôi có thể không luôn luôn có thể viết dữ liệu nếu tôi là một nền tảng thống nhất. 523 00:22:30,810 --> 00:22:32,130 Nhưng tôi sẽ có thể đọc dữ liệu. 524 00:22:32,130 --> 00:22:34,960 525 00:22:34,960 --> 00:22:38,010 >> Các trạng thái mềm chỉ mà khi tôi đọc dữ liệu, 526 00:22:38,010 --> 00:22:40,790 nó có thể không được giống như các nút khác. 527 00:22:40,790 --> 00:22:43,390 Nếu quyền đã được ban hành trên một nút ở một nơi khác trong cluster 528 00:22:43,390 --> 00:22:46,650 và nó đã không được nhân rộng trên toàn cụm nhưng khi tôi đọc dữ liệu đó, 529 00:22:46,650 --> 00:22:48,680 trạng thái đó có thể không phù hợp. 530 00:22:48,680 --> 00:22:51,650 Tuy nhiên, nó sẽ được cuối cùng nhất quán, 531 00:22:51,650 --> 00:22:53,870 có nghĩa là khi một viết được thực hiện cho hệ thống, 532 00:22:53,870 --> 00:22:56,480 nó sẽ nhân rộng khắp các nút. 533 00:22:56,480 --> 00:22:59,095 Và cuối cùng, trạng thái đó sẽ được đưa vào nền nếp, 534 00:22:59,095 --> 00:23:00,890 và nó sẽ là một nhà nước thống nhất. 535 00:23:00,890 --> 00:23:05,000 >> Bây giờ, định lý CAP thực sự lượt chỉ với một điều kiện. 536 00:23:05,000 --> 00:23:08,700 Tình trạng đó là khi điều này xảy ra. 537 00:23:08,700 --> 00:23:13,710 Bởi vì bất cứ khi nào nó hoạt động trong chế độ bình thường, không có phân vùng, 538 00:23:13,710 --> 00:23:16,370 mọi thứ đều phù hợp và có sẵn. 539 00:23:16,370 --> 00:23:19,990 Bạn chỉ lo lắng về CAP khi chúng tôi có phân vùng đó. 540 00:23:19,990 --> 00:23:21,260 Vì vậy, những người rất hiếm. 541 00:23:21,260 --> 00:23:25,360 Nhưng làm thế nào hệ thống phản ứng khi những xảy ra sai khiến loại hệ 542 00:23:25,360 --> 00:23:26,750 chúng tôi đang xử lý. 543 00:23:26,750 --> 00:23:31,110 >> Vì vậy, chúng ta hãy nhìn vào những gì mà hình như cho hệ thống AP. 544 00:23:31,110 --> 00:23:32,621 ĐƯỢC? 545 00:23:32,621 --> 00:23:34,830 Hệ thống AP đến trong hai mùi vị. 546 00:23:34,830 --> 00:23:38,514 Họ đi vào các hương vị đó là một thạc sĩ bậc thầy, 100%, luôn luôn có sẵn. 547 00:23:38,514 --> 00:23:40,430 Và họ đi vào các hương vị khác, trong đó nói rằng, 548 00:23:40,430 --> 00:23:43,330 bạn biết không, tôi sẽ lo lắng về điều phân vùng này 549 00:23:43,330 --> 00:23:44,724 khi một phân vùng thực sự xảy ra. 550 00:23:44,724 --> 00:23:47,890 Nếu không, có sẽ là chính hạch người sẽ mất quyền lợi. 551 00:23:47,890 --> 00:23:48,500 ĐƯỢC? 552 00:23:48,500 --> 00:23:50,040 >> Vì vậy, nếu chúng ta một cái gì đó giống như Cassandra. 553 00:23:50,040 --> 00:23:54,440 Cassandra sẽ là một bậc thầy thạc sĩ, hãy cho tôi viết thư cho bất kỳ nút. 554 00:23:54,440 --> 00:23:55,540 Vì vậy, những gì sẽ xảy ra? 555 00:23:55,540 --> 00:23:58,270 Vì vậy, tôi có một đối tượng trong cơ sở dữ liệu tồn tại trên hai nút. 556 00:23:58,270 --> 00:24:01,705 Hãy gọi đó là đối tượng S. Vì vậy, chúng ta có nhà nước cho S. 557 00:24:01,705 --> 00:24:04,312 Chúng tôi có một số hoạt động trên S mà đang được tiến hành. 558 00:24:04,312 --> 00:24:06,270 Cassandra cho phép tôi viết thư cho nhiều nút. 559 00:24:06,270 --> 00:24:08,550 Vì vậy, hãy nói rằng tôi có được một viết cho s để hai nút. 560 00:24:08,550 --> 00:24:12,274 Vâng, những gì xảy ra là kết thúc chúng tôi gọi đó là một sự kiện phân vùng. 561 00:24:12,274 --> 00:24:14,190 Có thể không có một phân vùng mạng vật lý. 562 00:24:14,190 --> 00:24:15,950 Nhưng vì những thiết kế của hệ thống, đó là 563 00:24:15,950 --> 00:24:18,449 thực sự phân vùng ngay khi tôi nhận được một ghi trên hai nút. 564 00:24:18,449 --> 00:24:20,830 Nó không buộc tôi phải viết tất cả thông qua một nút. 565 00:24:20,830 --> 00:24:22,340 Tôi đang viết về hai nút. 566 00:24:22,340 --> 00:24:23,330 ĐƯỢC? 567 00:24:23,330 --> 00:24:25,740 >> Vì vậy, bây giờ tôi có hai trạng thái. 568 00:24:25,740 --> 00:24:26,360 ĐƯỢC? 569 00:24:26,360 --> 00:24:28,110 Điều gì sẽ xảy ra là sớm hay muộn, 570 00:24:28,110 --> 00:24:29,960 có sẽ là một sự kiện nhân rộng. 571 00:24:29,960 --> 00:24:33,300 Có sẽ là những gì chúng tôi được gọi là một phân vùng phục hồi, mà 572 00:24:33,300 --> 00:24:35,200 là nơi mà hai bang quay về bên nhau 573 00:24:35,200 --> 00:24:37,310 và có sẽ là một thuật toán chạy bên trong cơ sở dữ liệu, 574 00:24:37,310 --> 00:24:38,540 quyết định phải làm gì. 575 00:24:38,540 --> 00:24:39,110 ĐƯỢC? 576 00:24:39,110 --> 00:24:43,057 Theo mặc định, bản cập nhật mới nhất thắng trong hầu hết các hệ thống AP. 577 00:24:43,057 --> 00:24:44,890 Vì vậy, có thường là một thuật toán mặc định, những gì 578 00:24:44,890 --> 00:24:47,400 họ gọi một cuộc gọi lại chức năng, một cái gì đó 579 00:24:47,400 --> 00:24:51,000 sẽ được gọi là khi tình trạng này được phát hiện để thực hiện một số logic 580 00:24:51,000 --> 00:24:52,900 để giải quyết cuộc xung đột đó. 581 00:24:52,900 --> 00:24:53,850 ĐƯỢC? 582 00:24:53,850 --> 00:24:58,770 Việc gọi lại mặc định và mặc định giải quyết trong hầu hết các cơ sở dữ liệu AP 583 00:24:58,770 --> 00:25:01,130 là, đoán những gì, dấu thời gian thắng. 584 00:25:01,130 --> 00:25:02,380 Đây là bản cập nhật cuối cùng. 585 00:25:02,380 --> 00:25:04,320 Tôi sẽ đặt bản cập nhật mà ở trong đó. 586 00:25:04,320 --> 00:25:08,440 Tôi có thể đổ kỷ lục này mà tôi đổ ra thành một bản ghi phục hồi 587 00:25:08,440 --> 00:25:11,670 do đó người dùng có thể quay lại sau và nói, hey, đã có một vụ va chạm. 588 00:25:11,670 --> 00:25:12,320 Chuyện gì đã xảy ra? 589 00:25:12,320 --> 00:25:16,370 Và bạn thực sự có thể đổ một kỷ lục tất cả các va chạm và rollbacks 590 00:25:16,370 --> 00:25:17,550 và xem những gì sẽ xảy ra. 591 00:25:17,550 --> 00:25:21,580 >> Bây giờ, khi một người sử dụng, bạn cũng có thể bao gồm logic vào gọi lại đó. 592 00:25:21,580 --> 00:25:24,290 Vì vậy, bạn có thể thay đổi điều đó hoạt động gọi lại. 593 00:25:24,290 --> 00:25:26,730 Bạn có thể nói, hey, tôi muốn để khắc phục các dữ liệu này. 594 00:25:26,730 --> 00:25:28,880 Và tôi muốn thử và hợp hai hồ sơ. 595 00:25:28,880 --> 00:25:30,050 Nhưng đó là tùy thuộc vào bạn. 596 00:25:30,050 --> 00:25:32,880 Các cơ sở dữ liệu không biết làm thế nào để làm điều đó bằng cách mặc định. Hầu hết thời gian, 597 00:25:32,880 --> 00:25:34,850 điều duy nhất cơ sở dữ liệu hiểu biết làm thế nào để làm được nói, 598 00:25:34,850 --> 00:25:36,100 đây là một trong những kỷ lục mới. 599 00:25:36,100 --> 00:25:39,183 Đó là một trong đó là sẽ giành chiến thắng, và đó là giá trị tôi sẽ đưa. 600 00:25:39,183 --> 00:25:41,490 Khi đã phục hồi phân vùng và sao chép xảy ra, 601 00:25:41,490 --> 00:25:43,930 chúng tôi có nhà nước của chúng tôi, bây giờ là S nguyên tố, đó là 602 00:25:43,930 --> 00:25:46,890 trạng thái hợp nhất của tất cả các đối tượng. 603 00:25:46,890 --> 00:25:49,700 Vì vậy, hệ thống AP có này. 604 00:25:49,700 --> 00:25:51,615 Hệ thống CP không cần phải lo lắng về điều này. 605 00:25:51,615 --> 00:25:54,490 Bởi vì ngay sau khi một phân vùng đến vào chơi, họ chỉ cần ngưng dùng 606 00:25:54,490 --> 00:25:55,530 viết. 607 00:25:55,530 --> 00:25:56,180 ĐƯỢC? 608 00:25:56,180 --> 00:25:58,670 Vì vậy, đó là rất dễ dàng để đối phó với sự kiên định 609 00:25:58,670 --> 00:26:01,330 khi bạn không chấp nhận bất kỳ bản cập nhật. 610 00:26:01,330 --> 00:26:04,620 Đó là với các hệ thống CP làm. 611 00:26:04,620 --> 00:26:05,120 Được rồi. 612 00:26:05,120 --> 00:26:07,590 >> Vì vậy, chúng ta hãy nói một chút chút về mô hình truy cập. 613 00:26:07,590 --> 00:26:11,580 Khi chúng ta nói về NoSQL, nó tất cả về cách thức truy cập. 614 00:26:11,580 --> 00:26:13,550 Bây giờ, SQL là ad hoc, các truy vấn. 615 00:26:13,550 --> 00:26:14,481 Đó là cửa hàng quan hệ. 616 00:26:14,481 --> 00:26:16,480 Chúng tôi không phải lo lắng về cách thức truy cập. 617 00:26:16,480 --> 00:26:17,688 Tôi viết một truy vấn rất phức tạp. 618 00:26:17,688 --> 00:26:19,250 Nó đi và nhận dữ liệu. 619 00:26:19,250 --> 00:26:21,210 Đó là những gì điều này có vẻ như thế, bình thường hóa. 620 00:26:21,210 --> 00:26:24,890 >> Vì vậy, trong cấu trúc đặc biệt này, chúng tôi đang tìm kiếm một danh mục sản phẩm. 621 00:26:24,890 --> 00:26:26,640 Tôi có các loại khác nhau của sản phẩm. 622 00:26:26,640 --> 00:26:27,217 Tôi có cuốn sách. 623 00:26:27,217 --> 00:26:27,800 Tôi có album. 624 00:26:27,800 --> 00:26:30,090 Tôi có video. 625 00:26:30,090 --> 00:26:33,370 Các mối quan hệ giữa các sản phẩm và bất kỳ một trong những cuốn sách, album, 626 00:26:33,370 --> 00:26:34,860 và video bàn là 1: 1. 627 00:26:34,860 --> 00:26:35,800 Được rồi? 628 00:26:35,800 --> 00:26:38,860 Tôi đã có một sản phẩm ID, và ID tương ứng 629 00:26:38,860 --> 00:26:41,080 để một cuốn sách, một album, hoặc một video. 630 00:26:41,080 --> 00:26:41,580 ĐƯỢC? 631 00:26:41,580 --> 00:26:44,350 Đó là một 1: mối quan hệ 1 qua những bảng. 632 00:26:44,350 --> 00:26:46,970 >> Bây giờ, tất cả họ books-- có là thuộc tính gốc. 633 00:26:46,970 --> 00:26:47,550 Không sao. 634 00:26:47,550 --> 00:26:48,230 Thật tuyệt. 635 00:26:48,230 --> 00:26:52,130 One-to-one mối quan hệ, tôi nhận được tất cả các dữ liệu tôi cần để mô tả cuốn sách đó. 636 00:26:52,130 --> 00:26:54,770 Album Albums-- có bài hát. 637 00:26:54,770 --> 00:26:56,470 Đây là những gì chúng ta gọi một đến nhiều. 638 00:26:56,470 --> 00:26:58,905 Mỗi album có thể có nhiều bài hát. 639 00:26:58,905 --> 00:27:00,780 Vì vậy, đối với mỗi ca khúc trên album, tôi có thể có 640 00:27:00,780 --> 00:27:02,570 một bản ghi trong bảng con này. 641 00:27:02,570 --> 00:27:04,680 Vì vậy, tôi tạo ra một bản ghi trong bảng album của tôi. 642 00:27:04,680 --> 00:27:06,700 Tôi tạo ra nhiều hồ sơ trong bảng bài hát. 643 00:27:06,700 --> 00:27:08,850 One-to-nhiều mối quan hệ. 644 00:27:08,850 --> 00:27:11,220 >> Mối quan hệ này là gì chúng tôi kêu gọi nhiều-nhiều. 645 00:27:11,220 --> 00:27:11,750 ĐƯỢC? 646 00:27:11,750 --> 00:27:17,000 Bạn thấy rằng các diễn viên có thể trong nhiều bộ phim, nhiều video. 647 00:27:17,000 --> 00:27:21,450 Vì vậy, những gì chúng tôi làm là đưa bản đồ này bảng giữa những người, mà nó chỉ 648 00:27:21,450 --> 00:27:24,040 bản đồ các diễn viên ID để ID video. 649 00:27:24,040 --> 00:27:28,464 Bây giờ tôi có thể tạo ra một truy vấn các gia video thông qua diễn viên phim với các diễn viên, 650 00:27:28,464 --> 00:27:31,130 và nó mang lại cho tôi một danh sách tốt đẹp của tất cả các phim và các diễn viên 651 00:27:31,130 --> 00:27:32,420 những người trong bộ phim đó. 652 00:27:32,420 --> 00:27:33,290 >> ĐƯỢC. 653 00:27:33,290 --> 00:27:33,880 Vì vậy, ở đây chúng tôi đi. 654 00:27:33,880 --> 00:27:38,040 One-to-one là cấp cao nhất mối quan hệ; one-to-many, 655 00:27:38,040 --> 00:27:40,240 album để theo dõi; nhiều-nhiều. 656 00:27:40,240 --> 00:27:44,990 Đó là ba cấp cao mối quan hệ trong bất kỳ cơ sở dữ liệu. 657 00:27:44,990 --> 00:27:48,050 Nếu bạn biết làm thế nào những người các mối quan hệ làm việc với nhau, 658 00:27:48,050 --> 00:27:51,490 sau đó bạn biết rất nhiều về cơ sở dữ liệu đã. 659 00:27:51,490 --> 00:27:55,660 Vì vậy, NoSQL hoạt động hơi khác. 660 00:27:55,660 --> 00:27:58,930 Hãy suy nghĩ về một thứ gì đó vẻ thích đi có được tất cả sản phẩm của tôi. 661 00:27:58,930 --> 00:28:01,096 >> Trong một cửa hàng quan hệ, tôi muốn có được tất cả các sản phẩm của tôi 662 00:28:01,096 --> 00:28:02,970 trên một danh sách của tất cả các sản phẩm của tôi. 663 00:28:02,970 --> 00:28:04,910 Đó là rất nhiều các câu truy vấn. 664 00:28:04,910 --> 00:28:07,030 Tôi có một truy vấn cho tất cả các cuốn sách của tôi. 665 00:28:07,030 --> 00:28:08,470 Tôi có một truy vấn từ các album của tôi. 666 00:28:08,470 --> 00:28:09,970 Và tôi có một truy vấn cho tất cả các video của tôi. 667 00:28:09,970 --> 00:28:11,719 Và tôi đã đặt nó tất cả cùng nhau trong một danh sách 668 00:28:11,719 --> 00:28:15,250 và phục vụ trở lại cho đến ứng dụng đó là yêu cầu nó. 669 00:28:15,250 --> 00:28:18,000 >> Để có được cuốn sách của tôi, tôi tham gia Sản phẩm và Sách. 670 00:28:18,000 --> 00:28:21,680 Để có được album của tôi, tôi đã tham gia Sản phẩm, Albums, và Tracks. 671 00:28:21,680 --> 00:28:25,330 Và để có được đoạn video của tôi, tôi có để tham gia Sản phẩm Videos, 672 00:28:25,330 --> 00:28:28,890 Nam diễn viên tham gia qua Videos, và mang lại những diễn viên. 673 00:28:28,890 --> 00:28:31,020 Vì vậy, đó là ba câu truy vấn. 674 00:28:31,020 --> 00:28:34,560 Truy vấn rất phức tạp để lắp ráp một tập hợp kết quả. 675 00:28:34,560 --> 00:28:36,540 >> Đó là ít hơn tối ưu. 676 00:28:36,540 --> 00:28:39,200 Đây là lý do tại sao khi chúng ta nói về một cấu trúc dữ liệu đó 677 00:28:39,200 --> 00:28:42,900 xây dựng để được thuyết bất khả tri đến việc truy cập pattern-- cũng thật tuyệt vời. 678 00:28:42,900 --> 00:28:45,730 Và bạn có thể thấy điều này thực sự là đẹp như thế nào, chúng tôi đã tổ chức dữ liệu. 679 00:28:45,730 --> 00:28:46,550 Và bạn biết những gì? 680 00:28:46,550 --> 00:28:49,750 Tôi chỉ có một bản ghi cho một diễn viên. 681 00:28:49,750 --> 00:28:50,440 >> Đó là mát mẻ. 682 00:28:50,440 --> 00:28:53,750 Tôi đã trùng lặp tất cả các diễn viên của tôi, và tôi vẫn cho các hiệp hội của tôi 683 00:28:53,750 --> 00:28:55,200 trong bảng vẽ bản đồ này. 684 00:28:55,200 --> 00:29:00,620 Tuy nhiên, nhận được dữ liệu ra trở nên đắt đỏ. 685 00:29:00,620 --> 00:29:04,500 Tôi gửi các CPU trên tất cả các hệ thống tham gia các cấu trúc dữ liệu với nhau 686 00:29:04,500 --> 00:29:05,950 để có thể kéo mà lại dữ liệu. 687 00:29:05,950 --> 00:29:07,310 >> Vì vậy, làm thế nào để tôi nhận được xung quanh đó? 688 00:29:07,310 --> 00:29:11,200 Trong NoSQL nó về tập hợp, không bình thường. 689 00:29:11,200 --> 00:29:13,534 Vì vậy, chúng tôi muốn nói rằng chúng ta muốn hỗ trợ các mô hình truy cập. 690 00:29:13,534 --> 00:29:15,283 Nếu các mô hình truy cập đến các ứng dụng, 691 00:29:15,283 --> 00:29:16,770 Tôi cần để có được tất cả các sản phẩm của tôi. 692 00:29:16,770 --> 00:29:19,027 Hãy đặt tất cả các sản phẩm trong một bảng. 693 00:29:19,027 --> 00:29:22,110 Nếu tôi đặt tất cả các sản phẩm trong một bảng, Tôi chỉ có thể chọn tất cả các sản phẩm 694 00:29:22,110 --> 00:29:23,850 từ bảng đó và tôi có tất cả. 695 00:29:23,850 --> 00:29:25,240 Vâng làm thế nào để làm điều đó? 696 00:29:25,240 --> 00:29:28,124 Cũng trong NoSQL không có cấu trúc để bàn. 697 00:29:28,124 --> 00:29:30,540 Chúng tôi sẽ nói một chút về cách làm việc này trong Dynamo DB. 698 00:29:30,540 --> 00:29:33,570 Nhưng bạn không có cùng các thuộc tính và các tính chất tương tự 699 00:29:33,570 --> 00:29:37,751 trong mỗi hàng duy nhất, trong mỗi đơn mục, như bạn làm trong một bảng SQL. 700 00:29:37,751 --> 00:29:39,750 Và những gì này cho phép tôi làm là rất nhiều thứ 701 00:29:39,750 --> 00:29:41,124 và cung cấp cho tôi rất nhiều tính linh hoạt. 702 00:29:41,124 --> 00:29:45,360 Trong trường hợp đặc biệt này, tôi có tài liệu sản phẩm của tôi. 703 00:29:45,360 --> 00:29:49,090 Và đặc biệt này Ví dụ, tất cả mọi thứ 704 00:29:49,090 --> 00:29:51,930 là một tài liệu trong bảng Products. 705 00:29:51,930 --> 00:29:56,510 Và các sản phẩm cho một cuốn sách có thể có một loại ID mà xác định một cuốn sách. 706 00:29:56,510 --> 00:29:59,180 Và các ứng dụng sẽ chuyển vào ID đó. 707 00:29:59,180 --> 00:30:02,570 >> Tại tầng ứng dụng, tôi sẽ nói oh, những gì ghi lại kiểu gì đây? 708 00:30:02,570 --> 00:30:04,100 Oh, đó là một kỷ lục cuốn sách. 709 00:30:04,100 --> 00:30:05,990 Hồ sơ Book có các đặc tính này. 710 00:30:05,990 --> 00:30:08,100 Hãy để tôi tạo một đối tượng cuốn sách. 711 00:30:08,100 --> 00:30:11,289 Vì vậy, tôi sẽ lấp đầy đối tượng cuốn sách với mặt hàng này. 712 00:30:11,289 --> 00:30:13,080 Tiếp đến mục và nói, mặt hàng này là những gì? 713 00:30:13,080 --> 00:30:14,560 Vâng item này là một album. 714 00:30:14,560 --> 00:30:17,340 Oh, tôi có một toàn bộ khác nhau xử lý thường xuyên cho rằng, 715 00:30:17,340 --> 00:30:18,487 bởi vì nó là một album. 716 00:30:18,487 --> 00:30:19,320 Bạn thấy những gì tôi có ý nghĩa? 717 00:30:19,320 --> 00:30:21,950 >> Vì vậy, các ứng dụng tier-- tôi chỉ cần chọn tất cả các hồ sơ này. 718 00:30:21,950 --> 00:30:23,200 Tất cả họ đều bắt đầu đến nhập. 719 00:30:23,200 --> 00:30:24,680 Họ có thể là tất cả các loại khác nhau. 720 00:30:24,680 --> 00:30:27,590 Và đó là logic của ứng dụng mà chuyển qua những loại 721 00:30:27,590 --> 00:30:29,530 và quyết định làm thế nào để xử lý chúng. 722 00:30:29,530 --> 00:30:33,640 >> Một lần nữa, vì vậy chúng tôi đang tối ưu hóa các giản đồ cho các mô hình truy cập. 723 00:30:33,640 --> 00:30:36,390 Chúng tôi đang làm điều đó bằng cách sụp đổ những bảng. 724 00:30:36,390 --> 00:30:39,670 Chúng tôi về cơ bản việc các cấu trúc bình thường, 725 00:30:39,670 --> 00:30:42,000 và chúng tôi đang xây dựng cấu trúc phân cấp. 726 00:30:42,000 --> 00:30:45,130 Bên trong mỗi một trong những hồ sơ này Tôi sẽ thấy các thuộc mảng. 727 00:30:45,130 --> 00:30:49,400 >> Bên trong tài liệu này cho Album, Tôi đang nhìn thấy các mảng của các bài hát. 728 00:30:49,400 --> 00:30:53,900 Những bài hát hiện nay become-- nó về cơ bản bảng con này mà 729 00:30:53,900 --> 00:30:56,520 tồn tại ngay trong cấu trúc này. 730 00:30:56,520 --> 00:30:57,975 Vì vậy, bạn có thể làm điều này trong DynamoDB. 731 00:30:57,975 --> 00:30:59,810 Bạn có thể làm điều này trong MongoDB. 732 00:30:59,810 --> 00:31:01,437 Bạn có thể làm điều này trong bất kỳ cơ sở dữ liệu NoSQL. 733 00:31:01,437 --> 00:31:03,520 Tạo các loại cấu trúc dữ liệu có thứ bậc 734 00:31:03,520 --> 00:31:07,120 mà cho phép bạn lấy dữ liệu rất nhanh chóng bởi vì bây giờ tôi 735 00:31:07,120 --> 00:31:08,537 không cần phải tuân theo. 736 00:31:08,537 --> 00:31:11,620 Khi tôi chèn một hàng vào các bài hát bảng, hoặc một hàng vào bảng Albums, 737 00:31:11,620 --> 00:31:13,110 Tôi phải phù hợp với lược đồ. 738 00:31:13,110 --> 00:31:18,060 Tôi cần phải có các thuộc tính hoặc các tài sản được xác định trên bảng đó. 739 00:31:18,060 --> 00:31:20,480 Mỗi một trong số họ, khi tôi chèn hàng đó. 740 00:31:20,480 --> 00:31:21,910 Đó không phải là trường hợp trong NoSQL. 741 00:31:21,910 --> 00:31:24,440 >> Tôi có thể có hoàn toàn khác nhau tài sản trong mỗi tài liệu 742 00:31:24,440 --> 00:31:26,100 rằng tôi chèn vào bộ sưu tập. 743 00:31:26,100 --> 00:31:30,480 Vì vậy, cơ chế rất mạnh mẽ. 744 00:31:30,480 --> 00:31:32,852 Và nó thực sự làm thế nào bạn tối ưu hóa hệ thống. 745 00:31:32,852 --> 00:31:35,310 Bởi vì bây giờ mà truy vấn, thay vì trong việc tham gia tất cả các bảng 746 00:31:35,310 --> 00:31:39,160 và thực hiện một nửa tá các truy vấn để kéo lại các dữ liệu tôi cần, 747 00:31:39,160 --> 00:31:40,890 Tôi đang thực hiện một truy vấn. 748 00:31:40,890 --> 00:31:43,010 Và tôi lặp qua kết quả thiết lập. 749 00:31:43,010 --> 00:31:46,512 nó cung cấp cho bạn một ý tưởng về sức mạnh của NoSQL. 750 00:31:46,512 --> 00:31:49,470 Tôi sẽ loại đi ngang đây và nói một chút về điều này. 751 00:31:49,470 --> 00:31:53,240 Đây là loại nhiều tiếp thị hoặc technology-- 752 00:31:53,240 --> 00:31:55,660 tiếp thị của công nghệ loại của cuộc thảo luận. 753 00:31:55,660 --> 00:31:58,672 Nhưng điều quan trọng là phải hiểu bởi vì nếu chúng ta nhìn ở đầu 754 00:31:58,672 --> 00:32:00,380 ở đây vào biểu đồ này, những gì chúng tôi đang tìm kiếm tại 755 00:32:00,380 --> 00:32:04,030 là những gì chúng ta gọi là đường cong cường điệu nghệ. 756 00:32:04,030 --> 00:32:06,121 Và điều này có nghĩa là công cụ mới đến chơi. 757 00:32:06,121 --> 00:32:07,120 Mọi người nghĩ rằng nó rất lớn. 758 00:32:07,120 --> 00:32:09,200 Tôi đã giải quyết tất cả các vấn đề của tôi. 759 00:32:09,200 --> 00:32:11,630 >> Điều này có thể là dấu chấm hết tất cả, là tất cả mọi thứ. 760 00:32:11,630 --> 00:32:12,790 Và họ bắt đầu sử dụng nó. 761 00:32:12,790 --> 00:32:14,720 Và họ nói, công cụ này không hoạt động. 762 00:32:14,720 --> 00:32:17,600 Điều này không đúng. 763 00:32:17,600 --> 00:32:19,105 Các cụ già là tốt hơn. 764 00:32:19,105 --> 00:32:21,230 Và họ trở lại làm mọi thứ theo cách họ. 765 00:32:21,230 --> 00:32:22,730 Và sau đó cuối cùng họ đi, bạn biết những gì? 766 00:32:22,730 --> 00:32:24,040 Công cụ này không phải là quá xấu. 767 00:32:24,040 --> 00:32:26,192 Oh, đó là cách nó hoạt động. 768 00:32:26,192 --> 00:32:28,900 Và một khi họ tìm ra cách nó công trình, họ bắt đầu nhận được tốt hơn. 769 00:32:28,900 --> 00:32:32,050 >> Và điều buồn cười về nó là, nó loại đường lên đến những gì 770 00:32:32,050 --> 00:32:34,300 chúng ta gọi Curve Công nghệ nhận con nuôi. 771 00:32:34,300 --> 00:32:36,910 Vì vậy, những gì xảy ra chúng ta có là một số kích hoạt công nghệ phân loại. 772 00:32:36,910 --> 00:32:39,100 Trong trường hợp cơ sở dữ liệu, đó là áp lực dữ liệu. 773 00:32:39,100 --> 00:32:42,200 Chúng tôi nói về những điểm nước cao áp lực dữ liệu trong suốt thời gian. 774 00:32:42,200 --> 00:32:46,310 Khi đó áp lực dữ liệu truy cập một số điểm, đó là một kích hoạt công nghệ. 775 00:32:46,310 --> 00:32:47,830 >> Nó nhận được quá đắt. 776 00:32:47,830 --> 00:32:49,790 Phải mất quá nhiều thời gian để xử lý dữ liệu. 777 00:32:49,790 --> 00:32:50,890 Chúng ta cần một cái gì đó tốt hơn. 778 00:32:50,890 --> 00:32:52,890 Bạn sẽ có được những nhà cải cách ra có chạy xung quanh, 779 00:32:52,890 --> 00:32:55,050 cố gắng để tìm ra giải pháp là gì. 780 00:32:55,050 --> 00:32:56,050 Ý tưởng mới là gì? 781 00:32:56,050 --> 00:32:58,170 >> Những gì là tốt nhất tiếp theo cách để làm điều này? 782 00:32:58,170 --> 00:32:59,530 Và họ đến với cái gì. 783 00:32:59,530 --> 00:33:03,140 Và những người có nỗi đau thực sự, các chàng trai ở cạnh chảy máu, 784 00:33:03,140 --> 00:33:06,390 họ sẽ nhảy trên tất cả nó, bởi vì họ cần một câu trả lời. 785 00:33:06,390 --> 00:33:09,690 Bây giờ những gì chắc chắn và happens-- nó đang xảy ra ngay bây giờ trong NoSQL. 786 00:33:09,690 --> 00:33:11,090 Tôi nhìn thấy tất cả các thời gian. 787 00:33:11,090 --> 00:33:13,610 >> Những gì xảy ra là không tránh khỏi mọi người bắt đầu sử dụng các công cụ mới 788 00:33:13,610 --> 00:33:15,490 giống như cách họ sử dụng các công cụ cũ. 789 00:33:15,490 --> 00:33:17,854 Và họ phát hiện ra nó không làm việc rất tốt. 790 00:33:17,854 --> 00:33:20,020 Tôi không thể nhớ tôi là ai nói chuyện với đầu ngày hôm nay. 791 00:33:20,020 --> 00:33:22,080 Nhưng nó giống như, khi cái búa khoan được phát minh, 792 00:33:22,080 --> 00:33:24,621 người không xoay nó qua đầu của mình để đập vỡ bê tông. 793 00:33:24,621 --> 00:33:27,360 794 00:33:27,360 --> 00:33:30,610 >> Nhưng đó là những gì xảy ra với NoSQL ngày hôm nay. 795 00:33:30,610 --> 00:33:33,900 Nếu bạn đi bộ trong hầu hết các cửa hàng, họ đang cố gắng để được cửa hàng NoSQL. 796 00:33:33,900 --> 00:33:36,510 Những gì họ đang làm là họ đang sử dụng NoSQL, 797 00:33:36,510 --> 00:33:39,900 và họ đang tải nó đầy đủ các lược đồ quan hệ. 798 00:33:39,900 --> 00:33:41,630 Bởi vì đó là cách họ thiết kế cơ sở dữ liệu. 799 00:33:41,630 --> 00:33:44,046 Và họ đang tự hỏi, tại sao nó không vận hành rất tốt? 800 00:33:44,046 --> 00:33:45,230 Boy, điều này stinks. 801 00:33:45,230 --> 00:33:49,900 Tôi đã phải duy trì tất cả của tôi tham gia in-- nó giống như, không, không. 802 00:33:49,900 --> 00:33:50,800 Duy trì tham gia? 803 00:33:50,800 --> 00:33:52,430 Tại sao các bạn gia nhập dữ liệu? 804 00:33:52,430 --> 00:33:54,350 Bạn không gia nhập dữ liệu trong NoSQL. 805 00:33:54,350 --> 00:33:55,850 Bạn tổng hợp nó. 806 00:33:55,850 --> 00:34:00,690 >> Vì vậy, nếu bạn muốn tránh điều này, tìm hiểu cách công cụ làm việc trước khi bạn thực sự 807 00:34:00,690 --> 00:34:02,010 bắt đầu sử dụng nó. 808 00:34:02,010 --> 00:34:04,860 Đừng cố gắng và sử dụng các công cụ mới cùng một cách bạn sử dụng các công cụ cũ. 809 00:34:04,860 --> 00:34:06,500 Bạn sẽ có một kinh nghiệm xấu. 810 00:34:06,500 --> 00:34:08,848 Và mỗi lần duy nhất đó là những gì này là về. 811 00:34:08,848 --> 00:34:11,389 Khi chúng tôi bắt đầu mọc lên ở đây, đó là bởi vì mọi người đã tìm ra 812 00:34:11,389 --> 00:34:13,449 làm thế nào để sử dụng các công cụ. 813 00:34:13,449 --> 00:34:16,250 >> Họ đã làm điều tương tự khi cơ sở dữ liệu quan hệ đã được phát minh, 814 00:34:16,250 --> 00:34:17,969 và họ đã thay thế các hệ thống tập tin. 815 00:34:17,969 --> 00:34:20,420 Họ đã cố gắng để xây dựng các hệ thống tập tin với cơ sở dữ liệu quan hệ 816 00:34:20,420 --> 00:34:22,159 bởi vì đó là những gì mọi người hiểu. 817 00:34:22,159 --> 00:34:23,049 Nó không làm việc. 818 00:34:23,049 --> 00:34:26,090 Vì vậy, sự hiểu biết về thực hành tốt nhất của công nghệ này bạn đang làm việc với 819 00:34:26,090 --> 00:34:26,730 là rất lớn. 820 00:34:26,730 --> 00:34:29,870 Rất quan trọng. 821 00:34:29,870 --> 00:34:32,440 >> Vì vậy, chúng ta sẽ nhận được vào DynamoDB. 822 00:34:32,440 --> 00:34:36,480 DynamoDB là của AWS hoàn toàn được quản lý nền tảng NoSQL. 823 00:34:36,480 --> 00:34:37,719 Những gì hiện đầy đủ quản lý nghĩa là gì? 824 00:34:37,719 --> 00:34:40,010 Nó có nghĩa là bạn không cần phải thực sự lo lắng về bất cứ điều gì. 825 00:34:40,010 --> 00:34:42,060 >> Bạn đi vào, bạn nói chúng tôi, tôi cần một bảng. 826 00:34:42,060 --> 00:34:43,409 Nó cần nhiều năng lực này. 827 00:34:43,409 --> 00:34:47,300 Bạn nhấn nút, và cung cấp chúng tôi tất cả các cơ sở hạ tầng phía sau cảnh. 828 00:34:47,300 --> 00:34:48,310 Bây giờ là rất lớn. 829 00:34:48,310 --> 00:34:51,310 >> Bởi vì khi bạn nói chuyện về việc mở rộng cơ sở dữ liệu, 830 00:34:51,310 --> 00:34:53,917 Cụm dữ liệu NoSQL tại quy mô, petabytes chạy, 831 00:34:53,917 --> 00:34:55,750 chạy hàng triệu giao dịch mỗi giây, 832 00:34:55,750 --> 00:34:58,180 những điều này không phải là cụm nhỏ. 833 00:34:58,180 --> 00:35:00,830 Chúng ta đang nói hàng ngàn trường hợp. 834 00:35:00,830 --> 00:35:04,480 Quản lý hàng ngàn trường hợp, thậm chí trường ảo, 835 00:35:04,480 --> 00:35:06,350 là một thực tại đau mông. 836 00:35:06,350 --> 00:35:09,110 Tôi có nghĩa là, suy nghĩ về mỗi khi một hệ điều hành bản vá đi ra 837 00:35:09,110 --> 00:35:11,552 hoặc một phiên bản mới của cơ sở dữ liệu. 838 00:35:11,552 --> 00:35:13,260 Điều đó có nghĩa là gì để bạn hoạt động? 839 00:35:13,260 --> 00:35:16,330 Điều đó có nghĩa là bạn đã nhận 1,200 các máy chủ cần phải được cập nhật. 840 00:35:16,330 --> 00:35:18,960 Bây giờ ngay cả với tự động hóa, mà có thể mất một thời gian dài. 841 00:35:18,960 --> 00:35:21,480 Điều đó có thể gây ra rất nhiều đau đầu hoạt động, 842 00:35:21,480 --> 00:35:23,090 bởi vì tôi có thể có dịch vụ xuống. 843 00:35:23,090 --> 00:35:26,070 >> Như tôi đã cập nhật các cơ sở dữ liệu, tôi có thể làm các triển khai xanh xanh 844 00:35:26,070 --> 00:35:29,420 nơi tôi triển khai và nâng cấp một nửa của tôi nút, và sau đó nâng cấp một nửa khác. 845 00:35:29,420 --> 00:35:30,490 Hãy những vụ này. 846 00:35:30,490 --> 00:35:33,410 Vì vậy, việc quản lý cơ sở hạ tầng quy mô là vô cùng đau đớn. 847 00:35:33,410 --> 00:35:36,210 Và AWS lấy nỗi đau mà ra khỏi nó. 848 00:35:36,210 --> 00:35:39,210 Và cơ sở dữ liệu NoSQL thể cực kì đau đớn 849 00:35:39,210 --> 00:35:41,780 vì cách họ mở rộng quy mô. 850 00:35:41,780 --> 00:35:42,926 >> Quy mô theo chiều ngang. 851 00:35:42,926 --> 00:35:45,550 Nếu bạn muốn có được một NoSQL lớn hơn cơ sở dữ liệu, bạn mua các nút hơn. 852 00:35:45,550 --> 00:35:48,660 Mỗi nút bạn mua là một nhức đầu hoạt động. 853 00:35:48,660 --> 00:35:50,830 Vì vậy, hãy để người khác làm điều đó cho bạn. 854 00:35:50,830 --> 00:35:52,000 AWS có thể làm điều đó. 855 00:35:52,000 --> 00:35:54,587 >> Chúng tôi hỗ trợ các giá trị chính tài liệu. 856 00:35:54,587 --> 00:35:56,670 Bây giờ chúng tôi không đi quá nhiều thành trên biểu đồ khác. 857 00:35:56,670 --> 00:35:58,750 Có rất nhiều khác nhau hương vị của NoSQL. 858 00:35:58,750 --> 00:36:02,670 Họ là tất cả các loại nhận munged với nhau vào thời điểm này. 859 00:36:02,670 --> 00:36:06,260 Bạn có thể nhìn vào DynamoDB và nói có, chúng tôi cả một tài liệu và một giá trị quan trọng 860 00:36:06,260 --> 00:36:08,412 lưu trữ điểm này. 861 00:36:08,412 --> 00:36:10,620 Và bạn có thể tranh luận về tính năng của một trong khác. 862 00:36:10,620 --> 00:36:13,950 Đối với tôi, rất nhiều này thực sự là sáu một nửa tá khác. 863 00:36:13,950 --> 00:36:18,710 Mỗi một trong những công nghệ là một công nghệ tốt và một giải pháp tốt. 864 00:36:18,710 --> 00:36:23,390 Tôi sẽ không nói MongoDB là tốt hơn hoặc tồi tệ hơn Couch, sau đó Cassandra, 865 00:36:23,390 --> 00:36:25,994 sau đó Dynamo, hoặc ngược lại. 866 00:36:25,994 --> 00:36:27,285 Ý tôi là, đây chỉ là tùy chọn. 867 00:36:27,285 --> 00:36:29,850 868 00:36:29,850 --> 00:36:32,700 >> Đó là nhanh chóng và nó phù hợp ở quy mô nào. 869 00:36:32,700 --> 00:36:36,210 Vì vậy, đây là một trong những lớn nhất tiền thưởng bạn nhận được với AWS. 870 00:36:36,210 --> 00:36:40,850 Với DynamoDB là khả năng để có được một con số thấp 871 00:36:40,850 --> 00:36:44,040 độ trễ millisecond ở quy mô nào. 872 00:36:44,040 --> 00:36:45,720 Đó là một mục tiêu thiết kế của hệ thống. 873 00:36:45,720 --> 00:36:49,130 Và chúng tôi có khách hàng đang làm hàng triệu giao dịch mỗi giây. 874 00:36:49,130 --> 00:36:52,670 >> Bây giờ tôi sẽ đi qua một số những trường hợp sử dụng trong một vài phút ở đây. 875 00:36:52,670 --> 00:36:55,660 Control-- tích hợp truy cập chúng tôi có những gì chúng ta gọi 876 00:36:55,660 --> 00:36:57,920 Quản lý truy cập Identity, hoặc IAM. 877 00:36:57,920 --> 00:37:01,980 Nó thấm vào mọi hệ thống, mọi dịch vụ AWS cung cấp. 878 00:37:01,980 --> 00:37:03,630 DynamoDB không là ngoại lệ. 879 00:37:03,630 --> 00:37:06,020 Bạn có thể kiểm soát truy cập các bảng DynamoDB. 880 00:37:06,020 --> 00:37:09,960 Trên tất cả các tài khoản của AWS xác định vai trò và quyền hạn truy cập 881 00:37:09,960 --> 00:37:12,140 trong các cơ sở hạ tầng IAM. 882 00:37:12,140 --> 00:37:16,630 >> Và đó là một thành phần quan trọng và không thể thiếu trong những gì chúng ta gọi là sự kiện trình Driven. 883 00:37:16,630 --> 00:37:19,056 Bây giờ đây là một mô hình mới. 884 00:37:19,056 --> 00:37:22,080 >> Đung thế nào là tỷ lệ của bạn thành sự thật tích cực so với âm sai 885 00:37:22,080 --> 00:37:24,052 về hệ thống kiểm soát truy cập của bạn? 886 00:37:24,052 --> 00:37:26,260 RICK Houlihan: dương Đúng so với âm sai? 887 00:37:26,260 --> 00:37:28,785 Đung Quay trở lại những gì bạn nên trở về? 888 00:37:28,785 --> 00:37:33,720 Trái ngược với một lần trong một thời gian nó không trả lại khi cần xác nhận? 889 00:37:33,720 --> 00:37:36,260 890 00:37:36,260 --> 00:37:38,050 >> RICK Houlihan: Tôi không thể nói với bạn rằng. 891 00:37:38,050 --> 00:37:40,140 Nếu có bất kỳ thất bại nào trên đó, 892 00:37:40,140 --> 00:37:42,726 Tôi không phải là người để hỏi rằng câu hỏi cụ thể. 893 00:37:42,726 --> 00:37:43,850 Nhưng đó là một câu hỏi hay. 894 00:37:43,850 --> 00:37:45,905 Tôi sẽ tò mò muốn biết mà bản thân mình, thực sự. 895 00:37:45,905 --> 00:37:48,810 896 00:37:48,810 --> 00:37:51,320 >> Và như vậy thì một lần nữa, mô hình mới là lập trình hướng sự kiện. 897 00:37:51,320 --> 00:37:55,160 Đây là ý tưởng mà bạn có thể triển khai các ứng dụng phức tạp 898 00:37:55,160 --> 00:37:59,720 có thể hoạt động rất, quy mô rất cao mà không có bất kỳ cơ sở hạ tầng nào. 899 00:37:59,720 --> 00:38:02,120 Nếu không có bất kỳ cố định cơ sở hạ tầng nào. 900 00:38:02,120 --> 00:38:04,720 Và chúng ta sẽ nói một chút về điều đó có nghĩa là chúng ta 901 00:38:04,720 --> 00:38:06,550 nhận được trên để các cặp đôi tiếp theo của bảng xếp hạng. 902 00:38:06,550 --> 00:38:08,716 >> Điều đầu tiên chúng tôi sẽ làm là chúng ta sẽ nói về các bảng. 903 00:38:08,716 --> 00:38:10,857 Kiểu dữ liệu API cho Dynamo. 904 00:38:10,857 --> 00:38:13,190 Và điều đầu tiên bạn sẽ thấy nhận thấy khi bạn nhìn vào điều này, 905 00:38:13,190 --> 00:38:17,930 nếu bạn đã quen thuộc với bất kỳ cơ sở dữ liệu, cơ sở dữ liệu có thực sự hai loại API 906 00:38:17,930 --> 00:38:18,430 Tôi muốn gọi nó. 907 00:38:18,430 --> 00:38:21,570 Hoặc hai bộ API. 908 00:38:21,570 --> 00:38:23,840 Một trong những người sẽ được API hành chính. 909 00:38:23,840 --> 00:38:26,710 >> Những điều họ chăm sóc các chức năng của cơ sở dữ liệu. 910 00:38:26,710 --> 00:38:31,340 Cấu hình các công cụ lưu trữ, thiết lập và thêm bảng. 911 00:38:31,340 --> 00:38:35,180 tạo cơ sở dữ liệu danh mục sản phẩm và trường hợp. 912 00:38:35,180 --> 00:38:40,450 Những things-- trong DynamoDB, bạn có rất ngắn, danh sách ngắn. 913 00:38:40,450 --> 00:38:43,120 >> Vì vậy, trong cơ sở dữ liệu khác, bạn có thể thấy hàng chục 914 00:38:43,120 --> 00:38:45,680 các lệnh, hành chính lệnh, để cấu hình 915 00:38:45,680 --> 00:38:47,290 các tùy chọn bổ sung. 916 00:38:47,290 --> 00:38:51,234 Trong DynamoDB bạn không cần những vì bạn không cấu hình hệ thống, chúng tôi làm. 917 00:38:51,234 --> 00:38:54,150 Vì vậy, điều duy nhất bạn cần làm là cho tôi biết những gì kích thước bảng nào tôi cần. 918 00:38:54,150 --> 00:38:55,660 Vì vậy, bạn sẽ có được một rất thiết lập giới hạn của lệnh. 919 00:38:55,660 --> 00:38:58,618 >> Bạn nhận được một Tạo Bảng Update, Bảng, Xóa bảng, và Mô tả Bảng. 920 00:38:58,618 --> 00:39:01,150 Đó là những điều chỉ bạn cần cho DynamoDB. 921 00:39:01,150 --> 00:39:03,294 Bạn không cần một lưu trữ cấu hình động cơ. 922 00:39:03,294 --> 00:39:04,960 Tôi không cần phải lo lắng về việc nhân rộng. 923 00:39:04,960 --> 00:39:06,490 Tôi không cần phải lo lắng về sharding. 924 00:39:06,490 --> 00:39:07,800 >> Tôi không cần phải lo lắng về bất kỳ của công cụ này. 925 00:39:07,800 --> 00:39:08,740 Chúng tôi làm tất cả cho bạn. 926 00:39:08,740 --> 00:39:11,867 Vì vậy, đó là một số tiền rất lớn của overhead đó là chỉ cần nâng lên khỏi đĩa của bạn. 927 00:39:11,867 --> 00:39:13,200 Sau đó, chúng tôi có các nhà khai thác CRUD. 928 00:39:13,200 --> 00:39:17,740 CRUD là một cái gì đó chúng ta gọi trong cơ sở dữ liệu đó là 929 00:39:17,740 --> 00:39:19,860 Tạo, Update, Delete các nhà khai thác. 930 00:39:19,860 --> 00:39:24,180 Đây là những thông thường của bạn hoạt động cơ sở dữ liệu. 931 00:39:24,180 --> 00:39:31,299 Những điều như đặt hàng, nhận hàng, cập nhật mục, xóa, truy vấn hàng loạt, quét. 932 00:39:31,299 --> 00:39:32,840 Nếu bạn muốn quét toàn bộ bảng. 933 00:39:32,840 --> 00:39:34,220 Kéo tất cả mọi thứ ra khỏi bàn. 934 00:39:34,220 --> 00:39:37,130 Một trong những điều tốt đẹp về DynamoDB là nó cho phép quét song song. 935 00:39:37,130 --> 00:39:40,602 Vì vậy, bạn thực sự có thể cho tôi biết bao nhiêu chủ đề bạn muốn chạy trên quét đó. 936 00:39:40,602 --> 00:39:41,810 Và chúng ta có thể chạy các chủ đề. 937 00:39:41,810 --> 00:39:43,985 Chúng tôi có thể quay mà quét lên trên nhiều chủ đề 938 00:39:43,985 --> 00:39:49,060 vì vậy bạn có thể quét toàn bộ bảng không gian rất, rất nhanh chóng trong DynamoDB. 939 00:39:49,060 --> 00:39:51,490 >> Các API khác mà chúng tôi có là những gì chúng ta gọi là Streams API của chúng tôi. 940 00:39:51,490 --> 00:39:52,940 Chúng tôi sẽ không nói quá nhiều về việc này ngay bây giờ. 941 00:39:52,940 --> 00:39:55,189 Tôi đã có một số nội dung sau vào trong boong về việc này. 942 00:39:55,189 --> 00:39:59,910 Nhưng Streams thực sự là một running-- nghĩ về nó như là thời gian đặt hàng 943 00:39:59,910 --> 00:40:01,274 và thay đổi phân vùng log. 944 00:40:01,274 --> 00:40:03,940 Tất cả mọi thứ đang xảy ra trên bảng hiển thị lên trên suối. 945 00:40:03,940 --> 00:40:05,940 >> Mỗi viết vào bảng xuất hiện trên suối. 946 00:40:05,940 --> 00:40:08,370 Bạn có thể đọc dòng đó, và bạn có thể làm việc với nó. 947 00:40:08,370 --> 00:40:10,150 Chúng tôi sẽ nói về những gì loại điều bạn 948 00:40:10,150 --> 00:40:13,680 làm gì với những thứ như sao chép, tạo chỉ mục thứ cấp. 949 00:40:13,680 --> 00:40:17,620 Tất cả các loại thực sự mát mẻ điều bạn có thể làm với điều đó. 950 00:40:17,620 --> 00:40:19,150 >> Các kiểu dữ liệu. 951 00:40:19,150 --> 00:40:23,320 Trong DynamoDB, chúng tôi hỗ trợ cả hai chìa khóa giá trị và dữ liệu tài liệu các loại. 952 00:40:23,320 --> 00:40:26,350 Ở phía bên tay trái của màn hình ở đây, chúng tôi đã có loại cơ bản của chúng tôi. 953 00:40:26,350 --> 00:40:27,230 Các loại giá trị quan trọng. 954 00:40:27,230 --> 00:40:30,040 Đây là chuỗi, số, và các tập tin nhị phân. 955 00:40:30,040 --> 00:40:31,640 >> Vì vậy, chỉ có ba loại cơ bản. 956 00:40:31,640 --> 00:40:33,700 Và sau đó bạn có thể có những bộ. 957 00:40:33,700 --> 00:40:37,650 Một trong những điều tốt đẹp về NoSQL là bạn có thể chứa các mảng như tài sản. 958 00:40:37,650 --> 00:40:42,050 Và với DynamoDB bạn có thể chứa các mảng các loại cơ bản như là một tài sản gốc. 959 00:40:42,050 --> 00:40:43,885 >> Và sau đó có các loại tài liệu. 960 00:40:43,885 --> 00:40:45,510 Có bao nhiêu người đã quen thuộc với JSON? 961 00:40:45,510 --> 00:40:47,130 Các bạn đã quen thuộc với JSON nhiều như vậy? 962 00:40:47,130 --> 00:40:49,380 Đó là cơ bản JavaScript, Đối tượng, Ký hiệu. 963 00:40:49,380 --> 00:40:52,510 Nó cho phép bạn cơ bản định nghĩa một cấu trúc phân cấp. 964 00:40:52,510 --> 00:40:58,107 >> Bạn có thể lưu trữ một tài liệu JSON trên DynamoDB sử dụng các thành phần chung 965 00:40:58,107 --> 00:41:00,940 hoặc khối xây dựng có sẵn trong hầu hết các ngôn ngữ lập trình. 966 00:41:00,940 --> 00:41:03,602 Vì vậy, nếu bạn có Java, bạn nhìn vào bản đồ và danh sách. 967 00:41:03,602 --> 00:41:05,060 Tôi có thể tạo ra các đối tượng mà khu vực bản đồ. 968 00:41:05,060 --> 00:41:08,030 Một bản đồ như là giá trị quan trọng được lưu trữ như là tài sản. 969 00:41:08,030 --> 00:41:10,890 Và nó có thể có danh sách giá trị trong những tài sản. 970 00:41:10,890 --> 00:41:13,490 Bạn có thể lưu trữ phức tạp này cấu trúc phân cấp 971 00:41:13,490 --> 00:41:16,320 như một thuộc tính đơn của một mục DynamoDB. 972 00:41:16,320 --> 00:41:19,010 973 00:41:19,010 --> 00:41:24,460 >> Vì vậy, các bảng trong DynamoDB, giống như hầu hết Cơ sở dữ liệu NoSQL, bảng có các mặt hàng. 974 00:41:24,460 --> 00:41:26,469 Trong MongoDB bạn sẽ gọi các tài liệu này. 975 00:41:26,469 --> 00:41:27,760 Và nó sẽ là cơ sở văng. 976 00:41:27,760 --> 00:41:28,900 Cũng là một cơ sở dữ liệu tài liệu. 977 00:41:28,900 --> 00:41:29,941 Bạn gọi các tài liệu này. 978 00:41:29,941 --> 00:41:32,930 Tài liệu hoặc vật phẩm có thuộc tính. 979 00:41:32,930 --> 00:41:35,850 Thuộc tính có thể tồn tại hoặc không tồn tại trên mục. 980 00:41:35,850 --> 00:41:38,520 Trong DynamoDB, có một thuộc tính bắt buộc. 981 00:41:38,520 --> 00:41:43,880 Cũng giống như trong một cơ sở dữ liệu quan hệ, bạn có một khóa chính trên bàn. 982 00:41:43,880 --> 00:41:46,010 >> DynamoDB có những gì chúng ta gọi là khoá băm. 983 00:41:46,010 --> 00:41:48,280 Khóa băm phải là duy nhất. 984 00:41:48,280 --> 00:41:52,580 Vì vậy, khi tôi định nghĩa một bảng băm, về cơ bản những gì tôi đang nói 985 00:41:52,580 --> 00:41:54,110 là mỗi mục sẽ có một phím băm. 986 00:41:54,110 --> 00:41:58,520 Và mỗi khóa băm phải là duy nhất. 987 00:41:58,520 --> 00:42:01,200 >> Mỗi mặt hàng được định nghĩa bởi đó chính băm độc đáo. 988 00:42:01,200 --> 00:42:02,940 Và chỉ có thể là một. 989 00:42:02,940 --> 00:42:05,820 Đây là OK, nhưng thông thường những gì mọi người cần 990 00:42:05,820 --> 00:42:08,170 là họ muốn là băm này chìa khóa để làm một chút ít hơn 991 00:42:08,170 --> 00:42:11,010 hơn là chỉ có một định danh duy nhất. 992 00:42:11,010 --> 00:42:15,240 Thông thường chúng ta muốn sử dụng đó chính băm như xô mức tập hợp hàng đầu. 993 00:42:15,240 --> 00:42:19,160 Và cách chúng ta làm điều đó là bởi thêm những gì chúng ta gọi là chính phạm vi. 994 00:42:19,160 --> 00:42:22,460 >> Vì vậy, nếu đó là một chỉ băm bảng, điều này phải là duy nhất. 995 00:42:22,460 --> 00:42:27,040 Nếu đó là một hash và phạm vi bảng, sự kết hợp của các hash và phạm vi 996 00:42:27,040 --> 00:42:28,640 phải là duy nhất. 997 00:42:28,640 --> 00:42:30,110 Vì vậy, suy nghĩ về nó theo cách này. 998 00:42:30,110 --> 00:42:32,140 Nếu tôi có một diễn đàn. 999 00:42:32,140 --> 00:42:39,010 Và hình thức có chủ đề, nó có đăng tải, và nó có phản ứng. 1000 00:42:39,010 --> 00:42:42,630 >> Vì vậy, tôi có thể có một băm chính, đó là ID topic. 1001 00:42:42,630 --> 00:42:46,650 Và tôi có thể có một phím phạm vi, đó là ID phản ứng. 1002 00:42:46,650 --> 00:42:49,650 Bằng cách đó, nếu tôi muốn có được tất cả các trả lời cho chủ đề cụ thể, 1003 00:42:49,650 --> 00:42:52,370 Tôi chỉ có thể truy vấn các hash. 1004 00:42:52,370 --> 00:42:55,190 Tôi chỉ có thể nói cho tôi tất cả các vật phẩm có băm này. 1005 00:42:55,190 --> 00:43:01,910 Và tôi sẽ có được mọi câu hỏi hoặc gửi cho chủ đề cụ thể. 1006 00:43:01,910 --> 00:43:03,910 Những quy tụ cấp cao nhất là rất quan trọng. 1007 00:43:03,910 --> 00:43:07,370 Họ hỗ trợ truy cập chính mô hình của các ứng dụng. 1008 00:43:07,370 --> 00:43:09,420 Nói chung, điều này là những gì chúng tôi muốn làm. 1009 00:43:09,420 --> 00:43:11,780 Chúng tôi muốn rằng table-- như bạn nạp bàn, 1010 00:43:11,780 --> 00:43:16,640 chúng ta muốn cấu trúc dữ liệu trong bảng theo cách như vậy 1011 00:43:16,640 --> 00:43:20,140 rằng các ứng dụng có thể rất nhanh chóng lấy lại những kết quả. 1012 00:43:20,140 --> 00:43:24,510 Và đôi khi những cách để làm điều đó là để duy trì các quy tụ như chúng tôi 1013 00:43:24,510 --> 00:43:25,650 chèn dữ liệu. 1014 00:43:25,650 --> 00:43:31,110 Về cơ bản, chúng tôi đang lan rộng các dữ liệu vào xô sáng vì nó đi kèm trong. 1015 00:43:31,110 --> 00:43:35,210 >> Phím phạm vi cho phép băm me-- phím phải được bình đẳng. 1016 00:43:35,210 --> 00:43:39,490 Khi tôi truy vấn một hash, tôi phải nói cho tôi một băm mà bằng này. 1017 00:43:39,490 --> 00:43:41,950 Khi tôi truy vấn nhiều, tôi có thể nói cho tôi một phạm vi 1018 00:43:41,950 --> 00:43:47,040 đó là sử dụng bất kỳ loại điều hành phong phú mà chúng tôi hỗ trợ. 1019 00:43:47,040 --> 00:43:49,200 Hãy cho tôi tất cả các mục trong một hash. 1020 00:43:49,200 --> 00:43:52,520 Có bằng, lớn hơn, ít hơn, nó bắt đầu với, 1021 00:43:52,520 --> 00:43:54,145 nó tồn tại giữa hai giá trị này? 1022 00:43:54,145 --> 00:43:56,811 Vì vậy, các loại truy vấn nhiều rằng chúng tôi luôn quan tâm. 1023 00:43:56,811 --> 00:43:59,650 Bây giờ có một điều về dữ liệu, khi bạn nhìn vào việc truy cập dữ liệu, khi 1024 00:43:59,650 --> 00:44:02,360 bạn truy cập dữ liệu, đó là luôn luôn về một tập hợp. 1025 00:44:02,360 --> 00:44:05,770 Nó luôn luôn về các hồ sơ có liên quan đến điều này. 1026 00:44:05,770 --> 00:44:10,390 Hãy cho tôi tất cả mọi thứ ở đây that's-- tất cả các giao dịch trên thẻ tín dụng này 1027 00:44:10,390 --> 00:44:12,500 cho tháng cuối cùng. 1028 00:44:12,500 --> 00:44:13,960 Đó là một tập hợp. 1029 00:44:13,960 --> 00:44:17,490 >> Hầu như tất cả mọi thứ bạn làm trong cơ sở dữ liệu là một số loại tập hợp. 1030 00:44:17,490 --> 00:44:21,530 Vì vậy, việc có thể để có thể xác định những xô và cung cấp cho bạn những phạm vi 1031 00:44:21,530 --> 00:44:24,950 thuộc tính để có thể truy vấn trên, những truy vấn giàu hỗ trợ nhiều, 1032 00:44:24,950 --> 00:44:27,165 nhiều, nhiều mô hình ứng dụng truy cập. 1033 00:44:27,165 --> 00:44:30,990 1034 00:44:30,990 --> 00:44:35,000 >> Vì vậy, điều khác phím băm không có gì nó mang lại cho chúng ta một cơ chế 1035 00:44:35,000 --> 00:44:37,740 để có thể lây lan các dữ liệu xung quanh. 1036 00:44:37,740 --> 00:44:40,390 Cơ sở dữ liệu NoSQL làm việc tốt nhất khi dữ liệu được đồng đều 1037 00:44:40,390 --> 00:44:41,740 phân phối trên các cluster. 1038 00:44:41,740 --> 00:44:44,530 1039 00:44:44,530 --> 00:44:47,050 Có bao nhiêu người đã quen thuộc với thuật toán băm? 1040 00:44:47,050 --> 00:44:49,860 Khi tôi nói băm và một hashing-- vì một thuật toán băm 1041 00:44:49,860 --> 00:44:54,140 là một cách có thể để tạo ra một giá trị ngẫu nhiên từ bất kỳ giá trị nào đó. 1042 00:44:54,140 --> 00:44:59,300 Vì vậy, trong trường hợp cụ thể này, thuật toán hash chúng chạy là NĐ 5 dựa. 1043 00:44:59,300 --> 00:45:04,765 >> Và nếu tôi có một ID, và điều này là chìa khóa băm của tôi, tôi có 1, 2, 3. 1044 00:45:04,765 --> 00:45:07,390 Khi tôi chạy các thuật toán băm, nó sẽ quay lại và nói, 1045 00:45:07,390 --> 00:45:10,800 cũng 1 bằng 7B, 2 bằng 48, 3 bằng CD. 1046 00:45:10,800 --> 00:45:13,092 Họ đang trải rộng trên tất cả các không gian chính. 1047 00:45:13,092 --> 00:45:14,050 Và tại sao bạn làm điều này? 1048 00:45:14,050 --> 00:45:17,120 Bởi vì đó làm cho chắc chắn rằng tôi có thể đưa các hồ sơ trên nhiều nút. 1049 00:45:17,120 --> 00:45:19,574 >> Nếu tôi làm điều này từng bước, 1, 2, 3. 1050 00:45:19,574 --> 00:45:21,990 Và tôi có một loạt băm chạy trong trường hợp cụ thể này, 1051 00:45:21,990 --> 00:45:24,785 một không gian băm nhỏ, nó chạy từ 00 đến FF, 1052 00:45:24,785 --> 00:45:27,951 sau đó các hồ sơ sẽ đến trong và chúng ta sẽ đi 1, 2, 3, 4, 5, 1053 00:45:27,951 --> 00:45:30,390 6, 7, 8, 9, 10, 11, 12. 1054 00:45:30,390 --> 00:45:31,800 Có chuyện gì? 1055 00:45:31,800 --> 00:45:34,860 Mỗi chèn được đi đến cùng một nút. 1056 00:45:34,860 --> 00:45:36,070 Bạn thấy những gì tôi có ý nghĩa? 1057 00:45:36,070 --> 00:45:40,910 >> Bởi vì khi tôi chia không gian, và tôi trải qua những hồ sơ này, 1058 00:45:40,910 --> 00:45:45,950 và phân vùng I, tôi sẽ nói 1 phân vùng có không gian quan trọng 0-54. 1059 00:45:45,950 --> 00:45:47,720 Phân vùng 2 là 55-89. 1060 00:45:47,720 --> 00:45:49,780 Phân vùng 3 là AA để FF. 1061 00:45:49,780 --> 00:45:53,740 Vì vậy, nếu tôi đang sử dụng tuyến tính incrementing ID, bạn có thể xem những gì đang xảy ra. 1062 00:45:53,740 --> 00:45:57,410 1, 2, 3, 4, 5, 6, tất cả các con đường lên đến 54. 1063 00:45:57,410 --> 00:46:00,030 Vì vậy, như tôi là những búa hồ sơ vào hệ thống, 1064 00:46:00,030 --> 00:46:02,030 tất cả mọi thứ kết thúc sẽ có một nút. 1065 00:46:02,030 --> 00:46:03,160 >> Đó không phải là tốt. 1066 00:46:03,160 --> 00:46:04,820 Đó là một antipattern. 1067 00:46:04,820 --> 00:46:08,760 Trong MongoDB họ có vấn đề này nếu bạn không sử dụng một khóa băm. 1068 00:46:08,760 --> 00:46:11,325 MongoDB cho bạn tùy chọn băm giá trị quan trọng. 1069 00:46:11,325 --> 00:46:13,950 Bạn nên luôn luôn làm điều đó, nếu bạn đang sử dụng một hash incrementing 1070 00:46:13,950 --> 00:46:17,380 quan trọng trong MongoDB, hoặc bạn sẽ được đóng đinh mỗi ghi vào một nút, 1071 00:46:17,380 --> 00:46:21,290 và bạn sẽ được hạn chế bạn viết thông nặng. 1072 00:46:21,290 --> 00:46:24,896 >> Đung Là A9 169 trong số thập phân? 1073 00:46:24,896 --> 00:46:28,450 >> RICK Houlihan: Yeah, đó là ở đâu đó xung quanh đó. 1074 00:46:28,450 --> 00:46:29,950 A9, tôi không biết. 1075 00:46:29,950 --> 00:46:32,200 Bạn muốn có để có được nhị phân của tôi để tính số thập phân. 1076 00:46:32,200 --> 00:46:34,237 Bộ não của tôi không làm việc như thế. 1077 00:46:34,237 --> 00:46:36,320 Đung Chỉ cần một cách nhanh chóng ý kiến ​​của Mongo của bạn. 1078 00:46:36,320 --> 00:46:39,530 Vì vậy, là đối tượng ID mà đến natively với Mongo làm điều đó? 1079 00:46:39,530 --> 00:46:40,179 1080 00:46:40,179 --> 00:46:41,470 RICK Houlihan: Liệu nó làm điều đó? 1081 00:46:41,470 --> 00:46:42,970 Nếu bạn chỉ định nó. 1082 00:46:42,970 --> 00:46:45,030 Với MongoDB, bạn có tùy chọn. 1083 00:46:45,030 --> 00:46:48,930 Bạn có thể specify-- mỗi tài liệu MongoDB phải có một ID gạch dưới. 1084 00:46:48,930 --> 00:46:50,300 Đó là giá trị duy nhất. 1085 00:46:50,300 --> 00:46:55,240 >> Trong MongoDB bạn có thể chỉ định liệu để băm nó hay không. 1086 00:46:55,240 --> 00:46:56,490 Họ chỉ cung cấp cho bạn tùy chọn. 1087 00:46:56,490 --> 00:46:58,198 Nếu bạn biết rằng nó ngẫu nhiên, không có vấn đề. 1088 00:46:58,198 --> 00:46:59,640 Bạn không cần phải làm điều đó. 1089 00:46:59,640 --> 00:47:04,260 Nếu bạn biết rằng nó không phải ngẫu nhiên, mà nó incrementing, sau đó làm các hash. 1090 00:47:04,260 --> 00:47:06,880 >> Bây giờ điều về băm, một khi bạn băm 1091 00:47:06,880 --> 00:47:08,800 một value-- và điều này là tại sao phím băm luôn 1092 00:47:08,800 --> 00:47:13,740 truy vấn duy nhất, bởi vì tôi đã thay đổi giá trị, bây giờ tôi không thể làm một truy vấn nhiều. 1093 00:47:13,740 --> 00:47:15,640 Tôi không thể nói là điều này giữa điều này hay đó, 1094 00:47:15,640 --> 00:47:20,800 bởi vì giá trị băm là không đi là tương đương với giá trị thực tế. 1095 00:47:20,800 --> 00:47:24,570 Vì vậy, khi bạn băm mà trọng, nó chỉ bình đẳng. 1096 00:47:24,570 --> 00:47:28,700 Đây là lý do tại sao trong DynamoDB khóa băm truy vấn là luôn luôn chỉ có sự bình đẳng. 1097 00:47:28,700 --> 00:47:32,090 1098 00:47:32,090 --> 00:47:34,700 >> Vì vậy, bây giờ trong một phạm vi key-- khi tôi thêm rằng chính phạm vi, 1099 00:47:34,700 --> 00:47:38,180 những hồ sơ quan trọng phạm vi tất cả đi vào và họ có được lưu trữ trên cùng một phân vùng. 1100 00:47:38,180 --> 00:47:42,430 Vì vậy, họ rất nhanh chóng, dễ dàng lấy ra vì đây là băm, 1101 00:47:42,430 --> 00:47:43,220 đây là phạm vi. 1102 00:47:43,220 --> 00:47:44,928 Và bạn thấy tất cả mọi thứ với cùng bảng băm 1103 00:47:44,928 --> 00:47:48,550 được lưu trữ trên phân vùng không gian tương tự. 1104 00:47:48,550 --> 00:47:53,889 Bạn có thể sử dụng phím khoảng cách để giúp đỡ xác định vị trí dữ liệu của bạn gần gũi với cha mẹ của nó. 1105 00:47:53,889 --> 00:47:55,180 Vì vậy, những gì tôi thực sự làm gì ở đây? 1106 00:47:55,180 --> 00:47:57,320 Đây là một trong nhiều mối quan hệ. 1107 00:47:57,320 --> 00:48:01,490 Các mối quan hệ giữa một khóa băm và phím phạm vi là một đến nhiều. 1108 00:48:01,490 --> 00:48:03,490 Tôi có thể có nhiều phím băm. 1109 00:48:03,490 --> 00:48:07,610 Tôi chỉ có thể có nhiều dải phím trong mỗi khóa băm. 1110 00:48:07,610 --> 00:48:11,910 >> Băm xác định cha mẹ, phạm vi xác định trẻ em. 1111 00:48:11,910 --> 00:48:15,240 Vì vậy, bạn có thể nhìn thấy ở đây tương tự ở đây giữa xây dựng quan hệ 1112 00:48:15,240 --> 00:48:18,840 và các loại tương tự của xây dựng trong NoSQL. 1113 00:48:18,840 --> 00:48:20,760 Mọi người nói về NoSQL là nonrelational. 1114 00:48:20,760 --> 00:48:22,200 Nó không phải nonrelational. 1115 00:48:22,200 --> 00:48:24,680 Dữ liệu luôn luôn có mối quan hệ. 1116 00:48:24,680 --> 00:48:28,172 Những mối quan hệ chỉ được mô hình hóa khác nhau. 1117 00:48:28,172 --> 00:48:29,880 Hãy nói một chút chút về độ bền. 1118 00:48:29,880 --> 00:48:34,860 Khi bạn viết thư cho DynamoDB, viết luôn ba cách nhân rộng. 1119 00:48:34,860 --> 00:48:37,550 Có nghĩa là chúng tôi có ba AZ của. 1120 00:48:37,550 --> 00:48:39,160 AZ của những khu sẵn có. 1121 00:48:39,160 --> 00:48:43,430 Bạn có thể nghĩ về một Availability Zone là một trung tâm dữ liệu 1122 00:48:43,430 --> 00:48:45,447 hoặc một bộ sưu tập của các trung tâm dữ liệu. 1123 00:48:45,447 --> 00:48:47,780 Những điều này là địa lý phân lập từ mỗi khác 1124 00:48:47,780 --> 00:48:51,610 trên đới đứt gãy khác nhau, qua lưới điện và khu vực đất khác nhau. 1125 00:48:51,610 --> 00:48:54,510 Một thất bại trong một AZ không phải là sẽ đi xuống khác. 1126 00:48:54,510 --> 00:48:56,890 Họ cũng được liên kết cùng với chất xơ tối. 1127 00:48:56,890 --> 00:49:01,240 Nó hỗ trợ một phụ 1 độ trễ millisecond giữa AZS. 1128 00:49:01,240 --> 00:49:05,390 Vì vậy, thời gian thực lặp dữ liệu có khả năng trong đa AZS. 1129 00:49:05,390 --> 00:49:09,990 >> Và đôi khi triển khai đa AZ đáp ứng yêu cầu sẵn sàng cao 1130 00:49:09,990 --> 00:49:12,930 của hầu hết các tổ chức doanh nghiệp. 1131 00:49:12,930 --> 00:49:16,139 Vì vậy DynamoDB được lan truyền trên ba AZS theo mặc định. 1132 00:49:16,139 --> 00:49:19,430 Chúng tôi sẽ chỉ kiến ​​thức write khi hai trong ba nút trở lại 1133 00:49:19,430 --> 00:49:21,470 và nói, Yeah, tôi đã nhận nó. 1134 00:49:21,470 --> 00:49:22,050 Tại sao vậy? 1135 00:49:22,050 --> 00:49:25,950 Bởi vì ở bên chúng tôi đọc chỉ sẽ cung cấp cho bạn các dữ liệu trở lại khi 1136 00:49:25,950 --> 00:49:27,570 chúng tôi nhận được nó từ hai nút. 1137 00:49:27,570 --> 00:49:30,490 >> Nếu tôi đang nhân rộng trên toàn ba, và tôi đọc từ hai, 1138 00:49:30,490 --> 00:49:32,840 Tôi luôn luôn được bảo đảm phải có ít nhất một 1139 00:49:32,840 --> 00:49:35,720 của những người đọc là nhất bản hiện tại của dữ liệu. 1140 00:49:35,720 --> 00:49:38,340 Đó là những gì làm cho DynamoDB phù hợp. 1141 00:49:38,340 --> 00:49:42,450 Bây giờ bạn có thể chọn để biến những người phù hợp đọc off. 1142 00:49:42,450 --> 00:49:45,070 Trong trường hợp đó, tôi sẽ nói, Tôi sẽ chỉ đọc từ một nút. 1143 00:49:45,070 --> 00:49:47,430 Và tôi không thể đảm bảo nó sẽ là dữ liệu mới nhất. 1144 00:49:47,430 --> 00:49:49,450 >> Vì vậy, nếu một ghi được đến, nó đã không được nhân rộng nào, 1145 00:49:49,450 --> 00:49:50,360 bạn sẽ nhận được bản sao đó. 1146 00:49:50,360 --> 00:49:52,220 Đó là một chi tiết cuối cùng phù hợp. 1147 00:49:52,220 --> 00:49:54,640 Và một nửa chi phí đó là những gì được. 1148 00:49:54,640 --> 00:49:56,140 Vì vậy, đây là một cái gì đó để suy nghĩ về. 1149 00:49:56,140 --> 00:50:00,160 Khi bạn đang đọc ra DynamoDB, và bạn đang thiết lập khả năng đọc của bạn 1150 00:50:00,160 --> 00:50:04,430 đơn vị, nếu bạn chọn cuối cùng nhất quán đọc, nó rẻ hơn rất nhiều, 1151 00:50:04,430 --> 00:50:06,010 đó là khoảng một nửa chi phí. 1152 00:50:06,010 --> 00:50:09,342 >> Và do đó, nó giúp bạn tiết kiệm tiền. 1153 00:50:09,342 --> 00:50:10,300 Nhưng đó là sự lựa chọn của bạn. 1154 00:50:10,300 --> 00:50:12,925 Nếu bạn muốn đọc nhất quán hay một chi tiết cuối cùng phù hợp. 1155 00:50:12,925 --> 00:50:15,720 Đó là một cái gì đó mà bạn có thể lựa chọn. 1156 00:50:15,720 --> 00:50:17,659 >> Hãy nói về chỉ số. 1157 00:50:17,659 --> 00:50:19,450 Vì vậy, chúng tôi đã đề cập rằng đầu tập hợp mức. 1158 00:50:19,450 --> 00:50:23,720 Chúng tôi đã có phím băm, và chúng tôi đã có nhiều phím. 1159 00:50:23,720 --> 00:50:24,320 Đó là tốt đẹp. 1160 00:50:24,320 --> 00:50:26,950 Và đó là trên bàn học, Tôi có một khoá băm, tôi đã nhận một trọng phạm vi. 1161 00:50:26,950 --> 00:50:27,783 >> Điều đó có nghĩa là gì? 1162 00:50:27,783 --> 00:50:30,410 Tôi đã có một thuộc tính mà tôi có thể chạy các truy vấn giàu chống lại. 1163 00:50:30,410 --> 00:50:31,800 Đó là chìa khóa loạt. 1164 00:50:31,800 --> 00:50:35,530 Các thuộc tính khác trên item-- đó Tôi có thể lọc trên những thuộc tính. 1165 00:50:35,530 --> 00:50:40,050 Nhưng tôi không thể làm những việc như thế, nó bắt đầu bằng hoặc lớn hơn. 1166 00:50:40,050 --> 00:50:40,820 >> Làm thế nào để làm điều đó? 1167 00:50:40,820 --> 00:50:42,860 Tôi tạo ra một chỉ số. 1168 00:50:42,860 --> 00:50:45,340 Có hai loại chỉ số trong DynamoDB. 1169 00:50:45,340 --> 00:50:49,002 Một chỉ số thực sự là nhìn khác của bảng. 1170 00:50:49,002 --> 00:50:50,490 Và chỉ số thứ cấp địa phương. 1171 00:50:50,490 --> 00:50:51,781 >> Người đầu tiên chúng tôi sẽ nói về. 1172 00:50:51,781 --> 00:50:57,740 Secondaries Vì vậy, địa phương đang cùng tồn tại trên cùng một phân vùng như là dữ liệu. 1173 00:50:57,740 --> 00:51:00,240 Và như vậy, họ đang trên các nút vật lý như nhau. 1174 00:51:00,240 --> 00:51:01,780 Họ là những gì chúng ta gọi là nhất quán. 1175 00:51:01,780 --> 00:51:04,599 Ý nghĩa, họ sẽ thừa nhận write cùng với bảng. 1176 00:51:04,599 --> 00:51:06,890 Khi viết đến, chúng tôi sẽ viết thư thông qua các chỉ số. 1177 00:51:06,890 --> 00:51:09,306 Chúng tôi sẽ viết lên bàn, và sau đó chúng tôi sẽ xác nhận. 1178 00:51:09,306 --> 00:51:10,490 Vì vậy, đó là phù hợp. 1179 00:51:10,490 --> 00:51:13,174 Một khi đã được ghi thừa nhận từ bảng, 1180 00:51:13,174 --> 00:51:15,090 nó đảm bảo rằng các Chỉ số thứ địa phương 1181 00:51:15,090 --> 00:51:18,380 sẽ có cùng một tầm nhìn của dữ liệu. 1182 00:51:18,380 --> 00:51:22,390 Nhưng những gì họ cho phép bạn làm là xác định phạm vi các phím thay thế. 1183 00:51:22,390 --> 00:51:25,260 >> Phải sử dụng cùng bảng băm chính là bảng chính, 1184 00:51:25,260 --> 00:51:29,050 bởi vì họ là đồng nằm trên cùng một phân vùng, và họ là phù hợp. 1185 00:51:29,050 --> 00:51:33,110 Nhưng tôi có thể tạo ra một chỉ số với các phím phạm vi khác nhau. 1186 00:51:33,110 --> 00:51:41,590 Vì vậy, ví dụ, nếu tôi đã có một nhà sản xuất rằng đã có một bảng phụ liệu sắp tới trong. 1187 00:51:41,590 --> 00:51:44,590 Và phần thô đi vào, và họ đang tổng hợp bằng cách lắp ráp. 1188 00:51:44,590 --> 00:51:46,840 Và có lẽ đó là một hồi. 1189 00:51:46,840 --> 00:51:50,240 >> Bất kỳ phần nào đã được thực hiện bằng cách này nhà sản xuất sau ngày này, 1190 00:51:50,240 --> 00:51:52,840 Tôi cần phải kéo từ đường của tôi. 1191 00:51:52,840 --> 00:51:55,950 Tôi có thể quay một chỉ số mà có thể tìm kiếm, 1192 00:51:55,950 --> 00:52:00,760 tập hợp vào ngày sản xuất của một phần cụ thể. 1193 00:52:00,760 --> 00:52:03,930 Vì vậy, nếu bảng cấp cao nhất của tôi là đã băm bởi nhà sản xuất, 1194 00:52:03,930 --> 00:52:07,655 có thể nó đã được sắp xếp vào phần ID, tôi có thể tạo ra một chỉ số tắt bảng đó 1195 00:52:07,655 --> 00:52:11,140 như băm của nhà sản xuất và dao động về ngày sản xuất. 1196 00:52:11,140 --> 00:52:14,490 Và cách mà tôi có thể nói, bất cứ điều gì được sản xuất giữa những ngày này, 1197 00:52:14,490 --> 00:52:16,804 Tôi cần phải kéo từ dòng. 1198 00:52:16,804 --> 00:52:18,220 Vì vậy, đó là một chỉ số trung học địa phương. 1199 00:52:18,220 --> 00:52:22,280 >> Những có tác dụng hạn chế không gian chính băm của bạn. 1200 00:52:22,280 --> 00:52:24,360 Bởi vì họ đồng tồn tại vào nút lưu trữ, 1201 00:52:24,360 --> 00:52:26,860 họ giới hạn các khóa băm không gian đến 10 GB. 1202 00:52:26,860 --> 00:52:28,950 DynamoDB, dưới bảng, sẽ phân vùng 1203 00:52:28,950 --> 00:52:31,380 bảng của bạn mỗi 10 gigabyte. 1204 00:52:31,380 --> 00:52:34,760 Khi bạn đặt 10 đồng biểu diễn của dữ liệu trong, chúng tôi đi [PHH], và chúng tôi thêm một nút khác. 1205 00:52:34,760 --> 00:52:38,120 1206 00:52:38,120 --> 00:52:42,070 >> Chúng tôi sẽ không chia LSI trên nhiều phân vùng. 1207 00:52:42,070 --> 00:52:43,200 Chúng tôi sẽ chia bảng. 1208 00:52:43,200 --> 00:52:44,679 Nhưng chúng tôi sẽ không phân chia các LSI. 1209 00:52:44,679 --> 00:52:46,470 Vì vậy, đó là một cái gì đó quan trọng để hiểu 1210 00:52:46,470 --> 00:52:50,070 là nếu bạn đang làm rất, rất, quy tụ rất lớn, 1211 00:52:50,070 --> 00:52:53,860 sau đó bạn sẽ được giới hạn đến 10 gigabytes trên LSIs của bạn. 1212 00:52:53,860 --> 00:52:56,640 >> Nếu đó là trường hợp, chúng ta có thể sử dụng secondaries toàn cầu. 1213 00:52:56,640 --> 00:52:58,630 Secondaries toàn cầu là thực sự bàn khác. 1214 00:52:58,630 --> 00:53:01,720 Chúng tồn tại hoàn toàn tắt để các bên của bảng chính của bạn. 1215 00:53:01,720 --> 00:53:04,680 Và họ cho phép tôi để tìm một cấu trúc hoàn toàn khác nhau. 1216 00:53:04,680 --> 00:53:08,010 Vì vậy, suy nghĩ của nó như là dữ liệu được chèn vào vào hai bảng khác nhau, cấu trúc 1217 00:53:08,010 --> 00:53:09,220 theo hai cách khác nhau. 1218 00:53:09,220 --> 00:53:11,360 >> Tôi có thể xác định một hoàn toàn khóa băm khác nhau. 1219 00:53:11,360 --> 00:53:13,490 Tôi có thể xác định một hoàn toàn key phạm vi khác nhau. 1220 00:53:13,490 --> 00:53:15,941 Và tôi có thể chạy này hoàn toàn độc lập. 1221 00:53:15,941 --> 00:53:18,190 Như một vấn đề của thực tế, tôi đã được cung cấp khả năng đọc của tôi 1222 00:53:18,190 --> 00:53:21,090 và viết công suất cho tôi chỉ số trung toàn cầu 1223 00:53:21,090 --> 00:53:24,240 hoàn toàn độc lập của bảng chính của tôi. 1224 00:53:24,240 --> 00:53:26,640 Nếu tôi xác định chỉ số đó, tôi nói nó bao nhiêu đọc và viết 1225 00:53:26,640 --> 00:53:28,610 khả năng nó sẽ được sử dụng. 1226 00:53:28,610 --> 00:53:31,490 >> Và đó là riêng biệt từ bảng chính của tôi. 1227 00:53:31,490 --> 00:53:35,240 Bây giờ cả hai chỉ số cho phép chúng tôi không chỉ xác định băm và nhiều phím, 1228 00:53:35,240 --> 00:53:38,610 nhưng họ cho phép chúng tôi dự án giá trị bổ sung. 1229 00:53:38,610 --> 00:53:44,950 Vì vậy, nếu tôi muốn đọc ra các chỉ số, và tôi muốn để có được một số tập hợp các dữ liệu, 1230 00:53:44,950 --> 00:53:48,327 Tôi không cần phải quay trở lại với chính bảng để có được các thuộc tính bổ sung. 1231 00:53:48,327 --> 00:53:50,660 Tôi có thể trình chiếu những bổ sung thuộc tính vào bảng 1232 00:53:50,660 --> 00:53:53,440 để hỗ trợ các mô hình truy cập. 1233 00:53:53,440 --> 00:53:57,700 Tôi biết có thể chúng đang đi vào một số thực sự, really-- nhận thành cỏ dại 1234 00:53:57,700 --> 00:53:58,910 đây trên một số các công cụ này. 1235 00:53:58,910 --> 00:54:02,725 Bây giờ tôi đã trôi dạt ra khỏi đây. 1236 00:54:02,725 --> 00:54:07,320 >> Đung [Không nghe thấy] key --table có nghĩa là một hash? 1237 00:54:07,320 --> 00:54:08,840 Các băm gốc? 1238 00:54:08,840 --> 00:54:09,340 Multi-thanh? 1239 00:54:09,340 --> 00:54:10,200 >> RICK Houlihan: Yes. 1240 00:54:10,200 --> 00:54:11,070 Vâng. 1241 00:54:11,070 --> 00:54:15,260 Chìa khóa bàn cơ bản lại trỏ vào mục. 1242 00:54:15,260 --> 00:54:19,280 Vì vậy, một chỉ là một con trỏ trở lại các mục gốc trên bàn. 1243 00:54:19,280 --> 00:54:22,910 Bây giờ bạn có thể chọn để xây dựng một chỉ số mà chỉ có phím bảng, 1244 00:54:22,910 --> 00:54:24,840 và không có tài sản khác. 1245 00:54:24,840 --> 00:54:26,570 Và tại sao tôi có thể làm điều đó? 1246 00:54:26,570 --> 00:54:28,570 Vâng, có lẽ tôi có các mục rất lớn. 1247 00:54:28,570 --> 00:54:31,660 >> Tôi thực sự chỉ cần biết which-- mô hình truy cập của tôi có thể nói, 1248 00:54:31,660 --> 00:54:33,760 mà mục chứa tài sản này? 1249 00:54:33,760 --> 00:54:35,780 Bạn không cần phải trả lại hàng. 1250 00:54:35,780 --> 00:54:37,800 Tôi chỉ cần biết mà mục chứa nó. 1251 00:54:37,800 --> 00:54:40,700 Vì vậy, bạn có thể xây dựng các chỉ số mà chỉ có chìa khóa bảng. 1252 00:54:40,700 --> 00:54:43,360 >> Nhưng đó là những gì chủ yếu một chỉ mục trong cơ sở dữ liệu là cho. 1253 00:54:43,360 --> 00:54:46,280 Đó là để có thể nhanh chóng xác định được ghi lại, 1254 00:54:46,280 --> 00:54:49,470 mà hàng, mà các mặt hàng trong bảng có 1255 00:54:49,470 --> 00:54:51,080 các tài sản mà tôi đang tìm kiếm. 1256 00:54:51,080 --> 00:54:53,610 1257 00:54:53,610 --> 00:54:54,860 >> GSIs, vậy làm thế nào để họ làm việc? 1258 00:54:54,860 --> 00:54:58,340 GSIs về cơ bản là không đồng bộ. 1259 00:54:58,340 --> 00:55:02,570 Bản cập nhật đi kèm vào bảng, bảng sau đó được cập nhật không đồng bộ 1260 00:55:02,570 --> 00:55:03,720 tất cả các GSIs của bạn. 1261 00:55:03,720 --> 00:55:06,680 Đây là lý do tại sao GSIs là cuối cùng phù hợp. 1262 00:55:06,680 --> 00:55:09,440 >> Điều quan trọng cần lưu ý đó là khi bạn đang xây dựng GSIs, 1263 00:55:09,440 --> 00:55:13,110 và bạn hiểu bạn đang tạo một chiều kích khác của aggregation-- 1264 00:55:13,110 --> 00:55:16,594 Bây giờ chúng ta hãy nói một ví dụ tốt đây là một nhà sản xuất. 1265 00:55:16,594 --> 00:55:19,260 Tôi nghĩ có thể tôi đã nói chuyện về một nhà sản xuất thiết bị y tế. 1266 00:55:19,260 --> 00:55:23,870 Các nhà sản xuất thiết bị y tế đôi khi có phần tuần tự. 1267 00:55:23,870 --> 00:55:28,070 Các bộ phận mà đi vào một sự thay thế hip tất cả 1268 00:55:28,070 --> 00:55:30,200 có một số rất ít về chúng. 1269 00:55:30,200 --> 00:55:33,584 Và họ có thể có hàng triệu và hàng hàng triệu và hàng tỷ phần 1270 00:55:33,584 --> 00:55:35,000 trong tất cả các thiết bị mà họ tàu. 1271 00:55:35,000 --> 00:55:37,440 Vâng, họ cần phải tập hợp dưới kích thước khác nhau, tất cả các bộ phận 1272 00:55:37,440 --> 00:55:39,520 trong một hội đồng, tất cả các các bộ phận đã được thực hiện 1273 00:55:39,520 --> 00:55:41,670 trên một đường nhất định, tất cả các phụ tùng đi kèm 1274 00:55:41,670 --> 00:55:44,620 từ một nhà sản xuất nào vào một ngày nhất định. 1275 00:55:44,620 --> 00:55:47,940 Và đôi khi những quy tụ có được lên đến hàng tỷ. 1276 00:55:47,940 --> 00:55:50,550 >> Vì vậy, tôi làm việc với một số những kẻ đang chịu đau khổ 1277 00:55:50,550 --> 00:55:53,156 bởi vì họ đang tạo ra các quy tụ ginormous 1278 00:55:53,156 --> 00:55:54,280 trong chỉ số trung của họ. 1279 00:55:54,280 --> 00:55:57,070 Họ có thể có một phần nguyên bảng mà đến như là chỉ băm. 1280 00:55:57,070 --> 00:55:59,090 Mỗi phần có một số serial duy nhất. 1281 00:55:59,090 --> 00:56:00,975 Tôi sử dụng số serial như băm. 1282 00:56:00,975 --> 00:56:01,600 Nó thật đẹp. 1283 00:56:01,600 --> 00:56:04,160 Bảng dữ liệu thô của tôi được lan truyền trên tất cả các không gian chính. 1284 00:56:04,160 --> 00:56:05,930 My [? viết?] [? ăn?] là tuyệt vời. 1285 00:56:05,930 --> 00:56:07,876 Tôi mất rất nhiều dữ liệu. 1286 00:56:07,876 --> 00:56:09,500 Sau đó, những gì họ làm là họ tạo ra một GSI. 1287 00:56:09,500 --> 00:56:12,666 Và tôi nói, bạn biết những gì, tôi cần phải xem tất cả các bộ phận cho nhà sản xuất này. 1288 00:56:12,666 --> 00:56:15,060 Vâng, tất cả của một đột ngột tôi tham gia một tỷ hàng, 1289 00:56:15,060 --> 00:56:17,550 và nhét chúng vào một nút, bởi vì khi 1290 00:56:17,550 --> 00:56:21,170 Tôi tổng hợp như nhà sản xuất ID như băm, 1291 00:56:21,170 --> 00:56:25,410 và phần số như phạm vi, sau đó tất cả những bất ngờ tôi 1292 00:56:25,410 --> 00:56:30,530 đặt một tỷ phần vào những gì nhà sản xuất này đã cứu tôi. 1293 00:56:30,530 --> 00:56:34,447 >> Điều đó có thể gây ra rất nhiều áp lực trên GSI, 1294 00:56:34,447 --> 00:56:36,030 một lần nữa, bởi vì tôi là búa một nút. 1295 00:56:36,030 --> 00:56:38,350 Tôi đang đặt tất cả các chèn vào một nút. 1296 00:56:38,350 --> 00:56:40,940 Và đó là một trường hợp thực tế sử dụng có vấn đề. 1297 00:56:40,940 --> 00:56:43,479 Bây giờ, tôi có một thiết kế tốt mô hình cho cách bạn tránh được điều đó. 1298 00:56:43,479 --> 00:56:45,770 Và đó là một trong những vấn đề rằng tôi luôn luôn làm việc với. 1299 00:56:45,770 --> 00:56:49,590 Nhưng điều gì sẽ xảy ra, là GSI thể không có đủ khả năng viết 1300 00:56:49,590 --> 00:56:52,330 để có thể đẩy tất cả những hàng vào một nút duy nhất. 1301 00:56:52,330 --> 00:56:55,390 Và những gì xảy ra sau đó là tiểu học, bảng khách hàng, 1302 00:56:55,390 --> 00:57:00,180 bảng chính sẽ được tăng cường vì GSI không thể theo kịp. 1303 00:57:00,180 --> 00:57:02,980 Vì vậy, tỷ lệ chèn của tôi sẽ rơi vào bảng chính 1304 00:57:02,980 --> 00:57:06,230 như GSI tôi sẽ cố gắng để theo kịp. 1305 00:57:06,230 --> 00:57:08,850 >> Tất cả các quyền, do GSI của, LSI, cái nào tôi nên sử dụng? 1306 00:57:08,850 --> 00:57:12,290 LSI là nhất quán. 1307 00:57:12,290 --> 00:57:13,750 GSI của là cuối cùng nhất quán. 1308 00:57:13,750 --> 00:57:17,490 Nếu đó là OK, tôi khuyên bạn nên sử dụng một GSI, họ linh hoạt hơn nhiều. 1309 00:57:17,490 --> 00:57:20,270 LSI có thể được mô hình hóa như một GSI. 1310 00:57:20,270 --> 00:57:27,040 Và nếu kích thước dữ liệu trên mỗi phím băm bộ sưu tập của bạn vượt quá 10 gigabyte, 1311 00:57:27,040 --> 00:57:31,050 sau đó bạn sẽ muốn sử dụng đó GSI vì nó chỉ là một giới hạn cứng. 1312 00:57:31,050 --> 00:57:32,035 >> Tất cả các quyền, do đó nhân rộng. 1313 00:57:32,035 --> 00:57:35,210 1314 00:57:35,210 --> 00:57:37,460 Throughput trong Dynamo DB, bạn cung lon [Không nghe thấy] 1315 00:57:37,460 --> 00:57:38,680 thông vào một bảng. 1316 00:57:38,680 --> 00:57:42,740 Chúng tôi có khách hàng có trích lập dự phòng 60 billion-- 1317 00:57:42,740 --> 00:57:45,970 đang làm 60 tỷ yêu cầu, thường xuyên chạy tại hơn một triệu yêu cầu 1318 00:57:45,970 --> 00:57:47,790 mỗi giây trên bàn của chúng tôi. 1319 00:57:47,790 --> 00:57:50,360 Có thực sự không giới hạn lý thuyết đến bao nhiêu 1320 00:57:50,360 --> 00:57:53,730 và làm thế nào nhanh chóng bàn có thể chạy trong Dynamo DB. 1321 00:57:53,730 --> 00:57:55,920 Có một số phần mềm giới hạn về tài khoản của bạn 1322 00:57:55,920 --> 00:57:58,170 mà chúng ta đặt ở đó vì vậy rằng bạn không đi điên. 1323 00:57:58,170 --> 00:58:00,070 Nếu bạn muốn nhiều hơn rằng, không phải là một vấn đề. 1324 00:58:00,070 --> 00:58:00,820 Bạn đến cho chúng tôi. 1325 00:58:00,820 --> 00:58:02,810 Chúng tôi sẽ lần lượt lên quay số. 1326 00:58:02,810 --> 00:58:08,210 >> Mỗi tài khoản được giới hạn trong một số mức trong mọi dịch vụ, chỉ cần ra khỏi bat 1327 00:58:08,210 --> 00:58:11,920 vì vậy những người không đi điên tự gây rắc rối. 1328 00:58:11,920 --> 00:58:12,840 Không có giới hạn về kích thước. 1329 00:58:12,840 --> 00:58:14,940 Bạn có thể đặt bất kỳ số các hạng mục trên một bảng. 1330 00:58:14,940 --> 00:58:17,620 Kích thước của một mục giới hạn đến 400 kilobytes mỗi, 1331 00:58:17,620 --> 00:58:20,050 đó sẽ là item không phải là thuộc tính. 1332 00:58:20,050 --> 00:58:24,200 Vì vậy, tổng của tất cả các thuộc tính được giới hạn đến 400 kilobyte. 1333 00:58:24,200 --> 00:58:27,300 Và sau đó một lần nữa, chúng tôi có mà ít vấn đề LSI 1334 00:58:27,300 --> 00:58:30,405 với giới hạn 10 gigabyte mỗi băm. 1335 00:58:30,405 --> 00:58:33,280 Đung số nhỏ, tôi là thiếu những gì bạn đang nói với tôi, rằng is-- 1336 00:58:33,280 --> 00:58:36,830 Đung Oh, 400 kilobyte là kích thước tối đa cho mỗi mục. 1337 00:58:36,830 --> 00:58:39,570 Vì vậy, một mặt hàng có tất cả các thuộc tính. 1338 00:58:39,570 --> 00:58:43,950 Vì vậy, 400 k là tổng kích thước của mục đó, 400 kilobyte. 1339 00:58:43,950 --> 00:58:46,170 Do đó tất cả các thuộc tính kết hợp, tất cả các dữ liệu 1340 00:58:46,170 --> 00:58:49,140 đó là trong tất cả những thuộc tính, cuộn lại thành một tổng kích cỡ, 1341 00:58:49,140 --> 00:58:51,140 hiện nay các giới hạn mục là 400 k. 1342 00:58:51,140 --> 00:58:54,390 1343 00:58:54,390 --> 00:58:57,046 Vì vậy, một lần nữa mở rộng quy mô, đạt được thông qua phân vùng. 1344 00:58:57,046 --> 00:58:58,920 Thông được trích lập dự phòng ở cấp bảng. 1345 00:58:58,920 --> 00:59:00,160 Và có thực sự hai nút bấm. 1346 00:59:00,160 --> 00:59:02,400 Chúng tôi đã đọc công suất và viết công suất. 1347 00:59:02,400 --> 00:59:05,530 >> Vì vậy, những được điều chỉnh độc lập với nhau. 1348 00:59:05,530 --> 00:59:08,640 Biện pháp RCU của Nghiêm phù đọc. 1349 00:59:08,640 --> 00:59:13,005 OK, vì vậy nếu bạn đang nói rằng tôi muốn 1000 RCU của những Nghiêm phù hợp, 1350 00:59:13,005 --> 00:59:14,130 những phù đọc. 1351 00:59:14,130 --> 00:59:17,130 Nếu bạn nói rằng tôi muốn cuối cùng nhất quán đọc, 1352 00:59:17,130 --> 00:59:19,402 bạn có thể cung cấp 1.000 RCU, bạn đang đi 1353 00:59:19,402 --> 00:59:21,840 để cuối cùng nhận được 2.000 nhất quán đọc. 1354 00:59:21,840 --> 00:59:25,940 Và một nửa giá cho những cuối cùng bao gồm trong lần đọc. 1355 00:59:25,940 --> 00:59:28,520 >> Một lần nữa, điều chỉnh độc lập với nhau. 1356 00:59:28,520 --> 00:59:32,900 Và họ có throughput-- Nếu bạn tiêu thụ 100% của RCU của bạn, 1357 00:59:32,900 --> 00:59:35,960 bạn sẽ không tác động đến sẵn có của các quyền của mình. 1358 00:59:35,960 --> 00:59:40,161 Vì vậy, họ là hoàn toàn độc lập với nhau. 1359 00:59:40,161 --> 00:59:43,160 Được rồi, vì vậy một trong những điều mà Tôi đã đề cập ngắn gọn đã bóp nghẹt. 1360 00:59:43,160 --> 00:59:44,320 Điều chỉnh tiết lưu là xấu. 1361 00:59:44,320 --> 00:59:47,311 Điều chỉnh tiết lưu chỉ xấu không có SQL. 1362 00:59:47,311 --> 00:59:50,310 Có những điều chúng ta có thể làm gì để giúp đỡ bạn làm giảm bớt các throttling bạn 1363 00:59:50,310 --> 00:59:51,040 đang gặp phải. 1364 00:59:51,040 --> 00:59:53,240 Nhưng giải pháp tốt nhất đến đây là chúng ta hãy 1365 00:59:53,240 --> 00:59:58,000 một nhìn vào những gì bạn đang làm, bởi vì có một mô hình chống các học trò ở đây. 1366 00:59:58,000 --> 01:00:02,140 >> Những điều này, những thứ như không đồng nhất khối lượng công việc, các phím nóng, phân vùng nóng. 1367 01:00:02,140 --> 01:00:06,210 Tôi đánh một không gian đặc biệt quan trọng rất khó khăn đối với một số lý do đặc biệt. 1368 01:00:06,210 --> 01:00:07,080 Tại sao tôi làm điều này? 1369 01:00:07,080 --> 01:00:08,710 Hãy hiểu rằng con số. 1370 01:00:08,710 --> 01:00:10,427 Tôi trộn dữ liệu nóng của tôi với dữ liệu lạnh. 1371 01:00:10,427 --> 01:00:12,510 Tôi để cho bàn của tôi có được rất lớn, nhưng có thực sự 1372 01:00:12,510 --> 01:00:15,970 chỉ có một số tập con của dữ liệu đó là thực sự thú vị với tôi. 1373 01:00:15,970 --> 01:00:20,290 Vì vậy, cho dữ liệu đăng nhập, ví dụ, rất nhiều khách hàng, họ nhận được đăng nhập dữ liệu hàng ngày. 1374 01:00:20,290 --> 01:00:22,490 Họ đã có một số lượng lớn các dữ liệu đăng nhập. 1375 01:00:22,490 --> 01:00:25,940 >> Nếu bạn chỉ cần đổ tất cả những gì log dữ liệu vào một bảng lớn, qua thời gian 1376 01:00:25,940 --> 01:00:28,070 bảng đó sẽ được lớn. 1377 01:00:28,070 --> 01:00:30,950 Nhưng tôi thực sự chỉ quan tâm đến 24 giờ qua, bảy ngày qua, 1378 01:00:30,950 --> 01:00:31,659 30 ngày qua. 1379 01:00:31,659 --> 01:00:34,074 Dù cửa sổ thời gian mà tôi quan tâm tìm kiếm 1380 01:00:34,074 --> 01:00:37,010 cho các sự kiện làm tôi bực mình, hoặc các sự kiện đó là thú vị với tôi, 1381 01:00:37,010 --> 01:00:39,540 đó là thời gian cửa sổ duy nhất mà tôi cần. 1382 01:00:39,540 --> 01:00:42,470 Vậy tại sao tôi đặt 10 năm giá trị của dữ liệu đăng nhập trong bảng? 1383 01:00:42,470 --> 01:00:45,030 Điều gì gây ra là bảng phân mảnh. 1384 01:00:45,030 --> 01:00:45,880 >> Nó sẽ rất lớn. 1385 01:00:45,880 --> 01:00:48,340 Nó bắt đầu lan rộng ra qua hàng ngàn các nút. 1386 01:00:48,340 --> 01:00:51,380 Và kể từ khi công suất của bạn như vậy là thấp, bạn 1387 01:00:51,380 --> 01:00:54,090 thực sự đánh giá hạn chế trên mỗi một trong những nút riêng lẻ. 1388 01:00:54,090 --> 01:00:57,120 Vì vậy, chúng ta hãy bắt đầu tìm kiếm như thế nào làm chúng tôi cuộn bảng trên. 1389 01:00:57,120 --> 01:01:01,502 Làm thế nào để chúng ta quản lý dữ liệu mà một chút tốt hơn để tránh những vấn đề này. 1390 01:01:01,502 --> 01:01:02,710 Và điều đó như thế nào? 1391 01:01:02,710 --> 01:01:04,370 Đây là những gì mà trông như thế nào. 1392 01:01:04,370 --> 01:01:06,790 Đây là những gì xấu NoSQL trông như thế nào. 1393 01:01:06,790 --> 01:01:07,830 >> Tôi có một phím nóng ở đây. 1394 01:01:07,830 --> 01:01:10,246 Nếu bạn nhìn vào bên đây, đây là tất cả các phân vùng của tôi. 1395 01:01:10,246 --> 01:01:12,630 Tôi có 16 phân vùng lên ở đây trên cơ sở dữ liệu đặc biệt này. 1396 01:01:12,630 --> 01:01:13,630 Chúng tôi làm điều này tất cả các thời gian. 1397 01:01:13,630 --> 01:01:15,046 Tôi chạy này cho khách hàng tất cả các thời gian. 1398 01:01:15,046 --> 01:01:16,550 Nó được gọi là bản đồ nhiệt. 1399 01:01:16,550 --> 01:01:20,590 Bản đồ nhiệt cho tôi làm thế nào bạn truy cập vào không gian chính của bạn. 1400 01:01:20,590 --> 01:01:23,700 Và điều này là nói cho tôi là rằng có một băm cụ thể 1401 01:01:23,700 --> 01:01:26,330 rằng anh chàng này thích một nhiều khủng khiếp, bởi vì anh ấy 1402 01:01:26,330 --> 01:01:28,250 đánh nó thực sự, thực sự khó khăn. 1403 01:01:28,250 --> 01:01:29,260 >> Vì vậy, màu xanh là tốt đẹp. 1404 01:01:29,260 --> 01:01:29,900 Chúng tôi thích màu xanh. 1405 01:01:29,900 --> 01:01:30,720 Chúng tôi không thích màu đỏ. 1406 01:01:30,720 --> 01:01:33,120 Red của nơi mà áp lực được lên đến 100%. 1407 01:01:33,120 --> 01:01:35,560 100%, bây giờ bạn sẽ được tăng cường. 1408 01:01:35,560 --> 01:01:39,030 Vì vậy, bất cứ khi nào bạn thấy bất kỳ đường màu đỏ như this-- và nó không chỉ là Dynamo DB-- 1409 01:01:39,030 --> 01:01:41,630 mỗi cơ sở dữ liệu NoSQL có vấn đề này. 1410 01:01:41,630 --> 01:01:44,640 Có anti-mẫu mà có thể lái xe các loại điều kiện. 1411 01:01:44,640 --> 01:01:49,070 Những gì tôi làm là tôi làm việc với khách hàng để làm giảm bớt những điều kiện này. 1412 01:01:49,070 --> 01:01:51,840 >> Và điều đó như thế nào? 1413 01:01:51,840 --> 01:01:54,260 Và điều này đang nhận được nhiều nhất ra của Dynamo DB thông, 1414 01:01:54,260 --> 01:01:56,176 nhưng nó thực sự nhận được nhiều nhất của NoSQL. 1415 01:01:56,176 --> 01:01:58,740 Điều này không chỉ giới hạn Dynamo. 1416 01:01:58,740 --> 01:02:02,050 Đây là definitely-- tôi được sử dụng để làm việc tại Mongo. 1417 01:02:02,050 --> 01:02:04,090 Tôi quen thuộc với nhiều nền tảng NoSQL. 1418 01:02:04,090 --> 01:02:06,830 Mỗi người có những loại các vấn đề về phím nóng. 1419 01:02:06,830 --> 01:02:10,320 Để nhận được nhiều nhất của bất kỳ NoSQL cơ sở dữ liệu, đặc biệt Dynamo DB, 1420 01:02:10,320 --> 01:02:13,320 bạn muốn tạo ra các bảng nơi mà các yếu tố quan trọng băm có 1421 01:02:13,320 --> 01:02:18,590 một số lượng lớn các giá trị khác nhau, một mức độ cao của lực lượng. 1422 01:02:18,590 --> 01:02:22,530 Bởi vì đó có nghĩa là tôi đang viết đến lô xô khác nhau. 1423 01:02:22,530 --> 01:02:24,870 >> Các xô hơn tôi viết để, nhiều khả năng 1424 01:02:24,870 --> 01:02:29,100 Tôi để lan truyền rằng write tải hoặc đọc tải ra trên nhiều nút, 1425 01:02:29,100 --> 01:02:33,560 nhiều khả năng tôi có một thông lượng cao trên bàn. 1426 01:02:33,560 --> 01:02:37,440 Và sau đó tôi muốn các giá trị được yêu cầu khá đồng đều theo thời gian 1427 01:02:37,440 --> 01:02:39,430 và thống nhất như ngẫu nhiên càng tốt. 1428 01:02:39,430 --> 01:02:42,410 Vâng, đó là loại thú vị, bởi vì tôi không thể thực sự 1429 01:02:42,410 --> 01:02:43,960 kiểm soát khi người sử dụng đến. 1430 01:02:43,960 --> 01:02:47,645 Vì vậy, đủ để nói, nếu chúng ta lan những điều trên khắp các không gian chính, 1431 01:02:47,645 --> 01:02:49,270 có lẽ chúng ta sẽ ở trong hình dạng tốt hơn. 1432 01:02:49,270 --> 01:02:51,522 >> Có một số lượng thời gian giao hàng 1433 01:02:51,522 --> 01:02:53,230 rằng bạn không đi được kiểm soát có thể. 1434 01:02:53,230 --> 01:02:55,438 Nhưng những người này thật sự là hai chiều mà chúng ta có, 1435 01:02:55,438 --> 01:02:58,800 không gian, tiếp cận đồng đều lây lan, thời gian, yêu cầu 1436 01:02:58,800 --> 01:03:01,040 Đến khoảng cách đồng đều trong thời gian. 1437 01:03:01,040 --> 01:03:03,110 Và nếu hai điều kiện được đáp ứng, 1438 01:03:03,110 --> 01:03:05,610 thì đó là những gì nó sẽ như thế nào. 1439 01:03:05,610 --> 01:03:07,890 Điều này là rất đẹp. 1440 01:03:07,890 --> 01:03:08,890 Chúng tôi thực sự hạnh phúc ở đây. 1441 01:03:08,890 --> 01:03:10,432 Chúng tôi đã có một mô hình truy cập rất đều. 1442 01:03:10,432 --> 01:03:13,098 Ừ, có lẽ bạn đang nhận được một ít áp lực tất cả bây giờ và sau đó, 1443 01:03:13,098 --> 01:03:14,830 nhưng không thực sự quá rộng lớn. 1444 01:03:14,830 --> 01:03:17,660 Vì vậy, nó tuyệt vời biết bao nhiêu lần, khi tôi làm việc với khách hàng, 1445 01:03:17,660 --> 01:03:20,670 mà đồ đầu tiên với màu đỏ lớn thanh và tất cả những gì xấu xí màu vàng nó 1446 01:03:20,670 --> 01:03:23,147 khắp nơi, chúng tôi được thực hiện với các bài tập 1447 01:03:23,147 --> 01:03:24,980 sau một vài tháng tái cấu trúc, 1448 01:03:24,980 --> 01:03:28,050 họ đang chạy cùng chính xác khối lượng công việc tại cùng một tải chính xác. 1449 01:03:28,050 --> 01:03:30,140 Và đây là những gì nó trông như bây giờ. 1450 01:03:30,140 --> 01:03:36,600 Vì vậy, những gì bạn nhận được với NoSQL là một giản đồ dữ liệu đó là hoàn toàn 1451 01:03:36,600 --> 01:03:38,510 gắn với các mô hình truy cập. 1452 01:03:38,510 --> 01:03:42,170 >> Và bạn có thể tối ưu hóa mà giản đồ dữ liệu để hỗ trợ cho rằng mô hình truy cập. 1453 01:03:42,170 --> 01:03:45,490 Nếu bạn không, sau đó bạn sẽ để xem những vấn đề đó 1454 01:03:45,490 --> 01:03:46,710 với những phím nóng. 1455 01:03:46,710 --> 01:03:50,518 >> Đung Vâng, chắc chắn một số nơi sẽ nóng hơn những người khác. 1456 01:03:50,518 --> 01:03:51,450 >> RICK Houlihan: Luôn luôn. 1457 01:03:51,450 --> 01:03:51,960 Luôn luôn. 1458 01:03:51,960 --> 01:03:54,620 Vâng, tôi có nghĩa là luôn luôn có a-- và một lần nữa, có 1459 01:03:54,620 --> 01:03:56,980 một số mẫu thiết kế, chúng tôi sẽ nhận được thông qua mà sẽ nói về cách bạn đối phó 1460 01:03:56,980 --> 01:03:58,480 với các quy tụ siêu lớn. 1461 01:03:58,480 --> 01:04:01,260 Ý tôi là, tôi đã có họ, làm thế nào để chúng ta đối phó với họ? 1462 01:04:01,260 --> 01:04:03,760 Tôi có một trường hợp sử dụng khá tốt rằng chúng ta sẽ nói về điều đó. 1463 01:04:03,760 --> 01:04:05,940 >> Tất cả các quyền, vì vậy chúng ta hãy nói về một số khách hàng hiện nay. 1464 01:04:05,940 --> 01:04:06,950 Những kẻ đang AdRoll. 1465 01:04:06,950 --> 01:04:08,990 Tôi không biết nếu bạn là quen thuộc với AdRoll. 1466 01:04:08,990 --> 01:04:10,781 Bạn có thể nhìn thấy chúng rất nhiều vào trình duyệt. 1467 01:04:10,781 --> 01:04:14,230 Họ quảng cáo nhắm mục tiêu lại, họ đang các doanh nghiệp nhắm mục tiêu tái quảng cáo lớn nhất 1468 01:04:14,230 --> 01:04:14,940 ngoài đó. 1469 01:04:14,940 --> 01:04:17,792 Họ thường xuyên chạy qua 60 tỷ giao dịch mỗi ngày. 1470 01:04:17,792 --> 01:04:20,000 Họ đang làm hơn một triệu giao dịch mỗi giây. 1471 01:04:20,000 --> 01:04:22,660 Họ đã có một bảng khá đơn giản cấu trúc, bảng bận rộn nhất. 1472 01:04:22,660 --> 01:04:26,450 Đó là cơ bản chỉ là một khóa băm là các cookie, 1473 01:04:26,450 --> 01:04:29,010 phạm vi là các nhân khẩu học thể loại, và sau đó 1474 01:04:29,010 --> 01:04:31,220 các thuộc tính thứ ba là điểm số. 1475 01:04:31,220 --> 01:04:33,720 >> Vì vậy, tất cả chúng ta có cookies trong trình duyệt của chúng tôi từ các guys. 1476 01:04:33,720 --> 01:04:35,900 Và khi bạn đi đến một tham gia buôn bán, 1477 01:04:35,900 --> 01:04:39,390 họ về cơ bản ghi bạn qua loại nhân khẩu học khác nhau. 1478 01:04:39,390 --> 01:04:42,070 Khi bạn đi vào một trang web và bạn nói tôi muốn xem ad-- này 1479 01:04:42,070 --> 01:04:44,920 hoặc về cơ bản bạn không nói that-- nhưng khi bạn đi đến các trang web 1480 01:04:44,920 --> 01:04:47,550 họ nói rằng bạn muốn thấy quảng cáo này. 1481 01:04:47,550 --> 01:04:49,370 Và họ đi nhận rằng quảng cáo từ AdRoll. 1482 01:04:49,370 --> 01:04:51,130 AdRoll trông bạn lên trên bàn của họ. 1483 01:04:51,130 --> 01:04:52,115 Họ tìm cookie của bạn. 1484 01:04:52,115 --> 01:04:53,990 Các nhà quảng cáo nói họ, tôi muốn ai đó 1485 01:04:53,990 --> 01:04:58,632 những người trung niên, Người đàn ông 40 tuổi, vào thể thao. 1486 01:04:58,632 --> 01:05:01,590 Và họ cho điểm các bạn trong những nhân khẩu học và họ quyết định có hay không 1487 01:05:01,590 --> 01:05:02,740 đó là một quảng cáo tốt cho bạn. 1488 01:05:02,740 --> 01:05:10,330 >> Bây giờ họ có một SLA với cung cấp dịch vụ quảng cáo của họ 1489 01:05:10,330 --> 01:05:14,510 cung cấp phụ 10 phần nghìn giây đáp ứng yêu cầu mỗi ngày duy nhất. 1490 01:05:14,510 --> 01:05:16,090 Vì vậy, họ đang sử dụng Dynamo DB cho việc này. 1491 01:05:16,090 --> 01:05:18,131 Họ đang đánh chúng ta một triệu yêu cầu mỗi giây. 1492 01:05:18,131 --> 01:05:21,120 Chúng tôi có thể làm tất cả của họ tra cứu, phân loại tất cả các dữ liệu đó, 1493 01:05:21,120 --> 01:05:26,130 và nhận được rằng add link lại cho rằng nhà quảng cáo ở dưới 10 mili giây. 1494 01:05:26,130 --> 01:05:29,800 Nó thực sự khá phi thường thực hiện mà họ có. 1495 01:05:29,800 --> 01:05:36,210 >> Những anh chàng actually-- là những kẻ. 1496 01:05:36,210 --> 01:05:38,010 Tôi không chắc chắn nếu đó là những chàng trai. 1497 01:05:38,010 --> 01:05:40,127 Có thể là những kẻ. 1498 01:05:40,127 --> 01:05:42,210 Về cơ bản nói us-- không, tôi không nghĩ rằng đó là họ. 1499 01:05:42,210 --> 01:05:43,000 Tôi nghĩ đó là một người khác. 1500 01:05:43,000 --> 01:05:44,750 Tôi đã làm việc với một khách hàng đó đã nói với tôi 1501 01:05:44,750 --> 01:05:47,040 rằng bây giờ họ đã đi Dynamo DB, họ 1502 01:05:47,040 --> 01:05:50,330 tiêu nhiều tiền bạc cho các món ăn nhẹ đội ngũ phát triển của họ mỗi tháng 1503 01:05:50,330 --> 01:05:52,886 hơn họ chi tiêu vào cơ sở dữ liệu của họ. 1504 01:05:52,886 --> 01:05:54,760 Vì vậy, nó sẽ cung cấp cho bạn một ý tưởng về tiết kiệm chi phí 1505 01:05:54,760 --> 01:05:57,889 mà bạn có thể nhận được trong Dynamo DB là rất lớn. 1506 01:05:57,889 --> 01:05:59,430 Tất cả các quyền, dropcam là một công ty khác. 1507 01:05:59,430 --> 01:06:02,138 Những anh chàng là loại of-- nếu bạn nghĩ của Internet của sự vật, dropcam 1508 01:06:02,138 --> 01:06:05,150 về cơ bản là video an ninh internet. 1509 01:06:05,150 --> 01:06:06,660 Bạn đặt máy ảnh của bạn lên đó. 1510 01:06:06,660 --> 01:06:08,180 Camera có một máy dò chuyển động. 1511 01:06:08,180 --> 01:06:10,290 Một người nào đó đi cùng, gây nên một điểm cue. 1512 01:06:10,290 --> 01:06:13,540 Camera bắt đầu ghi âm trong một thời gian cho đến khi nó không phát hiện bất kỳ chuyển động nữa. 1513 01:06:13,540 --> 01:06:15,310 Đặt video trên internet. 1514 01:06:15,310 --> 01:06:19,800 >> Dropcam là một công ty đó là về cơ bản chuyển sang Dynamo DB 1515 01:06:19,800 --> 01:06:22,200 bởi vì họ đã trải qua đau ngày càng lớn. 1516 01:06:22,200 --> 01:06:25,820 Và những gì họ nói với chúng tôi, đột nhiên petabyte dữ liệu. 1517 01:06:25,820 --> 01:06:28,070 Họ không có ý tưởng dịch vụ của họ sẽ rất thành công. 1518 01:06:28,070 --> 01:06:32,310 Video inbound hơn YouTube là những gì những kẻ đang nhận được. 1519 01:06:32,310 --> 01:06:36,780 Họ sử dụng DynamoDB để theo dõi tất cả các siêu dữ liệu trên tất cả các điểm chính video của họ. 1520 01:06:36,780 --> 01:06:40,282 >> Vì vậy, họ có xô S3 họ đẩy tất cả các hiện vật nhị phân thành. 1521 01:06:40,282 --> 01:06:41,990 Và sau đó họ có Hồ sơ Dynamo DB 1522 01:06:41,990 --> 01:06:44,070 điểm người dân với những S3 ba đối tượng. 1523 01:06:44,070 --> 01:06:47,070 Khi họ cần phải nhìn vào một video, họ tìm kiếm các bản ghi trong Dynamo DB. 1524 01:06:47,070 --> 01:06:47,903 Họ nhấp vào liên kết. 1525 01:06:47,903 --> 01:06:49,770 Họ kéo xuống các video từ S3. 1526 01:06:49,770 --> 01:06:51,590 Vì vậy, đó là loại gì trông như thế nào. 1527 01:06:51,590 --> 01:06:53,580 Và đây là trực tiếp từ đội ngũ của họ. 1528 01:06:53,580 --> 01:06:56,010 >> Dynamo DB giảm của họ thời gian giao hàng cho các sự kiện phim 1529 01:06:56,010 --> 01:06:57,590 từ năm đến 10 giây. 1530 01:06:57,590 --> 01:07:00,470 Trong cửa hàng quan hệ cũ của họ, họ thường phải đi và thực hiện 1531 01:07:00,470 --> 01:07:03,780 nhiều truy vấn phức tạp để hình ra video để kéo xuống, 1532 01:07:03,780 --> 01:07:06,690 đến dưới 50 mili giây. 1533 01:07:06,690 --> 01:07:08,990 Vì vậy, nó là tuyệt vời, tuyệt vời hiệu suất bao nhiêu 1534 01:07:08,990 --> 01:07:12,990 bạn có thể nhận được khi bạn tối ưu hóa và bạn điều chỉnh các cơ sở dữ liệu cơ bản 1535 01:07:12,990 --> 01:07:15,110 để hỗ trợ các mô hình truy cập. 1536 01:07:15,110 --> 01:07:20,500 Halfbrick, những anh chàng này, nó là gì, Fruit Ninja Tôi đoán là điều họ. 1537 01:07:20,500 --> 01:07:22,590 Đó là tất cả chạy trên Dynamo DB. 1538 01:07:22,590 --> 01:07:26,810 Và những chàng trai, họ là một tuyệt vời Đội ngũ phát triển, phát triển lớn 1539 01:07:26,810 --> 01:07:27,670 cửa tiệm. 1540 01:07:27,670 --> 01:07:29,364 >> Không phải là một ops đội bóng tốt. 1541 01:07:29,364 --> 01:07:31,280 Họ không có nhiều các nguồn lực hoạt động. 1542 01:07:31,280 --> 01:07:33,940 Họ đều đang nỗ lực cố gắng để giữ cơ sở hạ tầng ứng dụng của họ lên 1543 01:07:33,940 --> 01:07:34,290 và chạy. 1544 01:07:34,290 --> 01:07:35,000 Họ đến với chúng tôi. 1545 01:07:35,000 --> 01:07:36,251 Họ nhìn mà Dynamo DB. 1546 01:07:36,251 --> 01:07:37,291 Họ cho biết, đó là vì chúng ta. 1547 01:07:37,291 --> 01:07:39,470 Họ đã xây dựng toàn bộ của họ khung ứng dụng trên nó. 1548 01:07:39,470 --> 01:07:43,640 Một số ý kiến ​​thực sự tốt đẹp ở đây từ nhóm vào khả năng của họ 1549 01:07:43,640 --> 01:07:46,800 đến nay tập trung vào xây dựng các trò chơi và không 1550 01:07:46,800 --> 01:07:49,010 phải duy trì cơ sở hạ tầng, trong đó 1551 01:07:49,010 --> 01:07:51,910 đã trở thành một số lượng lớn trên không cho đội bóng của họ. 1552 01:07:51,910 --> 01:07:56,170 Vì vậy, đây là một cái gì đó that-- sự lợi ích mà bạn nhận được từ Dynamo DB. 1553 01:07:56,170 --> 01:08:00,930 >> Tất cả các bên phải, đi vào mô hình hóa dữ liệu ở đây. 1554 01:08:00,930 --> 01:08:03,440 Và chúng ta đã nói một chút về này một đến một, một đến nhiều, 1555 01:08:03,440 --> 01:08:05,060 và nhiều nhiều mối quan hệ kiểu. 1556 01:08:05,060 --> 01:08:07,630 Và làm thế nào để bạn duy trì những người trong Dynamo. 1557 01:08:07,630 --> 01:08:10,500 Trong Dynamo DB chúng tôi sử dụng chỉ số, nói chung, 1558 01:08:10,500 --> 01:08:12,910 để xoay các dữ liệu từ một hương vị khác. 1559 01:08:12,910 --> 01:08:15,210 Phím băm, phím phạm vi, và lập chỉ mục. 1560 01:08:15,210 --> 01:08:18,540 >> Đặc biệt này Ví dụ, như hầu hết các quốc gia 1561 01:08:18,540 --> 01:08:23,802 có một yêu cầu cấp phép giấy phép lái xe của một chỉ mỗi người. 1562 01:08:23,802 --> 01:08:26,510 Bạn không thể đi để có được hai lái xe giấy phép ở bang Boston. 1563 01:08:26,510 --> 01:08:27,500 Tôi không thể làm điều đó ở Texas. 1564 01:08:27,500 --> 01:08:28,708 Đó là loại cách nó được. 1565 01:08:28,708 --> 01:08:32,779 Và như vậy ở DMV, chúng ta phải tra cứu, chúng tôi muốn tìm kiếm giấy phép lái xe 1566 01:08:32,779 --> 01:08:35,180 bằng của số an sinh xã hội. 1567 01:08:35,180 --> 01:08:39,990 Tôi muốn tìm kiếm các chi tiết người dùng bởi số giấy phép lái xe. 1568 01:08:39,990 --> 01:08:43,620 >> Vì vậy, chúng ta có thể có một bảng của người dùng mà có một phím băm trên số serial, 1569 01:08:43,620 --> 01:08:47,830 hoặc số an sinh xã hội, và thuộc tính khác nhau được xác định vào mục. 1570 01:08:47,830 --> 01:08:49,859 Bây giờ trên các bảng I có thể xác định một GSI đó 1571 01:08:49,859 --> 01:08:53,370 flips mà xung quanh đó nói rằng tôi muốn một khóa băm trên giấy phép và sau đó 1572 01:08:53,370 --> 01:08:54,252 tất cả các mặt hàng khác. 1573 01:08:54,252 --> 01:08:57,210 Bây giờ nếu tôi muốn truy vấn và tìm ra Số giấy phép cho bất kỳ xã hội nhất định 1574 01:08:57,210 --> 01:08:59,609 Số an sinh, tôi có thể truy vấn bảng chính. 1575 01:08:59,609 --> 01:09:02,130 >> Nếu tôi muốn truy vấn và tôi muốn để có được an sinh xã hội 1576 01:09:02,130 --> 01:09:05,735 số hoặc các thuộc tính khác của một số giấy phép, tôi có thể truy vấn các GSI. 1577 01:09:05,735 --> 01:09:08,689 Đó là mô hình là một trong những đến một mối quan hệ. 1578 01:09:08,689 --> 01:09:12,460 Chỉ cần một GSI rất đơn giản, lật những thứ xung quanh. 1579 01:09:12,460 --> 01:09:13,979 Bây giờ, nói về một đến nhiều. 1580 01:09:13,979 --> 01:09:16,450 Một đến nhiều là về cơ bản key loạt băm của bạn. 1581 01:09:16,450 --> 01:09:20,510 Nơi mà chúng tôi nhận được rất nhiều với điều này trường hợp sử dụng màn hình dữ liệu. 1582 01:09:20,510 --> 01:09:23,880 Dữ liệu màn hình đi kèm trong thông thường khoảng thời gian, giống như Internet của sự vật. 1583 01:09:23,880 --> 01:09:26,890 Chúng tôi luôn luôn nhận được tất cả các hồ sơ đến trong tất cả các thời gian. 1584 01:09:26,890 --> 01:09:31,420 >> Và tôi muốn tìm tất cả các bài đọc giữa một khoảng thời gian cụ thể. 1585 01:09:31,420 --> 01:09:34,220 Đó là một câu hỏi rất phổ biến ở cơ sở hạ tầng theo dõi. 1586 01:09:34,220 --> 01:09:38,430 Cách di chuyển về điều đó là để tìm một cấu trúc bảng đơn giản, một bàn. 1587 01:09:38,430 --> 01:09:42,250 Tôi đã có một bảng đo thiết bị với một chìa khóa hash trên thiết bị ID. 1588 01:09:42,250 --> 01:09:47,340 Và tôi có một phím loạt trên dấu thời gian, hoặc trong trường hợp này, các sử thi. 1589 01:09:47,340 --> 01:09:50,350 Và điều đó cho phép tôi thực hiện phức tạp truy vấn đối với khóa đó phạm vi 1590 01:09:50,350 --> 01:09:54,950 và trả lại những hồ sơ mà có liên quan đến kết quả 1591 01:09:54,950 --> 01:09:56,310 thiết mà tôi đang tìm kiếm. 1592 01:09:56,310 --> 01:09:58,360 Và nó xây dựng một mà nhiều mối quan hệ 1593 01:09:58,360 --> 01:10:02,340 vào bảng chính bằng cách sử dụng khóa băm, cấu trúc chính phạm vi. 1594 01:10:02,340 --> 01:10:04,600 >> Vì vậy, đó là loại xây dựng vào bảng trong Dynamo DB. 1595 01:10:04,600 --> 01:10:07,290 Khi tôi xác định một hash và bảng phạm vi t, tôi 1596 01:10:07,290 --> 01:10:09,240 xác định một đến nhiều mối quan hệ. 1597 01:10:09,240 --> 01:10:12,770 Đó là một mối quan hệ cha-con. 1598 01:10:12,770 --> 01:10:14,620 >> Hãy nói về nhiều nhiều mối quan hệ. 1599 01:10:14,620 --> 01:10:19,170 Và cho ví dụ cụ thể này, một lần nữa, chúng ta sẽ sử dụng GSI của. 1600 01:10:19,170 --> 01:10:23,500 Và chúng ta hãy nói về chơi game kịch bản mà tôi có một người dùng nhất định. 1601 01:10:23,500 --> 01:10:26,500 Tôi muốn tìm hiểu tất cả các trò chơi mà anh đăng ký hoặc chơi ở. 1602 01:10:26,500 --> 01:10:29,600 Và đối với một trò chơi nào đó, tôi muốn tìm tất cả các người sử dụng. 1603 01:10:29,600 --> 01:10:31,010 Vì vậy, làm thế nào để làm điều đó? 1604 01:10:31,010 --> 01:10:34,330 Bảng trò chơi dùng của tôi, tôi sẽ để có một phím băm của người sử dụng ID 1605 01:10:34,330 --> 01:10:35,810 và một phím phạm vi của trò chơi. 1606 01:10:35,810 --> 01:10:37,810 >> Vì vậy, người dùng có thể có nhiều trò chơi. 1607 01:10:37,810 --> 01:10:41,380 Đó là một một đến nhiều mối quan hệ giữa người sử dụng và các trò chơi anh chơi. 1608 01:10:41,380 --> 01:10:43,410 Và sau đó vào GSI, Tôi sẽ lật xung quanh đó. 1609 01:10:43,410 --> 01:10:46,679 Tôi sẽ băm vào các trò chơi và Tôi sẽ dao vào người sử dụng. 1610 01:10:46,679 --> 01:10:48,970 Vì vậy, nếu tôi muốn có được tất cả các trò chơi của người sử dụng chơi trong, 1611 01:10:48,970 --> 01:10:49,950 Tôi sẽ truy vấn bảng chính. 1612 01:10:49,950 --> 01:10:52,699 Nếu tôi muốn có được tất cả những người sử dụng đang chơi một trò chơi cụ thể, 1613 01:10:52,699 --> 01:10:53,887 Tôi truy vấn GSI. 1614 01:10:53,887 --> 01:10:54,970 Vì vậy, bạn xem cách chúng tôi làm điều này? 1615 01:10:54,970 --> 01:10:58,369 Bạn xây dựng các của GSI để hỗ trợ trường hợp sử dụng, ứng dụng, truy cập 1616 01:10:58,369 --> 01:10:59,410 mô hình, các ứng dụng. 1617 01:10:59,410 --> 01:11:01,440 >> Nếu tôi cần phải truy vấn trên không gian này, chúng ta hãy 1618 01:11:01,440 --> 01:11:03,500 tôi tạo ra một chỉ số trên không gian đó. 1619 01:11:03,500 --> 01:11:05,850 Nếu tôi không, tôi không quan tâm. 1620 01:11:05,850 --> 01:11:09,060 Và tùy thuộc vào các trường hợp sử dụng, tôi có thể cần các chỉ số hoặc tôi có thể không. 1621 01:11:09,060 --> 01:11:12,390 Nếu đó là một trong những đơn giản với nhiều người, bảng chính là tốt. 1622 01:11:12,390 --> 01:11:15,860 Nếu tôi cần phải làm những nhiều người nhiều của, hay tôi cần phải làm một với những người thân, 1623 01:11:15,860 --> 01:11:18,390 sau đó có lẽ tôi cần thứ hai chỉ số. 1624 01:11:18,390 --> 01:11:20,840 Vì vậy, tất cả phụ thuộc vào những gì tôi đang cố gắng để làm 1625 01:11:20,840 --> 01:11:24,550 và những gì tôi đang cố gắng để có được thành tựu. 1626 01:11:24,550 --> 01:11:28,000 >> Có lẽ tôi sẽ không chi tiêu quá nhiều thời gian nói về tài liệu. 1627 01:11:28,000 --> 01:11:31,460 Điều này được một chút, có lẽ, sâu hơn, chúng tôi cần phải đi vào. 1628 01:11:31,460 --> 01:11:33,710 Hãy nói một chút biểu thức truy vấn về phong phú. 1629 01:11:33,710 --> 01:11:37,831 Vì vậy, trong Dynamo DB chúng tôi có khả năng tạo 1630 01:11:37,831 --> 01:11:39,330 những gì chúng ta gọi là biểu thức chiếu. 1631 01:11:39,330 --> 01:11:42,660 Biểu thức chiếu chỉ đơn giản là chọn các trường hoặc các giá trị 1632 01:11:42,660 --> 01:11:44,290 mà bạn muốn hiển thị. 1633 01:11:44,290 --> 01:11:46,000 OK, vì vậy tôi thực hiện một lựa chọn. 1634 01:11:46,000 --> 01:11:48,010 Tôi thực hiện một truy vấn đối với Dynamo DB. 1635 01:11:48,010 --> 01:11:51,730 Và tôi nói, bạn biết những gì, show tôi chỉ có các đánh giá năm sao 1636 01:11:51,730 --> 01:11:54,544 cho sản phẩm đặc biệt này. 1637 01:11:54,544 --> 01:11:55,710 Vì vậy, đó là tất cả tôi muốn xem. 1638 01:11:55,710 --> 01:11:57,320 Tôi không muốn nhìn thấy tất cả các các thuộc tính khác của hàng, 1639 01:11:57,320 --> 01:11:58,319 Tôi chỉ muốn thấy điều này. 1640 01:11:58,319 --> 01:12:01,209 Nó giống như trong SQL khi bạn nói sao chọn hoặc từ bảng, 1641 01:12:01,209 --> 01:12:02,000 bạn sẽ có được tất cả mọi thứ. 1642 01:12:02,000 --> 01:12:05,450 Khi tôi nói chọn tên từ bảng, tôi chỉ nhận được một thuộc tính. 1643 01:12:05,450 --> 01:12:09,070 Đó là cùng một loại điều trong Dynamo DB hoặc một cơ sở dữ liệu NoSQL. 1644 01:12:09,070 --> 01:12:14,510 Biểu thức lọc cho phép tôi về cơ bản cắt giảm các kết quả đặt xuống. 1645 01:12:14,510 --> 01:12:15,540 Vì vậy, tôi thực hiện một truy vấn. 1646 01:12:15,540 --> 01:12:17,260 Truy vấn có thể trở lại với 500 mặt hàng. 1647 01:12:17,260 --> 01:12:20,255 Nhưng tôi chỉ muốn các vật phẩm có một thuộc tính mà nói này. 1648 01:12:20,255 --> 01:12:23,380 OK, vì vậy chúng ta hãy lọc ra những mặt hàng không phù hợp với truy vấn cụ thể. 1649 01:12:23,380 --> 01:12:25,540 Vì vậy, chúng ta có các biểu thức lọc. 1650 01:12:25,540 --> 01:12:28,310 >> Biểu thức lọc có thể thể chạy trên bất kỳ thuộc tính. 1651 01:12:28,310 --> 01:12:30,260 Họ không muốn truy vấn nhiều. 1652 01:12:30,260 --> 01:12:32,690 Nâng truy vấn được chọn lọc hơn. 1653 01:12:32,690 --> 01:12:36,470 Truy vấn lọc đòi hỏi tôi phải đi được toàn bộ kết quả thiết lập và sau đó 1654 01:12:36,470 --> 01:12:39,170 carve ra các dữ liệu tôi không muốn. 1655 01:12:39,170 --> 01:12:40,660 Tại sao điều đó lại quan trọng? 1656 01:12:40,660 --> 01:12:42,770 Bởi vì tôi đọc tất cả. 1657 01:12:42,770 --> 01:12:46,597 Trong một truy vấn, tôi sẽ đọc và nó sẽ là một người khổng lồ về dữ liệu. 1658 01:12:46,597 --> 01:12:48,430 Và sau đó tôi sẽ carve ra những gì tôi cần. 1659 01:12:48,430 --> 01:12:52,080 Và nếu tôi chỉ khắc ra một vài hàng, thì đó là OK. 1660 01:12:52,080 --> 01:12:53,620 Nó không phải như vậy không hiệu quả. 1661 01:12:53,620 --> 01:12:57,800 >> Nhưng nếu tôi đọc một đống toàn bộ dữ liệu, chỉ cần để cắt ra một mặt hàng, 1662 01:12:57,800 --> 01:13:01,490 sau đó tôi sẽ được tốt hơn bằng cách sử dụng một truy vấn nhiều, 1663 01:13:01,490 --> 01:13:03,030 vì nó nhiều hơn chọn lọc. 1664 01:13:03,030 --> 01:13:06,330 Nó sẽ tiết kiệm cho tôi rất nhiều tiền, bởi vì tôi trả tiền để đọc mà. 1665 01:13:06,330 --> 01:13:10,430 Trường hợp kết quả mà trở lại qua dây mà có thể là nhỏ hơn, 1666 01:13:10,430 --> 01:13:11,890 nhưng tôi trả tiền cho việc đọc. 1667 01:13:11,890 --> 01:13:14,340 Vì vậy, hiểu như thế nào bạn đang nhận được dữ liệu. 1668 01:13:14,340 --> 01:13:16,420 Điều đó rất quan trọng trong Dynamo DB. 1669 01:13:16,420 --> 01:13:19,710 >> Biểu thức điều kiện, đây là những gì bạn có thể gọi là lạc quan khóa. 1670 01:13:19,710 --> 01:13:28,470 Cập nhật IF EXISTS, hoặc nếu giá trị này tương đương với những gì tôi chỉ định. 1671 01:13:28,470 --> 01:13:31,494 Và nếu tôi có một tem thời gian trên hồ sơ, tôi có thể đọc dữ liệu. 1672 01:13:31,494 --> 01:13:32,535 Tôi có thể thay đổi dữ liệu. 1673 01:13:32,535 --> 01:13:35,030 Tôi có thể đi viết rằng dữ liệu về cơ sở dữ liệu. 1674 01:13:35,030 --> 01:13:38,100 Nếu ai đó đã thay đổi các hồ sơ, dấu thời gian có thể đã thay đổi. 1675 01:13:38,100 --> 01:13:40,370 Và cách mà điều kiện của tôi cập nhật có thể nói cập nhật 1676 01:13:40,370 --> 01:13:42,340 nếu các dấu thời gian bằng này. 1677 01:13:42,340 --> 01:13:46,290 Hoặc cập nhật thất bại bởi vì ai đó cập nhật các bản ghi trong khi chờ đợi. 1678 01:13:46,290 --> 01:13:48,290 >> Đó là những gì chúng ta gọi là lạc quan khóa. 1679 01:13:48,290 --> 01:13:50,670 Nó có nghĩa là ai đó có thể đi vào và thay đổi nó, 1680 01:13:50,670 --> 01:13:53,100 và tôi sẽ phát hiện ra nó khi tôi quay trở lại để viết. 1681 01:13:53,100 --> 01:13:56,106 Và sau đó tôi thực sự có thể đọc mà dữ liệu và nói, oh, ông đã thay đổi này. 1682 01:13:56,106 --> 01:13:57,230 Tôi cần tài khoản cho điều đó. 1683 01:13:57,230 --> 01:14:00,490 Và tôi có thể thay đổi dữ liệu trong tôi ghi lại và áp dụng bản cập nhật khác. 1684 01:14:00,490 --> 01:14:04,330 Vì vậy, bạn có thể nắm bắt những gia tăng cập nhật xảy ra giữa thời gian 1685 01:14:04,330 --> 01:14:08,740 bạn đọc các dữ liệu và các thời gian bạn có thể ghi dữ liệu. 1686 01:14:08,740 --> 01:14:11,520 >> Đung Và bộ lọc biểu hiện thực sự có nghĩa là không 1687 01:14:11,520 --> 01:14:13,020 số hoặc not-- 1688 01:14:13,020 --> 01:14:14,316 >> [Interposing GIỌNG NÓI] 1689 01:14:14,316 --> 01:14:16,232 RICK Houlihan: Tôi sẽ không nhận được quá nhiều vào điều này. 1690 01:14:16,232 --> 01:14:17,700 Đây có phải là một từ khóa dành riêng. 1691 01:14:17,700 --> 01:14:20,130 Quan điểm bảng Anh một Ltd. từ khóa trong Dynamo DB. 1692 01:14:20,130 --> 01:14:24,500 Mỗi cơ sở dữ liệu có riêng của mình dành riêng tên cho bộ sưu tập bạn không thể sử dụng. 1693 01:14:24,500 --> 01:14:27,240 Dynamo DB, nếu bạn chỉ định pound trước mặt này, 1694 01:14:27,240 --> 01:14:29,310 bạn có thể xác định những cái tên lên trên. 1695 01:14:29,310 --> 01:14:31,840 Đây là một giá trị tham chiếu. 1696 01:14:31,840 --> 01:14:34,880 Đó có lẽ không phải là cú pháp tốt nhất để có trên đó trong cuộc thảo luận này, 1697 01:14:34,880 --> 01:14:38,090 bởi vì nó được vào một số real-- Tôi đã nói chuyện nhiều hơn 1698 01:14:38,090 --> 01:14:41,360 về điều đó ở một mức độ sâu hơn. 1699 01:14:41,360 --> 01:14:46,130 >> Nhưng đủ để nói, điều này có thể được truy vấn quét nơi họ views-- 1700 01:14:46,130 --> 01:14:50,190 cũng không xem bảng Anh là lớn hơn 10. 1701 01:14:50,190 --> 01:14:54,660 Nó là một giá trị số, có. 1702 01:14:54,660 --> 01:14:57,322 Nếu bạn muốn, chúng tôi có thể nói chuyện về rằng sau khi các cuộc thảo luận. 1703 01:14:57,322 --> 01:15:00,030 Được rồi, vì vậy chúng tôi đang đi vào một số tình huống trong thực tiễn tốt nhất 1704 01:15:00,030 --> 01:15:02,000 nơi chúng ta sẽ nói chuyện về một số ứng dụng ở đây. 1705 01:15:02,000 --> 01:15:03,810 Các trường hợp sử dụng cho Dynamo DB là gì. 1706 01:15:03,810 --> 01:15:06,120 Thiết kế là gì mẫu trong Dynamo DB. 1707 01:15:06,120 --> 01:15:09,110 >> Và người đầu tiên chúng ta sẽ nói về là internet của vạn vật. 1708 01:15:09,110 --> 01:15:15,010 Vì vậy, chúng tôi nhận được rất nhiều of-- tôi đoán, là những gì it-- hơn 50% 1709 01:15:15,010 --> 01:15:19,370 lưu lượng truy cập trên mạng Internet những ngày này là thực sự được tạo ra bởi máy móc, 1710 01:15:19,370 --> 01:15:21,930 quy trình tự động, không phải do con người. 1711 01:15:21,930 --> 01:15:25,140 Tôi có nghĩa là điều này điều này bạn mang theo trong túi của bạn, 1712 01:15:25,140 --> 01:15:28,840 bao nhiêu dữ liệu mà điều đó là thực sự gửi xung quanh mà không bạn 1713 01:15:28,840 --> 01:15:30,550 biết nó là hoàn toàn tuyệt vời. 1714 01:15:30,550 --> 01:15:34,970 Vị trí của bạn, thông tin về nhanh như thế nào bạn đang đi. 1715 01:15:34,970 --> 01:15:38,400 Làm thế nào để bạn nghĩ rằng công trình Google Maps khi họ nói với bạn những gì là giao thông. 1716 01:15:38,400 --> 01:15:41,275 Đó là bởi vì có hàng triệu và hàng triệu người lái xe xung quanh 1717 01:15:41,275 --> 01:15:44,667 với các điện thoại được gửi dữ liệu trên tất cả các nơi tất cả các thời gian. 1718 01:15:44,667 --> 01:15:46,500 Vì vậy, một trong những điều về kiểu dữ liệu 1719 01:15:46,500 --> 01:15:50,980 mà đi theo, màn hình dữ liệu, đăng nhập dữ liệu, dữ liệu chuỗi thời gian, là nó 1720 01:15:50,980 --> 01:15:53,540 thường chỉ thú vị cho một chút ít thời gian. 1721 01:15:53,540 --> 01:15:55,580 Sau thời gian đó, nó không thú vị như vậy. 1722 01:15:55,580 --> 01:15:58,390 Vì vậy, chúng tôi nói chuyện về, đừng để những bảng lớn lên mà không có giới hạn. 1723 01:15:58,390 --> 01:16:03,410 Ý tưởng ở đây là rằng có lẽ tôi đã có 24 giờ giá trị của sự kiện trong bảng nóng của tôi. 1724 01:16:03,410 --> 01:16:06,160 Và đó bảng nóng là có được được cung cấp với một tốc độ rất cao, 1725 01:16:06,160 --> 01:16:07,950 vì nó lấy rất nhiều dữ liệu. 1726 01:16:07,950 --> 01:16:10,920 Nó lấy rất nhiều dữ liệu và tôi đọc nó rất nhiều. 1727 01:16:10,920 --> 01:16:14,560 Tôi đã có rất nhiều hoạt động truy vấn chạy chống lại dữ liệu đó. 1728 01:16:14,560 --> 01:16:18,120 >> Sau 24 giờ, hey, bạn biết những gì, tôi không quan tâm. 1729 01:16:18,120 --> 01:16:21,150 Vì vậy, có lẽ mỗi nửa đêm tôi cuộn bàn của tôi qua một bảng mới 1730 01:16:21,150 --> 01:16:22,430 và tôi deprovision bảng này. 1731 01:16:22,430 --> 01:16:26,440 Và tôi sẽ lấy của RCU và Xuống WCU vì 24 giờ sau đó 1732 01:16:26,440 --> 01:16:28,630 Tôi không chạy nhiều truy vấn đối với dữ liệu đó. 1733 01:16:28,630 --> 01:16:30,200 Vì vậy, tôi sẽ tiết kiệm tiền. 1734 01:16:30,200 --> 01:16:32,940 Và có lẽ 30 ngày sau đó tôi không thậm chí cần phải quan tâm đến tất cả. 1735 01:16:32,940 --> 01:16:35,020 Tôi có thể lấy của WCU tất cả các con đường xuống một, 1736 01:16:35,020 --> 01:16:36,990 bởi vì bạn biết những gì, đó là không bao giờ được ghi vào. 1737 01:16:36,990 --> 01:16:38,300 Các dữ liệu là 30 ngày tuổi. 1738 01:16:38,300 --> 01:16:40,000 Nó không bao giờ thay đổi. 1739 01:16:40,000 --> 01:16:44,200 >> Và nó gần như không bao giờ để có được đọc, vì vậy chúng ta chỉ mất rằng RCU xuống 10. 1740 01:16:44,200 --> 01:16:49,372 Và tôi đang tiết kiệm một tấn tiền trên này dữ liệu, và chỉ trả tiền cho dữ liệu nóng của tôi. 1741 01:16:49,372 --> 01:16:52,330 Vì vậy, đó là điều quan trọng để tìm tại khi bạn nhìn vào một chuỗi thời gian 1742 01:16:52,330 --> 01:16:54,716 dữ liệu đi vào trong âm lượng. 1743 01:16:54,716 --> 01:16:55,590 Đây là chiến lược. 1744 01:16:55,590 --> 01:16:58,010 Bây giờ, tôi chỉ có thể để cho nó tất cả đi đến cùng một bảng 1745 01:16:58,010 --> 01:16:59,461 và chỉ cần cho bảng mọc. 1746 01:16:59,461 --> 01:17:01,460 Cuối cùng, tôi sẽ thấy vấn đề hiệu suất. 1747 01:17:01,460 --> 01:17:04,060 Tôi sẽ phải bắt đầu lưu trữ một số trong đó dữ liệu ra khỏi bàn, 1748 01:17:04,060 --> 01:17:04,720 những gì không. 1749 01:17:04,720 --> 01:17:07,010 >> Hãy tốt hơn nhiều thiết kế ứng dụng của bạn 1750 01:17:07,010 --> 01:17:08,900 để bạn có thể hoạt động theo cách này ngay. 1751 01:17:08,900 --> 01:17:11,460 Vì vậy, nó chỉ tự động trong mã ứng dụng. 1752 01:17:11,460 --> 01:17:13,580 Vào lúc nửa đêm mỗi đêm nó cuộn bàn. 1753 01:17:13,580 --> 01:17:17,170 Có lẽ những gì tôi cần là một trượt cửa sổ của 24 giờ của dữ liệu. 1754 01:17:17,170 --> 01:17:20,277 Sau đó, trên cơ sở thường xuyên tôi gọi dữ liệu khỏi bàn. 1755 01:17:20,277 --> 01:17:22,360 Tôi đang cắt tỉa nó với một Cron công việc và tôi đặt nó 1756 01:17:22,360 --> 01:17:24,160 vào các bảng khác, bất cứ điều gì bạn cần. 1757 01:17:24,160 --> 01:17:25,940 Vì vậy, nếu một rollover hoạt động, đó là tuyệt vời. 1758 01:17:25,940 --> 01:17:27,080 Nếu không, cắt nó. 1759 01:17:27,080 --> 01:17:29,640 Nhưng chúng ta hãy giữ cho rằng dữ liệu nóng đi từ dữ liệu lạnh của bạn. 1760 01:17:29,640 --> 01:17:32,535 Nó sẽ giúp bạn tiết kiệm rất nhiều tiền và làm cho các bảng của bạn có hiệu suất hơn. 1761 01:17:32,535 --> 01:17:35,960 1762 01:17:35,960 --> 01:17:38,210 Vì vậy, điều tiếp theo chúng ta sẽ nói về là danh mục sản phẩm. 1763 01:17:38,210 --> 01:17:42,000 Danh mục sản phẩm là trường hợp sử dụng khá phổ biến. 1764 01:17:42,000 --> 01:17:46,600 Đây thực sự là một mô hình rất phổ biến rằng chúng ta sẽ thấy trong một loạt các sự vật. 1765 01:17:46,600 --> 01:17:48,870 Bạn biết đấy, Twitter cho Ví dụ, một tweet nóng. 1766 01:17:48,870 --> 01:17:51,280 Và tất cả mọi người đang đến grabbing tweet đó. 1767 01:17:51,280 --> 01:17:52,680 Danh mục sản phẩm, tôi đã bán được hàng. 1768 01:17:52,680 --> 01:17:54,120 Tôi có một bán nóng. 1769 01:17:54,120 --> 01:17:57,277 Tôi đã nhận 70.000 yêu cầu mỗi lần thứ hai cho một sản phẩm 1770 01:17:57,277 --> 01:17:58,860 Mô tả ra khỏi danh mục sản phẩm của tôi. 1771 01:17:58,860 --> 01:18:02,384 Chúng tôi thấy điều này trên thị trường bán lẻ hoạt động khá một chút. 1772 01:18:02,384 --> 01:18:03,550 Vì vậy, làm thế nào để chúng ta đối phó với điều đó? 1773 01:18:03,550 --> 01:18:04,924 Không có cách nào để đối phó với điều đó. 1774 01:18:04,924 --> 01:18:07,110 Tất cả người dùng của tôi muốn xem cùng một mảnh của dữ liệu. 1775 01:18:07,110 --> 01:18:09,410 Họ đang đến, đồng thời. 1776 01:18:09,410 --> 01:18:11,920 Và tất cả họ đang làm cho các yêu cầu cho cùng một mảnh của dữ liệu. 1777 01:18:11,920 --> 01:18:16,240 Điều này mang lại cho tôi rằng phím nóng, mà lớn màu đỏ sọc trên bảng xếp hạng của tôi rằng chúng ta không thích. 1778 01:18:16,240 --> 01:18:17,720 Và đó là những gì mà trông như thế nào. 1779 01:18:17,720 --> 01:18:22,290 Vì vậy, trên không gian chính của tôi tôi nhận được rèn trong mục bán hàng. 1780 01:18:22,290 --> 01:18:24,070 Tôi nhận được không có gì bất cứ nơi nào khác. 1781 01:18:24,070 --> 01:18:26,050 >> Làm thế nào để giảm bớt vấn đề này? 1782 01:18:26,050 --> 01:18:28,410 Vâng, chúng tôi giảm bớt điều này với bộ nhớ cache. 1783 01:18:28,410 --> 01:18:33,630 Cache, bạn đặt cơ bản là một trong bộ nhớ phân vùng ở phía trước của cơ sở dữ liệu. 1784 01:18:33,630 --> 01:18:37,260 Chúng tôi đã được quản lý [Không nghe thấy] cache, làm thế nào bạn 1785 01:18:37,260 --> 01:18:40,260 có thể thiết lập bộ nhớ cache của riêng bạn, [nghe được] cache [? d,?] bất cứ điều gì bạn muốn. 1786 01:18:40,260 --> 01:18:42,220 Đặt rằng lên ở phía trước của cơ sở dữ liệu. 1787 01:18:42,220 --> 01:18:47,250 Và cách mà bạn có thể lưu trữ dữ liệu từ những phím nóng lên trong bộ nhớ cache 1788 01:18:47,250 --> 01:18:49,390 không gian và đọc thông qua bộ nhớ cache. 1789 01:18:49,390 --> 01:18:51,962 >> Và sau đó hầu hết các lần đọc của bạn bắt đầu tìm kiếm như thế này. 1790 01:18:51,962 --> 01:18:54,920 Tôi đã nhận tất cả các bộ nhớ cache lượt truy cập ở đây và tôi đã không có gì xảy ra ở đây xuống 1791 01:18:54,920 --> 01:18:59,330 vì cơ sở dữ liệu được ngồi phía sau bộ nhớ cache và các lần đọc không bao giờ đi qua. 1792 01:18:59,330 --> 01:19:02,520 Nếu tôi thay đổi dữ liệu trong các cơ sở dữ liệu, tôi phải cập nhật bộ nhớ cache. 1793 01:19:02,520 --> 01:19:04,360 Chúng tôi có thể sử dụng một cái gì đó như hơi nước để làm điều đó. 1794 01:19:04,360 --> 01:19:07,360 Và tôi sẽ giải thích làm thế nào mà làm việc. 1795 01:19:07,360 --> 01:19:09,060 Tất cả các quyền, nhắn tin. 1796 01:19:09,060 --> 01:19:11,180 Email, tất cả chúng ta sử dụng email. 1797 01:19:11,180 --> 01:19:12,540 >> Đây là một ví dụ khá tốt. 1798 01:19:12,540 --> 01:19:14,950 Chúng tôi đã có một số loại thông điệp bảng. 1799 01:19:14,950 --> 01:19:17,040 Và chúng tôi có hộp thư đến và hộp thư đi. 1800 01:19:17,040 --> 01:19:19,760 Đây là những gì SQL sẽ nhìn muốn xây dựng hộp thư đó. 1801 01:19:19,760 --> 01:19:23,350 Chúng tôi loại sử dụng cùng loại các chiến lược sử dụng của GSI, GSI của 1802 01:19:23,350 --> 01:19:25,320 cho hộp thư của tôi và hộp thư đi của tôi. 1803 01:19:25,320 --> 01:19:27,600 Vì vậy, tôi đã nhận thông điệp thô mới vào bảng tin nhắn của tôi. 1804 01:19:27,600 --> 01:19:30,194 Và các phương pháp tiếp cận đầu tiên này có thể là, nói, OK, không có vấn đề. 1805 01:19:30,194 --> 01:19:31,110 Tôi đã có thông điệp thô. 1806 01:19:31,110 --> 01:19:33,710 Tin nhắn đến [Không nghe thấy], tin ID, đó là tuyệt vời. 1807 01:19:33,710 --> 01:19:35,070 Đó là băm duy nhất của tôi. 1808 01:19:35,070 --> 01:19:38,280 Tôi sẽ tạo ra hai GSI, một trong cho hộp thư của tôi, một cho hộp thư đi của tôi. 1809 01:19:38,280 --> 01:19:40,530 Và điều đầu tiên tôi sẽ làm là tôi sẽ nói chính băm của tôi là 1810 01:19:40,530 --> 01:19:43,310 sẽ là người nhận và Tôi sẽ sắp xếp vào ngày tháng. 1811 01:19:43,310 --> 01:19:44,220 Điều này là tuyệt vời. 1812 01:19:44,220 --> 01:19:45,890 Tôi có cái nhìn tốt đẹp của tôi ở đây. 1813 01:19:45,890 --> 01:19:47,780 Nhưng có một vấn đề nhỏ ở đây. 1814 01:19:47,780 --> 01:19:50,891 Và bạn chạy vào trong này cơ sở dữ liệu quan hệ là tốt. 1815 01:19:50,891 --> 01:19:52,390 Họ được gọi là phân vùng theo chiều dọc. 1816 01:19:52,390 --> 01:19:55,840 Bạn muốn giữ lại dữ liệu lớn của bạn đi từ dữ liệu của bạn ít. 1817 01:19:55,840 --> 01:20:00,470 >> Và lý do tại sao là bởi vì tôi gotta đi đọc các mục để có được các thuộc tính. 1818 01:20:00,470 --> 01:20:05,570 Và nếu các cơ quan của tôi là tất cả trên đây, sau đó đọc chỉ là một vài mặt hàng 1819 01:20:05,570 --> 01:20:08,560 nếu chiều dài cơ thể của tôi là trung bình mỗi 256 kilobyte, 1820 01:20:08,560 --> 01:20:10,991 toán học được khá xấu xí. 1821 01:20:10,991 --> 01:20:12,490 Vì vậy, nói tôi muốn đọc hộp thư của David. 1822 01:20:12,490 --> 01:20:14,520 Hộp thư đến của David có 50 mặt hàng. 1823 01:20:14,520 --> 01:20:17,880 Trung bình và kích thước là 256 KB. 1824 01:20:17,880 --> 01:20:21,730 Đây là tỷ lệ chuyển đổi của tôi cho RCU là bốn kilobyte. 1825 01:20:21,730 --> 01:20:24,450 >> OK, chúng ta hãy đi với cuối cùng nhất quán đọc. 1826 01:20:24,450 --> 01:20:28,640 Tôi vẫn còn đang ăn 1600 RCU của chỉ để đọc hộp thư của David. 1827 01:20:28,640 --> 01:20:29,950 Ouch. 1828 01:20:29,950 --> 01:20:31,980 OK, bây giờ hãy nghĩ về cách ứng dụng hoạt động. 1829 01:20:31,980 --> 01:20:35,340 Nếu tôi đang ở trong một ứng dụng email và Tôi đang nhìn vào hộp thư của tôi, 1830 01:20:35,340 --> 01:20:39,680 và tôi nhìn vào cơ thể của mỗi tin nhắn, không, tôi nhìn vào tóm tắt. 1831 01:20:39,680 --> 01:20:41,850 Tôi đang nhìn vào chỉ tiêu đề. 1832 01:20:41,850 --> 01:20:46,310 Vì vậy, hãy xây dựng một cấu trúc bảng trông giống như thế. 1833 01:20:46,310 --> 01:20:49,470 >> Vì vậy, đây là những thông tin rằng công việc của tôi cần. 1834 01:20:49,470 --> 01:20:50,890 Đó là trong hộp thư đến của tôi GSI. 1835 01:20:50,890 --> 01:20:53,800 Đó là ngày tháng, người gửi, các đối tượng, và sau đó 1836 01:20:53,800 --> 01:20:56,790 ID tin nhắn, mà điểm trở lại với những thông điệp bảng 1837 01:20:56,790 --> 01:20:57,850 nơi mà tôi có thể có được cơ thể. 1838 01:20:57,850 --> 01:21:01,260 1839 01:21:01,260 --> 01:21:04,420 Vâng, sẽ có những IDs kỷ lục. 1840 01:21:04,420 --> 01:21:09,850 Họ sẽ chỉ trở lại ID mục trên bảng Dynamo DB. 1841 01:21:09,850 --> 01:21:12,220 Mỗi chỉ số luôn creates-- luôn luôn có hàng 1842 01:21:12,220 --> 01:21:15,750 ID như là một phần of-- đó đi kèm với các chỉ số. 1843 01:21:15,750 --> 01:21:17,414 >> Được rồi. 1844 01:21:17,414 --> 01:21:19,080 Đung Nó nói với nó, nơi nó được lưu trữ? 1845 01:21:19,080 --> 01:21:21,420 RICK Houlihan: Vâng, nó cho exactly-- đó là chính xác những gì nó. 1846 01:21:21,420 --> 01:21:22,644 Nó nói ở đây là hồ sơ của tôi lại. 1847 01:21:22,644 --> 01:21:24,310 Và nó sẽ chỉ cho nó trở lại để ghi lại của tôi. 1848 01:21:24,310 --> 01:21:26,460 Chính xác. 1849 01:21:26,460 --> 01:21:29,490 OK, vì vậy bây giờ hộp thư của tôi là thực sự nhỏ hơn nhiều. 1850 01:21:29,490 --> 01:21:32,210 Và điều này thực sự hỗ trợ các quy trình làm việc của một ứng dụng email. 1851 01:21:32,210 --> 01:21:34,230 Vì vậy, hộp thư của tôi, tôi bấm. 1852 01:21:34,230 --> 01:21:38,160 Tôi đi cùng và tôi bấm vào tin nhắn, đó là khi tôi cần phải đi lấy cơ thể, 1853 01:21:38,160 --> 01:21:40,180 bởi vì tôi sẽ đến đi đến một quan điểm khác nhau. 1854 01:21:40,180 --> 01:21:43,870 Vì vậy, nếu bạn nghĩ về MVC loại khuôn khổ, mô hình điều khiển xem. 1855 01:21:43,870 --> 01:21:46,120 >> Mô hình này có chứa các dữ liệu mà nhu cầu xem 1856 01:21:46,120 --> 01:21:48,130 và bộ điều khiển tương tác với. 1857 01:21:48,130 --> 01:21:51,670 Khi tôi thay đổi khung hình, khi Tôi thay đổi quan điểm, 1858 01:21:51,670 --> 01:21:55,080 đó là OK để quay trở lại máy chủ và phục hồi lại các mô hình, 1859 01:21:55,080 --> 01:21:56,860 bởi vì đó là những gì người dùng mong đợi. 1860 01:21:56,860 --> 01:22:00,530 Khi họ thay đổi quan điểm, đó là khi chúng ta có thể quay trở lại cơ sở dữ liệu. 1861 01:22:00,530 --> 01:22:02,480 Vì vậy, email, nhấn chuột. 1862 01:22:02,480 --> 01:22:03,710 Tôi đang tìm kiếm cho cơ thể. 1863 01:22:03,710 --> 01:22:04,330 Khư hôi. 1864 01:22:04,330 --> 01:22:05,680 Về nhận được cơ thể. 1865 01:22:05,680 --> 01:22:06,950 >> Tôi đọc dữ liệu ít hơn rất nhiều. 1866 01:22:06,950 --> 01:22:09,960 Tôi chỉ đọc cơ mà David cần khi anh ta cần họ. 1867 01:22:09,960 --> 01:22:14,230 Và tôi không ghi năm 1600 RCU của chỉ để hiển thị hộp thư đến của mình. 1868 01:22:14,230 --> 01:22:17,670 Vì vậy bây giờ that-- đây là cách mà LSI hoặc GSI-- Tôi xin lỗi, 1869 01:22:17,670 --> 01:22:19,900 GSI, sẽ làm việc ra. 1870 01:22:19,900 --> 01:22:25,450 Chúng tôi đã có hash của chúng tôi trên người nhận. 1871 01:22:25,450 --> 01:22:27,030 Chúng tôi đã có chìa khóa loạt vào ngày tháng. 1872 01:22:27,030 --> 01:22:31,380 Và chúng tôi đã có các thuộc tính dự chúng ta chỉ cần để ủng hộ quan điểm. 1873 01:22:31,380 --> 01:22:34,300 >> Chúng tôi xoay mà cho hộp thư đi. 1874 01:22:34,300 --> 01:22:35,770 Băm trên người gửi. 1875 01:22:35,770 --> 01:22:39,612 Và trong bản chất, chúng ta có các, nhìn sạch sẽ rất tốt đẹp. 1876 01:22:39,612 --> 01:22:41,570 Và nó basically-- chúng tôi có các tin nhắn này tốt đẹp 1877 01:22:41,570 --> 01:22:45,870 bảng đó được lan truyền độc đáo vì nó chỉ băm, băm ID tin nhắn. 1878 01:22:45,870 --> 01:22:51,750 Và chúng tôi có hai chỉ số đó được quay off của bảng đó. 1879 01:22:51,750 --> 01:22:57,411 Tất cả các quyền, vì vậy ý ​​tưởng ở đây là không giữ các dữ liệu lớn và dữ liệu nhỏ này 1880 01:22:57,411 --> 01:22:57,910 bên nhau. 1881 01:22:57,910 --> 01:23:00,700 Phân vùng theo chiều dọc, phân vùng những bảng. 1882 01:23:00,700 --> 01:23:03,150 Đừng đọc dữ liệu bạn không phải. 1883 01:23:03,150 --> 01:23:04,850 Được rồi, chơi game. 1884 01:23:04,850 --> 01:23:06,990 Chúng ta đều thích trò chơi. 1885 01:23:06,990 --> 01:23:10,902 Ít nhất là tôi thích trò chơi sau đó. 1886 01:23:10,902 --> 01:23:12,735 Vì vậy, một số trong những điều mà chúng ta đối phó với khi 1887 01:23:12,735 --> 01:23:14,193 chúng tôi đang suy nghĩ về chơi game, phải không? 1888 01:23:14,193 --> 01:23:16,999 Gaming những ngày này, đặc biệt là điện thoại di động chơi game, là tất cả về tư duy. 1889 01:23:16,999 --> 01:23:19,540 Và tôi sẽ xoay ở đây một chút chút xa DynamoDB. 1890 01:23:19,540 --> 01:23:21,373 Tôi sẽ mang lại một số cuộc thảo luận 1891 01:23:21,373 --> 01:23:24,240 xung quanh một số công nghệ AWS khác. 1892 01:23:24,240 --> 01:23:28,930 >> Nhưng ý tưởng về chơi game là để suy nghĩ về về các API, API mà, 1893 01:23:28,930 --> 01:23:31,730 nói chung, HTTP và JSON. 1894 01:23:31,730 --> 01:23:34,550 Đó là cách trò chơi di động loại tương tác với đầu trở lại của họ. 1895 01:23:34,550 --> 01:23:35,850 Họ làm JSON gửi bài. 1896 01:23:35,850 --> 01:23:40,660 Họ có được dữ liệu, và đó là tất cả, Nói chung, trong các API JSON đẹp. 1897 01:23:40,660 --> 01:23:44,950 >> Những điều như thế có được bạn bè, nhận các dữ liệu bảng dẫn, trao đổi, 1898 01:23:44,950 --> 01:23:47,699 người dùng tạo ra nội dung, đẩy trở lại vào hệ thống, 1899 01:23:47,699 --> 01:23:49,740 đây là những loại của sự vật rằng chúng tôi đang đi làm. 1900 01:23:49,740 --> 01:23:52,542 Dữ liệu tài sản nhị phân, dữ liệu này có thể không ngồi trong cơ sở dữ liệu. 1901 01:23:52,542 --> 01:23:54,250 Điều này có thể ngồi trong một cửa hàng đối tượng, đúng không? 1902 01:23:54,250 --> 01:23:56,541 Nhưng các cơ sở dữ liệu sẽ kết thúc lên nói cho hệ thống, 1903 01:23:56,541 --> 01:23:59,140 nói với các ứng dụng đi đâu có được nó. 1904 01:23:59,140 --> 01:24:03,550 Và chắc chắn, nhiều người máy chủ, cơ sở hạ tầng kết thúc trở lại, 1905 01:24:03,550 --> 01:24:06,180 và được thiết kế cho cao sẵn có và khả năng mở rộng. 1906 01:24:06,180 --> 01:24:09,400 Vì vậy, đây là những điều mà tất cả chúng ta muốn trong các cơ sở hạ tầng chơi game hiện nay. 1907 01:24:09,400 --> 01:24:12,160 >> Vì vậy, chúng ta hãy nhìn vào gì đó trông như thế nào. 1908 01:24:12,160 --> 01:24:16,070 Có một kết thúc trở lại cốt lõi, rất đơn giản. 1909 01:24:16,070 --> 01:24:19,880 Chúng tôi đã có một hệ thống ở đây với nhiều khu vực sẵn có. 1910 01:24:19,880 --> 01:24:23,780 Chúng tôi nói về AZS như being-- nghĩ của họ như là các trung tâm dữ liệu riêng biệt. 1911 01:24:23,780 --> 01:24:26,040 Trung tâm nhiều hơn một dữ liệu mỗi AZ, nhưng đó là OK, 1912 01:24:26,040 --> 01:24:28,831 chỉ cần nghĩ về chúng như dữ liệu riêng biệt các trung tâm địa lý 1913 01:24:28,831 --> 01:24:30,090 và lỗi cô lập. 1914 01:24:30,090 --> 01:24:32,172 >> Chúng ta sẽ có một trường hợp vài EC2. 1915 01:24:32,172 --> 01:24:33,880 Chúng ta sẽ có một số máy chủ kết thúc trở lại. 1916 01:24:33,880 --> 01:24:35,800 Có lẽ nếu bạn là một di sản kiến trúc, chúng tôi 1917 01:24:35,800 --> 01:24:38,920 sử dụng những gì chúng ta gọi RDS, dịch vụ cơ sở dữ liệu quan hệ. 1918 01:24:38,920 --> 01:24:42,040 Có thể là MSSQL, MySQL, hay đại loại thế. 1919 01:24:42,040 --> 01:24:47,080 Đây là cách một ứng dụng rất nhiều được thiết kế ngày nay. 1920 01:24:47,080 --> 01:24:49,594 >> Vâng, chúng tôi có thể muốn đi với này là khi chúng ta quy mô ra. 1921 01:24:49,594 --> 01:24:51,510 Chúng tôi sẽ đi trước và đặt xô S3 lên đó. 1922 01:24:51,510 --> 01:24:54,200 Và đó xô S3, thay vì phục vụ lên những đối tượng từ servers-- của chúng tôi 1923 01:24:54,200 --> 01:24:55,220 chúng ta có thể làm điều đó. 1924 01:24:55,220 --> 01:24:57,210 Bạn đặt tất cả nhị phân của bạn các đối tượng trên máy chủ của bạn 1925 01:24:57,210 --> 01:24:59,751 và bạn có thể sử dụng những máy chủ trường hợp để phục vụ dữ liệu lên. 1926 01:24:59,751 --> 01:25:01,860 Nhưng đó là khá tốn kém. 1927 01:25:01,860 --> 01:25:05,107 >> Cách tốt hơn để làm là đi trước và đưa những đối tượng trong một xô S3. 1928 01:25:05,107 --> 01:25:06,315 S3 là một kho đối tượng. 1929 01:25:06,315 --> 01:25:10,860 Nó được xây dựng riêng cho phục vụ tối đa các loại của sự vật. 1930 01:25:10,860 --> 01:25:13,690 Và để cho những khách hàng yêu cầu trực tiếp từ những xô đối tượng, 1931 01:25:13,690 --> 01:25:15,390 giảm tải các máy chủ. 1932 01:25:15,390 --> 01:25:17,020 Vì vậy, chúng tôi đang bắt đầu mở rộng ra ở đây. 1933 01:25:17,020 --> 01:25:19,140 >> Bây giờ chúng tôi đã sử dụng tất cả các nơi trên thế giới. 1934 01:25:19,140 --> 01:25:19,730 Tôi có người sử dụng. 1935 01:25:19,730 --> 01:25:23,380 Tôi cần phải có nội dung địa phương nằm gần với những người sử dụng, phải không? 1936 01:25:23,380 --> 01:25:26,200 Tôi đã tạo ra một xô S3 là kho lưu trữ nguồn của tôi. 1937 01:25:26,200 --> 01:25:29,370 Và tôi sẽ ở mặt trận này với sự phân bố CloudFront. 1938 01:25:29,370 --> 01:25:31,720 >> CloudFront là một CD và một mạng phân phối nội dung. 1939 01:25:31,720 --> 01:25:35,750 Về cơ bản nó mất dữ liệu mà bạn chỉ định và lưu trữ nó trên internet 1940 01:25:35,750 --> 01:25:39,230 vì vậy người sử dụng ở khắp mọi nơi có thể có một phản ứng rất nhanh khi 1941 01:25:39,230 --> 01:25:40,960 họ yêu cầu các đối tượng. 1942 01:25:40,960 --> 01:25:41,960 >> Vì vậy, bạn sẽ có được một ý tưởng. 1943 01:25:41,960 --> 01:25:48,230 Bạn đang loại tận dụng tất cả các các khía cạnh của AWS đây để thực hiện điều này. 1944 01:25:48,230 --> 01:25:50,790 Và cuối cùng, chúng ta vứt trong một nhóm tự động mở rộng quy mô. 1945 01:25:50,790 --> 01:25:52,737 Vì vậy, trường hợp của chúng tôi AC2 các máy chủ trò chơi của chúng tôi, 1946 01:25:52,737 --> 01:25:54,820 khi họ bắt đầu để có được bận rộn và bận rộn và bận rộn, 1947 01:25:54,820 --> 01:25:57,236 họ sẽ chỉ quay khác Chẳng hạn, quay dụ khác, 1948 01:25:57,236 --> 01:25:58,210 quay dụ khác. 1949 01:25:58,210 --> 01:26:02,090 Vì vậy, các công nghệ AWS có, nó cho phép bạn chỉ định các thông số 1950 01:26:02,090 --> 01:26:04,650 xung quanh mà các máy chủ của bạn sẽ phát triển. 1951 01:26:04,650 --> 01:26:08,110 Vì vậy, bạn có thể có số n của các máy chủ ra khỏi đó vào bất kỳ thời điểm nào. 1952 01:26:08,110 --> 01:26:11,870 Và nếu tải của bạn đi xa, họ sẽ thu nhỏ, số lượng sẽ giảm. 1953 01:26:11,870 --> 01:26:15,250 Và nếu nạp trở lại, nó sẽ mọc trở lại ra ngoài, đàn hồi. 1954 01:26:15,250 --> 01:26:17,050 >> Vì vậy, đây sẽ rất tốt. 1955 01:26:17,050 --> 01:26:19,800 Chúng tôi đã có rất nhiều trường hợp EC2. 1956 01:26:19,800 --> 01:26:21,671 Chúng tôi có thể đặt trong bộ nhớ cache phía trước của cơ sở dữ liệu, 1957 01:26:21,671 --> 01:26:23,045 cố gắng và thúc đẩy các cơ sở dữ liệu. 1958 01:26:23,045 --> 01:26:25,030 Các điểm áp lực tiếp theo thường mọi người nhìn thấy 1959 01:26:25,030 --> 01:26:28,850 là chúng co một trò chơi bằng cách sử dụng một hệ thống cơ sở dữ liệu quan hệ. 1960 01:26:28,850 --> 01:26:30,790 Jeez, cơ sở dữ liệu hiệu suất là khủng khiếp. 1961 01:26:30,790 --> 01:26:31,932 Làm thế nào để chúng tôi cải thiện điều đó? 1962 01:26:31,932 --> 01:26:33,640 Hãy thử đặt bộ nhớ cache trước đó. 1963 01:26:33,640 --> 01:26:36,780 >> Vâng, bộ nhớ cache không hoạt động tuyệt vời như vậy trong các trò chơi, phải không? 1964 01:26:36,780 --> 01:26:39,330 Đối với trò chơi, viết là đau đớn. 1965 01:26:39,330 --> 01:26:40,930 Trò chơi được rất viết nặng. 1966 01:26:40,930 --> 01:26:43,610 Bộ nhớ cache không hoạt động khi bạn viết nặng vì bạn đã luôn luôn 1967 01:26:43,610 --> 01:26:44,610 đã cập nhật bộ nhớ cache. 1968 01:26:44,610 --> 01:26:47,780 Bạn cập nhật bộ nhớ cache, đó là không liên quan đến bộ nhớ đệm được. 1969 01:26:47,780 --> 01:26:49,780 Nó thực sự chỉ phụ việc. 1970 01:26:49,780 --> 01:26:51,970 >> Vì vậy, nơi chúng tôi đi đây? 1971 01:26:51,970 --> 01:26:54,400 Bạn đã có một nút cổ chai lớn xuống có trong cơ sở dữ liệu. 1972 01:26:54,400 --> 01:26:57,661 Và là nơi để đi rõ ràng là phân vùng. 1973 01:26:57,661 --> 01:26:59,410 Phân vùng đĩa không dễ dàng để làm khi bạn đang 1974 01:26:59,410 --> 01:27:01,900 đối phó với cơ sở dữ liệu quan hệ. 1975 01:27:01,900 --> 01:27:05,080 Với cơ sở dữ liệu quan hệ, bạn trách nhiệm quản lý, có hiệu quả, 1976 01:27:05,080 --> 01:27:06,210 các không gian chính. 1977 01:27:06,210 --> 01:27:10,527 Bạn đang nói người sử dụng giữa A và M đi ở đây, giữa N và Z đến đó. 1978 01:27:10,527 --> 01:27:12,360 Và bạn đang chuyển qua các ứng dụng. 1979 01:27:12,360 --> 01:27:15,000 Vì vậy, bạn đang đối phó với nguồn dữ liệu này phân vùng. 1980 01:27:15,000 --> 01:27:18,670 Bạn có những hạn chế giao dịch mà không trải rộng phân vùng. 1981 01:27:18,670 --> 01:27:20,560 Bạn đã có tất cả các loại hỗn độn mà bạn 1982 01:27:20,560 --> 01:27:23,040 đối phó với giảm có cố gắng để đối phó với nhân rộng ra 1983 01:27:23,040 --> 01:27:25,120 và xây dựng một cơ sở hạ tầng lớn. 1984 01:27:25,120 --> 01:27:27,284 Nó chỉ là không có niềm vui. 1985 01:27:27,284 --> 01:27:30,930 >> Đung Vì vậy, bạn nói rằng tăng điểm nguồn tăng tốc 1986 01:27:30,930 --> 01:27:31,430 quá trình? 1987 01:27:31,430 --> 01:27:32,513 RICK Houlihan: Tăng? 1988 01:27:32,513 --> 01:27:33,520 Điểm Nguồn: Đung. 1989 01:27:33,520 --> 01:27:34,410 RICK Houlihan: Nguồn điểm? 1990 01:27:34,410 --> 01:27:37,500 Đung Từ những thông tin, nơi thông tin được đến từ đâu? 1991 01:27:37,500 --> 01:27:38,250 RICK Houlihan: No. 1992 01:27:38,250 --> 01:27:41,820 Những gì tôi nói là tăng Số lượng phân vùng trong các cửa hàng dữ liệu 1993 01:27:41,820 --> 01:27:44,060 cải thiện thông. 1994 01:27:44,060 --> 01:27:48,300 Vì vậy, những gì đang xảy ra ở đây là người dùng đi vào EC2 lên ở đây, 1995 01:27:48,300 --> 01:27:50,780 tốt, nếu tôi cần một người sử dụng đó là A đến M, tôi sẽ đi đây. 1996 01:27:50,780 --> 01:27:53,560 Từ N đến p, tôi sẽ đi đây. 1997 01:27:53,560 --> 01:27:55,060 Từ P đến Z, tôi sẽ đi đây. 1998 01:27:55,060 --> 01:27:57,120 >> Đung OK, những người như vậy là những người tất cả được lưu trữ trong các nút khác nhau? 1999 01:27:57,120 --> 01:27:57,911 >> RICK Houlihan: Yes. 2000 01:27:57,911 --> 01:28:00,210 Hãy nghĩ về những như silo dữ liệu khác nhau. 2001 01:28:00,210 --> 01:28:01,660 Vì vậy, bạn phải làm điều này. 2002 01:28:01,660 --> 01:28:02,910 Nếu bạn đang cố gắng để làm này, nếu bạn đang cố gắng 2003 01:28:02,910 --> 01:28:05,730 quy mô trên một nền tảng quan hệ, đây là những gì bạn đang làm. 2004 01:28:05,730 --> 01:28:08,100 Bạn đang dùng dữ liệu và bạn sẽ làm giảm xuống. 2005 01:28:08,100 --> 01:28:10,975 Và bạn đang phân vùng nó qua nhiều trường hợp của các cơ sở dữ liệu. 2006 01:28:10,975 --> 01:28:13,580 Và bạn đang quản lý tất cả những gì tại tầng ứng dụng. 2007 01:28:13,580 --> 01:28:14,729 Đó là không có niềm vui. 2008 01:28:14,729 --> 01:28:15,770 Vì vậy, những gì chúng ta muốn đi đâu? 2009 01:28:15,770 --> 01:28:20,240 Chúng tôi muốn đi DynamoDB, quản lý đầy đủ, Lưu trữ dữ liệu NoSQL, cung cấp thông lượng. 2010 01:28:20,240 --> 01:28:22,680 Chúng tôi sử dụng chỉ số phụ. 2011 01:28:22,680 --> 01:28:26,154 Đó là cơ bản HTTP API và bao gồm hỗ trợ tài liệu. 2012 01:28:26,154 --> 01:28:28,570 Vì vậy, bạn không phải lo lắng về bất kỳ phân vùng đó. 2013 01:28:28,570 --> 01:28:30,740 Chúng tôi làm tất cả cho bạn. 2014 01:28:30,740 --> 01:28:33,260 Vì vậy, bây giờ, thay vào đó, bạn chỉ cần ghi vào bảng. 2015 01:28:33,260 --> 01:28:36,490 Nếu một bảng cần được phân chia, điều đó xảy ra đằng sau hậu trường. 2016 01:28:36,490 --> 01:28:40,642 Bạn đang hoàn toàn cách ly từ đó như là một nhà phát triển. 2017 01:28:40,642 --> 01:28:42,350 Vì vậy, chúng ta hãy nói về một số các trường hợp sử dụng 2018 01:28:42,350 --> 01:28:47,564 rằng chúng tôi chạy vào trong game, phổ biến kịch bản game, dẫn. 2019 01:28:47,564 --> 01:28:49,980 Vì vậy, bạn đã có người đến, các BoardNames rằng họ đang 2020 01:28:49,980 --> 01:28:52,930 trên, điểm số cho người dùng này. 2021 01:28:52,930 --> 01:28:57,700 Chúng tôi có thể băm vào UserID, và sau đó chúng tôi có nhiều trên các trò chơi. 2022 01:28:57,700 --> 01:28:59,960 Vì vậy, mỗi người dùng muốn xem tất cả các trò chơi anh ta đã chơi 2023 01:28:59,960 --> 01:29:01,770 và tất cả các điểm cao của mình trên tất cả các trò chơi. 2024 01:29:01,770 --> 01:29:04,000 Vì vậy, đó là bảng dẫn cá nhân của mình. 2025 01:29:04,000 --> 01:29:10,010 >> Bây giờ tôi muốn đi vào và tôi muốn get-- vì vậy tôi có được những leaderboards cá nhân. 2026 01:29:10,010 --> 01:29:12,827 Những gì tôi muốn làm là đi lấy điểm cao nhất trên tất cả các người sử dụng. 2027 01:29:12,827 --> 01:29:13,660 Vì vậy, làm thế nào để làm điều đó? 2028 01:29:13,660 --> 01:29:18,070 Khi hồ sơ của tôi được băm trên UserID, dao động trên các trò chơi, 2029 01:29:18,070 --> 01:29:20,740 cũng tôi sẽ đi trước và cơ cấu lại, tạo ra một GSI, 2030 01:29:20,740 --> 01:29:22,370 và tôi sẽ phải cơ cấu lại dữ liệu đó. 2031 01:29:22,370 --> 01:29:27,310 >> Bây giờ tôi sẽ để băm trên BoardName, đó là trò chơi. 2032 01:29:27,310 --> 01:29:29,800 Và tôi sẽ nằm trong khoảng trên điểm cao nhất. 2033 01:29:29,800 --> 01:29:31,540 Và bây giờ tôi đã tạo ra xô khác nhau. 2034 01:29:31,540 --> 01:29:34,790 Tôi đang sử dụng cùng một bảng, các dữ liệu cùng một mục. 2035 01:29:34,790 --> 01:29:39,870 Nhưng tôi là tạo ra một thùng đó cho cho tôi một tập hợp của các điểm cao nhất của trò chơi. 2036 01:29:39,870 --> 01:29:43,180 >> Và tôi có thể truy vấn bảng để có được thông tin đó. 2037 01:29:43,180 --> 01:29:50,890 Vì vậy, tôi đã thiết lập rằng mô hình truy vấn lên đến được hỗ trợ bởi một số thứ. 2038 01:29:50,890 --> 01:29:54,556 Bây giờ họ có thể được sắp xếp theo BoardName và sắp xếp theo topscore, tùy thuộc vào. 2039 01:29:54,556 --> 01:29:57,180 Vì vậy, bạn có thể thấy, đây là những loại các trường hợp sử dụng bạn nhận được trong game. 2040 01:29:57,180 --> 01:30:02,190 Một trường hợp sử dụng tốt, chúng tôi có được trong game là các giải thưởng và những người đoạt giải thưởng. 2041 01:30:02,190 --> 01:30:05,340 Và đây là một trường hợp sử dụng tuyệt vời nơi chúng ta gọi là chỉ số thưa thớt. 2042 01:30:05,340 --> 01:30:07,340 Chỉ số thưa thớt là khả năng tạo 2043 01:30:07,340 --> 01:30:10,850 một chỉ số đó không nhất thiết chứa mọi hàng hoá trên bàn. 2044 01:30:10,850 --> 01:30:11,470 Và tại sao không? 2045 01:30:11,470 --> 01:30:14,540 Bởi vì các thuộc tính đó là được lập chỉ mục không tồn tại trên mọi mặt. 2046 01:30:14,540 --> 01:30:16,460 >> Vì vậy, trong này đặc biệt sử dụng trường hợp, tôi nói, 2047 01:30:16,460 --> 01:30:19,240 bạn biết không, tôi sẽ tạo ra một thuộc tính gọi là giải thưởng. 2048 01:30:19,240 --> 01:30:22,970 Và tôi sẽ cung cấp cho mỗi người sử dụng rằng có một giải thưởng thuộc tính. 2049 01:30:22,970 --> 01:30:25,950 Người sử dụng mà không có giải thưởng là sẽ không có thuộc tính đó. 2050 01:30:25,950 --> 01:30:27,800 Vì vậy, khi tôi tạo các chỉ số, người sử dụng chỉ 2051 01:30:27,800 --> 01:30:28,960 mà sẽ hiển thị trong danh mục được 2052 01:30:28,960 --> 01:30:31,050 những cái mà thực sự đã giành được giải thưởng. 2053 01:30:31,050 --> 01:30:34,440 Vì vậy, đó là một cách tuyệt vời để có thể để tạo ra các chỉ lọc mà 2054 01:30:34,440 --> 01:30:40,580 rất, rất chọn lọc mà không làm phải chỉ số toàn bộ bảng. 2055 01:30:40,580 --> 01:30:43,050 >> Vì vậy, chúng tôi đang nhận được thấp về thời gian ở đây. 2056 01:30:43,050 --> 01:30:49,190 Tôi sẽ đi trước và bỏ qua ra và bỏ qua kịch bản này. 2057 01:30:49,190 --> 01:30:52,625 Nói chuyện một chút about-- 2058 01:30:52,625 --> 01:30:54,460 >> Đung Tôi có thể hỏi một câu hỏi nhanh chóng? 2059 01:30:54,460 --> 01:30:56,722 Một là viết nặng? 2060 01:30:56,722 --> 01:30:57,680 RICK Houlihan: là gì? 2061 01:30:57,680 --> 01:30:58,596 Đung Viết nặng. 2062 01:30:58,596 --> 01:31:01,270 RICK Houlihan: Viết nặng. 2063 01:31:01,270 --> 01:31:03,460 Để tôi xem. 2064 01:31:03,460 --> 01:31:06,220 >> Đung Hoặc là không phải một cái gì đó bạn có thể chỉ 2065 01:31:06,220 --> 01:31:08,809 giọng nói để trong vài giây? 2066 01:31:08,809 --> 01:31:10,850 RICK Houlihan: Chúng tôi đi thông qua các kịch bản có quyền biểu quyết. 2067 01:31:10,850 --> 01:31:11,670 Nó không tệ. 2068 01:31:11,670 --> 01:31:14,580 Do you guys có một vài phút? 2069 01:31:14,580 --> 01:31:15,860 ĐƯỢC. 2070 01:31:15,860 --> 01:31:17,890 >> Vì vậy, chúng ta sẽ nói về bỏ phiếu. 2071 01:31:17,890 --> 01:31:20,250 Vì vậy, thời gian thực có quyền biểu quyết, chúng tôi có yêu cầu cho biểu quyết. 2072 01:31:20,250 --> 01:31:25,250 Yêu cầu được rằng chúng ta cho phép mỗi người bỏ phiếu chỉ một lần. 2073 01:31:25,250 --> 01:31:28,060 Chúng tôi muốn không ai để có thể thay đổi phiếu bầu của họ. 2074 01:31:28,060 --> 01:31:31,045 Chúng tôi muốn thời gian thực tập và phân tích nhân khẩu học cho 2075 01:31:31,045 --> 01:31:34,210 rằng chúng ta sẽ có hiển thị cho người dùng trên trang web. 2076 01:31:34,210 --> 01:31:35,200 >> Hãy suy nghĩ về kịch bản này. 2077 01:31:35,200 --> 01:31:37,550 Chúng tôi làm việc rất nhiều thực tế Chương trình truyền hình mà họ đang 2078 01:31:37,550 --> 01:31:38,960 làm các loại chính xác của sự vật. 2079 01:31:38,960 --> 01:31:41,584 Vì vậy, bạn có thể nghĩ đến kịch bản, chúng ta có hàng triệu và hàng triệu 2080 01:31:41,584 --> 01:31:43,959 cô gái tuổi teen có với các điện thoại di động của họ 2081 01:31:43,959 --> 01:31:46,250 và bỏ phiếu, và bỏ phiếu, và bỏ phiếu cho họ là ai 2082 01:31:46,250 --> 01:31:48,610 thấy là phổ biến nhất. 2083 01:31:48,610 --> 01:31:50,830 Vì vậy đây là một số các yêu cầu chúng tôi chạy ra ngoài. 2084 01:31:50,830 --> 01:31:52,990 >> Và do đó, lần đầu tiên đưa trong việc giải quyết vấn đề này 2085 01:31:52,990 --> 01:31:55,090 là xây dựng một ứng dụng rất đơn giản. 2086 01:31:55,090 --> 01:31:56,490 Vì vậy, tôi đã có ứng dụng này. 2087 01:31:56,490 --> 01:31:57,950 Tôi có một số cử tri ra khỏi đó. 2088 01:31:57,950 --> 01:31:59,980 Họ đi vào, họ nhấn ứng dụng có quyền biểu quyết. 2089 01:31:59,980 --> 01:32:03,440 Tôi đã có một số bảng votes liệu Tôi sẽ chỉ đổ những phiếu vào. 2090 01:32:03,440 --> 01:32:05,780 Tôi sẽ có một số tổng hợp bảng phiếu mà 2091 01:32:05,780 --> 01:32:09,490 sẽ làm phân tích và nhân khẩu học của tôi, và chúng tôi sẽ đặt tất cả điều này trong đó. 2092 01:32:09,490 --> 01:32:11,420 >> Và điều này là rất tốt. 2093 01:32:11,420 --> 01:32:12,332 Cuộc sống là tốt. 2094 01:32:12,332 --> 01:32:15,040 Cuộc sống của chúng ta tốt cho đến khi tìm ra rằng luôn luôn chỉ có một hoặc hai 2095 01:32:15,040 --> 01:32:16,879 người đó được phổ biến trong một cuộc bầu cử. 2096 01:32:16,879 --> 01:32:19,420 Có người chỉ có một hoặc hai điều mà mọi người thực sự quan tâm. 2097 01:32:19,420 --> 01:32:22,340 Và nếu bạn đang biểu quyết tại quy mô, tất cả của một đột ngột tôi 2098 01:32:22,340 --> 01:32:26,360 sẽ được búa địa ngục ra khỏi Hai ứng cử viên, một hoặc hai ứng cử viên. 2099 01:32:26,360 --> 01:32:29,390 Một số lượng rất hạn chế về các mặt hàng người tìm được phổ biến. 2100 01:32:29,390 --> 01:32:31,710 >> Đây không phải là một mẫu thiết kế tốt. 2101 01:32:31,710 --> 01:32:33,549 Đây thực sự là một mẫu thiết kế rất xấu 2102 01:32:33,549 --> 01:32:36,340 bởi vì nó tạo ra chính xác những gì chúng tôi nói về đó là các phím nóng. 2103 01:32:36,340 --> 01:32:38,960 Phím nóng là một cái gì đó chúng ta không thích. 2104 01:32:38,960 --> 01:32:40,470 >> Vì vậy, làm thế nào để chúng tôi khắc phục điều đó? 2105 01:32:40,470 --> 01:32:47,640 Và thực sự, cách để sửa lỗi này là bằng cách lấy những xô ứng viên 2106 01:32:47,640 --> 01:32:51,490 và cho mỗi ứng cử viên chúng ta có, chúng ta sẽ thêm một giá trị ngẫu nhiên, 2107 01:32:51,490 --> 01:32:54,192 một cái gì đó mà chúng ta biết, ngẫu nhiên giá trị từ một đến 100, 2108 01:32:54,192 --> 01:32:56,620 giữa 100 và 1000, hoặc giữa một và 1000, 2109 01:32:56,620 --> 01:32:59,940 Tuy nhiên nhiều giá trị ngẫu nhiên mà bạn muốn nối thêm vào cuối của các thí sinh. 2110 01:32:59,940 --> 01:33:01,330 >> Và những gì đã tôi thực sự thực hiện sau đó? 2111 01:33:01,330 --> 01:33:05,830 Nếu tôi đang sử dụng các ứng cử viên như ID xô đến phiếu tổng hợp, 2112 01:33:05,830 --> 01:33:08,780 nếu tôi đã thêm một ngẫu nhiên số để kết thúc đó, 2113 01:33:08,780 --> 01:33:12,000 Tôi đã tạo ra hiện nay 10 xô, một trăm xô, một ngàn thùng 2114 01:33:12,000 --> 01:33:14,160 mà tôi đang tổng hợp số phiếu ngang qua. 2115 01:33:14,160 --> 01:33:18,030 >> Vì vậy, tôi có hàng triệu và hàng triệu người, và hàng triệu bản ghi sắp tới trong 2116 01:33:18,030 --> 01:33:22,050 cho các ứng cử viên, bây giờ tôi đang lan rộng những phiếu trên Candidate A_1 2117 01:33:22,050 --> 01:33:24,630 Ứng viên qua A_100, vì mỗi khi một cuộc bỏ phiếu đến, 2118 01:33:24,630 --> 01:33:26,530 Tôi là tạo ra một cách ngẫu nhiên giá trị từ một đến 100. 2119 01:33:26,530 --> 01:33:29,446 Tôi tacking nó vào cuối ứng cử viên là người của bầu cho. 2120 01:33:29,446 --> 01:33:31,120 Tôi đang đổ vào thùng đó. 2121 01:33:31,120 --> 01:33:33,910 >> Bây giờ trên mặt sau, tôi biết rằng tôi có một trăm thùng. 2122 01:33:33,910 --> 01:33:36,350 Vì vậy, khi tôi muốn đi trước và tổng hợp các phiếu bầu, 2123 01:33:36,350 --> 01:33:38,244 Tôi đọc từ tất cả những xô. 2124 01:33:38,244 --> 01:33:39,160 Vì vậy, tôi đi trước và thêm. 2125 01:33:39,160 --> 01:33:42,410 Và sau đó tôi làm việc phân tán tập nơi tôi đi ra ngoài và nói hey, 2126 01:33:42,410 --> 01:33:45,399 bạn biết những gì, quan trọng của ứng viên này không gian là hơn một trăm thùng. 2127 01:33:45,399 --> 01:33:47,940 Tôi sẽ thu thập tất cả các phiếu từ những trăm xô. 2128 01:33:47,940 --> 01:33:49,981 Tôi sẽ tổng hợp họ và tôi sẽ nói, 2129 01:33:49,981 --> 01:33:53,830 Ứng cử viên A hiện có tổng số phiếu bầu của x. 2130 01:33:53,830 --> 01:33:55,690 >> Bây giờ cả viết truy vấn và truy vấn đọc 2131 01:33:55,690 --> 01:33:58,160 được phân phối độc đáo bởi vì tôi đang viết trên 2132 01:33:58,160 --> 01:34:00,320 và tôi đọc qua hàng trăm phím. 2133 01:34:00,320 --> 01:34:03,500 Tôi không viết và đọc qua một trong những trọng điểm bây giờ. 2134 01:34:03,500 --> 01:34:04,950 Vì vậy, đó là một mô hình tuyệt vời. 2135 01:34:04,950 --> 01:34:08,090 >> Điều này thực sự có lẽ là một của thiết kế quan trọng nhất 2136 01:34:08,090 --> 01:34:10,420 mô hình quy mô trong NoSQL. 2137 01:34:10,420 --> 01:34:14,470 Bạn sẽ thấy kiểu này mẫu thiết kế trong từng hương vị. 2138 01:34:14,470 --> 01:34:19,100 MongoDB, DynamoDB, nó không vấn đề, tất cả chúng ta phải làm điều này. 2139 01:34:19,100 --> 01:34:21,840 Bởi vì khi bạn đang làm việc với những quy tụ rất lớn, 2140 01:34:21,840 --> 01:34:26,650 bạn phải tìm ra một cách để trải chúng ra khắp xô. 2141 01:34:26,650 --> 01:34:29,512 Vì vậy, đây là cách bạn làm điều đó. 2142 01:34:29,512 --> 01:34:31,220 Được rồi, vì vậy những gì bạn đang làm ngay bây giờ 2143 01:34:31,220 --> 01:34:35,252 là bạn đang kinh doanh tắt đọc chi phí cho ghi khả năng mở rộng. 2144 01:34:35,252 --> 01:34:37,085 Các chi phí của tôi là đọc một chút phức tạp hơn 2145 01:34:37,085 --> 01:34:40,220 và tôi phải đi đọc từ một trăm xô thay vì một. 2146 01:34:40,220 --> 01:34:41,310 Nhưng tôi có thể viết. 2147 01:34:41,310 --> 01:34:44,860 Và thông của tôi, tôi viết thông qua là không thể tin được. 2148 01:34:44,860 --> 01:34:49,450 Vì vậy, nó thường là một giá trị kỹ thuật cho rộng DynamoDB, 2149 01:34:49,450 --> 01:34:51,350 hoặc bất kỳ cơ sở dữ liệu NoSQL cho rằng vấn đề. 2150 01:34:51,350 --> 01:34:53,824 2151 01:34:53,824 --> 01:34:55,240 Vì vậy, chúng tôi đã tìm ra cách để mở rộng nó. 2152 01:34:55,240 --> 01:34:56,930 Và chúng tôi đã tìm cách loại bỏ các phím nóng của chúng tôi. 2153 01:34:56,930 --> 01:34:57,820 Và điều này là tuyệt vời. 2154 01:34:57,820 --> 01:34:58,960 Và chúng tôi có hệ thống tốt đẹp này. 2155 01:34:58,960 --> 01:35:02,043 Và nó cho chúng ta bỏ phiếu rất chính xác bởi vì chúng tôi có ghi phiếu de-dupe. 2156 01:35:02,043 --> 01:35:03,130 Nó được xây dựng vào DynamoDB. 2157 01:35:03,130 --> 01:35:05,380 Chúng tôi nói về quyền có điều kiện. 2158 01:35:05,380 --> 01:35:08,170 >> Khi một cử tri đến, puts một chèn trên bàn, 2159 01:35:08,170 --> 01:35:11,220 họ chèn với ID cử tri của họ, nếu họ cố gắng để chèn bỏ phiếu khác, 2160 01:35:11,220 --> 01:35:13,320 Tôi làm một ghi điều kiện. 2161 01:35:13,320 --> 01:35:16,960 Chỉ nói viết này nếu điều này không tồn tại. 2162 01:35:16,960 --> 01:35:19,270 Vì vậy, ngay sau khi tôi thấy rằng rằng lá phiếu của hit bảng, 2163 01:35:19,270 --> 01:35:20,460 không ai khác sẽ là có thể đưa vào lá phiếu của họ trong. 2164 01:35:20,460 --> 01:35:21,634 Và đó là tuyệt vời. 2165 01:35:21,634 --> 01:35:23,550 Và chúng tôi đang incrementing quầy ứng cử viên của chúng tôi. 2166 01:35:23,550 --> 01:35:25,466 Và chúng tôi đang làm của chúng tôi nhân khẩu học và tất cả điều đó. 2167 01:35:25,466 --> 01:35:29,110 Nhưng điều gì sẽ xảy ra nếu tôi ứng dụng ngã xuống? 2168 01:35:29,110 --> 01:35:31,350 Bây giờ tất cả của một đột ngột phiếu đang đến, và tôi 2169 01:35:31,350 --> 01:35:34,840 không biết nếu họ đang bị xử lý vào phân tích và nhân khẩu học của tôi 2170 01:35:34,840 --> 01:35:36,040 nữa không. 2171 01:35:36,040 --> 01:35:38,462 Và khi các ứng dụng trở lại lên, làm thế nào 2172 01:35:38,462 --> 01:35:41,420 quái làm tôi biết những gì có phiếu được xử lý và nơi nào tôi bắt đầu? 2173 01:35:41,420 --> 01:35:44,530 >> Vì vậy, đây là một vấn đề thực sự khi bạn bắt đầu nhìn vào các loại kịch bản. 2174 01:35:44,530 --> 01:35:45,571 Và làm thế nào để chúng ta giải quyết đó? 2175 01:35:45,571 --> 01:35:48,070 Chúng tôi giải quyết nó với những gì chúng tôi gọi DynamoDB Streams. 2176 01:35:48,070 --> 01:35:53,470 Streams được một thời gian yêu cầu và phân vùng thay đổi đăng nhập của mỗi lần truy cập 2177 01:35:53,470 --> 01:35:55,700 để bàn, mỗi viết truy cập vào bảng. 2178 01:35:55,700 --> 01:35:58,810 Bất kỳ dữ liệu đó bằng văn bản cho bảng hiển thị lên trên suối. 2179 01:35:58,810 --> 01:36:01,815 >> Đó là cơ bản một hàng đợi 24 giờ. 2180 01:36:01,815 --> 01:36:03,690 Items nhấn suối, họ sống trong 24 giờ. 2181 01:36:03,690 --> 01:36:05,990 Họ có thể được đọc nhiều lần. 2182 01:36:05,990 --> 01:36:09,400 Đảm bảo sẽ được chuyển giao chỉ một lần cho các dòng, 2183 01:36:09,400 --> 01:36:11,180 có thể được đọc số n lần. 2184 01:36:11,180 --> 01:36:14,910 Vì vậy, tuy nhiên nhiều quá trình bạn muốn tiêu thụ dữ liệu đó, bạn có thể tiêu thụ nó. 2185 01:36:14,910 --> 01:36:16,350 Nó sẽ xuất hiện mỗi khi cập nhật. 2186 01:36:16,350 --> 01:36:18,455 Mỗi write sẽ chỉ xuất hiện một lần trên suối. 2187 01:36:18,455 --> 01:36:20,621 Vì vậy, bạn không phải lo lắng về chế biến nó hai lần 2188 01:36:20,621 --> 01:36:22,500 từ cùng một quá trình. 2189 01:36:22,500 --> 01:36:25,350 >> Nó ra lệnh nghiêm chỉnh cho mỗi mục. 2190 01:36:25,350 --> 01:36:28,180 Khi chúng ta nói thời gian đặt hàng và phân vùng, 2191 01:36:28,180 --> 01:36:30,680 bạn sẽ thấy mỗi phân vùng trên suối. 2192 01:36:30,680 --> 01:36:33,169 Bạn sẽ thấy các mục, cập nhật theo thứ tự. 2193 01:36:33,169 --> 01:36:35,210 Chúng tôi không đảm bảo trên dòng suối mà bạn 2194 01:36:35,210 --> 01:36:40,240 sẽ nhận được mỗi giao dịch theo thứ tự trên các mặt hàng. 2195 01:36:40,240 --> 01:36:42,440 >> Vì vậy, dòng suối có idempotent. 2196 01:36:42,440 --> 01:36:44,037 Tất cả chúng ta biết những gì idempotent nghĩa? 2197 01:36:44,037 --> 01:36:46,620 Idempotent có nghĩa là bạn có thể làm điều đó hơn, và hơn, và hơn nữa. 2198 01:36:46,620 --> 01:36:48,200 Kết quả sẽ được như vậy. 2199 01:36:48,200 --> 01:36:49,991 >> Streams là idempotent, nhưng chúng phải được 2200 01:36:49,991 --> 01:36:54,860 chơi từ điểm khởi đầu, bất cứ nơi nào bạn chọn, để kết thúc, 2201 01:36:54,860 --> 01:36:57,950 hoặc họ sẽ không kết quả trong cùng một giá trị. 2202 01:36:57,950 --> 01:36:59,727 >> Cùng một điều với MongoDB. 2203 01:36:59,727 --> 01:37:01,560 MongoDB có một cấu trúc họ gọi là oplog. 2204 01:37:01,560 --> 01:37:04,140 Nó là giống cấu trúc chính xác. 2205 01:37:04,140 --> 01:37:06,500 Nhiều cơ sở dữ liệu NoSQL có cấu trúc này. 2206 01:37:06,500 --> 01:37:08,790 Họ sử dụng nó để làm những việc như sao chép, mà 2207 01:37:08,790 --> 01:37:10,475 là chính xác những gì chúng tôi làm với suối. 2208 01:37:10,475 --> 01:37:12,350 Đung Có lẽ một câu lạc giáo, nhưng bạn 2209 01:37:12,350 --> 01:37:13,975 nói về các ứng dụng làm ngã một vv. 2210 01:37:13,975 --> 01:37:16,089 Được luồng đảm bảo không bao giờ có thể đi xuống? 2211 01:37:16,089 --> 01:37:18,630 RICK Houlihan: Yeah, suối được đảm bảo để không bao giờ đi xuống. 2212 01:37:18,630 --> 01:37:21,040 Chúng tôi quản lý cơ sở hạ tầng phía sau. suối tự động 2213 01:37:21,040 --> 01:37:22,498 triển khai trong nhóm tự động mở rộng quy mô của họ. 2214 01:37:22,498 --> 01:37:25,910 Chúng tôi sẽ đi qua một chút chút về những gì sẽ xảy ra. 2215 01:37:25,910 --> 01:37:30,060 >> Tôi không cần biết họ không đảm bảo không bao giờ đi xuống. 2216 01:37:30,060 --> 01:37:33,110 Các yếu tố được đảm bảo để xuất hiện trong các dòng suối. 2217 01:37:33,110 --> 01:37:36,740 Và dòng sẽ có thể truy cập. 2218 01:37:36,740 --> 01:37:40,580 Vì vậy, những gì đi xuống hoặc trở lại lên, điều đó xảy ra bên dưới. 2219 01:37:40,580 --> 01:37:43,844 Nó covers-- đó là OK. 2220 01:37:43,844 --> 01:37:46,260 Tất cả các bên phải, vì vậy bạn sẽ có được khác nhau xem loại ra khỏi màn hình. 2221 01:37:46,260 --> 01:37:51,040 Các loại điểm quan trọng đối với một lập trình thường được, đó là gì? 2222 01:37:51,040 --> 01:37:52,370 Tôi có được quan điểm cũ. 2223 01:37:52,370 --> 01:37:55,630 Khi một bản cập nhật số truy cập bảng, nó sẽ thấy đẩy quan điểm cũ vào dòng 2224 01:37:55,630 --> 01:38:02,070 vì vậy dữ liệu có thể lưu trữ, hoặc thay đổi kiểm soát, xác định sự thay đổi, thay đổi 2225 01:38:02,070 --> 01:38:03,600 quản lý. 2226 01:38:03,600 --> 01:38:07,160 >> Những hình ảnh mới, những gì nó bây giờ là sau khi cập nhật, đó là một kiểu giao diện 2227 01:38:07,160 --> 01:38:07,660 bạn có thể làm được. 2228 01:38:07,660 --> 01:38:09,660 Bạn có thể nhận được cả những hình ảnh cũ và mới. 2229 01:38:09,660 --> 01:38:10,660 Có lẽ tôi muốn cả hai. 2230 01:38:10,660 --> 01:38:11,790 Tôi muốn nhìn thấy những gì nó được. 2231 01:38:11,790 --> 01:38:13,290 Tôi muốn nhìn thấy những gì nó đã thay đổi tới. 2232 01:38:13,290 --> 01:38:15,340 >> Tôi có một loại tuân thủ của quá trình mà chạy. 2233 01:38:15,340 --> 01:38:17,430 Nó cần phải xác minh rằng khi những điều thay đổi, 2234 01:38:17,430 --> 01:38:21,840 rằng họ đang trong giới hạn nhất định hoặc trong các thông số nhất định. 2235 01:38:21,840 --> 01:38:23,840 >> Và sau đó có lẽ tôi chỉ cần phải biết những gì thay đổi. 2236 01:38:23,840 --> 01:38:26,240 Tôi không quan tâm những gì mục thay đổi. 2237 01:38:26,240 --> 01:38:28,580 Tôi không cần phải cần biết những gì thuộc tính thay đổi. 2238 01:38:28,580 --> 01:38:30,882 Tôi chỉ cần biết rằng các mặt hàng đang được xúc động. 2239 01:38:30,882 --> 01:38:33,340 Vì vậy, đây là những loại quan điểm mà bạn có được ra khỏi dòng 2240 01:38:33,340 --> 01:38:35,960 và bạn có thể tương tác với. 2241 01:38:35,960 --> 01:38:37,840 >> Các ứng dụng mà tiêu thụ các dòng, 2242 01:38:37,840 --> 01:38:39,298 đây là loại cách làm việc này. 2243 01:38:39,298 --> 01:38:42,570 DynamoDB khách hàng yêu cầu đẩy dữ liệu vào các bảng. 2244 01:38:42,570 --> 01:38:44,750 Streams triển khai trên những gì chúng ta gọi là những mảnh vỡ. 2245 01:38:44,750 --> 01:38:47,380 Shards được thu nhỏ độc lập của bảng. 2246 01:38:47,380 --> 01:38:50,660 Họ không xếp hàng hoàn toàn các phân vùng của bảng của bạn. 2247 01:38:50,660 --> 01:38:52,540 Và lý do tại sao vì họ xếp hàng 2248 01:38:52,540 --> 01:38:55,430 để công suất, hiện nay công suất của bảng. 2249 01:38:55,430 --> 01:38:57,600 >> Họ triển khai trong họ riêng nhóm tự động mở rộng quy mô, 2250 01:38:57,600 --> 01:39:00,800 và họ bắt đầu quay ra phụ thuộc bao nhiêu viết được đến, 2251 01:39:00,800 --> 01:39:03,090 bao nhiêu reads-- thực sự nó viết. 2252 01:39:03,090 --> 01:39:05,820 Không có reads-- nhưng làm thế nào nhiều viết được đến ở. 2253 01:39:05,820 --> 01:39:08,200 >> Và sau đó trên lưng kết thúc, chúng tôi có những gì chúng tôi 2254 01:39:08,200 --> 01:39:11,390 gọi một KCL, hoặc Kinesis Thư viện Client. 2255 01:39:11,390 --> 01:39:19,190 Kinesis là một dòng dữ liệu công nghệ chế biến từ Amazon. 2256 01:39:19,190 --> 01:39:22,040 Và suối được xây dựng trên đó. 2257 01:39:22,040 --> 01:39:25,670 >> Vì vậy, bạn sử dụng một KCL kích hoạt ứng dụng để đọc những dòng. 2258 01:39:25,670 --> 01:39:28,752 Các thư viện khách Kinesis thực quản lý lao động cho bạn. 2259 01:39:28,752 --> 01:39:30,460 Và nó cũng làm một số những điều thú vị. 2260 01:39:30,460 --> 01:39:35,630 Nó sẽ tạo ra một số bảng lên trong tablespace DynamoDB của bạn 2261 01:39:35,630 --> 01:39:38,410 để theo dõi các mục đã được xử lý. 2262 01:39:38,410 --> 01:39:41,190 Vì vậy, cách này nếu nó rơi trở lại, nếu nó té ngã hơn và đi kèm và được 2263 01:39:41,190 --> 01:39:45,570 đứng dậy, nó có thể xác định nơi là nó trong chế biến các dòng. 2264 01:39:45,570 --> 01:39:48,360 >> Điều đó rất quan trọng khi bạn đang nói về nhân rộng. 2265 01:39:48,360 --> 01:39:50,350 Tôi cần phải biết những gì dữ liệu đã được xử lý 2266 01:39:50,350 --> 01:39:52,810 và những dữ liệu vẫn chưa được xử lý. 2267 01:39:52,810 --> 01:39:57,380 Vì vậy, các thư viện KCL cho suối sẽ cung cấp cho bạn rất nhiều các chức năng đó. 2268 01:39:57,380 --> 01:39:58,990 Nó sẽ chăm sóc của tất cả các cửa. 2269 01:39:58,990 --> 01:40:01,140 Nó đứng dậy một công nhân cho mỗi mảnh. 2270 01:40:01,140 --> 01:40:04,620 Nó tạo ra một bảng hành chính cho mỗi mảnh, cho mỗi người lao động. 2271 01:40:04,620 --> 01:40:07,560 Và như những công nhân cháy, họ duy trì các bảng 2272 01:40:07,560 --> 01:40:10,510 vì vậy bạn có biết hồ sơ này được đọc và xử lý. 2273 01:40:10,510 --> 01:40:13,850 Và sau đó theo cách đó nếu tiến trình chết và trở lại trực tuyến, 2274 01:40:13,850 --> 01:40:17,940 nó có thể tiếp tục bên phải, nơi nó cất cánh. 2275 01:40:17,940 --> 01:40:20,850 >> Vì vậy, chúng tôi sử dụng này cho cross-khu vực rộng. 2276 01:40:20,850 --> 01:40:24,680 Rất nhiều khách hàng có nhu cầu di chuyển dữ liệu hoặc các bộ phận của các bảng dữ liệu của họ 2277 01:40:24,680 --> 01:40:25,920 xung quanh các vùng khác nhau. 2278 01:40:25,920 --> 01:40:29,230 Có chín vùng vòng quanh thế giới. 2279 01:40:29,230 --> 01:40:32,100 Vì vậy, có thể có một tôi need-- có thể có người dùng ở châu Á, người sử dụng 2280 01:40:32,100 --> 01:40:34,150 ở bờ biển phía Đông của Hoa Kỳ. 2281 01:40:34,150 --> 01:40:38,980 Họ có dữ liệu khác nhau cần được phân phối tại địa phương. 2282 01:40:38,980 --> 01:40:42,510 Và có lẽ một người sử dụng bay từ Á sang Hoa Kỳ, 2283 01:40:42,510 --> 01:40:45,020 và tôi muốn nhân rộng dữ liệu của mình với anh ta. 2284 01:40:45,020 --> 01:40:49,340 Vì vậy, khi ông bước ra khỏi máy bay, ông đã có một kinh nghiệm tốt bằng cách sử dụng ứng dụng di động của mình. 2285 01:40:49,340 --> 01:40:52,360 >> Bạn có thể sử dụng cross-khu vực thư viện nhân rộng để làm điều này. 2286 01:40:52,360 --> 01:40:55,730 Về cơ bản chúng tôi có cung cấp hai công nghệ. 2287 01:40:55,730 --> 01:40:59,400 Một là một ứng dụng giao diện điều khiển, bạn có thể đứng lên trên EC2 của riêng bạn. 2288 01:40:59,400 --> 01:41:01,240 Nó chạy nhân bản thuần túy. 2289 01:41:01,240 --> 01:41:02,720 Và sau đó chúng tôi đã cho bạn thư viện. 2290 01:41:02,720 --> 01:41:06,070 Các thư viện bạn có thể sử dụng để xây dựng ứng dụng của riêng bạn nếu bạn 2291 01:41:06,070 --> 01:41:10,740 muốn làm những điều điên rồ với data-- lọc, tái tạo chỉ là một phần của nó, 2292 01:41:10,740 --> 01:41:14,120 xoay dữ liệu, di chuyển nó thành một bảng khác nhau, vv và vv. 2293 01:41:14,120 --> 01:41:18,700 2294 01:41:18,700 --> 01:41:20,520 Vì vậy, đó là loại gì đó trông như thế nào. 2295 01:41:20,520 --> 01:41:23,690 >> DynamoDB Streams thể xử lý bởi những gì chúng ta gọi là Lambda. 2296 01:41:23,690 --> 01:41:27,394 Chúng tôi đã đề cập một chút về sự kiện kiến trúc ứng dụng điều khiển. 2297 01:41:27,394 --> 01:41:28,810 Lambda là một thành phần quan trọng của điều đó. 2298 01:41:28,810 --> 01:41:32,840 Lambda là mã mà bắn theo yêu cầu để đáp ứng với một sự kiện đặc biệt. 2299 01:41:32,840 --> 01:41:36,020 Một trong những sự kiện có thể là một kỷ lục xuất hiện trên suối. 2300 01:41:36,020 --> 01:41:39,100 Nếu một kỷ lục xuất hiện trên các dòng suối, chúng ta sẽ gọi hàm Java này. 2301 01:41:39,100 --> 01:41:44,980 Vâng, đây là JavaScript, và Lambda hỗ trợ Node.js, Java, Python, 2302 01:41:44,980 --> 01:41:47,820 và sẽ sớm hỗ trợ các ngôn ngữ khác. 2303 01:41:47,820 --> 01:41:50,940 Và đủ để nói, đó là mã tinh khiết. 2304 01:41:50,940 --> 01:41:53,610 viết Trong Java, bạn định nghĩa một lớp. 2305 01:41:53,610 --> 01:41:55,690 Bạn đẩy JAR thành Lambda. 2306 01:41:55,690 --> 01:42:00,200 Và sau đó bạn chỉ định lớp gọi để đáp ứng với sự kiện đó. 2307 01:42:00,200 --> 01:42:04,770 Và sau đó các cơ sở hạ tầng Lambda đằng sau đó sẽ chạy mã. 2308 01:42:04,770 --> 01:42:06,730 >> Mã mà có thể xử lý hồ sơ ra khỏi dòng. 2309 01:42:06,730 --> 01:42:08,230 Nó có thể làm bất cứ điều gì nó muốn với nó. 2310 01:42:08,230 --> 01:42:11,650 Trong ví dụ này, tất cả chúng tôi thực sự làm là đăng nhập các thuộc tính. 2311 01:42:11,650 --> 01:42:13,480 Nhưng đây chỉ là code. 2312 01:42:13,480 --> 01:42:15,260 Mã có thể làm bất cứ điều gì, phải không? 2313 01:42:15,260 --> 01:42:16,600 >> Vì vậy, bạn có thể xoay dữ liệu đó. 2314 01:42:16,600 --> 01:42:18,160 Bạn có thể tạo ra một cái nhìn phái sinh. 2315 01:42:18,160 --> 01:42:21,160 Nếu đó là một cấu trúc tài liệu, bạn có thể làm phẳng cấu trúc. 2316 01:42:21,160 --> 01:42:24,300 Bạn có thể tạo các chỉ mục thay thế. 2317 01:42:24,300 --> 01:42:27,100 Tất cả mọi thứ bạn có thể làm với Streams DynamoDB. 2318 01:42:27,100 --> 01:42:28,780 >> Và thực sự, đó là những gì mà trông như thế nào. 2319 01:42:28,780 --> 01:42:29,940 Vì vậy, bạn sẽ có được những bản cập nhật sắp tới trong. 2320 01:42:29,940 --> 01:42:31,190 Họ đang sắp tắt chuỗi. 2321 01:42:31,190 --> 01:42:32,720 Họ đang đọc bởi chức năng Lambda. 2322 01:42:32,720 --> 01:42:37,480 Họ đang quay các dữ liệu và đẩy nó lên trong bảng phái sinh, 2323 01:42:37,480 --> 01:42:42,200 thông báo cho các hệ thống bên ngoài của sự thay đổi, và đẩy dữ liệu vào ElastiCache. 2324 01:42:42,200 --> 01:42:45,900 >> Chúng tôi đã nói chuyện về làm thế nào để đưa bộ nhớ cache ở phía trước của cơ sở dữ liệu cho doanh số bán hàng mà 2325 01:42:45,900 --> 01:42:46,450 kịch bản. 2326 01:42:46,450 --> 01:42:50,049 Vâng những gì sẽ xảy ra nếu tôi cập nhật mô tả mục? 2327 01:42:50,049 --> 01:42:52,340 Vâng, nếu tôi đã có một Lambda chức năng chạy trên bàn đó, 2328 01:42:52,340 --> 01:42:55,490 nếu tôi cập nhật mô tả mục, nó sẽ thấy chọn các bản ghi ra khỏi dòng, 2329 01:42:55,490 --> 01:42:58,711 và nó sẽ cập nhật các ElastiCache Ví dụ với các dữ liệu mới. 2330 01:42:58,711 --> 01:43:00,460 Vì vậy, đó là rất nhiều những gì chúng tôi làm với Lambda. 2331 01:43:00,460 --> 01:43:02,619 Đó là mã keo, kết nối. 2332 01:43:02,619 --> 01:43:04,410 Và nó thực sự mang đến khả năng khởi động 2333 01:43:04,410 --> 01:43:07,930 và chạy các ứng dụng rất phức tạp mà không có một máy chủ chuyên dụng 2334 01:43:07,930 --> 01:43:10,371 cơ sở hạ tầng, mà là thực sự mát mẻ. 2335 01:43:10,371 --> 01:43:13,100 >> Vì vậy, chúng ta hãy quay trở lại của chúng tôi thời gian thực kiến ​​trúc biểu quyết. 2336 01:43:13,100 --> 01:43:17,984 Điều này là mới và cải tiến với chúng tôi suối và KCL kích hoạt ứng dụng. 2337 01:43:17,984 --> 01:43:20,150 Giống như trước, chúng ta có thể xử lý bất kỳ quy mô của cuộc bầu cử. 2338 01:43:20,150 --> 01:43:21,100 Chúng tôi thích điều này. 2339 01:43:21,100 --> 01:43:24,770 Chúng tôi đang làm ra tập hợp phân tán trên nhiều xô. 2340 01:43:24,770 --> 01:43:26,780 Chúng tôi đã có khóa lạc xảy ra. 2341 01:43:26,780 --> 01:43:30,192 Chúng tôi có thể giữ cho cử tri của chúng tôi từ việc thay đổi lá phiếu của họ. 2342 01:43:30,192 --> 01:43:31,400 Họ chỉ có thể bỏ phiếu một lần duy nhất. 2343 01:43:31,400 --> 01:43:32,880 Điều này là tuyệt vời. 2344 01:43:32,880 --> 01:43:35,895 Khả năng chịu lỗi thời gian thực, tập hợp khả năng mở rộng hiện nay. 2345 01:43:35,895 --> 01:43:38,270 Nếu điều ngã xuống, nó biết nơi để tự khởi động lại 2346 01:43:38,270 --> 01:43:41,300 khi nó trở lại lên vì chúng ta đang sử dụng ứng dụng KCL. 2347 01:43:41,300 --> 01:43:45,700 Và sau đó, chúng tôi cũng có thể sử dụng Ứng dụng KCL để đẩy dữ liệu ra 2348 01:43:45,700 --> 01:43:48,820 để dịch chuyển đỏ cho khác phân tích ứng dụng, hoặc sử dụng 2349 01:43:48,820 --> 01:43:51,990 các MapReduce đàn hồi để chạy thời gian thực trực tuyến quy tụ off 2350 01:43:51,990 --> 01:43:53,180 của dữ liệu đó. 2351 01:43:53,180 --> 01:43:55,480 >> Vì vậy, đây là những điều chúng tôi đã không nói về nhiều. 2352 01:43:55,480 --> 01:43:57,375 Nhưng họ đang thêm công nghệ mà đi 2353 01:43:57,375 --> 01:44:00,310 chịu khi bạn đang tìm kiếm ở các loại kịch bản. 2354 01:44:00,310 --> 01:44:03,160 >> Được rồi, vì vậy đó là khoảng phân tích với DynamoDB Streams. 2355 01:44:03,160 --> 01:44:05,340 Bạn có thể thu thập de-dupe dữ liệu, làm tất cả các loại 2356 01:44:05,340 --> 01:44:09,490 tốt đẹp các công cụ, dữ liệu tổng hợp trong bộ nhớ, tạo ra những bảng phái sinh. 2357 01:44:09,490 --> 01:44:13,110 Đó là một trường hợp sử dụng lớn mà rất nhiều khách hàng 2358 01:44:13,110 --> 01:44:16,950 được tham gia với, lấy lồng nhau tính chất của những tài liệu JSON 2359 01:44:16,950 --> 01:44:18,946 và tạo chỉ mục bổ sung. 2360 01:44:18,946 --> 01:44:21,680 2361 01:44:21,680 --> 01:44:23,150 >> Chúng tôi đang ở cuối. 2362 01:44:23,150 --> 01:44:26,689 Cảm ơn bạn đã mang với tôi. 2363 01:44:26,689 --> 01:44:28,480 Vì vậy, chúng ta hãy nói về kiến trúc tham khảo. 2364 01:44:28,480 --> 01:44:33,440 DynamoDB ngồi ở giữa nên nhiều cơ sở hạ tầng AWS. 2365 01:44:33,440 --> 01:44:37,090 Về cơ bản bạn có thể treo nó lên đến bất cứ điều gì bạn muốn. 2366 01:44:37,090 --> 01:44:45,600 Các ứng dụng được xây dựng sử dụng Dynamo bao gồm Lambda, ElastiCache, CloudSearch, 2367 01:44:45,600 --> 01:44:49,890 đẩy dữ liệu ra vào Elastic MapReduce, xuất khẩu, nhập khẩu từ DynamoDB 2368 01:44:49,890 --> 01:44:52,370 vào S3, tất cả các loại công việc. 2369 01:44:52,370 --> 01:44:54,120 Nhưng có lẽ là tốt nhất điều để nói về, 2370 01:44:54,120 --> 01:44:56,119 và đây là những gì thực sự thú vị là khi chúng ta 2371 01:44:56,119 --> 01:44:58,350 nói về các ứng dụng hướng sự kiện. 2372 01:44:58,350 --> 01:45:00,300 >> Đây là một ví dụ về một dự án nội bộ 2373 01:45:00,300 --> 01:45:04,850 rằng chúng ta có nơi chúng tôi đang thực sự xuất bản để thu thập kết quả khảo sát. 2374 01:45:04,850 --> 01:45:07,700 Vì vậy, trong một liên kết email chúng tôi gửi đi, sẽ thấy có 2375 01:45:07,700 --> 01:45:11,350 là một cái nhấn chuột đơn liên kết nói ở đây để đối phó với các cuộc điều tra. 2376 01:45:11,350 --> 01:45:14,070 Và khi một người nhấp chuột liên kết đó, những gì sẽ xảy ra 2377 01:45:14,070 --> 01:45:18,020 là họ kéo xuống một an toàn Mẫu khảo sát HTML từ S3. 2378 01:45:18,020 --> 01:45:18,980 Không có máy chủ. 2379 01:45:18,980 --> 01:45:20,600 Đây chỉ là một đối tượng S3. 2380 01:45:20,600 --> 01:45:22,770 >> Hình thức mà đi lên, tải lên trong trình duyệt. 2381 01:45:22,770 --> 01:45:24,240 Nó có Backbone. 2382 01:45:24,240 --> 01:45:30,160 Nó có JavaScript phức tạp rằng nó đang chạy. 2383 01:45:30,160 --> 01:45:33,557 Vì vậy, nó là ứng dụng rất phong phú chạy trong trình duyệt của khách hàng. 2384 01:45:33,557 --> 01:45:36,390 Họ không biết rằng họ đang không tương tác với một máy chủ kết thúc trở lại. 2385 01:45:36,390 --> 01:45:38,220 Tại thời điểm này, đó là tất cả trình duyệt. 2386 01:45:38,220 --> 01:45:41,780 >> Họ công bố kết quả những gì chúng ta gọi là Amazon API Gateway. 2387 01:45:41,780 --> 01:45:46,270 API Gateway chỉ đơn giản là một API web mà bạn có thể xác định và treo lên 2388 01:45:46,270 --> 01:45:47,760 để bất cứ điều gì bạn muốn. 2389 01:45:47,760 --> 01:45:50,990 Trong trường hợp này, chúng tôi nối với một chức năng Lambda. 2390 01:45:50,990 --> 01:45:54,797 >> Vì vậy, hoạt động POST của tôi là xảy ra không có máy chủ. 2391 01:45:54,797 --> 01:45:56,380 Về cơ bản đó API Gateway ngồi ở đó. 2392 01:45:56,380 --> 01:45:58,770 Nó chi phí cho tôi không có gì cho đến khi người bắt đầu gửi bài cho nó, phải không? 2393 01:45:58,770 --> 01:46:00,269 Các chức năng Lambda chỉ ngồi ở đó. 2394 01:46:00,269 --> 01:46:03,760 Và chi phí cho đến khi tôi không có gì mọi người bắt đầu đánh nó. 2395 01:46:03,760 --> 01:46:07,270 Vì vậy, bạn có thể thấy, khối lượng tăng lên, đó là khi các chi phí đi kèm. 2396 01:46:07,270 --> 01:46:09,390 Tôi không chạy một máy chủ 7/24. 2397 01:46:09,390 --> 01:46:12,310 >> Vì vậy, tôi kéo các hình thức xuống ngoài những xô, 2398 01:46:12,310 --> 01:46:15,719 và tôi gửi thông qua các API Cổng vào hàm Lambda. 2399 01:46:15,719 --> 01:46:17,510 Và sau đó là Lambda chức năng cho biết, bạn biết 2400 01:46:17,510 --> 01:46:20,600 những gì, tôi đã có một số PIIs, một số thông tin cá nhân 2401 01:46:20,600 --> 01:46:21,480 trong các phản ứng. 2402 01:46:21,480 --> 01:46:23,020 Tôi có ý kiến ​​đến từ người sử dụng. 2403 01:46:23,020 --> 01:46:24,230 Tôi đã có địa chỉ email. 2404 01:46:24,230 --> 01:46:26,190 Tôi đã có tên người dùng. 2405 01:46:26,190 --> 01:46:27,810 >> Hãy để tôi chia này off. 2406 01:46:27,810 --> 01:46:30,280 Tôi sẽ tạo ra một số metadata tắt hồ sơ này. 2407 01:46:30,280 --> 01:46:32,850 Và tôi sẽ đẩy siêu dữ liệu vào DynamoDB. 2408 01:46:32,850 --> 01:46:36,059 Và tôi có thể mã hóa tất cả các dữ liệu và đẩy nó vào DynamoDB nếu tôi muốn. 2409 01:46:36,059 --> 01:46:38,600 Nhưng nó dễ dàng hơn cho tôi, trong này trường hợp sử dụng, để đi trước một tiếng nói, 2410 01:46:38,600 --> 01:46:42,800 Tôi sẽ đẩy các dữ liệu thô vào một xô S3 được mã hóa. 2411 01:46:42,800 --> 01:46:47,240 Vì vậy, tôi sử dụng được xây dựng trong S3 phía máy chủ mã hóa và quản lý chính của Amazon 2412 01:46:47,240 --> 01:46:51,600 Dịch vụ như vậy mà tôi có một khóa có thể xoay trên một khoảng thời gian thường xuyên, 2413 01:46:51,600 --> 01:46:55,010 và tôi có thể bảo vệ dữ liệu PII như là một phần của toàn bộ công việc này. 2414 01:46:55,010 --> 01:46:55,870 >> Vì vậy, tôi đã làm được những gì? 2415 01:46:55,870 --> 01:47:00,397 Tôi vừa mới triển khai toàn bộ ứng dụng, và tôi không có máy chủ. 2416 01:47:00,397 --> 01:47:02,980 Vì vậy, những gì là sự kiện định hướng ứng dụng kiến trúc nào cho bạn. 2417 01:47:02,980 --> 01:47:05,730 >> Bây giờ nếu bạn suy nghĩ về các trường hợp sử dụng cho this-- 2418 01:47:05,730 --> 01:47:08,730 chúng tôi có khách hàng khác mà tôi đang nói để về kiến ​​trúc này chính xác người 2419 01:47:08,730 --> 01:47:14,560 chạy các chiến dịch phi thường lớn, những người đang tìm kiếm tại đây và đi, oh của tôi. 2420 01:47:14,560 --> 01:47:17,840 Bởi vì bây giờ, họ có thể về cơ bản đẩy nó ra khỏi đó, 2421 01:47:17,840 --> 01:47:21,900 để cho chiến dịch đó chỉ cần ngồi đó cho đến khi nó ra mắt, và không 2422 01:47:21,900 --> 01:47:24,400 phải lo lắng về một vả loại cơ sở hạ tầng 2423 01:47:24,400 --> 01:47:26,120 là có được ở đó để hỗ trợ nó. 2424 01:47:26,120 --> 01:47:28,600 Và sau đó càng sớm càng chiến dịch đó được thực hiện, 2425 01:47:28,600 --> 01:47:31,520 nó giống như các cơ sở hạ tầng chỉ ngay lập tức biến mất 2426 01:47:31,520 --> 01:47:33,680 bởi vì có thực sự là không có cơ sở hạ tầng. 2427 01:47:33,680 --> 01:47:35,660 Nó chỉ là mã mà ngồi trên Lambda. 2428 01:47:35,660 --> 01:47:38,560 Nó chỉ là dữ liệu mà ngồi trong DynamoDB. 2429 01:47:38,560 --> 01:47:41,340 Đó là một cách tuyệt vời để xây dựng các ứng dụng. 2430 01:47:41,340 --> 01:47:43,970 >> Đung vậy là nó nhiều hơn phù du hơn nó sẽ là 2431 01:47:43,970 --> 01:47:45,740 nếu nó được lưu trữ trên một máy chủ thực sự? 2432 01:47:45,740 --> 01:47:46,823 >> RICK Houlihan: Tuyệt đối. 2433 01:47:46,823 --> 01:47:49,190 Bởi vì đó ví dụ máy chủ sẽ phải là một 7/24. 2434 01:47:49,190 --> 01:47:51,954 Nó có phải là có sẵn cho ai đó để đáp ứng. 2435 01:47:51,954 --> 01:47:52,620 Cũng đoán những gì? 2436 01:47:52,620 --> 01:47:55,410 S3 có sẵn 7/24. 2437 01:47:55,410 --> 01:47:57,100 S3 luôn đáp ứng. 2438 01:47:57,100 --> 01:47:59,320 Và S3 là rất, rất tốt ở phục vụ các đối tượng. 2439 01:47:59,320 --> 01:48:02,590 Những đối tượng có thể là các file HTML, hoặc Các tập tin JavaScript, hoặc bất cứ điều gì bạn muốn. 2440 01:48:02,590 --> 01:48:07,430 Bạn có thể chạy các ứng dụng web rất giàu ra của S3 xô, và người làm. 2441 01:48:07,430 --> 01:48:10,160 >> Và đó là những ý tưởng ở đây là để có được đi từ đường 2442 01:48:10,160 --> 01:48:11,270 chúng ta sử dụng để suy nghĩ về nó. 2443 01:48:11,270 --> 01:48:14,270 Tất cả chúng ta sử dụng để suy nghĩ về máy chủ và máy chủ. 2444 01:48:14,270 --> 01:48:16,580 Nó không phải về điều đó nữa. 2445 01:48:16,580 --> 01:48:19,310 Đó là về cơ sở hạ tầng như mã. 2446 01:48:19,310 --> 01:48:22,470 Triển khai các mã cho các đám mây và thả mây chạy nó cho bạn. 2447 01:48:22,470 --> 01:48:24,980 Và đó là những gì AWS đang cố gắng làm. 2448 01:48:24,980 --> 01:48:29,690 >> Đung Vì vậy, hộp vàng của bạn ở giữa của API Gateway không phải là máy chủ giống như, 2449 01:48:29,690 --> 01:48:30,576 nhưng thay vào đó là just-- 2450 01:48:30,576 --> 01:48:32,850 >> RICK Houlihan: Bạn có thể nghĩ của nó là server mặt tiền. 2451 01:48:32,850 --> 01:48:38,040 Tất cả đó là là nó sẽ mất một HTTP yêu cầu và bản đồ nó đến quá trình khác. 2452 01:48:38,040 --> 01:48:39,192 Đó là tất cả nó. 2453 01:48:39,192 --> 01:48:41,525 Và trong trường hợp này, chúng tôi đang lập bản đồ nó vào một hàm Lambda. 2454 01:48:41,525 --> 01:48:44,119 2455 01:48:44,119 --> 01:48:45,410 Được rồi, vì vậy đó là tất cả tôi nhận. 2456 01:48:45,410 --> 01:48:46,190 Cảm ơn nhiều. 2457 01:48:46,190 --> 01:48:46,800 Tôi đánh giá cao nó. 2458 01:48:46,800 --> 01:48:48,100 Tôi biết chúng tôi muốn có một chút thời gian. 2459 01:48:48,100 --> 01:48:49,980 Và hy vọng bạn guys có một chút thông tin 2460 01:48:49,980 --> 01:48:51,410 mà bạn có thể lấy đi ngày hôm nay. 2461 01:48:51,410 --> 01:48:53,520 Và tôi xin lỗi nếu tôi đã đi qua một số người đứng đầu của bạn, 2462 01:48:53,520 --> 01:48:56,697 nhưng có rất nhiều tốt đẹp của kiến thức nền tảng cơ bản 2463 01:48:56,697 --> 01:48:58,280 mà tôi nghĩ là rất có giá trị cho bạn. 2464 01:48:58,280 --> 01:48:59,825 Vì vậy, cảm ơn bạn đã mời tôi. 2465 01:48:59,825 --> 01:49:00,325 [Vỗ tay] 2466 01:49:00,325 --> 01:49:02,619 Đung [Không nghe thấy] là khi bạn đang nói 2467 01:49:02,619 --> 01:49:05,160 bạn đã phải trải qua những điều từ đầu đến cuối 2468 01:49:05,160 --> 01:49:07,619 để có được những giá trị đúng hoặc cùng một giá trị, 2469 01:49:07,619 --> 01:49:09,410 như thế nào sẽ các giá trị thay đổi nếu [không nghe được]. 2470 01:49:09,410 --> 01:49:10,480 >> RICK Houlihan: Oh, idempotent? 2471 01:49:10,480 --> 01:49:11,800 Làm thế nào các giá trị sẽ thay đổi? 2472 01:49:11,800 --> 01:49:15,180 Vâng, bởi vì nếu tôi không chạy nó tất cả các cách để kết thúc, 2473 01:49:15,180 --> 01:49:19,770 sau đó tôi không biết những gì thay đổi đã được thực hiện trong những dặm cuối cùng. 2474 01:49:19,770 --> 01:49:22,144 Nó sẽ không phải là cùng một dữ liệu như những gì tôi đã thấy. 2475 01:49:22,144 --> 01:49:24,560 Đung Oh, vì vậy bạn chỉ đã không nhận toàn bộ đầu vào. 2476 01:49:24,560 --> 01:49:24,770 RICK Houlihan: Đúng vậy. 2477 01:49:24,770 --> 01:49:26,895 Bạn phải đi từ đầu đến cuối, và sau đó nó 2478 01:49:26,895 --> 01:49:29,280 sẽ là một nhà nước thống nhất. 2479 01:49:29,280 --> 01:49:31,520 Mát. 2480 01:49:31,520 --> 01:49:35,907 >> Đung Vì vậy, bạn đã cho chúng tôi DynamoDB có thể làm tài liệu hoặc các giá trị quan trọng. 2481 01:49:35,907 --> 01:49:38,740 Và chúng tôi đã dành rất nhiều thời gian trên giá trị quan trọng với một băm và những cách 2482 01:49:38,740 --> 01:49:40,005 để lật nó xung quanh. 2483 01:49:40,005 --> 01:49:43,255 Khi bạn nhìn vào những bảng, đó là để lại đằng sau những phương pháp tiếp cận tài liệu? 2484 01:49:43,255 --> 01:49:44,600 >> RICK Houlihan: Tôi sẽ không nói để lại đằng sau nó. 2485 01:49:44,600 --> 01:49:45,855 >> Đung Họ đã được tách ra từ the-- 2486 01:49:45,855 --> 01:49:49,140 >> RICK Houlihan: Với các tài liệu phương pháp tiếp cận, các loại tài liệu DynamoDB 2487 01:49:49,140 --> 01:49:50,880 là chỉ nghĩ đến như là thuộc tính khác. 2488 01:49:50,880 --> 01:49:53,560 Đó là một thuộc tính có chứa một cấu trúc dữ liệu phân cấp. 2489 01:49:53,560 --> 01:49:56,980 Và sau đó trong các truy vấn, bạn có thể sử dụng các thuộc tính 2490 01:49:56,980 --> 01:49:59,480 của các đối tượng sử dụng Object Notation. 2491 01:49:59,480 --> 01:50:03,562 Vì vậy, tôi có thể lọc trên một lồng nhau tài sản của các tài liệu JSON. 2492 01:50:03,562 --> 01:50:05,520 Đung Vì vậy, bất kỳ thời gian tôi làm một phương pháp tài liệu, 2493 01:50:05,520 --> 01:50:07,906 Tôi có thể loại đến các tabular-- 2494 01:50:07,906 --> 01:50:08,780 Đung Tuyệt đối. 2495 01:50:08,780 --> 01:50:09,800 Đung --indexes và những điều bạn vừa nói đến. 2496 01:50:09,800 --> 01:50:11,280 RICK Houlihan: Yeah, chỉ số và tất cả đó, 2497 01:50:11,280 --> 01:50:13,363 khi bạn muốn chỉ mục tính chất của các JSON, 2498 01:50:13,363 --> 01:50:18,230 cách mà chúng tôi phải làm điều đó là nếu bạn chèn một đối tượng JSON hoặc một tài liệu 2499 01:50:18,230 --> 01:50:20,780 Dynamo vào, bạn sẽ sử dụng các dòng. 2500 01:50:20,780 --> 01:50:22,400 Streams sẽ đọc đầu vào. 2501 01:50:22,400 --> 01:50:24,340 Bạn muốn nhận được rằng JSON phản đối và bạn muốn nói OK, 2502 01:50:24,340 --> 01:50:26,030 các tài sản tôi muốn chỉ mục là gì? 2503 01:50:26,030 --> 01:50:28,717 >> Bạn tạo một bảng dẫn xuất. 2504 01:50:28,717 --> 01:50:30,300 Bây giờ đó là cách nó hoạt động ngay bây giờ. 2505 01:50:30,300 --> 01:50:32,650 Chúng tôi không cho phép bạn lên danh mục trực tiếp những tài sản. 2506 01:50:32,650 --> 01:50:33,520 >> Đung Tabularizing tài liệu của bạn. 2507 01:50:33,520 --> 01:50:36,230 >> RICK Houlihan: Chính xác, làm phẳng nó, tabularizing nó, chính xác. 2508 01:50:36,230 --> 01:50:37,415 Đó là những gì bạn làm với nó. 2509 01:50:37,415 --> 01:50:37,860 >> Đung Cảm ơn bạn. 2510 01:50:37,860 --> 01:50:39,609 >> RICK Houlihan: Yep, hoàn toàn, cảm ơn bạn. 2511 01:50:39,609 --> 01:50:42,240 Đung Vì vậy, nó là loại Mongo đáp ứng Redis classifers. 2512 01:50:42,240 --> 01:50:43,990 >> RICK Houlihan: Yeah, đó là rất nhiều như thế. 2513 01:50:43,990 --> 01:50:45,940 Đó là một mô tả tốt cho nó. 2514 01:50:45,940 --> 01:50:47,490 Mát. 2515 01:50:47,490 --> 01:50:49,102