14 چیز که ای کاش قبل از شروع کار با MongoDB می دانستم

ترجمه مقاله در آستانه شروع دوره آماده شد "پایگاه های اطلاعاتی غیر رابطه ای".

14 چیز که ای کاش قبل از شروع کار با MongoDB می دانستم

نکات برجسته:

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

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

ایجاد سرور MongoDB بدون احراز هویت

متأسفانه MongoDB به طور پیش فرض بدون احراز هویت نصب می شود. برای ایستگاه کاری که به صورت محلی قابل دسترسی است، این عمل طبیعی است. اما از آنجایی که MongoDB یک سیستم چند کاربره است که دوست دارد از حجم زیادی از حافظه استفاده کند، بهتر است آن را روی سروری با حداکثر RAM قرار دهید، حتی اگر فقط برای توسعه از آن استفاده کنید. نصب روی سرور از طریق پورت پیش فرض می تواند مشکل ساز باشد، به خصوص اگر هر کد جاوا اسکریپت را بتوان در درخواست اجرا کرد (به عنوان مثال، $where به عنوان یک ایده برای تزریق).

چندین روش احراز هویت وجود دارد، اما ساده ترین آنها تنظیم شناسه کاربری/رمز عبور است. زمانی که به احراز هویت فانتزی بر اساس فکر می کنید، از این ایده استفاده کنید LDAP. وقتی صحبت از امنیت به میان می‌آید، MongoDB باید دائماً به‌روزرسانی شود و لاگ‌ها همیشه باید برای دسترسی غیرمجاز بررسی شوند. به عنوان مثال، من دوست دارم یک پورت دیگر را به عنوان پورت پیش فرض انتخاب کنم.

فراموش نکنید که سطح حمله خود را به MongoDB متصل کنید

چک لیست امنیتی MongoDB حاوی نکات خوبی برای کاهش خطر نفوذ شبکه و نشت داده است. به راحتی می توان آن را پاک کرد و گفت که یک سرور توسعه به سطح بالایی از امنیت نیاز ندارد. با این حال، به این سادگی نیست و این برای همه سرورهای MongoDB صدق می کند. به ویژه، اگر دلیل قانع کننده ای برای استفاده وجود نداشته باشد mapReduce, group یا $ کجا، باید استفاده از کد دلخواه در جاوا اسکریپت را با نوشتن در فایل پیکربندی غیرفعال کنید javascriptEnabled:false. از آنجایی که فایل های داده در MongoDB استاندارد رمزگذاری نشده اند، اجرای MongoDB با آن منطقی است کاربر اختصاصی، که دسترسی کامل به فایل ها دارد و فقط به آن دسترسی محدود دارد و امکان استفاده از کنترل های دسترسی به فایل های خود سیستم عامل را دارد.

خطا در هنگام توسعه مدار

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

مقاله کلاسیک "6 قانون سرانگشتی برای طراحی طرحواره MongoDB" ارزش خواندن را دارد و ویژگی هایی مانند این دارد Schema Explorer در ابزار شخص ثالث Studio 3T، ارزش استفاده از آن را برای بررسی منظم مدارها دارد.

ترتیب مرتب سازی را فراموش نکنید

فراموش کردن ترتیب مرتب سازی می تواند بیش از هر پیکربندی نادرست دیگری باعث ناامیدی و اتلاف زمان بیشتری شود. به طور پیش فرض MongoBD استفاده می کند مرتب سازی باینری. اما بعید است که برای کسی مفید باشد. در دهه 80 قرن گذشته، انواع حساس به حروف کوچک، حساس به لهجه، ناهنجاری‌های عجیب و غریب همراه با مهره‌ها، کافتان‌ها و سبیل‌های مجعد در نظر گرفته می‌شدند. اکنون استفاده از آنها نابخشودنی است. در زندگی واقعی "موتور سیکلت" همان "موتور سیکلت" است. و "بریتانیا" و "بریتانیا" یک مکان هستند. یک حرف کوچک به سادگی معادل بزرگ یک حرف بزرگ است. و من را در مرتب سازی نشانه ها شروع نکنید. هنگام ایجاد یک پایگاه داده در MongoDB، از ترکیب بندی حساس به لهجه و ثبت نام، که مطابق با زبان و فرهنگ کاربر سیستم. این کار جستجو در داده های رشته ای را بسیار آسان تر می کند.

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

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

ایجاد اسناد با آرایه های بزرگ

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

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

فراموش نکنید که ترتیب مراحل در یک تجمیع مهم است

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

در MongoDB شما به آشپز دستور می دهید. برای مثال، باید مطمئن شوید که داده‌ها از آن عبور می‌کنند reduce در اسرع وقت در خط لوله با استفاده از $match и $project، و مرتب سازی فقط پس از آن اتفاق می افتد reduce، و جستجو دقیقاً به ترتیبی که می خواهید انجام می شود. داشتن یک بهینه ساز پرس و جو که کارهای غیر ضروری را حذف می کند، مراحل را به طور بهینه ترتیب می دهد و انواع اتصال را انتخاب می کند، می تواند شما را خراب کند. با MongoDB، شما کنترل بیشتری به قیمت راحتی دارید.

ابزارهایی مانند Studio 3T ساخت پرس و جوهای تجمع را در آن ساده می کند MongoDB. ویژگی Aggregation Editor به شما این امکان را می دهد که دستورات خط لوله را در یک مرحله اعمال کنید و داده های ورودی و خروجی را در هر مرحله بررسی کنید تا اشکال زدایی را ساده کنید.

با استفاده از ضبط سریع

هرگز گزینه های نوشتن MongoDB را به گونه ای تنظیم نکنید که سرعت بالایی داشته باشد اما قابلیت اطمینان پایینی داشته باشد. این حالت "پرونده کردن و فراموش کردن" سریع به نظر می رسد زیرا دستور قبل از انجام نوشتن برگردانده می شود. اگر سیستم قبل از نوشتن اطلاعات روی دیسک از کار بیفتد، از بین می رود و در حالت ناسازگار قرار می گیرد. خوشبختانه، MongoDB 64 بیتی ورود به سیستم را فعال کرده است.

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

ژورنالینگ تضمین می کند که پایگاه داده پس از بازیابی در وضعیت ثابتی قرار دارد و تمام داده ها را تا زمانی که در گزارش نوشته شود حفظ می کند. فرکانس ضبط با استفاده از پارامتر پیکربندی می شود commitIntervalMs.

برای اطمینان از ورودی ها، مطمئن شوید که ورود به سیستم در فایل پیکربندی فعال است (storage.journal.enabled)، و تعداد دفعات ضبط مطابق با مقدار اطلاعاتی است که می توانید از دست بدهید.

مرتب سازی بدون فهرست

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

اگر شاخص مناسبی وجود نداشته باشد، MongoDB بدون آن کار خواهد کرد. محدودیت حافظه 32 مگابایت برای حجم کل اسناد موجود است عملیات مرتب سازیو اگر MongoDB به این حد برسد، یا خطا می دهد یا برمی گردد مجموعه رکورد خالی.

جستجو بدون پشتیبانی از فهرست

پرس و جوهای جستجو عملکردی مشابه عملیات JOIN در SQL انجام می دهند. برای اینکه بهترین کار را انجام دهند، به شاخص ارزش کلید استفاده شده به عنوان کلید خارجی نیاز دارند. این واضح نیست زیرا استفاده در آن منعکس نشده است explain(). این شاخص ها علاوه بر شاخصی هستند که در آن نوشته شده است explain()، که به نوبه خود توسط اپراتورهای خط لوله استفاده می شود $match и $sort، هنگامی که آنها در ابتدای خط لوله ملاقات می کنند. ایندکس ها اکنون می توانند هر مرحله ای را پوشش دهند خط لوله تجمع.

انصراف از استفاده از به‌روزرسانی‌های چندگانه

روش db.collection.update() بسته به پارامتری که مشخص می‌کنید، برای تغییر بخشی از یک سند موجود یا کل سند، تا جایگزینی کامل استفاده می‌شود. update. چیزی که چندان واضح نیست این است که تمام اسناد موجود در مجموعه را پردازش نمی کند مگر اینکه این گزینه را تنظیم کنید multi برای به روز رسانی تمام اسنادی که معیارهای درخواست را برآورده می کنند.

اهمیت ترتیب کلیدها در جدول هش را فراموش نکنید

در JSON، یک شی از مجموعه ای نامرتب با اندازه صفر یا بیشتر جفت نام/مقدار تشکیل شده است، که در آن نام یک رشته و مقدار یک رشته، عدد، بولی، تهی، شی یا آرایه است.

متأسفانه، BSON هنگام جستجو بر نظم تأکید زیادی دارد. در MongoDB، ترتیب کلیدها در اشیاء داخلی مسائل، یعنی { firstname: "Phil", surname: "factor" } - این یکسان نیست { { surname: "factor", firstname: "Phil" }. به این معنا که اگر می‌خواهید از پیدا کردن آنها مطمئن شوید، باید ترتیب جفت‌های نام/مقدار را در اسناد خود ذخیره کنید.

گیج نشوید "خالی" и "تعریف نشده"

ارزش "تعریف نشده" طبق گفته‌ها، هرگز در JSON معتبر نبود استاندارد رسمی JSON (ECMA-404 بخش 5)، حتی اگر در جاوا اسکریپت استفاده می شود. علاوه بر این، برای BSON منسوخ شده است و به آن تبدیل شده است $null، که همیشه راه حل خوبی نیست. از مصرف خودداری کنید "تعریف نشده" در MongoDB.

استفاده $limit() بدون $sort()

اغلب زمانی که در MongoDB در حال توسعه هستید، دیدن نمونه ای از نتیجه که از یک پرس و جو یا تجمیع بازگردانده می شود مفید است. برای این کار شما نیاز خواهید داشت $limit()، اما هرگز نباید در کد نهایی باشد مگر اینکه قبلاً از آن استفاده کرده باشید $sort. این مکانیک ضروری است زیرا در غیر این صورت نمی توانید ترتیب نتیجه را تضمین کنید و نمی توانید به طور قابل اعتماد داده ها را مشاهده کنید. در بالای نتیجه، بسته به مرتب سازی، ورودی های مختلفی دریافت خواهید کرد. برای کارکرد قابل اعتماد، پرس و جوها و تجمیع ها باید قطعی باشند، یعنی هر بار که اجرا می شوند، نتایج یکسانی تولید کنند. کدی که حاوی $limit()، اما نه $sort، قطعی نخواهد بود و ممکن است متعاقباً باعث ایجاد خطاهایی شود که ردیابی آنها دشوار خواهد بود.

نتیجه

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

معرفی تراکنشی ACID توسط MongoDB در نسخه 4.0 نمونه خوبی از معرفی پیشرفت های مهم به روشی نوآورانه است. معاملات چند سندی و چند بیانیه ای اکنون اتمی هستند. همچنین امکان تنظیم زمان لازم برای به دست آوردن قفل ها و خاتمه تراکنش های گیر کرده و همچنین تغییر سطح ایزوله وجود دارد.

14 چیز که ای کاش قبل از شروع کار با MongoDB می دانستم

بیشتر بخوانید:

منبع: www.habr.com

اضافه کردن نظر