خيارات للتخزين للقراءة فقط ثنائي ملف مسطح باستخدام بايثون

Question

ولقد تم تكليف مع إنشاء قاعدة بيانات SKU ملف شقة للاستخدام على الأجهزة المضمنة مع التخزين المحدودة وسرعة المعالج.

وأساسا البيانات ولست بحاجة إلى تخزين تتكون من ما يلي:

وSKU وصف موقعك السعر الكمية

وسوف يتكون ملف من عدة ملايين من السجلات.

وأهم الاعتبارات هي مساحة التخزين والوقت استرجاع. سوف تحتاج فقط السجلات التي يتم استردادها من قبل SKU وسيكون للقراءة فقط، بحيث يمكن فرز ملف SKU.

وأود أن الوصول إلى هذه البيانات مع بيثون. حتى أسئلتي الامر لذلك.

هل هناك مكتبات بايثون القائمة التي يمكن أن توفر هذه الوظيفة بالنسبة لي، أو هل أنا بحاجة للفة بلدي؟

وإذا كان الجواب يأتي الى لفة بلدي، لا أحد يملك اقتراحات، أو إشارات جيدة للقيام بذلك؟

Answer 1

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

Answer 2

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

في عام، استخدام برنامج SQLite. كما كتب الآخرين، فإنه يأتي معيار مع بيثون، وانها تستخدم في الكثير من النظم المضمنة بالفعل.

إذا يتم إصلاح السجلات طول ثم يمكنك استخدام وحدة شطر. حجم ملف / حجم قياسي يعطي عدد السجلات في الملف. فإن البحث شطر تفعل لO (سجل (ن)) البحث في الملف، وسوف تحتاج لكتابة محول للاختبار من أجل المساواة. ورغم أنني لم نجرب ذلك، وهنا رسم:

import bisect

RECORD_SIZE = 50

class MatchFirst10Chars(object):
    def __init__(self, word):
        self.word = word
    def __lt__(self, other):
        return self.word < other[:10]

class FileLookup(object):
    def __init__(self, f):
        self.f = f
        f.seek(0, 2)
        self.size = f.tell() // RECORD_SIZE
    def __len__(self):
        return self.size

    def __getitem__(self, i):
        self.f.seek(i*RECORD_SIZE)
        return self.f.read(RECORD_SIZE)


SKU = "123-56-89 "
f = open("data_file")
fl = FileLookup(f)
i = bisect.bisect(fl, MatchFirst10Chars(SKU))

هل يمكن بالإضافة إلى ذلك GZIP الملف وتسعى على ملف gzip'ped، ولكن هذا المقايضة للمرة مقابل المساحة التي سيكون لديك لاختبار.

Answer 3

المصرف ؟ (بيثون: بيثون المصرف )

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

المصرف المواصفات هو قراءة جيدة، لأسباب ليس أقلها يتم تنسيق الخطوط لخلق الهامش الأيمن موحد. :-D

Answer 4

وماذا عن HDF ؟ إذا كنت لا تحتاج SQL وتتطلب الوصول السريع إلى البيانات الخاصة بك، لا يوجد شيء أسرع ... في بيثون ... لبيانات رقمية أو منظم.

ونلقي نظرة على DatabaseInterfaces القسم الخاص في بيثون الويكي. انها شاملة. وهناك زوجين من الخيارات بيثون "نقية" المدرجة (مثل SnakeSQL )، والتي هي أجمل صبي لنشر. وبطبيعة الحال، هناك دائما بيركلي DB وما شابه ذلك، والتي هي السوبر العجاف و الخام.

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

Answer 5

وهناك حل بسيط هو CPickle . يمكنك أيضا العثور على <لأ href = "https://stackoverflow.com/questions/890485/python-how-do-i-write-a-list-to-file-and-then-pull-it-back-into -memory-ديكت-مندوب "> أسئلة مشابهة حول SO.

Answer 6

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

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

وهنا مثال على ذلك: ويقول لديك

SKU         16 bytes
Description Variable length
Location    Variable length
Price       4 bytes (up to $42949672.95)
Quantity    4 bytes (up to 4294967295)



 offset          SKU        desc_off   loc_off      Price      Quantity
0x00000000 SKU0000000000001 0x01f78a40 0x01f78a47  0x000003e8  0x000f4240
0x00000020 SKU0000000000002 0x01f78a53 0x01f78a59    ...
...
... # 999998 more records
...
0x01f78a40 Widget\x00
0x01f78a47 Head office\x00
0x01f78a53 Table\x00
0x01f78a59 Warehouse\x00