كار با حجم بالاي 100 ميليون ركورد در يك table

[reza105]

با سلام خدمت دوستان

ما يك ديتابيسي داريم كه پيش بيني ميشه در يك سال بيشتر از 100 ميليون ركورد فقط در يه table اون درج بشه و يه پيش بيني ديگه اينكه حجم ديتابيس ما بيشتر از 500 گيگا بايت ميشه البته بدون Index گذاري.

ميخواستم بدونم كسي تجربه كار با اين حجم اطلاعات رو داشته يا نه؟

آيا Index ميتونه مشكل search ها رو حل كنه؟

و كلاً SQL Server جوابگوي كار هست ياخير؟

ممنون

[ASKaffash]

سلام
با حجم 280 گیگ و رکوردهای زیاد کار کردم این نکات مهمه :
طراحی صحیح بانک اطلاعاتی (ایندکس های کم و حذف ایندکس های غیر ضروری حتی خسیس بودن در انتخاب نوع فیلد مثلا Tinyint را Bigint انتخاب نکنیم و ...)
طراحی مناسب و بهینه ایندکس ها
استفاده از FileGroup و ...
توزیع اطلاعات روی چند هارد دیسک
....

[Rezahak]

قطعا Sql SERVER 2008 جواب کار شما رو می ده ولی باید دقت کنید با این حجم داده optimization و استفاده از Index ها در جاهای صحیح و انجام عملیات ذخیره و بازیابی اطلاعات توسط اشیاء تعبیه شده در پایگاه داده به جای کد نویسی سمت Application و ... بسیار اهمیت پیدا می کند .
کلا کار قشنگی است .... موفق باشید

[tooraj_azizi_1035]

سلام،
اندیس گذاری روی فیلدهایی که جستجو بر اساس آنها زیاد است و همچنین برای مدیریت جداول با حجم زیاد باید روی بحث Partitioning Table کار کنید.
SQL Server محدوده خیلی خیلی بزرگی از رکورد ها ساپورت می کند.

می تونید تو گوگل با این کلید جستجو کنید: Performance of very large sql server table with millions of rows

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

سلام.


آيا Index ميتونه مشكل search ها رو حل كنه؟

ببینید روی نحوه ایندکس گذاری بسیار باید دقت کنید. هر چند ایندکس گذاشتن سرعت رو افزایش میده ولی روی عمل Update نیز تاثیر سو خواهد گذاشت. حتما از Filegroup ها استفاده کنید و دیتابیس رو به صورت توزیع شده روی چند هارد داشته باشید.همین کار باعث افزایش سرعت خواهد شد.


و كلاً SQL Server جوابگوي كار هست ياخير؟

بله.اگر به این سایت (http://tpc.org/tpch/results/tpch_perf_results.asp) مراجعه کنید لیست دیتابیسهای حجیم رو خواهید دید.
نکاتی که جناب کفاش ذکر کردند بسیار حائز اهمیت هست.

[iman_Delphi]

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

مثلا" یک تیبلی که 3 تا رکورد داره با این تیبل جوین می کنیید مشاهده میکنید که زمان زیادی رو تلف میکنه + اینکه هنگام پشتیبان گیری و غیره دردسر فضا و زمان و سخت افزار مورد نیاز درست میکنه

من این مشکل شما رو داشتم و دیتا خودم رو طبقه بندی کردم یعنی دیتای سال 87 و 88 و 89 و 90 هر کدام در یک دیتابیس جدا هست و همچنین مال هر سال رو دقیقا" جدا کردم و سال های گذشته رو وارد اونا نکردم البته طراحی سیستم طوری بود که زمان گرفتن گزارشات آماری که نیاز به دیتای تمام این سال ها بود سیستم به تمام این فایلها که روی یک هارد اکسترنال بود دسترسی پیدا میکرد و داده های مورد نیاز رو از اون استخراج میکرد.

البته بازم می گم طراحی سیستم من و نوع نیاز من طوری بود که می تونستم اینگونه پایگاه داده خودم رو انعتاف بدم

[AminSobati]

سلام دوست عزیزم،
تمام نکاتی که اشاره شد در جای خودش درست و کاربردی هست. ولی مسئله تعیین کننده در انتخاب راهکار، Pattern یا شیوه استفاده Application از دیتابیس هست. سوال شما بسیار کلی هست و قبل از بررسی بهینه ترین راهکار باید در آنالیز به این سوالات پاسخ بدین:
- کدام جداول هسته مرکزی دیتابیس از لحاظ ویرایش و خواندن اطلاعات هستند؟
- آیا تمام رکوردهای موجود، در تمام کوئری ها به کار برده میشن؟ یا WHEREهای به کار گرفته شده درصد قابل توجهی از رکوردها رو فیلتر خواهند کرد؟
- آیا استفاده دیتابیس دیگری بعنوان آرشیو باعث خواهد شد کوئری ها نیاز به ویرایش داشته باشند یا کوئریها هنوز نوشته نشدن؟
و ...

[غلامرضا شریفی]

ما يك ديتابيسي داريم كه پيش بيني ميشه در يك سال بيشتر از 100 ميليون ركورد فقط در يه table اون درج بشه و يه پيش بيني ديگه اينكه حجم ديتابيس ما بيشتر از 500 گيگا بايت ميشه البته بدون Index گذاري.

حس فضولي گل كرده ميشود بفرماييد اين چه اطلاعاتي است