كفاءة تخزين 7.300.000.000 الصفوف

Question

كيف يمكنك معالجة التالية تخزين واسترجاع المشكلة ؟

حوالي 2.000.000 الصفوف سيتم إضافة كل يوم (365 يوما في السنة) مع المعلومات التالية في الصف:

• id (معرف صف فريد)
• entity_id (يأخذ على القيم بين 1 و 2.000.000 شامل)
• date_id (زيادة مع واحدة كل يوم - سوف تأخذ على القيم بين 1 و 3.650 (عشر سنوات:1*365*10))
• value_1 (يأخذ على القيم بين 1 و 1.000.000 شامل)
• value_2 (يأخذ على القيم بين 1 و 1.000.000 شامل)

entity_id جنبا إلى جنب مع date_id هي فريدة من نوعها.ومن ثم في معظم صف واحد لكل كيان و تاريخ يمكن إضافتها إلى الجدول.قاعدة البيانات يجب أن تكون قادرة على عقد 10 سنوات بقيمة البيانات اليومية (7.300.000.000 الصفوف (3.650*2.000.000)).

ما هو موضح أعلاه هو كتابة الأنماط.قراءة نمط بسيط:جميع الاستفسارات على معين entity_id.أولا-هاء.استرداد كافة الصفوف واصفا entity_id = 12345.

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

الآن كيف يمكنك معالجة وصف المشكلة ؟

تحديث: لقد طلب مني أن تفصيلا فيما يتعلق القراءة والكتابة أنماط.يكتب إلى مائدة دفعة واحدة في اليوم الواحد حيث الجديدة 2M سيتم إضافة إدخالات في دفعة واحدة.يقرأ وسوف يتم بشكل مستمر مع أحد يقرأ في كل ثانية.

Answer 1

استخدام التقسيم.مع قراءة نمط تريد التقسيم من قبل entity_id تجزئة.

Answer 2

"الآن كيف يمكنك معالجة وصف المشكلة؟"

مع بسيطة ملفات مسطحة.

هنا لماذا

"جميع الاستفسارات سوف تكون على محددة entity_id.أولا-هاء.استرداد كافة الصفوف واصفا entity_id = 12345."

لديك 2.000.000 الكيانات.التقسيم على أساس كيان رقم:

level1= entity/10000
level2= (entity/100)%100
level3= entity%100

كل ملف البيانات level1/level2/level3/batch_of_data

ثم يمكنك قراءة كافة الملفات في جزء معين من الدليل العودة عينات للمعالجة.

إذا كان شخص ما يريد قاعدة بيانات علائقية ، ثم تحميل ملفات معينة entity_id في قاعدة بيانات لاستخدامها.

---

تحرير في اليوم أرقام.

1. على date_id/entity_id تفرد القاعدة لا الشيء الذي يجب أن يتم التعامل معها.إنه (أ) مسلي المفروضة على أسماء الملفات و (ب) غير ذي صلة بالنسبة الاستعلام.

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

لأنه لا يعتمد على الاستعلام date_id, لا شيء من أي وقت مضى يجب القيام به مع ذلك.يمكن أن يكون اسم الملف على كل ما يهم.

تشمل date_id في الكتابة في الملف مع أربعة آخرين من الصفات التي هي في كل صف من الملف.

---

تحرير على فتح/إغلاق

للكتابة, عليك أن تترك الملف(ق) مفتوحة.يمكنك القيام الدوري الهبات (أو إغلاق/فتح) أن أؤكد أن الأمور حقا هو الذهاب إلى القرص.

لديك خياران بنية الكاتب الخاص بك.

1. واحد "الكاتب" العملية التي تقوم بدمج البيانات من مختلف المصادر(s).وهذا مفيد إذا الاستعلامات متكررة نسبيا.تدفعه دمج البيانات في كتابة الوقت.

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

Answer 3

قد ترغب في النظر في هذه الأسئلة:

كبيرة المفتاح الأساسي:1+ مليار الصفوف MySQL + ك InnoDB?

كبيرة الجداول الخلية

شخصيا كنت أعتقد أيضا حول حساب الصف العرض أن تعطيك فكرة عن كيفية كبيرة الجدول الخاص بك سوف تكون (حسب التقسيم ملاحظة: في الرابط الأول).

HTH.,

S

Answer 4

التطبيق الخاص بك يبدو أن لها نفس الخصائص مثل الألغام.كتبت الخلية التخزين المخصصة المحرك بكفاءة في حل المشكلة.هو موضح هنا

تخيل البيانات الخاصة بك وضعت على القرص مجموعة من 2M طول ثابت إدخالات (واحد لكل كيان) تحتوي كل منها على 3650 الصفوف (واحد لكل يوم) 20 بايت (صف كيان واحد في اليوم الواحد).

الخاص بك قراءة نمط يقرأ كيان واحد.فمن متجاورة على القرص لذلك يأخذ 1 التماس (عن 8mllisecs) وقراءة 3650x20 = حوالي 80 ألف في ربما 100MB/sec ...لذلك يتم في جزء من الثانية ، بسهولة الاجتماع الخاص بك 1-الاستعلام في الثانية قراءة نمط.

التحديث لكتابة 20 بايت في 2M أماكن مختلفة على القرص.في أبسط الحالات هذا من شأنه أن 2M يسعى كل منها يستغرق حوالي 8millisecs هي 2M*8ms = 4.5 ساعات.إذا كنت نشر البيانات عبر 4 "raid0" الأقراص يمكن أن تأخذ 1.125 ساعات.

ومع ذلك الأماكن فقط 80K على حدة.في مما يعني أن هناك 200 مثل هذه الأماكن داخل 16MB كتلة (نموذجي القرص حجم ذاكرة التخزين المؤقت) لذلك يمكن أن تعمل في أي شيء يصل إلى 200 مرة أسرع.(1 دقيقة) الواقع في مكان ما بين الاثنين.

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

هل يمكن أن رمز بالضبط ما قد وصفت.وضع الكود في الخلية للتوصيل مشغل التخزين يعني أنه يمكنك استخدام الخلية الاستعلام عن البيانات مع مختلف التقرير مولدات الخ.

بالمناسبة, هل يمكن القضاء على تاريخ الكيان معرف من تخزين صف (لأنهم صفيف الفهارس) و قد تكون فريدة من نوعها id – إذا كنت لا حقا في حاجة إليها منذ (كيان الهوية والتاريخ) هي فريدة من نوعها ، وتخزين 2 القيم 3-البايت int.ثم المخزنة الصف 6 بايت, و لديك 700 التحديثات في 16M وبالتالي أسرع إدراج ملف أصغر.

تحرير مقارنة شقة الملفات

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

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

لذلك إذا كنت تستخدم ملفات مسطحة, لماذا لا تستخدم فقط واحد شقة الملف و مؤشر ذلك ؟

تحرير على الأداء

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

تحرير على قياسات مرجعية

لدي جدول تبدو كثيرا مثل لك (أو تقريبا بالضبط مثل واحد من الأقسام).كان 64K الكيانات غير 2M (1/32 لك) ، 2788 'الأيام'.جدول تم إنشاؤه في نفس إدراج أجل أن لك سوف يكون له نفس مؤشر (entity_id اليوم).حدد في كيان واحد يأخذ 20.3 ثانية لتفقد 2788 أيام ، وهي عبارة عن 130 يسعى في الثانية كما هو متوقع (في 8 millisec متوسط السعي الوقت الأقراص).حدد الوقت سوف يكون متناسبا مع عدد الأيام و لا يعتمد كثيرا على عدد من الكيانات.(سيكون أسرع على الأقراص مع أسرع تسعى مرات.أنا باستخدام زوج من SATA2s في RAID0 ولكن هذا لا يجعل الكثير من الفرق).

إذا كنت إعادة ترتيب الجدول في كيان النظام تغيير الجدول x النظام من قبل (الكيان اليوم) ثم حدد يأخذ 198 millisecs (لأن ذلك هو القراءة النظام في كيان واحد الوصول إلى القرص).ومع ذلك تعديل جدول العملية 13.98 أيام كاملة (على 182M الصفوف).

هناك عدد قليل من الأشياء الأخرى القياسات اقول لكم 1.الفهرس الخاص بك الملف سيكون كبير مثل ملف البيانات الخاص بك.فمن 3GB على هذه العينة الجدول.يعني (على النظام) كل مؤشر في القرص بسرعة لا الذاكرة بسرعة.

2.إدراج الخاص بك انخفاض معدل لها.إدراج في ملف البيانات الخطية ولكن إدراج المفتاح في مؤشر السجل.في 180M سجلات كنت الحصول على 153 إدراج في الثانية ، وهو أيضا قريب جدا من التماس معدل.فإنه يدل على أن الخلية هي تحديث ورقة مؤشر كتلة تقريبا كل إدراج (كما كنت تتوقع لأنه يتم فهرستها على الكيان ولكن إدراجها في أمر اليوم.).إذا كنت تبحث في 2M/153 ثانية= 3.6 ساعة للقيام اليومية إدراج 2M الصفوف.(مقسمة حسب ما التأثير الذي يمكن أن تحصل من قبل القسم عبر أنظمة أو الأقراص).

Answer 5

كان مشكلة مماثلة (على الرغم من أن مع أكبر نطاق حول سنويا الاستخدام كل يوم)

باستخدام أحد طاولة كبيرة حصلت لي الصراخ على التوقف - يمكنك سحب بضعة أشهر ولكن أعتقد أن عليك في نهاية المطاف تقسيم.

لا ننسى أن مؤشر الجدول والا سوف يكون يعبث صغيرة هزيلة من البيانات كل طلب ؛ و إذا كنت تريد أن تفعل كتلة الاستفسارات ، استخدام ملفات مسطحة

Answer 6

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

وهذا سوف يسمح لك أن تنظر في القيام الضغط على بعض الأعمدة.

تنظر أيضا في الأرشفة و التقسيم.

Answer 7

إذا كنت ترغب في التعامل مع البيانات الضخمة مع الملايين من الصفوف فإنه يمكن اعتبار المماثلة لآخر سلسلة بيانات سجلات الوقت و يحفظ البيانات إلى قاعدة البيانات.بعض الطرق لتخزين البيانات باستخدام InfluxDB و MongoDB.