من اخیرا متوجه شدم (مثلاً به دلیل تغییرات مجوز). این من را به این فکر واداشت که در چند سال گذشته من تعداد زیادی مقاله در مورد وحشتناک بودن MongoDB دیده ام و هیچ کس نباید از آن استفاده کند. اما در این مدت، MongoDB به یک محصول بسیار بالغ‌تر تبدیل شده است. چی شد؟ آیا واقعاً تمام نفرت ناشی از اشتباهات در ابتدای بازاریابی DBMS جدید است؟ یا مردم فقط از MongoDB در مکان اشتباه استفاده می کنند؟
اگر ناگهان احساس کردید که از MongoDB دفاع می کنم، لطفا بخوانید در پایان مقاله
روند جدید
من سال‌های بیشتری در صنعت نرم‌افزار بوده‌ام، اما هنوز هم تنها بخشی از روندهایی بوده‌ام که به صنعت ما ضربه زده است. من شاهد ظهور 4GL، AOP، Agile، SOA، Web 2.0، AJAX، بلاک چین بوده ام... لیست بی پایان است. هر سال روندهای جدیدی وجود دارد. برخی به سرعت در حال محو شدن هستند، در حالی که برخی دیگر اساساً روش توسعه نرم افزار را تغییر می دهند.
در اطراف هر روند جدید، یک هیجان عمومی خاص ایجاد می شود: مردم یا خودشان به داخل قایق می پرند، یا سر و صدای ایجاد شده توسط دیگران را می بینند - و جمعیت را دنبال می کنند. این فرآیند توسط گارتنر در کدنویسی شده است . اگرچه این نمودار قابل بحث است، اما این نمودار تقریباً اتفاقاتی را که برای فناوری‌ها پیش می‌آید قبل از اینکه در نهایت برای استفاده مفید شوند، توصیف می‌کند.
اما هر از گاهی نوآوری جدیدی وجود دارد (یا یک آمدن دوم وجود دارد، مانند این مورد) که تنها توسط یک اجرای خاص آن هدایت می شود. در مورد NoSQL، تبلیغات به شدت به دلیل ظهور و ظهور MongoDB بود. MongoDB این روند را شروع نکرد: در واقع، شرکت های اینترنتی بزرگ شروع به مشکلاتی در پردازش مقادیر زیادی از داده ها کردند که منجر به بازگشت پایگاه های داده غیرمرتبط شد. جنبش عمومی با پروژه هایی مانند Bigtable گوگل و کاساندرا فیس بوک آغاز شد، اما این MongoDB بود که به معروف ترین و در دسترس ترین پیاده سازی پایگاه داده NoSQL تبدیل شد که اکثر توسعه دهندگان به آن دسترسی داشتند.
توجه: ممکن است فکر کنید که من پایگاه‌های اطلاعاتی اسناد را با پایگاه‌های داده ستونی، فروشگاه‌های کلید/مقدار یا هر یک از انواع دیگر ذخیره‌سازی داده‌ای که تحت تعریف کلی NoSQL قرار می‌گیرند، اشتباه می‌گیرم. و حق با شماست. اما در آن زمان، هرج و مرج حاکم بود. همه به NoSQL وسواس دارند، همه چیز شده است کاملاً ضروری است، اگرچه بسیاری تفاوت ها را در فناوری های مختلف نمی بینند. برای بسیاری، MongoDB تبدیل شده است مترادف با NoSQL.
و توسعه دهندگان روی آن پریدند. ایده یک پایگاه داده بدون طرحواره که به طور جادویی برای حل هر مشکلی مقیاس می شود بسیار وسوسه انگیز بود. در حدود سال 2014، به نظر می رسید که یک سال پیش در هر جایی که یک پایگاه داده رابطه ای مانند MySQL، Postgres یا SQL Server استفاده می شد، پایگاه داده های MongoDB در حال استقرار بودند. وقتی از شما پرسیده شد که چرا، می توانید پاسخ هایی از پیش پا افتاده «این مقیاس وب است» تا متفکرانه تر «داده های من ساختار بسیار ضعیفی دارند و به خوبی در یک پایگاه داده بدون طرح واره قرار می گیرند» دریافت کنید.
مهم است که به یاد داشته باشید که MongoDB و به طور کلی پایگاه‌های داده اسناد، تعدادی از مشکلات را با پایگاه‌های داده رابطه‌ای سنتی حل می‌کنند:
- طرح سختگیرانه: با یک پایگاه داده رابطه‌ای، اگر داده‌هایی را به صورت پویا تولید کرده‌اید، مجبور می‌شوید یا مجموعه‌ای از ستون‌های داده تصادفی "متفاوت" ایجاد کنید، حباب‌های داده را در آنجا فشار دهید یا از یک پیکربندی استفاده کنید. همه اینها دارای معایب قابل توجهی است.
- سختی پوسته ریزی: اگر داده‌های زیادی وجود دارد که روی یک سرور قرار نمی‌گیرد، MongoDB مکانیسم‌هایی را ارائه می‌کند که به آن اجازه می‌دهد در چندین ماشین بزرگ شود.
- اصلاحات پیچیده مدار: بدون مهاجرت! در یک پایگاه داده رابطه ای، تغییر ساختار پایگاه داده می تواند یک مشکل بزرگ باشد (به خصوص زمانی که داده های زیادی وجود دارد). MongoDB توانسته است فرآیند را تا حد زیادی ساده کند. و این کار را به قدری آسان کرد که می توانید طرحواره را در حال حرکت به روز کنید و واقعاً سریع ادامه دهید.
- عملکرد را بنویسید: عملکرد MongoDB خوب بود، به خصوص زمانی که به درستی تنظیم شود. حتی پیکربندی خارج از جعبه MongoDB که اغلب به خاطر آن مورد انتقاد قرار می گرفت، ارقام عملکردی چشمگیر را نشان می داد.
همه خطرات متوجه شماست
مزایای بالقوه MongoDB بسیار زیاد بود، به خصوص برای کلاس های خاصی از مشکلات. اگر لیست بالا را بدون درک زمینه و نداشتن تجربه بخوانید، ممکن است این تصور را داشته باشید که MongoDB واقعا یک DBMS انقلابی است. تنها مشکل این بود که مزایای ذکر شده در بالا با تعدادی اخطار همراه بود که برخی از آنها در زیر ذکر شده است.
اگر منصف باشیم، هیچ کس در 10gen/MongoDB Inc. نخواهم گفت که موارد زیر درست نیست، اینها فقط سازش هستند.
- از دست دادن معاملاتپاسخ: تراکنش‌ها یکی از ویژگی‌های اصلی بسیاری از پایگاه‌های داده رابطه‌ای هستند (نه همه، بلکه بیشتر). تراکنش به این معنی است که می توانید چندین عملیات را به صورت اتمی انجام دهید و اطمینان حاصل کنید که داده ها ثابت می مانند. البته، با یک پایگاه داده NoSQL، تراکنشی می تواند در یک سند واحد باشد، یا می توانید از commit های دو فازی برای دریافت معنای تراکنشی استفاده کنید. اما شما باید خودتان این قابلیت را پیاده سازی کنید... که می تواند کاری دشوار و زمان بر باشد. اغلب تا زمانی که نبینید که داده‌های پایگاه داده به حالت‌های نامعتبر می‌رسند، متوجه مشکل نمی‌شوید، زیرا تضمین اتمی بودن عملیات غیرممکن است. توجه: خیلی ها به من گفته اند که تراکنش ها در MongoDB 4.0 در سال گذشته معرفی شدند، اما با محدودیت هایی. نتیجه مقاله یکسان است: ارزیابی کنید که چگونه فناوری با نیازهای شما مطابقت دارد.
- از دست دادن یکپارچگی رابطه (کلیدهای خارجی): اگر داده های شما دارای روابط هستند، باید آنها را در برنامه اعمال کنید. داشتن پایگاه داده ای که به این روابط احترام می گذارد، کار زیادی را از برنامه و در نتیجه بر روی برنامه نویسان شما می گیرد.
- ناتوانی در اعمال ساختار داده: طرحواره های سختگیرانه گاهی اوقات می توانند مشکل بزرگی باشند، اما در صورت استفاده عاقلانه، مکانیسم قدرتمندی برای ساختاردهی خوب داده ها نیز هستند. پایگاه داده های اسنادی مانند MongoDB انعطاف پذیری طرحواره ای باورنکردنی را ارائه می دهند، اما این انعطاف پذیری مسئولیت تمیز نگه داشتن داده ها را از بین می برد. اگر مراقب آنها نباشید، در نهایت کدهای زیادی را در برنامه خود می نویسید تا داده هایی را که به شکل مورد نظر شما ذخیره نمی شوند، حساب کنید. همانطور که اغلب در شرکت ما Simple Thread می گویند… برنامه روزی بازنویسی می شود، اما داده ها برای همیشه زنده می مانند. توجه: MongoDB از اعتبار سنجی طرحواره پشتیبانی می کند که مفید است اما تضمین های مشابه یک پایگاه داده رابطه ای را ارائه نمی دهد. اول از همه، افزودن یا تغییر اعتبار سنجی طرحواره تأثیری بر داده های موجود در مجموعه ندارد. باید مطمئن شوید که داده ها را مطابق طرح جدید به روز می کنید. خودتان تصمیم بگیرید که آیا این برای نیازهای شما کافی است یا خیر.
- زبان پرس و جو خود / از دست دادن اکوسیستم ابزار: ظهور SQL یک انقلاب مطلق بود و از آن زمان تاکنون چیزی تغییر نکرده است. این یک زبان فوق العاده قدرتمند، اما همچنین بسیار پیچیده است. نیاز به ساخت پرس و جوهای پایگاه داده در یک زبان جدید، متشکل از قطعات JSON، به عنوان یک گام بزرگ از سوی افرادی که با SQL تجربه دارند، در نظر گرفته می شود. مجموعه کاملی از ابزارها وجود دارد که با پایگاه‌های داده SQL از IDE گرفته تا ابزارهای گزارش‌دهی تعامل دارند. انتقال به پایگاه داده‌ای که از SQL پشتیبانی نمی‌کند به این معنی است که نمی‌توانید از بیشتر این ابزارها استفاده کنید یا برای استفاده از آنها باید داده‌ها را به SQL تبدیل کنید، که می‌تواند دشوارتر از آنچه فکر می‌کنید باشد.
بسیاری از توسعه دهندگانی که به MongoDB روی آوردند، واقعاً این مبادلات را درک نکردند، و اغلب با سر به راه انداختن آن به عنوان ذخیره داده اصلی خود بودند. پس از آن، اغلب بازگشت به عقب بسیار دشوار بود.
چه کاری می توانست متفاوت انجام شود؟
همه اول سر نپریدند و به پایین سقوط نکردند. اما بسیاری از پروژه‌ها پایه MongoDB را در جایی نصب کرده‌اند که به سادگی مناسب نیست - و باید سال‌های بیشتری با آن زندگی کنند. اگر این سازمان‌ها برای بررسی روشمند انتخاب‌های فناوری خود زمان می‌بردند، بسیاری از آنها انتخاب متفاوتی می‌کردند.
چگونه فناوری مناسب را انتخاب کنیم؟ چندین تلاش برای ایجاد یک چارچوب سیستماتیک برای ارزیابی فناوری انجام شده است، مانند и ، اما به نظر من این یک پیچیدگی غیر ضروری است.
تنها با پرسیدن دو سوال اساسی می توان به بسیاری از فناوری ها به صورت هوشمندانه ارزش گذاری کرد. مشکل در یافتن افرادی است که می توانند مسئولانه به آنها پاسخ دهند، زمان صرف یافتن پاسخ و بدون تعصب.
اگر با مشکلی مواجه نشدید، به ابزار جدیدی نیاز ندارید. نقطه.
سوال 1: چه مشکلاتی را می خواهم حل کنم؟
اگر با مشکلی مواجه نشدید، به ابزار جدیدی نیاز ندارید. نقطه. نیازی نیست به دنبال راه حل باشید و سپس به یک مشکل برسید. مگر اینکه با مشکلی روبرو شوید که فناوری جدید به طور قابل توجهی بهتر از فناوری موجود شما حل نمی کند، در اینجا چیزی برای بحث وجود ندارد. اگر می‌خواهید از این فناوری استفاده کنید زیرا دیده‌اید که دیگران از آن استفاده می‌کنند، به مشکلاتی که آنها دارند فکر کنید و بپرسید که آیا شما این مشکلات را دارید یا خیر. پذیرفتن فناوری آسان است زیرا دیگران از آن استفاده می کنند، مشکل این است که بدانید آیا شما با همین مسائل روبرو هستید یا خیر.
سوال 2: چه چیزی را از دست داده ام؟
مطمئناً این سؤال دشوارتر است، زیرا باید هم فناوری قدیمی و هم فناوری جدید را به خوبی کاوش و درک کنید. گاهی اوقات تا زمانی که چیزی با آن نسازید یا یک همکار با آن تجربه نداشته باشید، واقعا نمی توانید یک مورد جدید را درک کنید.
اگر هیچ کدام را ندارید، پس منطقی است که در مورد حداقل سرمایه ممکن برای تعیین ارزش این ابزار فکر کنید. و اگر سرمایه گذاری کنید، تغییر تصمیم چقدر دشوار خواهد بود؟
مردم همیشه همه چیز را خراب می کنند
در تلاش برای پاسخ دادن به این سوالات تا حد امکان بی طرفانه، یک چیز را به خاطر بسپارید: باید با طبیعت انسان مبارزه کنید. تعدادی از سوگیری های شناختی وجود دارد که برای ارزیابی موثر فناوری باید بر آنها غلبه کرد. در اینجا فقط چند مورد است:
- همه او را می شناسند، اما هنوز مبارزه با او سخت است. فقط مطمئن شوید که این فناوری واقعاً با نیازهای واقعی شما مطابقت دارد.
- بسیاری از توسعه دهندگان تمایل دارند فناوری هایی را که برای مدت طولانی با آنها کار کرده اند دست کم بگیرند و مزایای یک فناوری جدید را بیش از حد ارزیابی کنند. نه تنها برنامه نویسان، همه در معرض این سوگیری شناختی هستند.
- ما تمایل داریم آنچه را که هست ببینیم و آنچه نیست را از دست بدهیم. این می تواند منجر به هرج و مرج، همراه با اثر جدید شود، زیرا شما نه تنها ذاتاً فناوری جدید را بیش از حد ارزش گذاری می کنید، بلکه کاستی های آن را نیز نادیده می گیرید..
ارزیابی عینی آسان نیست، اما درک سوگیری های شناختی زمینه ای به شما کمک می کند تا تصمیمات منطقی تری بگیرید.
خلاصه
هنگامی که یک نوآوری ظاهر می شود، باید به دو سوال با دقت فراوان پاسخ داده شود:
- آیا این ابزار یک مشکل واقعی را حل می کند؟
- آیا ما در درک مبادلات خوب هستیم؟
اگر نمی توانید با اطمینان به این دو سوال پاسخ دهید، چند قدم به عقب برگردید و فکر کنید.
بنابراین آیا la MongoDB به طور کلی انتخاب درستی بود؟ البته که بله؛ مانند بسیاری از فناوری های مهندسی، به عوامل زیادی بستگی دارد. در میان کسانی که به این دو سوال پاسخ دادند، بسیاری از MongoDB بهره مند شده اند و به این کار ادامه می دهند. برای کسانی از شما که این کار را نکرده‌اند، امیدوارم درس ارزشمند و نه چندان دردناکی در مورد حرکت در چرخه تبلیغات فراگرفته باشید.
سلب مسئولیت
من می خواهم روشن کنم که من نه MongoDB را دوست دارم و نه از آن متنفرم. ما فقط از آن نوع مشکلاتی که MongoDB برای حل آنها مناسب است، نداشتیم. من می دانم که 10gen/MongoDB Inc. در ابتدا بسیار جسورانه عمل کرد، پیش‌فرض‌های ناامن تنظیم کرد و MongoDB را در همه جا (به‌ویژه در هکاتون‌ها) به عنوان یک راه‌حل یک‌جا برای کار با هر داده‌ای تبلیغ کرد. احتمالا تصمیم بدی بود. اما رویکردی که در اینجا توضیح داده شد را تأیید می کند: این مشکلات را می توان خیلی سریع حتی با ارزیابی سطحی فناوری شناسایی کرد.
منبع: www.habr.com