قدمت Sui Tidehunter، محرك تخزين مبني خصيصًا لبلوكتشين، بهدف استبدال RocksDB من خلال تقليل تضخيم الكتابة وتقديم معدل نقل أعلى وأكثر استقرارًا ووقت استجابة أقل لأعباء عمل المدققين والعقد الكاملة.
أطلقت Sui، شبكة بلوكتشين من الطبقة الأولى، محرك التخزين Tidehunter، وهو محرك جديد مصمم ليتوافق مع متطلبات الأداء وخصائص الوصول إلى البيانات والقيود التشغيلية الشائعة في بنى تحتية حديثة للبلوكتشين.
يُعتبر النظام كخليفة محتملة لطبقة قاعدة البيانات الحالية المستخدمة من قبل كل من المدققين والعقد الكاملة، ويعكس جهودًا أوسع لتحديث البنية التحتية الأساسية استجابةً لتغير حجم وأعباء العمل في بيئات البلوكتشين الإنتاجية.
كانت Sui تعتمد في الأصل على RocksDB كطبقة تخزين رئيسية للمفاتيح والقيم، وهو حل متبنى على نطاق واسع وناضج مكن من تطوير البروتوكول بسرعة. ومع توسع المنصة وزيادة الطلبات التشغيلية، ظهرت قيود أساسية على قواعد بيانات LSM-tree العامة، خاصة في بيئات تشبه الإنتاج.
لم تتمكن عمليات الضبط الموسعة والخبرة الداخلية العميقة من معالجة الكفاءات الهيكلية التي تتعارض مع أنماط الوصول النموذجية في أنظمة البلوكتشين. أدى ذلك إلى تحول استراتيجي نحو تصميم محرك تخزين مُحسّن خصيصًا لأعباء عمل البلوكتشين، مما أدى إلى تطوير Tidehunter.
عامل رئيسي وراء هذا القرار هو تضخيم الكتابة المستمر. أظهرت القياسات تحت أعباء عمل Sui الواقعية مستويات تضخيم تقارب عشرة إلى اثني عشر مرة، مما يعني أن كميات صغيرة نسبيًا من بيانات التطبيق تولد كميات غير متناسبة من حركة القرص. على الرغم من أن هذا السلوك شائع في أنظمة LSM، إلا أنه يقلل من عرض النطاق الترددي الفعلي للتخزين ويزيد من التنافس بين عمليات التجميع الخلفية وعمليات القراءة. في بيئات ذات كثافة كتابة عالية أو متوازنة بين القراءة والكتابة، يصبح هذا العبء أكثر تقييدًا مع زيادة معدل النقل.
أكدت اختبارات التحميل على مجموعات عالية الأداء التأثير، حيث اقترب استخدام القرص من التشبع على الرغم من معدلات كتابة تطبيق معتدلة، مما يبرز التباين المتزايد بين بنى التخزين التقليدية ومتطلبات أداء البلوكتشين الحديثة.
بنية Tidehunter: محرك تخزين مُحسن لأنماط الوصول في البلوكتشين وأعباء العمل ذات معدل النقل العالي المستدام
سلوك التخزين في Sui ومنصات البلوكتشين المماثلة يهيمن عليه مجموعة صغيرة من أنماط الوصول المتكررة للبيانات، وتم تصميم Tidehunter خصيصًا حول هذه الخصائص. يتم معالجة جزء كبير من الحالة باستخدام مفاتيح تجزئة تشفيرية موزعة بشكل متساوٍ وعادةً ما تربط بسجلات كبيرة نسبيًا، مما يلغي المحلية ولكنه يبسط التوافق والصحة.
في الوقت نفسه، تعتمد البلوكتشين بشكل كبير على هياكل موجهة للإضافة، مثل سجلات الإجماع والنقاط التفتيش، حيث تُكتب البيانات بترتيب وتُسترجع لاحقًا باستخدام معرفات متزايدة بشكل أحادي. هذه البيئات أيضًا بطبيعتها كثيفة الكتابة، مع الحاجة إلى وصول سريع في مسارات القراءة ذات الكمون الحرج، مما يجعل تضخيم الكتابة المفرط تهديدًا مباشرًا لكل من معدل النقل والاستجابة.
في مركز Tidehunter يوجد خط أنابيب كتابة عالي التزامن مصمم لاستغلال قدرات التخزين الصلب الحديثة. يتم توجيه عمليات الكتابة الواردة عبر سجل كتابة بدون قفل قادر على الحفاظ على معدلات عمليات عالية جدًا، مع الحد الأدنى من التنافس في خطوة تخصيص واحدة.
تتم عملية نسخ البيانات بشكل متوازي، ويتجنب النظام استدعاءات النظام لكل عملية باستخدام ملفات قابلة للكتابة على الذاكرة، بينما يتم التعامل مع المتانة بشكل غير متزامن بواسطة خدمات خلفية. ينتج عن هذا التصميم مسار كتابة متوقع ومتوازي بشكل كبير يمكنه استهلاك عرض النطاق الترددي للقرص دون أن يتقيد بعبء المعالج.
يُعتبر تقليل تضخيم الكتابة هدفًا معماريًا أساسيًا بدلاً من خطوة تحسين. بدلاً من استخدام السجل كموقع مؤقت، يخزن Tidehunter البيانات بشكل دائم في قطاعات السجل ويبني فهارس تشير مباشرةً إلى الإزاحات، مما يلغي إعادة كتابة القيم بشكل متكرر.
يتم تقسيم الفهارس بشكل كبير للحفاظ على انخفاض تضخيم الكتابة وزيادة التوازي، مما يلغي الحاجة إلى هياكل LSM-tree التقليدية. بالنسبة لمجموعات البيانات التي تعتمد على الإضافة، مثل نقاط التفتيش وسجلات الإجماع، تضمن استراتيجيات التوزيع الخاصة أن تظل البيانات الحديثة مجمعة بشكل محكم بحيث يظل عبء الكتابة مستقرًا حتى مع نمو البيانات التاريخية.
بالنسبة للجداول التي يتم الوصول إليها بواسطة مفاتيح تجزئة موزعة بشكل موحد، يقدم Tidehunter فهرس بحث موحدًا مُحسنًا للوصول المتوقع والمنخفض الكمون. بدلاً من إصدار العديد من عمليات القراءة الصغيرة والعشوائية، يقرأ الفهرس منطقة متجاورة أكبر قليلاً تحتوي إحصائيًا على الإدخال المطلوب، مما يسمح لمعظم عمليات البحث بالاكتمال في رحلة واحدة إلى القرص.
يتعمد هذا النهج على مبادلة بعض معدل القراءة مقابل تقليل الكمون المستقر والأقل، وهو تبادل عملي لأن تقليل تضخيم الكتابة يحرر عرض نطاق كبير للقرص لحركة القراءة. النتيجة هي أداء أكثر اتساقًا في العمليات الحساسة للكمون مثل تنفيذ المعاملات والتحقق من الحالة.
للسيطرة على زمن الاستجابة النهائي عند مقياس كبير، يجمع Tidehunter بين الإدخال المباشر (I/O) والتخزين المؤقت الذي تديره التطبيقات. تتجاوز عمليات القراءة التاريخية الكبيرة ذاكرة التخزين المؤقت للصفحة الخاصة بنظام التشغيل لمنع تلوث الكاش، بينما يتم الاحتفاظ بالبيانات الحديثة والمتكررة الوصول إليها في ذاكرات المستخدم المستنيرة بأنماط الوصول على مستوى التطبيق. معًا، يقلل هذا من الرحلات غير الضرورية إلى القرص ويحسن التوقعية تحت الحمل المستمر.
كما يتم تبسيط إدارة دورة حياة البيانات، حيث يتم تخزين السجلات مباشرة في قطاعات السجل، ويمكن حذف البيانات التاريخية غير الضرورية عن طريق حذف ملفات السجل بالكامل بمجرد أن تتجاوز فترة الاحتفاظ. هذا يتجنب آليات التجميع المعقدة والمستهلكة لعمليات الإدخال والإخراج التي تتطلبها قواعد بيانات LSM، ويمكّن من تقليم أسرع وأكثر توقعًا مع توسع مجموعات البيانات.
عبر أعباء العمل المصممة لتعكس الاستخدام الحقيقي لـ Sui، يُظهر Tidehunter معدل نقل أعلى ووقت استجابة أقل من RocksDB، مع استهلاك أقل بكثير لعرض النطاق الترددي لكتابة القرص. التحسين الأكثر وضوحًا يأتي من القضاء شبه الكامل على تضخيم الكتابة، مما يسمح لنشاط القرص أن يتطابق بشكل أدق مع عمليات الكتابة على مستوى التطبيق ويحافظ على سعة الإدخال والإخراج للقراءة. تُلاحظ هذه الآثار في الاختبارات المعملية وفي عمليات النشر الكاملة للمدققين، مما يشير إلى أن المكاسب تتجاوز الاختبارات الاصطناعية.
يتم التقييم باستخدام إطار عمل قياس غير مرتبط بقاعدة البيانات يحاكي مزيجًا واقعيًا من الإدخالات والحذف والبحث النقاطي والتكرار. تُعبر الاختبارات عن توزيعات مفاتيح مشابهة لـ Sui، وأحجام القيم، ونسب القراءة والكتابة، وتُنفذ على أجهزة متوافقة مع مواصفات المدقق الموصى بها. تحت هذه الظروف، يظل Tidehunter يدعم معدل نقل أعلى ووقت استجابة أقل من RocksDB بشكل مستمر، مع أكبر فوائد تظهر في سيناريوهات الكتابة الثقيلة والمتوازنة.
تؤكد اختبارات المدققين بشكل إضافي النتائج. عند دمجه مباشرة في Sui وخضوعه لحمولة معاملات مستمرة، تحافظ الأنظمة التي تستخدم Tidehunter على معدل نقل مستقر ووقت استجابة أقل عند نقاط التشغيل التي تبدأ فيها أنظمة RocksDB المعتمدة على التدهور في الأداء وزيادة استخدام القرص. تظهر القياسات ضغطًا أقل على القرص، واستقرارًا أكبر في استخدام المعالج، وتحسين زمن الوصول النهائي، مما يبرز تباينًا واضحًا في السلوك تحت حمل مماثل.
يمثل Tidehunter استجابة عملية لمتطلبات التشغيل لأنظمة البلوكتشين ذات معدل النقل العالي والطويلة الأمد. مع توجه البلوكتشين نحو أعباء عمل مستدامة بدلاً من تلك الناتجة عن فترات الذروة، تصبح كفاءة التخزين متطلبًا أساسيًا لأداء البروتوكول. يعكس تصميم Tidehunter تحولًا نحو بنية تحتية مصممة خصيصًا لهذا المرحلة التالية من التوسع، مع توقعات لمزيد من التفاصيل الفنية وخطط النشر لاحقًا.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
Tidehunter: قاعدة بيانات Sui من الجيل التالي محسنة لخفض الكمون وتقليل تضخيم الكتابة
ملخص سريع
قدمت Sui Tidehunter، محرك تخزين مبني خصيصًا لبلوكتشين، بهدف استبدال RocksDB من خلال تقليل تضخيم الكتابة وتقديم معدل نقل أعلى وأكثر استقرارًا ووقت استجابة أقل لأعباء عمل المدققين والعقد الكاملة.
أطلقت Sui، شبكة بلوكتشين من الطبقة الأولى، محرك التخزين Tidehunter، وهو محرك جديد مصمم ليتوافق مع متطلبات الأداء وخصائص الوصول إلى البيانات والقيود التشغيلية الشائعة في بنى تحتية حديثة للبلوكتشين.
يُعتبر النظام كخليفة محتملة لطبقة قاعدة البيانات الحالية المستخدمة من قبل كل من المدققين والعقد الكاملة، ويعكس جهودًا أوسع لتحديث البنية التحتية الأساسية استجابةً لتغير حجم وأعباء العمل في بيئات البلوكتشين الإنتاجية.
كانت Sui تعتمد في الأصل على RocksDB كطبقة تخزين رئيسية للمفاتيح والقيم، وهو حل متبنى على نطاق واسع وناضج مكن من تطوير البروتوكول بسرعة. ومع توسع المنصة وزيادة الطلبات التشغيلية، ظهرت قيود أساسية على قواعد بيانات LSM-tree العامة، خاصة في بيئات تشبه الإنتاج.
لم تتمكن عمليات الضبط الموسعة والخبرة الداخلية العميقة من معالجة الكفاءات الهيكلية التي تتعارض مع أنماط الوصول النموذجية في أنظمة البلوكتشين. أدى ذلك إلى تحول استراتيجي نحو تصميم محرك تخزين مُحسّن خصيصًا لأعباء عمل البلوكتشين، مما أدى إلى تطوير Tidehunter.
عامل رئيسي وراء هذا القرار هو تضخيم الكتابة المستمر. أظهرت القياسات تحت أعباء عمل Sui الواقعية مستويات تضخيم تقارب عشرة إلى اثني عشر مرة، مما يعني أن كميات صغيرة نسبيًا من بيانات التطبيق تولد كميات غير متناسبة من حركة القرص. على الرغم من أن هذا السلوك شائع في أنظمة LSM، إلا أنه يقلل من عرض النطاق الترددي الفعلي للتخزين ويزيد من التنافس بين عمليات التجميع الخلفية وعمليات القراءة. في بيئات ذات كثافة كتابة عالية أو متوازنة بين القراءة والكتابة، يصبح هذا العبء أكثر تقييدًا مع زيادة معدل النقل.
أكدت اختبارات التحميل على مجموعات عالية الأداء التأثير، حيث اقترب استخدام القرص من التشبع على الرغم من معدلات كتابة تطبيق معتدلة، مما يبرز التباين المتزايد بين بنى التخزين التقليدية ومتطلبات أداء البلوكتشين الحديثة.
بنية Tidehunter: محرك تخزين مُحسن لأنماط الوصول في البلوكتشين وأعباء العمل ذات معدل النقل العالي المستدام
سلوك التخزين في Sui ومنصات البلوكتشين المماثلة يهيمن عليه مجموعة صغيرة من أنماط الوصول المتكررة للبيانات، وتم تصميم Tidehunter خصيصًا حول هذه الخصائص. يتم معالجة جزء كبير من الحالة باستخدام مفاتيح تجزئة تشفيرية موزعة بشكل متساوٍ وعادةً ما تربط بسجلات كبيرة نسبيًا، مما يلغي المحلية ولكنه يبسط التوافق والصحة.
في الوقت نفسه، تعتمد البلوكتشين بشكل كبير على هياكل موجهة للإضافة، مثل سجلات الإجماع والنقاط التفتيش، حيث تُكتب البيانات بترتيب وتُسترجع لاحقًا باستخدام معرفات متزايدة بشكل أحادي. هذه البيئات أيضًا بطبيعتها كثيفة الكتابة، مع الحاجة إلى وصول سريع في مسارات القراءة ذات الكمون الحرج، مما يجعل تضخيم الكتابة المفرط تهديدًا مباشرًا لكل من معدل النقل والاستجابة.
في مركز Tidehunter يوجد خط أنابيب كتابة عالي التزامن مصمم لاستغلال قدرات التخزين الصلب الحديثة. يتم توجيه عمليات الكتابة الواردة عبر سجل كتابة بدون قفل قادر على الحفاظ على معدلات عمليات عالية جدًا، مع الحد الأدنى من التنافس في خطوة تخصيص واحدة.
تتم عملية نسخ البيانات بشكل متوازي، ويتجنب النظام استدعاءات النظام لكل عملية باستخدام ملفات قابلة للكتابة على الذاكرة، بينما يتم التعامل مع المتانة بشكل غير متزامن بواسطة خدمات خلفية. ينتج عن هذا التصميم مسار كتابة متوقع ومتوازي بشكل كبير يمكنه استهلاك عرض النطاق الترددي للقرص دون أن يتقيد بعبء المعالج.
يُعتبر تقليل تضخيم الكتابة هدفًا معماريًا أساسيًا بدلاً من خطوة تحسين. بدلاً من استخدام السجل كموقع مؤقت، يخزن Tidehunter البيانات بشكل دائم في قطاعات السجل ويبني فهارس تشير مباشرةً إلى الإزاحات، مما يلغي إعادة كتابة القيم بشكل متكرر.
يتم تقسيم الفهارس بشكل كبير للحفاظ على انخفاض تضخيم الكتابة وزيادة التوازي، مما يلغي الحاجة إلى هياكل LSM-tree التقليدية. بالنسبة لمجموعات البيانات التي تعتمد على الإضافة، مثل نقاط التفتيش وسجلات الإجماع، تضمن استراتيجيات التوزيع الخاصة أن تظل البيانات الحديثة مجمعة بشكل محكم بحيث يظل عبء الكتابة مستقرًا حتى مع نمو البيانات التاريخية.
بالنسبة للجداول التي يتم الوصول إليها بواسطة مفاتيح تجزئة موزعة بشكل موحد، يقدم Tidehunter فهرس بحث موحدًا مُحسنًا للوصول المتوقع والمنخفض الكمون. بدلاً من إصدار العديد من عمليات القراءة الصغيرة والعشوائية، يقرأ الفهرس منطقة متجاورة أكبر قليلاً تحتوي إحصائيًا على الإدخال المطلوب، مما يسمح لمعظم عمليات البحث بالاكتمال في رحلة واحدة إلى القرص.
يتعمد هذا النهج على مبادلة بعض معدل القراءة مقابل تقليل الكمون المستقر والأقل، وهو تبادل عملي لأن تقليل تضخيم الكتابة يحرر عرض نطاق كبير للقرص لحركة القراءة. النتيجة هي أداء أكثر اتساقًا في العمليات الحساسة للكمون مثل تنفيذ المعاملات والتحقق من الحالة.
للسيطرة على زمن الاستجابة النهائي عند مقياس كبير، يجمع Tidehunter بين الإدخال المباشر (I/O) والتخزين المؤقت الذي تديره التطبيقات. تتجاوز عمليات القراءة التاريخية الكبيرة ذاكرة التخزين المؤقت للصفحة الخاصة بنظام التشغيل لمنع تلوث الكاش، بينما يتم الاحتفاظ بالبيانات الحديثة والمتكررة الوصول إليها في ذاكرات المستخدم المستنيرة بأنماط الوصول على مستوى التطبيق. معًا، يقلل هذا من الرحلات غير الضرورية إلى القرص ويحسن التوقعية تحت الحمل المستمر.
كما يتم تبسيط إدارة دورة حياة البيانات، حيث يتم تخزين السجلات مباشرة في قطاعات السجل، ويمكن حذف البيانات التاريخية غير الضرورية عن طريق حذف ملفات السجل بالكامل بمجرد أن تتجاوز فترة الاحتفاظ. هذا يتجنب آليات التجميع المعقدة والمستهلكة لعمليات الإدخال والإخراج التي تتطلبها قواعد بيانات LSM، ويمكّن من تقليم أسرع وأكثر توقعًا مع توسع مجموعات البيانات.
عبر أعباء العمل المصممة لتعكس الاستخدام الحقيقي لـ Sui، يُظهر Tidehunter معدل نقل أعلى ووقت استجابة أقل من RocksDB، مع استهلاك أقل بكثير لعرض النطاق الترددي لكتابة القرص. التحسين الأكثر وضوحًا يأتي من القضاء شبه الكامل على تضخيم الكتابة، مما يسمح لنشاط القرص أن يتطابق بشكل أدق مع عمليات الكتابة على مستوى التطبيق ويحافظ على سعة الإدخال والإخراج للقراءة. تُلاحظ هذه الآثار في الاختبارات المعملية وفي عمليات النشر الكاملة للمدققين، مما يشير إلى أن المكاسب تتجاوز الاختبارات الاصطناعية.
يتم التقييم باستخدام إطار عمل قياس غير مرتبط بقاعدة البيانات يحاكي مزيجًا واقعيًا من الإدخالات والحذف والبحث النقاطي والتكرار. تُعبر الاختبارات عن توزيعات مفاتيح مشابهة لـ Sui، وأحجام القيم، ونسب القراءة والكتابة، وتُنفذ على أجهزة متوافقة مع مواصفات المدقق الموصى بها. تحت هذه الظروف، يظل Tidehunter يدعم معدل نقل أعلى ووقت استجابة أقل من RocksDB بشكل مستمر، مع أكبر فوائد تظهر في سيناريوهات الكتابة الثقيلة والمتوازنة.
تؤكد اختبارات المدققين بشكل إضافي النتائج. عند دمجه مباشرة في Sui وخضوعه لحمولة معاملات مستمرة، تحافظ الأنظمة التي تستخدم Tidehunter على معدل نقل مستقر ووقت استجابة أقل عند نقاط التشغيل التي تبدأ فيها أنظمة RocksDB المعتمدة على التدهور في الأداء وزيادة استخدام القرص. تظهر القياسات ضغطًا أقل على القرص، واستقرارًا أكبر في استخدام المعالج، وتحسين زمن الوصول النهائي، مما يبرز تباينًا واضحًا في السلوك تحت حمل مماثل.
يمثل Tidehunter استجابة عملية لمتطلبات التشغيل لأنظمة البلوكتشين ذات معدل النقل العالي والطويلة الأمد. مع توجه البلوكتشين نحو أعباء عمل مستدامة بدلاً من تلك الناتجة عن فترات الذروة، تصبح كفاءة التخزين متطلبًا أساسيًا لأداء البروتوكول. يعكس تصميم Tidehunter تحولًا نحو بنية تحتية مصممة خصيصًا لهذا المرحلة التالية من التوسع، مع توقعات لمزيد من التفاصيل الفنية وخطط النشر لاحقًا.