طراحی یک دیتابیس بزرگ

[sara_t]

سلام دوستان

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

ممنون میشم

[Cybersilent]

درود،
بهتره ابتدا تعریف خودتون ار "دیتابیس بزرگ" رو ارائه کنید، قراره چه حجم اطلاعاتی در روز به این بانک اطلاعاتی وارد بشه که فکر می کنید ممکنه برای مدیریت کردنش نیاز به انجام کاری خاصی باشه؟
همچنین مشخص کنید که از چه بانکی می خواید استفاده کنید، SQL ، Oracle ، mongdb .... ؟

[sara_t]

ممنون از پاسختون

در نظر داشته باشیم یه سایت اشپزی و یه انجمن برای اون وبسایت.حالا حدود 10000دستور غذا داریم و کلی عکس.
و از طرف انجمن هم هر روز پستهای زیادی رد وبدل میشه و کلی هم عکس منتقل میشه.
دیتابیس هم sql و کدنویسی هم mvc

[jaykob]

سلام

موارد زیر در طراحی دیتابیس توصیه می شه :

۱ - رعایت کامل اصول اولیه و نرمال سازی
۲ - طراحی به صورت کامل رابطه ای و استفاده از رابطه های صحیح
۳ - دقت به استفاده از Data Type های مناسب
۴ - رعایت اینکه جداول کمترین مقادیر Null رو داشته باشند و جداول Heap نداشته باشید
۵ - دقت بسیار زیاد بر روی Index گذاری و استفاده از Index های بسیار مناسب و استفاده از Index های فکر شده مثل Columnstore Index و ...
۶ - توجه کنید دیتا های حجیم مثل تصاویر رو به صورت باینری ذخیره نکنید و فقط نام و آدرس تصویر رو در یک column ذخیره کنید

مهمترین نکته : استفاده از SQL Server 2016 و تکنولوژی In-Memory OLTP

موفق باشید

[alireza_s_84]

سلام دوستان

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

ممنون میشم
1-بیش از حد نرمالسازی نکنید. باعث کاهش سرعت میشه.
2- اگر از EF استفاده میکنید سطوح دوم و سوم کش رو فعال کنید.
3- اگر از EF استفاده نمیکنید از SP ها استفاده کنید بخصوص در کوئری های پرکاربرد
4- ایندکس گذاری، ایندکس گذاری و ایندکس گذاری که بسیار بسیار مهم هست.
5- برخی از رابطه های چند به چند بهتره از بصورت XML Column تعریف بشن و روی اونها ایندکس گذاری بشه تا اینکه با نرمالسازی بیخود هم باعث پیچیدگی سیستم بشه هم کاهش سرعت
6- حتما حتما برای ذخیره هرنوع فایلی از File Stream استفاده کنید و توی خود پایگاه داده ذخیره بشه (دوران ذخیره روی هارددیسک گذشته)
7- جدوال بهینه شده برای حافظه (In-Memory OLTP) رو هم در دستور کار قرار بدین. از این جدوال در جاهایی استفاده میشه که نرخ واکشی اطلاعات بسیار بسیار بالا هست.
8- علاوه بر ذخیره فایلها در پایگاه داده از کش روی هارد دیسک استفاده کنید.
9- قسمتهایی از اطلاعات که زیاد تغییر نمیکنن رو توی حافظه سرور کش کنید. (مثل مسیرها، نقش ها، منوها و ...)
10- از بین تکنیک های صفحه بندی تکنیک Top در عمل تا 1000 برابر بیشتر از تکنیک Offset&Fetch سرعت داره پس سعی کنید روی نوع صفحه بندی دقت زیادی داشته باشید. (به جز این دو تکنیک به هیچ عنوان از روشهای دیگر صفحه بندی داده استفاه نکنید)
11- از تراکنش ها درست استفاده کنید و هیچ تراکنشی رو بیش از حد لزوم طول ندید تا از Dead Lock اجتناب کنید. (قفل در سطح سطر یا نهایتا Page و یا Extent)
و کلی موارد دیگه که اینها چکیده همه اونهاست

[sara_t]

بسیار بسیار ممنونم جناب jaykob و جناب alireza_s_84 .

[خانم گل]

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

[hakim22]

هیچ دلیلی برای جدا کردن دیتابیس ها ندارید. بهترین راه اینه که همه ی اطلاعات در یک دیتابیس نگه داری بشه. دیتابیس ها برای کار با حجم بسیار بالای اطلاعات طراحی شدن.

[خانم گل]

توی جستجوهایی که انجام دادم استفاده از partitioning برای تفکیک سالهای مالی پیشنهاد شده. از دوستان کسی میتونه توضیحاتی تو این زمینه بده؟

Partitioning data horizontally based on age and use is common. For example, a table may contain data for the last five years, but only data from the current year is regularly accessed. In this case, you may consider partitioning the data into five tables, with each table containing data from only one year.