كيفية تقليل حجم قاعدة بيانات sqlite3 للآيفون؟
https://stackoverflow.com/questions/401467
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
يحرر:شكرا جزيلا لجميع الإجابات.فيما يلي النتائج بعد تطبيق التحسينات حتى الآن:
- التبديل إلى فرز الأحرف وتشغيل التشفير - حجم قاعدة البيانات الجديد 42M
- إسقاط الفهارس على القيم المنطقية - حجم قاعدة البيانات الجديد 33M
الجزء الجميل حقًا هو أن هذا لم يتطلب أي تغييرات في رمز iPhone
لدي تطبيق iPhone يحتوي على قاموس كبير بتنسيق sqlite (للقراءة فقط).أبحث عن أفكار لتقليل حجم ملف قاعدة البيانات، وهو كبير جدًا حاليًا.
فيما يلي عدد الإدخالات والحجم الناتج لقاعدة بيانات sqlite:
franks-macbook:DictionaryMaker frank$ ls -lh dictionary.db
-rw-r--r-- 1 frank staff 59M 8 Oct 23:08 dictionary.db
franks-macbook:DictionaryMaker frank$ wc -l dictionary.txt
453154 dictionary.txt
...متوسط حوالي 135 بايت لكل إدخال.
هنا هو مخطط قاعدة البيانات الخاصة بي:
create table words (word text primary key, sowpods boolean, twl boolean, signature text)
create index sowpods_idx on words(sowpods)
create index twl_idx on words(twl)
create index signature_idx on words(signature)
فيما يلي بعض نماذج البيانات:
photoengrave|1|1|10002011000001210101010000
photoengraved|1|1|10012011000001210101010000
photoengraver|1|1|10002011000001210201010000
photoengravers|1|1|10002011000001210211010000
photoengraves|1|1|10002011000001210111010000
photoengraving|1|1|10001021100002210101010000
يمثل الحقل الأخير ترددات الحروف لاسترجاع الجناس الناقص (كل موضع يقع في النطاق 0..9).يمثل المنطقان القواميس الفرعية.
أحتاج إلى إجراء استفسارات مثل:
select signature from words where word = 'foo'
select word from words where signature = '10001021100002210101010000' order by word asc
select word from words where word like 'foo' order by word asc
select word from words where word = 'foo' and (sowpods='1' or twl='1')
إحدى الأفكار التي لدي هي تشفير ترددات الحروف بشكل أكثر كفاءة، على سبيل المثال.يقوم الثنائي بتشفيرها كنقطة (ربما باستخدام RLE نظرًا لوجود العديد من الأصفار؟).هل هناك أي أفكار حول أفضل السبل لتحقيق ذلك، أو أفكار أخرى لتقليل الحجم؟أقوم ببناء قاعدة البيانات في روبي، وقراءتها على الهاتف في الهدف C.
هل هناك أيضًا أي طريقة للحصول على إحصائيات على قاعدة البيانات حتى أتمكن من معرفة ما الذي يستخدم أكبر مساحة؟
المحلول
لست واضحًا بشأن جميع حالات الاستخدام لحقل التوقيع ولكن يبدو أن تخزين نسخة أبجدية من الكلمة بدلاً من ذلك سيكون مفيدًا.
نصائح أخرى
هل حاولت كتابة أمر "الفراغ" للتأكد من عدم وجود مساحة إضافية في قاعدة البيانات التي نسيت استعادتها؟
قم بإزالة الفهارس الموجودة على sowpods وtwl - فهي على الأرجح لا تساعد في أوقات استعلامك وتستهلك بالتأكيد مساحة كبيرة.
يمكنك الحصول على إحصائيات قاعدة البيانات باستخدام sqlite3_analyzer من صفحة تنزيل SQLite.
كنهج مختلف تمامًا، يمكنك تجربة استخدام مرشح الزهرة بدلاً من قاعدة بيانات شاملة.في الأساس، يتكون مرشح Bloom من مجموعة من وظائف التجزئة، يرتبط كل منها بحقل بت.لكل كلمة قانونية، يتم تقييم كل دالة تجزئة، ويتم تعيين البت المقابل في حقل البت المقابل.العيب هو أنه من الممكن نظريًا الحصول على نتائج إيجابية كاذبة، ولكن يمكن تقليلها/القضاء عليها عمليًا باستخدام ما يكفي من التجزئات.الجانب الإضافي هو توفير مساحة كبيرة.
يبيع منشئ SQLite إصدارًا من SQLite يتضمن ضغط قاعدة البيانات (والتشفير).هذا من شأنه أن يكون مثاليا.
أفضل رهان لك هو استخدام الضغط، والذي للأسف لا يدعمه SQLite أصلاً في هذه المرحلة.لحسن الحظ، استغرق شخص ما الوقت الكافي لتطوير تمديد الضغط لأنه يمكن أن يكون ما تحتاجه.
وإلا فإنني أوصي بتخزين بياناتك في الغالب بتنسيق مضغوط وفك الضغط بسرعة.
كحقل نصي signature يستخدم حاليًا ما لا يقل عن 26 * 8 بايت لكل إدخال (208 بايت)، ولكن إذا كنت تريد حزم البيانات في حقل بت، فمن المحتمل أن تتمكن من الحصول على 3 بتات فقط لكل حرف (مما يقلل الحد الأقصى للتكرار لكل حرف إلى 7).وهذا يعني أنه يمكنك حزم التوقيع بالكامل في 26 * 3 بت = 78 بت = 10 بايت.حتى لو استخدمت 4 بتات لكل حرف (بحد أقصى للتردد يبلغ 15 لكل حرف)، فإنك ستستخدم 104 بتات فقط (13 بايت).
يحرر:بعد مزيد من التفكير، أعتقد أن 4 بتات لكل حرف (بدلاً من 3) ستكون فكرة أفضل لأنها ستجعل الرياضيات الثنائية أسهل.
تحرير 2:القراءة من خلال المستندات على أنواع البيانات SQLite, ، يبدو أنك قد تكون قادرًا على جعل حقل "التوقيع" يمتد إلى 26 عمودًا من النوع INTEGER وسيقوم SQLite بفعل الشيء الصحيح وسيستخدم فقط عدد البتات المطلوبة لتخزين القيمة.
هل أعتقد بشكل صحيح أن لديك حوالي 450 ألف كلمة كهذه في قاعدة البيانات الخاصة بك؟
ليس لدي أي فكرة عن iPhone، ولا أنا جاد بشأن sqlitem ولكن...طالما أن sqlite لا يسمح بطريقة لحفظ الملف بتنسيق gz على الفور (ربما يكون موجودًا بالفعل داخليًا؟لا، لا يبدو الأمر كذلك عندما تقول إنه حوالي 135 ب لكل إدخال.ولا حتى مع كلا الفهرس)، سأبتعد عن نهج الجدول، وأحفظه "يدويًا" في ملف ضغط نهج القاموس وابني الباقي سريعًا وفي الذاكرة.من المفترض أن يؤدي ذلك أداءً جيدًا جدًا على نوع بياناتك.
انتظر...هل تستخدم هذا التوقيع للسماح بالبحث عن النص الكامل أو الكتابة بشكل خاطئ؟كان البحث عن النص الكامل على sqlite لا عفا عليها الزمن هذا المجال؟
كما لوحظ، فإن تخزين "التوقيع" بشكل أكثر كفاءة يبدو فكرة جيدة.
ومع ذلك، يبدو أيضًا أنه يمكنك توفير الكثير من المساحة باستخدام نوع ما من جدول البحث عن الكلمات - حيث يبدو أنك تأخذ كلمة جذر ثم تلحق "er" و"ed" و"es" وما إلى ذلك. لا تحتوي على عمود بمعرف رقمي يشير إلى كلمة جذر من جدول بحث منفصل، ثم عمود منفصل بمعرف رقمي يشير إلى جدول لواحق الكلمات الشائعة التي سيتم إلحاقها بالكلمة الأساسية.
إذا كانت هناك أي حيل حول تخزين الإصدارات المختصرة من التوقيعات لإدخالات متعددة بكلمة جذر واحدة، فيمكنك أيضًا استخدامها لتقليل حجم التوقيعات المخزنة (لست متأكدًا من الخوارزمية التي تنتج هذه القيم)
يبدو أن هذا أيضًا منطقي جدًا بالنسبة لي نظرًا لأن لديك عمود "الكلمة" كمفتاح أساسي، ولكن لا تقم حتى بفهرسته - فقط قم بإنشاء عمود رقمي منفصل يمثل المعرف الأساسي للجدول.
امممم...ايفون...أليس لديه اتصال بيانات دائم؟أعتقد أن هذا هو المكان الذي يمكن أن يتدخل فيه تطبيق الويب/خدمة الويب بشكل مريح.انقل معظم منطق عملك إلى خادم الويب (سيكون لديه SQL حقيقي مع FTS وكمية كبيرة من الذاكرة) واجلب تلك المعلومات عبر الإنترنت إلى العميل على الجهاز.
كما ذكرنا في مكان آخر، إذا فقدت الفهارس الموجودة في الأعمدة المنطقية، فمن المؤكد أنها ستكون أبطأ (إذا تم استخدامها على الإطلاق) من مسح الجدول وستستخدم المساحة دون داع.
سأفكر في تطبيق ضغط بسيط على الكلمات، ترميز هوفمان جيد جدًا لهذا النوع من الأشياء.كما أنني سألقي نظرة على التوقيعات:قم بفرز الأعمدة بترتيب تكرار الأحرف ولا تهتم بتخزين الأصفار الزائدة، وهو ما قد يكون ضمنيًا.أعتقد أنه بإمكانك تشفيرها بواسطة هوفمان أيضًا.
افترض دائمًا أن سلاسلك المشفرة لا تزعج SQLite بالطبع.
