آیا «پرس و جوهایی درباره جدول تریلیون ردیفی در ثانیه» وجود دارد؟ آیا “N-Times سریعتر از ORACLE” اغراق آمیز است؟

ما اغلب در مورد تبلیغات عملکرد یک محصول کلان داده می شنویم که می گویند این محصول می تواند “پرس و جوهایی را در جدول تریلیون ردیفی در چند ثانیه اجرا کند”، به این معنی که آنها می توانند داده های مطابق با شرایط مشخص شده را از یک تریلیون ردیف در دریافت کنند و برگردانند. ثانیه

آیا این درست است؟

اگر مقاله یک ترابایت داده چقدر است را خوانده باشید احتمالاً فکر نمی کنید که درست باشد؟ “. برای پردازش یک تریلیون ردیف داده، که ده ها، حتی صد ترابایت اندازه دارد، به ده ها هزار و حتی صدها هزار دیسک سخت نیاز داریم. این تقریبا غیر عملی است.

با این حال، “پرس و جو در ثانیه” لزوما به معنای پیمایش کامل نیست. اگر از شناسه‌های منحصربه‌فرد (مانند شماره تلفن، اگرچه یک تریلیون عدد وجود ندارد) برای انجام پرس و جو استفاده کنیم، میزان محاسبه بر اساس شاخص خیلی زیاد نخواهد بود و تعداد بازیابی‌ها و مقایسه‌ها در حدود چهل رایانه های امروزی می توانند این مقدار محاسبات را بدون دردسر در یک ثانیه انجام دهند، حتی در کنار بسیاری از همزمانی ها. پیچیدگی محاسباتی این نوع کار جستجوی هدف در سطح لگاریتمی است. هنگامی که حجم داده از یک میلیون ردیف به یک تریلیون ردیف افزایش می یابد، مقدار محاسباتی که کار جستجو شامل می شود تنها دو برابر افزایش می یابد. تقریباً همه پایگاه‌های داده تا زمانی که بتوانند این داده‌ها را در خود جای دهند، می‌توانند با جستجو مقابله کنند. اصلا تعجب آور نیست. البته ایجاد ایندکس بسیار کند خواهد بود، اما این چیز دیگری است.

اما اگر محاسباتی مبتنی بر پیمایش باشد چه اتفاقی خواهد افتاد؟ شاخص برای، مانند محاسبه مجموع مقادیر یک ستون خاص، بی فایده می شود.

خوب، دستیابی به “پرس و جو در ثانیه” برای چنین کار محاسباتی در جداول تریلیون ردیفی غیرعملی است، اما انجام این کار روی داده های سطح TB امکان پذیر است. اگر صد ستون داده وجود داشته باشد، یک تجمیع در یک ستون فقط باید 1٪ داده را بازیابی کند که احتمالاً 10 گیگابایت است. ده هارد دیسک برای اسکن داده ها در چند ثانیه کافی است. دستیابی به پیکربندی، حتی ده برابر بیشتر، در خوشه های سرور معاصر آسان است.

بنابراین، احتمالاً “توانایی مدیریت داده های سطح سل در چند ثانیه” واقعاً به این معنی است. هر محصول پایگاه داده می تواند این کار را انجام دهد.

برخی از محصولات پایگاه داده مانند مقایسه آنها با پایگاه های داده معروف قدیمی مانند Oracle. ما اغلب در مورد عباراتی می شنویم که می گویند محصول N برابر سریعتر از Oracle است. به نظر می رسد که آنها لاف می زنند. به عنوان محصول معیار در سطح جهانی، اگر N برابر به راحتی از آن پیشی بگیرد، اوراکل نیست.

خوب، آنها لاف نمی زنند.

Oracle عمدتا برای پردازش تراکنش (اغلب به عنوان TP شناخته می شود) به جای پردازش تحلیلی (اغلب به عنوان AP شناخته می شود) در نظر گرفته شده است. یک پایگاه داده TP باید از ذخیره سازی مبتنی بر ردیف استفاده کند در حالی که یک پایگاه داده AP معمولاً از ذخیره سازی ستونی استفاده می کند. به عنوان مثال، یک عملیات خاص فقط شامل دو ستون از یکصد ستون در یک جدول داده است. پایگاه داده Oracle مبتنی بر ردیف اساساً نیاز به خواندن تمام صد ستون دارد. اما یک پایگاه داده AP ستونی فقط نیاز به خواندن دو ستون هدف دارد. مقدار داده ای که بازیابی می شود ده ها برابر کمتر است. در این حالت طبیعی است که محاسبات N برابر سریعتر باشد. این نباید تعجب آور باشد. اگر محاسبه N برابر سریعتر نباشد، مشکل ساز خواهد شد.

به غیر از استفاده از ذخیره سازی ستونی به جای ذخیره سازی مبتنی بر ردیف، استراتژی های دیگر ممکن است شامل استفاده از خوشه ها به جای ماشین های تک، تکنیک های درون حافظه به جای استراتژی های حافظه خارجی و غیره باشد. در یک کلام، آنها سریعتر اجرا می شوند زیرا N برابر منابع بیشتری استفاده می کنند. با این حال، اگرچه آنها از اوراکل پیشی می گیرند، اما واقعاً از آن پیشی نمی گیرند.

این احتمالاً معنای “N برابر سریعتر از اوراکل بودن” است. سرعت یک واقعیت است اما ارزش لاف زدن را ندارد.

در واقع بهینه ساز اوراکل قدرتمند است. اگر برای ذخیره سازی ستونی و پشتیبانی از منابع فراوان نباشد، بسیاری از پایگاه های داده تخصصی AP لزوما سریعتر از Oracle اجرا نمی شوند، به ویژه فناوری های مبتنی بر Hadoop.

در بالا به قدرت الگوریتم سطح لگاریتمی اشاره کردیم که مقدار محاسبه را از یک تریلیون ردیف به ده ها ردیف لگاریتمی می کند. با این حال، وضعیت برعکس وجود دارد. حجم به ظاهر کم داده با مقدار نجومی محاسبات همراه است. در انجمن SPL یک سناریوی محاسباتی رصدخانه ملی نجوم وجود دارد. داده ها شامل یازده جدول است و هر جدول فقط 500000 ردیف دارد. حجم کل کمتر از 10 گیگابایت است. یک پایگاه داده توزیع شده 3.8 ساعت و 100 CPU طول می کشد تا محاسبات به پایان برسد، که درجه پیچیدگی آن در سطح ضرب است و کل محاسبات 10*500000*500000=2.5 ​​تریلیون را شامل می شود. در حال حاضر بسیار رضایت بخش است که بتوانیم کار را در چنین دوره زمانی انجام دهیم.

بنابراین، ما نمی‌توانیم به سادگی به شعارهایی نگاه کنیم که می‌گویند با چه سرعتی می‌توانند حجم عظیمی از داده‌ها را هنگام بررسی عملکرد محصولات کلان داده اجرا کنند. این گفته ها ممکن است درست باشد، اما بی معنی است. با یک الگوریتم کارآمد، می توانیم محاسبات را در 100 ترابایت در چند ثانیه انجام دهیم. بدون الگوریتم کارآمد، انجام محاسبات روی 10B می تواند N ساعت طول بکشد.

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

اما، تحت سیستم SQL، یک محصول بد می تواند بسیار بد باشد، اما یک محصول خوب حداکثر مناسب است. SQL برای چندین دهه توسعه یافته است. الگوریتم های بهینه سازی بالغ از قبل در سراسر صنعت شناخته شده است. برای زبان سخت است که چیز جدیدی به دست بیاورد. در نتیجه، فروشندگانی که تکنیک‌های بهینه‌سازی را ندارند، محصولات بسیار بدی تولید می‌کنند و کسانی که بر این تکنیک‌ها تسلط دارند، فقط می‌توانند محصولات متوسطی را طراحی کنند. پس از همه، آنها می توانند و فقط می توانند تکنیک ها را از یکدیگر کپی کنند.

با این حال، با خارج شدن از سیستم SQL، می توان الگوریتم های جدیدی را ارائه کرد. برای سناریوی Observatories که در بالا ذکر شد، در واقع الگوریتم‌هایی وجود دارند که می‌توانند یک طرف ضرب را لگاریتم کنند. مقدار محاسبه حدود 10*500000*log500000*2 است که 10000 برابر کاهش می یابد. با استفاده از این الگوریتم، esProc SPL می تواند محاسبات را در 2 دقیقه روی یک لپ تاپ 4 هسته ای به پایان برساند.

متاسفانه SQL قادر به بیان این الگوریتم نیست. فقط توصیف درست منطق محاسباتی بسیار پر زحمت است. مقدار کد بر حسب کیلوبایت اندازه گیری می شود، بهینه ساز پایگاه داده غیرفعال است و N ساعت کامل اجرا طول می کشد.