وقتی SQL (و روش ذخیره شده) خیلی آهسته اجرا می شود ، چه کاری باید انجام دهیم؟

به عنوان متداول ترین زبان پردازش داده ها ، SQL در بسیاری از سناریوها مانند پرس و جو و کار دسته ای به طور گسترده مورد استفاده قرار می گیرد. هنگامی که مقدار داده بزرگ است ، SQL (و روش ذخیره شده) اغلب منجر به دویدن بسیار کند می شود. در این حالت ، نیاز به بهینه سازی SQL دارد. برای بهینه سازی SQL ، برخی از روشهای خاص سیستم شده وجود دارد. به طور معمول ، برای یافتن دلیل ، ابتدا باید برنامه اجرای را بررسی کنیم و سپس به روشی هدفمند بازنویسی کنیم تا به هدف بهینه سازی برسیم. به عنوان مثال ، برای قضاوت اعداد مداوم ، می توانیم از بین برای جایگزینی استفاده کنیم ، از عبارت SELECT برای مشخص کردن نام فیلد ، استفاده از اتحادیه برای جایگزینی اتحادیه استفاده کنیم و بازنویسی وجود دارد. البته برخی از روش های بهینه سازی در عمل مانند ایجاد یک شاخص و استفاده از جدول/جدول تجمع موقت در دسترس هستند. به طور خلاصه ، بسیاری از روش های بهینه سازی وجود دارد ، و من معتقدم که هر DBA برای آنها غریبه نخواهد بود.

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

آیا راه حل دیگری وجود دارد؟

SQL و همچنین پایگاه داده رابطه ای را با هم دور کنید!

پس از چه چیزی باید استفاده کنیم؟

SQL نمی تواند این الگوریتم های با کارایی بالا را توصیف کند. در مورد جاوا یا C ++ چطور؟

مشکلی نیست! از لحاظ تئوریکی ، هر الگوریتم می تواند در جاوا و C ++ اجرا شود ، و از آنجا که می توان اقدامات سطح پایین رایانه را کنترل کرد ، کدی که به دو زبان نوشته شده است معمولاً با سرعت بالایی اجرا می شود (تا زمانی که توانایی برنامه نویس به اندازه کافی مناسب باشد).

با این حال ، مرغ های خود را قبل از تخم گذاری حساب نکنید. اگرچه الگوریتم های با کارایی بالا می توانند در هر یک از این زبان ها کدگذاری شوند ، اما آنها بیش از حد بومی هستند و هیچ کتابخانه محاسباتی با کارایی بالا برای پردازش داده ها ارائه نمی دهند. بنابراین ، برای اجرای چنین الگوریتم ها در جاوا یا C ++ ، باید از ابتدا شروع کنید ، که شما را خسته می کند. بیایید هش را به عنوان نمونه بپیوندیم. در صورت استفاده از جاوا ، حداقل صدها خط کد برای اجرای پیوستن هش مورد نیاز است ، که نه تنها به طراحی توابع هش مناسب نیاز دارد بلکه برای حل تعارضات احتمالی هش ، میزان کار در انجام این فرآیند بزرگ خواهد بود. علاوه بر این ، انجام برنامه نویسی چند رشته ای در جاوا آسان نیست ، اما محاسبات موازی روشی مؤثر برای بهبود عملکرد محاسبات است. به همین ترتیب ، بسیاری از الگوریتم های دیگر در محاسبه داده های ساختاری وجود دارند ، و می توانید تصور کنید که اگر چنین الگوریتم هایی توسط خودتان کدگذاری شوند ، چقدر پیچیده خواهد بود. اگر اجرای یک محاسبه بسیار پیچیده باشد ، و هزینه توسعه آن به مراتب از بهینه سازی عملکرد فراتر می رود ، هیچ اهمیتی برای بهینه سازی آن وجود ندارد.

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

سپس ، آیا ما باید کندی SQL را تحمل کنیم؟

نه ، SPL یک جایگزین عالی است!

SPL و عملکرد بالا

منبع باز SPL (زبان فرآیند ساختاری) یک زبان برنامه نویسی است که به طور خاص برای پردازش داده های ساختاری استفاده می شود ، که می تواند محاسبه ای را که در ابتدا در SQL رمزگذاری شده است سریعتر انجام دهد.

چرا؟ آیا یک فناوری جالب وجود دارد که می تواند سخت افزار را در SPL سرعت بخشد؟

واقعاً نیست نرم افزار نمی تواند عملکرد محاسبات سخت افزار را سرعت بخشد ، بنابراین SPL نیز انجام می شود. به بیان ساده تر ، دلیل استفاده از SPL می تواند محاسبه را سریعتر اجرا کند این است که از الگوریتم های با کارایی بالاتر همانطور که در بالا ذکر شد استفاده می کند. SPL تعداد زیادی از کتابخانه های اساسی الگوریتم با کارایی بالا را ارائه می دهد. کد مبتنی بر این کتابخانه ها می تواند به طور مؤثر میزان محاسبه را کاهش دهد. هنگام برنامه نویسی در SPL ، می توانیم از این الگوریتم ها در ترکیب استفاده کنیم. اگر هر محاسبه کمی سریعتر اجرا شود ، به طور کلی بسیار سریعتر خواهد بود ، تا عملکرد محاسبات را بهبود بخشد.

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

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

در اینجا برخی از الگوریتم های با کارایی بالا در موارد SPL و مقایسه با SQL آورده شده است:

مهارت بهینه سازی عملکرد: برای سرعت بخشیدن به گروه بندی چند منظوره از Traverse چند منظوره استفاده کنید

مهارت بهینه سازی عملکرد ： TOPN

مهارت بهینه سازی عملکرد: قبل از پیوستن

مهارت بهینه سازی عملکرد: شماره گذاری کلید خارجی

مهارت بهینه سازی عملکرد: جدول پیوست شده

الگوریتم پارتیشن بندی یک طرفه SPL

مهارت بهینه سازی عملکرد: گروه بندی سفارش داده شده

…

برای همان کار محاسباتی ، از آنجا که SPL مفهومی را که با SQL متفاوت است ، استفاده می کند ، از روش محاسبات با پیچیدگی های مختلف (پایین) می توان استفاده کرد.

در عمل ، SPL در حال حاضر بسیاری از موارد بهینه سازی عملکرد را انجام داده است ، و سرعت در حال اجرا این موارد حداقل چندین برابر ، حداکثر ده ها بار و حتی هزاران بار در موارد شدید افزایش می یابد. ترتیب افزایش سرعت در سرعت اساساً یک هنجار است.

به عنوان مثال ، در مورد “بهینه سازی دسته ای از بیمه نامه های خودرو از یک شرکت بیمه” (منبع باز SPL بهینه می کند که دسته ای از شرکت بیمه را از 2 ساعت به 17 دقیقه کار می کند) ، با استفاده از SPL زمان محاسبه را از 2 ساعت به 17 دقیقه کاهش می دهد ، در حالی که میزان کد را 2/3 کاهش می دهد. در این حالت ، از فناوری گذرگاه چند منظوره منحصر به فرد از SPL استفاده می شود ، که می تواند چندین عملیات را در یک فرآیند گذر داده های بزرگ انجام دهد ، از این طریق به طور موثری میزان دسترسی را به ذخیره خارجی کاهش می دهد. این مورد شامل سه عملیات ارتباط و تجمیع در یک جدول بزرگ است. در صورت استفاده از SQL ، جدول بزرگ باید سه بار طی شود ، در حالی که استفاده از SPL فقط باید یک بار آن را طی کند. علاوه بر این ، از روشهای مختلفی برای عملکرد ارتباط در این حالت استفاده می شود ، بنابراین بهبود عملکرد عظیمی به دست می آید.

مورد دیگر (منبع باز SPL باعث می شود که پیش از پرس و جو در حساب موبایل بانکی به انجمن زمان واقعی تبدیل شود) ، با استفاده از SPL ، پرس و جو حساب موبایل را که فقط می تواند از قبل در ارتباط باشد ، در حالی که تعداد سرورها را از 6 به 1 کاهش می دهد ، تبدیل می کند. خواندن تمام داده های یک حساب به صورت یک حساب به طور مؤثر ، زمان دسترسی به دیسک سخت (ذخیره مداوم فیزیکی) را کاهش می دهد ، و با کمک فن آوری انجمن کلیدی در زمان واقعی که جدول ابعاد را از جدول واقعیت متمایز می کند ، فقط با استفاده از یک دستگاه واحد ، پرس و جو انجمن در زمان واقعی را پیاده سازی می کند. در نتیجه ، عملکرد به میزان قابل توجهی بهبود می یابد و تعداد سخت افزار مورد نیاز بسیار کاهش می یابد.

موارد زیر برخی از سناریوهای تجاری مشترک است که می توانند از کتابخانه الگوریتم SPL برای به دست آوردن عملکرد بالا استفاده کنند:

چگونه می توان Run Run را سریعتر کرد؟

چگونه پایگاه داده در حافظه مزیت حافظه را به بازی می رساند؟

نحوه کارآمدتر کردن انبار داده ذخیره ستونی

چگونه می توان با پرس و جو حساب Conccurrency مقابله کرد؟

کلید اصلی برای سریعتر تجزیه و تحلیل پروفایل کاربر چند تایی چیست؟

تجزیه و تحلیل رفتار کاربر BIG DATA را با استفاده از ساختار سفارش دو بعدی سرعت بخشید

برای یادگیری دلیل عملکرد بالای SPL ، بازدید کنید: چگونه بهبود عملکرد توسط سفارشات بزرگی اتفاق افتاد ، جایی که یک تجزیه و تحلیل دقیق و موارد بهینه سازی واقعی تر برای مرجع ارائه می شود.

بحث بیشتر

حال ممکن است فکر کنید که محاسبه تا زمانی که یادگیری SPL SYNT را می توان سرعت بخشید. آیا درست است؟

در واقع ، این ساده نیست.

درباره الگوریتم ها
عملکرد بالاتر به دست آمده در SPL به نحو SPL نسبت نمی دهد. اگرچه SPL SYNTAX ویژگی های خاص خود را دارد ، اما دلیل اساسی دویدن سریع نیست. مهمترین چیز تسلط و اعمال الگوریتم های با کارایی بالا است.

بهینه سازی عملکرد به دو مرحله نیاز دارد: مرحله 1 ، طراحی یک طرح محاسبات کمتری. مرحله 2 ، این طرح را با هزینه کافی اجرا کنید. مرحله 1 مهمتر است ، که باید توسط برنامه نویسان با تجربه و دانش از درجه خاصی (توانایی تسلط و اعمال الگوریتم های با کارایی بالا) تهیه شود و مرحله 2 می تواند در SPL اجرا شود. به عبارت دیگر ، SPL برای طراحی راه حل مشکل استفاده نمی شود ، بلکه اجرای راه حل را آسان تر می کند.

نحو SPL بسیار ساده و بسیار ساده تر از جاوا است. در اصل ، شما می توانید طی دو ساعت شروع کنید و در دو یا سه هفته نسبتاً ماهر باشید. اما برای الگوریتم ، اینگونه نیست ، شما باید قبل از تسلط بر آن سخت و دوباره تمرین کنید و دوباره و دوباره تمرین کنید. برعکس ، تا زمانی که شما به الگوریتم تسلط داشته باشید ، چه نوع نحو نسبتاً کم اهمیت است (البته استفاده از زبان خیلی ترسیم شده مانند SQL هنوز کار نمی کند). این دقیقاً مانند معالجه بیمار است ، فقط پس از یافتن علت آسیب شناختی ، پزشک می تواند تعیین کند که کدام دارو کار می کند. برای درمان بیماری ، می توانید داروی آماده را مستقیماً (دقیقاً مانند استفاده از SPL محصور شده) خریداری کنید یا گیاهان موجود در کوه را جمع کنید (مانند استفاده از جاوا/C ++ به کد سخت). هر دو روش می توانند بیماری را درمان کنند ، تفاوت در میزان مشکل و هزینه پرداخت است.

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

الگوریتم با کارایی بالا SPL

بهینه سازی عملکرد – مقدمه

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

چرا؟

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

متأسفانه ، بیشتر سناریوهای محاسباتی آهسته که با آنها روبرو هستیم ، داده های فشرده است. اگر داده ها هنوز در پایگاه داده ذخیره شده باشند ، خواندن داده ها مدت زمان زیادی طول می کشد (راندمان IO بسیار کم است) به این دلیل که سرعت خواندن داده ها از طریق درایور داده های پایگاه داده (مانند JDBC) به طور کلی بسیار کند است ، و این بار اغلب از زمان محاسبه بعدی در SPL فراتر می رود ، و از این رو غیرممکن است که بتوانید اثر بهینه سازی را بدست آورید. علاوه بر این ، تعداد کمی از الگوریتم های SPL نیاز دارند که داده ها به روشی خاص ذخیره شوند. به عنوان مثال ، الگوریتم پارتیشن بندی یک طرفه نیاز به ذخیره داده ها به ترتیب دارد. با این حال ، بانک اطلاعاتی رابطه ای معمولی نمی تواند چنین الزامی را تضمین کند ، بنابراین این الگوریتم ها نمی توانند انجام شوند.

به منظور حل این مشکل ، SPL مکانیسم ذخیره سازی خود را فراهم می کند ، یعنی مستقیماً از سیستم فایل استفاده می کند و داده ها را از پایگاه داده به پرونده هایی با فرمت خاص صادر می کند. از طریق این مکانیسم ، نه تنها می توان یک بهره وری دسترسی به IO بالاتر و توانایی مدیریت انعطاف پذیر سیستم فایل را بدست آورد ، بلکه می توان از مزایای ذخیره سازی داده های خود به طور کامل مانند ذخیره ستونی ، سفارش ، فشرده سازی و تقسیم بندی موازی استفاده کرد ، از این طریق به طور موثر بازی را به اثر الگوریتم های با کارایی بالا می دهد.

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

درباره پرس و جو در زمان واقعی
اگر داده ها همه از پایگاه داده خارج شوند ، آیا اجرای محاسبه داده های زمان واقعی غیرممکن است؟ از این گذشته ، داده های جدید همیشه به طور مداوم تولید می شوند.

بله ، می تواند

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

راه شروع کار

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

برای حل این مشکل ، تیم SPL همچنین خدمات مشاوره مربوطه را ارائه می دهد: شما می توانید مشکل عملکردی را که با آن روبرو شده اید به ما بگویید و با ما همکاری کنید تا یک راه حل بهینه سازی را مورد بحث قرار دهید و طراحی کنید و در صورت لزوم نیز می توان یک POC را انجام داد.

اگر با یک مشکل عملکرد روبرو هستید و از ما می خواهید به شما کمک کنیم ، امیدواریم که بتوانید اطلاعات لازم را در زیر ارائه دهید: سناریوی کسب و کار ، نقاط درد که با آنها روبرو می شوید ، مقدار داده ، شماره همزمانی و زمان پاسخ محاسبات فعلی خود. بهتر است اگر اسکریپت های SQL ، ساختار جدول و داده های آزمایش را ارائه دهید. اگر سوالی دارید از طریق ایمیل به ما در: spl@scudata.com ایمیل کنید.

به ما اعتماد کنید زیرا ما هرگز نتوانستیم.

با تجربه یک یا دو مورد ، برنامه نویسان با روش تفکر در SPL آشنا می شوند (مثل این است که آنها درک می کنند که چگونه فرمان و شتاب دهنده را کار می کنند) ، پس از آن ، بهینه سازی عملکرد خود مشکلی نخواهد بود.

در زمینه محاسبات ، سرعت برنده را تعیین می کند. با این حال ، تنها با تسلط بر جوهر و روش سرعت می توانید شکست ناپذیر باشید. فکر می کنی؟

کد منبع SPL و بسته