[MUSIC CHƠI] RICK Houlihan: Tất cả các quyền. Chào mọi người. Tên tôi là Rick Houlihan. Tôi là một chính cao cấp các giải pháp kiến ​​trúc sư tại AWS. Tôi tập trung vào NoSQL và Công nghệ DynamoDB. 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. 

Nền của tôi là chủ yếu ở lớp dữ liệu. 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, truy cập dữ liệu, các giải pháp cho các ứng dụng khác nhau. Tôi đã ở trong đám mây ảo hóa trong khoảng 20 năm. 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. Và ý tưởng được, nó giống như PG & E, bạn phải trả cho những gì bạn sử dụng. Hôm nay chúng ta gọi nó là điện toán đám mây. 

Nhưng trong những năm qua, tôi đã làm việc cho một vài công ty có lẽ bạn đã không bao giờ nghe nói tới. 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. 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ý, xử lý sự kiện phức tạp, và các khu vực khác. 

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 cơ sở dữ liệu. 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ề. Vì vậy, những gì bạn có thể mong đợi từ phiên giao dịch này, chúng ta sẽ đi qua một cách ngắn gọn lịch sử của xử lý dữ liệu. Nó luôn luôn hữu ích để hiểu, nơi chúng tôi đến từ và lý do tại sao chúng tôi, nơi chúng tôi đang có. Và chúng ta sẽ nói một chút chút về công nghệ NoSQL từ một quan điểm cơ bản. 

Chúng tôi sẽ nhận được vào một số internals DynamoDB. DynamoDB là AWS của không có hương vị. Đó là một hoàn toàn quản lý và lưu trữ giải pháp NoSQL. 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, và một số các internals của công nghệ DynamoDB. 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. Chúng tôi sẽ nói về cách bạn sử dụng công nghệ này cho một số các ứng dụng ngày nay. 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 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 và làm thế nào DynamoDB đóng ở đó là tốt. 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 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. 

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ì. Rất nhiều người nghĩ rằng họ biết những gì một cơ sở dữ liệu là. Nếu bạn Google, bạn sẽ thấy điều này. Đó 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 có thể truy cập trong nhiều cách khác nhau. 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. Nhưng tôi không thích nó, bởi vì nó ngụ ý một vài điều. Nó bao hàm cấu trúc. Và nó ngụ ý rằng nó trên một máy tính. Và cơ sở dữ liệu không luôn tồn tại trên máy tính. Cơ sở dữ liệu thực sự tồn tại trong nhiều cách. 

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. Một cơ sở dữ liệu là một tổ chức cơ chế để lưu trữ, quản lý, và lấy thông tin. Đây là từ About.com. 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ữ, một kho lưu trữ của thông tin, không nhất thiết phải một cái gì đó mà ngồi trên một máy tính. Và trong suốt lịch sử, chúng ta không phải lúc nào có máy tính. 

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ì một cơ sở dữ liệu, đó là câu trả lời tôi nhận được. Một nơi nào đó tôi có thể dính thứ. Bên phải? Và đó là sự thật. Nhưng nó không may. 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. Nó là nền tảng của mỗi ứng dụng. 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 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. 

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ì xảy ra khi các nhà phát triển cách tiếp cận này và đối phó với hậu quả của một ứng dụng 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. Vì vậy, hy vọng khi bạn đi bộ ngày hôm nay, bạn sẽ có một vài công cụ trong vành đai của bạn mà sẽ giữ cho bạn từ làm cho những sai lầm tương tự. Được rồi. 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. Tôi nghĩ rằng tôi đọc một bài viết cách đây không lâu và nó nói cái gì đó trên lines-- đó là một tuyên bố rất thơ mộng. Nó nói lịch sử xử lý dữ liệu là đầy đủ các hình chìm cao dữ liệu phong phú. ĐƯỢC. Bây giờ, tôi đoán đó là loại đúng. Nhưng tôi thực sự nhìn vào là như lịch sử được thực sự đầy với watermark cao áp dữ liệu. Bởi vì tốc độ dữ liệu của ăn bao giờ đi xuống. Nó chỉ đi lên. 

Và đổi mới xảy ra khi chúng ta thấy áp lực dữ liệu, là số lượng dữ liệu đó là bây giờ trong đi vào hệ thống. Và nó không thể được xử lý hiệu quả hoặc trong thời gian hoặc trong chi phí. Và đó là khi chúng ta bắt đầu nhìn ở áp suất dữ liệu. 

Vì vậy, khi chúng ta nhìn vào cơ sở dữ liệu đầu tiên, điều này là một trong đó là giữa đôi tai của chúng tôi. Chúng tôi đều sinh ra với nó. Đó là một cơ sở dữ liệu tốt đẹp. Nó có tính sẵn sàng cao. Nó luôn luôn trên. Bạn luôn có thể có được nó. 

Nhưng đó là người dùng duy nhất. Tôi không thể chia sẻ những suy nghĩ của tôi với bạn. Bạn không thể có được những suy nghĩ của tôi khi bạn muốn họ. Và abilitiy của họ không phải là quá tốt. Chúng ta quên mất điều này. 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 và chúng ta mất tất cả mọi thứ đó là trong cơ sở dữ liệu đó. Vì vậy, đó không phải là tất cả những gì tốt. 

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 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 hoặc nơi mà chúng tôi thu thập các thực phẩm tốt nhất. 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 để đi vào được, và các doanh nghiệp bắt đầu phát triển, 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ì chúng ta có thể đặt ở đầu của chúng tôi. Được rồi? 

Chúng tôi cần các hệ thống hồ sơ. Chúng tôi cần nơi để có thể lưu trữ dữ liệu. 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ữ. Chúng tôi bắt đầu phát triển một hệ thống một kế toán sổ cái. Và rằng hệ thống sổ kế toán đếm chạy thế giới trong nhiều thế kỷ, và thậm chí có thể là thiên niên kỷ chúng tôi loại đã tăng đến điểm nơi mà tải dữ liệu vượt qua khả năng của các hệ thống để có thể chứa nó. 

Và điều này thực sự xảy ra trong những năm 1880. Bên phải? Trong Tổng điều tra năm 1880 của Mỹ. Đây thực sự là nơi quay chỉ xử lý dữ liệu hiện đại. Đây là điểm mà tại mà số lượng dữ liệu đó đã được thu thập bởi các Chính phủ Mỹ đã đến điểm nơi mà nó mất tám năm để xử lý. 

Bây giờ, tám years-- như Bạn có biết, cuộc điều tra chạy mỗi 10 years-- vì vậy nó khá rõ ràng, theo thời gian chúng tôi đã điều tra dân số năm 1890, số lượng dữ liệu mà được sẽ được xử lý bởi chính phủ là sẽ vượt quá 10 năm mà nó sẽ có được để đưa ra điều tra dân số mới. Đây là một vấn đề. 

Vì vậy, một người tên là Herman Hollerith đến cùng và ông đã phát minh đơn vị lục đục lỗ thẻ, đầu đọc thẻ đục lỗ, thẻ đục lỗ lập bảng, và collation của các cơ chế cho công nghệ này. 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, 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. 

Vì vậy, IBM ban đầu là trong kinh doanh cơ sở dữ liệu. Và đó thực sự là những gì họ đã làm. Họ đã xử lý dữ liệu. 

Như vậy sự gia tăng của cú đấm thẻ, một cơ chế tài tình 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. Bạn có thể nhìn thấy trong ảnh này chúng tôi đã có một little-- đó 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 nơi chúng tôi có một boong thẻ đục lỗ. Và lấy của ai đó một chút screwdriver và gắn bó qua khe và nâng nó lên để có được trận đấu đó, mà kết quả sắp xếp đặt. 

Đây là một tập hợp. Chúng tôi làm tất cả thời gian ngày hôm nay trong máy tính, nơi bạn làm điều đó trong cơ sở dữ liệu. Chúng tôi sử dụng để làm điều đó bằng tay, phải không? Người ta đặt những thứ cùng nhau. Và đó là sự gia tăng các thẻ đục lỗ 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. 

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. Chơi đàn piano lại Bước sang thế kỷ sử dụng để sử dụng cuộn giấy với khe trên để cho biết các phím để chơi. Vì vậy, công nghệ đã được chuyển thể cuối cùng để lưu trữ dữ liệu kỹ thuật số, bởi vì họ có thể đưa dữ liệu vào những cuộn băng giấy. 

Bây giờ, kết quả là, dữ liệu được actually-- như thế nào 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ó. 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. Tôi đã phải tung toàn bộ băng để truy cập tất cả các dữ liệu. Nếu tôi đưa dữ liệu trong cú đấm thẻ, tôi có thể truy cập nó 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. 

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ữ. Và do đó, đây là một vấn đề đi sâu vào những năm 50. 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ý các dữ liệu, phải, nó mở ra cửa cho giải pháp mới, cho các chương trình mới, mới ứng dụng cho dữ liệu đó. Và thực sự, quản trị có thể có được lý do lý do tại sao chúng tôi phát triển một số các hệ thống này. Nhưng kinh doanh trở nên nhanh chóng người lái xe phía sau tiến hóa của cơ sở dữ liệu hiện đại và các hệ thống tập tin hiện đại. 

Vì vậy, điều tiếp theo mà đã đưa ra là vào những năm 50 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. Điều này thật là đẹp. 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 và chúng ta có thể truy cập dữ liệu ngẫu nhiên. Chúng ta có thể phân tích rằng thông tin ra các tập tin. 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. 

Và kéo dài khoảng 20 hoặc 30 năm cho đến khi sự tiến hóa 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ờ 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 hệ thống mà chúng tôi đã xây dựng. Bên phải? Quá nhiều dữ liệu phân tán trong quá nhiều nơi, de-sao chép dữ liệu, và chi phí lưu trữ là rất lớn. 

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ữ. Các bộ xử lý được xem như là một chi phí cố định. Khi tôi mua hộp, CPU làm một số công việc. Nó sẽ được quay liệu nó thực sự làm việc hay không. Đó thực sự là một chi phí chìm. 

Nhưng những gì chi phí cho tôi như một kinh doanh là lưu trữ. 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ả. Và lưu trữ đó là đắt tiền. 

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. Các tính toán bây giờ là tài nguyên đắt tiền nhất. Việc lưu trữ là rẻ. 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ẻ. Nhưng tính giá rẻ những gì tôi không thể tìm thấy được. 

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, đang thực sự tập trung xung quanh cơ sở dữ liệu phân tán mà không bị cùng một loại quy mô hạn chế của cơ sở dữ liệu quan hệ. Chúng tôi sẽ nói một chút về những gì mà thực sự có nghĩa. 

Nhưng một trong những lý do và người lái xe phía sau this-- chúng tôi nói về áp lực dữ liệu. Áp lực dữ liệu là một cái gì đó mà các ổ đĩa sự đổi mới. Và nếu bạn nhìn qua năm năm qua, đâ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 trông giống như trong năm năm qua. 

Và quy luật chung của ngón tay những days-- nếu bạn đi Google-- là 90% dữ liệu mà chúng tôi lưu trữ ngày hôm nay, và nó đã được được tạo ra trong vòng hai năm qua. ĐƯỢC. Bây giờ, đây không phải là một xu hướng mới. Đây là một xu hướng đó là được đi ra ngoài trong 100 năm. Kể từ khi Herman Hollerith phát triển các thẻ đục lỗ, 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. 

Vì vậy, trong vòng 100 năm qua, chúng tôi đã nhìn thấy xu hướng này. Điều đó sẽ không thay đổi. 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. Và bạn có thể xem những gì mà trông như thế nào. 

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ý, ngày nay có nghĩa là họ đang quản lý 6,5 petabyte dữ liệu. Đó là 6.500 dữ liệu nhiều lần. Và tôi biết điều này. Tôi làm việc với các doanh nghiệp mỗi ngày. Năm năm trước đây, tôi sẽ nói chuyện với các công ty 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. Và họ sẽ nói chuyện với tôi về cách chúng ta nhìn rằng điều này có lẽ sẽ là một petabyte hoặc hai trong vòng một vài năm. 

Các công ty cùng Hôm nay tôi gặp gỡ, và họ đang nói chuyện với tôi về vấn đề đang có việc quản lý hàng chục, 20 petabyte dữ liệu. Vì vậy, sự bùng nổ của dữ liệu trong ngành công nghiệp là lái xe rất lớn cần giải pháp tốt hơn. Và các cơ sở dữ liệu quan hệ là chỉ là không sống theo nhu cầu. 

Và do đó, có một tuyến tính tương quan giữa áp suất dữ liệu và đổi mới kỹ thuật. Lịch sử đã chỉ cho chúng ta này, mà theo thời gian, bất cứ khi nào khối lượng dữ liệu mà cần phải được xử lý vượt quá khả năng của hệ thống để xử lý nó trong một thời gian hợp lý hoặc tại một chi phí hợp lý, công nghệ sau đó mới được phát minh ra để giải quyết những vấn đề đó. Những công nghệ mới, đến lượt nó, mở cửa đến một loạt vấn đề, trong đó là thu thập dữ liệu nhiều hơn. 

Bây giờ, chúng tôi sẽ không để ngăn chặn điều này. Bên phải? Chúng tôi sẽ không để ngăn chặn điều này. Tại sao? Bởi vì bạn không thể biết tất cả mọi thứ có biết trong vũ trụ. Và miễn là chúng tôi đã được sống, trong suốt lịch sử loài người, chúng tôi đã luôn luôn hướng để biết thêm. 

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, 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 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, khoảng cách vũ trụ hoạt động, về lái xe các khám phá khoa học, và các sáng chế chúng ta đang làm hôm nay. Khối lượng dữ liệu chỉ liên tục tăng. Vì vậy, việc có thể để đối phó với vấn đề này là rất lớn. 

Vì vậy, một trong những điều chúng ta nhìn như tại sao NoSQL? Làm thế nào để giải quyết vấn đề này NoSQL? Vâng, cơ sở dữ liệu quan hệ, Structured Query Language, SQL-- đó là thực sự là một cấu trúc của quan hệ database-- những điều này là tối ưu hóa cho việc lưu trữ. 

Trở lại những năm 70, một lần nữa, đĩa là tốn kém. 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. Tôi biết. Tôi sống nó. Tôi đã viết trình điều khiển lưu trữ cho một Công ty SuperServer enterprised trở lại trong những năm 90. Và dòng dưới cùng là kệ khác mảng lưu trữ chỉ là một cái gì đó xảy ra mỗi ngày trong các doanh nghiệp. Và nó không bao giờ dừng lại. Lưu trữ mật độ cao hơn, nhu cầu cho lưu trữ mật độ cao, và cho lưu trữ hiệu quả hơn devices-- nó không bao giờ dừng lại. 

Và NoSQL là một công nghệ tuyệt vời vì nó bình thường hóa dữ liệu. Nó de-trùng lặp dữ liệu. 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. 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, 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ọ. Đó là âm thanh tuyệt vời. 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ứ, nó được tối ưu hóa cho không có gì. ĐƯỢC? 

Và đó là những gì chúng tôi nhận được với cơ sở dữ liệu quan hệ. Nó được tối ưu hóa cho việc lưu trữ. Đó là bình thường. Đó là quan hệ. Nó hỗ trợ các truy vấn quảng cáo hoc. Và nó và nó quy mô theo chiều dọc. 

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, Tôi đi mua một mảnh lớn của sắt. ĐƯỢC? 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 cơ sở hạ tầng của họ chỉ SQL để tìm ra sáu tháng sau, họ nhấn tường một lần nữa. 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. 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ự. Chúng tôi cần phải thực sự thay đổi mọi thứ. Vì vậy, nơi làm việc này? Nó hoạt động tốt cho ẩn phân tích, OLAP loại khối lượng công việc. Và đó thực sự là nơi thuộc về SQL. 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 các ứng dụng. Và nó làm việc tốt tại một số mức độ sử dụng, nhưng nó chỉ không quy mô cách mà NoSQL không. Và chúng ta sẽ nói một chút chút về lý do tại sao đó là. 

Bây giờ, NoSQL, mặt khác, được tối ưu hơn cho tính toán. ĐƯỢC? Nó không phải là bất khả tri đến các mô hình truy cập. 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. Các dữ liệu trong cơ sở dữ liệu quan hệ là nối với nhau từ nhiều bảng để sản xuất các điểm mà bạn cần. 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 chứa các cấu trúc phân cấp. 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 được lưu trữ trong một tài liệu duy nhất. 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. 

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. ĐƯỢC? Bạn có quy mô theo chiều ngang. Bên phải? Nếu tôi cần phải tăng kích thước của cụm NoSQL của tôi, Tôi không cần phải nhận được một hộp lớn hơn. Tôi nhận được một hộp khác. Và tôi tụ họp những người với nhau, và tôi có thể Shard dữ liệu đó. Chúng tôi sẽ nói một chút về sharding là gì, để được thể quy mô cơ sở dữ liệu trên nhiều thiết bị vật lý 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. 

Vì vậy, nó thực sự xây dựng cho online xử lý giao dịch và quy mô. Có một sự khác biệt lớn đây giữa báo cáo, phải không? Báo cáo, tôi không biết câu hỏi tôi sẽ hỏi. Bên phải? Reporting-- nếu một người nào đó từ bộ phận tiếp thị của tôi 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 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. Vì vậy, tôi cần phải được thuyết bất khả tri. 

Bây giờ, trong một trực tuyến ứng dụng giao dịch, Tôi biết những câu hỏi tôi hỏi. Tôi xây dựng các ứng dụng cho một công việc rất cụ thể. ĐƯỢC? Vì vậy, nếu tôi tối ưu hóa dữ liệu lưu trữ để hỗ trợ công việc đó, nó sẽ được nhanh hơn. Và đó là lý do tại sao NoSQL thể thực sự đẩy nhanh tiến độ giao hàng những loại hình dịch vụ. Được rồi. 

Vì vậy, chúng ta sẽ nhận được vào một chút về lý thuyết ở đây. 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. Nhưng tôi sẽ cố gắng để giữ cho nó mức cao nhất có thể. Vì vậy, nếu bạn đang ở trong dự án quản lý, có một cấu trúc được gọi là tam giác của sự ràng buộc. ĐƯỢC. 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. Không thể có chiếc bánh của bạn và ăn nó quá. Vì vậy, trong quản lý dự án, mà tam hạn chế là bạn có thể có nó rẻ, bạn có thể có nó nhanh, hoặc bạn có thể có nó tốt. Chọn hai. Bởi vì bạn không thể có tất cả ba. Bên phải? ĐƯỢC. 

Vì vậy, bạn nghe về điều này rất nhiều. Đó là một hạn chế ba, tam giác của sự ràng buộc ba, 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, họ sẽ nói về điều này. Bây giờ, cơ sở dữ liệu có tam giác sắt của riêng mình. Và tam giác sắt của dữ liệu là những gì chúng ta gọi là định lý CAP. ĐƯỢC? 

CAP mệnh lệnh lý cơ sở dữ liệu hoạt động như thế nào theo một điều kiện rất cụ thể. Và chúng ta sẽ nói về những điều kiện đó là. Nhưng ba điểm của tam giác, có thể nói, là C, nhất quán. ĐƯỢC? 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 sẽ luôn luôn có một rất điểm nhất quán của dữ liệu. Sẽ không ai xem hai việc khác nhau. ĐƯỢC? Nếu tôi thấy các cơ sở dữ liệu, Tôi thấy quan điểm tương tự là đối tác của tôi đã thấy cơ sở dữ liệu tương tự. Đó là nhất quán. 

Sẵn có nghĩa là nếu cơ sở dữ liệu trực tuyến, nếu nó có thể đạt được, rằng tất cả các khách hàng sẽ luôn luôn có khả năng đọc và viết. ĐƯỢC? Vì vậy, mỗi khách hàng mà có thể đọc các cơ sở dữ liệu sẽ luôn có thể đọc dữ liệu và ghi dữ liệu. Và nếu đó là trường hợp, nó là một hệ thống có sẵn. 

Và điểm thứ ba là những gì chúng ta gọi là khoan dung phân vùng. ĐƯỢC? Phương tiện khoan dung phân vùng rằng hệ thống hoạt động tốt mặc dù mạng vật lý phân vùng giữa các nút. ĐƯỢC? 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? Được rồi. 

Vì vậy, cơ sở dữ liệu quan hệ choose-- bạn có thể chọn hai trong số này. ĐƯỢC. Vì vậy, cơ sở dữ liệu quan hệ chọn để phù hợp và có sẵn. Nếu phân vùng xảy ra giữa các DataNodes trong các cửa hàng dữ liệu, cơ sở dữ liệu bị lỗi. Bên phải? Nó chỉ đi xuống. ĐƯỢC. 

Và đây là lý do tại sao họ có để phát triển với hộp lớn hơn. Bên phải? 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ọ hoạt động theo cách đó. 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. Bởi vì họ cần phải được phù hợp và có sẵn. 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. 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. 

Và đó là những gì cơ sở dữ liệu NoSQL làm. Được rồi. Vì vậy, một cơ sở dữ liệu NoSQL, nó có hai hương vị. Chúng tôi have-- tốt, nó đi kèm trong nhiều hương vị, nhưng nó đi kèm với hai cơ bản characteristics-- gì 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 hệ thống. 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, chúng tôi sẽ không cho phép người để viết nữa. ĐƯỢC? 

Cho đến phân vùng đó được lấy ra, truy cập ghi bị chặn. Điều đó có nghĩa là họ không có sẵn. Họ là phù hợp. Khi chúng ta thấy rằng phân vùng tiêm chính nó, bây giờ chúng tôi là phù hợp, bởi vì chúng tôi sẽ không để cho phép thay đổi dữ liệu trên hai bên của phân vùng độc lập của nhau. Chúng tôi sẽ phải tái lập truyền thông trước khi bất kỳ bản cập nhật để các dữ liệu cho phép. ĐƯỢC? 

Hương vị tiếp theo sẽ là một hệ thống AP, hoặc có sẵn và phân hệ thống khoan dung. Những anh chàng không quan tâm. Bên phải? Bất kỳ nút mà được một viết, chúng ta sẽ lấy nó. Vì vậy, tôi đang sao chép dữ liệu của tôi qua nhiều nút. 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. Node nói, không có vấn đề. Các nút bên cạnh anh ta được một ghi trên cùng một kỷ lục, anh ta sẽ nói không có vấn đề. Một nơi nào đó lại trở lại vào cuối, dữ liệu đó sẽ nhân rộng. Và sau đó một người nào đó sẽ nhận ra, uh-oh, hệ thống họ sẽ nhận ra, uh-oh, đã có một sự cập nhật cho hai bên. Chúng ta làm gì? Và những gì họ làm sau đó là họ làm điều gì đó cho phép họ để giải quyết trạng thái dữ liệu. Và chúng ta sẽ nói về rằng trong biểu đồ tiếp theo. 

Điều cần chỉ ra ở đây. Và tôi sẽ không nhận được quá nhiều vào điều này, bởi vì đây được vào dữ liệu lý thuyết sâu sắc. Nhưng có một giao dịch khuôn khổ đó 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 đến nhiều đối tượng trong cơ sở dữ liệu. 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ả. Và điều này được gọi là các giao dịch ACID. ĐƯỢC? 

ACID cho chúng ta nguyên tử, tính thống nhất, cô lập, và độ bền. ĐƯỢC? Đ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. Tính nhất quán có nghĩa là cơ sở dữ liệu sẽ luôn luôn được đưa vào một cách nhất quán nhà nước sau khi cập nhật. 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. ĐƯỢC? 

Vì vậy, đó là một chút khác nhau hơn CAP nhất quán. 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. 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. Mối quan hệ của tôi là tất cả tốt. 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 trong một số bảng khác. Nó không thể xảy ra nếu tôi là phù hợp trong một giao dịch axit. 

Cách ly có nghĩa là giao dịch sẽ luôn luôn xảy ra sau khi một khác. Kết quả cuối cùng của dữ liệu sẽ là bang cùng như thể những giao dịch đã được ban hành đồng thời đã được thực hiện tuần tự. Vì vậy, nó đồng thời kiểm soát trong cơ sở dữ liệu. 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. 

Nhưng nếu tôi nói thêm 1 giá trị này, và hai giao dịch đi vào và cố gắng để làm điều đó, một là đi đến đó đầu tiên và một trong những khác của đi đến đó sau. Vì vậy, cuối cùng, tôi bổ sung thêm hai. Bạn thấy những gì tôi có ý nghĩa? ĐƯỢC. 

Độ bền là khá đơn giản. Khi giao dịch được thừa nhận, đó là sẽ có ngay nếu hệ thống bị treo. Khi hệ thống mà phục hồi, mà giao dịch đã được cam kết là thực sự đang có mặt ở đó. Vì vậy, đó là những bảo đảm các giao dịch ACID. Đó là những đảm bảo khá tốt đẹp có trên một cơ sở dữ liệu, nhưng họ đến lúc chi phí đó. Bên phải? 

Bởi vì vấn đề với khuôn khổ này là 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. Tôi sẽ phải cho phép cập nhật về mặt này hay mặt khác. Và nếu điều đó xảy ra, sau đó tôi không còn đi để có thể duy trì những đặc điểm. Họ sẽ không được nhất quán. Họ sẽ không bị cô lập. Đây là nơi mà nó phá vỡ cho cơ sở dữ liệu quan hệ. Đây là lý do quan hệ cơ sở dữ liệu quy mô theo chiều dọc. 

Mặt khác, chúng ta có những gì được gọi là công nghệ BASE. Và đây là những cơ sở dữ liệu NoSQL của bạn. Được rồi. Vì vậy, chúng tôi có CP của chúng tôi, cơ sở dữ liệu AP. 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 phù hợp. ĐƯỢC? 

Về cơ bản có sẵn, vì họ phân vùng chịu. Họ sẽ luôn luôn được ở đó, thậm chí nếu có một phân vùng mạng giữa các nút. 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. ĐƯỢC? 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. Nhưng tôi sẽ có thể đọc dữ liệu. 

Các trạng thái mềm chỉ mà khi tôi đọc dữ liệu, nó có thể không được giống như các nút khác. Nếu quyền đã được ban hành trên một nút ở một nơi khác trong cluster và nó đã không được nhân rộng trên toàn cụm nhưng khi tôi đọc dữ liệu đó, trạng thái đó có thể không phù hợp. Tuy nhiên, nó sẽ được cuối cùng nhất quán, có nghĩa là khi một viết được thực hiện cho hệ thống, nó sẽ nhân rộng khắp các nút. Và cuối cùng, trạng thái đó sẽ được đưa vào nền nếp, và nó sẽ là một nhà nước thống nhất. 

Bây giờ, định lý CAP thực sự lượt chỉ với một điều kiện. Tình trạng đó là khi điều này xảy ra. 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, mọi thứ đều phù hợp và có sẵn. Bạn chỉ lo lắng về CAP khi chúng tôi có phân vùng đó. Vì vậy, những người rất hiếm. 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ệ chúng tôi đang xử lý. 

Vì vậy, chúng ta hãy nhìn vào những gì mà hình như cho hệ thống AP. ĐƯỢC? Hệ thống AP đến trong hai mùi vị. 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. Và họ đi vào các hương vị khác, trong đó nói rằng, bạn biết không, tôi sẽ lo lắng về điều phân vùng này khi một phân vùng thực sự xảy ra. Nếu không, có sẽ là chính hạch người sẽ mất quyền lợi. ĐƯỢC? 

Vì vậy, nếu chúng ta một cái gì đó giống như Cassandra. 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. Vì vậy, những gì sẽ xảy ra? 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. Hãy gọi đó là đối tượng S. Vì vậy, chúng ta có nhà nước cho S. Chúng tôi có một số hoạt động trên S mà đang được tiến hành. Cassandra cho phép tôi viết thư cho nhiều nút. Vì vậy, hãy nói rằng tôi có được một viết cho s để hai nút. 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. Có thể không có một phân vùng mạng vật lý. Nhưng vì những thiết kế của hệ thống, đó là thực sự phân vùng ngay khi tôi nhận được một ghi trên hai nút. Nó không buộc tôi phải viết tất cả thông qua một nút. Tôi đang viết về hai nút. ĐƯỢC? 

Vì vậy, bây giờ tôi có hai trạng thái. ĐƯỢC? Điều gì sẽ xảy ra là sớm hay muộn, có sẽ là một sự kiện nhân rộng. 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à là nơi mà hai bang quay về bên nhau và có sẽ là một thuật toán chạy bên trong cơ sở dữ liệu, quyết định phải làm gì. ĐƯỢC? 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. Vì vậy, có thường là một thuật toán mặc định, những gì họ gọi một cuộc gọi lại chức năng, một cái gì đó 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 để giải quyết cuộc xung đột đó. ĐƯỢC? 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 là, đoán những gì, dấu thời gian thắng. Đây là bản cập nhật cuối cùng. Tôi sẽ đặt bản cập nhật mà ở trong đó. Tôi có thể đổ kỷ lục này mà tôi đổ ra thành một bản ghi phục hồi do đó người dùng có thể quay lại sau và nói, hey, đã có một vụ va chạm. Chuyện gì đã xảy ra? Và bạn thực sự có thể đổ một kỷ lục tất cả các va chạm và rollbacks và xem những gì sẽ xảy ra. 

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 đó. Vì vậy, bạn có thể thay đổi điều đó hoạt động gọi lại. Bạn có thể nói, hey, tôi muốn để khắc phục các dữ liệu này. Và tôi muốn thử và hợp hai hồ sơ. Nhưng đó là tùy thuộc vào bạn. 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, điều duy nhất cơ sở dữ liệu hiểu biết làm thế nào để làm được nói, đây là một trong những kỷ lục mới. Đó là một trong đó là sẽ giành chiến thắng, và đó là giá trị tôi sẽ đưa. Khi đã phục hồi phân vùng và sao chép xảy ra, chúng tôi có nhà nước của chúng tôi, bây giờ là S nguyên tố, đó là trạng thái hợp nhất của tất cả các đối tượng. Vì vậy, hệ thống AP có này. Hệ thống CP không cần phải lo lắng về điều này. 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 viết. ĐƯỢC? Vì vậy, đó là rất dễ dàng để đối phó với sự kiên định khi bạn không chấp nhận bất kỳ bản cập nhật. Đó là với các hệ thống CP làm. Được rồi. 

Vì vậy, chúng ta hãy nói một chút chút về mô hình truy cập. Khi chúng ta nói về NoSQL, nó tất cả về cách thức truy cập. Bây giờ, SQL là ad hoc, các truy vấn. Đó là cửa hàng quan hệ. Chúng tôi không phải lo lắng về cách thức truy cập. Tôi viết một truy vấn rất phức tạp. Nó đi và nhận dữ liệu. Đó là những gì điều này có vẻ như thế, bình thường hóa. 

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. Tôi có các loại khác nhau của sản phẩm. Tôi có cuốn sách. Tôi có album. Tôi có video. 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, và video bàn là 1: 1. Được rồi? Tôi đã có một sản phẩm ID, và ID tương ứng để một cuốn sách, một album, hoặc một video. ĐƯỢC? Đó là một 1: mối quan hệ 1 qua những bảng. 

Bây giờ, tất cả họ books-- có là thuộc tính gốc. Không sao. Thật tuyệt. 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 đó. Album Albums-- có bài hát. Đây là những gì chúng ta gọi một đến nhiều. Mỗi album có thể có nhiều bài hát. Vì vậy, đối với mỗi ca khúc trên album, tôi có thể có một bản ghi trong bảng con này. Vì vậy, tôi tạo ra một bản ghi trong bảng album của tôi. Tôi tạo ra nhiều hồ sơ trong bảng bài hát. One-to-nhiều mối quan hệ. 

Mối quan hệ này là gì chúng tôi kêu gọi nhiều-nhiều. ĐƯỢC? Bạn thấy rằng các diễn viên có thể trong nhiều bộ phim, nhiều video. 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ỉ bản đồ các diễn viên ID để ID video. 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, 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 những người trong bộ phim đó. 

ĐƯỢC. Vì vậy, ở đây chúng tôi đi. One-to-one là cấp cao nhất mối quan hệ; one-to-many, album để theo dõi; nhiều-nhiều. Đó là ba cấp cao mối quan hệ trong bất kỳ cơ sở dữ liệu. 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, sau đó bạn biết rất nhiều về cơ sở dữ liệu đã. Vì vậy, NoSQL hoạt động hơi khác. 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. 

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 trên một danh sách của tất cả các sản phẩm của tôi. Đó là rất nhiều các câu truy vấn. Tôi có một truy vấn cho tất cả các cuốn sách của tôi. Tôi có một truy vấn từ các album của tôi. Và tôi có một truy vấn cho tất cả các video của tôi. Và tôi đã đặt nó tất cả cùng nhau trong một danh sách và phục vụ trở lại cho đến ứng dụng đó là yêu cầu nó. 

Để có được cuốn sách của tôi, tôi tham gia Sản phẩm và Sách. Để có được album của tôi, tôi đã tham gia Sản phẩm, Albums, và Tracks. Và để có được đoạn video của tôi, tôi có để tham gia Sản phẩm Videos, Nam diễn viên tham gia qua Videos, và mang lại những diễn viên. Vì vậy, đó là ba câu truy vấn. Truy vấn rất phức tạp để lắp ráp một tập hợp kết quả. 

Đó là ít hơn tối ưu. Đây là lý do tại sao khi chúng ta nói về một cấu trúc dữ liệu đó 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. 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. Và bạn biết những gì? Tôi chỉ có một bản ghi cho một diễn viên. 

Đó là mát mẻ. 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 trong bảng vẽ bản đồ này. Tuy nhiên, nhận được dữ liệu ra trở nên đắt đỏ. 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 để có thể kéo mà lại dữ liệu. 

Vì vậy, làm thế nào để tôi nhận được xung quanh đó? Trong NoSQL nó về tập hợp, không bình thường. 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. Nếu các mô hình truy cập đến các ứng dụng, Tôi cần để có được tất cả các sản phẩm của tôi. Hãy đặt tất cả các sản phẩm trong một bảng. 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 từ bảng đó và tôi có tất cả. Vâng làm thế nào để làm điều đó? Cũng trong NoSQL không có cấu trúc để bàn. Chúng tôi sẽ nói một chút về cách làm việc này trong Dynamo DB. 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ự 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. Và những gì này cho phép tôi làm là rất nhiều thứ và cung cấp cho tôi rất nhiều tính linh hoạt. 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. Và đặc biệt này Ví dụ, tất cả mọi thứ là một tài liệu trong bảng Products. 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. Và các ứng dụng sẽ chuyển vào ID đó. 

Tại tầng ứng dụng, tôi sẽ nói oh, những gì ghi lại kiểu gì đây? Oh, đó là một kỷ lục cuốn sách. Hồ sơ Book có các đặc tính này. Hãy để tôi tạo một đối tượng cuốn sách. Vì vậy, tôi sẽ lấp đầy đối tượng cuốn sách với mặt hàng này. Tiếp đến mục và nói, mặt hàng này là những gì? Vâng item này là một album. Oh, tôi có một toàn bộ khác nhau xử lý thường xuyên cho rằng, bởi vì nó là một album. Bạn thấy những gì tôi có ý nghĩa? 

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. Tất cả họ đều bắt đầu đến nhập. Họ có thể là tất cả các loại khác nhau. Và đó là logic của ứng dụng mà chuyển qua những loại và quyết định làm thế nào để xử lý chúng. 

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. Chúng tôi đang làm điều đó bằng cách sụp đổ những bảng. Chúng tôi về cơ bản việc các cấu trúc bình thường, và chúng tôi đang xây dựng cấu trúc phân cấp. 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. 

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. Những bài hát hiện nay become-- nó về cơ bản bảng con này mà tồn tại ngay trong cấu trúc này. Vì vậy, bạn có thể làm điều này trong DynamoDB. Bạn có thể làm điều này trong MongoDB. Bạn có thể làm điều này trong bất kỳ cơ sở dữ liệu NoSQL. Tạo các loại cấu trúc dữ liệu có thứ bậc mà cho phép bạn lấy dữ liệu rất nhanh chóng bởi vì bây giờ tôi không cần phải tuân theo. 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, Tôi phải phù hợp với lược đồ. 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 đó. Mỗi một trong số họ, khi tôi chèn hàng đó. Đó không phải là trường hợp trong NoSQL. 

Tôi có thể có hoàn toàn khác nhau tài sản trong mỗi tài liệu rằng tôi chèn vào bộ sưu tập. Vì vậy, cơ chế rất mạnh mẽ. Và nó thực sự làm thế nào bạn tối ưu hóa hệ thống. Bởi vì bây giờ mà truy vấn, thay vì trong việc tham gia tất cả các bảng 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, Tôi đang thực hiện một truy vấn. Và tôi lặp qua kết quả thiết lập. nó cung cấp cho bạn một ý tưởng về sức mạnh của NoSQL. Tôi sẽ loại đi ngang đây và nói một chút về điều này. Đây là loại nhiều tiếp thị hoặc technology-- tiếp thị của công nghệ loại của cuộc thảo luận. Nhưng điều quan trọng là phải hiểu bởi vì nếu chúng ta nhìn ở đầu ở đây vào biểu đồ này, những gì chúng tôi đang tìm kiếm tại là những gì chúng ta gọi là đường cong cường điệu nghệ. Và điều này có nghĩa là công cụ mới đến chơi. Mọi người nghĩ rằng nó rất lớn. Tôi đã giải quyết tất cả các vấn đề của tôi. 

Điều này có thể là dấu chấm hết tất cả, là tất cả mọi thứ. Và họ bắt đầu sử dụng nó. Và họ nói, công cụ này không hoạt động. Điều này không đúng. Các cụ già là tốt hơn. Và họ trở lại làm mọi thứ theo cách họ. Và sau đó cuối cùng họ đi, bạn biết những gì? Công cụ này không phải là quá xấu. Oh, đó là cách nó hoạt động. 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. 

Và điều buồn cười về nó là, nó loại đường lên đến những gì chúng ta gọi Curve Công nghệ nhận con nuôi. 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. Trong trường hợp cơ sở dữ liệu, đó là áp lực dữ liệu. 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. 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ệ. 

Nó nhận được quá đắt. Phải mất quá nhiều thời gian để xử lý dữ liệu. Chúng ta cần một cái gì đó tốt hơn. Bạn sẽ có được những nhà cải cách ra có chạy xung quanh, cố gắng để tìm ra giải pháp là gì. Ý tưởng mới là gì? 

Những gì là tốt nhất tiếp theo cách để làm điều này? Và họ đến với cái gì. Và những người có nỗi đau thực sự, các chàng trai ở cạnh chảy máu, họ sẽ nhảy trên tất cả nó, bởi vì họ cần một câu trả lời. Bây giờ những gì chắc chắn và happens-- nó đang xảy ra ngay bây giờ trong NoSQL. Tôi nhìn thấy tất cả các thời gian. 

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 giống như cách họ sử dụng các công cụ cũ. Và họ phát hiện ra nó không làm việc rất tốt. Tôi không thể nhớ tôi là ai nói chuyện với đầu ngày hôm nay. Nhưng nó giống như, khi cái búa khoan được phát minh, người không xoay nó qua đầu của mình để đập vỡ bê tông. 

Nhưng đó là những gì xảy ra với NoSQL ngày hôm nay. 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. Những gì họ đang làm là họ đang sử dụng NoSQL, và họ đang tải nó đầy đủ các lược đồ quan hệ. Bởi vì đó là cách họ thiết kế cơ sở dữ liệu. Và họ đang tự hỏi, tại sao nó không vận hành rất tốt? Boy, điều này stinks. Tôi đã phải duy trì tất cả của tôi tham gia in-- nó giống như, không, không. Duy trì tham gia? Tại sao các bạn gia nhập dữ liệu? Bạn không gia nhập dữ liệu trong NoSQL. Bạn tổng hợp nó. 

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ự bắt đầu sử dụng nó. Đừ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ũ. Bạn sẽ có một kinh nghiệm xấu. Và mỗi lần duy nhất đó là những gì này là về. Khi chúng tôi bắt đầu mọc lên ở đây, đó là bởi vì mọi người đã tìm ra làm thế nào để sử dụng các công cụ. 

Họ đã làm điều tương tự khi cơ sở dữ liệu quan hệ đã được phát minh, và họ đã thay thế các hệ thống tập tin. 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ệ bởi vì đó là những gì mọi người hiểu. Nó không làm việc. 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 là rất lớn. Rất quan trọng. 

Vì vậy, chúng ta sẽ nhận được vào DynamoDB. DynamoDB là của AWS hoàn toàn được quản lý nền tảng NoSQL. Những gì hiện đầy đủ quản lý nghĩa là gì? 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ì. 

Bạn đi vào, bạn nói chúng tôi, tôi cần một bảng. Nó cần nhiều năng lực này. 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. Bây giờ là rất lớn. 

Bởi vì khi bạn nói chuyện về việc mở rộng cơ sở dữ liệu, Cụm dữ liệu NoSQL tại quy mô, petabytes chạy, chạy hàng triệu giao dịch mỗi giây, những điều này không phải là cụm nhỏ. Chúng ta đang nói hàng ngàn trường hợp. Quản lý hàng ngàn trường hợp, thậm chí trường ảo, là một thực tại đau mông. Tôi có nghĩa là, suy nghĩ về mỗi khi một hệ điều hành bản vá đi ra hoặc một phiên bản mới của cơ sở dữ liệu. Điều đó có nghĩa là gì để bạn hoạt động? Đ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. Bây giờ ngay cả với tự động hóa, mà có thể mất một thời gian dài. Điều đó có thể gây ra rất nhiều đau đầu hoạt động, bởi vì tôi có thể có dịch vụ xuống. 

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 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. Hãy những vụ này. Vì vậy, việc quản lý cơ sở hạ tầng quy mô là vô cùng đau đớn. Và AWS lấy nỗi đau mà ra khỏi nó. Và cơ sở dữ liệu NoSQL thể cực kì đau đớn vì cách họ mở rộng quy mô. 

Quy mô theo chiều ngang. 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. Mỗi nút bạn mua là một nhức đầu hoạt động. Vì vậy, hãy để người khác làm điều đó cho bạn. AWS có thể làm điều đó. 

Chúng tôi hỗ trợ các giá trị chính tài liệu. Bây giờ chúng tôi không đi quá nhiều thành trên biểu đồ khác. Có rất nhiều khác nhau hương vị của NoSQL. Họ là tất cả các loại nhận munged với nhau vào thời điểm này. 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 lưu trữ điểm này. Và bạn có thể tranh luận về tính năng của một trong khác. Đối với tôi, rất nhiều này thực sự là sáu một nửa tá khác. 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. Tôi sẽ không nói MongoDB là tốt hơn hoặc tồi tệ hơn Couch, sau đó Cassandra, sau đó Dynamo, hoặc ngược lại. Ý tôi là, đây chỉ là tùy chọn. 

Đó là nhanh chóng và nó phù hợp ở quy mô nào. 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. Với DynamoDB là khả năng để có được một con số thấp độ trễ millisecond ở quy mô nào. Đó là một mục tiêu thiết kế của hệ thống. Và chúng tôi có khách hàng đang làm hàng triệu giao dịch mỗi giây. 

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. Control-- tích hợp truy cập chúng tôi có những gì chúng ta gọi Quản lý truy cập Identity, hoặc IAM. Nó thấm vào mọi hệ thống, mọi dịch vụ AWS cung cấp. DynamoDB không là ngoại lệ. Bạn có thể kiểm soát truy cập các bảng DynamoDB. 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 trong các cơ sở hạ tầng IAM. 

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. Bây giờ đây là một mô hình mới. 

Đ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 về hệ thống kiểm soát truy cập của bạn? RICK Houlihan: dương Đúng so với âm sai? Đung Quay trở lại những gì bạn nên trở về? 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? 

RICK Houlihan: Tôi không thể nói với bạn rằng. Nếu có bất kỳ thất bại nào trên đó, Tôi không phải là người để hỏi rằng câu hỏi cụ thể. Nhưng đó là một câu hỏi hay. Tôi sẽ tò mò muốn biết mà bản thân mình, thực sự. 

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. Đây là ý tưởng mà bạn có thể triển khai các ứng dụng phức tạp 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. Nếu không có bất kỳ cố định cơ sở hạ tầng nào. Và chúng ta sẽ nói một chút về điều đó có nghĩa là chúng ta nhận được trên để các cặp đôi tiếp theo của bảng xếp hạng. 

Điều đầu tiên chúng tôi sẽ làm là chúng ta sẽ nói về các bảng. Kiểu dữ liệu API cho Dynamo. 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, 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 Tôi muốn gọi nó. Hoặc hai bộ API. Một trong những người sẽ được API hành chính. 

Những điều họ chăm sóc các chức năng của cơ sở dữ liệu. Cấu hình các công cụ lưu trữ, thiết lập và thêm bảng. tạo cơ sở dữ liệu danh mục sản phẩm và trường hợp. Những things-- trong DynamoDB, bạn có rất ngắn, danh sách ngắn. 

Vì vậy, trong cơ sở dữ liệu khác, bạn có thể thấy hàng chục các lệnh, hành chính lệnh, để cấu hình các tùy chọn bổ sung. 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. 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. Vì vậy, bạn sẽ có được một rất thiết lập giới hạn của lệnh. 

Bạn nhận được một Tạo Bảng Update, Bảng, Xóa bảng, và Mô tả Bảng. Đó là những điều chỉ bạn cần cho DynamoDB. Bạn không cần một lưu trữ cấu hình động cơ. Tôi không cần phải lo lắng về việc nhân rộng. Tôi không cần phải lo lắng về sharding. 

Tôi không cần phải lo lắng về bất kỳ của công cụ này. Chúng tôi làm tất cả cho bạn. 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. Sau đó, chúng tôi có các nhà khai thác CRUD. CRUD là một cái gì đó chúng ta gọi trong cơ sở dữ liệu đó là Tạo, Update, Delete các nhà khai thác. Đây là những thông thường của bạn hoạt động cơ sở dữ liệu. 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. Nếu bạn muốn quét toàn bộ bảng. Kéo tất cả mọi thứ ra khỏi bàn. Một trong những điều tốt đẹp về DynamoDB là nó cho phép quét song song. 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 đó. Và chúng ta có thể chạy các chủ đề. Chúng tôi có thể quay mà quét lên trên nhiều chủ đề 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. 

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. Chúng tôi sẽ không nói quá nhiều về việc này ngay bây giờ. Tôi đã có một số nội dung sau vào trong boong về việc này. Nhưng Streams thực sự là một running-- nghĩ về nó như là thời gian đặt hàng và thay đổi phân vùng log. Tất cả mọi thứ đang xảy ra trên bảng hiển thị lên trên suối. 

Mỗi viết vào bảng xuất hiện trên suối. Bạn có thể đọc dòng đó, và bạn có thể làm việc với nó. Chúng tôi sẽ nói về những gì loại điều bạn làm gì với những thứ như sao chép, tạo chỉ mục thứ cấp. 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 đó. 

Các kiểu dữ liệu. 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. Ở 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. Các loại giá trị quan trọng. Đây là chuỗi, số, và các tập tin nhị phân. 

Vì vậy, chỉ có ba loại cơ bản. Và sau đó bạn có thể có những bộ. 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. 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. 

Và sau đó có các loại tài liệu. Có bao nhiêu người đã quen thuộc với JSON? Các bạn đã quen thuộc với JSON nhiều như vậy? Đó là cơ bản JavaScript, Đối tượng, Ký hiệu. Nó cho phép bạn cơ bản định nghĩa một cấu trúc phân cấp. 

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 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. Vì vậy, nếu bạn có Java, bạn nhìn vào bản đồ và danh sách. Tôi có thể tạo ra các đối tượng mà khu vực bản đồ. Một bản đồ như là giá trị quan trọng được lưu trữ như là tài sản. Và nó có thể có danh sách giá trị trong những tài sản. Bạn có thể lưu trữ phức tạp này cấu trúc phân cấp như một thuộc tính đơn của một mục DynamoDB. 

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. Trong MongoDB bạn sẽ gọi các tài liệu này. Và nó sẽ là cơ sở văng. Cũng là một cơ sở dữ liệu tài liệu. Bạn gọi các tài liệu này. Tài liệu hoặc vật phẩm có thuộc tính. Thuộc tính có thể tồn tại hoặc không tồn tại trên mục. Trong DynamoDB, có một thuộc tính bắt buộc. 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. 

DynamoDB có những gì chúng ta gọi là khoá băm. Khóa băm phải là duy nhất. 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 là mỗi mục sẽ có một phím băm. Và mỗi khóa băm phải là duy nhất. 

Mỗi mặt hàng được định nghĩa bởi đó chính băm độc đáo. Và chỉ có thể là một. Đây là OK, nhưng thông thường những gì mọi người cần là họ muốn là băm này chìa khóa để làm một chút ít hơn hơn là chỉ có một định danh duy nhất. 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. 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. 

Vì vậy, nếu đó là một chỉ băm bảng, điều này phải là duy nhất. 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 phải là duy nhất. Vì vậy, suy nghĩ về nó theo cách này. Nếu tôi có một diễn đàn. Và hình thức có chủ đề, nó có đăng tải, và nó có phản ứng. 

Vì vậy, tôi có thể có một băm chính, đó là ID topic. Và tôi có thể có một phím phạm vi, đó là ID phản ứng. Bằng cách đó, nếu tôi muốn có được tất cả các trả lời cho chủ đề cụ thể, Tôi chỉ có thể truy vấn các hash. Tôi chỉ có thể nói cho tôi tất cả các vật phẩm có băm này. Và tôi sẽ có được mọi câu hỏi hoặc gửi cho chủ đề cụ thể. Những quy tụ cấp cao nhất là rất quan trọng. Họ hỗ trợ truy cập chính mô hình của các ứng dụng. Nói chung, điều này là những gì chúng tôi muốn làm. Chúng tôi muốn rằng table-- như bạn nạp bàn, chúng ta muốn cấu trúc dữ liệu trong bảng theo cách như vậy rằng các ứng dụng có thể rất nhanh chóng lấy lại những kết quả. Và đôi khi những cách để làm điều đó là để duy trì các quy tụ như chúng tôi chèn dữ liệu. 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. 

Phím phạm vi cho phép băm me-- phím phải được bình đẳng. 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. Khi tôi truy vấn nhiều, tôi có thể nói cho tôi một phạm vi đó là sử dụng bất kỳ loại điều hành phong phú mà chúng tôi hỗ trợ. Hãy cho tôi tất cả các mục trong một hash. Có bằng, lớn hơn, ít hơn, nó bắt đầu với, nó tồn tại giữa hai giá trị này? Vì vậy, các loại truy vấn nhiều rằng chúng tôi luôn quan tâm. 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 bạn truy cập dữ liệu, đó là luôn luôn về một tập hợp. Nó luôn luôn về các hồ sơ có liên quan đến điều này. 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 cho tháng cuối cùng. Đó là một tập hợp. 

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. 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 thuộc tính để có thể truy vấn trên, những truy vấn giàu hỗ trợ nhiều, nhiều, nhiều mô hình ứng dụng truy cập. 

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ế để có thể lây lan các dữ liệu xung quanh. Cơ sở dữ liệu NoSQL làm việc tốt nhất khi dữ liệu được đồng đều phân phối trên các cluster. Có bao nhiêu người đã quen thuộc với thuật toán băm? Khi tôi nói băm và một hashing-- vì một thuật toán băm 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 đó. 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. 

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. Khi tôi chạy các thuật toán băm, nó sẽ quay lại và nói, cũng 1 bằng 7B, 2 bằng 48, 3 bằng CD. Họ đang trải rộng trên tất cả các không gian chính. Và tại sao bạn làm điều này? 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. 

Nếu tôi làm điều này từng bước, 1, 2, 3. Và tôi có một loạt băm chạy trong trường hợp cụ thể này, một không gian băm nhỏ, nó chạy từ 00 đến FF, sau đó các hồ sơ sẽ đến trong và chúng ta sẽ đi 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Có chuyện gì? Mỗi chèn được đi đến cùng một nút. Bạn thấy những gì tôi có ý nghĩa? 

Bởi vì khi tôi chia không gian, và tôi trải qua những hồ sơ này, 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. Phân vùng 2 là 55-89. Phân vùng 3 là AA để FF. 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. 1, 2, 3, 4, 5, 6, tất cả các con đường lên đến 54. Vì vậy, như tôi là những búa hồ sơ vào hệ thống, tất cả mọi thứ kết thúc sẽ có một nút. 

Đó không phải là tốt. Đó là một antipattern. Trong MongoDB họ có vấn đề này nếu bạn không sử dụng một khóa băm. MongoDB cho bạn tùy chọn băm giá trị quan trọng. Bạn nên luôn luôn làm điều đó, nếu bạn đang sử dụng một hash incrementing quan trọng trong MongoDB, hoặc bạn sẽ được đóng đinh mỗi ghi vào một nút, và bạn sẽ được hạn chế bạn viết thông nặng. 

Đung Là A9 169 trong số thập phân? 

RICK Houlihan: Yeah, đó là ở đâu đó xung quanh đó. A9, tôi không biết. Bạn muốn có để có được nhị phân của tôi để tính số thập phân. Bộ não của tôi không làm việc như thế. Đung Chỉ cần một cách nhanh chóng ý kiến ​​của Mongo của bạn. Vì vậy, là đối tượng ID mà đến natively với Mongo làm điều đó? RICK Houlihan: Liệu nó làm điều đó? Nếu bạn chỉ định nó. Với MongoDB, bạn có tùy chọn. Bạn có thể specify-- mỗi tài liệu MongoDB phải có một ID gạch dưới. Đó là giá trị duy nhất. 

Trong MongoDB bạn có thể chỉ định liệu để băm nó hay không. Họ chỉ cung cấp cho bạn tùy chọn. Nếu bạn biết rằng nó ngẫu nhiên, không có vấn đề. Bạn không cần phải làm điều đó. 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. 

Bây giờ điều về băm, một khi bạn băm một value-- và điều này là tại sao phím băm luôn 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. Tôi không thể nói là điều này giữa điều này hay đó, bởi vì giá trị băm là không đi là tương đương với giá trị thực tế. Vì vậy, khi bạn băm mà trọng, nó chỉ bình đẳng. Đâ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. 

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, 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. Vì vậy, họ rất nhanh chóng, dễ dàng lấy ra vì đây là băm, đây là phạm vi. Và bạn thấy tất cả mọi thứ với cùng bảng băm được lưu trữ trên phân vùng không gian tương tự. 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ó. Vì vậy, những gì tôi thực sự làm gì ở đây? Đây là một trong nhiều mối quan hệ. 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. Tôi có thể có nhiều phím băm. Tôi chỉ có thể có nhiều dải phím trong mỗi khóa băm. 

Băm xác định cha mẹ, phạm vi xác định trẻ em. Vì vậy, bạn có thể nhìn thấy ở đây tương tự ở đây giữa xây dựng quan hệ và các loại tương tự của xây dựng trong NoSQL. Mọi người nói về NoSQL là nonrelational. Nó không phải nonrelational. Dữ liệu luôn luôn có mối quan hệ. Những mối quan hệ chỉ được mô hình hóa khác nhau. Hãy nói một chút chút về độ bền. Khi bạn viết thư cho DynamoDB, viết luôn ba cách nhân rộng. Có nghĩa là chúng tôi có ba AZ của. AZ của những khu sẵn có. Bạn có thể nghĩ về một Availability Zone là một trung tâm dữ liệu hoặc một bộ sưu tập của các trung tâm dữ liệu. Những điều này là địa lý phân lập từ mỗi khác trên đới đứt gãy khác nhau, qua lưới điện và khu vực đất khác nhau. Một thất bại trong một AZ không phải là sẽ đi xuống khác. Họ cũng được liên kết cùng với chất xơ tối. Nó hỗ trợ một phụ 1 độ trễ millisecond giữa AZS. Vì vậy, thời gian thực lặp dữ liệu có khả năng trong đa AZS. 

Và đôi khi triển khai đa AZ đáp ứng yêu cầu sẵn sàng cao của hầu hết các tổ chức doanh nghiệp. Vì vậy DynamoDB được lan truyền trên ba AZS theo mặc định. Chúng tôi sẽ chỉ kiến ​​thức write khi hai trong ba nút trở lại và nói, Yeah, tôi đã nhận nó. Tại sao vậy? 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 chúng tôi nhận được nó từ hai nút. 

Nếu tôi đang nhân rộng trên toàn ba, và tôi đọc từ hai, Tôi luôn luôn được bảo đảm phải có ít nhất một của những người đọc là nhất bản hiện tại của dữ liệu. Đó là những gì làm cho DynamoDB phù hợp. Bây giờ bạn có thể chọn để biến những người phù hợp đọc off. Trong trường hợp đó, tôi sẽ nói, Tôi sẽ chỉ đọc từ một nút. Và tôi không thể đảm bảo nó sẽ là dữ liệu mới nhất. 

Vì vậy, nếu một ghi được đến, nó đã không được nhân rộng nào, bạn sẽ nhận được bản sao đó. Đó là một chi tiết cuối cùng phù hợp. Và một nửa chi phí đó là những gì được. Vì vậy, đây là một cái gì đó để suy nghĩ về. Khi bạn đang đọc ra DynamoDB, và bạn đang thiết lập khả năng đọc của bạn đơ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, đó là khoảng một nửa chi phí. 

Và do đó, nó giúp bạn tiết kiệm tiền. Nhưng đó là sự lựa chọn của bạn. Nếu bạn muốn đọc nhất quán hay một chi tiết cuối cùng phù hợp. Đó là một cái gì đó mà bạn có thể lựa chọn. 

Hãy nói về chỉ số. Vì vậy, chúng tôi đã đề cập rằng đầu tập hợp mức. Chúng tôi đã có phím băm, và chúng tôi đã có nhiều phím. Đó là tốt đẹp. 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. 

Điều đó có nghĩa là gì? 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. Đó là chìa khóa loạt. 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. 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. 

Làm thế nào để làm điều đó? Tôi tạo ra một chỉ số. Có hai loại chỉ số trong DynamoDB. Một chỉ số thực sự là nhìn khác của bảng. Và chỉ số thứ cấp địa phương. 

Người đầu tiên chúng tôi sẽ nói về. 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. Và như vậy, họ đang trên các nút vật lý như nhau. Họ là những gì chúng ta gọi là nhất quán. Ý nghĩa, họ sẽ thừa nhận write cùng với bảng. Khi viết đến, chúng tôi sẽ viết thư thông qua các chỉ số. Chúng tôi sẽ viết lên bàn, và sau đó chúng tôi sẽ xác nhận. Vì vậy, đó là phù hợp. Một khi đã được ghi thừa nhận từ bảng, nó đảm bảo rằng các Chỉ số thứ địa phương sẽ có cùng một tầm nhìn của dữ liệu. 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ế. 

Phải sử dụng cùng bảng băm chính là bảng chính, bởi vì họ là đồng nằm trên cùng một phân vùng, và họ là phù hợp. 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. 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. Và phần thô đi vào, và họ đang tổng hợp bằng cách lắp ráp. Và có lẽ đó là một hồi. 

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, Tôi cần phải kéo từ đường của tôi. Tôi có thể quay một chỉ số mà có thể tìm kiếm, tập hợp vào ngày sản xuất của một phần cụ thể. 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, 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 đó như băm của nhà sản xuất và dao động về ngày sản xuất. 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, Tôi cần phải kéo từ dòng. Vì vậy, đó là một chỉ số trung học địa phương. 

Những có tác dụng hạn chế không gian chính băm của bạn. Bởi vì họ đồng tồn tại vào nút lưu trữ, họ giới hạn các khóa băm không gian đến 10 GB. DynamoDB, dưới bảng, sẽ phân vùng bảng của bạn mỗi 10 gigabyte. 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. 

Chúng tôi sẽ không chia LSI trên nhiều phân vùng. Chúng tôi sẽ chia bảng. Nhưng chúng tôi sẽ không phân chia các LSI. Vì vậy, đó là một cái gì đó quan trọng để hiểu là nếu bạn đang làm rất, rất, quy tụ rất lớn, sau đó bạn sẽ được giới hạn đến 10 gigabytes trên LSIs của bạn. 

Nếu đó là trường hợp, chúng ta có thể sử dụng secondaries toàn cầu. Secondaries toàn cầu là thực sự bàn khác. 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. Và họ cho phép tôi để tìm một cấu trúc hoàn toàn khác nhau. 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 theo hai cách khác nhau. 

Tôi có thể xác định một hoàn toàn khóa băm khác nhau. Tôi có thể xác định một hoàn toàn key phạm vi khác nhau. Và tôi có thể chạy này hoàn toàn độc lập. Như một vấn đề của thực tế, tôi đã được cung cấp khả năng đọc của tôi và viết công suất cho tôi chỉ số trung toàn cầu hoàn toàn độc lập của bảng chính của tôi. Nếu tôi xác định chỉ số đó, tôi nói nó bao nhiêu đọc và viết khả năng nó sẽ được sử dụng. 

Và đó là riêng biệt từ bảng chính của tôi. 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, nhưng họ cho phép chúng tôi dự án giá trị bổ sung. 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, 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. Tôi có thể trình chiếu những bổ sung thuộc tính vào bảng để hỗ trợ các mô hình truy cập. 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 đây trên một số các công cụ này. Bây giờ tôi đã trôi dạt ra khỏi đây. 

Đung [Không nghe thấy] key --table có nghĩa là một hash? Các băm gốc? Multi-thanh? 

RICK Houlihan: Yes. Vâng. Chìa khóa bàn cơ bản lại trỏ vào mục. Vì vậy, một chỉ là một con trỏ trở lại các mục gốc trên bàn. Bây giờ bạn có thể chọn để xây dựng một chỉ số mà chỉ có phím bảng, và không có tài sản khác. Và tại sao tôi có thể làm điều đó? Vâng, có lẽ tôi có các mục rất lớn. 

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, mà mục chứa tài sản này? Bạn không cần phải trả lại hàng. Tôi chỉ cần biết mà mục chứa nó. Vì vậy, bạn có thể xây dựng các chỉ số mà chỉ có chìa khóa bảng. 

Nhưng đó là những gì chủ yếu một chỉ mục trong cơ sở dữ liệu là cho. Đó là để có thể nhanh chóng xác định được ghi lại, mà hàng, mà các mặt hàng trong bảng có các tài sản mà tôi đang tìm kiếm. 

GSIs, vậy làm thế nào để họ làm việc? GSIs về cơ bản là không đồng bộ. 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ộ tất cả các GSIs của bạn. Đây là lý do tại sao GSIs là cuối cùng phù hợp. 

Điều quan trọng cần lưu ý đó là khi bạn đang xây dựng GSIs, và bạn hiểu bạn đang tạo một chiều kích khác của aggregation-- 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. Tôi nghĩ có thể tôi đã nói chuyện về một nhà sản xuất thiết bị y tế. Các nhà sản xuất thiết bị y tế đôi khi có phần tuần tự. Các bộ phận mà đi vào một sự thay thế hip tất cả có một số rất ít về chúng. Và họ có thể có hàng triệu và hàng hàng triệu và hàng tỷ phần trong tất cả các thiết bị mà họ tàu. 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 trong một hội đồng, tất cả các các bộ phận đã được thực hiện trên một đường nhất định, tất cả các phụ tùng đi kèm từ một nhà sản xuất nào vào một ngày nhất định. Và đôi khi những quy tụ có được lên đến hàng tỷ. 

Vì vậy, tôi làm việc với một số những kẻ đang chịu đau khổ bởi vì họ đang tạo ra các quy tụ ginormous trong chỉ số trung của họ. Họ có thể có một phần nguyên bảng mà đến như là chỉ băm. Mỗi phần có một số serial duy nhất. Tôi sử dụng số serial như băm. Nó thật đẹp. 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. My [? viết?] [? ăn?] là tuyệt vời. Tôi mất rất nhiều dữ liệu. Sau đó, những gì họ làm là họ tạo ra một GSI. 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. Vâng, tất cả của một đột ngột tôi tham gia một tỷ hàng, và nhét chúng vào một nút, bởi vì khi Tôi tổng hợp như nhà sản xuất ID như băm, và phần số như phạm vi, sau đó tất cả những bất ngờ tôi đặt một tỷ phần vào những gì nhà sản xuất này đã cứu tôi. 

Điều đó có thể gây ra rất nhiều áp lực trên GSI, một lần nữa, bởi vì tôi là búa một nút. Tôi đang đặt tất cả các chèn vào một nút. Và đó là một trường hợp thực tế sử dụng có vấn đề. 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 đó. Và đó là một trong những vấn đề rằng tôi luôn luôn làm việc với. Nhưng điều gì sẽ xảy ra, là GSI thể không có đủ khả năng viết để có thể đẩy tất cả những hàng vào một nút duy nhất. Và những gì xảy ra sau đó là tiểu học, bảng khách hàng, bảng chính sẽ được tăng cường vì GSI không thể theo kịp. Vì vậy, tỷ lệ chèn của tôi sẽ rơi vào bảng chính như GSI tôi sẽ cố gắng để theo kịp. 

Tất cả các quyền, do GSI của, LSI, cái nào tôi nên sử dụng? LSI là nhất quán. GSI của là cuối cùng nhất quán. 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. LSI có thể được mô hình hóa như một GSI. 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, sau đó bạn sẽ muốn sử dụng đó GSI vì nó chỉ là một giới hạn cứng. 

Tất cả các quyền, do đó nhân rộng. Throughput trong Dynamo DB, bạn cung lon [Không nghe thấy] thông vào một bảng. Chúng tôi có khách hàng có trích lập dự phòng 60 billion-- đ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 mỗi giây trên bàn của chúng tôi. Có thực sự không giới hạn lý thuyết đến bao nhiêu và làm thế nào nhanh chóng bàn có thể chạy trong Dynamo DB. Có một số phần mềm giới hạn về tài khoản của bạn mà chúng ta đặt ở đó vì vậy rằng bạn không đi điên. Nếu bạn muốn nhiều hơn rằng, không phải là một vấn đề. Bạn đến cho chúng tôi. Chúng tôi sẽ lần lượt lên quay số. 

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 vì vậy những người không đi điên tự gây rắc rối. Không có giới hạn về kích thước. Bạn có thể đặt bất kỳ số các hạng mục trên một bảng. Kích thước của một mục giới hạn đến 400 kilobytes mỗi, đó sẽ là item không phải là thuộc tính. Vì vậy, tổng của tất cả các thuộc tính được giới hạn đến 400 kilobyte. Và sau đó một lần nữa, chúng tôi có mà ít vấn đề LSI với giới hạn 10 gigabyte mỗi băm. Đung số nhỏ, tôi là thiếu những gì bạn đang nói với tôi, rằng is-- Đung Oh, 400 kilobyte là kích thước tối đa cho mỗi mục. Vì vậy, một mặt hàng có tất cả các thuộc tính. Vì vậy, 400 k là tổng kích thước của mục đó, 400 kilobyte. Do đó tất cả các thuộc tính kết hợp, tất cả các dữ liệu đó là trong tất cả những thuộc tính, cuộn lại thành một tổng kích cỡ, hiện nay các giới hạn mục là 400 k. Vì vậy, một lần nữa mở rộng quy mô, đạt được thông qua phân vùng. Thông được trích lập dự phòng ở cấp bảng. Và có thực sự hai nút bấm. Chúng tôi đã đọc công suất và viết công suất. 

Vì vậy, những được điều chỉnh độc lập với nhau. Biện pháp RCU của Nghiêm phù đọc. 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, những phù đọc. Nếu bạn nói rằng tôi muốn cuối cùng nhất quán đọc, bạn có thể cung cấp 1.000 RCU, bạn đang đi để cuối cùng nhận được 2.000 nhất quán đọc. Và một nửa giá cho những cuối cùng bao gồm trong lần đọc. 

Một lần nữa, điều chỉnh độc lập với nhau. Và họ có throughput-- Nếu bạn tiêu thụ 100% của RCU của bạn, bạn sẽ không tác động đến sẵn có của các quyền của mình. Vì vậy, họ là hoàn toàn độc lập với nhau. Đượ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. Điều chỉnh tiết lưu là xấu. Điều chỉnh tiết lưu chỉ xấu không có SQL. 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 đang gặp phải. Nhưng giải pháp tốt nhất đến đây là chúng ta hãy 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. 

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. 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. Tại sao tôi làm điều này? Hãy hiểu rằng con số. Tôi trộn dữ liệu nóng của tôi với dữ liệu lạnh. Tôi để cho bàn của tôi có được rất lớn, nhưng có thực sự chỉ có một số tập con của dữ liệu đó là thực sự thú vị với tôi. 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. Họ đã có một số lượng lớn các dữ liệu đăng nhập. 

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 bảng đó sẽ được lớn. Nhưng tôi thực sự chỉ quan tâm đến 24 giờ qua, bảy ngày qua, 30 ngày qua. Dù cửa sổ thời gian mà tôi quan tâm tìm kiếm 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, đó là thời gian cửa sổ duy nhất mà tôi cần. Vậy tại sao tôi đặt 10 năm giá trị của dữ liệu đăng nhập trong bảng? Điều gì gây ra là bảng phân mảnh. 

Nó sẽ rất lớn. Nó bắt đầu lan rộng ra qua hàng ngàn các nút. Và kể từ khi công suất của bạn như vậy là thấp, bạn thực sự đánh giá hạn chế trên mỗi một trong những nút riêng lẻ. 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. 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. Và điều đó như thế nào? Đây là những gì mà trông như thế nào. Đây là những gì xấu NoSQL trông như thế nào. 

Tôi có một phím nóng ở đây. 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. Tôi có 16 phân vùng lên ở đây trên cơ sở dữ liệu đặc biệt này. Chúng tôi làm điều này tất cả các thời gian. Tôi chạy này cho khách hàng tất cả các thời gian. Nó được gọi là bản đồ nhiệt. 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. Và điều này là nói cho tôi là rằng có một băm cụ thể rằng anh chàng này thích một nhiều khủng khiếp, bởi vì anh ấy đánh nó thực sự, thực sự khó khăn. 

Vì vậy, màu xanh là tốt đẹp. Chúng tôi thích màu xanh. Chúng tôi không thích màu đỏ. Red của nơi mà áp lực được lên đến 100%. 100%, bây giờ bạn sẽ được tăng cường. 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-- mỗi cơ sở dữ liệu NoSQL có vấn đề này. Có anti-mẫu mà có thể lái xe các loại điều kiện. 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. 

Và điều đó như thế nào? Và điều này đang nhận được nhiều nhất ra của Dynamo DB thông, nhưng nó thực sự nhận được nhiều nhất của NoSQL. Điều này không chỉ giới hạn Dynamo. Đây là definitely-- tôi được sử dụng để làm việc tại Mongo. Tôi quen thuộc với nhiều nền tảng NoSQL. Mỗi người có những loại các vấn đề về phím nóng. Để nhận được nhiều nhất của bất kỳ NoSQL cơ sở dữ liệu, đặc biệt Dynamo DB, 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ó 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. Bởi vì đó có nghĩa là tôi đang viết đến lô xô khác nhau. 

Các xô hơn tôi viết để, nhiều khả năng Tôi để lan truyền rằng write tải hoặc đọc tải ra trên nhiều nút, nhiều khả năng tôi có một thông lượng cao trên bàn. Và sau đó tôi muốn các giá trị được yêu cầu khá đồng đều theo thời gian và thống nhất như ngẫu nhiên càng tốt. Vâng, đó là loại thú vị, bởi vì tôi không thể thực sự kiểm soát khi người sử dụng đến. 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, có lẽ chúng ta sẽ ở trong hình dạng tốt hơn. 

Có một số lượng thời gian giao hàng rằng bạn không đi được kiểm soát có thể. Nhưng những người này thật sự là hai chiều mà chúng ta có, không gian, tiếp cận đồng đều lây lan, thời gian, yêu cầu Đến khoảng cách đồng đều trong thời gian. Và nếu hai điều kiện được đáp ứng, thì đó là những gì nó sẽ như thế nào. Điều này là rất đẹp. Chúng tôi thực sự hạnh phúc ở đây. Chúng tôi đã có một mô hình truy cập rất đều. Ừ, có lẽ bạn đang nhận được một ít áp lực tất cả bây giờ và sau đó, nhưng không thực sự quá rộng lớn. 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, 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ó khắp nơi, chúng tôi được thực hiện với các bài tập sau một vài tháng tái cấu trúc, 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. Và đây là những gì nó trông như bây giờ. 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 gắn với các mô hình truy cập. 

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. Nếu bạn không, sau đó bạn sẽ để xem những vấn đề đó với những phím nóng. 

Đung Vâng, chắc chắn một số nơi sẽ nóng hơn những người khác. 

RICK Houlihan: Luôn luôn. Luôn luôn. Vâng, tôi có nghĩa là luôn luôn có a-- và một lần nữa, có 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ó với các quy tụ siêu lớn. Ý tôi là, tôi đã có họ, làm thế nào để chúng ta đối phó với họ? 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 đó. 

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. Những kẻ đang AdRoll. Tôi không biết nếu bạn là quen thuộc với AdRoll. Bạn có thể nhìn thấy chúng rất nhiều vào trình duyệt. 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 ngoài đó. Họ thường xuyên chạy qua 60 tỷ giao dịch mỗi ngày. Họ đang làm hơn một triệu giao dịch mỗi giây. Họ đã có một bảng khá đơn giản cấu trúc, bảng bận rộn nhất. Đó là cơ bản chỉ là một khóa băm là các cookie, phạm vi là các nhân khẩu học thể loại, và sau đó các thuộc tính thứ ba là điểm số. 

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. Và khi bạn đi đến một tham gia buôn bán, họ về cơ bản ghi bạn qua loại nhân khẩu học khác nhau. Khi bạn đi vào một trang web và bạn nói tôi muốn xem ad-- này hoặc về cơ bản bạn không nói that-- nhưng khi bạn đi đến các trang web họ nói rằng bạn muốn thấy quảng cáo này. Và họ đi nhận rằng quảng cáo từ AdRoll. AdRoll trông bạn lên trên bàn của họ. Họ tìm cookie của bạn. Các nhà quảng cáo nói họ, tôi muốn ai đó những người trung niên, Người đàn ông 40 tuổi, vào thể thao. 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 đó là một quảng cáo tốt cho bạn. 

Bây giờ họ có một SLA với cung cấp dịch vụ quảng cáo của họ cung cấp phụ 10 phần nghìn giây đáp ứng yêu cầu mỗi ngày duy nhất. Vì vậy, họ đang sử dụng Dynamo DB cho việc này. Họ đang đánh chúng ta một triệu yêu cầu mỗi giây. 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 đó, và nhận được rằng add link lại cho rằng nhà quảng cáo ở dưới 10 mili giây. Nó thực sự khá phi thường thực hiện mà họ có. 

Những anh chàng actually-- là những kẻ. Tôi không chắc chắn nếu đó là những chàng trai. Có thể là những kẻ. Về cơ bản nói us-- không, tôi không nghĩ rằng đó là họ. Tôi nghĩ đó là một người khác. Tôi đã làm việc với một khách hàng đó đã nói với tôi rằng bây giờ họ đã đi Dynamo DB, họ 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 hơn họ chi tiêu vào cơ sở dữ liệu của họ. Vì vậy, nó sẽ cung cấp cho bạn một ý tưởng về tiết kiệm chi phí mà bạn có thể nhận được trong Dynamo DB là rất lớn. Tất cả các quyền, dropcam là một công ty khác. Những anh chàng là loại of-- nếu bạn nghĩ của Internet của sự vật, dropcam về cơ bản là video an ninh internet. Bạn đặt máy ảnh của bạn lên đó. Camera có một máy dò chuyển động. Một người nào đó đi cùng, gây nên một điểm cue. 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. Đặt video trên internet. 

Dropcam là một công ty đó là về cơ bản chuyển sang Dynamo DB bởi vì họ đã trải qua đau ngày càng lớn. Và những gì họ nói với chúng tôi, đột nhiên petabyte dữ liệu. Họ không có ý tưởng dịch vụ của họ sẽ rất thành công. Video inbound hơn YouTube là những gì những kẻ đang nhận được. 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ọ. 

Vì vậy, họ có xô S3 họ đẩy tất cả các hiện vật nhị phân thành. Và sau đó họ có Hồ sơ Dynamo DB điểm người dân với những S3 ba đối tượng. 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. Họ nhấp vào liên kết. Họ kéo xuống các video từ S3. Vì vậy, đó là loại gì trông như thế nào. Và đây là trực tiếp từ đội ngũ của họ. 

Dynamo DB giảm của họ thời gian giao hàng cho các sự kiện phim từ năm đến 10 giây. Trong cửa hàng quan hệ cũ của họ, họ thường phải đi và thực hiện nhiều truy vấn phức tạp để hình ra video để kéo xuống, đến dưới 50 mili giây. Vì vậy, nó là tuyệt vời, tuyệt vời hiệu suất bao nhiêu 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 để hỗ trợ các mô hình truy cập. Halfbrick, những anh chàng này, nó là gì, Fruit Ninja Tôi đoán là điều họ. Đó là tất cả chạy trên Dynamo DB. 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 cửa tiệm. 

Không phải là một ops đội bóng tốt. Họ không có nhiều các nguồn lực hoạt động. Họ đều đang nỗ lực cố gắng để giữ cơ sở hạ tầng ứng dụng của họ lên và chạy. Họ đến với chúng tôi. Họ nhìn mà Dynamo DB. Họ cho biết, đó là vì chúng ta. Họ đã xây dựng toàn bộ của họ khung ứng dụng trên nó. Một số ý kiến ​​thực sự tốt đẹp ở đây từ nhóm vào khả năng của họ đến nay tập trung vào xây dựng các trò chơi và không phải duy trì cơ sở hạ tầng, trong đó đã trở thành một số lượng lớn trên không cho đội bóng của họ. Vì vậy, đây là một cái gì đó that-- sự lợi ích mà bạn nhận được từ Dynamo DB. 

Tất cả các bên phải, đi vào mô hình hóa dữ liệu ở đây. Và chúng ta đã nói một chút về này một đến một, một đến nhiều, và nhiều nhiều mối quan hệ kiểu. Và làm thế nào để bạn duy trì những người trong Dynamo. Trong Dynamo DB chúng tôi sử dụng chỉ số, nói chung, để xoay các dữ liệu từ một hương vị khác. Phím băm, phím phạm vi, và lập chỉ mục. 

Đặc biệt này Ví dụ, như hầu hết các quốc gia 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. Bạn không thể đi để có được hai lái xe giấy phép ở bang Boston. Tôi không thể làm điều đó ở Texas. Đó là loại cách nó được. 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 bằng của số an sinh xã hội. 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. 

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, hoặc số an sinh xã hội, và thuộc tính khác nhau được xác định vào mục. Bây giờ trên các bảng I có thể xác định một GSI đó 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 đó tất cả các mặt hàng khác. 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 Số an sinh, tôi có thể truy vấn bảng chính. 

Nếu tôi muốn truy vấn và tôi muốn để có được an sinh xã hội 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. Đó là mô hình là một trong những đến một mối quan hệ. Chỉ cần một GSI rất đơn giản, lật những thứ xung quanh. Bây giờ, nói về một đến nhiều. Một đến nhiều là về cơ bản key loạt băm của bạn. 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. 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. 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. 

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ể. Đó là một câu hỏi rất phổ biến ở cơ sở hạ tầng theo dõi. 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. 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. 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. 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 và trả lại những hồ sơ mà có liên quan đến kết quả thiết mà tôi đang tìm kiếm. Và nó xây dựng một mà nhiều mối quan hệ 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. 

Vì vậy, đó là loại xây dựng vào bảng trong Dynamo DB. Khi tôi xác định một hash và bảng phạm vi t, tôi xác định một đến nhiều mối quan hệ. Đó là một mối quan hệ cha-con. 

Hãy nói về nhiều nhiều mối quan hệ. Và cho ví dụ cụ thể này, một lần nữa, chúng ta sẽ sử dụng GSI của. 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. Tôi muốn tìm hiểu tất cả các trò chơi mà anh đăng ký hoặc chơi ở. 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. Vì vậy, làm thế nào để làm điều đó? 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 và một phím phạm vi của trò chơi. 

Vì vậy, người dùng có thể có nhiều trò chơi. Đó 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. Và sau đó vào GSI, Tôi sẽ lật xung quanh đó. Tôi sẽ băm vào các trò chơi và Tôi sẽ dao vào người sử dụng. 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, Tôi sẽ truy vấn bảng chính. 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ể, Tôi truy vấn GSI. Vì vậy, bạn xem cách chúng tôi làm điều này? 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 mô hình, các ứng dụng. 

Nếu tôi cần phải truy vấn trên không gian này, chúng ta hãy tôi tạo ra một chỉ số trên không gian đó. Nếu tôi không, tôi không quan tâm. 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. Nếu đó là một trong những đơn giản với nhiều người, bảng chính là tốt. 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, sau đó có lẽ tôi cần thứ hai chỉ số. Vì vậy, tất cả phụ thuộc vào những gì tôi đang cố gắng để làm và những gì tôi đang cố gắng để có được thành tựu. 

Có lẽ tôi sẽ không chi tiêu quá nhiều thời gian nói về tài liệu. Đ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. Hãy nói một chút biểu thức truy vấn về phong phú. Vì vậy, trong Dynamo DB chúng tôi có khả năng tạo những gì chúng ta gọi là biểu thức chiếu. Biểu thức chiếu chỉ đơn giản là chọn các trường hoặc các giá trị mà bạn muốn hiển thị. OK, vì vậy tôi thực hiện một lựa chọn. Tôi thực hiện một truy vấn đối với Dynamo DB. Và tôi nói, bạn biết những gì, show tôi chỉ có các đánh giá năm sao cho sản phẩm đặc biệt này. Vì vậy, đó là tất cả tôi muốn xem. 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, Tôi chỉ muốn thấy điều này. Nó giống như trong SQL khi bạn nói sao chọn hoặc từ bảng, bạn sẽ có được tất cả mọi thứ. Khi tôi nói chọn tên từ bảng, tôi chỉ nhận được một thuộc tính. Đó là cùng một loại điều trong Dynamo DB hoặc một cơ sở dữ liệu NoSQL. 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. Vì vậy, tôi thực hiện một truy vấn. Truy vấn có thể trở lại với 500 mặt hàng. 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. 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ể. Vì vậy, chúng ta có các biểu thức lọc. 

Biểu thức lọc có thể thể chạy trên bất kỳ thuộc tính. Họ không muốn truy vấn nhiều. Nâng truy vấn được chọn lọc hơn. 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 đó carve ra các dữ liệu tôi không muốn. Tại sao điều đó lại quan trọng? Bởi vì tôi đọc tất cả. 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. Và sau đó tôi sẽ carve ra những gì tôi cần. Và nếu tôi chỉ khắc ra một vài hàng, thì đó là OK. Nó không phải như vậy không hiệu quả. 

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, sau đó tôi sẽ được tốt hơn bằng cách sử dụng một truy vấn nhiều, vì nó nhiều hơn chọn lọc. 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à. Trường hợp kết quả mà trở lại qua dây mà có thể là nhỏ hơn, nhưng tôi trả tiền cho việc đọc. Vì vậy, hiểu như thế nào bạn đang nhận được dữ liệu. Điều đó rất quan trọng trong Dynamo DB. 

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. 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. Và nếu tôi có một tem thời gian trên hồ sơ, tôi có thể đọc dữ liệu. Tôi có thể thay đổi dữ liệu. Tôi có thể đi viết rằng dữ liệu về cơ sở dữ liệu. Nếu ai đó đã thay đổi các hồ sơ, dấu thời gian có thể đã thay đổi. Và cách mà điều kiện của tôi cập nhật có thể nói cập nhật nếu các dấu thời gian bằng này. 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. 

Đó là những gì chúng ta gọi là lạc quan khóa. Nó có nghĩa là ai đó có thể đi vào và thay đổi nó, và tôi sẽ phát hiện ra nó khi tôi quay trở lại để viết. Và sau đó tôi thực sự có thể đọc mà dữ liệu và nói, oh, ông đã thay đổi này. Tôi cần tài khoản cho điều đó. 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. 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 bạn đọc các dữ liệu và các thời gian bạn có thể ghi dữ liệu. 

Đung Và bộ lọc biểu hiện thực sự có nghĩa là không số hoặc not-- 

[Interposing GIỌNG NÓI] RICK Houlihan: Tôi sẽ không nhận được quá nhiều vào điều này. Đây có phải là một từ khóa dành riêng. Quan điểm bảng Anh một Ltd. từ khóa trong Dynamo DB. 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. Dynamo DB, nếu bạn chỉ định pound trước mặt này, bạn có thể xác định những cái tên lên trên. Đây là một giá trị tham chiếu. Đó 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, bởi vì nó được vào một số real-- Tôi đã nói chuyện nhiều hơn về điều đó ở một mức độ sâu hơn. 

Nhưng đủ để nói, điều này có thể được truy vấn quét nơi họ views-- cũng không xem bảng Anh là lớn hơn 10. Nó là một giá trị số, có. 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. Đượ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 nơi chúng ta sẽ nói chuyện về một số ứng dụng ở đây. Các trường hợp sử dụng cho Dynamo DB là gì. Thiết kế là gì mẫu trong Dynamo DB. 

Và người đầu tiên chúng ta sẽ nói về là internet của vạn vật. 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% 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, quy trình tự động, không phải do con người. 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, bao nhiêu dữ liệu mà điều đó là thực sự gửi xung quanh mà không bạn biết nó là hoàn toàn tuyệt vời. Vị trí của bạn, thông tin về nhanh như thế nào bạn đang đi. 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. Đó là bởi vì có hàng triệu và hàng triệu người lái xe xung quanh 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. Vì vậy, một trong những điều về kiểu dữ liệu 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ó thường chỉ thú vị cho một chút ít thời gian. Sau thời gian đó, nó không thú vị như vậy. 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. Ý 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. Và đó bảng nóng là có được được cung cấp với một tốc độ rất cao, vì nó lấy rất nhiều dữ liệu. Nó lấy rất nhiều dữ liệu và tôi đọc nó rất nhiều. Tôi đã có rất nhiều hoạt động truy vấn chạy chống lại dữ liệu đó. 

Sau 24 giờ, hey, bạn biết những gì, tôi không quan tâm. 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 và tôi deprovision bảng này. Và tôi sẽ lấy của RCU và Xuống WCU vì 24 giờ sau đó Tôi không chạy nhiều truy vấn đối với dữ liệu đó. Vì vậy, tôi sẽ tiết kiệm tiền. 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ả. Tôi có thể lấy của WCU tất cả các con đường xuống một, bởi vì bạn biết những gì, đó là không bao giờ được ghi vào. Các dữ liệu là 30 ngày tuổi. Nó không bao giờ thay đổi. 

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. 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. 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 dữ liệu đi vào trong âm lượng. Đây là chiến lược. Bây giờ, tôi chỉ có thể để cho nó tất cả đi đến cùng một bảng và chỉ cần cho bảng mọc. Cuối cùng, tôi sẽ thấy vấn đề hiệu suất. Tôi sẽ phải bắt đầu lưu trữ một số trong đó dữ liệu ra khỏi bàn, những gì không. 

Hãy tốt hơn nhiều thiết kế ứng dụng của bạn để bạn có thể hoạt động theo cách này ngay. Vì vậy, nó chỉ tự động trong mã ứng dụng. Vào lúc nửa đêm mỗi đêm nó cuộn bàn. 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. Sau đó, trên cơ sở thường xuyên tôi gọi dữ liệu khỏi bàn. Tôi đang cắt tỉa nó với một Cron công việc và tôi đặt nó vào các bảng khác, bất cứ điều gì bạn cần. Vì vậy, nếu một rollover hoạt động, đó là tuyệt vời. Nếu không, cắt nó. 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. 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. Vì vậy, điều tiếp theo chúng ta sẽ nói về là danh mục sản phẩm. Danh mục sản phẩm là trường hợp sử dụng khá phổ biến. Đâ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. Bạn biết đấy, Twitter cho Ví dụ, một tweet nóng. Và tất cả mọi người đang đến grabbing tweet đó. Danh mục sản phẩm, tôi đã bán được hàng. Tôi có một bán nóng. Tôi đã nhận 70.000 yêu cầu mỗi lần thứ hai cho một sản phẩm Mô tả ra khỏi danh mục sản phẩm của tôi. 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. Vì vậy, làm thế nào để chúng ta đối phó với điều đó? Không có cách nào để đối phó với điều đó. 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. Họ đang đến, đồng thời. 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. Đ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. Và đó là những gì mà trông như thế nào. 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. Tôi nhận được không có gì bất cứ nơi nào khác. 

Làm thế nào để giảm bớt vấn đề này? Vâng, chúng tôi giảm bớt điều này với bộ nhớ cache. 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. Chúng tôi đã được quản lý [Không nghe thấy] cache, làm thế nào bạn 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. Đặt rằng lên ở phía trước của cơ sở dữ liệu. 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 không gian và đọc thông qua bộ nhớ cache. 

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. 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 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. 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. Chúng tôi có thể sử dụng một cái gì đó như hơi nước để làm điều đó. Và tôi sẽ giải thích làm thế nào mà làm việc. Tất cả các quyền, nhắn tin. Email, tất cả chúng ta sử dụng email. 

Đây là một ví dụ khá tốt. Chúng tôi đã có một số loại thông điệp bảng. Và chúng tôi có hộp thư đến và hộp thư đi. Đây là những gì SQL sẽ nhìn muốn xây dựng hộp thư đó. 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 cho hộp thư của tôi và hộp thư đi của tôi. 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. 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 đề. Tôi đã có thông điệp thô. Tin nhắn đến [Không nghe thấy], tin ID, đó là tuyệt vời. Đó là băm duy nhất của tôi. 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. 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à sẽ là người nhận và Tôi sẽ sắp xếp vào ngày tháng. Điều này là tuyệt vời. Tôi có cái nhìn tốt đẹp của tôi ở đây. Nhưng có một vấn đề nhỏ ở đây. Và bạn chạy vào trong này cơ sở dữ liệu quan hệ là tốt. Họ được gọi là phân vùng theo chiều dọc. 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. 

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. 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 nếu chiều dài cơ thể của tôi là trung bình mỗi 256 kilobyte, toán học được khá xấu xí. Vì vậy, nói tôi muốn đọc hộp thư của David. Hộp thư đến của David có 50 mặt hàng. Trung bình và kích thước là 256 KB. Đây là tỷ lệ chuyển đổi của tôi cho RCU là bốn kilobyte. 

OK, chúng ta hãy đi với cuối cùng nhất quán đọc. Tôi vẫn còn đang ăn 1600 RCU của chỉ để đọc hộp thư của David. Ouch. OK, bây giờ hãy nghĩ về cách ứng dụng hoạt động. 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, 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. Tôi đang nhìn vào chỉ tiêu đề. Vì vậy, hãy xây dựng một cấu trúc bảng trông giống như thế. 

Vì vậy, đây là những thông tin rằng công việc của tôi cần. Đó là trong hộp thư đến của tôi GSI. Đó là ngày tháng, người gửi, các đối tượng, và sau đó ID tin nhắn, mà điểm trở lại với những thông điệp bảng nơi mà tôi có thể có được cơ thể. Vâng, sẽ có những IDs kỷ lục. Họ sẽ chỉ trở lại ID mục trên bảng Dynamo DB. Mỗi chỉ số luôn creates-- luôn luôn có hàng ID như là một phần of-- đó đi kèm với các chỉ số. 

Được rồi. Đung Nó nói với nó, nơi nó được lưu trữ? RICK Houlihan: Vâng, nó cho exactly-- đó là chính xác những gì nó. Nó nói ở đây là hồ sơ của tôi lại. Và nó sẽ chỉ cho nó trở lại để ghi lại của tôi. Chính xác. OK, vì vậy bây giờ hộp thư của tôi là thực sự nhỏ hơn nhiều. 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. Vì vậy, hộp thư của tôi, tôi bấm. 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ể, bởi vì tôi sẽ đến đi đến một quan điểm khác nhau. Vì vậy, nếu bạn nghĩ về MVC loại khuôn khổ, mô hình điều khiển xem. 

Mô hình này có chứa các dữ liệu mà nhu cầu xem và bộ điều khiển tương tác với. Khi tôi thay đổi khung hình, khi Tôi thay đổi quan điểm, đó là OK để quay trở lại máy chủ và phục hồi lại các mô hình, bởi vì đó là những gì người dùng mong đợi. Khi họ thay đổi quan điểm, đó là khi chúng ta có thể quay trở lại cơ sở dữ liệu. Vì vậy, email, nhấn chuột. Tôi đang tìm kiếm cho cơ thể. Khư hôi. Về nhận được cơ thể. 

Tôi đọc dữ liệu ít hơn rất nhiều. Tôi chỉ đọc cơ mà David cần khi anh ta cần họ. Và tôi không ghi năm 1600 RCU của chỉ để hiển thị hộp thư đến của mình. Vì vậy bây giờ that-- đây là cách mà LSI hoặc GSI-- Tôi xin lỗi, GSI, sẽ làm việc ra. Chúng tôi đã có hash của chúng tôi trên người nhận. Chúng tôi đã có chìa khóa loạt vào ngày tháng. Và chúng tôi đã có các thuộc tính dự chúng ta chỉ cần để ủng hộ quan điểm. 

Chúng tôi xoay mà cho hộp thư đi. Băm trên người gửi. Và trong bản chất, chúng ta có các, nhìn sạch sẽ rất tốt đẹp. Và nó basically-- chúng tôi có các tin nhắn này tốt đẹp bảng đó được lan truyền độc đáo vì nó chỉ băm, băm ID tin nhắn. Và chúng tôi có hai chỉ số đó được quay off của bảng đó. 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 bên nhau. Phân vùng theo chiều dọc, phân vùng những bảng. Đừng đọc dữ liệu bạn không phải. Được rồi, chơi game. Chúng ta đều thích trò chơi. Ít nhất là tôi thích trò chơi sau đó. Vì vậy, một số trong những điều mà chúng ta đối phó với khi chúng tôi đang suy nghĩ về chơi game, phải không? 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. Và tôi sẽ xoay ở đây một chút chút xa DynamoDB. Tôi sẽ mang lại một số cuộc thảo luận xung quanh một số công nghệ AWS khác. 

Nhưng ý tưởng về chơi game là để suy nghĩ về về các API, API mà, nói chung, HTTP và JSON. Đó là cách trò chơi di động loại tương tác với đầu trở lại của họ. Họ làm JSON gửi bài. Họ có được dữ liệu, và đó là tất cả, Nói chung, trong các API JSON đẹp. 

Những điều như thế có được bạn bè, nhận các dữ liệu bảng dẫn, trao đổi, người dùng tạo ra nội dung, đẩy trở lại vào hệ thống, đây là những loại của sự vật rằng chúng tôi đang đi làm. 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. Điều này có thể ngồi trong một cửa hàng đối tượng, đúng không? Nhưng các cơ sở dữ liệu sẽ kết thúc lên nói cho hệ thống, nói với các ứng dụng đi đâu có được nó. Và chắc chắn, nhiều người máy chủ, cơ sở hạ tầng kết thúc trở lại, và được thiết kế cho cao sẵn có và khả năng mở rộng. 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. 

Vì vậy, chúng ta hãy nhìn vào gì đó trông như thế nào. Có một kết thúc trở lại cốt lõi, rất đơn giản. Chúng tôi đã có một hệ thống ở đây với nhiều khu vực sẵn có. 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. Trung tâm nhiều hơn một dữ liệu mỗi AZ, nhưng đó là OK, chỉ cần nghĩ về chúng như dữ liệu riêng biệt các trung tâm địa lý và lỗi cô lập. 

Chúng ta sẽ có một trường hợp vài EC2. Chúng ta sẽ có một số máy chủ kết thúc trở lại. Có lẽ nếu bạn là một di sản kiến trúc, chúng tôi sử dụng những gì chúng ta gọi RDS, dịch vụ cơ sở dữ liệu quan hệ. Có thể là MSSQL, MySQL, hay đại loại thế. Đây là cách một ứng dụng rất nhiều được thiết kế ngày nay. 

Vâng, chúng tôi có thể muốn đi với này là khi chúng ta quy mô ra. Chúng tôi sẽ đi trước và đặt xô S3 lên đó. Và đó xô S3, thay vì phục vụ lên những đối tượng từ servers-- của chúng tôi chúng ta có thể làm điều đó. 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 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. Nhưng đó là khá tốn kém. 

Cách tốt hơn để làm là đi trước và đưa những đối tượng trong một xô S3. S3 là một kho đối tượng. Nó được xây dựng riêng cho phục vụ tối đa các loại của sự vật. Và để cho những khách hàng yêu cầu trực tiếp từ những xô đối tượng, giảm tải các máy chủ. Vì vậy, chúng tôi đang bắt đầu mở rộng ra ở đây. 

Bây giờ chúng tôi đã sử dụng tất cả các nơi trên thế giới. Tôi có người sử dụng. 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? Tôi đã tạo ra một xô S3 là kho lưu trữ nguồn của tôi. Và tôi sẽ ở mặt trận này với sự phân bố CloudFront. 

CloudFront là một CD và một mạng phân phối nội dung. Về cơ bản nó mất dữ liệu mà bạn chỉ định và lưu trữ nó trên internet 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 họ yêu cầu các đối tượng. 

Vì vậy, bạn sẽ có được một ý tưởng. 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. Và cuối cùng, chúng ta vứt trong một nhóm tự động mở rộng quy mô. 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, khi họ bắt đầu để có được bận rộn và bận rộn và bận rộn, họ sẽ chỉ quay khác Chẳng hạn, quay dụ khác, quay dụ khác. Vì vậy, các công nghệ AWS có, nó cho phép bạn chỉ định các thông số xung quanh mà các máy chủ của bạn sẽ phát triển. 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. Và nếu tải của bạn đi xa, họ sẽ thu nhỏ, số lượng sẽ giảm. Và nếu nạp trở lại, nó sẽ mọc trở lại ra ngoài, đàn hồi. 

Vì vậy, đây sẽ rất tốt. Chúng tôi đã có rất nhiều trường hợp EC2. Chúng tôi có thể đặt trong bộ nhớ cache phía trước của cơ sở dữ liệu, cố gắng và thúc đẩy các cơ sở dữ liệu. Các điểm áp lực tiếp theo thường mọi người nhìn thấy 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ệ. Jeez, cơ sở dữ liệu hiệu suất là khủng khiếp. Làm thế nào để chúng tôi cải thiện điều đó? Hãy thử đặt bộ nhớ cache trước đó. 

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? Đối với trò chơi, viết là đau đớn. Trò chơi được rất viết nặng. Bộ nhớ cache không hoạt động khi bạn viết nặng vì bạn đã luôn luôn đã cập nhật bộ nhớ cache. Bạn cập nhật bộ nhớ cache, đó là không liên quan đến bộ nhớ đệm được. Nó thực sự chỉ phụ việc. 

Vì vậy, nơi chúng tôi đi đây? Bạn đã có một nút cổ chai lớn xuống có trong cơ sở dữ liệu. Và là nơi để đi rõ ràng là phân vùng. Phân vùng đĩa không dễ dàng để làm khi bạn đang đối phó với cơ sở dữ liệu quan hệ. Với cơ sở dữ liệu quan hệ, bạn trách nhiệm quản lý, có hiệu quả, các không gian chính. Bạn đang nói người sử dụng giữa A và M đi ở đây, giữa N và Z đến đó. Và bạn đang chuyển qua các ứng dụng. Vì vậy, bạn đang đối phó với nguồn dữ liệu này phân vùng. Bạn có những hạn chế giao dịch mà không trải rộng phân vùng. Bạn đã có tất cả các loại hỗn độn mà bạn đối phó với giảm có cố gắng để đối phó với nhân rộng ra và xây dựng một cơ sở hạ tầng lớn. Nó chỉ là không có niềm vui. 

Đung Vì vậy, bạn nói rằng tăng điểm nguồn tăng tốc quá trình? RICK Houlihan: Tăng? Điểm Nguồn: Đung. RICK Houlihan: Nguồn điểm? Đung Từ những thông tin, nơi thông tin được đến từ đâu? RICK Houlihan: No. 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 cải thiện thông. Vì vậy, những gì đang xảy ra ở đây là người dùng đi vào EC2 lên ở đây, tốt, nếu tôi cần một người sử dụng đó là A đến M, tôi sẽ đi đây. Từ N đến p, tôi sẽ đi đây. Từ P đến Z, tôi sẽ đi đây. 

Đ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? 

RICK Houlihan: Yes. Hãy nghĩ về những như silo dữ liệu khác nhau. Vì vậy, bạn phải làm điều này. Nếu bạn đang cố gắng để làm này, nếu bạn đang cố gắng quy mô trên một nền tảng quan hệ, đây là những gì bạn đang làm. Bạn đang dùng dữ liệu và bạn sẽ làm giảm xuống. 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. Và bạn đang quản lý tất cả những gì tại tầng ứng dụng. Đó là không có niềm vui. Vì vậy, những gì chúng ta muốn đi đâu? 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. Chúng tôi sử dụng chỉ số phụ. Đó là cơ bản HTTP API và bao gồm hỗ trợ tài liệu. Vì vậy, bạn không phải lo lắng về bất kỳ phân vùng đó. Chúng tôi làm tất cả cho bạn. Vì vậy, bây giờ, thay vào đó, bạn chỉ cần ghi vào bảng. Nếu một bảng cần được phân chia, điều đó xảy ra đằng sau hậu trường. Bạn đang hoàn toàn cách ly từ đó như là một nhà phát triển. Vì vậy, chúng ta hãy nói về một số các trường hợp sử dụng rằng chúng tôi chạy vào trong game, phổ biến kịch bản game, dẫn. Vì vậy, bạn đã có người đến, các BoardNames rằng họ đang trên, điểm số cho người dùng này. 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. Vì vậy, mỗi người dùng muốn xem tất cả các trò chơi anh ta đã chơi và tất cả các điểm cao của mình trên tất cả các trò chơi. Vì vậy, đó là bảng dẫn cá nhân của mình. 

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. 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. Vì vậy, làm thế nào để làm điều đó? Khi hồ sơ của tôi được băm trên UserID, dao động trên các trò chơi, cũng tôi sẽ đi trước và cơ cấu lại, tạo ra một GSI, và tôi sẽ phải cơ cấu lại dữ liệu đó. 

Bây giờ tôi sẽ để băm trên BoardName, đó là trò chơi. Và tôi sẽ nằm trong khoảng trên điểm cao nhất. Và bây giờ tôi đã tạo ra xô khác nhau. Tôi đang sử dụng cùng một bảng, các dữ liệu cùng một mục. 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. 

Và tôi có thể truy vấn bảng để có được thông tin đó. 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ứ. 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. 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. 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. 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. Chỉ số thưa thớt là khả năng tạo một chỉ số đó không nhất thiết chứa mọi hàng hoá trên bàn. Và tại sao không? 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. 

Vì vậy, trong này đặc biệt sử dụng trường hợp, tôi nói, 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. 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. Người sử dụng mà không có giải thưởng là sẽ không có thuộc tính đó. Vì vậy, khi tôi tạo các chỉ số, người sử dụng chỉ mà sẽ hiển thị trong danh mục được những cái mà thực sự đã giành được giải thưởng. Vì vậy, đó là một cách tuyệt vời để có thể để tạo ra các chỉ lọc mà rất, rất chọn lọc mà không làm phải chỉ số toàn bộ bảng. 

Vì vậy, chúng tôi đang nhận được thấp về thời gian ở đây. Tôi sẽ đi trước và bỏ qua ra và bỏ qua kịch bản này. Nói chuyện một chút about-- 

Đung Tôi có thể hỏi một câu hỏi nhanh chóng? Một là viết nặng? RICK Houlihan: là gì? Đung Viết nặng. RICK Houlihan: Viết nặng. Để tôi xem. 

Đung Hoặc là không phải một cái gì đó bạn có thể chỉ giọng nói để trong vài giây? RICK Houlihan: Chúng tôi đi thông qua các kịch bản có quyền biểu quyết. Nó không tệ. Do you guys có một vài phút? ĐƯỢC. 

Vì vậy, chúng ta sẽ nói về bỏ phiếu. 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. 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. Chúng tôi muốn không ai để có thể thay đổi phiếu bầu của họ. 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 rằng chúng ta sẽ có hiển thị cho người dùng trên trang web. 

Hãy suy nghĩ về kịch bản này. 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 làm các loại chính xác của sự vật. 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 cô gái tuổi teen có với các điện thoại di động của họ và bỏ phiếu, và bỏ phiếu, và bỏ phiếu cho họ là ai thấy là phổ biến nhất. Vì vậy đây là một số các yêu cầu chúng tôi chạy ra ngoài. 

Và do đó, lần đầu tiên đưa trong việc giải quyết vấn đề này là xây dựng một ứng dụng rất đơn giản. Vì vậy, tôi đã có ứng dụng này. Tôi có một số cử tri ra khỏi đó. Họ đi vào, họ nhấn ứng dụng có quyền biểu quyết. Tôi đã có một số bảng votes liệu Tôi sẽ chỉ đổ những phiếu vào. Tôi sẽ có một số tổng hợp bảng phiếu mà 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 đó. 

Và điều này là rất tốt. Cuộc sống là tốt. 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 người đó được phổ biến trong một cuộc bầu cử. Có người chỉ có một hoặc hai điều mà mọi người thực sự quan tâm. 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 sẽ được búa địa ngục ra khỏi Hai ứng cử viên, một hoặc hai ứng cử viên. 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. 

Đây không phải là một mẫu thiết kế tốt. Đây thực sự là một mẫu thiết kế rất xấu 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. Phím nóng là một cái gì đó chúng ta không thích. 

Vì vậy, làm thế nào để chúng tôi khắc phục điều đó? 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 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, một cái gì đó mà chúng ta biết, ngẫu nhiên giá trị từ một đến 100, giữa 100 và 1000, hoặc giữa một và 1000, 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. 

Và những gì đã tôi thực sự thực hiện sau đó? Nếu tôi đang sử dụng các ứng cử viên như ID xô đến phiếu tổng hợp, nếu tôi đã thêm một ngẫu nhiên số để kết thúc đó, Tôi đã tạo ra hiện nay 10 xô, một trăm xô, một ngàn thùng mà tôi đang tổng hợp số phiếu ngang qua. 

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 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 Ứng viên qua A_100, vì mỗi khi một cuộc bỏ phiếu đến, Tôi là tạo ra một cách ngẫu nhiên giá trị từ một đến 100. Tôi tacking nó vào cuối ứng cử viên là người của bầu cho. Tôi đang đổ vào thùng đó. 

Bây giờ trên mặt sau, tôi biết rằng tôi có một trăm thùng. Vì vậy, khi tôi muốn đi trước và tổng hợp các phiếu bầu, Tôi đọc từ tất cả những xô. Vì vậy, tôi đi trước và thêm. 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, 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. Tôi sẽ thu thập tất cả các phiếu từ những trăm xô. Tôi sẽ tổng hợp họ và tôi sẽ nói, Ứng cử viên A hiện có tổng số phiếu bầu của x. 

Bây giờ cả viết truy vấn và truy vấn đọc được phân phối độc đáo bởi vì tôi đang viết trên và tôi đọc qua hàng trăm phím. Tôi không viết và đọc qua một trong những trọng điểm bây giờ. Vì vậy, đó là một mô hình tuyệt vời. 

Điều này thực sự có lẽ là một của thiết kế quan trọng nhất mô hình quy mô trong NoSQL. Bạn sẽ thấy kiểu này mẫu thiết kế trong từng hương vị. MongoDB, DynamoDB, nó không vấn đề, tất cả chúng ta phải làm điều này. Bởi vì khi bạn đang làm việc với những quy tụ rất lớn, bạn phải tìm ra một cách để trải chúng ra khắp xô. Vì vậy, đây là cách bạn làm điều đó. Được rồi, vì vậy những gì bạn đang làm ngay bây giờ là bạn đang kinh doanh tắt đọc chi phí cho ghi khả năng mở rộng. Các chi phí của tôi là đọc một chút phức tạp hơn và tôi phải đi đọc từ một trăm xô thay vì một. Nhưng tôi có thể viết. Và thông của tôi, tôi viết thông qua là không thể tin được. Vì vậy, nó thường là một giá trị kỹ thuật cho rộng DynamoDB, hoặc bất kỳ cơ sở dữ liệu NoSQL cho rằng vấn đề. Vì vậy, chúng tôi đã tìm ra cách để mở rộng nó. Và chúng tôi đã tìm cách loại bỏ các phím nóng của chúng tôi. Và điều này là tuyệt vời. Và chúng tôi có hệ thống tốt đẹp này. 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. Nó được xây dựng vào DynamoDB. Chúng tôi nói về quyền có điều kiện. 

Khi một cử tri đến, puts một chèn trên bàn, họ chèn với ID cử tri của họ, nếu họ cố gắng để chèn bỏ phiếu khác, Tôi làm một ghi điều kiện. Chỉ nói viết này nếu điều này không tồn tại. Vì vậy, ngay sau khi tôi thấy rằng rằng lá phiếu của hit bảng, không ai khác sẽ là có thể đưa vào lá phiếu của họ trong. Và đó là tuyệt vời. Và chúng tôi đang incrementing quầy ứng cử viên của chúng tôi. 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 đó. Nhưng điều gì sẽ xảy ra nếu tôi ứng dụng ngã xuống? Bây giờ tất cả của một đột ngột phiếu đang đến, và tôi 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 nữa không. Và khi các ứng dụng trở lại lên, làm thế nào 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? 

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. Và làm thế nào để chúng ta giải quyết đó? Chúng tôi giải quyết nó với những gì chúng tôi gọi DynamoDB Streams. 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 để bàn, mỗi viết truy cập vào bảng. Bất kỳ dữ liệu đó bằng văn bản cho bảng hiển thị lên trên suối. 

Đó là cơ bản một hàng đợi 24 giờ. Items nhấn suối, họ sống trong 24 giờ. Họ có thể được đọc nhiều lần. Đảm bảo sẽ được chuyển giao chỉ một lần cho các dòng, có thể được đọc số n lần. 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ó. Nó sẽ xuất hiện mỗi khi cập nhật. Mỗi write sẽ chỉ xuất hiện một lần trên suối. Vì vậy, bạn không phải lo lắng về chế biến nó hai lần từ cùng một quá trình. 

Nó ra lệnh nghiêm chỉnh cho mỗi mục. Khi chúng ta nói thời gian đặt hàng và phân vùng, bạn sẽ thấy mỗi phân vùng trên suối. Bạn sẽ thấy các mục, cập nhật theo thứ tự. Chúng tôi không đảm bảo trên dòng suối mà bạn sẽ nhận được mỗi giao dịch theo thứ tự trên các mặt hàng. 

Vì vậy, dòng suối có idempotent. Tất cả chúng ta biết những gì idempotent nghĩa? Idempotent có nghĩa là bạn có thể làm điều đó hơn, và hơn, và hơn nữa. Kết quả sẽ được như vậy. 

Streams là idempotent, nhưng chúng phải được chơi từ điểm khởi đầu, bất cứ nơi nào bạn chọn, để kết thúc, hoặc họ sẽ không kết quả trong cùng một giá trị. 

Cùng một điều với MongoDB. MongoDB có một cấu trúc họ gọi là oplog. Nó là giống cấu trúc chính xác. Nhiều cơ sở dữ liệu NoSQL có cấu trúc này. Họ sử dụng nó để làm những việc như sao chép, mà là chính xác những gì chúng tôi làm với suối. Đung Có lẽ một câu lạc giáo, nhưng bạn nói về các ứng dụng làm ngã một vv. Được luồng đảm bảo không bao giờ có thể đi xuống? RICK Houlihan: Yeah, suối được đảm bảo để không bao giờ đi xuống. Chúng tôi quản lý cơ sở hạ tầng phía sau. suối tự động triển khai trong nhóm tự động mở rộng quy mô của họ. Chúng tôi sẽ đi qua một chút chút về những gì sẽ xảy ra. 

Tôi không cần biết họ không đảm bảo không bao giờ đi xuống. Các yếu tố được đảm bảo để xuất hiện trong các dòng suối. Và dòng sẽ có thể truy cập. 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. Nó covers-- đó là OK. 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. Các loại điểm quan trọng đối với một lập trình thường được, đó là gì? Tôi có được quan điểm cũ. 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 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 quản lý. 

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 bạn có thể làm được. Bạn có thể nhận được cả những hình ảnh cũ và mới. Có lẽ tôi muốn cả hai. Tôi muốn nhìn thấy những gì nó được. Tôi muốn nhìn thấy những gì nó đã thay đổi tới. 

Tôi có một loại tuân thủ của quá trình mà chạy. Nó cần phải xác minh rằng khi những điều thay đổi, rằng họ đang trong giới hạn nhất định hoặc trong các thông số nhất định. 

Và sau đó có lẽ tôi chỉ cần phải biết những gì thay đổi. Tôi không quan tâm những gì mục thay đổi. Tôi không cần phải cần biết những gì thuộc tính thay đổi. Tôi chỉ cần biết rằng các mặt hàng đang được xúc động. Vì vậy, đây là những loại quan điểm mà bạn có được ra khỏi dòng và bạn có thể tương tác với. 

Các ứng dụng mà tiêu thụ các dòng, đây là loại cách làm việc này. DynamoDB khách hàng yêu cầu đẩy dữ liệu vào các bảng. Streams triển khai trên những gì chúng ta gọi là những mảnh vỡ. Shards được thu nhỏ độc lập của bảng. 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. Và lý do tại sao vì họ xếp hàng để công suất, hiện nay công suất của bảng. 

Họ triển khai trong họ riêng nhóm tự động mở rộng quy mô, và họ bắt đầu quay ra phụ thuộc bao nhiêu viết được đến, bao nhiêu reads-- thực sự nó viết. Không có reads-- nhưng làm thế nào nhiều viết được đến ở. 

Và sau đó trên lưng kết thúc, chúng tôi có những gì chúng tôi gọi một KCL, hoặc Kinesis Thư viện Client. Kinesis là một dòng dữ liệu công nghệ chế biến từ Amazon. Và suối được xây dựng trên đó. 

Vì vậy, bạn sử dụng một KCL kích hoạt ứng dụng để đọc những dòng. Các thư viện khách Kinesis thực quản lý lao động cho bạn. Và nó cũng làm một số những điều thú vị. Nó sẽ tạo ra một số bảng lên trong tablespace DynamoDB của bạn để theo dõi các mục đã được xử lý. 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 đứng dậy, nó có thể xác định nơi là nó trong chế biến các dòng. 

Điều đó rất quan trọng khi bạn đang nói về nhân rộng. Tôi cần phải biết những gì dữ liệu đã được xử lý và những dữ liệu vẫn chưa được xử lý. 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 đó. Nó sẽ chăm sóc của tất cả các cửa. Nó đứng dậy một công nhân cho mỗi mảnh. Nó tạo ra một bảng hành chính cho mỗi mảnh, cho mỗi người lao động. Và như những công nhân cháy, họ duy trì các bảng vì vậy bạn có biết hồ sơ này được đọc và xử lý. Và sau đó theo cách đó nếu tiến trình chết và trở lại trực tuyến, nó có thể tiếp tục bên phải, nơi nó cất cánh. 

Vì vậy, chúng tôi sử dụng này cho cross-khu vực rộng. 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ọ xung quanh các vùng khác nhau. Có chín vùng vòng quanh thế giới. 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 ở bờ biển phía Đông của Hoa Kỳ. Họ có dữ liệu khác nhau cần được phân phối tại địa phương. Và có lẽ một người sử dụng bay từ Á sang Hoa Kỳ, và tôi muốn nhân rộng dữ liệu của mình với anh ta. 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. 

Bạn có thể sử dụng cross-khu vực thư viện nhân rộng để làm điều này. Về cơ bản chúng tôi có cung cấp hai công nghệ. 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. Nó chạy nhân bản thuần túy. Và sau đó chúng tôi đã cho bạn thư viện. 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 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ó, xoay dữ liệu, di chuyển nó thành một bảng khác nhau, vv và vv. Vì vậy, đó là loại gì đó trông như thế nào. 

DynamoDB Streams thể xử lý bởi những gì chúng ta gọi là Lambda. 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. Lambda là một thành phần quan trọng của điều đó. Lambda là mã mà bắn theo yêu cầu để đáp ứng với một sự kiện đặc biệt. Một trong những sự kiện có thể là một kỷ lục xuất hiện trên suối. 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. Vâng, đây là JavaScript, và Lambda hỗ trợ Node.js, Java, Python, và sẽ sớm hỗ trợ các ngôn ngữ khác. Và đủ để nói, đó là mã tinh khiết. viết Trong Java, bạn định nghĩa một lớp. Bạn đẩy JAR thành Lambda. Và sau đó bạn chỉ định lớp gọi để đáp ứng với sự kiện đó. Và sau đó các cơ sở hạ tầng Lambda đằng sau đó sẽ chạy mã. 

Mã mà có thể xử lý hồ sơ ra khỏi dòng. Nó có thể làm bất cứ điều gì nó muốn với nó. 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. Nhưng đây chỉ là code. Mã có thể làm bất cứ điều gì, phải không? 

Vì vậy, bạn có thể xoay dữ liệu đó. Bạn có thể tạo ra một cái nhìn phái sinh. 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. Bạn có thể tạo các chỉ mục thay thế. Tất cả mọi thứ bạn có thể làm với Streams DynamoDB. 

Và thực sự, đó là những gì mà trông như thế nào. Vì vậy, bạn sẽ có được những bản cập nhật sắp tới trong. Họ đang sắp tắt chuỗi. Họ đang đọc bởi chức năng Lambda. Họ đang quay các dữ liệu và đẩy nó lên trong bảng phái sinh, 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. 

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à kịch bản. Vâng những gì sẽ xảy ra nếu tôi cập nhật mô tả mục? Vâng, nếu tôi đã có một Lambda chức năng chạy trên bàn đó, 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, và nó sẽ cập nhật các ElastiCache Ví dụ với các dữ liệu mới. Vì vậy, đó là rất nhiều những gì chúng tôi làm với Lambda. Đó là mã keo, kết nối. Và nó thực sự mang đến khả năng khởi động 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 cơ sở hạ tầng, mà là thực sự mát mẻ. 

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. Đ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. Giống như trước, chúng ta có thể xử lý bất kỳ quy mô của cuộc bầu cử. Chúng tôi thích điều này. Chúng tôi đang làm ra tập hợp phân tán trên nhiều xô. Chúng tôi đã có khóa lạc xảy ra. 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ọ. Họ chỉ có thể bỏ phiếu một lần duy nhất. Điều này là tuyệt vời. 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. Nếu điều ngã xuống, nó biết nơi để tự khởi động lại khi nó trở lại lên vì chúng ta đang sử dụng ứng dụng KCL. Và sau đó, chúng tôi cũng có thể sử dụng Ứng dụng KCL để đẩy dữ liệu ra để dịch chuyển đỏ cho khác phân tích ứng dụng, hoặc sử dụng các MapReduce đàn hồi để chạy thời gian thực trực tuyến quy tụ off của dữ liệu đó. 

Vì vậy, đây là những điều chúng tôi đã không nói về nhiều. Nhưng họ đang thêm công nghệ mà đi chịu khi bạn đang tìm kiếm ở các loại kịch bản. 

Được rồi, vì vậy đó là khoảng phân tích với DynamoDB Streams. Bạn có thể thu thập de-dupe dữ liệu, làm tất cả các loại 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. Đó là một trường hợp sử dụng lớn mà rất nhiều khách hàng được tham gia với, lấy lồng nhau tính chất của những tài liệu JSON và tạo chỉ mục bổ sung. 

Chúng tôi đang ở cuối. Cảm ơn bạn đã mang với tôi. Vì vậy, chúng ta hãy nói về kiến trúc tham khảo. DynamoDB ngồi ở giữa nên nhiều cơ sở hạ tầng AWS. Về cơ bản bạn có thể treo nó lên đến bất cứ điều gì bạn muốn. Các ứng dụng được xây dựng sử dụng Dynamo bao gồm Lambda, ElastiCache, CloudSearch, đẩy dữ liệu ra vào Elastic MapReduce, xuất khẩu, nhập khẩu từ DynamoDB vào S3, tất cả các loại công việc. Nhưng có lẽ là tốt nhất điều để nói về, và đây là những gì thực sự thú vị là khi chúng ta nói về các ứng dụng hướng sự kiện. 

Đây là một ví dụ về một dự án nội bộ 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. Vì vậy, trong một liên kết email chúng tôi gửi đi, sẽ thấy có 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. Và khi một người nhấp chuột liên kết đó, những gì sẽ xảy ra là họ kéo xuống một an toàn Mẫu khảo sát HTML từ S3. Không có máy chủ. Đây chỉ là một đối tượng S3. 

Hình thức mà đi lên, tải lên trong trình duyệt. Nó có Backbone. Nó có JavaScript phức tạp rằng nó đang chạy. 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. 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. Tại thời điểm này, đó là tất cả trình duyệt. 

Họ công bố kết quả những gì chúng ta gọi là Amazon API Gateway. API Gateway chỉ đơn giản là một API web mà bạn có thể xác định và treo lên để bất cứ điều gì bạn muốn. Trong trường hợp này, chúng tôi nối với một chức năng Lambda. 

Vì vậy, hoạt động POST của tôi là xảy ra không có máy chủ. Về cơ bản đó API Gateway ngồi ở đó. 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? Các chức năng Lambda chỉ ngồi ở đó. Và chi phí cho đến khi tôi không có gì mọi người bắt đầu đánh nó. 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. Tôi không chạy một máy chủ 7/24. 

Vì vậy, tôi kéo các hình thức xuống ngoài những xô, và tôi gửi thông qua các API Cổng vào hàm Lambda. Và sau đó là Lambda chức năng cho biết, bạn biết những gì, tôi đã có một số PIIs, một số thông tin cá nhân trong các phản ứng. Tôi có ý kiến ​​đến từ người sử dụng. Tôi đã có địa chỉ email. Tôi đã có tên người dùng. 

Hãy để tôi chia này off. Tôi sẽ tạo ra một số metadata tắt hồ sơ này. Và tôi sẽ đẩy siêu dữ liệu vào DynamoDB. 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. 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, Tôi sẽ đẩy các dữ liệu thô vào một xô S3 được mã hóa. 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 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, 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. 

Vì vậy, tôi đã làm được những gì? Tôi vừa mới triển khai toàn bộ ứng dụng, và tôi không có máy chủ. 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. 

Bây giờ nếu bạn suy nghĩ về các trường hợp sử dụng cho this-- 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 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. Bởi vì bây giờ, họ có thể về cơ bản đẩy nó ra khỏi đó, để cho chiến dịch đó chỉ cần ngồi đó cho đến khi nó ra mắt, và không phải lo lắng về một vả loại cơ sở hạ tầng là có được ở đó để hỗ trợ nó. Và sau đó càng sớm càng chiến dịch đó được thực hiện, nó giống như các cơ sở hạ tầng chỉ ngay lập tức biến mất bởi vì có thực sự là không có cơ sở hạ tầng. Nó chỉ là mã mà ngồi trên Lambda. Nó chỉ là dữ liệu mà ngồi trong DynamoDB. Đó là một cách tuyệt vời để xây dựng các ứng dụng. 

Đung vậy là nó nhiều hơn phù du hơn nó sẽ là nếu nó được lưu trữ trên một máy chủ thực sự? 

RICK Houlihan: Tuyệt đối. Bởi vì đó ví dụ máy chủ sẽ phải là một 7/24. Nó có phải là có sẵn cho ai đó để đáp ứng. Cũng đoán những gì? S3 có sẵn 7/24. S3 luôn đáp ứng. Và S3 là rất, rất tốt ở phục vụ các đối tượng. 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. 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. 

Và đó là những ý tưởng ở đây là để có được đi từ đường chúng ta sử dụng để suy nghĩ về nó. Tất cả chúng ta sử dụng để suy nghĩ về máy chủ và máy chủ. Nó không phải về điều đó nữa. Đó là về cơ sở hạ tầng như mã. Triển khai các mã cho các đám mây và thả mây chạy nó cho bạn. Và đó là những gì AWS đang cố gắng làm. 

Đ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ư, nhưng thay vào đó là just-- 

RICK Houlihan: Bạn có thể nghĩ của nó là server mặt tiền. 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. Đó là tất cả nó. 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. Được rồi, vì vậy đó là tất cả tôi nhận. Cảm ơn nhiều. Tôi đánh giá cao nó. Tôi biết chúng tôi muốn có một chút thời gian. Và hy vọng bạn guys có một chút thông tin mà bạn có thể lấy đi ngày hôm nay. Và tôi xin lỗi nếu tôi đã đi qua một số người đứng đầu của bạn, nhưng có rất nhiều tốt đẹp của kiến thức nền tảng cơ bản mà tôi nghĩ là rất có giá trị cho bạn. Vì vậy, cảm ơn bạn đã mời tôi. [Vỗ tay] Đung [Không nghe thấy] là khi bạn đang nói bạn đã phải trải qua những điều từ đầu đến cuối để có được những giá trị đúng hoặc cùng một giá trị, như thế nào sẽ các giá trị thay đổi nếu [không nghe được]. 

RICK Houlihan: Oh, idempotent? Làm thế nào các giá trị sẽ thay đổi? 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, 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. Nó sẽ không phải là cùng một dữ liệu như những gì tôi đã thấy. Đung Oh, vì vậy bạn chỉ đã không nhận toàn bộ đầu vào. RICK Houlihan: Đúng vậy. Bạn phải đi từ đầu đến cuối, và sau đó nó sẽ là một nhà nước thống nhất. Mát. 

Đ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. 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 để lật nó xung quanh. 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? 

RICK Houlihan: Tôi sẽ không nói để lại đằng sau nó. 

Đung Họ đã được tách ra từ the-- 

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 là chỉ nghĩ đến như là thuộc tính khác. Đó là một thuộc tính có chứa một cấu trúc dữ liệu phân cấp. Và sau đó trong các truy vấn, bạn có thể sử dụng các thuộc tính của các đối tượng sử dụng Object Notation. 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. Đung Vì vậy, bất kỳ thời gian tôi làm một phương pháp tài liệu, Tôi có thể loại đến các tabular-- Đung Tuyệt đối. Đung --indexes và những điều bạn vừa nói đến. RICK Houlihan: Yeah, chỉ số và tất cả đó, khi bạn muốn chỉ mục tính chất của các JSON, 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 Dynamo vào, bạn sẽ sử dụng các dòng. Streams sẽ đọc đầu vào. Bạn muốn nhận được rằng JSON phản đối và bạn muốn nói OK, các tài sản tôi muốn chỉ mục là gì? 

Bạn tạo một bảng dẫn xuất. Bây giờ đó là cách nó hoạt động ngay bây giờ. 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. 

Đung Tabularizing tài liệu của bạn. 

RICK Houlihan: Chính xác, làm phẳng nó, tabularizing nó, chính xác. Đó là những gì bạn làm với nó. 

Đung Cảm ơn bạn. 

RICK Houlihan: Yep, hoàn toàn, cảm ơn bạn. Đung Vì vậy, nó là loại Mongo đáp ứng Redis classifers. 

RICK Houlihan: Yeah, đó là rất nhiều như thế. Đó là một mô tả tốt cho nó. Mát.