seaweedfs
3.80
SeaweedFS هو مشروع مستقل مفتوح المصدر مرخص من Apache، وقد أصبح تطويره المستمر ممكنًا بالكامل بفضل دعم هؤلاء الداعمين الرائعين. إذا كنت ترغب في تنمية SeaweedFS بشكل أقوى، فيرجى التفكير في الانضمام إلى رعاةنا على Patreon.
دعمكم سيكون موضع تقدير كبير من قبلي ومن المؤيدين الآخرين!
docker run -p 8333:8333 chrislusf/seaweedfs server -s3
weed أو weed.exe . أو قم بتشغيل go install github.com/seaweedfs/seaweedfs/weed@latest .weed server -dir=/some/data/dir -s3 لبدء خادم رئيسي واحد، وخادم وحدة تخزين واحد، وملف واحد، وبوابة S3 واحدة. أيضًا، لزيادة السعة، ما عليك سوى إضافة المزيد من خوادم الحجم عن طريق تشغيل weed volume -dir="/some/data/dir2" -mserver="<master_host>:9333" -port=8081 محليًا، أو على جهاز مختلف، أو على الآلاف من الآلات. هذا كل شيء!
SeaweedFS هو نظام ملفات موزع بسيط وقابل للتطوير بدرجة كبيرة. هناك هدفان:
بدأ SeaweedFS كمخزن كائنات للتعامل مع الملفات الصغيرة بكفاءة. بدلاً من إدارة كافة بيانات تعريف الملف في وحدة رئيسية مركزية، يقوم وحدة التخزين الرئيسية فقط بإدارة وحدات التخزين الموجودة على خوادم وحدة التخزين، وتقوم خوادم وحدة التخزين هذه بإدارة الملفات وبيانات التعريف الخاصة بها. يؤدي هذا إلى تخفيف ضغط التزامن من الجهاز الرئيسي المركزي وينشر بيانات تعريف الملف إلى خوادم الحجم، مما يسمح بالوصول بشكل أسرع إلى الملفات (O(1)، وعادةً ما تكون عملية قراءة قرص واحد فقط).
لا يوجد سوى 40 بايت من سعة تخزين القرص للبيانات التعريفية لكل ملف. يعد الأمر بسيطًا جدًا مع قراءات قرص O(1) بحيث نرحب بك لتحدي الأداء من خلال حالات الاستخدام الفعلية الخاصة بك.
بدأت SeaweedFS بتنفيذ ورقة تصميم Haystack الخاصة بفيسبوك. أيضًا، تنفذ SeaweedFS ترميز المحو باستخدام أفكار من f4: نظام تخزين Warm BLOB الخاص بفيسبوك، ولها الكثير من أوجه التشابه مع نظام الملفات التكتونية الخاص بفيسبوك
في الجزء العلوي من ملف تخزين العناصر، يمكن لـ Filer الاختياري دعم الدلائل وسمات POSIX. Filer هو خادم منفصل عديم الحالة قابل للتطوير خطيًا مع مخازن بيانات وصفية قابلة للتخصيص، على سبيل المثال، MySql، Postgres، Redis، Cassandra، HBase، Mongodb، Elastic Search، LevelDB، RocksDB، Sqlite، MemSql، TiDB، Etcd، CockroachDB، YDB، إلخ.
بالنسبة لأي مخازن قيمة رئيسية موزعة، يمكن إلغاء تحميل القيم الكبيرة إلى SeaweedFS. بفضل سرعة الوصول السريعة والقدرة القابلة للتطوير خطيًا، يمكن لـ SeaweedFS العمل كمخزن رئيسي ذو قيمة كبيرة.
يمكن لـ SeaweedFS التكامل بشفافية مع السحابة. من خلال البيانات الساخنة على المجموعة المحلية، والبيانات الدافئة على السحابة مع وقت وصول O(1)، يمكن لـ SeaweedFS تحقيق وقت وصول محلي سريع وسعة تخزين سحابية مرنة. علاوة على ذلك، يتم تقليل تكلفة واجهة برمجة التطبيقات للوصول إلى التخزين السحابي. أسرع وأرخص من التخزين السحابي المباشر!
العودة إلى جدول المحتويات
العودة إلى جدول المحتويات
العودة إلى جدول المحتويات
افتراضيًا، تعمل العقدة الرئيسية على المنفذ 9333، وتعمل عقد وحدة التخزين على المنفذ 8080. لنبدأ عقدة رئيسية واحدة وعقدتي وحدة تخزين على المنفذ 8080 و8081. ومن الناحية المثالية، يجب أن تبدأ من أجهزة مختلفة. سنستخدم المضيف المحلي كمثال.
يستخدم SeaweedFS عمليات HTTP REST للقراءة والكتابة والحذف. تكون الإجابات بتنسيق JSON أو JSONP.
> ./weed master
> weed volume -dir="/tmp/data1" -max=5 -mserver="localhost:9333" -port=8080 &
> weed volume -dir="/tmp/data2" -max=10 -mserver="localhost:9333" -port=8081 &
لتحميل ملف: أولاً، أرسل طلب HTTP POST أو PUT أو GET إلى /dir/assign للحصول على fid وعنوان URL لخادم وحدة التخزين:
> curl http://localhost:9333/dir/assign
{"count":1,"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}
ثانيًا، لتخزين محتوى الملف، أرسل طلب POST متعدد الأجزاء عبر HTTP إلى url + '/' + fid من الاستجابة:
> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}
للتحديث، أرسل طلب POST آخر يتضمن محتوى الملف المحدث.
للحذف، أرسل طلب HTTP DELETE إلى نفس url + '/' + fid URL:
> curl -X DELETE http://127.0.0.1:8080/3,01637037d6
الآن، يمكنك حفظ fid ، 3,01637037d6 في هذه الحالة، في حقل قاعدة البيانات.
الرقم 3 في البداية يمثل معرف المجلد. بعد الفاصلة، يوجد مفتاح ملف واحد، 01، وملف تعريف الارتباط، 637037d6.
معرف وحدة التخزين هو عدد صحيح غير موقع 32 بت. مفتاح الملف هو عدد صحيح 64 بت غير موقع. ملف تعريف الارتباط هو عدد صحيح غير موقّع يبلغ 32 بت، يُستخدم لمنع تخمين عنوان URL.
يتم ترميز كل من مفتاح الملف وملف تعريف الارتباط بالنظام السداسي. يمكنك تخزين الصف <volume id, file key, file cookie> بالتنسيق الخاص بك، أو ببساطة تخزين fid كسلسلة.
إذا تم تخزينها كسلسلة، فمن الناحية النظرية، ستحتاج إلى 8+1+16+8=33 بايت. سيكون char(33) كافيًا، إن لم يكن أكثر من كافٍ، نظرًا لأن معظم الاستخدامات لن تحتاج إلى 2^32 مجلدًا.
إذا كانت المساحة مثيرة للقلق حقًا، فيمكنك تخزين معرف الملف بالتنسيق الخاص بك. ستحتاج إلى عدد صحيح واحد بحجم 4 بايت لمعرف وحدة التخزين، ورقم طويل بطول 8 بايت لمفتاح الملف، وعدد صحيح بحجم 4 بايت لملف تعريف الارتباط. لذا فإن 16 بايت أكثر من كافية.
فيما يلي مثال لكيفية تقديم عنوان URL.
ابحث أولاً عن عناوين URL لخادم وحدة التخزين من خلال معرف وحدة تخزين الملف:
> curl http://localhost:9333/dir/lookup?volumeId=3
{"volumeId":"3","locations":[{"publicUrl":"localhost:8080","url":"localhost:8080"}]}
نظرًا لعدم وجود عدد كبير جدًا من خوادم وحدات التخزين (عادةً)، ولأن وحدات التخزين لا تتحرك كثيرًا، فيمكنك تخزين النتائج مؤقتًا في معظم الأوقات. اعتمادًا على نوع النسخ المتماثل، يمكن أن تحتوي وحدة التخزين الواحدة على مواقع نسخ متماثلة متعددة. ما عليك سوى اختيار موقع واحد للقراءة بشكل عشوائي.
يمكنك الآن الحصول على عنوان URL العام أو عرض عنوان URL أو القراءة مباشرةً من خادم وحدة التخزين عبر عنوان URL:
http://localhost:8080/3,01637037d6.jpg
لاحظ أننا نضيف امتداد الملف ".jpg" هنا. إنها طريقة اختيارية وطريقة واحدة فقط للعميل لتحديد نوع محتوى الملف.
إذا كنت تريد عنوان URL أفضل، فيمكنك استخدام أحد تنسيقات عناوين URL البديلة هذه:
http://localhost:8080/3/01637037d6/my_preferred_name.jpg
http://localhost:8080/3/01637037d6.jpg
http://localhost:8080/3,01637037d6.jpg
http://localhost:8080/3/01637037d6
http://localhost:8080/3,01637037d6
إذا كنت ترغب في الحصول على نسخة مصغرة من الصورة، يمكنك إضافة بعض المعلمات:
http://localhost:8080/3/01637037d6.jpg?height=200&width=200
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fit
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fill
تطبق SeaweedFS استراتيجية النسخ المتماثل على مستوى الحجم. لذلك، عندما تحصل على معرف ملف، يمكنك تحديد استراتيجية النسخ المتماثل. على سبيل المثال:
curl http://localhost:9333/dir/assign?replication=001
خيارات معلمة النسخ المتماثل هي:
000: no replication
001: replicate once on the same rack
010: replicate once on a different rack, but same data center
100: replicate once on a different data center
200: replicate twice on two different data center
110: replicate once on a different rack, and once on a different data center
يمكن العثور على مزيد من التفاصيل حول النسخ المتماثل على الويكي.
يمكنك أيضًا تعيين استراتيجية النسخ المتماثل الافتراضية عند بدء تشغيل الخادم الرئيسي.
يمكن بدء تشغيل خوادم التخزين باسم مركز بيانات محدد:
weed volume -dir=/tmp/1 -port=8080 -dataCenter=dc1
weed volume -dir=/tmp/2 -port=8081 -dataCenter=dc2
عند طلب مفتاح ملف، يمكن لمعلمة "dataCenter" الاختيارية تحديد الحجم المخصص لمركز بيانات محدد. على سبيل المثال، يحدد هذا أن وحدة التخزين المخصصة يجب أن تقتصر على 'dc1':
http://localhost:9333/dir/assign?dataCenter=dc1
العودة إلى جدول المحتويات
عادةً ما تقوم أنظمة الملفات الموزعة بتقسيم كل ملف إلى أجزاء، ويحتفظ المعلم المركزي بتعيين أسماء الملفات، ومؤشرات القطع إلى مقابض القطع، وكذلك القطع التي يمتلكها كل خادم قطعة.
العيب الرئيسي هو أن السيد المركزي لا يمكنه التعامل مع العديد من الملفات الصغيرة بكفاءة، وبما أن جميع طلبات القراءة تحتاج إلى المرور عبر القطعة الرئيسية، لذلك قد لا يتم قياسها بشكل جيد للعديد من المستخدمين المتزامنين.
بدلاً من إدارة القطع، يقوم SeaweedFS بإدارة أحجام البيانات في الخادم الرئيسي. يبلغ حجم كل وحدة تخزين بيانات 32 جيجابايت، ويمكن أن تحتوي على الكثير من الملفات. ويمكن أن تحتوي كل عقدة تخزين على العديد من وحدات تخزين البيانات. لذا فإن العقدة الرئيسية تحتاج فقط إلى تخزين البيانات التعريفية حول وحدات التخزين، وهي كمية صغيرة إلى حد ما من البيانات ومستقرة بشكل عام.
يتم تخزين بيانات تعريف الملف الفعلية في كل وحدة تخزين على خوادم وحدة التخزين. نظرًا لأن كل خادم وحدة تخزين يدير فقط البيانات التعريفية للملفات الموجودة على القرص الخاص به، مع 16 بايت فقط لكل ملف، يمكن لكل الوصول إلى الملفات قراءة البيانات التعريفية للملف من الذاكرة فقط ويحتاج فقط إلى عملية قرص واحدة لقراءة بيانات الملف فعليًا.
للمقارنة، ضع في اعتبارك أن بنية inode xfs في Linux تبلغ 536 بايت.
الهندسة المعمارية بسيطة إلى حد ما. يتم تخزين البيانات الفعلية في مجلدات على عقد التخزين. يمكن أن يحتوي خادم وحدة التخزين الواحدة على وحدات تخزين متعددة، ويمكن أن يدعم الوصول للقراءة والكتابة من خلال المصادقة الأساسية.
تتم إدارة جميع وحدات التخزين بواسطة خادم رئيسي. يحتوي الخادم الرئيسي على معرف وحدة التخزين لتعيين خادم وحدة التخزين. هذه معلومات ثابتة إلى حد ما، ويمكن تخزينها مؤقتًا بسهولة.
في كل طلب كتابة، يقوم الخادم الرئيسي أيضًا بإنشاء مفتاح ملف، وهو عدد صحيح غير موقّع يبلغ 64 بت. نظرًا لأن طلبات الكتابة ليست متكررة بشكل عام مثل طلبات القراءة، فيجب أن يكون هناك خادم رئيسي واحد قادر على التعامل مع التزامن بشكل جيد.
عندما يرسل العميل طلب كتابة، يقوم الخادم الرئيسي بإرجاع (معرف وحدة التخزين، مفتاح الملف، ملف تعريف الارتباط للملف، عنوان URL لعقدة وحدة التخزين) للملف. يقوم العميل بعد ذلك بالاتصال بعقدة وحدة التخزين وينشر محتوى الملف.
عندما يحتاج العميل إلى قراءة ملف بناءً على (معرف وحدة التخزين، مفتاح الملف، ملف تعريف الارتباط للملف)، فإنه يطلب من الخادم الرئيسي عن طريق معرف وحدة التخزين (عنوان URL لعقدة وحدة التخزين، عنوان URL العام لعقدة وحدة التخزين)، أو يسترد هذا من ذاكرة التخزين المؤقت. بعد ذلك، يمكن للعميل الحصول على المحتوى، أو مجرد عرض عنوان URL على صفحات الويب والسماح للمتصفحات بجلب المحتوى.
يرجى الاطلاع على المثال للحصول على تفاصيل حول عملية الكتابة والقراءة.
في التنفيذ الحالي، يمكن لكل وحدة تخزين أن تحتوي على 32 غيغابايت (32 غيغابايت أو 8x2^32 بايت). وذلك لأننا نقوم بمحاذاة المحتوى إلى 8 بايت. يمكننا بسهولة زيادة هذا إلى 64 جيجا بايت، أو 128 جيجا بايت، أو أكثر، عن طريق تغيير سطرين من التعليمات البرمجية، على حساب بعض مساحة الحشو الضائعة بسبب المحاذاة.
يمكن أن يكون هناك 4 غيغابايت (4 غيغابايت أو 2 ^ 32 بايت) من وحدات التخزين. وبالتالي فإن الحجم الإجمالي للنظام هو 8 × 4 جيجا بايت × 4 جيجا بايت وهو 128 إكسبيبايت (128EiB أو 2 ^ 67 بايت).
يقتصر حجم كل ملف فردي على حجم وحدة التخزين.
جميع معلومات تعريف الملف المخزنة على خادم وحدة التخزين قابلة للقراءة من الذاكرة دون الوصول إلى القرص. يأخذ كل ملف إدخال خريطة بحجم 16 بايت فقط من <مفتاح 64 بت، وإزاحة 32 بت، وحجم 32 بت>. بالطبع، كل إدخال خريطة له تكلفة مساحة خاصة به للخريطة. ولكن عادة ما تنفد مساحة القرص قبل أن تنفد الذاكرة.
تعد خوادم الحجم المحلي أسرع بكثير، في حين أن وحدات التخزين السحابية تتمتع بسعة مرنة وهي في الواقع أكثر فعالية من حيث التكلفة إذا لم يتم الوصول إليها كثيرًا (عادةً ما يكون التحميل مجانيًا، ولكن الوصول إليها مكلف نسبيًا). بفضل بنية الإلحاق فقط ووقت الوصول O(1)، يمكن لـ SeaweedFS الاستفادة من التخزين المحلي والسحابي عن طريق تفريغ البيانات الدافئة إلى السحابة.
عادة ما تكون البيانات الساخنة حديثة والبيانات الدافئة قديمة. يقوم SeaweedFS بوضع المجلدات التي تم إنشاؤها حديثًا على خوادم محلية، كما يقوم بشكل اختياري بتحميل المجلدات القديمة على السحابة. إذا تم الوصول إلى البيانات القديمة بشكل أقل، فهذا يمنحك حرفيًا سعة غير محدودة مع خوادم محلية محدودة، ولا يزال سريعًا للبيانات الجديدة.
مع وقت الوصول O(1)، يتم الاحتفاظ بتكلفة زمن الوصول للشبكة عند الحد الأدنى.
إذا تم تقسيم البيانات الساخنة/الدافئة إلى 20/80، مع 20 خادمًا، فيمكنك تحقيق سعة تخزين تصل إلى 100 خادم. وهذا توفير في التكاليف بنسبة 80٪! أو يمكنك إعادة توظيف الخوادم الـ 80 لتخزين البيانات الجديدة أيضًا، والحصول على إنتاجية تخزين 5X.
العودة إلى جدول المحتويات
تبدو معظم أنظمة الملفات الموزعة الأخرى أكثر تعقيدًا من اللازم.
من المفترض أن يكون SeaweedFS سريعًا وبسيطًا، في كل من الإعداد والتشغيل. إذا كنت لا تفهم كيف يعمل الأمر عند وصولك إلى هنا، فقد فشلنا! يرجى إثارة مشكلة مع أي أسئلة أو تحديث هذا الملف بالتوضيحات.
SeaweedFS تتقدم باستمرار إلى الأمام. نفس الشيء مع الأنظمة الأخرى. يمكن أن تصبح هذه المقارنات قديمة بسرعة. الرجاء المساعدة لإبقائهم محدثين.
العودة إلى جدول المحتويات
يستخدم HDFS أسلوب القطعة لكل ملف، وهو مثالي لتخزين الملفات الكبيرة.
يعد SeaweedFS مثاليًا لخدمة الملفات الصغيرة نسبيًا بسرعة وبشكل متزامن.
يمكن لـ SeaweedFS أيضًا تخزين ملفات كبيرة جدًا عن طريق تقسيمها إلى مجموعات بيانات يمكن التحكم فيها، وتخزين معرفات الملفات الخاصة بأجزاء البيانات في قطعة تعريفية. تتم إدارة ذلك من خلال أداة "تحميل/تنزيل الأعشاب الضارة"، ولا يدري سيد الأعشاب الضارة أو خوادم المجلدات عنها.
العودة إلى جدول المحتويات
البنى هي نفسها في الغالب. يهدف SeaweedFS إلى تخزين الملفات وقراءتها بسرعة، من خلال بنية بسيطة ومسطحة. الاختلافات الرئيسية هي
| نظام | بيانات تعريف الملف | قراءة محتوى الملف | بوسيكس | واجهة برمجة تطبيقات REST | الأمثل لعدد كبير من الملفات الصغيرة |
|---|---|---|---|---|---|
| الأعشاب البحريةFS | معرف حجم البحث، قابل للتخزين المؤقت | O(1) البحث عن القرص | نعم | نعم | |
| المدون الأعشاب البحرية | قابلة للتطوير خطيًا وقابلة للتخصيص | O(1) البحث عن القرص | فيوز | نعم | نعم |
| جلوسترفس | التجزئة | الصمامات، NFS | |||
| سيف | التجزئة + القواعد | فيوز | نعم | ||
| موسفس | في الذاكرة | فيوز | لا | ||
| MiniIO | ملف تعريف منفصل لكل ملف | نعم | لا |
العودة إلى جدول المحتويات
يقوم GlusterFS بتخزين الملفات، سواء الدلائل أو المحتوى، في مجلدات قابلة للتكوين تسمى "الطوب".
يقوم GlusterFS بتجزئة المسار واسم الملف إلى معرفات، وتعيينها لوحدات التخزين الافتراضية، ثم تعيينها إلى "الطوب".
العودة إلى جدول المحتويات
يختار MooseFS إهمال مشكلة الملفات الصغيرة. من دليل moosefs 3.0، "حتى الملف الصغير سيشغل 64 كيلو بايت بالإضافة إلى 4 كيلو بايت من المجموع الاختباري و1 كيلو بايت للرأس"، لأنه "تم تصميمه في البداية للاحتفاظ بكميات كبيرة (مثل عدة آلاف) من الملفات الكبيرة جدًا"
يحتفظ MooseFS Master Server بجميع بيانات التعريف في الذاكرة. نفس المشكلة مثل رمز HDFS.
العودة إلى جدول المحتويات
يمكن إعداد Ceph بشكل مشابه لـ SeaweedFS كمخزن مفتاح->blob. الأمر أكثر تعقيدًا، مع الحاجة إلى دعم الطبقات فوقه. هنا مقارنة أكثر تفصيلا
لدى SeaweedFS مجموعة رئيسية مركزية للبحث عن المجلدات المجانية، بينما يستخدم Ceph خوادم التجزئة والبيانات الوصفية لتحديد موقع كائناته. وجود معلم مركزي يجعل من السهل البرمجة والإدارة.
يعتمد Ceph، مثل SeaweedFS، على ملف تخزين العناصر RADOS. Ceph معقد نوعًا ما مع المراجعات المختلطة.
يستخدم Ceph تجزئة CRUSH لإدارة وضع البيانات تلقائيًا، وهو أمر فعال لتحديد موقع البيانات. ولكن يجب وضع البيانات وفقًا لخوارزمية CRUSH. أي تكوين خاطئ من شأنه أن يسبب فقدان البيانات. ستؤدي تغييرات الهيكل، مثل إضافة خوادم جديدة لزيادة السعة، إلى ترحيل البيانات بتكلفة إدخال/إخراج عالية لتناسب خوارزمية CRUSH. تقوم SeaweedFS بوضع البيانات عن طريق تخصيصها لأي مجلدات قابلة للكتابة. إذا فشلت الكتابة في أحد المجلدات، فما عليك سوى اختيار مجلد آخر للكتابة. تعد إضافة المزيد من المجلدات أمرًا بسيطًا قدر الإمكان.
تم تحسين SeaweedFS للملفات الصغيرة. يتم تخزين الملفات الصغيرة ككتلة واحدة متواصلة من المحتوى، مع وجود 8 بايتات غير مستخدمة على الأكثر بين الملفات. الوصول إلى الملفات الصغيرة هو قراءة القرص O(1).
يستخدم SeaweedFS Filer المتاجر الجاهزة، مثل MySql، وPostgres، وSqlite، وMongodb، وRedis، وElastic Search، وCassandra، وHBase، وMemSql، وTiDB، وCockroachCB، وEtcd، وYDB، لإدارة أدلة الملفات. لقد أثبتت هذه المتاجر فعاليتها وقابليتها للتطوير وأسهل في إدارتها.
| الأعشاب البحريةFS | قابلة للمقارنة مع Ceph | ميزة |
|---|---|---|
| يتقن | حركة الديمقراطيين الاشتراكيين | أبسط |
| مقدار | OSD | الأمثل للملفات الصغيرة |
| المدون | سيف FS | قابلة للتطوير خطيًا أو قابلة للتخصيص أو O(1) أو O(logN) |
العودة إلى جدول المحتويات
يتبع MinIO AWS S3 عن كثب ويعتبر مثاليًا لاختبار S3 API. يحتوي على واجهة مستخدم وسياسات وإصدارات جيدة وما إلى ذلك. تحاول SeaweedFS اللحاق بالركب هنا. من الممكن أيضًا وضع MinIO كبوابة أمام SeaweedFS لاحقًا.
البيانات التعريفية لـ MinIO موجودة في ملفات بسيطة. ستؤدي كل عملية كتابة ملف إلى عمليات كتابة إضافية إلى ملف التعريف المقابل.
ليس لدى MinIO تحسين للعديد من الملفات الصغيرة. يتم تخزين الملفات ببساطة كما هي على الأقراص المحلية. بالإضافة إلى ملف التعريف الإضافي والشظايا لتشفير المحو، فإنه يؤدي فقط إلى تضخيم مشكلة LOSF.
يحتوي MinIO على عدة أقراص IO لقراءة ملف واحد. يحتوي SeaweedFS على قراءات قرص O(1)، حتى بالنسبة للملفات المشفرة التي تم مسحها.
لدى MinIO تشفير محو بدوام كامل. يستخدم SeaweedFS النسخ المتماثل للبيانات الساخنة للحصول على سرعة أكبر ويطبق بشكل اختياري ترميز المحو على البيانات الدافئة.
لا يتمتع MinIO بدعم واجهة برمجة التطبيقات (API) المشابهة لـ POSIX.
لدى MinIO متطلبات محددة بشأن تخطيط التخزين. أنها ليست مرنة لضبط القدرة. في SeaweedFS، ما عليك سوى تشغيل خادم حجم واحد يشير إلى الخادم الرئيسي. هذا كل شيء.
هذا مشروع مثير للغاية! ونحن بحاجة إلى مساعدين ودعم!
العودة إلى جدول المحتويات
دليل التثبيت للمستخدمين الذين ليسوا على دراية بـ golang
الخطوة 1: قم بالتثبيت على جهازك وقم بإعداد البيئة باتباع الإرشادات الموجودة على:
https://golang.org/doc/install
تأكد من تحديد $GOPATH الخاص بك
الخطوة 2: الخروج من هذا الريبو:
git clone https://github.com/seaweedfs/seaweedfs.gitالخطوة 3: قم بتنزيل المشروع وتجميعه وتثبيته عن طريق تنفيذ الأمر التالي
cd seaweedfs/weed && make install بمجرد الانتهاء من ذلك، ستجد "weed" القابل للتنفيذ في دليل $GOPATH/bin الخاص بك
العودة إلى جدول المحتويات
عند اختبار أداء القراءة على SeaweedFS، فإنه يصبح في الأساس اختبارًا لأداء سرعة القراءة العشوائية لمحرك الأقراص الثابتة لديك. عادةً ما تحصل محركات الأقراص الثابتة على سرعة تتراوح بين 100 ميجابايت/ثانية إلى 200 ميجابايت/ثانية.
لتعديل الملفات الصغيرة أو حذفها، يجب على SSD حذف كتلة كاملة في كل مرة، ونقل المحتوى الموجود في الكتل الموجودة إلى كتلة جديدة. يكون SSD سريعًا عندما يكون جديدًا تمامًا، ولكنه سيتم تجزئته بمرور الوقت وسيتعين عليك جمع البيانات المهملة وضغط الكتل. يعد SeaweedFS صديقًا لـ SSD نظرًا لأنه ملحق فقط. يتم الحذف والضغط على مستوى الصوت في الخلفية، دون إبطاء القراءة وعدم التسبب في التجزئة.
العودة إلى جدول المحتويات
نتائج جهاز واحد غير علمي على جهاز Mac Book مزود بقرص الحالة الصلبة، وحدة المعالجة المركزية: 1 Intel Core i7 بسرعة 2.6 جيجا هرتز.
اكتب مليون ملف بحجم 1 كيلو بايت:
Concurrency Level: 16
Time taken for tests: 66.753 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106789009 bytes
Requests per second: 15708.23 [#/sec]
Transfer rate: 16191.69 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.3 1.0 84.3 0.9
Percentage of the requests served within a certain time (ms)
50% 0.8 ms
66% 1.0 ms
75% 1.1 ms
80% 1.2 ms
90% 1.4 ms
95% 1.7 ms
98% 2.1 ms
99% 2.6 ms
100% 84.3 ms
قراءة عشوائية مليون ملف:
Concurrency Level: 16
Time taken for tests: 22.301 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106812873 bytes
Requests per second: 47019.38 [#/sec]
Transfer rate: 48467.57 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.0 0.3 54.1 0.2
Percentage of the requests served within a certain time (ms)
50% 0.3 ms
90% 0.4 ms
98% 0.6 ms
99% 0.7 ms
100% 54.1 ms
make benchmark
warp: Benchmark data written to "warp-mixed-2023-10-16[102354]-l70a.csv.zst"
Mixed operations.
Operation: DELETE, 10%, Concurrency: 20, Ran 4m59s.
* Throughput: 6.19 obj/s
Operation: GET, 45%, Concurrency: 20, Ran 5m0s.
* Throughput: 279.85 MiB/s, 27.99 obj/s
Operation: PUT, 15%, Concurrency: 20, Ran 5m0s.
* Throughput: 89.86 MiB/s, 8.99 obj/s
Operation: STAT, 30%, Concurrency: 20, Ran 5m0s.
* Throughput: 18.63 obj/s
Cluster Total: 369.74 MiB/s, 61.79 obj/s, 0 errors over 5m0s.
لرؤية إحصائيات الطلب المجزأة، استخدم المعلمة --analyze.v.
warp analyze --analyze.v warp-mixed-2023-10-16[102354]-l70a.csv.zst
18642 operations loaded... Done!
Mixed operations.
----------------------------------------
Operation: DELETE - total: 1854, 10.0%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 6.19 obj/s
Requests considered: 1855:
* Avg: 104ms, 50%: 30ms, 90%: 207ms, 99%: 1.355s, Fastest: 1ms, Slowest: 4.613s, StdDev: 320ms
----------------------------------------
Operation: GET - total: 8388, 45.3%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.12 +0500 +05
* Throughput: 279.77 MiB/s, 27.98 obj/s
Requests considered: 8389:
* Avg: 221ms, 50%: 106ms, 90%: 492ms, 99%: 1.739s, Fastest: 8ms, Slowest: 8.633s, StdDev: 383ms
* TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 171ms, 99th: 669ms, Worst: 4.783s StdDev: 163ms
* First Access: Avg: 240ms, 50%: 105ms, 90%: 511ms, 99%: 2.08s, Fastest: 12ms, Slowest: 8.633s, StdDev: 480ms
* First Access TTFB: Avg: 88ms, Best: 2ms, 25th: 24ms, Median: 38ms, 75th: 64ms, 90th: 179ms, 99th: 919ms, Worst: 4.783s StdDev: 199ms
* Last Access: Avg: 219ms, 50%: 106ms, 90%: 463ms, 99%: 1.782s, Fastest: 9ms, Slowest: 8.633s, StdDev: 416ms
* Last Access TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 161ms, 99th: 657ms, Worst: 4.783s StdDev: 176ms
----------------------------------------
Operation: PUT - total: 2688, 14.5%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 89.83 MiB/s, 8.98 obj/s
Requests considered: 2689:
* Avg: 1.165s, 50%: 878ms, 90%: 2.015s, 99%: 5.74s, Fastest: 99ms, Slowest: 8.264s, StdDev: 968ms
----------------------------------------
Operation: STAT - total: 5586, 30.2%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.113 +0500 +05
* Throughput: 18.63 obj/s
Requests considered: 5587:
* Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 80ms, Fastest: 0s, Slowest: 245ms, StdDev: 17ms
* First Access: Avg: 14ms, 50%: 10ms, 90%: 33ms, 99%: 69ms, Fastest: 0s, Slowest: 203ms, StdDev: 16ms
* Last Access: Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 74ms, Fastest: 0s, Slowest: 203ms, StdDev: 17ms
Cluster Total: 369.64 MiB/s, 61.77 obj/s, 0 errors over 5m0s.
Total Errors:0.
العودة إلى جدول المحتويات
مرخص بموجب ترخيص Apache، الإصدار 2.0 ("الترخيص")؛ لا يجوز لك استخدام هذا الملف إلا وفقًا للترخيص. يمكنك الحصول على نسخة من الترخيص على
http://www.apache.org/licenses/LICENSE-2.0
ما لم يكن ذلك مطلوبًا بموجب القانون المعمول به أو تم الاتفاق عليه كتابيًا، يتم توزيع البرامج الموزعة بموجب الترخيص على أساس "كما هي"، دون ضمانات أو شروط من أي نوع، سواء كانت صريحة أو ضمنية. راجع الترخيص لمعرفة الأذونات والقيود التي تحكم اللغة المحددة بموجب الترخيص.
نص هذه الصفحة متاح للتعديل وإعادة الاستخدام بموجب شروط Creative Commons Attribution-Sharealike 3.0 Unported License وترخيص GNU Free Documentation License (غير مُصدر، مع عدم وجود أقسام ثابتة، أو نصوص الغلاف الأمامي، أو نصوص الغلاف الخلفي).
العودة إلى جدول المحتويات
