أفضل طريقة لتخزين/استرداد الملايين من الملفات عندما الفوقية البيانات في قاعدة بيانات SQL

Question

لدي العملية التي يحدث في البداية توليد 3-4 مليون ملفات PDF, و تستمر بمعدل 80 كيلو/يوم.أنها سوف تكون صغيرة جدا (50 دولار) لكل منهما ، ولكن ما يقلقني هو كيفية إدارة مجموع كتلة من الملفات أنا توليد لسهولة البحث.بعض التفاصيل:

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

أصلا أنا قد خططت لكتابة هذه الملفات إلى دليل واحد على ناس, ولكن أنا أدرك أن هذا قد لا يكون فكرة جيدة, لأن هناك الملايين من ويندوز قد لا تحمل مليون ملف-بحث برشاقة جدا.أنا أبحث عن بعض النصائح:

1. هو مجلد واحد حسنا ؟ الملفات لن تكون مدرجة - لن يتم استردادها باستخدام نظام.IO.الملف مع اسم الملف سبق تحديدها.
2. إذا كنت تفعل مجلد, هل استطيع مشاهدة ملفات جديدة مع النظام.IO.DirectoryWatcher ، حتى مع أن العديد من الملفات ، أو أنها سوف تبدأ أن يصبح بطيئا مع أن العديد من الملفات ؟
3. ينبغي أن تكون مخزنة النقط في قاعدة بيانات SQL Server بدلا من ذلك ؟ منذ كنت سوف تحتاج إلى استرداد لهم قيمة مرجعية ، ربما هذا أكثر منطقية.

شكرا لك على أفكارك!

Answer 1

كنت أرجم الملفات في مجلدات فرعية محددة، وحاول تنظيمها (المجلدات الفرعية) في بعض الطرق المنطقية للأعمال. ربما جميع الملفات التي تم إجراؤها خلال يوم معين؟ خلال فترة ست ساعات من كل يوم؟ أو كل # من الملفات، أود أن أقول بضعة 1000 كحد أقصى. (ربما هناك رقم مثالي هناك، نأمل أن ينشره شخص ما.)

هل الملفات من أي وقت مضى في العمر والحذف؟ إذا كان الأمر كذلك، يكون الفرز والملف غير قابل للحل. إذا لم يكن كذلك، هل يمكنني أن أكون بائع الأجهزة الخاصة بك؟

هناك حجج على جانبي الملفات في قاعدة البيانات.

• من ناحية، تحصل على تحسين الأمان، لأنها أكثر حرجا لسحب الملفات من DB؛ من ناحية أخرى، تحصل على أداء أكثر فقرا، "لأنها أكثر حرجة لسحب الملفات من DB.
• في DB، لا داعي للقلق بشأن عدد الملفات لكل مجلد، قطاع، نظام معلومات NAS، أيا كان - مشكلة DB، وربما لديهم تطبيق جيد لهذا. على الجانب الآخر، سيكون من الصعب إدارة / مراجعة البيانات، كما هو سيكون النقط Bazillion في جدول واحد، حسنا، يوك. (يمكنك تقسيم الجدول بناء على منطق الأعمال المذكورة أعلاه، مما سيجعل الحذف أو الأرشفة أسهل بلا حدود. ذلك، أو ربما طرق العرض المقسمة، لأن تقسيم الجدول يحتوي على حد 1000 أقسام.)
• SQL Server 2008 لديه نوع بيانات FileStream؛ لا أعرف الكثير عن ذلك، قد يستحق النظر في.

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

Answer 2

للإجابة على الأسئلة الخاصة بك:

1. لن تخزينها في مجلد واحد.كما أن هناك احتمالات في بعض نقطة كنت سوف ترغب في النظر في الملفات الفعلية على القرص ، ثم بدلا من ذلك بطريقة أخرى.
   بدلا من ذلك لماذا لا يتم تخزينها في فصل الدلائل تقسيمها إلى دفعات من 1000?ربما باستخدام ID كمفتاح.
2. أن العديد من الملفات ربما الفيضانات DirectorWatcher ، وحتى بعض سوف تضيع.لقد استعملت هذا في الماضي و الماضي نقطة معينة (بضعة مئات), لقد وجدت أنه يبدأ تفوت الملفات.ربما استخدام دليل مختلف عن الملفات الواردة ، ومن ثم معالجة هذا كل ذلك في كثير من الأحيان.ثم وهذا يمكن أن يؤدي إلى عملية التحديث الأصلي.
3. لا تخزين الوثائق في قاعدة بيانات ، ولكن بالتأكيد تخزين البيانات الوصفية في قاعدة البيانات الخاصة بنا.

Answer 3

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

أسهل طريقة للقيام بذلك هي إنشاء Hash فريدة من نوعها لاسم الملف، بحيث يمكنك الحصول على شيء مثل هذا:

sf394fgr90rtfofrpo98tx.pdf

ثم كسر هذا إلى كتل ذات حرفين، وسوف تحصل على هذا:

sf/39/4f/gr/90/rt/fo/fr/po/98/tx.pdf

كما ترون، فإنه يمنحك شجرة دليل ديب يمكنك التنقل بسهولة.

مع وظيفة تجزئة جيدة، سيتم توزيع هذا بالتساوي بشكل متساو، ولن تحصل أبدا على أكثر من 1296 إدخال لكل دليل. إذا حصلت على تصادم من أي وقت مضى (يجب أن تكون نادرة للغاية)، فما عليك سوى إضافة رقم إلى النهاية: TX.PDF، TX_1.PDF، TX_2.PDF. مرة أخرى، يجب أن تكون التصادمات على هذه التجزئة الكبيرة نادرة للغاية، بحيث يكون هذا النوع من الكتلة التي تحصل عليها بسبب هذه المشكلة غير المشكلة.

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

Answer 4

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

فقط كن على علم أنه إذا كنت تستخدم معرفات الطلب، فقد تواجهك http://en.wikipedia.org/wiki/benford٪27S_LAW.

Answer 5

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

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

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

لذلك، أود أن أبحث في نظام التشغيل المخطط الخاص بك وخيارات نظام الملفات، واختبارها ومعرفة أيها تعمل بشكل أفضل لك.

Answer 6

حدد بعض الطلب المنطقي للدلائل الفرعية وتخزينها في كتل لا تزيد عن 512 أو نحو ذلك في مجلد.

لا تقم بتخزين الملفات في قاعدة بيانات. قواعد البيانات للبيانات، خوادم الملفات هي الملفات. قم بتخزينها على خادم ملفات، ولكن تخزين معلومات المسار واسترجاعها في قاعدة بيانات.

Answer 7

لماذا لا تفكر في تخزين جميع هذه الملفات بعد تحويلها إلى PDF في مزايا DB (Blob) وبالتالي:

1. أعتقد أنك لن تضطر إلى التعامل مع direclty مع نظام التشغيل I / O، وترك كل شيء يصل إلى DB.
2. لا حاجة إلى التجزئة تسمية
3. من السهل النسخ الاحتياطي والصيانة

Answer 8

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

DELETE FROM BLOBTABLE WHERE NAME LIKE '<whatever>'

أو عندما يكون لديك تاريخ انتهاء الصلاحية، أو ترغب في تحديث ملف، يمكنك إزالته بواسطة:

DELETE FROM BLOBTABLE WHERE CREATIONDATE < ...
etc...

Answer 9

سؤال:

لماذا تحتاج هذه المستندات إلى إنشاء وتخزينها كملفات PDF؟

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

Answer 10

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

2) متجر كل منهم في الدلائل وإما مؤشر عليها مع ويندوز خدمة الفهرسة (الرعشات) أو إنشاء الخاصة بك مؤشر في SQL Server التي تحتوي على اسم الملف والمسار الكامل.أود أن أقترح تخزينها في أدلة منفصلة, مع فقط بضع عشرات الآلاف من الملفات لكل منهما.وربما يمكن استخدام النظام العام كما المجلد الاسم ؟

بغض النظر عن كيفية تخزين – لا تفحص الدليل للعثور على الملفات - بالتأكيد سوف تحتاج إلى أن يكون مؤشر من نوع ما.

ويساعد هذا الأمل!

Answer 11

تحتوي قاعدة بيانات الملفات الخاصة بي على أكثر من 4 ملايين مجلدات، مع العديد من الملفات في كل مجلد.

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

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

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

أيضا، لن أرم الملفات في قاعدة بيانات MySQL. لن تكون قادرا على تقييم الشبكة دون وجود عميل يفهم MySQL. الآن يمكنني الوصول إلى أي ملف عبر الشبكة باستخدام أي برنامج لأنه يمكنني فقط استخدام عنوان URL للشبكة.

Answer 12

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