it-swarm.asia

هل يمكن لـ MySQL تنفيذ الاستعلامات بشكل معقول حول مليارات الصفوف؟

أخطط لتخزين عمليات المسح من مطياف الكتلة في قاعدة بيانات MySQL وأود أن أعرف ما إذا كان تخزين هذه الكمية من البيانات وتحليلها ممكن عن بعد. أعلم أن الأداء يختلف اختلافًا كبيرًا اعتمادًا على البيئة ، لكني أبحث عن الترتيب التقريبي للحجم: هل ستستغرق الاستعلامات 5 أيام أو 5 مللي ثانية؟

نمط الإدخال

يحتوي كل ملف إدخال على تشغيل واحد للمطياف ؛ يتكون كل تشغيل من مجموعة من عمليات المسح ، ولكل مسح مجموعة مرتبة من نقاط البيانات. هناك القليل من البيانات الوصفية ، ولكن غالبية الملف يتكون من صفائف 32 أو 64 بت أو عوامات.

النظام المضيف

 | ---------------- + --------------------------- - | نظام التشغيل | Windows 2008 64 بت | 
 | نسخة MySQL | 5.5.24 (x86_64) | 
 | وحدة المعالجة المركزية | 2x Xeon E5420 (إجمالي 8 نوى) | 
 | RAM | 8 جيجابايت | 
 | نظام ملفات SSD | 500 GiB | 
 | HDD RAID | 12 TiB | 
 | ---------------- + ------------------------------- | 

هناك بعض الخدمات الأخرى التي تعمل على الخادم باستخدام وقت معالج لا يذكر.

إحصائيات الملف

 | ------------------ + -------------- | 
 | عدد الملفات | ~ 16،000 | 
 | الحجم الكلي | 1.3 TiB | 
 | الحد الأدنى للحجم | 0 بايت | 
 | أقصى حجم | 12 GiB | 
 | يعني | 800 ميغا بايت | 
 | متوسط ​​| 500 ميغا بايت | 
 | إجمالي نقاط البيانات | ~ 200 مليار | 
 | ------------------ + -------------- | 

إجمالي عدد نقاط البيانات هو تقدير تقريبي جدًا.

المخطط المقترح

أنا أخطط للقيام بأمور "صحيحة" (أي تطبيع البيانات مثل المجنون) وهكذا سيكون لدي جدول runs جدول ، spectra جدول بمفتاح خارجي إلى runs ، وجدول datapoints مع مفتاح خارجي لـ spectra.

سؤال 200 مليار datapoint

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

معلومات إضافية

ستأتي بيانات المسح من ملفات بتنسيق XML (--- mzML . لحم هذا الشكل في <binaryDataArrayList> عناصر حيث يتم تخزين البيانات. ينتج كل مسح> = 2 <binaryDataArray> العناصر التي تشكل مجتمعة مصفوفة ثنائية الأبعاد (أو أكثر) من النموذج [[123.456, 234.567, ...], ...].

هذه البيانات هي مرة واحدة للكتابة ، لذلك لا يعد تحديث الأداء وسلامة المعاملات معنيين.

خطتي الساذجة لمخطط قاعدة البيانات هي:

runs طاولة

 | اسم العمود | اكتب | 
 | ------------- + ------------- | 
 | معرف | مفتاح أساسي | 
 | وقت البدء | توقيت | 
 | الاسم | VARCHAR | 
 | ------------- + ------------- | 

spectra طاولة

 | اسم العمود | اكتب | 
 | ---------------- + ------------- | 
 | معرف | مفتاح أساسي | 
 | الاسم | VARCHAR | 
 | فهرس | INT | 
 | نوع الطيف | INT | 
 | التمثيل | INT | 
 | run_id | FOREIGN KEY | 
 | ---------------- + ------------- | 

datapoints طاولة

 | اسم العمود | اكتب | 
 | ------------- + ------------- | 
 | معرف | مفتاح أساسي | 
 | أطياف | مفتاح خارجي | 
 | mz | مزدوج | 
 | num_counts | مزدوج | 
 | فهرس | INT | 
 | ------------- + ------------- | 

هل هذا معقول؟


لذا ، ربما كنت قد تمكنت من الاستدلال ، أنا المبرمج ، وليس عالم الأحياء في المختبر ، لذلك لا أعرف العلم تقريبًا مثل العلماء الفعليين.

فيما يلي رسم بياني لطيف واحد (مسح) لنوع البيانات التي سأتعامل معها:

Viewer screenshot

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

285
haxney

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

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

هناك طريقة أخرى تتمثل في استخدام نظام تخزين مستند إلى المستندات لنقاط البيانات (وربما الأطياف) ، واستخدام MySQL لعمليات التشغيل (أو ربما وضع عمليات التشغيل في نفس قاعدة البيانات مثل قواعد البيانات الأخرى).

117
Krystian Cybulski

عملت مرة واحدة مع قاعدة بيانات MySQL (Terabyte +) كبيرة جدًا. أكبر طاولة لدينا حرفيا كانت أكثر من مليار صف. كان هذا يستخدم MySQL 5.0 ، لذا من المحتمل أن الأمور قد تحسنت.

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

كان مجرد النسخ الاحتياطي وتخزين البيانات تحديا. سوف يستغرق الأمر أيامًا لاستعادة الجدول إذا احتجنا ذلك.

كان لدينا العديد من الجداول في نطاق الصف 10-100 مليون. أي ارتباطات مهمة إلى الجداول كانت تستغرق وقتًا طويلاً وستستغرق إلى الأبد. لذلك قمنا بكتابة إجراءات مخزنة "لسير" الجداول وعملية الانضمام مقابل نطاقات "id". وبهذه الطريقة ، سنقوم بمعالجة البيانات من 10 إلى 100000 صف في المرة الواحدة (الانضمام مقابل معرف 1-100،000 ثم 100،001-200،000 ، إلخ). كان هذا أسرع بكثير من الانضمام مقابل الجدول بأكمله.

يعد استخدام الفهارس على جداول كبيرة جدًا لا يعتمد على المفتاح الأساسي أكثر صعوبة. يقوم Mysql 5.0 بتخزين الفهارس في جزئين - يقوم بتخزين الفهارس (بخلاف الفهرس الأساسي) كمؤشرات لقيم المفاتيح الأساسية. لذا يتم إجراء عمليات البحث المفهرسة في جزأين: أولاً ينتقل MySQL إلى فهرس ويسحب منه قيم المفتاح الأساسي التي يحتاج إلى البحث عنها ، ثم يقوم بإجراء بحث ثانٍ على فهرس المفتاح الأساسي للعثور على مكان هذه القيم.

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

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

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

أتفق مع إجابة srini.venigalla أن تطبيع البيانات مثل المجنون قد لا يكون فكرة جيدة هنا. سيؤدي القيام بالانضمام عبر جداول متعددة بهذه الكمية الكبيرة من البيانات إلى تعرضك لخطر أنواع الملفات مما قد يعني أن بعض استفساراتك لن تعود أبدًا. تمنحك عملية إزالة الخواص باستخدام مفاتيح بسيطة وصحيحة فرصة أفضل للنجاح.

كل ما كان لدينا كان InnoDB. فيما يتعلق MyISAM مقابل InnoDB: الشيء الرئيسي هو عدم الخلط بين الاثنين. لا يمكنك حقًا تحسين الخادم لكليهما بسبب الطريقة التي تخزن بها MySQL المفاتيح والبيانات الأخرى. اختر واحدًا أو آخر لجميع الجداول في الخادم إذا استطعت. قد تساعد MyISAM في بعض مشكلات السرعة ، ولكنها قد لا تساعد في عمل DBA الإجمالي الذي يجب القيام به - والذي يمكن أن يكون قاتلًا.

111
Kevin Bedell

تطبيع البيانات مثل مجنون

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

Is this reasonable?

أود أيضًا إنشاء جدول مسطح إضافي يحتوي على جميع البيانات.

run_id | spectrum_id | data_id | <data table columns..> |

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

الاستراتيجية هي ، الاستعلام على الجدول أعلاه أولاً ، تفريغ النتائج في جدول مؤقت والانضمام إلى الجدول المؤقت مع جداول البحث عن Run و Spectrum والحصول على البيانات التي تريدها.


هل قمت بتحليل احتياجات الكتابة الخاصة بك مقابل احتياجات القراءة؟ سيكون من المغري للغاية التخلص من SQL والانتقال إلى آليات تخزين البيانات غير القياسية. في رأيي ، يجب أن يكون الملاذ الأخير.

لتسريع سرعات الكتابة ، قد ترغب في تجربة طريقة Handler Socket. يقوم بيركونا ، إذا كنت أتذكر ، بحزم مقبس Handler في حزمة التثبيت الخاصة به. (لا علاقة لبيركونا!)

http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html

70
srini.venigalla

الإجابة المختصرة هي نعم مؤهلة - نظرًا لأن عدد الصفوف يزيد من أهمية المخطط الدقيق وأنواع البيانات والعمليات التي تختارها.

يعتمد مقدار تطبيع بياناتك على العمليات التي تخطط لتنفيذها على البيانات المخزنة. يبدو جدول نقاط البيانات الخاص بك على وجه الخصوص إشكالية - هل تخطط لمقارنة النقطة n من أي أطياف معينة مع mth من أي شيء آخر؟ إذا لم يكن الأمر كذلك ، فقد يكون تخزينها بشكل منفصل خطأ. إذا كانت نقاط البيانات الخاصة بك لا تقف بمفردها ولكن لا معنى لها إلا في سياق الأطياف المرتبطة بها ، فلن تحتاج إلى مفتاح أساسي - مفتاح خارجي للأطياف وعمود "nth" (عمود "الفهرس"؟) سيكون كافيًا .

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

أكبر MySQL قمت بإدارته شخصياً كان ~ 100 مليون صف. في هذا الحجم الذي تريده احتفظ بالصفوف وبالتالي الحقول الخاصة بك ثابتة الحجم - وهذا يسمح لـ MySQL بحساب موضع أي صف في الجدول بكفاءة عن طريق ضرب مرات الحجم الثابت لكل صف (أعتقد حساب المؤشر) - على الرغم من أن التفاصيل الدقيقة تعتمد على محرك التخزين الذي تخطط لاستخدامه. استخدم MyISAM إذا استطعت التخلص منه ، وما يفتقر إليه في الموثوقية التي يعوضها في السرعة ، وفي وضعك يجب أن يكون كافيًا. استبدل الحقول المتغيرة الحجم مثل VARCHAR بـ CHAR (n) واستخدم RTRIM () في استعلامات القراءة.

بمجرد أن تكون صفوف الجدول ذات عرض ثابت ، يمكنك تقليل عدد وحدات البايت من خلال تقييم MySQL بدقة أنواع البيانات الصحيحة (بعضها غير قياسي). كل مدخرات 1 بايت يمكنك الحصول عليها عن طريق تحويل 4 بايت INT إلى 3 بايت MEDIUMINT يوفر لك ~ 1 ميجابايت لكل مليون صف - مما يعني إدخال/إخراج أقل للقرص وتخزين أكثر فعالية. استخدم أصغر أنواع البيانات الممكنة التي يمكنك التخلص منها . تقييم أنواع الفاصلة العائمة بعناية ومعرفة ما إذا كان يمكنك استبدال أزواج 8 بايت بأزرار عائمة 4 بايت أو حتى 8 بايت أرقام ثابتة . قم بإجراء الاختبارات للتأكد من أن ما تختاره لا يعضك لاحقًا.

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

الأهم من ذلك ، بغض النظر عما تفعله في نهاية المطاف ، لا تفترض أنك قد اخترت المخطط المثالي ثم ابدأ بشكل أعمى في إغراق 10 ملايين من السجلات في. التصاميم الجيدة تستغرق وقتًا للتطور. أنشئ مجموعة كبيرة ولكن يمكن التحكم فيها (على سبيل المثال ، 1-5٪) من بيانات الاختبار وتحقق من صحة وأداء مخططك. تعرف على أداء العمليات المختلفة (http://dev.mysql.com/doc/refman/5.0/en/using-explain.html) وتأكد من موازنة مخططك لصالح العمليات الأكثر تكرارًا.

هل قلت قصيرة؟ عفوًا. على أي حال ، حظا سعيدا!

33
Ryan Flynn

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

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

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


بعد مراجعة تحديثات أسئلتك ، أعتقد أن النموذج الذي يتم فيه تخزين البيانات الثنائية كـ BLOB أو مجرد مؤشر للملف يكفي والعمل على تعديل النموذج الخاص بك لتخزين البيانات حول القمم المهمة التي تم تحديدها عند أول البيانات اقرأ.

23
Cade Roux

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

الأداء هنا جيد. إنها بيانات طبيعية للغاية. ومع ذلك - قلقي الرئيسي في قراءة هذا هو أنك سوف تكون أكثر من 4.2 مليار صف لهذه الجداول (ربما ليس "الجري" ولكن ربما الآخران) ، مما يعني أنك ستحتاج إلى استخدام BIGINT بدلاً من INT لـ المفاتيح الأساسية/الخارجية.

إن أداء MySQL مع حقول BIGINT في عمود مفهرس هو رهيب للغاية مقارنة بـ INT لقد أخطأت في القيام بذلك مرة واحدة بجدول اعتقدت أنه قد ينمو فوق هذا الحجم ، وبمجرد أن وصل إلى بضع مئات من ملايين الصفوف كان الأداء ببساطة سيئًا. ليس لدي أرقام أولية ولكن عندما أقول سيئة ، أعني أن Windows ME سيئ.

كان هذا العمود المفتاح الأساسي. قمنا بتحويلها مرة أخرى لتكون مجرد INT و presto magico ، وكان الأداء جيدًا مرة أخرى.

كانت جميع خوادمنا في ذلك الوقت على Debian 5 ومع MySQL 5.0. منذ ذلك الحين قمنا بالترقية إلى Debian 6 و Percona MySQL 5.5 ، لذا فقد تحسنت الأمور منذ ذلك الحين. ولكن بناءً على تجربتي هنا ، لا ، لا أعتقد أنها ستعمل جيدًا.

18
Sean

سواء كانت تعمل أم لا ، ستواجه دائمًا نفس المشكلة مع وسيط تخزين واحد متآلف: الأقراص بطيئة. بسرعة 100 ميجابايت/ثانية (جيد جدًا لوسائل الغزل) يستغرق 3 ساعات فقط لقراءة جدول 1 تيرابايت ؛ هذا على افتراض عدم وجود تحليل أو السعي أو التأخيرات الأخرى يبطئك.

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

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

18
tylerl

حسنًا ... أرى سببين أوليين لاختيارك لهذا النوع من بنية البيانات:

  • أنت حقًا بحاجة إلى القيام بأي استفسارات تتعلق بنقطة البيانات
  • تنوي القيام بكل منطقك في SQL

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

ملاحظة: ضع في اعتبارك أنك ستحتاج على الأقل إلى 36 + 5 بايت لكل نقطة بيانات ، لذا مع 200 نقطة بيانات يجب أن تمنحك 8.2 TB المساحة المطلوبة على الأقل.

ملاحظة: أنت لست بحاجة إلى العمود id في الجدول datapoints ، ربما يكفي PRIMARY KEY (spectrum_id, index) (فقط احذر أن index قد تكون كلمة محجوزة)

13
Tassos Bassoukos

تعديل:

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

وتحتاج إلى إلغاء ترتيب بياناتك إذا كنت ترغب في إجراء تحليل فعال للبيانات. أنت لا تصمم نظامًا عبر الإنترنت هنا. تريد تحليل الأرقام والتصميم وفقًا لذلك.

الإجابة الأصلية تحت السطر.


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

إذا كنت ترغب في إجراء المزيد من الاستفسارات المخصصة BigQuery من Google قد يكون الحل مناسبًا لك. عرض تقديمي ذي صلة من Google I/O 2012: Crunching Big Data with BigQuery

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

12
mdolk

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

المفهوم هو:

  • بدلا من قاعدة بيانات واحدة اضافية كبيرة
  • استخدم العديد من الأجزاء الصغيرة التي تحمل أجزاء من البيانات الأصلية

وبالتالي يمكنك القياس أفقيًا ، بدلاً من محاولة تحسين الأداء الرأسي. تستخدم Google BigTable و [~ # ~] gfs [~ # ~] أيضًا عُقدًا قابلة للتطوير أفقيًا رخيصة لتخزين طلبات بيتابايت والاستعلام عنها البيانات.

ومع ذلك ، ستكون هناك مشاكل إذا كنت بحاجة إلى تشغيل الاستعلامات على أجزاء مختلفة.


إذا كان أي شخص مهتمًا ، فقد قمت بتقديم تطبيق مشاركة مرحبا بالعالم منذ فترة. تمت مناقشته هنا في مشاركة مدونة. لقد استخدمت RavenDB و C # ولكن التفاصيل غير ذات صلة والفكرة هي نفسها.
9
oleksii

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

العامل النهائي الذي سيحدد وقت الاستعلام سيكون قرصك الصلب. تم تصميم قواعد البيانات ومحسنات استعلاماتها لتقليل عدد أقراص الإدخال/الإخراج قدر الإمكان. نظرًا لأن لديك 3 طاولات فقط ، فسيتم القيام بذلك بشكل موثوق به.

ستكون سرعة القراءة/الكتابة للقرص الصلب 200-300 مرة أبطأ من سرعات الذاكرة. ابحث عن الأقراص الصلبة ذات الكمون السريع وسرعات القراءة والكتابة السريعة. إذا كانت جميع هذه البيانات على محرك أقراص واحد بسعة 2 تيرابايت ، فربما تنتظر وقتًا طويلاً حتى تنتهي الاستعلامات. يستغرق زمن وصول القرص الصلب حوالي 10-15 ميلي ثانية بينما يكون زمن انتقال الذاكرة أقل من 10 نانو ثانية. يمكن أن يكون وقت استجابة القرص الصلب أبطأ بمقدار 1000-2000 مرة من وقت استجابة الذاكرة. إن تحريك الذراع الميكانيكية على القرص الصلب هو الأبطأ في هذا النظام بأكمله.

كم RAM لديك؟ 16 جيجابايت؟ دعنا نقول أنه يتيح لك الاحتفاظ بـ 32 سجلًا. لديك 16000 ملف. إذا كنت ستقوم بمسح جميع نقاط البيانات خطيًا ، فقد ينتهي بك الأمر بسهولة مع 5-10 ثواني في وقت البحث وحده. ثم ضع في الاعتبار معدل النقل 50 ميجابايت/ثانية؟ حوالي 7 ساعات. بالإضافة إلى ذلك ، يجب تخزين أي بيانات محفوظة مؤقتًا على القرص الصلب لإفساح المجال لقراءة البيانات الجديدة.

إذا كنت تستخدم جهاز تخزين مشترك يتم استخدامه بنشاط من قبل مستخدمين آخرين ... فإن أفضل رهان هو تشغيل كل شيء في الليل.

يساعد أيضًا تقليل عدد الاستعلامات المتداخلة بشكل جيد. تؤدي الاستعلامات المتداخلة إلى جداول مؤقتة ستسحق قرصك الصلب أكثر. آمل أن يكون لديك الكثير من المساحة الحرة على محرك الأقراص الثابتة.

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

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

إذا كنت ستقوم بتعديل قيم الاسم (varchars) ، فسأقوم بتغييرها إلى نوع بيانات بأقصى حجم ، فسوف تمنع التجزؤ وتبلغ المقايضة بضع بايتات إضافية من الذاكرة. ربما NVARCHAR مع 100 كحد أقصى.

بقدر التعليقات حول تطبيع الجدول. أعتقد أنه قد يكون من الأفضل تخزين نقاط البيانات في مجموعات أكبر (ربما كطيف الأطياف) ثم إجراء تحليل البيانات في python أو في لغة تتفاعل مع قاعدة البيانات. ساحر.

7
JustinDanielson

بالنسبة لي يبدو وكأنه سيناريو استخدام حيث تريد شيئًا مثل "مخزن الأعمدة العلائقية" كما هو موضح هنا .

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

عند استرداد المصفوفات ، قد لا تحتاج فقط إلى ربطها بجدول آخر ناتج عن تطبيعك ، ولكن يمكنك استرداد السلسلة كمصفوفة بدلاً من تجزئة.

قد أسيء فهم المشكلة حقًا ، ولا أقترح حتى حلًا معينًا.

هذا حديث آخر قد يكون ذا صلة ، حتى لو لم يكن حلاً حاليًا أو قابلاً للنشر.

6
RandallZ

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

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

http://dev.mysql.com/doc/refman/5.1/en/partitioning-limitation.html

http://www.slideshare.net/datacharmer/mysql-partitions-tutorial

6
user9866

نعم ولكن ...

لقد عملت مع الجداول التي تحتوي على 2 مليار صف. ومع ذلك ، كان من المتوقع أن تكون الاستفسارات التي تستخدم PK سريعة فقط.

الأهم من ذلك ، كان لدى الجهاز ما يكفي RAM لتناسب الجداول الكاملة في الذاكرة. عندما أصبح ذلك مشكلة (بحد أقصى 96 جيجابايت في ذلك الوقت) ، ذهب إلى التقسيم العمودي ، مع الاحتفاظ بحجم الجدول في كل الجهاز صغير بما يكفي ليظل صالحًا للذاكرة. أيضًا ، تم توصيل الأجهزة عبر ألياف 10 جيجابت ، لذلك لم يكن معدل نقل الشبكة مشكلة كبيرة.

بالمناسبة. مخططك يبدو كشيء يمكن أن يتناسب مع حل NoSQL باستخدام run_id كمفتاح تجزئة للأطياف و spectrum_id كمفتاح تجزئة لنقاط البيانات.

5
vartec

لقد كتبت عن هذا الموضوع في مدونتي: http://www.tocker.ca/2013/10/24/improving-the-performance-of-large-tables-in-MySQL.html =

لتكرار بعض النقاط الرئيسية:

  • تتدهور أشجار B عندما تكبر ولا تتناسب مع الذاكرة (MySQL ليست هنا وحدها).
  • يحتوي InnoDB على بعض الميزات للمساعدة في الحفاظ على بعض الأداء (تغيير التخزين المؤقت ؛ الذي كان يُطلق عليه سابقًا اسم "إدراج المخزن المؤقت").
  • يمكن أن يساعد التقسيم أيضًا.

في تعليقات منشوري Tim Callaghan المرتبط بهذا: http://www.tokutek.com/resources/benchmark-results/benchmarks-vs-innodb-hdds/#iiBench

مما يدل على إدخال 1 مليار صف باستخدام معيار iibench.

4
Morgan Tocker