1 00:00:00,000 --> 00:00:04,969 >> [MUSIC PLAYING] 2 00:00:04,969 --> 00:00:06,010 RICK Houlihan: Baiklah. 3 00:00:06,010 --> 00:00:06,600 Hai semuanya. 4 00:00:06,600 --> 00:00:07,670 Nama saya Rick Houlihan. 5 00:00:07,670 --> 00:00:10,330 Aku prinsipal senior solusi arsitek di AWS. 6 00:00:10,330 --> 00:00:14,070 Saya fokus pada NoSQL dan Teknologi DynamoDB. 7 00:00:14,070 --> 00:00:16,930 Aku di sini hari ini untuk berbicara dengan Anda sedikit tentang mereka. 8 00:00:16,930 --> 00:00:18,970 >> Latar belakang saya adalah terutama di lapisan data. 9 00:00:18,970 --> 00:00:21,390 Aku menghabiskan setengah perkembangan saya karir menulis database 10 00:00:21,390 --> 00:00:25,930 akses data, solusi untuk berbagai aplikasi. 11 00:00:25,930 --> 00:00:30,000 Aku sudah dalam virtualisasi Cloud selama sekitar 20 tahun. 12 00:00:30,000 --> 00:00:33,460 Jadi sebelum Cloud adalah Cloud, kami biasa menyebutnya komputasi utilitas. 13 00:00:33,460 --> 00:00:37,170 Dan ide itu, itu seperti PG & E, Anda membayar untuk apa yang Anda gunakan. 14 00:00:37,170 --> 00:00:38,800 Hari ini kita menyebutnya awan. 15 00:00:38,800 --> 00:00:41,239 >> Tapi selama bertahun-tahun, saya telah bekerja untuk beberapa perusahaan 16 00:00:41,239 --> 00:00:42,530 Anda mungkin pernah mendengar tentang. 17 00:00:42,530 --> 00:00:47,470 Tapi aku sudah menyusun daftar teknis prestasi, saya kira Anda akan mengatakan. 18 00:00:47,470 --> 00:00:51,620 Saya memiliki delapan paten di sistem Cloud virtualisasi, desain mikroprosesor, 19 00:00:51,620 --> 00:00:54,440 pengolahan event yang kompleks, dan daerah lainnya juga. 20 00:00:54,440 --> 00:00:58,290 >> Jadi hari ini, aku lebih sering fokus pada NoSQL teknologi dan generasi berikutnya 21 00:00:58,290 --> 00:00:59,450 Database. 22 00:00:59,450 --> 00:01:03,370 Dan itu umumnya apa yang akan saya berada di sini berbicara kepada Anda hari ini tentang. 23 00:01:03,370 --> 00:01:06,030 Jadi apa yang dapat Anda harapkan dari sesi ini, 24 00:01:06,030 --> 00:01:08,254 kita akan pergi melalui singkat sejarah pengolahan data. 25 00:01:08,254 --> 00:01:10,420 Itu selalu membantu untuk memahami dari mana kita berasal 26 00:01:10,420 --> 00:01:12,400 dan mengapa kita di mana kita berada. 27 00:01:12,400 --> 00:01:15,600 Dan kita akan berbicara sedikit sedikit tentang teknologi NoSQL 28 00:01:15,600 --> 00:01:17,500 dari sudut pandang fundamental. 29 00:01:17,500 --> 00:01:19,870 >> Kami akan masuk ke beberapa internal DynamoDB. 30 00:01:19,870 --> 00:01:24,350 DynamoDB adalah AWS ini tidak ada rasa. 31 00:01:24,350 --> 00:01:27,340 Ini sebuah sepenuhnya dikelola dan host solusi NoSQL. 32 00:01:27,340 --> 00:01:32,420 Dan kita akan berbicara sedikit tentang meja struktur, API, jenis data, indeks, 33 00:01:32,420 --> 00:01:35,177 dan beberapa internal dari teknologi DynamoDB. 34 00:01:35,177 --> 00:01:37,760 Kami akan masuk ke beberapa desain pola dan praktik terbaik. 35 00:01:37,760 --> 00:01:39,968 Kita akan berbicara tentang bagaimana Anda menggunakan teknologi ini untuk beberapa 36 00:01:39,968 --> 00:01:41,430 aplikasi hari ini. 37 00:01:41,430 --> 00:01:44,820 Dan kemudian kita akan berbicara sedikit tentang evolusi atau munculnya 38 00:01:44,820 --> 00:01:48,980 dari paradigma baru dalam pemrograman disebut aplikasi-event 39 00:01:48,980 --> 00:01:51,580 dan bagaimana DynamoDB bermain di itu juga. 40 00:01:51,580 --> 00:01:54,690 Dan kami akan meninggalkan Anda sedikit diskusi arsitektur referensi 41 00:01:54,690 --> 00:01:59,540 sehingga kami dapat berbicara tentang beberapa cara Anda dapat menggunakan DynamoDB. 42 00:01:59,540 --> 00:02:04,116 >> Jadi pertama off-- ini adalah pertanyaan Aku mendengar banyak adalah, apa database. 43 00:02:04,116 --> 00:02:06,240 Banyak orang berpikir mereka tahu apa database adalah. 44 00:02:06,240 --> 00:02:08,360 Jika Anda Google, Anda akan melihat ini. 45 00:02:08,360 --> 00:02:11,675 Ini adalah satu set terstruktur dari data yang dimiliki di komputer, terutama yang 46 00:02:11,675 --> 00:02:13,600 diakses dalam berbagai cara. 47 00:02:13,600 --> 00:02:16,992 Saya kira itu baik definisi database modern. 48 00:02:16,992 --> 00:02:19,450 Tapi aku tidak suka, karena itu berarti beberapa hal. 49 00:02:19,450 --> 00:02:20,935 Ini menyiratkan struktur. 50 00:02:20,935 --> 00:02:23,120 Dan itu berarti bahwa itu pada komputer. 51 00:02:23,120 --> 00:02:25,750 Dan database tidak selalu ada pada komputer. 52 00:02:25,750 --> 00:02:28,020 Database benar-benar ada dalam banyak cara. 53 00:02:28,020 --> 00:02:32,000 >> Jadi definisi yang lebih baik dari Database adalah sesuatu seperti ini. 54 00:02:32,000 --> 00:02:34,786 Sebuah database terorganisir mekanisme untuk menyimpan, mengelola, 55 00:02:34,786 --> 00:02:35,910 dan mengambil informasi. 56 00:02:35,910 --> 00:02:36,868 Ini adalah dari About.com. 57 00:02:36,868 --> 00:02:42,080 Jadi saya suka ini karena benar-benar pembicaraan tentang database menjadi repositori, 58 00:02:42,080 --> 00:02:44,800 repositori informasi, belum tentu 59 00:02:44,800 --> 00:02:46,780 sesuatu yang duduk di komputer. 60 00:02:46,780 --> 00:02:49,290 Dan sepanjang sejarah, kami tidak selalu memiliki komputer. 61 00:02:49,290 --> 00:02:52,110 >> Sekarang, jika saya meminta rata-rata pengembang saat ini apa 62 00:02:52,110 --> 00:02:54,770 database, itulah jawaban yang saya dapatkan. 63 00:02:54,770 --> 00:02:56,070 Suatu tempat saya bisa tetap hal. 64 00:02:56,070 --> 00:02:56,670 Kanan? 65 00:02:56,670 --> 00:02:58,725 Dan itu benar. 66 00:02:58,725 --> 00:02:59,600 Tapi itu disayangkan. 67 00:02:59,600 --> 00:03:02,700 Karena database benar-benar dasar dari aplikasi modern. 68 00:03:02,700 --> 00:03:04,810 Ini yayasan dari setiap aplikasi. 69 00:03:04,810 --> 00:03:07,240 Dan bagaimana Anda membangun itu Database, bagaimana Anda struktur 70 00:03:07,240 --> 00:03:11,750 Data yang akan menentukan bagaimana yang Aplikasi melakukan seperti yang Anda skala. 71 00:03:11,750 --> 00:03:14,640 >> Jadi banyak pekerjaan saya hari ini adalah berurusan dengan apa 72 00:03:14,640 --> 00:03:17,180 terjadi ketika pengembang mengambil pendekatan ini 73 00:03:17,180 --> 00:03:19,510 dan berurusan dengan akibatnya dari aplikasi yang 74 00:03:19,510 --> 00:03:24,966 sekarang skala luar asli maksud dan penderitaan dari desain yang buruk. 75 00:03:24,966 --> 00:03:26,840 Jadi mudah-mudahan ketika Anda pergi hari ini, Anda akan 76 00:03:26,840 --> 00:03:29,010 memiliki beberapa alat di ikat pinggang Anda yang akan membuat Anda 77 00:03:29,010 --> 00:03:32,566 dari membuat kesalahan-kesalahan yang sama. 78 00:03:32,566 --> 00:03:33,066 Baiklah. 79 00:03:33,066 --> 00:03:36,360 Jadi mari kita bicara tentang sedikit timeline teknologi database. 80 00:03:36,360 --> 00:03:38,830 Saya pikir saya membaca sebuah Artikel tidak lama yang lalu 81 00:03:38,830 --> 00:03:43,020 dan itu mengatakan sesuatu pada lines-- yang itu pernyataan yang sangat puitis. 82 00:03:43,020 --> 00:03:46,590 Dikatakan sejarah dari pengolahan data adalah 83 00:03:46,590 --> 00:03:49,350 penuh watermark tinggi data kelimpahan. 84 00:03:49,350 --> 00:03:49,920 OKE. 85 00:03:49,920 --> 00:03:52,532 Sekarang, saya kira itu semacam benar. 86 00:03:52,532 --> 00:03:54,990 Tapi aku benar-benar melihat yaitu sebagai sejarah sebenarnya diisi 87 00:03:54,990 --> 00:03:56,820 dengan watermark tinggi tekanan data. 88 00:03:56,820 --> 00:04:00,040 Karena tingkat data konsumsi tidak pernah turun. 89 00:04:00,040 --> 00:04:01,360 Hanya naik. 90 00:04:01,360 --> 00:04:03,670 >> Dan inovasi terjadi ketika kita melihat tekanan data, yang 91 00:04:03,670 --> 00:04:07,825 adalah jumlah data yang sekarang datang ke dalam sistem. 92 00:04:07,825 --> 00:04:12,027 Dan itu tidak bisa diproses efisien baik dalam waktu atau biaya. 93 00:04:12,027 --> 00:04:14,110 Dan saat itulah kita mulai untuk melihat tekanan data. 94 00:04:14,110 --> 00:04:15,920 >> Jadi ketika kita melihat database pertama, ini 95 00:04:15,920 --> 00:04:17,180 adalah salah satu yang antara telinga kita. 96 00:04:17,180 --> 00:04:18,310 Kita semua terlahir dengan itu. 97 00:04:18,310 --> 00:04:19,194 Ini database yang bagus. 98 00:04:19,194 --> 00:04:21,110 Memiliki ketersediaan tinggi. 99 00:04:21,110 --> 00:04:21,959 Ini selalu. 100 00:04:21,959 --> 00:04:23,930 Anda selalu bisa mendapatkannya. 101 00:04:23,930 --> 00:04:24,890 >> Tapi itu single user. 102 00:04:24,890 --> 00:04:26,348 Saya tidak bisa berbagi pikiran saya dengan Anda. 103 00:04:26,348 --> 00:04:28,370 Anda tidak bisa mendapatkan pikiran saya ketika Anda ingin mereka. 104 00:04:28,370 --> 00:04:30,320 Dan abilitiy mereka tidak begitu baik. 105 00:04:30,320 --> 00:04:32,510 Kita lupa hal. 106 00:04:32,510 --> 00:04:36,540 Sesekali, salah satu dari kami daun dan pindah ke lain keberadaan 107 00:04:36,540 --> 00:04:39,110 dan kami kehilangan segalanya yang berada di database tersebut. 108 00:04:39,110 --> 00:04:40,640 Jadi itu tidak semua yang baik. 109 00:04:40,640 --> 00:04:43,189 >> Dan ini bekerja dengan baik dari waktu ke waktu ketika kami kembali pada hari 110 00:04:43,189 --> 00:04:46,230 ketika semua kita benar-benar perlu tahu adalah di mana kita akan pergi besok 111 00:04:46,230 --> 00:04:49,630 atau di mana kita berkumpul makanan terbaik. 112 00:04:49,630 --> 00:04:52,820 Tapi seperti kita mulai tumbuh sebagai peradaban dan pemerintah mulai 113 00:04:52,820 --> 00:04:55,152 untuk datang menjadi ada, dan bisnis mulai berkembang, 114 00:04:55,152 --> 00:04:57,360 kami mulai menyadari bahwa kita perlu sedikit lebih dari apa yang 115 00:04:57,360 --> 00:04:58,210 kita bisa dimasukkan ke dalam kepala kita. 116 00:04:58,210 --> 00:04:58,870 Baiklah? 117 00:04:58,870 --> 00:05:00,410 >> Kami membutuhkan sistem catatan. 118 00:05:00,410 --> 00:05:02,220 Kami membutuhkan tempat untuk menyimpan data mampu. 119 00:05:02,220 --> 00:05:05,450 Jadi kita mulai menulis dokumen, menciptakan perpustakaan dan arsip. 120 00:05:05,450 --> 00:05:08,000 Kami mulai mengembangkan sistem akuntansi buku besar. 121 00:05:08,000 --> 00:05:12,200 Dan bahwa sistem penghitungan buku berlari dunia selama berabad-abad, 122 00:05:12,200 --> 00:05:15,580 dan bahkan mungkin ribuan tahun sebagai kami jenis tumbuh ke titik 123 00:05:15,580 --> 00:05:18,420 mana yang beban data melampaui kemampuan sistem-sistem 124 00:05:18,420 --> 00:05:19,870 untuk dapat menampungnya. 125 00:05:19,870 --> 00:05:22,070 >> Dan ini benar-benar terjadi di tahun 1880-an. 126 00:05:22,070 --> 00:05:22,570 Kanan? 127 00:05:22,570 --> 00:05:24,390 Di tahun 1880 Sensus Amerika Serikat. 128 00:05:24,390 --> 00:05:26,976 Ini benar-benar di mana balik yang menunjuk pengolahan data modern. 129 00:05:26,976 --> 00:05:28,850 Ini adalah titik di yang jumlah data 130 00:05:28,850 --> 00:05:32,060 yang sedang dikumpulkan oleh Pemerintah AS sampai ke titik 131 00:05:32,060 --> 00:05:34,005 di mana butuh delapan tahun untuk memproses. 132 00:05:34,005 --> 00:05:36,350 >> Sekarang, delapan years-- sebagai Anda tahu, sensus 133 00:05:36,350 --> 00:05:39,180 berjalan setiap 10 years-- jadi cukup jelas bahwa pada saat kita 134 00:05:39,180 --> 00:05:41,419 mendapat sensus 1890, jumlah data yang 135 00:05:41,419 --> 00:05:43,210 akan diproses oleh pemerintah adalah 136 00:05:43,210 --> 00:05:46,335 akan melebihi 10 tahun itu yang dibutuhkan untuk meluncurkan sensus baru. 137 00:05:46,335 --> 00:05:47,250 Ini adalah masalah. 138 00:05:47,250 --> 00:05:49,000 >> Jadi seorang pria bernama Herman Hollerith datang 139 00:05:49,000 --> 00:05:52,640 dan ia menemukan catatan unit pukulan kartu, card reader punch, kartu punch 140 00:05:52,640 --> 00:05:58,420 tabulator, dan pengumpulan mekanisme untuk teknologi ini. 141 00:05:58,420 --> 00:06:01,860 Dan bahwa perusahaan yang ia terbentuk pada waktu, bersama dengan beberapa orang lain, 142 00:06:01,860 --> 00:06:05,450 benar-benar menjadi salah satu pilar dari perusahaan kecil yang kita kenal sekarang disebut IBM. 143 00:06:05,450 --> 00:06:08,417 >> Jadi IBM awalnya berada di bisnis database. 144 00:06:08,417 --> 00:06:09,750 Dan itu benar-benar apa yang mereka lakukan. 145 00:06:09,750 --> 00:06:11,110 Mereka melakukan pengolahan data. 146 00:06:11,110 --> 00:06:15,400 >> Sebagai sehingga proliferasi pukulan kartu, sebuah mekanisme cerdik 147 00:06:15,400 --> 00:06:18,560 mampu memanfaatkan bahwa teknologi untuk polling hasil set diurutkan. 148 00:06:18,560 --> 00:06:20,726 Anda dapat melihat pada gambar ini di sana kami memiliki sebuah little-- 149 00:06:20,726 --> 00:06:23,970 itu sedikit small-- tetapi Anda dapat melihat mekanisme mekanik yang sangat cerdik 150 00:06:23,970 --> 00:06:26,970 di mana kita memiliki dek kartu punch. 151 00:06:26,970 --> 00:06:28,720 Dan mengambil seseorang obeng kecil 152 00:06:28,720 --> 00:06:31,400 dan menempel melalui slot dan mengangkatnya 153 00:06:31,400 --> 00:06:34,820 untuk mendapatkan pertandingan itu, yang Hasil diurutkan mengatur. 154 00:06:34,820 --> 00:06:36,270 >> Ini merupakan agregasi. 155 00:06:36,270 --> 00:06:38,690 Kami melakukan hal ini sepanjang waktu hari ini di komputer, 156 00:06:38,690 --> 00:06:40,100 di mana Anda melakukannya dalam database. 157 00:06:40,100 --> 00:06:41,620 Kami digunakan untuk melakukannya secara manual, kan? 158 00:06:41,620 --> 00:06:42,994 Orang menaruh hal-hal ini bersama-sama. 159 00:06:42,994 --> 00:06:45,440 Dan itu proliferasi punch card ini 160 00:06:45,440 --> 00:06:50,070 menjadi apa yang kita disebut Data drum dan gulungan data, pita kertas. 161 00:06:50,070 --> 00:06:55,980 >> Industri pengolahan data mengambil pelajaran dari pemain piano. 162 00:06:55,980 --> 00:06:57,855 Pemain piano-piano kembali pergantian abad 163 00:06:57,855 --> 00:07:02,100 digunakan untuk menggunakan gulungan kertas dengan slot untuk menceritakannya yang kunci untuk bermain. 164 00:07:02,100 --> 00:07:05,380 Jadi teknologi yang diadaptasi akhirnya untuk menyimpan data digital, 165 00:07:05,380 --> 00:07:08,070 karena mereka bisa menempatkan data yang ke mereka pita kertas gulungan. 166 00:07:08,070 --> 00:07:10,870 >> Sekarang, sebagai hasilnya, data itu actually-- bagaimana 167 00:07:10,870 --> 00:07:14,960 Anda mengakses data ini secara langsung tergantung pada bagaimana Anda menyimpannya. 168 00:07:14,960 --> 00:07:17,825 Jadi jika saya menempatkan data pada tape, Aku punya mengakses data secara linear. 169 00:07:17,825 --> 00:07:20,475 Aku harus menggulung seluruh tape untuk mengakses semua data. 170 00:07:20,475 --> 00:07:22,600 Jika saya menempatkan data di pukulan kartu, saya bisa mengaksesnya 171 00:07:22,600 --> 00:07:26,270 dalam sedikit lebih acak busana, mungkin tidak secepat. 172 00:07:26,270 --> 00:07:30,770 >> Tapi ada keterbatasan dalam bagaimana kita akses ke data berdasarkan bagaimana disimpan. 173 00:07:30,770 --> 00:07:32,890 Dan jadi ini adalah masalah pergi ke '50-an. 174 00:07:32,890 --> 00:07:37,890 Sekali lagi, kita bisa mulai melihat bahwa seperti yang kita mengembangkan teknologi baru untuk memproses 175 00:07:37,890 --> 00:07:41,670 data, kanan, membuka pintu untuk solusi baru, 176 00:07:41,670 --> 00:07:45,852 untuk program baru, baru aplikasi untuk data itu. 177 00:07:45,852 --> 00:07:47,810 Dan benar-benar, tata kelola mungkin alasannya 178 00:07:47,810 --> 00:07:49,435 mengapa kami mengembangkan beberapa sistem ini. 179 00:07:49,435 --> 00:07:52,290 Tapi bisnis cepat menjadi driver balik evolusi 180 00:07:52,290 --> 00:07:54,720 dari database modern dan sistem file modern. 181 00:07:54,720 --> 00:07:56,870 >> Jadi hal berikutnya yang muncul adalah pada tahun 50an 182 00:07:56,870 --> 00:08:00,780 adalah sistem file dan pengembangan penyimpanan akses acak. 183 00:08:00,780 --> 00:08:02,050 Ini adalah indah. 184 00:08:02,050 --> 00:08:06,230 Sekarang, semua tiba-tiba, kita dapat menempatkan kami file mana saja di hard drive 185 00:08:06,230 --> 00:08:09,760 dan kita dapat mengakses data ini secara acak. 186 00:08:09,760 --> 00:08:11,950 Kita bisa mengurai bahwa Informasi dari file. 187 00:08:11,950 --> 00:08:14,920 Dan kita memecahkan semua dunia masalah dengan pengolahan data. 188 00:08:14,920 --> 00:08:17,550 >> Dan itu berlangsung sekitar 20 atau 30 tahun sampai evolusi 189 00:08:17,550 --> 00:08:22,100 dari database relasional, yang adalah ketika dunia memutuskan kita sekarang 190 00:08:22,100 --> 00:08:27,940 perlu memiliki repositori yang mengalahkan gepeng data di file 191 00:08:27,940 --> 00:08:29,540 sistem yang kami telah membangun. Kanan? 192 00:08:29,540 --> 00:08:34,270 Terlalu banyak data didistribusikan di terlalu banyak tempat, de-duplikasi data, 193 00:08:34,270 --> 00:08:37,120 dan biaya penyimpanan sangat besar. 194 00:08:37,120 --> 00:08:43,760 >> Di 70-an, sumber daya yang paling mahal bahwa komputer memiliki adalah penyimpanan. 195 00:08:43,760 --> 00:08:46,200 Prosesor adalah dipandang sebagai biaya tetap. 196 00:08:46,200 --> 00:08:49,030 Ketika saya membeli kotak, CPU melakukan beberapa pekerjaan. 197 00:08:49,030 --> 00:08:51,960 Ini akan berputar apakah itu benar-benar bekerja atau tidak. 198 00:08:51,960 --> 00:08:53,350 Itu benar-benar biaya tenggelam. 199 00:08:53,350 --> 00:08:56,030 >> Tapi apa yang saya biaya sebagai bisnis penyimpanan. 200 00:08:56,030 --> 00:09:00,020 Jika saya harus membeli lebih disk berikutnya bulan, itu adalah biaya riil yang saya bayar. 201 00:09:00,020 --> 00:09:01,620 Dan penyimpanan yang mahal. 202 00:09:01,620 --> 00:09:05,020 >> Sekarang kita maju cepat 40 tahun dan kami memiliki masalah yang berbeda. 203 00:09:05,020 --> 00:09:10,020 Menghitung yang sekarang sumber daya yang paling mahal. 204 00:09:10,020 --> 00:09:11,470 Penyimpanan yang murah. 205 00:09:11,470 --> 00:09:14,570 Maksudku, kita bisa pergi ke mana pun pada awan dan kita dapat menemukan penyimpanan murah. 206 00:09:14,570 --> 00:09:17,190 Tapi apa yang saya tidak dapat menemukan adalah menghitung murah. 207 00:09:17,190 --> 00:09:20,700 >> Jadi evolusi hari ini teknologi, teknologi database, 208 00:09:20,700 --> 00:09:23,050 benar-benar terfokus di sekitar database terdistribusi 209 00:09:23,050 --> 00:09:26,960 yang tidak menderita jenis yang sama dari skala 210 00:09:26,960 --> 00:09:29,240 keterbatasan database relasional. 211 00:09:29,240 --> 00:09:32,080 Kami akan berbicara sedikit tentang apa yang benar-benar berarti. 212 00:09:32,080 --> 00:09:34,760 >> Tapi salah satu alasan dan driver di belakang kami this-- 213 00:09:34,760 --> 00:09:38,290 berbicara tentang tekanan data. 214 00:09:38,290 --> 00:09:41,920 Tekanan Data adalah sesuatu yang mendorong inovasi. 215 00:09:41,920 --> 00:09:44,610 Dan jika Anda melihat lebih lima tahun terakhir, 216 00:09:44,610 --> 00:09:48,180 ini adalah bagan dari apa data beban di perusahaan umum 217 00:09:48,180 --> 00:09:49,640 Sepertinya dalam lima tahun terakhir. 218 00:09:49,640 --> 00:09:52,570 >> Dan aturan umum days-- ini jika Anda pergi Google-- 219 00:09:52,570 --> 00:09:55,290 adalah 90% dari data yang kami menyimpan hari, dan itu 220 00:09:55,290 --> 00:09:57,330 dihasilkan dalam dua tahun terakhir. 221 00:09:57,330 --> 00:09:57,911 OKE. 222 00:09:57,911 --> 00:09:59,410 Sekarang, ini bukan sebuah tren yang baru. 223 00:09:59,410 --> 00:10:01,230 Ini adalah tren yang sudah akan keluar untuk 100 tahun. 224 00:10:01,230 --> 00:10:03,438 Sejak Herman Hollerith mengembangkan kartu punch, 225 00:10:03,438 --> 00:10:08,040 kami telah membangun repositori data yang dan mengumpulkan data pada tingkat yang fenomenal. 226 00:10:08,040 --> 00:10:10,570 >> Jadi selama 100 tahun terakhir, kita telah melihat tren ini. 227 00:10:10,570 --> 00:10:11,940 Itu tidak akan berubah. 228 00:10:11,940 --> 00:10:14,789 Ke depan, kita akan melihat ini, jika tidak tren dipercepat. 229 00:10:14,789 --> 00:10:16,330 Dan Anda dapat melihat apa yang tampak seperti. 230 00:10:16,330 --> 00:10:23,510 >> Jika bisnis pada tahun 2010 memiliki satu terabyte data di bawah manajemen, 231 00:10:23,510 --> 00:10:27,080 hari ini itu berarti mereka mengelola 6,5 ​​petabyte data. 232 00:10:27,080 --> 00:10:30,380 Itu 6.500 Data kali lebih. 233 00:10:30,380 --> 00:10:31,200 Dan aku tahu ini. 234 00:10:31,200 --> 00:10:33,292 Saya bekerja dengan bisnis ini setiap hari. 235 00:10:33,292 --> 00:10:35,000 Lima tahun yang lalu, saya akan berbicara dengan perusahaan 236 00:10:35,000 --> 00:10:38,260 yang akan berbicara kepada saya tentang apa yang sakit itu adalah untuk mengelola terabyte data. 237 00:10:38,260 --> 00:10:39,700 Dan mereka akan berbicara kepada saya tentang bagaimana kita melihat 238 00:10:39,700 --> 00:10:41,825 bahwa ini mungkin akan menjadi dua petabyte atau 239 00:10:41,825 --> 00:10:43,030 dalam beberapa tahun. 240 00:10:43,030 --> 00:10:45,170 >> Perusahaan-perusahaan yang sama hari ini aku bertemu dengan, 241 00:10:45,170 --> 00:10:48,100 dan mereka sedang berbicara kepada saya tentang Masalah yang ada memiliki pengelolaan 242 00:10:48,100 --> 00:10:51,440 puluhan, 20 petabyte data. 243 00:10:51,440 --> 00:10:53,590 Jadi ledakan Data di industri 244 00:10:53,590 --> 00:10:56,670 adalah mendorong besar butuhkan untuk solusi yang lebih baik. 245 00:10:56,670 --> 00:11:00,980 Dan database relasional adalah hanya tidak hidup sampai permintaan. 246 00:11:00,980 --> 00:11:03,490 >> Dan jadi ada linear korelasi antara tekanan Data 247 00:11:03,490 --> 00:11:05,210 dan inovasi teknis. 248 00:11:05,210 --> 00:11:07,780 Sejarah telah menunjukkan kepada kita ini, yang dari waktu ke waktu, 249 00:11:07,780 --> 00:11:11,090 setiap kali volume data yang perlu diproses 250 00:11:11,090 --> 00:11:15,490 melebihi kapasitas sistem untuk memprosesnya dalam waktu yang wajar 251 00:11:15,490 --> 00:11:18,870 atau dengan biaya yang wajar, teknologi baru kemudian 252 00:11:18,870 --> 00:11:21,080 yang diciptakan untuk memecahkan masalah tersebut. 253 00:11:21,080 --> 00:11:24,090 Mereka teknologi baru, pada gilirannya, membuka pintu 254 00:11:24,090 --> 00:11:27,840 untuk satu set masalah, yang mengumpulkan data bahkan lebih. 255 00:11:27,840 --> 00:11:29,520 >> Sekarang, kita tidak akan berhenti ini. 256 00:11:29,520 --> 00:11:30,020 Kanan? 257 00:11:30,020 --> 00:11:31,228 Kami tidak akan berhenti ini. 258 00:11:31,228 --> 00:11:31,830 Mengapa? 259 00:11:31,830 --> 00:11:35,520 Karena Anda tidak bisa tahu segalanya ada untuk mengetahui di alam semesta. 260 00:11:35,520 --> 00:11:40,510 Dan selama kita sudah hidup, sepanjang sejarah manusia, 261 00:11:40,510 --> 00:11:43,440 kami selalu didorong untuk tahu lebih banyak. 262 00:11:43,440 --> 00:11:49,840 >> Jadi sepertinya setiap inci kita bergerak menyusuri jalan penemuan ilmiah, 263 00:11:49,840 --> 00:11:54,620 kita mengalikan jumlah data bahwa kita perlu proses secara eksponensial 264 00:11:54,620 --> 00:11:59,920 seperti yang kita mengungkap lebih banyak dan lebih dan lebih tentang inner hidup, 265 00:11:59,920 --> 00:12:04,530 tentang bagaimana alam semesta bekerja, sekitar mengemudi penemuan ilmiah, 266 00:12:04,530 --> 00:12:06,440 dan penemuan yang kita lakukan hari ini. 267 00:12:06,440 --> 00:12:09,570 Volume data hanya terus meningkat. 268 00:12:09,570 --> 00:12:12,120 Sehingga mampu menangani masalah ini sangat besar. 269 00:12:12,120 --> 00:12:14,790 270 00:12:14,790 --> 00:12:17,410 >> Jadi salah satu hal kita melihat sebagai mengapa NoSQL? 271 00:12:17,410 --> 00:12:19,200 Bagaimana NoSQL memecahkan masalah ini? 272 00:12:19,200 --> 00:12:24,980 Nah, database relasional, Structured Query Language, 273 00:12:24,980 --> 00:12:28,600 SQL-- itu benar-benar suatu konstruksi dari relasional database-- hal-hal ini 274 00:12:28,600 --> 00:12:30,770 dioptimalkan untuk penyimpanan. 275 00:12:30,770 --> 00:12:33,180 >> Kembali di tahun 70-an, sekali lagi, disk mahal. 276 00:12:33,180 --> 00:12:36,990 Latihan penyediaan penyimpanan dalam perusahaan adalah tidak pernah berakhir. 277 00:12:36,990 --> 00:12:37,490 Aku tahu. 278 00:12:37,490 --> 00:12:38,020 Saya tinggal itu. 279 00:12:38,020 --> 00:12:41,250 Saya menulis driver penyimpanan untuk Perusahaan superserver enterprised 280 00:12:41,250 --> 00:12:42,470 kembali di tahun 90-an. 281 00:12:42,470 --> 00:12:45,920 Dan garis bawah adalah memeras lain array storage hanya sesuatu yang 282 00:12:45,920 --> 00:12:47,600 terjadi setiap hari di perusahaan. 283 00:12:47,600 --> 00:12:49,030 Dan tidak pernah berhenti. 284 00:12:49,030 --> 00:12:52,690 Penyimpanan kepadatan lebih tinggi, permintaan untuk penyimpanan kepadatan tinggi, 285 00:12:52,690 --> 00:12:56,340 dan untuk penyimpanan lebih efisien devices-- itu tidak pernah berhenti. 286 00:12:56,340 --> 00:13:00,160 >> Dan NoSQL adalah teknologi yang besar karena menormalkan data. 287 00:13:00,160 --> 00:13:02,210 Ini de-duplikasi data. 288 00:13:02,210 --> 00:13:07,180 Ini menempatkan data dalam struktur yang adalah agnostik untuk setiap pola akses. 289 00:13:07,180 --> 00:13:11,600 Beberapa aplikasi dapat menekan bahwa Database SQL, menjalankan query ad hoc, 290 00:13:11,600 --> 00:13:15,950 dan mendapatkan data dalam bentuk yang mereka perlu proses untuk beban kerja mereka. 291 00:13:15,950 --> 00:13:17,570 Kedengarannya fantastis. 292 00:13:17,570 --> 00:13:21,350 Tetapi intinya adalah dengan sistem, jika itu agnostik untuk segala sesuatu, 293 00:13:21,350 --> 00:13:23,500 dioptimalkan untuk apa-apa. 294 00:13:23,500 --> 00:13:24,050 OKE? 295 00:13:24,050 --> 00:13:26,386 >> Dan itulah apa yang kita dapatkan dengan database relasional. 296 00:13:26,386 --> 00:13:27,510 Itu dioptimalkan untuk penyimpanan. 297 00:13:27,510 --> 00:13:28,280 Ini normal. 298 00:13:28,280 --> 00:13:29,370 Ini relasional. 299 00:13:29,370 --> 00:13:31,660 Mendukung ad hoc query. 300 00:13:31,660 --> 00:13:34,000 Dan itu dan skala vertikal. 301 00:13:34,000 --> 00:13:39,030 >> Jika saya perlu untuk mendapatkan database SQL yang lebih besar atau database SQL yang lebih kuat, 302 00:13:39,030 --> 00:13:41,090 Aku pergi membeli sepotong lebih besar dari besi. 303 00:13:41,090 --> 00:13:41,600 OKE? 304 00:13:41,600 --> 00:13:44,940 Saya telah bekerja dengan banyak pelanggan yang telah melalui upgrade besar 305 00:13:44,940 --> 00:13:48,340 infrastruktur SQL mereka hanya untuk mengetahui enam bulan kemudian, 306 00:13:48,340 --> 00:13:49,750 mereka memukul dinding lagi. 307 00:13:49,750 --> 00:13:55,457 Dan jawaban dari Oracle atau MSSQL atau orang lain adalah mendapatkan kotak besar. 308 00:13:55,457 --> 00:13:58,540 Nah cepat atau lambat, Anda tidak bisa membeli lebih besar box, dan itulah masalah yang sebenarnya. 309 00:13:58,540 --> 00:14:00,080 Kita perlu untuk benar-benar mengubah keadaan. 310 00:14:00,080 --> 00:14:01,080 Jadi di mana ini bekerja? 311 00:14:01,080 --> 00:14:06,560 Ia bekerja dengan baik untuk secara offline analisis, OLAP-jenis beban kerja. 312 00:14:06,560 --> 00:14:08,670 Dan itu benar-benar di mana SQL milik. 313 00:14:08,670 --> 00:14:12,540 Sekarang, itu digunakan saat ini di banyak secara online transaksional pengolahan-jenis 314 00:14:12,540 --> 00:14:13,330 aplikasi. 315 00:14:13,330 --> 00:14:16,460 Dan bekerja dengan baik di beberapa tingkat pemanfaatan, 316 00:14:16,460 --> 00:14:18,670 tapi itu hanya tidak skala cara NoSQL tidak. 317 00:14:18,670 --> 00:14:20,660 Dan kita akan berbicara sedikit sedikit tentang mengapa itu. 318 00:14:20,660 --> 00:14:23,590 >> Sekarang, NoSQL, di sisi lain, lebih dioptimalkan untuk menghitung. 319 00:14:23,590 --> 00:14:24,540 OKE? 320 00:14:24,540 --> 00:14:26,830 Hal ini tidak agnostik untuk pola akses. 321 00:14:26,830 --> 00:14:31,620 Adalah apa yang kita sebut de-normalisasi struktur atau struktur hirarkis. 322 00:14:31,620 --> 00:14:35,000 Data dalam database relasional adalah bergabung bersama-sama dari beberapa tabel 323 00:14:35,000 --> 00:14:36,850 untuk menghasilkan tampilan yang Anda butuhkan. 324 00:14:36,850 --> 00:14:40,090 Data dalam database NoSQL disimpan dalam dokumen yang 325 00:14:40,090 --> 00:14:42,100 berisi struktur hirarkis. 326 00:14:42,100 --> 00:14:45,670 Semua data yang biasanya akan bergabung bersama untuk menghasilkan tampilan yang 327 00:14:45,670 --> 00:14:47,160 disimpan dalam satu dokumen. 328 00:14:47,160 --> 00:14:50,990 Dan kita akan berbicara sedikit tentang bagaimana yang bekerja di beberapa tangga lagu. 329 00:14:50,990 --> 00:14:55,320 >> Tapi ide di sini adalah bahwa Anda menyimpan data Anda karena ini pandangan yang dipakai. 330 00:14:55,320 --> 00:14:56,410 OKE? 331 00:14:56,410 --> 00:14:58,610 Anda skala horizontal. 332 00:14:58,610 --> 00:14:59,556 Kanan? 333 00:14:59,556 --> 00:15:02,100 Jika saya perlu meningkatkan Ukuran cluster NoSQL saya, 334 00:15:02,100 --> 00:15:03,700 Saya tidak perlu mendapatkan kotak besar. 335 00:15:03,700 --> 00:15:05,200 Saya mendapatkan kotak lain. 336 00:15:05,200 --> 00:15:07,700 Dan saya klaster mereka bersama-sama, dan saya dapat beling data tersebut. 337 00:15:07,700 --> 00:15:10,780 Kita akan berbicara sedikit tentang apa sharding adalah, untuk menjadi 338 00:15:10,780 --> 00:15:14,270 mampu skala database yang di beberapa perangkat fisik 339 00:15:14,270 --> 00:15:18,370 dan menghapus penghalang yang mengharuskan saya untuk skala vertikal. 340 00:15:18,370 --> 00:15:22,080 >> Jadi itu benar-benar dibangun untuk secara online proses transaksi dan skala. 341 00:15:22,080 --> 00:15:25,480 Ada perbedaan besar di sini antara pelaporan, kan? 342 00:15:25,480 --> 00:15:27,810 Pelaporan, saya tidak tahu pertanyaan saya akan bertanya. 343 00:15:27,810 --> 00:15:28,310 Kanan? 344 00:15:28,310 --> 00:15:30,570 Reporting-- jika seseorang dari departemen pemasaran saya 345 00:15:30,570 --> 00:15:34,520 ingin hanya-- berapa banyak pelanggan saya memiliki karakteristik tertentu yang 346 00:15:34,520 --> 00:15:37,850 membeli di day-- ini saya tidak tahu apa permintaan mereka akan bertanya. 347 00:15:37,850 --> 00:15:39,160 Jadi saya harus agnostik. 348 00:15:39,160 --> 00:15:41,810 >> Sekarang, di online aplikasi transaksional, 349 00:15:41,810 --> 00:15:43,820 Aku tahu apa pertanyaan yang saya minta. 350 00:15:43,820 --> 00:15:46,581 Saya membangun aplikasi untuk alur kerja yang sangat spesifik. 351 00:15:46,581 --> 00:15:47,080 OKE? 352 00:15:47,080 --> 00:15:50,540 Jadi jika saya mengoptimalkan data menyimpan untuk mendukung alur kerja itu, 353 00:15:50,540 --> 00:15:52,020 itu akan menjadi lebih cepat. 354 00:15:52,020 --> 00:15:55,190 Dan itulah mengapa NoSQL bisa benar-benar mempercepat pengiriman 355 00:15:55,190 --> 00:15:57,710 dari jenis-jenis layanan. 356 00:15:57,710 --> 00:15:58,210 Baiklah. 357 00:15:58,210 --> 00:16:00,501 >> Jadi kita akan masuk ke sedikit teori sini. 358 00:16:00,501 --> 00:16:03,330 Dan beberapa dari Anda, mata Anda mungkin memutar kembali sedikit. 359 00:16:03,330 --> 00:16:06,936 Tapi aku akan mencoba untuk tetap tingkat setinggi mungkin. 360 00:16:06,936 --> 00:16:08,880 Jadi jika Anda berada di proyek manajemen, ada 361 00:16:08,880 --> 00:16:12,280 membangun yang disebut segitiga kendala. 362 00:16:12,280 --> 00:16:12,936 OKE. 363 00:16:12,936 --> 00:16:16,060 Segitiga kendala diktat Anda tidak bisa memiliki segalanya sepanjang waktu. 364 00:16:16,060 --> 00:16:17,750 Tidak dapat memiliki kue dan memakannya juga. 365 00:16:17,750 --> 00:16:22,310 Jadi dalam manajemen proyek, yang segitiga kendala adalah Anda dapat memilikinya murah, 366 00:16:22,310 --> 00:16:24,710 Anda dapat memilikinya cepat, atau Anda dapat memilikinya baik. 367 00:16:24,710 --> 00:16:25,716 Ambil dua. 368 00:16:25,716 --> 00:16:27,090 Karena Anda tidak dapat memiliki semua tiga. 369 00:16:27,090 --> 00:16:27,460 Kanan? 370 00:16:27,460 --> 00:16:27,820 OKE. 371 00:16:27,820 --> 00:16:28,920 >> Jadi Anda mendengar tentang ini banyak. 372 00:16:28,920 --> 00:16:31,253 Ini adalah kendala tiga, segitiga triple kendala, 373 00:16:31,253 --> 00:16:34,420 atau segitiga besi oftentimes-- ketika Anda berbicara dengan manajer proyek, 374 00:16:34,420 --> 00:16:35,420 mereka akan berbicara tentang hal ini. 375 00:16:35,420 --> 00:16:37,640 Sekarang, database memiliki segitiga besi mereka sendiri. 376 00:16:37,640 --> 00:16:40,350 Dan segitiga besi data adalah apa yang kita sebut CAP teorema. 377 00:16:40,350 --> 00:16:41,580 OKE? 378 00:16:41,580 --> 00:16:43,770 >> CAP teorema mendikte bagaimana database beroperasi 379 00:16:43,770 --> 00:16:45,627 di bawah kondisi yang sangat spesifik. 380 00:16:45,627 --> 00:16:47,460 Dan kita akan berbicara tentang apa kondisi yang. 381 00:16:47,460 --> 00:16:52,221 Tapi tiga poin dari segitiga, sehingga untuk berbicara, adalah C, konsistensi. 382 00:16:52,221 --> 00:16:52,720 OKE? 383 00:16:52,720 --> 00:16:56,760 Jadi di CAP, konsistensi berarti bahwa semua klien yang dapat mengakses database 384 00:16:56,760 --> 00:16:59,084 akan selalu memiliki sangat tampilan yang konsisten dari data. 385 00:16:59,084 --> 00:17:00,750 Tidak ada yang akan melihat dua hal yang berbeda. 386 00:17:00,750 --> 00:17:01,480 OKE? 387 00:17:01,480 --> 00:17:04,020 Jika saya melihat database, Saya melihat pandangan yang sama 388 00:17:04,020 --> 00:17:06,130 sebagai mitra saya yang melihat database yang sama. 389 00:17:06,130 --> 00:17:07,470 Itu konsistensi. 390 00:17:07,470 --> 00:17:12,099 >> Ketersediaan berarti bahwa jika database online, jika dapat tercapai, 391 00:17:12,099 --> 00:17:14,760 bahwa semua klien akan selalu dapat membaca dan menulis. 392 00:17:14,760 --> 00:17:15,260 OKE? 393 00:17:15,260 --> 00:17:17,010 Jadi setiap klien yang dapat membaca database 394 00:17:17,010 --> 00:17:18,955 akan selalu dapat dibaca data dan menulis data. 395 00:17:18,955 --> 00:17:21,819 Dan jika itu yang terjadi, itu sebuah sistem yang tersedia. 396 00:17:21,819 --> 00:17:24,230 >> Dan titik ketiga adalah apa yang kita sebut toleransi partisi. 397 00:17:24,230 --> 00:17:24,730 OKE? 398 00:17:24,730 --> 00:17:28,160 Toleransi partisi berarti bahwa sistem bekerja dengan baik 399 00:17:28,160 --> 00:17:32,000 meskipun jaringan fisik partisi antara node. 400 00:17:32,000 --> 00:17:32,760 OKE? 401 00:17:32,760 --> 00:17:36,270 Jadi node di cluster tidak bisa berbicara satu sama lain, apa yang terjadi? 402 00:17:36,270 --> 00:17:36,880 Baiklah. 403 00:17:36,880 --> 00:17:39,545 >> Database sehingga relasional choose-- Anda dapat memilih dua ini. 404 00:17:39,545 --> 00:17:40,045 OKE. 405 00:17:40,045 --> 00:17:43,680 Database sehingga relasional pilih untuk konsisten dan tersedia. 406 00:17:43,680 --> 00:17:47,510 Jika partisi terjadi antara yang DataNodes dalam menyimpan data, 407 00:17:47,510 --> 00:17:48,831 database crash. 408 00:17:48,831 --> 00:17:49,330 Kanan? 409 00:17:49,330 --> 00:17:50,900 Itu hanya turun. 410 00:17:50,900 --> 00:17:51,450 OKE. 411 00:17:51,450 --> 00:17:54,230 >> Dan ini adalah mengapa mereka memiliki tumbuh dengan kotak besar. 412 00:17:54,230 --> 00:17:54,730 Kanan? 413 00:17:54,730 --> 00:17:58,021 Karena ada no-- biasanya, cluster Database, tidak ada sangat banyak dari mereka 414 00:17:58,021 --> 00:17:59,590 yang beroperasi dengan cara itu. 415 00:17:59,590 --> 00:18:03,019 Tapi kebanyakan database skala vertikal dalam kotak tunggal. 416 00:18:03,019 --> 00:18:05,060 Karena mereka harus konsisten dan tersedia. 417 00:18:05,060 --> 00:18:10,320 Jika partisi yang harus disuntikkan, maka Anda akan harus membuat pilihan. 418 00:18:10,320 --> 00:18:13,720 Anda harus membuat pilihan antara konsisten dan tersedia. 419 00:18:13,720 --> 00:18:16,080 >> Dan itulah yang database NoSQL lakukan. 420 00:18:16,080 --> 00:18:16,580 Baiklah. 421 00:18:16,580 --> 00:18:20,950 Jadi database NoSQL, itu datang dalam dua rasa. 422 00:18:20,950 --> 00:18:22,990 Kami have-- dengan baik, datang dalam berbagai rasa, 423 00:18:22,990 --> 00:18:26,140 tetapi ia datang dengan dua dasar characteristics-- apa 424 00:18:26,140 --> 00:18:30,050 kita akan memanggil database CP, atau toleransi konsisten dan partisi 425 00:18:30,050 --> 00:18:31,040 sistem. 426 00:18:31,040 --> 00:18:34,930 Orang-orang membuat pilihan bahwa ketika node kehilangan kontak dengan satu sama lain, 427 00:18:34,930 --> 00:18:37,091 kita tidak akan membiarkan orang untuk menulis lagi. 428 00:18:37,091 --> 00:18:37,590 OKE? 429 00:18:37,590 --> 00:18:41,855 >> Sampai partisi yang dihapus, akses tulis diblokir. 430 00:18:41,855 --> 00:18:43,230 Itu berarti mereka tidak tersedia. 431 00:18:43,230 --> 00:18:44,510 Mereka konsisten. 432 00:18:44,510 --> 00:18:46,554 Ketika kita melihat bahwa partisi menyuntikkan sendiri, 433 00:18:46,554 --> 00:18:48,470 kita sekarang konsisten, karena kita tidak akan 434 00:18:48,470 --> 00:18:51,517 untuk memungkinkan perubahan data pada dua sisi partisi independen 435 00:18:51,517 --> 00:18:52,100 satu sama lain. 436 00:18:52,100 --> 00:18:54,130 Kita harus kembali komunikasi 437 00:18:54,130 --> 00:18:56,930 sebelum update ke Data yang diperbolehkan. 438 00:18:56,930 --> 00:18:58,120 OKE? 439 00:18:58,120 --> 00:19:02,650 >> Rasa berikutnya akan menjadi sistem AP, atau tersedia dan dipartisi 440 00:19:02,650 --> 00:19:03,640 sistem toleransi. 441 00:19:03,640 --> 00:19:05,320 Orang-orang ini tidak peduli. 442 00:19:05,320 --> 00:19:06,020 Kanan? 443 00:19:06,020 --> 00:19:08,960 Setiap node yang mendapat menulis, kami akan mengambilnya. 444 00:19:08,960 --> 00:19:11,480 Jadi aku mereplikasi data saya di beberapa node. 445 00:19:11,480 --> 00:19:14,730 Node ini mendapatkan klien, klien datang di, mengatakan, aku akan menulis beberapa data. 446 00:19:14,730 --> 00:19:16,300 Node mengatakan, tidak ada masalah. 447 00:19:16,300 --> 00:19:18,580 Node sampingnya mendapat menulis pada catatan yang sama, 448 00:19:18,580 --> 00:19:20,405 dia akan mengatakan tidak ada masalah. 449 00:19:20,405 --> 00:19:23,030 Suatu tempat kembali di ujung belakang, Data itu akan meniru. 450 00:19:23,030 --> 00:19:27,360 Dan kemudian seseorang akan menyadari, uh-oh, sistem mereka akan menyadari, uh-oh, 451 00:19:27,360 --> 00:19:28,870 sudah ada update untuk kedua belah pihak. 452 00:19:28,870 --> 00:19:30,370 Apa yang kita lakukan? 453 00:19:30,370 --> 00:19:33,210 Dan apa yang mereka lakukan adalah mereka melakukan sesuatu yang 454 00:19:33,210 --> 00:19:36,080 memungkinkan mereka untuk menyelesaikan bahwa negara data. 455 00:19:36,080 --> 00:19:39,000 Dan kita akan berbicara tentang bahwa dalam grafik berikutnya. 456 00:19:39,000 --> 00:19:40,000 >> Hal yang menunjukkan di sini. 457 00:19:40,000 --> 00:19:42,374 Dan aku tidak akan terlalu banyak ke dalam ini, karena ini 458 00:19:42,374 --> 00:19:43,510 masuk ke teori Data dalam. 459 00:19:43,510 --> 00:19:46,670 Tapi ada transaksional yang kerangka yang 460 00:19:46,670 --> 00:19:50,680 berjalan di sistem relasional yang memungkinkan saya untuk aman melakukan update 461 00:19:50,680 --> 00:19:53,760 untuk beberapa entitas dalam database. 462 00:19:53,760 --> 00:19:58,320 Dan update tersebut akan terjadi sekaligus atau tidak sama sekali. 463 00:19:58,320 --> 00:20:00,500 Dan ini disebut transaksi ACID. 464 00:20:00,500 --> 00:20:01,000 OKE? 465 00:20:01,000 --> 00:20:06,570 >> ACID memberi kita atomicity, konsistensi, isolasi, dan daya tahan. 466 00:20:06,570 --> 00:20:07,070 OKE? 467 00:20:07,070 --> 00:20:13,550 Itu berarti atom, transaksi, semua update saya baik terjadi atau tidak. 468 00:20:13,550 --> 00:20:16,570 Konsistensi berarti bahwa database akan selalu 469 00:20:16,570 --> 00:20:19,780 dibawa ke dalam konsisten negara setelah update. 470 00:20:19,780 --> 00:20:23,900 Aku tidak akan pernah meninggalkan database dalam keadaan buruk setelah menerapkan pembaruan. 471 00:20:23,900 --> 00:20:24,400 OKE? 472 00:20:24,400 --> 00:20:26,720 >> Jadi itu adalah sedikit berbeda dari konsistensi CAP. 473 00:20:26,720 --> 00:20:29,760 Konsistensi CAP berarti semua saya klien selalu dapat melihat data. 474 00:20:29,760 --> 00:20:34,450 Konsistensi ACID berarti bahwa ketika transaksi dilakukan, data yang baik. 475 00:20:34,450 --> 00:20:35,709 Hubungan saya semua baik. 476 00:20:35,709 --> 00:20:38,750 Aku tidak akan menghapus baris tua dan meninggalkan sekelompok anak-anak yatim piatu 477 00:20:38,750 --> 00:20:40,970 di beberapa meja lain. 478 00:20:40,970 --> 00:20:44,320 Hal ini tidak bisa terjadi jika saya konsisten dalam transaksi asam. 479 00:20:44,320 --> 00:20:49,120 >> Isolasi berarti bahwa transaksi akan selalu terjadi satu demi satu. 480 00:20:49,120 --> 00:20:51,920 Hasil akhir dari data akan menjadi negara yang sama 481 00:20:51,920 --> 00:20:54,770 seolah-olah transaksi tersebut yang diterbitkan bersamaan 482 00:20:54,770 --> 00:20:57,340 dieksekusi serial. 483 00:20:57,340 --> 00:21:00,030 Jadi itu konkurensi kontrol dalam database. 484 00:21:00,030 --> 00:21:04,130 Jadi pada dasarnya, saya tidak bisa kenaikan nilai yang sama dua kali dengan dua operasi. 485 00:21:04,130 --> 00:21:08,580 >> Tapi jika saya katakan tambahkan 1 untuk nilai ini, dan dua transaksi datang dalam 486 00:21:08,580 --> 00:21:10,665 dan mencoba untuk melakukannya, salah satu yang akan sampai di sana pertama 487 00:21:10,665 --> 00:21:12,540 dan yang lain akan ke sana setelah. 488 00:21:12,540 --> 00:21:15,210 Jadi pada akhirnya, saya menambahkan dua. 489 00:21:15,210 --> 00:21:16,170 Anda melihat apa yang saya maksud? 490 00:21:16,170 --> 00:21:16,670 OKE. 491 00:21:16,670 --> 00:21:19,220 492 00:21:19,220 --> 00:21:21,250 >> Daya tahan cukup sederhana. 493 00:21:21,250 --> 00:21:23,460 Ketika transaksi diakui, itu 494 00:21:23,460 --> 00:21:26,100 akan berada di sana bahkan jika sistem crash. 495 00:21:26,100 --> 00:21:29,230 Ketika sistem yang pulih, yang transaksi yang dilakukan 496 00:21:29,230 --> 00:21:30,480 sebenarnya akan berada di sana. 497 00:21:30,480 --> 00:21:33,130 Jadi itulah jaminan transaksi ACID. 498 00:21:33,130 --> 00:21:35,470 Mereka adalah jaminan cukup bagus untuk memiliki di database, 499 00:21:35,470 --> 00:21:36,870 tetapi mereka datang dengan biaya itu. 500 00:21:36,870 --> 00:21:37,640 Kanan? 501 00:21:37,640 --> 00:21:40,520 >> Karena masalah dengan kerangka ini 502 00:21:40,520 --> 00:21:44,540 jika ada partisi dalam data set, saya harus membuat keputusan. 503 00:21:44,540 --> 00:21:48,000 Aku akan harus memungkinkan update di satu sisi atau yang lain. 504 00:21:48,000 --> 00:21:50,310 Dan jika itu terjadi, maka aku tidak lagi akan 505 00:21:50,310 --> 00:21:52,630 untuk dapat mempertahankan karakteristik. 506 00:21:52,630 --> 00:21:53,960 Mereka tidak akan konsisten. 507 00:21:53,960 --> 00:21:55,841 Mereka tidak akan terisolasi. 508 00:21:55,841 --> 00:21:58,090 Di sinilah itu rusak untuk database relasional. 509 00:21:58,090 --> 00:22:01,360 Ini adalah alasan relasional database skala vertikal. 510 00:22:01,360 --> 00:22:05,530 >> Di sisi lain, kita memiliki apa yang disebut teknologi BASIS. 511 00:22:05,530 --> 00:22:07,291 Dan ini adalah NoSQL Database Anda. 512 00:22:07,291 --> 00:22:07,790 Baiklah. 513 00:22:07,790 --> 00:22:10,180 Jadi kita harus CP kami, database AP. 514 00:22:10,180 --> 00:22:14,720 Dan ini adalah apa yang Anda sebut pada dasarnya tersedia, negara lembut, akhirnya 515 00:22:14,720 --> 00:22:15,740 konsisten. 516 00:22:15,740 --> 00:22:16,420 OKE? 517 00:22:16,420 --> 00:22:19,690 >> Pada dasarnya tersedia, karena mereka toleran partisi. 518 00:22:19,690 --> 00:22:21,470 Mereka akan selalu ada, bahkan jika ada 519 00:22:21,470 --> 00:22:23,053 partisi jaringan antara node. 520 00:22:23,053 --> 00:22:25,900 Jika saya dapat berbicara dengan sebuah node, aku akan dapat membaca data. 521 00:22:25,900 --> 00:22:26,460 OKE? 522 00:22:26,460 --> 00:22:30,810 Aku mungkin tidak selalu bisa menulis data jika aku platform yang konsisten. 523 00:22:30,810 --> 00:22:32,130 Tapi saya akan dapat membaca data. 524 00:22:32,130 --> 00:22:34,960 525 00:22:34,960 --> 00:22:38,010 >> Negara lembut menunjukkan bahwa ketika saya membaca data itu, 526 00:22:38,010 --> 00:22:40,790 tidak mungkin sama dengan node lain. 527 00:22:40,790 --> 00:22:43,390 Jika hak dikeluarkan pada node tempat lain di cluster 528 00:22:43,390 --> 00:22:46,650 dan belum direplikasi di seluruh klaster namun ketika saya membaca bahwa data, 529 00:22:46,650 --> 00:22:48,680 negara yang mungkin tidak konsisten. 530 00:22:48,680 --> 00:22:51,650 Namun, itu akan menjadi akhirnya konsisten, 531 00:22:51,650 --> 00:22:53,870 yang berarti bahwa ketika menulis sebuah dibuat untuk sistem, 532 00:22:53,870 --> 00:22:56,480 itu akan mereplikasi di node. 533 00:22:56,480 --> 00:22:59,095 Dan akhirnya, negara yang akan dibawa ke urutan, 534 00:22:59,095 --> 00:23:00,890 dan itu akan menjadi negara yang konsisten. 535 00:23:00,890 --> 00:23:05,000 >> Sekarang, CAP teorema benar memainkan hanya dalam satu kondisi. 536 00:23:05,000 --> 00:23:08,700 Kondisi yang saat ini terjadi. 537 00:23:08,700 --> 00:23:13,710 Karena setiap kali itu beroperasi di mode normal, tidak ada partisi, 538 00:23:13,710 --> 00:23:16,370 semuanya konsisten dan tersedia. 539 00:23:16,370 --> 00:23:19,990 Anda hanya khawatir tentang CAP ketika kita memiliki partisi itu. 540 00:23:19,990 --> 00:23:21,260 Jadi mereka adalah langka. 541 00:23:21,260 --> 00:23:25,360 Tapi bagaimana sistem bereaksi ketika mereka terjadi mendikte apa jenis sistem 542 00:23:25,360 --> 00:23:26,750 kita sedang berhadapan dengan. 543 00:23:26,750 --> 00:23:31,110 >> Jadi mari kita lihat apa yang yang terlihat seperti untuk sistem AP. 544 00:23:31,110 --> 00:23:32,621 OKE? 545 00:23:32,621 --> 00:23:34,830 Sistem AP datang dalam dua rasa. 546 00:23:34,830 --> 00:23:38,514 Mereka datang dalam rasa yang adalah Master Master, 100%, selalu tersedia. 547 00:23:38,514 --> 00:23:40,430 Dan mereka datang dalam rasa lainnya, yang mengatakan, 548 00:23:40,430 --> 00:23:43,330 Anda tahu apa, aku akan khawatir tentang hal ini partisi 549 00:23:43,330 --> 00:23:44,724 ketika partisi yang sebenarnya terjadi. 550 00:23:44,724 --> 00:23:47,890 Jika tidak, ada akan menjadi primary node yang akan mengambil hak. 551 00:23:47,890 --> 00:23:48,500 OKE? 552 00:23:48,500 --> 00:23:50,040 >> Jadi jika kita sesuatu seperti Cassandra. 553 00:23:50,040 --> 00:23:54,440 Cassandra akan menjadi master Master, mari saya menulis untuk setiap node. 554 00:23:54,440 --> 00:23:55,540 Jadi apa yang terjadi? 555 00:23:55,540 --> 00:23:58,270 Jadi saya memiliki objek di database yang ada pada dua node. 556 00:23:58,270 --> 00:24:01,705 Mari kita sebut bahwa objek S. Jadi kita memiliki negara untuk S. 557 00:24:01,705 --> 00:24:04,312 Kami memiliki beberapa operasi pada S yang sedang berlangsung. 558 00:24:04,312 --> 00:24:06,270 Cassandra memungkinkan saya untuk menulis ke beberapa node. 559 00:24:06,270 --> 00:24:08,550 Jadi katakanlah saya mendapatkan menulis untuk s untuk dua node. 560 00:24:08,550 --> 00:24:12,274 Nah, apa yang akhirnya terjadi adalah kita sebut bahwa acara partisi. 561 00:24:12,274 --> 00:24:14,190 Ada mungkin bukan partisi jaringan fisik. 562 00:24:14,190 --> 00:24:15,950 Tetapi karena desain sistem, itu 563 00:24:15,950 --> 00:24:18,449 sebenarnya partisi segera karena saya mendapatkan write pada dua node. 564 00:24:18,449 --> 00:24:20,830 Ini tidak memaksa saya untuk menulis semua melalui satu simpul. 565 00:24:20,830 --> 00:24:22,340 Aku menulis pada dua node. 566 00:24:22,340 --> 00:24:23,330 OKE? 567 00:24:23,330 --> 00:24:25,740 >> Jadi sekarang aku punya dua negara. 568 00:24:25,740 --> 00:24:26,360 OKE? 569 00:24:26,360 --> 00:24:28,110 Apa yang akan terjadi adalah cepat atau lambat, 570 00:24:28,110 --> 00:24:29,960 ada akan menjadi peristiwa replikasi. 571 00:24:29,960 --> 00:24:33,300 Ada akan menjadi apa yang kita disebut pemulihan partisi, yang 572 00:24:33,300 --> 00:24:35,200 adalah di mana kedua negara kembali bersama-sama 573 00:24:35,200 --> 00:24:37,310 dan ada akan menjadi sebuah algoritma yang berjalan di dalam database, 574 00:24:37,310 --> 00:24:38,540 memutuskan apa yang harus dilakukan. 575 00:24:38,540 --> 00:24:39,110 OKE? 576 00:24:39,110 --> 00:24:43,057 Secara default, update terakhir menang di sebagian besar sistem AP. 577 00:24:43,057 --> 00:24:44,890 Jadi biasanya ada algoritma default, apa 578 00:24:44,890 --> 00:24:47,400 mereka sebut callback fungsi, sesuatu yang 579 00:24:47,400 --> 00:24:51,000 akan dipanggil ketika kondisi ini terdeteksi untuk menjalankan beberapa logika 580 00:24:51,000 --> 00:24:52,900 untuk menyelesaikan konflik itu. 581 00:24:52,900 --> 00:24:53,850 OKE? 582 00:24:53,850 --> 00:24:58,770 The callback default dan standar penyelesai di sebagian besar database AP 583 00:24:58,770 --> 00:25:01,130 adalah, coba tebak, timestamp menang. 584 00:25:01,130 --> 00:25:02,380 Ini adalah update terakhir. 585 00:25:02,380 --> 00:25:04,320 Aku akan menempatkan pembaruan yang di sana. 586 00:25:04,320 --> 00:25:08,440 Aku mungkin membuang catatan ini bahwa saya dibuang off menjadi log pemulihan 587 00:25:08,440 --> 00:25:11,670 sehingga pengguna dapat kembali lagi nanti dan berkata, hey, ada tabrakan. 588 00:25:11,670 --> 00:25:12,320 Apa yang terjadi? 589 00:25:12,320 --> 00:25:16,370 Dan Anda benar-benar dapat membuang catatan semua tabrakan dan rollbacks 590 00:25:16,370 --> 00:25:17,550 dan melihat apa yang terjadi. 591 00:25:17,550 --> 00:25:21,580 >> Sekarang, sebagai pengguna, Anda juga bisa termasuk logika ke callback itu. 592 00:25:21,580 --> 00:25:24,290 Jadi Anda dapat mengubah itu operasi callback. 593 00:25:24,290 --> 00:25:26,730 Anda dapat mengatakan, hei, saya ingin untuk memulihkan data ini. 594 00:25:26,730 --> 00:25:28,880 Dan saya ingin mencoba dan menggabungkan dua catatan. 595 00:25:28,880 --> 00:25:30,050 Tapi itu terserah Anda. 596 00:25:30,050 --> 00:25:32,880 Database tidak tahu bagaimana melakukannya secara default. Sebagian besar waktu, 597 00:25:32,880 --> 00:25:34,850 satu-satunya hal database yang tahu bagaimana melakukan ini mengatakan, 598 00:25:34,850 --> 00:25:36,100 satu ini catatan terakhir. 599 00:25:36,100 --> 00:25:39,183 Itu salah satu yang akan menang, dan itulah nilai aku akan menempatkan. 600 00:25:39,183 --> 00:25:41,490 Setelah itu pemulihan partisi dan replikasi terjadi, 601 00:25:41,490 --> 00:25:43,930 kami memiliki negara kita, yang sekarang S perdana, yang merupakan 602 00:25:43,930 --> 00:25:46,890 negara gabungan dari semua objek tersebut. 603 00:25:46,890 --> 00:25:49,700 Jadi sistem AP memiliki ini. 604 00:25:49,700 --> 00:25:51,615 Sistem CP tidak perlu khawatir tentang hal ini. 605 00:25:51,615 --> 00:25:54,490 Karena begitu partisi datang ke dalam bermain, mereka hanya berhenti mengambil 606 00:25:54,490 --> 00:25:55,530 menulis. 607 00:25:55,530 --> 00:25:56,180 OKE? 608 00:25:56,180 --> 00:25:58,670 Sehingga sangat mudah untuk berurusan dengan konsisten 609 00:25:58,670 --> 00:26:01,330 ketika Anda tidak menerima pembaruan. 610 00:26:01,330 --> 00:26:04,620 Itu dengan sistem CP lakukan. 611 00:26:04,620 --> 00:26:05,120 Baiklah. 612 00:26:05,120 --> 00:26:07,590 >> Jadi mari kita bicara sedikit sedikit tentang pola akses. 613 00:26:07,590 --> 00:26:11,580 Ketika kita berbicara tentang NoSQL, itu semua tentang pola akses. 614 00:26:11,580 --> 00:26:13,550 Sekarang, SQL adalah ad hoc, query. 615 00:26:13,550 --> 00:26:14,481 Ini toko relasional. 616 00:26:14,481 --> 00:26:16,480 Kami tidak perlu khawatir tentang pola akses. 617 00:26:16,480 --> 00:26:17,688 Saya menulis query yang sangat kompleks. 618 00:26:17,688 --> 00:26:19,250 Ia pergi dan mendapatkan data. 619 00:26:19,250 --> 00:26:21,210 Itulah yang ini terlihat seperti, normalisasi. 620 00:26:21,210 --> 00:26:24,890 >> Jadi dalam struktur tertentu, kita sedang melihat katalog produk. 621 00:26:24,890 --> 00:26:26,640 Saya memiliki berbagai jenis produk. 622 00:26:26,640 --> 00:26:27,217 Saya memiliki buku-buku. 623 00:26:27,217 --> 00:26:27,800 Saya memiliki album. 624 00:26:27,800 --> 00:26:30,090 Saya memiliki video. 625 00:26:30,090 --> 00:26:33,370 Hubungan antara produk dan salah satu dari buku-buku, album, 626 00:26:33,370 --> 00:26:34,860 dan video tabel adalah 1: 1. 627 00:26:34,860 --> 00:26:35,800 Baiklah? 628 00:26:35,800 --> 00:26:38,860 Aku punya ID produk, dan bahwa ID berkorespondensi 629 00:26:38,860 --> 00:26:41,080 untuk buku, album, atau video. 630 00:26:41,080 --> 00:26:41,580 OKE? 631 00:26:41,580 --> 00:26:44,350 Itu 1: 1 hubungan di meja tersebut. 632 00:26:44,350 --> 00:26:46,970 >> Sekarang, books-- semua mereka miliki adalah sifat akar. 633 00:26:46,970 --> 00:26:47,550 Tidak masalah. 634 00:26:47,550 --> 00:26:48,230 Itu bagus. 635 00:26:48,230 --> 00:26:52,130 Satu-ke-satu hubungan, saya mendapatkan semua data yang saya butuhkan untuk menggambarkan buku itu. 636 00:26:52,130 --> 00:26:54,770 Album Albums-- memiliki trek. 637 00:26:54,770 --> 00:26:56,470 Ini adalah apa yang kita sebut satu ke banyak. 638 00:26:56,470 --> 00:26:58,905 Setiap album bisa memiliki banyak lagu. 639 00:26:58,905 --> 00:27:00,780 Jadi untuk setiap lagu pada album, aku bisa memiliki 640 00:27:00,780 --> 00:27:02,570 catatan lain dalam tabel anak ini. 641 00:27:02,570 --> 00:27:04,680 Jadi saya membuat satu record dalam tabel album saya. 642 00:27:04,680 --> 00:27:06,700 Saya membuat beberapa catatan dalam tabel trek. 643 00:27:06,700 --> 00:27:08,850 Satu-ke-banyak hubungan. 644 00:27:08,850 --> 00:27:11,220 >> Hubungan ini adalah apa yang kita sebut banyak-ke-banyak. 645 00:27:11,220 --> 00:27:11,750 OKE? 646 00:27:11,750 --> 00:27:17,000 Anda melihat bahwa pelaku bisa di banyak film, banyak video. 647 00:27:17,000 --> 00:27:21,450 Jadi apa yang kita lakukan adalah kita menempatkan pemetaan ini meja antara, yang hanya 648 00:27:21,450 --> 00:27:24,040 peta aktor ID ke ID video. 649 00:27:24,040 --> 00:27:28,464 Sekarang saya bisa membuat query bergabung video melalui aktor video ke aktor, 650 00:27:28,464 --> 00:27:31,130 dan itu memberi saya sebuah daftar dari semua film dan semua aktor 651 00:27:31,130 --> 00:27:32,420 yang dalam film itu. 652 00:27:32,420 --> 00:27:33,290 >> OKE. 653 00:27:33,290 --> 00:27:33,880 Jadi di sini kita pergi. 654 00:27:33,880 --> 00:27:38,040 Satu-ke-satu adalah top-level hubungan; satu-ke-banyak, 655 00:27:38,040 --> 00:27:40,240 album ke trek; banyak-ke-banyak. 656 00:27:40,240 --> 00:27:44,990 Mereka adalah tiga tingkat atas hubungan dalam database apapun. 657 00:27:44,990 --> 00:27:48,050 Jika Anda tahu bagaimana mereka hubungan bekerja sama, 658 00:27:48,050 --> 00:27:51,490 maka Anda tahu banyak tentang database sudah. 659 00:27:51,490 --> 00:27:55,660 Jadi NoSQL bekerja sedikit berbeda. 660 00:27:55,660 --> 00:27:58,930 Mari kita berpikir tentang untuk kedua apa terlihat ingin pergi mendapatkan semua produk saya. 661 00:27:58,930 --> 00:28:01,096 >> Dalam sebuah toko relasional, saya ingin mendapatkan semua produk saya 662 00:28:01,096 --> 00:28:02,970 pada daftar semua produk saya. 663 00:28:02,970 --> 00:28:04,910 Itu banyak pertanyaan. 664 00:28:04,910 --> 00:28:07,030 Saya punya pertanyaan untuk semua buku-buku saya. 665 00:28:07,030 --> 00:28:08,470 Saya mendapat pertanyaan dari album saya. 666 00:28:08,470 --> 00:28:09,970 Dan saya mendapat permintaan untuk semua video saya. 667 00:28:09,970 --> 00:28:11,719 Dan aku harus meletakkannya semua bersama-sama dalam daftar 668 00:28:11,719 --> 00:28:15,250 dan melayani kembali ke aplikasi yang meminta itu. 669 00:28:15,250 --> 00:28:18,000 >> Untuk mendapatkan buku-buku saya, saya bergabung Produk dan Buku. 670 00:28:18,000 --> 00:28:21,680 Untuk mendapatkan album saya, saya harus bergabung Produk, Album, dan Trek. 671 00:28:21,680 --> 00:28:25,330 Dan untuk mendapatkan video saya, saya memiliki untuk bergabung Produk untuk Video, 672 00:28:25,330 --> 00:28:28,890 bergabung melalui Aktor Video, dan membawa Aktor. 673 00:28:28,890 --> 00:28:31,020 Jadi itulah tiga pertanyaan. 674 00:28:31,020 --> 00:28:34,560 Pertanyaan yang sangat kompleks untuk merakit satu set hasil. 675 00:28:34,560 --> 00:28:36,540 >> Itu kurang optimal. 676 00:28:36,540 --> 00:28:39,200 Itulah sebabnya ketika kita berbicara tentang struktur data yang 677 00:28:39,200 --> 00:28:42,900 dibangun untuk menjadi agnostik untuk akses pattern-- baik itu besar. 678 00:28:42,900 --> 00:28:45,730 Dan Anda dapat melihat ini benar-benar bagus bagaimana kita telah mengatur data. 679 00:28:45,730 --> 00:28:46,550 Dan kau tahu apa? 680 00:28:46,550 --> 00:28:49,750 Saya hanya memiliki satu catatan untuk seorang aktor. 681 00:28:49,750 --> 00:28:50,440 >> Keren. 682 00:28:50,440 --> 00:28:53,750 Saya sudah deduplicated semua aktor saya, dan saya dipelihara asosiasi saya 683 00:28:53,750 --> 00:28:55,200 dalam tabel pemetaan ini. 684 00:28:55,200 --> 00:29:00,620 Namun, mendapatkan data keluar menjadi mahal. 685 00:29:00,620 --> 00:29:04,500 Saya mengirim CPU seluruh sistem bergabung struktur data ini bersama-sama 686 00:29:04,500 --> 00:29:05,950 untuk dapat menarik bahwa data kembali. 687 00:29:05,950 --> 00:29:07,310 >> Jadi bagaimana saya mendapatkan sekitar itu? 688 00:29:07,310 --> 00:29:11,200 Dalam NoSQL ini tentang agregasi, tidak normalisasi. 689 00:29:11,200 --> 00:29:13,534 Jadi kita ingin mengatakan kami ingin mendukung pola akses. 690 00:29:13,534 --> 00:29:15,283 Jika pola akses untuk aplikasi, 691 00:29:15,283 --> 00:29:16,770 Saya perlu untuk mendapatkan semua produk saya. 692 00:29:16,770 --> 00:29:19,027 Mari kita menempatkan semua produk dalam satu meja. 693 00:29:19,027 --> 00:29:22,110 Jika saya menempatkan semua produk dalam satu meja, Aku hanya bisa memilih semua produk 694 00:29:22,110 --> 00:29:23,850 dari meja itu dan aku mendapatkan itu semua. 695 00:29:23,850 --> 00:29:25,240 Nah bagaimana cara melakukannya? 696 00:29:25,240 --> 00:29:28,124 Nah di NoSQL tidak ada struktur ke meja. 697 00:29:28,124 --> 00:29:30,540 Kami akan berbicara sedikit tentang bagaimana ini bekerja di Dynamo DB. 698 00:29:30,540 --> 00:29:33,570 Tapi Anda tidak memiliki sama atribut dan sifat yang sama 699 00:29:33,570 --> 00:29:37,751 di setiap baris, di setiap satu item, seperti yang Anda lakukan di meja SQL. 700 00:29:37,751 --> 00:29:39,750 Dan apa ini memungkinkan saya untuk melakukan banyak hal 701 00:29:39,750 --> 00:29:41,124 dan memberi saya banyak fleksibilitas. 702 00:29:41,124 --> 00:29:45,360 Dalam kasus ini, saya memiliki dokumen produk saya. 703 00:29:45,360 --> 00:29:49,090 Dan dalam hal ini khususnya Misalnya, semuanya 704 00:29:49,090 --> 00:29:51,930 adalah dokumen dalam tabel Produk. 705 00:29:51,930 --> 00:29:56,510 Dan produk untuk sebuah buku mungkin memiliki ID jenis yang menentukan sebuah buku. 706 00:29:56,510 --> 00:29:59,180 Dan aplikasi akan beralih pada ID itu. 707 00:29:59,180 --> 00:30:02,570 >> Pada tingkat aplikasi, aku akan mengatakan oh, apa catatan jenis ini? 708 00:30:02,570 --> 00:30:04,100 Oh, itu catatan buku. 709 00:30:04,100 --> 00:30:05,990 Catatan buku memiliki sifat ini. 710 00:30:05,990 --> 00:30:08,100 Biarkan saya membuat objek buku. 711 00:30:08,100 --> 00:30:11,289 Jadi aku akan mengisi objek buku dengan item ini. 712 00:30:11,289 --> 00:30:13,080 Item berikutnya datang dan mengatakan, apa item ini? 713 00:30:13,080 --> 00:30:14,560 Nah item ini adalah sebuah album. 714 00:30:14,560 --> 00:30:17,340 Oh, aku punya yang berbeda secara keseluruhan pengolahan rutin untuk itu, 715 00:30:17,340 --> 00:30:18,487 karena itu album. 716 00:30:18,487 --> 00:30:19,320 Anda melihat apa yang saya maksud? 717 00:30:19,320 --> 00:30:21,950 >> Jadi aplikasi tier-- saya hanya memilih semua catatan tersebut. 718 00:30:21,950 --> 00:30:23,200 Mereka semua mulai datang di. 719 00:30:23,200 --> 00:30:24,680 Mereka bisa menjadi semua jenis. 720 00:30:24,680 --> 00:30:27,590 Dan itu logika aplikasi yang switch di jenis-jenis 721 00:30:27,590 --> 00:30:29,530 dan memutuskan bagaimana mengolahnya. 722 00:30:29,530 --> 00:30:33,640 >> Sekali lagi, jadi kita mengoptimalkan skema untuk pola akses. 723 00:30:33,640 --> 00:30:36,390 Kami melakukannya dengan runtuh meja tersebut. 724 00:30:36,390 --> 00:30:39,670 Kami pada dasarnya mengambil ini struktur normal, 725 00:30:39,670 --> 00:30:42,000 dan kami sedang membangun struktur hirarkis. 726 00:30:42,000 --> 00:30:45,130 Di dalam masing-masing dari catatan-catatan Aku akan melihat sifat array. 727 00:30:45,130 --> 00:30:49,400 >> Di dalam dokumen ini untuk Album, Saya melihat array dari trek. 728 00:30:49,400 --> 00:30:53,900 Mereka trek sekarang become-- itu pada dasarnya tabel anak ini yang 729 00:30:53,900 --> 00:30:56,520 ada di sini, di struktur ini. 730 00:30:56,520 --> 00:30:57,975 Sehingga Anda dapat melakukan ini di DynamoDB. 731 00:30:57,975 --> 00:30:59,810 Anda dapat melakukan ini di MongoDB. 732 00:30:59,810 --> 00:31:01,437 Anda dapat melakukan ini di database NoSQL. 733 00:31:01,437 --> 00:31:03,520 Buat jenis struktur data hirarkis 734 00:31:03,520 --> 00:31:07,120 yang memungkinkan Anda mengambil data sangat cepat karena sekarang saya 735 00:31:07,120 --> 00:31:08,537 tidak perlu menyesuaikan diri. 736 00:31:08,537 --> 00:31:11,620 Ketika saya memasukkan baris ke Trek tabel, atau baris ke dalam tabel Album, 737 00:31:11,620 --> 00:31:13,110 Saya harus menyesuaikan diri dengan skema itu. 738 00:31:13,110 --> 00:31:18,060 Saya harus memiliki atribut atau properti yang didefinisikan di atas meja itu. 739 00:31:18,060 --> 00:31:20,480 Setiap salah satu dari mereka, ketika saya menyisipkan baris itu. 740 00:31:20,480 --> 00:31:21,910 Itu tidak terjadi di NoSQL. 741 00:31:21,910 --> 00:31:24,440 >> Saya dapat memiliki sama sekali berbeda properti di setiap dokumen 742 00:31:24,440 --> 00:31:26,100 yang saya masukkan ke dalam koleksi. 743 00:31:26,100 --> 00:31:30,480 Mekanisme jadi sangat kuat. 744 00:31:30,480 --> 00:31:32,852 Dan itu benar-benar bagaimana Anda mengoptimalkan sistem. 745 00:31:32,852 --> 00:31:35,310 Karena sekarang permintaan, bukan bergabung semua tabel ini 746 00:31:35,310 --> 00:31:39,160 dan mengeksekusi setengah lusin query untuk menarik kembali data yang saya butuhkan, 747 00:31:39,160 --> 00:31:40,890 Saya menjalankan satu permintaan. 748 00:31:40,890 --> 00:31:43,010 Dan aku iterasi seluruh hasil set. 749 00:31:43,010 --> 00:31:46,512 itu memberi Anda ide dari kekuatan NoSQL. 750 00:31:46,512 --> 00:31:49,470 Aku akan jenis pergi ke samping sini dan berbicara sedikit tentang hal ini. 751 00:31:49,470 --> 00:31:53,240 Ini lebih baik dari pemasaran atau technology-- 752 00:31:53,240 --> 00:31:55,660 pemasaran teknologi jenis diskusi. 753 00:31:55,660 --> 00:31:58,672 Tapi itu penting untuk memahami karena jika kita melihat di bagian atas 754 00:31:58,672 --> 00:32:00,380 di sini di grafik ini, apa yang kita sedang melihat 755 00:32:00,380 --> 00:32:04,030 adalah apa yang kita sebut teknologi kurva sensasi. 756 00:32:04,030 --> 00:32:06,121 Dan apa ini berarti barang baru datang ke dalam bermain. 757 00:32:06,121 --> 00:32:07,120 Orang pikir itu bagus. 758 00:32:07,120 --> 00:32:09,200 Saya telah memecahkan semua masalah saya. 759 00:32:09,200 --> 00:32:11,630 >> Ini bisa menjadi akhir semua, menjadi semua untuk semuanya. 760 00:32:11,630 --> 00:32:12,790 Dan mereka mulai menggunakannya. 761 00:32:12,790 --> 00:32:14,720 Dan mereka berkata, hal ini tidak bekerja. 762 00:32:14,720 --> 00:32:17,600 Ini tidak benar. 763 00:32:17,600 --> 00:32:19,105 Barang lama lebih baik. 764 00:32:19,105 --> 00:32:21,230 Dan mereka kembali untuk melakukan sesuatu dengan cara mereka. 765 00:32:21,230 --> 00:32:22,730 Dan kemudian akhirnya mereka pergi, Anda tahu apa? 766 00:32:22,730 --> 00:32:24,040 Hal ini tidak begitu buruk. 767 00:32:24,040 --> 00:32:26,192 Oh, itu cara kerjanya. 768 00:32:26,192 --> 00:32:28,900 Dan setelah mereka mengetahui bagaimana karya, mereka mulai mendapatkan yang lebih baik. 769 00:32:28,900 --> 00:32:32,050 >> Dan hal lucu tentang hal itu adalah, itu jenis garis sampai apa 770 00:32:32,050 --> 00:32:34,300 kita sebut Curve Adopsi Teknologi. 771 00:32:34,300 --> 00:32:36,910 Jadi apa yang terjadi adalah kita harus beberapa pemicu teknologi semacam. 772 00:32:36,910 --> 00:32:39,100 Dalam kasus database, itu tekanan data. 773 00:32:39,100 --> 00:32:42,200 Kami berbicara tentang poin air yang tinggi tekanan data seluruh waktu. 774 00:32:42,200 --> 00:32:46,310 Ketika tekanan Data hits tertentu titik, itu pemicu teknologi. 775 00:32:46,310 --> 00:32:47,830 >> Sudah mulai terlalu mahal. 776 00:32:47,830 --> 00:32:49,790 Waktu terlalu lama untuk memproses data. 777 00:32:49,790 --> 00:32:50,890 Kita perlu sesuatu yang lebih baik. 778 00:32:50,890 --> 00:32:52,890 Anda mendapatkan inovator di luar sana berlarian, 779 00:32:52,890 --> 00:32:55,050 mencoba untuk mencari tahu apa solusinya. 780 00:32:55,050 --> 00:32:56,050 Apa ide baru? 781 00:32:56,050 --> 00:32:58,170 >> Apa yang terbaik berikutnya cara untuk melakukan hal ini? 782 00:32:58,170 --> 00:32:59,530 Dan mereka datang dengan sesuatu. 783 00:32:59,530 --> 00:33:03,140 Dan orang-orang dengan rasa sakit yang nyata, orang-orang di tepi pendarahan, 784 00:33:03,140 --> 00:33:06,390 mereka akan melompat di atasnya, karena mereka butuh jawaban. 785 00:33:06,390 --> 00:33:09,690 Sekarang apa yang pasti happens-- dan itu terjadi sekarang di NoSQL. 786 00:33:09,690 --> 00:33:11,090 Saya melihatnya sepanjang waktu. 787 00:33:11,090 --> 00:33:13,610 >> Apa yang pasti terjadi adalah orang mulai menggunakan alat baru 788 00:33:13,610 --> 00:33:15,490 dengan cara yang sama mereka menggunakan alat tua. 789 00:33:15,490 --> 00:33:17,854 Dan mereka tahu itu tidak bekerja dengan baik. 790 00:33:17,854 --> 00:33:20,020 Saya tidak ingat siapa aku berbicara dengan hari sebelumnya. 791 00:33:20,020 --> 00:33:22,080 Tapi seperti, ketika Konyol diciptakan, 792 00:33:22,080 --> 00:33:24,621 orang tidak ayunan itu lebih kepala mereka untuk menghancurkan beton. 793 00:33:24,621 --> 00:33:27,360 794 00:33:27,360 --> 00:33:30,610 >> Tapi itu adalah apa yang terjadi dengan NoSQL hari ini. 795 00:33:30,610 --> 00:33:33,900 Jika Anda berjalan di kebanyakan toko, mereka mencoba untuk menjadi toko NoSQL. 796 00:33:33,900 --> 00:33:36,510 Apa yang mereka lakukan adalah mereka menggunakan NoSQL, 797 00:33:36,510 --> 00:33:39,900 dan mereka loading penuh skema relasional. 798 00:33:39,900 --> 00:33:41,630 Karena itu bagaimana mereka merancang database. 799 00:33:41,630 --> 00:33:44,046 Dan mereka bertanya-tanya, mengapa tidak melakukan dengan sangat baik? 800 00:33:44,046 --> 00:33:45,230 Boy, hal ini bau. 801 00:33:45,230 --> 00:33:49,900 Aku harus menjaga semua saya bergabung in-- itu seperti, tidak, tidak. 802 00:33:49,900 --> 00:33:50,800 Menjaga bergabung? 803 00:33:50,800 --> 00:33:52,430 Mengapa Anda bergabung data? 804 00:33:52,430 --> 00:33:54,350 Anda tidak bergabung data dalam NoSQL. 805 00:33:54,350 --> 00:33:55,850 Anda agregat itu. 806 00:33:55,850 --> 00:34:00,690 >> Jadi jika Anda ingin menghindari ini, belajar bagaimana alat bekerja sebelum Anda benar-benar 807 00:34:00,690 --> 00:34:02,010 mulai menggunakannya. 808 00:34:02,010 --> 00:34:04,860 Jangan mencoba dan menggunakan alat-alat baru cara yang sama Anda menggunakan alat tua. 809 00:34:04,860 --> 00:34:06,500 Anda akan memiliki pengalaman buruk. 810 00:34:06,500 --> 00:34:08,848 Dan setiap kali itulah yang ini adalah tentang. 811 00:34:08,848 --> 00:34:11,389 Ketika kita mulai datang ke sini, itu karena orang tahu 812 00:34:11,389 --> 00:34:13,449 bagaimana menggunakan alat-alat. 813 00:34:13,449 --> 00:34:16,250 >> Mereka melakukan hal yang sama ketika database relasional diciptakan, 814 00:34:16,250 --> 00:34:17,969 dan mereka mengganti file sistem. 815 00:34:17,969 --> 00:34:20,420 Mereka mencoba untuk membangun sistem berkas dengan database relasional 816 00:34:20,420 --> 00:34:22,159 karena itulah yang orang mengerti. 817 00:34:22,159 --> 00:34:23,049 Ini tidak bekerja. 818 00:34:23,049 --> 00:34:26,090 Jadi memahami praktik terbaik teknologi Anda bekerja dengan 819 00:34:26,090 --> 00:34:26,730 sangat besar. 820 00:34:26,730 --> 00:34:29,870 Sangat penting. 821 00:34:29,870 --> 00:34:32,440 >> Jadi kita akan masuk ke DynamoDB. 822 00:34:32,440 --> 00:34:36,480 DynamoDB adalah AWS ini sepenuhnya dikelola platform yang NoSQL. 823 00:34:36,480 --> 00:34:37,719 Apa sepenuhnya dikelola artinya? 824 00:34:37,719 --> 00:34:40,010 Ini berarti Anda tidak perlu benar-benar khawatir tentang apa pun. 825 00:34:40,010 --> 00:34:42,060 >> Anda datang, Anda memberitahu kami, aku butuh meja. 826 00:34:42,060 --> 00:34:43,409 Perlu kapasitas jauh ini. 827 00:34:43,409 --> 00:34:47,300 Anda menekan tombol, dan kami penyediaan semua infrastruktur di belakang layar. 828 00:34:47,300 --> 00:34:48,310 Sekarang sangat besar. 829 00:34:48,310 --> 00:34:51,310 >> Karena ketika Anda berbicara tentang scaling database, 830 00:34:51,310 --> 00:34:53,917 Cluster Data NoSQL di skala, petabyte berjalan, 831 00:34:53,917 --> 00:34:55,750 menjalankan jutaan transaksi per detik, 832 00:34:55,750 --> 00:34:58,180 hal ini tidak kelompok kecil. 833 00:34:58,180 --> 00:35:00,830 Kita bicara ribuan kasus. 834 00:35:00,830 --> 00:35:04,480 Mengelola ribuan kasus, bahkan contoh virtual, 835 00:35:04,480 --> 00:35:06,350 adalah rasa sakit yang nyata di pantat. 836 00:35:06,350 --> 00:35:09,110 Maksud saya, berpikir tentang setiap kali Patch sistem operasi keluar 837 00:35:09,110 --> 00:35:11,552 atau versi baru dari database. 838 00:35:11,552 --> 00:35:13,260 maksudnya itu apa Anda operasional? 839 00:35:13,260 --> 00:35:16,330 Itu berarti Anda punya 1.200 server yang perlu diperbarui. 840 00:35:16,330 --> 00:35:18,960 Sekarang bahkan dengan otomatisasi, yang dapat memakan waktu yang lama. 841 00:35:18,960 --> 00:35:21,480 Yang dapat menyebabkan banyak sakit kepala operasional, 842 00:35:21,480 --> 00:35:23,090 karena saya mungkin memiliki layanan turun. 843 00:35:23,090 --> 00:35:26,070 >> Seperti yang saya memperbarui database ini, saya mungkin melakukan penyebaran hijau biru 844 00:35:26,070 --> 00:35:29,420 di mana saya menyebarkan dan meng-upgrade setengah node, dan kemudian meng-upgrade setengah lainnya. 845 00:35:29,420 --> 00:35:30,490 Mengambil orang-orang bawah. 846 00:35:30,490 --> 00:35:33,410 Jadi pengelolaan infrastruktur skala adalah sangat besar menyakitkan. 847 00:35:33,410 --> 00:35:36,210 Dan AWS mengambil rasa sakit yang keluar dari itu. 848 00:35:36,210 --> 00:35:39,210 Dan database NoSQL bisa menjadi sangat menyakitkan 849 00:35:39,210 --> 00:35:41,780 karena cara mereka skala. 850 00:35:41,780 --> 00:35:42,926 >> Skala horisontal. 851 00:35:42,926 --> 00:35:45,550 Jika Anda ingin mendapatkan lebih besar NoSQL Database, Anda membeli lebih node. 852 00:35:45,550 --> 00:35:48,660 Setiap simpul yang Anda beli adalah sakit kepala operasional lain. 853 00:35:48,660 --> 00:35:50,830 Jadi biarkan orang lain melakukannya untuk Anda. 854 00:35:50,830 --> 00:35:52,000 AWS bisa melakukan itu. 855 00:35:52,000 --> 00:35:54,587 >> Kami mendukung nilai-nilai kunci dokumen. 856 00:35:54,587 --> 00:35:56,670 Sekarang kita tidak pergi terlalu banyak ke pada grafik lainnya. 857 00:35:56,670 --> 00:35:58,750 Ada banyak yang berbeda rasa NoSQL. 858 00:35:58,750 --> 00:36:02,670 Mereka semua jenis mendapatkan munged bersama pada saat ini. 859 00:36:02,670 --> 00:36:06,260 Anda dapat melihat DynamoDB dan mengatakan ya, kami berdua dokumen dan nilai kunci 860 00:36:06,260 --> 00:36:08,412 menyimpan titik ini. 861 00:36:08,412 --> 00:36:10,620 Dan Anda bisa berdebat fitur dari satu atas yang lain. 862 00:36:10,620 --> 00:36:13,950 Bagi saya, banyak ini benar-benar enam satu setengah lusin yang lain. 863 00:36:13,950 --> 00:36:18,710 Setiap salah satu dari teknologi tersebut adalah teknologi baik dan solusi yang baik. 864 00:36:18,710 --> 00:36:23,390 Saya tidak akan mengatakan MongoDB lebih baik atau lebih buruk dari Couch, kemudian Cassandra, 865 00:36:23,390 --> 00:36:25,994 kemudian Dynamo, atau sebaliknya. 866 00:36:25,994 --> 00:36:27,285 Maksudku, ini hanya pilihan. 867 00:36:27,285 --> 00:36:29,850 868 00:36:29,850 --> 00:36:32,700 >> Ini cepat dan itu konsisten pada skala apapun. 869 00:36:32,700 --> 00:36:36,210 Jadi ini adalah salah satu yang terbesar bonus yang Anda dapatkan dengan AWS. 870 00:36:36,210 --> 00:36:40,850 Dengan DynamoDB adalah kemampuan untuk mendapatkan satu digit rendah 871 00:36:40,850 --> 00:36:44,040 milidetik latency pada skala apapun. 872 00:36:44,040 --> 00:36:45,720 Itu adalah tujuan desain sistem. 873 00:36:45,720 --> 00:36:49,130 Dan kami memiliki pelanggan yang melakukan jutaan transaksi per detik. 874 00:36:49,130 --> 00:36:52,670 >> Sekarang saya akan pergi melalui beberapa dari mereka menggunakan kasus dalam beberapa menit di sini. 875 00:36:52,670 --> 00:36:55,660 Terpadu control-- akses kita memiliki apa yang kita sebut 876 00:36:55,660 --> 00:36:57,920 Identitas Access Management, atau IAM. 877 00:36:57,920 --> 00:37:01,980 Ini menembus setiap sistem, setiap layanan yang menawarkan AWS. 878 00:37:01,980 --> 00:37:03,630 DynamoDB tidak terkecuali. 879 00:37:03,630 --> 00:37:06,020 Anda dapat mengontrol akses ke meja DynamoDB. 880 00:37:06,020 --> 00:37:09,960 Di semua AWS Anda rekening oleh mendefinisikan peran akses dan izin 881 00:37:09,960 --> 00:37:12,140 dalam infrastruktur IAM. 882 00:37:12,140 --> 00:37:16,630 >> Dan itu adalah komponen kunci dan integral dalam apa yang kita sebut acara Driven Programming. 883 00:37:16,630 --> 00:37:19,056 Sekarang ini adalah sebuah paradigma baru. 884 00:37:19,056 --> 00:37:22,080 >> AUDIENCE: Bagaimana tingkat Anda benar positif terhadap negatif palsu 885 00:37:22,080 --> 00:37:24,052 pada sistem kontrol akses Anda? 886 00:37:24,052 --> 00:37:26,260 RICK Houlihan: Benar positif dibandingkan negatif palsu? 887 00:37:26,260 --> 00:37:28,785 AUDIENCE: Kembali apa Anda harus kembali? 888 00:37:28,785 --> 00:37:33,720 Sebagai lawan sesekali itu tidak kembali ketika harus memvalidasi? 889 00:37:33,720 --> 00:37:36,260 890 00:37:36,260 --> 00:37:38,050 >> RICK Houlihan: Saya tidak bisa memberitahu Anda bahwa. 891 00:37:38,050 --> 00:37:40,140 Jika ada kegagalan setiap apapun pada itu, 892 00:37:40,140 --> 00:37:42,726 Saya bukan orang yang meminta pertanyaan tertentu. 893 00:37:42,726 --> 00:37:43,850 Tapi itu pertanyaan yang bagus. 894 00:37:43,850 --> 00:37:45,905 Saya akan penasaran ingin tahu itu sendiri, sebenarnya. 895 00:37:45,905 --> 00:37:48,810 896 00:37:48,810 --> 00:37:51,320 >> Dan sekali lagi, paradigma baru adalah pemrograman event driven. 897 00:37:51,320 --> 00:37:55,160 Ini adalah gagasan bahwa Anda bisa menyebarkan aplikasi kompleks yang 898 00:37:55,160 --> 00:37:59,720 dapat beroperasi sangat, skala sangat tinggi tanpa infrastruktur apapun. 899 00:37:59,720 --> 00:38:02,120 Tanpa tetap infrastruktur apapun. 900 00:38:02,120 --> 00:38:04,720 Dan kita akan berbicara sedikit tentang apa artinya seperti yang kita 901 00:38:04,720 --> 00:38:06,550 mendapatkan ke beberapa berikutnya grafik. 902 00:38:06,550 --> 00:38:08,716 >> Hal pertama yang akan kita lakukan adalah kita akan berbicara tentang meja. 903 00:38:08,716 --> 00:38:10,857 Tipe data API untuk Dynamo. 904 00:38:10,857 --> 00:38:13,190 Dan hal pertama yang Anda akan melihat ketika Anda melihat ini, 905 00:38:13,190 --> 00:38:17,930 jika Anda terbiasa dengan database apapun, database telah benar-benar dua jenis API 906 00:38:17,930 --> 00:38:18,430 Saya akan menyebutnya. 907 00:38:18,430 --> 00:38:21,570 Atau dua set API. 908 00:38:21,570 --> 00:38:23,840 Salah satu dari mereka akan API administrasi. 909 00:38:23,840 --> 00:38:26,710 >> Hal-hal yang mereka mengurus fungsi database. 910 00:38:26,710 --> 00:38:31,340 Konfigurasi mesin penyimpanan, pengaturan dan menambahkan tabel. 911 00:38:31,340 --> 00:38:35,180 membuat database katalog dan contoh. 912 00:38:35,180 --> 00:38:40,450 Things-- ini di DynamoDB, Anda memiliki sangat singkat, daftar singkat. 913 00:38:40,450 --> 00:38:43,120 >> Jadi dalam database lain, Anda mungkin melihat puluhan 914 00:38:43,120 --> 00:38:45,680 dari perintah, dari administrasi perintah, untuk mengkonfigurasi 915 00:38:45,680 --> 00:38:47,290 ini opsi tambahan. 916 00:38:47,290 --> 00:38:51,234 Dalam DynamoDB Anda tidak perlu mereka karena Anda tidak mengkonfigurasi sistem, kita lakukan. 917 00:38:51,234 --> 00:38:54,150 Jadi satu-satunya hal yang perlu Anda lakukan adalah ceritakan apa ukuran meja yang saya butuhkan. 918 00:38:54,150 --> 00:38:55,660 Jadi Anda mendapatkan sangat perintah terbatas. 919 00:38:55,660 --> 00:38:58,618 >> Anda mendapatkan Membuat Tabel Update, Table, Hapus Tabel, dan Jelaskan Tabel. 920 00:38:58,618 --> 00:39:01,150 Mereka adalah satu-satunya hal yang Anda perlu untuk DynamoDB. 921 00:39:01,150 --> 00:39:03,294 Anda tidak perlu penyimpanan konfigurasi mesin. 922 00:39:03,294 --> 00:39:04,960 Saya tidak perlu khawatir tentang replikasi. 923 00:39:04,960 --> 00:39:06,490 Saya tidak perlu khawatir tentang sharding. 924 00:39:06,490 --> 00:39:07,800 >> Saya tidak perlu khawatir mengenai hal ini. 925 00:39:07,800 --> 00:39:08,740 Kami melakukan semuanya untuk Anda. 926 00:39:08,740 --> 00:39:11,867 Jadi itu sejumlah besar overhead itu hanya mengangkat dari piring Anda. 927 00:39:11,867 --> 00:39:13,200 Maka kita memiliki operator CRUD. 928 00:39:13,200 --> 00:39:17,740 CRUD adalah sesuatu yang kita sebut dalam database itu 929 00:39:17,740 --> 00:39:19,860 Buat, Update, Delete operator. 930 00:39:19,860 --> 00:39:24,180 Ini adalah umum Anda operasi database. 931 00:39:24,180 --> 00:39:31,299 Hal-hal seperti put item, mendapatkan item, pembaruan item, menghapus item, query batch, memindai. 932 00:39:31,299 --> 00:39:32,840 Jika Anda ingin memindai seluruh tabel. 933 00:39:32,840 --> 00:39:34,220 Tarik segala sesuatu dari meja. 934 00:39:34,220 --> 00:39:37,130 Salah satu hal yang menyenangkan tentang DynamoDB itu memungkinkan pemindaian paralel. 935 00:39:37,130 --> 00:39:40,602 Sehingga Anda dapat benar-benar membiarkan saya tahu berapa banyak benang Anda ingin menjalankan pemindaian itu. 936 00:39:40,602 --> 00:39:41,810 Dan kita dapat menjalankan mereka benang. 937 00:39:41,810 --> 00:39:43,985 Kita dapat berputar yang memindai up di beberapa thread 938 00:39:43,985 --> 00:39:49,060 sehingga Anda dapat memindai seluruh tabel ruang yang sangat, sangat cepat di DynamoDB. 939 00:39:49,060 --> 00:39:51,490 >> API lainnya yang kita miliki adalah apa yang kita sebut Streaming API kami. 940 00:39:51,490 --> 00:39:52,940 Kami tidak akan berbicara terlalu banyak tentang ini sekarang. 941 00:39:52,940 --> 00:39:55,189 Saya punya beberapa konten kemudian di dalam dek tentang hal ini. 942 00:39:55,189 --> 00:39:59,910 Tapi Streaming benar-benar sebuah running-- menganggapnya sebagai memerintahkan waktu 943 00:39:59,910 --> 00:40:01,274 dan log perubahan partisi. 944 00:40:01,274 --> 00:40:03,940 Segala sesuatu yang terjadi di tabel muncul di sungai. 945 00:40:03,940 --> 00:40:05,940 >> Setiap menulis ke meja muncul di sungai. 946 00:40:05,940 --> 00:40:08,370 Anda dapat membaca sungai itu, dan Anda dapat melakukan hal-hal dengan itu. 947 00:40:08,370 --> 00:40:10,150 Kita akan berbicara tentang apa jenis hal yang Anda 948 00:40:10,150 --> 00:40:13,680 hubungannya dengan hal-hal seperti replikasi, membuat indeks sekunder. 949 00:40:13,680 --> 00:40:17,620 Semua jenis benar-benar keren hal yang dapat Anda lakukan dengan itu. 950 00:40:17,620 --> 00:40:19,150 >> Tipe data. 951 00:40:19,150 --> 00:40:23,320 Dalam DynamoDB, kami mendukung kunci nilai dan data dokumen jenis. 952 00:40:23,320 --> 00:40:26,350 Di sisi kiri layar di sini, kami punya tipe dasar kami. 953 00:40:26,350 --> 00:40:27,230 Nilai kunci jenis. 954 00:40:27,230 --> 00:40:30,040 Ini adalah string, nomor, dan binari. 955 00:40:30,040 --> 00:40:31,640 >> Jadi hanya tiga tipe dasar. 956 00:40:31,640 --> 00:40:33,700 Dan kemudian Anda dapat memiliki set mereka. 957 00:40:33,700 --> 00:40:37,650 Salah satu hal yang menyenangkan tentang NoSQL adalah Anda dapat berisi array sebagai properti. 958 00:40:37,650 --> 00:40:42,050 Dan dengan DynamoDB Anda dapat berisi array dari jenis dasar sebagai properti root. 959 00:40:42,050 --> 00:40:43,885 >> Dan kemudian ada jenis dokumen. 960 00:40:43,885 --> 00:40:45,510 Berapa banyak orang yang akrab dengan JSON? 961 00:40:45,510 --> 00:40:47,130 Kalian akrab dengan JSON begitu banyak? 962 00:40:47,130 --> 00:40:49,380 Ini pada dasarnya JavaScript, Objek, Notasi. 963 00:40:49,380 --> 00:40:52,510 Hal ini memungkinkan Anda untuk dasarnya mendefinisikan struktur hirarkis. 964 00:40:52,510 --> 00:40:58,107 >> Anda dapat menyimpan dokumen JSON pada DynamoDB menggunakan komponen umum 965 00:40:58,107 --> 00:41:00,940 atau blok bangunan yang tersedia dalam kebanyakan bahasa pemrograman. 966 00:41:00,940 --> 00:41:03,602 Jadi jika Anda memiliki Java, Anda melihat peta dan daftar. 967 00:41:03,602 --> 00:41:05,060 Aku bisa membuat objek yang peta area. 968 00:41:05,060 --> 00:41:08,030 Sebuah peta dengan nilai-nilai kunci disimpan sebagai properti. 969 00:41:08,030 --> 00:41:10,890 Dan mungkin memiliki daftar nilai-nilai dalam properti-properti. 970 00:41:10,890 --> 00:41:13,490 Anda dapat menyimpan kompleks ini struktur hirarkis 971 00:41:13,490 --> 00:41:16,320 sebagai atribut tunggal dari item DynamoDB. 972 00:41:16,320 --> 00:41:19,010 973 00:41:19,010 --> 00:41:24,460 >> Jadi tabel di DynamoDB, seperti kebanyakan Database NoSQL, tabel memiliki item. 974 00:41:24,460 --> 00:41:26,469 Dalam MongoDB Anda akan menyebut dokumen-dokumen ini. 975 00:41:26,469 --> 00:41:27,760 Dan itu akan menjadi dasar sofa. 976 00:41:27,760 --> 00:41:28,900 Juga database dokumen. 977 00:41:28,900 --> 00:41:29,941 Anda memanggil dokumen-dokumen ini. 978 00:41:29,941 --> 00:41:32,930 Dokumen atau barang memiliki atribut. 979 00:41:32,930 --> 00:41:35,850 Atribut dapat eksis atau tidak ada pada item. 980 00:41:35,850 --> 00:41:38,520 Dalam DynamoDB, ada satu atribut wajib. 981 00:41:38,520 --> 00:41:43,880 Sama seperti dalam database relasional, Anda memiliki kunci utama pada tabel. 982 00:41:43,880 --> 00:41:46,010 >> DynamoDB memiliki apa yang kita sebut kunci hash. 983 00:41:46,010 --> 00:41:48,280 Kunci hash harus unik. 984 00:41:48,280 --> 00:41:52,580 Jadi ketika saya mendefinisikan tabel hash, pada dasarnya apa yang saya katakan 985 00:41:52,580 --> 00:41:54,110 adalah setiap item akan memiliki kunci hash. 986 00:41:54,110 --> 00:41:58,520 Dan setiap kunci hash harus unik. 987 00:41:58,520 --> 00:42:01,200 >> Setiap item didefinisikan dengan itu kunci hash unik. 988 00:42:01,200 --> 00:42:02,940 Dan hanya ada satu. 989 00:42:02,940 --> 00:42:05,820 Ini adalah OK, tetapi seringkali apa yang orang butuhkan 990 00:42:05,820 --> 00:42:08,170 adalah mereka inginkan adalah hash ini Kunci untuk melakukan sedikit lebih 991 00:42:08,170 --> 00:42:11,010 dari sekedar menjadi pengenal unik. 992 00:42:11,010 --> 00:42:15,240 Sering kali kita ingin menggunakan kunci hash sebagai tingkat atas agregasi ember. 993 00:42:15,240 --> 00:42:19,160 Dan cara kita melakukan itu adalah dengan menambahkan apa yang kita sebut kunci jangkauan. 994 00:42:19,160 --> 00:42:22,460 >> Jadi jika itu hash hanya meja, ini harus unik. 995 00:42:22,460 --> 00:42:27,040 Jika itu adalah tabel hash dan jangkauan, Kombinasi hash dan jangkauan 996 00:42:27,040 --> 00:42:28,640 harus unik. 997 00:42:28,640 --> 00:42:30,110 Jadi berpikir tentang cara ini. 998 00:42:30,110 --> 00:42:32,140 Jika saya memiliki sebuah forum. 999 00:42:32,140 --> 00:42:39,010 Dan bentuk memiliki topik, ia memiliki posting, dan memiliki tanggapan. 1000 00:42:39,010 --> 00:42:42,630 >> Jadi saya mungkin memiliki hash kunci, yang merupakan ID topik. 1001 00:42:42,630 --> 00:42:46,650 Dan aku mungkin memiliki kunci jangkauan, yang merupakan ID respon. 1002 00:42:46,650 --> 00:42:49,650 Dengan cara itu jika saya ingin mendapatkan semua tanggapan untuk topik tertentu, 1003 00:42:49,650 --> 00:42:52,370 Aku hanya bisa query hash. 1004 00:42:52,370 --> 00:42:55,190 Saya hanya bisa mengatakan memberikan saya semua item yang memiliki hash ini. 1005 00:42:55,190 --> 00:43:01,910 Dan aku akan mendapatkan setiap pertanyaan atau posting untuk topik tertentu. 1006 00:43:01,910 --> 00:43:03,910 Ini agregasi tingkat atas sangat penting. 1007 00:43:03,910 --> 00:43:07,370 Mereka mendukung akses utama pola aplikasi. 1008 00:43:07,370 --> 00:43:09,420 Secara umum, ini adalah apa yang ingin kita lakukan. 1009 00:43:09,420 --> 00:43:11,780 Kami ingin table-- yang Anda memuat meja, 1010 00:43:11,780 --> 00:43:16,640 kami ingin struktur data dalam tabel sedemikian rupa 1011 00:43:16,640 --> 00:43:20,140 bahwa aplikasi dapat sangat cepat mengambil hasil tersebut. 1012 00:43:20,140 --> 00:43:24,510 Dan seringkali cara untuk melakukannya adalah untuk mempertahankan agregasi ini seperti yang kita 1013 00:43:24,510 --> 00:43:25,650 memasukkan data. 1014 00:43:25,650 --> 00:43:31,110 Pada dasarnya, kita menyebarkan data ke dalam ember terang seperti itu datang dalam. 1015 00:43:31,110 --> 00:43:35,210 >> Kunci Kisaran memungkinkan hash me-- Kunci harus kesetaraan. 1016 00:43:35,210 --> 00:43:39,490 Ketika saya query hash, saya harus mengatakan memberi saya hash yang sama ini. 1017 00:43:39,490 --> 00:43:41,950 Ketika saya query kisaran, saya bisa mengatakan memberi saya rentang 1018 00:43:41,950 --> 00:43:47,040 yang menggunakan segala jenis Operator kaya yang kami mendukung. 1019 00:43:47,040 --> 00:43:49,200 Beri aku semua item untuk hash. 1020 00:43:49,200 --> 00:43:52,520 Apakah sama, lebih besar dari, kurang dari, apakah itu dimulai dengan, 1021 00:43:52,520 --> 00:43:54,145 apakah itu ada di antara dua nilai tersebut? 1022 00:43:54,145 --> 00:43:56,811 Jadi jenis berbagai pertanyaan bahwa kita selalu tertarik. 1023 00:43:56,811 --> 00:43:59,650 Sekarang satu hal tentang data, ketika Anda melihat mengakses data, ketika 1024 00:43:59,650 --> 00:44:02,360 Anda mengakses data, itu selalu tentang agregasi. 1025 00:44:02,360 --> 00:44:05,770 Ini selalu tentang catatan yang terkait dengan ini. 1026 00:44:05,770 --> 00:44:10,390 Beri aku semuanya di sini that's-- semua transaksi pada kartu kredit ini 1027 00:44:10,390 --> 00:44:12,500 untuk bulan lalu. 1028 00:44:12,500 --> 00:44:13,960 Itu merupakan agregasi. 1029 00:44:13,960 --> 00:44:17,490 >> Hampir semua yang Anda lakukan dalam database semacam agregasi. 1030 00:44:17,490 --> 00:44:21,530 Jadi bisa dapat mendefinisikan ini ember dan memberikan berbagai ini 1031 00:44:21,530 --> 00:44:24,950 atribut untuk bisa query pada, mereka query kaya mendukung banyak, 1032 00:44:24,950 --> 00:44:27,165 banyak, banyak pola akses aplikasi. 1033 00:44:27,165 --> 00:44:30,990 1034 00:44:30,990 --> 00:44:35,000 >> Jadi hal lain kunci hash Apakah itu memberi kita suatu mekanisme 1035 00:44:35,000 --> 00:44:37,740 untuk dapat menyebarkan data sekitar. 1036 00:44:37,740 --> 00:44:40,390 Database NoSQL bekerja terbaik ketika data tersebut merata 1037 00:44:40,390 --> 00:44:41,740 didistribusikan di cluster. 1038 00:44:41,740 --> 00:44:44,530 1039 00:44:44,530 --> 00:44:47,050 Berapa banyak orang yang akrab dengan hashing algoritma? 1040 00:44:47,050 --> 00:44:49,860 Ketika saya mengatakan hash dan hashing-- sebuah karena algoritma hashing 1041 00:44:49,860 --> 00:44:54,140 adalah cara untuk dapat menghasilkan nilai acak dari setiap nilai yang diberikan. 1042 00:44:54,140 --> 00:44:59,300 Jadi dalam kasus ini, yang algoritma hash kita jalankan adalah ND 5 berdasarkan. 1043 00:44:59,300 --> 00:45:04,765 >> Dan jika saya memiliki ID, dan ini adalah kunci hash saya, saya memiliki 1, 2, 3. 1044 00:45:04,765 --> 00:45:07,390 Ketika saya menjalankan algoritma hash, itu akan datang kembali dan berkata, 1045 00:45:07,390 --> 00:45:10,800 juga 1 sama dengan 7B, 2 sama dengan 48, 3 sama dengan CD. 1046 00:45:10,800 --> 00:45:13,092 Mereka tersebar di seluruh ruang kunci. 1047 00:45:13,092 --> 00:45:14,050 Dan mengapa Anda melakukan ini? 1048 00:45:14,050 --> 00:45:17,120 Karena yang membuat yakin bahwa saya bisa menempatkan catatan di beberapa node. 1049 00:45:17,120 --> 00:45:19,574 >> Jika aku melakukan ini secara bertahap, 1, 2, 3. 1050 00:45:19,574 --> 00:45:21,990 Dan saya memiliki berbagai hash yang berjalan dalam kasus ini, 1051 00:45:21,990 --> 00:45:24,785 ruang hash kecil, berjalan dari 00 ke FF, 1052 00:45:24,785 --> 00:45:27,951 maka catatan akan datang dan mereka akan pergi 1, 2, 3, 4, 5, 1053 00:45:27,951 --> 00:45:30,390 6, 7, 8, 9, 10, 11, 12. 1054 00:45:30,390 --> 00:45:31,800 Apa yang terjadi? 1055 00:45:31,800 --> 00:45:34,860 Setiap insert akan node yang sama. 1056 00:45:34,860 --> 00:45:36,070 Anda melihat apa yang saya maksud? 1057 00:45:36,070 --> 00:45:40,910 >> Karena ketika aku membagi ruang, dan saya menyebarkan catatan ini di, 1058 00:45:40,910 --> 00:45:45,950 dan partisi saya, aku akan mengatakan partisi 1 memiliki ruang kunci 0-54. 1059 00:45:45,950 --> 00:45:47,720 Partisi 2 adalah 55-89. 1060 00:45:47,720 --> 00:45:49,780 Partisi 3 adalah AA untuk FF. 1061 00:45:49,780 --> 00:45:53,740 Jadi jika saya menggunakan linear incrementing ID, Anda dapat melihat apa yang terjadi. 1062 00:45:53,740 --> 00:45:57,410 1, 2, 3, 4, 5, 6, semua jalan sampai ke 54. 1063 00:45:57,410 --> 00:46:00,030 Jadi karena saya memalu catatan ke dalam sistem, 1064 00:46:00,030 --> 00:46:02,030 semuanya berakhir pergi ke salah satu simpul. 1065 00:46:02,030 --> 00:46:03,160 >> Itu tidak baik. 1066 00:46:03,160 --> 00:46:04,820 Itu antipattern. 1067 00:46:04,820 --> 00:46:08,760 Dalam MongoDB mereka memiliki masalah ini jika Anda tidak menggunakan kunci hash. 1068 00:46:08,760 --> 00:46:11,325 MongoDB memberikan Anda pilihan hashing nilai kunci. 1069 00:46:11,325 --> 00:46:13,950 Anda harus selalu melakukan itu, jika Anda menggunakan hash incrementing 1070 00:46:13,950 --> 00:46:17,380 kunci dalam MongoDB, atau Anda akan memaku setiap menulis ke satu simpul, 1071 00:46:17,380 --> 00:46:21,290 dan Anda akan membatasi write throughput Anda buruk. 1072 00:46:21,290 --> 00:46:24,896 >> AUDIENCE: Apakah yang A9 169 dalam desimal? 1073 00:46:24,896 --> 00:46:28,450 >> RICK Houlihan: Ya, itu suatu tempat di sekitar sana. 1074 00:46:28,450 --> 00:46:29,950 A9, saya tidak tahu. 1075 00:46:29,950 --> 00:46:32,200 Anda harus mendapatkan biner saya untuk kalkulator desimal. 1076 00:46:32,200 --> 00:46:34,237 Otak saya tidak bekerja seperti itu. 1077 00:46:34,237 --> 00:46:36,320 AUDIENCE: Hanya satu cepat Mongo komentar Anda. 1078 00:46:36,320 --> 00:46:39,530 Jadi adalah ID objek yang datang native dengan Mongo melakukan itu? 1079 00:46:39,530 --> 00:46:40,179 1080 00:46:40,179 --> 00:46:41,470 RICK Houlihan: Apakah itu melakukan itu? 1081 00:46:41,470 --> 00:46:42,970 Jika Anda tentukan itu. 1082 00:46:42,970 --> 00:46:45,030 Dengan MongoDB, Anda memiliki pilihan. 1083 00:46:45,030 --> 00:46:48,930 Anda dapat specify-- setiap dokumen MongoDB harus memiliki ID garis bawah. 1084 00:46:48,930 --> 00:46:50,300 Itu nilai yang unik. 1085 00:46:50,300 --> 00:46:55,240 >> Dalam MongoDB Anda dapat menentukan apakah hash atau tidak. 1086 00:46:55,240 --> 00:46:56,490 Mereka hanya memberikan pilihan. 1087 00:46:56,490 --> 00:46:58,198 Jika Anda tahu bahwa itu acak, tidak ada masalah. 1088 00:46:58,198 --> 00:46:59,640 Anda tidak perlu melakukan itu. 1089 00:46:59,640 --> 00:47:04,260 Jika Anda tahu bahwa itu tidak acak, yang itu incrementing, kemudian melakukan hash. 1090 00:47:04,260 --> 00:47:06,880 >> Sekarang hal tentang hashing, setelah Anda hash 1091 00:47:06,880 --> 00:47:08,800 sebuah value-- dan ini mengapa kunci hash selalu 1092 00:47:08,800 --> 00:47:13,740 pertanyaan unik, karena saya sudah berubah nilai, sekarang saya tidak bisa melakukan query jangkauan. 1093 00:47:13,740 --> 00:47:15,640 Saya tidak bisa mengatakan apakah ini antara ini atau itu, 1094 00:47:15,640 --> 00:47:20,800 karena nilai hash tidak akan menjadi setara dengan nilai aktual. 1095 00:47:20,800 --> 00:47:24,570 Jadi, ketika Anda hash yang kunci, itu hanya kesetaraan. 1096 00:47:24,570 --> 00:47:28,700 Inilah sebabnya mengapa di kunci hash DynamoDB pertanyaan selalu kesetaraan saja. 1097 00:47:28,700 --> 00:47:32,090 1098 00:47:32,090 --> 00:47:34,700 >> Jadi sekarang di kisaran KEY- ketika saya menambahkan bahwa kunci jangkauan, 1099 00:47:34,700 --> 00:47:38,180 catatan-catatan kunci kisaran semua datang dan mereka bisa disimpan pada partisi yang sama. 1100 00:47:38,180 --> 00:47:42,430 Jadi mereka sangat cepat, mudah diambil karena ini adalah hash, 1101 00:47:42,430 --> 00:47:43,220 ini jangkauan. 1102 00:47:43,220 --> 00:47:44,928 Dan Anda melihat segala sesuatu dengan hash yang sama 1103 00:47:44,928 --> 00:47:48,550 akan disimpan pada ruang partisi yang sama. 1104 00:47:48,550 --> 00:47:53,889 Anda dapat menggunakan kunci rentang untuk membantu mencari data Anda dekat dengan induknya. 1105 00:47:53,889 --> 00:47:55,180 Jadi apa yang saya benar-benar lakukan di sini? 1106 00:47:55,180 --> 00:47:57,320 Ini adalah salah satu hubungan banyak. 1107 00:47:57,320 --> 00:48:01,490 Hubungan antara kunci hash dan kunci kisaran satu ke banyak. 1108 00:48:01,490 --> 00:48:03,490 Saya dapat memiliki beberapa kunci hash. 1109 00:48:03,490 --> 00:48:07,610 Saya hanya dapat memiliki beberapa rentang kunci dalam setiap kunci hash. 1110 00:48:07,610 --> 00:48:11,910 >> Hash mendefinisikan orang tua, kisaran mendefinisikan anak. 1111 00:48:11,910 --> 00:48:15,240 Sehingga Anda dapat melihat ada analog di sini antara konstruk relasional 1112 00:48:15,240 --> 00:48:18,840 dan jenis yang sama konstruksi di NoSQL. 1113 00:48:18,840 --> 00:48:20,760 Orang berbicara tentang NoSQL sebagai nonrelational. 1114 00:48:20,760 --> 00:48:22,200 Ini bukan nonrelational. 1115 00:48:22,200 --> 00:48:24,680 Data selalu memiliki hubungan. 1116 00:48:24,680 --> 00:48:28,172 Hubungan mereka hanya dimodelkan berbeda. 1117 00:48:28,172 --> 00:48:29,880 Mari kita bicara sedikit sedikit tentang daya tahan. 1118 00:48:29,880 --> 00:48:34,860 Ketika Anda menulis untuk DynamoDB, menulis selalu tiga arah direplikasi. 1119 00:48:34,860 --> 00:48:37,550 Yang berarti bahwa kita memiliki tiga AZ. 1120 00:48:37,550 --> 00:48:39,160 AZ adalah Zona Ketersediaan. 1121 00:48:39,160 --> 00:48:43,430 Anda dapat memikirkan Ketersediaan Zona sebagai pusat data 1122 00:48:43,430 --> 00:48:45,447 atau kumpulan data center. 1123 00:48:45,447 --> 00:48:47,780 Hal-hal ini secara geografis terisolasi dari satu sama lain 1124 00:48:47,780 --> 00:48:51,610 di zona patahan yang berbeda, di berbeda jaringan listrik dan dataran banjir. 1125 00:48:51,610 --> 00:48:54,510 Kegagalan dalam satu AZ tidak akan mencatat lain. 1126 00:48:54,510 --> 00:48:56,890 Mereka juga terkait bersama-sama dengan serat gelap. 1127 00:48:56,890 --> 00:49:01,240 Mendukung satu sub 1 milidetik latency antara AZS. 1128 00:49:01,240 --> 00:49:05,390 Jadi ulangan Data real time mampu multi AZS. 1129 00:49:05,390 --> 00:49:09,990 >> Dan AZ penyebaran seringkali multi- memenuhi persyaratan ketersediaan tinggi 1130 00:49:09,990 --> 00:49:12,930 dari sebagian besar organisasi perusahaan. 1131 00:49:12,930 --> 00:49:16,139 Jadi DynamoDB tersebar di tiga AZS secara default. 1132 00:49:16,139 --> 00:49:19,430 Kami hanya akan pengetahuan menulis ketika dua dari tiga node datang kembali 1133 00:49:19,430 --> 00:49:21,470 dan berkata, Ya, saya mendapatkannya. 1134 00:49:21,470 --> 00:49:22,050 Kenapa itu? 1135 00:49:22,050 --> 00:49:25,950 Karena di sisi read kami hanya akan memberikan data kembali ketika 1136 00:49:25,950 --> 00:49:27,570 kami mendapatkannya dari dua node. 1137 00:49:27,570 --> 00:49:30,490 >> Jika saya mereplikasi di tiga, dan aku membaca dari dua, 1138 00:49:30,490 --> 00:49:32,840 Saya selalu dijamin memiliki setidaknya satu 1139 00:49:32,840 --> 00:49:35,720 dari mereka membaca menjadi sebagian salinan terbaru dari data. 1140 00:49:35,720 --> 00:49:38,340 Itulah yang membuat DynamoDB konsisten. 1141 00:49:38,340 --> 00:49:42,450 Sekarang Anda dapat memilih untuk mengaktifkan mereka konsisten membaca off. 1142 00:49:42,450 --> 00:49:45,070 Dalam hal saya akan mengatakan, Saya hanya akan membaca dari satu simpul. 1143 00:49:45,070 --> 00:49:47,430 Dan aku tidak bisa menjamin itu akan menjadi data terbaru. 1144 00:49:47,430 --> 00:49:49,450 >> Jadi jika menulis akan datang di, belum direplikasi belum, 1145 00:49:49,450 --> 00:49:50,360 Anda akan mendapatkan salinan itu. 1146 00:49:50,360 --> 00:49:52,220 Itu dibaca akhirnya konsisten. 1147 00:49:52,220 --> 00:49:54,640 Dan apa itu adalah setengah biaya. 1148 00:49:54,640 --> 00:49:56,140 Jadi ini adalah sesuatu untuk dipikirkan. 1149 00:49:56,140 --> 00:50:00,160 Ketika Anda membaca keluar DynamoDB, dan Anda sedang menyiapkan kapasitas membaca Anda 1150 00:50:00,160 --> 00:50:04,430 unit, jika Anda memilih akhirnya konsisten berbunyi, itu jauh lebih murah, 1151 00:50:04,430 --> 00:50:06,010 itu sekitar setengah biaya. 1152 00:50:06,010 --> 00:50:09,342 >> Dan sehingga menghemat uang Anda. 1153 00:50:09,342 --> 00:50:10,300 Tapi itu pilihan Anda. 1154 00:50:10,300 --> 00:50:12,925 Jika Anda ingin membaca konsisten atau dibaca akhirnya konsisten. 1155 00:50:12,925 --> 00:50:15,720 Itu sesuatu yang dapat Anda pilih. 1156 00:50:15,720 --> 00:50:17,659 >> Mari kita bicara tentang indeks. 1157 00:50:17,659 --> 00:50:19,450 Jadi kami menyebutkan bahwa atas tingkat agregasi. 1158 00:50:19,450 --> 00:50:23,720 Kami punya kunci hash, dan kita punya kunci jangkauan. 1159 00:50:23,720 --> 00:50:24,320 Itu bagus. 1160 00:50:24,320 --> 00:50:26,950 Dan itu di meja utama, saya punya satu kunci hash, aku punya satu kunci jangkauan. 1161 00:50:26,950 --> 00:50:27,783 >> Maksudnya itu apa? 1162 00:50:27,783 --> 00:50:30,410 Aku punya satu atribut yang saya dapat menjalankan query kaya terhadap. 1163 00:50:30,410 --> 00:50:31,800 Ini kunci jangkauan. 1164 00:50:31,800 --> 00:50:35,530 Atribut lain di item-- yang Aku bisa menyaring pada atribut-atribut. 1165 00:50:35,530 --> 00:50:40,050 Tapi aku tidak bisa melakukan hal-hal seperti itu, dimulai dengan, atau lebih besar dari. 1166 00:50:40,050 --> 00:50:40,820 >> Bagaimana aku melakukan itu? 1167 00:50:40,820 --> 00:50:42,860 Saya membuat indeks. 1168 00:50:42,860 --> 00:50:45,340 Ada dua jenis indeks dalam DynamoDB. 1169 00:50:45,340 --> 00:50:49,002 Indeks benar-benar pandangan lain dari meja. 1170 00:50:49,002 --> 00:50:50,490 Dan indeks sekunder lokal. 1171 00:50:50,490 --> 00:50:51,781 >> Yang pertama kami akan berbicara tentang. 1172 00:50:51,781 --> 00:50:57,740 Sekunder sehingga lokal hidup berdampingan pada partisi yang sama sebagai data. 1173 00:50:57,740 --> 00:51:00,240 Dan dengan demikian, mereka berada di node fisik yang sama. 1174 00:51:00,240 --> 00:51:01,780 Mereka adalah apa yang kita sebut konsisten. 1175 00:51:01,780 --> 00:51:04,599 Artinya, mereka akan mengakui write bersama dengan meja. 1176 00:51:04,599 --> 00:51:06,890 Ketika menulis masuk, kami akan menulis melalui indeks. 1177 00:51:06,890 --> 00:51:09,306 Kami akan menulis ke meja, dan kemudian kita akan mengakui. 1178 00:51:09,306 --> 00:51:10,490 Jadi itu konsisten. 1179 00:51:10,490 --> 00:51:13,174 Setelah menulis telah mengakui dari meja, 1180 00:51:13,174 --> 00:51:15,090 itu dijamin bahwa Indeks sekunder lokal 1181 00:51:15,090 --> 00:51:18,380 akan memiliki visi yang sama dari data. 1182 00:51:18,380 --> 00:51:22,390 Tapi apa yang mereka lakukan adalah memungkinkan Anda mendefinisikan kunci berbagai alternatif. 1183 00:51:22,390 --> 00:51:25,260 >> Harus menggunakan hash yang sama kunci sebagai tabel utama, 1184 00:51:25,260 --> 00:51:29,050 karena mereka co-terletak di partisi yang sama, dan mereka konsisten. 1185 00:51:29,050 --> 00:51:33,110 Tapi aku bisa membuat indeks dengan kunci kisaran yang berbeda. 1186 00:51:33,110 --> 00:51:41,590 Jadi misalnya, jika saya memiliki produsen yang memiliki meja bagian baku datang. 1187 00:51:41,590 --> 00:51:44,590 Dan bagian baku datang, dan mereka dikumpulkan oleh perakitan. 1188 00:51:44,590 --> 00:51:46,840 Dan mungkin ada recall. 1189 00:51:46,840 --> 00:51:50,240 >> Setiap bagian yang dibuat oleh ini produsen setelah tanggal ini, 1190 00:51:50,240 --> 00:51:52,840 Saya perlu untuk menarik dari garis saya. 1191 00:51:52,840 --> 00:51:55,950 Saya bisa berputar indeks yang akan mencari, 1192 00:51:55,950 --> 00:52:00,760 menggabungkan pada tanggal memproduksi dari bagian tertentu. 1193 00:52:00,760 --> 00:52:03,930 Jadi jika tabel tingkat atas saya adalah sudah hashed oleh produsen, 1194 00:52:03,930 --> 00:52:07,655 mungkin itu diatur di bagian ID, saya dapat membuat indeks dari meja yang 1195 00:52:07,655 --> 00:52:11,140 sebagai hash oleh produsen dan berkisar pada tanggal pembuatan. 1196 00:52:11,140 --> 00:52:14,490 Dan bahwa cara saya bisa mengatakan, apa pun yang diproduksi antara tanggal tersebut, 1197 00:52:14,490 --> 00:52:16,804 Saya perlu untuk menarik dari garis. 1198 00:52:16,804 --> 00:52:18,220 Jadi itu indeks sekunder lokal. 1199 00:52:18,220 --> 00:52:22,280 >> Ini memiliki efek membatasi ruang kunci hash Anda. 1200 00:52:22,280 --> 00:52:24,360 Karena mereka hidup berdampingan pada node penyimpanan yang sama, 1201 00:52:24,360 --> 00:52:26,860 mereka membatasi kunci hash ruang untuk 10 gigabyte. 1202 00:52:26,860 --> 00:52:28,950 DynamoDB, di bawah tabel, akan partisi 1203 00:52:28,950 --> 00:52:31,380 meja Anda setiap 10 gigabyte. 1204 00:52:31,380 --> 00:52:34,760 Ketika Anda menempatkan 10 gigs data dalam, kami pergi [PHH], dan kami menambahkan node lain. 1205 00:52:34,760 --> 00:52:38,120 1206 00:52:38,120 --> 00:52:42,070 >> Kami tidak akan membagi LSI di beberapa partisi. 1207 00:52:42,070 --> 00:52:43,200 Kami akan membagi meja. 1208 00:52:43,200 --> 00:52:44,679 Tapi kita tidak akan membagi LSI. 1209 00:52:44,679 --> 00:52:46,470 Jadi itu sesuatu penting untuk memahami 1210 00:52:46,470 --> 00:52:50,070 adalah jika Anda melakukannya dengan sangat, sangat, agregasi sangat besar, 1211 00:52:50,070 --> 00:52:53,860 maka Anda akan dibatasi 10 gigabyte pada LSIs Anda. 1212 00:52:53,860 --> 00:52:56,640 >> Jika itu yang terjadi, kita bisa menggunakan sekunder global. 1213 00:52:56,640 --> 00:52:58,630 Sekunder global benar-benar meja lain. 1214 00:52:58,630 --> 00:53:01,720 Mereka ada benar-benar off untuk sisi meja utama Anda. 1215 00:53:01,720 --> 00:53:04,680 Dan mereka memungkinkan saya untuk menemukan struktur yang sama sekali berbeda. 1216 00:53:04,680 --> 00:53:08,010 Jadi menganggapnya sebagai data yang dimasukkan menjadi dua tabel yang berbeda, terstruktur 1217 00:53:08,010 --> 00:53:09,220 dalam dua cara yang berbeda. 1218 00:53:09,220 --> 00:53:11,360 >> Saya dapat menentukan benar-benar kunci hash yang berbeda. 1219 00:53:11,360 --> 00:53:13,490 Saya dapat menentukan benar-benar kunci rentang yang berbeda. 1220 00:53:13,490 --> 00:53:15,941 Dan saya bisa menjalankan ini benar-benar independen. 1221 00:53:15,941 --> 00:53:18,190 Sebagai soal fakta, aku sudah ditetapkan kapasitas membaca saya 1222 00:53:18,190 --> 00:53:21,090 dan menulis kapasitas saya indeks sekunder global yang 1223 00:53:21,090 --> 00:53:24,240 benar-benar independen tabel utama saya. 1224 00:53:24,240 --> 00:53:26,640 Jika saya mendefinisikan indeks itu, saya memberitahu itu berapa banyak membaca dan menulis 1225 00:53:26,640 --> 00:53:28,610 Kapasitas itu akan menggunakan. 1226 00:53:28,610 --> 00:53:31,490 >> Dan yang terpisah dari meja utama saya. 1227 00:53:31,490 --> 00:53:35,240 Sekarang kedua indeks memungkinkan kita untuk tidak hanya mendefinisikan hash dan berbagai kunci, 1228 00:53:35,240 --> 00:53:38,610 tapi mereka memungkinkan kita untuk memproyeksikan nilai-nilai tambahan. 1229 00:53:38,610 --> 00:53:44,950 Jadi jika saya ingin membacakan indeks, dan saya ingin mendapatkan beberapa set data, 1230 00:53:44,950 --> 00:53:48,327 Saya tidak perlu kembali ke utama meja untuk mendapatkan atribut tambahan. 1231 00:53:48,327 --> 00:53:50,660 Saya dapat proyek mereka tambahan atribut ke dalam tabel 1232 00:53:50,660 --> 00:53:53,440 untuk mendukung pola akses. 1233 00:53:53,440 --> 00:53:57,700 Aku tahu kita mungkin masuk ke beberapa benar-benar, really-- masuk ke gulma 1234 00:53:57,700 --> 00:53:58,910 di sini pada beberapa hal ini. 1235 00:53:58,910 --> 00:54:02,725 Sekarang aku melayang keluar dari ini. 1236 00:54:02,725 --> 00:54:07,320 >> AUDIENCE: [tidak terdengar] kunci --table berarti adalah hash? 1237 00:54:07,320 --> 00:54:08,840 Hash asli? 1238 00:54:08,840 --> 00:54:09,340 Multi-bilah? 1239 00:54:09,340 --> 00:54:10,200 >> RICK Houlihan: Ya. 1240 00:54:10,200 --> 00:54:11,070 Iya nih. 1241 00:54:11,070 --> 00:54:15,260 Kunci tabel pada dasarnya menunjuk kembali ke item. 1242 00:54:15,260 --> 00:54:19,280 Jadi indeks adalah pointer kembali ke item asli di atas meja. 1243 00:54:19,280 --> 00:54:22,910 Sekarang Anda dapat memilih untuk membangun Indeks yang hanya memiliki kunci meja, 1244 00:54:22,910 --> 00:54:24,840 dan tidak ada sifat lainnya. 1245 00:54:24,840 --> 00:54:26,570 Dan mengapa mungkin saya melakukan itu? 1246 00:54:26,570 --> 00:54:28,570 Yah, mungkin aku memiliki barang-barang yang sangat besar. 1247 00:54:28,570 --> 00:54:31,660 >> Aku benar-benar hanya perlu tahu which-- pola akses saya mungkin mengatakan, 1248 00:54:31,660 --> 00:54:33,760 item yang mengandung properti ini? 1249 00:54:33,760 --> 00:54:35,780 Tidak perlu untuk kembali item. 1250 00:54:35,780 --> 00:54:37,800 Aku hanya perlu tahu yang item berisi itu. 1251 00:54:37,800 --> 00:54:40,700 Sehingga Anda dapat membangun indeks yang hanya memiliki kunci meja. 1252 00:54:40,700 --> 00:54:43,360 >> Tapi itu terutama apa indeks dalam database untuk. 1253 00:54:43,360 --> 00:54:46,280 Ini untuk mampu dengan cepat mengidentifikasi yang mencatat, 1254 00:54:46,280 --> 00:54:49,470 yang baris, yang item dalam tabel memiliki 1255 00:54:49,470 --> 00:54:51,080 sifat-sifat yang saya cari. 1256 00:54:51,080 --> 00:54:53,610 1257 00:54:53,610 --> 00:54:54,860 >> GSIS, jadi bagaimana mereka bekerja? 1258 00:54:54,860 --> 00:54:58,340 GSIS pada dasarnya adalah asynchronous. 1259 00:54:58,340 --> 00:55:02,570 Pembaruan datang ke meja, tabel ini kemudian diperbarui asynchronously 1260 00:55:02,570 --> 00:55:03,720 semua GSIS Anda. 1261 00:55:03,720 --> 00:55:06,680 Inilah sebabnya mengapa GSIS adalah akhirnya konsisten. 1262 00:55:06,680 --> 00:55:09,440 >> Hal ini penting untuk dicatat bahwa ketika Anda sedang membangun GSIS, 1263 00:55:09,440 --> 00:55:13,110 dan Anda memahami Anda sedang menciptakan dimensi lain dari aggregation-- 1264 00:55:13,110 --> 00:55:16,594 sekarang katakanlah contoh yang baik di sini adalah produsen. 1265 00:55:16,594 --> 00:55:19,260 Saya pikir saya mungkin telah berbicara tentang produsen perangkat medis. 1266 00:55:19,260 --> 00:55:23,870 Produsen perangkat medis seringkali memiliki bagian serial. 1267 00:55:23,870 --> 00:55:28,070 Bagian-bagian yang masuk ke penggantian pinggul semua 1268 00:55:28,070 --> 00:55:30,200 memiliki nomor seri kecil pada mereka. 1269 00:55:30,200 --> 00:55:33,584 Dan mereka bisa memiliki jutaan dan jutaan dan miliaran bagian 1270 00:55:33,584 --> 00:55:35,000 di semua perangkat yang mereka kapal. 1271 00:55:35,000 --> 00:55:37,440 Nah, mereka perlu agregat di bawah dimensi yang berbeda, semua bagian 1272 00:55:37,440 --> 00:55:39,520 dalam perakitan, semua bagian yang dibuat 1273 00:55:39,520 --> 00:55:41,670 pada baris tertentu, semua bagian-bagian yang datang 1274 00:55:41,670 --> 00:55:44,620 di dari produsen tertentu pada tanggal tertentu. 1275 00:55:44,620 --> 00:55:47,940 Dan agregasi ini kadang-kadang bangun ke miliaran. 1276 00:55:47,940 --> 00:55:50,550 >> Jadi saya bekerja dengan beberapa orang-orang yang menderita 1277 00:55:50,550 --> 00:55:53,156 karena mereka menciptakan ini agregasi ginormous 1278 00:55:53,156 --> 00:55:54,280 di indeks sekunder mereka. 1279 00:55:54,280 --> 00:55:57,070 Mereka mungkin memiliki bagian baku tabel yang datang sebagai hash saja. 1280 00:55:57,070 --> 00:55:59,090 Setiap bagian memiliki nomor seri yang unik. 1281 00:55:59,090 --> 00:56:00,975 Saya menggunakan nomor seri sebagai hash. 1282 00:56:00,975 --> 00:56:01,600 Cantiknya. 1283 00:56:01,600 --> 00:56:04,160 Tabel data mentah saya tersebar seluruh ruang kunci. 1284 00:56:04,160 --> 00:56:05,930 Saya [? menulis ?] [? konsumsi?] mengagumkan. 1285 00:56:05,930 --> 00:56:07,876 Saya mengambil banyak data. 1286 00:56:07,876 --> 00:56:09,500 Lalu apa yang mereka lakukan adalah mereka membuat GSI. 1287 00:56:09,500 --> 00:56:12,666 Dan saya katakan, Anda tahu apa, saya harus melihat semua bagian untuk produsen ini. 1288 00:56:12,666 --> 00:56:15,060 Nah, tiba-tiba aku mengambil miliar baris, 1289 00:56:15,060 --> 00:56:17,550 dan barang-barang mereka ke satu node, karena ketika 1290 00:56:17,550 --> 00:56:21,170 Saya agregat sebagai produsen ID sebagai hash, 1291 00:56:21,170 --> 00:56:25,410 dan nomor bagian sebagai jangkauan, maka semua tiba-tiba aku 1292 00:56:25,410 --> 00:56:30,530 menempatkan miliar bagian dalam apa produsen ini telah melepaskan aku. 1293 00:56:30,530 --> 00:56:34,447 >> Yang dapat menyebabkan banyak tekanan pada GSI, 1294 00:56:34,447 --> 00:56:36,030 lagi, karena aku memalu satu node. 1295 00:56:36,030 --> 00:56:38,350 Saya menempatkan semua ini memasukkan ke dalam satu simpul. 1296 00:56:38,350 --> 00:56:40,940 Dan itu kasus penggunaan bermasalah nyata. 1297 00:56:40,940 --> 00:56:43,479 Sekarang, saya punya desain yang baik pola untuk bagaimana Anda menghindari itu. 1298 00:56:43,479 --> 00:56:45,770 Dan itulah salah satu masalah bahwa saya selalu bekerja dengan. 1299 00:56:45,770 --> 00:56:49,590 Tapi apa yang terjadi, adalah mungkin GSI tidak memiliki kapasitas yang cukup menulis 1300 00:56:49,590 --> 00:56:52,330 untuk dapat mendorong semua orang baris ke node tunggal. 1301 00:56:52,330 --> 00:56:55,390 Dan apa yang terjadi kemudian adalah primer, meja klien, 1302 00:56:55,390 --> 00:57:00,180 tabel utama akan mencekik karena GSI tidak bisa mengikuti. 1303 00:57:00,180 --> 00:57:02,980 Jadi tingkat insert saya akan jatuh pada tabel utama 1304 00:57:02,980 --> 00:57:06,230 sebagai GSI saya mencoba untuk mengikutinya. 1305 00:57:06,230 --> 00:57:08,850 >> Baiklah, jadi GSI, LSI, mana yang harus saya gunakan? 1306 00:57:08,850 --> 00:57:12,290 LSI konsisten. 1307 00:57:12,290 --> 00:57:13,750 GSI yang akhirnya konsisten. 1308 00:57:13,750 --> 00:57:17,490 Jika itu OK, saya sarankan menggunakan GSI, mereka jauh lebih fleksibel. 1309 00:57:17,490 --> 00:57:20,270 LSI dapat dimodelkan sebagai GSI. 1310 00:57:20,270 --> 00:57:27,040 Dan jika ukuran data per kunci hash di koleksi Anda melebihi 10 gigabyte, 1311 00:57:27,040 --> 00:57:31,050 maka Anda akan ingin menggunakan GSI karena itu hanya batas keras. 1312 00:57:31,050 --> 00:57:32,035 >> Baiklah, jadi scaling. 1313 00:57:32,035 --> 00:57:35,210 1314 00:57:35,210 --> 00:57:37,460 Throughput dalam Dynamo DB, Anda Ketentuan kaleng [tidak terdengar] 1315 00:57:37,460 --> 00:57:38,680 troughput ke meja. 1316 00:57:38,680 --> 00:57:42,740 Kami memiliki pelanggan yang memiliki ditetapkan 60 billion-- 1317 00:57:42,740 --> 00:57:45,970 melakukan 60 miliar permintaan, secara teratur berjalan pada lebih dari satu juta permintaan 1318 00:57:45,970 --> 00:57:47,790 per detik di meja kami. 1319 00:57:47,790 --> 00:57:50,360 Ada benar-benar ada batas teoritis untuk berapa banyak 1320 00:57:50,360 --> 00:57:53,730 dan seberapa cepat meja dapat berjalan di Dynamo DB. 1321 00:57:53,730 --> 00:57:55,920 Ada beberapa lembut batas akun Anda 1322 00:57:55,920 --> 00:57:58,170 yang kita tempatkan di sana sehingga bahwa Anda tidak gila. 1323 00:57:58,170 --> 00:58:00,070 Jika Anda ingin lebih dari itu, tidak masalah. 1324 00:58:00,070 --> 00:58:00,820 Anda datang memberitahu kami. 1325 00:58:00,820 --> 00:58:02,810 Kami akan muncul dial. 1326 00:58:02,810 --> 00:58:08,210 >> Setiap akun terbatas pada beberapa tingkat di setiap layanan, hanya dari kelelawar 1327 00:58:08,210 --> 00:58:11,920 sehingga orang-orang tidak gila mendapatkan diri mereka ke dalam kesulitan. 1328 00:58:11,920 --> 00:58:12,840 Tidak ada batas dalam ukuran. 1329 00:58:12,840 --> 00:58:14,940 Anda dapat menempatkan sejumlah item di atas meja. 1330 00:58:14,940 --> 00:58:17,620 Ukuran item adalah terbatas pada setiap 400 kilobyte, 1331 00:58:17,620 --> 00:58:20,050 yang akan barang tidak atribut. 1332 00:58:20,050 --> 00:58:24,200 Jadi jumlah semua atribut terbatas pada 400 kilobyte. 1333 00:58:24,200 --> 00:58:27,300 Dan sekali lagi, kita memiliki yang sedikit masalah LSI 1334 00:58:27,300 --> 00:58:30,405 dengan batas 10 gigabyte per hash. 1335 00:58:30,405 --> 00:58:33,280 AUDIENCE: jumlah kecil, aku kehilangan apa yang kau bilang, bahwa is-- 1336 00:58:33,280 --> 00:58:36,830 AUDIENCE: Oh, 400 kilobyte adalah ukuran maksimum per item. 1337 00:58:36,830 --> 00:58:39,570 Jadi item memiliki semua atribut. 1338 00:58:39,570 --> 00:58:43,950 Jadi 400 k adalah ukuran jumlah item itu, 400 kilobyte. 1339 00:58:43,950 --> 00:58:46,170 Jadi dari semua atribut dikombinasikan, semua data 1340 00:58:46,170 --> 00:58:49,140 itu di semua atribut tersebut, digulung menjadi ukuran total, 1341 00:58:49,140 --> 00:58:51,140 Saat hari batas item 400 k. 1342 00:58:51,140 --> 00:58:54,390 1343 00:58:54,390 --> 00:58:57,046 Jadi skala lagi, mencapai melalui partisi. 1344 00:58:57,046 --> 00:58:58,920 Throughput ditetapkan di tingkat meja. 1345 00:58:58,920 --> 00:59:00,160 Dan ada benar-benar dua tombol. 1346 00:59:00,160 --> 00:59:02,400 Kami telah membaca kapasitas dan menulis kapasitas. 1347 00:59:02,400 --> 00:59:05,530 >> Jadi ini disesuaikan independen satu sama lain. 1348 00:59:05,530 --> 00:59:08,640 Ukuran RCU ini ketat konsisten membaca. 1349 00:59:08,640 --> 00:59:13,005 OK, jadi jika Anda mengatakan saya ingin 1000 RCU ini mereka secara ketat konsisten, 1350 00:59:13,005 --> 00:59:14,130 mereka konsisten membaca. 1351 00:59:14,130 --> 00:59:17,130 Jika Anda mengatakan saya ingin akhirnya konsisten berbunyi, 1352 00:59:17,130 --> 00:59:19,402 Anda bisa penyediaan 1.000 RCU, Anda akan 1353 00:59:19,402 --> 00:59:21,840 untuk mendapatkan 2000 akhirnya konsisten membaca. 1354 00:59:21,840 --> 00:59:25,940 Dan setengah harga bagi mereka akhirnya terdiri dalam membaca. 1355 00:59:25,940 --> 00:59:28,520 >> Sekali lagi, disesuaikan independen satu sama lain. 1356 00:59:28,520 --> 00:59:32,900 Dan mereka memiliki throughput-- yang Jika Anda mengkonsumsi 100% dari RCU Anda, 1357 00:59:32,900 --> 00:59:35,960 Anda tidak akan berdampak pada ketersediaan hak-hak Anda. 1358 00:59:35,960 --> 00:59:40,161 Jadi mereka benar-benar independen satu sama lain. 1359 00:59:40,161 --> 00:59:43,160 Baiklah, jadi salah satu hal yang Saya sebutkan secara singkat itu throttling. 1360 00:59:43,160 --> 00:59:44,320 Throttling buruk. 1361 00:59:44,320 --> 00:59:47,311 Throttling menunjukkan buruk ada SQL. 1362 00:59:47,311 --> 00:59:50,310 Ada hal-hal yang dapat kita lakukan untuk membantu Anda meringankan throttling yang Anda 1363 00:59:50,310 --> 00:59:51,040 mengalami. 1364 00:59:51,040 --> 00:59:53,240 Tapi solusi terbaik untuk ini mari kita 1365 00:59:53,240 --> 00:59:58,000 a melihat apa yang Anda lakukan, karena ada anti-pola dalam bermain di sini. 1366 00:59:58,000 --> 01:00:02,140 >> Hal-hal ini, hal-hal seperti non-seragam beban kerja, hot keys, partisi panas. 1367 01:00:02,140 --> 01:00:06,210 Aku memukul ruang kunci tertentu sangat sulit untuk beberapa alasan tertentu. 1368 01:00:06,210 --> 01:00:07,080 Mengapa saya melakukan ini? 1369 01:00:07,080 --> 01:00:08,710 Mari kita mencari tahu. 1370 01:00:08,710 --> 01:00:10,427 Aku mencampur Data panas saya dengan data dingin. 1371 01:00:10,427 --> 01:00:12,510 Aku membiarkan meja saya mendapatkan besar, tapi benar-benar 1372 01:00:12,510 --> 01:00:15,970 hanya beberapa subset dari data yang benar-benar menarik bagi saya. 1373 01:00:15,970 --> 01:00:20,290 Jadi untuk data log, misalnya, banyak pelanggan, mereka mendapatkan data log setiap hari. 1374 01:00:20,290 --> 01:00:22,490 Mereka mendapat sejumlah besar data log. 1375 01:00:22,490 --> 01:00:25,940 >> Jika Anda hanya membuang semua log yang data ke dalam satu meja besar, dari waktu ke waktu 1376 01:00:25,940 --> 01:00:28,070 tabel yang akan mendapatkan besar. 1377 01:00:28,070 --> 01:00:30,950 Tapi aku benar-benar hanya tertarik 24 jam terakhir, tujuh hari terakhir, 1378 01:00:30,950 --> 01:00:31,659 30 hari terakhir. 1379 01:00:31,659 --> 01:00:34,074 Apapun jendela waktu bahwa aku tertarik melihat 1380 01:00:34,074 --> 01:00:37,010 untuk acara yang mengganggu saya, atau acara yang menarik untuk saya, 1381 01:00:37,010 --> 01:00:39,540 itulah satu-satunya jendela waktu yang saya butuhkan. 1382 01:00:39,540 --> 01:00:42,470 Jadi, mengapa saya menempatkan 10 tahun senilai data log di meja? 1383 01:00:42,470 --> 01:00:45,030 Apa yang menyebabkan adalah tabel fragmen. 1384 01:00:45,030 --> 01:00:45,880 >> Ia mendapat besar. 1385 01:00:45,880 --> 01:00:48,340 Itu mulai menyebar di ribuan node. 1386 01:00:48,340 --> 01:00:51,380 Dan karena kapasitas Anda sangat rendah, Anda 1387 01:00:51,380 --> 01:00:54,090 sebenarnya menilai membatasi pada setiap salah satu node individu. 1388 01:00:54,090 --> 01:00:57,120 Jadi mari kita mulai melihat bagaimana kita berguling meja yang lebih. 1389 01:00:57,120 --> 01:01:01,502 Bagaimana kita mengelola data yang sedikit lebih baik untuk menghindari masalah ini. 1390 01:01:01,502 --> 01:01:02,710 Dan apa yang terlihat seperti? 1391 01:01:02,710 --> 01:01:04,370 Ini adalah apa yang tampak seperti. 1392 01:01:04,370 --> 01:01:06,790 Ini adalah apa yang buruk NoSQL seperti. 1393 01:01:06,790 --> 01:01:07,830 >> Aku punya kunci panas di sini. 1394 01:01:07,830 --> 01:01:10,246 Jika Anda melihat di sisi sini, ini semua partisi saya. 1395 01:01:10,246 --> 01:01:12,630 Saya punya 16 partisi di sini pada database tertentu. 1396 01:01:12,630 --> 01:01:13,630 Kami melakukan hal ini sepanjang waktu. 1397 01:01:13,630 --> 01:01:15,046 Saya menjalankan ini untuk pelanggan sepanjang waktu. 1398 01:01:15,046 --> 01:01:16,550 Ini disebut peta panas. 1399 01:01:16,550 --> 01:01:20,590 Peta panas memberitahu saya bagaimana Anda mengakses ruang kunci Anda. 1400 01:01:20,590 --> 01:01:23,700 Dan apa ini mengatakan kepada saya adalah bahwa ada satu hash tertentu 1401 01:01:23,700 --> 01:01:26,330 bahwa orang ini menyukai suatu mengerikan banyak, karena dia 1402 01:01:26,330 --> 01:01:28,250 memukul itu benar-benar, benar-benar keras. 1403 01:01:28,250 --> 01:01:29,260 >> Jadi biru bagus. 1404 01:01:29,260 --> 01:01:29,900 Kami seperti biru. 1405 01:01:29,900 --> 01:01:30,720 Kami tidak suka merah. 1406 01:01:30,720 --> 01:01:33,120 Red mana tekanan mendapat hingga 100%. 1407 01:01:33,120 --> 01:01:35,560 100%, sekarang kau akan mencekik. 1408 01:01:35,560 --> 01:01:39,030 Jadi, setiap kali Anda melihat garis merah seperti this-- dan itu bukan hanya Dynamo DB-- 1409 01:01:39,030 --> 01:01:41,630 setiap database yang NoSQL memiliki masalah ini. 1410 01:01:41,630 --> 01:01:44,640 Ada anti-pola yang dapat mendorong jenis kondisi. 1411 01:01:44,640 --> 01:01:49,070 Apa yang saya lakukan adalah saya bekerja dengan pelanggan untuk meringankan kondisi ini. 1412 01:01:49,070 --> 01:01:51,840 >> Dan apa yang terlihat seperti? 1413 01:01:51,840 --> 01:01:54,260 Dan ini adalah mendapatkan paling dari Dynamo DB throughput, 1414 01:01:54,260 --> 01:01:56,176 tapi itu benar-benar mendapatkan hasil maksimal dari NoSQL. 1415 01:01:56,176 --> 01:01:58,740 Hal ini tidak terbatas pada Dynamo. 1416 01:01:58,740 --> 01:02:02,050 Ini adalah definitely-- Saya digunakan untuk bekerja di Mongo. 1417 01:02:02,050 --> 01:02:04,090 Aku akrab dengan banyak platform NoSQL. 1418 01:02:04,090 --> 01:02:06,830 Setiap orang memiliki jenis masalah hot key. 1419 01:02:06,830 --> 01:02:10,320 Untuk mendapatkan hasil maksimal dari setiap NoSQL Database, khususnya Dynamo DB, 1420 01:02:10,320 --> 01:02:13,320 Anda ingin membuat tabel di mana elemen kunci hash memiliki 1421 01:02:13,320 --> 01:02:18,590 sejumlah besar nilai-nilai yang berbeda, tingkat tinggi kardinalitas. 1422 01:02:18,590 --> 01:02:22,530 Karena itu berarti aku menulis untuk banyak ember yang berbeda. 1423 01:02:22,530 --> 01:02:24,870 >> Semakin ember Saya menulis untuk, semakin besar kemungkinan 1424 01:02:24,870 --> 01:02:29,100 Saya menyebar bahwa menulis beban atau baca memuat keluar di beberapa node, 1425 01:02:29,100 --> 01:02:33,560 semakin besar kemungkinan saya untuk memiliki throughput yang tinggi di atas meja. 1426 01:02:33,560 --> 01:02:37,440 Dan kemudian saya ingin nilai-nilai menjadi diminta cukup merata dari waktu ke waktu 1427 01:02:37,440 --> 01:02:39,430 dan seragam sebagai acak mungkin. 1428 01:02:39,430 --> 01:02:42,410 Nah, itu semacam menarik, karena saya tidak bisa benar-benar 1429 01:02:42,410 --> 01:02:43,960 kontrol ketika pengguna datang. 1430 01:02:43,960 --> 01:02:47,645 Jadi cukup untuk mengatakan, jika kita menyebar hal-hal di ruang utama, 1431 01:02:47,645 --> 01:02:49,270 kita mungkin akan dalam kondisi yang lebih baik. 1432 01:02:49,270 --> 01:02:51,522 >> Ada tertentu jumlah waktu pengiriman 1433 01:02:51,522 --> 01:02:53,230 bahwa Anda tidak akan untuk dapat kontrol. 1434 01:02:53,230 --> 01:02:55,438 Tapi mereka benar-benar dua dimensi yang kita miliki, 1435 01:02:55,438 --> 01:02:58,800 ruang, akses merata penyebaran, waktu, permintaan 1436 01:02:58,800 --> 01:03:01,040 Sesampainya merata spasi dalam waktu. 1437 01:03:01,040 --> 01:03:03,110 Dan jika kedua kondisi terpenuhi, 1438 01:03:03,110 --> 01:03:05,610 maka itulah yang itu akan terlihat seperti. 1439 01:03:05,610 --> 01:03:07,890 Ini jauh lebih baik. 1440 01:03:07,890 --> 01:03:08,890 Kami benar-benar senang di sini. 1441 01:03:08,890 --> 01:03:10,432 Kami punya pola akses yang sangat bahkan. 1442 01:03:10,432 --> 01:03:13,098 Ya, mungkin Anda mendapatkan sedikit tekanan setiap sekarang dan kemudian, 1443 01:03:13,098 --> 01:03:14,830 tapi tidak ada yang benar-benar terlalu luas. 1444 01:03:14,830 --> 01:03:17,660 Jadi itu menakjubkan berapa kali, ketika saya bekerja dengan pelanggan, 1445 01:03:17,660 --> 01:03:20,670 bahwa grafik pertama dengan merah besar bar dan semua yang jelek kuning itu 1446 01:03:20,670 --> 01:03:23,147 seluruh tempat, kami bisa dilakukan dengan latihan 1447 01:03:23,147 --> 01:03:24,980 setelah beberapa bulan re-arsitektur, 1448 01:03:24,980 --> 01:03:28,050 mereka menjalankan persis sama beban kerja pada beban yang sama persis. 1449 01:03:28,050 --> 01:03:30,140 Dan ini adalah apa itu tampak seperti sekarang. 1450 01:03:30,140 --> 01:03:36,600 Jadi apa yang Anda dapatkan dengan NoSQL adalah Data skema yang benar-benar 1451 01:03:36,600 --> 01:03:38,510 terikat pada pola akses. 1452 01:03:38,510 --> 01:03:42,170 >> Dan Anda dapat mengoptimalkan bahwa skema data untuk mendukung pola akses. 1453 01:03:42,170 --> 01:03:45,490 Jika Anda tidak, maka Anda akan untuk melihat jenis-jenis masalah 1454 01:03:45,490 --> 01:03:46,710 dengan orang-orang kunci panas. 1455 01:03:46,710 --> 01:03:50,518 >> AUDIENCE: Nah, pasti beberapa tempat akan menjadi lebih panas daripada yang lain. 1456 01:03:50,518 --> 01:03:51,450 >> RICK Houlihan: Selalu. 1457 01:03:51,450 --> 01:03:51,960 Selalu. 1458 01:03:51,960 --> 01:03:54,620 Ya, maksud saya selalu ada a-- dan lagi, ada 1459 01:03:54,620 --> 01:03:56,980 beberapa pola desain kita akan melewati yang akan berbicara tentang bagaimana Anda menangani 1460 01:03:56,980 --> 01:03:58,480 dengan ini agregasi super besar. 1461 01:03:58,480 --> 01:04:01,260 Maksudku, aku harus memiliki mereka, bagaimana kita berurusan dengan mereka? 1462 01:04:01,260 --> 01:04:03,760 Saya punya kasus penggunaan yang cukup baik bahwa kita akan berbicara tentang untuk itu. 1463 01:04:03,760 --> 01:04:05,940 >> Baiklah, mari kita bicara sehingga tentang beberapa pelanggan sekarang. 1464 01:04:05,940 --> 01:04:06,950 Orang-orang ini AdRoll. 1465 01:04:06,950 --> 01:04:08,990 Saya tidak tahu apakah Anda akrab dengan AdRoll. 1466 01:04:08,990 --> 01:04:10,781 Anda mungkin melihat mereka banyak pada browser. 1467 01:04:10,781 --> 01:04:14,230 Mereka ad re-targeting, mereka terbesar bisnis menargetkan ulang iklan 1468 01:04:14,230 --> 01:04:14,940 di luar sana. 1469 01:04:14,940 --> 01:04:17,792 Mereka biasanya secara teratur menjalankan lebih 60 miliar transaksi per hari. 1470 01:04:17,792 --> 01:04:20,000 Mereka melakukan lebih dari satu juta transaksi per detik. 1471 01:04:20,000 --> 01:04:22,660 Mereka punya meja cukup sederhana struktur, meja tersibuk. 1472 01:04:22,660 --> 01:04:26,450 Itu pada dasarnya hanya kunci hash adalah cookie, 1473 01:04:26,450 --> 01:04:29,010 rentang adalah demografi kategori, dan kemudian 1474 01:04:29,010 --> 01:04:31,220 atribut ketiga adalah skor. 1475 01:04:31,220 --> 01:04:33,720 >> Jadi kita semua memiliki cookie di browser kita dari orang-orang. 1476 01:04:33,720 --> 01:04:35,900 Dan ketika Anda pergi ke berpartisipasi pedagang, 1477 01:04:35,900 --> 01:04:39,390 mereka pada dasarnya skor Anda di berbagai kategori demografis. 1478 01:04:39,390 --> 01:04:42,070 Ketika Anda pergi ke sebuah situs web dan Anda mengatakan saya ingin melihat ad-- ini 1479 01:04:42,070 --> 01:04:44,920 atau pada dasarnya Anda tidak mengatakan itu-- tetapi ketika Anda pergi ke situs web 1480 01:04:44,920 --> 01:04:47,550 mereka mengatakan Anda ingin melihat iklan ini. 1481 01:04:47,550 --> 01:04:49,370 Dan mereka pergi mendapatkan iklan dari AdRoll. 1482 01:04:49,370 --> 01:04:51,130 AdRoll terlihat Anda di atas meja mereka. 1483 01:04:51,130 --> 01:04:52,115 Mereka menemukan cookie Anda. 1484 01:04:52,115 --> 01:04:53,990 Pengiklan mengatakan mereka, saya ingin seseorang 1485 01:04:53,990 --> 01:04:58,632 siapa yang setengah baya, Pria 40 tahun, menjadi olahraga. 1486 01:04:58,632 --> 01:05:01,590 Dan mereka mencetak Anda pada mereka demografi dan mereka memutuskan apakah atau tidak 1487 01:05:01,590 --> 01:05:02,740 itu iklan yang baik untuk Anda. 1488 01:05:02,740 --> 01:05:10,330 >> Sekarang mereka memiliki SLA dengan penyedia iklan mereka 1489 01:05:10,330 --> 01:05:14,510 untuk memberikan sub-10 milidetik respon pada setiap permintaan tunggal. 1490 01:05:14,510 --> 01:05:16,090 Jadi mereka menggunakan Dynamo DB untuk ini. 1491 01:05:16,090 --> 01:05:18,131 Mereka memukul kami juta permintaan per detik. 1492 01:05:18,131 --> 01:05:21,120 Mereka mampu melakukan semua mereka lookup, triase semua data itu, 1493 01:05:21,120 --> 01:05:26,130 dan mendapatkan bahwa add link kembali ke yang pengiklan di bawah 10 milidetik. 1494 01:05:26,130 --> 01:05:29,800 Ini benar-benar cukup fenomenal implementasi yang mereka miliki. 1495 01:05:29,800 --> 01:05:36,210 >> Orang-orang ini actually-- apakah ini orang-orang. 1496 01:05:36,210 --> 01:05:38,010 Saya tidak yakin apakah itu orang-orang ini. 1497 01:05:38,010 --> 01:05:40,127 Mungkin orang-orang ini. 1498 01:05:40,127 --> 01:05:42,210 Pada dasarnya mengatakan us-- tidak, aku tidak berpikir itu mereka. 1499 01:05:42,210 --> 01:05:43,000 Saya pikir itu orang lain. 1500 01:05:43,000 --> 01:05:44,750 Saya bekerja dengan pelanggan yang mengatakan kepada saya 1501 01:05:44,750 --> 01:05:47,040 bahwa sekarang mereka sudah pergi ke Dynamo DB, mereka 1502 01:05:47,040 --> 01:05:50,330 menghabiskan lebih banyak uang pada makanan ringan untuk tim pengembangan mereka setiap bulan 1503 01:05:50,330 --> 01:05:52,886 dari yang mereka keluarkan untuk database mereka. 1504 01:05:52,886 --> 01:05:54,760 Sehingga akan memberi Anda ide penghematan biaya 1505 01:05:54,760 --> 01:05:57,889 bahwa Anda bisa mendapatkan di Dynamo DB sangat besar. 1506 01:05:57,889 --> 01:05:59,430 Baiklah, dropcam ini perusahaan lain. 1507 01:05:59,430 --> 01:06:02,138 Orang ini semacam of-- jika Anda berpikir dari internet hal, dropcam 1508 01:06:02,138 --> 01:06:05,150 pada dasarnya adalah keamanan video internet. 1509 01:06:05,150 --> 01:06:06,660 Anda menempatkan kamera Anda di luar sana. 1510 01:06:06,660 --> 01:06:08,180 Kamera memiliki detektor gerak. 1511 01:06:08,180 --> 01:06:10,290 Seseorang datang, memicu titik isyarat. 1512 01:06:10,290 --> 01:06:13,540 Kamera mulai merekam untuk sementara sampai itu tidak mendeteksi gerakan apapun lagi. 1513 01:06:13,540 --> 01:06:15,310 Menempatkan video yang di internet. 1514 01:06:15,310 --> 01:06:19,800 >> Dropcam adalah sebuah perusahaan yang pada dasarnya beralih ke Dynamo DB 1515 01:06:19,800 --> 01:06:22,200 karena mereka mengalami sakit tumbuh besar. 1516 01:06:22,200 --> 01:06:25,820 Dan apa yang mereka mengatakan kepada kami, tiba-tiba petabyte data. 1517 01:06:25,820 --> 01:06:28,070 Mereka tidak tahu layanan mereka akan begitu sukses. 1518 01:06:28,070 --> 01:06:32,310 Lebih video masuk dari YouTube adalah apa yang orang-orang ini mendapatkan. 1519 01:06:32,310 --> 01:06:36,780 Mereka menggunakan DynamoDB untuk melacak semua metadata pada semua poin kunci video mereka. 1520 01:06:36,780 --> 01:06:40,282 >> Sehingga mereka memiliki S3 ember mereka mendorong semua artefak biner ke dalam. 1521 01:06:40,282 --> 01:06:41,990 Dan kemudian mereka memiliki Catatan Dynamo DB yang 1522 01:06:41,990 --> 01:06:44,070 menunjuk orang untuk orang-orang S3 tiga objek. 1523 01:06:44,070 --> 01:06:47,070 Ketika mereka perlu melihat video, mereka mencari catatan di Dynamo DB. 1524 01:06:47,070 --> 01:06:47,903 Mereka klik link. 1525 01:06:47,903 --> 01:06:49,770 Mereka meruntuhkan video dari S3. 1526 01:06:49,770 --> 01:06:51,590 Jadi itu semacam apa ini terlihat seperti. 1527 01:06:51,590 --> 01:06:53,580 Dan ini adalah langsung dari tim mereka. 1528 01:06:53,580 --> 01:06:56,010 >> Dynamo DB mengurangi mereka waktu pengiriman untuk acara video 1529 01:06:56,010 --> 01:06:57,590 dari lima sampai 10 detik. 1530 01:06:57,590 --> 01:07:00,470 Di toko relasional lama mereka, mereka digunakan untuk memiliki pergi dan mengeksekusi 1531 01:07:00,470 --> 01:07:03,780 beberapa pertanyaan kompleks untuk angka mana video ke pull down, 1532 01:07:03,780 --> 01:07:06,690 menjadi kurang dari 50 milidetik. 1533 01:07:06,690 --> 01:07:08,990 Jadi itu menakjubkan, menakjubkan berapa banyak kinerja 1534 01:07:08,990 --> 01:07:12,990 Anda bisa dapatkan ketika Anda mengoptimalkan dan Anda menyetel database yang mendasari 1535 01:07:12,990 --> 01:07:15,110 untuk mendukung pola akses. 1536 01:07:15,110 --> 01:07:20,500 Halfbrick, orang-orang ini, apa itu, Fruit Ninja saya kira adalah hal mereka. 1537 01:07:20,500 --> 01:07:22,590 Itu semua berjalan pada Dynamo DB. 1538 01:07:22,590 --> 01:07:26,810 Dan orang-orang ini, mereka adalah besar tim pengembangan, pengembangan besar 1539 01:07:26,810 --> 01:07:27,670 toko. 1540 01:07:27,670 --> 01:07:29,364 >> Tidak baik tim ops. 1541 01:07:29,364 --> 01:07:31,280 Mereka tidak memiliki banyak sumber daya operasi. 1542 01:07:31,280 --> 01:07:33,940 Mereka berjuang berusaha untuk menjaga infrastruktur aplikasi mereka up 1543 01:07:33,940 --> 01:07:34,290 dan berjalan. 1544 01:07:34,290 --> 01:07:35,000 Mereka datang ke kami. 1545 01:07:35,000 --> 01:07:36,251 Mereka memandang bahwa Dynamo DB. 1546 01:07:36,251 --> 01:07:37,291 Mereka mengatakan, itu untuk kita. 1547 01:07:37,291 --> 01:07:39,470 Mereka membangun seluruh mereka kerangka aplikasi di atasnya. 1548 01:07:39,470 --> 01:07:43,640 Beberapa komentar yang benar-benar bagus di sini dari tim pada kemampuan mereka 1549 01:07:43,640 --> 01:07:46,800 untuk sekarang fokus pada bangunan permainan dan tidak 1550 01:07:46,800 --> 01:07:49,010 harus mempertahankan infrastruktur, yang 1551 01:07:49,010 --> 01:07:51,910 itu menjadi sejumlah besar overhead untuk tim mereka. 1552 01:07:51,910 --> 01:07:56,170 Jadi ini adalah sesuatu yang itu-- manfaat yang Anda dapatkan dari Dynamo DB. 1553 01:07:56,170 --> 01:08:00,930 >> Baiklah, masuk ke Data modeling di sini. 1554 01:08:00,930 --> 01:08:03,440 Dan kami berbicara sedikit tentang satu ini untuk satu, satu ke banyak, 1555 01:08:03,440 --> 01:08:05,060 dan banyak ke banyak hubungan jenis. 1556 01:08:05,060 --> 01:08:07,630 Dan bagaimana Anda menjaga mereka di Dynamo. 1557 01:08:07,630 --> 01:08:10,500 Dalam Dynamo DB kita menggunakan indeks, secara umum, 1558 01:08:10,500 --> 01:08:12,910 untuk memutar data dari satu rasa yang lain. 1559 01:08:12,910 --> 01:08:15,210 Kunci hash, kunci jangkauan, dan indeks. 1560 01:08:15,210 --> 01:08:18,540 >> Dalam tertentu Misalnya, karena kebanyakan negara 1561 01:08:18,540 --> 01:08:23,802 memiliki persyaratan lisensi yang hanya lisensi satu pengemudi per orang. 1562 01:08:23,802 --> 01:08:26,510 Anda tidak bisa pergi untuk mendapatkan sopir dua itu lisensi di negara bagian Boston. 1563 01:08:26,510 --> 01:08:27,500 Aku tidak bisa melakukannya di Texas. 1564 01:08:27,500 --> 01:08:28,708 Itu semacam cara itu. 1565 01:08:28,708 --> 01:08:32,779 Dan di DMV, kita memiliki pencarian, kita ingin mencari SIM 1566 01:08:32,779 --> 01:08:35,180 dengan nomor jaminan sosial. 1567 01:08:35,180 --> 01:08:39,990 Saya ingin mencari rincian pengguna dengan nomor SIM. 1568 01:08:39,990 --> 01:08:43,620 >> Jadi kita mungkin memiliki meja pengguna yang memiliki kunci hash pada nomor seri, 1569 01:08:43,620 --> 01:08:47,830 atau nomor jaminan sosial, dan berbagai atribut yang didefinisikan pada item. 1570 01:08:47,830 --> 01:08:49,859 Sekarang di atas meja saya bisa menentukan GSI yang 1571 01:08:49,859 --> 01:08:53,370 membalik bahwa sekitar yang mengatakan saya ingin kunci hash pada lisensi dan kemudian 1572 01:08:53,370 --> 01:08:54,252 semua barang-barang lainnya. 1573 01:08:54,252 --> 01:08:57,210 Sekarang jika saya ingin query dan menemukan nomor lisensi untuk setiap diberikan Sosial 1574 01:08:57,210 --> 01:08:59,609 Nomor jaminan, saya bisa query tabel utama. 1575 01:08:59,609 --> 01:09:02,130 >> Jika saya ingin query dan saya ingin untuk mendapatkan jaminan sosial 1576 01:09:02,130 --> 01:09:05,735 nomor atau atribut lainnya oleh nomor lisensi, aku bisa query GSI. 1577 01:09:05,735 --> 01:09:08,689 Model yang adalah salah satu yang untuk satu hubungan. 1578 01:09:08,689 --> 01:09:12,460 Hanya GSI sangat sederhana, membalik-hal di sekitar. 1579 01:09:12,460 --> 01:09:13,979 Sekarang, berbicara tentang satu ke banyak. 1580 01:09:13,979 --> 01:09:16,450 Satu ke banyak pada dasarnya adalah kunci kisaran hash Anda. 1581 01:09:16,450 --> 01:09:20,510 Di mana kita mendapatkan banyak dengan ini use case adalah data Monitor. 1582 01:09:20,510 --> 01:09:23,880 Data Monitor datang di reguler Interval, seperti internet hal. 1583 01:09:23,880 --> 01:09:26,890 Kami selalu mendapatkan semua ini catatan datang di sepanjang waktu. 1584 01:09:26,890 --> 01:09:31,420 >> Dan saya ingin mencari semua bacaan antara periode waktu tertentu. 1585 01:09:31,420 --> 01:09:34,220 Ini adalah permintaan yang sangat umum di infrastruktur monitoring. 1586 01:09:34,220 --> 01:09:38,430 Cara pergi tentang itu adalah untuk menemukan struktur tabel sederhana, satu meja. 1587 01:09:38,430 --> 01:09:42,250 Aku punya meja pengukuran perangkat dengan kunci hash pada ID perangkat. 1588 01:09:42,250 --> 01:09:47,340 Dan saya memiliki kunci pada rentang timestamp, atau dalam hal ini, epik. 1589 01:09:47,340 --> 01:09:50,350 Dan yang memungkinkan saya mengeksekusi kompleks query terhadap yang kunci kisaran 1590 01:09:50,350 --> 01:09:54,950 dan kembali catatan-catatan yang adalah relatif terhadap hasilnya 1591 01:09:54,950 --> 01:09:56,310 mengatur bahwa saya sedang mencari. 1592 01:09:56,310 --> 01:09:58,360 Dan itu membangun satu yang hubungan banyak 1593 01:09:58,360 --> 01:10:02,340 ke dalam tabel utama menggunakan kunci hash, struktur kunci jangkauan. 1594 01:10:02,340 --> 01:10:04,600 >> Jadi yang semacam dibangun ke dalam tabel di Dynamo DB. 1595 01:10:04,600 --> 01:10:07,290 Ketika saya mendefinisikan hash dan berbagai t tabel, aku 1596 01:10:07,290 --> 01:10:09,240 mendefinisikan satu ke banyak hubungan. 1597 01:10:09,240 --> 01:10:12,770 Ini adalah hubungan orangtua-anak. 1598 01:10:12,770 --> 01:10:14,620 >> Mari kita bicara tentang banyak untuk banyak hubungan. 1599 01:10:14,620 --> 01:10:19,170 Dan untuk contoh khusus ini, lagi, kita akan menggunakan GSI. 1600 01:10:19,170 --> 01:10:23,500 Dan mari kita bicara tentang game skenario di mana saya memiliki pengguna tertentu. 1601 01:10:23,500 --> 01:10:26,500 Saya ingin mengetahui semua game yang dia terdaftar untuk atau bermain di. 1602 01:10:26,500 --> 01:10:29,600 Dan untuk permainan yang diberikan, saya ingin mencari semua pengguna. 1603 01:10:29,600 --> 01:10:31,010 Jadi bagaimana saya melakukannya? 1604 01:10:31,010 --> 01:10:34,330 Meja permainan pengguna saya, saya akan memiliki kunci hash dari ID pengguna 1605 01:10:34,330 --> 01:10:35,810 dan kunci berbagai permainan. 1606 01:10:35,810 --> 01:10:37,810 >> Jadi pengguna dapat memiliki beberapa permainan. 1607 01:10:37,810 --> 01:10:41,380 Ini adalah satu ke banyak hubungan antara pengguna dan permainan dia bermain. 1608 01:10:41,380 --> 01:10:43,410 Dan kemudian pada GSI, Aku akan flip sekitar itu. 1609 01:10:43,410 --> 01:10:46,679 Aku akan hash pada permainan dan Aku akan berkisar pada pengguna. 1610 01:10:46,679 --> 01:10:48,970 Jadi jika saya ingin mendapatkan semua permainan pengguna bermain di, 1611 01:10:48,970 --> 01:10:49,950 Saya akan query tabel utama. 1612 01:10:49,950 --> 01:10:52,699 Jika saya ingin mendapatkan semua pengguna yang memainkan game tertentu, 1613 01:10:52,699 --> 01:10:53,887 Aku query GSI. 1614 01:10:53,887 --> 01:10:54,970 Jadi Anda melihat bagaimana kita melakukan ini? 1615 01:10:54,970 --> 01:10:58,369 Anda membangun ini GSI untuk mendukung kasus penggunaan, aplikasi, akses 1616 01:10:58,369 --> 01:10:59,410 pola, aplikasi. 1617 01:10:59,410 --> 01:11:01,440 >> Jika saya perlu query pada dimensi ini, biarkan 1618 01:11:01,440 --> 01:11:03,500 saya membuat indeks pada dimensi itu. 1619 01:11:03,500 --> 01:11:05,850 Jika saya tidak, saya tidak peduli. 1620 01:11:05,850 --> 01:11:09,060 Dan tergantung pada kasus penggunaan, saya mungkin perlu indeks atau saya mungkin tidak. 1621 01:11:09,060 --> 01:11:12,390 Jika itu yang sederhana ke banyak, tabel utama adalah baik-baik saja. 1622 01:11:12,390 --> 01:11:15,860 Jika saya perlu melakukan ini banyak ke banyak yang, atau saya harus melakukan satu dengan yang, 1623 01:11:15,860 --> 01:11:18,390 maka mungkin saya perlu untuk kedua indeks. 1624 01:11:18,390 --> 01:11:20,840 Jadi itu semua tergantung pada apa yang saya coba lakukan 1625 01:11:20,840 --> 01:11:24,550 dan apa yang saya coba untuk mendapatkan dicapai. 1626 01:11:24,550 --> 01:11:28,000 >> Mungkin saya tidak akan menghabiskan terlalu banyak waktu berbicara tentang dokumen. 1627 01:11:28,000 --> 01:11:31,460 Ini mendapat sedikit, mungkin, lebih dari yang kita butuhkan untuk masuk ke dalam. 1628 01:11:31,460 --> 01:11:33,710 Mari kita bicara sedikit ekspresi query tentang kaya. 1629 01:11:33,710 --> 01:11:37,831 Jadi di Dynamo DB kita memiliki kemampuan untuk membuat 1630 01:11:37,831 --> 01:11:39,330 apa yang kita sebut ekspresi proyeksi. 1631 01:11:39,330 --> 01:11:42,660 Ekspresi proyeksi hanya memilih bidang atau nilai-nilai 1632 01:11:42,660 --> 01:11:44,290 yang ingin ditampilkan. 1633 01:11:44,290 --> 01:11:46,000 OK, jadi saya membuat pilihan. 1634 01:11:46,000 --> 01:11:48,010 Saya membuat query melawan Dynamo DB. 1635 01:11:48,010 --> 01:11:51,730 Dan saya katakan, Anda tahu apa, acara saya hanya review bintang lima 1636 01:11:51,730 --> 01:11:54,544 untuk produk tertentu. 1637 01:11:54,544 --> 01:11:55,710 Jadi itu yang saya ingin melihat. 1638 01:11:55,710 --> 01:11:57,320 Saya tidak ingin melihat semua atribut lain dari baris, 1639 01:11:57,320 --> 01:11:58,319 Aku hanya ingin melihat ini. 1640 01:11:58,319 --> 01:12:01,209 Ini seperti di SQL ketika Anda mengatakan pilih bintang atau dari meja, 1641 01:12:01,209 --> 01:12:02,000 Anda mendapatkan semuanya. 1642 01:12:02,000 --> 01:12:05,450 Ketika saya mengatakan pilih nama dari meja, saya hanya mendapatkan satu atribut. 1643 01:12:05,450 --> 01:12:09,070 Ini adalah hal yang sama di Dynamo DB atau database NoSQL lain. 1644 01:12:09,070 --> 01:12:14,510 Filter ekspresi memungkinkan saya untuk pada dasarnya memotong hasil ditetapkan. 1645 01:12:14,510 --> 01:12:15,540 Jadi saya membuat query. 1646 01:12:15,540 --> 01:12:17,260 Query dapat kembali dengan 500 item. 1647 01:12:17,260 --> 01:12:20,255 Tapi aku hanya ingin item yang memiliki atribut yang mengatakan ini. 1648 01:12:20,255 --> 01:12:23,380 OK, jadi mari kita menyaring item-item yang tidak cocok pencarian tertentu. 1649 01:12:23,380 --> 01:12:25,540 Jadi kita memiliki ekspresi filter. 1650 01:12:25,540 --> 01:12:28,310 >> Filter ekspresi bisa dijalankan pada atribut apapun. 1651 01:12:28,310 --> 01:12:30,260 Mereka tidak suka berbagai pertanyaan. 1652 01:12:30,260 --> 01:12:32,690 Meningkatkan permintaan yang lebih selektif. 1653 01:12:32,690 --> 01:12:36,470 Filter query mengharuskan saya untuk pergi mendapatkan seluruh hasil set dan kemudian 1654 01:12:36,470 --> 01:12:39,170 mengukir data yang saya tidak ingin. 1655 01:12:39,170 --> 01:12:40,660 Mengapa itu penting? 1656 01:12:40,660 --> 01:12:42,770 Karena saya membaca itu semua. 1657 01:12:42,770 --> 01:12:46,597 Dalam query, saya akan membaca dan itu akan menjadi raksasa tentang data. 1658 01:12:46,597 --> 01:12:48,430 Dan kemudian aku akan mengukir apa yang saya butuhkan. 1659 01:12:48,430 --> 01:12:52,080 Dan jika aku hanya mengukir sebuah beberapa baris, maka itu OK. 1660 01:12:52,080 --> 01:12:53,620 Ini tidak begitu efisien. 1661 01:12:53,620 --> 01:12:57,800 >> Tetapi jika aku sedang membaca setumpuk data, hanya untuk mengukir satu item, 1662 01:12:57,800 --> 01:13:01,490 maka Aku akan menjadi lebih baik off menggunakan query kisaran, 1663 01:13:01,490 --> 01:13:03,030 karena itu jauh lebih selektif. 1664 01:13:03,030 --> 01:13:06,330 Ini akan menyelamatkan saya banyak uang, karena saya membayar untuk membaca itu. 1665 01:13:06,330 --> 01:13:10,430 Di mana hasil yang datang kembali menyeberangi kawat yang mungkin lebih kecil, 1666 01:13:10,430 --> 01:13:11,890 tapi saya membayar untuk membaca. 1667 01:13:11,890 --> 01:13:14,340 Jadi memahami bagaimana Anda mendapatkan data. 1668 01:13:14,340 --> 01:13:16,420 Itu sangat penting dalam Dynamo DB. 1669 01:13:16,420 --> 01:13:19,710 >> Ekspresi kondisional, ini adalah apa yang Anda mungkin menyebutnya penguncian optimis. 1670 01:13:19,710 --> 01:13:28,470 Perbarui JIKA ada, atau jika nilai ini setara dengan apa yang saya tentukan. 1671 01:13:28,470 --> 01:13:31,494 Dan jika saya memiliki cap waktu pada catatan, saya mungkin membaca data. 1672 01:13:31,494 --> 01:13:32,535 Aku mungkin mengubah data tersebut. 1673 01:13:32,535 --> 01:13:35,030 Aku bisa pergi menulis bahwa data kembali ke database. 1674 01:13:35,030 --> 01:13:38,100 Jika seseorang telah berubah catatan, timestamp mungkin telah berubah. 1675 01:13:38,100 --> 01:13:40,370 Dan cara yang saya kondisional Update bisa mengatakan pembaruan 1676 01:13:40,370 --> 01:13:42,340 jika timestamp sama ini. 1677 01:13:42,340 --> 01:13:46,290 Atau update akan gagal karena seseorang diperbarui rekor sementara itu. 1678 01:13:46,290 --> 01:13:48,290 >> Itulah yang kita sebut penguncian optimis. 1679 01:13:48,290 --> 01:13:50,670 Ini berarti bahwa seseorang bisa datang dan mengubahnya, 1680 01:13:50,670 --> 01:13:53,100 dan aku akan mendeteksinya ketika aku kembali untuk menulis. 1681 01:13:53,100 --> 01:13:56,106 Dan kemudian aku benar-benar bisa membaca bahwa Data dan mengatakan, oh, dia mengubah ini. 1682 01:13:56,106 --> 01:13:57,230 Saya perlu untuk memperhitungkan itu. 1683 01:13:57,230 --> 01:14:00,490 Dan saya bisa mengubah data di saya merekam dan menerapkan pembaruan lain. 1684 01:14:00,490 --> 01:14:04,330 Sehingga Anda dapat menangkap mereka tambahan pembaruan yang terjadi antara waktu 1685 01:14:04,330 --> 01:14:08,740 Anda membaca data dan waktu Anda mungkin menulis data. 1686 01:14:08,740 --> 01:14:11,520 >> AUDIENCE: Dan filter Ekspresi sebenarnya berarti tidak 1687 01:14:11,520 --> 01:14:13,020 dalam jumlah atau not-- 1688 01:14:13,020 --> 01:14:14,316 >> [Interposing SUARA] 1689 01:14:14,316 --> 01:14:16,232 RICK Houlihan: Saya tidak akan terlalu banyak ke dalam ini. 1690 01:14:16,232 --> 01:14:17,700 Ini adalah kata kunci yang dipesan. 1691 01:14:17,700 --> 01:14:20,130 Pound lihat adalah milik kata kunci di Dynamo DB. 1692 01:14:20,130 --> 01:14:24,500 Setiap database memiliki sendiri dilindungi nama untuk koleksi Anda tidak dapat menggunakan. 1693 01:14:24,500 --> 01:14:27,240 Dynamo DB, jika Anda menetapkan pon di depan ini, 1694 01:14:27,240 --> 01:14:29,310 Anda dapat menentukan nama-nama di atas. 1695 01:14:29,310 --> 01:14:31,840 Ini adalah nilai yang direferensikan. 1696 01:14:31,840 --> 01:14:34,880 Itu tidak mungkin sintaks terbaik untuk memiliki sana untuk diskusi ini, 1697 01:14:34,880 --> 01:14:38,090 karena itu akan menjadi beberapa real-- Saya akan telah berbicara lebih 1698 01:14:38,090 --> 01:14:41,360 tentang itu pada tingkat yang lebih dalam. 1699 01:14:41,360 --> 01:14:46,130 >> Tapi cukup untuk mengatakan, ini bisa menjadi permintaan memindai di mana mereka views-- 1700 01:14:46,130 --> 01:14:50,190 atau pon tampilan lebih besar dari 10. 1701 01:14:50,190 --> 01:14:54,660 Ini adalah nilai numerik, ya. 1702 01:14:54,660 --> 01:14:57,322 Jika Anda ingin, kita bisa bicara tentang bahwa setelah diskusi. 1703 01:14:57,322 --> 01:15:00,030 Baiklah, jadi kita masuk ke beberapa skenario dalam praktek terbaik 1704 01:15:00,030 --> 01:15:02,000 di mana kita akan berbicara tentang beberapa aplikasi di sini. 1705 01:15:02,000 --> 01:15:03,810 Apa kasus penggunaan untuk Dynamo DB. 1706 01:15:03,810 --> 01:15:06,120 Apa desain pola di Dynamo DB. 1707 01:15:06,120 --> 01:15:09,110 >> Dan yang pertama kita akan berbicara tentang adalah internet hal. 1708 01:15:09,110 --> 01:15:15,010 Jadi kita mendapatkan banyak of-- saya kira, apa yang itu-- lebih dari 50% 1709 01:15:15,010 --> 01:15:19,370 lalu lintas di internet hari ini sebenarnya dihasilkan oleh mesin, 1710 01:15:19,370 --> 01:15:21,930 proses otomatis, tidak oleh manusia. 1711 01:15:21,930 --> 01:15:25,140 Maksud saya hal ini hal ini yang Anda membawa sekitar di saku Anda, 1712 01:15:25,140 --> 01:15:28,840 berapa banyak data yang hal yang sebenarnya mengirimkan sekitar tanpa Anda 1713 01:15:28,840 --> 01:15:30,550 mengetahui itu adalah benar-benar menakjubkan. 1714 01:15:30,550 --> 01:15:34,970 Lokasi Anda, informasi tentang seberapa cepat Anda akan. 1715 01:15:34,970 --> 01:15:38,400 Bagaimana menurut Anda Google Maps karya ketika mereka memberitahu Anda apa lalu lintas. 1716 01:15:38,400 --> 01:15:41,275 Itu karena ada jutaan dan jutaan orang berkeliling 1717 01:15:41,275 --> 01:15:44,667 dengan ponsel yang mengirim Data seluruh tempat sepanjang waktu. 1718 01:15:44,667 --> 01:15:46,500 Jadi salah satu hal tentang jenis data 1719 01:15:46,500 --> 01:15:50,980 yang masuk, data yang memantau, log data, data time series, adalah itu 1720 01:15:50,980 --> 01:15:53,540 biasanya hanya menarik untuk sedikit waktu. 1721 01:15:53,540 --> 01:15:55,580 Setelah itu, itu tidak begitu menarik. 1722 01:15:55,580 --> 01:15:58,390 Jadi kita berbicara tentang, jangan biarkan meja tersebut tumbuh tanpa batas. 1723 01:15:58,390 --> 01:16:03,410 Idenya di sini adalah bahwa mungkin aku punya 24 jam senilai peristiwa di meja saya panas. 1724 01:16:03,410 --> 01:16:06,160 Dan bahwa meja panas akan menjadi ditetapkan pada tingkat yang sangat tinggi, 1725 01:16:06,160 --> 01:16:07,950 karena itu mengambil banyak data. 1726 01:16:07,950 --> 01:16:10,920 Itu mengambil banyak data dan aku membaca banyak. 1727 01:16:10,920 --> 01:16:14,560 Aku punya banyak operasi query berjalan terhadap data tersebut. 1728 01:16:14,560 --> 01:16:18,120 >> Setelah 24 jam, hei, Anda tahu apa, saya tidak peduli. 1729 01:16:18,120 --> 01:16:21,150 Jadi mungkin setiap tengah malam aku gulungan meja saya ke sebuah tabel baru 1730 01:16:21,150 --> 01:16:22,430 dan saya deprovision tabel ini. 1731 01:16:22,430 --> 01:16:26,440 Dan aku akan mengambil RCU dan WCU turun karena 24 jam kemudian 1732 01:16:26,440 --> 01:16:28,630 Aku tidak berjalan karena banyak query terhadap data tersebut. 1733 01:16:28,630 --> 01:16:30,200 Jadi aku akan menghemat uang. 1734 01:16:30,200 --> 01:16:32,940 Dan mungkin 30 hari kemudian saya tidak bahkan perlu peduli tentang itu semua. 1735 01:16:32,940 --> 01:16:35,020 Saya bisa mengambil WCU ini semua jalan ke satu, 1736 01:16:35,020 --> 01:16:36,990 karena Anda tahu apa, itu tidak akan pernah bisa ditulis. 1737 01:16:36,990 --> 01:16:38,300 Data yang berusia 30 hari. 1738 01:16:38,300 --> 01:16:40,000 Itu tidak pernah berubah. 1739 01:16:40,000 --> 01:16:44,200 >> Dan itu hampir tidak pernah akan mendapatkan membaca, jadi mari kita mengambil RCU ke 10. 1740 01:16:44,200 --> 01:16:49,372 Dan aku menyimpan satu ton uang ini data, dan hanya membayar untuk data saya panas. 1741 01:16:49,372 --> 01:16:52,330 Jadi itulah hal penting untuk melihat di saat Anda melihat serangkaian waktu 1742 01:16:52,330 --> 01:16:54,716 Data yang masuk dalam volume. 1743 01:16:54,716 --> 01:16:55,590 Ini adalah strategi. 1744 01:16:55,590 --> 01:16:58,010 Sekarang, aku hanya bisa membiarkannya semua pergi ke meja yang sama 1745 01:16:58,010 --> 01:16:59,461 dan hanya membiarkan meja yang tumbuh. 1746 01:16:59,461 --> 01:17:01,460 Akhirnya, aku akan melihat masalah kinerja. 1747 01:17:01,460 --> 01:17:04,060 Aku akan harus mulai untuk arsip beberapa data dari meja, 1748 01:17:04,060 --> 01:17:04,720 apa yang tidak. 1749 01:17:04,720 --> 01:17:07,010 >> Mari kita jauh lebih baik merancang aplikasi Anda 1750 01:17:07,010 --> 01:17:08,900 sehingga Anda dapat beroperasi dengan cara ini benar. 1751 01:17:08,900 --> 01:17:11,460 Jadi itu hanya otomatis dalam kode aplikasi. 1752 01:17:11,460 --> 01:17:13,580 Pada tengah malam setiap malam menggelinding meja. 1753 01:17:13,580 --> 01:17:17,170 Mungkin apa yang saya butuhkan adalah geser jendela 24 jam data. 1754 01:17:17,170 --> 01:17:20,277 Kemudian secara teratur saya memanggil data dari tabel. 1755 01:17:20,277 --> 01:17:22,360 Saya pemangkasan itu dengan Tugas cron dan aku meletakkan 1756 01:17:22,360 --> 01:17:24,160 ke tabel ini lain, apa pun yang Anda butuhkan. 1757 01:17:24,160 --> 01:17:25,940 Jadi jika rollover bekerja, itu hebat. 1758 01:17:25,940 --> 01:17:27,080 Jika tidak, memotongnya. 1759 01:17:27,080 --> 01:17:29,640 Tapi mari kita menjaga bahwa data panas jauh dari data yang dingin Anda. 1760 01:17:29,640 --> 01:17:32,535 Ini akan menghemat banyak uang dan membuat tabel Anda lebih berkinerja. 1761 01:17:32,535 --> 01:17:35,960 1762 01:17:35,960 --> 01:17:38,210 Jadi hal berikutnya kita akan berbicara tentang adalah katalog produk. 1763 01:17:38,210 --> 01:17:42,000 Katalog produk adalah kasus penggunaan yang cukup umum. 1764 01:17:42,000 --> 01:17:46,600 Ini sebenarnya adalah pola yang sangat umum bahwa kita akan melihat dalam berbagai hal. 1765 01:17:46,600 --> 01:17:48,870 Anda tahu, Twitter untuk Misalnya, tweet panas. 1766 01:17:48,870 --> 01:17:51,280 Semua orang datang dan meraih tweet yang. 1767 01:17:51,280 --> 01:17:52,680 Katalog produk, saya mendapat penjualan. 1768 01:17:52,680 --> 01:17:54,120 Saya mendapat penjualan panas. 1769 01:17:54,120 --> 01:17:57,277 Saya mendapat 70.000 permintaan per kedua datang untuk suatu produk 1770 01:17:57,277 --> 01:17:58,860 deskripsi dari katalog produk saya. 1771 01:17:58,860 --> 01:18:02,384 Kami melihat ini di ritel operasi sedikit. 1772 01:18:02,384 --> 01:18:03,550 Jadi bagaimana kita menghadapi itu? 1773 01:18:03,550 --> 01:18:04,924 Tidak ada cara untuk menghadapi itu. 1774 01:18:04,924 --> 01:18:07,110 Semua pengguna saya ingin melihat bagian yang sama dari data. 1775 01:18:07,110 --> 01:18:09,410 Mereka yang datang, bersamaan. 1776 01:18:09,410 --> 01:18:11,920 Dan mereka semua membuat permintaan untuk bagian yang sama dari data. 1777 01:18:11,920 --> 01:18:16,240 Ini memberi saya bahwa kunci panas, yang merah besar garis di grafik saya bahwa kita tidak suka. 1778 01:18:16,240 --> 01:18:17,720 Dan itulah yang yang terlihat seperti. 1779 01:18:17,720 --> 01:18:22,290 Jadi melintasi ruang kunci saya saya mendapatkan dipalu dalam item penjualan. 1780 01:18:22,290 --> 01:18:24,070 Saya mendapatkan apa-apa di tempat lain. 1781 01:18:24,070 --> 01:18:26,050 >> Bagaimana cara mengatasi masalah ini? 1782 01:18:26,050 --> 01:18:28,410 Yah, kita mengurangi ini dengan tembolok. 1783 01:18:28,410 --> 01:18:33,630 Cache, Anda menempatkan pada dasarnya di memori partisi di depan database. 1784 01:18:33,630 --> 01:18:37,260 Kami telah berhasil [Tidak terdengar] cache, bagaimana Anda 1785 01:18:37,260 --> 01:18:40,260 dapat mengatur cache sendiri, [tidak terdengar] Cache [? d,?] apa pun yang Anda inginkan. 1786 01:18:40,260 --> 01:18:42,220 Masukan yang di depan database. 1787 01:18:42,220 --> 01:18:47,250 Dan dengan cara itu Anda dapat menyimpan data yang dari orang-orang kunci panas di cache yang 1788 01:18:47,250 --> 01:18:49,390 ruang dan membaca cache. 1789 01:18:49,390 --> 01:18:51,962 >> Dan kemudian sebagian besar Anda membaca mulai mencari seperti ini. 1790 01:18:51,962 --> 01:18:54,920 Saya punya semua tembolok ini memukul di sini dan aku tidak ada yang terjadi di sini 1791 01:18:54,920 --> 01:18:59,330 karena database duduk di belakang cache dan bertuliskan pernah datang melalui. 1792 01:18:59,330 --> 01:19:02,520 Jika saya mengubah data di database, saya harus memperbarui cache. 1793 01:19:02,520 --> 01:19:04,360 Kita bisa menggunakan sesuatu seperti steams untuk melakukan itu. 1794 01:19:04,360 --> 01:19:07,360 Dan saya akan menjelaskan cara kerjanya. 1795 01:19:07,360 --> 01:19:09,060 Baiklah, pesan. 1796 01:19:09,060 --> 01:19:11,180 Email, kita semua menggunakan email. 1797 01:19:11,180 --> 01:19:12,540 >> Ini adalah contoh yang cukup baik. 1798 01:19:12,540 --> 01:19:14,950 Kami punya semacam pesan meja. 1799 01:19:14,950 --> 01:19:17,040 Dan kami mendapat inbox dan outbox. 1800 01:19:17,040 --> 01:19:19,760 Ini adalah apa yang akan SQL terlihat seperti untuk membangun inbox itu. 1801 01:19:19,760 --> 01:19:23,350 Kami semacam menggunakan jenis yang sama strategi untuk menggunakan GSI, GSI 1802 01:19:23,350 --> 01:19:25,320 untuk inbox saya dan kotak keluar saya. 1803 01:19:25,320 --> 01:19:27,600 Jadi aku pesan baku datang ke dalam tabel pesan saya. 1804 01:19:27,600 --> 01:19:30,194 Dan pendekatan pertama yang ini mungkin, mengatakan, OK, tidak ada masalah. 1805 01:19:30,194 --> 01:19:31,110 Aku punya pesan baku. 1806 01:19:31,110 --> 01:19:33,710 Pesan yang datang [tidak terdengar], pesan ID, itu hebat. 1807 01:19:33,710 --> 01:19:35,070 Itu hash unik saya. 1808 01:19:35,070 --> 01:19:38,280 Aku akan membuat dua GSI, salah satu untuk inbox saya, satu untuk kotak keluar saya. 1809 01:19:38,280 --> 01:19:40,530 Dan hal pertama yang saya akan melakukan adalah aku akan mengatakan kunci hash saya adalah 1810 01:19:40,530 --> 01:19:43,310 akan menjadi penerima dan Aku akan mengatur pada tanggal. 1811 01:19:43,310 --> 01:19:44,220 Ini fantastis. 1812 01:19:44,220 --> 01:19:45,890 Aku punya pandangan saya bagus di sini. 1813 01:19:45,890 --> 01:19:47,780 Tapi ada sedikit masalah di sini. 1814 01:19:47,780 --> 01:19:50,891 Dan Anda mengalami ini di database relasional juga. 1815 01:19:50,891 --> 01:19:52,390 Mereka disebut partisi vertikal. 1816 01:19:52,390 --> 01:19:55,840 Anda ingin menyimpan data besar Anda jauh dari sedikit data Anda. 1817 01:19:55,840 --> 01:20:00,470 >> Dan alasan mengapa adalah karena saya harus pergi membaca item untuk mendapatkan atribut. 1818 01:20:00,470 --> 01:20:05,570 Dan jika tubuh saya semua di sini, kemudian membaca hanya beberapa item 1819 01:20:05,570 --> 01:20:08,560 jika panjang tubuh saya rata-rata 256 kilobyte masing-masing, 1820 01:20:08,560 --> 01:20:10,991 matematika mendapat cukup jelek. 1821 01:20:10,991 --> 01:20:12,490 Jadi mengatakan saya ingin membaca inbox Daud. 1822 01:20:12,490 --> 01:20:14,520 Inbox David memiliki 50 item. 1823 01:20:14,520 --> 01:20:17,880 Rata-rata dan ukuran 256 kilobyte. 1824 01:20:17,880 --> 01:20:21,730 Berikut rasio konversi saya untuk RCU adalah empat kilobyte. 1825 01:20:21,730 --> 01:20:24,450 >> OK, mari kita pergi dengan akhirnya konsisten membaca. 1826 01:20:24,450 --> 01:20:28,640 Aku masih makan 1600 RCU ini hanya untuk membaca inbox Daud. 1827 01:20:28,640 --> 01:20:29,950 Aduh. 1828 01:20:29,950 --> 01:20:31,980 OK, sekarang mari kita berpikir tentang bagaimana aplikasi bekerja. 1829 01:20:31,980 --> 01:20:35,340 Jika saya di sebuah aplikasi email dan Aku sedang melihat inbox saya, 1830 01:20:35,340 --> 01:20:39,680 dan saya melihat tubuh setiap pesan, tidak, aku melihat ringkasan. 1831 01:20:39,680 --> 01:20:41,850 Aku sedang melihat hanya header. 1832 01:20:41,850 --> 01:20:46,310 Jadi mari kita membangun struktur tabel yang terlihat lebih seperti itu. 1833 01:20:46,310 --> 01:20:49,470 >> Jadi, inilah informasi bahwa alur kerja saya perlu. 1834 01:20:49,470 --> 01:20:50,890 Ini di inbox saya GSI. 1835 01:20:50,890 --> 01:20:53,800 Ini tanggal, pengirim, subjek, dan kemudian 1836 01:20:53,800 --> 01:20:56,790 ID pesan, yang menunjuk kembali ke meja pesan 1837 01:20:56,790 --> 01:20:57,850 di mana saya bisa mendapatkan tubuh. 1838 01:20:57,850 --> 01:21:01,260 1839 01:21:01,260 --> 01:21:04,420 Nah, ini akan menjadi catatan ID. 1840 01:21:04,420 --> 01:21:09,850 Mereka akan menunjuk kembali ke Item ID di meja Dynamo DB. 1841 01:21:09,850 --> 01:21:12,220 Setiap indeks selalu creates-- selalu memiliki item 1842 01:21:12,220 --> 01:21:15,750 ID sebagai bagian of-- yang dilengkapi dengan indeks. 1843 01:21:15,750 --> 01:21:17,414 >> Baiklah. 1844 01:21:17,414 --> 01:21:19,080 AUDIENCE: Ini memberitahu itu di mana itu disimpan? 1845 01:21:19,080 --> 01:21:21,420 RICK Houlihan: Ya, itu memberitahu exactly-- itulah apa yang dilakukannya. 1846 01:21:21,420 --> 01:21:22,644 Dikatakan inilah rekor ulang saya. 1847 01:21:22,644 --> 01:21:24,310 Dan itu akan menunjuk kembali ke record ulang saya. 1848 01:21:24,310 --> 01:21:26,460 Persis. 1849 01:21:26,460 --> 01:21:29,490 OK, jadi sekarang inbox saya sebenarnya jauh lebih kecil. 1850 01:21:29,490 --> 01:21:32,210 Dan ini benar-benar mendukung alur kerja dari sebuah aplikasi email. 1851 01:21:32,210 --> 01:21:34,230 Jadi inbox saya, saya klik. 1852 01:21:34,230 --> 01:21:38,160 Aku pergi bersama dan saya klik pada pesan, saat itulah saya harus pergi mendapatkan tubuh, 1853 01:21:38,160 --> 01:21:40,180 karena aku akan pergi ke pandangan yang berbeda. 1854 01:21:40,180 --> 01:21:43,870 Jadi jika Anda berpikir tentang jenis MVC dari framework, model view controller. 1855 01:21:43,870 --> 01:21:46,120 >> Model berisi Data yang kebutuhan tampilan 1856 01:21:46,120 --> 01:21:48,130 dan controller berinteraksi dengan. 1857 01:21:48,130 --> 01:21:51,670 Ketika saya mengubah frame, ketika Saya mengubah perspektif, 1858 01:21:51,670 --> 01:21:55,080 itu OK untuk kembali ke server dan terisi kembali model, 1859 01:21:55,080 --> 01:21:56,860 karena itulah yang diharapkan pengguna. 1860 01:21:56,860 --> 01:22:00,530 Ketika mereka mengubah pandangan, saat itulah kita bisa kembali ke database. 1861 01:22:00,530 --> 01:22:02,480 Jadi email, klik. 1862 01:22:02,480 --> 01:22:03,710 Saya mencari tubuh. 1863 01:22:03,710 --> 01:22:04,330 Perjalanan pulang pergi. 1864 01:22:04,330 --> 01:22:05,680 Pergi mendapatkan tubuh. 1865 01:22:05,680 --> 01:22:06,950 >> Saya membaca data jauh lebih sedikit. 1866 01:22:06,950 --> 01:22:09,960 Aku hanya membaca tubuh yang David kebutuhan ketika ia membutuhkan mereka. 1867 01:22:09,960 --> 01:22:14,230 Dan aku tidak membakar di 1600 RCU hanya untuk menunjukkan kotak masuk. 1868 01:22:14,230 --> 01:22:17,670 Jadi sekarang itu-- ini adalah cara bahwa LSI atau GSI-- Maaf, 1869 01:22:17,670 --> 01:22:19,900 GSI, akan berhasil. 1870 01:22:19,900 --> 01:22:25,450 Kami punya hash kami pada penerima. 1871 01:22:25,450 --> 01:22:27,030 Kami punya kunci rentang pada tanggal. 1872 01:22:27,030 --> 01:22:31,380 Dan kita punya atribut diproyeksikan bahwa kita hanya perlu untuk mendukung pandangan. 1873 01:22:31,380 --> 01:22:34,300 >> Kami memutar bahwa untuk kotak keluar. 1874 01:22:34,300 --> 01:22:35,770 Hash pada pengirim. 1875 01:22:35,770 --> 01:22:39,612 Dan pada intinya, kita harus yang sangat bagus, tampilan bersih. 1876 01:22:39,612 --> 01:22:41,570 Dan itu kami basically-- memiliki pesan ini bagus 1877 01:22:41,570 --> 01:22:45,870 tabel yang sedang menyebar baik karena itu hash saja, ID pesan hash. 1878 01:22:45,870 --> 01:22:51,750 Dan kami memiliki dua indeks yang yang berputar off dari meja itu. 1879 01:22:51,750 --> 01:22:57,411 Baiklah, jadi ide di sini adalah tidak menyimpan data yang besar dan data kecil ini 1880 01:22:57,411 --> 01:22:57,910 bersama. 1881 01:22:57,910 --> 01:23:00,700 Partisi vertikal, partisi meja tersebut. 1882 01:23:00,700 --> 01:23:03,150 Jangan membaca data Anda tidak perlu. 1883 01:23:03,150 --> 01:23:04,850 Baiklah, game. 1884 01:23:04,850 --> 01:23:06,990 Kita semua suka game. 1885 01:23:06,990 --> 01:23:10,902 Setidaknya aku suka game kemudian. 1886 01:23:10,902 --> 01:23:12,735 Jadi beberapa hal bahwa kita berurusan dengan ketika 1887 01:23:12,735 --> 01:23:14,193 kita berpikir tentang game, kan? 1888 01:23:14,193 --> 01:23:16,999 Game hari ini, terutama ponsel game, adalah semua tentang pemikiran. 1889 01:23:16,999 --> 01:23:19,540 Dan aku akan memutar di sini sedikit jauh dari DynamoDB. 1890 01:23:19,540 --> 01:23:21,373 Aku akan membawa beberapa diskusi 1891 01:23:21,373 --> 01:23:24,240 sekitar beberapa teknologi AWS lainnya. 1892 01:23:24,240 --> 01:23:28,930 >> Tapi gagasan tentang game adalah untuk berpikir sekitar dalam hal API, API yang, 1893 01:23:28,930 --> 01:23:31,730 secara umum, HTTP dan JSON. 1894 01:23:31,730 --> 01:23:34,550 Ini bagaimana game ponsel jenis berinteraksi dengan ujung belakang mereka. 1895 01:23:34,550 --> 01:23:35,850 Mereka melakukan JSON posting. 1896 01:23:35,850 --> 01:23:40,660 Mereka mendapatkan data, dan itu semua, secara umum, di bagus JSON API. 1897 01:23:40,660 --> 01:23:44,950 >> Hal-hal seperti mendapatkan teman-teman, mendapatkan data leaderboard, pertukaran, 1898 01:23:44,950 --> 01:23:47,699 user generated content, mendorong kembali ke sistem, 1899 01:23:47,699 --> 01:23:49,740 ini adalah jenis hal bahwa kita akan melakukan. 1900 01:23:49,740 --> 01:23:52,542 Data aset biner, data ini mungkin tidak duduk dalam database. 1901 01:23:52,542 --> 01:23:54,250 Ini mungkin duduk di toko objek, kan? 1902 01:23:54,250 --> 01:23:56,541 Tapi database akan akhirnya mengatakan sistem, 1903 01:23:56,541 --> 01:23:59,140 mengatakan aplikasi mana harus pergi mendapatkannya. 1904 01:23:59,140 --> 01:24:03,550 Dan pasti, multiplayer server, infrastruktur back-end, 1905 01:24:03,550 --> 01:24:06,180 dan dirancang untuk tinggi ketersediaan dan skalabilitas. 1906 01:24:06,180 --> 01:24:09,400 Jadi ini adalah hal-hal yang kita semua inginkan dalam infrastruktur game saat ini. 1907 01:24:09,400 --> 01:24:12,160 >> Jadi mari kita lihat apa yang terlihat seperti. 1908 01:24:12,160 --> 01:24:16,070 Mendapat back end inti, sangat mudah. 1909 01:24:16,070 --> 01:24:19,880 Kami punya sistem di sini dengan beberapa ketersediaan zona. 1910 01:24:19,880 --> 01:24:23,780 Kami berbicara tentang AZS sebagai being-- berpikir dari mereka sebagai pusat data yang terpisah. 1911 01:24:23,780 --> 01:24:26,040 Pusat lebih dari satu data per AZ, tapi itu OK, 1912 01:24:26,040 --> 01:24:28,831 hanya menganggap mereka sebagai data terpisah pusat yang secara geografis 1913 01:24:28,831 --> 01:24:30,090 dan kesalahan terisolasi. 1914 01:24:30,090 --> 01:24:32,172 >> Kita akan memiliki contoh beberapa EC2. 1915 01:24:32,172 --> 01:24:33,880 Kita akan memiliki beberapa end server kembali. 1916 01:24:33,880 --> 01:24:35,800 Mungkin jika Anda warisan arsitektur, kami 1917 01:24:35,800 --> 01:24:38,920 menggunakan apa yang kita sebut RDS, layanan database relasional. 1918 01:24:38,920 --> 01:24:42,040 Bisa MSSQL, MySQL, atau semacam itu. 1919 01:24:42,040 --> 01:24:47,080 Ini adalah cara aplikasi banyak yang dirancang hari ini. 1920 01:24:47,080 --> 01:24:49,594 >> Baik kita mungkin ingin pergi dengan ini adalah ketika kita skala keluar. 1921 01:24:49,594 --> 01:24:51,510 Kami akan pergi ke depan dan menempatkan ember S3 di sana. 1922 01:24:51,510 --> 01:24:54,200 Dan bahwa ember S3, alih-alih melayani up benda-benda dari servers-- kami 1923 01:24:54,200 --> 01:24:55,220 kita bisa melakukan itu. 1924 01:24:55,220 --> 01:24:57,210 Anda menempatkan semua biner Anda objek pada server Anda 1925 01:24:57,210 --> 01:24:59,751 dan Anda dapat menggunakan server mereka contoh untuk melayani data up. 1926 01:24:59,751 --> 01:25:01,860 Tapi itu cukup mahal. 1927 01:25:01,860 --> 01:25:05,107 >> Cara yang lebih baik untuk dilakukan adalah pergi ke depan dan menempatkan benda-benda dalam ember S3. 1928 01:25:05,107 --> 01:25:06,315 S3 adalah obyek repositori. 1929 01:25:06,315 --> 01:25:10,860 Itu dibangun khusus untuk melayani sampai jenis hal. 1930 01:25:10,860 --> 01:25:13,690 Dan biarkan meminta klien-klien langsung dari orang-orang obyek ember, 1931 01:25:13,690 --> 01:25:15,390 offload server. 1932 01:25:15,390 --> 01:25:17,020 Jadi kita mulai untuk skala sini. 1933 01:25:17,020 --> 01:25:19,140 >> Sekarang kita punya pengguna di seluruh dunia. 1934 01:25:19,140 --> 01:25:19,730 Aku pengguna. 1935 01:25:19,730 --> 01:25:23,380 Saya harus memiliki konten lokal terletak dekat dengan pengguna ini, kan? 1936 01:25:23,380 --> 01:25:26,200 Saya telah membuat ember S3 sebagai repositori sumber saya. 1937 01:25:26,200 --> 01:25:29,370 Dan aku akan depan bahwa dengan distribusi CloudFront. 1938 01:25:29,370 --> 01:25:31,720 >> CloudFront adalah CD dan jaringan pengiriman konten. 1939 01:25:31,720 --> 01:25:35,750 Pada dasarnya dibutuhkan data yang Anda tentukan dan cache itu semua melalui internet 1940 01:25:35,750 --> 01:25:39,230 sehingga pengguna di mana-mana dapat memiliki respon yang sangat cepat ketika 1941 01:25:39,230 --> 01:25:40,960 mereka meminta benda-benda. 1942 01:25:40,960 --> 01:25:41,960 >> Jadi Anda mendapatkan ide. 1943 01:25:41,960 --> 01:25:48,230 Anda semacam memanfaatkan semua aspek AWS sini untuk mendapatkan ini dilakukan. 1944 01:25:48,230 --> 01:25:50,790 Dan akhirnya, kita membuang dalam grup auto scaling. 1945 01:25:50,790 --> 01:25:52,737 Jadi contoh AC2 kami server permainan kami, 1946 01:25:52,737 --> 01:25:54,820 karena mereka mulai mendapatkan sibuk dan sibuk dan sibuk, 1947 01:25:54,820 --> 01:25:57,236 mereka hanya akan berputar lain Misalnya, berputar contoh lain, 1948 01:25:57,236 --> 01:25:58,210 berputar contoh lain. 1949 01:25:58,210 --> 01:26:02,090 Jadi teknologi AWS memiliki, itu memungkinkan Anda menentukan parameter 1950 01:26:02,090 --> 01:26:04,650 sekitar yang server Anda akan tumbuh. 1951 01:26:04,650 --> 01:26:08,110 Sehingga Anda dapat memiliki jumlah n server di luar sana pada waktu tertentu. 1952 01:26:08,110 --> 01:26:11,870 Dan jika beban Anda hilang, mereka akan menyusut, jumlahnya akan menyusut. 1953 01:26:11,870 --> 01:26:15,250 Dan jika beban datang kembali, itu akan tumbuh kembali keluar, elastis. 1954 01:26:15,250 --> 01:26:17,050 >> Jadi ini tampak hebat. 1955 01:26:17,050 --> 01:26:19,800 Kami punya banyak contoh EC2. 1956 01:26:19,800 --> 01:26:21,671 Kita dapat menempatkan cache depan database, 1957 01:26:21,671 --> 01:26:23,045 mencoba dan mempercepat database. 1958 01:26:23,045 --> 01:26:25,030 Titik tekanan berikutnya biasanya orang melihat 1959 01:26:25,030 --> 01:26:28,850 adalah mereka skala permainan menggunakan sistem database relasional. 1960 01:26:28,850 --> 01:26:30,790 Astaga, database kinerja mengerikan. 1961 01:26:30,790 --> 01:26:31,932 Bagaimana kita memperbaiki itu? 1962 01:26:31,932 --> 01:26:33,640 Mari kita coba menempatkan Cache di depan itu. 1963 01:26:33,640 --> 01:26:36,780 >> Nah, cache tidak bekerja begitu besar dalam permainan, kan? 1964 01:26:36,780 --> 01:26:39,330 Untuk game, menulis adalah menyakitkan. 1965 01:26:39,330 --> 01:26:40,930 Permainan sangat menulis berat. 1966 01:26:40,930 --> 01:26:43,610 Cache tidak bekerja ketika Anda menulis berat karena Anda telah selalu 1967 01:26:43,610 --> 01:26:44,610 harus memperbarui cache. 1968 01:26:44,610 --> 01:26:47,780 Anda memperbarui cache, itu relevan untuk caching. 1969 01:26:47,780 --> 01:26:49,780 Ini sebenarnya hanya bekerja ekstra. 1970 01:26:49,780 --> 01:26:51,970 >> Jadi di mana kita pergi di sini? 1971 01:26:51,970 --> 01:26:54,400 Anda punya hambatan besar di sana dalam database. 1972 01:26:54,400 --> 01:26:57,661 Dan tempat untuk pergi jelas adalah partisi. 1973 01:26:57,661 --> 01:26:59,410 Partisi tidak mudah dilakukan ketika Anda 1974 01:26:59,410 --> 01:27:01,900 berurusan dengan database relasional. 1975 01:27:01,900 --> 01:27:05,080 Dengan database relasional, Anda bertanggung jawab untuk mengelola, secara efektif, 1976 01:27:05,080 --> 01:27:06,210 ruang kunci. 1977 01:27:06,210 --> 01:27:10,527 Anda mengatakan pengguna antara A dan M pergi di sini, antara N dan Z pergi ke sana. 1978 01:27:10,527 --> 01:27:12,360 Dan Anda beralih di aplikasi. 1979 01:27:12,360 --> 01:27:15,000 Jadi Anda sedang berhadapan dengan ini sumber data partisi. 1980 01:27:15,000 --> 01:27:18,670 Anda memiliki kendala transaksional yang tidak menjangkau partisi. 1981 01:27:18,670 --> 01:27:20,560 Anda punya semua jenis kekacauan yang Anda 1982 01:27:20,560 --> 01:27:23,040 berurusan dengan di sana mencoba berurusan dengan skala keluar 1983 01:27:23,040 --> 01:27:25,120 dan membangun infrastruktur yang lebih besar. 1984 01:27:25,120 --> 01:27:27,284 Ini hanya tidak menyenangkan. 1985 01:27:27,284 --> 01:27:30,930 >> AUDIENCE: Jadi, apakah Anda mengatakan bahwa meningkatkan poin sumber mempercepat 1986 01:27:30,930 --> 01:27:31,430 proses? 1987 01:27:31,430 --> 01:27:32,513 RICK Houlihan: Meningkatkan? 1988 01:27:32,513 --> 01:27:33,520 AUDIENCE: Sumber poin. 1989 01:27:33,520 --> 01:27:34,410 RICK Houlihan: Sumber poin? 1990 01:27:34,410 --> 01:27:37,500 AUDIENCE: Dari informasi tersebut, di mana informasi tersebut berasal? 1991 01:27:37,500 --> 01:27:38,250 RICK Houlihan: No. 1992 01:27:38,250 --> 01:27:41,820 Apa yang saya katakan adalah meningkatkan Jumlah partisi dalam menyimpan data 1993 01:27:41,820 --> 01:27:44,060 meningkatkan throughput. 1994 01:27:44,060 --> 01:27:48,300 Jadi apa yang terjadi di sini adalah pengguna datang ke contoh EC2 di sini, 1995 01:27:48,300 --> 01:27:50,780 baik, jika saya membutuhkan pengguna itulah A ke M, aku akan pergi di sini. 1996 01:27:50,780 --> 01:27:53,560 Dari N ke p, aku akan pergi di sini. 1997 01:27:53,560 --> 01:27:55,060 Dari P ke Z, aku akan pergi di sini. 1998 01:27:55,060 --> 01:27:57,120 >> AUDIENCE: OK, mereka jadi mereka adalah semua disimpan di node yang berbeda? 1999 01:27:57,120 --> 01:27:57,911 >> RICK Houlihan: Ya. 2000 01:27:57,911 --> 01:28:00,210 Pikirkan ini sebagai silo data yang berbeda. 2001 01:28:00,210 --> 01:28:01,660 Jadi Anda harus melakukan ini. 2002 01:28:01,660 --> 01:28:02,910 Jika Anda mencoba untuk melakukan ini, jika Anda mencoba 2003 01:28:02,910 --> 01:28:05,730 untuk skala pada platform relasional, ini adalah apa yang Anda lakukan. 2004 01:28:05,730 --> 01:28:08,100 Anda mengambil data dan Anda memotong ke bawah. 2005 01:28:08,100 --> 01:28:10,975 Dan kau partisi itu di beberapa contoh dari database. 2006 01:28:10,975 --> 01:28:13,580 Dan kau mengelola semua yang di tingkat aplikasi. 2007 01:28:13,580 --> 01:28:14,729 Ini tidak menyenangkan. 2008 01:28:14,729 --> 01:28:15,770 Jadi apa yang kita ingin pergi? 2009 01:28:15,770 --> 01:28:20,240 Kami ingin pergi DynamoDB, sepenuhnya dikelola, NoSQL menyimpan data, penyediaan throughput. 2010 01:28:20,240 --> 01:28:22,680 Kami menggunakan indeks sekunder. 2011 01:28:22,680 --> 01:28:26,154 Ini pada dasarnya HTTP API dan termasuk dukungan dokumen. 2012 01:28:26,154 --> 01:28:28,570 Jadi Anda tidak perlu khawatir tentang semua partisi itu. 2013 01:28:28,570 --> 01:28:30,740 Kami melakukan semuanya untuk Anda. 2014 01:28:30,740 --> 01:28:33,260 Jadi sekarang, sebagai gantinya, Anda hanya menulis ke meja. 2015 01:28:33,260 --> 01:28:36,490 Jika tabel perlu dipartisi, yang terjadi di balik layar. 2016 01:28:36,490 --> 01:28:40,642 Anda benar-benar terisolasi dari yang sebagai pengembang. 2017 01:28:40,642 --> 01:28:42,350 Jadi mari kita bicara tentang beberapa kasus penggunaan 2018 01:28:42,350 --> 01:28:47,564 bahwa kita mengalami dalam game, umum skenario game, leaderboard. 2019 01:28:47,564 --> 01:28:49,980 Jadi Anda punya pengguna datang, yang BoardNames bahwa mereka 2020 01:28:49,980 --> 01:28:52,930 pada, skor untuk pengguna ini. 2021 01:28:52,930 --> 01:28:57,700 Kami mungkin hashing pada UserID, dan kemudian kami memiliki berbagai pada permainan. 2022 01:28:57,700 --> 01:28:59,960 Jadi setiap pengguna ingin melihat semua pertandingan dia bermain 2023 01:28:59,960 --> 01:29:01,770 dan semua top skor nya di semua pertandingan. 2024 01:29:01,770 --> 01:29:04,000 Jadi itulah leaderboard pribadinya. 2025 01:29:04,000 --> 01:29:10,010 >> Sekarang saya ingin pergi dan saya ingin get-- jadi saya mendapatkan ini leaderboards pribadi. 2026 01:29:10,010 --> 01:29:12,827 Yang ingin saya lakukan adalah pergi mendapatkan skor atas seluruh pengguna. 2027 01:29:12,827 --> 01:29:13,660 Jadi bagaimana saya melakukannya? 2028 01:29:13,660 --> 01:29:18,070 Ketika catatan saya hash pada UserID, berkisar pada permainan, 2029 01:29:18,070 --> 01:29:20,740 baik aku akan pergi ke depan dan restrukturisasi, membuat GSI, 2030 01:29:20,740 --> 01:29:22,370 dan aku akan merestrukturisasi data tersebut. 2031 01:29:22,370 --> 01:29:27,310 >> Sekarang aku akan hash pada BoardName, yang merupakan permainan. 2032 01:29:27,310 --> 01:29:29,800 Dan aku akan berkisar pada top skor. 2033 01:29:29,800 --> 01:29:31,540 Dan sekarang saya buat ember yang berbeda. 2034 01:29:31,540 --> 01:29:34,790 Saya menggunakan meja yang sama, Data item yang sama. 2035 01:29:34,790 --> 01:29:39,870 Tapi aku menciptakan sebuah ember yang memberikan saya sebuah agregasi dari top skor dengan permainan. 2036 01:29:39,870 --> 01:29:43,180 >> Dan aku bisa query tabel yang untuk mendapatkan informasi tersebut. 2037 01:29:43,180 --> 01:29:50,890 Jadi saya sudah menetapkan bahwa pola permintaan hingga didukung oleh indeks sekunder. 2038 01:29:50,890 --> 01:29:54,556 Sekarang mereka dapat diurutkan berdasarkan BoardName dan diurutkan berdasarkan topscore, tergantung pada. 2039 01:29:54,556 --> 01:29:57,180 Sehingga Anda dapat melihat, ini adalah jenis dari menggunakan kasus yang Anda dapatkan dalam game. 2040 01:29:57,180 --> 01:30:02,190 Penggunaan Lain halnya baik yang kita dapatkan di game adalah penghargaan dan siapa yang memenangkan penghargaan. 2041 01:30:02,190 --> 01:30:05,340 Dan ini adalah kasus penggunaan besar di mana kita sebut indeks jarang. 2042 01:30:05,340 --> 01:30:07,340 Indeks jarang adalah kemampuan untuk menghasilkan 2043 01:30:07,340 --> 01:30:10,850 indeks yang tidak tentu mengandung setiap satu item di atas meja. 2044 01:30:10,850 --> 01:30:11,470 Dan kenapa tidak? 2045 01:30:11,470 --> 01:30:14,540 Karena atribut yang menjadi diindeks tidak ada pada setiap item. 2046 01:30:14,540 --> 01:30:16,460 >> Jadi dalam hal ini khususnya menggunakan kasus, saya katakan, 2047 01:30:16,460 --> 01:30:19,240 Anda tahu apa, aku akan membuat atribut yang disebut Award. 2048 01:30:19,240 --> 01:30:22,970 Dan aku akan memberikan setiap pengguna yang memiliki penghargaan yang atribut. 2049 01:30:22,970 --> 01:30:25,950 Pengguna yang tidak memiliki penghargaan yang tidak akan memiliki atribut itu. 2050 01:30:25,950 --> 01:30:27,800 Jadi ketika saya membuat Indeks, satu-satunya pengguna 2051 01:30:27,800 --> 01:30:28,960 yang akan menunjukkan di indeks adalah 2052 01:30:28,960 --> 01:30:31,050 orang-orang yang benar-benar telah memenangkan penghargaan. 2053 01:30:31,050 --> 01:30:34,440 Jadi itulah cara yang bagus untuk dapat untuk membuat indeks disaring yang 2054 01:30:34,440 --> 01:30:40,580 sangat, sangat selektif yang tidak harus indeks seluruh tabel. 2055 01:30:40,580 --> 01:30:43,050 >> Jadi kita sudah rendah pada waktu di sini. 2056 01:30:43,050 --> 01:30:49,190 Aku akan pergi ke depan dan melewatkan dan melewatkan skenario ini. 2057 01:30:49,190 --> 01:30:52,625 Berbicara sedikit about-- 2058 01:30:52,625 --> 01:30:54,460 >> AUDIENCE: Dapatkah saya mengajukan pertanyaan singkat? 2059 01:30:54,460 --> 01:30:56,722 Salah satunya adalah menulis berat? 2060 01:30:56,722 --> 01:30:57,680 RICK Houlihan: Apa? 2061 01:30:57,680 --> 01:30:58,596 AUDIENCE: Menulis berat. 2062 01:30:58,596 --> 01:31:01,270 RICK Houlihan: Menulis berat. 2063 01:31:01,270 --> 01:31:03,460 Biarkan saya lihat. 2064 01:31:03,460 --> 01:31:06,220 >> AUDIENCE: Atau itu tidak sesuatu yang Anda hanya dapat 2065 01:31:06,220 --> 01:31:08,809 suara ke dalam hitungan detik? 2066 01:31:08,809 --> 01:31:10,850 RICK Houlihan: Kami pergi melalui skenario voting. 2067 01:31:10,850 --> 01:31:11,670 Tidak seburuk itu. 2068 01:31:11,670 --> 01:31:14,580 Apakah kalian memiliki beberapa menit? 2069 01:31:14,580 --> 01:31:15,860 OKE. 2070 01:31:15,860 --> 01:31:17,890 >> Jadi kita akan berbicara tentang voting. 2071 01:31:17,890 --> 01:31:20,250 Jadi real time voting, kita memiliki persyaratan untuk voting. 2072 01:31:20,250 --> 01:31:25,250 Persyaratan yang kita membiarkan setiap orang untuk memilih hanya sekali. 2073 01:31:25,250 --> 01:31:28,060 Kami ingin ada untuk dapat untuk mengubah suara mereka. 2074 01:31:28,060 --> 01:31:31,045 Kami ingin real-time agregasi dan analisis untuk demografi 2075 01:31:31,045 --> 01:31:34,210 bahwa kita akan menjadi menunjukkan kepada pengguna di situs. 2076 01:31:34,210 --> 01:31:35,200 >> Pikirkan skenario ini. 2077 01:31:35,200 --> 01:31:37,550 Kami bekerja banyak realitas TV menunjukkan di mana mereka 2078 01:31:37,550 --> 01:31:38,960 melakukan jenis ini sebenarnya hal. 2079 01:31:38,960 --> 01:31:41,584 Jadi Anda bisa memikirkan skenario, kita memiliki jutaan dan jutaan 2080 01:31:41,584 --> 01:31:43,959 gadis remaja di sana dengan ponsel mereka 2081 01:31:43,959 --> 01:31:46,250 dan voting, dan pemungutan suara, dan voting untuk siapa pun mereka 2082 01:31:46,250 --> 01:31:48,610 menemukan untuk menjadi yang paling populer. 2083 01:31:48,610 --> 01:31:50,830 Jadi ini adalah beberapa persyaratan kita kehabisan. 2084 01:31:50,830 --> 01:31:52,990 >> Dan mengambil begitu pertama dalam memecahkan masalah ini 2085 01:31:52,990 --> 01:31:55,090 akan membangun aplikasi yang sangat sederhana. 2086 01:31:55,090 --> 01:31:56,490 Jadi saya punya aplikasi ini. 2087 01:31:56,490 --> 01:31:57,950 Saya memiliki beberapa pemilih di luar sana. 2088 01:31:57,950 --> 01:31:59,980 Mereka datang dalam, mereka memukul aplikasi voting. 2089 01:31:59,980 --> 01:32:03,440 Aku punya beberapa orang meja baku Aku hanya akan membuang mereka ke dalam penilaian. 2090 01:32:03,440 --> 01:32:05,780 Aku akan memiliki beberapa agregat penilaian tabel yang 2091 01:32:05,780 --> 01:32:09,490 akan melakukan analisis dan demografi saya, dan kita akan meletakkan semua ini di sana. 2092 01:32:09,490 --> 01:32:11,420 >> Dan ini sangat bagus. 2093 01:32:11,420 --> 01:32:12,332 Hidup adalah baik. 2094 01:32:12,332 --> 01:32:15,040 Hidup yang baik sampai kita mengetahui bahwa selalu ada hanya satu atau dua 2095 01:32:15,040 --> 01:32:16,879 orang yang populer dalam pemilu. 2096 01:32:16,879 --> 01:32:19,420 Hanya ada satu atau dua hal bahwa orang-orang benar-benar peduli. 2097 01:32:19,420 --> 01:32:22,340 Dan jika Anda suara di skala, tiba-tiba aku 2098 01:32:22,340 --> 01:32:26,360 akan memalu neraka keluar dari dua kandidat, satu atau dua kandidat. 2099 01:32:26,360 --> 01:32:29,390 Sebuah jumlah yang sangat terbatas item orang menemukan untuk menjadi populer. 2100 01:32:29,390 --> 01:32:31,710 >> Ini bukan pola desain yang baik. 2101 01:32:31,710 --> 01:32:33,549 Ini sebenarnya adalah pola desain yang sangat buruk 2102 01:32:33,549 --> 01:32:36,340 karena ia menciptakan apa yang kita berbicara tentang yang kunci panas. 2103 01:32:36,340 --> 01:32:38,960 Kunci panas adalah sesuatu yang kita tidak suka. 2104 01:32:38,960 --> 01:32:40,470 >> Jadi bagaimana kita memperbaikinya? 2105 01:32:40,470 --> 01:32:47,640 Dan benar-benar, cara untuk memperbaiki ini dengan mengambil orang-orang calon ember 2106 01:32:47,640 --> 01:32:51,490 dan untuk masing-masing calon yang kita miliki, kita akan menambahkan nilai acak, 2107 01:32:51,490 --> 01:32:54,192 sesuatu yang kita tahu, random nilai antara satu dan 100, 2108 01:32:54,192 --> 01:32:56,620 antara 100 dan 1.000, atau antara satu dan 1.000, 2109 01:32:56,620 --> 01:32:59,940 namun banyak nilai acak Anda ingin menambahkan ke akhir calon itu. 2110 01:32:59,940 --> 01:33:01,330 >> Dan apa yang saya benar-benar melakukan itu? 2111 01:33:01,330 --> 01:33:05,830 Jika saya menggunakan kandidat ID sebagai ember untuk orang agregat, 2112 01:33:05,830 --> 01:33:08,780 jika saya telah menambahkan acak nomor akhir itu, 2113 01:33:08,780 --> 01:33:12,000 Saya telah membuat sekarang 10 ember, sebuah ratus ember, seribu ember 2114 01:33:12,000 --> 01:33:14,160 bahwa aku menggabungkan penilaian di seluruh. 2115 01:33:14,160 --> 01:33:18,030 >> Jadi saya memiliki jutaan, dan jutaan, dan jutaan catatan datang 2116 01:33:18,030 --> 01:33:22,050 untuk calon ini, saya sekarang menyebarkan mereka orang di seluruh Calon a_1 2117 01:33:22,050 --> 01:33:24,630 melalui Calon A_100, karena setiap kali orang masuk, 2118 01:33:24,630 --> 01:33:26,530 Aku menghasilkan acak nilai antara satu dan 100. 2119 01:33:26,530 --> 01:33:29,446 Aku memaku itu ke akhir kandidat yang orang memberikan suara untuk. 2120 01:33:29,446 --> 01:33:31,120 Aku membuangnya ke dalam ember itu. 2121 01:33:31,120 --> 01:33:33,910 >> Sekarang di bagian belakang, saya tahu bahwa saya mendapat seratus ember. 2122 01:33:33,910 --> 01:33:36,350 Jadi ketika saya ingin pergi ke depan dan agregat orang, 2123 01:33:36,350 --> 01:33:38,244 Saya membaca dari semua ember. 2124 01:33:38,244 --> 01:33:39,160 Jadi aku pergi ke depan dan menambahkan. 2125 01:33:39,160 --> 01:33:42,410 Dan kemudian saya pencar berkumpul di mana aku pergi keluar dan mengatakan hei, 2126 01:33:42,410 --> 01:33:45,399 Anda tahu apa, kunci ini kandidat ruang adalah lebih dari seratus ember. 2127 01:33:45,399 --> 01:33:47,940 Aku akan mengumpulkan semua memberikan suara dari orang-orang seratus ember. 2128 01:33:47,940 --> 01:33:49,981 Aku akan agregat mereka dan aku akan mengatakan, 2129 01:33:49,981 --> 01:33:53,830 Calon A sekarang memiliki Total penghitungan suara x. 2130 01:33:53,830 --> 01:33:55,690 >> Sekarang kedua menulis query dan permintaan membaca 2131 01:33:55,690 --> 01:33:58,160 yang baik didistribusikan karena saya sedang menulis di 2132 01:33:58,160 --> 01:34:00,320 dan aku membaca di ratusan kunci. 2133 01:34:00,320 --> 01:34:03,500 Saya tidak menulis dan membaca di salah satu kunci sekarang. 2134 01:34:03,500 --> 01:34:04,950 Jadi itulah pola yang besar. 2135 01:34:04,950 --> 01:34:08,090 >> Ini sebenarnya mungkin salah satu dari desain yang paling penting 2136 01:34:08,090 --> 01:34:10,420 pola skala di NoSQL. 2137 01:34:10,420 --> 01:34:14,470 Anda akan melihat jenis pola desain dalam setiap rasa. 2138 01:34:14,470 --> 01:34:19,100 MongoDB, DynamoDB, tidak peduli, kita semua harus melakukan ini. 2139 01:34:19,100 --> 01:34:21,840 Karena ketika Anda sedang berhadapan dengan orang-agregasi besar, 2140 01:34:21,840 --> 01:34:26,650 Anda harus mencari cara untuk menyebar mereka di ember. 2141 01:34:26,650 --> 01:34:29,512 Jadi ini adalah cara Anda melakukannya. 2142 01:34:29,512 --> 01:34:31,220 Baiklah, jadi apa Anda lakukan sekarang 2143 01:34:31,220 --> 01:34:35,252 adalah Anda perdagangan off dibaca Biaya untuk menulis skalabilitas. 2144 01:34:35,252 --> 01:34:37,085 Biaya membaca saya adalah sedikit lebih kompleks 2145 01:34:37,085 --> 01:34:40,220 dan saya harus pergi dibaca dari ratus ember, bukan satu. 2146 01:34:40,220 --> 01:34:41,310 Tapi aku bisa menulis. 2147 01:34:41,310 --> 01:34:44,860 Dan throughput saya, saya menulis throughput yang luar biasa. 2148 01:34:44,860 --> 01:34:49,450 Sehingga biasanya berharga teknik untuk skala DynamoDB, 2149 01:34:49,450 --> 01:34:51,350 atau database NoSQL untuk hal itu. 2150 01:34:51,350 --> 01:34:53,824 2151 01:34:53,824 --> 01:34:55,240 Jadi kami menemukan cara untuk skala itu. 2152 01:34:55,240 --> 01:34:56,930 Dan kami pikir bagaimana menghilangkan kunci panas kami. 2153 01:34:56,930 --> 01:34:57,820 Dan ini fantastis. 2154 01:34:57,820 --> 01:34:58,960 Dan kita punya sistem ini bagus. 2155 01:34:58,960 --> 01:35:02,043 Dan itu memberi kita voting sangat benar karena kita memiliki catatan suara de-korban penipuan. 2156 01:35:02,043 --> 01:35:03,130 Ini dibangun ke DynamoDB. 2157 01:35:03,130 --> 01:35:05,380 Kami berbicara tentang hak-hak bersyarat. 2158 01:35:05,380 --> 01:35:08,170 >> Ketika pemilih datang, menempatkan insert di atas meja, 2159 01:35:08,170 --> 01:35:11,220 mereka memasukkan dengan ID pemilih mereka, jika mereka mencoba untuk memasukkan suara lain, 2160 01:35:11,220 --> 01:35:13,320 Saya melakukan write bersyarat. 2161 01:35:13,320 --> 01:35:16,960 Mengatakan hanya menulis ini jika ini tidak ada. 2162 01:35:16,960 --> 01:35:19,270 Jadi, segera setelah saya melihat bahwa bahwa suara itu memukul meja, 2163 01:35:19,270 --> 01:35:20,460 tidak ada orang lain akan menjadi mampu menempatkan suara mereka di. 2164 01:35:20,460 --> 01:35:21,634 Dan itu fantastis. 2165 01:35:21,634 --> 01:35:23,550 Dan kita incrementing counter kandidat kami. 2166 01:35:23,550 --> 01:35:25,466 Dan kami melakukan kami demografi dan semua itu. 2167 01:35:25,466 --> 01:35:29,110 Tapi apa yang terjadi jika saya Aplikasi jatuh di atas? 2168 01:35:29,110 --> 01:35:31,350 Sekarang semua orang tiba-tiba dari yang datang, dan saya 2169 01:35:31,350 --> 01:35:34,840 tidak tahu apakah mereka mendapatkan diproses dalam analisis dan demografi saya 2170 01:35:34,840 --> 01:35:36,040 lagi. 2171 01:35:36,040 --> 01:35:38,462 Dan saat aplikasi datang kembali, bagaimana 2172 01:35:38,462 --> 01:35:41,420 sih saya tahu apa yang orang memiliki diproses dan di mana saya mulai? 2173 01:35:41,420 --> 01:35:44,530 >> Jadi ini adalah masalah nyata ketika Anda mulai melihat jenis skenario. 2174 01:35:44,530 --> 01:35:45,571 Dan bagaimana kita mengatasi itu? 2175 01:35:45,571 --> 01:35:48,070 Kami menyelesaikannya dengan apa yang kita memanggil DynamoDB Streaming. 2176 01:35:48,070 --> 01:35:53,470 Streaming adalah waktu memerintahkan dan dipartisi log perubahan setiap akses 2177 01:35:53,470 --> 01:35:55,700 ke meja, setiap menulis Akses ke meja. 2178 01:35:55,700 --> 01:35:58,810 Setiap data yang ditulis ke tabel muncul di sungai. 2179 01:35:58,810 --> 01:36:01,815 >> Ini pada dasarnya antrian 24 jam. 2180 01:36:01,815 --> 01:36:03,690 Item memukul sungai, mereka hidup selama 24 jam. 2181 01:36:03,690 --> 01:36:05,990 Mereka dapat dibaca beberapa kali. 2182 01:36:05,990 --> 01:36:09,400 Dijamin akan disampaikan hanya sekali ke sungai, 2183 01:36:09,400 --> 01:36:11,180 bisa membaca nomor n kali. 2184 01:36:11,180 --> 01:36:14,910 Jadi namun banyak proses yang ingin Anda mengkonsumsi data, Anda dapat mengkonsumsinya. 2185 01:36:14,910 --> 01:36:16,350 Ini akan muncul setiap update. 2186 01:36:16,350 --> 01:36:18,455 Setiap menulis hanya akan muncul sekali di sungai. 2187 01:36:18,455 --> 01:36:20,621 Jadi Anda tidak perlu khawatir tentang pengolahan dua kali 2188 01:36:20,621 --> 01:36:22,500 dari proses yang sama. 2189 01:36:22,500 --> 01:36:25,350 >> Ini benar-benar memerintahkan per item. 2190 01:36:25,350 --> 01:36:28,180 Ketika kita mengatakan waktu memerintahkan dan dipartisi, 2191 01:36:28,180 --> 01:36:30,680 Anda akan melihat per partisi di sungai. 2192 01:36:30,680 --> 01:36:33,169 Anda akan melihat item, update dalam rangka. 2193 01:36:33,169 --> 01:36:35,210 Kami tidak menjamin pada sungai yang Anda 2194 01:36:35,210 --> 01:36:40,240 akan mendapatkan setiap transaksi dalam urutan di item. 2195 01:36:40,240 --> 01:36:42,440 >> Jadi aliran yang idempoten. 2196 01:36:42,440 --> 01:36:44,037 Apakah kita semua tahu apa idempoten berarti? 2197 01:36:44,037 --> 01:36:46,620 Idempoten berarti Anda dapat melakukannya lebih, dan lebih, dan lebih lagi. 2198 01:36:46,620 --> 01:36:48,200 Hasilnya akan sama. 2199 01:36:48,200 --> 01:36:49,991 >> Streaming adalah idempoten, tetapi mereka harus 2200 01:36:49,991 --> 01:36:54,860 bermain dari titik awal, dimanapun Anda memilih, sampai akhir, 2201 01:36:54,860 --> 01:36:57,950 atau mereka tidak akan menghasilkan dalam nilai-nilai yang sama. 2202 01:36:57,950 --> 01:36:59,727 >> Hal yang sama dengan MongoDB. 2203 01:36:59,727 --> 01:37:01,560 MongoDB memiliki membangun sebuah mereka sebut oplog tersebut. 2204 01:37:01,560 --> 01:37:04,140 Ini adalah membangun yang sama persis. 2205 01:37:04,140 --> 01:37:06,500 Banyak database NoSQL memiliki konstruksi ini. 2206 01:37:06,500 --> 01:37:08,790 Mereka menggunakannya untuk melakukan hal-hal seperti replikasi, yang 2207 01:37:08,790 --> 01:37:10,475 adalah apa yang kita lakukan dengan aliran. 2208 01:37:10,475 --> 01:37:12,350 AUDIENCE: Mungkin pertanyaan sesat, tetapi Anda 2209 01:37:12,350 --> 01:37:13,975 berbicara tentang melakukan aplikasi turun sebagainya. 2210 01:37:13,975 --> 01:37:16,089 Apakah aliran dijamin tidak pernah mungkin turun? 2211 01:37:16,089 --> 01:37:18,630 RICK Houlihan: Ya, sungai dijamin untuk tidak pernah turun. 2212 01:37:18,630 --> 01:37:21,040 Kami mengelola infrastruktur di belakang. stream secara otomatis 2213 01:37:21,040 --> 01:37:22,498 menyebarkan dalam kelompok auto skala mereka. 2214 01:37:22,498 --> 01:37:25,910 Kami akan pergi melalui sedikit sedikit tentang apa yang terjadi. 2215 01:37:25,910 --> 01:37:30,060 >> Saya tidak harus mengatakan mereka tidak dijamin untuk tidak pernah turun. 2216 01:37:30,060 --> 01:37:33,110 Unsur-unsur dijamin muncul di sungai. 2217 01:37:33,110 --> 01:37:36,740 Dan sungai akan dapat diakses. 2218 01:37:36,740 --> 01:37:40,580 Jadi apa yang turun atau kembali lagi up, yang terjadi di bawah. 2219 01:37:40,580 --> 01:37:43,844 Ini covers-- itu OK. 2220 01:37:43,844 --> 01:37:46,260 Baiklah, sehingga Anda mendapatkan yang berbeda lihat jenis dari layar. 2221 01:37:46,260 --> 01:37:51,040 Jenis pandangan yang penting untuk programmer biasanya adalah, apa itu? 2222 01:37:51,040 --> 01:37:52,370 Saya mendapatkan tampilan lama. 2223 01:37:52,370 --> 01:37:55,630 Ketika update hits meja, itu akan mendorong pandangan lama ke sungai 2224 01:37:55,630 --> 01:38:02,070 sehingga data dapat arsip, atau perubahan kontrol, identifikasi perubahan, perubahan 2225 01:38:02,070 --> 01:38:03,600 pengelolaan. 2226 01:38:03,600 --> 01:38:07,160 >> Gambar baru, apa yang sekarang setelah update, itu jenis lain dari tampilan 2227 01:38:07,160 --> 01:38:07,660 Anda bisa mendapatkan. 2228 01:38:07,660 --> 01:38:09,660 Anda bisa mendapatkan kedua gambar lama dan baru. 2229 01:38:09,660 --> 01:38:10,660 Mungkin aku ingin mereka berdua. 2230 01:38:10,660 --> 01:38:11,790 Saya ingin melihat apa itu. 2231 01:38:11,790 --> 01:38:13,290 Saya ingin melihat apa yang berubah. 2232 01:38:13,290 --> 01:38:15,340 >> Saya memiliki jenis kepatuhan dari proses yang berjalan. 2233 01:38:15,340 --> 01:38:17,430 Perlu memverifikasi bahwa ketika hal-hal ini berubah, 2234 01:38:17,430 --> 01:38:21,840 bahwa mereka dalam batas-batas tertentu atau dalam parameter tertentu. 2235 01:38:21,840 --> 01:38:23,840 >> Dan kemudian mungkin saya hanya perlu tahu apa yang berubah. 2236 01:38:23,840 --> 01:38:26,240 Saya tidak peduli apa yang item berubah. 2237 01:38:26,240 --> 01:38:28,580 Saya tidak perlu perlu tahu apa atribut berubah. 2238 01:38:28,580 --> 01:38:30,882 Aku hanya perlu tahu bahwa item yang disentuh. 2239 01:38:30,882 --> 01:38:33,340 Jadi ini adalah jenis dilihat bahwa Anda turun sungai 2240 01:38:33,340 --> 01:38:35,960 dan Anda bisa berinteraksi dengan. 2241 01:38:35,960 --> 01:38:37,840 >> Aplikasi yang mengkonsumsi sungai, 2242 01:38:37,840 --> 01:38:39,298 ini adalah jenis cara ini bekerja. 2243 01:38:39,298 --> 01:38:42,570 DynamoDB klien meminta untuk mendorong data ke tabel. 2244 01:38:42,570 --> 01:38:44,750 Streaming menyebarkan pada apa yang kita sebut pecahan. 2245 01:38:44,750 --> 01:38:47,380 Pecahan yang ditingkatkan independen dari meja. 2246 01:38:47,380 --> 01:38:50,660 Mereka tidak berbaris benar untuk partisi dari meja Anda. 2247 01:38:50,660 --> 01:38:52,540 Dan alasan mengapa karena mereka berbaris 2248 01:38:52,540 --> 01:38:55,430 untuk kapasitas, saat ini kapasitas meja. 2249 01:38:55,430 --> 01:38:57,600 >> Mereka menyebarkan dalam mereka Kelompok skala auto sendiri, 2250 01:38:57,600 --> 01:39:00,800 dan mereka mulai berputar keluar tergantung berapa banyak menulis yang datang, 2251 01:39:00,800 --> 01:39:03,090 berapa banyak reads-- benar itu menulis. 2252 01:39:03,090 --> 01:39:05,820 Tidak ada reads-- tapi bagaimana banyak menulis datang di. 2253 01:39:05,820 --> 01:39:08,200 >> Dan kemudian di bagian belakang end, kita memiliki apa yang kita 2254 01:39:08,200 --> 01:39:11,390 memanggil KCL, atau Perpustakaan Client Kinesis. 2255 01:39:11,390 --> 01:39:19,190 Kinesis adalah aliran data teknologi pengolahan dari Amazon. 2256 01:39:19,190 --> 01:39:22,040 Dan sungai dibangun itu. 2257 01:39:22,040 --> 01:39:25,670 >> Jadi Anda menggunakan KCL diaktifkan aplikasi untuk membaca sungai. 2258 01:39:25,670 --> 01:39:28,752 Perpustakaan Klien Kinesis sebenarnya mengelola pekerja untuk Anda. 2259 01:39:28,752 --> 01:39:30,460 Dan itu juga melakukan beberapa hal yang menarik. 2260 01:39:30,460 --> 01:39:35,630 Ia akan membuat beberapa tabel up di tablespace DynamoDB Anda 2261 01:39:35,630 --> 01:39:38,410 untuk melacak item yang telah diproses. 2262 01:39:38,410 --> 01:39:41,190 Jadi cara ini jika jatuh kembali, jika itu jatuh di atas dan datang dan mendapat 2263 01:39:41,190 --> 01:39:45,570 kembali berdiri, dapat menentukan di mana adalah dalam pengolahan sungai. 2264 01:39:45,570 --> 01:39:48,360 >> Itu sangat penting ketika Anda sedang berbicara tentang replikasi. 2265 01:39:48,360 --> 01:39:50,350 Saya perlu tahu apa data diolah 2266 01:39:50,350 --> 01:39:52,810 dan data apa belum untuk diproses. 2267 01:39:52,810 --> 01:39:57,380 Jadi perpustakaan KCL untuk aliran akan memberikan banyak fungsi yang. 2268 01:39:57,380 --> 01:39:58,990 Itu mengurus semua rumah tangga. 2269 01:39:58,990 --> 01:40:01,140 Ini berdiri seorang pekerja untuk setiap pecahan. 2270 01:40:01,140 --> 01:40:04,620 Ini menciptakan meja administrasi untuk setiap pecahan, untuk setiap pekerja. 2271 01:40:04,620 --> 01:40:07,560 Dan seperti para pekerja api, mereka mempertahankan meja tersebut 2272 01:40:07,560 --> 01:40:10,510 sehingga Anda tahu catatan ini dibacakan dan diproses. 2273 01:40:10,510 --> 01:40:13,850 Dan kemudian dengan cara itu jika proses meninggal dan datang kembali online, 2274 01:40:13,850 --> 01:40:17,940 itu dapat melanjutkan di tempat itu lepas landas. 2275 01:40:17,940 --> 01:40:20,850 >> Jadi kita menggunakan ini untuk replikasi lintas wilayah. 2276 01:40:20,850 --> 01:40:24,680 Banyak pelanggan memiliki kebutuhan untuk memindahkan data atau bagian dari tabel data mereka 2277 01:40:24,680 --> 01:40:25,920 sekitar untuk daerah yang berbeda. 2278 01:40:25,920 --> 01:40:29,230 Ada sembilan daerah seluruh dunia. 2279 01:40:29,230 --> 01:40:32,100 Jadi mungkin ada saya need-- mungkin memiliki pengguna di Asia, pengguna 2280 01:40:32,100 --> 01:40:34,150 di Pantai Timur Amerika Serikat. 2281 01:40:34,150 --> 01:40:38,980 Mereka memiliki data yang berbeda yang perlu didistribusikan secara lokal. 2282 01:40:38,980 --> 01:40:42,510 Dan mungkin pengguna terbang dari Asia ke Amerika Serikat, 2283 01:40:42,510 --> 01:40:45,020 dan saya ingin meniru Data dengan dia. 2284 01:40:45,020 --> 01:40:49,340 Jadi, ketika ia mendapat turun dari pesawat, ia memiliki pengalaman yang baik menggunakan aplikasi mobile-nya. 2285 01:40:49,340 --> 01:40:52,360 >> Anda dapat menggunakan lintas wilayah perpustakaan replikasi untuk melakukan hal ini. 2286 01:40:52,360 --> 01:40:55,730 Pada dasarnya kita memiliki tersedia dua teknologi. 2287 01:40:55,730 --> 01:40:59,400 Satu adalah aplikasi konsol Anda bisa berdiri di atas EC2 contoh Anda sendiri. 2288 01:40:59,400 --> 01:41:01,240 Ini berjalan replikasi murni. 2289 01:41:01,240 --> 01:41:02,720 Dan kemudian kami memberi Anda perpustakaan. 2290 01:41:02,720 --> 01:41:06,070 Perpustakaan yang dapat digunakan untuk membangun aplikasi Anda sendiri jika Anda 2291 01:41:06,070 --> 01:41:10,740 ingin melakukan hal-hal gila dengan yang data-- filter, meniru hanya bagian dari itu, 2292 01:41:10,740 --> 01:41:14,120 memutar data, memindahkannya ke dalam tabel yang berbeda, seterusnya dan sebagainya. 2293 01:41:14,120 --> 01:41:18,700 2294 01:41:18,700 --> 01:41:20,520 Jadi itu semacam apa yang terlihat seperti. 2295 01:41:20,520 --> 01:41:23,690 >> DynamoDB Streaming dapat diproses oleh apa yang kita sebut Lambda. 2296 01:41:23,690 --> 01:41:27,394 Kami disebutkan sedikit tentang acara arsitektur aplikasi didorong. 2297 01:41:27,394 --> 01:41:28,810 Lambda adalah komponen kunci dari itu. 2298 01:41:28,810 --> 01:41:32,840 Lambda adalah kode yang kebakaran pada permintaan dalam menanggapi peristiwa tertentu. 2299 01:41:32,840 --> 01:41:36,020 Salah satu peristiwa bisa menjadi Rekor muncul di sungai. 2300 01:41:36,020 --> 01:41:39,100 Jika catatan muncul di sungai, kita akan memanggil fungsi Java ini. 2301 01:41:39,100 --> 01:41:44,980 Nah, ini adalah JavaScript, dan Lambda mendukung Node.js, Java, Python, 2302 01:41:44,980 --> 01:41:47,820 dan akan segera mendukung bahasa lain juga. 2303 01:41:47,820 --> 01:41:50,940 Dan cukup untuk mengatakan, itu kode murni. 2304 01:41:50,940 --> 01:41:53,610 menulis Di Jawa, Anda mendefinisikan kelas. 2305 01:41:53,610 --> 01:41:55,690 Anda mendorong JAR menjadi Lambda. 2306 01:41:55,690 --> 01:42:00,200 Dan kemudian Anda menentukan kelas untuk memanggil respon yang acara. 2307 01:42:00,200 --> 01:42:04,770 Dan kemudian infrastruktur Lambda balik yang akan menjalankan kode itu. 2308 01:42:04,770 --> 01:42:06,730 >> Kode yang dapat memproses catatan dari sungai. 2309 01:42:06,730 --> 01:42:08,230 Hal ini dapat melakukan apa saja yang diinginkannya dengan itu. 2310 01:42:08,230 --> 01:42:11,650 Dalam contoh ini, semua kami benar-benar lakukan adalah log atribut. 2311 01:42:11,650 --> 01:42:13,480 Tapi ini hanya kode. 2312 01:42:13,480 --> 01:42:15,260 Kode dapat melakukan apa-apa, kan? 2313 01:42:15,260 --> 01:42:16,600 >> Sehingga Anda dapat memutar data tersebut. 2314 01:42:16,600 --> 01:42:18,160 Anda dapat membuat tampilan derivatif. 2315 01:42:18,160 --> 01:42:21,160 Jika itu adalah struktur dokumen, Anda dapat meratakan struktur. 2316 01:42:21,160 --> 01:42:24,300 Anda dapat membuat indeks alternatif. 2317 01:42:24,300 --> 01:42:27,100 Segala macam hal yang Anda bisa lakukan dengan DynamoDB Streaming. 2318 01:42:27,100 --> 01:42:28,780 >> Dan benar-benar, itulah yang yang terlihat seperti. 2319 01:42:28,780 --> 01:42:29,940 Jadi Anda mendapatkan update tersebut datang. 2320 01:42:29,940 --> 01:42:31,190 Mereka datang dari string. 2321 01:42:31,190 --> 01:42:32,720 Mereka dibaca oleh fungsi Lambda. 2322 01:42:32,720 --> 01:42:37,480 Mereka berputar data dan mendorongnya di meja derivatif, 2323 01:42:37,480 --> 01:42:42,200 memberitahukan sistem eksternal perubahan, dan mendorong data ke ElastiCache. 2324 01:42:42,200 --> 01:42:45,900 >> Kami berbicara tentang bagaimana untuk menempatkan cache di depan database untuk penjualan yang 2325 01:42:45,900 --> 01:42:46,450 skenario. 2326 01:42:46,450 --> 01:42:50,049 Nah apa yang terjadi jika saya memperbarui deskripsi item? 2327 01:42:50,049 --> 01:42:52,340 Nah, jika saya memiliki Lambda fungsi berjalan di atas meja itu, 2328 01:42:52,340 --> 01:42:55,490 jika saya memperbarui deskripsi item, itu akan mengambil catatan dari sungai, 2329 01:42:55,490 --> 01:42:58,711 dan itu akan memperbarui ElastiCache Misalnya dengan data baru. 2330 01:42:58,711 --> 01:43:00,460 Jadi itulah banyak apa yang kita lakukan dengan Lambda. 2331 01:43:00,460 --> 01:43:02,619 Ini kode lem, konektor. 2332 01:43:02,619 --> 01:43:04,410 Dan itu benar-benar memberikan kemampuan untuk meluncurkan 2333 01:43:04,410 --> 01:43:07,930 dan untuk menjalankan aplikasi yang sangat kompleks tanpa dedicated server 2334 01:43:07,930 --> 01:43:10,371 infrastruktur, yang benar-benar keren. 2335 01:43:10,371 --> 01:43:13,100 >> Jadi mari kita kembali ke kami real-time arsitektur voting. 2336 01:43:13,100 --> 01:43:17,984 Ini adalah baru dan ditingkatkan dengan kami sungai dan KCL diaktifkan aplikasi. 2337 01:43:17,984 --> 01:43:20,150 Sama seperti sebelumnya, kita dapat menangani skala pemilu. 2338 01:43:20,150 --> 01:43:21,100 Kami suka ini. 2339 01:43:21,100 --> 01:43:24,770 Kami sedang melakukan keluar mengumpulkan pencar di beberapa ember. 2340 01:43:24,770 --> 01:43:26,780 Kami punya penguncian optimis terjadi. 2341 01:43:26,780 --> 01:43:30,192 Kita bisa menjaga pemilih kami mengubah suara mereka. 2342 01:43:30,192 --> 01:43:31,400 Mereka hanya dapat memilih hanya sekali. 2343 01:43:31,400 --> 01:43:32,880 Ini fantastis. 2344 01:43:32,880 --> 01:43:35,895 Toleransi kesalahan real-time, scalable agregasi sekarang. 2345 01:43:35,895 --> 01:43:38,270 Jika hal tersebut jatuh di atas, itu tahu di mana untuk me-restart sendiri 2346 01:43:38,270 --> 01:43:41,300 ketika datang kembali karena kita sedang menggunakan aplikasi KCL. 2347 01:43:41,300 --> 01:43:45,700 Dan kemudian kita juga bisa menggunakan Aplikasi KCL untuk mendorong data keluar 2348 01:43:45,700 --> 01:43:48,820 untuk pergeseran merah untuk lainnya analisis aplikasi, atau penggunaan 2349 01:43:48,820 --> 01:43:51,990 elastis MapReduce untuk menjalankan real-time streaming agregasi off 2350 01:43:51,990 --> 01:43:53,180 dari data tersebut. 2351 01:43:53,180 --> 01:43:55,480 >> Jadi ini adalah hal yang kita belum berbicara tentang banyak. 2352 01:43:55,480 --> 01:43:57,375 Tapi mereka tambahan teknologi yang datang 2353 01:43:57,375 --> 01:44:00,310 menanggung ketika Anda sedang mencari di jenis skenario. 2354 01:44:00,310 --> 01:44:03,160 >> Baiklah, jadi itu tentang analisis dengan DynamoDB Streaming. 2355 01:44:03,160 --> 01:44:05,340 Anda dapat mengumpulkan de-dupe data, melakukan segala macam 2356 01:44:05,340 --> 01:44:09,490 barang bagus, data agregat di memori, membuat meja tersebut derivatif. 2357 01:44:09,490 --> 01:44:13,110 Itu kasus penggunaan besar bahwa banyak pelanggan 2358 01:44:13,110 --> 01:44:16,950 terlibat dengan, mengambil bersarang Sifat dari dokumen-dokumen JSON 2359 01:44:16,950 --> 01:44:18,946 dan membuat indeks tambahan. 2360 01:44:18,946 --> 01:44:21,680 2361 01:44:21,680 --> 01:44:23,150 >> Kami di akhir. 2362 01:44:23,150 --> 01:44:26,689 Terima kasih untuk bantalan dengan saya. 2363 01:44:26,689 --> 01:44:28,480 Jadi mari kita bicara tentang referensi arsitektur. 2364 01:44:28,480 --> 01:44:33,440 DynamoDB duduk di tengah-tengah sehingga banyak infrastruktur AWS. 2365 01:44:33,440 --> 01:44:37,090 Pada dasarnya Anda dapat hook it sampai dengan apa pun yang Anda inginkan. 2366 01:44:37,090 --> 01:44:45,600 Aplikasi dibangun menggunakan Dynamo termasuk Lambda, ElastiCache, CloudSearch, 2367 01:44:45,600 --> 01:44:49,890 mendorong data keluar ke Elastic MapReduce, ekspor impor dari DynamoDB 2368 01:44:49,890 --> 01:44:52,370 ke S3, semua jenis alur kerja. 2369 01:44:52,370 --> 01:44:54,120 Tapi mungkin yang terbaik hal untuk dibicarakan, 2370 01:44:54,120 --> 01:44:56,119 dan ini adalah apa yang benar-benar menarik adalah ketika kita 2371 01:44:56,119 --> 01:44:58,350 berbicara tentang aplikasi event driven. 2372 01:44:58,350 --> 01:45:00,300 >> Ini adalah contoh dari proyek internal 2373 01:45:00,300 --> 01:45:04,850 bahwa kita memiliki mana kita benar-benar penerbitan untuk mengumpulkan hasil survei. 2374 01:45:04,850 --> 01:45:07,700 Jadi di link email yang kami mengirimkan, ada akan 2375 01:45:07,700 --> 01:45:11,350 menjadi klik link yang mengatakan sedikit di sini untuk menanggapi survei. 2376 01:45:11,350 --> 01:45:14,070 Dan ketika beberapa klik orang link tersebut, apa yang terjadi 2377 01:45:14,070 --> 01:45:18,020 adalah mereka pull down aman Bentuk survei HTML dari S3. 2378 01:45:18,020 --> 01:45:18,980 Ada tidak ada server. 2379 01:45:18,980 --> 01:45:20,600 Ini hanyalah sebuah objek S3. 2380 01:45:20,600 --> 01:45:22,770 >> Bentuk yang muncul, beban di browser. 2381 01:45:22,770 --> 01:45:24,240 Itu punya Backbone. 2382 01:45:24,240 --> 01:45:30,160 Itu punya kompleks JavaScript bahwa itu berjalan. 2383 01:45:30,160 --> 01:45:33,557 Jadi aplikasi yang sangat kaya berjalan di browser klien. 2384 01:45:33,557 --> 01:45:36,390 Mereka tidak tahu bahwa mereka tidak berinteraksi dengan server back end. 2385 01:45:36,390 --> 01:45:38,220 Pada titik ini, itu semua browser. 2386 01:45:38,220 --> 01:45:41,780 >> Mereka mempublikasikan hasil apa kita sebut Amazon API Gateway. 2387 01:45:41,780 --> 01:45:46,270 API Gateway hanyalah sebuah web API Anda dapat menentukan dan menghubungkan 2388 01:45:46,270 --> 01:45:47,760 untuk apa pun yang Anda inginkan. 2389 01:45:47,760 --> 01:45:50,990 Dalam kasus ini, kami terhubung ke fungsi Lambda. 2390 01:45:50,990 --> 01:45:54,797 >> Jadi operasi POST saya terjadi dengan tidak ada server. 2391 01:45:54,797 --> 01:45:56,380 Pada dasarnya bahwa API Gateway duduk di sana. 2392 01:45:56,380 --> 01:45:58,770 Biayanya apa-apa sampai orang mulai posting untuk itu, kan? 2393 01:45:58,770 --> 01:46:00,269 Fungsi Lambda hanya duduk di sana. 2394 01:46:00,269 --> 01:46:03,760 Dan biaya apa-apa sampai orang mulai memukul. 2395 01:46:03,760 --> 01:46:07,270 Sehingga Anda dapat melihat, sebagai volume meningkat, saat itulah tuduhan datang. 2396 01:46:07,270 --> 01:46:09,390 Aku tidak menjalankan server 7/24. 2397 01:46:09,390 --> 01:46:12,310 >> Jadi saya tarik bentuk turun dari ember, 2398 01:46:12,310 --> 01:46:15,719 dan saya posting melalui API Gateway ke dalam fungsi Lambda. 2399 01:46:15,719 --> 01:46:17,510 Dan kemudian Lambda Fungsi mengatakan, Anda tahu 2400 01:46:17,510 --> 01:46:20,600 apa, saya punya beberapa PIIs, beberapa informasi pribadi 2401 01:46:20,600 --> 01:46:21,480 di tanggapan ini. 2402 01:46:21,480 --> 01:46:23,020 Saya mendapat komentar yang datang dari pengguna. 2403 01:46:23,020 --> 01:46:24,230 Saya punya alamat email. 2404 01:46:24,230 --> 01:46:26,190 Aku punya username. 2405 01:46:26,190 --> 01:46:27,810 >> Biarkan saya membagi ini off. 2406 01:46:27,810 --> 01:46:30,280 Aku akan menghasilkan beberapa metadata dari catatan ini. 2407 01:46:30,280 --> 01:46:32,850 Dan aku akan mendorong metadata ke dalam DynamoDB. 2408 01:46:32,850 --> 01:46:36,059 Dan saya bisa mengenkripsi semua data dan dorong ke DynamoDB jika saya ingin. 2409 01:46:36,059 --> 01:46:38,600 Tapi itu lebih mudah bagi saya, dalam hal ini menggunakan kasus, untuk pergi ke depan sebuah katakanlah, 2410 01:46:38,600 --> 01:46:42,800 Aku akan mendorong data mentah menjadi S3 ember dienkripsi. 2411 01:46:42,800 --> 01:46:47,240 Jadi saya menggunakan dibangun di sisi server S3 enkripsi dan Manajemen Key Amazon 2412 01:46:47,240 --> 01:46:51,600 Layanan sehingga saya memiliki kunci yang dapat berputar pada interval reguler, 2413 01:46:51,600 --> 01:46:55,010 dan saya dapat melindungi data PII sebagai bagian dari keseluruhan alur kerja ini. 2414 01:46:55,010 --> 01:46:55,870 >> Jadi apa yang saya lakukan? 2415 01:46:55,870 --> 01:47:00,397 Saya baru saja dikerahkan seluruh aplikasi, dan saya tidak memiliki server yang. 2416 01:47:00,397 --> 01:47:02,980 Jadi apa acara aplikasi didorong arsitektur lakukan untuk Anda. 2417 01:47:02,980 --> 01:47:05,730 >> Sekarang jika Anda berpikir tentang kasus penggunaan untuk this-- 2418 01:47:05,730 --> 01:47:08,730 kami memiliki pelanggan lain yang saya bicarakan sekitar arsitektur ini sebenarnya yang 2419 01:47:08,730 --> 01:47:14,560 menjalankan kampanye fenomenal besar, yang melihat ini dan pergi, oh saya. 2420 01:47:14,560 --> 01:47:17,840 Karena sekarang, mereka bisa pada dasarnya mendorong di luar sana, 2421 01:47:17,840 --> 01:47:21,900 biarkan kampanye yang hanya duduk ada sampai meluncurkan, dan tidak 2422 01:47:21,900 --> 01:47:24,400 perlu khawatir ara tentang apa jenis infrastruktur 2423 01:47:24,400 --> 01:47:26,120 akan berada di sana untuk mendukungnya. 2424 01:47:26,120 --> 01:47:28,600 Dan kemudian secepat Kampanye yang dilakukan, 2425 01:47:28,600 --> 01:47:31,520 itu seperti infrastruktur hanya segera hilang 2426 01:47:31,520 --> 01:47:33,680 karena benar-benar ada infrastruktur. 2427 01:47:33,680 --> 01:47:35,660 Hanya saja kode yang duduk di Lambda. 2428 01:47:35,660 --> 01:47:38,560 Hanya saja data yang duduk di DynamoDB. 2429 01:47:38,560 --> 01:47:41,340 Ini adalah cara yang mengagumkan untuk membangun aplikasi. 2430 01:47:41,340 --> 01:47:43,970 >> AUDIENCE: Jadi, apakah itu lebih fana dari itu akan 2431 01:47:43,970 --> 01:47:45,740 jika disimpan pada sebuah server yang sebenarnya? 2432 01:47:45,740 --> 01:47:46,823 >> RICK Houlihan: Absolutely. 2433 01:47:46,823 --> 01:47:49,190 Karena itu contoh server harus menjadi 24/07. 2434 01:47:49,190 --> 01:47:51,954 Itu harus tersedia untuk seseorang untuk menanggapi. 2435 01:47:51,954 --> 01:47:52,620 Nah coba tebak? 2436 01:47:52,620 --> 01:47:55,410 S3 tersedia 24/7. 2437 01:47:55,410 --> 01:47:57,100 S3 selalu merespon. 2438 01:47:57,100 --> 01:47:59,320 Dan S3 adalah sangat, sangat baik di melayani sampai benda. 2439 01:47:59,320 --> 01:48:02,590 Benda-benda bisa file HTML, atau File JavaScript, atau apa pun yang Anda inginkan. 2440 01:48:02,590 --> 01:48:07,430 Anda dapat menjalankan aplikasi web yang sangat kaya dari S3 ember, dan orang-orang melakukan. 2441 01:48:07,430 --> 01:48:10,160 >> Dan itulah ide di sini adalah menjauh dari jalan 2442 01:48:10,160 --> 01:48:11,270 kita digunakan untuk berpikir tentang hal itu. 2443 01:48:11,270 --> 01:48:14,270 Kita semua digunakan untuk berpikir dalam hal server dan host. 2444 01:48:14,270 --> 01:48:16,580 Ini bukan tentang itu lagi. 2445 01:48:16,580 --> 01:48:19,310 Ini tentang infrastruktur sebagai kode. 2446 01:48:19,310 --> 01:48:22,470 Menyebarkan kode ke awan dan biarkan awan menjalankannya untuk Anda. 2447 01:48:22,470 --> 01:48:24,980 Dan itulah yang AWS coba lakukan. 2448 01:48:24,980 --> 01:48:29,690 >> AUDIENCE: Jadi kotak emas di tengah API Gateway tidak server seperti, 2449 01:48:29,690 --> 01:48:30,576 tetapi sebaliknya adalah hanya-- 2450 01:48:30,576 --> 01:48:32,850 >> RICK Houlihan: Anda dapat berpikir TI sebagai server fasad. 2451 01:48:32,850 --> 01:48:38,040 Semua itu adalah itu akan mengambil HTTP meminta dan peta ke proses lain. 2452 01:48:38,040 --> 01:48:39,192 Itu semua hal ini. 2453 01:48:39,192 --> 01:48:41,525 Dan dalam hal ini, kita pemetaan untuk fungsi Lambda. 2454 01:48:41,525 --> 01:48:44,119 2455 01:48:44,119 --> 01:48:45,410 Baiklah, jadi itu yang saya punya. 2456 01:48:45,410 --> 01:48:46,190 Terima kasih banyak. 2457 01:48:46,190 --> 01:48:46,800 Saya menghargainya. 2458 01:48:46,800 --> 01:48:48,100 Aku tahu kita ingin sedikit dari waktu ke waktu. 2459 01:48:48,100 --> 01:48:49,980 Dan mudah-mudahan kalian punya sedikit informasi 2460 01:48:49,980 --> 01:48:51,410 Anda dapat mengambil hari ini. 2461 01:48:51,410 --> 01:48:53,520 Dan saya minta maaf jika saya pergi atas beberapa kepala Anda, 2462 01:48:53,520 --> 01:48:56,697 tapi ada banyak yang baik dari pengetahuan dasar dasar 2463 01:48:56,697 --> 01:48:58,280 yang saya pikir sangat berharga bagi Anda. 2464 01:48:58,280 --> 01:48:59,825 Jadi terima kasih karena telah saya. 2465 01:48:59,825 --> 01:49:00,325 [TEPUK TANGAN] 2466 01:49:00,325 --> 01:49:02,619 AUDIENCE: [tidak terdengar] adalah ketika Anda katakan 2467 01:49:02,619 --> 01:49:05,160 Anda harus melalui hal dari awal sampai akhir 2468 01:49:05,160 --> 01:49:07,619 untuk mendapatkan nilai-nilai yang tepat atau nilai yang sama, 2469 01:49:07,619 --> 01:49:09,410 bagaimana akan nilai-nilai berubah jika [tidak terdengar]. 2470 01:49:09,410 --> 01:49:10,480 >> RICK Houlihan: Oh, idempoten? 2471 01:49:10,480 --> 01:49:11,800 Bagaimana nilai-nilai akan berubah? 2472 01:49:11,800 --> 01:49:15,180 Nah, karena jika saya tidak menjalankan semua jalan sampai akhir, 2473 01:49:15,180 --> 01:49:19,770 maka saya tidak tahu perubahan apa dibuat di mil terakhir. 2474 01:49:19,770 --> 01:49:22,144 Ini tidak akan menjadi Data yang sama seperti apa yang saya lihat. 2475 01:49:22,144 --> 01:49:24,560 AUDIENCE: Oh, jadi Anda hanya belum mendapatkan seluruh masukan. 2476 01:49:24,560 --> 01:49:24,770 RICK Houlihan: Benar. 2477 01:49:24,770 --> 01:49:26,895 Anda harus pergi dari awal sampai akhir, dan kemudian itu 2478 01:49:26,895 --> 01:49:29,280 akan menjadi negara yang konsisten. 2479 01:49:29,280 --> 01:49:31,520 Keren. 2480 01:49:31,520 --> 01:49:35,907 >> AUDIENCE: Jadi Anda menunjukkan kita DynamoDB dapat melakukan dokumen atau nilai kunci. 2481 01:49:35,907 --> 01:49:38,740 Dan kami menghabiskan banyak waktu pada nilai kunci dengan hash dan cara 2482 01:49:38,740 --> 01:49:40,005 untuk flip itu sekitar. 2483 01:49:40,005 --> 01:49:43,255 Ketika Anda melihat meja tersebut, adalah bahwa meninggalkan pendekatan dokumen? 2484 01:49:43,255 --> 01:49:44,600 >> RICK Houlihan: Saya tidak akan mengatakan meninggalkannya di belakang. 2485 01:49:44,600 --> 01:49:45,855 >> AUDIENCE: Mereka dipisahkan dari the-- 2486 01:49:45,855 --> 01:49:49,140 >> RICK Houlihan: Dengan dokumen Pendekatan, jenis dokumen DynamoDB 2487 01:49:49,140 --> 01:49:50,880 hanya berpikir sebagai atribut lain. 2488 01:49:50,880 --> 01:49:53,560 Ini atribut yang berisi struktur data hirarkis. 2489 01:49:53,560 --> 01:49:56,980 Dan kemudian di query, Anda dapat menggunakan properti 2490 01:49:56,980 --> 01:49:59,480 dari benda-benda menggunakan Object Notation. 2491 01:49:59,480 --> 01:50:03,562 Jadi saya dapat menyaring pada bersarang properti dari dokumen JSON. 2492 01:50:03,562 --> 01:50:05,520 AUDIENCE: Jadi setiap kali saya melakukan pendekatan dokumen, 2493 01:50:05,520 --> 01:50:07,906 Saya bisa semacam tiba di tabular-- yang 2494 01:50:07,906 --> 01:50:08,780 AUDIENCE: Absolutely. 2495 01:50:08,780 --> 01:50:09,800 AUDIENCE: --indexes dan hal yang Anda hanya berbicara tentang. 2496 01:50:09,800 --> 01:50:11,280 RICK Houlihan: Ya, indeks dan semua itu, 2497 01:50:11,280 --> 01:50:13,363 ketika Anda ingin indeks properti dari JSON, 2498 01:50:13,363 --> 01:50:18,230 cara bahwa kita harus melakukan itu adalah jika Anda menyisipkan objek JSON atau dokumen 2499 01:50:18,230 --> 01:50:20,780 ke Dynamo, Anda akan menggunakan aliran. 2500 01:50:20,780 --> 01:50:22,400 Streaming akan membaca input. 2501 01:50:22,400 --> 01:50:24,340 Anda akan mendapatkan bahwa JSON keberatan dan Anda akan mengatakan OK, 2502 01:50:24,340 --> 01:50:26,030 apa properti saya ingin indeks? 2503 01:50:26,030 --> 01:50:28,717 >> Anda membuat tabel turunan. 2504 01:50:28,717 --> 01:50:30,300 Nah, itu cara kerjanya sekarang. 2505 01:50:30,300 --> 01:50:32,650 Kami tidak mengizinkan Anda untuk indeks langsung properti-properti. 2506 01:50:32,650 --> 01:50:33,520 >> AUDIENCE: Tabularizing dokumen Anda. 2507 01:50:33,520 --> 01:50:36,230 >> RICK Houlihan: Tepat, perataan itu, tabularizing itu, persis. 2508 01:50:36,230 --> 01:50:37,415 Itulah apa yang Anda lakukan dengan itu. 2509 01:50:37,415 --> 01:50:37,860 >> AUDIENCE: Terima kasih. 2510 01:50:37,860 --> 01:50:39,609 >> RICK Houlihan: Yep, benar-benar, terima kasih. 2511 01:50:39,609 --> 01:50:42,240 AUDIENCE: Jadi itu semacam Mongo memenuhi Redis classifers. 2512 01:50:42,240 --> 01:50:43,990 >> RICK Houlihan: Ya, itu banyak seperti itu. 2513 01:50:43,990 --> 01:50:45,940 Itu penjelasan yang baik untuk itu. 2514 01:50:45,940 --> 01:50:47,490 Keren. 2515 01:50:47,490 --> 01:50:49,102