بازنویسی Cassandra با ++C با کارآیی ۱۰ برابر: Scylla DB

ebrahim · اکتبر 7، 2015، 3:50ق.ظ

http://www.scylladb.com/

جالبی‌ش این هست که حتی قالب روی لوح‌اش (On-Disk Format) کاملاً با Cassandra سازگاره.

افزایش کارآیی ۱۰ برابری، ادعای خودشان است.

aligorji110 · اکتبر 9، 2015، 1:12ب.ظ

چقدر محصول خفنی!
و چه تیم خفنی!

sayyid · اکتبر 10، 2015، 8:07ق.ظ

تجربه به من نشون داده که شرکت‌ها موقع تبلیغ محصولاتشون، حرف مفت زیاد می‌زنن! با عرض پوزش!
یه مثال:
http://googlecloudplatform.blogspot.com/2015/05/introducing-Google-Cloud-Bigtable.html

البته احتمالاً نتونید بازش کنید! اون بخشیش که مد نظرم بود رو اینجا میارم:

هر چند که در خفانت(!) گوگل و این که یه سر و گردن که چه عرض کنم، هفت-هشت تا هیکل از رقباش جلوتره شکی نیست، ولی به نظر می‌رسه توی این مقایسه یه مقدار اغراق کرده باشه!

صحبت سر این نیست که خالی ببندن ها، مسئله اینه که تمام واقعیت رو نمی‌گن و در نتیجه آدم گمراه می‌شه. بالاخره کار تبلیغاتیه دیگه!

اما استدلالم چیه؟ اینه:
معمولاً وقتی که شما داری Big Data کار می‌کنی، داده‌ات واقعاً Big هست! در حدی که احتمالاً از هارد-دیسک‌های SATA استفاده می‌کنی، مثلاً اگه خیلی خفن باشی، روی هر سیستم ۴ تا یا ۶ تا (یا حتی بیشتر!) هارد ۶ ترابایتی می‌ذاری (می‌شه به معمولی‌ترش هم فکر کرد، مثلاً ۳ تا هارد ۳ ترابایتی)، و داده‌ات رو روی اونها ذخیره می‌کنی. در نتیجه موقع دسترسی به داده، معمولاً bottleneck اصلیت می‌شه Random-Access به هارد دیسک (همونطور که احتمالاً می‌دونید، هر seek توی هاردهای معمولی SATA حدوداً ۵ میلی‌ثانیه طول می‌کشه، بعضی وقتها هم ۱۰ میلی‌ثانیه توی محاسبات براش در نظر می‌گیرن). حالا سؤال اصلی بنده اینجاس: این پایگاه داده‌ی خفن! چطوری تونسته با تغییر زبان از جاوا به ++C سرعت دسترسی به هارددیسک رو بالا ببره؟!!!
نتیجه‌گیری اخلاقی اینه که bottleneck دوستان توی تستشون هارددیسک نبوده. در نتیجه یا Random-Access نداشتن و به صورت sequential داده رو می‌خوندن (که باز هم احتمالاً bottleneck شما می‌شه پهنای باند دیسک که حدود ۱۳۰ مگابایت در ثانیه هست)، یا چیزی که محتمل‌تر هست اینه که bottleneck دوستان CPU بوده، که این اتفاق در صورتی می‌افته که داده‌ی شما روی هارد SSD باشه (روی هارد SAS هم سرعت بالاتره، ولی بعید می‌دونم در این حد و حدود باشه). خوب حالا شما حساب کن ببین برای اون config ای که من گفتم، مثلاً روی هر سرور بخوای بالای ۱۰ ترابایت هارد داشته باشی، اگه از هارد SSD استفاده کنی، چه بلایی سر بودجه‌ی شرکت میاد؟!

نتیجه‌گیری من اینه که اینا روی یه داده‌ی نسبتاً محدود (بازم روی SSD هم می‌شه داده‌ی نسبتاً زیادی بارگذاری کرد، ولی دیگه به عددای گوگل و فیس‌بوک و شرکت‌های واقعاً BigData کار نمی‌رسه!) روی هارد SSD تست کردن، و bottleneck شون CPU بوده، تونستن یه حالت‌های خاصی رو بهینه کنن که ۱۰ برابر performance بگیرن (ممکنه اون حالت‌های خاص، حالت‌های پرکاربردی باشن ها، نگفتم به درد نمی‌خوره!).

البته یه ان‌قلت دیگه‌ای هم هست، و اون اینه که جاوا انقدرا هم بدبخت نیست! که با تبدیلش به ++C بتونی سرعت ۱۰ برابر بگیری! به همین کشکی، به همین خوشمزگی! من توی حالت‌های خاصی سرعت نزدیک ۳ برابر رو دیده بودم، ولی دیگه ۱۰ برابر خیلیه! (البته شدنیه، ولی یه مقدار بعیده!)

یه البته‌ی دیگه: به قول یکی از دوستان این آدمای زیرساخت‌کار (مثل اینا که تیم KVM بودن) وقتی وارد یه همچین کارایی می‌شن، یا به کل گند می‌زنن توی کار، یا یه چیز خیلی خفن درست می‌کنن! بنابراین هیچ بعید نیست که چیز خفنی باشه!

یه البته‌ی دیگه هم بگم! (این تریبون رو از دست من نگیری تا صبح ول‌کن نیستم! ) این که خیلی وقت‌ها نرم‌افزارهای متن‌باز، حرف خیلی می‌زنن، ولی در عمل یه جای کارشون می‌لنگه! ما بارها توی موتور یوز گیر همین مسائل افتادیم و مجبور شدیم خودمون بنویسیم. مثلاً یه چیزی رو میاری استفاده می‌کنی، خیلی هم قشنگه و همه چیز خوبه، بعد که مقیاس کار می‌ره بالا به طول کلی دیگه کار نمی‌کنه! مثلاً Solr رو ما خیلی گشتیم که ببینیم بزرگ‌ترین خوشه‌ای که ازش توی دنیا وجود داره چند تا سرور داره، که بتونیم با سیستم خودمون مقایسه‌اش کنیم. هر چی گشتیم، عددای ۴-۵ و دیگه ته تهش ۱۰ بیشتر ندیدیم! بنابراین این پایگاه داده هم باید توی مقیاس بزرگ استفاده بشه تا ببینیم که چند مرده حلّاجه! (می‌دونید که، سیستم Messaging فیس‌بوک بر پایه‌ی HBase هست، یعنی در عمل جواب داده. البته اونا HBase رو حسابی دستکاری کردن!)

ebrahim · اکتبر 10، 2015، 8:12ق.ظ

ماجرا فقط تبدیل از Java به ++C نیست، بلکه یه مقدار فراتر از این حرف‌ها است. این دوستان کل ماجرا رو دوباره معماری کرده‌اند. گلوگاه هم فقط لوح سخت (Hard Disk) نیست. به عنوان مثال این عزیزان با کارآیی پشته‌ی شبکه‌ی (Network Stack) سیستم عامل‌شون حال نکرده‌اند، برداشته‌اند کلاً دورش زده‌اند و TCP/IP رو در Userspace پیاده‌سازی کرده‌اند و با DPDK مستقیم روی کارت شبکه نوشته‌اند و خونده‌اند و این خودش شده پروژه‌ی Seastar!

خب آدم وقتی این چیزها رو می‌بینه، براش حالا ۱۰ برابر نه، دیگه ۷-۸ برابر باورپذیر می‌شه! بماند که توی همون I/Oی معمولی هم تفاوت کارآیی مشهود بین Java و ++C وجود داره. حالا امتحانش کاری نداره که، به قول خودش سرویس Cassandra رو می‌آری پائین، Scylla رو می‌آری بالا! از نتیجه خوشت نیومد، بر می‌گردونی!