[عزف الموسيقى] RICK هوليهان: حسنا. أهلا بالجميع. اسمي ريك هوليهان. أنا مدير كبار حلول المعماري في AWS. أركز على NoSQL و تقنيات DynamoDB. أنا هنا اليوم لاجراء محادثات مع لكم قليلا عن تلك. 

خلفيتي هي في المقام الأول في طبقة البيانات. قضيت نصف تطوري مهنة الكتابة قاعدة البيانات، الوصول إلى البيانات، وحلول لمختلف التطبيقات. لقد كنت في الغيمة الافتراضية لنحو 20 عاما. حتى قبل أن سحابة الحوسبة السحابية، اعتدنا أن نسميها الحوسبة الخدمية. والفكرة، انها مثل PG & E، تدفعه مقابل ما تستخدمه. اليوم ونحن نسميها السحابة. 

لكن على مر السنين، لقد عملت لبضع شركات وربما كنت قد سمعت أبدا من. ولكن أنا قمت بتجميع قائمة من التقنية الإنجازات، أعتقد كنت أقول. لدي ثمانية براءات الاختراع في الأنظمة السحابية الافتراضية، وتصميم المعالجات الدقيقة، معالجة الحدث المعقد، ومناطق أخرى كذلك. 

حتى في هذه الأيام، وأنا تركز في معظمها على NoSQL تقنيات والجيل القادم قاعدة البيانات. وهذا عادة ما سأقوم أن أكون هنا أتحدث إليكم اليوم عن. ذلك ما يمكن أن تتوقعه من هذه الدورة، سنذهب من خلال سطور تاريخ معالجة البيانات. فمن المفيد دائما ل فهم من أين أتينا ولماذا نحن ما نحن فيه. وسنتحدث قليلا قليلا عن التكنولوجيا NoSQL من وجهة النظر الأساسية. 

ونحن سوف ندخل في بعض الأجزاء الداخلية DynamoDB. DynamoDB هو AWS في أي نكهة. انها تدار بالكامل و استضافت حل NoSQL. وسنتحدث قليلا عن الجدول هيكل، واجهات برمجة التطبيقات، وأنواع البيانات والمؤشرات، وبعض من الأجزاء الداخلية تلك التكنولوجيا DynamoDB. أننا سنصل إلى بعض من تصميم أنماط وأفضل الممارسات. سوف نتحدث عن كيف استخدام هذه التكنولوجيا لبعض من تطبيقات اليوم. ثم سنتحدث قليلا عن تطور أو ظهور نموذج جديد في البرمجة دعا التطبيقات الحدث يحركها وكيف يلعب DynamoDB في ذلك أيضا. ونحن سوف أترك لكم قليلا من مناقشة العمارة المرجعية حتى نتمكن من الحديث عن بعض الطرق التي يمكن استخدامها DynamoDB. 

أولا حتى off-- هذا هو السؤال أسمع الكثير هو، ما هو قاعدة بيانات. وهناك الكثير من الناس يعتقدون أنهم تعرف ما هي قاعدة البيانات. إذا كنت جوجل، وسترى هذا. انها مجموعة منظم للبيانات عقد في الكمبيوتر، وخاصة تلك التي يمكن الوصول إليه بطرق مختلفة. اعتقد ان هذا جيد تعريف قاعدة بيانات حديثة. ولكن أنا لا أحب ذلك، ل أنه ينطوي على أمرين. أنه ينطوي هيكل. وهذا يعني ضمنا أنه على جهاز كمبيوتر. ولم قواعد البيانات لا دائما موجودة على أجهزة الكمبيوتر. قواعد بيانات موجودة فعلا في العديد من الطرق. 

لذلك تعريف أفضل ل قاعدة بيانات شيء من هذا القبيل. هو تنظيم قاعدة البيانات آلية لتخزين وإدارة و واسترجاع المعلومات. هذا من About.com. لذلك أنا أحب هذا لأنه حقا المحادثات حول قاعدة بيانات كونها مستودع، مستودع لل المعلومات، وليس بالضرورة وهو الأمر الذي يجلس على جهاز كمبيوتر. وعبر التاريخ، ونحن لم يكن دائما أجهزة الكمبيوتر. 

الآن، إذا كنت تسأل المتوسط مطور اليوم ما هو قاعدة بيانات، وهذا هو الجواب الذي تحصل عليه. في مكان ما أستطيع أن عصا الاشياء. الصحيح؟ وهذا صحيح. ولكن من المؤسف. لأن قاعدة البيانات هو حقا أساس التطبيق الحديث. انها الأساس كل تطبيق. وكيف أن بناء قاعدة بيانات، كيف هيكل أن البيانات سوف تملي كيف أن تطبيق ينفذ كما كنت نطاق واسع. 

لذلك الكثير من وظيفتي اليوم والتعامل مع ما يحدث عندما المطورين اتخاذ هذا النهج والتعامل مع آثار من تطبيق ورفع الآن إلى ما بعد الأصلي النية والمعاناة من تصميم سيئة. لذلك نأمل عند سيرا على الاقدام اليوم، عليك لدينا اثنين من الأدوات في حزامك التي سوف تبقى لكم من صنع تلك الأخطاء نفسها. حسنا. لذلك دعونا نتحدث عن القليل من الجدول الزمني للتكنولوجيا قاعدة البيانات. أعتقد قرأت المادة ليس ذلك منذ فترة طويلة وقال شيئا على lines-- انها البيان الشعري جدا. وقالت ان التاريخ البيانات المعالجة كامل من علامات مائية عالية وفرة البيانات. حسنا. الآن، وأنا أعتقد أن هذا نوع من صحيح. لكنني في الواقع تبدو في غير النحو التاريخ مليء الواقع مع علامة مائية عالية من ضغط البيانات. لأن معدل البيانات ابتلاع تنخفض أبدا. وغني إلا أن ترتفع. 

ويحدث عندما الابتكار ونحن نرى ضغط البيانات، والتي هي كمية البيانات التي يتم الآن في حيز النظام. وأنه لا يمكن معالجتها بكفاءة سواء في الوقت أو في التكاليف. وذلك عندما نبدأ للنظر في ضغط البيانات. 

لذلك عندما ننظر إلى قاعدة بيانات الأولى، وهذا هو الذي كان بين آذاننا. نحن ولدنا جميعا معها. انها قاعدة بيانات لطيفة. لديها وفرة عالية. انها دائما على. يمكنك دائما الحصول عليه. 

ولكن من مستخدم واحد. لا أستطيع أن حصة أفكاري معك. لا يمكنك الحصول على أفكاري عندما تريد لهم. وأبيليتيي ليست جيدة جدا. نحن ننسى الأشياء. بين الحين والآخر، واحد منا الأوراق وينتقل إلى وجود آخر ونفقد كل شيء كان ذلك في قاعدة البيانات. لذلك هذا ليس كل شيء على ما يرام. 

وهذا يعمل بشكل جيد على مر الزمن عندما كنا مرة في اليوم وإذا كنا حقا بحاجة إلى معرفته هو أين نحن ذاهبون للذهاب غدا أو حيث نجتمع أفضل أنواع الطعام. ولكن كما بدأنا في النمو باعتباره بدأت الحضارة والحكومة إلى حيز الوجود، و بدأت الشركات في التطور، بدأنا ندرك أننا تحتاج إلى أكثر قليلا من ما يمكننا أن نضع في رؤوسنا. حسنا؟ 

نحن بحاجة أنظمة قياسية. نحن بحاجة الأماكن لتكون قادرة تخزين البيانات. لذلك بدأنا كتابة الوثائق، إنشاء المكتبات والمحفوظات. بدأنا تطوير نظام محاسبة دفتر الأستاذ. وهذا النظام من دفتر الأستاذ العد ركض العالم لقرون عديدة، وربما آلاف السنين كما نحن نوع من نما إلى نقطة حيث تجاوز ذلك تحميل البيانات قدرة تلك الأنظمة لتكون قادرة على احتوائه. 

وهذا حدث فعلا في 1880s. الصحيح؟ في الولايات المتحدة تعداد 1880. هذا هو حقا حيث تحول نشير معالجة البيانات الحديثة. هذه هي النقطة التي كمية البيانات التي يجري جمعها من قبل حصلت الحكومة الأميركية إلى نقطة حيث استغرق ثماني سنوات لهذه العملية. 

الآن، ثمانية years-- كما تعلمون، فإن التعداد مرة كل 10 years-- لذلك فمن واضح جدا أنه بحلول الوقت الذي حصلت على تعداد عام 1890، كمية البيانات التي كان على وشك أن معالجتها من قبل الحكومة كان سنتجاوز ال 10 عاما أنه سيستغرقه لإطلاق تعداد جديد. وكانت هذه المشكلة. 

لذلك الرجل يدعى هيرمان جاء هولليريث على طول واخترع وحدة قياسية لكمة بطاقات، وقارئ بطاقة لكمة، بطاقة لكمة الجدوال، وجمع من آليات لهذه التكنولوجيا. وتلك الشركة أنه شكلت في الوقت، جنبا إلى جنب مع اثنين آخرين، أصبح في الواقع واحدة من ركائز شركة صغيرة نعرفه اليوم ودعا IBM. 

لذلك IBM كان في الأصل في أعمال قاعدة البيانات. وهذا حقا ما فعلوه. فعلوا معالجة البيانات. 

وذلك انتشار لكمة بطاقات، وآليات مبتكرة أن تكون قادرة على الاستفادة من هذه التكنولوجيا لالاستقصاء مجموعات النتائج التي تم فرزها. يمكنك ان ترى في هذه الصورة. يوجد لدينا little-- انها small-- قليلا لكن يمكنك أن ترى آلية ميكانيكية بارعة جدا حيث لدينا سطح السفينة بطاقة لكمة. وأخذ شخص ما قليلا مفك والشائكة من خلال فتحات ورفعه لأعلى للحصول على هذه المباراة، التي مجموعة النتائج فرزها. 

هذا هو التجميع. ونحن نفعل ذلك في كل وقت اليوم في الكمبيوتر، حيث يمكنك أن تفعل ذلك في قاعدة البيانات. اعتدنا أن نفعل ذلك يدويا، أليس كذلك؟ وضع الناس هذه الأشياء معا. وكان انتشار من هذه البطاقات لكمة في ما أسميناه الطبول البيانات وبكرات البيانات، ورقة الشريط. 

أخذت صناعة معالجة البيانات درسا من البيانو لاعب. لاعب البيانو مرة أخرى في في مطلع القرن العشرين تستخدم لاستخدام بكرات الورق مع فتحات على أن أقول أنه المفاتيح التي للعب. لذلك تم تكييفها أن التكنولوجيا في نهاية المطاف لتخزين البيانات الرقمية، لأنها قد وضعت هذه البيانات على تلك بكرات شريط ورقي. 

الآن، ونتيجة لذلك، بيانات وكيف actually-- يمكنك الوصول إلى هذه البيانات مباشرة كان تعتمد على كيفية تخزينها. حتى لو كنت وضع البيانات على الشريط، كان لي الوصول إلى البيانات خطيا. كان لي للفة كله الشريط للوصول إلى كافة البيانات. إذا وضعت البيانات في لكمة بطاقات، ويمكنني أن الوصول إليه في أكثر من ذلك بقليل عشوائي أزياء، ربما ليس بالسرعة. 

ولكن كانت هناك قيود في كيفية الوصول إلى البيانات على أساس كيف تم تخزينها. وهكذا كان هذا مشكلة الخوض في '50S. مرة أخرى، يمكننا أن نبدأ في رؤية ذلك ونحن تطوير تقنيات جديدة لمعالجة البيانات، والحق، فإنه يفتح الباب عن حلول جديدة، لبرامج جديدة، جديدة طلبات الحصول على تلك البيانات. وحقا، والحكم قد يكون السبب لماذا وضعنا بعض هذه النظم. ولكن العمل أصبح بسرعة السائق وراء تطور قاعدة بيانات حديثة و نظام الملفات الحديث. 

ذلك الشيء التالي الذي جاء كان في '50S كان نظام الملفات و تطوير تخزين الوصول العشوائي. هذا كان جميل. الآن، كل من المفاجئ، يمكننا أن نضع الملفات في أي مكان على هذه الأقراص الصلبة ويمكننا الوصول إلى هذه البيانات بشكل عشوائي. يمكننا أن تحليل المعلومات من الملفات. وحللنا كل العالم ل مشاكل مع معالجة البيانات. 

والتي استمرت نحو 20 أو 30 سنوات حتى تطور من قواعد البيانات العلائقية، والتي عندما قرر العالم ونحن الآن الحاجة إلى وجود مستودع أن يهزم الامتداد من البيانات عبر الملف نظم أننا قد بنيت. الصحيح؟ الكثير من البيانات الموزعة في عدد كبير جدا الأماكن، والازدواجية دي البيانات، وكانت تكلفة تخزين هائلة. 

في '70s، المورد الأغلى أن جهاز كمبيوتر زيارتها كانت التخزين. كان المعالج ينظر إليها على أنها تكلفة ثابتة. عندما كنت شراء مربع، وحدة المعالجة المركزية يفعل بعض العمل. انها ستكون الغزل سواء انها تعمل فعلا أم لا. هذا هو حقا تكلفة غرقت. 

ولكن ما كلفني باعتباره العمل هو التخزين. إذا كان لدي لشراء المزيد من الأقراص المقبل الشهر، وهذا هو التكلفة الحقيقية أن أدفع. وأن تخزين مكلفة. 

نحن الآن سريع إلى الأمام 40 عاما وليس لدينا مشكلة مختلفة. وحوسبة هو الآن أغلى الموارد. تخزين رخيص. أعني، يمكننا أن نذهب في أي مكان على سحابة ويمكن أن نجد تخزين رخيصة. ولكن ما لا أستطيع أن أجد غير حساب رخيصة. 

وبالتالي فإن تطور اليوم التكنولوجيا، تكنولوجيا قاعدة البيانات، حقا يتركز حول قواعد البيانات الموزعة التي لا تعاني من نفس النوع من نطاق القيود المفروضة على قواعد البيانات العلائقية. سنتحدث قليلا عن ماذا يعني ذلك في الواقع. 

ولكن أحد الأسباب و السائق وراء this-- نحن تحدثت عن ضغط البيانات. ضغط البيانات هو شيء الذي يدفع الابتكار. وإذا نظرتم أكثر خلال السنوات الخمس الماضية، هذا هو مخطط لما البيانات تحميل عبر المؤسسة العامة يبدو في السنوات الخمس الماضية. 

وكقاعدة عامة من الإبهام هذه days-- إذا ذهبت Google-- 90٪ من البيانات التي نقوم بتخزين اليوم، وكان ولدت في العامين الماضيين. حسنا. الآن، ليس هذا هو الاتجاه الذي هو الجديد. هذا هو الاتجاه وهذا ما كان الخروج لمدة 100 سنة. منذ هيرمان هولليريث وضعت بطاقة لكمة، لقد تم بناء مستودعات البيانات وجمع البيانات بمعدلات هائلة. 

لذلك على مدى السنوات ال 100 الماضية، لقد رأيت هذا الاتجاه. التي لن تتغير. الذهاب إلى الأمام، ونحن في طريقنا لرؤية هذا، إن لم يكن اتجاها متسارعة. ويمكنك ان ترى ما يشبه. 

إذا كان العمل في 2010 وكان واحد تيرابايت من البيانات المدارة، اليوم وهذا يعني انهم إدارة 6.5 بيتابايت من البيانات. هذا 6500 بيانات مرات أكثر. وأنا أعرف هذا. أنا أعمل مع هذه الشركات كل يوم. قبل خمس سنوات، وأنا سيتحدث للشركات الذي من شأنه أن يتحدث معي حول ما ألم فمن لإدارة تيرابايت من البيانات. وأنها ستتحدث لي عن كيف نرى أن هذا هو الارجح أن يكون بيتابايت أو اثنين في غضون بضع سنوات. 

هذه الشركات نفسها اليوم أنا لقائه، ويتحدثون لي عن المشكلة هي وجود هناك إدارة عشرات، 20 بيتابايت من البيانات. حتى انفجار البيانات في الصناعة تقود هائلة تحتاج لإيجاد حلول أفضل. وقواعد البيانات العلائقية هي فقط لا يرقى إلى مستوى الطلب. 

ولذا فإن هناك الخطية العلاقة بين ضغط البيانات والابتكار التقني. لقد بين لنا التاريخ هذا، أنه بمرور الوقت، كلما حجم البيانات التي تحتاج إلى معالجتها يتجاوز قدرة النظام لمعالجة ذلك في فترة زمنية معقولة أو بتكلفة معقولة، تقنيات جديدة ثم واخترع لحل تلك المشاكل. هذه التكنولوجيات الجديدة، في المقابل، فتح الباب إلى مجموعة أخرى من المشاكل، التي وجمع المزيد من البيانات. 

الآن، ونحن لن نوقف هذا. الصحيح؟ نحن لن نوقف هذا. لماذا ا؟ لأنك لا يمكن أن تعرف كل شيء هناك لمعرفة في الكون. وطالما كنا على قيد الحياة، طوال تاريخ الرجل، نحن دفعت دائما لمعرفة المزيد. 

لذلك يبدو كل شبر ننتقل السير على طريق الاكتشاف العلمي، نحن بضرب كمية البيانات أننا بحاجة إلى معالجة أضعافا مضاعفة كما أننا كشف أكثر وأكثر وأكثر حول الأعمال الداخلية للحياة، حول الكيفية التي يعمل بها الكون، حول يقود هذا الاكتشاف العلمي، واختراع نقوم به اليوم. حجم البيانات فقط يزيد باستمرار. حتى تكون قادرة على التعامل مع هذه المشكلة هائلة. 

حتى واحد من الأشياء نحن تبدو كما NoSQL لماذا؟ كيف NoSQL حل هذه المشكلة؟ حسنا، قواعد البيانات العلائقية، لغة الاستعلام الهيكلية، SQL-- هذا حقا بناء لل العلائقية database-- هذه الأمور الأمثل للتخزين. 

مرة أخرى في '70s، مرة أخرى، القرص مكلفة. ممارسة توفير التخزين في المؤسسة هو لا تنتهي أبدا. اعرف. عشت ذلك. كتبت السائقين التخزين ل شركة superserver enterprised مرة أخرى في '90. وبيت القصيد هو الاجهاد آخر وكانت مجموعة تخزين مجرد شيء حدث كل يوم في المؤسسة. وأنه لم يتوقف. التخزين العالي الكثافة، الطلب لتخزين عالية الكثافة، وللتخزين أكثر كفاءة devices-- انها توقفت أبدا. 

وNoSQL هي تقنية كبيرة لأنه تطبيع البيانات. هو دي تكرار البيانات. أنه يضع البيانات في هيكل هو الملحد لكل نمط الوصول. يمكن لتطبيقات متعددة ضرب ذلك قاعدة بيانات SQL، تشغيل استعلامات ad hoc، والحصول على البيانات في شكل أنهم تحتاج إلى معالجة مع أعباء العمل. هذا يبدو رائعا. ولكن بيت القصيد هو مع أي النظام، إذا كان الملحد على كل شيء، هو الأمثل من أجل لا شيء. موافق؟ 

وهذا هو ما نحصل عليه مع قاعدة البيانات العلائقية. هو الأمثل لأنه التخزين. انها طبيعية. انها العلائقية. وهو يدعم الاستعلامات المخصصة. وذلك والمقاييس عموديا. 

إذا كنت بحاجة للحصول على قاعدة بيانات SQL أكبر أو قاعدة بيانات SQL أكثر قوة، أذهب شراء قطعة أكبر من الحديد. موافق؟ لقد عملت مع الكثير من الزبائن التي تم من خلال تحسينات كبيرة في البنية التحتية SQL بهم فقط لمعرفة بعد ستة أشهر، انهم ضرب الجدار مرة أخرى. والجواب من أوراكل أو MSSQL أو أي شخص آخر هو الحصول على أكبر مربع. حسنا عاجلا أو آجلا، لا يمكنك شراء مربع أكبر، وهذا هو المشكلة الحقيقية. نحن بحاجة إلى تغيير الواقع الأشياء. فأين يعمل هذا؟ أنه يعمل بشكل جيد للحاليا تحليلات، من نوع OLAP أعباء العمل. وهذا هو حقا حيث ينتمي SQL. الآن، وانها تستخدم اليوم في العديد من الانترنت معاملات معالجة من نوع التطبيقات. ويعمل على ما يرام في مستوى معين من الاستخدام، ولكن فقط لا مقياس الطريقة التي NoSQL لا. وسنتحدث قليلا قليلا عن لماذا هذا هو. 

الآن، NoSQL، من ناحية أخرى، وأكثر الأمثل للحوسبة. موافق؟ فإنه ليس الملحد ل نمط الوصول. هو ما نسميه دي تطبيع هيكل أو بنية هرمية. البيانات في قاعدة بيانات علائقية هو انضمت معا من جداول متعددة لإنتاج وجهة النظر التي تحتاجها. البيانات في قاعدة بيانات NoSQL يتم تخزينها في وثيقة يحتوي على بنية هرمية. جميع البيانات التي تكون عادة انضمت معا لإنتاج هذا الرأي يتم تخزينها في وثيقة واحدة. وسنتحدث قليلا عن كيف يعمل في بضع الرسوم البيانية. 

ولكن الفكرة هنا هي أن تقوم بتخزين البيانات الخاصة بك كما هذه الآراء مثيل. موافق؟ قمت بقياس أفقيا. الصحيح؟ إذا كنت بحاجة لزيادة حجم الكتلة NoSQL بلدي، ولست بحاجة للحصول على مربع أكبر. أحصل على آخر مربع. وأنا تجميع تلك معا، وأستطيع أن شارد تلك البيانات. سنتحدث قليلا عن ما هي sharding، ليكون قادرة على توسيع نطاق قاعدة البيانات عبر وسائل مادية متعددة وإزالة الحاجز الذي تتطلب مني لتوسيع نطاق عموديا. 

حتى انها بنيت حقا على الانترنت معالجة المعاملات واسع. هناك فرق كبير هنا بين التقرير، أليس كذلك؟ الإبلاغ، وأنا لا أعرف أسئلة انا ذاهب الى تسأل. الصحيح؟ Reporting-- إذا كان شخص ما من بلدي قسم التسويق يريد just-- كم من زبائني لديهم هذه الخاصية خاصة الذين اشترى في هذا day-- لا أعرف ما الاستعلام انهم ذاهبون لنسأل. لذلك أنا بحاجة إلى أن يكون الملحد. 

الآن، في الانترنت تطبيق المعاملات، وأنا أعلم ما هي الأسئلة أنا أسأل. لقد بنيت تطبيق ل سير عمل محددة للغاية. موافق؟ حتى لو كنت تحسين البيانات تخزين لدعم هذا العمل، انها سوف تكون أسرع. وهذا هو السبب في NoSQL يمكن حقا تسريع تسليم هذه الأنواع من الخدمات. حسنا. 

لذلك نحن ذاهبون للوصول الى قليلا من الناحية النظرية هنا. والبعض منكم، عينيك قد دحر قليلا. ولكن سأحاول أن يبقيه مستوى عال ما أستطيع. حتى إذا كنت في المشروع إدارة، وهناك وبناء يسمى مثلث القيود. حسنا. مثلث القيود يمليه لا يمكنك الحصول على كل شيء في كل وقت. لا يمكن أن يكون فطيرة بك وأكله أيضا. حتى في إدارة المشاريع، وهذا المثلث القيود هي أنك يمكن أن يكون لها أنها رخيصة، هل يمكن أن يكون ذلك بسرعة، أو هل يمكن أن يكون ذلك جيدا. اختر اثنان. لأنك لا يمكن أن يكون كل ثلاثة. الصحيح؟ حسنا. 

حتى تسمع عن هذا الكثير. انها القيد الثلاثي، مثلث الجبرية الثلاثي، أو المثلث الحديدي هو oftentimes-- عندما تتحدث إلى مديري المشاريع، انهم سوف نتحدث عن هذا. الآن، وقواعد البيانات لديها على المثلث الحديدي الخاص. والمثلث الحديدي البيانات هو ما نسميه CAP نظرية. موافق؟ 

CAP إملاءات نظرية كيف تعمل على قواعد البيانات في ظل حالة محددة جدا. وسوف نتحدث عن ما هو هذا الشرط. ولكن النقاط الثلاث للمثلث، إذا جاز التعبير، هي C، والاتساق. موافق؟ حتى في CAP، والاتساق يعني أن جميع العملاء الذين يمكنهم الوصول إلى قاعدة بيانات سوف يكون دائما جدا عرض ثابت من البيانات. ستعمل لا أحد يرى شيئين مختلفين. موافق؟ إذا رأيت قاعدة البيانات، اراه نفس الرأي كما شريكي الذي يرى نفس قاعدة البيانات. هذا الاتساق. 

توافر يعني أنه إذا كان قاعدة بيانات على شبكة الإنترنت، إذا كان يمكن التوصل إليه، التي من شأنها أن جميع العملاء دائما تكون قادرة على القراءة والكتابة. موافق؟ لذلك كل عميل يمكن قراءة قاعدة البيانات سوف تكون دائما قادرة قراءة البيانات بيانات والكتابة. وإذا كان هذا هو الحال، انها نظام المتاحة. 

والنقطة الثالثة هي ما ندعو التقسيم التسامح. موافق؟ وسائل التقسيم التسامح أن النظام يعمل بشكل جيد على الرغم من الشبكة المادية أقسام بين العقد. موافق؟ لذلك العقد في الكتلة لا يمكن التحدث مع بعضهم البعض، ماذا يحدث؟ حسنا. 

قواعد البيانات العلائقية ذلك choose-- يمكنك اختيار اثنين من هؤلاء. حسنا. قواعد البيانات العلائقية لذلك اختر أن تكون متسقة ومتاحة. إذا كان القسم يحدث بين وDataNodes في مخزن البيانات، تعطل قاعدة البيانات. الصحيح؟ وغني فقط إلى أسفل. حسنا. 

وهذا هو السبب لديهم لتنمو مع مربعات أكبر. الصحيح؟ لأنه لا يوجد no-- عادة، مجموعة قاعدة البيانات، وليس هناك عدد كبير جدا منهم التي تعمل بهذه الطريقة. ولكن معظم قواعد البيانات مقياس عموديا داخل صندوق واحد. لأنها تحتاج إلى أن تكون بما يتفق والمتاحة. إذا كان قسم ليتم حقنه، ثم قد تضطر إلى اتخاذ خيار. لديك لجعل الاختيار بين كونها تتفق والمتاحة. 

وهذا ما تفعله قواعد بيانات NoSQL. حسنا. لذلك قاعدة بيانات NoSQL، فإنه يأتي في اثنين من النكهات. نحن have-- بشكل جيد، فإنه يأتي في عدة أشكال، لكنه يأتي مع اثنين الأساسية characteristics-- ما يمكن أن نسميه قاعدة بيانات CP، أو التسامح ثابت والتقسيم نظام. هؤلاء الرجال جعل الخيار الذي عندما العقد تفقد الاتصال مع بعضها البعض، نحن لن نسمح الناس إلى إرسال أي أكثر. موافق؟ 

حتى تتم إزالة هذا القسم، تم منع وصول الكتابة. وهذا يعني انهم غير متوفر. انهم ثابت. عندما نرى أن تقسيم حقن نفسها، نحن الآن متسقة، لأننا لن للسماح للتغيير البيانات على اثنين جوانب من قسم مستقل من بعضها البعض. سيكون لدينا ل إعادة تأسيس الاتصالات قبل أي تحديث ل يسمح للبيانات. موافق؟ 

ان نكهة المقبلة ستكون نظام AP، أو المتاحة وتقسيم نظام التسامح. هؤلاء الرجال لا يعيرون اي اهتمام. الصحيح؟ أي عقدة أن يحصل على إرسال، سوف أعتبر. لذلك أنا تكرار البيانات الخاصة بي عبر العقد متعددة. هذه العقد الحصول على العميل، ويأتي العميل في، ويقول: أنا ذاهب إلى كتابة بعض البيانات. يقول عقدة، لا مشكلة. عقدة بجانبه يحصل الكتابة على نفس السجل، وقال انه ذاهب ليقول لا مشكلة. في مكان ما يعود في النهاية إلى الوراء، يسير على تلك البيانات إلى تكرار. ثم شخص ما سوف تدرك، اه-يا، نظام انهم سيدركون أه أوه، كان هناك تحديثا لالجانبين. ماذا نفعل؟ وماذا يفعلون بعد ذلك هو يفعلون الشيء الذي تتيح لهم حل تلك الدولة البيانات. وسوف نتحدث عن أنه في الرسم البياني التالي. 

شيء أن نشير هنا. وأنا لن تحصل أيضا كثيرا في هذا، لأن هذا يحصل في نظرية البيانات عميقة. ولكن هناك المعاملات الإطار الذي يعمل في نظام العلائقية التي يتيح لي الفرصة لإجراء تحديثات بأمان إلى كيانات متعددة في قاعدة البيانات. وتلك التحديثات سيحدث في كل مرة أم لا على الإطلاق. وهذا ما يسمى المعاملات ACID. موافق؟ 

ACID يعطينا atomicity، التناسق، العزلة، والمتانة. موافق؟ وهذا يعني ذرية، والمعاملات، كل تحديثات بريدي إما أن يحدث أو لم يفعلوا ذلك. الاتساق يعني أن سوف قاعدة البيانات دائما أن يقدم إلى متسقة الدولة بعد التحديث. أنا لن أترك قاعدة البيانات في حالة سيئة بعد تطبيق التحديث. موافق؟ 

لذلك هو مختلفة قليلا من CAP الاتساق. CAP الاتساق يعني كل ما عندي يمكن للعملاء دائما أن نرى البيانات. الاتساق حامض يعني أنه عندما انها فعلت معاملة، في بيانات جيدة. علاقاتي كلها جيدة. أنا لا أذهب إلى حذف صف الأم وترك مجموعة من الأطفال الأيتام في بعض الجدول الآخر. لا يمكن أن يحدث إذا أنا متسقة في معاملة الحمضية. 

العزلة يعني أن المعاملات وتحدث دائما واحدا تلو الآخر. النتيجة النهائية للبيانات سوف تكون هي نفسها الدولة وكأن تلك المعاملات التي صدرت في وقت واحد أعدم متسلسل. لذلك فمن التزامن التحكم في قاعدة البيانات. ذلك أساسا، لا أستطيع زيادة في نفس القيمة مرتين مع اثنين من العمليات. 

ولكن إذا قلت إضافة 1 إلى هذه القيمة، وصفقتين تأتي في وتحاول أن تفعل ذلك، واحدة من الذهاب للوصول إلى هناك أولا والآخر ل الذهاب للوصول إلى هناك بعد. حتى في نهاية المطاف، وأضفت اثنين. ترى ما أعنيه؟ حسنا. 

المتانة هي جميلة واضحة. عندما الصفقة ومن المسلم به، انها ستكون هناك حتى إذا تعطل النظام. عندما يتعافى هذا النظام، أن الصفقة التي ارتكبت هو في الواقع سيكون هناك. ذلك أن الضمانات المعاملات ACID. تلك هي الضمانات لطيفة وجميلة أن يكون على قاعدة بيانات، ولكنها تأتي في ذلك تكلفة. الصحيح؟ 

لأن المشكلة مع هذا الإطار إذا كان هناك قسم في البيانات مجموعة، لا بد لي من اتخاذ قرار. أنا ذاهب لدينا للسماح تحديثات على جانب واحد أو آخر. وإذا ما حدث ذلك، ثم أنا لم يعد الذهاب لتكون قادرة على الحفاظ على تلك الخصائص. فإنها لن تكون متسقة. أنها لن تكون معزولة. هذا هو المكان الذي ينهار لقواعد البيانات العلائقية. هذا هو السبب العلائقية قواعد بيانات مقياس عموديا. 

من ناحية أخرى، لدينا ما يسمى التكنولوجيا BASE. وهذه هي NoSQL قواعد البيانات الخاصة بك. حسنا. لذلك نحن لدينا CP، قواعد البيانات AP. وهذه هي ما تسمونه الأساس المتاحة، دولة ضعيفة، في نهاية المطاف متسقة. موافق؟ 

متوفر في الأساس، ل انهم التقسيم تسامحا. وأنها ستكون دائما هناك، حتى إذا كان هناك قسم الشبكة بين العقد. اذا كنت استطيع التحدث إلى عقدة، وأنا سوف تكون قادرة على قراءة البيانات. موافق؟ أنا قد لا تكون دائما قادرة على إرسال البيانات إذا أنا منصة ثابتة. ولكنني سوف تكون قادرا على قراءة البيانات. 

وتشير الدولة لينة أنه عندما قرأت تلك البيانات، قد لا يكون نفس العقد الأخرى. إذا صدر بحق على عقدة مكان آخر في الكتلة وأنها لم تتكرر في جميع أنحاء الكتلة ولكن عندما قرأت تلك البيانات، أن الدولة قد لا تكون متسقة. ومع ذلك، فإنه سيكون في نهاية المطاف متسقة، وهذا يعني أنه عندما الكتابة وأدخلت على النظام، فإنه سيتم تكرار عبر العقد. وفي نهاية المطاف، تلك الدولة وسوف تعرض في النظام، وسيكون من حالة متناسقة. 

الآن، CAP نظرية حقا يلعب إلا في حالة واحدة. هذا الشرط هو عندما يحدث هذا. لأنه كلما انها تعمل في الوضع العادي، وليس هناك التقسيم، كل شيء على ما يتفق والمتاحة. كنت تقلق فقط عن CAP عندما يكون لدينا هذا القسم. حتى تلك هي نادرة. ولكن كيف يتفاعل النظام عند تلك تحدث إملاء ما نوع النظام نتعامل معها. 

لذلك دعونا نلقي نظرة على ما يشبه لأنظمة AP. موافق؟ نظم AP يأتي في اثنين من النكهات. أنها تأتي في نكهة الذي هو ماجستير ماجستير، 100٪، متوفرة دائما. وأنها تأتي في نكهة أخرى، الذي يقول: أنت تعرف ماذا، أنا ذاهب للقلق عن هذا الشيء التقسيم عند حدوث التقسيم الفعلي. خلاف ذلك، هناك سيكون الابتدائية العقد الذي سيستغرق الحقوق. موافق؟ 

حتى إذا كان لدينا شيء مثل كاساندرا. سوف كاساندرا تكون على درجة الماجستير الماجستير، دعونا لي الكتابة إلى أي عقدة. فما يحدث؟ لذلك ليس لدي كائن في قاعدة بيانات موجود على عقدتين. دعونا نسمي هذا الكائن S. لذلك لدينا دولة لS. لدينا بعض العمليات على S التي هي مستمرة. كاساندرا يتيح لي الفرصة ل إرسال إلى العقد متعددة. لذلك دعونا نقول أحصل على أكتب عن الصورة لعقدتين. حسنا، ما ينتهي يحدث هو نحن ندعو إلى أن حدث التقسيم. قد لا يكون هناك تقسيم الشبكة الفعلية. ولكن نظرا للتصميم للنظام، وانها تقسيم الواقع في أقرب وقت كما أحصل على الكتابة على عقدتين. انها ليست أجبروني على إرسال كل ذلك من خلال عقدة واحدة. أنا أكتب على عقدتين. موافق؟ 

وحتى الآن لدي دولتين. موافق؟ ماذا سيحدث غير عاجلا أو آجلا، هناك سيكون حدثا النسخ المتماثل. هناك سيكون ما يسمى الانتعاش التقسيم، والتي حيث هذين الدول تأتي معا مرة أخرى وهناك سيكون خوارزمية الذي يمتد داخل قاعدة البيانات، تقرر ما يجب القيام به. موافق؟ افتراضيا، آخر تحديث يفوز في معظم النظم AP. ولذلك لا يوجد عادة خوارزمية الافتراضي، ما يسمونه رد وظيفة، وهو الأمر الذي سوف يتم استدعاؤها عند هذا الشرط تم الكشف عن لتنفيذ بعض المنطق لحل هذا النزاع. موافق؟ رد الاتصال الافتراضية والافتراضية محلل في معظم قواعد البيانات AP هو، تخمين ما، يفوز الطابع الزمني. كان هذا آخر تحديث. انا ذاهب الى وضع هذا التحديث في هناك. أنا قد تفريغ هذا السجل بأنني ملقاة خارج في سجل الانتعاش بحيث يمكن للمستخدم أن يعود في وقت لاحق ويقول: مهلا، كان هناك تصادم. ماذا حدث؟ ويمكنك تفريغ الواقع بسجل جميع التصادمات ومستواها السابق ونرى ما سيحدث. 

الآن، كمستخدم، يمكنك أيضا تضمين منطق في هذا الاستدعاء. حتى تتمكن من تغيير ذلك عملية الاستدعاء. هل يمكن القول، مهلا، أريد لإصلاح هذه البيانات. وكنت أريد أن أحاول و دمج تلك السجلات اثنين. ولكن هذا متروك لكم. لا يعرف قاعدة بيانات كيفية القيام بذلك عن طريق الافتراضية. معظم الوقت، الشيء الوحيد قاعدة البيانات يعرف كيفية القيام به هو القول، وكان هذا واحد السجل الأخير. هذا هو واحد أن يكون النصر، وهذا هو قيمة انا ذاهب الى وضع. مرة واحدة أن الانتعاش التقسيم ويحدث النسخ المتماثل، لدينا دولتنا، التي غير سنغافوري الآن رئيس الوزراء، الذي هو الدولة دمج كل تلك الكائنات. من النظم AP لها هذا. نظم CP لا تحتاج ما يدعو للقلق حول هذا الموضوع. لأنه بمجرد يأتي قسم في اللعب، فإنها تتوقف مجرد أخذ يكتب. موافق؟ بحيث من السهل جدا ل التعامل مع كونها تتفق عندما كنت لا تقبل أي تحديثات. هذا مع أنظمة CP القيام به. حسنا. 

لذلك دعونا نتحدث قليلا قليلا عن أنماط الوصول. عندما نتحدث عن NoSQL، انها كل شيء عن نمط الوصول. الآن، SQL غير مخصصة، استفسار. انها مخزن العلائقية. ليس لدينا ما يدعو للقلق حول نمط الوصول. أنا أكتب استعلام معقد جدا. وغني ويحصل على البيانات. هذا ما تبدو هذه مثل التطبيع. 

حتى في هذا الهيكل خاص، نحن نبحث في كتالوج المنتجات. لدي أنواع مختلفة من المنتجات. لدي الكتب. لدي ألبومات. لدي أشرطة الفيديو. العلاقة بين المنتجات وأي واحد من هذه الكتب، ألبومات، وأشرطة الفيديو الجداول هي 1: 1. حسنا؟ لقد حصلت على معرف المنتج، والذي يتوافق ID لكتاب، ألبوم، أو شريط فيديو. موافق؟ هذا هو 1: 1 علاقة عبر تلك الجداول. 

الآن، كل ما books-- يكون هو الخصائص الجذرية. ليس هناك أى مشكلة. هذا عظيم. علاقة واحد الى واحد، وأحصل على كل البيانات ولست بحاجة لوصف هذا الكتاب. ألبومات Albums-- لها المسارات. هذا هو ما نسميه واحد للكثيرين. كل ألبوم يمكن أن يكون العديد من المسارات. وذلك لكل مسار على الألبوم، وأنا يمكن أن يكون رقم قياسي آخر في هذا الجدول الطفل. لذلك أنا إنشاء سجل واحد في الجدول ألبومات بلدي. I إنشاء سجلات متعددة في الجدول المسارات. علاقة لاحد عديدة. 

هذه العلاقة هي ما ندعو كثير لكثير. موافق؟ ترى أن الفاعلين يمكن أن يكون في العديد من الأفلام، العديد من أشرطة الفيديو. فما نقوم به هو وضعنا هذا التعيين الجدول بين تلك التي للتو خرائط ID الممثل إلى معرف الفيديو. الآن يمكنني إنشاء استعلام ينضم أشرطة الفيديو من خلال الممثل الفيديو إلى الجهات الفاعلة، ويعطيني قائمة لطيفة جميع الأفلام وجميع الجهات الفاعلة الذين كانوا في هذا الفيلم. 

حسنا. حتى هنا نذهب. واحد الى واحد هو المستوى الأعلى علاقة؛ واحد لكثير، البومات لالمسارات؛ كثير لكثير. تلك هي على مستوى عال ثلاثة العلاقات في أي قاعدة بيانات. إذا كنت تعرف كيفية تلك علاقات العمل معا، ثم تعرف الكثير حول قاعدة البيانات بالفعل. حتى NoSQL يعمل بشكل مختلف قليلا. دعونا نفكر للحظة واحدة ما يبدو أن يذهب للحصول على جميع المنتجات بلدي. 

في متجر العلائقية، I ترغب في الحصول على جميع المنتجات بلدي على قائمة من جميع المنتجات بلدي. كما أن هناك العديد من الاستفسارات. حصلت استعلام لجميع كتبي. حصلت على استفسار من ألبومات بلدي. وحصلت على الاستعلام عن كل ما عندي من أشرطة الفيديو. وحصلت على وضعه كل ذلك معا في قائمة وتخدم إعادته لل تطبيق هذا ما يطلب منها. 

للحصول على كتبي، وأضم صوتي المنتجات وكتب. للحصول على ألبومات بلدي، وأنا حصلت على الانضمام المنتجات، الالبومات، والمسارات. وللحصول على أشرطة الفيديو الخاصة بي، ولدي للانضمام المنتجات للفيديو، انضمام من خلال ممثل فيديو، وجلب الجهات الفاعلة. حتى أن ثلاثة استفسار. استعلامات معقدة جدا ل تجميع مجموعة واحدة نتيجة. 

وهذا أقل من المستوى الأمثل. وهذا هو السبب في أننا عندما نتحدث حول بنية بيانات هذا بنيت لتكون الملحد إلى الوصول pattern-- جيدا هذا أمر عظيم. ويمكنك أن ترى هذا هو حقا لطيفة كيف قمنا تنظيم البيانات. وأنت تعرف لماذا؟ ليس لدي سوى سجل واحد للفاعل. 

هذا بارد. لقد deduplicated كل ما عندي من الجهات الفاعلة، وأنا حافظت الجمعيات بلدي في هذا الجدول رسم الخرائط. ومع ذلك، والحصول على البيانات من يصبح مكلفا. أنا أرسل وحدة المعالجة المركزية في جميع أنحاء النظام الانضمام إلى هذه الهياكل البيانات معا لتكون قادرة على سحب هذا يعود البيانات. 

فكيف يمكنني الحصول على حول ذلك؟ في NoSQL فقد حان التجميع، وليس التطبيع. لذلك نحن نريد أن نقول أننا نريد أن دعم نمط الوصول. إذا كان نمط الوصول إلى التطبيقات، ولست بحاجة للحصول على كل منتجاتي. دعونا نضع كل المنتجات في جدول واحد. إذا وضعت جميع المنتجات في طاولة واحدة، يمكنني فقط تحديد كافة المنتجات من هذا الجدول وأحصل على كل شيء. حسنا كيف أفعل ذلك؟ حسنا في NoSQL لا يوجد هيكل الى طاولة المفاوضات. سنتحدث قليلا عن كيف يعمل هذا في دينامو DB. ولكن لم يكن لديك نفس الصفات ونفس الخصائص في كل صف واحد، في كل واحدة البند، كما تفعل في جدول SQL. وهذا ما يسمح لي القيام به هو الكثير من الأشياء وتعطيني الكثير من المرونة. في هذه الحالة بالذات، وأنا وثائق المنتج الخاص بي. وفي هذا الخصوص مثلا، كل شيء هي وثيقة في الجدول المنتجات. والمنتج للكتاب قد لديك معرف النوع الذي يحدد الكتاب. والتطبيق ستتحول على هذا الرقم. 

في مستوى التطبيق، وانا ذاهب يقول أوه، ما نوع السجل هذا؟ أوه، انها سجل الكتاب. سجلات كتاب لها هذه الخصائص. اسمحوا لي أن إنشاء كائن الكتاب. لذلك أنا ذاهب لملء كائن الحجز لهذا البند. البند التالي يأتي و يقول: ما هو هذا البند؟ حسنا هذا البند هو الألبوم. أوه، أنا حصلت على مختلف كله روتين معالجة لذلك، لأنه ألبوم. ترى ما أعنيه؟ 

وبالتالي فإن تطبيق tier-- I ما عليك سوى اختيار جميع هذه السجلات. أنهم جميعا بدء القادمة. ويمكن أن تكون جميع أنواع مختلفة. وانها منطق التطبيق أن تتحول عبر تلك الأنواع وتقرر كيفية معالجتها. 

مرة أخرى، لذلك نحن الاستفادة المثلى من مخطط لنمط الوصول. نحن نفعل ذلك من قبل انهيار تلك الجداول. نتخذها أساسا هذه الهياكل تطبيع، ونحن بناء الهياكل الهرمية. داخل كل واحد من هذه السجلات أنا ذاهب لرؤية خصائص مجموعة. 

داخل هذه الوثيقة لألبومات، اراه صفائف من المسارات. تلك المسارات become-- الآن حان في الأساس الجدول التابع ذلك أن موجود هنا في هذا الهيكل. حتى تتمكن من القيام بذلك في DynamoDB. يمكنك القيام بذلك في MongoDB. يمكنك القيام بذلك في أي قاعدة بيانات NoSQL. إنشاء هذه الأنواع من هياكل البيانات الهرمية التي تسمح لك استرداد البيانات بسرعة جدا لاني الان ليس من الضروري أن تتفق. عندما كنت إدراج صف في المسارات الجدول، أو صف في الجدول الالبومات، لدي لتتوافق مع هذا المخطط. يجب أن يكون لدي السمة أو الممتلكات التي تم تعريفها على هذا الجدول. كل واحد منهم، عندما أقوم بإدخال هذا الصف. هذا ليس هو الحال في NoSQL. 

أنا يمكن أن يكون مختلفا تماما العقارات في كل وثيقة أنني تضاف إلى المجموعة. آلية ذلك قوية جدا. وانها حقا كيف تحسين النظام. لأنه الآن هذا الاستعلام، بدلا من ذلك للانضمام جميع هذه الجداول وتنفيذ نصف دزينة الاستفسارات لسحب البيانات أحتاج، أنا تنفيذ استعلام واحد. وأنا بالتكرار عبر نتائج مجموعة. أنها تعطيك فكرة من قوة NoSQL. انا ذاهب الى نوع من الذهاب جانبية هنا ونتحدث قليلا عن هذا. وهذا هو أكثر نوع من التسويق أو technology-- تسويق التكنولوجيا نوع من المناقشة. ولكن من المهم أن نفهم لأنه إذا نظرنا إلى أعلى هنا في هذا المخطط، ما نحن نبحث في هو ما نسميه منحنى الضجيج التكنولوجيا. وما يعنيه هذا هو الاشياء الجديدة يأتي دور. الناس يعتقدون انه لشيء رائع. لقد حل جميع مشاكلي. 

هذا يمكن أن يكون نهاية قبل كل شيء، أن يكون الجميع على كل شيء. وتبدأ استخدامه. وكما يقولون، لا تعمل هذه الاشياء. هذا ليس صحيحا. كان الاشياء القديمة أفضل. ويذهبون إلى القيام الامور على ما كانت عليه. ثم في النهاية يذهبون، أنت تعرف لماذا؟ هذه الاشياء ليست سيئة للغاية. أوه، هذا كيف يعمل. وبمجرد معرفة كيف أعمال، والبدء في الحصول على أفضل. 

والطريف عن ذلك يعني أنه نوع من خطوط تصل إلى ما نسميه منحنى تكنولوجيا إقرار. فما يحدث هو لدينا بعض الزناد التكنولوجيا النوع. في حالة قواعد البيانات، انها ضغط البيانات. تحدثنا عن نقاط المياه عالية ضغط البيانات على مدار الساعة. عندما يضرب هذا الضغط بيانات معين نقطة، وهذا هو الزناد التكنولوجيا. 

هو الحصول على مكلفة للغاية. يستغرق وقتا طويلا لمعالجة البيانات. نحن بحاجة إلى شيء أفضل. يمكنك الحصول على المبدعين هناك يركض، في محاولة لمعرفة ما هو الحل. ما هي الفكرة الجديدة؟ 

ما هو القادم أفضل طريقة للقيام بذلك الشيء؟ وأنها تأتي بشيء. والأشخاص الذين يعانون من الألم الحقيقي، الرجال على حافة النزيف، أنها سوف تقفز في كل ذلك، لأنها تحتاج إلى إجابة. الآن ما happens-- حتما و أنه يحدث الآن في NoSQL. أرى في كل وقت. 

ما يحدث حتما هو يبدأ الناس باستخدام أداة جديدة بنفس الطريقة التي تستخدم الأداة القديمة. ويكتشفون ذلك لا يعمل بشكل جيد. لا أستطيع أن أتذكر من أنا التحدث إلى وقت سابق اليوم. لكن هذا مثل، عندما تم اختراع آلات ثقب الصخور، لم يكن الناس تتأرجح أكثر من ذلك رئيس لتحطيم الخرسانة. 

ولكن هذا هو ما يحدث مع NoSQL اليوم. إذا كنت السير في معظم المحلات التجارية، أنها تحاول أن تكون محلات NoSQL. ما يفعلونه هو انهم يستخدمون NoSQL، وانهم تحميله كامل من مخطط العلائقية. لأن هذه هي الطريقة انهم تصميم قواعد البيانات. وهم يتساءلون، لماذا فإنه لا يؤدون بشكل جيد للغاية؟ الصبي، ينتن هذا الشيء. كان لي للحفاظ على كل ما عندي ينضم in-- انها مثل، لا، لا. الحفاظ ينضم؟ لماذا الانضمام البيانات؟ كنت لا تنضم البيانات في NoSQL. يمكنك تجميع ذلك. 

لذلك إذا كنت ترغب في تجنب هذا، وتعلم كيف تعمل هذه الأداة قبل كنت في الواقع البدء في استخدامه. لا تحاول واستخدام الأدوات الجديدة بنفس الطريقة التي تستخدم الأدوات القديمة. وأنت تسير لديك تجربة سيئة. وفي كل مرة واحد هذا ما هو ذلك. عندما نبدأ الخروج هنا، انها لأن الناس فهموا كيفية استخدام الأدوات. 

فعلوا الشيء نفسه عندما اخترعت قواعد البيانات العلائقية، وكانوا استبدال أنظمة الملفات. حاولوا بناء أنظمة الملفات مع قواعد البيانات العلائقية لأن هذا هو ما فهمه الناس. لكن ذلك لم ينجح. لذلك فهم أفضل الممارسات من التكنولوجيا كنت تعمل مع ضخمة. مهم جدا. 

لذلك نحن في طريقنا للوصول الى DynamoDB. DynamoDB هو في AWS المدارة بالكامل منصة NoSQL. ماذا تدار بالكامل يعني؟ فهذا يعني أنك لا تحتاج إلى قلق حقا عن أي شيء. 

جئت في، كنت اقول لنا، وأنا في حاجة الى الجدول. انها تحتاج هذه القدرة من ذلك بكثير. تضغط على الزر، ونحن توفير كل البنية التحتية خلف الكواليس. الآن هذا هو هائل. 

لأنه عندما تتحدث حول توسيع نطاق قاعدة بيانات، مجموعات بيانات NoSQL في الحجم، بيتابايت إدارة، تشغيل الملايين من المعاملات في الثانية الواحدة، هذه الأمور ليست مجموعات صغيرة. نحن نتحدث عن آلاف الحالات. إدارة الآلاف من الحالات، حتى حالات افتراضية، هو الألم الحقيقي في بعقب. أعني، أن نفكر في كل مرة نظام التشغيل التصحيح يخرج أو إصدار جديد من قاعدة البيانات. ماذا يعني هذا لك من الناحية العملية؟ وهذا يعني أنك حصلت على 1200 الملقمات التي تحتاج إلى تحديث. حتى الآن مع التشغيل الآلي، يمكن أن يستغرق وقتا طويلا. يمكن أن يسبب الكثير من الصداع التشغيلية، لأنني قد تضطر الخدمات أسفل. 

كما أقوم بتحديث قواعد البيانات هذه، وأنا قد تفعل نشر الخضراء الزرقاء حيث يمكنني نشر وترقية نصف بلدي العقد، ومن ثم رفع مستوى النصف الآخر. تأخذ هذه أسفل. لذلك إدارة البنية التحتية المقياس هو مؤلم جدا. وAWS اتخاذ هذا الألم للخروج منه. ويمكن أن قواعد بيانات NoSQL أن تكون مؤلمة للغاية بسبب الطريقة التي نطاق واسع. 

توسيع نطاق أفقيا. إذا كنت ترغب في الحصول على أكبر NoSQL قاعدة بيانات، تشتري أكثر من العقد. كل عقدة تشتري هو الصداع التشغيلي آخر. لذلك دعونا شخص آخر القيام بذلك نيابة عنك. AWS تستطيع أن تفعل ذلك. 

نحن نؤيد القيم ثيقة مفتاح. الآن لم نذهب كثيرا إلى على الرسم البياني للآخرين. هناك الكثير من مختلف النكهات من NoSQL. انهم كل نوع من الحصول على munged معا في هذه المرحلة. يمكنك أن تبحث في DynamoDB ونقول نعم، نحن على حد سواء وثيقة وقيمة مفتاح تخزين هذه النقطة. ويمكنك القول الميزات من واحد على الآخر. بالنسبة لي، والكثير من هذا هو حقا ستة واحد نصف دزينة من جهة أخرى. كل واحد من هذه التقنيات هو التكنولوجيا الدقيقة وحل جيد. لن أقول MongoDB هو أفضل أو أسوأ من الأريكة، ثم كاساندرا، ثم دينامو، أو العكس بالعكس. أعني، وهذه هي خيارات فقط. 

انها سريعة وانها تتفق على أي مستوى. لذلك هذا هو واحد من أكبر المكافآت تحصل مع AWS. مع DynamoDB هو القدرة للحصول على رقم واحد منخفض الكمون ميلي ثانية واحدة على أي مستوى. وهذا هدف تصميم النظام. ونحن لدينا عملاء الذين يفعلون الملايين من المعاملات في الثانية الواحدة. 

الآن سأذهب من خلال بعض تلك حالات استخدام في بضع دقائق هنا. وصول control-- المتكاملة لدينا ما نسميه هوية إدارة الوصول، أو IAM. ويتغلغل في النظام، كل الخدمات التي تقدم AWS. DynamoDB ليست استثناء. يمكنك التحكم في الوصول إلى الجداول DynamoDB. في جميع حسابات AWS عن طريق تحديد الأدوار وصول وأذونات في البنية التحتية إدارة الهوية والوصول. 

وانها عنصر أساسي وأساسيا في ما نسميه البرمجة الموجهة بالأحداث. الآن هذا هو نموذج جديد. 

الحضور: كيف يتم معدل حسابك من صحيح ايجابيات مقابل السلبيات كاذبة على نظام مراقبة الدخول الخاص بك؟ RICK هوليهان: ايجابيات صحيح مقابل السلبيات كاذبة؟ الحضور: العودة ما يجب أن تكون العودة؟ بدلا من مرة واحدة في حين أنه لا عودة عندما يجب أن تحقق؟ 

RICK هوليهان: لم أستطع أن أقول لك ذلك. إذا كان هناك أي فشل على الإطلاق على ذلك، أنا لست الشخص أن يسأل هذا السؤال المحدد. ولكن هذا سؤال جيد. وأود أن يكون من الغريب أن تعرف ذلك بنفسي، في الواقع. 

وهكذا مرة أخرى، نموذجا جديدا هي البرمجة الموجهة بالأحداث. هذه هي الفكرة التي يمكنك نشر التطبيقات المعقدة التي يمكن أن تعمل لذلك، على نطاق وعالية جدا جدا دون أي بنية تحتية على الإطلاق. دون أي ثابت البنية التحتية على الإطلاق. وسنتحدث قليلا حول ما يعنيه ذلك ونحن الحصول على لالقليلة القادمة من الرسوم البيانية. 

أول شيء سنقوم به هو أننا سوف نتحدث حول الجداول. أنواع البيانات API لدينامو. وأول شيء عليك لاحظت عند النظر في هذا، إذا كنت على دراية مع أي قاعدة بيانات، قواعد البيانات لديها حقا نوعين من واجهات برمجة التطبيقات ويهمني ان نسميها. أو مجموعتين من API. أن تكون واحدة من تلك API الإداري. 

الأشياء التي تعتني وظائف قاعدة البيانات. تكوين مشغل التخزين، إنشاء وإضافة الجداول. قاعدة بيانات خلق الكتالوجات والحالات. هذه things-- في DynamoDB، كنت لديهم، وقوائم قصيرة قصيرة جدا. 

حتى في قواعد البيانات الأخرى، قد ترى عشرات من أوامر، من الإدارية الأوامر، لتكوين هذه الخيارات الإضافية. في DynamoDB لا تحتاج تلك ل لم يتم تكوين النظام، ونحن نفعل. وبالتالي فإن الشيء الوحيد الذي عليك القيام به هو قل لي ما هو حجم الجدول الذي أحتاجه. حتى تحصل على جدا مجموعة محدودة من الأوامر. 

تحصل على إنشاء جدول تحديث، الجدول، حذف الجدول، ووصف الجدول. تلك هي الأشياء الوحيدة تحتاج لDynamoDB. أنت لا تحتاج إلى تخزين تكوين المحرك. أنا لا داعي للقلق حول النسخ المتماثل. أنا لا داعي للقلق بشأن sharding. 

أنا لا داعي للقلق حول أي من هذه الاشياء. نحن نفعل كل شيء بالنسبة لك. ذلك أن قدرا كبيرا من النفقات العامة وهذا ما رفع قبالة لوحة الخاص بك. ثم لدينا مشغلي CRUD. CRUD شيء ما دعوة في قاعدة البيانات التي ل إنشاء وتحديث، حذف المشغلين. هذه هي مشتركة بك عمليات قاعدة البيانات. أشياء مثل البند البيع، والحصول على البند، التحديث البنود، حذف العناصر، الاستعلام دفعة والمسح الضوئي. إذا كنت ترغب في مسح الجدول بأكمله. سحب كل شيء من على الطاولة. واحدة من أشياء لطيفة عن DynamoDB غير أنه يسمح المسح الضوئي الموازي. لذلك يمكنك أن تدع الواقع لي أن أعرف كم عدد المواضيع التي ترغب في تشغيلها على ان المسح. ويمكننا تشغيل هذه المواضيع. يمكننا أن تدور مسحها من عبر مواضيع متعددة حتى تتمكن من مسح الجدول بأكمله الفضاء بسرعة شديدة جدا في DynamoDB. 

وAPI آخر لدينا هو ما نسميه تيارات API لدينا. نحن لسنا بصدد الحديث جدا الكثير عن هذا الآن. لقد حصلت في وقت لاحق بعض المحتويات على سطح السفينة في حول هذا الموضوع. لكن تيارات حقا running-- كما أنها تفكر في أمر الوقت وسجل تغيير التقسيم. كل ما يحدث على يبين الجدول حتى على تيار. 

كل الكتابة إلى الجدول يظهر على تيار. يمكنك أن تقرأ هذا الدفق، و يمكنك أن تفعل أشياء معها. سوف نتحدث عن ما أنواع الأشياء التي نفعل مع أشياء مثل النسخ المتماثل إنشاء فهارس الثانوية. جميع أنواع حقا باردة الأشياء التي يمكن القيام به مع ذلك. 

أنواع البيانات. في DynamoDB، نحن نؤيد كل من مفتاح أنواع قيمة وثيقة البيانات. على الجانب الأيسر من الشاشة هنا، لدينا أنواع أساسية لدينا. أنواع قيمة المفتاح. هذه هي الجمل، أرقام والثنائيات. 

هكذا فقط ثلاثة أنواع أساسية. ثم هل يمكن أن يكون مجموعات من هؤلاء. واحدة من أشياء لطيفة عن NoSQL هو أنت يمكن أن تحتوي على صفائف من الخصائص. ومع DynamoDB يمكنك يحتوي على المصفوفات من أنواع أساسية كخاصية الجذر. 

وبعد ذلك هناك أنواع المستندات. كم من الناس هم على دراية JSON؟ يا رفاق دراية JSON كثيرا؟ انها في الاساس جافا سكريبت، الكائن، تدوين. انها تسمح لك لالأساس تحديد بنية هرمية. 

يمكنك تخزين وثيقة JSON على DynamoDB باستخدام مكونات مشتركة أو هي اللبنات التي تتوفر في معظم لغات البرمجة. حتى إذا كان لديك جافا، كنت النظر في الخرائط والقوائم. يمكنني إنشاء كائنات هذا المجال الخريطة. خريطة كقيم أساسية المخزنة على الممتلكات. وربما يكون له قوائم القيم داخل تلك الخصائص. يمكنك تخزين هذا المجمع الهيكل الهرمي كما سمة واحدة بند DynamoDB. 

حتى الجداول في DynamoDB، مثل معظم قواعد بيانات NoSQL والجداول لديها العناصر. في MongoDB تفعل نطلق على هذه الوثائق. وسيكون قاعدة الأريكة. أيضا قاعدة بيانات الوثيقة. استدعاء هذه الوثائق. وثائق أو البنود التي لديها سمات. يمكن الصفات موجودة أو غير موجود على هذا البند. في DynamoDB، هناك سمة إلزامية واحد. مثلما هو الحال في قاعدة بيانات علائقية، لديك مفتاح أساسي على الطاولة. 

DynamoDB لديه ما نسميه مفتاح الشباك. يجب أن يكون مفتاح الشباك فريدة من نوعها. حتى عندما كنت تحديد جدول تجزئة، أساسا ما أقوله هو سوف يكون كل بند مفتاح الشباك. ويجب أن يكون كل مفتاح تجزئة فريدة من نوعها. 

يتم تعريف كل عنصر بواسطة هذا المفتاح تجزئة فريدة من نوعها. ويمكن أن يكون هناك واحد فقط. هذا على ما يرام، ولكن في كثير من الأحيان ما يحتاج الناس هو ما يريدونه هو هذه البعثرة المفتاح لتفعل قليلا أكثر من أن تكون مجرد معرف فريد. في كثير من الأحيان نريد أن استخدام هذا المفتاح تجزئة كما رأس دلو مستوى التجميع. والطريقة التي نؤدي بها ذلك هي مضيفا ما نسميه مفتاح النطاق. 

حتى لو كان تجزئة فقط الجدول، ويجب أن تكون هذه فريدة من نوعها. اذا كان جدول تجزئة وطائفة، و مزيج من التجزئة والنطاق يجب أن تكون فريدة من نوعها. حتى التفكير في الامر بهذه الطريقة. إذا كان لدي المنتدى. وكان النموذج يحتوي الموضوعات، فقد وظائف، ولها ردود. 

ولذا فإنني قد يكون تجزئة المفتاح، الذي هو معرف الموضوع. وكنت قد يكون مفتاح المدى، وهو ID استجابة. بهذه الطريقة إذا كنت ترغب في الحصول على كل الردود على موضوع معين، يمكنني فقط الاستعلام التجزئة. ويمكنني أن أقول فقط أعطني كل البنود التي لديها هذه التجزئة. وانا ذاهب للحصول على كل سؤال أو الرد على هذا الموضوع بالذات. هذه المجموعات مستوى أعلى هي مهمة جدا. أنها تدعم الوصول الأساسي نمط التطبيق. عموما، هذا ما نريد أن نفعله. نريد أن table-- كما يمكنك تحميل الجدول، نحن نريد لتنظيم البيانات ضمن الجدول في مثل هذه الطريقة هذا التطبيق يمكن جدا بسرعة استرداد تلك النتائج. وكثير من الأحيان وسيلة لتحقيق ذلك هي للحفاظ على هذه المجموعات ونحن إدراج البيانات. في الأساس، ونحن نشر البيانات في دلو مشرق لانها تأتي في. 

مفاتيح مجموعة تسمح تجزئة me-- مفاتيح يجب أن تكون المساواة. عندما الاستعلام تجزئة، لا بد لي من القول أعطني التجزئة الذي يساوي هذا. عندما الاستعلام مجموعة، I يمكن القول أن تعطيني مجموعة يستخدم أي نوع من مشغل الغنية التي ندعمها. تعطيني كل العناصر لتجزئة. هو على قدم المساواة، أكبر من، أقل من، فإنه بادئ ذي بدء، أنه موجود بين هاتين القيمتين؟ وبالتالي فإن هذه الأنواع من الاستعلامات مجموعة أننا مهتمون دائما في. الآن شيء واحد حول البيانات، عندما نظرتم الوصول إلى البيانات، عندما يمكنك الوصول إلى البيانات، فمن دائما حول التجميع. انها دائما عن السجلات التي ترتبط بذلك. أعطني كل شيء هنا that's-- جميع المعاملات على هذه البطاقة الائتمانية للشهر الماضي. هذا تجميع. 

تقريبا كل ما تفعله في قاعدة البيانات هي نوع من التجميع. ذلك أن تكون قادرة على أن تكون قادرة على تحديد هذه الدلاء وتعطيك هذه مجموعة الصفات لتكون قادرة على الاستعلام عن، تلك الاستفسارات الغنية تدعم عديدة، العديد والعديد من أنماط الوصول إلى التطبيق. 

وبالتالي فإن الشيء الآخر على مفتاح الشباك هل هو يعطينا آلية لتكون قادرة على نشر بيانات حولها. قواعد بيانات NoSQL عمل أفضل عندما كانت البيانات بالتساوي وزعت عبر الكتلة. كم من الناس هم على دراية مع خوارزميات التجزئة؟ عندما أقول تجزئة وhashing-- لأن خوارزمية التجزئة هو وسيلة لتكون قادرة على توليد قيمة عشوائية من أي قيمة معينة. حتى في هذه الحالة بالذات، خوارزمية البعثرة نديرها هي ND 5 القائمة. 

وإذا كان لدي معرف، وهذا هو بلدي مفتاح الشباك، ولدي 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. في MongoDB لديهم هذه المشكلة إذا كنت لا تستخدم مفتاح الشباك. MongoDB يتيح لك خيار من تجزئة قيمة المفتاح. يتعين عليك أن تفعل دائما أنه إذا كنت تستخدم تجزئة تزايد المفتاح في MongoDB، أو عليك أن تكون تسمير كل الكتابة إلى عقدة واحدة، وسوف يكون الحد سرعة الكتابة بشكل سيئ. 

الحضور: هل هذا A9 169 في العشرية؟ 

RICK هوليهان: نعم، انها في مكان ما حول هناك. A9، وأنا لا أعرف. كنت قد لأحصل على ثنائي إلى آلة حاسبة العشرية. ذهني لا يعمل من هذا القبيل. الحضور: فقط واحد سريع التعليقات مونجو الخاصة بك. ذلك هو معرف الكائن الذي يأتي أصلا مع مونجو تفعل ذلك؟ RICK هوليهان: هل تفعل ذلك؟ إذا قمت بتحديد ذلك. مع MongoDB، لديك الخيار. يمكنك specify-- كل وثيقة في MongoDB لا بد أن يكون معرف تسطير. هذا هو قيمة فريدة من نوعها. 

في MongoDB يمكنك تحديد سواء لتجزئة ذلك أم لا. هم فقط تعطيك خيار. إذا كنت تعرف أنه عشوائية، لا مشكلة. لا تحتاج للقيام بذلك. إذا كنت تعرف أنه ليس عشوائي، أن انها تزايد، ثم القيام تجزئة. 

الآن الشيء عن تجزئة، وبمجرد تجزئة وvalue-- وهذا هو لماذا مفاتيح تجزئة دائما استفسار فريدة من نوعها، لأنني قمت بتغيير قيمة، وأنا الآن لا تستطيع أن تفعل استعلام مجموعة. لا أستطيع أن أقول غير هذا بين هذا أو ذاك، لأن قيمة التجزئة لن ليكون معادلا للقيمة الفعلية. حتى عندما كنت التجزئة التي مفتاح، انها المساواة فقط. هذا هو السبب في DynamoDB مفتاح الشباك الاستعلامات دائما المساواة فقط. 

وحتى الآن في مجموعة key-- عند إضافة هذا المفتاح مجموعة، تلك السجلات مفتاح نطاق كل ذلك يأتي في و أنها تحصل المخزنة على نفس القسم. لذلك هم بسرعة وسهولة استرجاع لأن هذا هو تجزئة، هذا هو النطاق. وأنت ترى كل شيء بنفس التجزئة يحصل المخزنة على نفس المساحة التقسيم. يمكنك استخدام هذا المفتاح مجموعة للمساعدة تحديد موقع البيانات الخاصة بك على مقربة من الأم. فما أنا حقا تفعل هنا؟ هذا هو واحد من العديد من العلاقة. العلاقة بين مفتاح الشباك ومفتاح مجموعة واحدة للكثيرين. أنا يمكن أن يكون لها مفاتيح التجزئة متعددة. أنا يمكن أن يكون فقط مجموعة متعددة مفاتيح داخل كل مفتاح الشباك. 

وتعرف تجزئة الأصل، يحدد مجموعة من الأطفال. حتى تستطيع أن ترى هناك التناظرية هنا بين بناء العلائقية ونفس أنواع يبني في NoSQL. الناس يتحدثون عن NoSQL كما nonrelational. انها ليست nonrelational. لديها بيانات دائما العلاقات. تلك العلاقات فقط وعلى غرار مختلف. دعونا نتحدث قليلا قليلا عن المتانة. عند الكتابة إلى DynamoDB، ويكتب دائما ثلاثي تكرارها. وهذا يعني أن لدينا ثلاثة من الألف إلى الياء ل. من الألف إلى الياء هي المناطق التوفر. يمكنك التفكير في التوفر المنطقة كمركز البيانات أو مجموعة من مراكز البيانات. هذه الأمور هي جغرافيا معزولة عن بعضها البعض عبر مناطق خطأ مختلفة، عبر تختلف شبكات الكهرباء والسهول الفيضية. فشل في واحد من الألف إلى الياء ليست الذهاب إلى إنزال آخر. وهي مرتبطة أيضا جنبا إلى جنب مع الألياف الظلام. وهو يدعم واحد الفرعية 1 ميلي ثانية واحدة الكمون بين AZS. حتى تكرار البيانات في الوقت الحقيقي قادرة في AZS متعددة. 

ونشر AZ في كثير من الأحيان متعددة تلبية متطلبات توافر عالية معظم الشركات الكبرى. حتى ينتشر DynamoDB عبر ثلاثة AZS افتراضيا. ونحن في طريقنا فقط لمعرفة الكتابة عندما اثنين من هذه العقد ثلاث أعود ويقول: نعم، حصلت عليه. لماذا هذا؟ لأن على الجانب القراءة نحن فقط ذاهب الى ان نعطيكم البيانات مرة أخرى عندما نحصل عليه من عقدتين. 

إذا أنا تكرار عبر ثلاثة، وأنا أقرأ من اثنين، أنا دائما مضمونة لديك واحد على الأقل تلك يقرأ ليكون معظم النسخة الحالية من البيانات. وهذا ما يجعل DynamoDB متسقة. الآن يمكنك اختيار إيقاف تلك التي تتساوق يقرأ خارج. وفي هذه الحالة انا ذاهب الى القول، سأقرأ فقط من عقدة واحدة. وأنا لا يمكن أن تضمن انها تسير ليكون أحدث البيانات. 

إذا كان الأمر كذلك كتابة قادم في، أنها لم تتكرر حتى الآن، كنت ذاهب للحصول على هذه النسخة. هذا هو لقراءة تتفق في نهاية المطاف. وما الذي هو نصف التكلفة. لذلك هذا هو شيء للتفكير. عندما كنت تقرأ DynamoDB، و كنت تقوم بإعداد قدرة القراءة الخاصة بك وحدة، إذا اخترت في النهاية يقرأ متسقة، انها أرخص كثيرا، انها ما يقرب من نصف التكلفة. 

وذلك يوفر عليك المال. ولكن هذا اختيارك. إذا كنت ترغب في قراءة متناسقة أو لقراءة تتفق في نهاية المطاف. هذا شيء يمكنك ان تختار. 

دعونا نتحدث عن الأرقام القياسية. لذلك ذكرنا أن أعلى مستوى التجميع. لدينا مفاتيح التجزئة، و لدينا مفاتيح النطاق. هذا جيد. وهذا في الجدول الأساسي، I حصلت مفتاح الشباك واحدة، وحصلت على مفتاح مجموعة واحدة. 

ماذا يعني هذا؟ لقد حصلت على سمة واحدة بأنني يمكن تشغيل الاستعلامات الغنية ضد. انها مفتاح النطاق. سمات أخرى على أن item-- يمكنني تصفية على تلك الصفات. ولكن لا أستطيع أن أفعل أشياء مثل، فإنه يبدأ، أو أكبر من. 

كيف يمكنني فعل ذلك؟ I إنشاء فهرس. هناك نوعين من الفهارس في DynamoDB. المؤشر هو حقا رأي آخر من الجدول. والمؤشر الثانوي المحلي. 

أول واحد سوف نتحدث عنه. وتتعايش المرتبات الثانية المحلية حتى على نفس القسم كما يتضح من البيانات. وعلى هذا النحو، فهي على نفس العقدة الفعلية. وهي ما نسميه ثابت. معنى، وأنها سوف نعترف الكتابة مع الجدول. عندما يحين الكتابة في، سنقوم الكتابة من خلال المؤشر. سنقوم إرسال ما يصل إلى الطاولة، وبعد ذلك سوف نعترف. ولهذا ثابت. مرة واحدة وقد تم الكتابة اعترف من الجدول، ما يضمن أن المؤشر الثانوي المحلي سيكون لديهم نفس الرؤية من البيانات. ولكن ما يسمح لك القيام به هو تحديد مفاتيح مجموعة بديلة. 

لديك لاستخدام نفس تجزئة المفتاح مثل الجدول الأساسي، لأنهم في موقع واحد على نفس القسم، وانهم ثابت. ولكن يمكنني إنشاء فهرس مع مفاتيح مجموعة مختلفة. هكذا على سبيل المثال، إذا كان الصانع ان كان جدول أجزاء الخام القادمة. وقطع الخام تأتي في، و انهم تجميعها من قبل الجمعية. وربما هناك التذكير. 

أي جزء الذي أدلى به هذا الصانع بعد هذا التاريخ، ولست بحاجة إلى سحب من خط بلدي. أستطيع أن تدور فهرس التي من شأنها أن أن تبحث، تجميع في تاريخ تصنيع هذا الجزء بعينه. حتى إذا كان مائدتي المستوى الأعلى تجزئته بالفعل من قبل الشركة المصنعة، ربما تم ترتيب ذلك على ID جزئيا، I يمكن إنشاء فهرس خارج هذا الجدول كما تجزئته من قبل الشركة المصنعة و تراوح على تاريخ الصنع. وبهذه الطريقة يمكن أن أقول، أي شيء تم تصنيعها بين هذه التواريخ، ولست بحاجة إلى سحب من على خط المرمى. لذلك هذا هو مؤشر الثانوي المحلي. 

هذه لها تأثير الحد من الفضاء مفتاح الشباك الخاص بك. لأنها تعايش على عقدة التخزين نفسها، أنها تحد من مفتاح الشباك الفضاء الى 10 جيجا بايت. DynamoDB، تحت الجداول، والتقسيم الجدول الخاص بك كل 10 غيغا بايت. عندما كنت وضعت 10 العربات البيانات في، ونحن يذهب [PHH]، ونضيف عقدة أخرى. 

ونحن لن تقسيم LSI عبر أقسام متعددة. سنقوم تقسيم الجدول. لكننا لن تقسيم LSI. بحيث شيء المهم أن نفهم هو اذا كنت تريد ان تفعل جدا، جدا، تجمعات كبيرة للغاية، ثم وأنت تسير أن تكون محدودة الى 10 جيجا بايت على LSIs الخاص بك. 

إذا كان هذا هو الحال، يمكننا استخدام المرتبات الثانية العالمية. المرتبات الثانية هي عالمية حقا جدول آخر. وجدت تماما قبالة ل جانب من الجدول الأساسي. وأنها تسمح لي لإيجاد بنية مختلفة تماما. لذلك أعتقد أنها يتم إدخال البيانات إلى جدولين مختلفة، منظم بطريقتين مختلفتين. 

أنا يمكن تعريف تماما مفتاح الشباك مختلفة. أنا يمكن تعريف تماما مفتاح مجموعة مختلفة. وأستطيع أن تشغيل هذا بشكل مستقل تماما. كما واقع الأمر، لقد المشروطة قدرة قراءة بلدي وكتابة القدرة على بلدي المؤشرات الثانوية العالمية بشكل مستقل تماما من الجدول الأساسي بلدي. إذا كنت تعرف أن مؤشر، وأنا أقول كان مقدار القراءة والكتابة قدرة انها سوف تستخدم. 

وهذا هو منفصل من الجدول الأساسي بلدي. الآن كل من مؤشرات تسمح لنا ل تحديد ليس فقط تجزئة ومجموعة مفاتيح، ولكنها تسمح لنا ل إبراز قيمنا إضافية. حتى لو كنت تريد أن تقرأ من المؤشر، وأريد الحصول على بعض مجموعة من البيانات، ولست بحاجة إلى العودة إلى الرئيسية جدول للحصول على سمات إضافية. أنا يمكن أن المشروع تلك إضافية الصفات في الجدول لدعم نمط الوصول. وأنا أعلم أننا ربما الدخول في بعض حقا، really-- الدخول في الأعشاب هنا على بعض من هذه الاشياء. الآن وصلت إلى الانجراف للخروج من هذا. 

الحضور: (غير مسموع) مفتاح --table يعني ان تجزئة؟ تجزئة الأصلية؟ شرائح متعددة؟ 

RICK هوليهان: نعم. نعم فعلا. مفتاح الجدول الأساس يشير إلى هذا البند. لذلك فإن المؤشر هو مؤشر إلى العناصر الأصلية على الطاولة. الآن يمكنك اختيار لبناء مؤشر الذي يحتوي على مفتاح الجدول فقط، وليس غيرها من الممتلكات. ولماذا قد أفعل ذلك؟ حسنا، ربما لدي عناصر كبيرة جدا. 

أنا حقا بحاجة الى معرفة فقط which-- قد يقول نمط الوصول بلدي، العناصر التي تحتوي على هذا العقار؟ لا تحتاج لإرجاع البند. أنا فقط بحاجة الى معرفة العناصر التي تحتوي عليها. حتى تتمكن من بناء الفهارس التي لا تملك إلا مفتاح الجدول. 

ولكن هذا في المقام الأول ما فهرس في قاعدة البيانات ل. انها لكونه قادرا على بسرعة تحديد الذي يسجل، الصفوف التي، الذي العناصر في الجدول لها الخصائص التي أنا تبحث عنه. 

هيئة التأمين، لذلك كيف تعمل؟ هيئة التأمين هي في الأساس غير متزامن. ويأتي هذا التحديث في الجدول، ثم يتم تحديث الجدول بشكل غير متزامن كل من هيئة التأمين الخاصة بك. هذا هو السبب في هيئة التأمين ل يتفق في نهاية المطاف. 

ومن المهم أن نلاحظ أن عندما كنت بناء نظام خدمات التأمين الحكومية، وفهمت أنك خلق بعدا آخر من aggregation-- الآن دعونا نقول مثال جيد هنا هو الصانع. أعتقد أنني قد تحدثت عن الشركة المصنعة للجهاز الطبي. الشركات المصنعة للأجهزة الطبية لدينا كثير من الأحيان أجزاء متسلسلة. الأجزاء التي تدخل في استبدال مفصل الورك جميع يملك الرقم التسلسلي قليلا عليهما. ويمكن أن يكون لها الملايين و الملايين والمليارات من أجزاء في جميع الأجهزة التي السفينة. كذلك، فإنها تحتاج إلى تجميع تحت أبعاد مختلفة، وجميع أجزاء في التجمع، جميع الأجزاء التي تم إجراؤها على خط معين، كل الأجزاء التي جاءت في من منتج معين في تاريخ معين. وهذه المجموعات أحيانا الحصول على ما يصل إلى المليارات. 

لذلك أنا أعمل مع بعض هؤلاء الرجال الذين يعانون لأنهم خلق هذه المجموعات ginormous في مؤشراتها الثانوية. قد يكون لديهم أجزاء الخام الجدول الذي يأتي التجزئة فقط. كل جزء له رقم تسلسلي فريد من نوعه. يمكنني استخدام الرقم التسلسلي مثل التجزئة. هذا جميل. ينتشر مائدتي البيانات الخام في جميع أنحاء الفضاء الرئيسي. لي [؟ اكتب ؟] [؟ ابتلاع؟] رائع. أنا تأخذ الكثير من البيانات. ثم ما يفعلونه هو أنها تخلق GSI. وأنا أقول، أنت تعرف ما، ولست بحاجة لرؤية جميع أجزاء لهذا المصنع. حسنا، فجأة أنا أخذ مليار الصفوف، والاشياء لهم على عقدة واحدة، لأنه عندما I تجميع باسم ID المصنعة مثل التجزئة، ورقم الجزء باعتبارها مجموعة، ثم كل من المفاجئ أنا وضع مليار الأجزاء إلى ما وقد القى هذا المصنع لي. 

يمكن أن يسبب الكثير من الضغط على GSI، مرة أخرى، لأنني يدق عقدة واحدة. أنا أضع كل هذه إدراج في عقدة واحدة. وهذا حقيقي حالة استخدام إشكالية. الآن، وأنا حصلت على التصميم الجيد نمط لكيفية تجنب ذلك. وهذا هو واحد من المشاكل أن أعمل دائما مع. ولكن ما يحدث، هو GSI قد لا تملك ما يكفي من القدرة الكتابة لتكون قادرة على دفع كل تلك الصفوف في عقدة واحدة. وماذا يحدث بعد ذلك هو الابتدائية، الجدول العميل، سيتم مخنوق الجدول الأساسي لأن GSI لا يمكن الاستمرار. لذلك فإن معدل إدراج بلدي تقع على الجدول الأساسي كما يحاول بلدي GSI لمواكبة. 

كل الحق، لذلك لGSI، في LSI، أي واحد يجب استخدامها؟ في LSI تتسق. وGSI تتفق في نهاية المطاف. إذا كان هذا هو موافق، أوصي باستخدام GSI، وأنهم أكثر مرونة. في LSI يمكن أن تكون على غرار باعتباره GSI. وإذا كان حجم البيانات في مفاتيح التجزئة في مجموعتك يتجاوز 10 غيغابايت، ثم كنت تريد الذهاب الى استخدام ذلك GSI لأنه مجرد الحد الثابت. 

كل الحق، لذلك التحجيم. الإنتاجية في دينامو DB، كنت توفير العلبة (غير مسموع) الإنتاجية إلى جدول. لدينا عملاء لها المشروطة 60 billion-- يفعلون 60 مليار الطلبات، بانتظام تشغيل في أكثر من مليون طلب في الثانية على جداول أعمالنا. هناك حقا أي الحد النظري لمدى ومدى سرعة الجدول يمكن تشغيلها في دينامو DB. هناك بعض ينة قيود على حسابك أن نضع في هناك حتى أن لا تذهب مجنون. إذا كنت تريد أكثر من هذا، ليست مشكلة. جئت تخبرنا. ونحن سوف يحضر الاتصال الهاتفي. 

كل حساب يقتصر على بعض مستوى في كل خدمة، قبالة الخفافيش وبالتالي فإن الناس لا يذهبون مجنون الحصول على أنفسهم في ورطة. لا يوجد حد في حجم. يمكنك وضع أي عدد من البنود المدرجة على جدول. حجم عنصر هو تقتصر على 400 كيلو بايت لكل منهما، من شأنه أن يكون البند لا السمات. وبالتالي فإن مجموع كل الصفات يقتصر على 400 كيلو بايت. ثم مرة أخرى، لدينا أن تذكر قضية LSI مع الحد 10 غيغا بايت في تجزئة. الحضور: عدد صغير، وأنا في عداد المفقودين ما كنت تقول لي، أن is-- الحضور: أوه، 400 كيلوبايت هو الحد الأقصى لحجم لكل بند. لذلك عنصر لديه كل الصفات. حتى 400 ك هو الحجم الكلي من هذا البند، 400 كيلو بايت. لذلك من كل الصفات جنبا إلى جنب، وجميع البيانات وهذا في كل تلك الصفات، طوى في الحجم الإجمالي، حاليا اليوم الحد البند هو 400 ك. لذلك التوسع مرة أخرى، حقق من خلال التقسيم. يتم توفير الإنتاجية مستوى الجدول. وهناك حقا اثنين من المقابض. لقد قرأنا قدرة والكتابة القدرات. 

بحيث يتم تعديل هذه بشكل مستقل عن بعضها البعض. قياس حدة التنسيق الإقليمي بدقة من يتفق يقرأ. حسنا، إذا كنت تقول أريد 1000 وحدة تنسيق تلك تتسق تماما، تلك هي يقرأ متسقة. إذا أنت تقول أريد نهائي يتفق يقرأ، يمكنك توفير 1000 وحدة التنسيق الإقليمي، وأنت تسير للحصول على 2000 في نهاية المطاف يقرأ متسقة. ونصف السعر لتلك في نهاية المطاف تتمثل في ما يلي. 

مرة أخرى، بعد تعديلها بشكل مستقل عن بعضها البعض. ولديهم throughput-- إذا كنت تستهلك 100٪ من RCU الخاص بك، كنت لن تؤثر على توافر حقوقك. لذلك هم تماما مستقلة عن بعضها البعض. كل الحق، لذلك واحدة من الأشياء التي ذكرت لفترة وجيزة واختناق. اختناق سيئة. اختناق يشير سيئة لا SQL. هناك أشياء يمكننا القيام به للمساعدة يمكنك تخفيف اختناق أنك تعاني منها. ولكن أفضل حل لهذا دعونا نلقي نظرة على ما تفعلونه، ل هناك مضاد للنمط في اللعب هنا. 

هذه الأشياء، أشياء مثل غير موحدة أعباء العمل، المفاتيح الساخنة، وأقسام الساخنة. أنا ضرب مساحة رئيسي معين من الصعب جدا لسبب معين. لماذا أفعل هذا؟ دعونا هذا الرقم. أنا خلط البيانات الخاصة بي الساخنة مع البيانات الباردة. أنا السماح لي الحصول على الجداول ضخمة، ولكن هناك حقا فقط بعض فرعية من البيانات هذا مثير للاهتمام حقا بالنسبة لي. حتى لبيانات السجل، على سبيل المثال، الكثير من الزبائن، وأنها تحصل على بيانات تسجيل كل يوم. أنها حصلت على كمية هائلة من البيانات السجل. 

إذا كنت مجرد إلقاء كل ما سجل البيانات في جدول واحد كبير، مع مرور الوقت يسير على هذا الجدول للحصول ضخمة. ولكن أنا حقا مهتم فقط في 24 ساعة الماضية، والأيام السبعة الأخيرة، آخر 30 يوما. مهما كانت نافذة من الوقت أن أنا مهتم في البحث لهذا الحدث الذي يزعجني، أو الحدث الذي هو المثير للاهتمام بالنسبة لي، هذا هو النافذة الوحيدة الوقت الذي أحتاج. إذن لماذا أنا وضع 10 سنوات قيمة بيانات السجل في الجدول؟ ما الذي يسبب هو الجدول جزء. 

فإنه يحصل ضخمة. ويبدأ يتباعد عبر الآلاف من العقد. ومنذ قدرتكم غير منخفضة جدا، وكنت معدل فعلا الحد على كل واحدة من تلك العقد الفردية. لذلك دعونا نبدأ النظر في كيفية هل نحن لفة هذا الجدول من جديد. كيف ندير هذه البيانات قليلا أفضل لتجنب هذه المشاكل. وماذا تشبه؟ هذا هو ما يشبه. هذا ما يبدو سيئا NoSQL مثل. 

حصلت على مفتاح ساخن هنا. اذا نظرتم على الجانب هنا، هذه هي كل ما عندي من أقسام. حصلت على 16 حواجز يصل هنا على هذا قاعدة بيانات معينة. ونحن نفعل ذلك في كل وقت. I تشغيل هذا للعملاء في جميع الوقت. انه دعا خريطة الحرارة. خريطة الحرارة يحكي لي كيف كنت الوصول إلى الفضاء الرئيسي الخاص بك. وهذا ما هو قول لي هو أن هناك تجزئة واحدة بعينها أن هذا الرجل يحب ل ضخم، لانه ضرب حقا، من الصعب حقا. 

وبالتالي فإن اللون الأزرق هو لطيف. نود الأزرق. نحن لا نحب الأحمر. الأحمر حيث الضغط يحصل على ما يصل إلى 100٪. 100٪، والآن كنت على وشك أن مخنوق. لذلك كلما كنت ترى أي خطوط حمراء مثل this-- وانها ليست مجرد دينامو DB-- كل قاعدة بيانات NoSQL لديها هذه المشكلة. هناك معاداة الأنماط التي يمكن تدفع هذه الأنواع من الظروف. ما أقوم به هو أن أعمل مع العملاء للتخفيف من هذه الشروط. 

وماذا تشبه؟ وهذا هو الحصول على أكثر من الإنتاجية دينامو DB، ولكن الأمر يزداد حقا أكثر من NoSQL. لا يقتصر هذا على دينامو. هذا هو definitely-- I كان يعمل في مونجو. أنا على دراية العديد من المنصات NoSQL. كل واحد لديه هذه الأنواع من المشاكل الرئيسية الساخنة. للحصول على أقصى استفادة من أي NoSQL قاعدة البيانات، على وجه التحديد دينامو DB، تريد إنشاء الجداول حيث العنصر مفتاح الشباك لديه عدد كبير من قيم واضحة، على درجة عالية من أصل. لأن ذلك يعني أنا أكتب إلى الكثير من الدلاء مختلفة. 

لمزيد من الدلاء أنا الكتابة ل، والأرجح أنا لنشر هذا الحمل الكتابة أو قراءة تحميل في أنحاء عدة عقد، والأرجح أنا لديك إنتاجية عالية على الطاولة. ثم أريد أن تكون القيم طلب بالتساوي إلى حد ما مع مرور الوقت وكما موحد بشكل عشوائي وقت ممكن. حسنا، هذا النوع من المثير للاهتمام، لأنني لا أستطيع حقا السيطرة عندما يأتي المستخدمين. لذلك يكفي أن أقول، إذا كان لنا نشر الامور عبر الفضاء الرئيسي، نحن على الأرجح سوف تكون في وضع أفضل. 

هناك بعض كمية التسليم في الوقت المحدد أنك لن لتكون قادرة السيطرة. ولكن هذه هي الحقيقة بعدين التي لدينا، الفضاء، والوصول بالتساوي انتشار، والوقت، طلبات وصوله إلى متباعدة بشكل متساو في الوقت المناسب. وإذا كانت تلك اثنين يتم استيفاء الشروط، ثم ان ما يدور حوله الذهاب لتبدو وكأنها. هذا هو أجمل من ذلك بكثير. نحن سعداء حقا هنا. لقد حصلت على نمط الوصول حتى للغاية. نعم، ربما كنت الحصول على الضغط قليلا بين الحين والآخر، ولكن لا شيء حقا اسعة جدا. حتى إنه لأمر مدهش كم مرة، عندما أعمل مع العملاء، هذا الرسم البياني الأول مع حمراء كبيرة شريط وكل ما القبيح الأصفر انها في كل مكان، ونحن الحصول على القيام به مع ممارسة بعد بضعة أشهر إعادة الهندسة المعمارية، أنها تقوم بتشغيل نفسها بالضبط عبء العمل في تحميل نفسه بالضبط. وهذا هو ما تبدو وكأنها الآن. ذلك ما تحصل عليه مع NoSQL هو مخطط البيانات التي على الاطلاق تعادل لنمط الوصول. 

ويمكنك تحسين هذا المخطط البيانات لدعم هذا النمط الوصول. إذا لم تقم بذلك، ثم وأنت تسير لمعرفة تلك الأنواع من المشاكل مع تلك المفاتيح الساخنة. 

الحضور: حسنا، لا محالة بعض الأماكن سوف تكون أكثر سخونة من غيرها. 

RICK هوليهان: دائما. دائما. نعم، أعني هناك دائما a-- ومرة ​​أخرى، هناك بعض أنماط التصميم سنقوم من خلال الحصول على التي سوف نتحدث عن كيفية التعامل مع هذه المجموعات الضخمة. يعني أنا حصلت أن يكون لهم، كيف نتعامل معها؟ حصلت على الحالة استخدام جيدة أننا سوف نتحدث عن لذلك. 

كل الحق، لذلك دعونا الحديث عن بعض العملاء الآن. هؤلاء هم AdRoll. أنا لا أعرف ما إذا كنت دراية AdRoll. وربما كنت أراهم كثيرا على المتصفح. انهم إعلان إعادة الاستهداف، وانهم أكبر شركة إعلانية إعادة استهداف هناك. هم عادة بشكل منتظم على 60 مليار المعاملات في اليوم الواحد. انهم يفعلون أكثر من مليون المعاملات في الثانية الواحدة. لقد حصلت على جدول بسيط جدا هيكل، جدول ازدحاما. انها في الاساس مجرد مفتاح الشباك هو الكعكة، مجموعة هو الديموغرافية فئة، ومن ثم السمة الثالثة هي النتيجة. 

لذلك نحن جميعا لدينا ملفات تعريف الارتباط في المتصفح لدينا من هؤلاء الرجال. وعندما تذهب إلى التاجر المشاركة، أنها في الأساس يسجل لك عبر فئات سكانية. عندما تذهب إلى موقع على شبكة الانترنت و كنت أقول أريد أن أرى هذا ad-- أو أساسا لا أقول هكذا- يضرب ولكن عندما تذهب إلى الموقع يقولون لك نريد أن نرى هذا الإعلان. ويذهبون حصول على هذا الإعلان من AdRoll. AdRoll يبدو لكم على الجدول بهم. وجدوا الكوكيز. المعلنين قول منهم، أريد شخص من هو في منتصف العمر، رجل يبلغ من العمر 40 عاما، في الرياضة. وهم يسجل لك في تلك التركيبة السكانية وقرروا أم لا هذا إعلان جيد بالنسبة لك. 

الآن لديهم جيش تحرير السودان مع مقدمي إعلاناتها لتوفير الفرعية 10 ميلي ثانية واحدة ردا على كل طلب واحد. حتى أنهم يستخدمون دينامو DB لهذا الغرض. انهم ضرب لنا مليون طلب في الثانية الواحدة. انهم قادرين على القيام كل ما لديهم عمليات البحث، فرز كل تلك البيانات، والحصول على هذا الرابط إضافة إلى أن المعلن في أقل من 10 ميلي ثانية. انها حقا ظاهرة جميلة تنفيذ التي لديهم. 

هؤلاء الرجال actually-- هم هؤلاء الرجال. لست متأكدا ما اذا كان هؤلاء الرجال. قد يكون هؤلاء الرجال. وقال في الأساس us-- لا، أنا لا أعتقد أنه كان منهم. وأعتقد أنه كان شخص آخر. كنت أعمل مع العملاء التي قال لي أن الآن أنهم أبلوا ذهبت إلى دينامو DB، وانهم إنفاق المزيد من المال على وجبات خفيفة ل فريق تنميتها كل شهر مما تنفق على قاعدة البيانات الخاصة بهم. لذلك سوف أعطيكم فكرة وفورات في التكاليف التي يمكنك الحصول عليها في دينامو DB ضخمة. كل الحق، dropcam من شركة أخرى. هذه الرجل هو نوع of-- إذا كنت تعتقد من إنترنت الأشياء، dropcam هو في الأساس الفيديو أمن الإنترنت. كنت وضعت الكاميرا هناك. الكاميرا لديه كشف الحركة. يأتي شخص ما على طول، يطلق نقطة جديلة. كاميرا يبدأ تسجيل لفترة من الوقت حتى فإنه لا يكشف عن أي حركة بعد الآن. يضع هذا الفيديو حتى على شبكة الانترنت. 

كان Dropcam الشركة التي هي تحولت أساسا إلى دينامو DB لأنها كانت تعاني آلام النمو الهائلة. وما قالوه لنا، بيتابايت فجأة من البيانات. لم يكن لديهم فكرة خدمتهم سيكون ناجحا جدا. المزيد من الفيديو الواردة من يوتيوب ما هؤلاء الرجال تزداد. التي يستخدمونها DynamoDB لتتبع جميع الفوقية على جميع النقاط الرئيسية الفيديو الخاصة بهم. 

بحيث يصبح لديهم دلاء S3 أنها تدفع جميع التحف الثنائية إلى. ثم لديهم سجلات دينامو DB أن يشير الناس إلى هذه الكائنات S3 الثلاثة. عندما تحتاج إلى إلقاء نظرة على شريط فيديو، تبدو يصل الرقم القياسي في دينامو DB. النقر فوق الارتباط. انهم هدم الفيديو من S3. ولهذا النوع من ما يبدو هذا مثل. وهذا هو مباشرة من فريقهم. 

يقلل دينامو DB بهم التسليم في الوقت المحدد للأحداث الفيديو من خمسة إلى 10 ثانية. في مخزن في العلاقة القديمة، كانوا لدينا للذهاب وتنفيذ استعلامات معقدة متعددة لشخصية من الذي أشرطة الفيديو لسحب أسفل، إلى أقل من 50 ميلي ثانية. حتى إنه لأمر مدهش، مدهش كم الأداء يمكنك الحصول على عندما كنت أمثل و يمكنك توليف قاعدة البيانات الأساسية لدعم نمط الوصول. Halfbrick، هؤلاء الرجال، ما هو عليه، الفاكهة النينجا اعتقد هو الشيء بهم. أن كل يعمل على دينامو DB. وهؤلاء الرجال، هم عظيم فريق التطوير، التطور الكبير متجر. 

ليس فريقا التقاط جيد. لم يكن لديهم الكثير الموارد العملية. كانوا يكافحون في محاولة للحفاظ على البنية التحتية للتطبيقات امرهم وقيد التشغيل. جاءوا إلينا. نظروا في ذلك دينامو DB. فقالوا: هذا بالنسبة لنا. بنوا بكامل إطار تطبيق على ذلك. بعض التعليقات لطيف هنا من الفريق على قدرتهم لنركز الآن على بناء لعبة وليس الحاجة إلى الحفاظ على البنية التحتية، التي أصبح وجود كمية هائلة من النفقات العامة لفريقهم. لذلك هذا هو شيء هكذا- يضرب لل الاستفادة التي تحصل عليها من دينامو DB. 

كل الحق، والدخول في نمذجة البيانات هنا. وتحدثنا قليلا عن هذا 1-1، واحدة للكثيرين، والكثيرون العديد من العلاقات النوع. وكيف يمكن الحفاظ على تلك في دينامو. في دينامو DB نستخدمها الفهارس، بصفة عامة، لتدوير البيانات من نكهة واحدة إلى أخرى. مفاتيح التجزئة، مفاتيح المدى، والفهارس. 

في هذا الخصوص سبيل المثال، حيث أن معظم الدول لديك شرط الترخيص التي رخصة قيادة واحدة فقط لكل شخص. لا يمكنك الذهاب للحصول على اثنين السائق التراخيص في ولاية بوسطن. لا أستطيع أن أفعل ذلك في ولاية تكساس. هذا النوع من ما هو عليه. وذلك في DMV، لدينا عمليات البحث، ونحن تريد البحث عن رخصة القيادة من رقم الضمان الاجتماعي. أريد للبحث عن تفاصيل المستخدم عن طريق رقم رخصة القيادة. 

لذلك قد يكون لدينا جدول للمستخدم أن لديه مفتاح الشباك على الرقم التسلسلي، أو رقم الضمان الاجتماعي، و سمات مختلفة محددة بشأن هذا البند. الآن على هذا الجدول I يمكن تعريف GSI أن تقلب أن حوالي تقول أريد مفتاح تجزئة على ترخيص ثم جميع البنود الأخرى. الآن إذا كنت تريد الاستعلام والعثور على رقم الرخصة لأي اجتماعية معينة رقم الضمان، لا يسعني الاستعلام عن الجدول الرئيسي. 

إذا كنت تريد الاستعلام وأريد للحصول على الضمان الاجتماعي عدد أو غيرها من الصفات التي ل رقم الرخصة، ويمكنني أن الاستعلام GSI. هذا النموذج هو أن واحدة لعلاقة واحدة. مجرد GSI بسيط جدا، الوجه تلك الأشياء حولها. الآن، والحديث عن واحدة للكثيرين. واحد لكثير هو في الأساس لديك مفتاح مجموعة التجزئة. حيث نحصل على الكثير مع هذا استخدام القضية هي رصد البيانات. ويأتي رصد البيانات في العادية الفاصل الزمني، مثل إنترنت الأشياء. نحن دائما الحصول على كل هذه سجلات القادمة في كل وقت. 

وأريد أن أجد كل القراءات بين فترة زمنية معينة. انها الاستعلام شائع جدا في بنية تحتية للمتابعة. طريقة الذهاب من ذلك هو العثور على هيكل جدول بسيط، طاولة واحدة. لقد حصلت على جدول قياسات الجهاز مع مفتاح الشباك على معرف الجهاز. ولدي مفتاح مجموعة على الطابع الزمني، أو في هذه الحالة، الملحمة. والتي تتيح لي تنفيذ مجمع استعلامات مقابل هذا المفتاح مجموعة وتعود تلك السجلات التي هي بالنسبة إلى نتيجة تعيين هذا أنا أبحث عن. وذلك بالطريقة التي احدة إلى العديد من علاقة في الجدول الأساسي باستخدام مفتاح الشباك، هيكل أساسي النطاق. 

ولهذا النوع من المدمج في الجدول في دينامو DB. عندما أحدد تجزئة ومجموعة تي الجدول، وأنا تعريف واحد لعلاقة طويلة. إنها العلاقة بين الوالدين والطفل. 

دعونا نتحدث عن كثير لكثير من العلاقات. وعلى سبيل المثال هذا بعينه، مرة أخرى، نحن في طريقنا للاستخدام في GSI. ودعونا نتحدث عن الألعاب السيناريو حيث لدي مستخدم معين. أريد أن معرفة كل الألعاب التي انه مسجل لأو اللعب في. وعن لعبة معينة، I تريد أن تجد جميع المستخدمين. فكيف أفعل ذلك؟ بلدي ألعاب الطاولة المستخدم، وانا ذاهب لديك مفتاح تجزئة هوية المستخدم ومفتاح مجموعة من اللعبة. 

لذلك يمكن للمستخدم أن يكون ألعاب متعددة. انها واحدة إلى العلاقة بين العديد من المستخدم والمباريات التي يلعبها. ثم على GSI، أنا الوجه الذي حولها. أنا تجزئة على اللعبة و سوف تتراوح على المستخدم. لذلك إذا كنت تريد أن تحصل على كل لعبة للمستخدم يلعبون في، سوف الاستعلام عن الجدول الرئيسي. إذا أريد لجميع المستخدمين الحصول على التي تلعب لعبة معينة، I الاستعلام GSI. لذلك ترى كيف نفعل ذلك؟ يمكنك بناء هذه GSI لدعم حالة الاستخدام، والتطبيق، وصول نمط، التطبيق. 

إذا كنت بحاجة إلى الاستعلام عن هذا البعد، واسمحوا لي إنشاء فهرس على هذا البعد. إذا كنت لا، لا يهمني. وتبعا للحالة استخدام، I قد تحتاج مؤشر أو أنا قد لا. اذا كان واحد بسيط للكثيرين، الجدول الأساسي على ما يرام. إذا كنت بحاجة للقيام بهذه الكثير ل العديد من وأو أحتاج لفعل واحد لأحد، ثم ربما كنت بحاجة لثاني المؤشر. لذلك كل هذا يتوقف على ما أحاول القيام به وما أحاول الحصول على إنجازه. 

ربما أنا لن تنفق جدا الكثير من الوقت في الحديث عن الوثائق. هذا يحصل قليلا، على الأرجح، أعمق مما كنا في حاجة للذهاب إلى. دعونا نتحدث قليلا تعبير استعلام حول الغني. حتى في دينامو DB لدينا القدرة على خلق ما نسميه تعبيرات الإسقاط. تعبيرات الإسقاط ببساطة اختيار الحقول أو القيم الذي تريد عرضه. OK، لذلك أنا بالاختيار. I جعل استعلام ضد دينامو DB. وأنا أقول، أنت تعرف ما، وتظهر لي سوى خمس استعراض نجوم لهذا منتج معين. بحيث كل ما تريد أن ترى. أنا لا أريد أن أرى كل سمات أخرى من الصف، أنا فقط أريد أن أرى هذا. انها مجرد مثل في SQL عند يقول اختر نجم أو من الجدول، تحصل على كل شيء. عندما أقول اسم حدد من الجدول، وأنا فقط الحصول على سمة واحدة. انها نفس النوع من الشيء في دينامو DB أو قواعد بيانات أخرى NoSQL. مرشح تعابير تسمح لي قطع أساسا نتيجة المنصوص عليها. لذلك أنا جعل استعلام. الاستعلام قد يعود مع 500 البنود. ولكن أريد فقط أن البنود لها سمة أن يقول هذا. OK، لذلك دعونا تصفية تلك البنود التي لا تطابق هذا الاستعلام معين. لذلك لدينا تعبيرات التصفية. 

مرشح تعبيرات يمكن يمكن تشغيلها على أي سمة. انهم لا يحبون الاستفسارات النطاق. رفع الاستعلامات أكثر انتقائية. مرشح الاستفسارات تتطلب مني ان اذهب الحصول على نتائج مجموعة كامل ثم انتقاء البيانات لا أريد. لماذا هو مهم؟ لأنني قرأت كل شيء. في استعلام، وانا ذاهب لقراءة و انها سوف تكون عملاقا حول البيانات. ثم انا ذاهب الى انتقاء ما أحتاج. وإذا أنا نحت فقط خارج زوجين من الصفوف، ثم هذا هو موافق. انها ليست غير فعالة جدا. 

ولكن إذا أنا أقرأ كومة كاملة من البيانات، فقط لانتقاء عنصر واحد، ثم انا ذاهب ليكون أفضل قبالة باستخدام استعلام مجموعة، لأنه أكثر انتقائية بكثير. انها سوف نجني الكثير من المال، لأنني دفع ثمن ذلك القراءة. حيث النتائج التي يعود عبور الأسلاك التي قد تكون أصغر، ولكن أنا دفع للقراءة. حتى نفهم كيف كنت الحصول على البيانات. هذا أمر مهم جدا في دينامو DB. 

التعبيرات الشرطية، وهذا هو ما يمكن أن نسميه تأمين متفائل. التحديث في حالة وجود، أو إذا هذه القيمة ما يعادل ما أحدده. وإذا كان لدي الوقت الطوابع على سجل، وأنا قد قراءة البيانات. وأود أن تغيير تلك البيانات. قد أذهب الكتابة التي العودة البيانات إلى قاعدة البيانات. إذا كان شخص ما قد تغير السجل، الطابع الزمني قد تغيرت. وأن طريقي مشروطة التحديث يمكن أن يقول التحديث إذا كان الطابع الزمني يساوي هذا. أو التحديث ستفشل لأن أحدا تحديث السجل في هذه الأثناء. 

هذا ما نسميه تأمين متفائل. وهذا يعني أن شخصا ما يمكن أن تأتي في وتغييره، وانا ذاهب الى الكشف عن ذلك عندما أعود إلى الكتابة. وبعد ذلك يمكن قراءة الواقع أن بيانات ويقول، يا، وقال انه يتغير هذا. ولست بحاجة لتفسير ذلك. ويمكنني تغيير البيانات في بلدي تسجيل وتطبيق تحديث آخر. حتى تتمكن من التقاط تلك تدريجية التحديثات التي تحدث بين وقت أن تقرأ البيانات و مرة كنت قد كتابة البيانات. 

الحضور: والتصفية التعبير يعني في الواقع لا في عدد أو not-- 

[فاصلة VOICES] RICK هوليهان: أنا لن تحصل على الكثير في هذا. هذا هو الكلمة المحجوزة. وجهة نظر جنيه هي محفوظة الكلمة في دينامو DB. كل قاعدة البيانات لديها قناعاتها محفوظة أسماء المجموعات التي لا يمكن استخدامها. دينامو DB، إذا قمت بتحديد الجنيه أمام هذا، يمكنك تحديد تلك الأسماء حتى أعلاه. هذه هي قيمة المشار إليه. انها ربما لا يكون أفضل الجملة ل يكون هناك لهذه المناقشة، لأنه يحصل في بعض real-- كنت قد نتحدث أكثر حول ذلك على مستوى أعمق. 

ولكن يكفي القول، وهذا يمكن يكون الاستعلام مسح حيث views-- ولا وجهات النظر الجنيه أكبر من 10. هو قيمة عددية، نعم. إذا كنت تريد، يمكننا أن نتحدث عن أنه بعد المناقشة. كل الحق، لذلك نحن نخوض بعض السيناريوهات في أفضل الممارسات أين نحن ذاهبون للحديث حول بعض تطبيقات هنا. ما هي حالات الاستخدام لدينامو DB. ما هي تصميم أنماط في دينامو DB. 

وأول واحد ونحن في طريقنا ل الحديث عنه هو إنترنت الأشياء. حتى نحصل على الكثير of-- أعتقد، ما هو it-- أكثر من 50٪ حركة المرور على الإنترنت في هذه الأيام يتم إنشاؤها بالفعل من قبل الأجهزة، العمليات المؤتمتة، وليس من قبل البشر. أعني هذا الشيء هذا الشيء الذي كنت تحملها في جيبك، كمية البيانات أن هذا الشيء هو إرسال الواقع حول بدونك مع العلم أنه المدهشة. موقع، معلوماتك حول مدى السرعة التي تسير. كيف تعتقد يعمل خرائط جوجل عندما اقول لكم ما هو المرور. ذلك لأن هناك الملايين و الملايين من الناس حول القيادة مع الهواتف التي ترسل البيانات في جميع أنحاء المكان طوال الوقت. حتى واحد من الأشياء حول هذا النوع من البيانات التي تأتي في والبيانات ورصد، تسجيل البيانات، بيانات السلاسل الزمنية، هو انها عادة مثيرة للاهتمام فقط لبعض الوقت. بعد ذلك الوقت، انها ليس للاهتمام بذلك. لذلك تحدثنا عنها، لا تدع هذه الجداول تنمو من دون حدود. والفكرة هنا هي أنه ربما أنا عندي 24 ساعات قيمة للأحداث في مائدتي الساخن. وهذا الجدول الساخن سيكون المشروطة بمعدل مرتفع جدا، لأنه أخذ الكثير من البيانات. انه أخذ الكثير من البيانات في وأنا أقرأ كثيرا. لقد حصلت على الكثير من العمليات استعلامات تشغيلها ضد تلك البيانات. 

بعد 24 ساعة، مهلا، ل تعرف ماذا، لا يهمني. ولذلك ربما يكون كل منتصف الليل وأنا لفة جدول سفري إلى جدول جديد وأنا إلغاء توفير هذا الجدول. وسآخذ وحدة التنسيق الإقليمي ل في وقت لاحق أسفل WCU لأن 24 ساعات أنا لا تشغل أكبر عدد ممكن استعلامات مقابل تلك البيانات. لذلك أنا ذاهب لتوفير المال. وربما بعد 30 أيام وأنا لا تحتاج حتى أن نهتم كل شيء. أنا يمكن أن تتخذ في WCU على طول الطريق إلى واحد، لأنك تعرف ما، انها لن الحصول على الكتابة عليها. البيانات هو 30 يوما. فإنه لم يتغير. 

وانها تقريبا لم يذهب للحصول على القراءة، لذلك دعونا نلقي مجرد أن حدة التنسيق الإقليمي وصولا الى 10. وأنا إنقاذ طن من المال على هذه البيانات، وتدفع فقط للبيانات بلدي الساخنة. لذلك هذا هو الشيء المهم أن ننظر في حين تنظر في سلسلة زمنية البيانات القادمة من حيث الحجم. هذه هي الاستراتيجيات. الآن، ويمكنني أن مجرد السماح لها يذهب الجميع إلى طاولة واحدة ومجرد السماح هذا الجدول تنمو. في نهاية المطاف، أنا ذاهب ل رؤية مشكلات في الأداء. انا ذاهب الى أن تبدأ لأرشفة بعض من تلك البيانات من على الطاولة، ليس ما. 

دعونا أفضل بكثير تصميم التطبيق الخاص بك بحيث يمكنك تشغيل هذا الطريق الحق. حتى انها مجرد التلقائي في رمز التطبيق. في منتصف الليل كل ليلة أنها تتحرك الطاولة. ربما ما احتاج اليه هو انزلاق نافذة 24 ساعة من البيانات. ثم على أساس منتظم أنا داعيا البيانات من على الطاولة. أنا تقليم ذلك مع وظيفة كرون وأنا وضعه على هذه الجداول الأخرى، كل ما تحتاجه. إذا كان الأمر كذلك يعمل على التمديد، وهذا عظيم. إن لم يكن، وتقليم ذلك. ولكن دعونا نحافظ على تلك البيانات الساخن بعيدا عن البيانات الباردة الخاص بك. وأنها سوف توفر لك الكثير من المال و جعل الجداول الخاصة بك أكثر الأداء. ذلك الشيء القادم سنتحدث حول والتسويقي. كتالوج هو حالة استخدام شائعة جدا. هذا هو في الواقع نمط شائع جدا أننا سنرى في مجموعة متنوعة من الأشياء. كما تعلمون، تويتر ل سبيل المثال، سقسقة الساخنة. والجميع قادمة الاستيلاء على أن سقسقة. أنواع البضائع، وحصلت على البيع. حصلت على بيع الساخن. حصلت على 70000 طلب في المجيء الثاني للمنتج وصف من بلدي التسويقي. ونحن نرى هذا على تجارة التجزئة عملية قليلا جدا. فكيف نتعامل مع ذلك؟ ليس هناك وسيلة للتعامل مع ذلك. كل ما عندي من المستخدمين يريدون أن يروا نفس قطعة من البيانات. انهم قادمون، بشكل متزامن. ويجعلون جميع الطلبات لنفس قطعة من البيانات. هذا يعطيني هذا المفتاح الساخن، والتي حمراء كبيرة شريط على الرسم البياني الخاص بي أن لا نحب. وهذا ما يشبه. هكذا عبر الفضاء مفتاحي انني اتلقى تم التوصل في بيع سلع. أنا الحصول على أي شيء في أي مكان آخر. 

كيف يمكنني التخفيف من حدة هذه المشكلة؟ حسنا، نحن تخفيف هذا مع ذاكرة التخزين المؤقت. ذاكرة التخزين المؤقت، كنت وضعت في الأساس في الذاكرة القسم أمام قاعدة البيانات. تمكنا [غير مسموع] مخبأ، وكيف يمكن إعداد مخبأ الخاص بك، (غير مسموع) مخبأ [؟ د،؟] كل ما تريد. وضع ما يصل أمام قاعدة البيانات. وبهذه الطريقة يمكنك تخزين البيانات من تلك المفاتيح الساخنة حتى في ذلك ذاكرة التخزين المؤقت الفضاء وقراءة من خلال ذاكرة التخزين المؤقت. 

ثم أكثر من يقرأ بك تبدأ في النظر مثل هذا. حصلت كل هذه مخبأ يضرب هنا وحصلت على شيء يحدث أسفل هنا لأن قاعدة البيانات هو يجلس خلف ذاكرة التخزين المؤقت ويقرأ أبدا يأتي من خلال. إذا قمت بتغيير البيانات في قاعدة بيانات، وأنا لديك لتحديث ذاكرة التخزين المؤقت. يمكننا استخدام شيء مثل ستندفع للقيام بذلك. وساوضح كيف يعمل. كل الحق، والرسائل. البريد الإلكتروني، ونحن جميعا استخدام البريد الإلكتروني. 

هذا هو مثال جيد جدا. لدينا نوعا من الجدول الرسائل. وحصلنا على البريد الوارد والصادر. وهذا هو ما من شأنه أن SQL تبدو وكأنها لبناء هذا البريد الوارد. نحن نوع من استخدام نفس النوع استراتيجية لاستخدام وGSI، وGSI لصندوق البريد الخاص بي وبلدي الصادر. حتى حصلت على رسائل الخام القادمة في جدول رسائلي. والنهج الأول لهذا قد يكون، نقول، حسنا، لا مشكلة. لقد حصلت على رسائل الخام. الرسائل الواردة (غير مسموع)، رسالة ID، هذا أمر عظيم. هذا هو بلدي تجزئة فريدة من نوعها. انا ذاهب لإنشاء اثنين من GSI، واحدة لصندوق البريد الخاص بي، واحد لبلدي الصادر. وأول شيء سأفعل وأنا أقول بلدي هو مفتاح الشباك ستكون المستفيدة و انا ذاهب الى ترتيب في التاريخ. هذا رائع. حصلت على وجهة نظري لطيف هنا. ولكن هناك مشكلة صغيرة هنا. واجهت هذا في قواعد البيانات العلائقية كذلك. ودعوا تقسيم عموديا. كنت تريد أن تبقي بياناتك كبير بعيدا عن البيانات الخاص بك قليلا. 

والسبب هو أنني فلدي انتقل قراءة البنود للحصول على الصفات. وإذا الهيئات بلدي كلها هنا، ثم القراءة فقط عدد قليل من البنود إذا كان لي طول الجسم بلغ متوسطها 256 كيلو بايت لكل منهما، الرياضيات يحصل قبيحة جدا. لذلك أقول أريد أن أقرأ وارد داود. البريد الوارد ديفيد لديه 50 بندا. في المتوسط، وحجم 256 كيلوبايت. وهنا نسبة اعتناقي لوحدة التنسيق الإقليمي هو أربعة كيلو بايت. 

حسنا، دعونا نذهب مع يقرأ تتفق في نهاية المطاف. ما زلت تناول 1600 وحدة التنسيق الإقليمية ل فقط لقراءة البريد الوارد داود. أوتش. حسنا، دعونا الآن نفكر حول كيفية عمل التطبيق. إذا أنا في التطبيق البريد الإلكتروني و أنا أبحث في صندوق البريد الخاص بي، وأنا أنظر إلى جسد كل رسالة، لا، أنا أبحث في ملخصات. أنا أبحث فقط في رؤوس. لذلك دعونا بناء بنية الجدول التي تبدو أشبه ذلك. 

حتى هنا في المعلومات أن سير العمل احتياجاتي. انها في صندوق البريد الخاص بي GSI. انها التاريخ، المرسل، هذا الموضوع، ومن ثم معرف الرسالة، مما يشير العودة الى طاولة الرسائل أين يمكنني الحصول على الجسم. كذلك، فإن هذه تكون معرفات قياسية. سوف يشيرون إلى معرفات البند على جدول دينامو DB. كل مؤشر creates-- دائما دائما هذا البند ID كجزء of-- أن يأتي مع المؤشر. 

حسنا. الجمهور: وهو يروي ذلك حيث يتم تخزينها؟ RICK هوليهان: نعم، يقول exactly-- هذا هو بالضبط ما تفعله. تقول هنا هو بلدي سجل إعادة. وسوف نشير مرة أخرى إلى بلدي سجل إعادة. بالضبط. حسنا، حتى الآن صندوق البريد الخاص بي هو في الواقع أصغر بكثير. وهذا يدعم فعلا سير العمل من التطبيق البريد الإلكتروني. حتى صندوق البريد الخاص بي، وأنا فوق. ذهبت على طول أنا وانقر على الرسالة، هذا عندما كنت في حاجة للذهاب الحصول على الجسم، لأنني ذاهب ل انتقل إلى وجهة نظر مختلفة. لذلك إذا كنت تفكر في نوع من MVC الإطار، تحكم عرض نموذج. 

يحتوي على نموذج البيانات أن عرض الاحتياجات ويتفاعل مع وحدة تحكم. عندما أقوم بتغيير الإطار، عندما يمكنني تغيير وجهة نظر، انه موافق على العودة إلى الخادم وإعادة ملء هذا النموذج، لأن هذا هو ما يتوقعه المستخدم. عند تغيير وجهات النظر، وذلك عندما يمكن أن نعود إلى قاعدة البيانات. لذلك البريد الإلكتروني، انقر فوق. أنا أبحث عن الجسم. جولة. يذهب للحصول على الجسم. 

قرأت أقل بكثير البيانات. أنا أقرأ الهيئات إلا أن ديفيد تحتاج عندما يحتاج إليها. وأنا لا يحرق في عام 1600 وحدة التنسيق الإقليمي فقط لاظهار ارد له. وحتى الآن هكذا- يضرب هذا هو الطريق أن LSI أو GSI-- أنا آسف، GSI، أن ينجح في مسعاه. لدينا التجزئة لدينا على المتلقي. لقد حصلت على مفتاح النطاق على التاريخ. ونحن قد حصلت على سمات المتوقعة أننا بحاجة فقط لدعم وجهة النظر. 

نحن تدوير أنه لصندوق الحفظ. بعثرة على المرسل. وفي الجوهر، لدينا لطيفة جدا، وعرض نظيفة. وانها أننا basically-- لديك هذه الرسائل طيبة الجدول الذي يتم نشر طيف ل انها التجزئة فقط، تجزئته ID الرسالة. ونحن لدينا اثنين من الفهارس التي وتناوب الخروج من هذا الجدول. كل الحق، لذلك الفكرة هنا هي لا الاحتفاظ بالبيانات الكبيرة وهذه البيانات صغير سويا. تقسيم عموديا، تقسيم تلك الجداول. لا تقرأ البيانات لم يكن لديك ل. كل الحق، والألعاب. ونحن جميعا نود الألعاب. على الأقل أنا أحب ألعاب الحين. وحتى بعض من الأشياء أن نتعامل مع عندما نحن نفكر حول الألعاب، أليس كذلك؟ اللعب في هذه الأيام، خصوصا المحمول الألعاب، هو كل شيء عن التفكير. وانا ذاهب لتدوير هنا قليلا بعيدا عن DynamoDB. أنا ذاهب لجلب بعض من المناقشة حول بعض تقنيات AWS الأخرى. 

ولكن فكرة عن الألعاب هو التفكير حول من حيث اجهات برمجة التطبيقات، واجهات برمجة التطبيقات التي هي، بصفة عامة، HTTP وJSON. انها الطريقة الألعاب المحمول نوع من التفاعل مع نهايات ظهورهم. يفعلون JSON نشر. أنها تحصل على البيانات، والأمر كله، عموما، في واجهات برمجة التطبيقات JSON لطيفة. 

أشياء مثل الحصول على أصدقاء، والحصول على البيانات المتصدرين، وتبادل، المحتوى الذي ينتجه المستخدم، دفع ما يصل الى النظام، هذه هي أنواع الأشياء أننا في طريقنا للقيام. بيانات الأصول ثنائي، هذه البيانات قد لا يجلس في قاعدة البيانات. قد تجلس هذا في مخزن كائن، أليس كذلك؟ لكن قاعدة البيانات هو الذهاب الى في نهاية المطاف نقول للنظام، نقول للتطبيق أين تذهب الحصول عليه. وحتما، متعددة الخوادم والبنية التحتية النهاية الخلفية، ومصممة للارتفاع توافر وتطويره. لذلك فان هذه هي الأشياء التي نريد جميعا في البنية التحتية الألعاب اليوم. 

لذلك دعونا نلقي نظرة على ما يشبه. حصلت على النهاية الخلفية الأساسية، واضحة جدا. لدينا نظام هنا مع مناطق توافر متعددة. تحدثنا عن AZS كما being-- التفكير منها كمراكز بيانات منفصلة. مركز بيانات أكثر من واحد في AZ، ولكن هذا موافق، مجرد التفكير منهم عن بيانات منفصلة المراكز التي جغرافيا وخطأ معزولة. 

ونحن في طريقنا لديك حالات زوجين EC2. ونحن في طريقنا ل بعض خادم النهاية الخلفية. ربما لو كنت إرثا الهندسة المعمارية، ونحن استخدام ما نسميه RDS، خدمات قواعد البيانات العلائقية. يمكن أن يكون MSSQL، الخلية، أو شيء من هذا القبيل. هذا هو الطريق الكثير من التطبيقات مصممة اليوم. 

حسنا نحن قد ترغب في الذهاب مع هذا هو عندما كنا مقياس بها. سنقوم المضي قدما ووضع دلو S3 هناك. وأن دلو S3، بدلا من خدمة حتى تلك الكائنات من servers-- لدينا أننا يمكن أن نفعل ذلك. كنت وضعت كل ما تبذلونه من ثنائي الكائنات على الخوادم ويمكنك استخدام تلك الخادم حالات لخدمة ذلك بيانات تصل. ولكن هذا مكلف جدا. 

أفضل طريقة القيام به هو المضي قدما و وضع تلك الكائنات في دلو S3. S3 هو مستودعات الكائن. انها بنيت خصيصا ل تخدم ما يصل هذه الأنواع من الأشياء. وترك طلب هؤلاء العملاء مباشرة من تلك الدلاء الكائن، افراغ الخوادم. لذلك نحن بدأنا التوسع هنا. 

الآن وصلنا إلى المستخدمين في جميع أنحاء العالم. حصلت المستخدمين. أحتاج إلى المحتوى محليا تقع على مقربة من هؤلاء المستخدمين، أليس كذلك؟ لقد خلق دلو S3 كما بلدي مصدر مستودع. وسوف أكون الجبهة التي مع توزيع CloudFront. 

CloudFront هو CD و المحتوى شبكة التسليم. اساسا يأخذ البيانات التي تحددها وتخزين كل ذلك عبر شبكة الانترنت بحيث يمكن للمستخدمين في كل مكان يمكن أن يكون استجابة سريعة جدا عندما يطلبون تلك الكائنات. 

حتى تحصل على فكرة. كنت نوع من الاستفادة من جميع جوانب AWS هنا للحصول على فعلته هذه. وفي نهاية المطاف، نحن نرمي في مجموعة التحجيم السيارات. هكذا حالات AC2 لدينا من خوادم اللعبة لدينا، لأنها تبدأ في الحصول على أكثر انشغالا وأكثر انشغالا وانشغالا، أنها سوف مجرد دوران أخرى سبيل المثال، وتدور حالة أخرى، تدور حالة أخرى. وبالتالي فإن التكنولوجيا AWS ديه، فإنه يسمح لك تحديد المعلمات وتجمع حولها الخوادم سوف تنمو. لذلك يمكن أن يكون ن عدد من الخوادم هناك في أي وقت من الأوقات. وإذا تحميل الخاص يذهب بعيدا، وأنها سوف يتقلص، فإن عدد يتقلص. وإذا كان الحمل يعود، انها سوف تنمو إلى الوراء، مطاطيا. 

ولذلك فإن هذا يبدو رائعا. لقد حصلت على الكثير من حالات EC2. يمكننا وضع ذاكرة التخزين المؤقت في أمام قواعد البيانات، محاولة لتسريع قواعد البيانات. نقطة الضغط المقبلة وعادة ما يرى الناس غير أنها مقياس لعبة باستخدام نظام قواعد البيانات العلائقية. جيز، وقاعدة بيانات أداء رهيب. كيف يمكننا تحسين ذلك؟ دعونا نحاول وضع مخبأ أمام ذلك. 

حسنا، لا يعمل مخبأ كبيرة جدا في المباريات، أليس كذلك؟ للألعاب، الكتابة هي مؤلمة. ألعاب يتم إرسال جدا الثقيلة. لا يعمل مخبأ عندما كنت إرسال ثقيلة لأنك دائما حصلت على تحديث ذاكرة التخزين المؤقت. قمت بتحديث ذاكرة التخزين المؤقت، انها لا علاقة لها أن التخزين المؤقت. انها فعلا العمل الإضافي فقط. 

فأين نذهب هنا؟ كنت قد حصلت على عنق الزجاجة الكبيرة الى هناك في قاعدة البيانات. ومكان يذهبون إليه ومن الواضح أن تقسيم. التقسيم ليس من السهل القيام به عندما كنت التعامل مع قواعد البيانات العلائقية. مع قواعد البيانات العلائقية، كنت المسؤولة عن إدارة وفعالية، مساحة الرئيسي. تقوله المستخدمين بين A و M تذهب هنا، بين N و Z الذهاب إلى هناك. وكنت التحول عبر التطبيق. لذلك كنت تتعامل مع هذا مصدر بيانات التقسيم. لديك قيود المعاملات التي لا تمتد أقسام. كنت قد حصلت على جميع أنواع الفوضى أنك التعامل مع أسفل هناك محاولة للتعامل مع التوسع خارج وبناء البنية التحتية الكبيرة. انها مجرد متعة لا. 

الحضور: حتى أنت تقول أن زيادة نقاط المصدر يسرع هذه العملية؟ RICK هوليهان: زيادة؟ نقاط المصدر: الحضور. RICK هوليهان: نقاط المصدر؟ الحضور: من المعلومات، حيث تأتي المعلومات من؟ RICK هوليهان: رقم ما أقوله هو زيادة عدد من الأقسام في مخزن البيانات يحسن الإنتاجية. فما يحدث هنا هو المستخدمين المقبلة في المثال EC2 هنا، حسنا، إذا كنت بحاجة للمستخدم هذا هو A إلى M، سأذهب هنا. من N إلى p، سأذهب هنا. من P إلى Z، سأذهب هنا. 

الحضور: OK، تلك حتى تلك هي جميع المخزنة في العقد مختلفة؟ 

RICK هوليهان: نعم. التفكير في هذه كما صوامع مختلفة من البيانات. لذلك كنت وجود للقيام بذلك. إذا كنت تحاول أن تفعل هذا، إذا كنت تحاول لتوسيع نطاق على منصة العلائقية، هذا ما تفعلونه. كنت أخذ البيانات و كنت قطع عليه. وكنت تقسيم ذلك عبر مثيلات متعددة من قاعدة البيانات. وكنت تدير كل ما في مستوى التطبيق. انها ليست متعة. فماذا نريد أن تذهب؟ نريد أن نذهب DynamoDB، إدارتها بشكل كامل، NoSQL تخزين البيانات، وتوفير الإنتاجية. نحن نستخدم المؤشرات الثانوية. انها في الاساس HTTP API و تتضمن وثيقة الدعم. لذلك لم يكن لديك ما يدعو للقلق عن أي من ذلك التقسيم. نحن نفعل كل شيء بالنسبة لك. وحتى الآن، بدلا من ذلك، كنت اكتبوا الى طاولة المفاوضات. إذا احتاج الجدول الذي سيتم تقسيم، ما يحدث وراء الكواليس. كنت معزولة تماما من ذلك كمطور. لذلك دعونا نتحدث عن بعض حالات الاستخدام التي واجهتنا في الألعاب، شائعة سيناريوهات الألعاب، المتصدرين. لذلك كنت قد حصلت على المستخدمين القادمة، وBoardNames انهم على، وعشرات لهذا المستخدم. نحن يمكن تجزئة على هوية المستخدم، ثم لدينا مجموعة على اللعبة. لذلك كل مستخدم يريد أن يرى كل لعبة لعبت انه وكل ما قدمه من أعلى درجة في كل لعبة. ذلك أن له المتصدرين الشخصية. 

الآن أريد أن أذهب في وأريد أن get-- حتى أحصل على هذه المتصدرين الشخصية. ما أريد القيام به هو الذهاب الحصول على على أعلى درجة في جميع المستخدمين. فكيف أفعل ذلك؟ عندما يتم تجزئته سجل بلدي على من هوية المستخدم، تراوحت على اللعبة، كذلك انا ذاهب الى المضي قدما وإعادة هيكلة وإنشاء GSI، وانا ذاهب الى إعادة هيكلة تلك البيانات. 

الآن انا ذاهب الى تجزئة على BoardName، والتي هي لعبة. وانا ذاهب الى تتراوح على أعلى درجة. والآن لقد خلق دلاء مختلفة. أنا باستخدام نفس الطاولة، البيانات البند نفسها. ولكن أنا خلق دلو الذي يعطي لي تجميع أعلى درجة قبل المباراة. 

ويمكنني الاستعلام هذا الجدول للحصول على تلك المعلومات. حتى لقد حدد هذا النمط الاستعلام يصل إلى تكون معتمدة من قبل مؤشر الثانوي. الآن يمكن فرزها من قبل BoardName وفرزها من قبل TopScore، اعتمادا على. حتى تتمكن من رؤية، وهذه هي أنواع من حالات استخدام تحصل في الألعاب. آخر حالة استخدام جيدة نحصل في الألعاب هو من الجوائز والذي قد فاز في الجوائز. وهذا هو حال استخدام كبيرة حيث نسميه الفهارس متفرق. مؤشرات قليلة هي القدرة على توليد فهرس الذي لا يعني بالضرورة يحتوي على كل بند واحد على الطاولة. ولما لا؟ لأن السمة التي يجري فهرستها غير موجود على كل بند. 

حتى في هذا الخصوص استخدام الحالة، أنا أقول، أنت تعرف ماذا، أنا ذاهب ل إنشاء سمة تسمى جائزة. وانا ذاهب لإعطاء كل مستخدم يحتوي على الجائزة التي تعزو. المستخدمين الذين لا يملكون الجوائز ليس لدينا هذه السمة. لذلك عندما خلق المؤشر المستخدمين الوحيد التي سوف تظهر حتى في المؤشر هي تلك التي في الواقع قد حصل على جوائز. ذلك أن وسيلة رائعة لتكون قادرة إنشاء فهارس المصفاة التي هم جدا، انتقائية جدا التي لا يجب أن مؤشر الجدول بأكمله. 

لذلك نحن نحصل على انخفاض في الوقت المحدد هنا. انا ذاهب الى المضي قدما وتخطي من وتخطي هذا السيناريو. نتحدث قليلا about-- 

الحضور: هل يمكنني طرح سؤال سريع؟ واحد هو كتابة الثقيلة؟ RICK هوليهان: ما هو؟ الحضور: كتابة الثقيل. RICK هوليهان: كتابة الثقيلة. دعني أرى. 

الحضور: أم لا شيء يمكنك فقط صوت لفي ثوان؟ RICK هوليهان: نذهب من خلال سيناريو التصويت. انها ليست بهذا السوء. هل الرجال قد بضع دقائق؟ حسنا. 

ولذا فإننا سوف نتحدث عن التصويت. حتى التصويت في الوقت الحقيقي، لدينا متطلبات التصويت. المتطلبات هي أن نسمح كل شخص التصويت مرة واحدة فقط. نحن نريد لأحد أن يكون قادرا لتغيير تصويتهم. نريد في الوقت الحقيقي التجميع والتحليل لالتركيبة السكانية أننا في طريقنا لتكون تظهر للمستخدمين على الموقع. 

التفكير في هذا السيناريو. ونحن نعمل الكثير من الواقع البرامج التلفزيونية حيث انهم تفعل هذه بالضبط نوع من الأشياء. حتى تتمكن من التفكير في السيناريو، لدينا الملايين والملايين الفتيات في سن المراهقة من هناك مع هواتفهم الخليوية والتصويت، والتصويت، و التصويت لمن هم تجد أن تكون الأكثر شعبية. لذلك فان هذه هي بعض من متطلبات أن ينفد. 

واتخاذ ذلك أولا في حل هذه المشكلة سيكون لبناء تطبيق بسيط جدا. حتى لقد حصلت على هذا التطبيق. لدي بعض الناخبين هناك. أنها تأتي في، ضربوا التطبيق التصويت. لقد حصلت على بعض الأصوات الجدول الخام سوف تفريغ فقط تلك الأصوات إلى. سآخذ بعض الركام الجدول الاصوات التي سوف أبذل تحليلات والتركيبة السكانية، وسوف نضع كل هذا في هناك. 

وهذا شيء عظيم. الحياة جيدة. الحياة جيدة حتى نكتشف أن هناك دائما واحد أو اثنين فقط الناس التي تحظى بشعبية كبيرة في الانتخابات. هناك أشياء واحد أو اثنين فقط أن الناس يهتمون كثيرا. وإذا كنت في التصويت الحجم، وفجأة أنا على وشك أن يدق من الجحيم اثنين من المرشحين، واحد أو اثنين من المرشحين. وهناك عدد محدود جدا من العناصر الناس يجدون أن شعبية. 

هذا ليس نمط التصميم الجيد. هذا هو في الواقع نمط تصميم سيء جدا لأنه يخلق بالضبط ما كنا تحدث عن الذي كان المفاتيح الساخنة. المفاتيح الساخنة هي شيء نحن لا نحب. 

لذلك كيف نصلح ذلك؟ وحقا، وطريقة لإصلاح هذا هو عن طريق اتخاذ تلك الدلاء مرشح ولكل مرشح لدينا، ونحن في طريقنا إلى إلحاق قيمة عشوائية، الشيء الذي نعرفه، عشوائي قيمة بين واحد و 100، ما بين 100 و 1000، أو بين واحد و1000، لكن العديد من القيم العشوائية التي تريد إلحاق إلى نهاية ذلك المرشح. 

وما أنا حقا فعلت بعد ذلك؟ إذا أنا باستخدام معرف مرشح رئاسة دلو لالأصوات الإجمالية، إذا كنت قد أضفت عشوائي رقم إلى نهاية ذلك، لقد خلقت الآن 10 الدلاء، وهو مائة والدلاء، وألف الدلاء أنني تجميع الأصوات عبر. 

لذلك ليس لدي الملايين، والملايين، والملايين من السجلات القادمة من لهؤلاء المرشحين، وأنا الآن نشر تلك الأصوات عبر المرشح A_1 من خلال المرشح A_100، ل في كل مرة تصويت يأتي في، أنا توليد عشوائي قيمة بين واحد و 100. أنا تغير اتجاهها وضعها على نهاية المرشح هذا الشخص التصويت ل. أنا دفنها في ذلك دلو. 

الآن على مساعدات، وأنا أعلم التي حصلت على مئات من الدلاء. حتى عندما أريد أن أذهب إلى الأمام وتجميع الأصوات، قرأت من كل تلك الدلاء. لذلك أنا المضي قدما وإضافة. وبعد ذلك لا مبعثر جمع حيث أخرج وأقول مهلا، أنت تعرف ماذا، ومفتاح هذا المرشح المساحات هي أكثر من مائة الدلاء. انا ذاهب الى جمع كل يصوت من تلك الدلاء مئة. انا ذاهب الى تجميع لهم وانا ذاهب الى القول، المرشح الأول لديها الآن فرز الأصوات الكلي للالسينية. 

الآن كل من الكتابة الاستعلام والاستعلام قراءة وتوزع بشكل جيد لأنني أكتب في وأنا أقرأ عبر مئات المفاتيح. أنا لا أكتب و قراءة عبر مفتاح واحد الآن. ذلك أن نمط كبيرة. 

هذا هو في الواقع على الارجح واحدة من تصميم أهم أنماط النطاق في NoSQL. سترى هذا النوع من نمط التصميم في كل نكهة. MongoDB، DynamoDB، فإنه لا المسألة، علينا جميعا أن نفعل ذلك. لأنه عندما كنت تتعامل مع تلك المجموعات الضخمة، لديك لمعرفة وسيلة ل تنتشر بها عبر الدلاء. لذلك هذا هو الطريق كنت تفعل ذلك. كل الحق، لذلك ما تفعلونه الآن وكنت مقايضة قراءة التكلفة للكتابة تطويره. تكلفة بلدي هي قراءة وأكثر تعقيدا قليلا ويجب أن أذهب قراءة من مئات من الدلاء بدلا من واحدة. ولكن أنا قادرة على الكتابة. وبلدي الإنتاجية، يا الكتابة سرعة لا تصدق. لذلك عادة ما تكون قيمة تقنية لتوسيع نطاق DynamoDB، أو أي قاعدة بيانات NoSQL لهذه المسألة. ولذا فإننا ترد على كيفية توسيع نطاق ذلك. وبرزت لنا كيفية القضاء على مفاتيح لدينا الساخنة. وهذا أمر رائع. وحصلنا على هذا النظام لطيف. ولقد أعطيت لنا التصويت صحيح جدا لأن لدينا تصويت سجل دي مغفل. انها بنيت في DynamoDB. تحدثنا عن حقوق المشروطة. 

عندما يأتي الناخبين في، يضع لإدراج على الطاولة، أنها تضاف مع ID الناخبين بهم، إذا كانت محاولة لادخال صوت آخر، أفعل الكتابة المشروط. أقول فقط أكتب هذا إذا كان هذا غير موجود. ذلك في أقرب وقت أرى أن أن التصويت لضرب الطاولة، لا أحد آخر سيكون قادرة على وضع تصويتهم في. وهذا أمر رائع. ونحن تزايد عدادات مرشحنا. ونفعله لدينا التركيبة السكانية وكل ذلك. ولكن ماذا يحدث لو كانت لغتي تطبيق يسقط من جديد؟ الآن كل من الأصوات المفاجئة هي القادمة في، وأنا لا أعرف ما إذا كانوا يحصلون معالجتها في بلدي تحليلات والتركيبة السكانية أي أكثر من ذلك. وعند التطبيق يصعد، كيف الجحيم أعرف ما لها صوتا تم معالجة وأين أبدأ؟ 

لذلك هذا هو مشكلة حقيقية عند تبدأ في النظر في هذا النوع من السيناريو. وكيف يمكننا حل ذلك؟ نحن حلها مع ما كنا استدعاء DynamoDB تيارات. هو الوقت أمر تيارات و تقسيم سجل تغيير كل الوصول الى طاولة المفاوضات، كل إرسال الوصول الى طاولة المفاوضات. أي البيانات التي المكتوب على ويبين الجدول حتى على تيار. 

انها في الاساس طابور 24 ساعة. ضربت عناصر تيار، يعيشون لمدة 24 ساعة. يمكن قراءتها عدة مرات. مضمون ليتم تسليمها فقط مرة واحدة لتيار، يمكن قراءة ن عدد من المرات. لذلك ولكن الكثير من العمليات التي تريد تستهلك تلك البيانات، يمكنك تستهلك فيه. وسوف تظهر كل تحديث. كل الكتابة لن يؤدي إلا إلى تظهر مرة واحدة على تيار. لذلك لم يكن لديك ما يدعو للقلق حول تجهيز مرتين من نفس العملية. 

هو أمر منعا باتا لكل بند. عندما نقول مرة أمر وتقسيمه، سترى في القسم على تيار. سترى البنود والتحديثات في النظام. نحن لا ضمان على تيار أنك ذاهب للحصول على كل صفقة في النظام عبر العناصر. 

لذلك تيارات هي idempotent. هل نحن جميعا نعرف ما يعني idempotent؟ Idempotent يعني أنك تستطيع أن تفعل ذلك أكثر، وأكثر، وتكرارا. والنتيجة ستكون هي نفسها. 

تيارات هي idempotent، ولكن يجب عليهم أن يكونوا لعبت من نقطة البداية، في أي مكان تختاره، حتى النهاية، أو أنها لن تؤدي في نفس القيم. 

نفس الشيء مع MongoDB. MongoDB لديه بناء يسمونه oplog. وهو نفس التصور المحدد. العديد من قواعد البيانات NoSQL يكون هذا البناء. يستخدم فيه أن تفعل أشياء مثل النسخ المتماثل الذي هو بالضبط ما نفعله مع تيارات. الحضور: ربما السؤال هرطقة، ولكنك الحديث عن تطبيقات تفعل أسفل وهكذا دواليك. وتيارات مضمونة ل أبدا ربما تنخفض؟ RICK هوليهان: نعم، والجداول ويضمن أن لا يذهب إلى أسفل. نحن إدارة البنية التحتية خلف. الجداول تلقائيا نشر في مجموعة التحجيم السيارات. سنذهب من خلال قليلا قليلا عن ما يحدث. 

لا ينبغي أن أقول أنهم لا مضمونة أبدا النزول. ويضمن العناصر لتظهر في الدفق. وتيار سوف تكون متاحة. وذلك ما تنخفض أو يعود حتى أن يحدث في الأسفل. ذلك covers-- انه موافق. كل الحق، حتى تحصل مختلف عرض أنواع خارج الشاشة. أنواع الرأي التي تعتبر مهمة ل مبرمج وعادة ما تكون، ما كان عليه؟ أحصل على النظرة القديمة. عندما يضرب تحديث الجدول، وأنها سوف دفع النظرة القديمة إلى تيار البيانات بحيث يمكن أرشفة، أو تغيير السيطرة، وتحديد التغيير، التغيير إدارة. 

الصورة الجديدة، ما هو عليه الآن بعد التحديث، وهذا نوع آخر من رأي يمكنك الحصول. يمكنك الحصول على كل الصور القديمة والجديدة. ربما أريد لهم على حد سواء. أريد أن أرى ما كان عليه. أريد أن أرى ما الذي تغير ل. 

لدي نوع الامتثال من العملية التي يتم تشغيلها. فإنه يحتاج إلى التحقق من أن عندما تتغير هذه الأمور، انهم في حدود معينة أو ضمن حدود معينة. 

ثم ربما أنا فقط بحاجة إلى معرفة ما تغير. لا يهمني ما البند تغييرها. ولست بحاجة إلى بحاجة إلى معرفة ما سمات تغييرها. أنا فقط بحاجة إلى معرفة أن ويجري تطرق البنود. لذلك فان هذه هي أنواع وجهات النظر التي تحصل خارج تيار ويمكنك التفاعل معها. 

التطبيق الذي يستهلك تيار، هذا هو نوع من يعمل هذا الطريق. العميل DynamoDB يسأل ل دفع البيانات إلى الجداول. تيارات نشر على ما نسميه شظايا. يتم تحجيم شظايا بشكل مستقل من الجدول. انهم لا يصطف تماما إلى أقسام من الجدول الخاص بك. والسبب هو لأنهم يصطفون إلى القدرة، التيار قدرة الجدول. 

انتشارها في حياتهم الخاصة مجموعة التحجيم السيارات، وأنها بداية لتخرج اعتمادا على مدى العديد من يكتب قادمون، كم عدد reads-- حقا انها يكتب. ليس هناك reads-- ولكن كيف كثير من يكتب تأتي في. 

ثم على الظهر نهاية، لدينا ما استدعاء بوكل، أو مكتبة عميل كينسيس. كينسيس هو تدفق البيانات تكنولوجيا معالجة من الأمازون. وبنيت تيارات على ذلك. 

لذلك يمكنك استخدام بوكل تمكين تطبيق لقراءة الدفق. مكتبة عميل كينسيس الواقع يدير العمال بالنسبة لك. وكما هو الحال بعض أشياء مثيرة للاهتمام. فإنه سيتم إنشاء بعض الجداول حتى في جدولية DynamoDB بك لتعقب العناصر التي تم تجهيزها. لذلك بهذه الطريقة إذا كان يرتد، إذا انها تقع على ويأتي ويحصل وقفت احتياطية، فإنه يمكن تحديد مكان كان عليه في معالجة الدفق. 

هذا أمر مهم جدا عندما كنت تتحدث عن النسخ المتماثل. أريد أن أعرف ما وقد تم معالجة البيانات وما هي البيانات التي تمت حتى الآن لتتم معالجتها. لذلك فإن مكتبة بوكل لتيارات تعطيك الكثير من تلك الوظائف. فإنه يأخذ الرعاية من جميع التجهيزات المنزلية. أنه يقف عامل لكل قشرة. أنه يخلق جدول الإداري لكل قشرة، لكل عامل. ومثل تلك النار العمال، كانت المحافظة على تلك الجداول حتى تعرف هذا السجل كان يقرأ ومعالجتها. وبعد ذلك بهذه الطريقة إذا كانت العملية يموت ويعود على الانترنت، ويمكن استئناف الحق الذي أقلعت منه. 

لذلك نستخدم هذا ل تكرار عبر المنطقة. وهناك الكثير من العملاء لديها الحاجة إلى نقل البيانات أو أجزاء من الجداول بياناتهم حول إلى مناطق مختلفة. هناك تسع مناطق حول العالم. لذلك قد يكون هناك I need-- قد يكون لديك المستخدمين في آسيا، مستخدمين في الساحل الشرقي للولايات المتحدة. لديهم البيانات المختلفة التي يجب أن يتم توزيعها محليا. وربما الذباب مستخدم من آسيا الى الولايات المتحدة، وأريد أن تكرار بيانات معه. لذلك عندما يحصل من الطائرة، لديه تجربة جيدة باستخدام التطبيق المحمول له. 

يمكنك استخدام هذه المنطقة عبر مكتبة النسخ المتماثل للقيام بذلك. أساسا لدينا قدمت اثنين من التكنولوجيات. واحدة تطبيق وحدة يمكنك الوقوف على سبيل المثال EC2 الخاصة بك. تشغيله تكرار محض. ثم رددنا لكم المكتبة. المكتبة التي يمكن استخدامها لبناء التطبيق الخاص بك إذا كنت تريد أن تفعل أشياء مجنونة مع أن data-- مرشح، تكرار جزءا منه فقط، تدوير البيانات، نقله إلى الجدول مختلفة، لذلك جرا وهكذا دواليك. ولهذا النوع من ما يشبه. 

يمكن DynamoDB تيارات يكون معالجتها بواسطة ما نسميه امدا. ذكرنا قليلا عن الحدث أبنية تطبيق مدفوعة. امدا هو عنصر أساسي في ذلك. امدا هو رمز الذي وقع على الطلب ردا على حدث معين. يمكن أن تكون واحدة من تلك الأحداث سجل تظهر على تيار. إذا ظهر سجل في تيار، سنقوم استدعاء هذه الدالة جافا. حسنا، هذا هو جافا سكريبت، وامدا يدعم Node.js، جافا، بيثون، وستدعم قريبا لغات أخرى أيضا. ويكفي القول، انها رمز النقي. إرسال في جاوة، عليك أن تحدد فئة. يمكنك دفع ما يصل إلى JAR امدا. ثم يمكنك تحديد أي فئة للاتصال ردا على هذه الحالة. ثم البنية التحتية لامدا وراء ذلك سيتم تشغيل هذا الرمز. 

يمكن أن التعليمات البرمجية معالجة سجلات قبالة تيار. ويمكن أن تفعل أي شيء يريد معها. في هذا المثال معين، كل ما كنت به حقا هو تسجيل السمات. ولكن هذا هو مجرد رمز. رمز يمكن أن تفعل أي شيء، أليس كذلك؟ 

حتى تتمكن من تدوير تلك البيانات. يمكنك إنشاء طريقة عرض المشتقة. اذا كان هيكل وثيقة، يمكنك تتسطح الهيكل. يمكنك إنشاء فهارس بديلة. كل أنواع الأشياء التي يمكن علاقة مع تيارات DynamoDB. 

وحقا، وهذا ما يشبه. حتى تحصل على تلك التحديثات القادمة من. انهم نزوله السلسلة. انهم قراءة بواسطة الدالة امدا. انهم الدورية للبيانات و دفع ما يصل في الجداول المشتقة، إعلام الأنظمة الخارجية التغيير، ودفع البيانات إلى ElastiCache. 

تحدثنا عن كيفية وضع ذاكرة التخزين المؤقت أمام قاعدة البيانات عن أن مبيعات سيناريو. حسنا ماذا يحدث إذا أنا تحديث هذه السلعة؟ حسنا، إذا كان لي امدا وظيفة تعمل على هذا الجدول، إذا قمت بتحديث وصف السلعة، انها سوف التقاط سجل قبالة تيار، وأنها سوف تحديث ElastiCache المثال مع البيانات الجديدة. لذلك أن الكثير من ما نقوم به مع امدا. انها رمز الغراء، والموصلات. ويعطي في الواقع القدرة على اطلاق وتشغيل التطبيقات المعقدة جدا بدون خادم مخصص البنية التحتية، وهو بارد حقا. 

لذلك دعونا نعود إلى موقعنا في الوقت الحقيقي العمارة التصويت. هذا هو جديد وتحسنت مع دينا تمكين تيارات وبوكل التطبيق. نفسه كما كان من قبل، ويمكننا التعامل مع أي حجم الانتخابات. نحن أحب هذا. نقوم به من يجمع مبعثر عبر الدلاء متعددة. لدينا تأمين متفائل مستمرة. نحن يمكن أن تبقي ناخبينا من تغيير أصواتهم. يمكنهم التصويت مرة واحدة فقط فقط. هذا رائع. في الوقت الحقيقي التسامح مع الخطأ، تجميع تحجيم الآن. إذا انخفض الشيء مرارا، فإنه يعرف أين إعادة تشغيل نفسه عندما يتعلق الأمر بعمل نسخة احتياطية ل نستخدمه التطبيق بوكل. وبعد ذلك يمكننا أيضا استخدام ذلك تطبيق بوكل لدفع البيانات من إلى الانزياح نحو الأحمر لأغراض أخرى تحليلات التطبيق، أو استخدام وMapReduce مطاطا لتشغيل في الوقت الحقيقي الجري تجمعات خارج من تلك البيانات. 

لذلك هذه هي الأشياء التي لم نتحدث عن ذلك بكثير. ولكنهم إضافية التقنيات التي تأتي تلقى على كاهلها عندما كنت تبحث في هذه الأنواع من السيناريوهات. 

كل الحق، حتى أن حوالي تحليلات مع DynamoDB تيارات. يمكنك جمع دي مغفل البيانات، تفعل كل أنواع من أشياء جميلة، البيانات المجمعة في الذاكرة، وخلق هذه الجداول المشتقة. هذا هو حال استخدام ضخمة أن الكثير من الزبائن وتشارك مع، مع الأخذ في متداخلة خصائص تلك الوثائق JSON وإنشاء فهارس إضافية. 

نحن في نهاية المطاف. شكرا لتحمل معي. لذلك دعونا نتحدث عن العمارة المرجعية. DynamoDB يجلس في منتصف ذلك الكثير من البنى التحتية AWS. أساسا يمكنك وصل الأمر تصل إلى أي شيء تريده. التطبيقات التي تم إنشاؤها باستخدام دينامو تشمل امدا، ElastiCache، CloudSearch، دفع البيانات للخروج الى مطاطا MapReduce، الاستيراد والتصدير من DynamoDB إلى S3، وجميع أنواع سير العمل. ولكن ربما الأفضل شيء للحديث عنه، وهذا هو ما هو حقا المثير للاهتمام هو أننا عندما الحديث عن التطبيقات الحدث مدفوعة. 

هذا مثال من مشروع الداخلي أن لدينا حيث أننا في الواقع نشر لجمع نتائج المسح. حتى في وجود صلة البريد الإلكتروني التي وجهنا، هناك سوف أكون يكون قليلا بنقرة وصلة قائلا هنا للرد على المسح. وعندما يكون الشخص النقرات التي تصل، ماذا يحدث غير أنها هدم آمنة HTML استمارة استقصاء من S3. هناك أي ملقم. هذا هو مجرد كائن S3. 

هذا النموذج حتى يأتي، تصل الاحمال في المتصفح. انها حصلت على العمود الفقري. انها حصلت معقدة جافا سكريبت أن انها تعمل. لذلك فمن تطبيق غنية جدا يعمل في متصفح العميل. انهم لا يعرفون أنهم ليسوا التفاعل مع خادم النهاية الخلفية. عند هذه النقطة، كل شيء المتصفح. 

كانت تنشر النتائج إلى ما نسميه API بوابة الأمازون. API بوابة هو مجرد API على شبكة الإنترنت التي يمكنك تحديد وعقف إلى ما تريد. في هذه الحالة بالذات، ونحن التوصيل إلى وظيفة امدا. 

حتى بلدي عملية نشر يحدث مع أي ملقم. أساسا أن API بوابة يجلس هناك. يكلف لي شيئا حتى الناس بدء بالإرسال إليها، أليس كذلك؟ وظيفة لامبدا فقط يجلس هناك. ويكلف لي شيئا حتى يبدأ الناس ضربه. هكذا ترون، حيث بلغ حجم زيادات، وذلك عندما تأتي هذه الاتهامات. أنا لا بتشغيل خادم 24/07. 

لذلك أنا سحب شكل أسفل من دلو، وأنا آخر من خلال API بوابة إلى وظيفة امدا. ثم امدا وتقول وظيفة، كما تعلمون ما، لقد حصلت على بعض PIIs، بعض معلومات شخصية في هذه الردود. حصلت على تعليقات القادمة من المستخدمين. لقد حصلت على عناوين البريد الإلكتروني. لقد حصلت على أسماء المستخدمين. 

اسمحوا لي أن تقسيم هذا الخروج. انا ذاهب لتوليد بعض التعريف من هذا السجل. وانا ذاهب لدفع الفوقية إلى DynamoDB. وأنا لا يمكن تشفير كافة البيانات ودفعها إلى DynamoDB إذا أريد. لكن من الأسهل بالنسبة لي، في هذا استخدام الحالة، على المضي قدما ليقول، انا ذاهب لدفع البيانات الخام في دلو S3 مشفرة. ولذا فإنني استخدام المدمج في S3 جانب الخادم التشفير وإدارة المفاتيح الأمازون الخدمة بحيث لدي مفتاح يمكن أن تدور على فترات منتظمة، وأستطيع أن حماية تلك البيانات PII كجزء من هذا العمل كله. 

وذلك ما فعلت؟ لقد نشرت للتو ككل التطبيق، وليس لدي أي الخادم. ذلك هو ما الدافع وراء أحداث التطبيق العمارة يفعل لك. 

الآن إذا كنت تفكر في حالة استخدام لthis-- لدينا زبائن آخرين أتحدث لعن هذه العمارة الدقيق الذي حملات كبيرة هائل، الذي تبحث في هذا ويذهب، يا بلدي. لأنه الآن، في وسعهم دفع الأساس هو هناك، ترك تلك الحملة مجرد الجلوس هناك حتى تطلق، وليس داعي للقلق التين حول أي نوع من البنية التحتية ستكون هناك لتقديم الدعم لها. وبعد ذلك في أقرب وقت يتم تلك الحملة، انها مثل البنية التحتية فقط على الفور يذهب بعيدا لأن هناك حقا لم البنية التحتية. انها رمز فقط أن يجلس على امدا. انها بيانات العادل الذي يجلس في DynamoDB. هذا هو وسيلة مذهلة لبناء التطبيقات. 

الجمهور: ذلك هو أنه أكثر زائلة مما سيكون عليه إذا تم تخزينها على خادم الفعلي؟ 

RICK هوليهان: بالتأكيد. لأن هذا المثال الخادم يجب أن يكون 24/07. عليها أن تكون متاحة لل شخص للرد على. بالاضافة الى تخمين ما؟ S3 هو متاح 24/7. S3 يستجيب دائما. وS3 جدا، جيد جدا في تخدم ما يصل الكائنات. يمكن لهذه الأشياء أن تكون ملفات HTML، أو ملفات جافا سكريبت، أو ما تريد. يمكنك تشغيل تطبيقات الويب الغنية جدا من دلاء S3، والناس. 

وهكذا هذا هو الفكرة هنا هو الابتعاد عن الطريق كنا نفكر في ذلك. علينا جميعا أن نفكر في استخدامها حيث الخوادم والمضيفين. انها ليست عن ذلك بعد الآن. ولكن عن البنية التحتية كرمز. نشر رمز إلى سحابة و السماح للسحابة تشغيله بالنسبة لك. وهذا ما يحاول AWS القيام به. 

الحضور: وهكذا مربع الذهب الخاص بك في منتصف من API بوابة ليس مثل الخادم، ولكن بدلا من ذلك هو just-- 

RICK هوليهان: يمكنك التفكير من هو خادم واجهة. كل ما هو غير ذلك سنأخذ HTTP طلب وتعيين ذلك إلى عملية أخرى. هذا هو كل ما يفعل. وفي هذه الحالة، نحن رسم الخرائط أن وظيفة امدا. كل الحق، لذلك هذا كل ما حصل. اشكرك شكرا جزيلا. أنا أقدر ذلك. وأنا أعلم أننا نريد قليلا مع مرور الوقت. ونأمل أن حصل يا رفاق قليلا من المعلومات يمكنك أن يسلب اليوم. وأعتذر إذا ذهبت على بعض رؤوسكم، ولكن هناك الكثير جيد لل المعرفة التأسيسية الأساسية أعتقد أنه قيمة للغاية بالنسبة لك. لذلك أشكركم على استضافتي. [تصفيق] الحضور: (غير مسموع) عندما كنت تقولين كان عليك أن تذهب من خلال كل شيء من البداية إلى النهاية للحصول على القيم الصحيحة أو نفس القيم، كيف يمكن أن القيم تغيير إذا (غير مسموع). 

RICK هوليهان: أوه، idempotent؟ كيف يمكن تغيير القيم؟ حسنا، لأنه إذا لم تقم بتشغيل على طول الطريق حتى النهاية، ثم أنا لا أعرف ما هي التغييرات تم إجراؤها في الميل الأخير. انها لن تكون نفس البيانات مثل ما رأيت. الحضور: أوه، لذلك أنت فقط لم نصل مدخلات بأكمله. RICK هوليهان: الحق. عليك أن تذهب من البداية لهذه الغاية، وبعد ذلك انها ستكون حالة متناسقة. رائع. 

الحضور: إذن أنت أظهر لنا DynamoDB يمكن القيام به وثيقة أو قيمة المفتاح. وقضينا الكثير من الوقت على قيمة المفتاح مع تجزئة والطرق على الوجه حولها. عند النظر في هذه الجداول، هو أن تاركا وراءه النهج المستند؟ 

RICK هوليهان: أود أن لا يقول تركها وراءهم. 

الحضور: تم فصلهم من the-- 

RICK هوليهان: مع وثيقة النهج، ونوع المستند في DynamoDB ومجرد التفكير على أنها سمة أخرى. انها سمة يحتوي على هيكل البيانات الهرمية. ثم في الاستعلامات، يمكنك استخدام خصائص تلك الكائنات باستخدام تدوين كائن. حتى أتمكن من تصفية على متداخلة ممتلكات وثيقة JSON. الحضور: لذلك أي وقت أنا القيام النهج المستند، أنا يمكن أن تصل إلى نوع من في tabular-- الحضور: بالتأكيد. الحضور: --indexes و الأشياء التي تحدث فقط عن. RICK هوليهان: نعم، فهارس وكل ذلك، عندما تريد فهرسة خصائص JSON، الطريقة التي سيكون لدينا لذلك هي إذا يمكنك إدراج كائن JSON أو وثيقة إلى دينامو، يمكنك استخدام تيارات. أن تيارات قراءة الإدخال. سوف تحصل على هذا JSON الاعتراض وكنت أقول OK، ما هي الملكية أريد أن المؤشر؟ 

يمكنك إنشاء جدول المشتقة. الآن هذه هي الطريقة التي يعمل في الوقت الحالي. نحن لا نسمح لك مؤشر مباشرة هذه الخصائص. 

الحضور: Tabularizing المستندات الخاصة بك. 

RICK هوليهان: بالضبط، تسطيح ذلك، tabularizing ذلك، بالضبط. هذا ما تفعله معها. 

الحضور: شكرا لك. 

RICK هوليهان: نعم، على الاطلاق، وشكرا لكم. الحضور: لذلك نوع من مونجو يلتقي classifers رديس. 

RICK هوليهان: نعم، انها الكثير من هذا القبيل. هذا وصفا جيدا لذلك. رائع.