it-swarm.asia

ما هي خصائص أداء sqlite مع ملفات قاعدة بيانات كبيرة جدا؟

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

ومع ذلك ، لأغراضي ، أود أن أحصل على فكرة عن مدى سوء الأمر قبل التفكير في حلول أخرى.

أنا أتحدث عن ملفات البيانات sqlite في مجموعة متعددة غيغابايت ، من 2GB فصاعدا. هل هناك أحد يمتلك خبرة لهذا؟ أي نصائح/أفكار؟

309
Snazzer

لذلك قمت ببعض الاختبارات باستخدام sqlite لملفات كبيرة جدًا ، وتوصلت إلى بعض الاستنتاجات (على الأقل بالنسبة للتطبيق المحدد الخاص بي).

تنطوي الاختبارات على ملف sqlite واحد يحتوي إما على جدول واحد أو على جداول متعددة. يحتوي كل جدول على حوالي 8 أعمدة وكل الأعداد الصحيحة تقريبًا و 4 مؤشرات.

كانت الفكرة هي إدخال بيانات كافية حتى تصل ملفات sqlite إلى حوالي 50 جيجابايت.

جدول واحد

حاولت إدراج صفوف متعددة في ملف sqlite مع جدول واحد فقط. عندما كان حجم الملف حوالي 7 غيغابايت (آسف لا أستطيع أن أكون محددًا حول عدد الصفوف) كانت عمليات الإدراج تستغرق وقتًا طويلاً. لقد قدرت أن اختباري لإدخال جميع بياناتي سيستغرق 24 ساعة أو نحو ذلك ، لكنه لم يكتمل حتى بعد 48 ساعة.

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

أعتقد أن هذا ليس مفاجئًا ، حيث إن الجدول يزداد حجمًا ، حيث يستغرق إدخال كل المؤشرات وتحديثها وقتًا أطول.

جداول متعددة

حاولت بعد ذلك تقسيم البيانات حسب الوقت على عدة جداول ، جدول واحد في اليوم. تم تقسيم بيانات الجدول 1 الأصلي إلى ~ 700 الجداول.

لم يواجه هذا الإعداد أي مشاكل في عملية الإدراج ، ولم يستغرق الأمر وقتًا أطول مع تقدم الوقت ، حيث تم إنشاء جدول جديد يوميًا.

مشاكل الفراغ

كما أشار i_like_caffeine ، فإن أمر VACUUM يمثل مشكلة كلما زاد حجم ملف sqlite. مع إجراء المزيد من عمليات الإدراج/الحذف ، فإن تجزئة الملف على القرص ستزداد سوءًا ، وبالتالي فإن الهدف هو الحصول على فراغ دائم لتحسين الملف واستعادة مساحة الملف.

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

الاستنتاجات

بالنسبة للتطبيق الخاص بي ، من المحتمل أن أقوم بتوزيع البيانات على عدة ملفات ديسيبل ، واحد في اليوم ، للحصول على أفضل أداء فراغي وسرعة الإدراج/الحذف.

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

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

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

228
Snazzer

نحن نستخدم DBS من 50 جيجابايت + على منصتنا. لا يشكو يعمل كبيرة. تأكد من أنك تفعل كل شيء بشكل صحيح! هل تستخدم عبارات محددة مسبقا؟ * سكليتي 3.7.3

  1. المعاملات
  2. قبل أدلى البيانات
  3. قم بتطبيق هذه الإعدادات (مباشرة بعد إنشاء قاعدة البيانات)

    PRAGMA main.page_size = 4096;
    PRAGMA main.cache_size=10000;
    PRAGMA main.locking_mode=EXCLUSIVE;
    PRAGMA main.synchronous=NORMAL;
    PRAGMA main.journal_mode=WAL;
    PRAGMA main.cache_size=5000;
    

آمل أن يساعد هذا الآخرين ، ويعمل بشكل رائع هنا

155
Alex

لقد قمت بإنشاء قواعد بيانات SQLite بحجم يصل إلى 3.5 جيجابايت مع عدم وجود مشاكل ملحوظة في الأداء. إذا كنت أتذكر بشكل صحيح ، أعتقد أن SQLite2 قد يكون لديه بعض الحدود الدنيا ، لكن لا أعتقد أن SQLite3 لديه أي مثل هذه المشاكل.

وفقًا لـ حدود SQLite الصفحة ، يبلغ الحد الأقصى لحجم كل صفحة قاعدة بيانات 32 كيلو بايت. والحد الأقصى لصفحات قاعدة البيانات هو 1024 ^ 3. لذلك من خلال حسابي الذي يخرج إلى 32 تيرابايت كحد أقصى للحجم. أعتقد أنك سوف تضغط على حدود نظام الملفات الخاص بك قبل أن تصل إلى SQLite!

62
Paul Lefebvre

يرجع السبب في كون الأمر استغرق أكثر من 48 ساعة للقيام بإدخالاتك إلى فهارسك. إنه أسرع بشكل لا يصدق إلى:

1 - إسقاط جميع الفهارس 2 - هل جميع إدراج 3 - إنشاء الفهارس مرة أخرى

50
user352992

إلى جانب التوصية المعتادة:

  1. مؤشر انخفاض لإدراج بالجملة.
  2. الدفعة إدراج/التحديثات في المعاملات الكبيرة.
  3. ضبط ذاكرة التخزين المؤقت المخزن المؤقت/تعطيل مجلة/ث PRAGMAs.
  4. استخدم جهاز 64 بت (لتتمكن من استخدام الكثير من ذاكرة التخزين المؤقت ™).
  5. [تمت إضافة يوليو 2014] استخدم تعبير جدول شائع (CTE) بدلاً من تشغيل استعلامات SQL متعددة! يتطلب سكليتي الإصدار 3.8.3.

لقد تعلمت ما يلي من تجربتي مع SQLite3:

  1. لسرعة الإدراج القصوى ، لا تستخدم المخطط مع أي قيود العمود. (تعديل الجدول في وقت لاحق حسب الحاجة لا يمكنك إضافة قيود مع ALTER TABLE).
  2. تحسين المخطط لتخزين ما تحتاجه. هذا يعني في بعض الأحيان تقسيم الجداول و/أو حتى ضغط/تحويل بياناتك قبل الإدراج في قاعدة البيانات. مثال رائع هو تخزين عناوين IP كأعداد صحيحة (طويلة).
  3. جدول واحد لكل ملف ديسيبل - لتقليل تنازع القفل. (استخدم قاعدة بيانات ATTACH إذا كنت تريد أن يكون لديك كائن اتصال واحد.
  4. يمكن لـ SQLite تخزين أنواع مختلفة من البيانات في نفس العمود (الكتابة الديناميكية) ، واستخدامها لصالحك.

سؤال/تعليق مرحبا. ؛-)

30
Lester Cheung

لدي 7GB قاعدة بيانات SQLite. لتنفيذ استعلام معين مع صلة داخلية يستغرق 2.6s من أجل تسريع هذا الأمر ، حاولت إضافة فهارس. بناءً على الفهرس الذي قمت بإضافته ، انخفض الاستعلام في بعض الأحيان إلى 0.1 ثانية وأحيانًا ارتفع إلى 7 ثوانٍ. أعتقد أن المشكلة في حالتي هي أنه إذا كان العمود مكررًا جدًا ، فإن إضافة فهرس يؤدي إلى انخفاض الأداء :(

8
Mike Oxynormas

أعتقد أن الشكاوى الرئيسية حول تحجيم sqlite هي:

  1. عملية واحدة الكتابة.
  2. لا النسخ المتطابق.
  3. لا النسخ المتماثل.
8
Unknown

لقد واجهت مشاكل مع ملفات sqlite الكبيرة عند استخدام الأمر vacuum.

لم أجرب ميزة الفراغ التلقائي بعد. إذا كنت تتوقع أن تقوم بتحديث وحذف البيانات في كثير من الأحيان ، فهذا أمر يستحق الاهتمام.

6
eodonohoe