[Bermain muzik] RICK Houlihan: Baiklah. Hai semua. Nama saya Rick Houlihan. Saya adalah seorang ibu kanan penyelesaian arkitek di AWS. Saya memberi tumpuan kepada NoSQL dan Teknologi DynamoDB. Saya di sini hari ini untuk bercakap dengan anda sedikit tentang mereka. 

Latar belakang saya adalah terutamanya dalam lapisan data. Saya menghabiskan separuh pembangunan saya kerjaya menulis pangkalan data, akses data, penyelesaian untuk pelbagai aplikasi. Saya telah berada dalam virtualisasi Cloud selama kira-kira 20 tahun. Jadi sebelum Awan adalah Cloud, kita digunakan untuk memanggil ia pengkomputeran utiliti. Dan idea itu, ia seperti PG & E, anda membayar untuk apa yang anda gunakan. Hari ini kita panggil awan. 

Tetapi sejak beberapa tahun, saya telah bekerja untuk beberapa syarikat anda mungkin tidak pernah mendengar tentang. Tetapi saya telah menyusun satu senarai teknikal pencapaian, saya rasa anda akan katakan. Saya mempunyai lapan paten dalam sistem Cloud virtualisasi, reka bentuk mikropemproses, pemprosesan acara yang kompleks, dan kawasan-kawasan lain juga. 

Jadi hari ini, saya memberi tumpuan kebanyakannya pada NoSQL teknologi dan generasi akan datang pangkalan data. Dan itu secara umumnya apa yang saya akan untuk berada di sini bercakap dengan anda hari ini mengenai. Jadi apa yang anda boleh mengharapkan dari sesi ini, kita akan pergi melalui ringkas sejarah pemprosesan data. Ia sentiasa membantu untuk memahami di mana kita datang dari dan mengapa kita di mana kita berada. Dan kita akan bercakap sedikit sedikit tentang teknologi NoSQL dari sudut asas. 

Kami akan masuk ke dalam beberapa mengenai dalaman DynamoDB. DynamoDB adalah AWS ini tiada rasa. Ia terurus sepenuhnya dan penyelesaian NoSQL menjadi tuan rumah. Dan kita akan bercakap sedikit tentang jadual struktur, API, jenis data, indeks, dan beberapa dalaman itu teknologi DynamoDB. Kami akan masuk ke dalam beberapa reka bentuk corak dan amalan terbaik. Kami akan bercakap tentang bagaimana anda menggunakan teknologi ini untuk beberapa aplikasi hari ini. Dan kemudian kita akan bercakap sedikit mengenai evolusi atau kemunculan paradigma baru dalam pengaturcaraan dipanggil aplikasi acara yang didorong oleh dan bagaimana DynamoDB bermain dalam itu juga. Dan kita akan meninggalkan anda sedikit perbincangan kerangka rujukan supaya kita boleh bercakap tentang beberapa cara-cara yang boleh anda gunakan DynamoDB. 

Jadi pertama off-- ini adalah soalan yang Saya mendengar banyak adalah, apa yang sistem database. Ramai orang berfikir bahawa mereka tahu apa pangkalan data adalah. Jika anda Google, anda akan melihat ini. Ia adalah satu set yang berstruktur data yang disimpan dalam komputer, terutama yang boleh diakses dalam pelbagai cara. Saya rasa itulah yang baik definisi pangkalan data moden. Tetapi saya tidak suka, kerana ia menunjukkan beberapa perkara. Ia membayangkan struktur. Dan ia membayangkan bahawa ia pada komputer. Dan pangkalan data tidak sentiasa wujud di komputer. Pangkalan data benar-benar wujud dalam hati. 

Jadi definisi yang lebih baik daripada pangkalan data adalah sesuatu seperti ini. Pangkalan data yang tersusun mekanisme untuk menyimpan, mengurus, dan mendapatkan semula maklumat. Ini dari About.com. Jadi saya suka ini kerana ia benar-benar rundingan mengenai pangkalan data menjadi sebuah gedung, repositori maklumat, tidak semestinya sesuatu yang duduk di atas komputer. Dan sepanjang sejarah, kita tidak sentiasa mempunyai komputer. 

Sekarang, jika saya meminta purata hari ini pemaju apa yang pangkalan data, itulah jawapan yang saya dapat. Tempat saya boleh melekat barangan. Betul? Dan ia adalah benar. Tetapi ia adalah malang. Kerana pangkalan data adalah benar-benar asas aplikasi moden. Ia adalah asas setiap permohonan. Dan bagaimana anda membina yang pangkalan data, bagaimana anda menyusun data yang akan menentukan bagaimana yang permohonan melakukan seperti yang anda skala. 

Jadi banyak kerja saya hari ini berurusan dengan apa yang berlaku apabila pemaju mengambil pendekatan ini dan berurusan dengan selepas itu permohonan yang kini meniti di luar asal niat dan penderitaan dari reka bentuk yang tidak baik. Jadi diharapkan apabila anda berjalan kaki hari ini, anda akan mempunyai beberapa alat dalam tali pinggang anda yang akan membuat anda daripada membuat mereka kesilapan yang sama. Baiklah. Jadi mari kita bercakap tentang sedikit garis masa teknologi pangkalan data. Saya rasa saya membaca artikel tidak lama dahulu dan ia berkata sesuatu di lines-- yang ia adalah satu kenyataan yang puitis. Ia berkata sejarah data pemprosesan adalah penuh dengan tera air tinggi kelimpahan data. OKEY. Sekarang, saya rasa itu adalah jenis yang benar. Tetapi saya benar-benar melihat adalah sebagai sejarah sebenarnya penuh dengan watermark tinggi tekanan data. Oleh kerana kadar data pemakanan tidak pernah terbenam. Ia hanya naik. 

Dan inovasi berlaku apabila kita lihat tekanan data, yang adalah jumlah data yang kini datang ke dalam sistem. Dan ia tidak boleh diproses cekap sama ada dalam masa atau kos. Dan itulah apabila kita mula untuk melihat tekanan data. 

Oleh itu, apabila kita melihat pangkalan data pertama, ini adalah salah satu yang adalah di antara telinga kita. Kita semua dilahirkan dengannya. Ia adalah pangkalan data yang baik. Ia mempunyai ketersediaan yang tinggi. Ia sentiasa. Anda sentiasa boleh mendapatkannya. 

Tetapi ia adalah pengguna tunggal. Saya tidak boleh berkongsi pandangan saya dengan anda. Anda tidak boleh mendapatkan fikiran saya apabila anda mahu mereka. Dan abilitiy mereka tidak begitu baik. Kita lupa sesuatu. Setiap sekarang dan kemudian, salah seorang dari kami daun dan bergerak ke kewujudan lain dan kami kehilangan segala-galanya yang di dalam pangkalan data itu. Jadi itu bukan semua yang baik. 

Dan ini berjalan dengan baik dari masa ke masa apabila kita kembali di hari apabila semua yang kita benar-benar perlu tahu adalah di mana kita akan pergi esok atau di mana kami mengumpul makanan terbaik. Tetapi seperti yang kita mula berkembang sebagai tamadun dan kerajaan mula untuk datang ke dalam diri, dan perniagaan mula berkembang, kami mula menyedari bahawa kita memerlukan lebih sedikit daripada apa yang kita boleh dimasukkan ke dalam kepala kita. Semua betul? 

Kami memerlukan sistem rekod. Kami memerlukan tempat untuk menyimpan data dapat. Oleh itu, kita mula dokumen bertulis, mewujudkan perpustakaan dan arkib. Kami mula membangunkan sistem perakaunan lejar. Dan bahawa sistem lejar pengiraan berlari dunia untuk beberapa abad, dan mungkin juga beribu tahun sebagai kita jenis berkembang ke titik di mana beban data melepasi keupayaan sistem tersebut dapat membendungnya. 

Dan ini sebenarnya berlaku pada 1880-an. Betul? Dalam tahun 1880 Banci Amerika Syarikat. Ini adalah benar-benar di mana perubahan menunjukkan pemprosesan data moden. Ini adalah titik di mana jumlah data yang sedang dikumpul oleh Kerajaan AS sampai ke titik di mana ia mengambil masa lapan tahun untuk diproses. 

Kini, lapan years-- sebagai anda tahu, banci berjalan setiap 10 years-- jadi ia cukup jelas bahawa pada masa kita mendapat banci tahun 1890, jumlah data yang akan diproses oleh kerajaan adalah akan melebihi 10 tahun bahawa ia akan mengambil masa untuk melancarkan banci baru. Ini adalah masalah. 

Jadi lelaki yang bernama Herman Hollerith datang bersama-sama dan dia mencipta unit rekod punch kad, pembaca kad perakam waktu, kad perakam waktu tabulator, dan pengumpulan mekanisme untuk teknologi ini. Dan syarikat itu bahawa dia terbentuk pada masa, bersama-sama dengan beberapa orang lain, sebenarnya menjadi salah satu daripada rukun yang syarikat kecil yang kita tahu hari ini menggesa IBM. 

Jadi IBM asalnya adalah dalam perniagaan pangkalan data. Dan yang benar-benar apa yang mereka lakukan. Mereka melakukan pemprosesan data. 

Sebagaimana yang percambahan punch kad, satu mekanisme bijak untuk dapat memanfaatkan yang teknologi untuk membuat tinjauan terhadap set hasil disusun. Anda boleh lihat di dalam gambar ini di sana kami mempunyai little-- yang ia sedikit small-- tetapi anda boleh melihat mekanisme mekanikal sangat bijak di mana kita mempunyai dek kad perakam waktu. Dan pengambilan seseorang itu pemutar skru kecil dan berpegang teguh melalui slot dan mengangkatnya ke atas untuk mendapatkan perlawanan itu, bahawa keputusan disusun ditetapkan. 

Ini adalah pengumpulan yang. Kami melakukan ini sepanjang masa hari ini dalam komputer, di mana anda melakukannya dalam pangkalan data. Kami pernah melakukannya secara manual, bukan? Orang meletakkan perkara-perkara ini bersama-sama. Dan ia adalah percambahan kad-kad punch menjadi apa yang kita dipanggil data gendang dan gulungan data, pita kertas. 

Industri pemprosesan data mengambil pengajaran dari piano pemain. Pemain piano kembali awal abad ke- digunakan untuk menggunakan gulungan kertas dengan slot di beritahu yang kunci untuk bermain. Jadi teknologi yang telah disesuaikan akhirnya untuk menyimpan data digital, kerana mereka boleh meletakkan data yang ke mereka gulungan pita kertas. 

Kini, hasilnya, data telah actually-- bagaimana anda mengakses data ini secara terus bergantung kepada bagaimana anda disimpannya. Jadi, jika saya meletakkan data pada pita, Saya terpaksa mendapatkan data-data yang linear. Saya terpaksa menggulung keseluruhan pita untuk mengakses semua data. Jika saya meletakkan data dalam punch kad, saya boleh mengaksesnya dalam sedikit lebih rawak fesyen, mungkin tidak dengan cepat. 

Tetapi terdapat batasan dalam bagaimana kita akses kepada data berdasarkan berapa disimpan. Dan sebagainya ini adalah masalah yang masuk ke dalam 50-an. Sekali lagi, kita boleh mula melihat bahawa seperti yang kita membangunkan teknologi baru untuk memproses data, kanan, ia membuka pintu untuk penyelesaian baru, bagi program-program baru, baru permohonan bagi data tersebut. Dan benar-benar, tadbir urus mungkin menjadi sebab mengapa kita telah membangunkan beberapa sistem ini. Tetapi perniagaan cepat menjadi pemandu di belakang evolusi pangkalan data yang moden dan sistem fail moden. 

Jadi perkara yang seterusnya yang datang adalah dalam 50-an adalah sistem fail dan pembangunan Penyimpanan rawak. Ini adalah cantik. Sekarang, semua tiba-tiba, kita boleh meletakkan kami fail di mana-mana ini pemacu keras dan kita boleh mengakses data ini secara rawak. Kita boleh menghuraikan bahawa maklumat daripada fail. Dan kita menyelesaikan semua dunia ini masalah dengan pemprosesan data. 

Dan itu berlangsung kira-kira 20 atau 30 tahun sehingga evolusi pangkalan data hubungan, yang adalah apabila dunia memutuskan kita kini perlu mempunyai repositori yang menewaskan yang terkapar data merentasi fail sistem yang kami telah dibina. Betul? Terlalu banyak data diedarkan terlalu banyak tempat, de-duplikasi data, dan kos penyimpanan adalah sangat besar. 

Pada 70-an, sumber yang paling mahal bahawa komputer mempunyai adalah simpanan. Pemproses adalah dilihat sebagai kos tetap. Apabila saya membeli kotak, CPU melakukan beberapa pekerjaan. Ia akan dapat berputar sama ada ia sebenarnya bekerja atau tidak. Itu benar-benar kos tenggelam. 

Tetapi apa kos saya sebagai perniagaan adalah penyimpanan. Jika saya perlu membeli lebih cakera seterusnya bulan, itu adalah satu kos sebenar yang saya bayar. Dan simpanan yang mahal. 

Sekarang kita melihat ke hadapan 40 tahun dan kami mempunyai masalah yang berbeza. Pengiraan ini sekarang adalah sumber yang paling mahal. Penyimpanan adalah murah. Maksud saya, kita boleh pergi mana-mana pada awan dan kita boleh mencari simpanan murah. Tetapi apa yang saya tidak dapat mencari adalah pengiraan murah. 

Jadi evolusi hari ini teknologi, teknologi pangkalan data, adalah benar-benar tertumpu kepada pangkalan data yang diedarkan yang tidak mengalami jenis yang sama skala batasan pangkalan data hubungan. Kami akan bercakap sedikit tentang apa yang benar-benar bermakna. 

Tetapi salah satu daripada sebab-sebab dan pemandu di belakang kita this-- bercakap tentang tekanan data. Tekanan Data adalah sesuatu yang mendorong inovasi. Dan jika anda melihat lebih lima tahun yang lalu, ini adalah carta dari apa data beban seluruh perusahaan umum kelihatan seperti dalam tempoh lima tahun yang lalu. 

Dan peraturan am ibu jari days-- ini jika anda pergi Google-- adalah 90% daripada data yang kami menyimpan hari ini, dan ia adalah dihasilkan dalam tempoh dua tahun yang lalu. OKEY. Sekarang, ini bukan satu trend yang yang baru. Ini adalah satu trend yang sudah keluar selama 100 tahun. Sejak Herman Hollerith membangunkan kad perakam waktu itu, kami telah membina repositori data dan mengumpul data pada kadar yang luar biasa. 

Jadi lebih 100 tahun yang lalu, yang kami telah lihat trend ini. Itu tidak akan berubah. Melangkah ke hadapan, kita akan melihat ini, jika tidak satu trend yang dipercepatkan. Dan anda boleh melihat apa yang kelihatan seperti. 

Jika perniagaan pada tahun 2010 mempunyai satu terabyte data di bawah pengurusan, hari ini yang bermakna mereka menguruskan 6.5 petabyte data. Itulah 6,500 kali lebih banyak data. Dan saya tahu ini. Saya bekerja dengan perniagaan ini setiap hari. Lima tahun yang lalu, saya akan berbincang dengan syarikat-syarikat yang akan bercakap kepada saya tentang apa yang sakit ia adalah untuk menguruskan terabytes data. Dan mereka akan bercakap kepada saya tentang bagaimana kita melihat bahawa ini mungkin akan menjadi petabyte atau dua dalam beberapa tahun. 

Syarikat-syarikat ini sama hari ini saya bertemu dengan, dan mereka bercakap dengan saya tentang masalah yang ada mempunyai urusan berpuluh-puluh, 20 petabyte data. Jadi letupan yang data dalam industri memandu yang besar keperluan untuk penyelesaian yang lebih baik. Dan pangkalan data hubungan adalah tidak hidup sehingga permintaan. 

Dan jadi tidak linear korelasi antara tekanan data dan inovasi teknikal. Sejarah telah menunjukkan kepada kita ini, yang dari semasa ke semasa, apabila jumlah data yang perlu diproses melebihi kapasiti sistem untuk memproses dalam masa yang munasabah atau pada kos yang munasabah, teknologi kemudian baru yang dicipta untuk menyelesaikan masalah tersebut. Mereka teknologi baru, seterusnya, membuka pintu kepada masalah lain, yang sedang mengumpul lebih banyak data. 

Sekarang, kita tidak akan menghentikan ini. Betul? Kami tidak akan berhenti ini. Mengapa? Kerana anda tidak boleh tahu segala-galanya ada tahu di alam semesta. Dan selagi kita telah hidup, sepanjang sejarah manusia, kami sentiasa terdorong untuk mengetahui lebih lanjut. 

Oleh itu, ia seolah-olah seperti setiap inci kita bergerak ke jalan penemuan saintifik, kita mendarabkan jumlah data yang kita perlu memproses pesat seperti yang kita mendedahkan lebih dan lebih dan lebih mengenai mekanisme dalaman kehidupan, tentang bagaimana alam semesta berfungsi, kira-kira memandu penemuan saintifik, dan ciptaan yang yang kita lakukan hari ini. Jumlah data hanya terus meningkat. Jadi dapat menangani masalah ini adalah sangat besar. 

Jadi salah satu daripada perkara-perkara kami melihat seolah mengapa NoSQL? Bagaimanakah NoSQL menyelesaikan masalah ini? Nah, pangkalan data hubungan, Bahasa Pertanyaan Berstruktur, SQL-- itu benar-benar yang membina daripada hubungan database-- perkara-perkara ini dioptimumkan untuk penyimpanan. 

Kembali dalam 70-an, sekali lagi, cakera adalah mahal. Menjalankan peruntukan penyimpanan dalam syarikat adalah tidak berkesudahan. Saya tahu. Saya tinggal itu. Saya menulis pemandu simpanan untuk yang syarikat SuperServer enterprised kembali dalam tahun 90-an. Dan garis bawah adalah urat lain pelbagai penyimpanan hanya sesuatu yang berlaku setiap hari dalam perusahaan. Dan ia tidak pernah berhenti. Penyimpanan ketumpatan yang lebih tinggi, permintaan untuk penyimpanan kepadatan tinggi, dan untuk simpanan yang lebih cekap devices-- ia tidak pernah berhenti. 

Dan NoSQL adalah teknologi yang hebat kerana ia menormalkan data. Ia de-bertindih dengan data. Ia meletakkan data dalam struktur yang adalah agnostik kepada setiap corak akses. Pelbagai aplikasi boleh memukul yang Pangkalan data SQL, lari ad hoc pertanyaan, dan mendapatkan data dalam bentuk yang mereka perlu memproses untuk beban kerja mereka. Yang berbunyi hebat. Tetapi garis bawah adalah dengan mana-mana sistem, jika ia agnostik untuk segala-galanya, ia dioptimumkan untuk apa-apa. OKEY? 

Dan itulah apa yang kita dapat dengan pangkalan data hubungan. Ia dioptimumkan untuk penyimpanan. Ia adalah normal. Ia adalah hubungan. Ia menyokong ad hoc pertanyaan. Dan ia dan ia skala menegak. 

Jika saya perlu mendapatkan pangkalan data SQL yang lebih besar atau pangkalan data SQL yang lebih kuat, Saya pergi membeli bahagian yang lebih besar daripada besi. OKEY? Saya telah bekerja dengan banyak pelanggan yang telah melalui peningkatan utama dalam infrastruktur SQL mereka hanya untuk mengetahui enam bulan kemudian, mereka memukul dinding lagi. Dan jawapan dari Oracle atau MSSQL atau orang lain adalah mendapatkan kotak yang lebih besar. Well lambat laun, anda tidak boleh membeli kotak yang lebih besar, dan itulah masalah sebenar. Kita perlu untuk benar-benar mengubah keadaan. Jadi di mana ini berfungsi? Ia berfungsi dengan baik untuk Talian analisis, beban kerja OLAP-jenis. Dan itu benar-benar di mana SQL dimiliki. Kini, ia digunakan hari ini di banyak talian transaksi pemprosesan-jenis aplikasi. Dan ia berfungsi dengan baik di beberapa tahap penggunaan, tetapi ia hanya tidak skala cara yang NoSQL tidak. Dan kita akan bercakap sedikit sedikit tentang mengapa yang. 

Sekarang, NoSQL, di sisi lain, adalah lebih dioptimumkan untuk pengiraan. OKEY? Ia tidak agnostik untuk corak akses. Adakah apa yang kita panggil de-normal struktur atau struktur hierarki. Data dalam pangkalan data hubungan adalah menyertai bersama-sama dari berbilang jadual untuk menghasilkan pemandangan yang anda perlukan. Data dalam pangkalan data NoSQL disimpan di dalam dokumen yang mengandungi struktur hierarki. Semua data yang biasanya akan menjadi bergabung bersama untuk menghasilkan pandangan yang disimpan dalam satu dokumen. Dan kita akan bercakap sedikit tentang bagaimana yang bekerja dalam beberapa carta. 

Tetapi idea di sini adalah bahawa anda menyimpan data anda kerana ini pandangan instantiated. OKEY? Anda skala mendatar. Betul? Jika saya perlu meningkatkan saiz kelompok NoSQL saya, Saya tidak perlu untuk mendapatkan kotak yang lebih besar. Saya mendapatkan kotak lain. Dan saya kelompok mereka bersama-sama, dan saya boleh Shard data tersebut. Kami akan bercakap sedikit tentang apa sharding, untuk menjadi dapat mengikut skala pangkalan data yang merentasi pelbagai peranti fizikal dan menghapuskan halangan yang memerlukan saya untuk skala menegak. 

Oleh itu, ia benar-benar dibina untuk online pemprosesan urus niaga dan skala. Ada perbezaan yang besar di sini antara laporan, bukan? Melaporkan, saya tidak tahu soalan saya akan bertanya. Betul? Reporting-- jika seseorang dari jabatan pemasaran saya mahu just-- berapa ramai daripada pelanggan saya mempunyai ciri-ciri tertentu yang yang dibeli di day-- ini saya tidak tahu apa pertanyaan mereka akan bertanya. Jadi saya perlu menjadi agnostik. 

Sekarang, dalam talian yang permohonan transaksi, Saya tahu apa soalan saya bertanya. Saya membina permohonan untuk aliran kerja yang sangat khusus. OKEY? Jadi, jika saya mengoptimumkan data menyimpan untuk menyokong aliran kerja itu, ia akan menjadi lebih cepat. Dan itulah sebabnya NoSQL boleh benar-benar mempercepatkan penghantaran dari orang-orang jenis perkhidmatan. Baiklah. 

Jadi, kita akan masuk ke dalam sedikit teori di sini. Dan di antara kamu, mata anda mungkin mengadakan semula sedikit. Tetapi saya akan cuba untuk memastikan ia tahap setinggi yang saya boleh. Jadi, jika anda berada dalam projek pengurusan, ada konstruk yang dikenali sebagai segi tiga kekangan. OKEY. Segi tiga kekangan telunjuk anda tidak boleh mempunyai segala-galanya sepanjang masa. Tidak boleh mempunyai pai anda dan makan juga. Jadi dalam pengurusan projek, yang segi tiga kekangan ialah anda boleh mempunyai ia murah, anda boleh mempunyai ia cepat, atau anda boleh mempunyai ia baik. Pilih dua. Kerana anda tidak boleh mempunyai semua tiga. Betul? OKEY. 

Jadi, anda mendengar tentang ini banyak. Ia adalah satu kekangan tiga segi tiga kekangan tiga atau segi tiga besi adalah oftentimes-- apabila anda bercakap kepada pengurus projek, mereka akan bercakap tentang perkara ini. Sekarang, pangkalan data yang mempunyai segitiga besi mereka sendiri. Dan segi tiga besi data adalah apa yang kita panggil teorem CAP. OKEY? 

CAP teorem telunjuk bagaimana pangkalan data yang beroperasi di bawah keadaan yang sangat khusus. Dan kita akan bercakap tentang apa keadaan yang. Tetapi tiga titik segi tiga, boleh dikatakan, adalah C, konsisten. OKEY? Jadi dalam CAP, konsisten bermakna semua pelanggan yang boleh mengakses pangkalan data akan sentiasa mempunyai sangat pandangan konsisten data. Tiada siapa yang akan kita lihat dua perkara yang berbeza. OKEY? Jika saya melihat pangkalan data, Saya melihat pandangan yang sama sebagai rakan saya yang melihat pangkalan data yang sama. Itulah konsisten. 

Ketersediaan bermakna jika pangkalan data dalam talian, jika ia dapat dicapai, bahawa semua pelanggan akan sentiasa dapat membaca dan menulis. OKEY? Jadi setiap pelanggan yang boleh membaca pangkalan data akan sentiasa dapat dibaca data dan menulis data. Dan jika itu berlaku, ia adalah satu sistem yang ada. 

Dan yang ketiga adalah apa yang kita panggil toleransi partition. OKEY? Cara toleransi Partition bahawa sistem yang berfungsi dengan baik walaupun rangkaian fizikal partition antara nod. OKEY? Jadi nod dalam kelompok tidak boleh bercakap antara satu sama lain, apa yang berlaku? Baiklah. 

Pangkalan data supaya hubungan choose-- anda boleh mengambil dua ini. OKEY. Pangkalan data supaya hubungan pilih untuk menjadi konsisten dan boleh didapati. Jika partition yang berlaku di antara yang DataNodes di kedai data, pangkalan data kemalangan. Betul? Ia hanya terbenam. OKEY. 

Dan ini adalah mengapa mereka mempunyai berkembang dengan kotak yang lebih besar. Betul? Kerana ada no-- biasanya, kelompok pangkalan data, tidak ada sangat ramai di antara mereka yang beroperasi dengan cara itu. Tetapi kebanyakan pangkalan data skala menegak dalam kotak tunggal. Kerana mereka perlu konsisten dan boleh didapati. Jika partition adalah untuk disuntik, maka anda perlu membuat pilihan. Anda perlu membuat pilihan di antara yang konsisten dan boleh didapati. 

Dan itulah yang pangkalan data NoSQL lakukan. Baiklah. Jadi pangkalan data NoSQL, ia datang dalam dua perisa. Kami ada-- dengan baik, ia datang dalam pelbagai perisa, tetapi ia datang dengan dua asas characteristics-- apa kita panggil pangkalan data CP, atau toleransi yang konsisten dan partition sistem. Lelaki-lelaki ini membuat pilihan yang apabila nod kehilangan hubungan dengan satu sama lain, kita tidak akan membenarkan orang untuk menulis lagi. OKEY? 

Sehingga partition yang dikeluarkan, akses tulis disekat. Ini bermakna mereka tidak boleh didapati. Mereka konsisten. Apabila kita melihat bahawa partition menyuntik sendiri, kami kini konsisten, kerana kita tidak akan untuk membenarkan perubahan data pada dua belah partition secara bebas satu sama lain. Kita perlu membina semula komunikasi sebelum apa-apa kemas kini untuk data yang dibenarkan. OKEY? 

Rasa yang akan datang akan menjadi satu sistem AP, atau yang ada dan dibahagikan sistem toleransi. Lelaki-lelaki ini tidak peduli. Betul? Mana-mana nod yang mendapat menulis, kami akan mengambilnya. Jadi, saya mereplikasi data saya di beberapa nod. Ini nod mendapatkan pelanggan, pelanggan datang dalam, berkata, saya akan menulis beberapa data. Node berkata, tidak ada masalah. Nod seterusnya beliau mendapat penulisan dalam rekod yang sama, dia akan berkata tidak ada masalah. Di suatu tempat kembali pada akhir belakang, data yang akan meniru. Dan kemudian seseorang akan sedar, uh-oh, sistem mereka akan sedar, uh-oh, ada menjadi kemas kini untuk kedua-dua pihak. Apa yang kita lakukan? Dan apa yang mereka lakukan itu adalah mereka melakukan sesuatu yang membolehkan mereka untuk menyelesaikan bahawa kerajaan data. Dan kita akan bercakap tentang bahawa dalam carta seterusnya. 

Perkara untuk menunjukkan di sini. Dan saya tidak akan terlalu banyak ke dalam ini, kerana ini masuk ke dalam teori data dalam. Tetapi ada transaksi yang rangka kerja yang berjalan dalam sistem hubungan yang membolehkan saya untuk selamat membuat kemas kini kepada beberapa entiti di dalam pangkalan data. Dan orang-orang kemas kini akan berlaku semua sekali gus atau tidak sama sekali. Dan ini dipanggil transaksi ACID. OKEY? 

ACID memberikan kita atomicity, konsisten, pengasingan, dan ketahanan. OKEY? Ini bermakna atom, transaksi, semua kemas kini saya sama ada berlaku atau mereka tidak. Ketekalan bermakna pangkalan data akan sentiasa dibawa masuk ke dalam yang konsisten negeri selepas kemas kini. Saya tidak akan meninggalkan pangkalan data dalam keadaan buruk selepas menggunakan kemas kini. OKEY? 

Jadi ia sedikit berbeza daripada CAP konsisten. CAP konsisten bermakna semua saya pelanggan sentiasa boleh melihat data. Konsisten ACID bermakna apabila transaksi dilakukan, data yang baik. Hubungan saya semua baik. Saya tidak akan memadamkan berturut-turut ibu bapa dan meninggalkan sekumpulan anak-anak yatim di beberapa meja lain. Ia tidak boleh berlaku jika saya konsisten dalam urus niaga asid. 

Pengasingan bermaksud bahawa transaksi akan sentiasa berlaku satu demi satu. Hasil akhir data akan menjadi negeri yang sama seolah-olah mereka urus niaga yang dikeluarkan serentak telah dilaksanakan secara bersiri. Jadi ia keserentakan kawalan dalam pangkalan data. Jadi, pada asasnya, saya tidak dapat kenaikan yang nilai yang sama dua kali dengan dua operasi. 

Tetapi jika saya katakan tambah 1 dengan nilai ini, dan dua transaksi datang dalam dan cuba untuk melakukannya, seseorang yang akan ke sana pertama dan yang lain akan ke sana selepas. Jadi pada akhirnya, saya menambah dua. Anda lihat apa yang saya maksudkan? OKEY. 

Ketahanan adalah agak mudah. Apabila transaksi diakui, ia akan berada di sana walaupun jika sistem crash. Apabila sistem yang pulih, yang transaksi yang telah dilakukan sebenarnya akan berada di sana. Jadi itu jaminan transaksi ACID. Mereka ialah jaminan cukup baik ada ke atas pangkalan data, tetapi mereka datang pada kos itu. Betul? 

Kerana masalah ini dengan rangka kerja ini adalah jika ada partition dalam data set, saya perlu membuat keputusan. Saya akan perlu membenarkan kemas kini di satu pihak atau yang lain. Dan jika itu berlaku, maka saya tidak lagi akan dapat mengekalkan ciri-ciri tersebut. Mereka tidak akan konsisten. Mereka tidak akan diasingkan. Ini adalah di mana ia rosak untuk pangkalan data hubungan. Ini adalah sebab hubungan yang pangkalan data skala menegak. 

Sebaliknya, kita mempunyai apa yang dipanggil teknologi BASE. Inilah Pangkalan data NoSQL anda. Baiklah. Jadi kita mempunyai CP kami, pangkalan data AP. Dan ini adalah apa yang anda panggil pada dasarnya ada, keadaan lembut, akhirnya konsisten. OKEY? 

Pada dasarnya ada, kerana mereka partition toleran. Mereka akan sentiasa di sana, walaupun ada partition rangkaian antara nod. Jika saya boleh bercakap kepada nod, Saya akan dapat membaca data. OKEY? Saya mungkin tidak selalunya dapat menulis data jika saya platform yang konsisten. Tetapi saya akan dapat membaca data. 

Keadaan lembut menunjukkan bahawa apabila saya membaca data itu, ia mungkin tidak sama dengan nod lain. Jika hak yang telah dikeluarkan pada nod tempat lain dalam kelompok dan ia tidak ditiru di seluruh kelompok lagi apabila saya membaca bahawa data, negeri yang mungkin tidak konsisten. Walau bagaimanapun, ia akan menjadi akhirnya konsisten, yang bermaksud bahawa apabila menulis satu penting untuk sistem, ia akan meniru seluruh nod. Dan akhirnya, menyatakan bahawa akan dibawa ke dalam perintah, dan ia akan menjadi negeri yang konsisten. 

Sekarang, CAP teorem benar-benar memainkan hanya pada satu keadaan. Keadaan itu adalah apabila ini berlaku. Kerana apabila ia beroperasi di mod biasa, tidak ada partition, segala-galanya yang konsisten dan boleh didapati. Anda hanya bimbang tentang CAP apabila kita mempunyai partition itu. Jadi mereka adalah jarang berlaku. Tetapi bagaimana sistem ini bertindak balas apabila orang- berlaku menentukan jenis sistem apa kita berurusan dengan. 

Jadi mari kita lihat apa yang yang kelihatan seperti untuk sistem AP. OKEY? Sistem AP datang dalam dua perisa. Mereka datang dalam rasa itu adalah master master, 100%, sentiasa ada. Dan mereka datang dalam rasa lain, yang berkata, anda tahu apa, saya akan bimbang tentang perkara pembahagian ini apabila partition sebenar berlaku. Jika tidak, akan menjadi rendah nod yang akan mengambil hak. OKEY? 

Jadi, jika kita sesuatu seperti Cassandra. Cassandra akan menjadi tuan tuan, mari saya menulis kepada mana-mana nod. Jadi apa yang berlaku? Jadi saya mempunyai objek dalam pangkalan data yang wujud pada dua nod. Mari kita memanggil bahawa objek S. Jadi kita mempunyai negeri untuk S. Kami mempunyai beberapa operasi pada S yang berterusan. Cassandra membolehkan saya menulis kepada beberapa nod. Jadi katakan saya mendapat menulis untuk s kepada dua nod. Nah, apa yang akhirnya berlaku adalah kami menamakannya sebagai acara pembahagian. Mungkin tidak menjadi partition rangkaian fizikal. Tetapi kerana reka bentuk sistem, ia sebenarnya pembahagian sebaik kerana saya mendapat tulis pada dua nod. Ia tidak memaksa saya untuk menulis semua melalui satu nod. Saya menulis pada dua nod. OKEY? 

Jadi sekarang saya mempunyai kedua-dua negeri. OKEY? Apa yang akan berlaku adalah cepat atau lambat, ada akan menjadi satu acara yang replikasi. Ada akan menjadi apa yang kita dipanggil pemulihan partition, yang adalah di mana kedua-dua negeri datang kembali bersama-sama dan tidak akan menjadi algoritma yang berjalan di dalam pangkalan data, memutuskan apa yang perlu dilakukan. OKEY? Secara lalai, dikemaskini menang dalam kebanyakan sistem AP. Jadi ada biasanya algoritma lalai, apa mereka panggil panggilan balik fungsi, sesuatu yang akan dipanggil apabila keadaan ini dikesan untuk melaksanakan beberapa logik untuk menyelesaikan konflik itu. OKEY? Panggil balik lalai dan lalai resolver dalam kebanyakan pangkalan data AP adalah, meneka apa, tanda waktu menang. Ini telah dikemaskini terakhir. Saya akan meletakkan maklumat yang di sana. Saya boleh membuang rekod ini yang saya terdampar ke dalam log pemulihan supaya pengguna boleh kembali kemudian dan berkata, hey, terdapat perlanggaran. Apa yang berlaku? Dan anda sebenarnya boleh membuang rekod semua perlanggaran dan rollbacks dan melihat apa yang berlaku. 

Sekarang, sebagai pengguna, anda juga boleh termasuk logik ke dalam panggilan balik itu. Jadi anda boleh menukar yang operasi pang. Anda boleh berkata, hey, saya mahu untuk mengatasinya data ini. Dan saya mahu mencuba dan menggabungkan kedua-dua rekod. Tetapi itu terpulang kepada anda. Pangkalan data ini tidak tahu bagaimana untuk berbuat demikian secara lalai. Kebanyakan masa, satu-satunya perkara pangkalan data tahu bagaimana untuk lakukan adalah berkata, Ia ini adalah rekod yang terakhir. Itulah salah satu yang akan menang, dan itulah nilai saya akan meletakkan. Sekali bahawa pemulihan partition dan replikasi berlaku, kita ada negara kita, yang kini S perdana, yang negeri percantuman semua orang-orang objek. Jadi sistem AP mempunyai ini. Sistem CP tidak perlu bimbang tentang perkara ini. Kerana sebaik sahaja partition datang ke dalam bermain, mereka hanya berhenti mengambil menulis. OKEY? Jadi, itu sangat mudah untuk berurusan dengan yang konsisten apabila anda tidak menerima apa-apa maklumat terkini. Itulah dengan sistem CP lakukan. Baiklah. 

Jadi mari kita bercakap sedikit sedikit tentang corak akses. Apabila kita bercakap mengenai NoSQL, ia semua tentang corak capaian. Sekarang, SQL adalah ad hoc, pertanyaan. Ia adalah kedai hubungan. Kami tidak perlu bimbang tentang corak capaian. Saya menulis pertanyaan yang sangat kompleks. Ia pergi dan mendapat data. Itulah yang ini kelihatan seperti, pemulihan. 

Jadi dalam struktur tertentu ini, kita sedang melihat katalog produk. Saya mempunyai pelbagai jenis produk. Saya mempunyai buku. Saya mempunyai album. Saya mempunyai video. Hubungan antara produk dan mana-mana salah satu buku ini, album, dan video jadual adalah 1: 1. Semua betul? Saya telah mendapat satu ID produk, dan sepadan dengan ID untuk sebuah buku, album, atau video. OKEY? Itu satu 1: hubungan 1 seluruh jadual tersebut. 

Sekarang, books-- semua mereka ada adalah sifat akar. Tiada masalah. Itu yang besar. Satu-sama-satu hubungan, saya mendapatkan semua data yang saya perlukan untuk menggambarkan buku itu. Album Albums-- mempunyai trek. Ini adalah apa yang kita panggil satu kepada ramai. Setiap album boleh mempunyai banyak trek. Jadi bagi setiap trek pada album, saya boleh mempunyai satu lagi rekod dalam jadual kanak-kanak ini. Jadi saya membuat satu rekod dalam jadual album saya. Saya membuat beberapa rekod dalam jadual trek. Hubungan satu-ke-banyak. 

Hubungan ini adalah apa yang kita panggil banyak ke banyak. OKEY? Anda melihat bahawa pelakon boleh menjadi dalam banyak filem, banyak video. Jadi apa yang kita lakukan ialah kita meletakkan pemetaan ini meja antara mereka, yang ia hanya maps ID pelakon untuk ID video. Sekarang saya boleh mencipta pertanyaan itu menyertai video melalui video pelakon untuk pelakon, dan ia memberikan saya senarai bagus semua filem dan pelakon yang bersama-sama dalam filem itu. 

OKEY. Jadi di sini kita pergi. Satu-sama-satu adalah peringkat bahagian atas hubungan; satu-ke-banyak, album untuk trek; banyak-ke-banyak. Mereka adalah tingkat atas tiga hubungan dalam mana-mana pangkalan data. Jika anda tahu bagaimana mereka hubungan bekerja bersama-sama, maka anda tahu banyak mengenai pangkalan data sudah. Jadi NoSQL berfungsi sedikit berbeza. Mari kita fikirkan untuk kali kedua apa yang ia kelihatan suka pergi mendapatkan semua produk saya. 

Di kedai hubungan, Saya mahu untuk mendapatkan semua produk saya dalam senarai dari semua produk saya. Itu banyak pertanyaan. Saya mendapat pertanyaan untuk semua buku saya. Saya mendapat pertanyaan dari album saya. Dan saya mendapat pertanyaan untuk semua video saya. Dan saya mendapat untuk meletakkan ia semua bersama-sama dalam senarai dan berkhidmat kembali kepada permohonan yang yang memintanya. 

Untuk mendapatkan buku-buku saya, saya menyertai Produk dan Buku. Untuk mendapatkan album saya, saya dapat menyertai Produk, Album, dan Tracks. Dan untuk mendapatkan video saya, saya mempunyai untuk menyertai Produk untuk Video, menyertai melalui Actor Video, dan membawa masuk Pelakon. Jadi itulah tiga pertanyaan. Pertanyaan yang sangat kompleks untuk memasang satu set hasil. 

Itu kurang daripada optimum. Kerana itulah apabila kita bercakap mengenai struktur data itu dibina untuk menjadi agnostik untuk akses pattern-- juga yang hebat. Dan anda boleh melihat ini adalah benar-benar baik bagaimana kami telah menganjurkan data. Dan anda tahu apa? Saya hanya mempunyai satu rekod untuk pelakon. 

Itu sejuk. Saya telah deduplicated semua pelakon saya, dan saya mengekalkan persatuan saya dalam jadual pemetaan ini. Walau bagaimanapun, dapatkan data keluar menjadi mahal. Aku menghantar CPU seluruh sistem menyertai dalam struktur data bersama-sama dapat menarik yang kembali data. 

Jadi bagaimana saya boleh mendapatkan sekitar itu? Dalam NoSQL ia mengenai mengumpul, tidak normal. Oleh itu, kita mahu mengatakan bahawa kita mahu menyokong corak capaian. Jika corak akses kepada aplikasi, Saya perlu untuk mendapatkan semua produk saya. Mari kita meletakkan semua produk dalam satu jadual. Jika saya meletakkan semua produk dalam satu meja, Saya hanya boleh memilih semua produk dari meja itu dan saya mendapatkan semuanya. Nah bagaimana saya boleh berbuat demikian? Baik dalam NoSQL tidak ada struktur ke meja. Kami akan bercakap sedikit tentang bagaimana ini bekerja di Dynamo DB. Tetapi anda tidak mempunyai yang sama sifat-sifat dan sifat yang sama dalam setiap baris, dalam setiap satu perkara, seperti yang anda lakukan dalam jadual SQL. Dan apa ini membolehkan saya lakukan adalah banyak perkara dan memberi saya banyak fleksibiliti. Dalam kes ini, saya mempunyai dokumen produk saya. Dan dalam hal ini khususnya Sebagai contoh, segala-galanya adalah dokumen dalam jadual Produk. Dan produk untuk buku mungkin mempunyai ID jenis yang menentukan buku. Dan permohonan itu akan menghidupkan ID tersebut. 

Pada peringkat permohonan itu, saya akan untuk mengatakan oh, apa jenis rekod ini? Oh, ia adalah satu rekod buku. Rekod buku mempunyai ciri-ciri ini. Biar saya mencipta objek buku. Jadi saya akan untuk mengisi objek tempah dengan item ini. Perkara seterusnya datang dan berkata, apa yang barangan ini? Baik perkara ini adalah album. Oh, saya mendapat yang berbeza keseluruhannya rutin pemprosesan untuk itu, kerana ia adalah album. Anda lihat apa yang saya maksudkan? 

Jadi permohonan tier-- Saya hanya pilih semua rekod-rekod ini. Mereka semua mula datang. Mereka boleh menjadi semua jenis yang berbeza. Dan ia adalah logik aplikasi yang beralih seluruh orang-orang jenis dan memutuskan bagaimana untuk memprosesnya. 

Sekali lagi, jadi kita mengoptimumkan skema untuk corak capaian. Kami melakukannya dengan runtuh jadual tersebut. Kami pada dasarnya mengambil struktur ini normal, dan kami sedang membina struktur hierarki. Di dalam setiap satu daripada rekod-rekod ini Saya akan dapat melihat ciri-ciri pelbagai. 

Di dalam dokumen ini untuk Album, Saya melihat tatasusunan trek. Mereka trek sekarang become-- ia pada dasarnya meja kanak-kanak ini yang wujud di sini dalam struktur ini. Jadi, anda boleh melakukan ini dalam DynamoDB. Anda boleh melakukan ini dalam MongoDB. Anda boleh melakukan ini dalam mana-mana pangkalan data NoSQL. Buat jenis struktur data hierarki yang membolehkan anda mengambil data dengan cepat kerana sekarang saya tidak perlu akur. Apabila saya memasukkan berturut-turut ke dalam Tracks meja, atau berturut-turut ke dalam jadual Album itu, Saya harus menepati skema itu. Saya perlu mempunyai sifat atau harta yang ditakrifkan di atas meja itu. Setiap seorang daripada mereka, apabila saya memasukkan baris tersebut. Itu bukan kes di NoSQL. 

Saya boleh mempunyai sama sekali berbeza hotel di tiap-tiap dokumen yang saya masukkan ke dalam koleksi. Mekanisme Jadi sangat kuat. Dan ia benar-benar bagaimana anda mengoptimumkan sistem. Kerana sekarang bahawa pertanyaan, bukan menyertai semua jadual ini dan melaksanakan pertanyaan setengah dozen menarik balik data yang saya perlukan, Saya melaksanakan satu pertanyaan. Dan saya iterating seluruh keputusan ditetapkan. ia memberi anda idea kuasa NoSQL. Saya akan jenis pergi ke tepi sini dan bercakap sedikit tentang perkara ini. Ini adalah jenis lebih daripada pemasaran atau technology-- pemasaran teknologi jenis perbincangan. Tetapi ia adalah penting untuk memahami kerana jika kita melihat bahagian atas di sini di carta ini, apa yang kita cari di adalah apa yang kita panggil keluk gembar-gembur teknologi. Dan apa ini bermakna barangan baru datang ke dalam bermain. Orang fikir ia hebat. Saya telah menyelesaikan semua masalah saya. 

Ini boleh menjadi akhir semua, menjadi semua untuk segala-galanya. Dan mereka mula menggunakannya. Dan mereka berkata, barangan ini tidak berfungsi. Ini tidak betul. The barangan lama adalah lebih baik. Dan mereka telah kembali kepada melakukan sesuatu dengan cara yang mereka berada. Dan kemudian akhirnya mereka pergi, anda tahu apa? Barangan ini tidak begitu buruk. Oh, itu bagaimana ia berfungsi. Dan apabila mereka memikirkan bagaimana ia kerja-kerja, mereka mula semakin baik. 

Dan perkara yang lucu mengenainya adalah, ia jenis garisan sehingga apa kita panggil Curve Teknologi Angkat. Jadi apa yang berlaku ialah kita mempunyai beberapa pencetus teknologi macam. Dalam kes pangkalan data, ia adalah tekanan data. Kita bercakap tentang mata air yang tinggi tekanan data sepanjang masa. Apabila tekanan data menjadi asas yang tertentu mata, itu adalah satu pencetus teknologi. 

Ia semakin terlalu mahal. Ia mengambil masa yang lama untuk memproses data. Kami memerlukan sesuatu yang lebih baik. Anda mendapatkan inovator di luar sana berjalan di sekitar, cuba untuk mengetahui apa yang penyelesaian. Apakah idea yang baru? 

Apa yang terbaik seterusnya cara untuk melakukan perkara ini? Dan mereka datang dengan sesuatu. Dan orang-orang yang sakit yang sebenar, lelaki di tepi pendarahan, mereka akan melompat di seluruh ia, kerana mereka memerlukan jawapan. Sekarang apa yang tidak dapat tidak happens-- dan ia berlaku sekarang di NoSQL. Saya lihat sepanjang masa. 

Apa yang tidak dapat tidak berlaku ialah orang mula menggunakan alat baru cara yang sama mereka menggunakan alat yang lama. Dan mereka mengetahui ia tidak berfungsi dengan baik. Saya tidak ingat siapa saya bercakap dengan awal hari ini. Tetapi ia seperti, apabila gerudi tukul dicipta, orang tidak swing ia lebih kepala mereka untuk menghancurkan konkrit. 

Tetapi itu adalah apa yang berlaku dengan NoSQL hari ini. Jika anda berjalan di kebanyakan kedai-kedai, mereka cuba untuk menjadi kedai NoSQL. Apa yang mereka lakukan adalah mereka menggunakan NoSQL, dan mereka memuatkan penuh skema hubungan. Oleh kerana itu bagaimana mereka bentuk pangkalan data. Mereka tertanya-tanya, mengapa ia tidak melaksanakan dengan baik? Boy, perkara ini berbau. Saya terpaksa mengekalkan semua saya menyertai dalam- ia seperti, tidak, tidak. Mengekalkan menyertai? Mengapa kamu menyertai data? Awak tidak masuk data dalam NoSQL. Anda menggabungkan ia. 

Jadi, jika anda mahu mengelakkan ini, belajar bagaimana alat ini berfungsi sebelum anda sebenarnya mula menggunakannya. Jangan cuba menggunakan alat yang baru Cara yang sama yang anda gunakan alat-alat yang lama. Anda akan mempunyai pengalaman yang buruk. Dan setiap kali itulah yang ini adalah kira-kira. Apabila kita mula datang sini, ia adalah kerana orang digambarkan bagaimana untuk menggunakan alat. 

Mereka melakukan perkara yang sama apabila pangkalan data hubungan telah dicipta, dan mereka telah menggantikan sistem fail. Mereka cuba untuk membina sistem fail dengan pangkalan data hubungan kerana itulah yang orang difahami. Ia tidak berjaya. Jadi memahami amalan terbaik teknologi yang anda bekerja dengan adalah besar. Sangat penting. 

Jadi, kita akan masuk ke dalam DynamoDB. DynamoDB adalah AWS ini diuruskan sepenuhnya platform NoSQL. Apa yang diuruskan sepenuhnya bermakna? Ini bermakna anda tidak perlu benar-benar bimbang tentang apa-apa. 

Anda datang, anda beritahu kita, saya perlu jadual. Ia memerlukan kapasiti ini banyak. Anda menekan butang, dan peruntukan kita semua infrastruktur di sebalik kejadian. Sekarang adalah sangat besar. 

Kerana apabila anda bercakap tentang mendaki pangkalan data, NoSQL kelompok data pada skala, petabyte berjalan, berjalan berjuta-juta transaksi sesaat, perkara-perkara ini tidak kelompok kecil. Kami bercakap beribu-ribu kes. Urusan beribu-ribu kes, walaupun keadaan maya, adalah sakit sebenar di punggung itu. Maksud saya, berfikir tentang setiap masa yang sistem operasi patch keluar atau versi baru pangkalan data. Apa maksudnya kepada anda operasi? Ini bermakna anda mendapat 1200 pelayan yang perlu dikemaskini. Kini dengan automasi, yang boleh mengambil masa yang lama. Yang boleh menyebabkan banyak sakit kepala operasi, kerana saya mungkin mempunyai perkhidmatan ke bawah. 

Seperti yang saya mengemas kini pangkalan data tersebut, saya mungkin melakukan pergerakan hijau biru di mana saya menggunakan dan menaik taraf separuh saya nod, dan kemudian menaik taraf separuh yang lain. Mengambil orang-orang ke bawah. Jadi menguruskan infrastruktur skala ini sangat menyakitkan. Dan AWS mengambil kesakitan yang keluar daripadanya. Dan pangkalan data NoSQL boleh menjadi luar biasa menyakitkan kerana cara mereka skala. 

Skala mendatar. Jika anda ingin mendapatkan NoSQL yang lebih besar pangkalan data, anda membeli lebih nod. Setiap nod anda beli adalah lain sakit kepala operasi. Jadi mari orang lain melakukannya untuk anda. AWS boleh berbuat demikian. 

Kami menyokong nilai-nilai utama dokumen. Sekarang kita tidak pergi terlalu banyak ke dalam pada carta yang lain. Ada banyak yang berbeza rasa NoSQL. Mereka semua jenis mendapat munged bersama-sama pada ketika ini. Anda boleh melihat DynamoDB dan berkata ya, kami kedua-dua dokumen dan nilai utama menyimpan hal ini. Dan anda boleh berhujah ciri-ciri satu atas yang lain. Bagi saya, banyak ini adalah benar-benar enam satu setengah dozen yang lain. Setiap satu daripada teknologi ini adalah satu teknologi halus dan penyelesaian halus. Saya tidak akan mengatakan MongoDB lebih baik atau lebih buruk daripada Couch, kemudian Cassandra, kemudian Dynamo, atau sebaliknya. Maksud saya, ini adalah hanya pilihan. 

Ia cepat dan ia konsisten di mana-mana. Jadi ini adalah salah satu yang terbesar bonus yang anda dapat dengan AWS. Dengan DynamoDB adalah keupayaan untuk mendapatkan satu angka yang rendah kependaman milisaat di mana-mana. Itu adalah matlamat reka bentuk sistem. Dan kami mempunyai pelanggan yang melakukan berjuta-juta transaksi sesaat. 

Sekarang saya akan pergi melalui beberapa orang-orang menggunakan kes-kes dalam beberapa minit di sini. Akses control-- Bersepadu kita mempunyai apa yang kita panggil Pengurusan Akses identiti, atau IAM. Ia meresap setiap sistem, setiap perkhidmatan yang AWS ditawarkan. DynamoDB tidak terkecuali. Anda boleh mengawal akses kepada jadual DynamoDB. Di semua akaun anda dengan AWS menentukan peranan akses dan kebenaran dalam infrastruktur IAM. 

Dan ia adalah satu komponen utama dan penting dalam apa yang kita panggil acara Programming Didorong. Sekarang ini adalah paradigma baru. 

PENONTON: Bagaimana dengan kadar anda benar positif berbanding negatif palsu pada sistem kawalan akses anda? RICK Houlihan: Kebenaran positif berbanding negatif palsu? PENONTON: Kembali apa anda perlu pulang? Berbeza dengan sekali-sekala ia tidak akan kembali apabila ia perlu mengesahkan? 

RICK Houlihan: Saya tidak dapat memberitahu anda bahawa. Jika ada apa-apa kegagalan sekalipun pada itu, Saya bukan orang yang meminta bahawa soalan tertentu. Tetapi itu adalah satu soalan yang baik. Saya akan ingin tahu bahawa diri saya, sebenarnya. 

Dan demikian maka sekali lagi, paradigma baru adalah acara didorong pengaturcaraan. Ini adalah idea bahawa anda boleh menggunakan aplikasi kompleks yang boleh beroperasi sangat, skala yang sangat tinggi tanpa apa-apa infrastruktur sekalipun. Tanpa apa-apa tetap infrastruktur sekalipun. Dan kita akan bercakap sedikit tentang apa yang bermakna seperti yang kita mendapatkan ke setahun dua lagi carta. 

Perkara pertama yang kita akan buat adalah kita akan bercakap tentang jadual. Jenis data API untuk Dynamo. Dan perkara pertama yang anda akan notis apabila anda melihat ini, jika anda sudah biasa dengan mana-mana pangkalan data, pangkalan data yang telah benar-benar dua jenis API Saya memanggilnya. Atau dua set API. Salah satu daripada mereka akan API pentadbiran. 

Perkara-perkara yang mereka menjaga fungsi pangkalan data. Konfigurasi enjin penyimpanan, menubuhkan dan menambah jadual. mewujudkan pangkalan data katalog dan contoh. Ini things-- dalam DynamoDB, anda mempunyai sangat pendek, senarai pendek. 

Jadi dalam pangkalan data yang lain, anda mungkin melihat berpuluh-puluh arahan, daripada pentadbiran arahan, untuk mengkonfigurasi pilihan-pilihan tambahan. Dalam DynamoDB anda tidak perlu mereka kerana anda tidak mengkonfigurasi sistem, yang kita lakukan. Jadi satu-satunya perkara yang anda perlu lakukan adalah beritahu saya apa saiz meja yang saya perlukan. Supaya anda mendapat yang sangat set terhad arahan. 

Anda mendapat Cipta Meja Update, Meja, Padam Table, dan Huraikan Jadual. Mereka adalah perkara-perkara sahaja anda perlukan untuk DynamoDB. Anda tidak memerlukan penyimpanan yang konfigurasi enjin. Saya tidak perlu bimbang tentang replikasi. Saya tidak perlu bimbang tentang sharding. 

Saya tidak perlu bimbang mengenai mana-mana barangan ini. Kami melakukan semuanya untuk anda. Jadi itulah sejumlah besar overhed yang hanya diangkat dari pinggan anda. Kemudian kita mempunyai pengendali Makanan Tak. Makanan Tak adalah sesuatu yang kita memanggil di dalam pangkalan data itu Cipta, Update, Padam pengendali. Ini adalah biasa anda operasi pangkalan data. Perkara seperti item put, dapatkan item, maklumat barang-barang, memadam item, kumpulan pertanyaan, mengimbas. Jika anda mahu untuk mengimbas seluruh meja. Tarik semua dari meja. Salah satu perkara yang menarik mengenai DynamoDB adalah ia membolehkan pengimbasan selari. Jadi, anda sebenarnya boleh beritahu saya berapa banyak benang anda ingin melaksanakan imbasan itu. Dan kita boleh menjalankan mereka benang. Kami boleh berputar yang mengimbas sehingga merentasi pelbagai benang supaya anda boleh mengimbas keseluruhan jadual ruang yang sangat, sangat cepat dalam DynamoDB. 

API lain yang kita ada adalah apa yang kita panggil API Streams kami. Kami tidak akan bercakap terlalu banyak mengenai ini buat masa ini. Saya ada beberapa kandungan kemudian di dalam dek tentang perkara ini. Tetapi Streams adalah benar-benar running-- yang memikirkan ia sebagai masa yang dipesan dan log perubahan partition. Segala-galanya yang berlaku di jadual muncul di sungai itu. 

Setiap menulis kepada jadual muncul di sungai itu. Anda boleh membaca aliran itu, dan anda boleh melakukan perkara-perkara dengannya. Kami akan bercakap tentang apa yang jenis perkara yang anda kaitan dengan perkara-perkara seperti replikasi, mewujudkan indeks menengah. Semua jenis benar-benar sejuk perkara yang boleh anda lakukan dengan itu. 

Jenis data. Dalam DynamoDB, kami menyokong kedua-dua kunci nilai dan data dokumen jenis. Di sebelah kiri skrin di sini, kami mempunyai jenis asas kami. Jenis nilai utama. Ini adalah tali, nombor, dan binari. 

Jadi hanya tiga jenis asas. Dan kemudian anda boleh mempunyai set mereka. Salah satu perkara yang menarik mengenai NoSQL adalah anda boleh mengandungi tatasusunan sebagai hartanah. Dan dengan DynamoDB anda boleh mengandungi tatasusunan jenis asas sebagai harta akar. 

Dan kemudian ada jenis-jenis dokumen. Berapa banyak orang sudah biasa dengan JSON? Anda semua biasa dengan JSON begitu banyak? Ia pada dasarnya JavaScript, Objek, notasi. Ia membolehkan anda untuk pada dasarnya menentukan struktur hierarki. 

Anda boleh menyimpan dokumen JSON pada DynamoDB menggunakan komponen yang sama atau blok bangunan yang boleh didapati dalam kebanyakan bahasa pengaturcaraan. Jadi jika anda mempunyai Java, anda melihat peta dan senarai. Saya boleh membuat objek yang kawasan peta. A peta sebagai nilai utama disimpan sebagai hartanah. Dan ia mungkin mempunyai senarai nilai dalam hartanah. Anda boleh menyimpan kompleks ini struktur hierarki sebagai sifat tunggal bagi item DynamoDB. 

Jadi jadual dalam DynamoDB, seperti kebanyakan Pangkalan data yang NoSQL, jadual mempunyai item. Dalam MongoDB yang anda lakukan memanggil dokumen-dokumen ini. Dan ia akan menjadi asas sofa. Juga pangkalan data dokumen. Anda memanggil dokumen-dokumen ini. Dokumen atau barangan yang mempunyai sifat-sifat. Sifat-sifat yang boleh wujud atau tidak wujud pada item. Dalam DynamoDB, ada salah satu sifat wajib. Sama seperti dalam pangkalan data hubungan, anda mempunyai kunci utama di atas meja. 

DynamoDB mempunyai apa yang kita panggil kekunci hash. Utama Hash mestilah unik. Oleh itu, apabila saya menentukan jadual hash, pada dasarnya apa yang saya cakapkan adalah setiap item akan mempunyai kunci hash. Dan setiap utama hash mestilah unik. 

Setiap item ditakrifkan oleh bahawa kunci hash unik. Dan hanya ada satu. Ini adalah OK, tetapi sering kali apa yang diperlukan oleh adalah mereka mahu adalah hash ini Kunci untuk melakukan sedikit lebih daripada hanya menjadi pengecam unik. Sering kali kita ingin menggunakan kunci hash sebagai bahagian atas baldi pengagregatan peringkat. Dan cara kita lakukan iaitu dengan menambah apa yang kita panggil kunci pelbagai. 

Jadi, jika ia adalah satu hash sahaja meja, ini mestilah unik. Jika ia merupakan satu jadual hash dan pelbagai, yang gabungan hash dan julat mestilah unik. Jadi berfikir tentang hal itu dengan cara ini. Jika saya mempunyai forum. Dan bentuk yang mempunyai topik, ia mempunyai posts, dan ia mempunyai jawapan. 

Oleh itu, saya mungkin mempunyai hash utama, yang merupakan ID topik. Dan saya mungkin mempunyai kunci pelbagai, yang merupakan ID sambutan. Dengan cara itu jika saya mahu untuk mendapatkan semua jawapan untuk topik tertentu, Saya hanya boleh query hash. Saya hanya boleh mengatakan memberi saya semua barang-barang yang mempunyai hash ini. Dan saya akan untuk mendapatkan setiap soalan atau pos untuk topik tersebut. Ini kesatuan peringkat tertinggi adalah amat penting. Mereka menyokong akses utama corak permohonan. Secara umum, ini adalah apa yang kita mahu lakukan. Kami ingin table-- yang anda memuatkan meja, kita mahu menyusun data dalam jadual di dalam apa-apa cara bahawa permohonan itu boleh sangat cepat mendapatkan hasil tersebut. Dan sering kali cara untuk berbuat demikian adalah untuk mengekalkan kesatuan ini seperti yang kita memasukkan data. Pada asasnya, kami menyebarkan data ke dalam baldi terang kerana ia datang dalam. 

Kunci pelbagai membolehkan hash me-- kunci perlu kesaksamaan. Apabila saya bertanya hash, saya perlu mengatakan memberi saya hash yang sama ini. Apabila saya bertanya pelbagai, saya boleh mengatakan memberikan saya pelbagai yang menggunakan apa-apa jenis pengendali kaya yang kami menyokong. Berikan saya semua barang-barang untuk hash. Adakah ia sama, lebih besar daripada, kurang daripada, ia bermula dengan, ia wujud di antara kedua-dua nilai? Jadi ini jenis pertanyaan pelbagai bahawa kita sentiasa berminat. Sekarang satu perkara tentang data, apabila anda melihat mengakses data, apabila anda mengakses data, ia sentiasa tentang pengagregatan yang. Ia sentiasa mengenai rekod yang berkaitan dengan ini. Berikan saya segala-galanya di sini that's-- semua transaksi pada kad kredit ini untuk bulan lepas. Itulah pengagregatan yang. 

Hampir semua yang anda lakukan dalam pangkalan data beberapa jenis pengagregatan. Jadi dapat dapat menentukan ini baldi dan memberikan anda pelbagai ini sifat-sifat dapat membuat carian ke atas, orang-orang kaya pertanyaan menyokong banyak, banyak, banyak corak akses permohonan. 

Jadi perkara lain utama hash tidak adalah ia memberikan kita satu mekanisme dapat menyebarkan data sekitar. Pangkalan data yang NoSQL bekerja terbaik apabila data adalah sama rata diedarkan di seluruh kelompok. Berapa ramai orang yang biasa dengan hashing algoritma? Apabila saya mengatakan hash dan hashing-- yang kerana algoritma hashing adalah satu cara yang dapat menjana nilai secara rawak daripada apa-apa nilai yang diberikan. Jadi dalam kes ini, yang algoritma hash kita jalankan adalah ND 5 berdasarkan. 

Sekalipun aku mempunyai ID, dan ini adalah kunci hash saya, saya mempunyai 1, 2, 3. Apabila saya menjalankan algoritma hash, ia akan datang kembali dan berkata, baik 1 sama 7B, 2 sama dengan 48, 3 sama dengan CD. Mereka tersebar di seluruh ruang utama. Mengapa anda melakukan ini? Kerana yang akan memastikan bahawa saya boleh meletakkan rekod di beberapa nod. 

Jika saya melakukan ini secara berperingkat, 1, 2, 3. Dan saya mempunyai pelbagai hash yang berjalan dalam kes ini, ruang hash kecil, ia berjalan dari 00 hingga FF, maka rekod akan datang dalam dan mereka akan pergi 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Apa yang berlaku? Setiap insert akan nod yang sama. Anda lihat apa yang saya maksudkan? 

Kerana apabila saya berpecah ruang, dan Aku telah rekod-rekod ini di seluruh, dan partition saya, saya akan berkata partition 1 mempunyai ruang utama 0-54. Partition 2 adalah 55-89. Partition 3 adalah AA FF. Jadi, jika saya menggunakan linear menokok ID, anda boleh melihat apa yang berlaku. 1, 2, 3, 4, 5, 6, sepanjang jalan sehingga 54. Jadi seperti yang saya terantuk yang rekod ke dalam sistem, segala-galanya berakhir akan satu nod. 

Yang tidak baik. Itulah antipattern yang. Dalam MongoDB mereka mempunyai masalah ini jika anda tidak menggunakan kekunci hash. MongoDB memberikan anda pilihan daripada hashing nilai utama. Anda harus selalu berbuat demikian, jika anda menggunakan hash menokok utama dalam MongoDB, atau anda akan menjadi memaku setiap tulis ke satu nod, dan anda akan mengehadkan pemprosesan menulis anda teruk. 

PENONTON: Adakah itu A9 169 dalam perpuluhan? 

RICK Houlihan: Ya, ia tempat di sekitar sana. A9, saya tidak tahu. Anda harus mendapatkan binari saya kalkulator perpuluhan. Otak saya tidak berfungsi seperti itu. PENONTON: Hanya satu cepat komen Mongo anda. Jadi adalah ID objek yang datang secara asal dengan Mongo berbuat demikian? RICK Houlihan: Adakah ia berbuat demikian? Jika anda nyatakan ia. Dengan MongoDB, anda mempunyai pilihan. Anda boleh specify-- tiap-tiap dokumen dalam MongoDB perlu mempunyai ID garis bawah. Itulah nilai yang unik. 

Dalam MongoDB anda boleh menentukan sama ada untuk hash atau tidak. Mereka hanya memberi anda pilihan. Jika anda tahu bahawa itu rawak, tidak ada masalah. Anda tidak perlu untuk berbuat demikian. Jika anda tahu bahawa ia bukan rawak, yang ia menokok, kemudian melakukan hash. 

Sekarang perkara yang kira-kira hashing, sebaik sahaja anda hash yang value-- dan ini adalah mengapa kekunci hash sentiasa pertanyaan yang unik, kerana saya telah mengubah nilai, sekarang saya tidak boleh melakukan pelbagai pertanyaan. Saya tidak boleh katakan adalah ini antara ini atau itu, kerana nilai hash tidak akan sebagai setaraf dengan nilai sebenar. Oleh itu, apabila anda hash yang utama, ia kesamaan sahaja. Inilah sebabnya mengapa dalam kunci hash DynamoDB pertanyaan yang selalu kesamaan sahaja. 

Jadi sekarang dalam pelbagai key-- apabila saya menambah bahawa kunci pelbagai, rekod utama pelbagai semua datang dan mereka akan disimpan pada partition yang sama. Jadi mereka sangat cepat, mudah diambil kerana ini adalah hash, ini adalah julat. Dan anda melihat segala-galanya dengan hash yang sama akan disimpan pada ruang partition yang sama. Anda boleh menggunakan kunci pelbagai untuk membantu mengesan data anda dekat dengan induknya. Jadi apa yang saya benar-benar buat di sini? Ini adalah salah satu hubungan banyak. Hubungan antara kunci hash dan kunci julat adalah salah satu kepada ramai. Saya boleh mempunyai kekunci hash berbilang. Saya hanya boleh mempunyai pelbagai pelbagai kunci dalam setiap utama hash. 

Hash mentakrifkan induk, julat mentakrifkan kanak-kanak. Jadi, anda boleh melihat ada analog di sini antara konstruk hubungan dan jenis yang sama membina dalam NoSQL. Orang bercakap mengenai NoSQL sebagai nonrelational. Ia bukan nonrelational. Data sentiasa mempunyai hubungan. Hubungan tersebut hanya dimodelkan berbeza. Mari kita bercakap sedikit sedikit tentang ketahanan. Apabila anda menulis untuk DynamoDB, menulis adalah tiga hala replika. Yang bererti bahawa kita mempunyai tiga AZ-kanak. AZ adalah Zon ketersediaan. Anda boleh memikirkan Ketersediaan yang Zon sebagai pusat data atau koleksi pusat data. Perkara-perkara ini adalah mengikut geografi diasingkan daripada satu sama lain merentasi zon kesalahan yang berbeza, di seluruh berbeza grid kuasa dan dataran banjir. Kegagalan dalam satu AZ tidak akan mengambil lain. Mereka juga dikaitkan bersama-sama dengan serat gelap. Ia menyokong satu sub 1 milisaat latency antara Azs. Jadi ulangan data masa sebenar berkebolehan dalam pelbagai Azs. 

Dan sering kali pelbagai AZ pergerakan memenuhi keperluan ketersediaan tinggi organisasi perusahaan paling. Jadi DynamoDB disebarkan di tiga AZS secara lalai. Kami hanya akan pengetahuan menulis apabila dua daripada tiga nod kembali dan berkata, Ya, saya mendapat ia. Kenapa begitu? Kerana di sebelah membaca kami hanya akan memberi anda data kembali apabila kita mendapatkannya dari dua nod. 

Jika saya mereplikasi seluruh tiga, dan saya membaca dari dua, Saya sentiasa dijamin untuk mempunyai sekurang-kurangnya satu daripada mereka yang berbunyi sebagai salinan terkini data. Itulah yang membuat DynamoDB konsisten. Kini anda boleh memilih untuk menghidupkan mereka konsisten berbunyi di luar. Di mana saya akan berkata, Saya hanya akan membaca dari satu nod. Dan saya tidak dapat menjamin ia akan sebagai data yang terkini. 

Jadi, jika menulis yang akan datang pada, ia tidak ditiru lagi, anda akan mendapatkan salinan itu. Itu satu dibaca akhirnya konsisten. Dan apa yang adalah setengah kos. Jadi ini adalah sesuatu untuk berfikir tentang. Apabila anda membaca daripada DynamoDB, dan anda menyediakan kapasiti membaca anda unit, jika anda memilih akhirnya konsisten berbunyi, ia adalah jauh lebih murah, ia kira-kira setengah kos. 

Dan oleh itu menjimatkan wang anda. Tetapi itu pilihan anda. Jika anda mahu membaca selaras atau membaca yang akhirnya konsisten. Itu sesuatu yang boleh anda pilih. 

Mari kita bercakap tentang indeks. Oleh itu, kita menyebut bahagian pengagregatan peringkat. Kami mempunyai kekunci hash, dan kami mempunyai kunci pelbagai. Itu bagus. Dan itu di atas meja rendah, saya mendapat satu kekunci hash, saya mendapat satu kunci pelbagai. 

Apa maksudnya? Saya ada satu sifat yang saya boleh menjalankan pertanyaan kaya terhadap. Ia adalah kunci julat. Sifat-sifat yang lain pada item-- yang Saya boleh menapis atas mereka sifat-sifat. Tetapi saya tidak boleh melakukan perkara-perkara seperti, ia bermula dengan, atau lebih besar daripada. 

Bagaimana saya boleh berbuat demikian? Saya mencipta indeks. Ada dua jenis indeks dalam DynamoDB. Indeks adalah benar-benar lain memandangkan meja. Dan indeks menengah tempatan. 

Yang pertama kita akan bercakap tentang. Sekunder Jadi tempatan wujud bersama pada partition yang sama dengan data. Dan oleh itu, mereka berada di nod fizikal sama. Mereka adalah apa yang kita panggil yang konsisten. Bermaksud, mereka akan mengakui menulis bersama-sama dengan meja. Apabila menulis telah ada, kami akan menulis melalui indeks. Kami akan menulis ke meja, dan kemudian kita akan mengakui. Jadi itulah yang konsisten. Setelah menulis itu telah mengakui dari jadual, ia dijamin bahawa indeks menengah tempatan akan mempunyai visi yang sama data. Tetapi apa yang mereka membolehkan anda lakukan adalah menentukan kunci pelbagai alternatif. 

Perlu menggunakan hash yang sama utama memandangkan jadual primer, kerana mereka bersama terletak di partition sama, dan mereka konsisten. Tetapi saya boleh mencipta indeks dengan kunci rangkaian yang berbeza. Jadi, sebagai contoh, jika saya mempunyai pengeluar yang mempunyai jadual bahagian mentah datang. Dan bahagian-bahagian mentah datang, dan mereka dikumpulkan oleh pemasangan. Dan mungkin ada dipanggil semula. 

Mana-mana bahagian yang telah dibuat oleh ini pengeluar selepas tarikh ini, Saya perlu tarik keluar dari saya. Saya boleh berputar indeks yang akan mencari, menjumlahkan pada tarikh mengeluarkan bahagian tertentu. Jadi jika jadual peringkat atas saya adalah sudah dicincang oleh pengeluar, mungkin ia telah diatur di pihak ID, saya boleh membuat indeks dari meja yang sebagai dicincang oleh pengeluar dan antara pada tarikh pengilangan. Dan dengan cara itu saya boleh berkata, apa-apa yang telah dikeluarkan antara tarikh-tarikh ini, Saya perlu tarik dari talian. Jadi itulah indeks menengah tempatan. 

Ini mempunyai kesan mengehadkan ruang utama hash anda. Kerana mereka bersama-wujud pada nod penyimpanan yang sama, mereka menghadkan utama hash ruang untuk 10 gigabait. DynamoDB, di bawah jadual, akan partition meja anda setiap 10 gigabait. Apabila anda meletakkan 10 gig data, kami pergi [PHH], dan kita menambah nod yang lain. 

Kami tidak akan berpecah LSI merentasi pelbagai sekatan. Kami akan berpecah meja. Tetapi kita tidak akan berpecah LSI. Supaya sesuatu penting untuk memahami adalah jika anda lakukan sangat, sangat, kesatuan yang sangat besar, maka anda akan dihadkan 10 gigabait pada LSIs anda. 

Jika itu berlaku, kita boleh menggunakan sekunder global. Sekunder Global benar-benar meja yang lain. Mereka wujud sepenuhnya di luar untuk tepi meja utama anda. Dan mereka membenarkan saya untuk mencari struktur yang berbeza. Jadi berfikir ia sebagai data sedang dimasukkan kepada dua jadual yang berbeza, berstruktur dalam dua cara yang berbeza. 

Saya boleh menentukan yang sama sekali utama hash yang berbeza. Saya boleh menentukan yang sama sekali yang berbeza utama pelbagai. Dan saya boleh menjalankan ini benar-benar bebas. Sebagai perkara fakta, saya telah diperuntukkan kapasiti membaca saya dan menulis kapasiti untuk saya indeks menengah global secara bebas jadual utama saya. Jika saya menentukan indeks itu, saya memberitahu ia berapa banyak membaca dan menulis kapasiti ia akan menggunakan. 

Dan itu adalah berasingan dari meja utama saya. Sekarang kedua-dua indeks membolehkan kita untuk bukan sahaja menentukan hash dan pelbagai kunci, tetapi mereka membolehkan kita untuk menonjolkan nilai-nilai tambahan. Jadi, jika saya mahu membaca kira indeks, dan saya mahu untuk mendapatkan beberapa set data, Saya tidak perlu kembali ke utama meja untuk mendapatkan ciri-ciri tambahan. Saya boleh projek mereka tambahan sifat-sifat ke dalam jadual untuk menyokong corak capaian. Saya tahu bahawa kita mungkin mendapat ke dalam beberapa benar-benar, really-- masuk ke lalang di sini beberapa barangan ini. Sekarang saya mendapat untuk hanyut keluar dari ini. 

PENONTON: [didengar] utama --table maksudkan adalah hash? Hash asal? Multi-selat? 

RICK Houlihan: Ya. Ya. Kunci jadual pada dasarnya menunjuk kembali ke item. Jadi indeks adalah penunjuk kembali ke item asal di atas meja. Kini anda boleh memilih untuk membina sebuah indeks yang hanya mempunyai kunci meja, dan tiada kediaman lain. Dan mengapa saya boleh berbuat demikian? Well, mungkin saya mempunyai perkara yang sangat besar. 

Saya benar-benar hanya perlu tahu yang- corak akses saya mungkin berkata, item mana yang mengandungi penginapan ini? Tidak perlu untuk kembali item. Saya hanya perlu tahu item mana membendungnya. Jadi, anda boleh membina indeks yang hanya mempunyai kunci meja. 

Tetapi itu terutamanya apa indeks di dalam pangkalan data adalah untuk. Ia kerana dapat dengan cepat mengenal pasti rekod, yang baris, yang item dalam jadual mempunyai sifat-sifat yang saya cari. 

GSIS, jadi bagaimana ia berfungsi? GSIS pada dasarnya adalah tak segerak. Maklumat ini datang ke dalam jadual, jadual kemudiannya asynchronously dikemaskini semua GSIS anda. Inilah sebabnya mengapa GSIS adalah akhirnya konsisten. 

Adalah penting untuk ambil perhatian bahawa apabila anda membina GSIS, dan anda memahami anda membuat satu lagi dimensi aggregation-- sekarang mari kita katakan contoh yang baik di sini adalah pengilang. Saya fikir saya mungkin telah bercakap tentang pengilang peranti perubatan. Pengeluar peranti perubatan sering kali mempunyai bahagian-bahagian bersiri. Bahagian-bahagian yang masuk ke dalam penggantian pinggul semua mempunyai nombor siri sedikit kepada mereka. Dan mereka boleh mempunyai berjuta-juta dan berjuta-juta dan berbilion-bilion bahagian dalam semua peranti yang mereka kapal. Nah, mereka perlukan untuk agregat di bawah dimensi yang berbeza, semua bahagian-bahagian perhimpunan, semua bahagian-bahagian yang telah dibuat pada garis tertentu, semua bahagian-bahagian yang datang dari pengilang tertentu pada tarikh yang tertentu. Inilah kesatuan kadang-kadang bangun ke dalam berbilion-bilion. 

Jadi saya bekerja dengan beberapa ini lelaki yang menderita kerana mereka mewujudkan ini pengagregatan ginormous dalam indeks menengah. Mereka mungkin mempunyai bahagian mentah jadual yang datang sebagai hash sahaja. Setiap bahagian mempunyai nombor siri yang unik. Saya menggunakan nombor siri sebagai hash. Ia nya cantik. Jadual data mentah saya disebarkan di seluruh ruang utama. [Saya? menulis?] [? pengambilan?] adalah hebat. Saya mengambil banyak data. Maka apa yang mereka lakukan ialah mereka membuat GSI. Dan saya berkata, anda tahu apa, saya perlu berjumpa semua bahagian untuk kategori ini. Nah, tiba-tiba saya mengambil satu bilion baris, dan barang-barang mereka ke satu nod, kerana apabila Saya agregat sebagai ID pengilang sebagai hash, dan nombor bahagian sebagai julat, kemudian secara tiba-tiba saya meletakkan bilion bahagian ke dalam apa pengilang ini yang menyelamatkan aku. 

Yang boleh menyebabkan banyak tekanan ke atas GSI, sekali lagi, kerana saya mengetuk satu nod. Saya meletakkan semua ini memasukkan ke dalam satu nod. Dan itu adalah satu kes penggunaan bermasalah nyata. Sekarang, saya mendapat reka bentuk yang baik corak untuk bagaimana anda mengelakkan itu. Dan itulah salah satu masalah bahawa saya sentiasa bekerja dengan. Tetapi apa yang berlaku, adalah GSI mungkin tidak mempunyai kapasiti menulis cukup dapat menolak semua orang-orang baris ke nod tunggal. Dan apa yang berlaku kemudian adalah utama, meja pelanggan, jadual rendah akan musnah kerana GSI tidak boleh bersaing. Jadi kadar memasukkan saya akan jatuh pada jadual primer sebagai GSI saya cuba untuk bersaing. 

Baiklah, jadi ini GSI, ini LSI, yang mana satu harus saya gunakan? Ini LSI konsisten. GSI ini adalah akhirnya konsisten. Jika itu OK, saya cadangkan menggunakan GSI, mereka lebih fleksibel. LSI ini boleh dimodelkan sebagai GSI. Dan jika saiz data setiap kekunci hash dalam koleksi anda melebihi 10 gigabait, maka anda akan mahu untuk digunakan yang GSI kerana ia hanya satu had keras. 

Baiklah, jadi bersisik. Pemprosesan di Dynamo DB, anda peruntukan boleh [didengar] pemprosesan ke meja. Kami mempunyai pelanggan yang mempunyai diperuntukkan 60 billion-- lakukan 60 bilion permintaan, kerap berjalan pada lebih daripada satu juta permintaan sesaat di atas meja kami. Ada benar-benar tidak had teori kepada berapa banyak dan berapa cepat meja boleh berjalan di Dynamo DB. Terdapat beberapa lembut had ke atas akaun anda yang kita masukkan ke dalam sana supaya bahawa anda tidak pergi gila. Jika anda mahu lebih daripada itu, tidak menjadi masalah. Anda datang kepada kami. Kami akan hadir dail. 

Setiap akaun adalah terhad kepada tahap tertentu dalam setiap perkhidmatan, tidak jauh dari kelawar supaya rakyat tidak pergi gila mendapatkan diri mereka ke dalam masalah. Tiada had dalam saiz. Anda boleh meletakkan apa-apa bilangan barang-barang di atas meja. Saiz item adalah terhad kepada 400 kilobait setiap satu, yang akan menjadi item bukan sifat-sifat. Jadi jumlah semua sifat-sifat adalah terhad kepada 400 kilobait. Dan sekali lagi, kami mempunyai isu LSI yang sedikit dengan had 10 gigabit per hash. PENONTON: Sebilangan kecil, saya hilang apa yang anda memberitahu saya, yang is-- PENONTON: Oh, 400 kilobait adalah saiz maksimum bagi setiap item. Jadi item mempunyai semua sifat-sifat. Jadi 400 k adalah jumlah saiz barang itu, 400 kilobait. Jadi daripada semua sifat-sifat digabungkan, semua data yang dalam semua sifat-sifat, digulung ke dalam jumlah saiz, kini hari ini had item adalah 400 k. Jadi mendaki lagi, mencapai melalui pembahagian. Pemprosesan adalah diperuntukkan di peringkat meja. Dan ada benar-benar dua tombol. Kami telah membaca kapasiti dan menulis kapasiti. 

Jadi ini diselaraskan bebas daripada satu sama lain. Langkah RCU dengan tegas selaras berbunyi. OK, jadi jika anda mengatakan saya mahu 1000 RCU ini mereka adalah ketat konsisten, mereka adalah konsisten berbunyi. Jika anda mengatakan saya mahu akhirnya konsisten berbunyi, anda boleh peruntukan 1000 Ini RCU, anda akan untuk mendapatkan 2000 akhirnya konsisten berbunyi. Dan separuh harga bagi mereka akhirnya terdiri dalam membaca. 

Sekali lagi, diselaraskan bebas daripada satu sama lain. Dan mereka mempunyai throughput-- yang Jika anda mengambil 100% daripada RCU anda, anda tidak akan memberi kesan kepada adanya hak-hak anda. Jadi mereka benar-benar bebas daripada satu sama lain. Baiklah, jadi salah satu daripada perkara-perkara yang Saya nyatakan secara ringkas telah pendikitan. Pendikitan buruk. Pendikitan menunjukkan tidak baik tidak SQL. Terdapat beberapa perkara yang boleh kita lakukan untuk membantu anda mengurangkan pendikit yang anda alami. Tetapi penyelesaian terbaik kepada ini adalah mari kita yang melihat apa yang anda lakukan, kerana terdapat satu anti corak dalam bermain di sini. 

Perkara-perkara ini, perkara seperti tidak seragam bebanan kerja, kunci panas, partition panas. Saya memukul ruang kunci tertentu keras untuk beberapa sebab tertentu. Kenapa saya berbuat demikian? Mari kita memikirkan yang keluar. Saya mencampurkan data panas saya dengan data sejuk. Saya membiarkan jadual saya mendapatkan besar, tetapi ada benar-benar hanya beberapa subset data itu benar-benar menarik bagi saya. Jadi untuk log data, sebagai contoh, banyak pelanggan, mereka mendapatkan log data setiap hari. Mereka mendapat sejumlah besar data log. 

Jika anda hanya lambakan semua log yang data ke dalam satu meja besar, dari masa ke masa jadual yang akan mendapatkan besar-besaran. Tetapi saya benar-benar hanya berminat untuk 24 jam yang lalu, tujuh hari yang lalu, 30 hari yang lalu. Apa sahaja tingkap masa yang saya minat mencari untuk acara yang mengganggu saya, atau Sekiranya yang menarik bagi saya, itulah kali tetingkap itu sahaja yang saya perlukan. Jadi mengapa saya meletakkan 10 tahun bernilai log data dalam jadual? Apa yang menyebabkan adalah meja serpihan. 

Ia mendapat besar. Ia mula merebak seluruh beribu-ribu nod. Dan kerana keupayaan anda adalah begitu rendah, anda sebenarnya mengadar menghadkan pada setiap salah satu nod individu. Jadi mari kita mula melihat bagaimana kita melancarkan jadual yang lebih. Bagaimana kita menguruskan data yang sedikit lebih baik untuk mengelakkan masalah ini. Dan apa yang kelihatan seperti? Ini adalah apa yang kelihatan seperti. Inilah yang buruk NoSQL kelihatan seperti. 

Saya mendapat kunci yang panas di sini. Jika anda melihat di sebelah sini, semua ini adalah partition saya. Saya mendapat 16 partition di sini pada pangkalan data telefon ini. Kami melakukannya sepanjang masa. Saya menjalankan ini untuk pelanggan-pelanggan semasa. Ia dipanggil peta haba. Peta haba memberitahu saya bagaimana anda mengakses ruang kunci anda. Dan apa ini memberitahu saya adalah bahawa ada satu hash tertentu bahawa lelaki ini suka yang banyak sekali, kerana dia memukul ia benar-benar, benar-benar keras. 

Jadi biru yang bagus. Kami suka biru. Kami tidak suka merah. Di mana tekanan Merah yang mendapat sehingga 100%. 100%, kini anda akan musnah. Jadi setiap kali anda melihat apa-apa garis merah seperti this-- dan ia bukan hanya Dynamo DB-- setiap pangkalan data NoSQL mempunyai masalah ini. Terdapat anti-corak yang boleh memandu jenis keadaan. Apa yang saya lakukan ialah saya bekerja dengan pelanggan untuk mengurangkan keadaan ini. 

Dan apa yang kelihatan seperti? Dan ini adalah mendapatkan yang terbaik daripada Dynamo DB pemprosesan, tetapi ia benar-benar mendapat yang terbaik daripada NoSQL. Ini tidak terhad kepada Dynamo. Ini adalah saya definitely-- pernah bekerja di Mongo. Saya biasa dengan platform NoSQL banyak. Setiap orang mempunyai jenis-jenis ini masalah utama panas. Untuk mendapatkan yang terbaik daripada apa-apa NoSQL pangkalan data, khususnya Dynamo DB, anda ingin membuat jadual di mana elemen utama hash mempunyai sebilangan besar nilai-nilai yang berbeza, tahap yang tinggi cardinality. Kerana itu bermakna saya menulis kepada banyak baldi yang berbeza. 

Semakin baldi Saya bertulis kepada, semakin besar kemungkinan Saya untuk menyebarkan beban menulis atau membaca memuatkan keluar di beberapa nod, semakin besar kemungkinan saya mempunyai pemprosesan yang tinggi di atas meja. Dan kemudian saya mahu nilai-nilai sebagai diminta agak sama rata dari masa ke masa dan seragam sebagai rawak yang mungkin. Nah, itu adalah jenis yang menarik, kerana saya tidak boleh benar-benar kawalan apabila pengguna datang. Jadi cukup untuk mengatakan, jika kita menyebarkan perkara di seluruh ruang utama, kita mungkin akan berada dalam keadaan yang lebih baik. 

Ada yang tertentu jumlah masa penghantaran bahawa anda tidak akan sebagai kawalan dapat. Tetapi mereka adalah benar-benar dua dimensi yang kita ada, ruang, akses sama rata penyebaran, masa, permintaan yang tiba sama rata jarak dalam masa. Dan jika kedua-dua syarat-syarat dipenuhi, maka itulah apa yang ia akan kelihatan seperti. Ini jauh lebih bagus. Kami benar-benar gembira di sini. Kami mempunyai corak akses yang sangat walaupun. Ya, mungkin anda mendapat sedikit tekanan setiap sekarang dan kemudian, tetapi tiada apa yang benar-benar terlalu luas. Jadi ia adalah menakjubkan berapa banyak kali, apabila saya bekerja dengan pelanggan, bahawa graf pertama dengan merah besar bar dan semua yang hodoh kuning itu di seluruh tempat, kita mendapatkan dilakukan dengan senaman selepas beberapa bulan semula seni bina, mereka berjalan yang sama beban kerja pada beban yang sama. Dan ini adalah apa yang ia kelihatan seperti sekarang. Jadi apa yang anda dapat dengan NoSQL ialah skema data yang sememangnya terikat kepada pola capaian. 

Dan anda boleh mengoptimumkan bahawa skema data untuk menyokong corak akses. Jika tidak, maka anda akan untuk melihat orang-orang jenis masalah dengan orang-orang kunci panas. 

PENONTON: Sebenarnya, tidak dapat tidak beberapa tempat akan menjadi lebih panas daripada yang lain. 

RICK Houlihan: Sentiasa. Sentiasa. Ya, maksud saya selalu ada a-- dan sekali lagi, ada beberapa corak reka bentuk kita akan mendapat melalui yang akan bercakap tentang bagaimana anda berurusan dengan ini pengagregatan super besar. Maksud saya, saya perlu mempunyai mereka, bagaimana kita berurusan dengan mereka? Saya mendapat kes penggunaan yang cukup baik yang kita akan bercakap tentang untuk itu. 

Baiklah, jadi mari kita bercakap tentang beberapa pelanggan kini. Orang-orang ini AdRoll. Saya tidak tahu jika anda biasa dengan AdRoll. Anda mungkin melihat mereka banyak pada pelayar. Mereka iklan semula sasaran, mereka perniagaan terbesar mensasarkan semula iklan di luar sana. Mereka biasanya kerap dilanggar 60 bilion urus niaga setiap hari. Yang mereka lakukan lebih sejuta transaksi sesaat. Mereka telah mendapat jadual agak mudah struktur, meja paling sibuk. Ia pada dasarnya hanya utama hash adalah cookie, julat adalah demografi kategori, dan kemudian sifat yang ketiga ialah skor. 

Oleh itu, kita semua mempunyai kuki dalam pelayar kami dari lelaki ini. Dan apabila anda pergi ke yang mengambil bahagian saudagar, mereka pada dasarnya skor anda seluruh pelbagai kategori demografi. Apabila anda pergi ke laman web dan anda mengatakan saya mahu melihat ad-- ini atau pada dasarnya anda tidak mengatakan bahawa- tetapi apabila anda pergi ke laman web mereka berkata anda mahu melihat iklan ini. Dan mereka pergi mendapatkan iklan dari AdRoll. AdRoll kelihatan anda di atas meja mereka. Mereka mendapati cookie anda. Pengiklan memberitahu mereka, saya mahu seseorang siapa yang pertengahan umur, Lelaki berusia 40 tahun, ke dalam sukan. Dan mereka skor anda pada mereka demografi dan mereka membuat keputusan sama ada atau tidak itu adalah satu iklan yang baik untuk anda. 

Sekarang mereka mempunyai SLA dengan pembekal pengiklanan mereka untuk menyediakan sub-10 milisaat tindak balas pada setiap permintaan tunggal. Jadi mereka menggunakan Dynamo DB untuk ini. Mereka memukul kita juta permintaan sesaat. Mereka dapat melakukan semua mereka lookup, triage semua data itu, dan mendapatkan yang mengandungi pautan add kembali kepada yang pengiklan di bawah 10 milisaat. Ia benar-benar cukup luar biasa pelaksanaan yang mereka ada. 

Lelaki-lelaki ini actually-- adakah ini semua. Saya tidak pasti jika ia lelaki ini. Mungkin lelaki ini. Pada dasarnya memberitahu us-- tidak, saya tidak fikir ia adalah mereka. Saya rasa ia adalah orang lain. Saya bekerja dengan pelanggan yang memberitahu saya bahawa sekarang bahawa mereka telah pergi ke Dynamo DB, mereka menghabiskan lebih banyak wang ke atas makanan ringan untuk pasukan pembangunan mereka setiap bulan daripada apa yang mereka belanjakan untuk pangkalan data mereka. Jadi ia akan memberikan anda idea penjimatan kos yang anda boleh mendapatkan di Dynamo DB adalah besar. Baiklah, dropcam yang syarikat lain. Lelaki ini adalah jenis daripada- jika anda berfikir internet perkara, dropcam pada dasarnya internet video keselamatan. Anda meletakkan kamera anda di luar sana. Kamera mempunyai pengesan pergerakan. Seseorang datang bersama-sama, mencetuskan titik kiu. Kamera bermula rakaman untuk sementara sehingga ia tidak mengesan apa-apa usul lagi. Meletakkan video yang di internet. 

Dropcam adalah sebuah syarikat yang pada dasarnya bertukar kepada Dynamo DB kerana mereka telah mengalami kesakitan yang semakin meningkat besar. Dan apa yang mereka memberitahu kami, tiba-tiba petabyte data. Mereka tidak tahu perkhidmatan mereka akan menjadi begitu berjaya. Lebih video masuk daripada YouTube adalah apa yang lelaki ini telah mendapat. Mereka menggunakan DynamoDB untuk mengesan semua metadata pada semua mata video mereka utama. 

Supaya mereka mempunyai S3 baldi mereka menolak semua artifak binari ke dalam. Dan kemudian mereka mempunyai Rekod Dynamo DB yang menunjukkan orang kepada orang-orang S3 tiga objek. Apabila mereka perlu melihat video, mereka melihat ke atas rekod dalam Dynamo DB. Mereka klik pautan. Mereka tarik turun video dari S3. Jadi itulah jenis apa ini kelihatan seperti. Dan ini adalah lurus dari pasukan mereka. 

Dynamo DB mengurangkan mereka masa penghantaran untuk acara-acara video lima hingga 10 saat. Di kedai hubungan lama mereka, mereka selalu perlu pergi dan melaksanakan beberapa pertanyaan kompleks untuk angka mana video untuk menarik ke bawah, kepada kurang daripada 50 milisaat. Jadi ia adalah menakjubkan, yang menakjubkan prestasi berapa banyak anda boleh mendapatkan apabila anda mengoptimumkan dan anda menala pangkalan data asas untuk menyokong corak capaian. Halfbrick, lelaki ini, apa yang ia, Fruit Ninja saya rasa perkara mereka. Bahawa semua berjalan pada Dynamo DB. Dan lelaki ini, mereka yang besar pasukan pembangunan, pembangunan yang besar kedai. 

Bukan pasukan ops baik. Mereka tidak mempunyai banyak sumber operasi. Mereka bergelut cuba untuk menjaga infrastruktur permohonan mereka sehingga dan berjalan. Mereka datang kepada kami. Mereka melihat bahawa Dynamo DB. Mereka berkata, itu untuk kita. Mereka membina keseluruhan mereka rangka kerja permohonan di atasnya. Beberapa komen benar-benar baik di sini dari pasukan kepada keupayaan mereka kini memberi tumpuan kepada bangunan permainan dan tidak perlu mengekalkan infrastruktur, yang telah menjadi jumlah yang sangat besar overhed untuk pasukan mereka. Jadi ini adalah sesuatu yang bahawa- manfaat yang anda dapat daripada Dynamo DB. 

Baiklah, masuk ke pemodelan data di sini. Dan kita bercakap sedikit tentang yang satu ini kepada satu, satu kepada ramai, dan banyak kepada hubungan jenis banyak. Dan bagaimana anda mengekalkan mereka yang Dynamo. Dalam Dynamo DB kita gunakan indeks, amnya, untuk memutarkan data daripada satu rasa yang lain. Kekunci hash, kunci pelbagai, dan indeks. 

Dalam khusus ini Sebagai contoh, seperti kebanyakan negeri mempunyai keperluan pelesenan yang hanya satu lesen memandu seorang. Anda tidak boleh pergi untuk mendapatkan dua pemandu lesen di negeri Boston. Saya tidak boleh melakukannya di Texas. Itulah jenis cara ia. Dan sebagainya di DMV, kami mempunyai lookup, kita mahu melihat ke atas lesen memandu dengan nombor keselamatan sosial. Saya mahu melihat ke atas butiran pengguna dengan jumlah lesen pemandu. 

Oleh itu, kita mungkin mempunyai jadual pengguna yang mempunyai kunci hash pada nombor siri, atau nombor keselamatan sosial, dan pelbagai ciri-ciri yang ditakrifkan pada item. Sekarang bahawa jadual saya boleh menentukan GSI yang lambungan bahawa sekitar yang mengatakan saya mahu kekunci hash pada lesen itu dan kemudian semua barang-barang lain. Sekarang jika saya ingin bertanya dan mencari nombor lesen bagi mana-mana sosial diberikan Nombor keselamatan, saya boleh query meja utama. 

Jika saya ingin bertanya dan saya mahu untuk mendapatkan keselamatan sosial nombor atau sifat-sifat lain oleh nombor lesen, saya boleh query GSI. Model yang adalah salah satu yang untuk satu hubungan. Hanya GSI sangat mudah, flip perkara-perkara di sekeliling. Sekarang, bercakap mengenai satu kepada ramai. Satu hingga banyak pada dasarnya utama pelbagai hash anda. Di mana kita akan mendapat banyak dengan ini kes penggunaan adalah monitor data. Data monitor datang dalam biasa selang, seperti internet perkara. Kami sentiasa mendapat semua ini rekod yang masuk sepanjang masa. 

Dan saya mahu untuk mencari semua bacaan antara tempoh masa yang tertentu. Ia adalah satu pertanyaan yang biasa di infrastruktur pemantauan. Cara pergi tentang itu adalah untuk mencari Struktur jadual mudah, satu jadual. Saya telah mendapat jadual ukuran peranti dengan kunci hash pada ID peranti. Dan saya mempunyai kunci pelbagai pada tanda waktu, atau dalam kes ini, epik. Dan yang membolehkan saya melaksanakan kompleks pertanyaan terhadap bahawa kunci pelbagai dan kembali rekod-rekod yang relatif kepada hasil menetapkan bahawa saya cari. Dan ia membina satu yang hubungan banyak ke dalam jadual primer menggunakan utama hash, pelbagai struktur utama. 

Supaya adalah jenis dibina ke dalam jadual di Dynamo DB. Apabila saya menentukan hash dan pelbagai t meja, Saya mentakrifkan satu hingga hubungan banyak. Ia adalah satu hubungan ibu bapa dan anak. 

Mari kita bercakap tentang banyak kepada banyak hubungan. Dan sebagai contoh khusus ini, sekali lagi, kita akan menggunakan ini GSI. Dan mari kita bercakap tentang permainan senario di mana saya mempunyai pengguna yang dinyatakan. Saya ingin mengetahui semua permainan yang dia mendaftar untuk atau bermain di. Dan untuk permainan yang diberikan, saya hendak mencari semua pengguna. Jadi bagaimana saya melakukannya? Saya permainan meja pengguna, saya akan mempunyai kunci hash ID pengguna dan kunci pelbagai permainan. 

Jadi pengguna boleh mempunyai beberapa permainan. Ia adalah satu hubungan antara banyak pengguna dan permainan dia bermain. Dan kemudian pada GSI, Saya akan flip sekitar itu. Saya akan hash kepada permainan dan Saya akan berkisar kepada pengguna. Jadi jika saya mahu untuk mendapatkan semua permainan pengguna bermain di, Saya akan bertanya meja utama. Jika saya mahu untuk mendapatkan semua pengguna yang bermain sesuatu permainan, Saya mempersoalkan GSI. Jadi anda lihat bagaimana kita melakukan ini? Anda membina ini GSI untuk menyokong kes guna, permohonan itu, akses corak, permohonan itu. 

Jika saya perlu bertanya pada dimensi ini, mari saya membuat indeks dimensi itu. Jika saya tidak berbuat demikian, saya tidak peduli. Dan bergantung kepada kes penggunaan, saya mungkin perlu indeks atau saya mungkin tidak. Jika ia adalah salah satu yang mudah untuk banyak, jadual utama adalah baik. Jika saya perlukan untuk melakukan perkara-yang banyak, atau saya perlu untuk melakukan satu kepada orang, maka mungkin saya perlu untuk kedua indeks. Jadi ia bergantung kepada apa yang saya cuba lakukan dan apa yang saya cuba untuk mendapatkan dicapai. 

Mungkin saya tidak akan menghabiskan terlalu banyak masa bercakap mengenai dokumen. Ini semakin sedikit, mungkin, lebih dalam dari kita perlu pergi ke dalam. Mari kita bercakap sedikit ungkapan pertanyaan mengenai kaya. Jadi dalam Dynamo DB kita ada keupayaan untuk mewujudkan apa yang kita panggil ungkapan unjuran. Ungkapan unjuran adalah semata-mata memilih bidang atau nilai-nilai yang anda mahu untuk dipaparkan. OK, jadi saya membuat pilihan. Saya membuat pertanyaan menentang Dynamo DB. Dan saya berkata, anda tahu apa, persembahan saya hanya lima ulasan bintang untuk produk ini tertentu. Jadi itu sahaja yang saya mahu lihat. Saya tidak mahu melihat semua sifat-sifat lain berturut-turut, Saya hanya mahu melihat ini. Ia hanya seperti dalam SQL apabila anda mengatakan pilih bintang atau dari jadual, anda mendapat segala-galanya. Apabila saya mengatakan pilih nama daripada meja, saya hanya mendapat satu atribut. Ia adalah jenis yang sama perkara dalam Dynamo DB atau lain pangkalan data yang NoSQL. Ungkapan penapis membolehkan saya pada dasarnya mengurangkan hasil yang ditetapkan. Jadi saya membuat pertanyaan. Pertanyaan boleh kembali dengan 500 item. Tetapi saya hanya mahu perkara-perkara yang mempunyai sifat yang mengatakan ini. OK, jadi mari kita menapis item-item yang tidak sepadan dengan pertanyaan tersebut. Jadi kita mempunyai ungkapan penapis. 

Ungkapan penapis boleh dijalankan di mana-mana atribut. Mereka tidak suka pertanyaan yang pelbagai. Mengemukakan pertanyaan lebih selektif. Pertanyaan penapis memerlukan saya pergi mendapatkan keseluruhan keputusan ditetapkan dan kemudian mengukir data yang saya tidak mahu. Mengapa yang penting? Kerana saya membaca semuanya. Dalam pertanyaan, saya akan membaca dan ia akan menjadi gergasi mengenai data. Dan kemudian saya akan mengukir apa yang saya perlukan. Dan jika saya hanya mengukir beberapa baris, maka tidak apa-apa. Ia tidak begitu cekap. 

Tetapi jika saya membaca timbunan keseluruhan data, hanya untuk mengukir satu perkara, kemudian saya akan menjadi lebih baik off menggunakan pelbagai pertanyaan, kerana ia lebih selektif. Ia akan menyelamatkan saya banyak wang, kerana saya membayar untuk pembacaan itu. Jika keputusan yang datang kembali menyeberangi wayar yang mungkin menjadi lebih kecil, tetapi saya membayar untuk membaca. Jadi faham bagaimana anda mendapat data. Itu sangat penting dalam Dynamo DB. 

Ungkapan bersyarat, ini adalah apa yang anda mungkin memanggil mengunci optimis. Update JIKA EXISTS, atau jika nilai ini bersamaan dengan apa yang saya nyatakan. Sekalipun aku mempunyai cap masa pada rekod, saya mungkin membaca data. Saya mungkin berubah data tersebut. Saya mungkin pergi tulis yang kembali data kepada pangkalan data. Jika seseorang telah mengubah rekod, tanda waktu itu mungkin telah berubah. Dan cara yang bersyarat saya maklumat boleh mengatakan maklumat jika tanda waktu yang sama ini. Atau kemas kini akan gagal kerana seseorang dikemaskini rekod dalam masa yang sama. 

Itulah yang kita panggil mengunci optimis. Ia bermaksud seseorang boleh datang dan mengubahnya, dan saya akan mengesannya apabila saya kembali untuk menulis. Dan kemudian saya sebenarnya boleh membaca bahawa data dan berkata, oh, dia berubah ini. Saya perlu mengambil kira itu. Dan saya boleh mengubah data dalam saya merakam dan memohon kemas kini lain. Jadi, anda boleh menangkap orang-orang tambahan kemas kini yang berlaku antara masa supaya meneliti data dan kali anda mungkin menulis data. 

PENONTON: Dan penapis ungkapan sebenarnya tidak bermakna dalam nombor atau tidak-- 

[Interposing SUARA] RICK Houlihan: Saya tidak akan terlalu banyak ke dalam ini. Ini Adakah kata kunci yang ditempah. Pandangan paun ialah Terpelihara kata kunci dalam Dynamo DB. Setiap pangkalan data mempunyai sendiri Cipta Terpelihara nama-nama untuk koleksi anda tidak boleh menggunakan. Dynamo DB, jika anda menetapkan satu paun di hadapan ini, anda boleh menentukan nama-nama ke atas. Ini adalah nilai yang dirujuk. Ia mungkin tidak sintaks yang terbaik untuk ada di sana untuk perbincangan ini, kerana ia mendapat ke dalam beberapa real-- Saya akan bercakap lebih tentang itu pada tahap yang lebih mendalam. 

Tetapi cukup untuk mengatakan, boleh ini menjadi pertanyaan mengimbas mana mereka views-- atau pandangan pound adalah lebih besar daripada 10. Ia adalah nilai berangka, ya. Jika anda mahu, kita boleh bercakap tentang bahawa selepas perbincangan. Baiklah, jadi kami mendapat ke dalam beberapa senario dalam amalan terbaik di mana kita akan bercakap tentang beberapa aplikasi di sini. Apakah kes guna untuk Dynamo DB. Apakah reka bentuk corak dalam Dynamo DB. 

Dan yang pertama kita akan bercakap tentang adalah internet perkara. Oleh itu, kita mendapat banyak daripada- saya rasa, apa yang kitab itu lebih daripada 50% lalu lintas di internet hari ini sebenarnya dihasilkan oleh mesin, berautomatik, bukan oleh manusia. Maksud saya perkara ini perkara ini yang anda membawa di dalam poket anda, berapa banyak data yang perkara yang sebenarnya menghantar sekitar tanpa anda mengetahui ia adalah benar-benar menakjubkan. Lokasi, Maklumat anda tentang berapa cepat anda akan pergi. Bagaimana anda berfikir Peta Google kerja-kerja apabila mereka memberitahu anda apa lalu lintas yang. Ini kerana terdapat berjuta-juta dan berjuta-juta orang memandu di dengan telefon yang menghantar data di seluruh tempat sepanjang masa. Jadi salah satu daripada perkara-perkara tentang jenis data yang datang dalam, memantau data, sila layari data, data siri masa, adalah ia biasanya hanya menarik untuk sedikit masa. Selepas masa itu, ia tidak begitu menarik. Oleh itu, kita bercakap tentang, jangan biarkan jadual tersebut berkembang tanpa batas. Idea di sini adalah bahawa mungkin saya telah mendapat 24 jam bernilai peristiwa dalam jadual panas saya. Dan bahawa jadual panas akan menjadi diperuntukkan pada kadar yang sangat tinggi, kerana ia mengambil banyak data. Ia mengambil banyak data dalam dan saya membaca banyak. Saya telah mendapat banyak operasi pertanyaan berjalan terhadap data tersebut. 

Selepas 24 jam, hey, anda tahu apa, saya tidak peduli. Jadi mungkin setiap tengah malam saya roll meja saya kepada jadual baru dan saya deprovision jadual ini. Dan saya akan mengambil RCU dan Turun WCU kerana 24 jam kemudian Saya tidak berjalan seperti banyak pertanyaan terhadap data tersebut. Jadi, saya akan menjimatkan wang. Dan mungkin 30 hari kemudian saya tidak perlu untuk mengambil berat tentang segala-galanya. Saya boleh mengambil ini WCU semua jalan ke bawah kepada satu, kerana anda tahu apa, ia tidak akan untuk ditulis. Data ini adalah 30 hari. Ia tidak pernah berubah. 

Dan ia hampir tidak pernah akan mendapat membaca, jadi mari kita hanya mengambil yang RCU turun ke 10. Dan saya menjimatkan satu tan wang pada ini data, dan hanya membayar untuk data panas saya. Jadi itulah perkara yang penting untuk melihat di ketika anda melihat siri masa data yang datang dalam jumlah. Ini adalah strategi. Sekarang, saya hanya boleh biarkan ia semua pergi ke meja yang sama dan hanya membiarkan jadual yang berkembang. Akhirnya, saya akan melihat isu-isu prestasi. Saya akan perlu untuk memulakan untuk arkib sebahagian dari data di luar jadual, apa yang tidak. 

Mari kita jauh lebih baik mereka bentuk aplikasi anda supaya anda boleh beroperasi cara ini betul. Jadi ia hanya automatik kod aplikasi. Pada tengah malam setiap malam ia bergolek meja. Mungkin apa yang saya perlukan adalah gelongsor tingkap 24 jam selepas data. Kemudian secara tetap saya memanggil data dari meja. Saya memotong ia dengan Cron pekerjaan dan saya meletakkan ia ke dalam jadual lain, apa sahaja yang anda perlukan. Jadi, jika peralihan yang bekerja, yang hebat. Jika tidak, mengurangkan ia. Tetapi mari kita menyimpan data panas jauh dari data sejuk anda. Ia akan menjimatkan banyak wang dan membuat jadual anda lebih berprestasi. Jadi perkara yang akan datang kita akan bercakap tentang adalah katalog produk. Katalog produk adalah kes penggunaan agak biasa. Ini sebenarnya adalah satu corak yang biasa bahawa kita akan melihat dalam pelbagai perkara. Anda tahu, Twitter untuk Sebagai contoh, tweet panas. Semua orang yang datang dan merebut tweet itu. Katalog produk, saya mendapat jualan. Saya mendapat jualan yang panas. Saya mendapat 70,000 permintaan setiap kedua kali untuk produk yang penerangan daripada katalog produk saya. Kami melihat ini di runcit operasi agak sedikit. Jadi bagaimana kita berurusan dengan itu? Tidak ada cara untuk mengatasinya. Semua pengguna saya mahu melihat bahagian yang sama data. Mereka yang datang dalam, serentak. Dan mereka semua membuat permintaan untuk sekeping yang sama data. Ini memberikan saya bahawa kunci panas, yang merah yang besar jalur pada carta saya bahawa kita tidak suka. Dan itulah apa yang kelihatan seperti. Jadi seluruh ruang utama saya Saya mendapat dibelasah dalam perkara itu dijual. Saya mendapat apa-apa di mana pun. 

Bagaimana saya boleh mengatasi masalah ini? Nah, kita meringankan ini dengan cache. Cache, anda meletakkan asasnya merupakan dalam ingatan partition di hadapan pangkalan data. Kami telah berjaya [Didengar] cache, bagaimana anda boleh menyediakan cache anda sendiri, [didengar] cache [? d,?] apa sahaja yang anda mahu. Meletakkan bahawa di hadapan pangkalan data. Dan cara yang anda boleh menyimpan data yang dari orang-orang kunci panas dalam cache yang ruang dan membaca cache. 

Dan kemudian kebanyakan berbunyi anda mula mencari seperti ini. Saya mendapat semua cache ini menjadi asas di sini dan saya tidak perlu lagi apa yang berlaku ke sini kerana pangkalan data sedang duduk di belakang cache dan dibaca tidak keluar. Jika saya menukar data dalam pangkalan data, saya perlu mengemaskini cache. Kita boleh menggunakan sesuatu seperti steams untuk berbuat demikian. Dan saya akan terangkan bagaimana ia berfungsi. Baiklah, mesej. E-mel, kita semua menggunakan e-mel. 

Ini adalah contoh yang cukup baik. Kami telah mendapat beberapa jenis meja mesej. Dan kami mendapat peti masuk dan peti keluar. Inilah yang SQL akan kelihatan suka untuk membina peti masuk itu. Kita jenis menggunakan jenis yang sama daripada strategi untuk menggunakan ini GSI, ini GSI untuk peti masuk saya dan peti keluar saya. Jadi saya mendapat mesej yang mentah akan datang ke dalam jadual mesej saya. Dan pendekatan yang pertama ini mungkin, berkata, OK, tidak ada masalah. Saya telah mendapat mesej yang mentah. Mesej-mesej yang akan datang [didengar], ID mesej, yang hebat. Itulah hash unik saya. Saya akan mewujudkan dua ini GSI, satu untuk peti masuk saya, satu untuk peti keluar saya. Dan perkara pertama yang saya akan lakukan yang saya akan katakan utama hash saya ialah akan menjadi penerima dan Saya akan menguruskan pada tarikh. Ini adalah hebat. Saya mendapat pandangan yang bagus saya di sini. Tetapi ada sedikit masalah di sini. Dan anda menghadapi ini dalam pangkalan data hubungan juga. Mereka dipanggil pembahagian menegak. Anda mahu menyimpan data besar anda jauh dari data kecil anda. 

Dan sebab mengapa adalah kerana saya kena pergi membaca item untuk mendapatkan sifat-sifat. Dan jika badan saya semua di sini, kemudian membaca beberapa barangan jika panjang badan saya adalah dengan purata 256 kilobait setiap satu, matematik mendapat cukup hodoh. Jadi mengatakan saya mahu membaca peti masuk Daud. Peti masuk Daud mempunyai 50 item. Purata dan saiz adalah 256 kilobait. Berikut adalah nisbah penukaran saya bagi ini RCU adalah empat kilobait. 

OK, mari kita pergi dengan akhirnya konsisten berbunyi. Saya masih makan 1600 RCU ini hanya untuk membaca peti masuk Daud. Ouch. OK, sekarang mari kita berfikir tentang bagaimana aplikasi ini berfungsi. Jika saya dalam aplikasi e-mel dan Saya melihat peti masuk saya, dan saya melihat mayat setiap mesej, tidak, saya melihat ringkasan. Saya melihat hanya tajuk. Jadi mari kita membina struktur jadual yang kelihatan seperti itu. 

Jadi di sini adalah maklumat yang bahawa aliran kerja saya memerlukan. Ada dalam peti masuk saya GSI. Ia adalah tarikh, penghantar, subjek, dan kemudian ID mesej, yang menunjukkan kembali ke meja Mesej di mana saya boleh mendapatkan badan. Nah, ini akan menjadi rekod ID. Mereka akan menunjukkan kembali kepada item ID di atas meja Dynamo DB. Setiap indeks sentiasa creates-- sentiasa mempunyai item ID sebagai sebahagian daripada- yang datang dengan indeks. 

Baiklah. PENONTON: Ia memberitahu ia di mana ia disimpan? RICK Houlihan: Ya, ia memberitahu exactly-- itulah apa yang dilakukan. Ia mengatakan inilah rekod semula saya. Dan ia akan menunjukkan kembali kepada rekod semula saya. Tepat sekali. OK, jadi sekarang peti masuk saya ialah sebenarnya jauh lebih kecil. Dan ini sebenarnya menyokong aliran kerja bagi aplikasi e-mel. Jadi email saya, saya hantar. Saya pergi bersama-sama dan saya klik pada mesej, itulah apabila saya perlu pergi mendapatkan badan, kerana saya akan pergi ke pandangan yang berbeza. Jadi, jika anda berfikir tentang jenis MVC daripada rangka kerja, melihat model pengawal. 

Model ini mengandungi data yang diperlukan oleh pandangan dan pengawal berinteraksi dengan. Apabila saya menukar bingkai, apabila Saya menukar perspektif, ia OK untuk kembali ke pelayan dan repopulate model, kerana itulah yang pengguna menjangka. Apabila mereka mengubah pandangan, itu apabila kita boleh kembali kepada pangkalan data. Supaya e-mel, klik. Saya sedang mencari badan. Pergi-balik. Pergi mendapatkan badan. 

Saya membaca banyak kurang data. Saya hanya membaca badan-badan yang David perlu apabila dia memerlukannya. Dan saya tidak terbakar pada tahun 1600 Ini RCU hanya untuk menunjukkan peti masuk beliau. Jadi sekarang bahawa- ini adalah cara yang yang LSI atau GSI-- Saya minta maaf, GSI, akan bekerja keluar. Kami telah mendapat hash kami pada penerima. Kami mempunyai kunci julat pada tarikh tersebut. Dan kami mempunyai ciri-ciri yang dijangka bahawa kita hanya perlu untuk menyokong pandangan. 

Kami berputar bahawa bagi peti keluar. Hash pada penghantar. Dan pada dasarnya, kita ada yang sangat bagus, pandangan bersih. Dan ia kita basically-- mempunyai mesej yang bagus jadual yang yang sedang merebak dengan baik kerana ia hash sahaja, dicincang ID mesej. Dan kita mempunyai dua indeks yang berputar kira meja itu. Baiklah, jadi idea di sini adalah tidak menyimpan data yang besar dan data yang kecil ini bersama-sama. Partition menegak, partition jadual tersebut. Jangan baca data yang anda tidak perlu. Baiklah, permainan. Kita semua suka permainan. Sekurang-kurangnya saya suka permainan itu. Jadi beberapa perkara bahawa kita berurusan dengan apabila kita berfikir tentang permainan, bukan? Perjudian hari ini, terutama bimbit perjudian, adalah tentang pemikiran. Dan saya akan berputar di sini sedikit dari DynamoDB. Saya akan membawa masuk beberapa perbincangan sekitar beberapa teknologi AWS lain. 

Tetapi idea tentang permainan adalah untuk berfikir kira-kira dalam syarat-syarat API, API yang, secara umum, HTTP dan JSON. Ia adalah bagaimana permainan mudah alih jenis berinteraksi dengan hujung belakang mereka. Mereka melakukan JSON posting. Mereka mendapat data, dan itu semua, secara umum, dalam API JSON bagus. 

Perkara seperti mendapatkan kawan-kawan, dapatkan data Leaderboard, pertukaran, kandungan yang dihasilkan pengguna, menolak kembali kepada sistem, ini adalah jenis perkara yang kita akan lakukan. Data aset binari, data ini mungkin tidak duduk dalam pangkalan data. Ini mungkin duduk di dalam kedai objek, bukan? Tetapi pangkalan data akan berakhir memberitahu sistem, memberitahu permohonan itu di mana untuk pergi mendapatkannya. Dan tidak dapat tidak, berbilang pelayan, infrastruktur akhir belakang, dan direka untuk tinggi ketersediaan dan skala. Jadi ini adalah perkara yang kita semua mahu dalam infrastruktur permainan hari ini. 

Oleh itu, mari kita lihat pada apa yang kelihatan seperti. Punya akhir belakang teras, sangat mudah. Kami mempunyai sistem di sini dengan zon ketersediaan berbilang. Kita bercakap tentang AZS sebagai being-- berfikir daripada mereka sebagai pusat-pusat data yang berasingan. Lebih daripada satu pusat data setiap AZ, tetapi itu OK, hanya memikirkan mereka sebagai data yang berasingan pusat-pusat yang secara geografi dan kesalahan terpencil. 

Kita akan mempunyai contoh pasangan EC2. Kita akan mempunyai beberapa pelayan akhir belakang. Mungkin jika anda berada warisan seni bina, kami menggunakan apa yang kita panggil RDS, perkhidmatan pangkalan data hubungan. Boleh MSSQL, MySQL, atau sesuatu seperti itu. Ini adalah cara yang aplikasi banyak adalah direka hari ini. 

Baik kita mungkin mahu pergi dengan ini adalah apabila kami meningkatkan keluar. Kami akan pergi ke depan dan meletakkan baldi S3 yang di atas sana. Dan baldi S3, bukan untuk sehingga orang-orang objek dari servers-- kami kita boleh berbuat demikian. Anda meletakkan semua binari anda objek pada pelayan anda dan anda boleh menggunakan pelayan mereka contoh untuk berkhidmat data atas. Tetapi itu cukup mahal. 

Cara yang lebih baik lakukan adalah pergi ke depan dan meletakkan objek dalam baldi S3. S3 adalah repositori objek. Ia dibina khusus untuk berkhidmat sehingga jenis perkara. Dan orang-orang permintaan pelanggan langsung dari orang-orang baldi objek, melepaskan pelayan. Jadi kami mula mengikut skala di sini. 

Sekarang kita mendapat pengguna di seluruh dunia. Saya mendapat pengguna. Saya perlu mempunyai kandungan tempatan terletak berhampiran dengan pengguna ini, bukan? Saya telah membuat baldi S3 sebagai repositori sumber saya. Dan saya akan hadapan itu dengan pengagihan Cloudfront. 

Cloudfront adalah CD dan kandungan penghantaran rangkaian. Pada asasnya, ia mengambil data yang anda tentukan dan cache ia di seluruh internet jadi pengguna mana-mana boleh mempunyai tindak balas yang sangat cepat apabila mereka meminta objek. 

Jadi anda mendapat idea. Anda jenis memanfaatkan semua aspek AWS di sini untuk mendapatkan ini dilakukan. Dan akhirnya, kita buang dalam kumpulan bersisik automatik. Jadi keadaan AC2 kami pelayan permainan kami, kerana mereka mula untuk mendapatkan sibuk dan lebih sibuk dan sibuk, mereka hanya akan berputar lain contoh, berputar contoh lain, berputar contoh lain. Jadi teknologi AWS mempunyai, ia membolehkan anda menentukan parameter sekitar yang pelayan anda akan berkembang. Jadi, anda boleh mempunyai nombor n pelayan di luar sana pada bila-bila masa. Dan jika beban anda hilang, mereka akan mengecut, jumlah itu akan mengecut. Dan jika beban kembali, ia akan tumbuh semula keluar, anjal. 

Jadi ini kelihatan besar. Kami mempunyai banyak kes EC2. Kita boleh meletakkan cache dalam hadapan pangkalan data, cuba dan mempercepatkan pangkalan data. Titik tekanan seterusnya biasanya orang melihat adalah mereka mengikut skala permainan yang menggunakan sistem pangkalan data hubungan. Jeez, pangkalan data prestasi yang amat dahsyat. Bagaimana kita meningkatkan itu? Mari kita cuba meletakkan cache di hadapan itu. 

Nah, cache tidak berfungsi begitu besar dalam permainan, bukan? Untuk permainan, menulis adalah menyakitkan. Permainan sangat naik berat. Cache tidak berfungsi apabila anda berada menulis berat kerana kamu sentiasa mendapat untuk mengemaskini cache. Anda mengemaskini cache, ia tidak relevan untuk caching. Ini sebenarnya hanya kerja tambahan. 

Jadi di mana kita pergi di sini? Anda telah mendapat kesesakan besar di bawah sana dalam pangkalan data. Dan tempat untuk pergi jelas adalah pembahagian. Pemisahan tidak mudah untuk lakukan apabila anda berurusan dengan pangkalan data hubungan. Dengan pangkalan data hubungan, anda bertanggungjawab untuk mengurus, berkesan, ruang utama. Anda katakan pengguna antara A dan M pergi di sini, di antara N dan Z pergi ke sana. Dan anda beralih seluruh permohonan. Jadi, anda sedang berhadapan dengan ini sumber data partition. Anda mempunyai kekangan transaksi yang tidak meliputi sekatan. Anda telah mendapat semua jenis messiness bahawa anda berurusan dengan di bawah sana cuba menangani mendaki keluar dan membina infrastruktur yang lebih besar. Ia hanya tidak seronok. 

PENONTON: Jadi, adakah anda mengatakan bahawa meningkatkan mata sumber mempercepatkan proses? RICK Houlihan: Meningkatkan? Mata Sumber: PENONTON. RICK Houlihan: Mata Source? PENONTON: Dari maklumat itu, di mana maklumat itu datang dari? RICK Houlihan: No. Apa yang saya katakan ialah meningkatkan beberapa partition di kedai data meningkatkan daya pemprosesan. Jadi apa yang berlaku di sini adalah pengguna mula contoh EC2 yang di sini, baik, jika saya memerlukan pengguna itulah A hingga M, saya akan pergi di sini. Dari N untuk lulus, saya akan pergi di sini. Dari P ke Z, saya akan pergi di sini. 

PENONTON: OK, mereka jadi orang-orang yang semua disimpan di dalam nod yang berbeza? 

RICK Houlihan: Ya. Fikirkan ini sebagai silo data yang berbeza. Jadi, anda mempunyai untuk melakukan ini. Jika anda cuba untuk melakukan ini, jika anda cuba mengikut skala di atas platform hubungan, ini adalah apa yang anda lakukan. Anda mengambil data dan anda memotong ke bawah. Dan anda pembahagian ia merentasi berbilang kejadian pangkalan data. Dan anda menguruskan semua yang pada peringkat permohonan. Ia tidak menyeronokkan. Jadi apa yang kita mahu pergi? Kami mahu pergi DynamoDB, berjaya sepenuhnya, Menyimpan data NoSQL, penyediaan pemprosesan. Kami menggunakan indeks menengah. Ia pada dasarnya HTTP API dan termasuk sokongan dokumen. Jadi anda tidak perlu bimbang mengenai mana-mana pembahagian itu. Kami melakukan semuanya untuk anda. Oleh sebab itu, sebaliknya, anda hanya menulis ke meja. Jika jadual perlu dibahagikan, yang berlaku di belakang tabir. Anda sama sekali terasing itu sebagai pemaju. Jadi mari kita bercakap tentang Banyak kes-kes penggunaan yang kita berjalan ke dalam permainan, biasa senario perjudian, Leaderboard. Jadi anda mempunyai pengguna yang datang, yang BoardNames bahawa mereka pada, markah untuk pengguna ini. Kita mungkin sambil berbincang mengenai UserID, dan kemudian kita mempunyai pelbagai kepada permainan. Jadi setiap pengguna mahu melihat semua permainan dia bermain dan skor tertinggi beliau di semua permainan. Jadi itulah Leaderboard peribadinya. 

Sekarang saya mahu pergi dalam dan saya mahu get-- jadi saya mendapatkan ini leaderboards peribadi. Apa yang saya mahu lakukan adalah pergi mendapatkan skor tertinggi di semua pengguna. Jadi bagaimana saya melakukannya? Apabila rekod saya dicincang pada UserID yang, antara dalam permainan, juga saya akan pergi ke hadapan dan menyusun semula, buat GSI, dan saya akan menyusun semula data tersebut. 

Sekarang saya akan untuk hash pada BoardName, yang merupakan permainan. Dan saya akan berkisar pada skor tertinggi. Dan sekarang saya telah membuat baldi yang berbeza. Saya menggunakan jadual yang sama, data item yang sama. Tetapi saya mewujudkan satu baldi yang memberikan saya satu kesatuan skor tertinggi oleh permainan. 

Dan saya boleh query jadual yang untuk mendapatkan maklumat tersebut. Jadi saya telah menetapkan bahawa corak Pertanyaan sehingga disokong oleh indeks menengah. Sekarang mereka boleh disusun mengikut BoardName dan disusun mengikut SkorTertinggi, bergantung kepada. Jadi anda lihat, ini adalah jenis daripada kes-kes penggunaan anda dalam permainan. Satu lagi kes penggunaan yang baik kita akan mendapat dalam permainan adalah anugerah dan siapa yang memenangi anugerah. Dan ini adalah kes penggunaan yang besar di mana kita panggil indeks jarang. Indeks jarang adalah keupayaan untuk menjana indeks yang tidak semestinya mengandungi setiap item di atas meja. Dan mengapa tidak? Oleh kerana sifat yang yang yang yang diindeks tidak wujud pada setiap item. 

Jadi dalam khusus ini menggunakan kes, saya berkata, anda tahu apa, saya akan mewujudkan satu sifat yang dikenali sebagai Anugerah. Dan saya akan memberikan setiap pengguna yang mempunyai satu anugerah yang atribut. Pengguna yang tidak mempunyai Anugerah ini tidak akan mempunyai sifat itu. Jadi, apabila saya mencipta indeks, satu-satunya pengguna yang akan menunjukkan dalam indeks adalah orang-orang yang benar-benar telah memenangi anugerah. Jadi itu adalah satu cara yang baik untuk dapat untuk mewujudkan indeks yang ditapis sangat, sangat terpilih yang tidak perlu indeks keseluruhan meja. 

Jadi, kita semakin rendah pada masa di sini. Saya akan pergi ke depan dan skip keluar dan skip senario ini. Bercakap sedikit about-- 

PENONTON: Boleh saya tanya satu soalan yang cepat? Satu adalah menulis berat? RICK Houlihan: Apa? PENONTON: Tulis berat. RICK Houlihan: Tulis berat. Supaya aku dapat melihat. 

PENONTON: Atau adakah yang tidak sesuatu yang anda boleh hanya suara ke dalam masa beberapa saat? RICK Houlihan: Kami pergi melalui senario pengundian. Ia bukan yang buruk. Adakah anda semua mempunyai beberapa minit? OKEY. 

Oleh itu, kita akan bercakap tentang mengundi. Jadi mengundi masa sebenar, kita ada keperluan untuk mengundi. Keperluan adalah bahawa kita membenarkan setiap orang untuk mengundi hanya sekali. Kami mahu tiada siapa yang dapat untuk menukar undi mereka. Kami ingin mengumpul masa nyata dan analisis untuk demografi bahawa kita akan menjadi dipaparkan kepada pengguna di laman web ini. 

Fikirkan senario ini. Kami bekerja banyak realiti TV menunjukkan di mana mereka melakukan jenis ini tepat perkara. Jadi, anda boleh memikirkan senario, kita ada berjuta-juta dan berjuta-juta gadis-gadis remaja di sana dengan telefon bimbit mereka dan mengundi, dan mengundi, dan mengundi untuk siapa mereka mencari untuk menjadi yang paling popular. Jadi ini adalah sebahagian daripada keperluan kita kehabisan. 

Dan sebagainya yang mula-mula mengambil dalam menyelesaikan masalah ini adalah untuk membina aplikasi yang sangat mudah. Jadi saya telah mendapat aplikasi ini. Saya mempunyai beberapa pengundi di luar sana. Mereka datang, mereka memukul aplikasi pengundian. Saya telah mendapat beberapa meja undi mentah Saya hanya akan membuang undi mereka ke dalam. Saya akan mempunyai beberapa agregat meja undi yang akan melakukan analisis dan demografi saya, dan kita akan meletakkan semua ini di sana. 

Dan ini adalah besar. Hidup ini indah. Hidup yang baik sehingga kita ketahui bahawa selalu ada hanya satu atau dua orang yang popular di dalam pilihan raya. Terdapat hanya satu atau dua perkara bahawa orang benar-benar mengambil berat tentang. Dan jika anda mengundi skala, tiba-tiba saya akan memalu neraka daripada dua calon, satu atau dua calon. Satu jumlah yang sangat terhad barangan orang mencari untuk menjadi popular. 

Ini bukan corak reka bentuk yang baik. Ini sebenarnya corak reka bentuk yang sangat buruk kerana ia mewujudkan apa yang kita bercakap tentang yang merupakan kunci panas. Kunci panas adalah sesuatu yang kita tidak suka. 

Jadi bagaimana kita menetapkan bahawa? Dan benar-benar, cara untuk menetapkan ini adalah dengan mengambil mereka baldi calon dan bagi setiap calon kita ada, kita akan menambah nilai secara rawak, sesuatu yang kita tahu, rawak nilai antara satu dan 100, antara 100 dan 1,000, atau di antara satu dan 1,000, Walau bagaimanapun banyak nilai-nilai rawak anda mahu menambah ke akhir calon itu. 

Dan apa yang telah saya benar-benar dilakukan kemudian? Jika saya menggunakan ID calon sebagai baldi untuk undi agregat, jika saya telah menambah rawak nombor untuk akhir itu, Saya telah membuat kini 10 baldi, yang ratus baldi, seribu baldi bahawa saya menjumlahkan undi di seluruh. 

Jadi saya mempunyai berjuta-juta, dan berjuta-juta, dan berjuta-juta rekod datang untuk calon-calon ini, saya kini sedang merebak mereka undi seluruh Calon a_1 melalui Calon A_100, kerana setiap kali undi masuk, Saya menjana rawak nilai antara satu hingga 100. Saya tacking ia ke akhir calon orang itu mengundi. Saya membuangnya ke dalam baldi itu. 

Kini di bahagian belakang, saya tahu bahawa saya mendapat seratus baldi. Jadi, apabila saya mahu pergi ke depan dan agregat undi, Saya membaca dari semua orang-orang baldi. Jadi saya pergi ke hadapan dan menambah. Dan kemudian saya berselerak berkumpul di mana saya pergi keluar dan berkata hey, anda tahu apa, kekunci ini calon ruang adalah lebih seratus baldi. Saya akan mengumpulkan semua undi dari orang-ratus baldi. Saya akan agregat mereka dan saya akan berkata, Calon kini mempunyai jumlah undian x. 

Sekarang kedua-dua tulisan pertanyaan dan Pertanyaan membaca adalah baik diedarkan kerana saya menulis seluruh dan saya membaca seluruh beratus-ratus kunci. Saya tidak menulis dan membaca seluruh satu kunci sekarang. Jadi itulah corak yang besar. 

Ini sebenarnya mungkin salah reka bentuk yang paling penting corak untuk skala dalam NoSQL. Anda akan melihat jenis ini corak reka bentuk dalam setiap rasa. MongoDB, DynamoDB, ia tidak perkara, kita semua mempunyai untuk melakukan ini. Kerana apabila anda berurusan dengan orang-kesatuan yang besar, anda perlu memikirkan satu cara untuk menyebarkan mereka di seluruh baldi. Jadi ini adalah cara yang anda lakukan itu. Baiklah, jadi apa yang anda lakukan sekarang adalah anda berdagang off dibaca kos untuk menulis skala. Kos membaca saya ialah kompleks yang lebih sedikit dan saya perlu pergi baca dari ratus baldi dan bukan satu. Tetapi saya dapat menulis. Dan pemprosesan saya, saya tulis pemprosesan yang luar biasa. Jadi ia biasanya berharga teknik untuk mendaki DynamoDB, atau mana-mana pangkalan data NoSQL untuk perkara itu. Oleh itu, kita digambarkan bagaimana untuk skala itu. Dan kita digambarkan bagaimana untuk menghapuskan kunci panas kami. Dan ini adalah hebat. Dan kami mendapat sistem ini bagus. Dan ia memberikan kita mengundi sangat betul kerana kita mempunyai undi rekod de-korban penipuan. Ia dibina ke dalam DynamoDB. Kita bercakap tentang hak-hak bersyarat. 

Apabila pengundi masuk, meletakkan sisipan di atas meja, mereka memasukkan ID pengundi mereka, jika mereka cuba untuk memasukkan undi lain, Saya melakukan tulis bersyarat. Mengatakan hanya menulis ini jika ini tidak wujud. Jadi sebaik sahaja saya melihat bahawa bahawa undi mencecah meja, tiada siapa lagi yang akan menjadi dapat meletakkan undi mereka masuk. Dan itu hebat. Dan kita menokok kaunter calon kita. Dan yang kami lakukan kami demografi dan semua itu. Tetapi apa yang berlaku jika saya permohonan jatuh ke atas? Sekarang semua daripada undi secara tiba-tiba yang datang, dan saya tidak tahu jika mereka mendapat diproses ke dalam analisis dan demografi saya lagi. Dan jika permohonan itu datang kembali, bagaimana neraka yang aku tidak mengetahui apa undi mempunyai diproses dan di mana saya bermula? 

Jadi ini adalah masalah yang sebenar apabila anda mula melihat jenis ini senario. Dan bagaimana kita menyelesaikan itu? Kami menyelesaikannya dengan apa yang kita memanggil DynamoDB Streams. Sungai adalah masa yang dipesan dan dibahagikan log perubahan setiap akses ke meja, tiap-tiap menulis akses ke meja. Sebarang data yang yang bertulis kepada jadual muncul di sungai itu. 

Ia pada dasarnya barisan 24 jam. Item melanda sungai itu, mereka tinggal selama 24 jam. Mereka boleh membaca beberapa kali. Dijamin akan dihantar hanya sekali ke sungai, boleh membaca nombor n kali. Jadi bagaimanapun banyak proses anda mahu menggunakan data itu, anda boleh menggunakannya. Ia akan muncul setiap kemas kini. Setiap menulis hanya akan muncul sekali di sungai itu. Jadi anda tidak perlu bimbang mengenai pemprosesan dua kali daripada proses yang sama. 

Ia tegas mengarahkan setiap barang. Apabila kita mengatakan masa dipesan dan dibahagikan, anda akan melihat setiap partition di sungai itu. Anda akan melihat barang-barang, kemas kini teratur. Kami tidak menjamin beroperasi bahawa anda akan mendapat setiap transaksi dalam perintah itu di seluruh item. 

Jadi jurusan ialah idempotent. Adakah kita semua tahu apa yang idempotent bermakna? Idempotent bermakna anda boleh melakukannya ke atas, dan ke atas, dan sekali lagi. Hasilnya akan menjadi sama. 

Aliran adalah idempotent, tetapi mereka perlu dimainkan daripada titik permulaan, di mana sahaja yang anda pilih, hingga akhir, atau mereka tidak akan menyebabkan dalam nilai yang sama. 

Perkara yang sama dengan MongoDB. MongoDB mempunyai konstruk yang mereka memanggil oplog itu. Ia adalah konstruk yang sama. Banyak pangkalan data NoSQL mempunyai konstruk ini. Mereka menggunakannya untuk melakukan perkara-perkara seperti replikasi, yang adalah apa yang kita lakukan dengan sungai. PENONTON: Mungkin soalan bidaah, tetapi anda bercakap tentang aplikasi melakukan ke bawah yang seterusnya. Adakah aliran dijamin tidak mungkin turun? RICK Houlihan: Ya, sungai dijamin untuk tidak pernah turun. Kami menguruskan infrastruktur di belakang. sungai secara automatik menggunakan dalam kumpulan bersisik auto mereka. Kami akan melalui sedikit sedikit mengenai apa yang berlaku. 

Saya tidak boleh mengatakan mereka tidak dijamin tidak pernah turun. Unsur-unsur yang dijamin untuk hadir di dalam sungai itu. Dan sungai itu akan boleh diakses. Jadi apa yang berlaku ke bawah atau kembali up, yang berlaku di bawahnya. Ia covers-- ia OK. Baiklah, supaya anda mendapat yang berbeza pandangan jenis di luar skrin. Jenis-jenis pandangan yang penting kepada programmer biasanya, apa yang ia? Saya mendapatkan pandangan lama. Apabila kemas kini mencecah meja, IA AKAN menolak pandangan lama ke sungai supaya data boleh arkibkan, atau perubahan kawalan, pengenalan perubahan, perubahan pengurusan. 

Imej baru, apa yang ia kini selepas kemas kini, itulah jenis pandangan yang lain awak boleh dapatkan. Anda boleh mendapatkan kedua-dua imej lama dan baru. Mungkin saya mahu mereka kedua-duanya. Saya mahu melihat apa yang ia. Saya mahu melihat apa yang ia ditukar kepada. 

Saya mempunyai jenis pematuhan proses yang berjalan. Ia perlu untuk mengesahkan bahawa Apabila semuanya berubah, bahawa mereka dalam had tertentu atau dalam parameter tertentu. 

Dan kemudian mungkin saya sahaja perlu tahu apa yang berubah. Saya tidak peduli apa yang item berubah. Saya tidak perlu perlu tahu apa sifat-sifat berubah. Saya hanya perlu tahu bahawa perkara-perkara yang disentuh. Jadi ini adalah jenis pandangan yang anda turun aliran dan anda boleh berinteraksi dengan. 

Aplikasi yang menggunakan sungai itu, ini adalah jenis cara ini berfungsi. Pelanggan DynamoDB meminta untuk menolak data ke meja. Aliran menggunakan pada apa yang kita panggil shards. Shards diskalakan secara bebas daripada meja. Mereka tidak beratur sepenuhnya kepada partition meja anda. Dan sebab mengapa kerana mereka beratur kapasiti, semasa kapasiti meja. 

Mereka menggunakan dalam mereka kumpulan bersisik auto sendiri, dan mereka mula berputar di luar bergantung kepada berapa banyak menulis yang datang dalam, berapa banyak reads-- benar-benar ia menulis. Tidak ada reads-- tetapi bagaimana banyak menulis akan masuk. 

Dan kemudian di belakang akhir, kita mempunyai apa yang kita memanggil KCL, atau Perpustakaan Pelanggan Kinesis. Kinesis adalah data aliran teknologi pemprosesan dari Amazon. Dan aliran dibina di atas itu. 

Jadi anda menggunakan KCL dibolehkan aplikasi membaca sungai. Perpustakaan Pelanggan Kinesis sebenarnya menguruskan pekerja-pekerja anda. Dan ia juga tidak beberapa perkara yang menarik. Ia akan mewujudkan beberapa jadual sehingga dalam tablespace DynamoDB anda untuk mengesan barang-barang telah diproses. Jadi cara ini jika ia jatuh kembali, jika ia jatuh ke atas dan datang dan mendapat berdiri kembali, ia boleh menentukan di mana adakah ia dalam pemprosesan sungai. 

Itu sangat penting apabila anda bercakap tentang replikasi. Saya perlu tahu apa yang data telah diproses dan apa data masih belum diproses. Jadi perpustakaan KCL secara sungai akan memberikan anda banyak fungsi itu. Ia menjaga semua pengemasan. Ia berdiri seorang pekerja untuk setiap beling. Ia mewujudkan jadual pentadbiran untuk setiap beling, bagi setiap pekerja. Dan sebagai orang-api pekerja, mereka mengekalkan jadual tersebut supaya anda tahu rekod ini dibacakan dan diproses. Dan kemudian dengan cara yang jika proses mati dan kembali semula dalam talian, ia boleh meneruskan betul di mana ia berlepas. 

Oleh itu, kita menggunakan ini untuk replikasi rantau silang. Banyak pelanggan mempunyai keperluan untuk memindahkan data atau bahagian jadual data mereka sekitar untuk kawasan yang berbeza. Terdapat sembilan wilayah semua di seluruh dunia. Jadi mungkin terdapat Saya need-- mungkin mempunyai pengguna di Asia, pengguna di Pantai Timur Amerika Syarikat. Mereka mempunyai data yang berbeza yang perlu diedarkan di pasaran tempatan. Dan mungkin pengguna lalat dari Asia ke Amerika Syarikat, dan saya mahu meniru data serta. Oleh itu, apabila dia mendapat dari pesawat, dia mempunyai pengalaman yang baik menggunakan aplikasi bimbitnya. 

Anda boleh menggunakan rantau salib perpustakaan replikasi untuk melakukan ini. Pada dasarnya kita mempunyai menyediakan dua teknologi. Salah satu konsol aplikasi anda boleh berdiri pada contoh EC2 anda sendiri. Ia berjalan replikasi tulen. Dan kemudian kami berikan kepadamu perpustakaan. Perpustakaan ini boleh anda gunakan untuk membina permohonan anda sendiri jika anda mahu buat gila dengan yang data-- penapis, meniru hanya sebahagian daripadanya, memutarkan data, bergerak ke dalam jadual yang berbeza, sebagainya dan sebagainya. Jadi itulah jenis apa yang kelihatan seperti. 

DynamoDB Streams boleh diproses oleh apa yang kita panggil Lambda. Yang telah dinyatakan sedikit tentang acara seni bina aplikasi didorong. Lambda adalah komponen utama itu. Lambda adalah kod yang kebakaran apabila diminta sebagai tindak balas kepada peristiwa tertentu. Salah satu peristiwa boleh menjadi rekod yang terdapat di sungai itu. Jika rekod yang muncul di sungai itu, kami akan memanggil fungsi Java ini. Nah, ini adalah JavaScript, dan Lambda menyokong Node.js, Java, Python, dan tidak lama lagi akan menyokong bahasa lain juga. Dan cukup untuk mengatakan, ia adalah kod tulen. menulis Di Jawa, anda menentukan kelas. Anda menolak JAR sehingga ke Lambda. Dan kemudian anda menentukan kelas untuk memanggil sebagai tindak balas kepada mana acara. Dan kemudian infrastruktur Lambda yang belakang yang akan berjalan kod itu. 

Kod yang boleh memproses rekod off sungai. Ia boleh berbuat apa-apa yang ia mahu dengan itu. Dalam contoh ini tertentu, semua kami benar-benar lakukan adalah log sifat. Tetapi ini hanya kod. Kod boleh berbuat apa-apa, kan? 

Jadi, anda boleh berputar data tersebut. Anda boleh membuat pandangan yang derivatif. Jika ia merupakan satu struktur dokumen, anda boleh meleperkan struktur. Anda boleh membuat indeks alternatif. Semua jenis perkara yang anda boleh kaitan dengan Streams DynamoDB. 

Dan benar-benar, itulah yang yang kelihatan seperti. Oleh itu, anda mendapatkan orang-orang maklumat yang akan datang masuk. Mereka datang dari tali. Mereka membaca oleh fungsi Lambda itu. Mereka berputar data dan menolaknya dalam jadual terbitan, memberitahu sistem luaran perubahan, dan menolak data ke dalam ElastiCache. 

Kita bercakap tentang bagaimana untuk meletakkan cache di hadapan pangkalan data untuk jualan yang senario. Baik apa yang akan berlaku jika saya mengemaskini keterangan item? Nah, jika saya mempunyai Lambda fungsi berjalan di atas meja itu, jika saya mengemas kini keterangan item IA AKAN mengambil rekod off sungai itu, dan ia akan mengemaskini ElastiCache contoh dengan data baru. Jadi itulah banyak apa yang kita lakukan dengan Lambda. Ia adalah kod gam, penyambung. Dan ia sebenarnya memberikan keupayaan untuk melancarkan dan untuk menjalankan aplikasi yang sangat kompleks tanpa dedicated server infrastruktur, yang benar-benar sejuk. 

Oleh itu, marilah kita kembali kepada kami masa nyata seni bina mengundi. Ini adalah baru dan lebih baik dengan kami sungai dan KCL membolehkan permohonan. Sama seperti sebelum ini, kita boleh mengendalikan apa-apa skala pilihan raya. Kita suka ini. Kami melakukan keluar mengumpulkan berselerak di beberapa baldi. Kami telah mendapat mengunci optimis berlaku. Kita boleh terus pengundi kita daripada menukar undi mereka. Mereka hanya boleh mengundi sekali sahaja. Ini adalah hebat. Masa nyata kesalahan toleransi, pengagregatan berskala sekarang. Sekiranya semua benda yang jatuh ke atas, ia tahu di mana untuk memulakan semula sendiri apabila ia datang kembali kerana kita menggunakan aplikasi KCL itu. Dan maka kita juga boleh menggunakan Permohonan KCL untuk menolak data daripada untuk Anjakan merah untuk lain analisis aplikasi, atau penggunaan yang MapReduce elastik untuk menjalankan masa nyata live kesatuan off data itu. 

Jadi ini adalah perkara yang kita tidak bercakap tentang banyak. Tetapi mereka tambahan teknologi yang datang menanggung apabila anda sedang mencari pada jenis senario. 

Baiklah, jadi itu kira-kira analisis dengan DynamoDB Streams. Anda boleh mengumpul de-korban penipuan data, melakukan semua jenis barang bagus, data agregat dalam memori, membuat jadual tersebut derivatif. Itulah kes penggunaan yang besar bahawa banyak pelanggan terlibat dengan, mengambil bersarang sifat dokumen JSON dan mewujudkan indeks tambahan. 

Kami memohon pada akhir. Terima kasih kerana membawa dengan saya. Jadi mari kita bercakap tentang kerangka rujukan. DynamoDB duduk di tengah-tengah supaya banyak infrastruktur AWS ini. Pada asasnya anda boleh cangkuk ia sehingga apa sahaja yang anda mahu. Aplikasi dibina menggunakan Dynamo termasuk Lambda, ElastiCache, CloudSearch, menolak data ke dalam elastik MapReduce, eksport import dari DynamoDB ke dalam S3, semua jenis aliran kerja. Tetapi mungkin yang terbaik Perkara untuk bercakap tentang, dan ini adalah apa yang benar-benar menarik ialah apabila kita bercakap tentang aplikasi acara didorong. 

Ini adalah contoh projek dalaman yang kita ada di mana kita sebenarnya penerbitan untuk mengumpul hasil kajian. Jadi dalam pautan e-mel yang kami hantar keluar, tidak akan mempunyai menjadi sedikit klik pautan berkata di sini untuk menjawab kaji selidik. Dan apabila seseorang klik yang mengandungi pautan, apa yang berlaku adalah mereka tarik ke bawah yang selamat Borang kaji selidik HTML dari S3. Tidak ada pelayan. Ini hanyalah satu objek S3. 

Bentuk yang datang, memuatkan dalam pelayar. Ia mempunyai tulang belakang. Ia mempunyai kompleks JavaScript bahawa ia berjalan. Jadi ia adalah aplikasi yang sangat kaya berjalan dalam pelayar pelanggan. Mereka tidak tahu bahawa mereka tidak berinteraksi dengan pelayan akhir belakang. Pada ketika ini, itu semua pelayar. 

Mereka menerbitkan hasil dengan apa kita panggil API Gateway Amazon. Gateway API hanya satu API web bahawa anda boleh menentukan dan menyambung untuk apa sahaja yang anda mahu. Dalam kes ini, kami disambungkan kepada fungsi Lambda. 

Jadi operasi POST saya ialah berlaku tanpa pelayan. Pada asasnya bahawa API Gateway duduk di sana. Ia kos saya apa-apa sehingga orang mula menghantar kepadanya, bukan? Fungsi Lambda hanya duduk di sana. Dan ia kos saya apa-apa sehingga orang mula memukul. Jadi, anda boleh lihat, seperti kelantangan kenaikan, itu selepas pertuduhan datang. Saya tidak menjalankan pelayan 7/24. 

Jadi saya tarik borang turun dari baldi, dan saya hantar melalui API Gateway ke dalam fungsi Lambda itu. Dan kemudian Lambda fungsi berkata, anda tahu apa, saya telah mendapat beberapa Piis, beberapa maklumat peribadi dalam tindak balas ini. Saya mendapat komen yang datang daripada pengguna. Saya ada alamat e-mel. Saya telah mendapat nama pengguna. 

Biar saya berpecah ini di luar. Saya akan menjana beberapa metadata off rekod ini. Dan saya akan menolak metadata ke dalam DynamoDB. Dan saya boleh menyulitkan semua data dan tolak ke dalam DynamoDB jika saya mahu. Tetapi ia lebih mudah bagi saya, dalam hal ini menggunakan kes, untuk meneruskan berkata yang, Saya akan menolak data mentah ke dalam baldi S3 disulitkan. Jadi saya menggunakan dibina pada S3 sebelah pelayan penyulitan dan Pengurusan Utama Amazon Perkhidmatan supaya saya mempunyai kunci yang boleh berputar pada jarak waktu tetap, dan saya boleh melindungi data PII sebagai sebahagian daripada aliran kerja ini keseluruhan. 

Jadi apa yang telah kuperbuat? Saya baru sahaja mengerahkan seluruh permohonan, dan saya tidak mempunyai pelayan. Begitu juga apa acara didorong permohonan seni bina tidak untuk anda. 

Sekarang jika anda berfikir tentang kes penggunaan secara this-- kami mempunyai pelanggan lain yang saya bercakap kepada kira-kira seni bina ini tepat yang menjalankan kempen phenomenally besar, yang sedang melihat ini dan pergi, oh saya. Kerana sekarang, mereka boleh pada dasarnya menolak di luar sana, biarlah kempen yang hanya duduk di sana sehingga ia dilancarkan, dan tidak perlu bimbang tentang ara apa jenis infrastruktur akan berada di sana untuk menyokongnya. Dan kemudian dengan seberapa segera yang kempen yang dilakukan, ia seperti infrastruktur hanya dengan serta-merta hilang kerana ada benar-benar ada infrastruktur. Ia hanya kod yang duduk di atas Lambda. Ia data hanya itu duduk di DynamoDB. Ia adalah satu cara yang menakjubkan untuk membina aplikasi. 

PENONTON: Jadi ia lebih tidak kekal daripada ia akan menjadi jika ia disimpan pada pelayan sebenar? 

RICK Houlihan: Sudah tentu. Kerana itu misalnya pelayan perlu menjadi 7/24. Ia perlu disediakan untuk seseorang untuk bertindak balas terhadap. Well cuba teka? S3 disediakan 24/7. S3 sentiasa bertindak balas. Dan S3 adalah sangat, sangat baik di berkhidmat sehingga objek. Objek boleh menjadi fail HTML, atau JavaScript fail, atau apa sahaja yang anda mahu. Anda boleh menjalankan aplikasi web sangat kaya daripada baldi S3, dan orang-orang lakukan. 

Dan supaya idea di sini adalah untuk melepaskan diri dari jalan yang kita digunakan untuk berfikir mengenainya. Kita semua digunakan untuk berfikir dalam segi pelayan dan tuan rumah. Ini bukan soal itu lagi. Ia mengenai infrastruktur kod. Menggunakan kod untuk awan dan biarkan awan menjalankannya untuk anda. Dan itulah yang AWS sedang cuba lakukan. 

PENONTON: Jadi kotak emas anda di tengah-tengah API Gateway tidak pelayan-suka, tetapi sebaliknya adalah just-- 

RICK Houlihan: Anda boleh berfikir ia sebagai pelayan fasad. Semua itu adalah ia akan mengambil HTTP yang meminta dan peta kepada proses lain. Itu sahaja yang ia. Dan dalam kes ini, kita pemetaan kepada fungsi Lambda. Baiklah, jadi itu sahaja yang saya dapat. Terima kasih banyak. Saya menghargainya. Saya tahu bahawa kita mahu sedikit masa ke masa. Dan mudah-mudahan anda semua mendapat sedikit maklumat bahawa anda boleh mengambil hari ini. Dan saya memohon maaf jika saya pergi atas beberapa kepala anda, tetapi ada banyak yang baik pengetahuan asas asas yang saya rasa adalah sangat berharga untuk anda. Jadi terima kasih kerana telah saya. [Tepuk tangan] PENONTON: [didengar] adalah apabila anda yang berkata anda terpaksa melalui perkara yang dari awal hingga akhir untuk mendapatkan nilai yang betul atau nilai yang sama, bagaimana akan nilai-nilai berubah jika [didengar]. 

RICK Houlihan: Oh, idempotent? Bagaimana nilai-nilai akan berubah? Nah, kerana jika saya tidak berjalan ia sehingga ke akhirnya, maka saya tidak tahu apa yang berubah telah dibuat dalam batu yang terakhir. Ia tidak akan menjadi yang data yang sama seperti apa yang saya lihat. PENONTON: Oh, jadi anda hanya tidak mendapat keseluruhan input. RICK Houlihan: Betul. Anda perlu pergi dari awal hingga akhir, dan kemudian ia akan menjadi negeri yang konsisten. Sejuk. 

PENONTON: Jadi, anda menunjukkan kepada kita DynamoDB boleh lakukan dokumen atau nilai utama. Dan kita menghabiskan banyak masa di nilai utama dengan hash dan cara-cara untuk flip sekitar. Apabila anda melihat jadual tersebut, adalah bahawa meninggalkan pendekatan dokumen? 

RICK Houlihan: Saya tidak akan mengatakan meninggalkannya di belakang. 

PENONTON: Mereka telah dipisahkan dari the-- 

RICK Houlihan: With dokumen pendekatan, jenis dokumen dalam DynamoDB hanya fikirkan sebagai atribut lain. Ia adalah satu sifat yang mengandungi struktur data hierarki. Dan kemudian dalam pertanyaan, anda boleh menggunakan ciri-ciri dari orang-orang objek menggunakan Object Notation. Jadi saya boleh menapis pada bersarang harta dokumen JSON. PENONTON: Jadi apa-apa kali saya melakukan pendekatan dokumen, Saya jenis boleh tiba di tabular-- yang PENONTON: Sudah tentu. PENONTON: --indexes dan perkara yang anda hanya bercakap tentang. RICK Houlihan: Ya, yang indeks dan semua itu, apabila anda mahu kepada indeks sifat-sifat JSON, cara yang kita akan perlu lakukan iaitu jika anda memasukkan objek JSON atau dokumen ke dalam Dynamo, anda akan menggunakan sungai. Sungai akan membaca input. Anda akan mendapat yang JSON membantah dan anda akan katakan OK, apa yang harta yang ingin saya indeks? 

Anda membuat jadual derivatif. Sekarang ini cara ia berfungsi sekarang. Kami tidak membenarkan anda untuk indeks langsung hartanah. 

PENONTON: Tabularizing dokumen anda. 

RICK Houlihan: Tepat, meratakan ia, tabularizing itu, betul-betul. Itulah apa yang anda lakukan dengannya. 

PENONTON: Terima kasih. 

RICK Houlihan: Ya, sama sekali, terima kasih. PENONTON: Jadi ia adalah jenis Mongo memenuhi classifers Redis. 

RICK Houlihan: Ya, ia banyak seperti itu. Itulah penerangan yang baik untuk. Sejuk.