منظورتون از استراکچر ثابت چیه ؟ چرا استفادش تو دیتابس NoSQL بی معنی هست ؟نقل قول:
نوشته اصلی توسط M.Abooali
نمایش نسخه قابل چاپ
منظورتون از استراکچر ثابت چیه ؟ چرا استفادش تو دیتابس NoSQL بی معنی هست ؟نقل قول:
نوشته اصلی توسط M.Abooali
این سوال شما خودش یک بحث مفصل هست. معمولا افراد تا قبل از آشنایی با nosql تصور می کنند بهتر از RDBMS وجود ندارد که اشتباه است و بعد از آشنایی با nosql نیز تا یک مدت فکر می کنند بهترین انتخاب است خصوصا با خودنمایی مانگو.کد:منظورتون از استراکچر ثابت چیه ؟ چرا استفادش تو دیتابس NoSQL بی معنی هست ؟
اما بعد از یک مدت تجربه و کار این سوال برای هر کسی پیش خواهد آمد حالا که هم RDBMS پایه ها و هم nosql پایه ها را بلد هستم برای پروژه جدید کدام رو استفاده کنم؟ پس از تحقیق نتیجه خواهید گرفت که این امر وابسته است و مطلق نیست. شرح ابعاد گوناگونش اینجا دشوار و خارج از حوصله است. شاید باید در خصوصش یک کتاب نوشت. بنده فقط در خصوص هر کیس کاری میتونم نظر بدم که کدوم گزینه مناسب تر است. چون قصد برگزاری کلاس آموزشی رو ندارم. یک تصویر بسیار مفید که راهنمای خوبی است در این زمینه:
http://redup.ir/images/kdxfy/7503_me...bivg_thumb.png
در مورد یک سیستم وبلاگ دهی از نظر شخص بنده RDBMS انتخاب درست تری می باشد. اما چرا nosql مناسب نیست؟
از اون جهت که شما ناچار هستید به ذخیره چندباره (یا نوبتی) اطلاعات و بازخوانی چندباره اون،(دقیقا به دلیل فقدان A در تصویر فوق) یا به زبان خودمانیش چون در حالت nosql از جیزی با مفهوم join (در sql) خبری نیست.
به این ترتیب پهنه دیتابیس شما خیلی وسیع تر از حالت RDBMS خواهد شد. حجم کدهای شما نیز طبیعتا بیشتر خواهد شد. در خصوص پرفرمنس هم چندان نباید خوش بین باشید چون با این وضعیت در صورت بالا بردن اون ریسک از دست رفتن دیتا در nosql نیز بالاتر خواهد رفت (اگر دلیلش را نمی دانید در خصوصش قبل از سوال در اینجا سرچ کنید).
لازم به اشاره است که سیستم وبلاگ دهی شامل فضاهای نسبتا جدای اطلاعاتی است (شبیه انجمن یک سامانه مشترک نیست). مقصود من پست ها، کامنت ها و این موارد برای هر وبلاگ است. حتی شما میتونید هر وبلاگ را تبدیل به یک دیتابیس جدا کنید و به لطف RDBMS کوئری هایی فرا دیتابیسی داشته باشید !
به طور مثال شما قطعا برای دانستن آمار کل تعداد پست ها قرار نیست برید تک تک تیبل های وبلاگها رو آنالیز کنید و جمع بزنید بیاید بخونید.و این اطلاعات رو دارید از تیبل آمار کلی سایت بلاگ دهی می خونید. تا اینجا مشکل نیست. همین کیس را در nosql تصور کنید و بخواهید این آمار در وبلاگ ها نمایش داده شود.
به زبان دیگر،زمانی که شما صدها بار ناچارید چندین فایل را باز کنید برای خواندن یک اطلاعات بهتر نیست این اطلاعات در یک محل باشند یا حداقل به هم ریلیت باشند با قابلیت جوین ؟ قطعا پاسخ شما مثبت است و اینجاست که بنده RDBMS را به nosql در این پروژه ترجیح می دهم. چه از نظر کدنویسی چه پرفرمنس نتیجه مطلوب تری دارد.
درسته از هر دیتابس باید به جای خودش استفاده کرد ، اما این لزوما به این معنی نیست که هر کدوم فقط برای یک موارد خاص استفاده کنیم ، برای مثال از دیتابس های NoSQL هم میشه برای مدل های رابطه ای استفاده کرد (به خصوص دیتابس MongoDB)نقل قول:
نوشته اصلی توسط M.Abooali
من برنامه نویسی رو با php و Mysql شروع کردم ، حدود ۳ سال پیش بود که از php مهاجرت کردم ، بعد از اون هم با دیتابس های NoSQL شروع به کار کردم ( MongoDB و Cassandra) و البته هنوز هم از MySQL استفاده میکنم.
یک باور غلطی که در مورد دیتابس های NoSQL وجود داره این هست که دیتابس NoSQL به هیچ وجه به درد مدل رابطه ای نمی خورن ، در صورتی که با دیتابس های NoSQL به راحتی میتونی مدل رابطه ای One to One و One to Many و حتی Many to Many رو انجام بدید ، بدون اینکه بخواهید صرفا denormalization رو انجام بدید و پراکنده گی داده ها رو افزایش بدید.
به نظر من ، تعریف ساختار های رابطه ای پیچیده ساختاریافته رو خیلی راحت تر میشه تو JSON objects انجام داد ، برای مثال همین گرفتن بازدید هر پست و بازدید کل یک بلاگ که خودتون بهش اشاره کردید ، برای این کار میتونی آمار بازدید هر پست رو به صورت Embedded تو خود همون پست ذخیره کنید و برای بازدید کل با یک aggregate کوئری ساده جمع بازدید های کل پست ها رو دریافت کنید.
در ضمن MongoDB از نسخه ۲.۳ به بعد قابلیت lookup رو به aggregate pipline اضافه کرده که این امکان رو بهتون میده دادهای ۲ تا کالکشن رو به هم مرتبط کنید. (همون کار Join در Mysql).
این که ما میتونیم تو کار خودمان دیتا رو پیوست کنیم خاص NoSQL نیست. حتی جدا از json ما با هر الگوی دلخواهی می تونیم این کار رو بکنیم همانطور که مثلا در اپن کارت یا برخی فروشگاه سازهای عجیب و غریب شاهدش هستیم با یک سری الگو ها (و گاه همین json) سعی شده در ستون سطر گاه تیبل های دیتابیس صرفه جویی شود.
مثلا هر پلاگین، تنظیماتش و مسائل مربوط بهش در یک سلول به صورت جیسان ذخیره می شوند اینطور لازم نیست هر پلاگین تیبل خودش را داشته باشد یا ...
اما هدف را گم نکنیم. این که آیا چیزی امکان پذیر است یا خیر، یک بحث است. این که آیا میتوان php را روی ویندوز ران کرد یا مثلا asp را روی لینوکس... یک بحث است ...
اما این که کدام بهینه تر و ما را به شکل درست تری به مقصود میرساند یک بحث.
بنده تجربیات محدودی در زمینه NoSQL دارم. اما تجربه مواردی رو داشتم که کاملا احساس کردم این مورد باید حتما با NoSQL کار شود. منظورم این هست اونقدرها برام گنگ نیست که کجا کدوم گزینه برتر است. البته این مطلق نیست ممکنه با کسب تجربه بیشتر نظرات من تغییر کند.
نظری که اینجا دادم با توجه به دانش و تجربیات فعلیم هست.
میدونم تو MySQL هم میشه از JSON استفاده کرد ، اما تو دیتابس مثل MongoDB هر داکیومنت به صورت JSON ذخیره میشه ، این انعطاف پذیری بالایی در اختیارمون قرار میده ، شما هر زمان بخواهید میتونید ساختار داده ها رو تغییر بدید ، یا حتی یک ساختار ثابت تعریف کنید (Mongodb ولیدیتور های داخلی داره ، که میشه باهاش نوع داده ها رو چک کنید)نقل قول:
نوشته اصلی توسط M.Abooali
در مورد مثال تون در مورد php روی ویندوز یا asp رو لینوکس و نسبت دادنش به NoSQL ، این مقایسه بیشتر شبیه این هست ، مثل برنامه نویسی توی زبان C و زبان Python ، تو زبان C نسبت به Python برنامه نوشتن برنامه با سرعت کمتری انجام میشه و نسبتا سخت تره (البته این در مورد همه افراد صدق نمیکنه ، اما به طور کلی به همین صورت هست) ، اما در عوض سرعت و کارایی برنامه نهایی اون سخت ها رو جبران میکنه.
در مورد دیتابس های NoSQL هم همینطوره ، ممکنه کارهایی که با دیتابس های SQL به راحتی انجام بدید ، توی NoSQL نیاز به کوئری پیچیده تری داشته باشید ، اما در پایان اون افزایش کارایی که اپلیکیشن تون به دست میاره ، ارزش اش رو داره.
من به یگ مساله معتقدم هرکسی صلاح کار خودش رو بهتر از دیگران میدونه... اگر برنامه ای که نوشتید و بانک اطلاعاتی شما اختصاصی و طبق استاندارد نوشته شده چرا که نه خیلی هم خوبه ولی اگر هرکسی از راه رسیده یک برنامه نوشته و ... خب بهترین هم ممکنه جوابگو نباشه