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

Question

كنت فقط أعتقد أنه الآن شائع الحصول على ما يكفي من ذاكرة الوصول العشوائي على خادم قاعدة البيانات الخاص بك لتخزين قاعدة البيانات الكاملة الخاصة بك لماذا المتخصص في قاعدة بيانات الذاكرة (على سبيل المثال Timesten, ، أنظر أيضا صفحة ويكيبيديا) التي كانت كل الغضب قبل بضع سنوات لم يتم استخدامها أكثر؟

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

أنا أسأل هذا ، لأنني قرأت للتو على بنية التداول والصفحة تقول الصفحة

هذا أمر مهم لأن قاعدة بيانات Stack Overflow بالكامل تقريبًا في ذاكرة الوصول العشوائي ولا تزال الندوات عالية التكلفة.

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

لكننا ما زلنا بحاجة إلى قاعدة بيانات ، كما تفعل

• قفل
• الكشف عن طريق الجمود
• تسجيل المعاملات
• التعافي
• إلخ

من الصعب جدا.

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

(من غير المرجح أن أستخدم Timesten بنفسي ، لأنها عالية السعر (41،500.00 دولار / معالج) وأنا لا أحب التحدث إلى موظفي Oracle Sales - أفضل قضاء وقتي في كتابة الكود.)

أنظر أيضا:

• بديل عن Timesten في قاعدة بيانات الذاكرة
• هل نشر أي شخص مقارنة مفصلة بين RDBMSS المختلفة في الذاكرة?

تحديث:

سألت هذا السؤال أ طويل منذ زمن ، هذه الأيام خادم Microsoft SQL "في الذاكرة OLTP"هذا محرك قاعدة بيانات محسّن للذاكرة مدمج في محرك SQL Server. إنه ليس رخيصًا ، ولكن يبدو أنه سريع جدا لبعض أعباء العمل.

Answer 1

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

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

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

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

Answer 2

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

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

بالنسبة لـ #1 ، فكر في دليل التلفزيون في مربع الإعداد الخاص بك (STB). STB منخفضة (أي أولئك الذين لديهم قدرة DVR) ليس لديهم تخزين مستمر ، ولا تحتاج إلى تخزين مستمر. لكن قاعدة البيانات لدليل تلفزيوني مدته 400 قناة لمدة 14 يومًا غير تافهة. هناك متطلبات أداء هنا أيضًا ، لأن البيانات تصل من Carousel المستجيب بسرعة عالية وهي حالة من "التقاطها أو الانتظار حتى تأتي الكاروسيل مرة أخرى". ولكن ليست هناك حاجة إلى الثبات. لقد رأينا جميعًا هذا ؛ عندما تفقد الطاقة في منزلك ، عندما يعود إلى دليل التلفزيون ، يقول "سيكون متاحًا قريبًا" لأنه يوفر نفسه من مستجيب أو نهاية الكابل. تشترك أجهزة توجيه الشبكة في نفس الخصائص: لا توجد تخزين مستمر ، وتحتاج إلى أن تكون سريعًا ، ويمكن توفير قاعدة البيانات من مصدر خارجي (أجهزة توجيه الأقران على الشبكة ، في هذه الحالة ، لإعادة توزيع جدول التوجيه).

هناك أمثلة لا نهاية لها عن رقم 2: الاستهداف في الوقت الفعلي في النظم العسكرية ، وأنظمة التداول عالية التردد ، وأكثر من ذلك.

فيما يتعلق بالجزء الثاني من السؤال ، "قضية الانتباه إلى": هناك الكثير.

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

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

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

Answer 3

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

لا تزال هناك قواعد بيانات في الذاكرة حولها ويتم استخدامها ، لكن ذلك يعتمد على السياق الذي تريد استخدامه. sqlite على سبيل المثال ، غالبًا ما يستخدم كقاعدة بيانات في الذاكرة عند اختبار طبقات البيانات.

Answer 4

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

كسب Microsoft و Oracle الكثير من المال من خلال منتجات قاعدة البيانات الخاصة بهم لجعلها (سياسيا) ممكنة لهم للتوصل إلى مقاربات أفضل.

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

Answer 5

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

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

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

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

Answer 6

هذا أيضًا خيار: http://www.memsql.com/

لم أستخدمها شخصيًا ، لكن من المفترض أن تكون على غرار بديل للاستبدال في الذاكرة MySQL.

Answer 7

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

sqlite

إصدار SQL Server Compact

هذه مجرد لاعبين كبار قد تكون هناك خيارات أخرى ، لكن اللاعبين الكبار يتعاملون مع الحد الأدنى من المتطلبات مع إطلاقها .. :)

وفي قاعدة بيانات الذاكرة ، يمكنك دعم البيانات باستمرار في حالة ظهور تقلبات أو PowerCut ، يمكنك فقدان المجموعة بأكملها. كما هو الحال في أخرى سيتم التعامل معها في الذاكرة الثانوية (HDD) وستكون فرص الخسارة 10 ٪ مقارنة مع الذاكرة DB.

آمل أن هذا قد يساعد :)

Answer 8

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

يبدو أن الخيارات الشائعة في هذا المجال هي RavendB لمطوري .NET و OrientDB لمطوري Java. نظرًا لأن كلاهما يمكن أن يعمل كقواعد بيانات في الذاكرة ، و "شيء آخر" اعتمادًا على التكوين ، بحيث يمكنك استخدام واحد أو آخر اعتمادًا على تكوينك (App.Config في إعدادات .NET أو Maven أو ANT في Java).

Answer 9

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

RDBMS التقليدية: مجموعة MySQL الخاصة بك سريعة بما يكفي ، وسهلة بما يكفي للحفاظ عليها ، وتحب الحصول على موثوقية امتثال الحمض.

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

في الذاكرة RDBMS:

1. (سرعة): يحتاج التطبيق الخاص بك إلى معالجة البيانات/الطلبات بشكل أسرع من قاعدة البيانات المستندة إلى القرص.
2. (تعقيد): تحتاج إلى إجراء قراءات معاملات معقدة وتكتب مع الوصلات والتجمعات وترغب في استخدام قوة SQL.
3. (قابلية التوسع): تحتاج إلى توسيع نطاق قاعدة البيانات الخاصة بك أفقيا دون توقف.
4. (قابلية الصيانة): أنت بحاجة إلى قاعدة البيانات لتوفير توفر عالي ، وتكرار ، وتوازن الحمل والتعافي من الكوارث دون إضافة أعمال الصيانة الخاصة بك.
5. (مذكرة قانونية): يجب أن تتناسب بياناتك في الذاكرة (عادة في تيرابايت).