[MÜZİK OYUN] Rick, Houlihan: Pekala. Herkese merhaba. Benim adım Rick Houlihan olduğunu. Ben üst düzey bir anapara değilim AWS de çözümler mimar. Ben NoSQL odaklanmak ve DynamoDB teknolojileri. Ben konuşmak için bugün buradayım O hakkında biraz. 

Benim arka plan öncelikle veri katmanı. Ben yarısını gelişimini geçirdi kariyer, veritabanı yazma veri erişimi, çözümleri çeşitli uygulamalar için. Ben Bulut sanallaştırma oldum yaklaşık 20 yıldır. Bulut Bulut önce Yani, Biz yarar bilgisayar onu aramak için kullanılır. Ve fikir, bu gibi oldu PG & E, ne kullanmak için ödeme yaparsınız. Bugün bulut diyoruz. 

Ancak yıllar geçtikçe, ben çalıştığım şirketlerin bir çift için Muhtemelen hiç duymadım. Ama teknik bir liste derledik başarıları, sana derdim herhalde. Ben Bulut sistemlerde sekiz patenti bulunmaktadır sanallaştırma, mikroişlemci tasarımı, karmaşık olay işleme, ve diğer alanlarda da. 

Bu günlerde Yani, ben NoSQL çoğunlukla odak teknolojiler ve yeni nesil veri tabanı. Ve ben gidiyorum genellikle ne var seninle bugün konuşuyor burada olmak. Yani ne bekleyebilirsiniz Bu oturumdan, Biz kısa aracılığıyla gidersiniz veri işleme tarihçesi. O her zaman yararlı olur Biz nereden geldiğini anlamaya Biz olmamızın sebebi ve nerede olduğumuzu. Ve biz biraz konuşalım NoSQL teknolojisi hakkında biraz temel bir açıdan. 

Biz biraz içine alacak DynamoDB internals. DynamoDB AWS hayır lezzet. Bu tamamen yönetilen ve barındırılan NoSQL çözümü. Ve biz masaya hakkında biraz konuşacağım yapısı, API'ler, veri tipleri, indeksler, ve iç donanım bazı bu DynamoDB teknolojisi. Biz tasarım bazı içine alırsınız desenleri ve en iyi uygulamaları. Sizinle nasıl bahsedeceğiz Bazıları için bu teknolojiyi kullanır Bugünün uygulamalarının. Ve sonra biz biraz konuşacağım Evrim veya ortaya çıkışı hakkında programlamada yeni bir paradigma denilen olay güdümlü uygulamalar ve DynamoDB de o oynuyor nasıl. Ve size biraz bırakacağım Bir referans mimarisi tartışması bu yüzden bazıları hakkında konuşabilirsiniz yollar sen DynamoDB kullanabilirsiniz. 

Bu yüzden ilk bu soru off-- Ben bir sürü veritabanı ne olduğunu duydum. Bir sürü insan onlar düşünüyorum Bir veritabanı ne olduğunu biliyorum. Google'ın size, bu görürsünüz. Bu tutulan bir veri yapılandırılmış bir set Bir bilgisayar, özellikle de bir o çeşitli şekillerde ulaşılabilir. Bunun iyi bir olduğunu varsayalım Modern bir veritabanının tanımı. Ama ben, çünkü sevmiyorum o birkaç şey ima eder. Bu yapıyı ifade eder. Ve bunun bir bilgisayarda olduğunu ima eder. Ve veritabanları vermedi bilgisayarlarda her zaman var. Veritabanları aslında birçok yönden var. 

Bir Yani daha iyi bir tanım Veritabanı böyle bir şeydir. Bir veritabanı bir organize saklamak, yönetmek için bir mekanizma, ve bilgi alma. Bu About.com değil. Yani ben gerçekten görüşmeler bunun nedeni bu gibi Bir veritabanı deposu olma, Bir depo bilgi, ille Bir bilgisayarda oturur bir şey. Ve tarih boyunca, biz Her zaman bilgisayar olmadı. 

Şimdi, ben ortalama sorarsanız ne geliştirici bugün Bir veritabanı, ben olsun cevap. Somewhere I şeyler sopa olabilir. Sağ? Ve bu doğrudur. Ama talihsiz. Veritabanı gerçekten Çünkü Modern app temeli. Bu vakıf var Her uygulama. Ve bunu nasıl inşa veritabanı nasıl yapı veri nasıl dikte gidiyor Ölçeklerken uygulama gerçekleştirir. 

Yani benim işim bugün bir sürü ile ilgili ne ne zaman geliştiriciler olur Bu yaklaşım ve sonrasında başa Bir uygulamada bu Şimdi asıl ötesinde ölçekleme Kötü tasarım niyet ve acı. Yani umarım sizi Bugün yürüyüp, sen olacak araçları bir çift var devam edeceğiz senin kemer bu aynı hataları yapmaktan. Pekala. Yani birazcık bahsedelim veritabanı teknolojisinin zaman çizelgesi. Ben bir okudum düşünüyorum makale değil uzun zaman önce ve çizgiler, bir şey söyledi çok şiirsel ifadesi var. O dedi tarih Verilerin işlenmesi olduğunu Yüksek filigran dolu veri bolluğu. TAMAM. Şimdi, ben bu tür doğru sanırım. Ama ben aslında hiç bir unsur olarak bakmak Tarih aslında doldurulur Veri basıncının yüksek filigran. Veri hızı için yutma iner asla. Bu sadece kadar gider. 

Ve yenilik oluşur Biz veri basıncı, gördüğünüz bir veri miktarını Şimdi sisteme geliyor. Ve bu işlenemeyen verimli zamanında ve maliyet ya. Başlamadan Ve o zaman Veri basıncına bakmak için. 

Yani biz baktığımızda İlk veri tabanı, bu kulağımıza arasında idi biridir. Hepimiz onunla doğmuş ediyoruz. Güzel bir veritabanı var. Bu yüksek kullanılabilirlik vardır. Her zaman üzerinde. Sen her zaman alabilirsiniz. 

Ama tek bir kullanıcı var. Seninle benim düşüncelerimi paylaşmak olamaz. Sen benim düşüncelerimi alınamıyor Bunları istediğiniz zaman. Ve onların abilitiy o kadar iyi değil. Biz şeyleri unutmak. Her şimdi ve sonra, bizden biri yaprakları ve başka bir varoluş geçer ve biz her şeyi kaybetmek Bu veritabanındaki oldu. Yani tüm bu iyi değil. 

Ve bu zaman içinde iyi çalıştı biz gün geri vardı ne zaman biz gerçekten bilmek gerekli tek şey Nereye yarın gidecek ya da biz en iyi yiyecek toplamak nerede. Ama biz başladık bir şekilde büyümek için medeniyet ve devlet başladı vücuda gelmiş, ve işletmeler, gelişmeye başladı Biz biz fark etmeye başladım biraz daha gerekenler Bizim baş koymak olabilir. Pekala? 

Biz kayıt sistemlerini gerekli. Biz mümkün veri depolamak gereken yerler gerekiyordu. Bu yüzden, yazı belgeler başladı kütüphaneler ve arşivler oluşturmak. Biz geliştirmeye başladı Sistem bir defter muhasebe. Ve defter sayma sistem , yüzyıllar boyunca dünya koştu ve belki de bin olarak biz tür noktasına büyüdü nerede veri yükü aştı bu sistemlerin özelliği Bunu içermesi mümkün. 

Ve bu aslında 1880'lerde oldu. Sağ? 1880 ABD sayımında. Bu nerede dönüm gerçekten Modern veri işleme etmektedir. Bu noktada olduğunu veri bu miktar, Bu tarafından toplanan ediliyordu ABD hükümeti noktası var nerede işlemek için sekiz yıl sürdü. 

Şimdi, sekiz senedir olarak Eğer, sayım biliyorum çalışır, her 10 senedir o yüzden Oldukça açık o zaman biz 1890 nüfus sayımını var veri miktarı o işlenecek gidiyordu hükümet tarafından oldu 10 yıldan fazla olacak, öyle başlatılan yeni nüfus sayımına alacaktı. Bu bir sorun oldu. 

Yani adam Herman adında Hollerith birlikte geldi ve o birim rekor yumruk icat Kartlar, delikli kart okuyucu, delikli kart tab ve harmanlama ve Bu teknoloji için mekanizmalar. Ve o oluşan bu şirket Zaman, diğerleri bir çift ile birlikte, aslında oldu bir direklerinden biri bugün bildiğimiz küçük şirket IBM çağırdı. 

Böylece IBM aslen oldu Veritabanı iş. Ve bu yaptıklarını gerçekten. Onlar veri işleme yaptılar. 

Yumruk çoğalması böylece kartları, ustaca bir mekanizma bu kaldıraç edememek teknoloji sıralı sonuç kümelerini yoklamak için. Bu resimde görebilirsiniz orada biz biraz-- var Biraz small-- ama gördüğünüz Çok ustaca mekanik mekanizması Biz delikli kart güverte nerede. Ve birilerinin alma Biraz tornavida aracılığı ile yapışmasını yuvaları ve yukarı kaldırarak o maçı almak için sıralanmış sonuçlar ayarlayın. 

Bu bir kümelenme olduğunu. Biz bu her zaman yapmak Bilgisayarda Bugün veritabanında bunu nerede. Biz doğru, elle yapmak için kullanılan? İnsanlar bunları birlikte koydu. Ve yayılması oldu Bu yumruk kartları Biz denilen hangi veri davul içine ve veri makaraları, kağıt şerit. 

Veri işleme endüstrisi aldı Oyuncu piyano bir ders. Oyuncu geri piyanolar Yüzyılın dönüş yuvaları ile kağıt makaraları kullanmak için kullanılır üzerinde oynamak için hangi tuşları söylemek. Bu teknoloji uyarlanmıştır Yani Sonunda, dijital veri depolamak için Onlar bu verileri koymak olabilir çünkü Bu kağıt şerit makaralar üzerine. 

Şimdi, bir sonucu olarak, veri nasıl actually-- oldu Bu veriler doğrudan erişebilirsiniz oldu Eğer depolanan nasıl bağlıdır. Yani bir kaset verileri koyarsanız, Ben doğrusal veri erişim vardı. Ben bütün rulo zorunda bant tüm verilere erişmek için. Ben yumruk veri koyarsanız Kartlar, bunu erişebilir Biraz daha rastgele moda, belki değil en kısa sürede. 

Ama nasıl sınırlamalar vardı biz depolanan nasıl dayalı verilere erişim. Ve böylece bu bir sorun olduğunu 50'li girecek. Yine, biz biz olarak görmek başlayabilirsiniz işlemek için yeni teknolojiler geliştirmek Veri, sağ, yukarı açılır yeni çözümler kapı, Yeni programlar için, yeni Bu veriler için uygulamalar. Ve gerçekten, yönetişim neden olmuş olabilir neden biz bu sistemlerin bazıları geliştirdi. Ama iş hızla oldu Evrim arkasında sürücü Modern veritabanı ve modern bir dosya sistemi. 

Sonraki şey Böylece 50'lerde geldi oldu Dosya sistemi ve oldu rasgele erişim depolama gelişimi. Bu güzel oldu. Şimdi, aniden, biz koyabilirsiniz bizim Bu sabit diskler üzerinde herhangi bir yere dosyaları ve biz rastgele bu verilere erişebilir. Bunu ayrıştırmak dosyaları dışarı bilgi. Ve biz Dünyanın en tüm çözüldü veri işleme ile ilgili sorunlar. 

Ve bu yaklaşık 20 kadar ya da Evrim kadar 30 yıl ilişkisel veritabanı, hangi Dünya artık biz karar verdiğinde ise yenilgiler bir depo olması gerekir dosyanın arasında veri yayılma biz inşa ettik sistemler. Sağ? Çok sayıda dağıtılmış çok fazla veri yerler, veri de-çoğaltılması, ve depolama maliyeti büyük oldu. 

70'lerde, en pahalı kaynak Bir bilgisayar olduğu depolama oldu. İşlemci oldu Sabit maliyet olarak inceledi. Ben kutu satın aldığınızda, CPU bazı iş yapar. Bu ister iplik için gidiyor aslında çalışma ya da değil. Bu gerçekten bir batık maliyet var. 

Ama ne bir olarak bana maliyeti iş depolama. Gelecek daha fazla disk satın almak varsa ay, ben ödemek gerçek bir maliyet var. Ve depolama pahalıdır. 

Şimdi ileri 40 yıl ve biz farklı bir sorunumuz var. Hesaplamak artık En pahalı bir kaynak. Depolama ucuz. Biz herhangi bir yere gidebilir demek bulut ve biz ucuz depolama bulabilirsiniz. Ama ne bulamıyorum ucuz hesaplama olduğunu. 

Bugünün evrimi So teknoloji, veritabanı teknolojisi, gerçekten etrafında odaklanmıştır dağıtık veritabanları Bu muzdarip yok ölçek aynı tip İlişkisel veritabanlarının sınırlamalar. Biz hakkında biraz konuşacağım aslında ne anlama geldiğini. 

Ancak nedenlerinden biri bu-- biz arkasında sürücü Veri basıncı hakkında konuştuk. Veri basıncı şey Bu yenilik sürücüler. Ve bakıyorum eğer Son beş yılda, Bu hangi veri grafiğidir Genel işletme genelinde yük son beş yıl içinde gibi görünüyor. 

Ve Genel kural Bu days-- Eğer Google-- giderseniz Verilerin 90% olduğu Bugün saklamak, ve oldu son iki yıl içinde üretilen. TAMAM. Şimdi, bu yeni bir eğilim değil. Bu oldu bir eğilim 100 yıl için dışarı gidiyor. Hiç Herman Hollerith beri punch kart geliştirdi, Biz veri depoları inşa ettik ve olağanüstü hızlarda veri toplama. 

Yani son 100 yıldır, Bu eğilim gördüm. Yani değiştirmek için gitmiyor. İleriye dönük olarak, biz görmeye gidiyoruz Bu, değilse bir hızlandırılmış eğilim. Ve bu neye benzediğini görebilirsiniz. 

2010 yılında bir iş vardı varsa yönetimi altında veri terabayt Onlar anlamına geliyor bugün veri 6,5 petabayt yönetimi. Yani 6500 kat daha fazla veri var. Ve bunu biliyorum. Ben her gün bu işletmeler ile çalışır. Beş yıl önce, ben şirketlere konuşmak istiyorum ne bir ağrı hakkında benimle kim konuşmak istiyorum verinin terabayt yönetmektir. Ve onlar konuşmak istiyorum Gördüğümüz nasıl bana Bu muhtemelen gidiyor Bir petabayt ya da iki olmak üzere bir kaç yıl içinde. 

Bunlar aynı şirketler Ben ile toplantı yapıyorum, bugün, ve onlar benimle konuşuyor Sorun yönetmek orada yaşıyorsanız on, veri 20 petabayt. Patlaması Yani endüstrisinde veri muazzam yönlendirdiğini Daha iyi çözümler için gereklidir. Ve ilişkisel veritabanı Sadece talebe kadar yaşayan değil. 

Ve böylece lineer var Veri basıncı arasındaki korelasyon ve teknik yenilik. Tarih bize göstermiştir Bu, o zaman, zaman veri hacmi İşlenmiş gereken Sistemin kapasitesini aştığı makul bir süre içinde işlemek için veya makul bir maliyetle, Daha sonra yeni teknolojiler Bu sorunları çözmek için icat edilir. Bu yeni teknolojiler, sırayla, kapıyı aç sorunlar başka bir dizi, hangi daha fazla veri topluyor. 

Şimdi, bu durdurmak için gitmiyoruz. Sağ? Biz bu durdurmak için gitmiyoruz. Neden? Her şeyi bilemeyiz, çünkü evrende bilmek var. Ve sürece biz, hayatta oldum olarak insanın tarih boyunca, biz her zaman daha fazla şey öğrenmek tahrik var. 

Bu yüzden biz hareket her inç gibi görünüyor Bilimsel keşif yolda, Biz veri miktarını katlanarak artıyor Biz katlanarak işlemek gerektiğini Biz daha fazla ve daha fazla ortaya çıkarmak olarak hayatın işleyişinin, evren nasıl çalıştığıyla ilgili yaklaşık bilimsel keşif sürüş ve buluş, Bugün yapıyoruz. Veri hacmi sadece sürekli artar. Yani başa edememek Bu sorun çok büyük. 

Şeylerden biri So Biz NoSQL neden olarak görünüyor? Nasıl NoSQL Bu sorunu çözmek nedir? Peki, ilişkisel veri tabanları, Yapılandırılmış sorgu dili, SQL-- gerçekten bir yapı var İlişkisel bu şeyler database-- depolama için optimize edilmiş. 

70'lerde, yine Disk pahalıdır. Depolama sağlama egzersiz kurumsal hiç bitmeyen olduğunu. Biliyorum. Ben yaşadım. Ben bir depolama sürücüleri yazdı Enterprised superserver şirketi geri 90'larda. Ve alt satırda başka bozucu olduğunu Depolama dizisi sadece bir şey olduğunu işletmedeki her gün oldu. Ve bu hiçbir zaman durdu. Yüksek yoğunluklu depolama, talep Yüksek yoğunluklu depolama için, ve daha verimli depolama için durdu asla devices--. 

Ve NoSQL büyük bir teknolojidir veriyi normalleştirir çünkü. Bu veri de-çoğaltır. Bir yapıda veri koyar Her erişim desen agnostik olduğunu. Çoklu uygulamalar söz vurabilir SQL veritabanı, ad hoc sorguları çalıştırmak, ve şekil veri almak onlar Onların iş yükleri için işlemek gerekir. Bu fantastik geliyor. Ama alt satırda herhangi ile Sistem, bu her şeyi agnostik olmadığını, hiçbir şey için optimize edilmiştir. Tamam mı? 

Ve biz ne olsun ilişkisel veritabanı. Bu depolama için optimize edilmiş. Bu normalize var. Bu ilişkisel değil. Bu ad hoc sorguları destekler. Ve bu ve dikey ölçekler. 

Ben daha büyük bir SQL veritabanı almak gerekiyorsa ya da daha güçlü bir SQL veritabanı, Ben demir daha büyük bir parça satın almak gidin. Tamam mı? Ben müşterilerinin çok çalıştık büyük yükseltmeleri yoluyla olmuştur Onların SQL altyapısında sadece Altı ay sonra bulmak için, yine duvara vuruyorlar. Ve Oracle veya MSSQL cevap veya başkası daha büyük bir kutu olsun. Peki er ya da geç, bir satın alamazsınız kutu büyük ve gerçek bir sorun. Biz aslında bir şeyleri değiştirmek gerekiyor. Peki bu nasıl çalışır? Bu çevrimdışı için iyi çalışır analitik, OLAP tipi iş yükleri. SQL nereye ait Ve bu gerçekten. Şimdi, birçok çevrimiçi bugün kullanılan işlem işleme tipi uygulamaları. Ve en gayet güzel çalışıyor kullanımı belli bir düzeyde, ama sadece ölçek değil NoSQL yaptığı yol. Ve biz biraz konuşalım Bu yüzden hakkında biraz. 

Şimdi, NoSQL, diğer taraftan, Daha fazla bilgi işlem için optimize edilmiştir. Tamam mı? O kadar agnostik değil erişim deseni. Biz de-normalize dediğimiz mı yapı veya bir hiyerarşik yapı. Ilişkisel bir veritabanında veri Birden fazla tablodan araya İhtiyacınız görünümünü üretmek için. Bir NoSQL veri tabanında veriler bir belge içinde saklanır hiyerarşik yapısını içermektedir. Normal olacağını tüm veriler bu görünüm elde etmek için bir araya tek bir belge saklanır. Ve biz hakkında biraz konuşacağım nasıl çizelgeleri bir çift çalışır. 

Ama burada fikir depolamak olduğunu Bu örneği görünümler gibi veri. Tamam mı? Yatay ölçek. Sağ? Ben artırmak gerekiyorsa Benim NoSQL küme boyutu, Ben daha büyük bir kutu almak gerekmez. Ben başka bir kutu olsun. Ve ben, birlikte bu küme ve ben bu verileri shard olabilir. Biz hakkında biraz konuşacağız sharding ne olmak Bu veritabanını ölçekli mümkün Birden fazla fiziksel cihazlar arasında ve bariyer kaldırmak dikey ölçek beni gerektirir. 

Bu yüzden gerçekten çevrimiçi için yerleşik işlem ve ölçek. Büyük bir ayrım var Burada raporlama arasında, değil mi? Raporlama, bilmiyorum soruları ben soracağım. Sağ? Reporting-- birisi itibaren ise Benim pazarlama departmanı Benim müşterilerinin kaç sadece- istiyor Bu özel özelliğine sahip olan Bilmiyorum bu day-- aldım ne sormak için gidiyoruz sorgulayabilirsiniz. Yani agnostik olmak gerekir. 

Şimdi, online olarak işlem uygulaması, Ben soruyorum sorular biliyorum. Ben uygulama inşa çok özel bir iş akışı. Tamam mı? Ben verileri optimize Yani eğer Bu iş akışını desteklemek için saklamak, Daha hızlı olacak. Ve bu yüzden NoSQL can var Gerçekten teslimatı hızlandırmak hizmetlerin bu tip. Pekala. 

Yani biz içine almak için gidiyoruz Burada teori biraz. Ve bazılarınız, gözlerin biraz geri almak olabilir. Ama tutmaya çalışacağım Ben mümkün olduğunca yüksek seviyede. Projede iseniz Yani yönetimi, var Bir yapı denilen kısıtlamaların üçgeni. TAMAM. Kısıtlar emirlerine üçgeni Eğer her şeyi her zaman sahip olamaz. Senin pasta var ve o çok yiyemez. Yani proje yönetimi, bu üçgen kısıtlamaları, sen ucuz olabilir olduğu Eğer hızlı olabilir ya da bunu iyi olabilir. İkisini seç. Eğer üçünü olamaz çünkü. Sağ? TAMAM. 

Yani bu çok duymak. Bu, üçlü kısıt var üçlü kısıt üçgen, veya demir üçgen oftentimes-- olduğunu Eğer proje yöneticileri konuşmak, onlar bu konuda konuşacağız. Şimdi, veri tabanları var Kendi demir üçgen. Ve Verilerin demir üçgen Biz CAP teoremi diyoruz. Tamam mı? 

CAP teoremi dikte nasıl veritabanları işletmek çok özel koşullar altında. Ve biz hakkında konuşacağım Bu durum ne. Ama üçgenin üç puan, bu yüzden, C'dir, tutarlılık konuşmak için. Tamam mı? Yani TKP, tutarlılık tüm demektir veritabanına erişebilir istemcileri her zaman çok olacaktır Verilerin tutarlı görünümü. Kimse iki farklı şeyler görmek. Tamam mı? Ben veritabanı görürseniz, Ben aynı görünüm görüyorum Benim ortağı olarak görmektedir kim aynı veritabanı. Bu tutarlılık var. 

Durumu demektir ki, eğer veritabanı çevrimiçi, bu ulaşılabilir eğer, tüm istemcilerin hep olacak ki okumak ve yazmak mümkün. Tamam mı? Yani her müşteri o veritabanı okuyabilirsiniz Her zaman mümkün okuma olacak Veri ve yazma veri. Ve eğer durum buysa, o kullanılabilir bir sistemdir. 

Ve Üçüncü nokta ne olduğunu Biz bölüm tolerans diyoruz. Tamam mı? Bölme tolerans araçları sistem iyi çalışır fiziksel ağ rağmen Düğümler arasındaki bölmeler. Tamam mı? Yani kümedeki düğümler olamaz birbirleriyle konuşmak, ne olur? Pekala. 

Yani ilişkisel veritabanları choose-- Bu iki seçebilirsiniz. TAMAM. Yani ilişkisel veritabanları seçim tutarlı ve kullanılabilir olması. Bölüm arasında olursa veri deposunda DataNodes, Veritabanı çöker. Sağ? Sadece iner. TAMAM. 

Ve bu onların neden olduğu Daha büyük kutuları ile büyümek. Sağ? Hayır-- genellikle bir küme var, çünkü Veritabanı, pek çoğunun orada değil o şekilde işletmek. Ama en veritabanları ölçek dikey tek bir kutu içinde. Olmaları gerekir çünkü tutarlı ve kullanılabilir. Bir bölüm enjekte edilecek olursa, o zaman bir seçim yapmak zorunda kalacak. Sen arasında bir seçim yapmak zorunda tutarlı ve kullanılabilir olması. 

Ve bu NoSQL veritabanları ne var. Pekala. Bu yüzden, bir NoSQL veri tabanı, bu İki çeşit olarak geliyor. Biz, iyi have-- Birçok tatlar geliyor, ama iki temel ile geliyor ne characteristics-- Biz CP veritabanı veya a çağırır tutarlı ve bölme toleransı sistemi. Bu adamlar seçim yapmak o zaman düğümleri, birbirleri ile temas kaybı Biz izin gitmiyoruz insanlar artık yazmaya. Tamam mı? 

Bu bölüm kaldırılıncaya kadar, yazma erişimi engellendi. Bu da onların mevcut değildir demektir. Bunlar tutarlı değil. Biz gördüğünüzde bölüm kendini enjekte, Biz şimdi tutarlıdır biz gitmiyoruz, çünkü İki veri değişimini sağlamak için bağımsız bölümün yanları birbirinden. Biz zorunda kalacak iletişim yeniden herhangi bir güncellemeden önce veri izin verilir. Tamam mı? 

Bir sonraki lezzet, AP sistem olacaktır ya da mevcut ve paylaştırıldı tolerans sistemi. Bu adamlar umurumda değil. Sağ? Bir gets herhangi bir düğüm biz onu alacağım, yazma. Yani benim veri kopyalayan ediyorum Birden düğümler arasında. Bu düğümler, bir istemci, müşteri geliyor olsun diyor yılında, bazı verileri yazmak için gidiyorum. Düğüm hiçbir sorun diyor. Düğüm onu ​​alır yanındaki aynı kayıt üzerinde bir yazma, O hiçbir sorun söyleyecek. Somewhere arka arka ucunda, veri çoğaltmak için gidiyor. Ve sonra biri, fark oluyor uh-oh, gerçekleştirecek Münafık sistem, ah-ah, İki taraf için bir güncelleştirme olmuş. Biz ne yaptık? Ve ne o zaman ne olduğunu Onlar bir şeyler yapmak hangi Onları Veri durumunu çözmek için izin verir. Ve biz hakkında konuşacağım Bir sonraki grafikte söyledi. 

Şey burada işaret etmek. Ve ben de almak için gitmiyorum bu kadar içine bunun nedeni Derin veri teorisinin içine alır. Ama işlem var çerçeve o İlişkisel sistemde çalışır o Beni güvenle güncellemeler yapmak sağlar veritabanında birden kuruluşlara. Ve bu güncellemeler oluşacak tek seferde ya da hiç. Bu ASİT işlemleri olarak adlandırılır. Tamam mı? 

ASİT bize tutarlılık atomicity verir, izolasyon ve dayanıklılık. Tamam mı? Hepsi, atom, işlemler anlamına gelir Benim güncellemeler olur ya da onlar değil. Tutarlılık demektir veritabanı her zaman olacak tutarlı getirilebilir Bir güncellemeden sonra devlet. Ben bir veritabanı asla terk etmeyeceğini Bir güncelleştirme uygulandıktan sonra kötü durum. Tamam mı? 

Yani bu biraz farklı CAP tutarlılık daha. CAP tutarlılık anlamına tüm benim müşteriler hep verileri görebilirsiniz. ASİT tutarlılık anlamına zaman o Bir işlem verileri en iyi, bitti. Benim ilişkileri hepsi iyi. Ben bir üst satırı silmek için gitmiyorum ve yetim çocukların bir demet bırakın diğer bazı tabloda. Ben tutarlı olduğumu eğer olamaz bir asit işlemde. 

İzolasyon işlemleri demektir Her zaman birbiri ardına meydana gelecektir. Verilerin sonuç Aynı devlet olacak Bu işlemler sanki Bu aynı zamanda ihraç edildi seri idam edildi. Yani eşzamanlılık var Veri kontrolü. Yani temelde, ben artırmak değil iki kere iki operasyon ile aynı değeri. 

Ama bu değere 1 ekleme diyorsan, ve iki işlemler gelip ve biri, bunu yapmak için denemek İlk oraya gidiyor diğeri en sonra oraya gidiyor. Yani sonunda, ben ikisini ekledi. Ne demek istediğimi görüyor musun? TAMAM. 

Dayanıklılık oldukça basittir. Tüm işlemin kabul edilmektedir, bu kadar Hatta orada olacak Sistem çöküyor. Sistemin kurtarır, bu işlendiği işlem aslında orada olacak. Yani garanti var ASİT işlemleri. Bunlar çok güzel garantisidir bir veritabanı üzerinde olması, ama onlar maliyetle geliyor. Sağ? 

Çünkü sorun Bu çerçeve ile veri bir bölüm varsa set, ben bir karar vermek zorunda. Ben izin zorunda kalacağım bir tarafı veya diğer ilgili güncellemeleri. Ve bu olursa, o zaman ben artık gidiyorum değilim muhafaza edebilmek için bu özellikler. Onlar tutarlı olmayacaktır. Bunlar izole edilmez. O yıkar budur ilişkisel veri tabanları için. Bu nedenle ilişkisel olduğunu veritabanları dikey ölçek. 

Öte yandan, biz var Ne BASE teknolojisini denir. Ve bunlar senin NoSQL Veritabanları vardır. Pekala. Bu yüzden bizim CP, AP veritabanları var. Ve bu temelde dediğimiz vardır mevcuttur, yumuşak devlet, sonunda tutarlı. Tamam mı? 

Temel olarak mevcuttur, çünkü Onlar bölüm hoşgörülü sensin. Onlar her zaman olacak Orada, orada bile düğümler arasında bir ağ bölümü. Ben bir düğüme konuşabilirsiniz, ben değilim veri okumak mümkün olacak. Tamam mı? Hep yazmak mümkün olmayabilir Veri ben tutarlı bir platform yaşıyorum. Ama veri okumak mümkün olacak. 

Yumuşak devlet gösterir Ben o veriyi okumak zaman ki diğer düğümler aynı olmayabilir. Sağ bir düğüm üzerinde verildiyse kümedeki başka bir yerde ve karşısında çoğaltılmadı Küme henüz, o veriyi okurken devlet tutarlı olmayabilir. Ancak, bu olacak sonunda tutarlı, anlam sırasında bir yazma olduğunu sisteme yapılır, bu düğümlere çoğaltılır. Ve sonunda, bu devlet sipariş getirilecek, ve tutarlı bir devlet olacaktır. 

Şimdi, CAP teoremi gerçekten Sadece bir durumda oynar. Bu durumda o zaman durumdur. Her ne zaman faaliyet Çünkü normal mod, hiçbir bölüm yoktur, her şey tutarlı ve kullanılabilir. Sadece CAP dert biz bu bölümü varken. Yani o nadirdir. Ama sistem zaman o nasıl tepki vereceğini Sistemin ne tür dikte meydana biz uğraşıyoruz. 

Yani bir göz atalım neler O AP sistemleri gibi görünüyor. Tamam mı? AP sistemleri iki tatlar geliyor. Onlar ise lezzet gelir usta usta, her zaman kullanılabilir% 100. Ve onlar gelip diyor başka lezzet, Eğer, ben endişe gidiyorum biliyorum Bu bölümleme şey hakkında olduğunda, gerçek bir bölüm meydana gelir. Aksi takdirde, birincil orada oluyor haklarını almaya gidiyor düğümleri. Tamam mı? 

Cassandra gibi biz bir şey Yani eğer. Cassandra usta olurdu usta, bana herhangi bir düğüme yazma bulunuyor edelim. Peki ne oluyor? Yani bir nesne var iki düğüm üzerinde varolan veritabanı. En nesneyi S. arayalım Bu yüzden S. devlet var Bazı operasyonları var S devam ettiğini. Cassandra bana izin verir birden fazla düğüm için yazıyorum. Yani ben bir olsun diyelim İki düğümlerine s için yazma. Peki, nedir oluyor biter Biz bölümleme olay olduğunu diyoruz. Orada olmayabilir fiziksel ağ bölümü. Ama nedeniyle tasarım Sistemin, bu kadar aslında en kısa sürede bölümleme Ben iki düğüm üzerinde bir yazma olsun. Bu beni zorluyor değil bir düğüm üzerinden tüm mal. Ben iki düğüm üzerinde yazıyorum. Tamam mı? 

Yani şimdi ben iki devlet var. Tamam mı? Ne olacak er ya da geç bir Bir çoğaltma olayı orada oluyor. Orada neler olup bittiğini biz Bir bölüm kurtarma denilen hangi Nerede bu iki olduğunu devletler bir araya gel ve bir algoritma olması oluyor Bu, veritabanı içinde çalışır ne karar verir. Tamam mı? Varsayılan olarak, son güncelleme En AP sistemlerinde kazanır. Yani orada genellikle bir Varsayılan algoritma ne Onlar bir geri arama diyoruz işlevi, bir şey o bu durumda adı verilecek bazı mantık yürütmek için tespit edilir Bu çatışmayı çözmek için. Tamam mı? Varsayılan geri ve varsayılan En AP veritabanlarında çözümleyici olduğunu, zaman damgası kazanır sanırım. Bu son güncelleme oldu. Orada bu güncelleştirmeyi koymak için gidiyorum. Bu kaydı dökümü olabilir ben Bir kurtarma günlüğüne dökülüyor Kullanıcı daha sonra tekrar gelip, böylece ve söylemek, hey, bir çarpışma oldu. Ne oldu? Ve aslında bir kaydını dökümü tüm çarpışmalar ve Al ve ne olduğunu görün. 

Şimdi, bir kullanıcı olarak, siz de yapabilirsiniz Bu geri çağırma içine mantığı içerir. Yani bunu değiştirebilirsiniz geri arama çalışması. Sen hey, ben istiyorum, söyleyebilirim Bu verileri düzeltmek için. Ve ben denemek istiyorum ve Bu iki kayıt birleştirildikten. Ama bu size kalmış. Veritabanı bilmiyor nasıl Varsayılan olarak bunu. Zaman çoğu Tek şey veritabanı nasıl ki yapmanız bilir, Bu son kayıt oldu. Yani, kazanmak için gidiyor biri ve ben koyacağım değerdir. Bu bölüm kurtarma kez ve çoğaltma oluşur Bizim devlet, sahip olduğu şimdi hangi asal S Tüm bu nesnelerin birleştirme durumu. Yani AP sistemleri bu var. CP sistemleri gerekmez Bu endişelenecek. En kısa sürede bir bölüm geliyor çünkü oyuna, sadece alarak durdurmak yazıyor. Tamam mı? Yani çok kolay tutarlı olmak ile anlaşma ne zaman hiçbir güncellemeyi kabul etmiyoruz. CP sistemleri yapmak ile budur. Pekala. 

Yani biraz konuşalım erişim desenleri hakkında biraz. Biz NoSQL hakkında konuşmak, bu kadar tüm erişim deseni hakkında. Şimdi, SQL ad hoc, sorgular olduğunu. Bu ilişkisel mağaza bulunuyor. Biz endişelenmenize gerek yok erişim deseni hakkında. Ben çok karmaşık bir sorgu yazmak. Bu gider ve verileri alır. İşte bu görünüyor ne gibi, normalleştirme. 

Bu özel yapının Yani Biz ürün kataloğu bakıyoruz. Ben ürünlerin farklı türleri vardır. Ben kitap var. Ben albüm var. Ben videolar var. Ürünler arasındaki ilişki ve bu kitaplar, albümler herhangi biri, ve videolar tablolar 1: 1 dir. Pekala? Ben bir ürün kimliği var, ve bu kimlik karşılık gelir Bir kitap, bir albüm, ya da bir video. Tamam mı? 1 ilişki: Bu bir 1 var Bu tablolar arasında. 

Şimdi, hepsi books-- sahip kök özellikleri olduğunu. Problem değil. Bu harika. Bir-bir ilişki, ben hepsini almak Veri ben o kitabı açıklamak gerekir. Albums-- albümleri şarkıları var. Bu, birçok tane diyoruz. Her albüm, birçok parça olabilir. Her parça için So Albüm, ben olabilir Bu alt tabloda başka bir rekor. Yani bir kayıt oluşturmak Benim Resimlerim tablo. Birden kayıtları oluşturmak izler tabloda. Bir-çok ilişkisi. 

Bu ilişki ne olduğunu birçok-çok diyoruz. Tamam mı? Sen aktörler olabileceğini görüyoruz Birçok film, pek çok videolar. Yani biz ne biz bu haritalama koymak olduğunu arasındaki tablo, hangi sadece Video kimliği aktör kimliğini eşler. Şimdi birleştiren bir sorgu oluşturabilirsiniz aktörlere aktör video aracılığıyla videoları, ve bana güzel bir listesini verir tüm filmler ve tüm aktörlerin kim film vardı. 

TAMAM. Yani burada biz gitmek. Bire-bir üst düzey ilişki; Bire çok sayıda, parça albümleri; Birçok-çok. Bu üç üst düzey vardır herhangi bir veritabanında ilişkileri. Nasıl bu biliyorsanız ilişkiler birlikte çalışmak, o zaman çok şey biliyor Zaten veritabanı hakkında. Yani NoSQL biraz farklı çalışır. En bir saniye düşünelim Ne o görünüyor tüm ürün almak gitmek istiyorum. 

İlişkisel bir mağazada, ben Tüm ürünlerimizi almak istiyorum Tüm ürünler listesinde. Bu sorgular bir sürü. Ben bütün kitaplar için bir sorgu var. Benim albümlerden bir sorgu var. Ve ben bütün videolar için bir sorgu var. Ve ben koymak lazım hep birlikte bir liste halinde ve geri kadar bu hizmet Bunu talep ediyor uygulamasıdır. 

Benim kitap almak için, ben katılmak Ürün ve kitaplar. Albümlerimi almak için, ben katılmak lazım Ürünler, Albümler ve Parçalar. Ve ben, benim videoları almak için Videolar Ürünleri katılmak için, Aktör Videolar aracılığıyla katılmak, ve Aktörler getirmek. Yani üç sorguları var. Çok karmaşık sorgular tek sonuç kümesini bir araya getirin. 

Bu optimum az var. Bu konuşmamız neden zaman olduğu olan bir veri yapısının gösterimi erişmek için agnostik olması için inşa pattern-- de bu harika. Ve bu gerçekten görebilirsiniz Verileri organize ettik ne güzel. Ve biliyor musun? Ben sadece bir aktör için bir kayıt var. 

Çok havalı. Ben bütün aktörleri deduplicated ettik, ve ben dernekler tutulan Bu eşleme tablosunda. Ancak, veri alma dışarı pahalı olur. Tüm sistem üzerinden CPU yolluyorum Birlikte bu veri yapılarını katılmadan veri geri çekmeye muktedir. 

Peki nasıl etrafında alabilirim? NoSQL yılında hakkında kümeleme, değil normalleşme. Yani biz istiyoruz demek istiyorum erişim deseni destekler. Erişim desen Eğer uygulamalara, Ben bütün ürünlerini almak gerekir. En tek tablodaki tüm ürünleri koysunlar. Bir tablodaki tüm ürünleri koyarsanız, Ben sadece tüm ürünleri seçebilirsiniz Bu tablodan ve ben hepsini almak. Peki bunu nasıl yapacağız? Peki NoSQL hiçbir var tabloya yapısı. Biz hakkında biraz konuşacağım bu nasıl Dinamo DB çalışır. Ama aynı yoksa nitelikleri ve aynı özellikleri her tek her satırda, içinde öğe, bir SQL tablosundaki yapmak gibi. Peki bu bana izin verir yapılacak bir çok şey olduğunu ve bana bir esneklik verir. Bu özel durumda, Benim ürün belgeler var. Bu, özellikle Örnek, her Ürünler tablosundaki bir belgedir. Ve bir kitap için ürün olabilir Bir kitap belirten bir tür kimliği var. Ve uygulama bu ID devreye olacaktır. 

Uygulama katmanı, ben gidiyorum Ah, bu nasıl kayıt türü olduğunu söylemek? Oh, bu bir kitap rekor. Kitap kayıtları bu özelliklere sahip. Bana bir kitap nesnesi yaratalım. Yani doldurmak için gidiyorum Bu madde ile kitap nesnesi. Sonraki öğe gelir ve Bu öğeyi ne diyor? Peki bu öğeyi bir albüm. Ah, ben bambaşka bir var Bunun için işlem rutin, bir albüm çünkü. Ne demek istediğimi görüyor musun? 

Yani uygulama tier-- Ben sadece tüm bu kayıtları seçin. Hepsi geliyor başlar. Hepsi farklı olabilir. Ve bu uygulamanın mantığı var o türleri arasında geçiş ve bunları işlemek için nasıl karar verir. 

Yine, bu yüzden optimize ediyoruz erişim deseni için şema. Biz bunu yapıyoruz bu tabloları çöken. Biz temelde alıyorsun bu normalize yapılar, ve biz inşa ediyoruz hiyerarşik yapılar. Bu kayıtların her birinin içinde Ben dizi özelliklerini görmek için gidiyorum. 

Albümleri için bu belgede içinde, Ben parça dizi görüyorum. Bu izler şimdi o become-- Temelde bu çocuk tablo bu Burada bu yapının var. Yani DynamoDB yapabilirsiniz. Siz MongoDB yapabilirsiniz. Herhangi bir NoSQL veritabanı yapabilirsiniz. Bu tür oluşturun Hiyerarşik veri yapıları Eğer veri almak izin olduğunu çok çabuk şimdi çünkü uymak zorunda değilsiniz. Ben Tracks bir satır eklediğinizde tablo veya Albümleri tabloya bir satır, Ben bu şema uymak zorunda. Ben öznitelik veya olması Bu tablo üzerinde tanımlanan özellik. Bunların her biri, O satır eklediğinizde. Bu NoSQL durum değil. 

Ben tamamen farklı olabilir Her belgede özellikleri Ben koleksiyonuna yerleştirin söyledi. Yani çok güçlü bir mekanizma. Ve gerçekten nasıl var sistemi optimize. Yerine şimdi sorguda, çünkü Tüm bu tabloları birleştirme ve yarım düzine sorguları yürütme İhtiyacım verileri geri çekmek için, Ben bir sorgu yürütme ediyorum. Ve ben yineleme ediyorum ayarlamak sonuçlarla karşılaşmışlardır. size bir fikir verir NoSQL gücünün. Ben tür yanlara buraya gitmek için gidiyorum ve bu konuda biraz konuşmak. Bu, daha çok tür pazarlama veya technology-- teknoloji pazarlama tartışma türü. Ama anlamak önemlidir Biz üst bakmak çünkü eğer Burada bu tabloya, ne bakıyoruz Biz diyoruz teknoloji yutturmaca eğrisi. Ve bu demektir yeni ürünleri devreye giriyor. İnsanlar harika olduğunu düşünüyorum. Ben bütün sorunlarını çözdük. 

Bu son olabilir tüm her şeyi tüm olacak. Ve onlar bunu kullanmaya başlayabilirsiniz. Ve bu şeyler çalışmıyor derler. Bu doğru değil. Eski şeyler daha iyiydi. Ve yaptıklarını geri şeyler olduklarını yolu. Ve sonra sonunda onlar ne biliyorsun, git? Bu şey o kadar kötü değil. Oh, nasıl çalışır. Ve onlar nasıl bunu anlamaya kez işleri, onlar iyiye başlar. 

Ve bu konuda komik bir şey o kadar hatların tür olduğunu Biz Teknoloji Benimseme Eğrisi diyoruz. Yani biz ne olur ise bir çeşit teknoloji tetik. Veri tabanları halinde, veri basıncı var. Biz yüksek su noktaları hakkında konuştuk zaman boyunca veri basıncı. Veri basıncı belli bir çarptığında nokta, bir teknoloji tetik. 

Çok pahalı oluyor. Bu verileri işlemek için çok uzun sürüyor. Biz daha iyi bir şey gerekiyor. Sen yenilikçiler olsun Orada koşturup, çözüm ne olduğunu öğrenmek için çalışıyorum. Yeni bir fikir nedir? 

En iyi Sırada ne var Bu işi yapmanın yolu? Ve onlar bir şey ile gelip. Ve gerçek acıyla insanlar, kanama kenarında çocuklar, onlar her yerinden atlarsınız, Onlar bir cevap gerekir çünkü. Şimdi kaçınılmaz olan oldu ve ne o NoSQL şu anda oluyor. Ben her zaman görüyorum. 

Ne kaçınılmaz olur ise insanlar yeni aracını kullanmaya başlamak Aynı şekilde eski aracı kullanılır. Ve onlar bunu öğrenmek çok iyi çalışmıyor. Ben kim olduğunu hatırlayamıyorum Daha önce bugün konuşuyor. Ama, ne zaman gibi jackhammer icat edilmiştir, insanlar üzerinde salıncak vermedi Onların baş beton şut. 

Ama bu ne Bugün NoSQL ile oluyor. En dükkan yürümek durumunda, Onlar NoSQL dükkan olmaya çalışıyoruz. Ne yapıyoruz olduğunu Onlar, NoSQL kullanıyorsanız ve bunu yüklüyoruz İlişkisel şema dolu. Bu nasıl Çünkü onlar veritabanı tasarımı. Ve onlar neden, merak ediyorsanız Çok iyi performans? Oğlum, bu şey kokuyor. Tüm korumak zorunda benim hayır, hayır, gibi açmayız katılır. Birleştirmeler koruyun? Neden Veri katılıyor? Siz NoSQL veri katılmak yok. Sen araya. 

Bunu önlemek istiyorsanız, öğrenmek yüzden aracı aslında sizin daha önce nasıl çalıştığını kullanmaya başlayabilirsiniz. Denemek ve yeni araçları kullanmayın Aynı şekilde eski araçlar kullanılır. Sen kötü bir deneyim olması için gidiyoruz. Ve her zaman bu hakkında budur. Buraya geliyor başladığınızda insanlar anladım çünkü var nasıl araçları kullanmak. 

Onlar ne zaman aynı şeyi yaptı ilişkisel veritabanları icat edildi, ve dosya sistemleri yerine bulundu. Onlar dosya sistemleri kurmak için çalıştı ilişkisel veri tabanları ile insanların anladım çünkü. Bu işe yaramadı. En iyi uygulamaları anlamak Yani Teknolojinin sizinle çalışıyoruz çok büyük. Çok önemli. 

Bu yüzden DynamoDB içine almak için gidiyoruz. DynamoDB AWS kullanıcısının olduğunu NoSQL platformu tamamen başardı. Ne anlama tamamen yönetilen mu? Bu gerek yok demektir gerçekten bir şey hakkında endişelenmenize. 

Sen gel, sen söyle Bize, bir tablo gerekir. Bu kadar kapasite ihtiyacı var. Sen düğmesine basın ve biz karşılığı sahne arkasında tüm altyapı. Şimdi bu çok büyük. 

Konuşurken Çünkü Bir veritabanı ölçekleme hakkında NoSQL veri kümeleri de Ölçek, koşu petabayt, Milyonlarca çalışan Saniyede işlemler, bunlar küçük kümeler değildir. Biz örnekleri binlerce bahsediyoruz. Örnekleri binlerce yönetme, hatta sanal örneklerini, popo gerçek bir ağrı olduğunu. Ben, her seferinde düşünmek demek İşletim sistemi patch çıkar veya veritabanının yeni bir sürümü. Bu ne anlama geliyor Size operasyonel? Yani 1.200 var demektir gerek sunucuların güncellenmesi. Şimdi bile otomasyon ile, Bu uzun zaman alabilir. Bu bir sürü neden olabilir Operasyonel baş ağrısı, Ben hizmet aşağı olabilir çünkü. 

Ben bu veritabanlarını güncellemek, ben mavi-yeşil dağıtımları yapabilir nerede dağıtmak ve yükseltme yarısı benim düğümleri ve sonra diğer yarısını yükseltin. Bu aşağı atın. Yani altyapısını yönetiyor Ölçek son derece ağrılıdır. Ve AWS bunun dışında o acıyı çekmek. Ve NoSQL veritabanları can olağanüstü acı Onlar ölçek yol yüzünden. 

Yatay Scale. Eğer daha büyük bir NoSQL almak istiyorsanız Veritabanı, daha fazla düğüm satın. Eğer satın Her düğüm Başka bir operasyonel baş ağrısı. Yani bir başkası senin için yapalım. AWS yapabilir. 

Biz belge anahtar değerleri desteklemektedir. Şimdi çok gitmedi Diğer grafik içine. Farklı bir yeri var NoSQL lezzetleri. Onlar getting her türlü konum Bu noktada bir araya munged. Sen, DynamoDB bakmak ve evet diyebiliriz Biz belge ve anahtar değeri hem konum Bu noktayı saklayın. Ve özellikleri iddia edebilirsiniz birinin diğerinin üzerinden. Bana göre, bu bir sürü gerçekten altı olduğunu yarısının, diğer bir düzine evi. Bu teknolojilerin her biri bir İnce teknoloji ve ince bir çözüm. Ben MongoDB iyi ya da olduğunu söyleyemem Daha sonra Couch, Cassandra daha kötü, Daha sonra Dinamo, ya da tam tersi. Bunları sadece seçenekleri demek. 

Bu hızlı ve var her ölçekte tutarlı. Yani bu en büyük biridir ikramiye size AWS ile olsun. DynamoDB ile yeteneği Düşük tek basamaklı almak için herhangi bir ölçekte milisaniyelik gecikme. Bu sistemin bir tasarım hedefi oldu. Ve biz yapıyoruz müşteriler var Saniyede işlemlerin milyonlarca. 

Şimdi bunlardan bazıları ile gidersiniz Burada bir kaç dakika içinde durumlarda kullanmak. Entegre erişim bir denetleme biz dediğimiz var Kimlik Erişim Yönetimi veya IAM. Her sistem nüfuz, AWS sunan her hizmet. DynamoDB bir istisna değildir. Sen erişimi kontrol edebilirsiniz DynamoDB tabloları. Senin AWS tarafından hesapları tamamında erişim rolleri ve izinleri tanımlayan IAM altyapı. 

Ve bu bir anahtar ve ayrılmaz bir bileşeni var Biz Driven Programlama olay dediğimiz. Şimdi bu yeni bir paradigma olduğunu. 

HEDEF KİTLE: Ne kadar doğru sizin oranı var yanlış negatif karşı pozitif Erişim kontrol sistemi? Rick, Houlihan: Gerçek pozitifler yanlış negatif karşı? HEDEF KİTLE: Ne dönersek Eğer iade edilmelidir? Bir süre sonra karşıt olarak o doğrulamak ne zaman geri dönmez? 

Rick, Houlihan: Sana bunu anlayamadı. Herhangi bir hataları varsa olursa olsun bu konuda, Ben sormak için bir insan değilim söz konusu bir soru. Ama bu iyi bir soru. Bilmek merak olurdu Kendim o aslında. 

Ve böylece yeniden, yeni bir paradigma olay güdümlü programlama. Bu, yapabilirsiniz fikir karmaşık uygulamaları dağıtmak olduğunu çok, çok yüksek bir ölçek çalışabilir herhangi bir altyapı olmadan. Herhangi bir sabit olmadan olursa olsun altyapı. Ve biz biraz konuşacağım Bu biz olarak ne anlama geldiği hakkında çizelgeleri sonraki birkaç olsun. 

Biz yapacağız ilk şey Biz tabloları hakkında konuşacağım olduğunu. Dynamo API veri türleri. Ilk şey Ve olacak Bu baktığınızda fark, Eğer herhangi bir veritabanı aşina iseniz, veritabanları API'leri gerçekten iki tür var Ben derim. Veya API iki set. Bunlardan biri olacaktı İdari API. 

Onlar ilgilenir şeyler veritabanı fonksiyonları. Depolama motorunu yapılandırılması, kurma ve tablolar sözlerine ekledi. oluşturma veritabanı kataloglar ve örnekleri. DynamoDB bu seyleri, sen Çok kısa, kısa listeleri vardır. 

Yani diğer bir veritabanlarında, Eğer onlarca görebilirsiniz idari ve komutları komutları, yapılandırma Bu ek seçenekler. DynamoDB size çünkü o gerekmez Eğer sisteminizi yapılandırmak değil, biz bunu. Yani yapmanız gereken tek şey ihtiyacım var hangi boyutta tablo söyle. Yani bir çok olsun komutlar sınırlı sayıda. 

Bir tablo Güncellemesi oluşturma olsun, Masa, Tablo silin ve Tablo açıklayın. Bunlar tek şey Eğer DynamoDB için gereklidir. Bir depolama gerekmez motor konfigürasyonu. Ben çoğaltma konusunda endişelenmenize gerek yok. Ben Sharding hakkında endişelenmenize gerek yok. 

Ben endişelenmenize gerek yok Bu şeyler hakkında herhangi. Biz sizin için her şeyi. Yani havai büyük miktarda bulunuyor sadece plaka kaldırdı oluyor. Sonra CRUD operatörleri var. CRUD şey ne olduğunu bu veritabanında arama , Update, operatörler Sil oluşturun. Bunlar yaygın veritabanı işlemleri. Put öğesi gibi şeyler, öğe, güncelleme olsun öğeleri, öğeleri silmek, toplu sorgu, tarayın. Eğer tüm tabloyu taramak istiyorsanız. Masadan şeyi çekin. DynamoDB hakkında güzel şeylerden biri paralel tarama izin verir. Yani aslında kaç bana bildirin ipler bu tarama çalıştırmak istiyorum. Ve biz bu konuları çalıştırabilirsiniz. Biz yukarı tarama spin olabilir birden çok iş parçacığı üzerinde böylece tüm tabloyu tarayabilir Çok, çok hızlı bir şekilde DynamoDB boşluk. 

Elimizdeki diğer API Bizim Akarsular API dediğimiz. Biz de konuşmak için gitmiyoruz Şu anda bu konuda çok. Ben bazı içerik daha sonra var Bu konuda güverte üzerinde. Ama Akımlar gerçekten running-- olduğunu Zaman sipariş olarak düşünmek ve bölüm değiştirme günlüğü. Üzerinde oluyor her şey masa dere üzerinde gösterir. 

Her tabloya yazma dere üzerinde gösterir. O akışı okuyabilir ve onunla şeyler yapabilirsiniz. Biz hakkında konuşmak ne yapacaksınız şeylerin türleri çoğaltma gibi şeyler yapmak, ikincil dizin oluşturma. Gerçekten harika her türlü işler o ile yapabilirsiniz. 

Veri türleri. DynamoDB, biz hem anahtar destekleyen değer ve belge veri türleri. Ekranın sol tarafta Burada, bizim temel türleri var. Anahtar değer türleri. Bu dizeleri, sayılar ve ikili. 

Yani sadece üç temel türleri. Ve sonra o kümeleri olabilir. Güzel şeylerden biri NoSQL ile ilgili Eğer özellikleri gibi diziler içerebilir. Ve DynamoDB ile diziler içerebilir Bir kök özelliği olarak temel türde. 

Ve sonra belge türleri var. Kaç kişi JSON aşina? Çok JSON aşina Siz? Bu temelde JavaScript var Nesne, Notasyon. Bu temelde sağlar hiyerarşik bir yapıyı tanımlar. 

Üzerinde JSON belgesini saklayabilirsiniz DynamoDB ortak bileşenler kullanılarak veya yapı taşları mevcuttur çoğu programlama dillerinde. Java varsa Yani, sen haritalar ve listeleri bakarak. Ben o bölgede harita nesneleri oluşturabilirsiniz. Anahtar değerler olarak bir harita özellikleri olarak depolanır. Ve bu listeleri olabilir bu özellikleri içindeki değerler. Bu karmaşık saklayabilirsiniz hiyerarşik yapı Tek bir niteliği olarak Bir DynamoDB ürünün. 

DynamoDB tabloları Yani, çoğu gibi NoSQL veritabanları, tablolar ürün yok. MongoDB sen olur Bu belgeleri arayın. Ve bu kanepe temel olacaktır. Ayrıca belge veritabanı. Sen bu belgeleri diyoruz. Belgeler veya öğeler özelliklere sahip. Özellikler mevcut olabilir ya da öğe mevcut değil. DynamoDB olarak, orada bir zorunlu nitelik. Sadece bir ilişkisel veritabanı gibi, Eğer masada bir birincil anahtara sahip. 

DynamoDB bir karma anahtarı dediğimiz vardır. Hash anahtar benzersiz olmalıdır. Yani bir karma tablo tanımladığınızda, temelde ne söylüyorum Her öğe bir karma anahtarı olacaktır. Ve her karma anahtarı benzersiz olmalıdır. 

Her madde tanımlanır benzersiz karma tuşu ile. Ve sadece bir olabilir. Bu Tamam, ama çoğu zaman insanlar ne gerek İstedikleri bu karma Biraz daha yapmak için anahtar daha sadece benzersiz bir tanımlayıcı olabilir. Çoğu kez o karma tuşunu kullanmak istiyorsanız üst düzey çekiş kova olarak. Ve biz bunu yolu gereğidir Biz aralık anahtarı dediğimiz sözlerine ekledi. 

Sadece bir hash Yani eğer masa, bu benzersiz olmalıdır. Bir karma ve aralık tablo ise, karma ve aralık kombinasyonu eşsiz olmalı. Yani bu şekilde düşün. Ben bir forum var. Ve formu vardır, konular vardır nakleder ve yanıtları vardır. 

Yani bir karma olabilir Konu kimliği anahtar. Ve ben bir aralık anahtarı olabilir, Hangi yanıt kimliğidir. Bu şekilde tüm almak istiyorsanız Belirli bir konu için yanıtlar, Ben sadece hash sorgulayabilirsiniz. Bana tüm vermek demek sadece edebilirsiniz Bu karma sahip ürün. Ve ben her soruyu alacağım ya da belirli bir konu için yazı. Bunlar üst düzey toplamalardan çok önemlidir. Onlar birincil erişim desteği Uygulama örneği. Genel olarak, bu, konuşma bizim yapmak istediğimiz budur. Biz table-- istiyoruz Tabloyu yük olarak, Biz veri yapısı istiyoruz bu şekilde tablo içinde Bu uygulama çok can hızlı bir şekilde bu sonuçları almak. Ve çoğu zaman bunu yapmak için bir yoldur biz olarak bu toplamalardan korumak veri ekleyin. Temelde, biz verileri yaymak ediyoruz Parlak kova içine o gelir olarak. 

Aralık tuşları Benim, karma izin tuşları eşitlik olması gerekir. Ben karma sorguladığınızda, söylemek zorunda Bana bu eşittir bir karma verin. Ben bir dizi sorguladığınızda, ben Bana bir dizi vermek söyleyebiliriz Bu her türlü kullanımı olduğunu Desteklediğimiz zengin operatör. Bana bir karma için tüm öğeleri verin. O, daha büyük, eşit midir onunla kaçta başlayacak, daha az bu iki değer arasındaki mevcut mu? Aralık sorguları Yani bu tür Biz her zaman ilgi olduğunu. Şimdi veriler hakkında bir şey, ne zaman Eğer veri erişimini bakmak Eğer veri erişim, bu kadar Her zaman bir toplama konusunda. Bu kayıtları hakkında her zaman bu ilişkilidir. Burada bana her şeyi ver tüm bu- Bu kredi kartı işlemleri geçen ay. Bu bir toplanma var. 

Neredeyse her şeyi yapmak Veritabanı toplanmasının bir tür. Tanımlayabilmek Yani varlık mümkün Bu kovalar ve size bu dizi vermek üzerinde sorgulamak mümkün niteliklerini, Bu zengin sorgular, birçok destekleyen birçok, birçok uygulama erişim desenleri. 

Başka bir şey karma anahtarı Yani does it bize bir mekanizma sağlar olduğu etrafında verilerini yaymak mümkün. NoSQL veritabanları en iyi iş zaman verileri eşit olduğunu küme dağılmış. Kaç kişi tanıdık algoritmalar karma ile? Ben karma bir hashing-- deyince Bir karma algoritması, çünkü üretmek edememek bir yoludur herhangi bir değeri rastgele bir değer. Bu özel durumda, bu yüzden Biz koşmak hash algoritması tabanlı ND 5'tir. 

Ve ben bir kimlik var ve bu eğer Benim karma anahtarı, ben 1, 2, 3 var. Ben karma algoritması çalıştırdığınızda, o, geri gel ve söyleyecek kuyu 1, 2 7B eşittir 48 eşittir 3 CD eşittir. Onlar tüm anahtar alan yayılmış ediyoruz. Ve neden bunu yapıyorsun? Emin kılan Çünkü ben can Birden düğümler arasında kayıtlarını koydu. 

Ben yapıyorum, eğer adım adım, 1, 2, 3. Ve ben bir karma aralığı var Bu özel durumda çalışır, Küçük bir karma boşluk, o, 00 ile FF çalışır Daha sonra kayıt gelmek için gidiyoruz ve onlar gitmek için gidiyoruz 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Ne oluyor? Her insert aynı düğüme gidiyor. Ne demek istediğimi görüyor musun? 

Ben uzay böldüğünüzde Çünkü, ve ben, karşısında bu kayıtları yaymak ve ben bölümü, söylemek için gidiyorum bölüm 1 54 anahtar alanı 0 vardır. Partition 2 89 55 olduğunu. Bölme 3 FF AA. Ben artan doğrusal kullanıyorum Yani eğer Kimlikleri, neler olup bittiğini görebilirsiniz. 1, 2, 3, 4, 5, 6, yukarı 54'e tüm yol. Ben çekiç ediyorum Yani sisteme kayıtları, Her şey bir düğüme gidiş biter. 

Bu iyi değil. Bu bir antipattern var. MongoDB onlar bu sorunu Bir karma tuşunu kullanın yoksa. MongoDB size seçenek sunuyor anahtar değerini karma. Her zaman, eğer o yapmalıyım Eğer artan bir karma kullanıyorsanız MongoDB anahtar veya olacağım bir düğüm her yazma çivileme, ve sınırlandırıcı olacaktır kötü senin yazma çıktı. 

HEDEF KİTLE: ondalık o A9 169 mı? 

Rick, Houlihan: Evet, var oralarda etrafında. A9, bilmiyorum. Sen benim ikili almak olurdu ondalık hesap makinesi. Beynim böyle çalışmaz. HEDEF KİTLE: Sadece bir hızlı bir senin Mongo yorumlar. Yani gelen nesne kimliğidir doğal Mongo ile bunu? Rick, Houlihan: o yapar mı? Eğer belirtirseniz. MongoDB ile, seçeneğiniz vardır. Siz her belgeyi specify-- edebilirsiniz MongoDB bir alt kimliği olması gerekiyor. Bu eşsiz bir değerdir. 

MongoDB olarak belirtebilirsiniz Bunu karma edip etmeyeceğine. Onlar sadece sana seçeneği sunar. Bunun olduğunu biliyorsanız rastgele, sorun yok. Bunu yapmak gerekmez. Eğer o, rastgele olmadığını biliyorsanız o artan oluyor, sonra karma yapmak. 

Şimdi bir şey hakkında Eğer karma bir kez, karma Bir value-- ve bu Neden karma anahtarları her zaman Eşsiz sorgular, ben değiştim çünkü değer, şimdi bir aralık sorgusu yapamaz. Ben bu olduğunu söyleyemeyiz şu ya da bu arasındaki müzakere değeri gitmiyor çünkü gerçek değerine denk olduğu. Yani o zaman karma anahtar, sadece eşitlik var. Bu yüzden DynamoDB karma anahtarında ise sorgular hep sadece eşitlik vardır. 

Yani şimdi bir aralıkta key-- O aralık anahtarı eklediğinizde, Bu aralık anahtarı kayıtları tüm gelir ve aynı bölüme saklanan olsun. Yani kolayca, çok hızlı bir şekilde vardır Bu karma çünkü alınan, Bu aralığıdır. Ve her şeyi görmek Aynı karma ile Aynı bölüm alanı depolanır. Siz yardım için bu aralık tuşunu kullanabilirsiniz Onun ailesine yakın verilerinizi bulun. Yani gerçekten burada ne yapıyorum? Bu, pek çok ilişki bir tanesidir. Bir diyez arasındaki ilişki ve aralık tuşu birçok biridir. Birden karma anahtarı olabilir. Ben sadece birden aralığı olabilir Her karma anahtarı içindeki tuşları. 

Karma üst tanımlar, aralık çocukları tanımlar. Gördüğünüz analog burada var ilişkisel yapı arasındaki ve aynı tip NoSQL bölgesindeki oluşturur. İnsanlar hakkında konuşmak Nonrelational olarak NoSQL. Bu nonrelational değil. Veri hep ilişkileri vardır. Bu ilişkiler sadece farklı modellenmiştir. Hadi biraz konuşalım dayanıklılık konusunda biraz. Eğer DynamoDB yazdığınızda, yazar Her zaman üç yönlü çoğaltılır vardır. Biz üç AZ en olması anlamına gelir. AZ adlı Durumu Bölgeleri vardır. Bir Uygunluk düşünebilirsiniz Bir veri merkezi olarak Bölge veri merkezleri veya bir koleksiyon. Bunlar coğrafi olarak birbirlerinden izole Farklı fay zonları boyunca, karşısında elektrik hatları ve havzalarını farklı. Tek AZ bir başarısızlık değil, Başka bir aşağı çekmek için gidiyor. Ayrıca bağlantılıdır Birlikte dark fiber ile. Bu bir alt destekler 1 AZS arasındaki milisaniye gecikme. Yani gerçek zamanlı veri replikasyonu Çok AZS yetenekli. 

Ve çoğu zaman çoklu AZ dağıtımları yüksek kullanılabilirlik gereksinimlerini karşılamak en kurumsal kuruluşların. Böylece DynamoDB yayılır Varsayılan olarak üç AZS arasında. Biz sadece bilgi yazma gidiyoruz Bu üç düğüm iki döndüğümde ve ben bunu aldım, evet, diyorum. Neden? Okuma tarafında Çünkü biz sadece ne zaman size geri veri vereceğim Biz iki düğüm onu ​​olsun. 

Ben genelinde kopyalayan ediyorsam Üç ve ben ikiden okuyorum, Ben her zaman garanti ediyorum En az bir tane Bu olmayı okur Verilerin en güncel kopyası. Bu DynamoDB tutarlı kılan. Şimdi açmak için seçebilirsiniz Bu tutarlı kapalı okur. Bu durumda söylemek için gidiyorum, Ben sadece bir düğümden okuyacağım. Ve ben gidiyor garanti edemez En güncel veriler olması. 

Bir yazma geliyor Yani, o, henüz çoğaltılmış değil O kopyasını almak için gidiyoruz. Bu bir sonuçta tutarlı okuma. Ve ne yarım maliyetidir. Yani bu düşünmek bir şeydir. Ne zaman DynamoDB okuyarak ve konum Eğer okuma kapasitesi kuruyoruz birimler, sonunda seçerseniz Tutarlı, bu çok ucuz, okur yaklaşık yarım maliyeti var. 

Ve böylece size para kazandırır. Ama bu senin seçimin. Eğer tutarlı bir okuma istiyorsanız veya Bir sonunda tutarlı bir okuma. Yani seçebilirsiniz şey. 

En endeksler hakkında konuşalım. Yani biz belirtti üst düzey çekiş. Biz karma anahtarları var ve var Biz aralık tuşları var. Bu güzel. Ve bu, birincil masada olduğunu ben tek karma anahtar var, ben bir aralık anahtar var. 

Bu ne anlama geliyor? Bir özniteliği var ki ben karşı zengin sorguları çalıştırabilirsiniz. Bu aralık anahtarı. Bu item-- diğer nitelikleri Ben bu niteliklerini süzebilirsiniz. Ama ben bunu şeyler gibi yapamaz ile başlayan ya da daha büyüktür. 

Bunu nasıl yaparım? Ben bir dizin oluşturabilirsiniz. İki tür var DynamoDB endeksler. Bir indeks gerçekten Tablonun bir başka görünümü. Ve yerel ikincil indeks. 

Biz bahsedeceğiz ilki. Yani yerel ikinciller bir arada olan veri olarak aynı bölümde. Ve gibi, onlar üzerinde aynı fiziksel düğüm. Onlar bizim tutarlı dediğimiz vardır. Anlamı, onlar kabul edecek tablo ile birlikte yazma. Yazma geldiğinde, Biz endeksi ile yazacağım. Biz masaya yazacağım ve sonra kabul edecektir. Yani tutarlı. Yazma olmuştur kez Tablodan kabul, bu garantili Yerel ikincil indeks Verilerin aynı vizyona sahip olacak. Ama ne onlar izin yapmak olduğunu Alternatif aralık tuşları tanımlamak. 

Aynı karma kullanmak zorunda Birincil tablodaki gibi anahtar, Onlar çünkü üzerinde birlikte yer Aynı bölüm ve onlar tutarlı değil. Ama ben bir dizin oluşturabilirsiniz Farklı aralık tuşları ile. Yani, örneğin, eğer ben bir üretici vardı Bu ham parça tablo geliyor vardı. Ve ham parçalar halinde gelir ve Onlar meclis tarafından toplanan ediyoruz. Ve belki bir hatırlama var. 

Bu tarafından yapılan herhangi bir bölümü Bu tarihten sonra üretici, Benim hattan çekmeniz gerekmektedir. Ben bir dizin spin olabilir Bu, bakıyor olurdu tarihte toplayarak söz konusu parçanın imalatı. Benim üst düzey tablo oldu Yani eğer Zaten üretici tarafından karma, belki ben, bölüm kimliği düzenlenmiştir O masadan bir dizin oluşturabilirsiniz imalatçı tarafından karma olarak ve üretim tarihi değişiyordu. Ve diyorum ki yol, herhangi bir şey Bu tarihler arasında imal edilmiştir, Ben hattan çekmeniz gerekmektedir. Yani yerel bir ikincil dizin var. 

Bu etkiye sahip senin karma anahtar alan sınırlayıcı. Onlar Çünkü birlikte var aynı depolama düğümde, Onlar karma anahtarı sınırı 10 gigabayt yer. DynamoDB altında tablolar, bölüm olacak Tablonuzu her 10 gigabayt. Veri 10 konser koymak, biz [PHH] gitmek ve biz başka bir düğüm ekleyin. 

Sizlere LSI bölünmüş olmaz birden fazla bölüme karşısında. Biz tabloyu bölünmüş olacak. Ama biz LSI bölünmüş olmaz. Bu yüzden bir şey anlamak önemlidir Çok yapıyoruz olduğunu, çok büyük toplamalar, o zaman sınırlı gidiyoruz senin LSIS 10 gigabayt. 

Bu durumda, biz Global Sekonder kullanın. Küresel ikinciller vardır Gerçekten başka bir tablo. Onlar için kapalı tamamen mevcut Birincil tablonun yan. Ve onlar beni bulmak için izin tamamen farklı bir yapı. Veri eklenir ediliyor Yani düşün İki farklı tabloya, yapılandırılmış iki farklı şekilde. 

Bir tamamen tanımlayabilir farklı hash tuşuna basın. Bir tamamen tanımlayabilir Farklı aralık tuşuna basın. Ve ben bu çalıştırabilirsiniz Tamamen bağımsız. Nitekim olarak, ben ettik Benim okuma kapasitesi provisioned ve kapasitesini yazmak benim Küresel ikincil indeksler Tamamen bağımsız olarak benim birincil tablonun. O indeksi tanımlarsanız, anlarım ne kadar okuma ve yazma kapasite kullanarak gidiyor. 

Ve bu ayrı benim birincil tablodan. Şimdi dizinler hem bize izin sadece, karma ve aralık tuşları tanımlamak ama onlar için bize izin ek değerler proje. Ben endeksi kapalı okumak istiyorsanız, ve ben bazı verilerin set almak istiyorum, Ben ana geri dönmek gerek yok tablo ek özellikleri elde etmek. Ben bu ek proje olabilir tabloya niteliklerini erişim deseni desteklemek. Ben muhtemelen bazı içine alıyoruz biliyorum Gerçekten, otların içine almak gerçekten-- Burada bu bazı şeyler üzerinde. Şimdi bu dışarı kayması lazım. 

HEDEF KİTLE: [duyulamaz] --table anahtar bir karma olduğu anlamına geliyordu? Orijinal karma? Çoklu kaburgalar? 

Rick, Houlihan: Evet. Evet. Masa anahtarı temelde geri öğeye işaret eder. Yani bir dizin bir işaretçi için geri masaya orijinal öğeler. Şimdi bir inşa seçebilirsiniz yalnızca tablo anahtar vardır endeksi, ve başka hiçbir özellikleri. Ve ben bu yüzden yapabilirim? Eh, belki çok büyük ürün yok. 

Ben gerçekten sadece bilmeniz gereken hususların Benim erişim deseni, diyebilirsiniz hangi öğelerin bu özelliğini içeren? Öğeyi döndürmek gerek yok. Sadece bilmek istiyorum hangi öğelerin bunu içerir. Yani dizinler oluşturabilirsiniz tek tablo anahtarı var. 

Ama bu öncelikle ne var veritabanında bir göstergesi olduğunu. Hızla için güçlü olmak için var kaydeder hangi tanımlamak hangi satırların, hangi Tablodaki öğeler var Arıyorum özellikleri. 

GSIS, bu yüzden nasıl çalışır? GSIS temelde asenkron bulunmaktadır. Güncelleştirme tabloya geliyor, tablo daha sonra zaman uyumsuz güncellenir senin GSIS hepsi. GSIS neden budur sonunda tutarlı. 

Bu dikkat etmek önemlidir ne zaman GSIS bina konum, ve sen oluştururken anlıyorum aggregation-- başka boyutu Şimdi en iyi bir örnek diyelim Burada bir üreticisidir. Ben hakkında konuştuk olabileceğini düşünüyorum Bir tıbbi cihaz üreticisi. Tıbbi cihaz üreticileri çoğu zaman tefrika parçalar var. Gitmek parçaları Bir kalça protezi tüm Onlara biraz seri numarası var. Ve onlar milyonlarca verebilir ve milyonlarca parça milyarlarca Onlar gemi tüm cihazlarda. Eh, onlar altında toplamak gerekir Farklı boyutlar, tüm parçaları Bir montajda, tüm yapılan parça Belirli bir hat üzerinde, tüm geldi parçalar Belirli bir üretici dan belirli bir tarihte. Bazen bu toplamlar Milyarlarca içine kalk. 

Yani bazı çalışmak acı bu adamlar onlar oluştururken çünkü Bu ginormous toplamalardan ikincil endeksler. Onlar ham parçalar olabilir Sadece karma olarak geliyor tablo. Her bölüm benzersiz bir seri numarası vardır. Ben karma olarak seri numarasını kullanabilirsiniz. Bu güzel. Benim ham veri tablosu yayılır tüm kilit alan üzerinde. Benim [? mal?] [? yutma?] müthiş. Ben çok fazla veri almak. Sonra ne onlar bir GSI oluşturmak olduğunu. Ve ben görmeliyim, ne biliyorsun, demek Bu üreticiler tüm parçalar. Peki, aniden ben Bir milyar satır alarak, ve üzerine onları şeyler Bir düğüm, çünkü ne zaman Ben agrega karma olarak üretici kimliği, ve aralık olarak parça numarası, Sonra ben aniden içine milyar parça koyarak neyi Bu üretici beni teslim etti. 

Bu bir sürü neden olabilir GSI üzerinde baskı, Yine, ben tek düğüm çekiçleme ediyorum çünkü. Ben bütün bu atıyorum bir düğüm haline ekler. Ve bu gerçek sorunlu kullanım durumunda bulunuyor. Şimdi, ben iyi bir tasarım var Bunun önlemek için nasıl model. Ve bu sorunlardan biri Hep çalışmak söyledi. Ne Fakat, GSI olabilir olduğu Yeterli yazma kapasiteye sahip değildir Tüm bu itmek mümkün olduğu tek bir düğüm haline satırları. Ve sonra ne olur ise Birincil müşteri tablosu, birincil tablo throttled olacak GSI kadar devam edemez, çünkü. Yani benim insert oranı olacak Birincil masaya düşmek Benim GSI yetişmek için çalışır gibi. 

Pekala, LSI kıyafetleri, GSI o kadar, Ben hangisinin kullanmalıyım? LSI en tutarlıdır. GSI en sonunda tutarlıdır. Bu Tamam, ben bir kullanmanızı tavsiye GSI, onlar çok daha esnek konum. LSI en bir GSI olarak modellenebilir. Ve eğer karma tuşları başına veri boyutu toplama 10 gigabayt aşıyor, sonra o kullanmak istiyorum gidiyoruz GSI sadece zor bir sınırı var çünkü. 

Pekala, ölçekleme. Dynamo DB Verim, sen can karşılığı [duyulamaz] Bir tabloya throughput. Biz müşterilerimiz vardır provisioned 60 billion-- Düzenli, 60 milyar isteklerini yapıyor bir milyondan fazla istekleri çalışan Bizim masalarda saniyede. Hayır gerçekten var teorik sınırı ne kadar ve ne kadar hızlı tablo Dynamo DB çalıştırabilirsiniz. Bazı yumuşak vardır Hesabınızdaki sınırları böylece oraya koymak Bu deli gitmez. Eğer daha fazla isterseniz Bu, bir sorun değil. Sen bize gel. Biz çevirmeli döneceğiz. 

Her hesabın bir seviyede sınırlıdır Her hizmet, sadece yarasa böylece insanlar deli gitmez belaya kendilerini olsun. Boyutunda sınırı yok. Herhangi bir sayı koyabilirsiniz Bir masaya öğeleri. Bir öğenin boyutu 400 kilobayt Her sınırlı Bu öğe değil nitelikler olacaktır. Tüm niteliklerin toplamı So 400 kilobayt sınırlıdır. Ve sonra tekrar, biz o küçük LSI sorunu karma başına 10 gigabyte limitli. HEDEF KİTLE: Az sayıda, ben eksik ne o, bana söylüyorsun o-- HEDEF KİTLE: Oh, 400 kilobayt öğe başına maksimum boyutudur. Yani bir öğe tüm özelliklere sahiptir. Yani 400 k toplam boyutu Bu öğenin, 400 kilobayt. Tüm niteliklerin Yani Birleştirilen tüm veri tüm bu nitelikleri de var, toplam büyüklüğü içine yuvarlandı Şu anda, bugün kalemi sınırı 400 k. Yani elde yine ölçekleme Bölmeli. Üretilen sağlanmışsa tablo düzeyinde. Ve gerçekten iki düğme var. Biz kapasite okudum ve kapasite yazın. 

Peki bu ayarlanır birbirinden bağımsız olarak. Kumandanın en tedbir kesinlikle tutarlı okur. Tamam, bu yüzden eğer ben 1,000 istiyorum söylüyorsun UKÜ en olanlar kesinlikle tutarlı Bu tutarlı bir okuma bulunmaktadır. Eğer istediğim derseniz Tutarlı nihai okur Eğer hüküm 1000 can UKÜ kıyafetleri, sen gidiyorsun Sonunda 2,000 almak için tutarlıdır okur. Ve olanlar için yarı fiyatına Sonunda okur oluşur. 

Yine ayarlanmış birbirinden bağımsız olarak. Ve onlar throughput-- var Eğer Kumandanın% 100 tüketmek ise, Eğer darbe gitmiyorsun Haklarınız durumu. Yani tamamen birbirinden bağımsız olarak gerçekleştirilir. Pekâlâ, şeylerden biri olduğunu Ben kısaca kısıcı oldu bahsettiniz. Bastırma kötü. Bastırma hiçbir SQL kötü olduğunu gösterir. Biz yardım etmek için yapabileceğiniz şeyler vardır Eğer azaltmayı hafifletmek olduğunu yaşıyoruz. Ama en iyi çözüm Buna en atalım olduğunu Bir nedeni, ne yaptığınızı bakmak Burada oyunda bir anti-desen var. 

Bunlar, sigara üniforma gibi şeyler iş yükü, sıcak tuşları, sıcak bölümleri. Belirli bir anahtar alan vuruyorum çok sert belirli bazı nedenden dolayı. Neden yapıyorum? En anlamaya edelim. Ben soğuk verilerle benim sıcak verileri karıştırma ediyorum. Benim tabloları almak izin veriyorum büyük, ama orada gerçekten verilerin sadece bir alt grubunu Bu benim için gerçekten ilginç. Böylece log verileri, örneğin, bir çok Müşteriler, her gün veri giriş olsun. Bunlar günlük veri büyük miktarda var. 

Sadece tüm bu günlük damping ediyorsanız Zamanla büyük bir tabloya veri Bu tablo masif almak için gidiyor. Ama ben gerçekten sadece ilgileniyorum Son 24 saat son yedi gün, son 30 gün. Zaman ne olursa olsun pencere Ben arıyorum ilgileniyorum o beni rahatsız ediyor, ya da etkinlik için Benim için ilginç olay, ben gereken tek pencere zamanı. Peki neden 10 yıl koyarak yaşıyorum Tablodaki günlük verilerini değerinde? Bunun sebebi nedir olduğu Tablo fragmanı. 

Çok büyük olur. Dışarı yayılan başlar binlerce düğüm arasında. Ve kapasite beri sen, bu kadar düşük aslında her sınırlaması oranı bu bireysel düğümlerden biri. Yani nasıl bakıyor başlayalım biz üzerinden bu tabloyu rulo yapın. Biz bu verileri biraz yönetmek nasıl Daha iyi bu sorunları önlemek için. Peki bu neye benziyor? Bu durum böyle görünüyor. Bu kötü NoSQL neye benzediğini olduğunu. 

Burada sıcak bir anahtar var. Burada tarafında bakarsak, bunların hepsi benim bölümlerdir. Burada 16 bölüm kalktı Bu özel veritabanı üzerinde. Biz bunu hep yapar. Ben müşteriler için her zaman bu çalıştırın. Bu ısı haritası denir. Isı haritası sen nasıl söyler anahtar alan erişen. Peki bu bana olduğunu belirli bir karma var ki bu adam bir seviyor çok korkunç, o çünkü gerçekten zor, gerçekten isabet. 

Yani mavi güzel. Biz mavi gibi. Biz kırmızı sevmiyorum. Red'in burada basınç % 100'e kadar alır. % 100, şimdi bastırma için gidiyoruz. Yani gibi herhangi bir kırmızı çizgiler gördüğünüzde bu-- ve sadece Dynamo DB-- değil Her NoSQL veritabanı, bu sorunu var. Anti-desenler o can vardır Bu tür koşullar sürücü. Ne yapmam ben müşterileri ile çalışmak olduğunu Bu koşulları azaltmak için. 

Peki bu neye benziyor? Ve bu en oluyor Dynamo DB hacmi dışında, ama gerçekten gidiyor NoSQL en iyi şekilde. Bu Dinamo ile sınırlı değildir. Bu definitely-- I Mongo çalışmak için kullanılır. Birçok NoSQL platformları aşina değilim. Her biri bu tür var kısayol tuşu sorunlar. Herhangi bir NoSQL en iyi şekilde almak için veri tabanı, özel olarak Dinamo DB Eğer tablo oluşturmak istiyorum nerede hash unsurdur vardır farklı değerler çok sayıda, cardinality yüksek derecede. Ben yazıyorum anlamına gelir, çünkü Farklı kovalar sürü. 

Ben daha fazla kovalar , daha büyük olasılıkla yazma O yazma yükü yaymak için ben veya Birden düğümler genelinde yük okumak, daha muhtemel Ben sahip değilim masaya yüksek verimlilik. Ve sonra değerleri olmak istiyorum zamanla oldukça eşit istenen ve düzgün şekilde rastgele mümkün olduğunca. Peki, bu, bir tür ilginç çünkü ben yapamam gerçekten Kontrol kullanıcılar geldiğinde. Biz yayıldı Yani, eğer söylemek yeterli anahtar alanı genelinde şeyler dışında, biz muhtemelen daha iyi şekil olacak. 

Belirli bir var zamanında teslimat miktarı Eğer gitmiyorsun muktedir kontrolünü olmak. Ama o gerçekten biz iki boyut, uzay, erişim eşit yayılması, zaman, istekler eşit zaman aralıklı gelmeden. Ve bu iki eğer şartlar yerine ediliyor, Sonra işte bu ne benzeyecek. Bu çok güzel. Biz burada gerçekten çok mutluyuz. Biz çok bile erişim deseni var. Evet, belki alıyoruz bir küçük basınç şimdi ve sonra her, ama hiçbir şey gerçekten çok geniş. Yani, kaç kez şaşırtıcı Ben müşterileri ile çalışırken, Büyük kırmızı ilk grafik bar ve tüm o sarı değil çirkin biryere, biz egzersiz ile halletmek Birkaç ay sonra Yeniden mimari, onlar tam olarak aynı koşuyoruz aynı yükte iş yükü. Ve bu artık böyle bakıyor ne olduğunu. Peki ne NoSQL ile olsun bir Kesinlikle bir veri şeması erişim desen bağladılar. 

Ve o veri şemasını optimize edebilirsiniz Bu erişim deseni desteklemek. Bunu yapmazsanız, o zaman gidiyoruz sorunların bu tip görmek için Bu kısayol tuşları ile. 

HEDEF KİTLE: Peki, kaçınılmaz olarak bazı yerlerde diğerlerinden daha sıcak olacak. 

Rick, Houlihan: Her zaman. Her zaman. Evet, ben her zaman var demek bir-- ve yine orada bazı tasarım desenleri biz aracılığıyla alırsınız Bu sizin nasıl başa bahsedeceğiz Bu süper geniş toplamalarla. Yani, onları olması lazım Onlarla nasıl başa çıkıyorsunuz? Ben oldukça iyi bir kullanım vaka var Bunun için söz edeceğiz. 

Pekala, diyelim tartışma Şimdi ilgili bazı müşteriler. Bu adamlar AdRoll vardır. Sen eğer ben bilmiyorum AdRoll aşina. Muhtemelen onları görmek tarayıcı üzerinde bir sürü. Onlar değil, reklam yeniden hedefleme konum en büyük reklam yeniden hedefleme iş dışarıda. Normalde düzenli üzerinde çalıştırmak Günde 60 milyar işlemler. Onlar milyon üzerinde yapıyoruz Saniyede işlemler. Onlar oldukça basit bir tablo var yapı, işlek bir tablo. Bu temelde bir Kare tuşuna, cookie aralık demografik kategori ve daha sonra Üçüncü nitelik puanı. 

Bu yüzden tüm çerezleri Bu adamlar bizim tarayıcı. Ve sen gittiğinde tüccar katılan onlar temelde karşısında sizi puanı çeşitli demografik kategoriler. Bir web sitesine gittiğinizde ve Eğer ben bu ad-- görmek istiyorum demek veya temelde ki- söyleme ancak web sitesine gittiğinizde onlar bu reklamı görmek istediklerini söylüyorlar. Ve onlar AdRoll o reklamı getir. AdRoll onların masada seni arar. Onlar çerez bulabilirsiniz. Söylüyorum reklamverenler Onları, ben birini istiyorum Kim, orta yaşlı var Spor içine 40 yaşındaki adam,. Ve onlar bu demografik sizi puanı ve olup olmadığına karar Bu sizin için iyi bir reklam var. 

Şimdi bir SLA ile var onların reklam sağlayıcıları alt 10 milisaniye sağlamak için her istek üzerine tepki. Yani bunun için Dynamo DB kullanıyoruz. Bizi bir isabet ediyoruz saniyede milyon istekleri. Onlar her şeyi mümkün olacaktır onların aramaları, triyaj, tüm bu verileri, ve geri o eklenti link almak 10 milisaniye altında İlan. Gerçekten oldukça olağanüstü bulunuyor Uygulama sahip oldukları. 

Bu adamlar actually-- adamlar bunlar. Ben bu adamları ise emin değilim. Bu adamlar olabilir. Temelde, hayır us-- anlattı Onları olduğunu sanmıyorum. Ben başkası olduğunu düşünüyorum. Ben birlikte çalıştığım Müşteri bana söyledi şimdi onlar var olduğu Dynamo DB gitti, onlar aperatifler daha fazla para harcama Onların geliştirme ekibi her ay onların veritabanında harcama daha. Bu yüzden size vereceğim maliyet tasarrufu fikri Eğer Dinamo DB alabilirsiniz büyük. Pekala, dropcam başka bir şirket var. Bu adam tür of-- sizce eğer var şeylerin internet dropcam ve temelde internet güvenlik video. Orada kameranızı söndürüldü. Kamera bir hareket detektörü bulunmaktadır. Birisi birlikte geliyor Bir işaret noktasını tetikler. Kamera bir süre kadar için kayda başlar artık herhangi bir hareketi algılamaz. Internet üzerinde bu videoyu koyar. 

Dropcam bir şirket oldu temelde Dynamo DB geçti onlar yaşıyor çünkü muazzam büyüme sancıları. Ve onlar bize söylediklerini, anda veri petabayt. Onlar hiçbir fikri onların hizmet vardı kadar başarılı olacaktır. YouTube daha gelen bir video bu adamlar alıyorsanız budur. Hepsi izlemek için DynamoDB kullanın tüm Video kilit noktaları üzerinde meta. 

Yani onlar itmek S3 kovalar var tüm ikili eserler içine. Ve sonra sahip oldukları Dynamo DB kayıtları olduğunu Bu S3 üç nesnelere insanları etmektedir. Onlar bir video bakmak gerektiğinde, Onlar Dinamo DB kaydını aramak. Onlar bağlantısını tıklayın. Onlar S3 video aşağı çekin. Yani bu neye benzediğini tür. Ve bu onların takımdan düzdür. 

Dynamo DB onların azaltır Video olaylar için teslimat süresi beş ila 10 saniye arasında. Eski ilişkisel mağazasında, gittikleri ve yürütmek için kullanılan şekle birden karmaşık sorgular hangi videolar, aşağı çekmek için 50'den az milisaniye. Bu yüzden şaşırtıcı, şaşırtıcı Ne kadar performans optimize zaman alabilir ve size ayar altında yatan veritabanı erişim deseni desteklemek. Bunu ne Halfbrick, bu adamlar, Sanırım Fruit Ninja onların şeydir. Dynamo DB tüm çalışır That. Ve bu adamlar, onlar büyük geliştirme ekibi, büyük bir gelişme dükkan. 

Değil iyi ops ekip. Onlar çok yoktu operasyon kaynaklarının. Onlar tutmaya çalışıyorum mücadele vardı uygulama altyapısı yukarı ve koşuyor. Onlar bize geldi. Onlar Dinamo DB baktı. Onlar bizim için olduğunu söyledi. Onlar kendi bütün yerleşik Bunun üzerine uygulama çerçevesi. Burada bazı gerçekten güzel yorumlar yeteneklerine ekibinden Şimdi bina odaklanmak Oyun ve korumak zorunda alt yapı, burada çok büyük miktarda haline geldi kendi takımı için havai. Yani bu şey ki- Eğer Dinamo DB olsun yararlanır. 

Pekala, içine almak Burada veri modelleme. Ve biz hakkında biraz konuştuk bir bu, bir çok, bir, ve birçok türü ilişkileri çok. Ve nasıl Dynamo bu bakımını yapmak. Dynamo DB biz kullanmak indeksler, genel anlamda, veri döndürmek için diğer bir lezzet. Hash tuşları, aralık tuşları ve indeksler. 

Bu özellikle örnek çoğu devletler olarak Bir lisans şartı var kişi başına sadece bir ehliyet. İki sürücü almak için gidemem Boston eyaletinde lisanslar. Ben Teksas'ta bunu yapamam. Yani o şekilde türüdür. Ve böylece DMV'de, biz aramaları var, biz ehliyet bakmak istiyorum sosyal güvenlik numarası ile. Ben kullanıcı bilgilerini bakmak istiyorum ehliyet sayısına göre. 

Yani biz bir kullanıcının tabloya sahip olabilir Seri numarasına bir karma anahtarı vardır, veya sosyal güvenlik numarası ve Çeşitli özellikleri öğe üzerinde tanımlı. Şimdi bu tablo I Bir GSI tanımlayabilir ki diyor etrafında ben istiyorum döndürür Daha sonra lisans ve bir karma anahtarı tüm diğer öğeler. Şimdi sorgulamak ve bulmak istiyorsanız Herhangi bir Sosyal lisans numarası Güvenlik numarası, I can Ana tablosunu sorgulamak. 

Ben sorgulamak istiyorum ve ben isterseniz sosyal güvenlik almak için numara veya diğer özellikleri Lisans numarası, ben GSI sorgulayabilirsiniz. Bu model, bir tanesidir tek ilişki için. Sadece çok basit bir GSI, etrafınızdaki şeyleri çevirin. Şimdi, birçok yaklaşık bir konuşun. Birçok için bir temelde senin karma aralığı tuşuna basın. Biz bu çok olsun nerede kullanma durumu monitör veridir. Monitör verileri düzenli gelir şeylerin internet gibi aralık. Biz her zaman tüm bu olsun kayıtları her zaman geliyor. 

Ve ben tüm okumaları bulmak istiyorum Belirli bir zaman diliminde arasında. Bu çok yaygın bir sorgu var izleme altyapısı. Bu konuda yol gitmek bir bulmaktır basit bir tablo yapısı, bir tablo. Ben bir aygıt ölçümleri tablo var Cihaz numarası karma tuşu ile. Ve ben bir aralık anahtarı var zaman damgası, ya da bu durumda, destan. Ve bu beni kompleksi yürütmek sağlar Bu aralık tuşu karşı sorguları ve bu kayıtların dönmek Sonuç göredir Ben arıyorum olduğunu ayarlayın. Ve o bir inşa birçok ilişki kullanarak birincil tabloya Kare tuşuna, aralık tuş yapısı. 

Yani bu tür inşa edilmiştir Dynamo DB tabloya. Ben karma tanımladığınızda ve aralık t tablosu, ben birçok ilişki bir tane tanımlayan. Bir ebeveyn-çocuk ilişkisinin var. 

Birçok bahsedelim Birçok ilişkileri. Bu, özellikle, örneğin, Yine, biz GSI en kullanmak için gidiyoruz. Ve en oyun hakkında konuşalım Ben belirli bir kullanıcı var senaryo. Ben tüm oyunları öğrenmek istiyorum O veya oynarken kayıtlı. Ve belirli bir oyun için, I Tüm kullanıcıları bulmak istiyorum. Peki nasıl böyle yaparsın? Benim kullanıcılı oyunlar tablo, ben gidiyorum kullanıcı kimliğinin bir karma anahtarı var ve oyunun bir dizi anahtar. 

Yani, bir kullanıcı birden fazla oyun olabilir. Bu arasında birçok ilişki bir biri Kullanıcı ve oynadığı oyunlar. Sonra ve patolojik düzeyde, O etrafta kapak olacak. Ben oyuna karma olacak ve Ben kullanıcı aralığı olacak. Ben hepsini almak istiyorsanız Yani Oyun kullanıcının, oynarken Ben ana tablosunu sorgulamak gerekir. Ben tüm kullanıcıları almak istiyorsanız Bu, belirli bir oyun oynuyorlar, Ben GSI sorgulamak. Yani biz bunu nasıl? Bu GSI en desteklemek için inşa kullanma durumu, uygulama, erişim desen, uygulaması. 

Ben sorgulamak gerekiyorsa Bu boyut, let bana o boyutta bir dizin oluşturun. Ben yapmazsam, umurumda değil. Ve kullanım durumunda bağlı, ben endeksi gerek ya da ben olmayabilir olabilir. Basit bir tek birçok varsa, birincil tablo gayet iyi. Ben bu pek yapmanız gerekiyorsa Birçok kıyafetleri, ya da ben, olanları birini yapmanız gerekir o zaman belki ihtiyacım var İkinci endeksi. Yani hepsi bağlıdır ne yapmaya çalışıyorum ve ben başarılı olsun ne çalışıyorum. 

Muhtemelen ben de geçirmek için gitmiyorum çok zaman belgeler bahsediyoruz. Bu, muhtemelen, biraz alır derine biz gitmek gerekir daha. En biraz konuşalım hakkında zengin sorgu ifadesi. Yani Dinamo DB biz oluşturma yeteneği Biz projeksiyon ifadelerini dediğimiz. Projeksiyon ifadeleri sade alanları veya değerleri toplama Görüntülemek istediğiniz söyledi. Tamam, bu yüzden bir seçim yapın. Ben Dinamo DB karşı bir sorgu yapmak. Ve ben, gösteri ne biliyorsun, demek bana sadece beş yıldızlı yorumu Bu belirli bir ürün için. Yani ben görmek istiyorum hepsi bu. Ben görmek istemiyorum sıranın diğer özellikler, Ben sadece bu görmek istiyorum. Bu sadece zaman SQL gibi sen select yıldız ya da masadan demek, Eğer her şeyi olsun. Ben seçin isim deyince masa, ben sadece bir özniteliği olsun. Bu şey aynı tür içinde var Dynamo DB veya başka bir NoSQL veritabanları. Filtre ifadeleri için bana izin temelde aşağı ayarlamak sonuç kesti. Yani bir sorgu yapmak. Sorgu 500 öğelerle geri gelebilir. Ama ben sadece öğeleri istediğiniz Bu diyor bir nitelik var. Tamam, bu yüzden bu öğeleri filtrelemek izin o belirli sorgu eşleşmiyor. Bu yüzden filtre ifadeleri var. 

Filtre ifadeleri can Herhangi bir niteliğin üzerinde çalıştırılabilir. Onlar aralık sorguları gibi değiliz. Raise sorguları daha seçici. Filtre sorguları gitmemi gerektiren tüm sonuçlar daha sonra set ve get Ben istemiyorum verileri ayırırlar. Neden önemli? Ben hepsini okudum çünkü. Bir sorguda, ben okuyacağım ve bu verilerle ilgili bir dev olacak. Ve sonra ben gidiyorum Ben ne gerek ayırırlar. Ve ben sadece dışarı oyma ediyorsam bir satır çift, o tamam. O kadar verimsiz değil. 

Ama bir bütün kazık okuyorum eğer Veri, sadece bir öğe ayırırlar o zaman daha iyi olacağım Bir aralık sorgusu kullanarak kapalı, çok daha seçici çünkü. Bana bir sürü kaydetmek için gidiyor para, o okuma için ödeme çünkü. Nerede geri geliyor sonuçları küçük olabileceği tel çapraz ama ben okumak için ödüyorum. Peki nasıl anlamak Veri alıyoruz. Yani Dinamo DB çok önemli. 

Koşullu ifadeler, bu ne olduğu Eğer iyimser kilitleme diyebilirsiniz. Güncelleme IF EXISTS veya bu değerin ise Ben belirtmek ne eşdeğerdir. Ve ben bir bir zaman damgası varsa kayıt, ben verileri okuyabilir. Ben bu verileri değişebilir. Ben yazma gitmek olabilir veritabanına verileri geri. Biri rekor değişti ise, Zaman damgası değiştirmiş olabilir. Ve bu şekilde, benim koşullu Güncelleştirmenin söyleyebiliriz timestamp bu eşitse. Veya güncelleştirme biri çünkü başarısız olur Bu arada rekor güncellendi. 

İşte biz iyimser kilitleme diyoruz. O birileri gelir gelir ve değiştirebilirsiniz, ve ben bunu tespit etmek gidiyorum Ben ne zaman geri gitmek yazmak için. Ve sonra aslında okuyabilirsiniz Veri ve oh, o bu değişti söylüyorlar. Bunun hesabını gerekir. Ve ben verileri değiştirebilirim benim kayıt ve diğer güncelleştirmeyi uygulayın. Yani bu artan yakalayabilirsiniz zaman arasında meydana güncellemeler veri ve okumak zaman veri yazma olabilir. 

HEDEF KİTLE: Ve filtre ifadesi aslında anlamına gelir sayı veya değil-- bölgesindeki 

[SESLER interposing] Rick, Houlihan: Ben olmaz Bu içine çok fazla olsun. Bu ayrılmış bir anahtar var. Kiloluk görünümü saklıdır Dynamo DB kelime. Her veritabanı vardır kendi saklıdır Eğer kullanamazsınız koleksiyonları isimler. Dinamo DB, belirttiğiniz takdirde Bu önünde bir kiloluk, Yukarıdaki o isimleri tanımlayabilirsiniz. Bu başvurulan bir değerdir. Muhtemelen en iyi sözdizimi değil Bu tartışma için orada var, bazı real-- içine alır çünkü Ben konuşurken olurdu daha daha derin bir düzeyde bu konuda. 

Ama söylemek yeterli, bu olabilir Onlar views-- nerede tarama sorgusu olacak ne kiloluk views 10 daha büyüktür. Evet, bir sayısal değerdir. İsterseniz, biz hakkında konuşabilirsiniz tartışma bundan sonra. Pekala, biz içine alıyoruz en iyi uygulamaları bazı senaryolar nereye konuşacağız Burada bazı uygulamalar hakkında. Dynamo DB için kullanım durumları nelerdir. Tasarım nelerdir Dynamo DB desenleri. 

Ve ilk biz gidiyoruz hakkında konuşmak şeyler internet. Sanırım of-- Yani biz bir sürü almak, dökersin--% 50'den fazla ne Bugünlerde internette trafik Aslında makineler tarafından oluşturulan, değil insanlar tarafından otomatik süreçler. Ben bu şeyi bu şey demek Eğer cebinizde taşımak ne kadar veri bu şey olduğunu Aslında sensiz etrafında gönderme Bunu bilerek kesinlikle şaşırtıcı. Bulunduğunuz yer, bilgi ne kadar hızlı hakkında gidiyorsun. Google Maps işleri sizce nasıl onlar size zaman trafik nedir. Milyonlarca vardır çünkü var ve etrafında sürüş milyonlarca insan gönderiyor telefonlar ile tüm zaman biryere verileri. Şeylerden biri So Verilerin bu tür hakkında O geliyor, monitör verileri, günlük veri zaman serisi verileri, bu kadar olduğunu genellikle sadece ilginç zaman biraz için. Bu süreden sonra, bu kadar çok ilginç değil. Bu yüzden izin vermeyin, hakkında konuştuk Bu tablo sınırları olmadan büyür. Buradaki fikir belki 24 var olduğunu benim sıcak tablodaki olayların değerinde saat. Ve bu sıcak tablo olacak çok yüksek oranda sağlanan, bu çok fazla veri alıyor çünkü. Bu çok fazla veri alıyor ve ben onu çok okuyorum. Ben operasyonun bir sürü var Bu veri karşı çalışan sorguları. 

24 saat sonra hey, Umrumda değil, ne biliyorsun. Yani belki her gece yarısı ben rulo Yeni tabloya üzerinde benim tablo ve ben bu tabloyu deprovision. Ve ben alacağım RCU en ve WCU aşağı nedeniyle 24 saat sonra Ben birçok kaçmıyorum Bu veri karşı sorguları. Yani para kazanmak için gidiyorum. Ve belki 30 gün sonra I do not Hatta hepsi umurumda gerekir. Ben WCU adlı sürebilir biri aşağı tüm yol, Bildiğiniz çünkü ne asla yazılı almak için gidiyor. Veri 30 gün eskidir. Bu asla değişmez. 

Ve bu, okuma alacaksın neredeyse hiç bu yüzden sadece 10 aşağı o RCU alalım. Ve ben bu para bir ton tasarruf ediyorum Veri ve sadece benim sıcak veriler için ödeme. Yani bakmak önemli şey Bir zaman serisinin baktığınızda at veri hacmi geliyor. Bu stratejiler vardır. Şimdi, ben sadece bunu izin verebilir hepsi aynı masaya gitmek ve sadece bu tablo büyümesine izin verin. Sonunda, ben gidiyorum performans sorunları görüyoruz. Ben arşive başlamak zorunda gidiyorum masadan o bazı verilerin, etajer. 

En çok daha iyi Let Başvurunuzu tasarım bu yüzden doğru bu şekilde çalışabilir söyledi. Yani sadece otomatik var Uygulama kodu. Gece yarısı her gece bu tablo yuvarlanıyor. Belki de ne ihtiyacım sürgülü olduğunu Verilerin 24 saat penceresi. Daha sonra düzenli bir şekilde ben masadan verileri çağırıyor. Ben onu buduyorum Cron iş ve ben bunu atıyorum bu tablolar üzerine, ihtiyacınız ne olursa olsun. Bir rollover çalışır Yani, bu harika. Değilse, bunu düzeltin. Ama bu sıcak verileri kalsın uzakta, soğuk veri. Size çok para tasarruf edeceğiz ve senin masalar daha başarımlı olun. Yani bir sonraki şey konuşacağım yaklaşık ürün kataloğu olduğunu. Ürün katalog oldukça yaygın kullanım durumunda. Bu aslında çok yaygın bir desen şeylerin çeşitli görürsünüz. Sizin için, Twitter biliyorum örneğin sıcak bir tweet. Herkes geliyor ve Bu tweet kapma. Ürün katalogu, ben bir satış var. Ben bir sıcak satış var. Ben başına 70.000 isteklerini var İkinci bir ürün için gelen Benim ürün kataloğu dışarı açıklaması. Biz perakende görmek operasyon biraz. Peki bununla nasıl başa çıkıyorsunuz? Bununla başa çıkmak için hiçbir yolu yoktur. Bütün kullanıcılar görmek istiyorum aynı veri parçası. Bunlar aynı zamanda, geliyor ediyoruz. Ve hepsi isteklerini yapıyoruz aynı veri parçası için. Bu beni verdiği kısayol tuşu, o büyük kırmızı Biz sevmiyorum benim grafik şerit. Ve o neye benzediğini var. Benim anahtar alan üzerinde ben alıyorum Yani satış kalemlerinde dövülmüş. Ben başka bir yerde bir şey alıyorum. 

Nasıl bu sorunu hafifletmek mı? Peki, biz önbelleğe sahip bu hafifletmek. Önbellek, sen bellek temelde bir koydu veritabanında önünde bölümü. Biz başardık [Duyulamaz] önbellek, nasıl Kendi önbellek kurabilirsiniz, [inaudible] cache [? d?] istersen. Veritabanında önünde o kadar koyun. Ve bu şekilde bu verileri saklayabilirsiniz Bu önbellek kadar bu sıcak tuşları Uzay ve önbellek okudum. 

Ve sonra çoğu sizin okur Böyle aramaya başlamak. Ben bu önbellek buraya kadar vurur var ve ben hiçbir şey aşağı burada gidiş var Veritabanı arkasında oturan çünkü önbellek ve içinden asla okur. Ben verileri değiştirirseniz Veritabanı, ben önbellek güncellemek zorunda. Biz bir şey kullanabilirsiniz gibi bunu buharlısı. Ve ben o nasıl çalıştığını anlatacağım. Pekala, mesajlaşma. E-posta, hepimiz e-posta kullanıyoruz. 

Bu oldukça iyi bir örnektir. Biz mesajlar tablonun çeşit var. Ve biz gelen kutusu ve giden kutusunu aldım. Bu nedir, SQL olur ise Bu gelen kutusu inşa etmek gibi görünüyorsun. Biz tür aynı tür kullanın GSI adlı GSI adlı kullanmak için strateji Gelen kutuma ve benim outbox için. Yani ham mesajlar geliyor got Benim mesajlar tabloya. Ve bu ilk yaklaşım olabilir, tamam, sorun yok, diyorum. Ben çiğ mesajlar var. Önümüzdeki Mesajlar [duyulamaz], mesajı kimliği, bu harika. O benim eşsiz hash. Ben, iki GSI en oluşturmak için bir gidiyorum Gelen kutuma benim outbox için biri için. Ve ilk şey yapacağım Benim karma anahtarı söyleyeceğim olduğunu Alıcı olacak ve Ben tarih düzenlemek için gidiyorum. Bu fantastik. Burada benim güzel bir görünümü var. Ama biraz sorun burada var. Ve sen bu işe koşmak ilişkisel veritabanları da. Onlar dikey bölümleme denir. Eğer büyük veri tutmak istiyorum uzakta küçük veri. 

Ben lazım çünkü Ve nedeni ise özelliklerini almak için öğeleri okumak gidin. Ve benim organları Burada üzerinde iseniz, Daha sonra birkaç öğe okuma Benim vücut uzunluğu ise 256 kilobayt her ortalama matematik oldukça çirkin olur. Yani David'in gelen kutusunu okumak istediğiniz söylüyorlar. David'in gelen 50 maddeden oluşmaktadır. Ortalama ve büyüklüğü 256 kilobayt olduğunu. İşte benim dönüşüm oranı var UKÜ en dört kilobayt olduğunu. 

Tamam, birlikte gidelim sonunda tutarlı okur. Ben hala 1600 RCU en yiyorum Sadece David'in gelen kutusunu okumak için. Ah. Tamam, şimdi düşünelim App nasıl çalıştığı hakkında. Ben bir e-posta uygulaması isem ve Ben, benim doğuştan bakıyorum ve ben her iletinin gövdesine bakmak, hayır, ben özetleri bakıyorum. Ben sadece başlıklarını bakıyorum. Yani bir tablo yapısı oluşsun Bu daha çok benziyor. 

Yani burada bilgi var Benim iş akışı ihtiyacı olduğunu. Benim Gelen kutunuzda GSI içinde. Bu randevu, gönderen, konu, ve sonra işaret mesaj kimliği, geri mesajları masaya nerede cesedi alabilirsiniz. Peki, bu rekor kimlikleri olacaktır. Onlar geri işaret olur Dynamo DB masaya öğe kimlikleri. Her endeks hep creates-- Her zaman öğe vardır Bu of-- parçası olarak kimliği endeksi ile birlikte geliyor. 

Pekala. HEDEF KİTLE: Bunu söyler depolandığı? Rick, Houlihan: Evet, söyler tam olarak-- o yapar tam olarak buydu. Burada diyor ki, benim yeniden rekor. Ve bu benim yeniden kayda geri işaret edeceğiz. Kesinlikle. Tamam, şimdi benim gelen bir Aslında çok daha küçük. Ve bu aslında destekler Bir e-posta uygulaması akışı. Gelen kutuma Yani, ben tıklayın. Ben de gidip mesajla tıklayın Cesedi almak gitmek gerekir o zaman, var Ben gidiyorum, çünkü Farklı bir görünümüne gidin. Eğer MVC türü hakkında düşünmek eğer öyleyse çerçeve, model görünümü denetleyicisi. 

Model içeriyor Veri görünümü ihtiyacı olduğunu ve kontrolör ile etkileşime girer. Ben çerçeveyi değiştirmek, ne zaman Ben perspektif değiştirmek, o geri dönmek için Tamam Sunucu ve modelini yeniden doldurmak, kullanıcının beklediğini çünkü. Onlar görüşlerini değiştirdiğinizde, bu zaman var Biz geri veritabanına gidebilirsiniz. Yani e-posta, tıklayın. Ben vücudun arıyorum. Gidiş. Cesedi getir. 

Ben çok daha az veri okumak. Ben sadece bedenleri okuyorum o Onlara gerektiğinde David ihtiyacı var. Ve ben 1600 yılında yakmak değilim UKÜ Sadece onun gelen kutusunu göstermek için. Yani şimdi bu şekilde ki- LSI veya GSI-- üzgünüm ki GSI, işe olacaktır. Biz alıcı bizim karma var. Biz tarihte aralık anahtarı var. Ve biz öngörülen nitelikleri var biz görünümü desteklemek için gereken tek şey söyledi. 

Biz outbox için bu döndürün. Gönderici üzerinde Hash. Ve özünde, biz Çok güzel, temiz bir görünüm. Ve bu basically-- Biz bu Bu güzel mesajlar var güzel çünkü yayılmış ediliyor tablo bu karma sadece karma mesaj kimliği var. Ve biz iki dizin var Bu tablonun dışına döndürürken. Pekala, işte bir fikir yapmak değil Büyük veri ve bu küçük verileri tutmak Birlikte. Dikey Bölme, bu tabloları bölümlemek. Veri okumak etmeyin gerek yok. Pekala, oyun. Hepimiz oyunları gibi. En azından ben o zaman oyunlar gibi. Bazı şeyler Yani Biz ne zaman başa olduğunu biz doğru, oyun hakkında düşünüyorsun? Bu günlerde Gaming, özellikle mobil Oyun, bütün düşünme olduğunu. Ve ben burada bir döndürmek için gidiyorum uzakta DynamoDB dan biraz. Ben getirmek için gidiyorum tartışma Bazı Bazı etrafında Diğer AWS teknolojileri. 

Ama oyun hakkında bir fikir düşünmektir API'leri cinsinden yaklaşık vardır API'ler, Genellikle, HTTP ve JSON konuşuyor. It nasıl mobil oyunlar tür Onların arka uçları ile etkileşim. Onlar JSON ilanı yok. Onlar veri almak ve hepsi genellikle güzel JSON API'leri olarak, konuşma. 

Arkadaşlar olsun gibi şeyler olsun afiş, veri alışverişi, Kullanıcı tarafından oluşturulan içerik, sisteme geri itin, Bunlardan türleri yapmamız gereken gidiyoruz. İkili varlık verileri, bu veriler veritabanında oturup olmayabilir. Bu oturup olabilir Nesne deposu, değil mi? Ancak veritabanı gidiyor Sistemi söylüyorum sonuna kadar, Uygulamayı söylüyorum nereye gidip. Ve kaçınılmaz olarak, çok oyunculu sunucular, arka uç altyapısı, ve yüksek için tasarlanmış kullanılabilirlik ve ölçeklenebilirlik. Peki bu hepimizin istediği şeyi vardır oyun altyapısına bugün. 

Yani bir göz atalım Ne böyle görünüyor. Bir çekirdek arka sonu var çok basit. Biz burada bir sistem var Birden kullanılabilirlik bölgeleri. Düşünmek being-- gibi AZS hakkında konuştuk Bunlardan ayrı veri merkezleri olarak. Birden fazla veri merkezi AZ başına, ama bu, Tamam Sadece ayrı veri olarak onları düşünüyorum coğrafi olarak merkezler ve arıza izole edilmiştir. 

Biz var gidiyoruz çift ​​EC2 örnekleri. Biz gidiyoruz Bazı arka uç sunucu. Eğer eski bir konum belki mimari, biz konum Biz RDS dediğimiz kullanarak, ilişkisel veritabanı hizmetleri. MSSQL, MySQL Olabilir, Ya da bunun gibi bir şey. Bu şekilde bir çok uygulamaları Bugün dizayn bulunmaktadır. 

Peki biz gitmek isteyebilirsiniz biz ölçek zaman budur. Biz go ahead ve koyacağım Orada S3 kova. Ve o S3 kova yerine hizmet Bizim servers-- gelen bu nesneleri kadar bunu yapabilirdi. Hepiniz ikili koymak Sunucularınızdaki nesneleri ve o sunucu kullanabilirsiniz örnekleri veri yukarı hizmet etmek. Ama bu oldukça pahalı. 

Yapacak daha iyi bir yolu go ahead ve bir S3 kova bu nesneleri koymak. S3 bir nesne depoları olduğunu. Bu için özel olarak inşa edilmiştir bu tür şeyleri kadar hizmet. Ve bu müşteriler isteğinde izin doğrudan bu nesne kovalar, sunucuları boşaltma. Yani biz burada ölçek başlıyoruz. 

Şimdi tüm dünyada kullanıcıların aldım. Ben kullanıcıları var. Ben yerel içerik olması gerekir Doğru, bu kullanıcılara yakın bulunan? Ben bir S3 kova yarattık benim kaynak deposu olarak. Ve ben ön olacak o CloudFront dağılımı. 

CloudFront CD ve bir içerik dağıtım ağı. Temelde belirttiğiniz verileri alır ve internet üzerinden tüm önbelleğe Kullanıcıların her yerde olabilir bu yüzden Çok hızlı tepki ne zaman onlar bu nesneleri isteyin. 

Yani bir fikir olsun. Tür yararlanarak konum tüm AWS yönleri burada halletmek için. Ve sonunda, biz atmak Otomatik ölçekleme grubunda. Bizim AC2 örnekleri Yani Bizim oyun sunucuları, onlar daha yoğun almak için başlangıç ​​olarak ve kalabalıklaştı ve kalabalıklaştı, onlar sadece başka dönmeye edeceğiz örneği, başka bir örneğini döndürmek başka bir örneğini döndürün. AWS, has it teknoloji Yani Eğer parametrelerini belirtmek sağlar hangi etrafında sunucuların büyüyecek. Yani sunucuların n sayıda olabilir Herhangi bir zamanda orada. Yükleme uzak giderse, onlar olacak küçültmek, sayı küçülecek. Ve yük geri gelirse, o elastik, geri büyürüz. 

Yani bu harika görünüyor. Biz EC2 örnekleri bir sürü var. Biz önbelleğini koyabilirsiniz veritabanlarının ön, denemek ve veritabanlarını hızlandırmak. Bir sonraki basınç noktası tipik insanlar görmek Onlar kullanarak bir oyun ölçek olduğunu ilişkisel veritabanı sistemi. Of, veritabanı performans korkunç. Biz nasıl geliştirebilirim? En koyarak deneyelim Bunun önüne önbellek. 

Peki, önbellek çalışmıyor oyunlarda çok büyük, değil mi? Oyunlar için, yazı ağrılıdır. Oyun çok ağır yazma vardır. Sen ne zaman Önbellek çalışmıyor Her zaman ettik çünkü ağır mal önbelleğini güncellemek lazım. Sen bu kadar, önbelleği güncelleme ilgisiz önbelleğe alma için. Aslında sadece ekstra bir iş. 

Yani biz burada nereye? Büyük bir darboğaz var Orada veritabanında. Ve bir yerde gitmek Açıkçası bölümleme olduğunu. Bölümleme değil sen ne yapmak kolay ilişkisel veritabanları ile ilgili. Ilişkisel veritabanları ile, sen idaresinden sorumludur etkili Anahtar alan. Sen A ve M arasında kullanıcıların söylüyorsun N ve Z oraya gitmek arasında, buraya gidin. Ve sen gectiginize uygulama karşısında. Yani uğraşıyoruz Bu bölüm veri kaynağı. Sen işlem kısıtlamaları Bu bölümleri yayılan yok. Sen her türlü var sen messiness Orada aşağı çalışıyor ile ilgili dışarı ölçekleme başa ve daha geniş bir altyapının oluşturulması. Sadece hiç eğlenceli değil. 

HEDEF KİTLE: Yani söylüyor Kaynak puan artarak hızlandırır süreç? Rick, Houlihan: Artan? HEDEF KİTLE: Kaynak noktaları. Rick, Houlihan Kaynak: noktaları? HEDEF KİTLE: bilgilerden, nerede bilgi nereden geliyor? Rick, Houlihan: Hayır Ne diyorum artmaktadır veri deposunda bölümlerin sayısı hacmini artırır. Peki burada oluyor kullanıcımız buraya EC2 örneği girdiği, iyi, ben bir kullanıcı gerekirse Bu M A var, ben burada gidersiniz. N p, burada gidersiniz. A'dan Z'ye P, ben burada gidersiniz. 

HEDEF KİTLE: Tamam, bu yüzden olanlardır farklı düğümlerin saklanan? 

Rick, Houlihan: Evet. Bu olarak düşünün farklı veri silolar. Yani bunun için yaşıyoruz. Yapmanız çalışıyorsanız Bu, sen çalışıyorsanız İlişkisel platformda büyütmek için, Bu yaptığın şeydir. Verileri alıyorsun ve Bunu kesiyorlar. Ve bunu genelinde bölümleme ediyoruz veritabanı birden çok örneği. Ve hepiniz idare konum Uygulama katmanı olarak. Bu hiç eğlenceli değil. Peki biz gitmek istiyorsun? Biz DynamoDB, tam olarak yönetilen gitmek istiyorum, NoSQL veri deposu, hüküm çıktı. Biz ikincil indeksler kullanın. It temelde HTTP API ve Belge desteği içerir. Yani endişelenmenize gerek yok Bu bölümleme hakkında herhangi. Biz sizin için her şeyi. Yani şimdi, bunun yerine, Sadece tabloya yazın. Tablo bölümlenmiş gerekiyorsa, Bu perde arkasında olur. Tamamen izole ediyoruz Bir geliştirici olarak bundan. Öyleyse hakkında konuşalım kullanım durumları bazı Biz oyun içinde, ortak koşmak olduğunu oyun senaryoları, afiş. Yani, kullanıcıların gelen var they BoardNames on, bu kullanıcı için puanlar. Biz, UserID üzerinde karma olabilir ve sonra biz oyun yelpazesi var. Böylece her kullanıcının görmek istiyor O oynadı tüm oyun ve onun üst puanı tüm oyun boyunca. Yani onun kişisel afiş var. 

Şimdi ben gitmek istiyorum ve ben get-- istiyorum bu yüzden bu kişisel leaderboards olsun. Ne yapmak istediğinizi elde gitmek olduğunu tüm kullanıcılar üst puanı. Peki nasıl böyle yaparsın? Benim kayıtlarında karma zaman kimliği, oyun değişiyordu, iyi ben önde gidiyorum ve yeniden yapılandırılması, bir GSI oluşturmak ve ben bu verileri yeniden gidiyorum. 

Şimdi ben karma gidiyorum Oyun BoardName. Ve ben üst puanı üzerinde aralığı için gidiyorum. Ve şimdi farklı kovalar yarattık. Ben aynı tabloyu kullanıyorum, Aynı öğe verileri. Ama verir bir kova oluşturma Bana göre en iyi oyun skor bir toplanma. 

Ve ben bu tabloyu sorgulayabilirsiniz Bu bilgileri almak için. Yani ben bu sorgu model kurdum ikincil indeks ile desteklenmelidir. Şimdi BoardName sıralaması olabilir ve bağlı Topscore sıralama kriteri. Gördüğünüz Peki, bu türleri size oyun içinde olsun durumlarda kullanmak. Biz oyun olsun Başka iyi kullanım durumunda ödül ve kimin ödül kazandı olduğunu. Ve bu büyük bir kullanım durumdur Biz seyrek indeksler diyoruz nerede. Seyrek indeksleri vardır oluşturma yeteneği mutlaka değil bir dizin masada her öğe içerir. Ve neden olmasın? Çünkü davranıyor nitelik endekslenmiş her öğe üzerinde yok. 

Bu, özellikle Yani davayı kullanın diyorum, ne, ben gidiyorum biliyorum Ödül adlı bir öznitelik oluşturmak. Ve ben her kullanıcıya vereceğim Bu özellik bir ödül vardır. Kullanıcılar ödüller vardır yok Bu özniteliği için gitmiyorum. Yani oluşturduğunuzda indeksi, sadece kullanıcıların olduğunu göstermek için gidiyoruz Endekste kadar olan aslında ödül kazanmış olanlar. Böylece edebilmek için harika bir yoldur süzülmüş dizinleri oluşturmak için bilmediğimiz çok seçici endeks için tüm tablo var. 

Yani biz burada zamanında düşük alıyoruz. Devam edin ve atlamak için gidiyorum dışarı ve bu senaryoyu atlayın. Biraz konuşmak about-- 

İZLEYİCİ: Ben bir soru sorabilir miyim? Bir ağır yazmak mı? Rick, Houlihan: Nedir? HEDEF KİTLE: Ağır yaz. Rick, Houlihan: Ağır yaz. Bir bakayım. 

HEDEF KİTLE: Ya o değil bir şey sadece can birkaç saniye içinde ses? Rick, Houlihan: Gitmemiz oylama senaryosu aracılığıyla. O kadar da kötü değil. Siz birkaç dakika var mı? TAMAM. 

Bu yüzden oylama hakkında konuşacağım. Yani gerçek zamanlı oylama, biz var oylama için gereksinimleri. Gereksinimler biz izin verdiğini vardır Her kişi sadece bir kez oy vermeye. Biz hiç kimse muktedir olmak istiyorum oylarını değiştirmek için. Biz gerçek zamanlı toplanmasını istiyorum ve demografik için analitik biz olmak için gidiyoruz Sitede kullanıcılara gösteriliyor. 

Bu senaryoda düşünün. Biz gerçeğin çok çalışmak Onlar nereli TV şovları şeyleri tam bu tip yapıyor. Yani senaryo aklınıza gelebilecek, Biz milyonlarca ve milyonlarca Oradan genç kız kendi cep telefonları ile ve oylama ve oylama ve onlar kim için oy En popüler olmaya bulabilirsiniz. Peki bu bazı Gereksinim biz tükendi. 

Ve böylece ilk almak Bu sorunu çözmede Bir inşa etmek olacaktır çok basit bir uygulama. Yani bu uygulama var. Orada bazı seçmenleri dışarı. Onlar oylama uygulaması vurdu gelir. Ben bazı ham oy tablo var Ben sadece bu oy içine dökümü olacak. Bazı agrega olacak oy tablo bu Benim analitik ve demografik yapacak, ve biz orada bütün bu koymak gerekir. 

Ve bu harika. Hayat güzeldir. Hayat biz bulana kadar iyi Her zaman sadece bir veya iki tane var bir seçimde popüler insanlar. Sadece bir ya da iki şey var insanlar gerçekten umurumda söyledi. Ve oy kullanma eğer Ölçek, ben aniden defolup çekiçleme olacak İki aday, bir ya da iki aday. Öğeleri bir çok sınırlı sayıda insanlar popüler olmaya bulabilirsiniz. 

Bu iyi bir tasarım deseni değil. Bu aslında bir olduğunu çok kötü desen oluşturur, çünkü tam olarak ne biz kısayol tuşları olan konuştuk. Sıcak tuşları hoşumuza gitmeyen bir şey vardır. 

Peki nasıl böyle düzeltebilirim? Ve gerçekten, bunu düzeltmek için bir yoldur Bu aday kovalar alarak ve biz her bir aday için, Biz rastgele bir değer eklemek için gidiyoruz, rastgele bildiğimiz bir şey, bir ve 100 arasında bir değer, 100 ila 1,000 arasında, ya da bir ila 1,000 arasında, Ancak birçok rasgele değerleri istediğiniz Bu adayın ucuna ekleyin. 

Ve ben gerçekten o zaman ne yaptın? Ben aday kimliğinizi olarak kullanıyorum ise agrega oyların kepçe, Ben rastgele eklediyseniz Bu sonuna sayısı Ben yarattım şimdi 10 kovalar, bir yüz kova, bin kovalar ben genelinde oy toplayarak ediyorum. 

Yani, milyonlarca ve milyonlarca ve kayıtların milyonlarca geliyor Bu adaylar için, şimdi yayılıyor am Aday A_1 genelinde bu oy Aday A_100 yoluyla nedeniyle Bir oy gelir her zaman, Rasgele bir üretme ediyorum bir ve 100 arasında bir değer. Ben sonuna üzerine teyel ediyorum kişinin için oy adayı. O kova içine damping ediyorum. 

Şimdi ters biliyorum ben yüz kova var. Yani devam etmek istediğinizde ve oy toplamak, Ben tüm bu kova okumak. Yani go ahead ve ekleyin. Ve sonra dağılım toplamak do Ben dışarı çıkmak ve hey demek nerede, ne var biliyor musun, bu adayın anahtar alanlarda yüzün üzerinde kovalar olduğunu. Tüm toplamak için gidiyorum Bu yüz kovalar oyu. Ben toplamak için gidiyorum Onları ve ben, söylemek için gidiyorum Aday A şimdi var x toplam oy sayısı. 

Şimdi yazma hem Sorgu ve okuma sorgusu güzel dağıtılır Ben yazıyorum çünkü karşısında ve ben anahtarları yüzlerce genelinde okuyorum. Ben yazmıyorum ve Şimdi tek bir tuş genelinde okuma. Böylece büyük bir desen var. 

Bu aslında muhtemelen biridir En önemli tasarım NoSQL ölçek için desenleri. Siz bu tür göreceksiniz Her lezzet tasarım deseni. MongoDB, DynamoDB, değil mi olursa olsun, hepimiz bunu yapmak zorunda. Eğer uğraşırken Çünkü bu büyük toplamalarla, Eğer bir yol anlamaya zorunda kova genelinde onları yaymak. Yani bu bunu yoludur. Pekâlâ, ne yani Şu anda yapıyoruz Eğer okuma kapalı ticaret yapıyoruz edilir Yazma ölçeklenebilirlik için maliyeti. Benim okuma maliyeti Biraz daha karmaşık ve ben okumak gitmek zorunda Yüz kovalar yerine biri. Ama yazabilir değilim. Ve benim hacmi, benim yazma verim inanılmaz. Bu yüzden genellikle değerli DynamoDB ölçekleme için bir teknik, ya da bu konuda herhangi bir NoSQL veritabanı. Yani biz ölçeklemek nasıl anladım. Ve biz düşündüm nasıl Bizim kısayol tuşları ortadan kaldırır. Ve bu harika. Ve biz bu güzel sistem var. Ve bu bize çok doğru oylama verdi Biz rekor oy de-dupe çünkü. Bu DynamoDB içine yerleşik. Biz koşullu haklar hakkında konuştuk. 

Bir seçmen geldiğinde, koyar masada bir ekleme, Onlar, kendi seçmen kimliğiyle eklemek onlar başka bir oylamayı eklemeye çalışırsanız, Ben bir koşullu yazma yapmak. Bu bilgileri sadece Say Bu yoksa. Yani en kısa sürede bunu gördüğünüz gibi Bu oy masasına vurdu kimse olacak kendi oy koymak mümkün. Ve bu harika. Ve biz artan ediyoruz Bizim aday sayaçlar. Ve biz yapıyoruz demografik ve hepsi bu. Ama ne olur benim Uygulama yere düşer? Şimdi ani oy tüm geliyor ve ben onlar işleme alıyoruz olmadığını bilmiyorum Benim analitik ve demografik içine Artık. Ve ne zaman uygulama yukarı, ne geri geliyor cehenneme ben oy var biliyor musunuz İşlenmiş ve nerede başlar? 

Yani bu gerçek bir sorun olduğunda sizi olduğunu Bu tür bir senaryoda bakmaya başlar. Ve nasıl bunu çözmek mi? Biz ne ile çözmeye biz DynamoDB Akışları diyoruz. Akarsular zaman sipariş ve Her erişim bölümlenmiş değişiklik günlüğü masaya, her yazma masaya erişim. Için yazılı herhangi bir veri masa dere üzerinde gösterir. 

Bu temelde 24 saat kuyruk var. Öğeler akışı vurdu Onlar 24 saat yaşıyor. Onlar defalarca okunabilir. Teslim edilmesi garantisi Sadece akımı bir kez, n defa okunabilir. Peki Ancak birçok süreçler istediğiniz bu verileri tüketmek, bunu tüketebilir. Her güncelleme görünecektir. Her yazma sadece olacak akışta bir kez görünür. Yani endişelenmenize gerek yok İki kere işleme konusunda Aynı süreçten. 

Kesinlikle öğe başına sipariş ediyor. Biz zaman derken sipariş ve bölümlenmiş, Eğer dere üzerinde bölüm başına görürsünüz. Sen sırayla öğeleri, güncellemeleri göreceksiniz. Biz garanti değil sen dere üzerinde Her işlem alacaksın öğeler arasında sırayla. 

Yani akışları idempotent bulunmaktadır. Hepimiz idempotent ne anlama geldiğini biliyor musun? Idempotent bunu anlamına gelir üzerinde ve üzerinde tekrar tekrar. Sonuç aynı olacak. 

Akarsular, idempotent vardır ama onlar olmak zorunda Başlangıç ​​noktasından oynadı Seçtiğiniz her yerde, sonuna kadar, ya da neden olmaz Aynı değerleri. 

MongoDB ile aynı şey. MongoDB bir yapı yer alır Onlar OPLOG diyoruz. Bu aynı yapıdır. Birçok NoSQL veritabanları Bu yapı vardır. Onlar şeyler yapmak için kullanabilirsiniz gibi çoğaltma, hangi Tam olarak akışları ile ne olduğunu. HEDEF KİTLE: Belki sapkın bir soru, ama sen uygulamalar bir benzeri yapıyorsun hakkında konuşmak. Akışları garanti edilir muhtemelen aşağı gitmek asla? Rick, Houlihan: Evet, akarsuları aşağı gitmek asla garanti edilir. Biz altyapısını yönetmek arkasında. otomatik akışları Onların oto ölçeklendirme grubunda dağıtın. Biz biraz geçmesi gerekir ne olduğu hakkında biraz. 

Ben onlar değil söylememelidir aşağı gitmek asla garanti. Elemanlar garantilidir akışında görünmesi. Ve dere erişilebilir olacak. Peki iner ya da geri geliyor yukarı, bu altından olur. O Tamam covers--. Pekala, farklı olsun ekranın dışına görünüm türleri. Bir önemlidir görünüm türleri Programcı genellikle o neydi vardır? Ben eski bir görünüm olsun. Bir güncelleme tablosunu çarptığında, olacak dere eski görünümü itin bu yüzden veri arşivlemek veya değişiklik olabilir kontrol, değişim tespiti, değişim yönetimi. 

O sonra şimdi ne yeni görüntü, Bir başka tip güncelleme alabilirsin. Eski ve yeni görüntüler hem de alabilirsiniz. Belki ikisini de istiyorum. Ne olduğunu görmek istiyorum. Bunun için nelerin değiştiğini görmek istiyorum. 

Ben bir uygunluk türü var işlemin bu çalışır. Bu doğrulamak gerekiyor bunlar değiştirdiğinizde, belli sınırlar içinde olduğunuzu veya belirli parametreler dahilinde. 

Ve sonra belki de sadece değiştiğini bilmek gerekir. Ben ne değişti öğe umurumda değil. Bilmem gereken gerekmez Ne değişti bağlıyor. Ben sadece olduğunu bilmek gerekir öğe dokundu ediliyor. Peki bu görüşlerin türleri Eğer akış kapalı olsun ve etkileşimde bulunabilirsiniz. 

Uygulama bu akışı tüketir, bu çalışır şekilde türüdür. DynamoDB istemci sormak tabloları veri itin. Akarsular biz kırıkları dediğimiz dağıtmak. Shards ölçeklendirilmiş bağımsız olarak tablo. Onlar tamamen hizaya yok senin tablonun bölümleri. Ve nedeni ise onlar hizaya çünkü kapasitesi, akım Tablonun kapasitesi. 

Onlar dağıtmak onların Kendi oto ölçeklendirme grubu, ve onlar bağlı dışarı dönmeye başlar geliyor kaç yazıyor üzerinde, Kaç reads-- gerçekten var yazıyor. Orada hiçbir reads-- ama nasıl Birçok yazar geliyor. 

Ve sonra sırtında sonunda, biz ne biz Bir KCI, ya da Kinesis Client Library diyoruz. Kinesis bir akım verileri Amazon işleme teknolojisi. Ve akımları o üzerine inşa edilmiştir. 

Yani bir KCL etkin kullanımı Uygulama akışı okumak için. Kinesis Müşteri Kütüphane aslında Sizin için işçileri yönetir. Ve aynı zamanda, bazı yapar ilginç şeyler. Bazı tabloları yaratacak senin DynamoDB tablo içinde hangi öğeleri izlemek için İşlenmiş oylandı. Yani bu yolu ise, geri düşerse o yere düşer ve gelir ve alır geri kalktı, nerede belirleyebilirsiniz akımının işlenmesi içinde oldu. 

Bu zaman çok önemli çoğaltma bahsediyoruz. Ne bilmeliyim veri işlendikten edildi ve hangi verileri henüz işlenecek olan. Yani dere KCL kütüphane olacak Sana bu işlevselliği bir sürü vermek. Tüm temizlik ilgilenir. Her shard için bir işçi ayağa kalkar. Bu idari bir tablo oluşturur her işçinin her shard için. Ve bu işçiler yangın gibi, onlar bu tabloları korumak bu yüzden bu rekor biliyorum okuma ve işlenmiştir. Ve sonra bu şekilde süreci ise ölür ve çevrimiçi geri geliyor o çıkardı nerede hakkı devam ettirebilirsiniz. 

Yani biz bu kullanmak Çapraz bölge çoğaltma. Müşterilerin bir sürü ihtiyacı var kendi veri tabloları veri veya parçalarını taşımak etrafında farklı bölgelere. Dokuz bölge vardır dünyanın her yerinde. Yani need-- orada olabilir Asya'da kullanıcıların olabilir, kullanıcılar ABD'nin Doğu Kıyısı. Onlar farklı veriler var Yerel olarak dağıtılmış olması gerekir. Ve belki de kullanıcı uçar ABD'ye üzerinde Asya, ve ben çoğaltmak istediğiniz Onunla yaptığı verileri. O Uçaktan alır Yani, o var onun cep uygulamayı kullanarak iyi bir deneyim. 

Sen çapraz bölge kullanabilirsiniz Çoğaltma kütüphanesi bunu yapmak için. Temelde biz iki teknoloji sağladı. Bir yapabilirsiniz bir konsol uygulaması var Kendi EC2 örneği ayağa kalk. Saf çoğaltma çalışır. Ve sonra biz size kütüphaneyi verdi. Kütüphane oluşturmak için kullanabileceğiniz kendi uygulama eğer Bununla çılgınca şeyler yapmak istiyorum verilerinin-- Filtre, bunun sadece bir bölümünü çoğaltmak veri döndürmek bir içine taşımak farklı tablo, vesaire vesaire. Yani o neye benzediğini tür. 

DynamoDB Akımlar olabilir Biz Lambda dediğimiz tarafından işlenen. Biz olay hakkında biraz söz tahrik uygulama mimarileri. Lambda bunun önemli bir bileşenidir. Lambda talep üzerine yangınları koddur Belirli bir olaya yanıt olarak. Bu olaylardan biri bir olabilir dere üzerinde görünen kaydı. Bir rekor akışı belirirse, Bu Java işlevini arayacağım. Peki, bu JavaScript ve Lambda olduğunu node.js, Java, Python, destekler ve yakında destek verecek diğer diller de. Ve saf kod, söylemek yeterli. Java yazma, bir sınıf tanımlamak. Sen Lambda içine JAR yukarı itin. Ve sonra hangi sınıf belirtin Olay yanıt aramak için. Sonra Lambda alt arkasında bu kodu çalışacaktır. 

Bu kod işleyebilir dere kapalı kayıtlar. O onunla istediği her şeyi yapabilir. Bu özel örnekte, her we ' Gerçekten özelliklerini oturum yapıyor. Ama bu sadece bir koddur. Kod doğru, her şeyi yapabilir? 

Yani bu verileri döndürebilirsiniz. Bir türev görünüm oluşturabilirsiniz. Bir belge yapısı ise, Eğer yapısını dümdüz olabilir. Sen alternatif dizin oluşturabilirsiniz. Şeyler her türlü yapabilirsiniz DynamoDB Streams yapmak. 

Ve gerçekten, o gibi görünüyor budur. Yani bu güncelleştirmeler geliyor olsun. Onlar dize kapalı geliyorlar. Onlar Lambda fonksiyonu tarafından okunan ediyoruz. Onlar verileri dönen konum ve Türev tablolarda o kadar iterek, değişimin dış sistemlerin bildiren ve ElastiCache veri bastırıyor. 

Biz önbelleği koymak nasıl hakkında konuştuk Bu satışlar için veritabanı önünde senaryo. Peki ne olur ben öğe açıklamasını güncellemek? Eh, ben olsaydı Lambda işlevi, o masaya çalışan Ben öğe açıklamasını güncellemek, eğer olacak dere kapalı rekor pick up, ve ElastiCache güncelleme olacak yeni verilerle örneği. Yani bir sürü ait olduğunu Biz Lambda ne yapacağız. Bu, bağlantı tutkal kodu. Ve aslında verir başlatmak için yeteneği ve çok karmaşık uygulamaları çalıştırmak için Adanmış bir sunucu olmadan gerçekten harika altyapı. 

Yani en geri dönelim bizim Gerçek zamanlı oylama mimarisi. Bu yeni ve geliştirilmiş olan bizim ile dere ve KCL etkin bir uygulama. Aynı, biz daha önce olduğu gibi seçimde herhangi bir ölçek anlaştım. Biz bu gibi. Biz dağılım büzgüler dışarı yapıyoruz Birden kovaları arasında. Biz iyimser kilitleme devam var. Biz seçmeni tutabilir oylarını değiştirmesini. Onlar sadece bir kez oy kullanabilirsiniz. Bu fantastik. Gerçek zamanlı hata toleransı, Şimdi ölçeklenebilir toplanma. Şey üzerinde düşerse, onu kendisini yeniden bilir nerede çünkü geri geldiğinde Biz KCL uygulamasını kullanarak ediyoruz. Ve o zaman biz de onu kullanabilirsiniz KCL uygulaması dışarı veri itmek diğeri için kırmızıya kayma için Uygulamaya analitik, ya da kullanım Elastik MapReduce çalıştırmak off gerçek-zamanlı streaming toplamalardan Bu verilerin. 

Yani bu şeyler biz çok konuşulan değil. Ama ek konum gelen teknolojiler Eğer aradığınız zaman ayı senaryolarda bu tür at. 

Pekala, bu konuda yani DynamoDB Streams ile analitik. Sen de-dupe toplayabilirsiniz Veri, her türlü yapmak güzel şeyler, toplam veriler Bellek, bu türev tablo oluşturun. Bu çok büyük bir kullanım davası Bu müşterilerinin çok İç içe alarak, birlikte katılıyor Bu JSON belgelerin özelliklerini ve ek dizin oluşturma. 

Sonuna geldik. Benimle rulman için teşekkür ederiz. Öyleyse hakkında konuşalım referans mimarisi. DynamoDB yüzden ortasında oturur AWS altyapısının çok. Temelde bunu kanca bir şey kadar istediğiniz. Uygulamalar Dynamo dahil kullanılarak inşa Lambda, ElastiCache, CloudSearch, Elastik içine veri itmek MapReduce, DynamoDB ithalat ihracat S3, iş akışları her türlü içine. Ama muhtemelen en iyi hakkında konuşmak için bir şey, ve bu gerçekten ne olduğunu ilginç zaman biz ise olay güdümlü uygulamalar hakkında konuşmak. 

Bu bir örnek bir iç proje biz aslında olduğun yerde var yayıncılık anket sonuçlarını toplamak için. Bir e-posta link Böylece Biz orada olacak, göndermek Biraz bağlantı söyleyerek tıklayın olmak Burada ankete yanıt vermek. Ve ne zaman bir kişinin tıklama Bu bağlantı, ne olur Onlar güvenli bir aşağı çekme olduğunu S3'ten HTML anket formu. Hiçbir sunucu yok. Bu sadece bir S3 nesnesidir. 

Bu form çıkageldi tarayıcıda kadar yükler. Bu Omurga var. Karmaşık JavaScript var o koşuyor. Bu yüzden çok zengin bir uygulama var müşterinin tarayıcıda çalışan. Onlar değil bilmiyorum Bir arka uç sunucusu ile etkileşim. Bu noktada, her bir tarayıcıdır. 

Onlar sonuçları yayımlamak neler Amazon API Geçidi diyoruz. API ağ geçidi sadece bir web API Tanımlamak ve kanca olabilir ne olursa olsun istediğiniz. Bu özel durumda, konum Lambda fonksiyonu bağladım. 

Yani benim POST operasyonu Hiçbir sunucu ile oluyor. Temelde bu API ağ geçidini orada oturur. Bana insanların dek hiçbir maliyeti Doğru, o deftere nakil başlar? Lambda fonksiyonu sadece orada oturuyor. Ve bu kadar bana hiçbir maliyeti insanlar isabet başlar. Yani hacim olarak görebilirsiniz ücretleri gelince artar bu. Bir sunucu 7/24 kaçmıyorum. 

Yani formu çekin aşağı kova dışında, ve ben API aracılığıyla sonrası Lambda işlevi Geçidi. Sonra Lambda fonksiyon bilirsin diyor Ne Bazı PIIS var, bazı kişisel bilgiler Bu yanıtlarında. Ben kullanıcılardan gelen yorumları aldım. Ben e-posta adresleri var. Ben adları var. 

Bana bu kapalı bölme edelim. Bazı üretmek için gidiyorum Bu kayıt dışı meta. Ve ben itmek için gidiyorum DynamoDB içine metadata. Ve ben tüm verileri şifrelemek olabilir Ben istiyorum ve DynamoDB itin. Ama bu benim için daha kolay Önümüzdeki bir söz gitmek için, davayı kullanın, Ben ham verileri itmek için gidiyorum Şifrelenmiş S3 kova içine. Yani S3 sunucu tarafında inşa kullanmak şifreleme ve Amazon'un Anahtar Yönetimi Böylece hizmet bir anahtar var düzenli aralıklarla dönebilir, ve ben o KKB verilerini koruyabilir Bütün bu iş akışının bir parçası olarak. 

Peki ben ne yaptım? Ben sadece bir bütün dağıtılan ettik Uygulama ve hiçbir sunucu var. Yani olay uygulama odaklı nedir mimari sizin için yapar. 

Şimdi düşünmek eğer bu-- için kullanma durumu biz konuşuyorum diğer müşterileri var yaklaşık bu kesin mimarisi kim Olağanüstü büyük kampanyaları, koşmak kim Bu bakarak ve oh my, gidiyoruz. Şimdi, onlar çünkü temelde orada dışarı itmek, Sadece oturup kampanyayı izin orada başlattı ve kadar değil Bir incir endişelenmenize gerek altyapı ne tür Bunu desteklemek için oraya olacak. Ve sonra en kısa sürede Bu kampanya, yapılır bu altyapı gibi sadece hemen kaybolduktan Gerçekten orada çünkü Hiçbir altyapı. Bu Lambda oturur sadece kodu. Bu DynamoDB oturur sadece veri var. Bu inanılmaz bir yoludur uygulamalar oluşturmak için. 

HEDEF KİTLE: Peki daha çok olduğunu geçici olacağını daha gerçek bir sunucuda saklanan olsaydı? 

Rick, Houlihan: Kesinlikle. Bu sunucu örneği Çünkü 7/24 olurdu. Bunun için hazır olmak zorundadır Biri cevap. Peki ne oldu? S3 24/07 mevcuttur. S3 zaman verir. Ve S3 çok çok iyi, nesneleri hizmet veren. Bu nesneler HTML dosyaları olabilir, ya da JavaScript dosyaları, ya da her ne istiyorsun. Çok zengin web uygulamaları çalıştırabilir S3 kovalar dışında, ve insanlar yok. 

Ve böylece bu fikir burada uzak yoldan elde etmektir Biz bu konuda düşünmek için kullanılır. Hepimiz düşünmek için kullanılan sunucular ve bilgisayarlara şartları. Artık bu konuda değil. Bu kodu olarak altyapı hakkında. Bulut kodunu dağıtmak ve Bulut sizin için çalışmasına izin verin. Ve bu AWS yapmaya çalışıyor budur. 

HEDEF KİTLE: ortasına altın kutusunda Yani API Gateway, sunucu gibi değil ancak bunun yerine sadece- olduğu 

Rick, Houlihan: Sence edebilirsiniz Sunucu cephe olarak bunu. O Tüm bir HTTP alacağım olduğunu talep ve başka bir işlem için harita. Yani öyle hepsi bu. Ve bu durumda biz haritalama konum Bir Lambda fonksiyonu. Pekala, ben aldım hepsi bu. Çok teşekkür ederim. Bunu takdir ediyorum. Sanırım zamanla biraz istediğini biliyorum. Ve umarım siz var bilgi biraz Bugün uzakta alabilir. Ben gidersem Ve özür dilerim senin başlarının üzerinde bazı, ama iyi bir şey var Temel temel bilgiler Bence sizin için çok değerlidir. Yani bana sahip için teşekkür ederim. [ALKIŞ] HEDEF KİTLE: [duyulamaz] Söylediğiniz zaman olduğu Eğer bir şey gitmek zorunda kaldı başından sonuna kadar Doğru değerleri almak için veya aynı değerler nasıl olur değerler [duyulamaz] eğer değiştirin. 

Rick, Houlihan: Oh, idempotent? Değerler nasıl değiştirecek? Eh, çünkü koşmak vermedi sonuna kadar tüm yol, Sonra ben değişir bilmiyorum son mil yapılmıştır. Bu olacak değil Ben ne gördüm aynı verileri. HEDEF KİTLE: Ah, senin bu yüzden sadece Tüm giriş kazanılmış değil. Rick, Houlihan: Doğru. Sen baştan gitmek zorunda sonuna ve daha sonra bu tutarlı bir devlet olacak. Güzel. 

HEDEF KİTLE: Eğer bize gösterdi Yani DynamoDB belge veya anahtar değerini yapabilirsiniz. Ve biz çok zaman geçirdim Bir karma ve yollar anahtar değeri Etrafını çevirmek için. O masalarda baktığında, yani Belge yaklaşımı geride bırakarak? 

Rick, Houlihan: Ben olmaz Bunu geride bırakarak söylüyorlar. 

İZLEYİCİ: Bunlar Şeyin ayrıldı 

Rick, Houlihan: Belge yaklaşım, DynamoDB belge türü sadece başka nitelik olarak düşünmek olduğunu. Bu içeren bir nitelik var hiyerarşik bir veri yapısı. Ve sonra sorgularda, Eğer özelliklerini kullanabilirsiniz Nesne Notasyonu kullanarak bu nesnelerin. Yani iç içe geçmiş bir filtre edebilirsiniz JSON belgenin özelliği. HEDEF KİTLE: Yani herhangi bir zaman Bir belge yaklaşım yapmak, Ben tür tabular-- varmak olabilir HEDEF KİTLE: Kesinlikle. HEDEF KİTLE: --indexes ve Sadece konuştuk şeyler. Rick, Houlihan: Evet, indeksler ve bütün bu, ne zaman dizin oluşturmak istediğiniz JSON özellikleri, Biz bunu yapmak zorundayız yolu varsa olduğunu Bir JSON nesnesi veya bir belgeyi eklemek Dynamo içine siz akışları kullanmak istiyorsunuz. Akarsular girdi okurdum. Sen JSON olduğunu olsun istiyorum nesne ve Tamam derdim, Ben indeksi istediğiniz özellik nedir? 

Bir türev tablo oluşturun. Şimdi şu anda çalışır yoludur. Biz indeksine izin vermez doğrudan bu özellikleri. 

HEDEF KİTLE: Belgelerinizi Tabularizing. 

Rick, Houlihan: Kesinlikle, düzleşme o, tam olarak bunu tabularizing. Yani onunla ne var. 

HEDEF KİTLE: Teşekkür ederim. 

Rick, Houlihan: Evet, kesinlikle, teşekkür ederim. HEDEF KİTLE: Yani bu tür var Mongo Redis classifers karşılamaktadır. 

Rick, Houlihan: Evet, böyle bir çok şey. Bunun için iyi bir açıklaması. Güzel.