it-swarm.asia

لماذا لا تستطيع قواعد البيانات الارتباطية تلبية مقاييس البيانات الضخمة؟

غالبًا ما يتكرر أن مشكلة البيانات الكبيرة هي أن قواعد البيانات العلائقية لا يمكنها التوسع في معالجة الأحجام الضخمة من البيانات التي يتم إنشاؤها الآن.

ولكن ما هي قيود قابلية التوسع التي لا تلتزم بها حلول البيانات الضخمة مثل Hadoop؟ لماذا لا يمكن لـ Oracle RAC أو MySQL Sharding أو MPP RDBMS مثل Teradata (إلخ) تحقيق هذه المفاخر؟

أنا مهتم بالقيود التقنية - أدرك أن التكاليف المالية لتجميع RDBMS يمكن أن تكون باهظة.

17
Jeremy Beard

كان لدى MS للتو حديث تقني في هولندا حيث ناقشوا بعض هذه الأشياء. يبدأ ببطء ، لكنه يدخل لحم Hadoop حول علامة 20 دقيقة.

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

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

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

15
Dave Markle

شارك رائد قاعدة البيانات والباحث مايكل ستونبراكر في كتابة ورقة تناقش قيود بنية قواعد البيانات التقليدية. بشكل عام ، تتطور هذه الأجهزة بمعدات أكثر تكلفة ، ولكنها تواجه صعوبة في التوسع بمزيد من أجهزة السلع الأساسية بالتوازي ، وهي محدودة ببنية البرامج القديمة التي تم تصميمها لعصر أقدم. ويؤكد أن عصر BigData يتطلب العديد من بنيات قواعد البيانات الجديدة التي تستفيد من البنية التحتية الحديثة وتحسين عبء العمل المحدد. ومن الأمثلة على ذلك مشروع C-store ، الذي أدى إلى قاعدة البيانات التجارية Vertica Systems ، ومشروع H-store الذي أدى إلى VoltDB ، ذاكرة داخلية OLTP قاعدة بيانات SQL مصممة لسرعة عالية أعباء عمل BigData. (الكشف الكامل ، أعمل لـ VoltDB).

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

6
BenjaminBallard

ليس صحيحًا تمامًا أن RDBMS لا يمكنها التوسع. ومع ذلك ، تعتمد الحقيقة الجزئية في البيان على الهندسة المعمارية. في القائمة التي قدمتها ، يختلف Oracle RAC عن البقية (MySQL و Teradata). والفرق الرئيسي هو القرص المشترك مقابل البنى المشتركة.

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

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

5
sunil