Amazon Redshift: سعر أقل وأداء أعلى | خدمات الويب الأمازون

Amazon Redshift: سعر أقل وأداء أعلى | خدمات الويب الأمازون

عقدة المصدر: 2959258

مثل جميع العملاء تقريبًا، تريد إنفاق أقل قدر ممكن مع الحصول على أفضل أداء ممكن. هذا يعني أنك بحاجة إلى الاهتمام بأداء السعر. مع الأمازون الأحمر، يمكنك الحصول على كعكتك و أكلها أيضا! يوفر Amazon Redshift تكلفة أقل بما يصل إلى 4.9 مرات لكل مستخدم وأداء أفضل بما يصل إلى 7.9 مرات من السعر مقارنة بمستودعات البيانات السحابية الأخرى في أعباء العمل الواقعية باستخدام تقنيات متقدمة مثل القياس المتزامن لدعم مئات المستخدمين المتزامنين، وترميز السلسلة المحسن لأداء استعلام أسرع ، و أمازون Redshift Serverless تحسينات الأداء. تابع القراءة لفهم سبب أهمية أداء السعر وكيف أن أداء السعر في Amazon Redshift هو مقياس لمدى تكلفة الحصول على مستوى معين من أداء عبء العمل، أي أداء ROI (العائد على الاستثمار).

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

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

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

أداء السعر لأحمال العمل في العالم الحقيقي

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

تتضمن بعض الأمثلة الحديثة لتحسينات الأداء المدفوعة بقياس الأسطول عن بُعد ما يلي:

  • تحسينات استعلام السلسلة – من خلال تحليل كيفية معالجة Amazon Redshift لأنواع مختلفة من البيانات في أسطول Redshift، وجدنا أن تحسين الاستعلامات ذات السلاسل الثقيلة من شأنه أن يحقق فائدة كبيرة لأعباء عمل عملائنا. (سنناقش هذا بمزيد من التفصيل لاحقًا في هذه المقالة.)
  • وجهات النظر تتحقق الآلي - لقد وجدنا أن عملاء Amazon Redshift غالبًا ما يقومون بتشغيل العديد من الاستعلامات التي لها أنماط استعلام فرعي شائعة. على سبيل المثال، قد تقوم عدة استعلامات مختلفة بربط نفس الجداول الثلاثة باستخدام نفس شرط الربط. أصبح بإمكان Amazon Redshift الآن إنشاء طرق عرض متحققة والحفاظ عليها تلقائيًا ثم إعادة كتابة الاستعلامات بشفافية لاستخدام طرق العرض المتحققة باستخدام طرق التعلم المستفادة آليًا عرض مادي آلي ميزة التشغيل الذاتي في Amazon Redshift. عند تمكينها، يمكن للعروض المنجزة تلقائيًا أن تزيد من أداء الاستعلام بشكل شفاف للاستعلامات المتكررة دون أي تدخل من المستخدم. (لاحظ أنه لم يتم استخدام طرق العرض المادية الآلية في أي من النتائج المعيارية التي تمت مناقشتها في هذا المنشور).
  • أعباء العمل عالية التزامن - حالة الاستخدام المتزايدة التي نراها هي استخدام Amazon Redshift لخدمة أعباء العمل المشابهة للوحة المعلومات. تتميز أحمال العمل هذه بأوقات استجابة الاستعلام المطلوبة التي تبلغ ثوانٍ من رقم واحد أو أقل، مع قيام عشرات أو مئات من المستخدمين المتزامنين بتشغيل الاستعلامات في وقت واحد باستخدام نمط استخدام حاد وغير متوقع في كثير من الأحيان. والمثال النموذجي على ذلك هو لوحة معلومات BI المدعومة من Amazon Redshift والتي تتميز بارتفاع كبير في حركة المرور صباح يوم الاثنين عندما يبدأ عدد كبير من المستخدمين أسبوعهم.

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

لمحاكاة هذا النوع من عبء العمل، استخدمنا معيارًا مشتقًا من TPC-DS مع مجموعة بيانات تبلغ 100 جيجابايت. TPC-DS هو معيار معياري صناعي يتضمن مجموعة متنوعة من استعلامات مستودع البيانات النموذجية. بهذا المقياس الصغير نسبيًا الذي يبلغ 100 جيجابايت، يتم تشغيل الاستعلامات في هذا المعيار على Redshift Serverless في متوسط ​​بضع ثوانٍ، وهو ما يمثل ما يتوقعه المستخدمون الذين يقومون بتحميل لوحة معلومات BI التفاعلية. لقد أجرينا ما بين 1 إلى 200 اختبار متزامن لهذا المعيار، وقمنا بمحاكاة ما بين 1 إلى 200 مستخدم يحاولون تحميل لوحة المعلومات في نفس الوقت. لقد كررنا أيضًا الاختبار مقابل العديد من مستودعات البيانات السحابية البديلة الشائعة والتي تدعم أيضًا التوسع تلقائيًا (إذا كنت على دراية بالمنشور تواصل Amazon Redshift ريادتها لأداء السعر، لم نقم بتضمين المنافس أ لأنه لا يدعم التوسع تلقائيًا). لقد قمنا بقياس متوسط ​​وقت استجابة الاستعلام، مما يعني المدة التي سينتظرها المستخدم حتى تنتهي استعلاماته (أو تحميل لوحة التحكم الخاصة به). وتظهر النتائج في الرسم البياني التالي.

يتوسع المنافس ب بشكل جيد حتى حوالي 64 استعلامًا متزامنًا، وعند هذه النقطة يكون غير قادر على توفير حوسبة إضافية وتبدأ الاستعلامات في قائمة الانتظار، مما يؤدي إلى زيادة أوقات الاستجابة للاستعلام. على الرغم من أن المنافس C قادر على التوسع تلقائيًا، إلا أنه يتوسع إلى إنتاجية استعلام أقل من كل من Amazon Redshift والمنافس B ولا يستطيع إبقاء أوقات تشغيل الاستعلام منخفضة. بالإضافة إلى ذلك، فهو لا يدعم الاستعلامات في قائمة الانتظار عند نفاد الحوسبة، مما يمنعه من التوسع إلى ما يتجاوز حوالي 128 مستخدمًا متزامنًا. يتم رفض إرسال استفسارات إضافية تتجاوز ذلك من قبل النظام.

هنا، يتمكن Redshift Serverless من الحفاظ على وقت استجابة الاستعلام ثابتًا نسبيًا عند حوالي 5 ثوانٍ حتى عندما يقوم مئات المستخدمين بتشغيل الاستعلامات في نفس الوقت. يزداد متوسط ​​أوقات استجابة الاستعلام للمنافسين B وC بشكل مطرد مع زيادة الحمل على المستودعات، مما يؤدي إلى اضطرار المستخدمين إلى الانتظار لفترة أطول (حتى 16 ثانية) حتى تعود استعلاماتهم عندما يكون مستودع البيانات مشغولاً. وهذا يعني أنه إذا كان المستخدم يحاول تحديث لوحة المعلومات (والتي قد ترسل أيضًا العديد من الاستعلامات المتزامنة عند إعادة التحميل)، فسيكون Amazon Redshift قادرًا على الحفاظ على أوقات تحميل لوحة المعلومات أكثر اتساقًا حتى إذا تم تحميل لوحة المعلومات بواسطة عشرات أو مئات من التطبيقات الأخرى. المستخدمين في نفس الوقت.

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

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

النتائج السابقة واضحة للتكرار. جميع الاستعلامات المستخدمة في المعيار متوفرة في موقعنا مستودع جيثب ويتم قياس الأداء من خلال إطلاق مستودع بيانات، وتمكين القياس المتزامن على Amazon Redshift (أو ميزة القياس التلقائي المقابلة في المستودعات الأخرى)، وتحميل البيانات خارج الصندوق (بدون ضبط يدوي أو إعداد خاص بقاعدة البيانات)، ثم تشغيل التدفق المتزامن للاستعلامات في التزامنات من 1 إلى 200 في خطوات من 32 في كل مستودع بيانات. يشير نفس GitHub repo إلى بيانات TPC-DS التي تم إنشاؤها مسبقًا (وغير المعدلة). خدمة تخزين أمازون البسيطة (Amazon S3) بمقاييس مختلفة باستخدام مجموعة أدوات توليد البيانات TPC-DS الرسمية.

تحسين أعباء العمل ذات السلاسل الثقيلة

كما ذكرنا سابقًا، يبحث فريق Amazon Redshift باستمرار عن فرص جديدة لتقديم أداء سعر أفضل لعملائنا. أحد التحسينات التي أطلقناها مؤخرًا والذي أدى إلى تحسين الأداء بشكل ملحوظ هو التحسين الذي يعمل على تسريع أداء الاستعلامات عبر بيانات السلسلة. على سبيل المثال، قد ترغب في العثور على إجمالي الإيرادات الناتجة عن متاجر البيع بالتجزئة الموجودة في مدينة نيويورك باستخدام استعلام مثل SELECT sum(price) FROM sales WHERE city = ‘New York’. يقوم هذا الاستعلام بتطبيق مسند على بيانات السلسلة (city = ‘New York’). كما يمكنك أن تتخيل، فإن معالجة البيانات المتسلسلة موجودة في كل مكان في تطبيقات مستودعات البيانات.

لتحديد عدد مرات وصول أعباء عمل العملاء إلى السلاسل، أجرينا تحليلًا تفصيليًا لاستخدام نوع بيانات السلسلة باستخدام قياس الأسطول عن بُعد لعشرات الآلاف من مجموعات العملاء التي تديرها Amazon Redshift. يشير تحليلنا إلى أنه في 90% من المجموعات، تشكل أعمدة السلسلة 30% على الأقل من جميع الأعمدة، وفي 50% من المجموعات، تشكل أعمدة السلسلة 50% على الأقل من جميع الأعمدة. علاوة على ذلك، فإن غالبية الاستعلامات التي يتم تشغيلها على منصة مستودع البيانات السحابية Amazon Redshift تصل إلى عمود سلسلة واحد على الأقل. هناك عامل مهم آخر وهو أن بيانات السلسلة غالبًا ما تكون ذات قيمة أساسية منخفضة، مما يعني أن الأعمدة تحتوي على مجموعة صغيرة نسبيًا من القيم الفريدة. على سبيل المثال، على الرغم من أن orders قد يحتوي الجدول الذي يمثل بيانات المبيعات على مليارات الصفوف order_status قد يحتوي العمود الموجود داخل هذا الجدول على عدد قليل فقط من القيم الفريدة عبر مليارات الصفوف، مثل pending, in processو completed.

حتى وقت كتابة هذه السطور، يتم ضغط معظم أعمدة السلسلة في Amazon Redshift باستخدام LZO or ZSTD خوارزميات. تعتبر هذه خوارزميات ضغط جيدة للأغراض العامة، ولكنها ليست مصممة للاستفادة من بيانات السلسلة ذات العدد المنخفض. على وجه الخصوص، تتطلب فك ضغط البيانات قبل تشغيلها، وتكون أقل كفاءة في استخدامها لعرض النطاق الترددي لذاكرة الأجهزة. بالنسبة للبيانات ذات العدد المنخفض، هناك نوع آخر من الترميز يمكن أن يكون أكثر مثالية: BYTEDICT. يستخدم هذا التشفير نظام ترميز القاموس الذي يسمح لمحرك قاعدة البيانات بالعمل مباشرة على البيانات المضغوطة دون الحاجة إلى فك ضغطها أولاً.

لمزيد من تحسين أداء السعر لأحمال العمل ذات السلاسل الثقيلة، تقدم Amazon Redshift الآن تحسينات إضافية للأداء تعمل على تسريع عمليات الفحص والتقييمات الأصلية، عبر أعمدة سلسلة ذات أصل منخفض تم ترميزها كـ BYTEDICT، بشكل أسرع بما يتراوح بين 5 إلى 63 مرة (راجع النتائج في القسم التالي) مقارنة بترميزات الضغط البديلة مثل LZO أو ZSTD. يحقق Amazon Redshift هذا التحسين في الأداء من خلال توجيه عمليات الفحص عبر أعمدة سلسلة خفيفة الوزن وفعالة من حيث كفاءة وحدة المعالجة المركزية ومشفرة بواسطة BYTEDICT ومنخفضة العدد. تعمل تحسينات معالجة السلسلة هذه على الاستخدام الفعال لعرض النطاق الترددي للذاكرة الذي توفره الأجهزة الحديثة، مما يتيح إجراء تحليلات في الوقت الفعلي لبيانات السلسلة. تعد إمكانات الأداء المقدمة حديثًا هذه مثالية لأعمدة السلسلة ذات الأعداد المنخفضة (حتى بضع مئات من قيم السلسلة الفريدة).

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

نتائج الأداء

لقياس تأثير أداء تحسينات السلسلة الخاصة بنا، قمنا بإنشاء مجموعة بيانات بسعة 10 تيرابايت (Tera Byte) تتكون من بيانات سلسلة ذات أصل منخفض. لقد أنشأنا ثلاثة إصدارات من البيانات باستخدام سلاسل قصيرة ومتوسطة وطويلة، تتوافق مع المئين 25 و50 و75 من أطوال السلسلة من القياس عن بعد لأسطول Amazon Redshift. قمنا بتحميل هذه البيانات إلى Amazon Redshift مرتين، وقمنا بتشفيرها في حالة واحدة باستخدام ضغط LZO وفي حالة أخرى باستخدام ضغط BYTEDICT. أخيرًا، قمنا بقياس أداء الاستعلامات كثيفة الفحص التي تُرجع العديد من الصفوف (90% من الجدول)، وعدد متوسط ​​من الصفوف (50% من الجدول)، وبضعة صفوف (1% من الجدول) فوق هذه الصفوف المنخفضة -مجموعات بيانات سلسلة أصل. يتم تلخيص نتائج الأداء في الرسم البياني التالي.

شهدت الاستعلامات ذات المسندات التي تتطابق مع نسبة عالية من الصفوف تحسينات تتراوح بين 5-30 مرة باستخدام تشفير BYTEDICT المتجه الجديد مقارنةً بـ LZO، في حين شهدت الاستعلامات ذات المسندات التي تتطابق مع نسبة منخفضة من الصفوف تحسينات تتراوح بين 10-63 مرة في هذا المعيار الداخلي.

Redshift Server-أداء السعر بدون خادم

بالإضافة إلى نتائج الأداء عالي التزامن المقدمة في هذا المنشور، استخدمنا أيضًا معيار Cloud Data Warehouse المشتق من TPC-DS لمقارنة أداء السعر لـ Redshift Serverless بمستودعات البيانات الأخرى باستخدام مجموعة بيانات أكبر تبلغ 3 تيرابايت. لقد اخترنا مستودعات البيانات التي تم تسعيرها بشكل مماثل، في هذه الحالة ضمن 10% من 32 دولارًا في الساعة باستخدام التسعير المتاح للجمهور عند الطلب. تُظهر هذه النتائج أنه، مثل مثيلات Amazon Redshift RA3، يقدم Redshift Serverless أداءً أفضل للسعر مقارنةً بمستودعات البيانات السحابية الرائدة الأخرى. وكما هو الحال دائمًا، يمكن تكرار هذه النتائج باستخدام نصوص SQL الخاصة بنا في ملفنا مستودع جيثب.

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

احصل على أفضل أداء من حيث السعر لأعباء العمل لديك

المعايير المستخدمة في هذا المنشور مستمدة من معيار TPC-DS القياسي في الصناعة، ولها الخصائص التالية:

  • يتم استخدام المخطط والبيانات بدون تعديل من TPC-DS.
  • يتم إنشاء الاستعلامات باستخدام مجموعة TPC-DS الرسمية مع معلمات الاستعلام التي تم إنشاؤها باستخدام البذرة العشوائية الافتراضية لمجموعة TPC-DS. يتم استخدام متغيرات الاستعلام المعتمدة من TPC للمستودع إذا كان المستودع لا يدعم لهجة SQL لاستعلام TPC-DS الافتراضي.
  • يتضمن الاختبار 99 استعلامات TPC-DS SELECT. لا يتضمن خطوات الصيانة والإنتاجية.
  • بالنسبة لاختبار التزامن الفردي بسعة 3 تيرابايت، تم تشغيل ثلاث عمليات تشغيل للطاقة، ويتم إجراء أفضل تشغيل لكل مستودع بيانات.
  • يتم حساب أداء السعر لاستعلامات TPC-DS على أنه التكلفة لكل ساعة (USD) مضروبة في وقت التشغيل المعياري بالساعات، وهو ما يعادل تكلفة تشغيل المعيار. يتم استخدام أحدث الأسعار المنشورة حسب الطلب لجميع مستودعات البيانات وليس تسعير المثيلات المحجوزة كما هو مذكور سابقًا.

نحن نطلق على هذا المعيار اسم Cloud Data Warehouse، ويمكنك بسهولة إعادة إنتاج نتائج القياس السابقة باستخدام البرامج النصية والاستعلامات والبيانات المتوفرة في موقعنا. مستودع جيثب. إنه مشتق من معايير TPC-DS كما هو موضح في هذا المنشور، وعلى هذا النحو لا يمكن مقارنته بنتائج TPC-DS المنشورة، لأن نتائج اختباراتنا لا تتوافق مع المواصفات الرسمية.

وفي الختام

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

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

للبقاء على اطلاع بأحدث التطورات في Amazon Redshift، اتبع ما الجديد في Amazon Redshift إطعام.


عن المؤلفين

ستيفان جرومول هو أحد كبار مهندسي الأداء في فريق Amazon Redshift حيث يكون مسؤولاً عن قياس أداء Redshift وتحسينه. وفي أوقات فراغه، يستمتع بالطهي واللعب مع أولاده الثلاثة وتقطيع الحطب.

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

عامر شاه هو مهندس أول في فريق Amazon Redshift Service.

سانكيت هاسي هو مدير تطوير البرمجيات في فريق Amazon Redshift Service.

أوريستيس بوليكرونيو هو مهندس رئيسي في فريق Amazon Redshift Service.

الطابع الزمني:

اكثر من بيانات AWS الضخمة