۹ دلیلی که SQL باید از کار بیفتد

چرا توسعه دهندگان زبان و DBA ها برای سازماندهی داده های ما چنین آشفتگی دارند؟ در اینجا ۹ دلیل وجود دارد که آرزو می کنیم از SQL خارج شویم، حتی اگر این کار را نکنیم.

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

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

مدل جدولی SQL آنقدر غالب است که بسیاری از پروژه‌های غیر SQL به دلیل درخواست کاربران، یک رابط SQLish اضافه می‌کنند. این حتی در مورد جنبش NoSQL نیز صادق است که برای رهایی از پارادایم قدیمی ابداع شد. در پایان، به نظر می رسد، SQL برنده شد.

محدودیت های SQL ممکن است برای هدایت آن به زباله دان کافی نباشد. توسعه دهندگان ممکن است هرگز بلند نشوند و تمام داده های خود را از SQL خارج کنند. اما مشکلات SQL به اندازه‌ای واقعی هستند که برای توسعه‌دهندگان استرس ایجاد می‌کنند، تأخیر اضافه می‌کنند و حتی برای برخی پروژه‌ها نیاز به مهندسی مجدد دارند.

در اینجا نه دلیل وجود دارد که آرزو می‌کنیم بتوانیم SQL را ترک کنیم، حتی اگر می‌دانیم که احتمالاً این کار را نمی‌کنیم.

۹ روشی که SQL اوضاع را بدتر می کند

1. جدول‌ها مقیاس ندارند
2. SQL بومی JSON یا XML نیست
3. مارشال کردن یک زمان گیر بزرگ است
4. SQL بلادرنگ کار نمی کند
5. پیوستن ها سردرد هستند
6. ستون ها فضا را هدر می دهند
7. بهینه ساز فقط گاهی کمک می کند
8. Denormalization با جداول مانند زباله رفتار می کند
9. ایده های پیچ شده می توانند پایگاه داده شما را خراب کنند

جدول ها مقیاس بندی نمی شوند

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

برخی سعی می کنند مشکل را با کنار هم قرار دادن قدیم و جدید حل کنند، مانند ادغام اشتراک گذاری در یک پایگاه داده منبع باز قدیمی. به نظر می رسد افزودن لایه ها مدیریت داده ها را ساده تر می کند و مقیاس بی نهایت ارائه می دهد. اما این لایه های اضافه شده می توانند مین ها را پنهان کنند. پردازش یک SELECT یا یک JOIN بسته به مقدار داده‌ای که در خرده‌ها ذخیره می‌شود، زمان بسیار متفاوتی می‌برد.

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

برخی از ماشین‌های AWS دارای ۲۴ ترابایت رم هستند. چرا؟ زیرا برخی از کاربران پایگاه داده به این میزان نیاز دارند. آنها داده های زیادی در پایگاه داده SQL دارند و در یک دستگاه واحد در یک بلوک RAM بسیار بهتر اجرا می شود.

SQL بومی JSON یا XML نیست

SQL ممکن است به عنوان یک زبان همیشه سبز باشد، اما با فرمت های جدیدتر تبادل داده مانند JSON، YAML، و XML به خوبی اجرا نمی شود. همه اینها از قالب سلسله مراتبی و انعطاف پذیرتری نسبت به SQL پشتیبانی می کنند. ذات پایگاه داده های SQL هنوز در مدل رابطه ای با جداول در همه جا گیر کرده است.

بازار راه‌هایی برای اثبات این شکایت رایج پیدا می‌کند. اضافه کردن یک قالب داده متفاوت مانند JSON با کد چسب مناسب نسبتاً آسان است، اما هزینه آن را با زمان از دست رفته پرداخت خواهید کرد.

برخی پایگاه‌های داده SQL اکنون می‌توانند فرمت‌های داده مدرن‌تری مانند JSON، XML، GraphQL یا YAML را به عنوان ویژگی‌های بومی رمزگذاری و رمزگشایی کنند. اما در داخل، داده ها معمولاً با استفاده از همان مدل جدولی قدیمی ذخیره و نمایه می شوند.

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

مارشالینگ یک زمان‌بندی بزرگ است

پایگاه های داده ممکن است داده ها را در جداول ذخیره کنند، اما برنامه نویسان کدی را می نویسند که با اشیا سروکار دارد. به نظر می‌رسد که بیشتر کار طراحی برنامه‌های مبتنی بر داده، یافتن بهترین راه برای استخراج داده‌ها از پایگاه داده و تبدیل آن به اشیایی است که منطق تجاری می‌تواند با آنها کار کند. سپس، فیلدهای داده از شی باید با تبدیل آنها به یک SQL upsert از هم جدا شوند. آیا راهی برای رها کردن داده ها در قالبی وجود ندارد که آماده استفاده باشد؟

SQL بلادرنگ کار نمی کند

پایگاه داده اصلی SQL برای تجزیه و تحلیل دسته ای و حالت تعاملی طراحی شده است. مدل جریان داده با خطوط لوله پردازش طولانی ایده نسبتا جدیدی است و دقیقاً مطابقت ندارد.

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

برخی از جدیدترین برنامه‌ها به عملکرد در زمان واقعی بهتر نیاز دارند – نه تنها برای راحتی، بلکه به این دلیل که برنامه به آن نیاز دارد. نشستن مانند یک گورو روی کوه در دنیای مدرن و جریانی چندان خوب کار نمی کند.

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

JOIN ها سردرد هستند

قدرت پایگاه های داده رابطه ای از تقسیم داده ها به جداول کوچکتر و مختصرتر ناشی می شود. سردرد بعد از آن ظاهر می شود.

مجموعه مجدد داده‌ها با JOIN اغلب از نظر محاسباتی گران‌ترین بخش کار است، زیرا پایگاه داده باید همه داده‌ها را جابجا کند. سردرد زمانی شروع می شود که داده ها از RAM بیشتر می شوند.

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

ستون ها هدر دادن فضا هستند

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

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

بهینه ساز فقط گاهی کمک می کند

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

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

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

Denormalization با جداول مانند سطل زباله برخورد می کند

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

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

ایده‌های پیچ‌دار می‌توانند پایگاه داده شما را خراب کنند

توسعه‌دهندگان سال‌هاست که ویژگی‌های جدیدی را به SQL اضافه می‌کنند و برخی از آنها بسیار باهوش هستند. ناراحت شدن از ویژگی های جالبی که مجبور نیستید استفاده کنید، سخت است. از سوی دیگر، این زنگ‌ها و سوت‌ها اغلب بر روی آنها پیچ می‌شوند که می‌تواند منجر به مشکلات عملکرد شود. برخی از توسعه‌دهندگان هشدار می‌دهند که باید در مورد سؤالات فرعی بیشتر مراقب باشید، زیرا آنها سرعت همه چیز را کاهش می‌دهند. دیگران می گویند که انتخاب زیر مجموعه هایی مانند Common Table Expressions، Views یا Windows کد شما را بیش از حد پیچیده می کند. خالق کد می‌تواند آن را بخواند، اما دیگران در تلاش برای ثابت نگه داشتن تمام لایه‌ها و نسل‌های SQL دچار سردرد می‌شوند. مثل تماشای فیلمی از کریستوفر نولان اما به صورت رمزی است.

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