حجم اطلاعاتی زیاد در پایگاه داده
با سلام خدمت همه ی دوستان عزیز
یلداتون هم مبارک
ما توی پایگاه داده جدولی داریم که موقعیت های مکانی رو ذخیره می کنه
برای مثال در طول روز برای یک کاربر ممکنه 50 تا موقعیت ذخیره بشه
در یک ماه 1500 تا رکورد ذخیره میشه
و احتمال این میره که تعداد کاربران تا صد هزار تا افزایش پیدا کنه
که در یک ماه حدودا میشه 150،000،000 رکورد که تعداد خیلی زیادی هست حتی اگه mysql محدودیتی هم برای تعداد رکورد نداشته باشه , پردازش اون جدول برای سرور سنگین میشه
برای حل این مشکل چه راه حلی رو پیشنهاد می کنین؟
یک راهی که به نظر خودم میاد اینه برای تعداد جدول یک عددی نسبت داده بشه وقتی تعداد رکورد به اون عدد رسید ، مابقی اطلاعات رو در جدول دوم ذخیره بکنه و همینطور تا اخر یا اینکه در دیتابیس دیگه ذخیره بشه
و یا اینکه برای مثلا یه تعداد کاربری اطلاعاتشون توی یه جدول بقیه یه جدول دیگه
اینهایی که پفتم تا حالا عملی کار نکردم نمیدونم اصولی هستند یا نه
ممنون میشم اگه نظراتتونو بگین
8 پاسخ
سلام afarhad عزیز
قطعا راهی که پیشنهاد دادید راه جالبی نیست.
من فکر کنم که شما باید از همون یه جدول استفاده کنید ولی خب باید پایگاه دادتونو بهینه کنید و کویری های بهینه تری بزنید و البته که ایندکس گذاری مناسب داشته باشید.
سعی کنید چیزایی مثل Triggerروی جدول نداشته باشید که پردازش رو سنگین تر بکنه!
itpro باشید
خب ببینید 150 میلیون رکورد رو توی جدول داریم
اجرای دستورات select,insert با سرعت کمی اجرا میشه اینکه میگین کوئری رو بهینه کنین , دستور select در حد ساده ترین شکل ممکن هست !
منظور این است که Index Edge Key با Where Clause همخوانی داشته باشه.
سلام حمید عزیز
منظور شما از این جمله "استفاده از CLR Function باعث می شود تا نوع پردازش به Pre-emtive تغییر کندو باعث عملیات Context Switch بالا و هزینه زیادی برای مدیریت CLR برای SQL Server دارد. "
در چه حالتی است؟
در حالت External_Access و Unsafe است؟
ودر ضمن در برخی سناریو ها مانند SQL Concatenate که با 4 الی 5 روش قابل پیاده سازی است ،روش استفاده از SQLCLR UDAs سرعت بالاتری نسبت به بقیه دارد.
آیا این قبیل موضوعات باعث تداخل خواهد شد؟
با سپاس
این که میگین کوئری رو بهینه کنم دقیق متوجه نمی شم! چون دستور من یا insert هست یا select !!!!!
و اینکه جدول ایندکس هم داره
این هم جدول مکان های کاربران :
مورد دوم همون طور که از اسمش معلومه فکر کنم اون چیزی باشه که من مد نظرمه
یعنی جدول رو پارتیشن پارتیشن تقسیم میکنه
با سلام
در هر حالتی چه Safe, Unsafe , External_Access هزینه بالایی دارد مخصوصا هم که از طریق آن به پایگاه داده متصل شود.
اصولا به دلیل اینکه اجراء CLR زیر نظر SQL Server نیست باید عملیات Pre-Emtive و Context Switch برای مدیریت آن انجام شود.
به امید خدا در مورد این موضوع و مدیریت CLR در SQL Server یک رخداد آنلاین با یاری ITPRO برگذار خواهیم کرد
Afarhad: شما می توانید با بهینه سازی کوری ها و گذاشتن ایندکس های درست سرعت سیستم را بالا ببرید. پارتیشن کردن پایگاه داده اگر هر پارتیشن در یک دیسک سخت جداگانه نباشد هیچ امتیازی ندارد بلکه به عملیات مدیریت پایگاه داده می افزاید.
البته من پایگاه داده ای را داشتم که روزانه ۳ میلیون رکورد وارد یک جدول می شد. پایگاه داده برای کارتهای اعتباری بود.
Bargozideh: مواردی که ذکر کردید بغیر از CLR Function درست است. استفاده از CLR Function باعث می شود تا نوع پردازش به Pre-emtive تغییر کندو باعث عملیات Context Switch بالا و هزینه زیادی برای مدیریت CLR برای SQL Server دارد.