پرفرمنس روابط در MongoDB

سلام دوست عزیز
من خیلی به این روشی که می خوام بگم مطمئن نیستم ولی خودم توی یه موقعیت شبیه به شما از این روش استفاده کردم :
شما توی کالکشن مثلا posts برای هر داکیومنت یه ارایه تعریف میکنید مثلا به اسم comments بعد توی اون قرار نیست کل کامنت ها رو ذخیره کنید.
کاری که می کنید یک کالکشن دیگه به اسم comments هم تعریف می کنید و کامنت ها رو میزارید اونجا و توی ارایه comments که توی کالکشن posts هست فقط ایدی کامنت های مربوط به اون پست رو ذخیره می کنید و با یه لوپ می تونید همه کامنت ها رو بگیرید.
البته این موقعیت شما یه خورده با اونی که من داشتم فرق می کنه برا همین فکر نمی کنم روش درستی باشه چون تعداد کوئری ها خیلی زیاد میشه.

یه راه دیگه هم که به نظر من میرسه اینه که کلا حالت همون sql ذخیرش کنید یعنی هیچی امبدد نداشته باشید این وسط که البته من توی خود داکیومنتیشن MongoDB هم همین مورد رو دیدم که این روش رو پیشنهاد کرده بود
https://docs.mongodb.com/ecosystem/use-cases/storing-comments/
اینم لینکش
@proamirm

به نظر من روش دوم خیلی بهتره چون همونطور که خودتون گفتین تعداد کامنت هاتون خیلی زیاده و البته به نظر من اصلا اون چند هزار تا کامنت رو یکجا دریافت نکنید یعنی یا حالت pagination یا حالت infinite loader براش بزارید حتما

مونگو بدرد کارهای رابطه ای نمیخوره و اگه میخوای روابط رو پیاده سازی کنی بهتره از دیتابیس های رابطه ای یا گراف استفاده کنی. استفاده کردن از مونگو برای کارهای رابطه ای به معنی اینه که به زور میخوای یه وظیفه ای که مرتبط با مونگو نیست رو بهش بدی تا برات انجام بده و بازده پایینی خواهد داشت.

@mamaliosezar
ممنون ازتون
روش اول رو که نه، خیلی کوئری میشه.
سایت مونگو رو الان دارم نگاه میکنم ببینم چی به چیه اما اون هم احتمالا میخواد روش embedded رو پیشنهاد بده.

@khanzadimahdi
ممنون ازتون، احتمالا باید از همون sql استفاده کنم چاره ای نیست. اما خیلی پیاده سازیش واسم سخته به دلیلی که تو پست اول گفتم شاید ممکن نباشه.

اون قسمتی که گفتید استفاده کردن از مونگو برای کارهای رابطه ای به معنی اینه که به زور میخوای یه وظیفه ای که مرتبط با مونگو نیست رو بهش بدی تا برات انجام بده و بازده پایینی خواهد داشت. خب، پس مونگو به چه درد میخوره.
چون فکر نمیکنم پروژه ای باشه که توش حداقل یه رابطه کوچیک نباشه (یه وبلاگ، یه فروشگاه اینترنتی یا...)
پس عملا مونگو و همه دیتابیس های nosql یه دیتابیس بی کاربرد هستن که فقط به درد ذخیره کردن log میخورن!

@proamirm
ببین کاربرد اصلی nosql تو سیستم چت و این مدلی هست .. بطور مثال شما یه فروشگاه داری که میخوای یه بخش چت بین خریدار و فروشنده بذاری .. خب nodejs در کنار mongodb اینجاها عالی عمل میکنه
یا یه سایت خرید و فروش مث esam و divar که میخوای بخش چت بذاری توش ... میای کل سایت رو بطور مثال با laravel mysql میزنی بعد اون بخش چت رو با nodejs mongodb

@proamirm
فکر می کنم روش دومی که گفتم و توی سایت مونگو هم بود بتونه کمکتون کنه
https://docs.mongodb.com/ecosystem/use-cases/storing-comments/one-document-per-comment
این رو بخونید.
نوشته که One Document Per Comment
یعنی برای هر کامنت یک داکیومنت تعریف کرده و یک فیلد discussion_id هم داره که مربوط میشه به اون بحثی که کامنت براش گذاشته شده.
این توضیح رو هم برای اون فیلد داده
the discussion_id field that references the discussion parent

@rezajashnsaz0011
بله فکر میکنم واسه منم مناسب نباشه مونگو اما این که ساختار نداره خیلی کار رو راحت میکنه.
خیلی دیتابیس عالی میشد اگه روابط توش قدرتمند میشد.

@mamaliosezar
بله درسته؛ من روش پیاده سازی رو بلدم. بحثم سر پرفرمنسه که فکر میکنم مونگو کم بیاره وقتی رابطه میاد تو کار.

@proamirm

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

یه موردی هم هست
دیتابیس مونگو داکیومنشن هست دیگه
وقتی همچین فرمتی داره ( که میشه تو در تو کار کرد )
شما میتونی موجودیت های مختلفی رو به جای اینکه کلی مجموعه جدا بسازید توی یک مجموعه ایجاد کنید

برای همین میشه خیلی از رلیشن ها دوری کرد توش

با سلام .
بنده با دیتا بیس مونگو تجربه کار زیادی دارم . و به شما تضمین میدم.که خیلی خوب از پس پروژه که گفتید برمیاد.و نتنها افتضاح نمیشه بلکه تا حد زیادی با دیتاهایی کمتر حتی با برقراری رابطه پرفورمنس بهتری میگیرید.(دیتابیس ها را دست کم نگیریم :) )