پایگاه داده نرمال (با جداول زیاد) یا غیرنرمال (با جداول کم و یک تیکه) برای افزایش سرعت روی وب؟

[emad4000]

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

یه عده نظرشون اینه که برای اینکه از میزان JOIN شدن جداول موقع Runtime کاسته بشه و متعاقباً میزان ردوبدل شدن داده با Server کم بشه، بعضی جاها باید خودم جداول رو یه تیکه طراحی کنم (یعنی به جای چند جدول یک جدول بزرگ طراحی کنم) که جدول یه جا Load بشه و در نتیجه سرعت بره بالا.

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

نظر شما چیه؟

[حمیدرضاصادقیان]

سلام.
نیازی نیست شما قید نرمال سازی رو بزنید.
این در مواقع خیلی خاص و برای گزارش گیری از داده های خیلی حجیم هست که باز در جداول اصلی درست طراحی شده و برای گرفتن گزارش داده های مورد نظر در جدول دومی اضافه میشوند و از اون گزارشات مربوطه گرفته خواهند شد.
پس نیازی به این کار نیست.
باز اگر خیلی حجم داده های شما افزایش پیدا کرد میتونید از تکنیکهایی مثل Partitioning استفاده کنید.
حجم اطلاعات شما در یک سال چقدره؟ و در روز چند نفر به سایت متصل می شوند؟
داده ها بیشتر گزارشاتی هستند یا کاربران بیشتر داده ها رو تغییر میدهند؟
ماهیت نرم افزار به چه شکل است؟

[h_r_ibm]

با سلام
به نظر من نوع پرو‍ژه گزارش مربوطه و ... خيلي مهمه
مثلا ذخيره معدل دانش آموزان براي بالا بردن سرعت گزارش گيري مانعي نداره

[emad4000]

حجم اطلاعات شما در یک سال چقدره؟ و در روز چند نفر به سایت متصل می شوند؟
داده ها بیشتر گزارشاتی هستند یا کاربران بیشتر داده ها رو تغییر میدهند؟
ماهیت نرم افزار به چه شکل است؟

ممنون از راهنماییتون، مفید بود
این بخشی که الان مشغول هستم یه سیستم Workflow ای هست که شاید آنچنان فشاری روش نباشه، ولی بیشتر به فکر بخش دوم کارم هستم که سیستم Billing هست.
در مورد بخش دوم (سیستم Billing) خیلی تحلیلی انجام ندادم. ولی در مورد بخش فعلی حدس می زنم که روزانه 300 نفر به سایت متصل بشوند.
همچنین کاربران بیشتر داده ها رو تغییر می دن، یعنی حدوداً نسبت 1 به 5

[حمیدرضاصادقیان]

خوب این حجم زیادی نمیشه و داده زیادی روانه سایت نخواهد شد که نیازی باشه از حالت نرمال جداول رو خارج کنید.
خیلی از فیلدهایی که محاسباتی هستند میشه سمت کلاینت پردازش بشه .
منظور من از داده های حجیم بالای 100 میلیون رکورد هست.

[baktash.n81@gmail.com]

سلام
دوست عزیز برای اینکار روش های مختلفی وجود داره ... و متدهای مختلفی با عنوان Denormalization وجود داره ... مثالا شما می تونید میزان fetch کردن اطلاعات رو کم کنید .... یعنی فرض کنیم در یه جدول نامه فیلدی به عنوان گیرنده داریم ... که کلید خارجی برای جدول گیرندگان هست ... این متد یا پترن می گه شما اگه تعداد کاربرایی که نامه رو با نام گیرنده جستجو می کنند به جای اینکه فقط کد گیرنده رو نگهداری نام گیرنده رو هم به جدول نامه ها به عنوان یه فیلد اضافه کن ... تا اگه کسی خواست بر اساس نام گیرنده جستجو کنه عمل join انجام ندی ... مخصوصا در مواردی مثل نام روزهای هفته و جنسیت و ... یا مثالا نگهداری اطلاعات مستر دیتیل خیلی ساده در یک جدول ... مثالا اگه سیستم شما از یه نفر می تونه چنتا شماره تلفن رو نگهداره لازم نیست یه جدول دیتیل داشته باشی می تونید با یه کاراکتر مشخص اطلاعات رو از هم جدا کنی ...

[emad4000]

... به جای اینکه فقط کد گیرنده رو نگهداری نام گیرنده رو هم به جدول نامه ها به عنوان یه فیلد اضافه کن ... تا اگه کسی خواست بر اساس نام گیرنده جستجو کنه عمل join انجام ندی ...

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

[حمیدرضاصادقیان]

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

[emad4000]

این مرز بندی که کردین برای کارهای کوچک و بزرگ کاملا اشتباهه و اصلا به این سمت نرید که بعدا دچار مشکل خواهید شد.


شما در این زمینه تجربتون خیلی بیشتر از من هست و من حرفتون رو منطقاً قبول دارم، ولی راستش رو بگم دلم راضی نمیشه :لبخند::چشمک:
یعنی به نظر شما برای یه فیلد ساده که برای بدست آوردنش باید مثلاً سه تا جدول رو JOIN کنیم بهتر نیست اون فیلد رو به جدول اول اضافه کنیم که نیاز به اون JOIN ها نباشه؟؟؟ (یعنی افزونگی ایجاد کنیم)

[baktash.n81@gmail.com]

از نظر من دقیقا باید این کارو بکنید ... اینکه اون مرز رو شما کجا در نظر می گیرید (یا اصلا در نظر نمی گیرید) مربوط به خود شماست و البته توی پست های دیگه هم گفتم که این چیزهاست که دست خط شما رو مشخص می کنه ... یکی از فاکتورهای مهم میزان تراکنش هست ... یعنی اگه شما یه مقدار (مثلا همون نام گیرنده) رو زیاد به روز نمی کنید (یعنی تغییراتش خیلی کمه) و در نمایش و جستجو همیشه ازش استفاده می کنید می تونید انرو به عنوان یه فیلد به جدول اضافه می کنید ...

[حمیدرضاصادقیان]

یعنی به نظر شما برای یه فیلد ساده که برای بدست آوردنش باید مثلاً سه تا جدول رو JOIN کنیم بهتر نیست اون فیلد رو به جدول اول اضافه کنیم که نیاز به اون JOIN ها نباشه؟؟؟ (یعنی افزونگی ایجاد کنیم)
خوب این فیلد ساده رو شما اضافه کردید. مثلا در چند جدول نیازه اضافه بشه و شما اضافه کردید که از یک Join جلوگیری کنید.
حالا کاربر دلش میخواد بیاد اونو اصلاح کنه یعنی اشتباه کرده.
اینجاست که شما نیاز دارید روی چند جدول مختلف کار Update رو انجام بدید/
چه تعداد این Update ها کم باشه چه زیاد کلا اشتباهه. به خاطر اینکه برای یک Join که سربار خاصی روی Query های شما نداره دارید به سیستم چند عمل اضافی رو تحمیل میکنید که این ها سبب افزایش Lock روی جداول شما و کاهش محسوس سرعت ، و مشکلاتی در حذف برای شما پیش خواهد آورد.

[zarifcomputer]

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

[emad4000]

با نظرتون موافقم آقای صادقیان، ممنون از اطلاعاتتون


... برای این کار باید پول مناسب برای پروژه خرج کنید

با این حرف آقای ظریف کامپیوتر!!! هم موافقم، این مسئله هم نکته مهمی هست


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

[zarifcomputer]

ولی با این بخش صحبتتون خیلی موافق نیستم
اگر دیتابیس خیلی Unnormal باشه، فکر نمی کنم هیچ Server ای با هر میزان قدرت بتونه جبرانش کنه

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

راستی از ظریف کامپیوتر!!! تعجب کردید؟
علت سه تا علامت تعجب چیست؟

[emad4000]

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

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



راستی از ظریف کامپیوتر!!! تعجب کردید؟
علت سه تا علامت تعجب چیست؟
نه، جسارت نشه، تعجب نکردم، علامت تعجب رو به خاطر کلمه آقا در پیشوند ظریف کامپیوتر گذاشتم :لبخند: