it-swarm.asia

أي DBMS جيد للقراءة فائقة السرعة وهيكل بيانات بسيط؟

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

معلومات حول قاعدة البيانات:

  • <100،000 إدخال لمعلومات الإحصائيات
  • قراءة قاعدة البيانات بالكامل عند التمهيد ، فقط مسار الملف ضروري
  • سيكون للملفات المدرجة بقائمة الانتظار حقل أولوية (لا حاجة للبحث عن أي شيء آخر)
  • يمكن أن تكون عمليات الإدراج بطيئة

لقد وجدت قاعدتي بيانات أعتقد أنهما سيعملان ، لكنني لست متأكدًا أيهما أفضل:

  • Redis - تخزين مسار الملف كمفتاح ، بيانات إحصائية كقيمة ؛ قائمة الانتظار ستكون قائمة
  • MongoDB - خيارات استعلام أكثر من Redis ، ولكنها لا تزال سريعة

أعتقد أن قاعدة بيانات NoSQL ستكون أفضل حل هنا ، حيث لا يوجد الكثير من المنطق العلائقي المستمر ، وحجم البيانات الإجمالي ليس كبيرًا جدًا (شيء مثل <100 ميغابايت ، أقرب إلى <30 ميغابايت). لقد نظرت إلى SQLite لأنه يبدو بسيطًا بما يكفي للتضمين في تطبيق قابل للتثبيت.

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

إذن السؤال ، ما هي قاعدة البيانات الأكثر قابلية للتطبيق على هذا الموقف؟

أيضا ، هل هناك أي قواعد بيانات أخرى من شأنها أن تكون أكثر منطقية لتطبيق مثل هذا؟

16
beatgammit

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

لذا ، نصيحتي هي الذهاب مع قاعدة بيانات مألوفة لك. إذا كنت على دراية بـ Redis أو MongoDB ، فانتقل إلى أحد هذه. إذا كنت أكثر دراية بـ SQLite ، فاختر ذلك.

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

9
Richard

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

يحتوي محرك تخزين MyISAM على خيار يسمح بزيادة الهيكل المادي للجدول للحصول على أداء أفضل. ما هذا الخيار؟ خيار ALTER TABLE ROW_FORMAT.

على سبيل المثال ، الكتاب MySQL Database Design and Tuning يوصي باستخدام ROW_FORMAT = FIXED على الصفحات 72،73. سيؤدي ذلك إلى تحويل جميع حقول VARCHAR داخليًا إلى CHAR. سيجعل جدول MyISAM أكبر ، ولكن تنفيذ SELECTs مقابله سيكون أسرع بكثير. أستطيع أن أشهد شخصيا على هذا. كان لدي جدول 1.9 غيغابايت. لقد غيرت التنسيق مع ALTER TABLE tblname ROW_FORMAT = FIXED. انتهى الجدول إلى 3.7 جيجابايت. كانت سرعة SELECTs ضدها أسرع بنسبة 20-25 ٪ دون تحسين أو تغيير أي شيء آخر.

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

SELECT * FROM tblname PROCEDURE ANALYSE();

تحليل الإجراء () لن يتم عرض البيانات. سيقرأ قيمة كل عمود ويوصي بتعريفات الأعمدة. على سبيل المثال ، إذا كان لديك عمود نوع قيمه 1-4 ، فسيتم اقتراحه باستخدام ENUM من هذه القيم الأربع. يمكنك بعد ذلك اختيار استخدام TINYINT أو CHAR (1) لأنها تأخذ نفس المساحة (1 بايت).

إليك شيء آخر يجب مراعاته: نظرًا لأنك كنت تفكر في استخدام NoSQL DB ، هل فكرت يومًا في استخدام MyISAM بطريقة NoSQL؟ هذا ممكن جدا. الصفحة 175 من نفس الكتاب الذي ذكرته يقترح استخدام هياكل HANDLER لقراءة جدول بدون الأمتعة العلائقية . في الواقع ، تعطي الصفحة 175 هذا المثال:

CREATE TABLE customer_mileage_details
(
    customer_id INT NOT NULL,
    ff_number CHAR(10) NOT NULL,
    transaction_date DATE NOT NULL,
    mileage SMALLINT NOT NULL,
    INSERT(customer_id),
    INSERT (ff_number,transaction_date)
) ENGINE = MYISAM;

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

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

تسمح هذه الأوامر بقراءة سريعة وقذرة من الجدول:

HANDLER customer_mileage_details OPEN;
HANDLER customer_mileage_details READ ff_number FIRST WHERE ff_number=('aaetm-4441');
HANDLER customer_mileage_details READ NEXT LIMT 10;
HANDLER customer_mileage_details CLOSE;

آمل أن يعطي هذا طعامًا للتفكير. يرجى النظر فيه.

مذكرة قانونية

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

12
RolandoMySQLDBA