[موسیقی] RICK HOULIHAN: بسیار خوب. سلام به همه. نام من ... ریک Houlihan است. من یک مدیر ارشد هستم راه حل های معمار در AWS. من در نواسکیوال تمرکز و فن آوری DynamoDB. من امروز اینجا هستم به صحبت کردن شما کمی در مورد آن. 

پس زمینه من است در درجه اول در لایه داده ها. من نیمی از پیشرفت من صرف حرفه ای نوشتن پایگاه داده، دسترسی به داده ها، راه حل های برای کاربردهای مختلف. من در ابر مجازی سازی شده برای حدود 20 سال. بنابراین قبل از ابر ابر بود، ما استفاده می شود به آن پاسخ محاسبات ابزار. و ایده این بود که آن را مانند PG & E، شما را برای آنچه شما استفاده از پرداخت. امروز ما آن را به ابر. 

اما در طول سال، من کار کرده ام برای چند شرکت شما احتمالا هرگز از شنیده می شود. اما من یک لیست از فنی وارد شده ام دستاوردها، من حدس می زنم شما می گویند. من هشت اختراع ثبت شده در سیستم های ابر مجازی سازی، طراحی ریز پردازنده، رویداد پردازش پیچیده، و مناطق دیگر نیز هست. 

بنابراین این روزها، من عمدتا متمرکز بر نواسکیوال فن آوری و نسل بعدی بانک اطلاعات. و که به طور کلی آنچه که من قصد می شود در اینجا صحبت کردن به شما امروز در مورد. پس چه شما می توانید انتظار از این جلسه، ما را از طریق رفتن مختصر تاریخ پردازش داده ها. آن را همیشه به مفید درک که در آن ما را از آمد و چرا ما که در آن ما هستند. و ما کمی صحبت کمی در مورد فن آوری های NoSQL از نقطه نظر اساسی است. 

ما را به گرفتن برخی از داخلی DynamoDB. DynamoDB هیچ عطر و طعم AWS است. آن را به طور کامل مدیریت و راه حل میزبانی نواسکیوال. و ما کمی در مورد جدول صحبت ساختار، رابط های برنامه کاربردی، انواع داده ها، شاخص ها، و برخی از داخلی این تکنولوژی DynamoDB. ما به برخی از طراحی کنید الگوهای و بهترین شیوه. ما در مورد چگونه شما صحبت استفاده از این فناوری برای برخی از از برنامه های امروز است. و سپس ما را کمی صحبت در مورد تکامل یا ظهور یک پارادایم جدید در برنامه نویسی نام برنامه های کاربردی رویداد محور و چگونه DynamoDB بازی می کند در آن نیز هست. و ما به شما یک کمی از ترک بحث معماری مرجع بنابراین ما می توانیم در مورد برخی از صحبت شما می توانید روش DynamoDB استفاده کنید. 

بنابراین برای اولین بار off-- این یک سوال است من می شنوم زیادی است، چه یک پایگاه داده است. بسیاری از مردم فکر می کنم آنها مطمئن شوید که چه یک پایگاه داده است. اگر شما گوگل، شما این را ببینید. این مجموعه ای از داده های ساخت یافته برگزار یک در یک کامپیوتر، به ویژه که در شیوه های مختلف در دسترس است. گمان می کنم که خوب تعریف یک پایگاه داده مدرن است. اما من آن را دوست ندارم، چون دلالت دارد، بر چند چیز است. این نشان میدهد ساختار. و آن را نشان می دهد که آن را بر روی یک کامپیوتر است. و پایگاه داده نیست همیشه بر روی کامپیوتر وجود دارد. پایگاه های داده در واقع در بسیاری وجود داشته است. 

بنابراین تعریف بهتری از پایگاه داده چیزی شبیه به این است. یک پایگاه داده است سازمان یافته مکانیسم برای ذخیره سازی، مدیریت، و بازیابی اطلاعات. این است که از About.com. بنابراین من این را دوست چون واقعا مذاکرات درباره پایگاه بودن یک مخزن، یک مخزن از اطلاعات، لزوما چیزی است که نشسته است بر روی یک کامپیوتر است. و در طول تاریخ، ما همیشه کامپیوتر نداشته است. 

در حال حاضر، اگر بپرسم متوسط توسعه امروز چه یک پایگاه داده، که پاسخ من است. در جایی من می توانید مسائل را می چسبد. درست؟ و این درست است. اما این مایه تاسف است. از آنجا که پایگاه داده است که واقعا پایه و اساس برنامه مدرن است. این بنیاد از هر نرم افزار است. و چگونه شما ساخت است که پایگاه داده، چگونه ساختار شما که داده است که به دیکته کند که چگونه است که نرم افزار همانطور که در مقیاس انجام می دهد. 

بنابراین تعداد زیادی از کار من امروز در برخورد با چه اتفاق می افتد زمانی که توسعه دهندگان این روش و خرید و فروش با عواقب از برنامه ای که در حال حاضر فراتر از اصلی پوسته پوسته شدن قصد و درد و رنج از طراحی بد است. پس امیدوارم زمانی که شما راه رفتن به دور امروز، شما یک زن و شوهر از ابزار در کمربند خود را که به شما در حفظ و از ساخت آن اشتباهات است. خیلی خوب. بنابراین اجازه دهید در مورد یک کمی از صحبت جدول زمانی از فن آوری پایگاه داده. من فکر می کنم به عنوان خوانده شده مقاله که مدتها پیش و آن گفت: چیزی در lines-- این بیانیه بسیار شاعرانه است. این گفت تاریخ پردازش اطلاعات است پر از متن را بالا فراوانی داده ها. باشه. در حال حاضر، من حدس می زنم که این نوع از درست است. اما من در واقع نگاه به عنوان تاریخ است که در واقع پر با علامت بالایی از فشار داده ها. از آنجا که نرخ داده مصرف هرگز پایین می رود. آن را تنها بالا می رود. 

و نوآوری زمانی رخ می دهد ما فشار داده، ببینید که مقدار داده است که در حال حاضر در آینده به سیستم. و آن را نمی تواند پردازش شود موثر هم در زمان و یا در هزینه. و این زمانی که ما شروع به به در فشار داده است. 

تا زمانی که ما در نگاه پایگاه داده برای اولین بار از این یکی که بین گوش ما بود است. همه ما با آن به دنیا آمد. این یک پایگاه داده خوب است. از آن است که در دسترس بودن بالا. آن را همیشه در. شما همیشه می توانید آن را دریافت. 

اما تنها کاربران است. من می توانم افکار من با شما به اشتراک بگذارند. شما می توانید افکار من نیست هنگامی که شما آنها را می خواهم. و abilitiy است خیلی خوب نیست. ما فراموش می کنیم همه چیز. در هر حال حاضر و پس از آن، یکی از ما برگ و در حرکت می کند به وجود یکی دیگر از و ما از دست دادن همه چیز که در آن پایگاه داده بود. به طوری که همه که خوب نیست. 

و این به خوبی در طول زمان کار هنگامی که ما در روز بود زمانی که همه ما واقعا نیاز به دانستن است به کجا می رویم به در فردا یا جایی که ما جمع آوری بهترین مواد غذایی است. اما همانطور که ما شروع به رشد به عنوان یک تمدن و دولت آغاز شده به وجود آمده است، و کسب و کار آغاز شده به تکامل، ما متوجه ما نیاز به یک کمی بیشتر از آنچه که ما می تواند در سر ما قرار داده است. خیلی خوب؟ 

ما سیستم های رکورد مورد نیاز است. ما مکان های مورد نیاز برای ذخیره داده ها قادر. بنابراین ما اسناد نوشتن آغاز شده، ایجاد کتابخانه و آرشیو. ما آغاز شده در حال توسعه یک سیستم حسابداری دفتر. و این که سیستم شمارش دفتر جهان برای قرن ها زد، و شاید حتی هزاران سال به عنوان ما به نوعی به نقطه رشد که در آن است که بار داده پیشی گرفته توانایی این سیستم قادر به مهار آن. 

و این در واقع در 1880s اتفاق افتاده است. درست؟ در سال 1880 سرشماری ایالات متحده. این است که واقعا که در آن عطف اشاره پردازش داده مدرن است. این نقطه در است که مقدار داده که توسط جمع آوری شد دولت ایالات متحده به نقطه کردم که در آن زمان هشت سال برای پردازش. 

در حال حاضر، هشت years-- عنوان شما می دانید، سرشماری اجرا می شود هر 10 years-- پس از آن کاملا آشکار است که با زمان ما کردم سرشماری سال 1890، مقدار داده که قرار بود به پردازش شود توسط دولت بود به بیش از 10 سال است که آن را به سرشماری جدید راه اندازی می شود. این یک مشکل بود. 

بنابراین یک پسر به نام هرمان Hollerith در آمد همراه و او را اختراع واحد ثبت، پانچ کارت، کارت پانچ خوان، کارت پانچ جدول نویس، و میترا مکانیزم برای این فناوری است. و شرکت است که او در تشکیل زمان، همراه با چند تن دیگر، در واقع تبدیل به یکی از ستون های یک شرکت کوچک ما امروز می شناسیم به نام آی بی ام. 

بنابراین IBM در اصل در بود کسب و کار پایگاه داده. و این واقعا چیزی است که آنها انجام داد. آنها پردازش داده است. 

همانطور که از تکثیر پانچ کارت، یک مکانیسم هوشمندانه از قادر به اهرم بودن فن آوری به نظرسنجی مجموعه نتایج مرتب شده است. شما می توانید در این تصویر مشاهده می کنید ما یک little-- آن را کمی small-- اما شما می توانید ببینید یک مکانیزم مکانیکی بسیار مبتکرانه که در آن ما یک عرشه کارت پانچ. و در نظر گرفتن کسی یک پیچ گوشتی کوچک و چسبیده از طریق اسلات و بلند کردن آن را تا که برای دریافت بازی، که نتایج طبقه بندی شده اند تنظیم شده است. 

این تجمع است. ما این کار را در همه زمان ها امروز در کامپیوتر، که در آن شما آن را در پایگاه داده باشد. ما برای این کار را دستی، درست است؟ مردم این چیزها را با هم. و آن را تکثیر شد از این کارت های پانچ به آنچه که ما به نام طبل داده و قرقره داده ها، نوار کاغذی. 

صنعت پردازش داده و جو در زمان یک درس از پیانو بازیکن. بازیکن تماس پیانو در به نوبه خود از قرن استفاده می شود به استفاده از قرقره کاغذ با اسلات به آن بگویید که کلید را به بازی. به طوری که تکنولوژی اقتباس شده در نهایت برای ذخیره داده های دیجیتال، زیرا آنها می توانند که داده قرار داده است بر روی آن قرقره نوار کاغذی. 

در حال حاضر، به عنوان یک نتیجه، داده شد چگونه actually-- شما دسترسی به این اطلاعات به طور مستقیم بود وابسته به چگونه شما آن را ذخیره می شود. بنابراین اگر من داده ها بر روی یک نوار قرار داده است، من تا به حال دسترسی به داده ها به صورت خطی. من تا به حال به رول طیف نوار برای دسترسی به همه داده ها. اگر من داده ها در پانچ قرار کارت های، من می توانم آن دسترسی داشته باشید در کمی بیشتر تصادفی مد، شاید نه به عنوان به سرعت. 

اما محدودیت در نحوه وجود دارد و ما دسترسی به داده ها بر اساس چگونه ذخیره شده بود. و این یک مشکل بود رفتن به '50S. باز هم، ما می توانید شروع به دیدن که ما به عنوان توسعه فن آوری های جدید برای پردازش داده ها، درست است، آن باز می شود تا درها را برای راه حل های جدید، برای برنامه های جدید، جدید برنامه های کاربردی برای آن داده است. و در واقع، حکومت ممکن است به این دلیل بوده است چرا ما توسعه برخی از این سیستم ها. اما کسب و کار به سرعت در حال تبدیل شد راننده پشت تکامل از پایگاه داده های مدرن و سیستم فایل مدرن است. 

بنابراین چیزی که بعد که آمد در '50S بود سیستم فایل و بود توسعه ذخیره سازی دسترسی تصادفی. این زیبا بود. در حال حاضر، همه ناگهانی، ما می توانیم قرار ما فایل در هر نقطه بر روی این دیسک های سخت و ما می توانیم این داده ها به صورت تصادفی دسترسی داشته باشید. ما می تواند تجزیه که اطلاعات از فایل های. و ما همه حل شده در جهان، مشکلات را با پردازش داده ها. 

و به طول انجامید حدود 20 یا 30 سال تا زمان تکامل از پایگاه داده رابطه ای که زمانی که جهان ما در حال حاضر تصمیم گرفت نیاز به یک مخزن است که شکست پراکندگی داده ها در سراسر فایل سیستم های که ما ساخته شده است. درست؟ بیش از حد داده توزیع در بسیاری از از نقاط، د تکرار از داده ها، و هزینه های ذخیره سازی بسیار زیاد بود. 

در '70s، منابع گران قیمت ترین که یک کامپیوتر در حال ذخیره سازی است. پردازنده بود به عنوان یک هزینه ثابت مشاهده شده است. وقتی که من خرید جعبه، پردازنده برخی از کار انجام می دهد. آن را به چرخش می شود که آیا آن را در واقع کار است یا نه. این واقعا یک هزینه ریخته. 

اما آنچه من به عنوان یک هزینه کسب و کار ذخیره سازی است. اگر من به خرید دیسک بیشتر بعدی ماه، که هزینه های واقعی که من پرداخت است. و ذخیره سازی گران قیمت است. 

در حال حاضر ما سریع به جلو 40 سال و ما یک مشکل مختلف داشته باشد. را پردازش و در حال حاضر منابع گران ترین. ذخیره سازی ارزان است. منظورم این است که، ما می توانیم در هر نقطه بر روی بروید ابر و ما می توانیم ذخیره سازی ارزان پیدا کنید. اما آنچه که من می توانید پیدا کردن ارزان است. با 

بنابراین تکامل امروز تکنولوژی، تکنولوژی های پایگاه داده، واقعا اطراف متمرکز پایگاه داده توزیع شده که از رنج می برند نیست از همان نوع از مقیاس محدودیت های پایگاه داده های رابطه. ما کمی در مورد آن صحبت خواهیم آنچه که در واقع به معنی. 

اما یکی از دلایل و راننده پشت this-- ما در مورد فشار داده صحبت کردیم. فشار داده چیزی است که همواره نوآوری است. و اگر شما نگاه در بیش از در پنج سال گذشته، این یک نمودار از آنچه که داده است بار در سراسر شرکت به طور کلی به نظر می رسد در پنج سال گذشته است. 

و قانون کلی این days-- اگر شما به Google-- 90 درصد از داده ها است که ما امروز ذخیره، و آن بود تولید شده در داخل دو سال گذشته. باشه. در حال حاضر، این است یک روند است که جدید نیست. این یک روند است که شده است بیرون رفتن برای 100 سال است. از زمانی که هرمان هولریث توسعه کارت پانچ، ما شده ایم ساخت مخازن داده و جمع آوری داده ها با نرخ های فوق العاده. 

بنابراین در طول 100 سال گذشته، ما دیده ایم این روند است. که رفتن به تغییر. در آینده، ما در حال رفتن به این، اگر نه یک روند شتاب. و شما می توانید ببینید چه که به نظر می رسد. 

اگر کسب و کار در سال 2010 یکی بود ترابایت اطلاعات تحت مدیریت خود، امروز این بدان معناست که آنها مدیریت 6.5 پتابایت داده. که 6،500 بار داده بیشتر است. و من این را می دانم. من هر روز با این کسب و کار است. پنج سال پیش، من به شرکت ها صحبت که به من در مورد چه درد صحبت است برای مدیریت ترابایت داده. و آنها صحبت به من در مورد چگونه ما می بینیم که این است که احتمالا رفتن به دو پتابایت یا در چند سال است. 

این شرکت ها همان امروز من از ملاقات با، و آنها در حال صحبت کردن به من در مورد مشکل با داشتن مدیریت وجود دارد دهها، 20 پتابایت داده. بنابراین انفجار داده ها در صنعت رانندگی عظیم نیاز به راه حل بهتر است. و پایگاه داده رابطه ای است فقط به تقاضا زندگی نمی کند تا. 

و بنابراین یک خطی وجود دارد ارتباط بین فشار داده و نوآوری های فنی. تاریخ به ما نشان داده شده است این، که در طول زمان، هر زمان که حجم داده که نیاز به پردازش شود بیش از ظرفیت سیستم به آن فرایند در یک مدت زمان معقول و یا با هزینه معقول، فن آوری جدید پس از آن اختراع برای حل این مشکلات. این فن آوری جدید، به نوبه خود، باز کردن درب مجموعه ی دیگری از مشکلات، که است جمع آوری داده ها و حتی بیشتر. 

در حال حاضر، ما قصد داریم برای جلوگیری از این. درست؟ ما قصد داریم برای جلوگیری از این. واسه چی؟ آنجا که شما نمی توانید همه چیز را می دانم است که بدانید در جهان وجود دارد. و تا زمانی که ما زنده بوده است، در طول تاریخ انسان، ما همیشه محور بیشتر بدانید. 

بنابراین آن را مانند هر اینچ حرکت به نظر می رسد ما پایین مسیر کشف علمی، ما در حال ضرب مقدار داده که ما نیاز به پردازش نمایی همانطور که ما کشف بیشتر و بیشتر و بیشتر در مورد فعالیتهای داخلی از زندگی، در مورد چگونه جهان کار می کند، در مورد رانندگی کشف علمی، و اختراع که ما در حال انجام است. حجم اطلاعات فقط به طور مستمر افزایش می دهد. بنابراین قادر به مقابله با بودن این مشکل عظیم است. 

بنابراین یکی از چیزهایی ما به عنوان چرا نواسکیوال نگاه می کنید؟ چگونه نواسکیوال حل این مشکل؟ خوب، پایگاه داده های رابطه، ساختار زبان پرس و جو، SQL-- که واقعا یک ساختار از رابطه database-- این چیزها بهینه سازی شده برای ذخیره سازی. 

تماس در '70s، دوباره، دیسک گران است. ورزش تأمین ذخیره سازی در شرکت است بی پایان. میدانم. من آن زندگی می کردند. من درایور ذخیره سازی برای نوشت شرکت superserver enterprised تماس در '90s. و خط پایین این است میشماره یکی دیگر از آرایه ذخیره سازی فقط چیزی بود که هر روز در شرکت اتفاق افتاده است. و آن را هرگز متوقف شده است. ذخیره سازی تراکم بالاتر، تقاضا برای ذخیره سازی چگالی بالا، و برای ذخیره سازی کارآمد تر devices-- آن را هرگز متوقف شد. 

و نواسکیوال تکنولوژی بزرگ است چرا که آن را عادی داده است. آن د-تکراری داده ها. این قرار می دهد داده ها را در یک ساختار است که اگنوستیک به هر الگوی دسترسی است. برنامه های متعدد می تواند ضربه که پایگاه داده SQL، اجرا موقت نمایش داده شد، و دریافت داده ها در شکل که آنها نیاز به برای وظایف سنگین خود روند. که برای تلفن های موبایل فوق العاده است. اما خط پایین این است که با هر سیستم، اگر آن را اگنوستیک به همه چیز، آن است که برای هیچ چیز بهینه شده است. باشه؟ 

و این چیزی است که ما با گرفتن پایگاه داده رابطه ای است. آن را برای ذخیره سازی بهینه شده است. آن را نرمال. آن رابطه ای است. این پشتیبانی از موقت نمایش داده شد. و آن و مقیاس آن را به صورت عمودی. 

اگر من نیاز به یک پایگاه داده SQL بزرگتر و یا یک پایگاه داده قوی تر SQL، من به خرید یک قطعه بزرگتر از آهن است. باشه؟ من با بسیاری از مشتریان کار کرده ام که از طریق ارتقاء بزرگ شده در زیرساخت های SQL خود را تنها برای پیدا کردن شش ماه بعد، آنها در حال ضربه زدن به دیوار است. و پاسخ را از اوراکل و یا MSSQL یا هر کس دیگری این است که یک جعبه بزرگتر. خب دیر یا زود، شما می توانید یک خرید جعبه بزرگتر، و این که مشکل واقعی است. ما نیاز به در واقع همه چیز را تغییر دهید. طوری که در آن کار می کند؟ این آثار به خوبی برای آنلاین تجزیه و تحلیل، OLAP نوع حجم کار. و این واقعا که در آن SQL میباشد. در حال حاضر، آن را امروزه در بسیاری از آنلاین استفاده می شود معاملاتی پردازش نوع کاربردها. و آثار آن را فقط در خوب برخی از سطح بهره برداری، اما آن را فقط به مقیاس نیست راه که نواسکیوال کند. و ما کمی صحبت کمی در مورد چرا که است. 

در حال حاضر، نواسکیوال، از سوی دیگر، برای محاسبه بیشتر بهینه شده است. باشه؟ آن است اگنوستیک به الگوی دسترسی. چیزی است که ما د نرمال ساختار یا یک ساختار سلسله مراتبی. داده ها در یک پایگاه داده رابطه با هم از جداول چندگانه پیوست به تولید این دیدگاه است که شما نیاز دارید. داده ها در یک پایگاه داده های NoSQL در یک سند ذخیره شده است که شامل ساختار سلسله مراتبی. تمام داده ها که به طور معمول می شود متصل به هم به تولید این دیدگاه در یک سند واحد ذخیره می شود. و ما کمی در مورد صحبت چگونه کار می کند در چند نمودار. 

اما این ایده در اینجا این است که شما ذخیره داده های خود را به عنوان این دیدگاه ها معرفی می شود. باشه؟ شما در مقیاس افقی. درست؟ اگر من نیاز به افزایش اندازه خوشه های NoSQL من، من لازم نیست برای به دست آوردن یک جعبه بزرگتر است. من جعبه دیگری. و من این خوشه با هم، و من می توانم که داده سفال. ما کمی در مورد آن صحبت خواهیم چه sharding است، به قادر به مقیاس که پایگاه داده در سراسر دستگاه های فیزیکی متعدد و حذف سد نیاز من به مقیاس به صورت عمودی. 

پس از آن واقعا برای آنلاین ساخته شده است پردازش تراکنش و مقیاس. یک تمایز بزرگ وجود دارد در اینجا بین گزارش، درست است؟ گزارش، من نمی دانم سوال من قصد دارم به بپرسید. درست؟ Reporting-- اگر کسی از بخش بازاریابی من می خواهد به just-- چگونه بسیاری از مشتریان من این ویژگی خاصی که خریداری در این day-- من نمی دانم چه پرس و جو آنها در حال رفتن به درخواست. بنابراین من باید اگنوستیک. 

در حال حاضر، در یک فروشگاه نرم افزار کاربردی، من می دانم چه سوال من درخواست. من ساخته شده نرم افزار برای گردش کار بسیار خاص است. باشه؟ بنابراین اگر من بهینه سازی داده ذخیره برای حمایت از این گردش کار، آن را به سریع تر. و به همین دلیل می توانید نواسکیوال واقعا سرعت بخشیدن به تحویل از این نوع خدمات است. خیلی خوب. 

بنابراین ما قصد داریم برای وارد شدن یک کمی از نظریه است. و برخی از شما، چشم خود را ممکن است عقب کمی. اما من سعی کنید به آن را نگه دارید سطح عنوان بالا به عنوان من می توانم. بنابراین اگر شما در پروژه هستید مدیریت، وجود دارد یک ساختار به نام مثلث محدودیت. باشه. مثلث محدودیت دیکته شما می توانید همه چیز را در همه زمان ها است. می توانید پای خود را ندارد و خوردن آن. بنابراین در مدیریت پروژه، که مثلث محدودیت این است که شما می توانید آن را ارزان، شما می توانید آن سریع، و یا شما می توانید آن خوب است. انتخاب دو. از آنجا که شما نمی توانید هر سه را داشته باشد. درست؟ باشه. 

بنابراین شما در مورد این زیادی بشنود. این یک سه گانه است، مثلث محدودیت سه گانه، یا مثلث آهن oftentimes-- وقتی که شما صحبت به مدیران پروژه، آنها در این مورد صحبت. در حال حاضر، پایگاه داده را داشته مثلث آهن خود را. و مثلث آهنی از داده چیزی است که ما قضیه CAP پاسخ. باشه؟ 

دیکته قضیه CAP چگونه پایگاه داده کار تحت شرایط بسیار خاص است. و ما صحبت در مورد آنچه که بیماری است. اما سه نقطه از مثلث، پس به صحبت، می C، قوام. باشه؟ بنابراین در CAP، قوام معنی است که همه مشتریان که می توانید پایگاه داده دسترسی داشته باشید همیشه بسیار دارند مشاهده مداوم از داده ها. تو هیچ کس دیدن دو چیز متفاوت است. باشه؟ اگر من در پایگاه داده، من از دیدن این دیدگاه همان به عنوان شریک زندگی من که می بیند پایگاه داده. که ثبات است. 

در دسترس بودن بدین معناست که اگر پایگاه داده آنلاین، اگر آن می توان رسید، که تمام مشتریان همیشه قادر به خواندن و نوشتن. باشه؟ به طوری که هر مشتری است که می توانید پایگاه داده به عنوان خوانده شده همیشه قادر خوانده شود داده ها و ارسال داده ها. و اگر چنین است، این یک سیستم در دسترس است. 

و نکته سوم چیزی است که ما شکیبایی پارتیشن پاسخ. باشه؟ یعنی تحمل پارتیشن که سیستم به خوبی کار میکند با وجود شبکه فیزیکی پارتیشن بین گره. باشه؟ بنابراین در خوشه گره می تواند صحبت کردن با یکدیگر، چه اتفاقی می افتد؟ خیلی خوب. 

پایگاه های داده رابطه ای choose-- بنابراین شما می توانید دو تا از این انتخاب کنید. باشه. پایگاه های داده رابطه ای را انتخاب کنید پس سازگار باشد و در دسترس است. اگر پارتیشن بین اتفاق می افتد DataNodes در ذخیره داده، پایگاه داده را قفل. درست؟ این فقط پایین می رود. باشه. 

و این است که چرا آنها با جعبه های بزرگتر شوند. درست؟ از آنجا که معمولا no--، یک خوشه وجود دارد پایگاه داده، بسیار بسیاری از آنها وجود ندارد که کار آن است که راه. اما بسیاری از پایگاه داده در مقیاس به صورت عمودی در یک جعبه. از آنجا که آنها نیاز به سازگار و در دسترس است. اگر یک پارتیشن به تزریق می شود، پس از آن شما را مجبور به یک انتخاب. شما باید برای انتخاب بین سازگار و در دسترس بودن. 

و این چیزی است که پایگاه داده های NoSQL است. خیلی خوب. بنابراین یک پایگاه داده های NoSQL آن، آید در دو طعم. ما have-- خوب، آن را می آید در بسیاری از طعم دهنده، اما آن را با دو پایه می آید characteristics-- چه ما پایگاه داده CP، و یا تماس بگیرید تحمل سازگار و پارتیشن سیستم. این بچه ها را به انتخاب است که زمانی که گره از دست دادن تماس با یکدیگر، ما قصد داریم اجازه می دهد تا مردم را به نوشتن هر بیشتر. باشه؟ 

تا زمانی که پارتیشن حذف شده است، دسترسی مسدود شده است. این بدان معناست که آنها در دسترس نیست. آنها سازگار است. هنگامی که ما می بینیم که پارتیشن خود را تزریق، ما در حال حاضر سازگار باشد، چرا که ما در حال رفتن اجازه می دهد تا تغییر داده بر روی دو دو طرف از پارتیشن به طور مستقل از یکدیگر است. ما به دوباره ارتباطات قبل از هر گونه به روز رسانی به داده ها مجاز است. باشه؟ 

عطر و طعم بعدی خواهد بود یک سیستم AP، یا یک موجود و تقسیم سیستم تحمل است. این بچه ها اهمیتی نمی دهند. درست؟ هر گره که می شود یک ارسال، ما آن را می کنند. بنابراین من تکرار داده من گره های متعدد در سراسر. این گره به دست آوردن یک مشتری، مشتری می آید در، می گوید، من قصد دارم برای نوشتن برخی از داده ها. گره می گوید، هیچ مشکلی. گره بعدی را به او می شود نوشتن در همان رکورد، او را به رفتن به مشکلی ندارد. جایی تماس در پایان به عقب، که داده را به تکثیر کند. و پس از آن کسی را به درک، آه، آه، سیستم آنها متوجه خواهد شد، آه، آه، یک به روز رسانی به دو طرف وجود داشته است. چه کنیم؟ و آنچه را که انجام دهید و سپس آنها انجام کاری که اجازه می دهد تا آنها را به حل و فصل است که دولت داده است. و ما صحبت در مورد که در جدول بعدی. 

چیزی که به اینجا اشاره. و من قصد دارم به دریافت بیش از حد خیلی به این، چرا که این می شود به تئوری داده های عمیق. اما یک معاملاتی وجود دارد چارچوب است که اجرا می شود در یک سیستم رابطه ای است که من اجازه می دهد تا با خیال راحت به روز رسانی را به اشخاص متعدد در پایگاه داده باشد. و آن روز رسانی رخ خواهد داد همه در یک بار یا نه در همه. و این است که به نام معاملات ACID. باشه؟ 

ACID به ما می دهد ظرفیت اتمی، قوام، انزوا، و دوام. باشه؟ این بدان معناست که اتمی، معاملات، تمام به روز رسانی من هم رخ دهد و یا آنها نمی کنند. سازگاری بدان معنی است که پایگاه داده همیشه به یک منسجم آورده دولت پس از به روز رسانی. من هرگز پایگاه داده در یک ترک خواهد کرد حالت بد پس از استفاده از به روز رسانی. باشه؟ 

پس از آن یک کمی متفاوت از قوام CAP. سازگاری CAP به معنی تمام من مشتریان همیشه می توانید داده را مشاهده کنید. سازگاری ACID معنی که هنگامی که یک معامله را انجام داده، داده ها خوب است. روابط من همه خوب است. من قصد ندارم به حذف یک ردیف پدر و مادر و ترک یک دسته از بچه های یتیم در برخی از جدول دیگر. این نمی تواند اتفاق می افتد اگر من سازگار نیست در یک معامله اسید. 

جداسازی بدان معنی است که معاملات همیشه یکی پس از دیگری رخ خواهد داد. نتیجه نهایی از داده خواهد بود که همان حالت اگر آن دسته از معاملات که به صورت همزمان صادر شد سریال اعدام شدند. پس از آن همزمانی کنترل در پایگاه داده. بنابراین اساسا، من می توانم افزایش نمی همان مقدار دو بار با دو عملیات. 

اما اگر من می گویند اضافه کردن 1 به این مقدار، و دو معاملات در آمده و سعی کنید برای این کار، یکی برای رسیدن به آنجا برای اولین بار و یکی دیگر برای رسیدن به آنجا بعد از. بنابراین در پایان، من دو اضافه شده است. شما ببینید من چه معناست؟ باشه. 

دوام بسیار ساده است. در زمانی که تراکنش اذعان شده است، آن را رفتن وجود داشته باشد حتی در صورتی که سیستم سقوط کرد. هنگامی که این سیستم بازیابی، که معامله ای که متعهد شد در واقع رفتن وجود داشته باشد. به طوری که حداقل تضمین های دادرسی است معاملات ACID. کسانی که حداقل تضمین های دادرسی بسیار خوب هستند به یک پایگاه داده، اما آنها که در آن هزینه آمده است. درست؟ 

چرا که مشکل با این چارچوب است اگر یک پارتیشن در داده ها وجود دارد مجموعه ای، من به تصمیم گیری. من قصد دارم به اجازه می دهد تا به روز رسانی در یک طرف یا طرف دیگر. و در صورتی که اتفاق می افتد، پس از آن من دیگر نیستم رفتن قادر به حفظ این ویژگی. آنها نمی خواهد سازگار است. آنها نمی خواهند جدا شده است. این جایی است که آن را تجزیه می برای پایگاه داده های رابطه. به همین دلیل رابطه است پایگاه های داده در مقیاس عمودی. 

از سوی دیگر، ما باید آنچه به نام تکنولوژی BASE. و این پایگاه داده های NoSQL شما می باشد. خیلی خوب. بنابراین ما باید CP ما، پایگاه داده AP. و این چیزی است که شما اساسا پاسخ موجود، حالت نرم، در نهایت استوار. باشه؟ 

اساسا موجود، به دلیل آنها تحمل پارتیشن است. آنها همیشه خواهد بود وجود دارد، حتی اگر وجود دارد یک پارتیشن شبکه بین گره ها. اگر من می توانم به یک گره صحبت می کنید، من رفتن به قادر به خواندن داده ها. باشه؟ من ممکن است همیشه قادر به ارسال شود داده ها اگر من یک پلت فرم سازگار است. اما من قادر به خواندن داده ها. 

حالت نرم نشان می دهد که زمانی که من به عنوان خوانده شده که داده ها، آن را نمی ممکن بود که همان گره های دیگر. اگر راست بر روی یک گره صادر شد در جایی دیگر در خوشه و آن را در سراسر تکرار نمی خوشه هنوز زمانی که من خواندن که داده ها، که دولت ممکن است سازگار است. با این حال، از آن خواهد شد در نهایت سازگار باشد، به این معنی که هنگامی که یک ارسال به سیستم ساخته شده، آن را در سراسر گره را تکثیر کند. و در نهایت، که دولت خواهد شد را به نظم آورده، و از آن خواهد شد یک حالت پایدار. 

در حال حاضر، قضیه CAP واقعا بازی می کند تنها در یک شرط. این وضعیت زمانی که این اتفاق می افتد. چرا که هر زمان آن را در عامل حالت عادی، هیچ پارتیشن وجود دارد، همه چیز سازگار و در دسترس است. شما فقط در مورد CAP نگران هنگامی که ما آن پارتیشن. بنابراین کسانی که نادر است. اما چگونه سیستم واکنش نشان می دهد زمانی که این رخ می دهد دیکته چه نوع سیستم ما در حال برخورد با. 

بنابراین اجازه دهید نگاهی به آنچه که به نظر می رسد برای سیستم های AP. باشه؟ سیستم های AP در دو طعم آمده است. آنها در عطر و طعم است که آمده استاد استاد، 100٪، همیشه در دسترس است. و آنها را در می آیند عطر و طعم های دیگر، که می گوید، شما می دانید چه، من قصد دارم به نگرانی در مورد این چیزی پارتیشن بندی زمانی که یک پارتیشن واقعی رخ می دهد. در غیر این صورت، برای رفتن به اولیه وجود دارد گره که رفتن را به حقوق. باشه؟ 

بنابراین اگر ما مانند کاساندرا چیزی. کاساندرا می شود یک استاد استاد، اجازه دهید من به هر گره ارسال. پس چه اتفاقی می افتد؟ بنابراین من یک شی در پایگاه داده است که در دو گره وجود دارد. اجازه دهید که جسم S. پاسخ بنابراین ما دولت برای S. دارند ما باید برخی از عملیات در S که در حال انجام است. کاساندرا من اجازه می دهد تا به ارسال به گره های متعدد. بنابراین اجازه دهید بگویم من یک گرفتن ارسال برای بازدید کنندگان به دو گره. خب، چه پایان می رسد تا اتفاق می افتد است ما تماس بگیرید که یک رویداد پارتیشن بندی. ممکن است وجود داشته باشد پارتیشن شبکه فیزیکی است. اما به دلیل طراحی از سیستم، آن را در واقع پارتیشن بندی به عنوان به زودی من به عنوان یک نوشتن بر روی دو گره را دریافت کنید. آن را به من به مجبور نمی ارسال از طریق یک گره است. من نوشتن در دو گره. باشه؟ 

بنابراین در حال حاضر من دو کشور داشته باشد. باشه؟ چه اتفاقی خواهد افتاد دیر یا زود، رفتن به یک رویداد تکرار وجود دارد. رفتن وجود دارد به است آنچه که ما نام بازیابی پارتیشن، که است که در آن این دو ایالات تماس گرد هم می آیند و برای رفتن به یک الگوریتم وجود دارد اجرا می شود که در داخل پایگاه داده، تصمیم می گیرد چه کاری انجام دهید. باشه؟ به طور پیش فرض، آخرین به روز رسانی در بسیاری از سیستم AP برنده است. بنابراین معمولا وجود دارد الگوریتم به طور پیش فرض، چه آنها مخاطبین پاسخ تابع، چیزی است که خواهد شد به نام وقتی که این شرایط تشخیص داده شده است برای اجرای برخی از منطق برای حل و فصل درگیری که. باشه؟ پاسخ به تماس به طور پیش فرض و به طور پیش فرض برطرف در اکثر پایگاه های داده AP است، حدس بزنید چه، برچسب زمان برنده است. این آخرین به روز رسانی شد. من قصد دارم برای قرار دادن که به روز رسانی در آن وجود دارد. من ممکن است این رکورد روگرفت که من خاموش به ورود به سیستم بازیابی ریخته به طوری که کاربر می توانید بعدا و می گویند، هی، یک برخورد وجود دارد. چی شد؟ و شما در واقع می تواند کمپرسی یک رکورد از همه از برخورد و rollbacks و ببینید چه اتفاقی می افتد. 

در حال حاضر، به عنوان یک کاربر، شما همچنین می توانید منطق به آن پاسخ به تماس. بنابراین شما می توانید تغییر دهید که عملیات پاسخ به تماس. شما می توانید می گویند، با سلام، من می خواهم برای زدودن این داده ها. و من می خواهم را امتحان کنید و ادغام این دو پرونده. اما تا به شما. پایگاه داده نمی داند که چگونه به که به طور پیش فرض. ترین زمان، تنها چیزی که در پایگاه داده می داند که چگونه به انجام این کار است می گویند، این یکی از آخرین رکورد بود. که یکی از که رفتن به پیروزی است، و ارزش من قصد دارم به قرار داده است. هنگامی که بازیابی پارتیشن و تکرار رخ می دهد، در حال حاضر دولت ما، که در حال حاضر S نخست است که دولت ادغام از تمام کسانی که اشیاء. بنابراین سیستم های AP این. سیستم های CP لازم نیست در این مورد نگران. زیرا به محض یک پارتیشن می آید را به بازی، آنها فقط قطع مصرف می نویسد. باشه؟ به طوری که بسیار آسان برای مقابله با سازگار بودن زمانی که شما هیچ به روز رسانی را قبول نمی کند. که با سیستم های CP است. خیلی خوب. 

بنابراین اجازه دهید کمی صحبت کمی در مورد الگوهای دسترسی داشته باشید. هنگامی که ما در مورد نواسکیوال صحبت می کنید، آن را همه چیز در مورد الگوی دسترسی. در حال حاضر، SQL موردی است، نمایش داده شد. آن را ذخیره رابطه است. ما نیست که نگران باشید در مورد الگوی دسترسی. من ارسال پرس و جو بسیار پیچیده است. از آن می رود و می شود داده ها. این چیزی است که به نظر می رسد این مانند، عادی. 

بنابراین در این ساختار خاص، ما به دنبال در یک فروشگاه محصولات. من دارای انواع مختلف از محصولات می باشد. من کتاب را داشته باشد. من آلبوم داشته باشد. من فیلم ها. رابطه بین محصولات و هر یک از این کتاب، آلبوم، فیلم ها و جداول 1: 1 است. خیلی خوب؟ من یک ID کالا کردم، و که مربوط ID به یک کتاب، یک آلبوم، و یا یک ویدیو. باشه؟ رابطه 1: 1 است که در سراسر آن جداول. 

در حال حاضر، همه آنها books-- خواص ریشه است. مشکلی نیست. عالیه. یک به یک رابطه، من به همه داده ها من نیاز به توصیف آن کتاب. آلبوم Albums-- دارند آهنگ. این چیزی است که ما به بسیاری است. هر آلبوم می تواند بسیاری از آهنگ. بنابراین برای هر آهنگ بر روی آلبوم، من می توانستم رکورد دیگر در این جدول کودک. بنابراین من ایجاد یک رکورد در جدول آلبوم های من. من سوابق متعدد ایجاد در جدول آهنگ های. رابطه یک به بسیاری از. 

این رابطه چه است ما بسیاری از پاسخ به بسیاری از. باشه؟ شما می بینید که بازیگران می تواند در بسیاری از فیلم، بسیاری از فیلم ها. بنابراین آنچه که ما انجام دهید این است که ما را از این نقشه برداری جدول بین کسانی که آن را فقط نقشه ها ID به ID بازیگر فیلم. حالا من می تواند یک پرس و جو می پیوندد ایجاد فیلم ها از طریق ویدئو بازیگر به بازیگران، و آن را به من می دهد یک لیست خوب از از فیلم ها و تمام بازیگران که در آن فیلم بود. 

باشه. بنابراین در اینجا ما به. یک به یک در سطح بالا است ارتباط؛ یک به بسیاری از، آلبوم به آهنگ های. چند به بسیاری از. آن سه سطح بالا روابط در هر پایگاه داده. اگر شما می دانید که چگونه کسانی که روابط با هم کار کنند، پس از آن شما می دانید بسیاری در مورد پایگاه داده در حال حاضر. بنابراین نواسکیوال کار می کند کمی متفاوت است. اجازه دهید در مورد برای یک ثانیه فکر می کنم آنچه در آن به نظر می رسد به گرفتن همه محصولات من. 

در یک فروشگاه رابطه، من می خواهید برای دریافت تمام محصولات من در یک لیست از تمام محصولات من. که بسیاری از نمایش داده شد است. من پرس و جو برای همه ی کتاب من است. من پرس و جو از آلبوم من است. و من پرس و جو برای تمام فیلم های من است. و من آن را قرار داده همه با هم در یک لیست و خدمت به آن را به بالا و به برنامه ای که آن را درخواست. 

برای دریافت کتاب من، من ملحق محصولات و کتاب ها. برای دریافت آلبوم من، من برای پیوستن به کردم محصولات، آلبوم ها، و آهنگ های. و به فیلم من، من برای پیوستن به محصولات به فیلم ها، عضویت از طریق فیلم ها بازیگر نقش اول مرد، و آن را در بازیگران. به طوری که سه نمایش داده شد است. نمایش داده شد بسیار پیچیده به جمع آوری یک مجموعه نتیجه. 

که کمتر از مطلوب است. این است که چرا وقتی ما حرف در مورد ساختار داده هایی را که ساخته شده است به اگنوستیک به دسترسی pattern-- خب این خیلی عالیه. و شما می توانید ببینید این است که واقعا خوب ما چگونه داده های سازمان یافته است. و شما می دانید چه؟ من فقط یک رکورد برای یک بازیگر است. 

که سرد است. من همه بازیگران من deduplicated ام، و من انجمن من حفظ در این جدول نگاشت. با این حال، گرفتن داده ها خارج گران شود. من ارسال CPU در سراسر سیستم پیوستن به این ساختمان داده با هم قادر به جلو است که داده ها به عقب. 

پس چگونه است که در اطراف را دریافت کنم؟ در نواسکیوال آن را در مورد تجمع، نه عادی. بنابراین ما می خواهم بگویم که ما می خواهید حمایت الگوی دسترسی. اگر الگوی دسترسی به برنامه های کاربردی، من نیاز به تمام محصولات من. اجازه دهید تمام محصولات در یک جدول. اگر من تمام این محصولات در یک جدول قرار داده است، من فقط می توانید انتخاب کنید تمام محصولات از جدول و من آن را دریافت کنید. خب چگونه می توانم انجام دهم؟ خوب در نواسکیوال هیچ وجود دارد ساختار به جدول. ما کمی در مورد آن صحبت خواهیم چگونه این کار را دینامو DB. اما شما همان ندارد ویژگی ها و خواص مشابه در هر سطر، در هر آیتم، مثل شما در یک جدول SQL است. و این اجازه می دهد تا من برای انجام بسیاری از چیزهایی است و من بسیاری از انعطاف پذیری است. در این مورد خاص، من اسناد محصول من. و در این خاص به عنوان مثال، همه چیز یک سند در جدول محصولات است. و محصول ممکن است برای یک کتاب یک ID نوع است که یک کتاب مشخص می کند. و نرم افزار بر که ID تغییر دهید. 

در لایه برنامه های کاربردی، من قصد دارم به آه، چه نوع رکورد است؟ آه، آن را یک رکورد کتاب است. سوابق کتاب این خواص است. اجازه بدهید من یک شی کتاب ایجاد کنید. بنابراین من قصد دارم برای پر کردن شی کتاب با این آیتم. مورد بعدی می آید و می گوید، آنچه در این مورد چیست؟ خب این مورد یک آلبوم است. آه، من مختلف طیف کردم پردازش معمول برای آن، به دلیل آن یک آلبوم است. شما ببینید من چه معناست؟ 

به طوری که برنامه tier-- من فقط همه این پرونده انتخاب کنید. همه آنها شروع به آمدن در. آنها می تواند تمام انواع مختلف. و آن منطق برنامه است که سوئیچ در سراسر آن نوع و تصمیم می گیرد که چگونه به آنها را پردازش کند. 

باز هم، بنابراین ما در حال بهینه سازی طرح برای الگوی دسترسی. ما در حال انجام آن توسط سقوط آن جداول. ما اساسا در حال گرفتن این سازه نرمال، و ما در حال ساخت و ساز ساختارهای سلسله مراتبی. در داخل هر یک از این سوابق من قصد دارم برای دیدن خواص آرایه. 

در داخل این سند برای آلبوم ها، من از دیدن آرایه از آهنگ های. کسانی که آهنگ در حال حاضر become-- آن اساسا این جدول کودکان است که وجود دارد در اینجا در این ساختار است. بنابراین شما می توانید این کار را در DynamoDB است. شما می توانید این را در مانگودیبی است. شما می توانید این را در هر پایگاه داده های NoSQL است. درست این نوع از ساختار داده های سلسله مراتبی که به شما اجازه بازیابی اطلاعات به سرعت به دلیل در حال حاضر من لازم نیست که به مطابقت داشته باشد. وقتی که من وارد یک ردیف به آهنگ جدول، و یا یک ردیف به جدول آلبوم ها، من به مطابقت با طرح که. من به صفت یا اموال است که در آن جدول تعریف شده است. هر یک از آنها، وقتی که من وارد آن ردیف. که این مورد در نواسکیوال است. 

من می توانم کاملا متفاوت دارند خواص در هر سند که من را به مجموعه وارد کنید. ساز و بنابراین بسیار قدرتمند است. و آن را واقعا چگونه شما بهینه سازی سیستم. از آنجا که پرس و جو، به جای از پیوستن به این جداول و اجرای نیم دوجین نمایش داده شد به جلو و عقب داده نیاز دارم، من اجرای یکی پرس و جو. و من تکرار در سراسر نتایج تنظیم شده است. آن را به شما می دهد یک ایده از قدرت های NoSQL. من قصد دارم به نوع رفت وری اینجا و بحث کمی در مورد این. این نوع بیشتر از است بازاریابی و یا technology-- بازاریابی از فن آوری نوع بحث. اما این مهم است که درک چرا که اگر ما در بالای نگاه در اینجا در این نمودار، آنچه که ما به دنبال در است آنچه ما تماس بگیرید منحنی اعتیاد به مواد مخدره فن آوری است. و این بدان معنی است چیزهای جدید به بازی می آید. مردم فکر می کنند آن بزرگ است. من تمام مشکلات من حل شده است. 

این می تواند پایان همه، همه به همه چیز. و آنها شروع به استفاده از آن. و آنها می گویند، این مسائل کار نمی کند. این درست نیست. چیزهای قدیمی بهتر بود. و آنها به بازگشت به کار همه چیز راه آنها بود. و سپس در نهایت آنها بروید، شما می دانید چه؟ این مسائل خیلی بد نیست. آه، که چگونه کار می کند. و زمانی که آنها شکل از چگونه آن آثار، آنها شروع به گرفتن بهتر است. 

و نکته خنده دار در مورد آن نوع از خطوط است، آن را تا به آنچه ما در منحنی تصویب فناوری پاسخ. بنابراین چه اتفاقی می افتد این است که ما برخی ماشه فن آوری مرتب سازی بر. در مورد پایگاه داده، آن را فشار داده است. ما در مورد نقاط آب بالا صحبت فشار داده در طول زمان. وقتی که فشار داده با یک خاص نقطه، که یک ماشه تکنولوژی است. 

آن را بیش از حد گران است. آن طول می کشد بیش از حد طولانی برای پردازش داده ها. ما نیاز به چیزی بهتر است. شما می توانید از نوآوران خارج وجود دارد در حال اجرا در اطراف، تلاش برای پیدا کردن آنچه که راه حل است. این ایده تازه چه خبر؟ 

چه خبر بعدی بهترین راه برای انجام این کار؟ و آنها می آیند تا با چیزی. و مردم با درد واقعی، بچه ها در لبه خونریزی، همه آنها بیش از آن پرش، زیرا آنها پاسخ نیاز دارند. در حال حاضر چه ناچار happens-- و در حال حاضر آن اتفاق می افتد در نواسکیوال. من آن را در همه زمان ها را ببینید. 

چه اتفاقی می افتد به ناچار است مردم شروع به استفاده از ابزار جدید به همان شیوه آنها با استفاده از ابزار قدیمی است. و آنها پیدا کردن آن کند تا به خوبی کار نمی کند. من نمی توانم به یاد داشته باشید که من بود صحبت کردن به اوایل امروز. اما آن را مانند، زمانی که مته دستی مخصوص سوراخ کردن سنگ، اختراع شد مردم آن را نوسان بیش از سر خود را به سر و صدا بتن می باشد. 

اما این چیزی است که اتفاق می افتد با نواسکیوال امروز. اگر شما به اکثر مغازه ها راه رفتن در، آنها در تلاش هستند به مغازه ها نواسکیوال. آنچه که آنها انجام است آنها با استفاده از داده های NoSQL، و آنها در حال بارگذاری آن پر از طرح رابطه ای است. دلیل این که چگونه آنها پایگاههای اطلاعاتی را طراحی کنند. و آنها تعجب، به همین دلیل است آن را به خوبی انجام؟ پسر، این چیزی که بدبو است. من تا به حال برای حفظ تمام من می پیوندد in-- آن را مانند، نه، نه. حفظ می پیوندد؟ چرا اطلاعات شما پیوستن هستند. شما اطلاعات در نواسکیوال پیوستن نیست. شما آن را جمع. 

بنابراین اگر شما می خواهید برای جلوگیری از این، یادگیری چگونه از ابزار قبل از شما کار می کند در واقع شروع به استفاده از آن است. سعی نکنید و استفاده از ابزار جدید به همان شیوه شما با استفاده از ابزار قدیمی. شما در حال رفتن به یک تجربه بد است. و هر زمان تنها این چیزی است که این در مورد. زمانی که ما شروع به رو آمدن در اینجا، به این دلیل است نمیفهمد چگونه به استفاده از ابزار. 

آنها همان چیزی بود که پایگاه داده های رابطه، اختراع شد و آنها به جای فایل سیستم شد. آنها سعی کردند به ساخت سیستم های فایل با پایگاه داده های رابطه چرا که آنچه مردم درک شود. آن کار نمی کند. بنابراین درک بهترین شیوه از این فن آوری شما کار با بزرگ است. بسیار مهم. 

بنابراین ما قصد داریم به DynamoDB دریافت کنید. DynamoDB AWS است به طور کامل مدیریت پلت فرم های NoSQL. چه طور کامل مدیریت چیست؟ این بدان معنی است که شما لازم نیست که واقعا در مورد هر چیزی نگران باشید. 

شما در آمده است، به شما بگویم ما، من نیاز به یک جدول. به آن نیاز دارد این ظرفیت است. شما دکمه، و ما ارائه تمام زیرساخت های پشت صحنه. حالا که بسیار زیاد است. 

از آنجا که وقتی شما صحبت می در مورد پوسته پوسته شدن یک پایگاه داده، نواسکیوال خوشه داده ها در مقیاس، پتابایت در حال اجرا، در حال اجرا میلیون ها تراکنش در ثانیه، این چیزها خوشه کوچک نیست. ما در حال صحبت هزاران نفر از موارد. مدیریت هزاران نفر از موارد، حتی نمونه مجازی، درد واقعی در لب به لب است. منظور من، فکر می کنم در مورد هر زمان سیستم عامل پچ بیرون می آید و یا یک نسخه جدید از پایگاه داده باشد. معنی آن چیست به شما عملیاتی؟ این بدان معناست که شما رو 1،200 سرویس دهنده است که باید به روز شود. در حال حاضر حتی با اتوماسیون، است که می تواند مدت زمان طولانی را. که می تواند بسیاری از باعث سردرد عملیاتی، چرا که من ممکن خدمات پایین داشته باشد. 

همانطور که من این پایگاه داده به روز رسانی، من ممکن است استقرار سبز آبی انجام جایی که من استقرار و ارتقاء نیم گره ها، و سپس ارتقا نیمه دیگر. نگاهی کسانی که پایین. بنابراین مدیریت زیرساخت مقیاس بسیار دردناک است. و AWS را که درد خارج از آن. و می توانید پایگاه داده های NoSQL فوق العاده دردناک به دلیل راه مقیاس آنها. 

مقیاس افقی. اگر شما می خواهید برای دریافت نواسکیوال بزرگتر پایگاه داده، شما از خرید گره. هر گره شما خرید می باشد سردرد عملیاتی است. بنابراین اجازه دهید شخص دیگری انجام دهید که برای شما. AWS تواند انجام دهد. 

ما ارزش های کلیدی سند حمایت می کنند. در حال حاضر ما نمی تواند بیش از حد به در نمودار دیگر. در بسیاری از مختلف وجود دارد طعم های NoSQL. آنها همه نوع از گرفتن هستید با هم در این نقطه munged. شما می توانید در DynamoDB نگاه کنید و بگویید بله، ما هر دو یک سند و یک ارزش کلیدی هستید این نقطه را ذخیره کنید. و شما می توانید ویژگی های استدلال از یکی را بر دیگری. به نظر من، بسیاری از این است که واقعا شش یک نیم دوجین از سوی دیگر است. هر یک از این فن آوری است فن آوری خوب و یک راه حل خوب است. من نمی خواهم بگویم مانگودیبی بهتر است بدتر از نیمکت، سپس کاساندرا، پس از آن دینامو، و یا بالعکس. منظورم این تنها گزینه است. 

این برنامه سریع و آن را سازگار در هر مقیاس. پس این یکی از بزرگترین است پاداش شما را با AWS دریافت کنید. با DynamoDB توانایی است برای به دست آوردن یک رقم کم تک تاخیر میلی ثانیه در هر مقیاس. یک هدف طراحی سیستم کرد. و ما به مشتریان است که انجام می دهند میلیون ها نفر از معاملات در هر ثانیه. 

در حال حاضر من از طریق برخی از کسانی که به استفاده از موارد در چند دقیقه است. control-- دسترسی یکپارچه ما آنچه که ما پاسخ مدیریت هویت دسترسی، و یا IAM. این نفوذ هر سیستم، هر سرویس که AWS ارائه می دهد. DynamoDB قاعده مستثنی است. شما می توانید دسترسی به کنترل به جداول DynamoDB است. در تمام حساب های خود را با AWS تعریف نقش دسترسی و مجوزهای در زیرساخت IAM. 

و آن را یک جزء کلیدی و انتگرال در این آنچه که ما در رویداد پاسخ برنامه نویسی هدایت می شود. در حال حاضر این یک پارادایم جدید است. 

مخاطبان: چگونه سرعت خود را از واقعی است مثبت در مقابل منفی کاذب در سیستم کنترل دسترسی خود را؟ RICK HOULIHAN: مثبت واقعی در مقابل منفی کاذب؟ مخاطبان: بازگشت چه شما باید از بازگشت؟ همانطور که به یک بار در حالی مخالف آن نمی گرداند که آن را باید اعتبار؟ 

RICK HOULIHAN: من نمی تواند به شما بگوید که. اگر هر گونه شکست وجود دارد آنچه در آن، من فرد به درخواست این سوال خاص است. اما این سوال خوبی است. من خواهد بود کنجکاو به دانستن که خودم، در واقع. 

و به این ترتیب پس از آن دوباره، پارادایم جدید برنامه نویسی رویداد محور است. این ایده این است که شما می توانید گسترش برنامه های کاربردی پیچیده ای است که می توانید، در مقیاس بسیار بالا بسیار کار بدون هیچ زیرساخت ندارند. بدون هر گونه ثابت زیرساخت ندارند. و ما بحث کمی در در مورد آنچه که به معنی به عنوان ما دریافت بر روی زن و شوهر بعد از نمودار. 

اولین چیزی که ما را انجام دهد است ما در مورد جداول صحبت کنید. انواع داده API برای دینامو. و اولین چیزی که شما متوجه شما در این نگاه، اگر شما با هر پایگاه داده آشنا هستید، پایگاه های داده را واقعا دو نوع از رابط های برنامه کاربردی من می خواهم آن تماس بگیرید. یا دو مجموعه از API. یکی از کسانی که می شود API اداری. 

چیزهایی را که مراقبت از توابع پایگاه داده باشد. پیکربندی موتور ذخیره سازی، راه اندازی و اضافه کردن جداول. پایگاه داده ایجاد کاتالوگ و موارد. این چیز در DynamoDB، شما می بسیار کوتاه، لیست کوتاه است. 

بنابراین در پایگاه داده های دیگر، شما ممکن است ده ها تن را ببینید از دستورات، اداری دستورات، برای پیکربندی این گزینه های اضافی. در DynamoDB شما کسانی که به دلیل نیاز شما از سیستم پیکربندی کنید، کار می کنیم. بنابراین تنها چیزی که شما نیاز به انجام است به من بگویید چه اندازه جدول نیاز دارم. بنابراین شما بسیار گرفتن مجموعه ای محدود از دستورات. 

شما دریافت می کنید درست به روز رسانی جدول، جدول، حذف جدول، جدول و توصیف. کسانی که تنها چیزهایی هستند شما برای DynamoDB نیاز دارند. شما یک ذخیره سازی نیاز ندارد پیکربندی موتور. من لازم نیست که در مورد تکرار نگران باشید. من لازم نیست که در مورد sharding نگران باشید. 

من لازم نیست که به نگرانی در مورد هر یک از این مسائل است. ما تمام آن را برای شما. به طوری که مقدار زیادی از بالای سر است که فقط بلند کردن بشقاب شما. پس ما باید اپراتورهای CRUD است. CRUD چیزی که به ما است پاسخ در پایگاه داده که ایجاد، بروز رسانی، حذف اپراتورها. این مشترک خود را می عملیات پایگاه داده. چیزهایی مثل مورد قرار داده، گرفتن آیتم، به روز رسانی آیتم ها، آیتم های حذف، پرس و جو دسته ای، اسکن. اگر می خواهید به اسکن کل جدول. همه چیز را از روی میز نگه دار. یکی از چیزهایی که خوب در مورد DynamoDB است آن را اجازه می دهد تا اسکن موازی. بنابراین شما در واقع می توانید اجازه دهید من می دانم که چگونه بسیاری موضوعات شما می خواهید برای اجرا بر روی که اسکن. و ما می توانیم آن موضوعات را اجرا کنید. ما می توانید چرخش که اسکن کردن موضوعات مختلف در سراسر بنابراین شما می توانید کل جدول اسکن فضای بسیار، بسیار به سرعت در DynamoDB. 

از API های دیگر ما است آنچه که ما در جریان API ما تماس بگیرید. ما قصد داریم به صحبت بیش از حد زیادی در مورد این در حال حاضر. من برخی از مطالب بعد کردم در عرشه در مورد این. اما جریان است که واقعا یک running-- از آن فکر می کنم به عنوان زمان دستور داد و ورود به سیستم تغییر پارتیشن. هر آنچه را که اتفاق می افتد در جدول نشان می دهد تا در جریان است. 

هر به جدول ارسال نشان می دهد تا در جریان است. شما می توانید این جریان را بخواند، و شما می توانید همه چیز را با آن انجام دهد. ما در مورد آنچه انواع چیزهایی که شما با چیزهایی مانند تکرار، ایجاد شاخص ثانویه. انواع واقعا سرد همه چیز شما می توانید با آن انجام دهد. 

انواع داده. در DynamoDB، ما هر دو کلیدی پشتیبانی ارزش و داده سند نوع. در سمت چپ صفحه نمایش در اینجا، ما نوع اساسی ما است. انواع ارزش کلیدی است. این رشته ها، اعداد و فایل های باینری. 

پس فقط سه نوع اساسی. و پس از آن شما می توانید مجموعه ای از آن داشته باشد. یکی از چیزهایی که خوب در مورد نواسکیوال است شما می توانید حاوی آرایه به عنوان خواص. و با DynamoDB شما می توانید حاوی آرایه از انواع عمومی به عنوان یک ویژگی ریشه. 

و پس از آن انواع سند وجود دارد. چگونه بسیاری از مردم با JSON آشنا هستند؟ شما بچه ها با JSON خیلی آشنا نیست؟ این اساسا جاوا اسکریپت، شی، نشانه گذاری. این اجازه می دهد تا شما را به اساسا تعریف یک ساختار سلسله مراتبی. 

شما می توانید یک سند JSON در فروشگاه DynamoDB با استفاده از اجزای مشترک و یا بلوک های ساختمان که در دسترس هستند در اکثر زبان های برنامه نویسی. بنابراین اگر شما جاوا، شما نگاه کردن به نقشه و لیست. من می توانید اشیاء ایجاد می کند که نقشه منطقه است. یک نقشه به عنوان ارزش های کلیدی به عنوان خواص ذخیره می شود. و این ممکن است لیست از ارزش ها در آن دسته از خواص. شما می توانید این مجموعه ذخیره ساختار سلسله مراتبی به عنوان یک ویژگی واحد از یک آیتم DynamoDB. 

بنابراین جداول در DynamoDB، مانند بسیاری از پایگاه داده های NoSQL، جداول اقلام است. در مانگودیبی شما را این اسناد است. و این امر می تواند پایه نیمکت. همچنین یک پایگاه داده سند. شما این اسناد است. اسناد و یا موارد دارای ویژگی های. ویژگی ها می توانند وجود داشته باشند یا در مورد وجود ندارد. در DynamoDB، وجود دارد یکی از ویژگی اجباری. فقط در یک پایگاه داده رابطه ای را دوست دارم، شما یک کلید اصلی در جدول. 

DynamoDB است آنچه که ما یک کلید هش پاسخ. کلید هش باید منحصر به فرد باشد. بنابراین، هنگامی که یک جدول هش را تعریف می کنم، اساسا من چه می گویم است هر آیتم یک کلید هش داشته باشد. و هر کلید هش باید منحصر به فرد باشد. 

هر آیتم تعریف شده است که کلید هش منحصر به فرد. و تنها می تواند یک باشد. این خوب است، اما اغلب چه مردم نیاز است که آنها می خواهند این هش کلیدی برای انجام یک کمی بیشتر از یک شناسه منحصر به فرد. اغلب اوقات ما می خواهیم به استفاده از این کلید هش به عنوان سطل تجمع سطح بالا است. و راه ما انجام این کار است اضافه کردن چیزی است که ما یک کلید وسیعی تماس بگیرید. 

بنابراین اگر آن را تنها یک هش است جدول، این باید منحصر به فرد باشد. اگر یک رشته هش و محدوده جدول در آن است، ترکیبی از هش و دامنه باید تک باشی. بنابراین فکر می کنم در مورد آن در این راه. اگر من یک انجمن. و فرم مباحث، آن را تا پست ها، و پاسخ آن است. 

بنابراین من ممکن است یک رشته هش شده اند کلید است که موضوع ID. و من ممکن است یک کلید وسیعی دارند، که ID پاسخ است. به این ترتیب اگر من می خواهم به همه پاسخ ها برای موضوع خاص، من فقط می توانید پرس و جو از هش. من فقط می توانم بگویم همه به من بدهید آیتم هایی که این هش. و من قصد دارم به هر سوال و یا ارسال برای آن موضوع خاص است. این واحدهای سطح بالا بسیار مهم است. آنها دسترسی ابتدایی پشتیبانی الگوی از نرم افزار. به طور کلی، این چیزی است که ما خواهید انجام دهید. ما می خواهیم که table-- به عنوان جدول باز می کنید، ما می خواهیم به ساختار داده ها در جدول به گونه ای است که می توانید نرم افزار بسیار سرعت بازیابی این نتایج. و اغلب در راه به انجام این کار است برای حفظ این واحدهای به عنوان ما وارد کردن داده. در واقع، ما در حال گسترش داده به سطل روشن به عنوان آن را در می آید. 

کلید محدوده اجازه می دهد هش me-- کلید باید برابری است. وقتی که من پرس و جو هش، باید بگویم من یک رشته هش که این برابر است. وقتی که من پرس و جو وسیعی، من می توانید می گویند من یک محدوده را است که استفاده از هر نوع اپراتور غنی است که ما حمایت می کنند. من تمام موارد برای یک رشته هش می دهد. آیا برابر، بیشتر از، کمتر از، آن را با شروع، آن بین این دو ارزش وجود دارد؟ بنابراین این نوع از نمایش داده شد وسیعی که ما همیشه در علاقه مند است. در حال حاضر یک چیز در مورد داده ها، هنگامی شما در دسترسی به اطلاعات، زمانی که نگاه شما دسترسی به داده ها، آن را همیشه در مورد تجمع. این همیشه در مورد سوابق که به این مربوط می شود. من همه چیز در اینجا را that's-- همه معاملات بر روی این کارت اعتباری در ماه گذشته. که تجمع است. 

تقریبا همه چیز شما در انجام پایگاه داده نوعی از تجمع است. بنابراین قادر بودن به قادر به تعریف این سطل و شما این را وسیعی ویژگی قادر به پرس و جو در، آن نمایش داده شد غنی پشتیبانی از بسیاری از، بسیاری از، بسیاری از الگوهای دسترسی به نرم افزار. 

بنابراین چیزی دیگر کلید هش ندارد آن را به ما می دهد یک مکانیسم قادر به گسترش اطلاعات در سراسر. پایگاه داده های NoSQL بهترین کار زمانی که داده ها به طور مساوی توزیع شده در سراسر خوشه. چگونه بسیاری از مردم آشنا هستند با الگوریتم های هش کردن؟ وقتی که من میگویم هش و یک hashing-- به دلیل یک الگوریتم هش کردن راهی که قادر به تولید است یک مقدار تصادفی از هر مقدار داده شده. بنابراین در این مورد خاص، الگوریتم هش ما اجرا ND 5 بر اساس است. 

و اگر من یک ID، و این کلید هش من است، من باید 1، 2، 3. وقتی که من الگوریتم هش اجرا شود، آن را به بازگشت و می گویند، خوب 1 برابر 7B، 2 برابر 48، 3 برابر CD. آنها در سراسر فضای کلید گسترش یافته است. و چرا شما این کار؟ از آنجا که باعث می شود که من می توانم قرار دادن پرونده گره های متعدد در سراسر. 

اگر من انجام این کار تدریجی، 1، 2، 3. و من یک وسیعی هش که اجرا می شود در این مورد خاص، یک فضای هش کوچک، آن را از 00 اجرا می شود به FF، پس از آن پرونده می رویم به در و آنها در حال رفتن به 1، 2، 3، 4، 5، 6، 7، 8، 9، 10، 11، 12. چه اتفاقی می افتد؟ هر درج است که به همان گره. شما ببینید من چه معناست؟ 

زیرا زمانی که من فضای تقسیم، و من این پرونده در سراسر، و پارتیشن من، من قصد دارم برای گفتن پارتیشن 1 دارای فضای کلیدی 0-54. پارتیشن 2 55-89 است. پارتیشن 3 AA به FF است. بنابراین اگر من با استفاده از خطی افزایش شناسه، شما می توانید ببینید که چه اتفاقی می افتد. 1، 2، 3، 4، 5، 6، تمام راه را تا به 54. بنابراین به عنوان من چکش سوابق به سیستم، همه چیز به پایان می رسد تا رفتن به یک گره. 

این خوب نیست. که antipattern است. در مانگودیبی آنها این مشکل اگر شما یک کلید هش استفاده نمی کند. مانگودیبی شما می دهد گزینه از هش ارزش کلیدی است. شما همیشه باید انجام دهید که اگر شما با استفاده از یک هش افزایش کلیدی در مانگودیبی، یا شما می شود استخوان هر نوشتن به یک گره، و شما خواهد شد محدود توان نوشتن خود را بد. 

رسید که A9 169 در مبنای ده؟ 

RICK HOULIHAN: آره، آن را در جایی در اطراف وجود دارد. A9، من نمی دانم. شما می خواهم که به من باینری به ماشین حساب دهدهی. مغز من را مثل کار نمی کند. مخاطبان: فقط یکی از سریع نظرات Mongo ها خود را. بنابراین ID شی که می آید این است بومی با Mongo ها انجام این کار؟ RICK HOULIHAN: آیا انجام این کار؟ اگر شما آن را مشخص کنید. با مانگودیبی، شما باید گزینه. شما می توانید هر سند specify-- مانگودیبی است باید ID زیرین. که ارزش منحصر به فرد است. 

در مانگودیبی شما می توانید مشخص آیا به آن هش یا نه. آنها فقط شما این گزینه را. اگر شما می دانید که آن را تصادفی، مشکلی ندارد. شما لازم نیست برای انجام این کار. اگر شما می دانید که آن را به صورت تصادفی نیست، که آن را افزایش، پس از آن انجام هش. 

در حال حاضر چیزی که در مورد هش کردن، هنگامی که شما هش value-- و این است که چرا کلید هش همیشه نمایش داده شد منحصر به فرد، چرا که من را تغییر داده ام ارزش، در حال حاضر من می توانم یک پرس و جو وسیعی نیست. من نمی توانم بگویم این است بین این یا آن، به این دلیل که مقدار هش است که نمی به معادل ارزش واقعی. تا زمانی که شما هش که کلید، آن را تنها برابری می شود. این است که چرا در DynamoDB کلید هش نمایش داده شد همیشه تنها برابری است. 

بنابراین در حال حاضر در طیف وسیعی key-- وقتی که من اضافه کنم که کلیدی محدوده، کسانی که ثبت کلیدی وسیعی در می آیند و آنها بر روی همان پارتیشن ذخیره می شود. به طوری که آنها به سرعت هستند، به راحتی بازیابی چرا که این هش، این محدوده است. و شما همه چیز را ببینید با هش همان می شود در فضای همان پارتیشن ذخیره می شود. شما می توانید که کلید وسیعی برای کمک به استفاده از قرار دادن داده خود را نزدیک به پدر و مادر خود. پس چه هستم من واقعا انجام می دهند؟ این یک رابطه بسیاری است. رابطه بین یک کلید هش و کلید محدوده به بسیاری است. من می توانم کلید های متعدد هش داشته باشد. من فقط می توانم چند دامنه دارند کلید در هر کلید هش. 

هش پدر و مادر تعریف می کند، محدوده کودکان تعریف می کند. بنابراین شما می توانید ببینید که در اینجا وجود دارد آنالوگ بین ساختار رابطه ای و به همان نوع از سازه ها در نواسکیوال. مردم می گویند نواسکیوال به عنوان nonrelational. آن nonrelational است. اطلاعات همواره روابط. این روابط تنها متفاوت مدل شده است. اجازه دهید کمی صحبت کمی در مورد دوام. زمانی که شما به DynamoDB ارسال، می نویسد همیشه سه راه تکرار شود. به این معنی که ما سه AZ است. در AZ می مناطق در دسترس بودن. شما می توانید از یک در دسترس فکر می کنم منطقه به عنوان یک مرکز داده و یا مجموعه ای از مراکز داده. این چیزها از لحاظ جغرافیایی جدا از یکدیگر در مناطق گسل های مختلف، در سراسر شبکه های قدرت های مختلف و دشت های سیلابی. شکستی در یک AZ است رفتن به پایین است. آنها همچنین در ارتباط همراه با فیبر تاریک. این پشتیبانی از یک زیر 1 تاخیر میلی ثانیه بین گاز. بنابراین زمان واقعی تکرار داده قادر است در چند گاز. 

و استقرار اغلب چند AZ دیدار با الزامات دسترس بودن بالا اغلب سازمان های شرکت. بنابراین DynamoDB گسترده شده است در سراسر سه گاز به طور پیش فرض. ما تنها به دانش نوشتن رفتن زمانی که دو از این سه گره دوباره و می گویند، بله، من آن را کردم. چرا چنین است؟ از آنجا که در کنار خواندن ما تنها رفتن به شما داده را به زمانی که ما آن را از دو گره را دریافت کنید. 

اگر من تکرار در سراسر سه، و من از دو خواندن، من همیشه تضمین شده به حداقل یک از آن می خواند می شود ترین کپی فعلی از داده ها. این چیزی است که DynamoDB سازگار است. در حال حاضر شما می توانید انتخاب کنید به نوبه خود آن سازگار می خواند است. که در این صورت من قصد دارم برای گفتن، من فقط از یک گره به عنوان خوانده شده. و من نمی توانم آن را تضمین به داده های فعلی است. 

بنابراین اگر یک نوشتن در آینده، آن تکرار نشده است، شما در حال رفتن برای دریافت کنید که کپی. که در نهایت به عنوان خوانده شده سازگار است. و چه چیزی است که نیمی از هزینه است. پس این چیزی به فکر کردن در مورد. هنگامی که شما در حال خواندن DynamoDB، و شما راه اندازی ظرفیت خواندن خود را واحد، اگر شما انتخاب در نهایت سازگار شده است، آن را بسیار ارزان تر است، آن را حدود نیمی از هزینه است. 

و پس از آن موجب صرفه جویی در پول شما. اما این انتخاب شما است. اگر شما می خواهید به عنوان خوانده شده سازگار و یا در نهایت به عنوان خوانده شده سازگار است. این چیزی است که شما می توانید انتخاب کنید. 

بیایید در مورد شاخص های صحبت کنید. بنابراین ما به ذکر است که تجمع سطح بالا است. ما کلید هش کردم، و ما کلید وسیعی کردم. این خوبه. و این بر روی میز اولیه، من کردم یک کلید هش، من یک کلید وسیعی است. 

معنی آن چیست؟ من یک ویژگی کردم که من می توانید نمایش داده ثروتمندان علیه اجرا کنید. این کلید محدوده است. ویژگی های دیگر که item-- من می توانم در آن ویژگی ها را فیلتر کند. اما من می تواند چیزهایی مانند انجام نشده است، آن را با آغاز می شود، و یا بزرگتر از. 

چگونه می توانم انجام دهم؟ من یک شاخص. این دو نوع وجود دارد شاخص ها در DynamoDB. شاخص است که واقعا نظر دیگری از جدول. و شاخص ثانویه محلی است. 

یکی از اولین ما در مورد صحبت کنید. بنابراین ثانویه محلی همزیستی بر روی همان پارتیشن به عنوان داده. و به عنوان مثل، آنها در هستند گره های فیزیکی است. آنها آنچه ما تماس بگیرید سازگار است. معنا، آنها اذعان خواهد نوشتن همراه با جدول. زمانی که نوشتن در می آید، ما از طریق شاخص ارسال. ما تا ارسال به جدول، و پس از آن ما اذعان خواهد شد. به طوری که سازگار است. هنگامی که نوشتن است اذعان از جدول، آن تضمین شده است که صفحه اول متوسطه محلی خواهد دید همان داده است. اما آنچه آنها به شما اجازه انجام دهید این است تعریف کلید وسیعی جایگزین. 

مجبور به استفاده از هش همان کلید را به عنوان جدول اولیه، چرا که آنها به شرکت واقع در همان پارتیشن، و آنها سازگار است. اما من می تواند یک شاخص ایجاد با کلید های مختلف برد. بنابراین برای مثال، اگر من به حال یک تولید کننده که تا به حال یک جدول قطعات خام در آینده. و قطعات خام در آمده است، و آنها توسط مجمع جمع شده است. و شاید یک فراخوان وجود دارد. 

هر بخشی که توسط این ساخته شده بود تولید کننده پس از این تاریخ، من نیاز به از خط من بکشید. من می توانم یک شاخص چرخش خواهد بود که به دنبال، جمع آوری در تاریخ تولید آن بخش خاص است. بنابراین اگر جدول سطح بالا بود در حال حاضر توسط کارخانه سازنده درهم، شاید آن را در قسمت ID تنظیم شده بود، من می تواند یک شاخص خاموش که جدول ایجاد که توسط کارخانه سازنده درهم و رویداد در محدوده زمانی در تاریخ تولید. و به این ترتیب من می توانم بگویم، هر چیزی را که بین این تاریخ ساخته شده بود، من نیاز به از خط بکشید. به طوری که شاخص ثانویه محلی است. 

این اثر از محدود کردن فضای کلید هش خود را. از آنجا که آنها همزیستی در گره ذخیره سازی همان، آنها کلید هش محدود فضای 10 گیگابایت است. DynamoDB، تحت جداول، پارتیشن جدول خود را هر 10 گیگابایت است. هنگامی که شما 10 گیگابایت از داده ها در، ما رفتن [PHH]، و ما اضافه کردن گره دیگر است. 

ما را به LSI تقسیم نشده پارتیشن های متعدد در سراسر. ما در جدول را تقسیم می شود. اما ما را به LSI تقسیم نشده است. بنابراین این چیزی است که مهم است که درک است اگر شما در حال انجام بسیار، بسیار، واحدهای بسیار بزرگ، پس از آن شما در حال رفتن به محدود شود 10 گیگابایت در LSIS خود را. 

اگر چنین است، ما می توانیم استفاده ثانویه جهانی است. ثانویه جهانی واقعا یکی دیگر از جدول. آنها را به طور کامل وجود داشته باشد سمت از جدول اولیه خود را. و آنها به من اجازه پیدا کردن یک ساختار کاملا متفاوت است. پس از آن به فکر می کنم به عنوان داده های در حال درج به دو جدول مختلف، ساختار به دو روش مختلف. 

من می توانم کاملا تعریف کلید هش متفاوت است. من می توانم کاملا تعریف کلید محدوده های مختلف. و من می توانم این اجرا به طور کامل مستقل. به عنوان یک ماده در واقع، من مشروط ظرفیت خوانده شده و ارسال ظرفیت برای من شاخص ثانویه جهانی به طور کامل مستقل جدول اصلی من. اگر که شاخص را تعریف می کنم، من به آن چه مقدار خواندن و نوشتن ظرفیت آن را به توان با استفاده از. 

و جداگانه است از جدول اصلی من. حالا هر دو از شاخص ما اجازه می دهد به هش و وسیعی کلید نه تنها تعریف، اما آنها ما را اجازه می دهد تا پروژه ارزش اضافی. بنابراین اگر من می خواهم به خواندن کردن شاخص، و من می خواهم به گرفتن برخی از مجموعه ای از داده ها، من لازم نیست برای رفتن به اصلی جدول برای دریافت ویژگی های اضافی. من می توانم آن اضافی پروژه ویژگی های به جدول برای حمایت از الگوی دسترسی. من می دانم که ما در حال احتمالا به برخی از گرفتن واقعا، really-- وارد شدن به علف های هرز در اینجا بر روی برخی از این مسائل. در حال حاضر من بی اراده کار کردن این است. 

مخاطبان: [نامفهوم] کلید --table به معنای یک رشته هش بود؟ هش اصلی؟ چند اسلاید؟ 

RICK HOULIHAN: بله. بله. کلید جدول اساسا برگشت به مورد اشاره می کند. بنابراین شاخص یک اشاره گر است به موارد اولیه بر روی میز. در حال حاضر شما می توانید انتخاب کنید برای ساخت یک شاخص است که فقط کلید جدول، و هیچ خواص دیگر است. و به همین دلیل ممکن است من که؟ خب، شاید من آیتم ها بسیار بزرگ است. 

من واقعا فقط نیاز به دانستن which-- الگوی دسترسی من ممکن است بگویید، که آیتم های حاوی این ملک؟ لازم نیست برای بازگشت به آیتم استفاده کنید. من فقط نیاز به دانستن که شامل موارد آن است. بنابراین شما می توانید ایندکس ساخت که تنها کلید جدول داشته باشد. 

اما این در درجه اول چه شاخص در پایگاه داده است. آن را برای سرعت قادر به است شناسایی که سوابق، که ردیف، که آیتم ها در جدول داشته خواص است که من در جستجوی. 

GSIs، پس چگونه کار می کنند؟ GSIs اساسا آسنکرون می باشد. به روز رسانی به جدول می آید، جدول است و سپس به روز ناهمگام همه GSIs خود را. به همین دلیل است GSIs هستند در نهایت سازگار است. 

این مهم است که توجه داشته باشید که وقتی شما در حال ایجاد GSIs، و شما را در درک شما در حال ایجاد بعد دیگری از aggregation-- حالا می گویند یک مثال خوب در اینجا یک تولید کننده است. من فکر می کنم من ممکن است در مورد صحبت کردیم تولید کننده دستگاه های پزشکی. تولید کنندگان دستگاه پزشکی اغلب قطعات سریال. قسمت های که به رفتن جراحی تعویض مفصل لگن همه یک شماره سریال کمی بر روی آنها. و آنها می توانند میلیون و میلیون ها و میلیاردها قطعات در تمام دستگاه های که آنها کشتی. خب، آنها نیاز به دانه ها در ابعاد مختلف، تمام قطعات در مجلس موسسان، تمام قطعات ساخته شده است که بود در یک خط خاص، همه قسمت های که آمد از یک تولید کننده خاص در یک تاریخ خاص. و این واحدهای گاهی اوقات تا به میلیاردها. 

بنابراین من با برخی از کار این بچه ها که رنج می برند چرا که آنها در حال ایجاد این واحدهای ginormous در شاخص ثانویه است. آنها ممکن است یک قسمت خام جدول است که می آید به عنوان تنها هش. هر بخش دارای یک شماره سریال منحصر به فرد. من با استفاده از شماره سریال به عنوان هش. زیباست. من جدول داده های خام گسترده شده است در سراسر فضای کلید. [من؟ ارسال؟] [؟ مصرف؟] بسیار جذاب است. من را به مقدار زیادی از داده ها. سپس آنچه انجام می دهند این است که آنها ایجاد یک GSI. و من می گویم، شما می دانید چه، من نیاز به مراجعه به تمام قطعات برای این تولید کننده است. خب، همه ناگهانی من گرفتن یک میلیارد ردیف، و چیزهای آنها را بر روی یک گره، چرا که وقتی من به عنوان جمع ID سازنده به عنوان هش، و تعداد بخش را به عنوان محدوده، پس از آن همه از ناگهانی من قرار دادن یک میلیارد قطعات به آنچه این تولید کننده به من تحویل داده است. 

که می تواند بسیاری باعث فشار بر GSI، دوباره، چرا که من یک گره چکش. من قرار دادن تمام این وارد یک گره. و واقعی مورد استفاده مشکل ساز است. در حال حاضر، من یک طراحی خوب الگوی برای شما اجتناب از آن. و این یکی از مشکلات است که من همیشه با کار. اما چه اتفاقی می افتد، آیا GSI ممکن ظرفیت نوشتن به اندازه کافی ندارد قادر به فشار همه کسانی که ردیف به یک گره منفرد. و پس از آن چه اتفاقی می افتد است اولیه، جدول مشتری، جدول اولیه باشد متوقف خواهد به این دلیل که GSI نمی تواند نگه داشتن. بنابراین، میزان درج من خواهد سقوط در جدول اصلی به عنوان GSI من سعی می کند. 

همه حق است، بنابراین در GSI، در LSI، که یکی باید استفاده کنم؟ در LSI سازگار می باشد. در GSI در نهایت سازگار است. در صورتی که OK، توصیه میکنم با استفاده از یک GSI، آنها بسیار انعطاف پذیر تر است. در LSI می توان به عنوان یک سازمان مدل شده است. و اگر به اندازه داده در هر کلید هش در مجموعه خود را بیش از 10 گیگابایت، پس از آن شما به خواهید به استفاده از آن GSI دلیل آن را فقط یک حد سخت است. 

همه حق است، بنابراین پوسته پوسته شدن. توان عملیاتی در دینامو DB، شما ارائه می [نامفهوم] توان به یک جدول. ما به مشتریان که مشروط 60 billion-- انجام می دهند 60 میلیارد درخواست، به طور منظم در حال اجرا در بیش از یک میلیون درخواست در هر ثانیه در جدول ما. واقعا وجود ندارد حد نظری به چه مقدار و با چه سرعتی جدول می توانید در دینامو DB اجرا کنید. برخی از نرم وجود دارد محدودیت در حساب شما که ما در قرار دادن وجود دارد بنابراین که شما نمی رویم دیوانه. اگر می خواهید بیش از که، نه یک مشکل. شما می آیند به ما بگویید. ما به نوبه خود تا شماره گیری. 

هر حساب به برخی از سطح محدود در هر سرویس، فقط کردن خفاش به طوری که مردم نمی رویم دیوانه به دردسر خود را دارند. هیچ محدودیتی در اندازه. شما می توانید هر تعداد قرار داده از اقلام در یک جدول. اندازه یک آیتم است محدود به هر 400 کیلوبایت، که می تواند مورد مشخصه باشد. بنابراین در مجموع تمام صفات است که 400 کیلوبایت محدود شده است. و سپس دوباره، ما باید مسئله ای است که کمی LSI با حد 10 گیگابایت در هر هش. مخاطبان: تعداد کوچک، من گم شده چه شما به من گفتن که is-- مخاطبان: اوه، 400 کیلوبایت حداکثر اندازه در هر مورد است. بنابراین یک مورد دارای تمام ویژگی های. بنابراین 400 K اندازه کل است که در مورد، 400 کیلوبایت. بنابراین از تمام ویژگی های ترکیب، تمام داده ها که در تمام آن دسته از صفات، تا به یک اندازه کل نورد، در حال حاضر امروز حد مورد 400 k است. بنابراین پوسته پوسته شدن دوباره، به دست آورد از طریق پارتیشن بندی. توان مشروط است در سطح جدول. و واقعا وجود دارد دو دستگیره. ما ظرفیت را خوانده و ارسال ظرفیت. 

بنابراین این تنظیم مستقل از یکدیگر. اندازه گیری RCU به شدت سازگار می خواند. خوب، پس اگر شما می گویید من می خواهم 1،000 کسانی که RCU به شدت سازگار باشد، آن سازگار می خواند. اگر شما بگویم من می خواهم نهایی سازگار می خواند، شما می توانید ارائه 1،000 در RCU، شما در حال رفتن به 2،000 نهایت سازگار می خواند. و نیمی از قیمت برای کسانی که در نهایت شامل در می خواند. 

باز هم، تنظیم مستقل از یکدیگر. و آنها را به throughput-- اگر شما مصرف 100٪ RCU خود را، شما در حال رفتن به تاثیر در دسترس بودن از حقوق خود را. بنابراین آنها به طور کامل مستقل از یکدیگر. همه حق است، به طوری که یکی از چیزهایی که من به ذکر خلاصه شد گلوگاه. گلوگاه بد است. گلوگاه بد نشان می دهد هیچ SQL. چیزهایی که ما می توانیم برای کمک وجود دارد شما در گلوگاه کاهش که شما در حال تجربه. اما بهترین راه حل این است اجازه دهید یک در آنچه شما انجام نگاه کنید، چرا یک ضد الگوی در بازی وجود دارد. 

این چیزها، چیزهایی مانند غیر یکنواخت حجم کار، کلید های داغ، پارتیشن گرم است. من هدف قرار دادن یک فضای کلید خاص بسیار سخت برای برخی از دلیل خاص است. چرا من انجام این کار؟ بیایید که در شکل خارج. من مخلوط کردن داده های گرم من با داده های سرد است. من اجازه جداول من بزرگ است، اما واقعا وجود دارد تنها برخی زیر مجموعه از داده که واقعا برای من جالب. بنابراین برای اطلاعات ورود به سیستم، برای مثال، بسیاری از مشتریان، آنها ورود داده ها هر روز. آنها مقدار زیادی از اطلاعات ورود به سیستم است. 

اگر شما فقط آزادسازی که ورود به سیستم اطلاعات در یک جدول بزرگ، در طول زمان که جدول را رفتن به عظیم. اما من واقعا تنها در علاقه مند هستم 24 ساعت گذشته، هفت روز گذشته، 30 روز گذشته. هر پنجره از زمان که من علاقه مند به دنبال من برای این رویداد که مرا اذیت، و یا این رویداد که برای من جالب، که پنجره تنها زمانی که من نیاز است. پس چرا من قرار دادن 10 سال ارزش اطلاعات ورود به سیستم در جدول؟ چه که باعث شده است جدول قطعه. 

این می شود بزرگ است. آن شروع می شود گسترش در سراسر هزاران گره. و از آنجایی که ظرفیت خود را چنان نازل است، شما در واقع در هر محدود کردن رای یکی از کسانی که گره های فردی. بنابراین شروع به دنبال چگونه اجازه ما رول که بیش از جدول. چگونه ما مدیریت است که داده ها کمی بهتر است برای جلوگیری از این مشکلات. و چه می کند که نگاه می کنید؟ این چیزی است که که به نظر میرسد. این چیزی است که بد نواسکیوال نظر می رسد. 

من یک کلید جدید به اینجا رسیدیم. اگر شما در سمت اینجا نگاه کنید، این تمام پارتیشن های من هستند. من 16 تا پارتیشن کردم اینجا در این پایگاه داده خاص است. ما این کار را تمام وقت. من این اجرا برای مشتریان در تمام دوران. این نقشه حرارتی نامیده می شود. نقشه گرما به من می گوید که چگونه شما را دسترسی به فضای کلید خود را. و این است به من گفتن است که یکی هش خاص وجود دارد که این پسر دوست خیلی افتضاح، چرا که او هدف قرار دادن آن واقعا، واقعا سخت است. 

بنابراین رنگ آبی زیبا است. ما دوست داریم آبی رنگ است. ما دوست قرمز است. که در آن فشار سرخ می شود تا به 100٪. 100٪، در حال حاضر شما در حال رفتن به متوقف شود. بنابراین هر زمان که شما هر خطوط قرمز مانند this-- و آن را فقط دینامو DB-- نیست هر پایگاه داده های NoSQL است این مشکل است. ضد الگوها وجود دارد که می تواند رانندگی این نوع از شرایط. آنچه که من انجام است با مشتریان کار برای کاهش این شرایط است. 

و چه می کند که نگاه می کنید؟ و این است که گرفتن بیشتر از توان دینامو DB، اما واقعا گرفتن بیشتر از نواسکیوال. این است که به دینامو محدود نمی شود. این من definitely-- است مورد استفاده برای کار در Mongo ها. من با بسیاری از سیستم عامل های NoSQL آشنا هستم. هر کس این نوع از مشکلات کلیدی داغ. برای دریافت بیشتر از هر نواسکیوال پایگاه داده، به طور خاص دینامو DB، شما می خواهید برای ایجاد جداول که در آن عنصر کلیدی هش است تعداد زیادی از ارزش های متمایز، درجه بالایی از کاردینالیتی. این یعنی من نوشتن به تعداد زیادی از سطل های مختلف. 

سطل تر من نوشتن به، بیشتر احتمال دارد من به گسترش است که بار نوشتن هستم و یا به عنوان خوانده شده بار از گره های متعدد در سراسر، بیشتر احتمال دارد من به یک توان بالا روی میز. و پس از آن من می خواهم ارزش به درخواست نسبتا به طور مساوی در طول زمان و یکنواخت به طور تصادفی به عنوان امکان پذیر است. خب، این نوع از جالب توجه است، چون من نمی توانم واقعا کنترل هنگامی که کاربران آمده. بنابراین کافی است، اگر ما گسترش همه چیز از سراسر فضای کلید، ما احتمالا در شکل بهتر باشد. 

یک خاصی وجود دارد مقدار زمان تحویل که شما در حال رفتن به کنترل قادر. ولی برای کسانی که واقعا دو بعد است که ما، فضا، دسترسی به طور مساوی گسترش، زمان، درخواست پس از رسیدن به طور مساوی در زمان فاصله. و اگر آن دو شرایط می شوند، پس از آن که آنچه در آن است رفتن به مانند نگاه کنید. این است که بسیار بهتر است. ما در اینجا واقعا خوشحال هستیم. ما یک الگوی دسترسی بسیار حتی کردم. آره، شاید شما در حال گرفتن فشار کمی در هر حال حاضر و پس از آن، اما هیچ چیز واقعا بیش از حد گسترده. بنابراین آن را شگفت انگیز چند بار، زمانی که من با مشتریان کار که نمودار برای اولین بار با قرمز بزرگ نوار و تمام است که زشت زرد آن همه جا، ما با این ورزش انجام می شود پس از چند ماه دوباره معماری، آنها در حال اجرا به همان دقیق حجم کار در همان بار دقیق. و این چیزی است آن را به دنبال مانند اکنون. بنابراین آنچه که شما با گرفتن یک نواسکیوال طرح داده است که کاملا گره خورده است به الگوی دسترسی. 

و شما می توانید طرح داده بهینه سازی برای حمایت از این الگوی دسترسی داشته باشید. اگر اینکار را نکنید، پس از آن شما در حال رفتن برای دیدن آن نوع از مشکلات با کسانی که کلید های داغ. 

مخاطبان: خب، به ناچار بعضی از نقاط در حال رفتن به داغ تر از دیگران است. 

RICK HOULIHAN: همیشه. همیشه. آره، من همیشه وجود دارد a-- و دوباره، وجود دارد برخی از الگوهای طراحی ما از طریق دریافت که در مورد چگونه شما برخورد صحبت با این واحدهای فوق العاده بزرگ است. منظور من، من به آنها، ما چگونه با آنها برخورد کنیم؟ من یک مورد استفاده بسیار خوب که ما در مورد آن صحبت برای. 

همه حق است، بنابراین اجازه دهید بحث در مورد برخی از مشتریان در حال حاضر. این بچه ها هستند AdRoll. من نمی دانم اگر شما با AdRoll. شما احتمالا آنها را ببینید زیادی به مرورگر. آنها تبلیغ دوباره هدف قرار دادن هستید، آنها بزرگترین کسب و کار آگهی مجدد با هدف قرار دادن خارج وجود دارد. آنها به طور معمول به طور منظم اجرا بیش از 60 میلیارد معاملات در هر روز. آنها در حال انجام بیش از یک میلیون معاملات در هر ثانیه. یک میز بسیار ساده ام ساختار، شلوغ ترین جدول. این اساسا فقط یک کلید هش کوکی است، محدوده جمعیتی است دسته، و سپس ویژگی سوم نمره است. 

بنابراین همه ما در کوکی مرورگر خود را از این بچه ها. و هنگامی که شما به یک رفتن شرکت های تجاری، آنها اساسا نمره شما در سراسر دسته بندی های مختلف جمعیتی. هنگامی که شما را به یک وب سایت و به شما می گویند من می خواهم برای دیدن این ad-- و یا اساسا شما that-- می گویند اما زمانی که شما به وب سایت آنها می گویند شما می خواهید برای دیدن این آگهی. و آنها به که آگهی از AdRoll. AdRoll شما به نظر می رسد تا در جدول خود را. آنها کوکی خود را پیدا کنید. تبلیغ گفتن آنها، من می خواهم کسی که میانسال، مرد 40 ساله، به ورزش. و آنها نمره شما در آن جمعیت و آنها تصمیم می گیرید یا نه که یک آگهی خوب برای شما است. 

در حال حاضر آنها با SLA ارائه دهندگان تبلیغات خود را به ارائه زیر 10 میلی ثانیه پاسخ در هر درخواست تنها. بنابراین آنها با استفاده از دینامو DB برای این. آنها به ما ضربه میلیون درخواست در هر ثانیه. آنها قادر به انجام تمام هستید خود جستجوها، تریاژ که داده ها، و دریافت که اضافه کردن لینک به آن تبلیغ در کمتر از 10 میلی ثانیه است. این واقعا خیلی فوق العاده پیاده سازی است که آنها داشته باشند. 

این بچه ها actually-- بچه ها این. من مطمئن هستم که اگر آن را به این بچه ها نیست. ممکن است این بچه ها. اساسا us-- گفت نه، من فکر نمی کنم آن آنها بود. من فکر می کنم کسی دیگر بود. من با یک کار مشتری که به من گفت که اکنون که آنها را رفته به دینامو DB، آنها صرف پول بیشتر در اسنک برای تیم توسعه خود را هر ماه از آنها در پایگاه داده خود را صرف. پس از آن به شما می دهد ایده صرفه جویی در هزینه که شما می توانید در دینامو DB گرفتن بزرگ است. همه حق است، Dropcam در یک شرکت دیگر است. این مرد نوع of-- اگر شما فکر می کنم اینترنت از چیزهایی، Dropcam در است که اساسا ویدیو های امنیتی اینترنت. شما با قرار دادن دوربین خود را خارج وجود دارد. دوربین دارای یک آشکارساز حرکت. کسی پیش می آید، باعث یک نقطه نشانه. دوربین شروع به ضبط در حالی که برای تا آن را از هیچ حرکت را تشخیص نیست. قرار می دهد که فیلم بر روی اینترنت است. 

Dropcam در یک شرکت است که اساسا به دینامو DB روشن زیرا آنها تجربه شد دردهای بزرگی در حال رشد. و آنچه را که به ما گفت، به طور ناگهانی از داده پتابایت. آنها به حال هیچ ایده خدمات خود را خواهد بود تا موفق است. ویدیو های ورودی بیش از یوتیوب است آنچه که این افراد در حال گرفتن. آنها با استفاده از DynamoDB برای پیگیری همه ابرداده در تمام نقاط کلیدی ویدئویی خود را. 

به طوری که آنها سطل S3 آنها فشار تمام مصنوعات باینری را به. و بعد آنها را سوابق دینامو DB که نقطه مردم به آن S3 سه اشیاء. زمانی که آنها نیاز به یک ویدیو نگاه کنید، آنها نگاه کردن رکورد در دینامو DB. آنها روی لینک کلیک کنید. آنها پایین کشیدن تصویری از S3. بنابراین این نوع از آنچه به نظر میرسد این است. و این است که مستقیما از تیم خود. 

دینامو DB را کاهش می دهد خود زمان تحویل برای حوادث ویدئو از پنج تا 10 ثانیه است. در فروشگاه رابطه قدیمی خود را، آنها استفاده می شود برای رفتن و اجرای چند نمایش داده شد پیچیده به شکل که فیلم ها را به جلو و پایین، به کمتر از 50 میلی ثانیه است. بنابراین آن را شگفت انگیز، شگفت انگیز عملکرد چقدر شما می توانید زمانی که شما بهینه سازی و لحن شما در پایگاه داده های اساسی برای حمایت از الگوی دسترسی. آپدیتی که Halfbrick، این بچه ها، آنچه در آن است، میوه نینجا من حدس می زنم چیزی است. که همه قابل اجرا بر روی دینامو DB. و این افراد، آنها بزرگ هستند تیم توسعه، توسعه بزرگ مغازه. 

یک تیم عملیات خوب است. آنها مقدار زیادی ندارد منابع بهره برداری است. آنها تلاش می کردند تلاش برای نگه داشتن زیرساخت های نرم افزار خود را تا و در حال اجرا. آنها به ما آمد. آنها در آن دینامو DB نگاه کرد. آنها گفتند که برای ما. آنها طیف خود ساخته شده است چارچوب برنامه بر روی آن. برخی از نظرات واقعا خوب در اینجا از تیم بر روی توانایی خود به حال در ساختمان تمرکز بازی و نه نیاز به حفظ زیرساخت ها، که تبدیل شدن به یک مقدار زیادی سربار برای تیم خود. پس این چیزی است that-- بهره مند است که شما از دینامو DB دریافت کنید. 

همه حق است، از وارد شدن به مدل سازی داده ها در اینجا. و ما صحبت کردیم کمی در مورد این یکی به یک، یک به چند، و بسیاری به بسیاری از روابط نوع. و چگونه شما می کسانی که در دینامو حفظ کند. در دینامو DB استفاده می کنیم شاخص، به طور کلی، به چرخش داده ها از یک عطر و طعم به طرف دیگر. کلید هش، کلید برد، و شاخص. 

در این خاص به عنوان مثال، به عنوان بسیاری از ایالت یک نیاز صدور مجوز که تنها مجوز یک راننده در هر فرد. شما نمی توانید به به دو راننده مجوز در ایالت بوستون. من می توانم آن در تگزاس نیست. این نوع از راه آن است. و به این ترتیب در DMV، ما باید جستجوها، ما خواهید به نگاه کردن مجوز رانندگی شده توسط تعدادی امنیت اجتماعی است. من می خواهم به نگاه کردن به جزئیات کاربران توسط شماره مجوز راننده است. 

بنابراین ما ممکن جدول یک کاربر که دارای یک کلید هش در شماره سریال، و یا شماره امنیت اجتماعی، و ویژگی های مختلف در مورد تعریف شده است. در حال حاضر در جدول که می تواند یک تعریف که GSI flips یک که در اطراف است که می گوید من می خواهم یک کلید هش در مورد مجوز و پس از آن همه موارد دیگر. در حال حاضر اگر من می خواهم به پرس و جو و پیدا کردن شماره مجوز برای هر اجتماعی داده شماره امنیت، من می توانم پرس و جو از جدول اصلی. 

اگر من می خواهم به پرس و جو و من می خواهم برای دریافت امنیت اجتماعی شماره و یا ویژگی های دیگر توسط تعداد مجوز، من می توانم GSI پرس و جو. این مدل که یکی است به یک رابطه. فقط یک GSI بسیار ساده است، تلنگر آن چیزهایی که در اطراف. در حال حاضر، حدود یک صحبت به بسیاری از. به بسیاری است که اساسا کلید وسیعی هش خود را. که در آن ما یک مقدار زیادی با این مورد استفاده از داده مانیتور است. داده مانیتور می آید در به طور منظم فاصله، مانند اینترنت از چیزهایی است. ما همیشه این را دریافت کنید سوابق آینده در تمام وقت. 

و من می خواهم برای پیدا کردن همه خوانش بین یک دوره زمانی خاص. این یک پرس و جو بسیار معمول است در این زیرساخت های نظارت. راه رفتن در مورد این است که برای پیدا کردن یک ساختار جدول ساده، یک جدول. من یک جدول اندازه گیری دستگاه را با یک کلید هش در ID دستگاه. و من یک کلید وسیعی دارند در برچسب زمان، یا در این مورد، حماسه. و من اجازه می دهد پیچیده اجرا نمایش داده شد در برابر آن کلیدی وسیعی و بازگشت کسانی که ثبت که نسبت به نتیجه مجموعه ای که من به دنبال. و آن را می سازد که به رابطه بسیاری از به جدول اولیه با استفاده از کلید هش، ساختار کلید برد. 

به طوری که این نوع از ساخته شده است به جدول در دینامو DB. هنگامی که یک رشته هش را تعریف می کنم و محدوده t جدول، من تعریف یک رابطه بسیاری از. این یک رابطه پدر و مادر کودک است. 

اجازه دهید در مورد بسیاری از صحبت به بسیاری از روابط است. و برای این مثال خاص، دوباره، ما قصد داریم به استفاده از GSI. و اجازه دهید در مورد بازی صحبت سناریو که در آن من یک کاربر داده شده است. من می خواهم برای پیدا کردن تمام بازی های که او برای بازی در ثبت نام یا. و برای یک بازی داده می شود، من می خواهید برای پیدا تمام کاربران. پس چگونه انجام دهم؟ من جدول بازی های کاربر، من قصد دارم به یک کلید هش از شناسه کاربری و یک کلید وسیعی از بازی ها. 

بنابراین کاربر می تواند بازی های متعدد داشته باشد. این یکی به رابطه بین بسیاری از این کاربر و بازی او بازی می کند. و سپس بر روی GSI، من که در اطراف شما تلنگر. من در بازی هش و من در کاربر. بنابراین اگر من می خواهم به همه بازی کاربر در حال بازی در، من جدول اصلی را پرس و جو. اگر من می خواهم به همه کاربران هایی که در بازی یک بازی خاص، من پرس و جو از GSI. بنابراین شما ببینید که چگونه ما انجام این کار؟ شما ساخت به حمایت از این سازمان ها در مورد استفاده، نرم افزار، دسترسی الگو، نرم افزار. 

اگر من نیاز به پرس و جو در این بعد، اجازه دهید من یک شاخص در آن بعد ایجاد کنید. اگر من، نه برای من مهم نیست. و بسته به مورد استفاده، من ممکن است شاخص و یا نیاز به من ممکن نیست. اگر این یکی از ساده به بسیاری از، جدول اولیه خوب است. اگر من نیاز به انجام این بسیاری از به بسیاری از، و یا من نیاز به انجام یک به آنهایی که، پس از آن شاید من لازم دوم شاخص. پس از آن همه بستگی به آنچه که من در تلاش برای انجام و آنچه من در تلاش برای به دست آوردن انجام شده است. 

احتمالا من قصد ندارم به صرف بیش از زمان زیادی صحبت کردن در مورد اسناد و مدارک. این می شود کمی، احتمالا، عمیق تر از ما نیاز به رفتن به. بیایید بحث کمی پرس و جو در مورد غنی بیان. بنابراین در دینامو DB ما توانایی ایجاد آنچه که ما عبارت طرح ریزی پاسخ. عبارت پروجکشن به سادگی چیدن زمینه و یا ارزش که شما می خواهید برای نمایش ندارد. خوب، پس من را انتخاب کنید. من پرس و جو در برابر دینامو DB است. و من می گویم، شما می دانید چه، نشان می دهد من تنها بررسی های پنج ستاره برای این محصول خاص است. به طوری که تمام من می خواهم برای دیدن. من نمی خواهم برای دیدن همه ویژگی های دیگر از ردیف، من فقط می خواهم به این. این درست مثل وقتی که شما در SQL می گویند ستاره را انتخاب کنید یا از جدول، شما همه چیز را دریافت کنید. وقتی که من می گویند نام انتخاب کنید و از جدول، من فقط یک ویژگی را دریافت کنید. این همان چیزی است در دینامو DB و یا پایگاه داده های NoSQL دیگر. فیلتر عبارت من اجازه می دهد تا اساسا قطع نتیجه مجموعه است. بنابراین من یک پرس و جو است. پرس و جو ممکن است با 500 مورد است. اما من فقط می خواهم آیتم هایی که یک ویژگی است که می گوید این. خوب، پس اجازه دهید فیلتر کردن کسانی که در مورد که که پرس و جو خاص مطابقت ندارد. بنابراین ما باید عبارت فیلتر. 

فیلتر عبارت می توانید بر روی هر ویژگی را اجرا کنید. آنها نمایش داده شد وسیعی را دوست ندارد. بالا بردن نمایش داده شد بیشتر انتخابی هستند. فیلتر نمایش داده شد من نیاز به رفتن دریافت کل نتایج تنظیم و پس از آن حک کردن داده من نمی خواهم. چرا مهم است که؟ از آنجا که من خواندن آن تمام. در یک پرس و جو، من قصد دارم به خواندن و آن را به یک غول در مورد داده ها. و پس از آن من قصد دارم به حک کردن آنچه که نیاز دارم. و اگر من فقط کنده کاری از یک زن و شوهر از ردیف، پس از آن که OK. این خیلی ناکارآمد است. 

اما اگر من خواندن کل توده از داده ها، تنها به حک کردن یک مورد، سپس من قصد دارم به بهتر با استفاده از یک پرس و جو محدوده، به دلیل آن را بسیار بیشتر انتخابی. آن را به من بسیاری از صرفه جویی پول، چون من که خواندن پرداخت. که در آن نتایج می آید که عبور از سیم ممکن است کوچکتر، اما من برای پرداخت به عنوان خوانده شده. بنابراین درک کنند که چگونه شما در حال گرفتن داده ها. که در دینامو DB بسیار مهم است. 

عبارات شرطی، این چیزی است که شما ممکن است قفل خوش بینانه است. به روز رسانی اگر وجود دارد، و یا اگر این مقدار معادل به آنچه که من مشخص است. و اگر من یک تمبر زمان در ضبط، من ممکن است از داده خوانده شده. من ممکن است که داده ها را تغییر دهید. من ممکن است به نوشتن که داده ها به پایگاه داده باشد. اگر کسی رکورد تغییر کرده است، برچسب زمان ممکن است تغییر کرده. و به این ترتیب شرطی من به روز رسانی می تواند به روز رسانی می گویند اگر زمان برابر است. و یا به روز رسانی خواهد چرا که کسی شکست به روز شده در رکورد در عین حال. 

این چیزی است که ما قفل خوش بینانه است. این بدان معنی است که کسی می توانید در آمده و تغییر آن، و من قصد دارم به تشخیص آن زمانی که من به برگشت به ارسال. و بعد من در واقع می تواند به عنوان خوانده شده که داده ها و می گویند، آه، او این تغییر کرده است. من نیاز به حساب برای آن است. و من می توانم داده ها در تغییر من ثبت و اعمال روز رسانی دیگر. بنابراین شما می توانید آن افزایشی گرفتن به روز رسانی که بین زمان رخ می دهد که داده ها و به شما خواندن زمان شما ممکن است داده های ارسال. 

رسید و فیلتر بیان در واقع به معنی نیست در تعداد و یا not-- 

[INTERPOSING صداهای] RICK HOULIHAN: من نمی خواهد دریافت بیش از حد به این. این یک کلمه کلیدی محفوظ است. دیدگاه پوند محفوظ کلمه کلیدی در دینامو DB. هر پایگاه داده خود را دارد محفوظ است نام برای مجموعه شما می توانید استفاده کنید. دینامو DB، اگر شما یک پوند در مقابل این، شما می توانید این نام در بالا تعریف کنیم. این یک ارزش اشاره است. این احتمالا بهترین نحو به اند تا در آنجا برای این بحث، چرا که آن را به برخی از real-- می شود من می خواهم که صحبت شده است بیشتر در مورد که در یک سطح عمیق تر. 

اما کافی است، این می تواند پرس و جو می شود که در آن آنها را اسکن views-- و نه دیدگاه پوند بیشتر از 10 است. این یک مقدار عددی است، بله. اگر شما می خواهید، ما می توانیم صحبت در مورد که پس از بحث. همه حق است، بنابراین ما در حال وارد شدن به برخی از حالات در بهترین شیوه که در آن ما قصد داریم به بحث در مورد برخی از برنامه های در اینجا. موارد استفاده برای دینامو DB چه هستند. چه هستند طراحی الگوهای در دینامو DB. 

و یکی از اولین ما قصد داریم به بحث در مورد اینترنت از چیزهایی است. بنابراین ما بسیاری of-- من حدس می زنم، چه it-- بیش از 50٪ است ترافیک در اینترنت این روزها است که در واقع توسط ماشین، فرآیندهای خودکار، نه توسط انسان است. منظور من این چیزی که این چیزی که شما به اطراف حمل در جیب شما، چه مقدار اطلاعات است که آن چیز است در واقع ارسال در اطراف بدون شما دانستن آن کاملا شگفت انگیز است. مکان شما، اطلاعات در مورد چگونه سریع شما در حال رفتن. به نظر شما چگونه کار نقشه های گوگل هنگامی که آنها شما را به آنچه ترافیک است. به این دلیل که میلیون ها نفر وجود دارد و میلیونها نفر از مردم رانندگی در اطراف با گوشی های که در حال ارسال اطلاعات در سراسر جای تمام وقت. بنابراین یکی از چیزهایی در مورد این نوع از داده که می آید در، داده مانیتور، ورود به سیستم داده ها، داده های سری زمانی، این است که آن معمولا فقط جالب برای کمی از زمان. پس از آن زمان، آن را بنابراین جالب است. بنابراین ما در مورد صحبت کردیم، اجازه ندهید که آن جداول بدون مرزهای رشد می کنند. ایده این است که شاید من 24 ساعت به ارزش حوادث در جدول داغ من. و جدول داغ است برای رفتن به مشروط در سرعت بسیار بالا، به دلیل آن را مصرف مقدار زیادی از داده ها. آن را مصرف مقدار زیادی از داده در و من آن را خواندن بسیاری. من بسیاری از عملیات کردم نمایش داده شد در حال اجرا در برابر آن داده است. 

پس از 24 ساعت، سلام، شما می دانید چه، من اهمیتی نمی دهند. بنابراین شاید هر نیمه شب من رول جدول من را به یک جدول جدید و من deprovision این جدول. و من را و RCU است پایین WCU به دلیل 24 ساعت بعد من در حال اجرا نیست به عنوان بسیاری از نمایش داده شد در برابر آن داده است. بنابراین من قصد دارم به صرفه جویی در پول است. و شاید 30 روز بعد من نمی حتی نیاز به در مورد آن همه مراقبت. من می توانم را در WCU تمام راه را به یک، چون شما می دانید چه، آن را هرگز برای رسیدن به نوشته شده است. داده 30 روز قدیمی است. آن را هرگز تغییر می دهد. 

و آن را تقریبا هرگز به خواندن، بنابراین اجازه دهید فقط که RCU را به 10. و من صرفه جویی در یک تن از پول در این داده ها، و فقط برای داده های گرم من پرداخت. به طوری که نکته مهم به نگاه در زمانی که شما در یک سری زمانی نگاه داده ها در آینده در حجم. این استراتژی هستند. در حال حاضر، من فقط می تواند آن را اجازه همه به همان جدول به و فقط اجازه دهید که جدول رشد می کنند. در نهایت، من قصد دارم به مسائل مربوط به عملکرد ببینید. من قصد دارم به باید برای شروع به آرشیو برخی از داده ها که از روی میز، چه چیزی نیست. 

بیایید بهتر طراحی نرم افزار خود را به طوری که شما می توانید این راه درست به کار گیرند. بنابراین آن را فقط به صورت خودکار در کد نرم افزار. در نیمه شب هر شب رول آن جدول. شاید آنچه که من نیاز به یک کشویی پنجره از 24 ساعت از داده ها. پس از آن به طور منظم من تماس داده را از جدول. من آن را با پیرایش برنامه cron و من از قرار دادن آن بر روی این جداول دیگر، هر آنچه شما نیاز دارید. بنابراین اگر یک رول اور کار می کند، این عالی است. اگر نه، آن را تر و تمیز. اما اجازه دهید باشید که داده داغ به دور از داده سرد خود را. آن را به شما مقدار زیادی از پول را نجات دهد و ساخت جداول خود را انجام بیشتر. بنابراین چیزی که بعد ما صحبت در مورد اضافه کردن کاتولوگ محصولات است. اضافه کردن کاتولوگ محصولات است بسیار رایج مورد استفاده. این در واقع یک الگوی بسیار رایج که ما در انواع مختلف از چیز را ببینید. شما می دانید، توییتر برای به عنوان مثال، یک صدای جیر جیر گرم است. هر کس به آینده و گرفتن که صدای جیر جیر. اضافه کردن کاتولوگ محصولات، من یک فروش است. من یک فروش گرم است. من 70،000 درخواست در هر رو آمدن برای یک محصول توضیحات از اضافه کردن کاتولوگ محصولات است. ما این را در خرده فروشی عملیات کاملا کمی است. پس چگونه ما با برخورد؟ هیچ راهی برای مقابله با آن وجود دارد. همه کاربران من می خواهم برای دیدن همان قطعه از داده ها. آنها می آیند در، به صورت همزمان. و همه آنها ساخت درخواست برای همان قطعه از داده ها. این به من می دهد که کلید داغ، که بزرگ قرمز نوار در نمودار من است که ما را دوست ندارند. و این چیزی است که به نظر می رسد. بنابراین در سراسر فضای کلید من من گرفتن چکش در فروش اقلام است. من گرفتن چیزی هر جای دیگر. 

چگونه می توانم این مشکل را کاهش دهم؟ خب، ما این کار را با کش را کاهش دهد. کش، شما را اساسا در حافظه پارتیشن در مقابل پایگاه داده باشد. ما موفق شده اند [نامفهوم] کش، چگونه شما می توانید راه اندازی کش خود را، [نامفهوم] کش [؟ D،؟] هر آنچه که شما می خواهید. قرار است که در مقابل پایگاه داده باشد. و به این ترتیب شما می توانید که داده ها را ذخیره از آن کلید گرم کردن در کش فضا و از طریق خواندن حافظه پنهان. 

و پس از آن بسیاری از بار خوانده شده خود را شروع به دنبال شبیه به این. من همه این کش بازدید تا اینجا و من هیچ چیز در اینجا رفتن به پایین چرا که بانک اطلاعاتی در پشت نشسته است کش و می خواند هرگز از طریق آمده است. اگر داده ها در عوض کنم پایگاه داده، من به روز رسانی ذخیره سازی. ما می توانیم چیزی استفاده مانند بخار به انجام این کار. و من توضیح دهید که چگونه است که کار می کند. همه حق است، پیام رسانی است. ایمیل، همه ما استفاده از ایمیل. 

این یک مثال بسیار خوب است. ما برخی از پیام های جدول کردم. و ما صندوق پستی و صندوق است. این چیزی است که SQL را شبیه به ساخت که صندوق. ما نوع استفاده از همان نوع استراتژی به استفاده از GSI است، در GSI برای صندوق من و صندوق من. بنابراین من پیام خام آینده کردم به جدول پیام من. و اولین رویکرد به این ممکن است، می گویند، OK، مشکلی ندارد. من پیام خام کردم. پیغام آینده [نامفهوم]، پیام ID، که بزرگ. که هش منحصر به فرد من است. من قصد دارم برای ایجاد دو را GSI، یکی برای صندوق پستی من، یکی برای صندوق من. و اولین چیزی که من انجام است من می گویم کلید هش من است رفتن به گیرنده و من قصد دارم به ترتیب در تاریخ. این فوق العاده است. من نظر خوب من به اینجا رسیدیم. اما یک مسئله کمی وجود دارد در اینجا. و شما را به این در اجرا پایگاه داده های رابطه است. آنها پارتیشن بندی به صورت عمودی به نام. شما می خواهید به نگه داشتن اطلاعات بزرگ خود را به دور از داده کوچک خود را. 

و به همین دلیل است، زیرا من باید رفتن به عنوان خوانده موارد برای دریافت ویژگی ها است. و اگر بدن من همه در اینجا، پس از آن خواندن تنها چند مورد اگر طول بدن من است به طور متوسط ​​هر 256 کیلوبایت، ریاضی می شود بسیار زشت است. بنابراین می گویند من می خواهم به خواندن صندوق پستی دیوید. صندوق دیوید دارای 50 اقلام است. متوسط ​​و اندازه 256 کیلوبایت است. در اینجا ضریب تبدیل من برای این RCU چهار کیلوبایت است. 

خوب، اجازه دهید با رفتن در نهایت سازگار می خواند. من هنوز هم خوردن 1600 RCU است فقط به خواندن صندوق دیوید. آخ. خوب، حالا بیایید فکر می کنم در مورد چگونگی برنامه کار می کند. اگر من در یک برنامه ایمیل هستم و من به دنبال در صندوق پستی من، و من در بدن هر پیام نگاه کنید، نه، من به دنبال نگاهی به خلاصه. من به دنبال در تنها هدر. بنابراین اجازه دهید یک ساختار جدول ساخت که به نظر می رسد بیشتر شبیه است که. 

بنابراین در اینجا اطلاعات است که گردش کار من نیاز دارد. آن را در صندوق پستی من GSI است. این تاریخ است، فرستنده، این موضوع، و پس از آن شناسه پیام، که اشاره بازگشت به میز پیام جایی که من می تواند بدن را دریافت کنید. خب، این امر می تواند شناسه رکورد. آنها را به نقطه تماس شناسه آیتم در جدول دینامو DB. هر شاخص همیشه creates-- همواره مورد ID به عنوان بخشی of-- که همراه با شاخص. 

خیلی خوب. رسید این آن را می گوید که در آن ذخیره می شود؟ RICK HOULIHAN: بله، آن را می گوید exactly-- این دقیقا همان چیزی آن را ندارد. این گزارش می گوید در اینجا ثبت RE من است. و آن را اشاره به سابقه RE من. دقیقا. OK، بنابراین در حال حاضر صندوق پستی من است در واقع بسیار کوچکتر است. و این در واقع از گردش کار از یک نرم افزار ایمیل. بنابراین صندوق پستی من، من را کلیک کنید. من به همراه و من در پیام کلیک کنید، که زمانی که من نیاز به رفتن بدن، چون من قصد دارم به رفتن به یک دیدگاه متفاوت است. بنابراین اگر شما در مورد نوع MVC از فکر می کنم چارچوب، مدل کنترل مشاهده. 

مدل شامل داده هایی را که نیازهای نظر و کنترل تعامل با. هنگامی که قاب را تغییر دهید من، وقتی دیدگاه خود را عوض کنم، آن را OK به بازگشت به سرور و تکثیر مدل، زیرا این چیزی است که کاربر انتظار. هنگامی که آنها دیدگاه تغییر، که زمانی که ما به پایگاه داده می توانید بروید. بنابراین ایمیل، کلیک کنید. من به دنبال برای بدن است. رفت و برگشت. برو بدن است. 

من داده بسیار کمتر شده است. من فقط خواندن بدن که دیوید زمانی که او نیاز به آنها نیاز دارد. و من در 1600 سوختگی نیست در RCU فقط برای نشان دادن صندوق است. بنابراین در حال حاضر that-- این راه است که LSI و یا GSI-- من متاسفم، GSI، کار است. ما هش ما در گیرنده کردم. ما کلید وسیعی در تاریخ کردم. و ما صفات بینی کردم که ما فقط نیاز به حمایت از این دیدگاه. 

ما چرخش که برای صندوق. هش در فرستنده. و در اصل، ما باید بسیار خوب، مشاهده تمیز. و آن را ما basically-- این پیام زیبا جدول که در حال گسترش به دلیل سادگی آن را هش تنها، درهم ID پیام است. و ما باید دو شاخص که در حال چرخاندن کردن از آن جدول. همه حق است، بنابراین ایده این جا است که نمی نگه داشتن داده های بزرگ و کوچک این داده ها با یکدیگر. پارتیشن به صورت عمودی، پارتیشن آن جداول. آیا اطلاعات نمی خواند شما لازم نیست که. همه حق است، بازی. همه ما دوست داریم بازی ها. حداقل من دوست دارم بازی پس از آن. بنابراین برخی از چیزهایی که ما با زمانی که مقابله ما در حال فکر کردن در مورد بازی، درست است؟ بازی این روزها، به خصوص تلفن همراه بازی، همه چیز در مورد تفکر است. و من قصد دارم به چرخش در اینجا یک کمی به دور از DynamoDB. من قصد دارم به در برخی از بحث در اطراف برخی از فن آوری های دیگر AWS. 

اما این ایده در مورد بازی است به فکر می کنم در مورد شرایط استفاده از رابط های برنامه کاربردی در، رابط های برنامه کاربردی که، به طور کلی، HTTP و JSON. این که چگونه بازی های تلفن همراه نوع با به پایان می رسد تماس خود را در تعامل. آنها این کار مجوز های ارسال و JSON. آنها داده، و آن را به همه، به طور کلی، در رابط های برنامه کاربردی JSON خوب است. 

چیزهایی مثل گرفتن از دوستان، داده رهبران، ارز، کاربر تولید محتوا، فشار به بالا و به سیستم، این نوع از همه چیز که ما قصد داریم به انجام است. داده های دارایی دودویی، این داده ها ممکن است در پایگاه داده نشستن نیست. این ممکن است در نشستن فروشگاه اینترنتی شی، درست است؟ اما پایگاه داده است که به تا پایان گفتن سیستم، گفتن نرم افزار که در آن به گرفتن آن را. و به ناچار، چند نفره سرویس دهنده ها، زیرساخت های پایان دادن به عقب، طراحی شده برای بالا و در دسترس بودن و مقیاس پذیری. بنابراین این چیزهایی که همه ما می خواهیم هستند در زیرساخت های بازی امروز. 

بنابراین اجازه دهید نگاهی به آنچه که به نظر می رسد. یک پایان هسته تماس، بسیار ساده است. ما یک سیستم را در اینجا با مناطق در دسترس بودن متعدد. ما در مورد گاز صحبت کردیم که فکر می کنم being-- از آنها به عنوان مراکز داده جداگانه. مرکز بیش از یک داده در هر AZ، اما این OK، فقط به آنها به عنوان داده های جداگانه مراکزی که از لحاظ جغرافیایی و گسل جدا شده است. 

ما در حال رفتن به یک موارد چند EC2. ما در حال رفتن به برخی از سرور پایان دادن به عقب. شاید اگر شما یک میراث هستید معماری، ما با استفاده از آنچه که ما RDS پاسخ، خدمات پایگاه داده رابطه ای. می تواند MSSQL، خروجی، و یا چیزی شبیه به آن. به این ترتیب یک برنامه بسیار است امروز طراحی شده است. 

خوب ما ممکن است بخواهید تا با این زمانی است که ما در مقیاس است. ما پیش بروید و قرار سطل S3 وجود دارد. و سطل S3، به جای خدمت تا کسانی که اشیاء از servers-- ما ما می تواند انجام دهد. شما قرار دادن تمام باینری خود را اشیاء بر روی سرور خود و شما می توانید آن سرور استفاده کنید موارد برای خدمت به که داده است. اما این بسیار گران است. 

راه بهتر انجام دهید این است به جلو بروید و قرار دادن آن اشیاء در یک سطل S3. S3 مخازن جسم است. به طور خاص برای ساخته شده است خدمت تا این نوع از همه چیز. و اجازه دهید آن دسته از مشتریان درخواست به طور مستقیم از آن سطل شی، رها سرور. بنابراین ما در حال شروع به مقیاس را اینجا ببینید. 

در حال حاضر ما کاربران در سراسر جهان است. من کاربران است. من نیاز به محتوا به صورت محلی واقع نزدیک به این کاربران، درست است؟ من یک سطل S3 ایجاد کرده اید به عنوان مخزن منبع من. و من جلو که با توزیع CloudFront قابلیت. 

CloudFront قابلیت یک سی دی و یک شبکه های تحویل محتوا. در واقع آن را طول می کشد داده است که شما مشخص و آن همه انبارها از طریق اینترنت بنابراین کاربران در همه جا می توانید پاسخ بسیار سریع زمانی که آنها درخواست کسانی که اشیاء. 

بنابراین شما یک ایده را دریافت کنید. شما در حال نوع اعمال نفوذ همه جنبه های AWS در اینجا به این انجام می شود. و در نهایت، ما پرتاب در یک گروه پوسته پوسته شدن خودکار. بنابراین موارد AC2 ما سرور های بازی ما، عنوان آنها شروع به شلوغ و شلوغ و شلوغ، آنها فقط یکی دیگر از چرخش به عنوان مثال، چرخش به عنوان مثال دیگر، چرخش به عنوان مثال دیگری. بنابراین تکنولوژی AWS است، آن اجازه می دهد تا شما را مشخص پارامترهای که در اطراف سرور خود را رشد خواهد کرد. بنابراین شما می توانید تعداد نفر از سرورها خارج وجود دارد در هر زمان داده شده. و اگر بار خود را از بین می رود، آنها کوچک، تعداد کوچک خواهد شد. و اگر بار می آید، آن را رشد از پشت، کشسان. 

بنابراین این به نظر می رسد بزرگ است. ما بسیاری از موارد EC2 کردم. ما می توانید کش قرار داده در آن مقابل پایگاه های داده، امتحان کنید و سرعت بخشیدن به پایگاه های داده. از نقطه فشار بعدی به طور معمول مردم را ببینید این است که آنها را در مقیاس یک بازی با استفاده از یک سیستم بانک اطلاعاتی رابطه. خدای، پایگاه داده عملکرد وحشتناک است. چگونه ما را بهبود بخشد که؟ بیایید سعی کنید با قرار دادن کش در مقابل آن. 

خب، کش کار نمی کند آنقدر بزرگ در بازی، درست است؟ برای بازی، نوشتن دردناک است. بازی ها بسیار سنگین ارسال. کش کار نمی کند زمانی که شما ارسال سنگین به دلیل شما همیشه رو به روز رسانی ذخیره سازی. شما روز رسانی ذخیره سازی، آن را بی ربط به ذخیره شود. این در واقع فقط کار اضافی است. 

بنابراین که در آن ما اینجا بروم؟ شما تنگنا بزرگ کردم پایین وجود دارد در پایگاه داده است. و جایی برای رفتن بدیهی است پارتیشن بندی است. پارتیشن بندی است آسان برای انجام زمانی که شما با پایگاه داده های رابطه. با پایگاه داده های رابطه، شما مسئول برای مدیریت، به طور موثر، فضای کلیدی است. شما در حال کاربران بین A و M و گفت اینجا، بین N و Z وجود دارد. و شما در حال تعویض در سراسر برنامه. بنابراین شما در حال برخورد با این منبع داده پارتیشن. شما باید محدودیت های معاملاتی که پارتیشن را بگستراند. شما همه نوع از messiness که شما هستید با پایین وجود دارد تلاش برای مقابله با پوسته پوسته شدن و ایجاد یک زیرساخت بزرگتر است. این فقط سرگرم کننده است. 

مخاطبان: بنابراین آیا شما گفت که افزایش نقاط منبع سرعت فرایند؟ RICK HOULIHAN: افزایش است؟ نقطه منبع: مخاطبان. RICK HOULIHAN: نقطه منبع؟ رسید از اطلاعات، که در آن اطلاعات است که از؟ RICK HOULIHAN: شماره من چه می گویم در حال افزایش است تعداد پارتیشن در فروشگاه داده ها توان بهبود می بخشد. پس چه اینجا اتفاق می افتد کاربران است که به عنوان مثال EC2 تا اینجا، خوب، اگر من نیاز به یک کاربر که یک به M، من اینجا خواهم رفت. از N به P، من اینجا خواهم رفت. از P به Z، من اینجا خواهم رفت. 

رسید OK، کسانی بنابراین کسانی که همه در گره های مختلف ذخیره می شود؟ 

RICK HOULIHAN: بله. فکر می کنم از این به عنوان سیلوهای مختلف از داده ها. بنابراین شما نیاز به انجام این کار. اگر شما در حال تلاش برای انجام این، اگر شما در حال تلاش به مقیاس در یک پلت فرم ارتباطی، این چیزی است که شما در حال انجام. شما در حال گرفتن داده ها و شما آن را قطع. و شما آن را پارتیشن بندی در سراسر چند نمونه از پایگاه داده باشد. و شما در حال مدیریت همه که در لایه های نرم افزار. این هیچ سرگرم کننده است. بنابراین چه چیزی ما خواهید بروید؟ ما می خواهیم به DynamoDB، به طور کامل موفق، نواسکیوال ذخیره داده، توان ارائه. ما با استفاده از شاخص ثانویه. این اساسا HTTP API و شامل پشتیبانی سند. بنابراین شما لازم نیست که به نگرانی در مورد هر یک از این پارتیشن بندی. ما تمام آن را برای شما. بنابراین در حال حاضر، در عوض، شما فقط به جدول ارسال. اگر جدول نیاز به تقسیم می شود، که در پشت صحنه اتفاق می افتد. شما به طور کامل عایق از آن به عنوان یک توسعه دهنده. بنابراین اجازه دهید بحث در مورد برخی از موارد استفاده که ما را به در بازی، مشترک اجرا سناریوهای بازی، رهبران. بنابراین شما کاربران در آینده، BoardNames که آنها در، نمرات برای این کاربر. ما ممکن است از هش در آی دی کاربر، و پس از آن در حال حاضر طیف در بازی. بنابراین هر کاربر می خواهد برای دیدن تمام بازی او بازی و همه نمره بالا خود در تمام بازی ها. به طوری که رهبران شخصی خود است. 

حالا من می خواهم به در و من می خواهم به get-- بنابراین من این مدیران شخصی است. چه من می خواهم انجام دهید این است برو نمره بالا در بین همه کاربران. پس چگونه انجام دهم؟ هنگامی که رکورد من در درهم یوزر آی دی، محدوده در این بازی، خوب من دارم به جلو بروید و بازسازی، ایجاد یک GSI، و من قصد دارم به بازسازی آن داده است. 

حالا من قصد دارم به هش بر روی BoardName، بازی است. و من قصد دارم به محدوده در نمره بالا است. و اکنون من سطل های مختلف ایجاد کرده اید. من با استفاده از همان جدول، داده ها مورد همان. اما من ایجاد یک سطل که به من یک تجمع نمره بالا بازی ها. 

و من می توانم که جدول که برای دریافت اطلاعات. بنابراین من که الگوی پرس و جو کرده ام تا به مجموعه توسط شاخص ثانویه پشتیبانی می شود. در حال حاضر آنها را می توان با طبقه بندی شده اند BoardName و بر اساس TopScore، بسته به. بنابراین شما می توانید ببینید، این نوع هستند از موارد شما در بازی استفاده کنید. مورد دیگری که مورد استفاده مناسب ما در بازی مطلع جوایز و که موفق به کسب جوایز است. و این یک مورد استفاده بزرگ است که در آن ما شاخص پراکنده است. شاخص پراکنده هستند توانایی تولید شاخص که لزوما شامل هر مورد تنها روی میز. و چرا نه؟ از آنجا که ویژگی که در حال ایندکس شده بر روی هر مورد وجود ندارد. 

بنابراین در این خاص استفاده از مورد، من گفت، شما می دانید چه، من قصد دارم به ایجاد یک ویژگی به نام جایزه. و من قصد دارم به هر کاربر است که دارای یک جایزه که نسبت داد. کاربران است که لازم نیست جوایز قصد ندارم به آن صفت. تا زمانی که من ایجاد صفحه اول، تنها کاربران که در حال رفتن به نشان می دهد در شاخص آنهایی که در واقع جوایز به دست آورد. به طوری که یک راه عالی برای قادر است ایجاد شاخص فیلتر شده است که بسیار، بسیار گزینشی است که نمی به شاخص دارند کل جدول. 

بنابراین ما در حال کم روی زمان گرفتن در اینجا. من قصد دارم به جلو بروید و جست و خیز و جست و خیز این سناریو است. بحث کمی about-- 

مخاطبان: آیا من می توانم یک سوال سریع بپرسم؟ یکی از ارسال سنگین؟ RICK HOULIHAN: چیست؟ رسید نوشتن سنگین است. RICK HOULIHAN: نوشتن سنگین است. بذار ببینم. 

رسید یا این است که نه شما فقط می توانید صدای در یک ماده از ثانیه؟ RICK HOULIHAN: ما به از طریق سناریو رای. این که بد نیست. آیا شما بچه ها چند دقیقه؟ باشه. 

بنابراین ما در مورد رای گیری صحبت کنید. بنابراین رای زمان واقعی، ما باید الزامات مورد نیاز برای رای دادن. لازم است که ما اجازه می دهد هر فرد برای رای دادن فقط یک بار. ما می خواهیم هیچ کس قادر به تغییر رای خود را. ما می خواهیم در زمان واقعی تجمع تجزیه و تحلیل ترافیک برای جمعیتی و که ما در حال رفتن به نشان دادن به کاربران در سایت. 

فکر می کنم از این سناریو است. ما کار زیادی از واقعیت تلویزیون را نشان می دهد که در آن آنها انجام این نوع دقیق از همه چیز. بنابراین شما می توانید از سناریو فکر می کنم، ما میلیون ها و میلیون دختران نوجوان وجود دارد با تلفن های همراه خود و رای دهی و رای گیری، و رای دادن به هر که باشند پیدا می شود محبوب ترین است. بنابراین بعضی از این هستند مورد نیاز ما را اجرا کردن. 

و به این ترتیب برای اولین بار در حل این مشکل می شود برای ساخت یک نرم افزار بسیار ساده است. بنابراین من این برنامه دارم. من به برخی از رای دهندگان خارج وجود دارد. آنها در می آیند، آنها برنامه رای رسید. من برخی از آرا جدول خام کردم من فقط کمپرسی این آرا به. من برخی از دانه ها باید جدول که رای تجزیه و تحلیل ترافیک و جمعیتی خواهد من، و ما این همه در وجود دارد قرار داده است. 

و این فوق العاده است. زندگی خوب است. زندگی خوب تا زمانی که ما پیدا کردن که همیشه تنها یک یا دو وجود دارد مردم که در انتخابات محبوب است. تنها یک یا دو چیز وجود دارد که مردم واقعا در مورد مراقبت. و اگر شما رای دهنده در مقیاس، همه ناگهانی من رفتن به چکش جهنم از دو نامزد، یک یا دو نامزد. تعداد بسیار محدودی از اقلام مردم پیدا می شود محبوب. 

این یک الگوی طراحی خوب نیست. این در واقع یک الگوی طراحی بسیار بد دلیل آن را ایجاد چیزی است که ما که در مورد کلید های داغ بود صحبت کردیم. کلید های داغ چیزهایی هستند که ما را دوست ندارند. 

پس چگونه مشکل را حل کنیم؟ و واقعا، راه را برای حل این مشکل است با در نظر گرفتن آن سطل نامزد و برای هر نامزد ما، ما قصد داریم به اضافه یک مقدار تصادفی، چیزی است که ما می دانیم، به صورت تصادفی ارزش بین یک و 100، بین 100 تا 1،000، و یا بین یک و 1،000، با این حال بسیاری از ارزش های تصادفی شما می خواهید اضافه بر روی انتهای که نامزد. 

و من چه کرده ام واقعا انجام می شود پس از آن؟ اگر من با استفاده از ID نامزد به عنوان سطل به رای کل، اگر من یک تصادفی اضافه شده تعداد تا پایان آن، من ایجاد کرده اید در حال حاضر 10 سطل، یک صد سطل، سطل هزار که من جمع آوری آرا در سراسر. 

بنابراین من میلیون ها و میلیون، و میلیون ها پرونده در آینده برای این نامزدها، من در حال حاضر گسترش این آرا در سراسر A_1 نامزد از طریق A_100 نامزد، به دلیل هر بار که یک رای در می آید، من تولید تصادفی ارزش بین یک و 100. من آن را بر روی ضمیمه پایان نامزد است که فرد را برای رای دادن. من آن را آزادسازی را به که سطل. 

در حال حاضر در پشت، من می دانم که من صد سطل است. بنابراین، هنگامی که من می خواهم به جلو بروید و جمع آرا، من از تمام کسانی که سطل به عنوان خوانده شده. بنابراین من پیش بروید و اضافه کنید. و پس از آن من پراکنده جمع آوری که در آن من و می گویند هی، شما می دانید چه، کلید این نامزد فضاهای بیش از یک صد سطل است. من قصد دارم به جمع آوری تمام رای از اون صد سطل. من قصد دارم به جمع آنها را و من قصد دارم برای گفتن، نامزد در حال حاضر تعداد کل آرا x است. 

در حال حاضر هر دو ارسال پرس و جو و پرس و جو به عنوان خوانده شده به سادگی توزیع چون من نوشتن در سراسر و من خواندن در سراسر صدها نفر از کلید هستم. من نوشتن نیست و خواندن در سراسر یک کلید است. به طوری که یک الگوی بزرگ است. 

این است که در واقع احتمالا یکی از طراحی مهمترین الگوهای برای مقیاس در نواسکیوال. شما می توانید این نوع دید الگوی طراحی در هر عطر و طعم. مانگودیبی، DynamoDB، آن را نمی کند ماده، همه ما باید به انجام این کار. زیرا زمانی که شما در حال برخورد با کسانی که واحدهای بزرگ، شما باید به شکل از راه به آنها گسترش در سراسر سطل. پس این راه شما انجام این کار است. همه حق است، پس چه شما در حال انجام در حال حاضر است که شما معامله کردن به عنوان خوانده شده هزینه برای نوشتن مقیاس پذیری. هزینه خوانده است کمی پیچیده تر و من برای رفتن از یک به عنوان خوانده شده صد سطل به جای یکی. اما من قادر به ارسال کنم. و توان من، نوشتن من توان باور نکردنی است. پس از آن معمولا با ارزش روش برای پوسته پوسته شدن DynamoDB، یا هر پایگاه داده های NoSQL که برای ماده. بنابراین ما نمیفهمد چگونه به آن را در مقیاس. و ما نمیفهمد چگونه به از بین بردن کلید های داغ ما است. و این فوق العاده است. و ما این سیستم خوب است. و آن را به ما رای بسیار صحیح داده چرا که ما رای رکورد د احمق. آن را به DynamoDB ساخته شده است. ما در مورد حقوق مشروط صحبت کردیم. 

هنگامی که یک رای دهنده در می آید، قرار می دهد قرار دادن بر روی میز، آنها با ID خود را وارد رای دهندگان، اگر آنها سعی کنید برای وارد رای دیگر، من نوشتن شرطی. می گویند تنها این ارسال اگر این وجود ندارد. تا در اسرع وقت من می بینم که که رای ضربه جدول، هیچ کس دیگری را برای رفتن به قادر به قرار دادن رای خود را در. و این فوق العاده است. و ما در حال افزایش شمارنده نامزد ما. و ما در حال انجام ما جمعیت شناسی و تمام. اما اگر من نرم افزار افتد؟ در حال حاضر همه از یک رای ناگهانی در آینده، و من نمی دانم اگر آنها در حال پردازش شدن به تجزیه و تحلیل و جمعیتی من دیگر. و زمانی که برنامه می آید به بالا، چگونه جهنم من می دانم که چه رای داشته پردازش شده است و از کجا شروع کنم؟ 

بنابراین این یک مشکل واقعی است وقتی که شما شروع به در این نوع سناریو است. و چگونه می توانم حل که ما؟ ما آن را حل کند با آنچه که ما DynamoDB جریان است. جریان است یک زمان و دستور داد تقسیم ورود به سیستم تغییر هر دسترسی به جدول، هر ارسال دسترسی به جدول. هر گونه اطلاعات که به نوشته جدول نشان می دهد تا در جریان است. 

این یک صف 24 ساعته اساسا. موارد ضربه جریان، آنها به مدت 24 ساعت زندگی می کنند. آنها را می توان چندین بار بخوانید. تضمین تحویل داده می شود تنها یک بار به جریان، می تواند به عنوان خوانده شده تعداد نفر از بار. بنابراین با این حال بسیاری از فرآیندهای شما می خواهید مصرف که داده ها، شما می توانید آن را مصرف کنند. این هر به روز رسانی ظاهر خواهد شد. هر نوشتن تنها به یک بار در جریان نظر می رسد. بنابراین شما لازم نیست که به نگرانی در مورد پردازش آن را دو بار از همان روند. 

آن را به شدت در هر مورد دستور داد. هنگامی که ما می گویند زمان دستور و تقسیم، شما در هر پارتیشن در جریان را ببینید. شما می توانید آیتم، به روز رسانی در دید. ما تضمین نمی در جریان هستید که شما رفتن به هر معامله در سفارش به سراسر اقلام است. 

بنابراین جریان idempotent است می باشد. آیا همه ما می دانیم چه idempotent است بدان معنی است؟ idempotent است یعنی شما می توانید آن را انجام دهید بیش از، و بیش از، و دوباره و دوباره. نتیجه را برای رفتن به همان. 

جریان idempotent است هستند، اما آنها باید بازی از نقطه شروع، هر کجا که شما انتخاب می کنید، به پایان، و یا آنها نمی خواهند نتیجه در همان ارزش. 

همان چیزی که با مانگودیبی. مانگودیبی یک ساختار آنها oplog پاسخ. این همان ساختار دقیق است. بسیاری از پایگاه داده های NoSQL این ساختار. آنها از آن استفاده به انجام کارهای مانند تکرار، که دقیقا همان چیزی است که ما با جریان است. مخاطبان: شاید یک درخواست بدعت، اما شما در مورد برنامه های انجام پایین غیره صحبت کنید. آیا جریان تضمین شده به هرگز احتمالا به پایین؟ RICK HOULIHAN: بله، جریان تضمین هرگز به پایین. ما مدیریت زیرساخت پشت. به طور خودکار جریان استقرار در گروه پوسته پوسته شدن خودکار است. ما را از طریق کمی کمی در مورد آنچه اتفاق می افتد. 

باید بگویم نه آنها نیست تضمین هرگز به پایین. عناصر تضمین در جریان نظر می رسد. و جریان دسترس خواهد بود. پس چه پایین می رود یا می آید به تا که اتفاق می افتد در زیر. این covers-- آن را OK. همه حق است، بنابراین شما متفاوت است انواع نمایش روی صفحه نمایش. انواع که به مهم هستند برنامه نویس معمولا، چه بود؟ من با نظر قدیمی. هنگامی که یک به روز رسانی بازدید جدول، آن را فشار نگاه قدیمی به جریان بنابراین داده ها می توانید آرشیو، یا تغییر شناسایی، تغییر، تغییر مدیریت. 

تصویر جدید، آنچه در آن است در حال حاضر پس به روز رسانی، که نوع دیگری از نمایش میتونی به دستش بیاری. شما می توانید هر دو قدیمی و جدید تصاویر را دریافت کنید. شاید من آنها را هر دو می خواهند. من می خواهم به دیدن آنچه در آن بود. من می خواهم به دیدن آنچه در آن به تغییر. 

من یک نوع انطباق از فرایند است که اجرا می شود. به آن نیاز دارد که به منظور بررسی هنگامی که این چیز را تغییر دهید، که آنها در محدوده خاص هستید و یا در داخل پارامترهای خاصی. 

و پس از آن تنها شاید من باید بدانید که چه تغییر کرده است. برای من مهم نیست چه مورد تغییر کرده است. من لازم نیست به نیاز به دانستن چه چیزی تغییر ویژگی های. من فقط باید بدانید که اقلام حال لمس کرد. بنابراین این نوع نمایش ها هستند که شما دریافت کردن جریان و شما می توانید با تعامل. 

برنامه ای که مصرف جریان، این نوع از راه این کار این است. مشتری DynamoDB بخواهید به فشار داده ها به جداول. جریان استقرار در آنچه که ما خرده ریز است. خرده ریز کوچک هستند به طور مستقل از جدول. آنها خط نیست تا به طور کامل به پارتیشن جدول خود را. و به همین دلیل است چرا که آنها به خط تا به ظرفیت، در حال حاضر ظرفیت از جدول. 

آنها در استقرار خود خودرو خود گروه پوسته پوسته شدن، و آنها شروع به چرخش بسته که چگونه بسیاری از می نویسد در آینده، چگونه بسیاری از reads-- واقعا آن را می نویسد. وجود ندارد اما چگونه reads-- بسیاری از نوشتن در آینده. 

و سپس بر روی تماس پایان، ما آنچه که ما KCL یا kinesis به مشتری کتابخانه تماس بگیرید. kinesis به داده های جریان است تکنولوژی پردازش از آمازون. و جریان است که در آن ساخته شده است. 

بنابراین شما با استفاده از یک KCL فعال برنامه کاربردی برای خواندن جریان است. kinesis به مشتری کتابخانه در واقع مدیریت کارگران برای شما. و آن را نیز انجام می دهد برخی چیزهای جالب. آن را به برخی جداول را ایجاد در جدول DynamoDB خود را برای پیگیری که آیتم پردازش شده است. بنابراین این روش اگر آن را سقوط تماس، اگر آن می افتد و می آید و می شود تا ایستاده بود برگشت، آن را می توانید تعیین که در آن آن را در پردازش جریان بود. 

این بسیار مهم است که شما در حال صحبت کردن در مورد تکرار. من نیاز به دانستن چه اطلاعات پردازش شده است شد و چه داده هنوز به پردازش شود. بنابراین کتابخانه KCL برای جریان خواهد شد شما مقدار زیادی از که قابلیت بدهد. آن طول می کشد مراقبت از تمام خانه داری. آن می ایستد تا یک کارگر برای هر سفال. آن را ایجاد یک جدول اداری برای هر سفال، برای هر کارگر. و به عنوان کسانی که کارگران آتش، آنها آن جداول حفظ بنابراین شما می دانید این رکورد خوانده شد و پردازش شده است. و پس از آن که اگر روند می میرد و می آید آنلاین تماس، آن را می توانید حق را از سر که در آن زمان خاموش. 

بنابراین ما از این استفاده برای تکرار متقابل منطقه است. بسیاری از مشتریان نیاز به حرکت داده ها یا بخش هایی از جداول داده های خود اطراف به مناطق مختلف. نه مناطق وجود دارد در سراسر جهان. بنابراین ممکن است یک من need-- ممکن است کاربران در آسیا، کاربران در ساحل شرق از ایالات متحده است. آنها داده های مختلف که نیاز به صورت محلی توزیع شده است. و شاید یک کاربر از مگس آسیا به ایالات متحده آمریکا، و من می خواهم به تکرار داده های خود را با او. بنابراین، هنگامی که او می شود را از هواپیما، او یک تجربه خوب با استفاده از نرم افزار تلفن همراه خود را. 

شما می توانید متقابل منطقه استفاده کتابخانه تکرار به انجام این کار. اساسا ما ارائه دو تکنولوژی. یکی یک برنامه کنسول شما می توانید این ایستادن روی عنوان مثال EC2 خود را. این اجرا می شود تکرار خالص است. و سپس ما شما کتابخانه داد. کتابخانه شما می توانید استفاده کنید برای ساخت نرم افزار خود را اگر شما می خواهید به انجام کارهای دیوانه با data-- فیلتر، تکرار تنها بخشی از آن، چرخش داده ها، حرکت آن را به یک جدول های مختلف، به طوری که در تاریخ و غیره. به طوری که نوع از آنچه که به نظر می رسد مانند است. 

DynamoDB جریان را می توان پردازش توسط آنچه که ما لامبدا پاسخ. ما کمی در مورد رویداد ذکر معماری نرم افزار هدایت می شود. لامبدا یک جزء کلیدی از آن است. لامبدا کد است که آتش سوزی در تقاضا است در پاسخ به یک رویداد خاص است. یکی از این حوادث می تواند یک رکورد ظاهر می شود در جریان است. اگر سابقه در جریان نظر می رسد، ما این تابع جاوا پاسخ. خوب، این جاوا اسکریپت و لامبدا است از نود.جیاس، جاوا، پایتون، و به زودی پشتیبانی خواهد کرد زبان های دیگر نیز هست. و کافی است، آن را کد خالص است. ارسال در جاوا، شما یک کلاس تعریف کنیم. شما با فشار JAR تا به لامبدا. و سپس شما که کلاس را مشخص در پاسخ به که رویداد پاسخ. و پس از آن زیرساخت های لامبدا پشت که کد اجرا خواهد شد. 

که کد می تواند پردازش سوابق کردن جریان. می تواند هر چیزی آن را با آن می خواهد انجام دهد. در این مثال خاص، همه ما در حال واقعا انجام شده است ورود به سیستم ویژگی ها است. اما این فقط کد است. کد می توانید هر چیزی را انجام، درست است؟ 

بنابراین شما می توانید که داده می چرخد. شما می توانید نظر مشتق ایجاد کنید. اگر آن یک ساختار سند، شما می توانید ساختار صاف. شما می توانید ایندکس متناوب ایجاد کنید. همه نوع چیز شما می توانید با جریان DynamoDB. 

و واقعا، این چیزی است که به نظر می رسد. بنابراین شما می توانید آن روز رسانی های آینده در. آنها در حال آمدن کردن رشته است. آنها توسط تابع لامبدا به عنوان خوانده شده. آنها در حال چرخش داده ها و هل دادن آن در جداول مشتق شده، آگاه سیستم های خارجی از تغییر، و هل دادن داده ها را به ElastiCache. 

ما در مورد چگونه برای قرار دادن کش صحبت در مقابل پایگاه داده برای که فروش سناریو. خب چه اتفاقی می افتد اگر من به روز رسانی توضیحات مورد؟ خوب، اگر من تا به حال لامبدا تابع در حال اجرا در این جدول، اگر توضیحات مورد به روز کنم، آن را انتخاب کنید تا به رکورد کردن جریان، و آن را به روز رسانی ElastiCache به عنوان مثال با داده های جدید. به طوری که بسیاری از این آنچه که ما با لامبدا است. این کد چسب اتصالات است. و آن را در واقع می دهد توانایی برای راه اندازی و برای اجرای برنامه های بسیار پیچیده بدون یک سرور اختصاصی زیرساخت ها، که واقعا سرد است. 

بنابراین اجازه دهید به تماس به ما زمان واقعی معماری رای گیری. این جدید و بهبود یافته است با ما رودخانه ها و KCL نرم افزار را فعال کنید. مانند قبل، ما می توانیم رسیدگی به هر گونه مقیاس انتخابات. ما این را دوست. ما در حال انجام را جمع آوری پراکنده در سراسر سطل های متعدد. ما باید قفل خوش بینانه در رفتن. ما می توانیم رای دهندگان ما را نگه دارید از تغییر رای خود را. آنها فقط می تواند تنها یک بار رای دهید. این فوق العاده است. زمان واقعی تحمل خطا، تجمع مقیاس پذیر است. اگر چیزی می افتد، آن داند که در آن به خود راه اندازی مجدد هنگامی که آن را به بالا و به دلیل همراه ما با استفاده از نرم افزار KCL. و پس از آن ما نیز می توانید استفاده کنید که نرم افزار KCL به فشار داده انتقال به قرمز را برای دیگر تجزیه و تحلیل برنامه، و یا استفاده نگاشتکاهش الاستیک برای اجرا زمان واقعی واحدهای جریان خاموش از آن داده است. 

همه این چیزها ما در مورد خیلی صحبت نمی کند. اما آنها اضافی هستید فن آوری است که آمده به تحمل زمانی که شما به دنبال در این نوع از حالات. 

همه حق است، به طوری که در مورد تجزیه و تحلیل با DynamoDB جریان. شما می توانید د احمق جمع آوری داده ها، انجام تمام انواع از مسائل خوب، داده های کلی در حافظه، ایجاد آن جداول مشتق شده. که یک مورد استفاده بزرگ است که بسیاری از مشتریان با درگیر، به دست گرفتن تو در تو خواص آن اسناد JSON و ایجاد شاخص های اضافی. 

ما در پایان است. با تشکر از شما برای تحمل با من است. بنابراین اجازه دهید بحث در مورد معماری مرجع. DynamoDB نشسته در وسط تا بسیاری از زیرساخت AWS. در واقع شما می توانید آن را به قلاب به هر چیزی که می خواهید. نرم افزار ساخته شده با استفاده دینامو عبارتند از لامبدا، ElastiCache، CloudSearch، فشار داده را به الاستیک نگاشتکاهش، صادرات و واردات از DynamoDB به S3، انواع گردش. اما احتمالا بهترین چیزی که در مورد صحبت می کنید، و این چیزی است که واقعا جالب است که ما در مورد برنامه های کاربردی رویداد محور صحبت کنید. 

این یک نمونه از است یک پروژه داخلی که ما که در آن ما در واقع هستید چاپ و نشر به جمع آوری نتایج نظر سنجی. بنابراین در یک لینک ایمیل که ما از ارسال، آنجا خواهم یک کمی لینک کلیک گفت در اینجا برای پاسخ به نظر سنجی. و هنگامی که فرد کلیک این لینک، چه اتفاقی می افتد این است که آنها در پایین کشیدن امن فرم نظر سنجی از HTML S3. هیچ سرور وجود دارد. این فقط یک شی S3 است. 

که به صورت بالا می آید، بارگذاری میکند در مرورگر. آن را به ستون فقرات. این رو پیچیده جاوا اسکریپت که در حال اجرا. پس از آن نرم افزار بسیار غنی در حال اجرا در مرورگر مشتری. آنها نمی دانند که آنها نیست تعامل با سرور پایان دادن به عقب. در این نقطه، آن را تمام مرورگر است. 

آنها نتیجه را به انتشار آنچه ما در آمازون API دروازه پاسخ. API دروازه است به سادگی یک API وب که شما می توانید تعریف و قلاب تا به هر آنچه که شما می خواهید. در این مورد خاص، ما به یک تابع لامبدا قلاب. 

بنابراین عملیات POST من است اتفاق می افتد با هیچ سرور. اساسا API دروازه نشسته وجود دارد. آن را به من هزینه چیزی تا زمانی که مردم شروع ارسال پست به آن، درست است؟ تابع لامبدا فقط نشسته وجود دارد. و آن را به من هزینه چیزی تا زمانی که مردم شروع به هدف قرار دادن آن. بنابراین شما می توانید ببینید، به عنوان حجم افزایش می دهد، که زمانی که اتهامات آمده است. من یک سرور 7/24 است. 

بنابراین من به شکل جلو پایین از سطل، و من را از طریق API ارسال دروازه به تابع لامبدا. و پس از آن لامبدا تابع می گوید، شما می دانید چه، من مقداری PIIs کردم، برخی از اطلاعات شناسایی شخصی در این پاسخ. من نظر از کاربران است. من آدرس ایمیل کردم. من نام های کاربری را کردم. 

اجازه بدهید من این تقسیم کردن. من قصد دارم به تولید برخی از فراداده کردن این رکورد. و من قصد دارم به فشار ابرداده به DynamoDB. و من می توانم تمام داده ها را رمزگذاری و فشار آن را به DynamoDB اگر من می خواهم. اما آن را برای من ساده تر، در این مورد استفاده، به جلو بروید می گویند، من قصد دارم به فشار داده های خام به سطل S3 رمزگذاری شده است. بنابراین من با استفاده S3 در سمت سرور ساخته شده است رمزنگاری و مدیریت کلید آمازون خدمات به طوری که من یک کلید که می توانید در یک فاصله زمانی منظم چرخش، و من می توانم که داده PII محافظت به عنوان بخشی از طیف این گردش کار. 

بنابراین من چه کرده ام؟ من فقط به یک کل مستقر نرم افزار، و من هیچ سرور. بنابراین آن چیزی است که رویداد برنامه محور معماری را برای شما. 

حال اگر شما فکر می کنم در مورد مورد استفاده برای this-- ما به مشتریان دیگر من صحبت کردن در در مورد این معماری که دقیق اجرای کمپین های پدیداری بزرگ، که به دنبال در این و رفتن ها، آه من. چون در حال حاضر، آنها می توانند اساسا آن را فشار خارج وجود دارد، اجازه دهید که در مبارزات انتخاباتی فقط نشستن وجود دارد تا آن را راه اندازی، و نه به نگرانی در مورد انجیر چه نوع از زیرساخت است به وجود داشته باشد به حمایت از آن. و پس از آن به زودی به عنوان این کمپین انجام شده است، آن را مانند زیرساخت است فقط بلافاصله از بین می رود چون واقعا وجود دارد هیچ زیرساخت است. این کد فقط که نشسته است در لامبدا است. این داده ها که فقط در DynamoDB نشسته است. این یک راه شگفت انگیز است برای ساخت برنامه های. 

رسید پس از آن است زودگذر از آن خواهد بود اگر آن را در یک سرور واقعی ذخیره شده بود؟ 

RICK HOULIHAN: کاملا. از آنجا که مثال از سرور باید به یک 7/24. این است که در دسترس برای شود کسی برای پاسخ به. خوب حدس بزنید چه؟ S3 در دسترس 7/24 است. S3 همیشه پاسخ می دهد. و S3 بسیار، بسیار خوب است در خدمت کردن اشیاء. کسانی که اشیاء می تواند فایل های HTML، و یا فایل های جاوا اسکریپت، یا هر آنچه شما می خواهید. شما می توانید برنامه های کاربردی وب بسیار غنی اجرا از سطل S3، و مردم انجام دهد. 

و به طوری که این ایده را در اینجا است به دور از راه ما به فکر می کنم. همه ما به فکر می کنم در شرایط استفاده از سرور و میزبان. آن را در مورد که نیست. این در مورد زیرساخت به عنوان کد است. استقرار کد به ابر و اجازه دهید که ابر آن را اجرا برای شما. و این چیزی است که AWS است تلاش برای انجام. 

مخاطبان: بنابراین جعبه طلا خود را در وسط از API دروازه مانند سرور، اما به جای just-- است 

RICK HOULIHAN: شما می توانید فکر می کنم از آن به عنوان سرور نما. همه آن است که آن را یک HTTP را درخواست و نقشه آن را به یکی دیگر از فرایند. که همه آن را است. و در این مورد، ما در حال نقشه برداری آن را به یک تابع لامبدا. همه حق است، به طوری که تمام من است. خیلی ممنون. من آن را قدردانی میکنیم. من می دانم که ما می خواهیم کمی در طول زمان. و امیدوارم که شما بچه ها رو یک کمی از اطلاعات که شما می توانید دور امروز. و من عذر خواهی اگر من رفتم بیش از برخی از سر خود را، اما زیادی خوب وجود دارد دانش اساسی بنیادی که من فکر می کنم بسیار ارزشمند برای شما است. بنابراین شما برای داشتن من تشکر می کنم. [تشویق حضار] مخاطبان: [نامفهوم] است که شما می گفتند شما تا به حال از طریق چیزی به از آغاز تا پایان برای دریافت مقادیر مناسب و یا ارزش های مشابه، ارزش چگونه می اگر [نامفهوم] تغییر دهید. 

RICK HOULIHAN: اوه، idempotent است؟ چگونه ارزش را تغییر دهید؟ خب، چرا که اگر من اجرا نشد آن را تمام راه را به پایان، پس از آن من نمی دانم چه تغییراتی در آخرین مایل ساخته شده است. این نمی شود همان داده ها به عنوان آنچه که من دیدم. مخاطبان: اوه، بنابراین شما فقط اند کل ورودی بدست نیست. RICK HOULIHAN: درست است. شما باید برای رفتن از ابتدا به پایان است، و سپس آن را برای رفتن به یک حالت پایدار. خنک. 

رسید بنابراین شما به ما نشان داد DynamoDB می توانید سند و یا مقدار کلید را انجام دهد. و ما زمان زیادی را صرف در مقدار کلید را با hash و راه به آن تلنگر است. هنگامی که شما در آن جداول نگاه کرد، این است که پشت سر گذاشتن رویکرد سند؟ 

RICK HOULIHAN: من نیست می گویند آن را پشت سرگذاشت. 

رسید آنها از هم جدا شدند the-- 

RICK HOULIHAN: با سند رویکرد، نوع سند در DynamoDB است فقط از به عنوان ویژگی دیگر فکر میکنم. این یک ویژگی است که شامل است یک ساختار داده های سلسله مراتبی. و سپس در نمایش داده شد، شما می توانید خصوصیات استفاده از کسانی که اشیاء با استفاده از نشانه گذاری شی. بنابراین من می تواند در تو در تو فیلتر اموال از سند JSON. مخاطبان: بنابراین هر زمان که من انجام یک رویکرد سند، من مرتب از می توانید در tabular-- وارد مخاطبان: کاملا. مخاطبان: --indexes و چیزهایی که شما فقط در مورد صحبت کردیم. RICK HOULIHAN: آره، شاخص ها و همه این ها، وقتی که شما به صفحه اول می خواهم خواص از JSON، راه که ما می باید انجام دهید این است که اگر قرار دادن یک شی JSON و یا یک سند به دینامو، شما می توانید جریان استفاده کنید. جریان به ورودی را بخوانید. شما می خواهم که JSON اعتراض و شما می خواهم بگویم OK، چه اموال من به صفحه اول می خواهم؟ 

شما ایجاد یک جدول مشتق شده. حالا که راه کار می کند در حال حاضر است. ما شما را به صفحه اول اجازه نمی دهد به طور مستقیم آن دسته از خواص. 

مخاطبان: Tabularizing اسناد خود را. 

RICK HOULIHAN: دقیقا، مسطح آن، tabularizing آن، دقیقا. این چیزی است که شما را با آن انجام دهید. 

رسید با تشکر از شما. 

RICK HOULIHAN: بله، کاملا، از شما سپاسگزارم. رسید پس از آن نوع Mongo ها در دیدار classifers ردیس. 

RICK HOULIHAN: آره، آن را دوست دارم که. که یک توصیف خوبی برای آن است. خنک.