فهرس الجنون: كيفية تجنب فوضى قاعدة البيانات

بواسطة Techopedia Staff ، 5 أكتوبر 2016

الوجبات الجاهزة: يناقش المضيف إريك كافاناغ فهرسة قواعد البيانات مع الدكتور روبن بلور وديز بلانشفيلد وبرت سكالزو من المعهد.

أنت لم تسجل الدخول حاليًا. يرجى تسجيل الدخول أو التسجيل لمشاهدة الفيديو.

شريك محتوى Techopedia

يرتبط موظفو Techopedia بـ Bloor Group ويمكن الاتصال بهم باستخدام الخيارات الموجودة على اليمين. للحصول على معلومات حول كيفية عملنا مع شركاء الصناعة ، انقر هنا.

• الملف الشخصي
• موقع الكتروني

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

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

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

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

والإجابة على ذلك ، أعتقد أن مايكل ستونبراكر أعطى أفضل إجابة على ذلك ، وقال: "يمكن لقاعدة البيانات معرفة المزيد عن مكان البيانات ومدى سرعة الحصول عليها ، مما يمكن لأي برنامج أن يعرفه". وأعتقد أن هذا مثير للاهتمام. إنها طبيعة اللعبة. لكن في عام 19 - حوالي عام 1989 ، بدأت في تحليل التكنولوجيا ، وكما تعلمون ، في تلك المرحلة الزمنية ، كانت قواعد البيانات بسيطة للغاية وقواعد البيانات العلائقية كانت بسيطة للغاية. كانت لديهم قدرة قليلة جدًا ، أعني أنه يمكنهم تخزين البيانات ، ومن الواضح أنك تستطيع عمل نسخة احتياطية منها ، وكانوا متوافقين مع ACID ، لكن لديهم بالفعل مُحسِّن ضعيف جدًا. في الواقع ، سيكون من الصعب القول إن لديهم القدرة على تحسين الأداء على الإطلاق.

وبعد ذلك أصبحوا أفضل وأفضل ، ولكن ، كما تعلمون ، عندما لا تعمل قاعدة بيانات - حيث يبدو أن هذه الكنغر تشير بطريقة أو بأخرى - يمكن أن يكون هناك الكثير من الأسباب البطيئة لتباطؤها. وهذا يقودني إلى النقطة: تحتوي قواعد البيانات على العديد من الوظائف ، ولكن أهمها هو تحسين الاستعلام. إذا لم يفعلوا ذلك ، فلن تستخدمها. يتعلق الأمر بالحصول على المعلومات بسرعة ، إنه يتعلق بالقدرة على القيام بذلك عندما يكون هناك الكثير من المستخدمين المتزامنين ، وهذه مشكلة صعبة. وعندما تنظر بالفعل إلى ، دعنا نسميها قواعد البيانات الناضجة ، إذا أردت - ولكن بالتأكيد Oracle ، إلى حد أقل قليلاً ، فإن Microsoft SQL Server ، وبالتأكيد Teradata و DB2 - قد حصلت على محسن لقواعد البيانات هذه ، عقود في بناء. كما تعلمون ، لم يفعلوا - لم يجلس شخص ما - ستة رجال في رجل وسنة ومشروع وطرقوا واحدًا معًا. أنها لا تعمل من هذا القبيل. لقد نمت قدرة التحسين تدريجياً ، وتتطلب الكثير من النمو. على أي حال ، دعنا نتحدث عن خلفية قاعدة البيانات. حسنًا ، هناك الكثير من الأمور التي تقال عن قاعدة بيانات NoSQL الآن ، وهناك الكثير من الحماس لقاعدة بيانات الرسم البياني. واستخدام SQL على Hadoop وأشياء من هذا القبيل. ولكن ، حقيقة الأمر هي أنه إذا كنت تريد قاعدة بيانات في الوقت الحالي ، أو إذا كنت تريد قاعدة بيانات كاملة الوظائف ، قادرة على OLTP وحركة مرور كبيرة للاستعلام ، فهي قاعدة بيانات علائقية ، أو لا شيء.

بين قواعد البيانات العلائقية ، أوراكل هي المهيمنة في الشعبية. Microsoft SQL Server ، في اعتقادي ، هو الثاني. كلاهما قادر على الاستخدام في OLTP والاستعلام عن عبء العمل ، ولكن في الواقع لا يمكنك التخلص من خلط أعباء العمل هذه. تحتاج إلى حوادث مختلفة لأحمال عمل OLTP واستعلام أعباء العمل. هناك بدائل SQL والرسم البياني. توحيد معظم الشركات على قاعدة بيانات واحدة محددة ، وهذا هو السبب - أعني بعد عقود من قتالها مع جميع اللاعبين الآخرين ، أصبحت أوراكل هي المهيمنة. ببساطة لأنهم انتهوا من بيع تراخيص الشركات ، وبالتالي فإن الشركات ستستخدم فقط المنتجات البديلة في منتجات استثنائية لن تفعلها أوراكل ببساطة. وقواعد البيانات هي استراتيجية في ذلك أيضا أنها تتطور. وأنت تعرف أنني قد أجريت القليل من البحث لهذا العرض التقديمي ، وهو نوع من - سآتي إليه في فترة من الوقت ، ولكن من المثير للاهتمام كيفية تطورها ، من حيث النظر إليها من موقع DBA. هذا ما أسميه الاتجاه غير المرئي. انها قانون مور مكعبة. يشبه هذا الأمر تقريبًا: أكبر قاعدة بيانات ، وقواعد بيانات جديدة ، لا توجد قاعدة بيانات قديمة تحتوي على الكثير من البيانات لاستيعابها. إنها عادة قاعدة بيانات يتم تطبيقها على مشكلة جديدة. وهي تنمو بالفعل من حيث وحدات تخزين البيانات. تقريبا في مكعب مور القانون. إذن قانون مور هو عامل عشر مرات كل ست سنوات. تميل VLDBs إلى زيادة معامل الألف كل ستة أعوام. في عام 1991 ، 1992 ، يتم قياس قواعد البيانات الكبيرة من حيث ميغابايت. في '97 و '98 ، غيغا بايت. 2003 ، 4 ، تيرابايت. 2009 ، '10 ، بدأت تشاهد قواعد بيانات بيتابايت. أعتقد أنه ربما كانت هناك قاعدة بيانات واحدة أو قاعدتي exabyte في الوقت الحالي ، ولكن أكبر ما سمعته هو 200 بايت في الوقت المحدد ، كما تعلمون ، لا تحصل على بيانات إلى قواعد بيانات بيتابايت. ولكن من الواضح أن معظم ذلك سيكون من الواضح أن شركات الويب 2.0 الكبيرة الجديدة ، ربما تكون قد حصلت على Facebook في هذا الاتجاه.

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

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

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

إريك كافانا: رايت ديز ، خذها بعيدًا.

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

في رأيي ، يأخذ الكثير من الأشخاص مقاربة حديدية كبيرة في ذلك ، ولدي صورة لـ The Flash هنا لأنه إذا سبق لك أن شاهدت أي أفلام قديمة أو بالتأكيد أحدث برنامج تلفزيوني مع The Flash ، كما في Flash Gordon الشخصية القديمة ، والآن بعد أن أطلق عليه "The Flash" ، يميل سريعًا جدًا وبلا طاقته تنفد. وهذا ما يحدث عند رمي الحديد الكبير في أداء قاعدة البيانات. دائمًا ، في تجربتي ، يمكنك وضع أداء عالي ، وعمل شاق في اللعبة ، ويمكنك تحسين أنظمة التشغيل الخاصة بك وضبطها إلى نقطة معينة. يمكنك التأكد من حصولك على وحدات متعددة وحدات المعالجة المركزية ذات مؤشرات سريعة سريعة لجعل التطبيق يعمل بشكل أسرع ، ويمكنك إلقاء الكثير من ذاكرة الوصول العشوائي عليه ، ويمكن أن يكون لديك شبكات اتصال خلفية عالية الإنتاجية ، ويمكنك الانتقال من محركات الأقراص الثابتة إلى التخزين المؤقت لمحركات الأقراص الثابتة إلى الحالة الصلبة ، ومجموعة تخزين عالية الأداء. وحتى الآن ، يلقي الأشخاص أشياء مثل flash و NVMe على محركات قاعدة البيانات الخاصة بهم ، معتقدين أنهم سيحصلون على مكاسب تسجيل الدخول هذه مرتين مكاسب في الأداء. ودائما ما يحصلون على بعض المكاسب. ولكن ، كل ذلك يعود إلى نفس مشاكل ضبط الأداء الأساسية. الكثير من اتصالات الشبكات منخفضة زمن الوصول ، بحيث تعمل المجموعات بسرعة. وبتجميع البنية التحتية لقاعدة البيانات ، لذلك لديك أكثر من جهاز واحد يقوم بكل العمل. لكنك تميل إلى العودة إلى نفس مشكلة الأداء الأساسية ، وهي قراءة البيانات. تعد كتابة البيانات ، في معظمها ، تحديًا خطيًا إلى حد ما وما لم يتم القيام به بشكل صحيح.

ثم لدينا التحدي في عالم اليوم: لا يتم إنشاء جميع قواعد البيانات على قدم المساواة. هناك قواعد بيانات و "قاعدة بيانات اقتباس" ، وعندما نفكر في محركات قاعدة البيانات ، غالبًا ما يفكر الناس في المشتبه بهم التقليديين المعتاد كما كانوا في عالم SQL. كما تعلمون ، لدينا Oracle و Microsoft SQL Server ، وهناك زوجان حوله في عالم مفتوح المصدر مع MySQL ، التي تملكها Oracle الآن ، لكنها لا تزال مفتوحة المصدر. ثم لدينا المشتبه بهم غير المعتادين ، محركات NoSQL ، التي لا تزال تواجه مشكلة حول الفهرسة وإدارة الأداء ، ولن أخوض فيها بتفاصيل كثيرة ، لكن هناك عددًا متزايدًا من هؤلاء تظهر الأشياء كل يوم وهي تبدو وتشعر وكأنها محركات قاعدة بيانات من وجهة نظر المطورين ومن وجهة نظر الأداء ، لكنهم وحوش مختلفة تمامًا ولديهم مكانة صغيرة خاصة بهم في العالم للنحت بها أداء في الذاكرة أو مقياس خطي على القرص. ولكن هذا هو ما يشبه العالم في عالم قاعدة البيانات. هذا هو عام 2016 ، هذا هو الإصدار الثالث من خريطة ، بواسطة مجموعة من الأشخاص الذين ينتجون هذه الخريطة الطبيعية المستمرة لما تبدو عليه قواعد البيانات ، وهذا هو المكان - حتى مهندس معماري لقواعد البيانات أو مسؤول قاعدة البيانات الخارقة للطبيعة يمكن أن يكون له معنى من ذلك. المئات ، والمئات ، والمئات من الماركات المختلفة ، النماذج ، الشركات المصنعة لقواعد البيانات ، متوافقة دائمًا مع SQL. والشيء المثير للاهتمام هو أنهم جميعا يعودون إلى نفس التحدي. ضبط الأداء والأداء حول مشغل قاعدة البيانات ، ولا سيما كيفية فهرسة البيانات.

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

بشكل عام عندما نتحدث عن فهرسة قاعدة البيانات ، هناك عدد من الطرق الشائعة. وكلما أصبحت فهارس قاعدة البيانات الأكثر تعقيدًا ، زاد تعقيد طريقة فهرسة البيانات. لكن عند التفكير في فهرسة البيانات بشكل أساسي - تخيل أن لدينا ملفًا يحتوي على قائمة بالأسماء ؛ قد لا يتم فرزها حسب الترتيب الأبجدي. دعنا نتخيل أن هناك عشرين منهم. إذا أردنا الفرز - إذا كنا سنبحث عن بيانات في تلك القائمة ، من الأعلى إلى الأسفل ، فلنفترض أنها قائمة بالأسماء. إذا اخترت اسمًا عشوائيًا وبدأت بالتمرير لأسفل تلك القائمة ، من أعلى إلى أسفل ، بتنسيق خطي وقائمة غير مرتبة ، فهناك معياران أفكر فيهما كمتوسط ​​وقت البحث وأقصي لوقت البحث - و لدي خطأ مطبعي في السطر الثاني ، يجب أن يكون "الحد الأقصى لوقت البحث" ، آسف - ولكن متوسط ​​وقت البحث الخاص بي هو في الأساس N زائد واحد ، مقسوم على اثنين ، وهذا في المتوسط ​​، يستغرق مني خمسين في المئة من الوقت للمسح الضوئي من أعلى القائمة ، إلى أسفل القائمة للعثور على أي شيء عشوائي في تلك القائمة. والخط الثاني هناك ، تحت الخطي ، يجب أن يكون "الحد الأقصى لوقت البحث". لكن الحد الأقصى لوقت البحث هو في الأساس عدد العناصر ، وهذا هو أنه إذا كان لدي قائمة بعشرين شيئًا ، فإن معظم الوقت الذي يمكن أن يستغرقه الأمر لي هو للبحث عن شيء ما في قاعدة البيانات تلك ، يجب الانتقال من الأعلى إلى الأسفل ، وهو ما يشير إلى 20 عنصرًا في هذا المثال المبسط. إنها عملية بطيئة للغاية وليس هناك طريقة لضبط الأداء. ثم ، هناك أنواع أخرى من طرق أخذ تلك البيانات وإنشاء فهرس ، وهي قائمة قصيرة من المؤشرات بشكل فعال إلى حيث توجد البيانات الفعلية ، مثل ثنائي ، B- شجرة ، صورة نقطية ، التجزئة ، متفاوت المسافات وغير متفاوت المسافات ، ثم هناك أنواع مختلفة من البيانات مثل المكانية ، المصفاة ، XML والنص الكامل.

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

عدد قواعد البيانات التي يتعين عليهم التعامل معها إما من نظام أساسي خاص مثل ERP أو HR أو نظام مالي ، أو ما إذا كانوا عبارة عن منصة منزلية الصنع لأسباب مختلفة ، وعدد قواعد البيانات وجداول قواعد البيانات والسجلات التي انتهى بنا المطاف بها التعامل مع الفلكية مجرد وأنت جسديا لا تستطيع أن تفعل ذلك باليد. ولدينا تعقيد إضافي الآن ، حيث قد يجلس خادم قاعدة بيانات ذات مرة تحت مكتبك. كما تعلمون ، عندما كنت طفلاً صغيراً بعد المدرسة ، اعتدت أن أذهب وأعمل في برنامج قاعدة البيانات على أنظمة Apple IIes ، ثم أنظمة DOS المستندة إلى جهاز الكمبيوتر الشخصي ، مثل dBase II ، dBase III ، مرت بحقبة تضم الحاسبات الكبيرة والمتوسطة. مجموعة وحتى VAXs و PDPs وملف السجل على ذلك. ومثل سيبر ، ثم في نهاية المطاف عندما جاءت بعض قواعد بيانات SQL. لكن في هذه الأيام عندما نفكر في محركات قاعدة البيانات ، فإنها تبدو كالزاوية السفلية اليسرى. لم يعد خادم قاعدة البيانات مجرد جهاز واحد يجلس على الأرض أسفل مكتب ؛ إنها المئات من الأجهزة التي تشغل نسخًا من محركات قاعدة البيانات والمجموعات ، وهي تعمل على زيادة حجم مئات ومئات تيرابايت من البيانات ، إن لم يكن بايتات البيانات ، والتي هي آلاف تيرابايت. وحتى إلى أقصى الحدود ، كما ذكر الطبيب روبن بلور ، فإن بعض حالات الاستخدام المحددة - شركات الطيران والوكالات الحكومية على وجه الخصوص - يمكن أن تصل إلى exabytes. لا تزال هذه الفئة مناسبة إلى حد ما ، لكن مئات تيرابايت وحتى عشرات البيجابايت لم تعد غير معتادة ، خاصة منذ طفرة الدوت كوم حتى الآن ، نوعًا ما نسميه شركات الويب 2.0 ، مثل Facebook و Google و Yahoo وهكذا دواليك.

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

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

بيرت سكالزو: شكرًا لك. مرحباً بالجميع ، اسمي بيرت سكالزو ، أعمل لدى IDERA. أنا كبير مديري المنتجات لبعض منتجات قواعد البيانات الخاصة بنا. سأعرض بعض هؤلاء اليوم. لكنني أريد أن أتحدث عن الفهارس ، لأنني أتفق مع كل ما قاله الجميع هنا ، خاصة الشريحة الأخيرة ، أن الفهارس معقدة للغاية الآن وتحتاج إلى أداة ، وآمل أن أقنعك. لذلك ، تصميم فهرس Oracle ، ليس سهلاً كما كان في الأيام الخوالي. الكثير من الناس لن يكونوا متأكدين من أنفسهم عندما ينظرون إلى الخيارات ، وأنا أحب هذا القول بأنني انسحبت من التاريخ ، "في هذه الأمور ، اليقين الوحيد ، هو أنه لا يوجد شيء مؤكد." تشعر بفهارس هذه الأيام ، لأنه حتى لو كنت تعتقد أنك تعرف أن إجابتك يجب أن تفهرس X أو Y أو Z ، فأنت لا تستطيع أن تكون متأكدًا حتى تقوم بتجربتها ، لأن هؤلاء المحسنون يتصرفون في بعض الأحيان بطريقة مختلفة عن الطريقة التي تتوقعها. وبالتالي هناك الكثير من التجربة والخطأ في تصميم الفهرس. الآن ، في الأيام الخوالي ، إذا كنت بحاجة إلى فهرس ، كان هناك عمومًا سؤالان فقط ، أو سؤال واحد. هل كانت فريدة أم أنها ليست فريدة من نوعها؟ وربما فكرت في أشياء أخرى مثل ، "كم عدد الفهارس التي يمكنني الحصول عليها كحد أقصى في جدول واحد؟" لأن الكثير من الفهارس تبطئ إدخالاتك وتحديثاتك وحذفك. قد تكون أيضًا في نظام قاعدة البيانات لديك ، وكان لديك قيود على عدد الأعمدة التي يمكن أن تكون في فهرس متعدد الأعمدة ، لأنه في بعض الأحيان كانت هناك حدود بناءً على الصفحة أو حجم كتلة محرك قاعدة البيانات الخاص بك ، ولكن في الواقع كان الأمر بسيطًا جدًا في الايام الخوالي إما فهرستها أو لم تفعل ذلك. وفي الحقيقة ، كان كل شيء في شجرة ب. يمكن أن نسمح التكرارات أم لا ، وكان ذلك حول هذا الموضوع. كانت الحياة جيدة ، كانت الحياة بسيطة.

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

إذا كنت سأضع طاولتي في كتلة ، فسوف يتعين علي امتلاك فهرس مجمع على ذلك الجدول. الآن ، في Oracle ، عندما تقوم بتجميع جدول ، كنت تقوم بشكل أساسي بتخزين الصفوف أو كانت الصفوف قريبة من بعضها البعض حيث كانت القيم متشابهة. وهكذا ، يجب أن يكون لديك فهرس متفاوت المسافات ويمكن أن يكون هذا الفهرس المجمع غير مقسم. بمعنى آخر ، لم تكن هناك بالفعل أي طرق تقسيم لكيفية القيام بجدول متفاوت المسافات. كان غير مقسم بدقة. ولأنه لم يتم تقسيمه ، فقد كان عالميًا. سأشرح ما هو عالمي في دقيقة واحدة. وكان دائما B شجرة. بعبارة أخرى ، عندما ذهبت إلى هذا الفرع ، كان الأمر بسيطًا للغاية ، ولم يكن لدي الكثير من الخيارات. الآن ، إذا قمت بعمل فهرس غير متفاوت المسافات على جدول متفاوت المسافات ، والذي كان مسموحًا به في بعض الإصدارات ، فقد تم تقسيمه مرة أخرى ؛ عندما لا يتم تقسيمها ، يكون خيارك الوحيد عالميًا. وهكذا ، يوجد لديك خيار B-tree أو الصورة النقطية. مرة أخرى ، كان يعتمد على إصدار قاعدة البيانات الخاصة بك. لكن الآن ، دعنا نعود إلى الطاولة العلائقية ونبدأ في النزول إلى الجانب الأيمن مرة أخرى والآن سيكون لدينا فقط جدول عادي ، قديم ، منتظم ، مكدس: علائقي. سيكون في مساحة الجدول. أنا نوع من النزول في الجانب الأيمن هنا أولاً. لذلك التنظيم ، كومة. السؤال التالي الذي يجب علي طرحه على نفسي هو: "هل أريد تقسيم هذا الجدول أم لا؟" الآن ، في بعض الأحيان تقوم بالتقسيم لأنك تعتقد ، "مهلاً ، سيكون المحسن أكثر ذكاءً حول كيفية تحسين الاستعلامات. لكن سيخبرك الكثير من DBAs أن السبب وراء قيامك بذلك هو لأغراض إدارية. إذا كان لديك جدول بمئات المليارات من الصفوف ، إذا قسمته إلى أقسام أو مجموعات ، عندما تريد إضافة بيانات إلى المجموعة الأخيرة ، فيمكنك إسقاط وفهرسة بضعة ملايين من الصفوف. يمكنك إدراج تلك البيانات وبعد ذلك يمكنك إعادة بناء هذا الفهرس على ذلك الجرد.

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

والواقع أن هذا قد حدث بسبب Red Brick ، ​​التي كانت قاعدة بيانات منذ عدة سنوات - قد يتذكرها الكثير من الناس. وهكذا ، إذا نظرت إلى هذه الصورة - وتذكر أني لم أضع كل شيء في هذه الصورة لأن الصورة ستكون أكبر بكثير - لا تزال هناك مشكلات إضافية ، لدي نص في هذا الجزء العلوي الأيمن . هل هو مؤشر الترتيب العكسي؟ وقد تقول ، "لماذا أريد مؤشر ترتيب عكسي؟ هذا لا معنى له على الإطلاق. "حسنًا ، إذا كنت في بيئة مجمعة في Oracle ، إذا كنت تقوم بتجميع مجموعات تطبيقات حقيقية ، إذا احتفظت بالفهارس بالترتيب ، بحيث لا يتم عكسها ، إذا كان لديك الكثير من المعالجة التي تصل إلى نفس القيم أو نفس قيم الفهرس ، ماذا سيحدث ، سيكون لديك مناطق ساخنة من شجرة B الخاصة بك. وهذا يعني أنه سيكون لديك خلاف وربما تأمين لمحاولة الوصول إلى هذه الأشياء ، وكنت تفعل ذلك عبر العقد في الشبكة. حسنًا ، إذا وضعت فهرسًا عكسيًا ، يمكنك الآن التراجع عن ذلك. يمكنك أن تقول ، "حسنًا ، القيم المتشابهة موجودة في أجزاء مختلفة من الأشجار ، لذلك ليس لديّ عقدتي المنفصلة تتنافس على المناطق الساخنة في الشجرة". ثم لاحظ أيضًا أن الفريدة لا تعمل مع بعض الخيارات . إذا نظرت ، فقد قمت بعدد ثلاثة وخمسة وثمانية عشر والحادية عشر ، لذلك هناك بعض الحالات التي لا يمكنني فيها الحصول على فهرس فريد. وبالمثل ، هناك بعض الحالات التي لا يمكنني فيها امتلاك فهرس عكسي ، ثم هناك مشكلات إضافية مثل التسجيل أو عدم التسجيل ، ومتوازية وغير متوازية. يمكنني تعيين أشياء إلى منطقة معينة في الذاكرة.

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

على سبيل المثال ، إذا كنت تريد أن تأخذ جدول معاملات ، وتضع فهارس الصور النقطية على جدول معاملات ، فمن المكلف حساب الصور النقطية وإعادة تعيينها ، هذه السلاسل الطويلة ، وهكذا في جدول OLTP ، قد تضغط على الجدول بشدة بحيث تصبح الصورة النقطية كبيرة يمكن أن يصبح الفهرس تالفًا ويبطئ نظامك نظرًا لأنها ليست مخصصة للتحديثات. إنها رائعة للوصول السريع ، ولكنها ليست جيدة للتحديثات. أعتقد أن مؤشر يأخذ المحاكمة والخطأ. لم يعد هناك قاعدة ذهبية بعد الآن - فهناك العديد من المتغيرات المختلفة في هذه المعادلة التي يجب معرفتها - وفي النهاية سيتعين عليك النظر في التنفيذ أو شرح الخطط في قاعدة بياناتك لمعرفة ما إذا كنت تقوم بتحديدات جيدة أم لا. وفي بعض الأحيان ، يمكن أن يكون تحليل الخطة علمًا بحد ذاته. لن أغطي ذلك اليوم - هذا موضوع آخر - لكن لا أعتبر تصميم الفهرس أمرًا مفروغًا منه. هناك أسباب وجيهة وراء وجود كل أنواع الفهرس المجنون التي عرضتها عليك في الصورة السابقة وتحدث عنها المتحدث السابق. لم يتم إنشاء هذه فقط لأنها كانت ميزة أنيقة لوضعها على قائمة مرجعية في مكان ما لبائع قاعدة البيانات ؛ هناك حالات استخدام أو سيناريوهات تكون فيها هذه الفهارس مهمة وستحدث فرقًا كبيرًا. الآن مع ذلك ، سأريك بعض الأمثلة لأنواع مختلفة من الفهارس في إحدى أدواتنا. اسمحوا لي فقط الحصول على شاشتي حتى تتمكن من رؤيتها. حسنًا ، لذلك أنا هنا جالسًا داخل - دعني أقلل من هذا التطبيق. أنا جالس داخل VMware وأقوم بتشغيل Windows Server 2012 VM.

ويمكنك أن ترى ، لدي كل أداة معروفة للإنسان. بصفتي مديرًا للمنتج ، يجب أن أبقى على دراية بالمنافسة ، لذا فهي ليست فقط الأدوات التي لديّ ، ولكن ما الذي يفعله المنافسون؟ ولدينا هذه الأداة هنا تسمى DBArtisan ، والتي قمت بتشغيلها بالفعل ، لكنني ذاهب - لذلك سأقوم بإحضارها. وما يمكنك رؤيته هو أن هذه أداة رائعة حقًا ، لأنه بدلاً من الاضطرار لاستخدامها ، يقول مدير مؤسسة لـ Oracle و SQL Management Studio لـ SQL Server ، و MySQL Workbench for MySQL ، و 12 قاعدة بيانات أخرى ندعمها ، حسنًا ، لدي كل قواعد البيانات الخاصة بي المدمجة في هذه الأداة الواحدة. هناك DB2 ، وهناك MySQL و Oracle و Postgres و SQL Server و Sybase ، وهذا - لدي ستة قواعد بيانات فقط في هذا الشيء بالذات لأنني لا أستطيع - تدعم الأداة اثني عشر قاعدة بيانات لكن نظام VM الخاص بي سيئ ، وتشغيل ست قواعد بيانات متزامنة ، ومحاولة للقيام بالعرض التوضيحي ، فهو يساوي قدر ما ستسهل أجهزتي. لذا ، دعني أعود إلى Oracle الآن ، وإذا لاحظت ، كل هذه الأشياء متشابهة. إذا كنت أرغب في قياس أدائي في DB2 ، فهذه هي نفس الخيارات التي أختارها في Oracle. الآن تحت الأغطية ، نقوم بالكثير من الأشياء المختلفة ، لذا لن تضطر إلى معرفة ما يجري ، لكننا نقدم لك واجهة متسقة حتى تتمكن من أن تكون خبيرًا في العديد من منصات قواعد البيانات. وهذا يشمل العمل مع الفهارس ، موضوع هذه المناقشة.

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

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

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

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

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

الآن يعمل الضغط فقط على فهرس B-tree. ما يسمح به هو ، عندما تنظر إلى العقد المختلفة في شجرة B ، فإنه يسمح بضغط بعض القيم. إنه في الواقع ليس ضغطًا مثل ضغط الجدول ، إنه ضغط لما يتم تخزينه في شجرة B في العقد غير الورقية. لا يوفر الكثير من المساحة ، ولكنه قد يحدث فرقًا. ومع ذلك لاحظت ذلك ، لقد اقتربت كثيرًا من الوقت ، لذا فإن ما أريد القيام به هو ، وأريد العودة ، وأوقف مشاركتي. ولدينا منتجنا هناك لفترة تجريبية مدتها أربعة عشر يومًا على idera.com. إنه منتج جيد جدًا ، خاصةً إذا كنت تعمل مع منصات قواعد بيانات متعددة. إذا كنت تعمل مع اثنين أو ثلاث قواعد بيانات مختلفة ، فإن هذه الأداة سوف تجعل حياتك أسهل بكثير. لدينا أدوات لمساعدتك في تصميم الفهرس والاختيار ، ولدينا أداة تسمى DB Optimizer. لم أستطع تغطية ذلك اليوم ، سيكون ذلك كثيرًا. وإذا كنت ترغب في الاتصال بي ، فهناك عنوان بريدي الإلكتروني ، أو يمكنك أن تصطحبني على بريدي الإلكتروني الخاص ، ولدي مدونات ، ولدي موقع إلكتروني ومدونات وملف LinkedIn على LinkedIn. لذا لا تتردد في التواصل معي بشأن أي شيء ، حتى لو لم يكن متعلقًا بالمنتج ، إذا كنت تريد فقط التحدث بقواعد البيانات ، فأنا أميل إلى قلبه وأحب أن أتعجب من technobabble.

إريك كافانا: حسنًا ، حسنًا ، ديز ، روبن ، أنا متأكد من أنك حصلت على سؤالين على الأقل ، لقد بقي هنا بضع دقائق. ديز ، ما رأيك؟

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

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

ديز بلانشفيلد: نعم ، إنه من المثير للاهتمام عدد المرات التي واجهتك فيها ، وأعتقد أن التحدي مع قواعد البيانات ، ينسى الناس أنه علم. وهناك أشخاص يحملون شهادات ودكتوراه في هذه المساحة بالكامل ، ويكتبون أوراقًا عليها ، وقد كتبت مجموعة غنيمة كاملة بما في ذلك كتيبات TOAD وأشياء أخرى من الذاكرة. الاتجاه نحو نوع من "البيانات الضخمة" ، على أساس الاقتباس الآن - أرى الكثير من الناس ينسون أساسيات بنية قاعدة البيانات وتكنولوجيا قواعد البيانات ، وعلوم قاعدة البيانات ، إذا أردت. ما الذي تراه في هذا المجال بقدر ما يتعلق الأمر بالانتقال من منصات قواعد البيانات التقليدية والتفكير في قواعد البيانات التقليدية التي قمنا بها بفعالية على الأرض ، وكانت مجرد حالة من ضبط الأداء وتوسيع نطاقه. هل ترى الكثير من الناس يتعلمون ولديهم تجربة حيث يجلسون هناك فقط ولديهم لحظة "a-ha" ، مثل لحظة eureka ، حيث يدركون ، أن هذه البيانات الضخمة هي في الواقع مجرد نوع من قواعد البيانات الكبيرة حقًا؟ هل هذا شيء هناك والناس يردون عليك ونوع من ذلك ، "لقد نسينا ، ما عرفناه وهل يمكنك إعادتنا من الجانب المظلم؟"

بيرت سكالزو: حسنًا ، لا ، وهذا أمر فظيع أن نعترف به ، لكن بائعي قواعد البيانات العلائقية شربوا ذلك Kool-Aid أيضًا. إذا كنت تتذكر ، لا أعرف ، منذ حوالي عقد من الزمان ، فقد بدأنا في وضع بيانات غير منظمة في قواعد البيانات العلائقية ، والتي كانت شيئًا غريبًا ، ثم البيانات ، قواعد البيانات العلائقية ، تضيف الآن نوع NoSQL أمور. في الواقع ، في Oracle 12 ، CR2 - أعرف أنه لم ينته بعد - ولكن إذا نظرت إلى الإصدار التجريبي ، إذا كنت في برنامج beta ، فهو يدعم المشاركة. وهكذا ، لديك الآن قاعدة بيانات علائقية لم تتم إضافة المفهوم من مشاركة NoSQL. وهكذا ، يبدو أن لحظة "a-ha" هي أكثر بالنسبة للأشخاص من الجانب العلائقي الذين يقومون بـ "a-ha". لا أحد سيفعل ذلك بشكل صحيح مرة أخرى ، ولا حتى مديري قواعد البيانات ، لذلك قمنا حصلت على الذهاب والانضمام إلى الجانب المظلم.

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

بيرت سكالزو: لا ، عادة ، إذا كانت لديهم حاجة في ذلك - كان يمكن أن يقتبس ذلك "حاجة كبيرة من نوع البيانات" ، فإنهم يجدون ذلك بدلاً من الذهاب إلى منصة قاعدة البيانات الأخرى والقيام بشيء في بطريقة-علائقية ، يمنحها الآن موردو قواعد البيانات نفس التقنيات غير العلائقية داخل قاعدة البيانات العلائقية الخاصة بهم ، للقيام بهذه الأشياء. أعني ، مثال جيد على ذلك ، إذا كان لديك بيانات غير منظمة ، مثل نوع بيانات JSON أو بعض أنواع البيانات المعقدة الأخرى التي لها معنى مضمن في البيانات نفسها ، فإن موردي قواعد البيانات لا يدعمون ذلك فحسب ، ولكنهم سيعطونك ACID الامتثال للبيانات غير المهيكلة. لقد احتضنت قواعد البيانات الترابطية التقنيات والتقنيات الأحدث ، وهكذا ، يبدو أن "a-ha" ليست أكثر من ذلك ، "يا نحن ، مطورو التطبيقات ، لقد تخلصنا من شيء ونحن بحاجة إلى تعلمه مرة أخرى" ، إنه "يا ، ونحن نفعل ذلك بهذه الطريقة الآن ، كيف يمكنني أن أفعل ذلك بهذه الطريقة في قاعدة البيانات العلائقية التقليدية الخاصة بك ونفعل ذلك كما أفعل في قاعدة البيانات هذه هنا؟ "وهذا أصبح أكثر انتشارًا ، وكما قلت ، يمكّن بائعو قواعد البيانات أنفسهم أن.

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

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

ديز بلانشفيلد: نعم ، أعتقد ، أن الناس يرغبون في الحصول على مزيد من الضجة من أجل مواردهم البشرية. وقد ولت أيام وجود متخصص فردي في Oracle و Ingres و DB2. من المتوقع أن يكون الأشخاص هم جاك جميع المهن ، لذلك أعتقد أن هذا الشيء أنقذ حياتهم تمامًا.

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

بيرت سكالزو: أي بيئة ويندوز ، لذلك ويندوز 7 ، الجهاز الظاهري مع وحدة المعالجة المركزية واحد وأربعة العربات من الذاكرة. نحن لسنا حقا أداة الدهون أو باهظة الثمن. الآن إذا كنت ترغب في تشغيل خادم قاعدة البيانات الخاصة بك على نفس VM ضمن نفس نظام Windows ، نعم ، ستحتاج إلى إضافة المزيد ، ولكن إذا كنت تقوم بتشغيل قاعدة البيانات الخاصة بك على خادم قاعدة بيانات أو VM منفصل ، فإن VM يتم تحميله و تشغيل منتجنا خفيف الوزن للغاية: وحدة المعالجة المركزية واحدة ، وأربعة العربات من الذاكرة ، إلى حد كبير أي إصدار من Windows - ونحن ندعم كل من تثبيت اثنين وثلاثين وأربعة وستين بت. ولكن عليك تثبيت عميل بائع قاعدة البيانات الخاصة بك. لذلك ، إذا كنت ترغب في الاتصال بـ Oracle ، فعليك تثبيت عميل SQL net ، لأن هذا ما تتطلبه Oracle حتى تتمكن من التحدث إلى قاعدة بيانات.

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

روبن ، أنا متأكد من أنك تلقيت أسئلة وإريك ، وربما حصلت على بعض من الحضور ، لذلك روبن ، ماذا عني ، ثم أعود إلى إريك؟

روبن بلور: نعم ، حسنًا ، حسنًا لدي أشياء لأقولها ، أقصد ، لقد وجدت دائمًا هذه المنطقة رائعة لأنها كانت - قمت بقطع أسناني عليها. ولكن الحقيقة ، ربما منذ حوالي عام 1998 ، 1999 ، لقد كنت على وشك ما أوراكل هو في الواقع قادرة على. وكنت أعرف Sybase و Microsoft SQL Server ، كلاهما بسيط إلى حد ما مقارنة بما يمكن أن يفعله Oracle. لقد ضحكتني عندما كنت - أقصد ، غطيت فمي ، عندما بدأت تتحدث عن التقسيم. فعلت أوراكل هذا من قبل. أدخلت شركة أوراكل في مرحلة ما من الزمن ، فقد شعروا بالقلق من فكرة العلاقة بين الكائنات ، ولذا فقد قدموا القدرة على إنشاء نوع من تدوين الأشياء وتخزين الأشياء في أوراكل ، وتحدثت مع أحد مهندسيهم ، وهو ما يشبه زوجين بعد سنوات من تقديمه وسألته عن عدد الأشخاص الذين استخدموه ، وقال إنني أعتقد أن اثنين من العملاء قاموا بتجربته وكان هذا هو الأمر. وأعتقد أن نفس الشيء سيحدث إذا بدأوا في محاولة القيام بأشياء NoSQL. أنت تعرف ، أعتقد أنه خطأ ، أعني ، أنا مهتم بماهية أفكارك. بالتأكيد ، - يشربون كوول إيد. يشعرون كما لو أنهم يجب أن يكونوا قادرين على تقديم مطالبات مماثلة لقواعد بيانات NoSQL الكبيرة مثل Cassandra ، لكنك تعلم ، هل هذا منطقي بالنسبة لك؟

بيرت سكالزو: لا ، لقد أصبت الظفر على رأسك. بالنسبة لي ، إذا كنت سأقوم بالعلاقة ، فسوف أختار بائعًا علائقيًا مثل Oracle أو SQL Server أو DB2 أو Postgres ، لكن إذا كنت سأقوم بشيء غير علائقي ، في مساحة البيانات الكبيرة ، أو مساحة NoSQL ، سأختار الأداة المناسبة للوظيفة المناسبة. ولا أظن أن ذلك سيذهب بشكل طبيعي إلى بائع قواعد البيانات العلائقية أولاً. وبعد ذلك ، يمكنك إضافة التجاعيد الأخرى إليه ، ما هو متوفر في السحابة؟ الكثير من الناس الذين يريدون الحصول على قواعد البيانات الخاصة بهم قبالة فرضية. ثم عليك أن تنظر إلى موفر الخدمة السحابية الخاصة بك وتقول ، "حسنًا ، ما الذي توفره ، وما هي قواعد البيانات المتاحة لديك التي تناسب احتياجاتي وكيف يمكن بيعها ، وبصراحة ما هو معدل أو تكلفة استخدام قاعدة البيانات تلك في السحابة في الساعة ، أو في اليوم الواحد. وكل غيغابايت أو تيرابايت؟ "وما ستجده ربما يكون بعض قواعد البيانات الأحدث نسبيًا مثل Mongo أو Cassandra ، وربما تكون أسعارها أرخص ، لذلك إذا كنت ستقوم بعمل بيانات كبيرة متعددة الأنواع ، فقد يجب أن - من وجهة نظر التكلفة - يجب أن تأخذ في الاعتبار قواعد بيانات NoSQL في السحابة لأنها قد تكون أكثر الطرق فعالية من حيث التكلفة للقيام بذلك.

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

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

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

بيرت سكالزو: بالتأكيد . ويجب أن أضحك ، لأنني بدأت بالعودة قبل قواعد البيانات العلائقية والعودة عندما كان إنجرس RTI ، معهد Relational Technology Institute ، ولم يكن لدينا لغة SQL ، كان لدينا لغات مترابطة قبل SQL. أعتقد في Ingres ، في ذلك الوقت ، كان يطلق عليه Quel. إذن ، لقد حصلت على نماذج قواعد البيانات القديمة مثل الشبكة وأعلى الرسومات أو التسلسل الهرمي ، وتتعرف على النماذج العلائقية بعد عقدين من الزمان والآن ، يبدو لي وكأننا عدنا إلى تسلسل هرمي تقريبًا مرة أخرى. انها تقريبا مثل لقد عدنا.

روبن بلور: نعم ، صحيح. من الأفضل تسليمك إلى Eric ، فأنا أستهلك الكثير من الوقت ، لكن هل تلقينا أي أسئلة من الجمهور ، Eric؟

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

بيرت سكالزو: هذه فكرة جيدة.

إريك كافانا: سؤال فضولي أيضًا ، لذا لمعلوماتك فقط.

بيرت سكالزو: لا ، ليس عليك أن تمتلك أدواتنا. هذه ميزة أوراكل ، فهرس غير مرئي. بشكل أساسي في قاموس البيانات ، يحتفظ Oracle فقط بجزء من البيانات الوصفية يقول "Optimizer ، تجاهل هذا الفهرس. إنه هنا ، ولكن ما لم يتم توجيهك فعليًا من خلال تلميح في ، تلميح محسن في أمر SQL ، لا تستخدم هذا. "وهكذا ، لا ، لا يلزم أن يكون لديك أدواتنا ، وفي كل النواحي هو مؤشر قديم بسيط ، ويمكنك رؤيته في أي أداة ، إنه فقط المحسن الذي سيقول ، "سوف نتجاهله في معالجة الاستعلام العادية". يجب عليك توجيهه إذا كنت تريد استخدامه. إنه مفيد حقًا للسيناريو الذي وصفته وهو ، إذا أردت إنشاء فهرس في الإنتاج ولكن لا تخاطر بكسر التقارير أو الأشياء التي تعمل بالفعل ، لكنك أردت اختبارها ، يمكنك القيام بذلك. هذا هو الشيء الأكثر فائدة ل.

إريك كافانا: هذه أشياء جيدة ، ثم كان هناك سؤال جيد آخر هنا. "ماذا عن بعض قواعد البيانات الجديدة هذه في الذاكرة؟ كيف تغير تكنولوجيا قواعد البيانات في الذاكرة اللعبة فيما يتعلق بالفهرسة؟ "

بيرت سكالزو: حسنًا ، حسنًا - الآن هذا أمر جيد ، أنا سعيد لأن شخصًا ما طرح هذا السؤال ، فسوف يتعين علينا الذهاب نصف ساعة أخرى. لا ، في الذاكرة ، فإنه يعتمد على بائع قاعدة البيانات. الآن ، عادةً ، أنا لا أتحدث إلا عن الثناء على أي شيء تفعله Oracle لأنه من المدهش التكنولوجيا التي قاموا بإنشائها ، ولكن عندما تمزق تحت الأغطية وأنت تنظر إلى ما يوجد في Oracle في Oracle ، في Oracle قاعدة البيانات ، ما هي عليه في الواقع هي أنه لا يزال يحتفظ بمخزن للصف على القرص ، وسوف يتم تحميله في مخزن الأعمدة بالذاكرة ، وإذا كانت هناك ذاكرة غير كافية للاحتفاظ بالجدول بأكمله ، فسوف تعود إلى الأجزاء ؛ لن يتلاءم مع الذاكرة ، وللقيام بذلك في متجر للصف ، ومن ثم يمكنك فعل ذلك تحديد مقابل الجدول وبالنسبة لنصف الجدول ، فأنت تستخدم فهرسة تضرب الصفوف التقليدية على الطاولة ، وللنصف الآخر من حدد أنه في الواقع ينطلق ويستحوذ فقط على كل شيء من البحث في الذاكرة ، وهكذا ، فهو مختلف في الطريقة التي يقوم بها SQL Server ، على سبيل المثال ، بتطبيقه باستخدام تقنية Hekaton ، كما تعلمون ، و SQL 2014 ، وقد تم تحسينه في SQL 2016 ، ولكن في بعض النواحي ، يكون إصدارهم أكثر صدقًا من الذاكرة ، ولكن كل تطبيق له إيجابيات وسلبيات ، لكن عليك أن تبحث نوعًا ما تحت الأغطية وأدرك. لأنه ، كان لدي عميل قال: "يا هذا الجدول في الذاكرة - سأقوم فقط بصياغة جميع الفهارس" ، وأنا معجب ، "الجدول أكبر من الذاكرة الموجودة على الخادم ، لذلك في مرحلة ما ، وصل بعض الاستعلام إلى القرص ".

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

شريك محتوى Techopedia

يرتبط موظفو Techopedia بـ Bloor Group ويمكن الاتصال بهم باستخدام الخيارات الموجودة على اليمين. للحصول على معلومات حول كيفية عملنا مع شركاء الصناعة ، انقر هنا.

• الملف الشخصي
• موقع الكتروني