>> [MUSIC PLAYING]
RICK Houlihan: Baiklah.
Hai semuanya.
Nama saya Rick Houlihan.
Aku prinsipal senior solusi arsitek di AWS.
Saya fokus pada NoSQL dan Teknologi DynamoDB.
Aku di sini hari ini untuk berbicara dengan Anda sedikit tentang mereka.
>> Latar belakang saya adalah terutama di lapisan data.
Aku menghabiskan setengah perkembangan saya karir menulis database
akses data, solusi untuk berbagai aplikasi.
Aku sudah dalam virtualisasi Cloud selama sekitar 20 tahun.
Jadi sebelum Cloud adalah Cloud, kami biasa menyebutnya komputasi utilitas.
Dan ide itu, itu seperti PG & E, Anda membayar untuk apa yang Anda gunakan.
Hari ini kita menyebutnya awan.
>> Tapi selama bertahun-tahun, saya telah bekerja untuk beberapa perusahaan
Anda mungkin pernah mendengar tentang.
Tapi aku sudah menyusun daftar teknis prestasi, saya kira Anda akan mengatakan.
Saya memiliki delapan paten di sistem Cloud virtualisasi, desain mikroprosesor,
pengolahan event yang kompleks, dan daerah lainnya juga.
>> Jadi hari ini, aku lebih sering fokus pada NoSQL teknologi dan generasi berikutnya
Database.
Dan itu umumnya apa yang akan saya berada di sini berbicara kepada Anda hari ini tentang.
Jadi apa yang dapat Anda harapkan dari sesi ini,
kita akan pergi melalui singkat sejarah pengolahan data.
Itu selalu membantu untuk memahami dari mana kita berasal
dan mengapa kita di mana kita berada.
Dan kita akan berbicara sedikit sedikit tentang teknologi NoSQL
dari sudut pandang fundamental.
>> Kami akan masuk ke beberapa internal DynamoDB.
DynamoDB adalah AWS ini tidak ada rasa.
Ini sebuah sepenuhnya dikelola dan host solusi NoSQL.
Dan kita akan berbicara sedikit tentang meja struktur, API, jenis data, indeks,
dan beberapa internal dari teknologi DynamoDB.
Kami akan masuk ke beberapa desain pola dan praktik terbaik.
Kita akan berbicara tentang bagaimana Anda menggunakan teknologi ini untuk beberapa
aplikasi hari ini.
Dan kemudian kita akan berbicara sedikit tentang evolusi atau munculnya
dari paradigma baru dalam pemrograman disebut aplikasi-event
dan bagaimana DynamoDB bermain di itu juga.
Dan kami akan meninggalkan Anda sedikit diskusi arsitektur referensi
sehingga kami dapat berbicara tentang beberapa cara Anda dapat menggunakan DynamoDB.
>> Jadi pertama off-- ini adalah pertanyaan Aku mendengar banyak adalah, apa database.
Banyak orang berpikir mereka tahu apa database adalah.
Jika Anda Google, Anda akan melihat ini.
Ini adalah satu set terstruktur dari data yang dimiliki di komputer, terutama yang
diakses dalam berbagai cara.
Saya kira itu baik definisi database modern.
Tapi aku tidak suka, karena itu berarti beberapa hal.
Ini menyiratkan struktur.
Dan itu berarti bahwa itu pada komputer.
Dan database tidak selalu ada pada komputer.
Database benar-benar ada dalam banyak cara.
>> Jadi definisi yang lebih baik dari Database adalah sesuatu seperti ini.
Sebuah database terorganisir mekanisme untuk menyimpan, mengelola,
dan mengambil informasi.
Ini adalah dari About.com.
Jadi saya suka ini karena benar-benar pembicaraan tentang database menjadi repositori,
repositori informasi, belum tentu
sesuatu yang duduk di komputer.
Dan sepanjang sejarah, kami tidak selalu memiliki komputer.
>> Sekarang, jika saya meminta rata-rata pengembang saat ini apa
database, itulah jawaban yang saya dapatkan.
Suatu tempat saya bisa tetap hal.
Kanan?
Dan itu benar.
Tapi itu disayangkan.
Karena database benar-benar dasar dari aplikasi modern.
Ini yayasan dari setiap aplikasi.
Dan bagaimana Anda membangun itu Database, bagaimana Anda struktur
Data yang akan menentukan bagaimana yang Aplikasi melakukan seperti yang Anda skala.
>> Jadi banyak pekerjaan saya hari ini adalah berurusan dengan apa
terjadi ketika pengembang mengambil pendekatan ini
dan berurusan dengan akibatnya dari aplikasi yang
sekarang skala luar asli maksud dan penderitaan dari desain yang buruk.
Jadi mudah-mudahan ketika Anda pergi hari ini, Anda akan
memiliki beberapa alat di ikat pinggang Anda yang akan membuat Anda
dari membuat kesalahan-kesalahan yang sama.
Baiklah.
Jadi mari kita bicara tentang sedikit timeline teknologi database.
Saya pikir saya membaca sebuah Artikel tidak lama yang lalu
dan itu mengatakan sesuatu pada lines-- yang itu pernyataan yang sangat puitis.
Dikatakan sejarah dari pengolahan data adalah
penuh watermark tinggi data kelimpahan.
OKE.
Sekarang, saya kira itu semacam benar.
Tapi aku benar-benar melihat yaitu sebagai sejarah sebenarnya diisi
dengan watermark tinggi tekanan data.
Karena tingkat data konsumsi tidak pernah turun.
Hanya naik.
>> Dan inovasi terjadi ketika kita melihat tekanan data, yang
adalah jumlah data yang sekarang datang ke dalam sistem.
Dan itu tidak bisa diproses efisien baik dalam waktu atau biaya.
Dan saat itulah kita mulai untuk melihat tekanan data.
>> Jadi ketika kita melihat database pertama, ini
adalah salah satu yang antara telinga kita.
Kita semua terlahir dengan itu.
Ini database yang bagus.
Memiliki ketersediaan tinggi.
Ini selalu.
Anda selalu bisa mendapatkannya.
>> Tapi itu single user.
Saya tidak bisa berbagi pikiran saya dengan Anda.
Anda tidak bisa mendapatkan pikiran saya ketika Anda ingin mereka.
Dan abilitiy mereka tidak begitu baik.
Kita lupa hal.
Sesekali, salah satu dari kami daun dan pindah ke lain keberadaan
dan kami kehilangan segalanya yang berada di database tersebut.
Jadi itu tidak semua yang baik.
>> Dan ini bekerja dengan baik dari waktu ke waktu ketika kami kembali pada hari
ketika semua kita benar-benar perlu tahu adalah di mana kita akan pergi besok
atau di mana kita berkumpul makanan terbaik.
Tapi seperti kita mulai tumbuh sebagai peradaban dan pemerintah mulai
untuk datang menjadi ada, dan bisnis mulai berkembang,
kami mulai menyadari bahwa kita perlu sedikit lebih dari apa yang
kita bisa dimasukkan ke dalam kepala kita.
Baiklah?
>> Kami membutuhkan sistem catatan.
Kami membutuhkan tempat untuk menyimpan data mampu.
Jadi kita mulai menulis dokumen, menciptakan perpustakaan dan arsip.
Kami mulai mengembangkan sistem akuntansi buku besar.
Dan bahwa sistem penghitungan buku berlari dunia selama berabad-abad,
dan bahkan mungkin ribuan tahun sebagai kami jenis tumbuh ke titik
mana yang beban data melampaui kemampuan sistem-sistem
untuk dapat menampungnya.
>> Dan ini benar-benar terjadi di tahun 1880-an.
Kanan?
Di tahun 1880 Sensus Amerika Serikat.
Ini benar-benar di mana balik yang menunjuk pengolahan data modern.
Ini adalah titik di yang jumlah data
yang sedang dikumpulkan oleh Pemerintah AS sampai ke titik
di mana butuh delapan tahun untuk memproses.
>> Sekarang, delapan years-- sebagai Anda tahu, sensus
berjalan setiap 10 years-- jadi cukup jelas bahwa pada saat kita
mendapat sensus 1890, jumlah data yang
akan diproses oleh pemerintah adalah
akan melebihi 10 tahun itu yang dibutuhkan untuk meluncurkan sensus baru.
Ini adalah masalah.
>> Jadi seorang pria bernama Herman Hollerith datang
dan ia menemukan catatan unit pukulan kartu, card reader punch, kartu punch
tabulator, dan pengumpulan mekanisme untuk teknologi ini.
Dan bahwa perusahaan yang ia terbentuk pada waktu, bersama dengan beberapa orang lain,
benar-benar menjadi salah satu pilar dari perusahaan kecil yang kita kenal sekarang disebut IBM.
>> Jadi IBM awalnya berada di bisnis database.
Dan itu benar-benar apa yang mereka lakukan.
Mereka melakukan pengolahan data.
>> Sebagai sehingga proliferasi pukulan kartu, sebuah mekanisme cerdik
mampu memanfaatkan bahwa teknologi untuk polling hasil set diurutkan.
Anda dapat melihat pada gambar ini di sana kami memiliki sebuah little--
itu sedikit small-- tetapi Anda dapat melihat mekanisme mekanik yang sangat cerdik
di mana kita memiliki dek kartu punch.
Dan mengambil seseorang obeng kecil
dan menempel melalui slot dan mengangkatnya
untuk mendapatkan pertandingan itu, yang Hasil diurutkan mengatur.
>> Ini merupakan agregasi.
Kami melakukan hal ini sepanjang waktu hari ini di komputer,
di mana Anda melakukannya dalam database.
Kami digunakan untuk melakukannya secara manual, kan?
Orang menaruh hal-hal ini bersama-sama.
Dan itu proliferasi punch card ini
menjadi apa yang kita disebut Data drum dan gulungan data, pita kertas.
>> Industri pengolahan data mengambil pelajaran dari pemain piano.
Pemain piano-piano kembali pergantian abad
digunakan untuk menggunakan gulungan kertas dengan slot untuk menceritakannya yang kunci untuk bermain.
Jadi teknologi yang diadaptasi akhirnya untuk menyimpan data digital,
karena mereka bisa menempatkan data yang ke mereka pita kertas gulungan.
>> Sekarang, sebagai hasilnya, data itu actually-- bagaimana
Anda mengakses data ini secara langsung tergantung pada bagaimana Anda menyimpannya.
Jadi jika saya menempatkan data pada tape, Aku punya mengakses data secara linear.
Aku harus menggulung seluruh tape untuk mengakses semua data.
Jika saya menempatkan data di pukulan kartu, saya bisa mengaksesnya
dalam sedikit lebih acak busana, mungkin tidak secepat.
>> Tapi ada keterbatasan dalam bagaimana kita akses ke data berdasarkan bagaimana disimpan.
Dan jadi ini adalah masalah pergi ke '50-an.
Sekali lagi, kita bisa mulai melihat bahwa seperti yang kita mengembangkan teknologi baru untuk memproses
data, kanan, membuka pintu untuk solusi baru,
untuk program baru, baru aplikasi untuk data itu.
Dan benar-benar, tata kelola mungkin alasannya
mengapa kami mengembangkan beberapa sistem ini.
Tapi bisnis cepat menjadi driver balik evolusi
dari database modern dan sistem file modern.
>> Jadi hal berikutnya yang muncul adalah pada tahun 50an
adalah sistem file dan pengembangan penyimpanan akses acak.
Ini adalah indah.
Sekarang, semua tiba-tiba, kita dapat menempatkan kami file mana saja di hard drive
dan kita dapat mengakses data ini secara acak.
Kita bisa mengurai bahwa Informasi dari file.
Dan kita memecahkan semua dunia masalah dengan pengolahan data.
>> Dan itu berlangsung sekitar 20 atau 30 tahun sampai evolusi
dari database relasional, yang adalah ketika dunia memutuskan kita sekarang
perlu memiliki repositori yang mengalahkan gepeng data di file
sistem yang kami telah membangun. Kanan?
Terlalu banyak data didistribusikan di terlalu banyak tempat, de-duplikasi data,
dan biaya penyimpanan sangat besar.
>> Di 70-an, sumber daya yang paling mahal bahwa komputer memiliki adalah penyimpanan.
Prosesor adalah dipandang sebagai biaya tetap.
Ketika saya membeli kotak, CPU melakukan beberapa pekerjaan.
Ini akan berputar apakah itu benar-benar bekerja atau tidak.
Itu benar-benar biaya tenggelam.
>> Tapi apa yang saya biaya sebagai bisnis penyimpanan.
Jika saya harus membeli lebih disk berikutnya bulan, itu adalah biaya riil yang saya bayar.
Dan penyimpanan yang mahal.
>> Sekarang kita maju cepat 40 tahun dan kami memiliki masalah yang berbeda.
Menghitung yang sekarang sumber daya yang paling mahal.
Penyimpanan yang murah.
Maksudku, kita bisa pergi ke mana pun pada awan dan kita dapat menemukan penyimpanan murah.
Tapi apa yang saya tidak dapat menemukan adalah menghitung murah.
>> Jadi evolusi hari ini teknologi, teknologi database,
benar-benar terfokus di sekitar database terdistribusi
yang tidak menderita jenis yang sama dari skala
keterbatasan database relasional.
Kami akan berbicara sedikit tentang apa yang benar-benar berarti.
>> Tapi salah satu alasan dan driver di belakang kami this--
berbicara tentang tekanan data.
Tekanan Data adalah sesuatu yang mendorong inovasi.
Dan jika Anda melihat lebih lima tahun terakhir,
ini adalah bagan dari apa data beban di perusahaan umum
Sepertinya dalam lima tahun terakhir.
>> Dan aturan umum days-- ini jika Anda pergi Google--
adalah 90% dari data yang kami menyimpan hari, dan itu
dihasilkan dalam dua tahun terakhir.
OKE.
Sekarang, ini bukan sebuah tren yang baru.
Ini adalah tren yang sudah akan keluar untuk 100 tahun.
Sejak Herman Hollerith mengembangkan kartu punch,
kami telah membangun repositori data yang dan mengumpulkan data pada tingkat yang fenomenal.
>> Jadi selama 100 tahun terakhir, kita telah melihat tren ini.
Itu tidak akan berubah.
Ke depan, kita akan melihat ini, jika tidak tren dipercepat.
Dan Anda dapat melihat apa yang tampak seperti.
>> Jika bisnis pada tahun 2010 memiliki satu terabyte data di bawah manajemen,
hari ini itu berarti mereka mengelola 6,5 ​​petabyte data.
Itu 6.500 Data kali lebih.
Dan aku tahu ini.
Saya bekerja dengan bisnis ini setiap hari.
Lima tahun yang lalu, saya akan berbicara dengan perusahaan
yang akan berbicara kepada saya tentang apa yang sakit itu adalah untuk mengelola terabyte data.
Dan mereka akan berbicara kepada saya tentang bagaimana kita melihat
bahwa ini mungkin akan menjadi dua petabyte atau
dalam beberapa tahun.
>> Perusahaan-perusahaan yang sama hari ini aku bertemu dengan,
dan mereka sedang berbicara kepada saya tentang Masalah yang ada memiliki pengelolaan
puluhan, 20 petabyte data.
Jadi ledakan Data di industri
adalah mendorong besar butuhkan untuk solusi yang lebih baik.
Dan database relasional adalah hanya tidak hidup sampai permintaan.
>> Dan jadi ada linear korelasi antara tekanan Data
dan inovasi teknis.
Sejarah telah menunjukkan kepada kita ini, yang dari waktu ke waktu,
setiap kali volume data yang perlu diproses
melebihi kapasitas sistem untuk memprosesnya dalam waktu yang wajar
atau dengan biaya yang wajar, teknologi baru kemudian
yang diciptakan untuk memecahkan masalah tersebut.
Mereka teknologi baru, pada gilirannya, membuka pintu
untuk satu set masalah, yang mengumpulkan data bahkan lebih.
>> Sekarang, kita tidak akan berhenti ini.
Kanan?
Kami tidak akan berhenti ini.
Mengapa?
Karena Anda tidak bisa tahu segalanya ada untuk mengetahui di alam semesta.
Dan selama kita sudah hidup, sepanjang sejarah manusia,
kami selalu didorong untuk tahu lebih banyak.
>> Jadi sepertinya setiap inci kita bergerak menyusuri jalan penemuan ilmiah,
kita mengalikan jumlah data bahwa kita perlu proses secara eksponensial
seperti yang kita mengungkap lebih banyak dan lebih dan lebih tentang inner hidup,
tentang bagaimana alam semesta bekerja, sekitar mengemudi penemuan ilmiah,
dan penemuan yang kita lakukan hari ini.
Volume data hanya terus meningkat.
Sehingga mampu menangani masalah ini sangat besar.
>> Jadi salah satu hal kita melihat sebagai mengapa NoSQL?
Bagaimana NoSQL memecahkan masalah ini?
Nah, database relasional, Structured Query Language,
SQL-- itu benar-benar suatu konstruksi dari relasional database-- hal-hal ini
dioptimalkan untuk penyimpanan.
>> Kembali di tahun 70-an, sekali lagi, disk mahal.
Latihan penyediaan penyimpanan dalam perusahaan adalah tidak pernah berakhir.
Aku tahu.
Saya tinggal itu.
Saya menulis driver penyimpanan untuk Perusahaan superserver enterprised
kembali di tahun 90-an.
Dan garis bawah adalah memeras lain array storage hanya sesuatu yang
terjadi setiap hari di perusahaan.
Dan tidak pernah berhenti.
Penyimpanan kepadatan lebih tinggi, permintaan untuk penyimpanan kepadatan tinggi,
dan untuk penyimpanan lebih efisien devices-- itu tidak pernah berhenti.
>> Dan NoSQL adalah teknologi yang besar karena menormalkan data.
Ini de-duplikasi data.
Ini menempatkan data dalam struktur yang adalah agnostik untuk setiap pola akses.
Beberapa aplikasi dapat menekan bahwa Database SQL, menjalankan query ad hoc,
dan mendapatkan data dalam bentuk yang mereka perlu proses untuk beban kerja mereka.
Kedengarannya fantastis.
Tetapi intinya adalah dengan sistem, jika itu agnostik untuk segala sesuatu,
dioptimalkan untuk apa-apa.
OKE?
>> Dan itulah apa yang kita dapatkan dengan database relasional.
Itu dioptimalkan untuk penyimpanan.
Ini normal.
Ini relasional.
Mendukung ad hoc query.
Dan itu dan skala vertikal.
>> Jika saya perlu untuk mendapatkan database SQL yang lebih besar atau database SQL yang lebih kuat,
Aku pergi membeli sepotong lebih besar dari besi.
OKE?
Saya telah bekerja dengan banyak pelanggan yang telah melalui upgrade besar
infrastruktur SQL mereka hanya untuk mengetahui enam bulan kemudian,
mereka memukul dinding lagi.
Dan jawaban dari Oracle atau MSSQL atau orang lain adalah mendapatkan kotak besar.
Nah cepat atau lambat, Anda tidak bisa membeli lebih besar box, dan itulah masalah yang sebenarnya.
Kita perlu untuk benar-benar mengubah keadaan.
Jadi di mana ini bekerja?
Ia bekerja dengan baik untuk secara offline analisis, OLAP-jenis beban kerja.
Dan itu benar-benar di mana SQL milik.
Sekarang, itu digunakan saat ini di banyak secara online transaksional pengolahan-jenis
aplikasi.
Dan bekerja dengan baik di beberapa tingkat pemanfaatan,
tapi itu hanya tidak skala cara NoSQL tidak.
Dan kita akan berbicara sedikit sedikit tentang mengapa itu.
>> Sekarang, NoSQL, di sisi lain, lebih dioptimalkan untuk menghitung.
OKE?
Hal ini tidak agnostik untuk pola akses.
Adalah apa yang kita sebut de-normalisasi struktur atau struktur hirarkis.
Data dalam database relasional adalah bergabung bersama-sama dari beberapa tabel
untuk menghasilkan tampilan yang Anda butuhkan.
Data dalam database NoSQL disimpan dalam dokumen yang
berisi struktur hirarkis.
Semua data yang biasanya akan bergabung bersama untuk menghasilkan tampilan yang
disimpan dalam satu dokumen.
Dan kita akan berbicara sedikit tentang bagaimana yang bekerja di beberapa tangga lagu.
>> Tapi ide di sini adalah bahwa Anda menyimpan data Anda karena ini pandangan yang dipakai.
OKE?
Anda skala horizontal.
Kanan?
Jika saya perlu meningkatkan Ukuran cluster NoSQL saya,
Saya tidak perlu mendapatkan kotak besar.
Saya mendapatkan kotak lain.
Dan saya klaster mereka bersama-sama, dan saya dapat beling data tersebut.
Kita akan berbicara sedikit tentang apa sharding adalah, untuk menjadi
mampu skala database yang di beberapa perangkat fisik
dan menghapus penghalang yang mengharuskan saya untuk skala vertikal.
>> Jadi itu benar-benar dibangun untuk secara online proses transaksi dan skala.
Ada perbedaan besar di sini antara pelaporan, kan?
Pelaporan, saya tidak tahu pertanyaan saya akan bertanya.
Kanan?
Reporting-- jika seseorang dari departemen pemasaran saya
ingin hanya-- berapa banyak pelanggan saya memiliki karakteristik tertentu yang
membeli di day-- ini saya tidak tahu apa permintaan mereka akan bertanya.
Jadi saya harus agnostik.
>> Sekarang, di online aplikasi transaksional,
Aku tahu apa pertanyaan yang saya minta.
Saya membangun aplikasi untuk alur kerja yang sangat spesifik.
OKE?
Jadi jika saya mengoptimalkan data menyimpan untuk mendukung alur kerja itu,
itu akan menjadi lebih cepat.
Dan itulah mengapa NoSQL bisa benar-benar mempercepat pengiriman
dari jenis-jenis layanan.
Baiklah.
>> Jadi kita akan masuk ke sedikit teori sini.
Dan beberapa dari Anda, mata Anda mungkin memutar kembali sedikit.
Tapi aku akan mencoba untuk tetap tingkat setinggi mungkin.
Jadi jika Anda berada di proyek manajemen, ada
membangun yang disebut segitiga kendala.
OKE.
Segitiga kendala diktat Anda tidak bisa memiliki segalanya sepanjang waktu.
Tidak dapat memiliki kue dan memakannya juga.
Jadi dalam manajemen proyek, yang segitiga kendala adalah Anda dapat memilikinya murah,
Anda dapat memilikinya cepat, atau Anda dapat memilikinya baik.
Ambil dua.
Karena Anda tidak dapat memiliki semua tiga.
Kanan?
OKE.
>> Jadi Anda mendengar tentang ini banyak.
Ini adalah kendala tiga, segitiga triple kendala,
atau segitiga besi oftentimes-- ketika Anda berbicara dengan manajer proyek,
mereka akan berbicara tentang hal ini.
Sekarang, database memiliki segitiga besi mereka sendiri.
Dan segitiga besi data adalah apa yang kita sebut CAP teorema.
OKE?
>> CAP teorema mendikte bagaimana database beroperasi
di bawah kondisi yang sangat spesifik.
Dan kita akan berbicara tentang apa kondisi yang.
Tapi tiga poin dari segitiga, sehingga untuk berbicara, adalah C, konsistensi.
OKE?
Jadi di CAP, konsistensi berarti bahwa semua klien yang dapat mengakses database
akan selalu memiliki sangat tampilan yang konsisten dari data.
Tidak ada yang akan melihat dua hal yang berbeda.
OKE?
Jika saya melihat database, Saya melihat pandangan yang sama
sebagai mitra saya yang melihat database yang sama.
Itu konsistensi.
>> Ketersediaan berarti bahwa jika database online, jika dapat tercapai,
bahwa semua klien akan selalu dapat membaca dan menulis.
OKE?
Jadi setiap klien yang dapat membaca database
akan selalu dapat dibaca data dan menulis data.
Dan jika itu yang terjadi, itu sebuah sistem yang tersedia.
>> Dan titik ketiga adalah apa yang kita sebut toleransi partisi.
OKE?
Toleransi partisi berarti bahwa sistem bekerja dengan baik
meskipun jaringan fisik partisi antara node.
OKE?
Jadi node di cluster tidak bisa berbicara satu sama lain, apa yang terjadi?
Baiklah.
>> Database sehingga relasional choose-- Anda dapat memilih dua ini.
OKE.
Database sehingga relasional pilih untuk konsisten dan tersedia.
Jika partisi terjadi antara yang DataNodes dalam menyimpan data,
database crash.
Kanan?
Itu hanya turun.
OKE.
>> Dan ini adalah mengapa mereka memiliki tumbuh dengan kotak besar.
Kanan?
Karena ada no-- biasanya, cluster Database, tidak ada sangat banyak dari mereka
yang beroperasi dengan cara itu.
Tapi kebanyakan database skala vertikal dalam kotak tunggal.
Karena mereka harus konsisten dan tersedia.
Jika partisi yang harus disuntikkan, maka Anda akan harus membuat pilihan.
Anda harus membuat pilihan antara konsisten dan tersedia.
>> Dan itulah yang database NoSQL lakukan.
Baiklah.
Jadi database NoSQL, itu datang dalam dua rasa.
Kami have-- dengan baik, datang dalam berbagai rasa,
tetapi ia datang dengan dua dasar characteristics-- apa
kita akan memanggil database CP, atau toleransi konsisten dan partisi
sistem.
Orang-orang membuat pilihan bahwa ketika node kehilangan kontak dengan satu sama lain,
kita tidak akan membiarkan orang untuk menulis lagi.
OKE?
>> Sampai partisi yang dihapus, akses tulis diblokir.
Itu berarti mereka tidak tersedia.
Mereka konsisten.
Ketika kita melihat bahwa partisi menyuntikkan sendiri,
kita sekarang konsisten, karena kita tidak akan
untuk memungkinkan perubahan data pada dua sisi partisi independen
satu sama lain.
Kita harus kembali komunikasi
sebelum update ke Data yang diperbolehkan.
OKE?
>> Rasa berikutnya akan menjadi sistem AP, atau tersedia dan dipartisi
sistem toleransi.
Orang-orang ini tidak peduli.
Kanan?
Setiap node yang mendapat menulis, kami akan mengambilnya.
Jadi aku mereplikasi data saya di beberapa node.
Node ini mendapatkan klien, klien datang di, mengatakan, aku akan menulis beberapa data.
Node mengatakan, tidak ada masalah.
Node sampingnya mendapat menulis pada catatan yang sama,
dia akan mengatakan tidak ada masalah.
Suatu tempat kembali di ujung belakang, Data itu akan meniru.
Dan kemudian seseorang akan menyadari, uh-oh, sistem mereka akan menyadari, uh-oh,
sudah ada update untuk kedua belah pihak.
Apa yang kita lakukan?
Dan apa yang mereka lakukan adalah mereka melakukan sesuatu yang
memungkinkan mereka untuk menyelesaikan bahwa negara data.
Dan kita akan berbicara tentang bahwa dalam grafik berikutnya.
>> Hal yang menunjukkan di sini.
Dan aku tidak akan terlalu banyak ke dalam ini, karena ini
masuk ke teori Data dalam.
Tapi ada transaksional yang kerangka yang
berjalan di sistem relasional yang memungkinkan saya untuk aman melakukan update
untuk beberapa entitas dalam database.
Dan update tersebut akan terjadi sekaligus atau tidak sama sekali.
Dan ini disebut transaksi ACID.
OKE?
>> ACID memberi kita atomicity, konsistensi, isolasi, dan daya tahan.
OKE?
Itu berarti atom, transaksi, semua update saya baik terjadi atau tidak.
Konsistensi berarti bahwa database akan selalu
dibawa ke dalam konsisten negara setelah update.
Aku tidak akan pernah meninggalkan database dalam keadaan buruk setelah menerapkan pembaruan.
OKE?
>> Jadi itu adalah sedikit berbeda dari konsistensi CAP.
Konsistensi CAP berarti semua saya klien selalu dapat melihat data.
Konsistensi ACID berarti bahwa ketika transaksi dilakukan, data yang baik.
Hubungan saya semua baik.
Aku tidak akan menghapus baris tua dan meninggalkan sekelompok anak-anak yatim piatu
di beberapa meja lain.
Hal ini tidak bisa terjadi jika saya konsisten dalam transaksi asam.
>> Isolasi berarti bahwa transaksi akan selalu terjadi satu demi satu.
Hasil akhir dari data akan menjadi negara yang sama
seolah-olah transaksi tersebut yang diterbitkan bersamaan
dieksekusi serial.
Jadi itu konkurensi kontrol dalam database.
Jadi pada dasarnya, saya tidak bisa kenaikan nilai yang sama dua kali dengan dua operasi.
>> Tapi jika saya katakan tambahkan 1 untuk nilai ini, dan dua transaksi datang dalam
dan mencoba untuk melakukannya, salah satu yang akan sampai di sana pertama
dan yang lain akan ke sana setelah.
Jadi pada akhirnya, saya menambahkan dua.
Anda melihat apa yang saya maksud?
OKE.
>> Daya tahan cukup sederhana.
Ketika transaksi diakui, itu
akan berada di sana bahkan jika sistem crash.
Ketika sistem yang pulih, yang transaksi yang dilakukan
sebenarnya akan berada di sana.
Jadi itulah jaminan transaksi ACID.
Mereka adalah jaminan cukup bagus untuk memiliki di database,
tetapi mereka datang dengan biaya itu.
Kanan?
>> Karena masalah dengan kerangka ini
jika ada partisi dalam data set, saya harus membuat keputusan.
Aku akan harus memungkinkan update di satu sisi atau yang lain.
Dan jika itu terjadi, maka aku tidak lagi akan
untuk dapat mempertahankan karakteristik.
Mereka tidak akan konsisten.
Mereka tidak akan terisolasi.
Di sinilah itu rusak untuk database relasional.
Ini adalah alasan relasional database skala vertikal.
>> Di sisi lain, kita memiliki apa yang disebut teknologi BASIS.
Dan ini adalah NoSQL Database Anda.
Baiklah.
Jadi kita harus CP kami, database AP.
Dan ini adalah apa yang Anda sebut pada dasarnya tersedia, negara lembut, akhirnya
konsisten.
OKE?
>> Pada dasarnya tersedia, karena mereka toleran partisi.
Mereka akan selalu ada, bahkan jika ada
partisi jaringan antara node.
Jika saya dapat berbicara dengan sebuah node, aku akan dapat membaca data.
OKE?
Aku mungkin tidak selalu bisa menulis data jika aku platform yang konsisten.
Tapi saya akan dapat membaca data.
>> Negara lembut menunjukkan bahwa ketika saya membaca data itu,
tidak mungkin sama dengan node lain.
Jika hak dikeluarkan pada node tempat lain di cluster
dan belum direplikasi di seluruh klaster namun ketika saya membaca bahwa data,
negara yang mungkin tidak konsisten.
Namun, itu akan menjadi akhirnya konsisten,
yang berarti bahwa ketika menulis sebuah dibuat untuk sistem,
itu akan mereplikasi di node.
Dan akhirnya, negara yang akan dibawa ke urutan,
dan itu akan menjadi negara yang konsisten.
>> Sekarang, CAP teorema benar memainkan hanya dalam satu kondisi.
Kondisi yang saat ini terjadi.
Karena setiap kali itu beroperasi di mode normal, tidak ada partisi,
semuanya konsisten dan tersedia.
Anda hanya khawatir tentang CAP ketika kita memiliki partisi itu.
Jadi mereka adalah langka.
Tapi bagaimana sistem bereaksi ketika mereka terjadi mendikte apa jenis sistem
kita sedang berhadapan dengan.
>> Jadi mari kita lihat apa yang yang terlihat seperti untuk sistem AP.
OKE?
Sistem AP datang dalam dua rasa.
Mereka datang dalam rasa yang adalah Master Master, 100%, selalu tersedia.
Dan mereka datang dalam rasa lainnya, yang mengatakan,
Anda tahu apa, aku akan khawatir tentang hal ini partisi
ketika partisi yang sebenarnya terjadi.
Jika tidak, ada akan menjadi primary node yang akan mengambil hak.
OKE?
>> Jadi jika kita sesuatu seperti Cassandra.
Cassandra akan menjadi master Master, mari saya menulis untuk setiap node.
Jadi apa yang terjadi?
Jadi saya memiliki objek di database yang ada pada dua node.
Mari kita sebut bahwa objek S. Jadi kita memiliki negara untuk S.
Kami memiliki beberapa operasi pada S yang sedang berlangsung.
Cassandra memungkinkan saya untuk menulis ke beberapa node.
Jadi katakanlah saya mendapatkan menulis untuk s untuk dua node.
Nah, apa yang akhirnya terjadi adalah kita sebut bahwa acara partisi.
Ada mungkin bukan partisi jaringan fisik.
Tetapi karena desain sistem, itu
sebenarnya partisi segera karena saya mendapatkan write pada dua node.
Ini tidak memaksa saya untuk menulis semua melalui satu simpul.
Aku menulis pada dua node.
OKE?
>> Jadi sekarang aku punya dua negara.
OKE?
Apa yang akan terjadi adalah cepat atau lambat,
ada akan menjadi peristiwa replikasi.
Ada akan menjadi apa yang kita disebut pemulihan partisi, yang
adalah di mana kedua negara kembali bersama-sama
dan ada akan menjadi sebuah algoritma yang berjalan di dalam database,
memutuskan apa yang harus dilakukan.
OKE?
Secara default, update terakhir menang di sebagian besar sistem AP.
Jadi biasanya ada algoritma default, apa
mereka sebut callback fungsi, sesuatu yang
akan dipanggil ketika kondisi ini terdeteksi untuk menjalankan beberapa logika
untuk menyelesaikan konflik itu.
OKE?
The callback default dan standar penyelesai di sebagian besar database AP
adalah, coba tebak, timestamp menang.
Ini adalah update terakhir.
Aku akan menempatkan pembaruan yang di sana.
Aku mungkin membuang catatan ini bahwa saya dibuang off menjadi log pemulihan
sehingga pengguna dapat kembali lagi nanti dan berkata, hey, ada tabrakan.
Apa yang terjadi?
Dan Anda benar-benar dapat membuang catatan semua tabrakan dan rollbacks
dan melihat apa yang terjadi.
>> Sekarang, sebagai pengguna, Anda juga bisa termasuk logika ke callback itu.
Jadi Anda dapat mengubah itu operasi callback.
Anda dapat mengatakan, hei, saya ingin untuk memulihkan data ini.
Dan saya ingin mencoba dan menggabungkan dua catatan.
Tapi itu terserah Anda.
Database tidak tahu bagaimana melakukannya secara default. Sebagian besar waktu,
satu-satunya hal database yang tahu bagaimana melakukan ini mengatakan,
satu ini catatan terakhir.
Itu salah satu yang akan menang, dan itulah nilai aku akan menempatkan.
Setelah itu pemulihan partisi dan replikasi terjadi,
kami memiliki negara kita, yang sekarang S perdana, yang merupakan
negara gabungan dari semua objek tersebut.
Jadi sistem AP memiliki ini.
Sistem CP tidak perlu khawatir tentang hal ini.
Karena begitu partisi datang ke dalam bermain, mereka hanya berhenti mengambil
menulis.
OKE?
Sehingga sangat mudah untuk berurusan dengan konsisten
ketika Anda tidak menerima pembaruan.
Itu dengan sistem CP lakukan.
Baiklah.
>> Jadi mari kita bicara sedikit sedikit tentang pola akses.
Ketika kita berbicara tentang NoSQL, itu semua tentang pola akses.
Sekarang, SQL adalah ad hoc, query.
Ini toko relasional.
Kami tidak perlu khawatir tentang pola akses.
Saya menulis query yang sangat kompleks.
Ia pergi dan mendapatkan data.
Itulah yang ini terlihat seperti, normalisasi.
>> Jadi dalam struktur tertentu, kita sedang melihat katalog produk.
Saya memiliki berbagai jenis produk.
Saya memiliki buku-buku.
Saya memiliki album.
Saya memiliki video.
Hubungan antara produk dan salah satu dari buku-buku, album,
dan video tabel adalah 1: 1.
Baiklah?
Aku punya ID produk, dan bahwa ID berkorespondensi
untuk buku, album, atau video.
OKE?
Itu 1: 1 hubungan di meja tersebut.
>> Sekarang, books-- semua mereka miliki adalah sifat akar.
Tidak masalah.
Itu bagus.
Satu-ke-satu hubungan, saya mendapatkan semua data yang saya butuhkan untuk menggambarkan buku itu.
Album Albums-- memiliki trek.
Ini adalah apa yang kita sebut satu ke banyak.
Setiap album bisa memiliki banyak lagu.
Jadi untuk setiap lagu pada album, aku bisa memiliki
catatan lain dalam tabel anak ini.
Jadi saya membuat satu record dalam tabel album saya.
Saya membuat beberapa catatan dalam tabel trek.
Satu-ke-banyak hubungan.
>> Hubungan ini adalah apa yang kita sebut banyak-ke-banyak.
OKE?
Anda melihat bahwa pelaku bisa di banyak film, banyak video.
Jadi apa yang kita lakukan adalah kita menempatkan pemetaan ini meja antara, yang hanya
peta aktor ID ke ID video.
Sekarang saya bisa membuat query bergabung video melalui aktor video ke aktor,
dan itu memberi saya sebuah daftar dari semua film dan semua aktor
yang dalam film itu.
>> OKE.
Jadi di sini kita pergi.
Satu-ke-satu adalah top-level hubungan; satu-ke-banyak,
album ke trek; banyak-ke-banyak.
Mereka adalah tiga tingkat atas hubungan dalam database apapun.
Jika Anda tahu bagaimana mereka hubungan bekerja sama,
maka Anda tahu banyak tentang database sudah.
Jadi NoSQL bekerja sedikit berbeda.
Mari kita berpikir tentang untuk kedua apa terlihat ingin pergi mendapatkan semua produk saya.
>> Dalam sebuah toko relasional, saya ingin mendapatkan semua produk saya
pada daftar semua produk saya.
Itu banyak pertanyaan.
Saya punya pertanyaan untuk semua buku-buku saya.
Saya mendapat pertanyaan dari album saya.
Dan saya mendapat permintaan untuk semua video saya.
Dan aku harus meletakkannya semua bersama-sama dalam daftar
dan melayani kembali ke aplikasi yang meminta itu.
>> Untuk mendapatkan buku-buku saya, saya bergabung Produk dan Buku.
Untuk mendapatkan album saya, saya harus bergabung Produk, Album, dan Trek.
Dan untuk mendapatkan video saya, saya memiliki untuk bergabung Produk untuk Video,
bergabung melalui Aktor Video, dan membawa Aktor.
Jadi itulah tiga pertanyaan.
Pertanyaan yang sangat kompleks untuk merakit satu set hasil.
>> Itu kurang optimal.
Itulah sebabnya ketika kita berbicara tentang struktur data yang
dibangun untuk menjadi agnostik untuk akses pattern-- baik itu besar.
Dan Anda dapat melihat ini benar-benar bagus bagaimana kita telah mengatur data.
Dan kau tahu apa?
Saya hanya memiliki satu catatan untuk seorang aktor.
>> Keren.
Saya sudah deduplicated semua aktor saya, dan saya dipelihara asosiasi saya
dalam tabel pemetaan ini.
Namun, mendapatkan data keluar menjadi mahal.
Saya mengirim CPU seluruh sistem bergabung struktur data ini bersama-sama
untuk dapat menarik bahwa data kembali.
>> Jadi bagaimana saya mendapatkan sekitar itu?
Dalam NoSQL ini tentang agregasi, tidak normalisasi.
Jadi kita ingin mengatakan kami ingin mendukung pola akses.
Jika pola akses untuk aplikasi,
Saya perlu untuk mendapatkan semua produk saya.
Mari kita menempatkan semua produk dalam satu meja.
Jika saya menempatkan semua produk dalam satu meja, Aku hanya bisa memilih semua produk
dari meja itu dan aku mendapatkan itu semua.
Nah bagaimana cara melakukannya?
Nah di NoSQL tidak ada struktur ke meja.
Kami akan berbicara sedikit tentang bagaimana ini bekerja di Dynamo DB.
Tapi Anda tidak memiliki sama atribut dan sifat yang sama
di setiap baris, di setiap satu item, seperti yang Anda lakukan di meja SQL.
Dan apa ini memungkinkan saya untuk melakukan banyak hal
dan memberi saya banyak fleksibilitas.
Dalam kasus ini, saya memiliki dokumen produk saya.
Dan dalam hal ini khususnya Misalnya, semuanya
adalah dokumen dalam tabel Produk.
Dan produk untuk sebuah buku mungkin memiliki ID jenis yang menentukan sebuah buku.
Dan aplikasi akan beralih pada ID itu.
>> Pada tingkat aplikasi, aku akan mengatakan oh, apa catatan jenis ini?
Oh, itu catatan buku.
Catatan buku memiliki sifat ini.
Biarkan saya membuat objek buku.
Jadi aku akan mengisi objek buku dengan item ini.
Item berikutnya datang dan mengatakan, apa item ini?
Nah item ini adalah sebuah album.
Oh, aku punya yang berbeda secara keseluruhan pengolahan rutin untuk itu,
karena itu album.
Anda melihat apa yang saya maksud?
>> Jadi aplikasi tier-- saya hanya memilih semua catatan tersebut.
Mereka semua mulai datang di.
Mereka bisa menjadi semua jenis.
Dan itu logika aplikasi yang switch di jenis-jenis
dan memutuskan bagaimana mengolahnya.
>> Sekali lagi, jadi kita mengoptimalkan skema untuk pola akses.
Kami melakukannya dengan runtuh meja tersebut.
Kami pada dasarnya mengambil ini struktur normal,
dan kami sedang membangun struktur hirarkis.
Di dalam masing-masing dari catatan-catatan Aku akan melihat sifat array.
>> Di dalam dokumen ini untuk Album, Saya melihat array dari trek.
Mereka trek sekarang become-- itu pada dasarnya tabel anak ini yang
ada di sini, di struktur ini.
Sehingga Anda dapat melakukan ini di DynamoDB.
Anda dapat melakukan ini di MongoDB.
Anda dapat melakukan ini di database NoSQL.
Buat jenis struktur data hirarkis
yang memungkinkan Anda mengambil data sangat cepat karena sekarang saya
tidak perlu menyesuaikan diri.
Ketika saya memasukkan baris ke Trek tabel, atau baris ke dalam tabel Album,
Saya harus menyesuaikan diri dengan skema itu.
Saya harus memiliki atribut atau properti yang didefinisikan di atas meja itu.
Setiap salah satu dari mereka, ketika saya menyisipkan baris itu.
Itu tidak terjadi di NoSQL.
>> Saya dapat memiliki sama sekali berbeda properti di setiap dokumen
yang saya masukkan ke dalam koleksi.
Mekanisme jadi sangat kuat.
Dan itu benar-benar bagaimana Anda mengoptimalkan sistem.
Karena sekarang permintaan, bukan bergabung semua tabel ini
dan mengeksekusi setengah lusin query untuk menarik kembali data yang saya butuhkan,
Saya menjalankan satu permintaan.
Dan aku iterasi seluruh hasil set.
itu memberi Anda ide dari kekuatan NoSQL.
Aku akan jenis pergi ke samping sini dan berbicara sedikit tentang hal ini.
Ini lebih baik dari pemasaran atau technology--
pemasaran teknologi jenis diskusi.
Tapi itu penting untuk memahami karena jika kita melihat di bagian atas
di sini di grafik ini, apa yang kita sedang melihat
adalah apa yang kita sebut teknologi kurva sensasi.
Dan apa ini berarti barang baru datang ke dalam bermain.
Orang pikir itu bagus.
Saya telah memecahkan semua masalah saya.
>> Ini bisa menjadi akhir semua, menjadi semua untuk semuanya.
Dan mereka mulai menggunakannya.
Dan mereka berkata, hal ini tidak bekerja.
Ini tidak benar.
Barang lama lebih baik.
Dan mereka kembali untuk melakukan sesuatu dengan cara mereka.
Dan kemudian akhirnya mereka pergi, Anda tahu apa?
Hal ini tidak begitu buruk.
Oh, itu cara kerjanya.
Dan setelah mereka mengetahui bagaimana karya, mereka mulai mendapatkan yang lebih baik.
>> Dan hal lucu tentang hal itu adalah, itu jenis garis sampai apa
kita sebut Curve Adopsi Teknologi.
Jadi apa yang terjadi adalah kita harus beberapa pemicu teknologi semacam.
Dalam kasus database, itu tekanan data.
Kami berbicara tentang poin air yang tinggi tekanan data seluruh waktu.
Ketika tekanan Data hits tertentu titik, itu pemicu teknologi.
>> Sudah mulai terlalu mahal.
Waktu terlalu lama untuk memproses data.
Kita perlu sesuatu yang lebih baik.
Anda mendapatkan inovator di luar sana berlarian,
mencoba untuk mencari tahu apa solusinya.
Apa ide baru?
>> Apa yang terbaik berikutnya cara untuk melakukan hal ini?
Dan mereka datang dengan sesuatu.
Dan orang-orang dengan rasa sakit yang nyata, orang-orang di tepi pendarahan,
mereka akan melompat di atasnya, karena mereka butuh jawaban.
Sekarang apa yang pasti happens-- dan itu terjadi sekarang di NoSQL.
Saya melihatnya sepanjang waktu.
>> Apa yang pasti terjadi adalah orang mulai menggunakan alat baru
dengan cara yang sama mereka menggunakan alat tua.
Dan mereka tahu itu tidak bekerja dengan baik.
Saya tidak ingat siapa aku berbicara dengan hari sebelumnya.
Tapi seperti, ketika Konyol diciptakan,
orang tidak ayunan itu lebih kepala mereka untuk menghancurkan beton.
>> Tapi itu adalah apa yang terjadi dengan NoSQL hari ini.
Jika Anda berjalan di kebanyakan toko, mereka mencoba untuk menjadi toko NoSQL.
Apa yang mereka lakukan adalah mereka menggunakan NoSQL,
dan mereka loading penuh skema relasional.
Karena itu bagaimana mereka merancang database.
Dan mereka bertanya-tanya, mengapa tidak melakukan dengan sangat baik?
Boy, hal ini bau.
Aku harus menjaga semua saya bergabung in-- itu seperti, tidak, tidak.
Menjaga bergabung?
Mengapa Anda bergabung data?
Anda tidak bergabung data dalam NoSQL.
Anda agregat itu.
>> Jadi jika Anda ingin menghindari ini, belajar bagaimana alat bekerja sebelum Anda benar-benar
mulai menggunakannya.
Jangan mencoba dan menggunakan alat-alat baru cara yang sama Anda menggunakan alat tua.
Anda akan memiliki pengalaman buruk.
Dan setiap kali itulah yang ini adalah tentang.
Ketika kita mulai datang ke sini, itu karena orang tahu
bagaimana menggunakan alat-alat.
>> Mereka melakukan hal yang sama ketika database relasional diciptakan,
dan mereka mengganti file sistem.
Mereka mencoba untuk membangun sistem berkas dengan database relasional
karena itulah yang orang mengerti.
Ini tidak bekerja.
Jadi memahami praktik terbaik teknologi Anda bekerja dengan
sangat besar.
Sangat penting.
>> Jadi kita akan masuk ke DynamoDB.
DynamoDB adalah AWS ini sepenuhnya dikelola platform yang NoSQL.
Apa sepenuhnya dikelola artinya?
Ini berarti Anda tidak perlu benar-benar khawatir tentang apa pun.
>> Anda datang, Anda memberitahu kami, aku butuh meja.
Perlu kapasitas jauh ini.
Anda menekan tombol, dan kami penyediaan semua infrastruktur di belakang layar.
Sekarang sangat besar.
>> Karena ketika Anda berbicara tentang scaling database,
Cluster Data NoSQL di skala, petabyte berjalan,
menjalankan jutaan transaksi per detik,
hal ini tidak kelompok kecil.
Kita bicara ribuan kasus.
Mengelola ribuan kasus, bahkan contoh virtual,
adalah rasa sakit yang nyata di pantat.
Maksud saya, berpikir tentang setiap kali Patch sistem operasi keluar
atau versi baru dari database.
maksudnya itu apa Anda operasional?
Itu berarti Anda punya 1.200 server yang perlu diperbarui.
Sekarang bahkan dengan otomatisasi, yang dapat memakan waktu yang lama.
Yang dapat menyebabkan banyak sakit kepala operasional,
karena saya mungkin memiliki layanan turun.
>> Seperti yang saya memperbarui database ini, saya mungkin melakukan penyebaran hijau biru
di mana saya menyebarkan dan meng-upgrade setengah node, dan kemudian meng-upgrade setengah lainnya.
Mengambil orang-orang bawah.
Jadi pengelolaan infrastruktur skala adalah sangat besar menyakitkan.
Dan AWS mengambil rasa sakit yang keluar dari itu.
Dan database NoSQL bisa menjadi sangat menyakitkan
karena cara mereka skala.
>> Skala horisontal.
Jika Anda ingin mendapatkan lebih besar NoSQL Database, Anda membeli lebih node.
Setiap simpul yang Anda beli adalah sakit kepala operasional lain.
Jadi biarkan orang lain melakukannya untuk Anda.
AWS bisa melakukan itu.
>> Kami mendukung nilai-nilai kunci dokumen.
Sekarang kita tidak pergi terlalu banyak ke pada grafik lainnya.
Ada banyak yang berbeda rasa NoSQL.
Mereka semua jenis mendapatkan munged bersama pada saat ini.
Anda dapat melihat DynamoDB dan mengatakan ya, kami berdua dokumen dan nilai kunci
menyimpan titik ini.
Dan Anda bisa berdebat fitur dari satu atas yang lain.
Bagi saya, banyak ini benar-benar enam satu setengah lusin yang lain.
Setiap salah satu dari teknologi tersebut adalah teknologi baik dan solusi yang baik.
Saya tidak akan mengatakan MongoDB lebih baik atau lebih buruk dari Couch, kemudian Cassandra,
kemudian Dynamo, atau sebaliknya.
Maksudku, ini hanya pilihan.
>> Ini cepat dan itu konsisten pada skala apapun.
Jadi ini adalah salah satu yang terbesar bonus yang Anda dapatkan dengan AWS.
Dengan DynamoDB adalah kemampuan untuk mendapatkan satu digit rendah
milidetik latency pada skala apapun.
Itu adalah tujuan desain sistem.
Dan kami memiliki pelanggan yang melakukan jutaan transaksi per detik.
>> Sekarang saya akan pergi melalui beberapa dari mereka menggunakan kasus dalam beberapa menit di sini.
Terpadu control-- akses kita memiliki apa yang kita sebut
Identitas Access Management, atau IAM.
Ini menembus setiap sistem, setiap layanan yang menawarkan AWS.
DynamoDB tidak terkecuali.
Anda dapat mengontrol akses ke meja DynamoDB.
Di semua AWS Anda rekening oleh mendefinisikan peran akses dan izin
dalam infrastruktur IAM.
>> Dan itu adalah komponen kunci dan integral dalam apa yang kita sebut acara Driven Programming.
Sekarang ini adalah sebuah paradigma baru.
>> AUDIENCE: Bagaimana tingkat Anda benar positif terhadap negatif palsu
pada sistem kontrol akses Anda?
RICK Houlihan: Benar positif dibandingkan negatif palsu?
AUDIENCE: Kembali apa Anda harus kembali?
Sebagai lawan sesekali itu tidak kembali ketika harus memvalidasi?
>> RICK Houlihan: Saya tidak bisa memberitahu Anda bahwa.
Jika ada kegagalan setiap apapun pada itu,
Saya bukan orang yang meminta pertanyaan tertentu.
Tapi itu pertanyaan yang bagus.
Saya akan penasaran ingin tahu itu sendiri, sebenarnya.
>> Dan sekali lagi, paradigma baru adalah pemrograman event driven.
Ini adalah gagasan bahwa Anda bisa menyebarkan aplikasi kompleks yang
dapat beroperasi sangat, skala sangat tinggi tanpa infrastruktur apapun.
Tanpa tetap infrastruktur apapun.
Dan kita akan berbicara sedikit tentang apa artinya seperti yang kita
mendapatkan ke beberapa berikutnya grafik.
>> Hal pertama yang akan kita lakukan adalah kita akan berbicara tentang meja.
Tipe data API untuk Dynamo.
Dan hal pertama yang Anda akan melihat ketika Anda melihat ini,
jika Anda terbiasa dengan database apapun, database telah benar-benar dua jenis API
Saya akan menyebutnya.
Atau dua set API.
Salah satu dari mereka akan API administrasi.
>> Hal-hal yang mereka mengurus fungsi database.
Konfigurasi mesin penyimpanan, pengaturan dan menambahkan tabel.
membuat database katalog dan contoh.
Things-- ini di DynamoDB, Anda memiliki sangat singkat, daftar singkat.
>> Jadi dalam database lain, Anda mungkin melihat puluhan
dari perintah, dari administrasi perintah, untuk mengkonfigurasi
ini opsi tambahan.
Dalam DynamoDB Anda tidak perlu mereka karena Anda tidak mengkonfigurasi sistem, kita lakukan.
Jadi satu-satunya hal yang perlu Anda lakukan adalah ceritakan apa ukuran meja yang saya butuhkan.
Jadi Anda mendapatkan sangat perintah terbatas.
>> Anda mendapatkan Membuat Tabel Update, Table, Hapus Tabel, dan Jelaskan Tabel.
Mereka adalah satu-satunya hal yang Anda perlu untuk DynamoDB.
Anda tidak perlu penyimpanan konfigurasi mesin.
Saya tidak perlu khawatir tentang replikasi.
Saya tidak perlu khawatir tentang sharding.
>> Saya tidak perlu khawatir mengenai hal ini.
Kami melakukan semuanya untuk Anda.
Jadi itu sejumlah besar overhead itu hanya mengangkat dari piring Anda.
Maka kita memiliki operator CRUD.
CRUD adalah sesuatu yang kita sebut dalam database itu
Buat, Update, Delete operator.
Ini adalah umum Anda operasi database.
Hal-hal seperti put item, mendapatkan item, pembaruan item, menghapus item, query batch, memindai.
Jika Anda ingin memindai seluruh tabel.
Tarik segala sesuatu dari meja.
Salah satu hal yang menyenangkan tentang DynamoDB itu memungkinkan pemindaian paralel.
Sehingga Anda dapat benar-benar membiarkan saya tahu berapa banyak benang Anda ingin menjalankan pemindaian itu.
Dan kita dapat menjalankan mereka benang.
Kita dapat berputar yang memindai up di beberapa thread
sehingga Anda dapat memindai seluruh tabel ruang yang sangat, sangat cepat di DynamoDB.
>> API lainnya yang kita miliki adalah apa yang kita sebut Streaming API kami.
Kami tidak akan berbicara terlalu banyak tentang ini sekarang.
Saya punya beberapa konten kemudian di dalam dek tentang hal ini.
Tapi Streaming benar-benar sebuah running-- menganggapnya sebagai memerintahkan waktu
dan log perubahan partisi.
Segala sesuatu yang terjadi di tabel muncul di sungai.
>> Setiap menulis ke meja muncul di sungai.
Anda dapat membaca sungai itu, dan Anda dapat melakukan hal-hal dengan itu.
Kita akan berbicara tentang apa jenis hal yang Anda
hubungannya dengan hal-hal seperti replikasi, membuat indeks sekunder.
Semua jenis benar-benar keren hal yang dapat Anda lakukan dengan itu.
>> Tipe data.
Dalam DynamoDB, kami mendukung kunci nilai dan data dokumen jenis.
Di sisi kiri layar di sini, kami punya tipe dasar kami.
Nilai kunci jenis.
Ini adalah string, nomor, dan binari.
>> Jadi hanya tiga tipe dasar.
Dan kemudian Anda dapat memiliki set mereka.
Salah satu hal yang menyenangkan tentang NoSQL adalah Anda dapat berisi array sebagai properti.
Dan dengan DynamoDB Anda dapat berisi array dari jenis dasar sebagai properti root.
>> Dan kemudian ada jenis dokumen.
Berapa banyak orang yang akrab dengan JSON?
Kalian akrab dengan JSON begitu banyak?
Ini pada dasarnya JavaScript, Objek, Notasi.
Hal ini memungkinkan Anda untuk dasarnya mendefinisikan struktur hirarkis.
>> Anda dapat menyimpan dokumen JSON pada DynamoDB menggunakan komponen umum
atau blok bangunan yang tersedia dalam kebanyakan bahasa pemrograman.
Jadi jika Anda memiliki Java, Anda melihat peta dan daftar.
Aku bisa membuat objek yang peta area.
Sebuah peta dengan nilai-nilai kunci disimpan sebagai properti.
Dan mungkin memiliki daftar nilai-nilai dalam properti-properti.
Anda dapat menyimpan kompleks ini struktur hirarkis
sebagai atribut tunggal dari item DynamoDB.
>> Jadi tabel di DynamoDB, seperti kebanyakan Database NoSQL, tabel memiliki item.
Dalam MongoDB Anda akan menyebut dokumen-dokumen ini.
Dan itu akan menjadi dasar sofa.
Juga database dokumen.
Anda memanggil dokumen-dokumen ini.
Dokumen atau barang memiliki atribut.
Atribut dapat eksis atau tidak ada pada item.
Dalam DynamoDB, ada satu atribut wajib.
Sama seperti dalam database relasional, Anda memiliki kunci utama pada tabel.
>> DynamoDB memiliki apa yang kita sebut kunci hash.
Kunci hash harus unik.
Jadi ketika saya mendefinisikan tabel hash, pada dasarnya apa yang saya katakan
adalah setiap item akan memiliki kunci hash.
Dan setiap kunci hash harus unik.
>> Setiap item didefinisikan dengan itu kunci hash unik.
Dan hanya ada satu.
Ini adalah OK, tetapi seringkali apa yang orang butuhkan
adalah mereka inginkan adalah hash ini Kunci untuk melakukan sedikit lebih
dari sekedar menjadi pengenal unik.
Sering kali kita ingin menggunakan kunci hash sebagai tingkat atas agregasi ember.
Dan cara kita melakukan itu adalah dengan menambahkan apa yang kita sebut kunci jangkauan.
>> Jadi jika itu hash hanya meja, ini harus unik.
Jika itu adalah tabel hash dan jangkauan, Kombinasi hash dan jangkauan
harus unik.
Jadi berpikir tentang cara ini.
Jika saya memiliki sebuah forum.
Dan bentuk memiliki topik, ia memiliki posting, dan memiliki tanggapan.
>> Jadi saya mungkin memiliki hash kunci, yang merupakan ID topik.
Dan aku mungkin memiliki kunci jangkauan, yang merupakan ID respon.
Dengan cara itu jika saya ingin mendapatkan semua tanggapan untuk topik tertentu,
Aku hanya bisa query hash.
Saya hanya bisa mengatakan memberikan saya semua item yang memiliki hash ini.
Dan aku akan mendapatkan setiap pertanyaan atau posting untuk topik tertentu.
Ini agregasi tingkat atas sangat penting.
Mereka mendukung akses utama pola aplikasi.
Secara umum, ini adalah apa yang ingin kita lakukan.
Kami ingin table-- yang Anda memuat meja,
kami ingin struktur data dalam tabel sedemikian rupa
bahwa aplikasi dapat sangat cepat mengambil hasil tersebut.
Dan seringkali cara untuk melakukannya adalah untuk mempertahankan agregasi ini seperti yang kita
memasukkan data.
Pada dasarnya, kita menyebarkan data ke dalam ember terang seperti itu datang dalam.
>> Kunci Kisaran memungkinkan hash me-- Kunci harus kesetaraan.
Ketika saya query hash, saya harus mengatakan memberi saya hash yang sama ini.
Ketika saya query kisaran, saya bisa mengatakan memberi saya rentang
yang menggunakan segala jenis Operator kaya yang kami mendukung.
Beri aku semua item untuk hash.
Apakah sama, lebih besar dari, kurang dari, apakah itu dimulai dengan,
apakah itu ada di antara dua nilai tersebut?
Jadi jenis berbagai pertanyaan bahwa kita selalu tertarik.
Sekarang satu hal tentang data, ketika Anda melihat mengakses data, ketika
Anda mengakses data, itu selalu tentang agregasi.
Ini selalu tentang catatan yang terkait dengan ini.
Beri aku semuanya di sini that's-- semua transaksi pada kartu kredit ini
untuk bulan lalu.
Itu merupakan agregasi.
>> Hampir semua yang Anda lakukan dalam database semacam agregasi.
Jadi bisa dapat mendefinisikan ini ember dan memberikan berbagai ini
atribut untuk bisa query pada, mereka query kaya mendukung banyak,
banyak, banyak pola akses aplikasi.
>> Jadi hal lain kunci hash Apakah itu memberi kita suatu mekanisme
untuk dapat menyebarkan data sekitar.
Database NoSQL bekerja terbaik ketika data tersebut merata
didistribusikan di cluster.
Berapa banyak orang yang akrab dengan hashing algoritma?
Ketika saya mengatakan hash dan hashing-- sebuah karena algoritma hashing
adalah cara untuk dapat menghasilkan nilai acak dari setiap nilai yang diberikan.
Jadi dalam kasus ini, yang algoritma hash kita jalankan adalah ND 5 berdasarkan.
>> Dan jika saya memiliki ID, dan ini adalah kunci hash saya, saya memiliki 1, 2, 3.
Ketika saya menjalankan algoritma hash, itu akan datang kembali dan berkata,
juga 1 sama dengan 7B, 2 sama dengan 48, 3 sama dengan CD.
Mereka tersebar di seluruh ruang kunci.
Dan mengapa Anda melakukan ini?
Karena yang membuat yakin bahwa saya bisa menempatkan catatan di beberapa node.
>> Jika aku melakukan ini secara bertahap, 1, 2, 3.
Dan saya memiliki berbagai hash yang berjalan dalam kasus ini,
ruang hash kecil, berjalan dari 00 ke FF,
maka catatan akan datang dan mereka akan pergi 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12.
Apa yang terjadi?
Setiap insert akan node yang sama.
Anda melihat apa yang saya maksud?
>> Karena ketika aku membagi ruang, dan saya menyebarkan catatan ini di,
dan partisi saya, aku akan mengatakan partisi 1 memiliki ruang kunci 0-54.
Partisi 2 adalah 55-89.
Partisi 3 adalah AA untuk FF.
Jadi jika saya menggunakan linear incrementing ID, Anda dapat melihat apa yang terjadi.
1, 2, 3, 4, 5, 6, semua jalan sampai ke 54.
Jadi karena saya memalu catatan ke dalam sistem,
semuanya berakhir pergi ke salah satu simpul.
>> Itu tidak baik.
Itu antipattern.
Dalam MongoDB mereka memiliki masalah ini jika Anda tidak menggunakan kunci hash.
MongoDB memberikan Anda pilihan hashing nilai kunci.
Anda harus selalu melakukan itu, jika Anda menggunakan hash incrementing
kunci dalam MongoDB, atau Anda akan memaku setiap menulis ke satu simpul,
dan Anda akan membatasi write throughput Anda buruk.
>> AUDIENCE: Apakah yang A9 169 dalam desimal?
>> RICK Houlihan: Ya, itu suatu tempat di sekitar sana.
A9, saya tidak tahu.
Anda harus mendapatkan biner saya untuk kalkulator desimal.
Otak saya tidak bekerja seperti itu.
AUDIENCE: Hanya satu cepat Mongo komentar Anda.
Jadi adalah ID objek yang datang native dengan Mongo melakukan itu?
RICK Houlihan: Apakah itu melakukan itu?
Jika Anda tentukan itu.
Dengan MongoDB, Anda memiliki pilihan.
Anda dapat specify-- setiap dokumen MongoDB harus memiliki ID garis bawah.
Itu nilai yang unik.
>> Dalam MongoDB Anda dapat menentukan apakah hash atau tidak.
Mereka hanya memberikan pilihan.
Jika Anda tahu bahwa itu acak, tidak ada masalah.
Anda tidak perlu melakukan itu.
Jika Anda tahu bahwa itu tidak acak, yang itu incrementing, kemudian melakukan hash.
>> Sekarang hal tentang hashing, setelah Anda hash
sebuah value-- dan ini mengapa kunci hash selalu
pertanyaan unik, karena saya sudah berubah nilai, sekarang saya tidak bisa melakukan query jangkauan.
Saya tidak bisa mengatakan apakah ini antara ini atau itu,
karena nilai hash tidak akan menjadi setara dengan nilai aktual.
Jadi, ketika Anda hash yang kunci, itu hanya kesetaraan.
Inilah sebabnya mengapa di kunci hash DynamoDB pertanyaan selalu kesetaraan saja.
>> Jadi sekarang di kisaran KEY- ketika saya menambahkan bahwa kunci jangkauan,
catatan-catatan kunci kisaran semua datang dan mereka bisa disimpan pada partisi yang sama.
Jadi mereka sangat cepat, mudah diambil karena ini adalah hash,
ini jangkauan.
Dan Anda melihat segala sesuatu dengan hash yang sama
akan disimpan pada ruang partisi yang sama.
Anda dapat menggunakan kunci rentang untuk membantu mencari data Anda dekat dengan induknya.
Jadi apa yang saya benar-benar lakukan di sini?
Ini adalah salah satu hubungan banyak.
Hubungan antara kunci hash dan kunci kisaran satu ke banyak.
Saya dapat memiliki beberapa kunci hash.
Saya hanya dapat memiliki beberapa rentang kunci dalam setiap kunci hash.
>> Hash mendefinisikan orang tua, kisaran mendefinisikan anak.
Sehingga Anda dapat melihat ada analog di sini antara konstruk relasional
dan jenis yang sama konstruksi di NoSQL.
Orang berbicara tentang NoSQL sebagai nonrelational.
Ini bukan nonrelational.
Data selalu memiliki hubungan.
Hubungan mereka hanya dimodelkan berbeda.
Mari kita bicara sedikit sedikit tentang daya tahan.
Ketika Anda menulis untuk DynamoDB, menulis selalu tiga arah direplikasi.
Yang berarti bahwa kita memiliki tiga AZ.
AZ adalah Zona Ketersediaan.
Anda dapat memikirkan Ketersediaan Zona sebagai pusat data
atau kumpulan data center.
Hal-hal ini secara geografis terisolasi dari satu sama lain
di zona patahan yang berbeda, di berbeda jaringan listrik dan dataran banjir.
Kegagalan dalam satu AZ tidak akan mencatat lain.
Mereka juga terkait bersama-sama dengan serat gelap.
Mendukung satu sub 1 milidetik latency antara AZS.
Jadi ulangan Data real time mampu multi AZS.
>> Dan AZ penyebaran seringkali multi- memenuhi persyaratan ketersediaan tinggi
dari sebagian besar organisasi perusahaan.
Jadi DynamoDB tersebar di tiga AZS secara default.
Kami hanya akan pengetahuan menulis ketika dua dari tiga node datang kembali
dan berkata, Ya, saya mendapatkannya.
Kenapa itu?
Karena di sisi read kami hanya akan memberikan data kembali ketika
kami mendapatkannya dari dua node.
>> Jika saya mereplikasi di tiga, dan aku membaca dari dua,
Saya selalu dijamin memiliki setidaknya satu
dari mereka membaca menjadi sebagian salinan terbaru dari data.
Itulah yang membuat DynamoDB konsisten.
Sekarang Anda dapat memilih untuk mengaktifkan mereka konsisten membaca off.
Dalam hal saya akan mengatakan, Saya hanya akan membaca dari satu simpul.
Dan aku tidak bisa menjamin itu akan menjadi data terbaru.
>> Jadi jika menulis akan datang di, belum direplikasi belum,
Anda akan mendapatkan salinan itu.
Itu dibaca akhirnya konsisten.
Dan apa itu adalah setengah biaya.
Jadi ini adalah sesuatu untuk dipikirkan.
Ketika Anda membaca keluar DynamoDB, dan Anda sedang menyiapkan kapasitas membaca Anda
unit, jika Anda memilih akhirnya konsisten berbunyi, itu jauh lebih murah,
itu sekitar setengah biaya.
>> Dan sehingga menghemat uang Anda.
Tapi itu pilihan Anda.
Jika Anda ingin membaca konsisten atau dibaca akhirnya konsisten.
Itu sesuatu yang dapat Anda pilih.
>> Mari kita bicara tentang indeks.
Jadi kami menyebutkan bahwa atas tingkat agregasi.
Kami punya kunci hash, dan kita punya kunci jangkauan.
Itu bagus.
Dan itu di meja utama, saya punya satu kunci hash, aku punya satu kunci jangkauan.
>> Maksudnya itu apa?
Aku punya satu atribut yang saya dapat menjalankan query kaya terhadap.
Ini kunci jangkauan.
Atribut lain di item-- yang Aku bisa menyaring pada atribut-atribut.
Tapi aku tidak bisa melakukan hal-hal seperti itu, dimulai dengan, atau lebih besar dari.
>> Bagaimana aku melakukan itu?
Saya membuat indeks.
Ada dua jenis indeks dalam DynamoDB.
Indeks benar-benar pandangan lain dari meja.
Dan indeks sekunder lokal.
>> Yang pertama kami akan berbicara tentang.
Sekunder sehingga lokal hidup berdampingan pada partisi yang sama sebagai data.
Dan dengan demikian, mereka berada di node fisik yang sama.
Mereka adalah apa yang kita sebut konsisten.
Artinya, mereka akan mengakui write bersama dengan meja.
Ketika menulis masuk, kami akan menulis melalui indeks.
Kami akan menulis ke meja, dan kemudian kita akan mengakui.
Jadi itu konsisten.
Setelah menulis telah mengakui dari meja,
itu dijamin bahwa Indeks sekunder lokal
akan memiliki visi yang sama dari data.
Tapi apa yang mereka lakukan adalah memungkinkan Anda mendefinisikan kunci berbagai alternatif.
>> Harus menggunakan hash yang sama kunci sebagai tabel utama,
karena mereka co-terletak di partisi yang sama, dan mereka konsisten.
Tapi aku bisa membuat indeks dengan kunci kisaran yang berbeda.
Jadi misalnya, jika saya memiliki produsen yang memiliki meja bagian baku datang.
Dan bagian baku datang, dan mereka dikumpulkan oleh perakitan.
Dan mungkin ada recall.
>> Setiap bagian yang dibuat oleh ini produsen setelah tanggal ini,
Saya perlu untuk menarik dari garis saya.
Saya bisa berputar indeks yang akan mencari,
menggabungkan pada tanggal memproduksi dari bagian tertentu.
Jadi jika tabel tingkat atas saya adalah sudah hashed oleh produsen,
mungkin itu diatur di bagian ID, saya dapat membuat indeks dari meja yang
sebagai hash oleh produsen dan berkisar pada tanggal pembuatan.
Dan bahwa cara saya bisa mengatakan, apa pun yang diproduksi antara tanggal tersebut,
Saya perlu untuk menarik dari garis.
Jadi itu indeks sekunder lokal.
>> Ini memiliki efek membatasi ruang kunci hash Anda.
Karena mereka hidup berdampingan pada node penyimpanan yang sama,
mereka membatasi kunci hash ruang untuk 10 gigabyte.
DynamoDB, di bawah tabel, akan partisi
meja Anda setiap 10 gigabyte.
Ketika Anda menempatkan 10 gigs data dalam, kami pergi [PHH], dan kami menambahkan node lain.
>> Kami tidak akan membagi LSI di beberapa partisi.
Kami akan membagi meja.
Tapi kita tidak akan membagi LSI.
Jadi itu sesuatu penting untuk memahami
adalah jika Anda melakukannya dengan sangat, sangat, agregasi sangat besar,
maka Anda akan dibatasi 10 gigabyte pada LSIs Anda.
>> Jika itu yang terjadi, kita bisa menggunakan sekunder global.
Sekunder global benar-benar meja lain.
Mereka ada benar-benar off untuk sisi meja utama Anda.
Dan mereka memungkinkan saya untuk menemukan struktur yang sama sekali berbeda.
Jadi menganggapnya sebagai data yang dimasukkan menjadi dua tabel yang berbeda, terstruktur
dalam dua cara yang berbeda.
>> Saya dapat menentukan benar-benar kunci hash yang berbeda.
Saya dapat menentukan benar-benar kunci rentang yang berbeda.
Dan saya bisa menjalankan ini benar-benar independen.
Sebagai soal fakta, aku sudah ditetapkan kapasitas membaca saya
dan menulis kapasitas saya indeks sekunder global yang
benar-benar independen tabel utama saya.
Jika saya mendefinisikan indeks itu, saya memberitahu itu berapa banyak membaca dan menulis
Kapasitas itu akan menggunakan.
>> Dan yang terpisah dari meja utama saya.
Sekarang kedua indeks memungkinkan kita untuk tidak hanya mendefinisikan hash dan berbagai kunci,
tapi mereka memungkinkan kita untuk memproyeksikan nilai-nilai tambahan.
Jadi jika saya ingin membacakan indeks, dan saya ingin mendapatkan beberapa set data,
Saya tidak perlu kembali ke utama meja untuk mendapatkan atribut tambahan.
Saya dapat proyek mereka tambahan atribut ke dalam tabel
untuk mendukung pola akses.
Aku tahu kita mungkin masuk ke beberapa benar-benar, really-- masuk ke gulma
di sini pada beberapa hal ini.
Sekarang aku melayang keluar dari ini.
>> AUDIENCE: [tidak terdengar] kunci --table berarti adalah hash?
Hash asli?
Multi-bilah?
>> RICK Houlihan: Ya.
Iya nih.
Kunci tabel pada dasarnya menunjuk kembali ke item.
Jadi indeks adalah pointer kembali ke item asli di atas meja.
Sekarang Anda dapat memilih untuk membangun Indeks yang hanya memiliki kunci meja,
dan tidak ada sifat lainnya.
Dan mengapa mungkin saya melakukan itu?
Yah, mungkin aku memiliki barang-barang yang sangat besar.
>> Aku benar-benar hanya perlu tahu which-- pola akses saya mungkin mengatakan,
item yang mengandung properti ini?
Tidak perlu untuk kembali item.
Aku hanya perlu tahu yang item berisi itu.
Sehingga Anda dapat membangun indeks yang hanya memiliki kunci meja.
>> Tapi itu terutama apa indeks dalam database untuk.
Ini untuk mampu dengan cepat mengidentifikasi yang mencatat,
yang baris, yang item dalam tabel memiliki
sifat-sifat yang saya cari.
>> GSIS, jadi bagaimana mereka bekerja?
GSIS pada dasarnya adalah asynchronous.
Pembaruan datang ke meja, tabel ini kemudian diperbarui asynchronously
semua GSIS Anda.
Inilah sebabnya mengapa GSIS adalah akhirnya konsisten.
>> Hal ini penting untuk dicatat bahwa ketika Anda sedang membangun GSIS,
dan Anda memahami Anda sedang menciptakan dimensi lain dari aggregation--
sekarang katakanlah contoh yang baik di sini adalah produsen.
Saya pikir saya mungkin telah berbicara tentang produsen perangkat medis.
Produsen perangkat medis seringkali memiliki bagian serial.
Bagian-bagian yang masuk ke penggantian pinggul semua
memiliki nomor seri kecil pada mereka.
Dan mereka bisa memiliki jutaan dan jutaan dan miliaran bagian
di semua perangkat yang mereka kapal.
Nah, mereka perlu agregat di bawah dimensi yang berbeda, semua bagian
dalam perakitan, semua bagian yang dibuat
pada baris tertentu, semua bagian-bagian yang datang
di dari produsen tertentu pada tanggal tertentu.
Dan agregasi ini kadang-kadang bangun ke miliaran.
>> Jadi saya bekerja dengan beberapa orang-orang yang menderita
karena mereka menciptakan ini agregasi ginormous
di indeks sekunder mereka.
Mereka mungkin memiliki bagian baku tabel yang datang sebagai hash saja.
Setiap bagian memiliki nomor seri yang unik.
Saya menggunakan nomor seri sebagai hash.
Cantiknya.
Tabel data mentah saya tersebar seluruh ruang kunci.
Saya [? menulis ?] [? konsumsi?] mengagumkan.
Saya mengambil banyak data.
Lalu apa yang mereka lakukan adalah mereka membuat GSI.
Dan saya katakan, Anda tahu apa, saya harus melihat semua bagian untuk produsen ini.
Nah, tiba-tiba aku mengambil miliar baris,
dan barang-barang mereka ke satu node, karena ketika
Saya agregat sebagai produsen ID sebagai hash,
dan nomor bagian sebagai jangkauan, maka semua tiba-tiba aku
menempatkan miliar bagian dalam apa produsen ini telah melepaskan aku.
>> Yang dapat menyebabkan banyak tekanan pada GSI,
lagi, karena aku memalu satu node.
Saya menempatkan semua ini memasukkan ke dalam satu simpul.
Dan itu kasus penggunaan bermasalah nyata.
Sekarang, saya punya desain yang baik pola untuk bagaimana Anda menghindari itu.
Dan itulah salah satu masalah bahwa saya selalu bekerja dengan.
Tapi apa yang terjadi, adalah mungkin GSI tidak memiliki kapasitas yang cukup menulis
untuk dapat mendorong semua orang baris ke node tunggal.
Dan apa yang terjadi kemudian adalah primer, meja klien,
tabel utama akan mencekik karena GSI tidak bisa mengikuti.
Jadi tingkat insert saya akan jatuh pada tabel utama
sebagai GSI saya mencoba untuk mengikutinya.
>> Baiklah, jadi GSI, LSI, mana yang harus saya gunakan?
LSI konsisten.
GSI yang akhirnya konsisten.
Jika itu OK, saya sarankan menggunakan GSI, mereka jauh lebih fleksibel.
LSI dapat dimodelkan sebagai GSI.
Dan jika ukuran data per kunci hash di koleksi Anda melebihi 10 gigabyte,
maka Anda akan ingin menggunakan GSI karena itu hanya batas keras.
>> Baiklah, jadi scaling.
Throughput dalam Dynamo DB, Anda Ketentuan kaleng [tidak terdengar]
troughput ke meja.
Kami memiliki pelanggan yang memiliki ditetapkan 60 billion--
melakukan 60 miliar permintaan, secara teratur berjalan pada lebih dari satu juta permintaan
per detik di meja kami.
Ada benar-benar ada batas teoritis untuk berapa banyak
dan seberapa cepat meja dapat berjalan di Dynamo DB.
Ada beberapa lembut batas akun Anda
yang kita tempatkan di sana sehingga bahwa Anda tidak gila.
Jika Anda ingin lebih dari itu, tidak masalah.
Anda datang memberitahu kami.
Kami akan muncul dial.
>> Setiap akun terbatas pada beberapa tingkat di setiap layanan, hanya dari kelelawar
sehingga orang-orang tidak gila mendapatkan diri mereka ke dalam kesulitan.
Tidak ada batas dalam ukuran.
Anda dapat menempatkan sejumlah item di atas meja.
Ukuran item adalah terbatas pada setiap 400 kilobyte,
yang akan barang tidak atribut.
Jadi jumlah semua atribut terbatas pada 400 kilobyte.
Dan sekali lagi, kita memiliki yang sedikit masalah LSI
dengan batas 10 gigabyte per hash.
AUDIENCE: jumlah kecil, aku kehilangan apa yang kau bilang, bahwa is--
AUDIENCE: Oh, 400 kilobyte adalah ukuran maksimum per item.
Jadi item memiliki semua atribut.
Jadi 400 k adalah ukuran jumlah item itu, 400 kilobyte.
Jadi dari semua atribut dikombinasikan, semua data
itu di semua atribut tersebut, digulung menjadi ukuran total,
Saat hari batas item 400 k.
Jadi skala lagi, mencapai melalui partisi.
Throughput ditetapkan di tingkat meja.
Dan ada benar-benar dua tombol.
Kami telah membaca kapasitas dan menulis kapasitas.
>> Jadi ini disesuaikan independen satu sama lain.
Ukuran RCU ini ketat konsisten membaca.
OK, jadi jika Anda mengatakan saya ingin 1000 RCU ini mereka secara ketat konsisten,
mereka konsisten membaca.
Jika Anda mengatakan saya ingin akhirnya konsisten berbunyi,
Anda bisa penyediaan 1.000 RCU, Anda akan
untuk mendapatkan 2000 akhirnya konsisten membaca.
Dan setengah harga bagi mereka akhirnya terdiri dalam membaca.
>> Sekali lagi, disesuaikan independen satu sama lain.
Dan mereka memiliki throughput-- yang Jika Anda mengkonsumsi 100% dari RCU Anda,
Anda tidak akan berdampak pada ketersediaan hak-hak Anda.
Jadi mereka benar-benar independen satu sama lain.
Baiklah, jadi salah satu hal yang Saya sebutkan secara singkat itu throttling.
Throttling buruk.
Throttling menunjukkan buruk ada SQL.
Ada hal-hal yang dapat kita lakukan untuk membantu Anda meringankan throttling yang Anda
mengalami.
Tapi solusi terbaik untuk ini mari kita
a melihat apa yang Anda lakukan, karena ada anti-pola dalam bermain di sini.
>> Hal-hal ini, hal-hal seperti non-seragam beban kerja, hot keys, partisi panas.
Aku memukul ruang kunci tertentu sangat sulit untuk beberapa alasan tertentu.
Mengapa saya melakukan ini?
Mari kita mencari tahu.
Aku mencampur Data panas saya dengan data dingin.
Aku membiarkan meja saya mendapatkan besar, tapi benar-benar
hanya beberapa subset dari data yang benar-benar menarik bagi saya.
Jadi untuk data log, misalnya, banyak pelanggan, mereka mendapatkan data log setiap hari.
Mereka mendapat sejumlah besar data log.
>> Jika Anda hanya membuang semua log yang data ke dalam satu meja besar, dari waktu ke waktu
tabel yang akan mendapatkan besar.
Tapi aku benar-benar hanya tertarik 24 jam terakhir, tujuh hari terakhir,
30 hari terakhir.
Apapun jendela waktu bahwa aku tertarik melihat
untuk acara yang mengganggu saya, atau acara yang menarik untuk saya,
itulah satu-satunya jendela waktu yang saya butuhkan.
Jadi, mengapa saya menempatkan 10 tahun senilai data log di meja?
Apa yang menyebabkan adalah tabel fragmen.
>> Ia mendapat besar.
Itu mulai menyebar di ribuan node.
Dan karena kapasitas Anda sangat rendah, Anda
sebenarnya menilai membatasi pada setiap salah satu node individu.
Jadi mari kita mulai melihat bagaimana kita berguling meja yang lebih.
Bagaimana kita mengelola data yang sedikit lebih baik untuk menghindari masalah ini.
Dan apa yang terlihat seperti?
Ini adalah apa yang tampak seperti.
Ini adalah apa yang buruk NoSQL seperti.
>> Aku punya kunci panas di sini.
Jika Anda melihat di sisi sini, ini semua partisi saya.
Saya punya 16 partisi di sini pada database tertentu.
Kami melakukan hal ini sepanjang waktu.
Saya menjalankan ini untuk pelanggan sepanjang waktu.
Ini disebut peta panas.
Peta panas memberitahu saya bagaimana Anda mengakses ruang kunci Anda.
Dan apa ini mengatakan kepada saya adalah bahwa ada satu hash tertentu
bahwa orang ini menyukai suatu mengerikan banyak, karena dia
memukul itu benar-benar, benar-benar keras.
>> Jadi biru bagus.
Kami seperti biru.
Kami tidak suka merah.
Red mana tekanan mendapat hingga 100%.
100%, sekarang kau akan mencekik.
Jadi, setiap kali Anda melihat garis merah seperti this-- dan itu bukan hanya Dynamo DB--
setiap database yang NoSQL memiliki masalah ini.
Ada anti-pola yang dapat mendorong jenis kondisi.
Apa yang saya lakukan adalah saya bekerja dengan pelanggan untuk meringankan kondisi ini.
>> Dan apa yang terlihat seperti?
Dan ini adalah mendapatkan paling dari Dynamo DB throughput,
tapi itu benar-benar mendapatkan hasil maksimal dari NoSQL.
Hal ini tidak terbatas pada Dynamo.
Ini adalah definitely-- Saya digunakan untuk bekerja di Mongo.
Aku akrab dengan banyak platform NoSQL.
Setiap orang memiliki jenis masalah hot key.
Untuk mendapatkan hasil maksimal dari setiap NoSQL Database, khususnya Dynamo DB,
Anda ingin membuat tabel di mana elemen kunci hash memiliki
sejumlah besar nilai-nilai yang berbeda, tingkat tinggi kardinalitas.
Karena itu berarti aku menulis untuk banyak ember yang berbeda.
>> Semakin ember Saya menulis untuk, semakin besar kemungkinan
Saya menyebar bahwa menulis beban atau baca memuat keluar di beberapa node,
semakin besar kemungkinan saya untuk memiliki throughput yang tinggi di atas meja.
Dan kemudian saya ingin nilai-nilai menjadi diminta cukup merata dari waktu ke waktu
dan seragam sebagai acak mungkin.
Nah, itu semacam menarik, karena saya tidak bisa benar-benar
kontrol ketika pengguna datang.
Jadi cukup untuk mengatakan, jika kita menyebar hal-hal di ruang utama,
kita mungkin akan dalam kondisi yang lebih baik.
>> Ada tertentu jumlah waktu pengiriman
bahwa Anda tidak akan untuk dapat kontrol.
Tapi mereka benar-benar dua dimensi yang kita miliki,
ruang, akses merata penyebaran, waktu, permintaan
Sesampainya merata spasi dalam waktu.
Dan jika kedua kondisi terpenuhi,
maka itulah yang itu akan terlihat seperti.
Ini jauh lebih baik.
Kami benar-benar senang di sini.
Kami punya pola akses yang sangat bahkan.
Ya, mungkin Anda mendapatkan sedikit tekanan setiap sekarang dan kemudian,
tapi tidak ada yang benar-benar terlalu luas.
Jadi itu menakjubkan berapa kali, ketika saya bekerja dengan pelanggan,
bahwa grafik pertama dengan merah besar bar dan semua yang jelek kuning itu
seluruh tempat, kami bisa dilakukan dengan latihan
setelah beberapa bulan re-arsitektur,
mereka menjalankan persis sama beban kerja pada beban yang sama persis.
Dan ini adalah apa itu tampak seperti sekarang.
Jadi apa yang Anda dapatkan dengan NoSQL adalah Data skema yang benar-benar
terikat pada pola akses.
>> Dan Anda dapat mengoptimalkan bahwa skema data untuk mendukung pola akses.
Jika Anda tidak, maka Anda akan untuk melihat jenis-jenis masalah
dengan orang-orang kunci panas.
>> AUDIENCE: Nah, pasti beberapa tempat akan menjadi lebih panas daripada yang lain.
>> RICK Houlihan: Selalu.
Selalu.
Ya, maksud saya selalu ada a-- dan lagi, ada
beberapa pola desain kita akan melewati yang akan berbicara tentang bagaimana Anda menangani
dengan ini agregasi super besar.
Maksudku, aku harus memiliki mereka, bagaimana kita berurusan dengan mereka?
Saya punya kasus penggunaan yang cukup baik bahwa kita akan berbicara tentang untuk itu.
>> Baiklah, mari kita bicara sehingga tentang beberapa pelanggan sekarang.
Orang-orang ini AdRoll.
Saya tidak tahu apakah Anda akrab dengan AdRoll.
Anda mungkin melihat mereka banyak pada browser.
Mereka ad re-targeting, mereka terbesar bisnis menargetkan ulang iklan
di luar sana.
Mereka biasanya secara teratur menjalankan lebih 60 miliar transaksi per hari.
Mereka melakukan lebih dari satu juta transaksi per detik.
Mereka punya meja cukup sederhana struktur, meja tersibuk.
Itu pada dasarnya hanya kunci hash adalah cookie,
rentang adalah demografi kategori, dan kemudian
atribut ketiga adalah skor.
>> Jadi kita semua memiliki cookie di browser kita dari orang-orang.
Dan ketika Anda pergi ke berpartisipasi pedagang,
mereka pada dasarnya skor Anda di berbagai kategori demografis.
Ketika Anda pergi ke sebuah situs web dan Anda mengatakan saya ingin melihat ad-- ini
atau pada dasarnya Anda tidak mengatakan itu-- tetapi ketika Anda pergi ke situs web
mereka mengatakan Anda ingin melihat iklan ini.
Dan mereka pergi mendapatkan iklan dari AdRoll.
AdRoll terlihat Anda di atas meja mereka.
Mereka menemukan cookie Anda.
Pengiklan mengatakan mereka, saya ingin seseorang
siapa yang setengah baya, Pria 40 tahun, menjadi olahraga.
Dan mereka mencetak Anda pada mereka demografi dan mereka memutuskan apakah atau tidak
itu iklan yang baik untuk Anda.
>> Sekarang mereka memiliki SLA dengan penyedia iklan mereka
untuk memberikan sub-10 milidetik respon pada setiap permintaan tunggal.
Jadi mereka menggunakan Dynamo DB untuk ini.
Mereka memukul kami juta permintaan per detik.
Mereka mampu melakukan semua mereka lookup, triase semua data itu,
dan mendapatkan bahwa add link kembali ke yang pengiklan di bawah 10 milidetik.
Ini benar-benar cukup fenomenal implementasi yang mereka miliki.
>> Orang-orang ini actually-- apakah ini orang-orang.
Saya tidak yakin apakah itu orang-orang ini.
Mungkin orang-orang ini.
Pada dasarnya mengatakan us-- tidak, aku tidak berpikir itu mereka.
Saya pikir itu orang lain.
Saya bekerja dengan pelanggan yang mengatakan kepada saya
bahwa sekarang mereka sudah pergi ke Dynamo DB, mereka
menghabiskan lebih banyak uang pada makanan ringan untuk tim pengembangan mereka setiap bulan
dari yang mereka keluarkan untuk database mereka.
Sehingga akan memberi Anda ide penghematan biaya
bahwa Anda bisa mendapatkan di Dynamo DB sangat besar.
Baiklah, dropcam ini perusahaan lain.
Orang ini semacam of-- jika Anda berpikir dari internet hal, dropcam
pada dasarnya adalah keamanan video internet.
Anda menempatkan kamera Anda di luar sana.
Kamera memiliki detektor gerak.
Seseorang datang, memicu titik isyarat.
Kamera mulai merekam untuk sementara sampai itu tidak mendeteksi gerakan apapun lagi.
Menempatkan video yang di internet.
>> Dropcam adalah sebuah perusahaan yang pada dasarnya beralih ke Dynamo DB
karena mereka mengalami sakit tumbuh besar.
Dan apa yang mereka mengatakan kepada kami, tiba-tiba petabyte data.
Mereka tidak tahu layanan mereka akan begitu sukses.
Lebih video masuk dari YouTube adalah apa yang orang-orang ini mendapatkan.
Mereka menggunakan DynamoDB untuk melacak semua metadata pada semua poin kunci video mereka.
>> Sehingga mereka memiliki S3 ember mereka mendorong semua artefak biner ke dalam.
Dan kemudian mereka memiliki Catatan Dynamo DB yang
menunjuk orang untuk orang-orang S3 tiga objek.
Ketika mereka perlu melihat video, mereka mencari catatan di Dynamo DB.
Mereka klik link.
Mereka meruntuhkan video dari S3.
Jadi itu semacam apa ini terlihat seperti.
Dan ini adalah langsung dari tim mereka.
>> Dynamo DB mengurangi mereka waktu pengiriman untuk acara video
dari lima sampai 10 detik.
Di toko relasional lama mereka, mereka digunakan untuk memiliki pergi dan mengeksekusi
beberapa pertanyaan kompleks untuk angka mana video ke pull down,
menjadi kurang dari 50 milidetik.
Jadi itu menakjubkan, menakjubkan berapa banyak kinerja
Anda bisa dapatkan ketika Anda mengoptimalkan dan Anda menyetel database yang mendasari
untuk mendukung pola akses.
Halfbrick, orang-orang ini, apa itu, Fruit Ninja saya kira adalah hal mereka.
Itu semua berjalan pada Dynamo DB.
Dan orang-orang ini, mereka adalah besar tim pengembangan, pengembangan besar
toko.
>> Tidak baik tim ops.
Mereka tidak memiliki banyak sumber daya operasi.
Mereka berjuang berusaha untuk menjaga infrastruktur aplikasi mereka up
dan berjalan.
Mereka datang ke kami.
Mereka memandang bahwa Dynamo DB.
Mereka mengatakan, itu untuk kita.
Mereka membangun seluruh mereka kerangka aplikasi di atasnya.
Beberapa komentar yang benar-benar bagus di sini dari tim pada kemampuan mereka
untuk sekarang fokus pada bangunan permainan dan tidak
harus mempertahankan infrastruktur, yang
itu menjadi sejumlah besar overhead untuk tim mereka.
Jadi ini adalah sesuatu yang itu-- manfaat yang Anda dapatkan dari Dynamo DB.
>> Baiklah, masuk ke Data modeling di sini.
Dan kami berbicara sedikit tentang satu ini untuk satu, satu ke banyak,
dan banyak ke banyak hubungan jenis.
Dan bagaimana Anda menjaga mereka di Dynamo.
Dalam Dynamo DB kita menggunakan indeks, secara umum,
untuk memutar data dari satu rasa yang lain.
Kunci hash, kunci jangkauan, dan indeks.
>> Dalam tertentu Misalnya, karena kebanyakan negara
memiliki persyaratan lisensi yang hanya lisensi satu pengemudi per orang.
Anda tidak bisa pergi untuk mendapatkan sopir dua itu lisensi di negara bagian Boston.
Aku tidak bisa melakukannya di Texas.
Itu semacam cara itu.
Dan di DMV, kita memiliki pencarian, kita ingin mencari SIM
dengan nomor jaminan sosial.
Saya ingin mencari rincian pengguna dengan nomor SIM.
>> Jadi kita mungkin memiliki meja pengguna yang memiliki kunci hash pada nomor seri,
atau nomor jaminan sosial, dan berbagai atribut yang didefinisikan pada item.
Sekarang di atas meja saya bisa menentukan GSI yang
membalik bahwa sekitar yang mengatakan saya ingin kunci hash pada lisensi dan kemudian
semua barang-barang lainnya.
Sekarang jika saya ingin query dan menemukan nomor lisensi untuk setiap diberikan Sosial
Nomor jaminan, saya bisa query tabel utama.
>> Jika saya ingin query dan saya ingin untuk mendapatkan jaminan sosial
nomor atau atribut lainnya oleh nomor lisensi, aku bisa query GSI.
Model yang adalah salah satu yang untuk satu hubungan.
Hanya GSI sangat sederhana, membalik-hal di sekitar.
Sekarang, berbicara tentang satu ke banyak.
Satu ke banyak pada dasarnya adalah kunci kisaran hash Anda.
Di mana kita mendapatkan banyak dengan ini use case adalah data Monitor.
Data Monitor datang di reguler Interval, seperti internet hal.
Kami selalu mendapatkan semua ini catatan datang di sepanjang waktu.
>> Dan saya ingin mencari semua bacaan antara periode waktu tertentu.
Ini adalah permintaan yang sangat umum di infrastruktur monitoring.
Cara pergi tentang itu adalah untuk menemukan struktur tabel sederhana, satu meja.
Aku punya meja pengukuran perangkat dengan kunci hash pada ID perangkat.
Dan saya memiliki kunci pada rentang timestamp, atau dalam hal ini, epik.
Dan yang memungkinkan saya mengeksekusi kompleks query terhadap yang kunci kisaran
dan kembali catatan-catatan yang adalah relatif terhadap hasilnya
mengatur bahwa saya sedang mencari.
Dan itu membangun satu yang hubungan banyak
ke dalam tabel utama menggunakan kunci hash, struktur kunci jangkauan.
>> Jadi yang semacam dibangun ke dalam tabel di Dynamo DB.
Ketika saya mendefinisikan hash dan berbagai t tabel, aku
mendefinisikan satu ke banyak hubungan.
Ini adalah hubungan orangtua-anak.
>> Mari kita bicara tentang banyak untuk banyak hubungan.
Dan untuk contoh khusus ini, lagi, kita akan menggunakan GSI.
Dan mari kita bicara tentang game skenario di mana saya memiliki pengguna tertentu.
Saya ingin mengetahui semua game yang dia terdaftar untuk atau bermain di.
Dan untuk permainan yang diberikan, saya ingin mencari semua pengguna.
Jadi bagaimana saya melakukannya?
Meja permainan pengguna saya, saya akan memiliki kunci hash dari ID pengguna
dan kunci berbagai permainan.
>> Jadi pengguna dapat memiliki beberapa permainan.
Ini adalah satu ke banyak hubungan antara pengguna dan permainan dia bermain.
Dan kemudian pada GSI, Aku akan flip sekitar itu.
Aku akan hash pada permainan dan Aku akan berkisar pada pengguna.
Jadi jika saya ingin mendapatkan semua permainan pengguna bermain di,
Saya akan query tabel utama.
Jika saya ingin mendapatkan semua pengguna yang memainkan game tertentu,
Aku query GSI.
Jadi Anda melihat bagaimana kita melakukan ini?
Anda membangun ini GSI untuk mendukung kasus penggunaan, aplikasi, akses
pola, aplikasi.
>> Jika saya perlu query pada dimensi ini, biarkan
saya membuat indeks pada dimensi itu.
Jika saya tidak, saya tidak peduli.
Dan tergantung pada kasus penggunaan, saya mungkin perlu indeks atau saya mungkin tidak.
Jika itu yang sederhana ke banyak, tabel utama adalah baik-baik saja.
Jika saya perlu melakukan ini banyak ke banyak yang, atau saya harus melakukan satu dengan yang,
maka mungkin saya perlu untuk kedua indeks.
Jadi itu semua tergantung pada apa yang saya coba lakukan
dan apa yang saya coba untuk mendapatkan dicapai.
>> Mungkin saya tidak akan menghabiskan terlalu banyak waktu berbicara tentang dokumen.
Ini mendapat sedikit, mungkin, lebih dari yang kita butuhkan untuk masuk ke dalam.
Mari kita bicara sedikit ekspresi query tentang kaya.
Jadi di Dynamo DB kita memiliki kemampuan untuk membuat
apa yang kita sebut ekspresi proyeksi.
Ekspresi proyeksi hanya memilih bidang atau nilai-nilai
yang ingin ditampilkan.
OK, jadi saya membuat pilihan.
Saya membuat query melawan Dynamo DB.
Dan saya katakan, Anda tahu apa, acara saya hanya review bintang lima
untuk produk tertentu.
Jadi itu yang saya ingin melihat.
Saya tidak ingin melihat semua atribut lain dari baris,
Aku hanya ingin melihat ini.
Ini seperti di SQL ketika Anda mengatakan pilih bintang atau dari meja,
Anda mendapatkan semuanya.
Ketika saya mengatakan pilih nama dari meja, saya hanya mendapatkan satu atribut.
Ini adalah hal yang sama di Dynamo DB atau database NoSQL lain.
Filter ekspresi memungkinkan saya untuk pada dasarnya memotong hasil ditetapkan.
Jadi saya membuat query.
Query dapat kembali dengan 500 item.
Tapi aku hanya ingin item yang memiliki atribut yang mengatakan ini.
OK, jadi mari kita menyaring item-item yang tidak cocok pencarian tertentu.
Jadi kita memiliki ekspresi filter.
>> Filter ekspresi bisa dijalankan pada atribut apapun.
Mereka tidak suka berbagai pertanyaan.
Meningkatkan permintaan yang lebih selektif.
Filter query mengharuskan saya untuk pergi mendapatkan seluruh hasil set dan kemudian
mengukir data yang saya tidak ingin.
Mengapa itu penting?
Karena saya membaca itu semua.
Dalam query, saya akan membaca dan itu akan menjadi raksasa tentang data.
Dan kemudian aku akan mengukir apa yang saya butuhkan.
Dan jika aku hanya mengukir sebuah beberapa baris, maka itu OK.
Ini tidak begitu efisien.
>> Tetapi jika aku sedang membaca setumpuk data, hanya untuk mengukir satu item,
maka Aku akan menjadi lebih baik off menggunakan query kisaran,
karena itu jauh lebih selektif.
Ini akan menyelamatkan saya banyak uang, karena saya membayar untuk membaca itu.
Di mana hasil yang datang kembali menyeberangi kawat yang mungkin lebih kecil,
tapi saya membayar untuk membaca.
Jadi memahami bagaimana Anda mendapatkan data.
Itu sangat penting dalam Dynamo DB.
>> Ekspresi kondisional, ini adalah apa yang Anda mungkin menyebutnya penguncian optimis.
Perbarui JIKA ada, atau jika nilai ini setara dengan apa yang saya tentukan.
Dan jika saya memiliki cap waktu pada catatan, saya mungkin membaca data.
Aku mungkin mengubah data tersebut.
Aku bisa pergi menulis bahwa data kembali ke database.
Jika seseorang telah berubah catatan, timestamp mungkin telah berubah.
Dan cara yang saya kondisional Update bisa mengatakan pembaruan
jika timestamp sama ini.
Atau update akan gagal karena seseorang diperbarui rekor sementara itu.
>> Itulah yang kita sebut penguncian optimis.
Ini berarti bahwa seseorang bisa datang dan mengubahnya,
dan aku akan mendeteksinya ketika aku kembali untuk menulis.
Dan kemudian aku benar-benar bisa membaca bahwa Data dan mengatakan, oh, dia mengubah ini.
Saya perlu untuk memperhitungkan itu.
Dan saya bisa mengubah data di saya merekam dan menerapkan pembaruan lain.
Sehingga Anda dapat menangkap mereka tambahan pembaruan yang terjadi antara waktu
Anda membaca data dan waktu Anda mungkin menulis data.
>> AUDIENCE: Dan filter Ekspresi sebenarnya berarti tidak
dalam jumlah atau not--
>> [Interposing SUARA]
RICK Houlihan: Saya tidak akan terlalu banyak ke dalam ini.
Ini adalah kata kunci yang dipesan.
Pound lihat adalah milik kata kunci di Dynamo DB.
Setiap database memiliki sendiri dilindungi nama untuk koleksi Anda tidak dapat menggunakan.
Dynamo DB, jika Anda menetapkan pon di depan ini,
Anda dapat menentukan nama-nama di atas.
Ini adalah nilai yang direferensikan.
Itu tidak mungkin sintaks terbaik untuk memiliki sana untuk diskusi ini,
karena itu akan menjadi beberapa real-- Saya akan telah berbicara lebih
tentang itu pada tingkat yang lebih dalam.
>> Tapi cukup untuk mengatakan, ini bisa menjadi permintaan memindai di mana mereka views--
atau pon tampilan lebih besar dari 10.
Ini adalah nilai numerik, ya.
Jika Anda ingin, kita bisa bicara tentang bahwa setelah diskusi.
Baiklah, jadi kita masuk ke beberapa skenario dalam praktek terbaik
di mana kita akan berbicara tentang beberapa aplikasi di sini.
Apa kasus penggunaan untuk Dynamo DB.
Apa desain pola di Dynamo DB.
>> Dan yang pertama kita akan berbicara tentang adalah internet hal.
Jadi kita mendapatkan banyak of-- saya kira, apa yang itu-- lebih dari 50%
lalu lintas di internet hari ini sebenarnya dihasilkan oleh mesin,
proses otomatis, tidak oleh manusia.
Maksud saya hal ini hal ini yang Anda membawa sekitar di saku Anda,
berapa banyak data yang hal yang sebenarnya mengirimkan sekitar tanpa Anda
mengetahui itu adalah benar-benar menakjubkan.
Lokasi Anda, informasi tentang seberapa cepat Anda akan.
Bagaimana menurut Anda Google Maps karya ketika mereka memberitahu Anda apa lalu lintas.
Itu karena ada jutaan dan jutaan orang berkeliling
dengan ponsel yang mengirim Data seluruh tempat sepanjang waktu.
Jadi salah satu hal tentang jenis data
yang masuk, data yang memantau, log data, data time series, adalah itu
biasanya hanya menarik untuk sedikit waktu.
Setelah itu, itu tidak begitu menarik.
Jadi kita berbicara tentang, jangan biarkan meja tersebut tumbuh tanpa batas.
Idenya di sini adalah bahwa mungkin aku punya 24 jam senilai peristiwa di meja saya panas.
Dan bahwa meja panas akan menjadi ditetapkan pada tingkat yang sangat tinggi,
karena itu mengambil banyak data.
Itu mengambil banyak data dan aku membaca banyak.
Aku punya banyak operasi query berjalan terhadap data tersebut.
>> Setelah 24 jam, hei, Anda tahu apa, saya tidak peduli.
Jadi mungkin setiap tengah malam aku gulungan meja saya ke sebuah tabel baru
dan saya deprovision tabel ini.
Dan aku akan mengambil RCU dan WCU turun karena 24 jam kemudian
Aku tidak berjalan karena banyak query terhadap data tersebut.
Jadi aku akan menghemat uang.
Dan mungkin 30 hari kemudian saya tidak bahkan perlu peduli tentang itu semua.
Saya bisa mengambil WCU ini semua jalan ke satu,
karena Anda tahu apa, itu tidak akan pernah bisa ditulis.
Data yang berusia 30 hari.
Itu tidak pernah berubah.
>> Dan itu hampir tidak pernah akan mendapatkan membaca, jadi mari kita mengambil RCU ke 10.
Dan aku menyimpan satu ton uang ini data, dan hanya membayar untuk data saya panas.
Jadi itulah hal penting untuk melihat di saat Anda melihat serangkaian waktu
Data yang masuk dalam volume.
Ini adalah strategi.
Sekarang, aku hanya bisa membiarkannya semua pergi ke meja yang sama
dan hanya membiarkan meja yang tumbuh.
Akhirnya, aku akan melihat masalah kinerja.
Aku akan harus mulai untuk arsip beberapa data dari meja,
apa yang tidak.
>> Mari kita jauh lebih baik merancang aplikasi Anda
sehingga Anda dapat beroperasi dengan cara ini benar.
Jadi itu hanya otomatis dalam kode aplikasi.
Pada tengah malam setiap malam menggelinding meja.
Mungkin apa yang saya butuhkan adalah geser jendela 24 jam data.
Kemudian secara teratur saya memanggil data dari tabel.
Saya pemangkasan itu dengan Tugas cron dan aku meletakkan
ke tabel ini lain, apa pun yang Anda butuhkan.
Jadi jika rollover bekerja, itu hebat.
Jika tidak, memotongnya.
Tapi mari kita menjaga bahwa data panas jauh dari data yang dingin Anda.
Ini akan menghemat banyak uang dan membuat tabel Anda lebih berkinerja.
Jadi hal berikutnya kita akan berbicara tentang adalah katalog produk.
Katalog produk adalah kasus penggunaan yang cukup umum.
Ini sebenarnya adalah pola yang sangat umum bahwa kita akan melihat dalam berbagai hal.
Anda tahu, Twitter untuk Misalnya, tweet panas.
Semua orang datang dan meraih tweet yang.
Katalog produk, saya mendapat penjualan.
Saya mendapat penjualan panas.
Saya mendapat 70.000 permintaan per kedua datang untuk suatu produk
deskripsi dari katalog produk saya.
Kami melihat ini di ritel operasi sedikit.
Jadi bagaimana kita menghadapi itu?
Tidak ada cara untuk menghadapi itu.
Semua pengguna saya ingin melihat bagian yang sama dari data.
Mereka yang datang, bersamaan.
Dan mereka semua membuat permintaan untuk bagian yang sama dari data.
Ini memberi saya bahwa kunci panas, yang merah besar garis di grafik saya bahwa kita tidak suka.
Dan itulah yang yang terlihat seperti.
Jadi melintasi ruang kunci saya saya mendapatkan dipalu dalam item penjualan.
Saya mendapatkan apa-apa di tempat lain.
>> Bagaimana cara mengatasi masalah ini?
Yah, kita mengurangi ini dengan tembolok.
Cache, Anda menempatkan pada dasarnya di memori partisi di depan database.
Kami telah berhasil [Tidak terdengar] cache, bagaimana Anda
dapat mengatur cache sendiri, [tidak terdengar] Cache [? d,?] apa pun yang Anda inginkan.
Masukan yang di depan database.
Dan dengan cara itu Anda dapat menyimpan data yang dari orang-orang kunci panas di cache yang
ruang dan membaca cache.
>> Dan kemudian sebagian besar Anda membaca mulai mencari seperti ini.
Saya punya semua tembolok ini memukul di sini dan aku tidak ada yang terjadi di sini
karena database duduk di belakang cache dan bertuliskan pernah datang melalui.
Jika saya mengubah data di database, saya harus memperbarui cache.
Kita bisa menggunakan sesuatu seperti steams untuk melakukan itu.
Dan saya akan menjelaskan cara kerjanya.
Baiklah, pesan.
Email, kita semua menggunakan email.
>> Ini adalah contoh yang cukup baik.
Kami punya semacam pesan meja.
Dan kami mendapat inbox dan outbox.
Ini adalah apa yang akan SQL terlihat seperti untuk membangun inbox itu.
Kami semacam menggunakan jenis yang sama strategi untuk menggunakan GSI, GSI
untuk inbox saya dan kotak keluar saya.
Jadi aku pesan baku datang ke dalam tabel pesan saya.
Dan pendekatan pertama yang ini mungkin, mengatakan, OK, tidak ada masalah.
Aku punya pesan baku.
Pesan yang datang [tidak terdengar], pesan ID, itu hebat.
Itu hash unik saya.
Aku akan membuat dua GSI, salah satu untuk inbox saya, satu untuk kotak keluar saya.
Dan hal pertama yang saya akan melakukan adalah aku akan mengatakan kunci hash saya adalah
akan menjadi penerima dan Aku akan mengatur pada tanggal.
Ini fantastis.
Aku punya pandangan saya bagus di sini.
Tapi ada sedikit masalah di sini.
Dan Anda mengalami ini di database relasional juga.
Mereka disebut partisi vertikal.
Anda ingin menyimpan data besar Anda jauh dari sedikit data Anda.
>> Dan alasan mengapa adalah karena saya harus pergi membaca item untuk mendapatkan atribut.
Dan jika tubuh saya semua di sini, kemudian membaca hanya beberapa item
jika panjang tubuh saya rata-rata 256 kilobyte masing-masing,
matematika mendapat cukup jelek.
Jadi mengatakan saya ingin membaca inbox Daud.
Inbox David memiliki 50 item.
Rata-rata dan ukuran 256 kilobyte.
Berikut rasio konversi saya untuk RCU adalah empat kilobyte.
>> OK, mari kita pergi dengan akhirnya konsisten membaca.
Aku masih makan 1600 RCU ini hanya untuk membaca inbox Daud.
Aduh.
OK, sekarang mari kita berpikir tentang bagaimana aplikasi bekerja.
Jika saya di sebuah aplikasi email dan Aku sedang melihat inbox saya,
dan saya melihat tubuh setiap pesan, tidak, aku melihat ringkasan.
Aku sedang melihat hanya header.
Jadi mari kita membangun struktur tabel yang terlihat lebih seperti itu.
>> Jadi, inilah informasi bahwa alur kerja saya perlu.
Ini di inbox saya GSI.
Ini tanggal, pengirim, subjek, dan kemudian
ID pesan, yang menunjuk kembali ke meja pesan
di mana saya bisa mendapatkan tubuh.
Nah, ini akan menjadi catatan ID.
Mereka akan menunjuk kembali ke Item ID di meja Dynamo DB.
Setiap indeks selalu creates-- selalu memiliki item
ID sebagai bagian of-- yang dilengkapi dengan indeks.
>> Baiklah.
AUDIENCE: Ini memberitahu itu di mana itu disimpan?
RICK Houlihan: Ya, itu memberitahu exactly-- itulah apa yang dilakukannya.
Dikatakan inilah rekor ulang saya.
Dan itu akan menunjuk kembali ke record ulang saya.
Persis.
OK, jadi sekarang inbox saya sebenarnya jauh lebih kecil.
Dan ini benar-benar mendukung alur kerja dari sebuah aplikasi email.
Jadi inbox saya, saya klik.
Aku pergi bersama dan saya klik pada pesan, saat itulah saya harus pergi mendapatkan tubuh,
karena aku akan pergi ke pandangan yang berbeda.
Jadi jika Anda berpikir tentang jenis MVC dari framework, model view controller.
>> Model berisi Data yang kebutuhan tampilan
dan controller berinteraksi dengan.
Ketika saya mengubah frame, ketika Saya mengubah perspektif,
itu OK untuk kembali ke server dan terisi kembali model,
karena itulah yang diharapkan pengguna.
Ketika mereka mengubah pandangan, saat itulah kita bisa kembali ke database.
Jadi email, klik.
Saya mencari tubuh.
Perjalanan pulang pergi.
Pergi mendapatkan tubuh.
>> Saya membaca data jauh lebih sedikit.
Aku hanya membaca tubuh yang David kebutuhan ketika ia membutuhkan mereka.
Dan aku tidak membakar di 1600 RCU hanya untuk menunjukkan kotak masuk.
Jadi sekarang itu-- ini adalah cara bahwa LSI atau GSI-- Maaf,
GSI, akan berhasil.
Kami punya hash kami pada penerima.
Kami punya kunci rentang pada tanggal.
Dan kita punya atribut diproyeksikan bahwa kita hanya perlu untuk mendukung pandangan.
>> Kami memutar bahwa untuk kotak keluar.
Hash pada pengirim.
Dan pada intinya, kita harus yang sangat bagus, tampilan bersih.
Dan itu kami basically-- memiliki pesan ini bagus
tabel yang sedang menyebar baik karena itu hash saja, ID pesan hash.
Dan kami memiliki dua indeks yang yang berputar off dari meja itu.
Baiklah, jadi ide di sini adalah tidak menyimpan data yang besar dan data kecil ini
bersama.
Partisi vertikal, partisi meja tersebut.
Jangan membaca data Anda tidak perlu.
Baiklah, game.
Kita semua suka game.
Setidaknya aku suka game kemudian.
Jadi beberapa hal bahwa kita berurusan dengan ketika
kita berpikir tentang game, kan?
Game hari ini, terutama ponsel game, adalah semua tentang pemikiran.
Dan aku akan memutar di sini sedikit jauh dari DynamoDB.
Aku akan membawa beberapa diskusi
sekitar beberapa teknologi AWS lainnya.
>> Tapi gagasan tentang game adalah untuk berpikir sekitar dalam hal API, API yang,
secara umum, HTTP dan JSON.
Ini bagaimana game ponsel jenis berinteraksi dengan ujung belakang mereka.
Mereka melakukan JSON posting.
Mereka mendapatkan data, dan itu semua, secara umum, di bagus JSON API.
>> Hal-hal seperti mendapatkan teman-teman, mendapatkan data leaderboard, pertukaran,
user generated content, mendorong kembali ke sistem,
ini adalah jenis hal bahwa kita akan melakukan.
Data aset biner, data ini mungkin tidak duduk dalam database.
Ini mungkin duduk di toko objek, kan?
Tapi database akan akhirnya mengatakan sistem,
mengatakan aplikasi mana harus pergi mendapatkannya.
Dan pasti, multiplayer server, infrastruktur back-end,
dan dirancang untuk tinggi ketersediaan dan skalabilitas.
Jadi ini adalah hal-hal yang kita semua inginkan dalam infrastruktur game saat ini.
>> Jadi mari kita lihat apa yang terlihat seperti.
Mendapat back end inti, sangat mudah.
Kami punya sistem di sini dengan beberapa ketersediaan zona.
Kami berbicara tentang AZS sebagai being-- berpikir dari mereka sebagai pusat data yang terpisah.
Pusat lebih dari satu data per AZ, tapi itu OK,
hanya menganggap mereka sebagai data terpisah pusat yang secara geografis
dan kesalahan terisolasi.
>> Kita akan memiliki contoh beberapa EC2.
Kita akan memiliki beberapa end server kembali.
Mungkin jika Anda warisan arsitektur, kami
menggunakan apa yang kita sebut RDS, layanan database relasional.
Bisa MSSQL, MySQL, atau semacam itu.
Ini adalah cara aplikasi banyak yang dirancang hari ini.
>> Baik kita mungkin ingin pergi dengan ini adalah ketika kita skala keluar.
Kami akan pergi ke depan dan menempatkan ember S3 di sana.
Dan bahwa ember S3, alih-alih melayani up benda-benda dari servers-- kami
kita bisa melakukan itu.
Anda menempatkan semua biner Anda objek pada server Anda
dan Anda dapat menggunakan server mereka contoh untuk melayani data up.
Tapi itu cukup mahal.
>> Cara yang lebih baik untuk dilakukan adalah pergi ke depan dan menempatkan benda-benda dalam ember S3.
S3 adalah obyek repositori.
Itu dibangun khusus untuk melayani sampai jenis hal.
Dan biarkan meminta klien-klien langsung dari orang-orang obyek ember,
offload server.
Jadi kita mulai untuk skala sini.
>> Sekarang kita punya pengguna di seluruh dunia.
Aku pengguna.
Saya harus memiliki konten lokal terletak dekat dengan pengguna ini, kan?
Saya telah membuat ember S3 sebagai repositori sumber saya.
Dan aku akan depan bahwa dengan distribusi CloudFront.
>> CloudFront adalah CD dan jaringan pengiriman konten.
Pada dasarnya dibutuhkan data yang Anda tentukan dan cache itu semua melalui internet
sehingga pengguna di mana-mana dapat memiliki respon yang sangat cepat ketika
mereka meminta benda-benda.
>> Jadi Anda mendapatkan ide.
Anda semacam memanfaatkan semua aspek AWS sini untuk mendapatkan ini dilakukan.
Dan akhirnya, kita membuang dalam grup auto scaling.
Jadi contoh AC2 kami server permainan kami,
karena mereka mulai mendapatkan sibuk dan sibuk dan sibuk,
mereka hanya akan berputar lain Misalnya, berputar contoh lain,
berputar contoh lain.
Jadi teknologi AWS memiliki, itu memungkinkan Anda menentukan parameter
sekitar yang server Anda akan tumbuh.
Sehingga Anda dapat memiliki jumlah n server di luar sana pada waktu tertentu.
Dan jika beban Anda hilang, mereka akan menyusut, jumlahnya akan menyusut.
Dan jika beban datang kembali, itu akan tumbuh kembali keluar, elastis.
>> Jadi ini tampak hebat.
Kami punya banyak contoh EC2.
Kita dapat menempatkan cache depan database,
mencoba dan mempercepat database.
Titik tekanan berikutnya biasanya orang melihat
adalah mereka skala permainan menggunakan sistem database relasional.
Astaga, database kinerja mengerikan.
Bagaimana kita memperbaiki itu?
Mari kita coba menempatkan Cache di depan itu.
>> Nah, cache tidak bekerja begitu besar dalam permainan, kan?
Untuk game, menulis adalah menyakitkan.
Permainan sangat menulis berat.
Cache tidak bekerja ketika Anda menulis berat karena Anda telah selalu
harus memperbarui cache.
Anda memperbarui cache, itu relevan untuk caching.
Ini sebenarnya hanya bekerja ekstra.
>> Jadi di mana kita pergi di sini?
Anda punya hambatan besar di sana dalam database.
Dan tempat untuk pergi jelas adalah partisi.
Partisi tidak mudah dilakukan ketika Anda
berurusan dengan database relasional.
Dengan database relasional, Anda bertanggung jawab untuk mengelola, secara efektif,
ruang kunci.
Anda mengatakan pengguna antara A dan M pergi di sini, antara N dan Z pergi ke sana.
Dan Anda beralih di aplikasi.
Jadi Anda sedang berhadapan dengan ini sumber data partisi.
Anda memiliki kendala transaksional yang tidak menjangkau partisi.
Anda punya semua jenis kekacauan yang Anda
berurusan dengan di sana mencoba berurusan dengan skala keluar
dan membangun infrastruktur yang lebih besar.
Ini hanya tidak menyenangkan.
>> AUDIENCE: Jadi, apakah Anda mengatakan bahwa meningkatkan poin sumber mempercepat
proses?
RICK Houlihan: Meningkatkan?
AUDIENCE: Sumber poin.
RICK Houlihan: Sumber poin?
AUDIENCE: Dari informasi tersebut, di mana informasi tersebut berasal?
RICK Houlihan: No.
Apa yang saya katakan adalah meningkatkan Jumlah partisi dalam menyimpan data
meningkatkan throughput.
Jadi apa yang terjadi di sini adalah pengguna datang ke contoh EC2 di sini,
baik, jika saya membutuhkan pengguna itulah A ke M, aku akan pergi di sini.
Dari N ke p, aku akan pergi di sini.
Dari P ke Z, aku akan pergi di sini.
>> AUDIENCE: OK, mereka jadi mereka adalah semua disimpan di node yang berbeda?
>> RICK Houlihan: Ya.
Pikirkan ini sebagai silo data yang berbeda.
Jadi Anda harus melakukan ini.
Jika Anda mencoba untuk melakukan ini, jika Anda mencoba
untuk skala pada platform relasional, ini adalah apa yang Anda lakukan.
Anda mengambil data dan Anda memotong ke bawah.
Dan kau partisi itu di beberapa contoh dari database.
Dan kau mengelola semua yang di tingkat aplikasi.
Ini tidak menyenangkan.
Jadi apa yang kita ingin pergi?
Kami ingin pergi DynamoDB, sepenuhnya dikelola, NoSQL menyimpan data, penyediaan throughput.
Kami menggunakan indeks sekunder.
Ini pada dasarnya HTTP API dan termasuk dukungan dokumen.
Jadi Anda tidak perlu khawatir tentang semua partisi itu.
Kami melakukan semuanya untuk Anda.
Jadi sekarang, sebagai gantinya, Anda hanya menulis ke meja.
Jika tabel perlu dipartisi, yang terjadi di balik layar.
Anda benar-benar terisolasi dari yang sebagai pengembang.
Jadi mari kita bicara tentang beberapa kasus penggunaan
bahwa kita mengalami dalam game, umum skenario game, leaderboard.
Jadi Anda punya pengguna datang, yang BoardNames bahwa mereka
pada, skor untuk pengguna ini.
Kami mungkin hashing pada UserID, dan kemudian kami memiliki berbagai pada permainan.
Jadi setiap pengguna ingin melihat semua pertandingan dia bermain
dan semua top skor nya di semua pertandingan.
Jadi itulah leaderboard pribadinya.
>> Sekarang saya ingin pergi dan saya ingin get-- jadi saya mendapatkan ini leaderboards pribadi.
Yang ingin saya lakukan adalah pergi mendapatkan skor atas seluruh pengguna.
Jadi bagaimana saya melakukannya?
Ketika catatan saya hash pada UserID, berkisar pada permainan,
baik aku akan pergi ke depan dan restrukturisasi, membuat GSI,
dan aku akan merestrukturisasi data tersebut.
>> Sekarang aku akan hash pada BoardName, yang merupakan permainan.
Dan aku akan berkisar pada top skor.
Dan sekarang saya buat ember yang berbeda.
Saya menggunakan meja yang sama, Data item yang sama.
Tapi aku menciptakan sebuah ember yang memberikan saya sebuah agregasi dari top skor dengan permainan.
>> Dan aku bisa query tabel yang untuk mendapatkan informasi tersebut.
Jadi saya sudah menetapkan bahwa pola permintaan hingga didukung oleh indeks sekunder.
Sekarang mereka dapat diurutkan berdasarkan BoardName dan diurutkan berdasarkan topscore, tergantung pada.
Sehingga Anda dapat melihat, ini adalah jenis dari menggunakan kasus yang Anda dapatkan dalam game.
Penggunaan Lain halnya baik yang kita dapatkan di game adalah penghargaan dan siapa yang memenangkan penghargaan.
Dan ini adalah kasus penggunaan besar di mana kita sebut indeks jarang.
Indeks jarang adalah kemampuan untuk menghasilkan
indeks yang tidak tentu mengandung setiap satu item di atas meja.
Dan kenapa tidak?
Karena atribut yang menjadi diindeks tidak ada pada setiap item.
>> Jadi dalam hal ini khususnya menggunakan kasus, saya katakan,
Anda tahu apa, aku akan membuat atribut yang disebut Award.
Dan aku akan memberikan setiap pengguna yang memiliki penghargaan yang atribut.
Pengguna yang tidak memiliki penghargaan yang tidak akan memiliki atribut itu.
Jadi ketika saya membuat Indeks, satu-satunya pengguna
yang akan menunjukkan di indeks adalah
orang-orang yang benar-benar telah memenangkan penghargaan.
Jadi itulah cara yang bagus untuk dapat untuk membuat indeks disaring yang
sangat, sangat selektif yang tidak harus indeks seluruh tabel.
>> Jadi kita sudah rendah pada waktu di sini.
Aku akan pergi ke depan dan melewatkan dan melewatkan skenario ini.
Berbicara sedikit about--
>> AUDIENCE: Dapatkah saya mengajukan pertanyaan singkat?
Salah satunya adalah menulis berat?
RICK Houlihan: Apa?
AUDIENCE: Menulis berat.
RICK Houlihan: Menulis berat.
Biarkan saya lihat.
>> AUDIENCE: Atau itu tidak sesuatu yang Anda hanya dapat
suara ke dalam hitungan detik?
RICK Houlihan: Kami pergi melalui skenario voting.
Tidak seburuk itu.
Apakah kalian memiliki beberapa menit?
OKE.
>> Jadi kita akan berbicara tentang voting.
Jadi real time voting, kita memiliki persyaratan untuk voting.
Persyaratan yang kita membiarkan setiap orang untuk memilih hanya sekali.
Kami ingin ada untuk dapat untuk mengubah suara mereka.
Kami ingin real-time agregasi dan analisis untuk demografi
bahwa kita akan menjadi menunjukkan kepada pengguna di situs.
>> Pikirkan skenario ini.
Kami bekerja banyak realitas TV menunjukkan di mana mereka
melakukan jenis ini sebenarnya hal.
Jadi Anda bisa memikirkan skenario, kita memiliki jutaan dan jutaan
gadis remaja di sana dengan ponsel mereka
dan voting, dan pemungutan suara, dan voting untuk siapa pun mereka
menemukan untuk menjadi yang paling populer.
Jadi ini adalah beberapa persyaratan kita kehabisan.
>> Dan mengambil begitu pertama dalam memecahkan masalah ini
akan membangun aplikasi yang sangat sederhana.
Jadi saya punya aplikasi ini.
Saya memiliki beberapa pemilih di luar sana.
Mereka datang dalam, mereka memukul aplikasi voting.
Aku punya beberapa orang meja baku Aku hanya akan membuang mereka ke dalam penilaian.
Aku akan memiliki beberapa agregat penilaian tabel yang
akan melakukan analisis dan demografi saya, dan kita akan meletakkan semua ini di sana.
>> Dan ini sangat bagus.
Hidup adalah baik.
Hidup yang baik sampai kita mengetahui bahwa selalu ada hanya satu atau dua
orang yang populer dalam pemilu.
Hanya ada satu atau dua hal bahwa orang-orang benar-benar peduli.
Dan jika Anda suara di skala, tiba-tiba aku
akan memalu neraka keluar dari dua kandidat, satu atau dua kandidat.
Sebuah jumlah yang sangat terbatas item orang menemukan untuk menjadi populer.
>> Ini bukan pola desain yang baik.
Ini sebenarnya adalah pola desain yang sangat buruk
karena ia menciptakan apa yang kita berbicara tentang yang kunci panas.
Kunci panas adalah sesuatu yang kita tidak suka.
>> Jadi bagaimana kita memperbaikinya?
Dan benar-benar, cara untuk memperbaiki ini dengan mengambil orang-orang calon ember
dan untuk masing-masing calon yang kita miliki, kita akan menambahkan nilai acak,
sesuatu yang kita tahu, random nilai antara satu dan 100,
antara 100 dan 1.000, atau antara satu dan 1.000,
namun banyak nilai acak Anda ingin menambahkan ke akhir calon itu.
>> Dan apa yang saya benar-benar melakukan itu?
Jika saya menggunakan kandidat ID sebagai ember untuk orang agregat,
jika saya telah menambahkan acak nomor akhir itu,
Saya telah membuat sekarang 10 ember, sebuah ratus ember, seribu ember
bahwa aku menggabungkan penilaian di seluruh.
>> Jadi saya memiliki jutaan, dan jutaan, dan jutaan catatan datang
untuk calon ini, saya sekarang menyebarkan mereka orang di seluruh Calon a_1
melalui Calon A_100, karena setiap kali orang masuk,
Aku menghasilkan acak nilai antara satu dan 100.
Aku memaku itu ke akhir kandidat yang orang memberikan suara untuk.
Aku membuangnya ke dalam ember itu.
>> Sekarang di bagian belakang, saya tahu bahwa saya mendapat seratus ember.
Jadi ketika saya ingin pergi ke depan dan agregat orang,
Saya membaca dari semua ember.
Jadi aku pergi ke depan dan menambahkan.
Dan kemudian saya pencar berkumpul di mana aku pergi keluar dan mengatakan hei,
Anda tahu apa, kunci ini kandidat ruang adalah lebih dari seratus ember.
Aku akan mengumpulkan semua memberikan suara dari orang-orang seratus ember.
Aku akan agregat mereka dan aku akan mengatakan,
Calon A sekarang memiliki Total penghitungan suara x.
>> Sekarang kedua menulis query dan permintaan membaca
yang baik didistribusikan karena saya sedang menulis di
dan aku membaca di ratusan kunci.
Saya tidak menulis dan membaca di salah satu kunci sekarang.
Jadi itulah pola yang besar.
>> Ini sebenarnya mungkin salah satu dari desain yang paling penting
pola skala di NoSQL.
Anda akan melihat jenis pola desain dalam setiap rasa.
MongoDB, DynamoDB, tidak peduli, kita semua harus melakukan ini.
Karena ketika Anda sedang berhadapan dengan orang-agregasi besar,
Anda harus mencari cara untuk menyebar mereka di ember.
Jadi ini adalah cara Anda melakukannya.
Baiklah, jadi apa Anda lakukan sekarang
adalah Anda perdagangan off dibaca Biaya untuk menulis skalabilitas.
Biaya membaca saya adalah sedikit lebih kompleks
dan saya harus pergi dibaca dari ratus ember, bukan satu.
Tapi aku bisa menulis.
Dan throughput saya, saya menulis throughput yang luar biasa.
Sehingga biasanya berharga teknik untuk skala DynamoDB,
atau database NoSQL untuk hal itu.
Jadi kami menemukan cara untuk skala itu.
Dan kami pikir bagaimana menghilangkan kunci panas kami.
Dan ini fantastis.
Dan kita punya sistem ini bagus.
Dan itu memberi kita voting sangat benar karena kita memiliki catatan suara de-korban penipuan.
Ini dibangun ke DynamoDB.
Kami berbicara tentang hak-hak bersyarat.
>> Ketika pemilih datang, menempatkan insert di atas meja,
mereka memasukkan dengan ID pemilih mereka, jika mereka mencoba untuk memasukkan suara lain,
Saya melakukan write bersyarat.
Mengatakan hanya menulis ini jika ini tidak ada.
Jadi, segera setelah saya melihat bahwa bahwa suara itu memukul meja,
tidak ada orang lain akan menjadi mampu menempatkan suara mereka di.
Dan itu fantastis.
Dan kita incrementing counter kandidat kami.
Dan kami melakukan kami demografi dan semua itu.
Tapi apa yang terjadi jika saya Aplikasi jatuh di atas?
Sekarang semua orang tiba-tiba dari yang datang, dan saya
tidak tahu apakah mereka mendapatkan diproses dalam analisis dan demografi saya
lagi.
Dan saat aplikasi datang kembali, bagaimana
sih saya tahu apa yang orang memiliki diproses dan di mana saya mulai?
>> Jadi ini adalah masalah nyata ketika Anda mulai melihat jenis skenario.
Dan bagaimana kita mengatasi itu?
Kami menyelesaikannya dengan apa yang kita memanggil DynamoDB Streaming.
Streaming adalah waktu memerintahkan dan dipartisi log perubahan setiap akses
ke meja, setiap menulis Akses ke meja.
Setiap data yang ditulis ke tabel muncul di sungai.
>> Ini pada dasarnya antrian 24 jam.
Item memukul sungai, mereka hidup selama 24 jam.
Mereka dapat dibaca beberapa kali.
Dijamin akan disampaikan hanya sekali ke sungai,
bisa membaca nomor n kali.
Jadi namun banyak proses yang ingin Anda mengkonsumsi data, Anda dapat mengkonsumsinya.
Ini akan muncul setiap update.
Setiap menulis hanya akan muncul sekali di sungai.
Jadi Anda tidak perlu khawatir tentang pengolahan dua kali
dari proses yang sama.
>> Ini benar-benar memerintahkan per item.
Ketika kita mengatakan waktu memerintahkan dan dipartisi,
Anda akan melihat per partisi di sungai.
Anda akan melihat item, update dalam rangka.
Kami tidak menjamin pada sungai yang Anda
akan mendapatkan setiap transaksi dalam urutan di item.
>> Jadi aliran yang idempoten.
Apakah kita semua tahu apa idempoten berarti?
Idempoten berarti Anda dapat melakukannya lebih, dan lebih, dan lebih lagi.
Hasilnya akan sama.
>> Streaming adalah idempoten, tetapi mereka harus
bermain dari titik awal, dimanapun Anda memilih, sampai akhir,
atau mereka tidak akan menghasilkan dalam nilai-nilai yang sama.
>> Hal yang sama dengan MongoDB.
MongoDB memiliki membangun sebuah mereka sebut oplog tersebut.
Ini adalah membangun yang sama persis.
Banyak database NoSQL memiliki konstruksi ini.
Mereka menggunakannya untuk melakukan hal-hal seperti replikasi, yang
adalah apa yang kita lakukan dengan aliran.
AUDIENCE: Mungkin pertanyaan sesat, tetapi Anda
berbicara tentang melakukan aplikasi turun sebagainya.
Apakah aliran dijamin tidak pernah mungkin turun?
RICK Houlihan: Ya, sungai dijamin untuk tidak pernah turun.
Kami mengelola infrastruktur di belakang. stream secara otomatis
menyebarkan dalam kelompok auto skala mereka.
Kami akan pergi melalui sedikit sedikit tentang apa yang terjadi.
>> Saya tidak harus mengatakan mereka tidak dijamin untuk tidak pernah turun.
Unsur-unsur dijamin muncul di sungai.
Dan sungai akan dapat diakses.
Jadi apa yang turun atau kembali lagi up, yang terjadi di bawah.
Ini covers-- itu OK.
Baiklah, sehingga Anda mendapatkan yang berbeda lihat jenis dari layar.
Jenis pandangan yang penting untuk programmer biasanya adalah, apa itu?
Saya mendapatkan tampilan lama.
Ketika update hits meja, itu akan mendorong pandangan lama ke sungai
sehingga data dapat arsip, atau perubahan kontrol, identifikasi perubahan, perubahan
pengelolaan.
>> Gambar baru, apa yang sekarang setelah update, itu jenis lain dari tampilan
Anda bisa mendapatkan.
Anda bisa mendapatkan kedua gambar lama dan baru.
Mungkin aku ingin mereka berdua.
Saya ingin melihat apa itu.
Saya ingin melihat apa yang berubah.
>> Saya memiliki jenis kepatuhan dari proses yang berjalan.
Perlu memverifikasi bahwa ketika hal-hal ini berubah,
bahwa mereka dalam batas-batas tertentu atau dalam parameter tertentu.
>> Dan kemudian mungkin saya hanya perlu tahu apa yang berubah.
Saya tidak peduli apa yang item berubah.
Saya tidak perlu perlu tahu apa atribut berubah.
Aku hanya perlu tahu bahwa item yang disentuh.
Jadi ini adalah jenis dilihat bahwa Anda turun sungai
dan Anda bisa berinteraksi dengan.
>> Aplikasi yang mengkonsumsi sungai,
ini adalah jenis cara ini bekerja.
DynamoDB klien meminta untuk mendorong data ke tabel.
Streaming menyebarkan pada apa yang kita sebut pecahan.
Pecahan yang ditingkatkan independen dari meja.
Mereka tidak berbaris benar untuk partisi dari meja Anda.
Dan alasan mengapa karena mereka berbaris
untuk kapasitas, saat ini kapasitas meja.
>> Mereka menyebarkan dalam mereka Kelompok skala auto sendiri,
dan mereka mulai berputar keluar tergantung berapa banyak menulis yang datang,
berapa banyak reads-- benar itu menulis.
Tidak ada reads-- tapi bagaimana banyak menulis datang di.
>> Dan kemudian di bagian belakang end, kita memiliki apa yang kita
memanggil KCL, atau Perpustakaan Client Kinesis.
Kinesis adalah aliran data teknologi pengolahan dari Amazon.
Dan sungai dibangun itu.
>> Jadi Anda menggunakan KCL diaktifkan aplikasi untuk membaca sungai.
Perpustakaan Klien Kinesis sebenarnya mengelola pekerja untuk Anda.
Dan itu juga melakukan beberapa hal yang menarik.
Ia akan membuat beberapa tabel up di tablespace DynamoDB Anda
untuk melacak item yang telah diproses.
Jadi cara ini jika jatuh kembali, jika itu jatuh di atas dan datang dan mendapat
kembali berdiri, dapat menentukan di mana adalah dalam pengolahan sungai.
>> Itu sangat penting ketika Anda sedang berbicara tentang replikasi.
Saya perlu tahu apa data diolah
dan data apa belum untuk diproses.
Jadi perpustakaan KCL untuk aliran akan memberikan banyak fungsi yang.
Itu mengurus semua rumah tangga.
Ini berdiri seorang pekerja untuk setiap pecahan.
Ini menciptakan meja administrasi untuk setiap pecahan, untuk setiap pekerja.
Dan seperti para pekerja api, mereka mempertahankan meja tersebut
sehingga Anda tahu catatan ini dibacakan dan diproses.
Dan kemudian dengan cara itu jika proses meninggal dan datang kembali online,
itu dapat melanjutkan di tempat itu lepas landas.
>> Jadi kita menggunakan ini untuk replikasi lintas wilayah.
Banyak pelanggan memiliki kebutuhan untuk memindahkan data atau bagian dari tabel data mereka
sekitar untuk daerah yang berbeda.
Ada sembilan daerah seluruh dunia.
Jadi mungkin ada saya need-- mungkin memiliki pengguna di Asia, pengguna
di Pantai Timur Amerika Serikat.
Mereka memiliki data yang berbeda yang perlu didistribusikan secara lokal.
Dan mungkin pengguna terbang dari Asia ke Amerika Serikat,
dan saya ingin meniru Data dengan dia.
Jadi, ketika ia mendapat turun dari pesawat, ia memiliki pengalaman yang baik menggunakan aplikasi mobile-nya.
>> Anda dapat menggunakan lintas wilayah perpustakaan replikasi untuk melakukan hal ini.
Pada dasarnya kita memiliki tersedia dua teknologi.
Satu adalah aplikasi konsol Anda bisa berdiri di atas EC2 contoh Anda sendiri.
Ini berjalan replikasi murni.
Dan kemudian kami memberi Anda perpustakaan.
Perpustakaan yang dapat digunakan untuk membangun aplikasi Anda sendiri jika Anda
ingin melakukan hal-hal gila dengan yang data-- filter, meniru hanya bagian dari itu,
memutar data, memindahkannya ke dalam tabel yang berbeda, seterusnya dan sebagainya.
Jadi itu semacam apa yang terlihat seperti.
>> DynamoDB Streaming dapat diproses oleh apa yang kita sebut Lambda.
Kami disebutkan sedikit tentang acara arsitektur aplikasi didorong.
Lambda adalah komponen kunci dari itu.
Lambda adalah kode yang kebakaran pada permintaan dalam menanggapi peristiwa tertentu.
Salah satu peristiwa bisa menjadi Rekor muncul di sungai.
Jika catatan muncul di sungai, kita akan memanggil fungsi Java ini.
Nah, ini adalah JavaScript, dan Lambda mendukung Node.js, Java, Python,
dan akan segera mendukung bahasa lain juga.
Dan cukup untuk mengatakan, itu kode murni.
menulis Di Jawa, Anda mendefinisikan kelas.
Anda mendorong JAR menjadi Lambda.
Dan kemudian Anda menentukan kelas untuk memanggil respon yang acara.
Dan kemudian infrastruktur Lambda balik yang akan menjalankan kode itu.
>> Kode yang dapat memproses catatan dari sungai.
Hal ini dapat melakukan apa saja yang diinginkannya dengan itu.
Dalam contoh ini, semua kami benar-benar lakukan adalah log atribut.
Tapi ini hanya kode.
Kode dapat melakukan apa-apa, kan?
>> Sehingga Anda dapat memutar data tersebut.
Anda dapat membuat tampilan derivatif.
Jika itu adalah struktur dokumen, Anda dapat meratakan struktur.
Anda dapat membuat indeks alternatif.
Segala macam hal yang Anda bisa lakukan dengan DynamoDB Streaming.
>> Dan benar-benar, itulah yang yang terlihat seperti.
Jadi Anda mendapatkan update tersebut datang.
Mereka datang dari string.
Mereka dibaca oleh fungsi Lambda.
Mereka berputar data dan mendorongnya di meja derivatif,
memberitahukan sistem eksternal perubahan, dan mendorong data ke ElastiCache.
>> Kami berbicara tentang bagaimana untuk menempatkan cache di depan database untuk penjualan yang
skenario.
Nah apa yang terjadi jika saya memperbarui deskripsi item?
Nah, jika saya memiliki Lambda fungsi berjalan di atas meja itu,
jika saya memperbarui deskripsi item, itu akan mengambil catatan dari sungai,
dan itu akan memperbarui ElastiCache Misalnya dengan data baru.
Jadi itulah banyak apa yang kita lakukan dengan Lambda.
Ini kode lem, konektor.
Dan itu benar-benar memberikan kemampuan untuk meluncurkan
dan untuk menjalankan aplikasi yang sangat kompleks tanpa dedicated server
infrastruktur, yang benar-benar keren.
>> Jadi mari kita kembali ke kami real-time arsitektur voting.
Ini adalah baru dan ditingkatkan dengan kami sungai dan KCL diaktifkan aplikasi.
Sama seperti sebelumnya, kita dapat menangani skala pemilu.
Kami suka ini.
Kami sedang melakukan keluar mengumpulkan pencar di beberapa ember.
Kami punya penguncian optimis terjadi.
Kita bisa menjaga pemilih kami mengubah suara mereka.
Mereka hanya dapat memilih hanya sekali.
Ini fantastis.
Toleransi kesalahan real-time, scalable agregasi sekarang.
Jika hal tersebut jatuh di atas, itu tahu di mana untuk me-restart sendiri
ketika datang kembali karena kita sedang menggunakan aplikasi KCL.
Dan kemudian kita juga bisa menggunakan Aplikasi KCL untuk mendorong data keluar
untuk pergeseran merah untuk lainnya analisis aplikasi, atau penggunaan
elastis MapReduce untuk menjalankan real-time streaming agregasi off
dari data tersebut.
>> Jadi ini adalah hal yang kita belum berbicara tentang banyak.
Tapi mereka tambahan teknologi yang datang
menanggung ketika Anda sedang mencari di jenis skenario.
>> Baiklah, jadi itu tentang analisis dengan DynamoDB Streaming.
Anda dapat mengumpulkan de-dupe data, melakukan segala macam
barang bagus, data agregat di memori, membuat meja tersebut derivatif.
Itu kasus penggunaan besar bahwa banyak pelanggan
terlibat dengan, mengambil bersarang Sifat dari dokumen-dokumen JSON
dan membuat indeks tambahan.
>> Kami di akhir.
Terima kasih untuk bantalan dengan saya.
Jadi mari kita bicara tentang referensi arsitektur.
DynamoDB duduk di tengah-tengah sehingga banyak infrastruktur AWS.
Pada dasarnya Anda dapat hook it sampai dengan apa pun yang Anda inginkan.
Aplikasi dibangun menggunakan Dynamo termasuk Lambda, ElastiCache, CloudSearch,
mendorong data keluar ke Elastic MapReduce, ekspor impor dari DynamoDB
ke S3, semua jenis alur kerja.
Tapi mungkin yang terbaik hal untuk dibicarakan,
dan ini adalah apa yang benar-benar menarik adalah ketika kita
berbicara tentang aplikasi event driven.
>> Ini adalah contoh dari proyek internal
bahwa kita memiliki mana kita benar-benar penerbitan untuk mengumpulkan hasil survei.
Jadi di link email yang kami mengirimkan, ada akan
menjadi klik link yang mengatakan sedikit di sini untuk menanggapi survei.
Dan ketika beberapa klik orang link tersebut, apa yang terjadi
adalah mereka pull down aman Bentuk survei HTML dari S3.
Ada tidak ada server.
Ini hanyalah sebuah objek S3.
>> Bentuk yang muncul, beban di browser.
Itu punya Backbone.
Itu punya kompleks JavaScript bahwa itu berjalan.
Jadi aplikasi yang sangat kaya berjalan di browser klien.
Mereka tidak tahu bahwa mereka tidak berinteraksi dengan server back end.
Pada titik ini, itu semua browser.
>> Mereka mempublikasikan hasil apa kita sebut Amazon API Gateway.
API Gateway hanyalah sebuah web API Anda dapat menentukan dan menghubungkan
untuk apa pun yang Anda inginkan.
Dalam kasus ini, kami terhubung ke fungsi Lambda.
>> Jadi operasi POST saya terjadi dengan tidak ada server.
Pada dasarnya bahwa API Gateway duduk di sana.
Biayanya apa-apa sampai orang mulai posting untuk itu, kan?
Fungsi Lambda hanya duduk di sana.
Dan biaya apa-apa sampai orang mulai memukul.
Sehingga Anda dapat melihat, sebagai volume meningkat, saat itulah tuduhan datang.
Aku tidak menjalankan server 7/24.
>> Jadi saya tarik bentuk turun dari ember,
dan saya posting melalui API Gateway ke dalam fungsi Lambda.
Dan kemudian Lambda Fungsi mengatakan, Anda tahu
apa, saya punya beberapa PIIs, beberapa informasi pribadi
di tanggapan ini.
Saya mendapat komentar yang datang dari pengguna.
Saya punya alamat email.
Aku punya username.
>> Biarkan saya membagi ini off.
Aku akan menghasilkan beberapa metadata dari catatan ini.
Dan aku akan mendorong metadata ke dalam DynamoDB.
Dan saya bisa mengenkripsi semua data dan dorong ke DynamoDB jika saya ingin.
Tapi itu lebih mudah bagi saya, dalam hal ini menggunakan kasus, untuk pergi ke depan sebuah katakanlah,
Aku akan mendorong data mentah menjadi S3 ember dienkripsi.
Jadi saya menggunakan dibangun di sisi server S3 enkripsi dan Manajemen Key Amazon
Layanan sehingga saya memiliki kunci yang dapat berputar pada interval reguler,
dan saya dapat melindungi data PII sebagai bagian dari keseluruhan alur kerja ini.
>> Jadi apa yang saya lakukan?
Saya baru saja dikerahkan seluruh aplikasi, dan saya tidak memiliki server yang.
Jadi apa acara aplikasi didorong arsitektur lakukan untuk Anda.
>> Sekarang jika Anda berpikir tentang kasus penggunaan untuk this--
kami memiliki pelanggan lain yang saya bicarakan sekitar arsitektur ini sebenarnya yang
menjalankan kampanye fenomenal besar, yang melihat ini dan pergi, oh saya.
Karena sekarang, mereka bisa pada dasarnya mendorong di luar sana,
biarkan kampanye yang hanya duduk ada sampai meluncurkan, dan tidak
perlu khawatir ara tentang apa jenis infrastruktur
akan berada di sana untuk mendukungnya.
Dan kemudian secepat Kampanye yang dilakukan,
itu seperti infrastruktur hanya segera hilang
karena benar-benar ada infrastruktur.
Hanya saja kode yang duduk di Lambda.
Hanya saja data yang duduk di DynamoDB.
Ini adalah cara yang mengagumkan untuk membangun aplikasi.
>> AUDIENCE: Jadi, apakah itu lebih fana dari itu akan
jika disimpan pada sebuah server yang sebenarnya?
>> RICK Houlihan: Absolutely.
Karena itu contoh server harus menjadi 24/07.
Itu harus tersedia untuk seseorang untuk menanggapi.
Nah coba tebak?
S3 tersedia 24/7.
S3 selalu merespon.
Dan S3 adalah sangat, sangat baik di melayani sampai benda.
Benda-benda bisa file HTML, atau File JavaScript, atau apa pun yang Anda inginkan.
Anda dapat menjalankan aplikasi web yang sangat kaya dari S3 ember, dan orang-orang melakukan.
>> Dan itulah ide di sini adalah menjauh dari jalan
kita digunakan untuk berpikir tentang hal itu.
Kita semua digunakan untuk berpikir dalam hal server dan host.
Ini bukan tentang itu lagi.
Ini tentang infrastruktur sebagai kode.
Menyebarkan kode ke awan dan biarkan awan menjalankannya untuk Anda.
Dan itulah yang AWS coba lakukan.
>> AUDIENCE: Jadi kotak emas di tengah API Gateway tidak server seperti,
tetapi sebaliknya adalah hanya--
>> RICK Houlihan: Anda dapat berpikir TI sebagai server fasad.
Semua itu adalah itu akan mengambil HTTP meminta dan peta ke proses lain.
Itu semua hal ini.
Dan dalam hal ini, kita pemetaan untuk fungsi Lambda.
Baiklah, jadi itu yang saya punya.
Terima kasih banyak.
Saya menghargainya.
Aku tahu kita ingin sedikit dari waktu ke waktu.
Dan mudah-mudahan kalian punya sedikit informasi
Anda dapat mengambil hari ini.
Dan saya minta maaf jika saya pergi atas beberapa kepala Anda,
tapi ada banyak yang baik dari pengetahuan dasar dasar
yang saya pikir sangat berharga bagi Anda.
Jadi terima kasih karena telah saya.
[TEPUK TANGAN]
AUDIENCE: [tidak terdengar] adalah ketika Anda katakan
Anda harus melalui hal dari awal sampai akhir
untuk mendapatkan nilai-nilai yang tepat atau nilai yang sama,
bagaimana akan nilai-nilai berubah jika [tidak terdengar].
>> RICK Houlihan: Oh, idempoten?
Bagaimana nilai-nilai akan berubah?
Nah, karena jika saya tidak menjalankan semua jalan sampai akhir,
maka saya tidak tahu perubahan apa dibuat di mil terakhir.
Ini tidak akan menjadi Data yang sama seperti apa yang saya lihat.
AUDIENCE: Oh, jadi Anda hanya belum mendapatkan seluruh masukan.
RICK Houlihan: Benar.
Anda harus pergi dari awal sampai akhir, dan kemudian itu
akan menjadi negara yang konsisten.
Keren.
>> AUDIENCE: Jadi Anda menunjukkan kita DynamoDB dapat melakukan dokumen atau nilai kunci.
Dan kami menghabiskan banyak waktu pada nilai kunci dengan hash dan cara
untuk flip itu sekitar.
Ketika Anda melihat meja tersebut, adalah bahwa meninggalkan pendekatan dokumen?
>> RICK Houlihan: Saya tidak akan mengatakan meninggalkannya di belakang.
>> AUDIENCE: Mereka dipisahkan dari the--
>> RICK Houlihan: Dengan dokumen Pendekatan, jenis dokumen DynamoDB
hanya berpikir sebagai atribut lain.
Ini atribut yang berisi struktur data hirarkis.
Dan kemudian di query, Anda dapat menggunakan properti
dari benda-benda menggunakan Object Notation.
Jadi saya dapat menyaring pada bersarang properti dari dokumen JSON.
AUDIENCE: Jadi setiap kali saya melakukan pendekatan dokumen,
Saya bisa semacam tiba di tabular-- yang
AUDIENCE: Absolutely.
AUDIENCE: --indexes dan hal yang Anda hanya berbicara tentang.
RICK Houlihan: Ya, indeks dan semua itu,
ketika Anda ingin indeks properti dari JSON,
cara bahwa kita harus melakukan itu adalah jika Anda menyisipkan objek JSON atau dokumen
ke Dynamo, Anda akan menggunakan aliran.
Streaming akan membaca input.
Anda akan mendapatkan bahwa JSON keberatan dan Anda akan mengatakan OK,
apa properti saya ingin indeks?
>> Anda membuat tabel turunan.
Nah, itu cara kerjanya sekarang.
Kami tidak mengizinkan Anda untuk indeks langsung properti-properti.
>> AUDIENCE: Tabularizing dokumen Anda.
>> RICK Houlihan: Tepat, perataan itu, tabularizing itu, persis.
Itulah apa yang Anda lakukan dengan itu.
>> AUDIENCE: Terima kasih.
>> RICK Houlihan: Yep, benar-benar, terima kasih.
AUDIENCE: Jadi itu semacam Mongo memenuhi Redis classifers.
>> RICK Houlihan: Ya, itu banyak seperti itu.
Itu penjelasan yang baik untuk itu.
Keren.