درخواست های ارتباط
جستجو
لیست دوستان من
صندوق پیام
همه را دیدم
  • در حال دریافت لیست پیام ها
صندوق پیام
رویدادها
همه را دیدم
  • در حال دریافت لیست رویدادها
همه رویدادهای من
تخفیف های وب سایت
همه تخفیف ها

حجم اطلاعاتی زیاد در پایگاه داده

نویسنده متن پست
پاسخ به این پست
author
afarhad
فرهاد مهریاری
1394/09/30 06:01:37
با سلام خدمت همه ی دوستان عزیز
یلداتون هم مبارک
ما توی پایگاه داده جدولی داریم که موقعیت های مکانی رو ذخیره می کنه
برای مثال در طول روز برای یک کاربر ممکنه 50 تا موقعیت ذخیره بشه
در یک ماه 1500 تا رکورد ذخیره میشه
و احتمال این میره که تعداد کاربران تا صد هزار تا افزایش پیدا کنه
که در یک ماه حدودا میشه 150،000،000 رکورد که تعداد خیلی زیادی هست حتی اگه mysql محدودیتی هم برای تعداد رکورد نداشته باشه , پردازش اون جدول برای سرور سنگین میشه
برای حل این مشکل چه راه حلی رو پیشنهاد می کنین؟
یک راهی که به نظر خودم میاد اینه برای تعداد جدول یک عددی نسبت داده بشه وقتی تعداد رکورد به اون عدد رسید ، مابقی اطلاعات رو در جدول دوم ذخیره بکنه و همینطور تا اخر یا اینکه در دیتابیس دیگه ذخیره بشه

و یا اینکه برای مثلا یه تعداد کاربری اطلاعاتشون توی یه جدول بقیه یه جدول دیگه
اینهایی که پفتم تا حالا عملی کار نکردم نمیدونم اصولی هستند یا نه
ممنون میشم اگه نظراتتونو بگین
author
parsasi
پارسا صفوی
39 ماه قبل
سلام afarhad عزیز

قطعا راهی که پیشنهاد دادید راه جالبی نیست.
من فکر کنم که شما باید از همون یه جدول استفاده کنید ولی خب باید پایگاه دادتونو بهینه کنید و کویری های بهینه تری بزنید و البته که ایندکس گذاری مناسب داشته باشید.
سعی کنید چیزایی مثل Triggerروی جدول نداشته باشید که پردازش رو سنگین تر بکنه!

itpro باشید

author
afarhad
فرهاد مهریاری
39 ماه قبل
خب ببینید 150 میلیون رکورد رو توی جدول داریم
اجرای دستورات select,insert با سرعت کمی اجرا میشه اینکه میگین کوئری رو بهینه کنین , دستور select در حد ساده ترین شکل ممکن هست !
author
bargozideh
مصطفی اسماعیلی
39 ماه قبل
سلام عزیز
مبحث performance and tuning فقط مربوط به کوئری ها نیست
این ها رو ببینید :
1- استفاده از Memory Optimized Table برای جداولی که select های زیادی روی آنها زده میشود
2- استفاده از Partitioning در جداول بزرگ برای افزایش سرعت کوئری ها
3- استفاده از File Table برای صرفه جویی در مصرف حافظه و افزایش سرعت کوئری ها برای جداولی که داده های BLOB دارند
4- استفاده از Selective XML Index برای افزایش سرعت کوئری هایی که با XML کار میکنند.
5- استفاده از Service Broker برای درج تعداد زیاد رکورد و استفاده از مکانیزم صف
6- استفاده از Compression در جداول حجیم برای افزایش سرعت کوئری ها
7- استفاده از always On برای High available نگه داشتن دیتابیس ها
8- استفاده از Full Text Search برای سرعت بخشیدن به جستجو ها
9- استفاده از CLR Function
10- استفاده از Syntax های جدید کوئری نویسی مانند Window Function و OFFSET FETCH

احتمالا مورد یک و دو مشکلتتون رو حل میکنه

author
afarhad
فرهاد مهریاری
39 ماه قبل
مورد دوم همون طور که از اسمش معلومه فکر کنم اون چیزی باشه که من مد نظرمه
یعنی جدول رو پارتیشن پارتیشن تقسیم میکنه
author
HamidJFard
حمید ج. فرد
39 ماه قبل
Afarhad: شما می توانید با بهینه سازی کوری ها و گذاشتن ایندکس های درست سرعت سیستم را بالا ببرید. پارتیشن کردن پایگاه داده اگر هر پارتیشن در یک دیسک سخت جداگانه نباشد هیچ امتیازی ندارد بلکه به عملیات مدیریت پایگاه داده می افزاید.
البته من پایگاه داده ای را داشتم که روزانه ۳ میلیون رکورد وارد یک جدول می شد. پایگاه داده برای کارتهای اعتباری بود.

Bargozideh: مواردی که ذکر کردید بغیر از CLR Function درست است. استفاده از CLR Function باعث می شود تا نوع پردازش به Pre-emtive تغییر کندو باعث عملیات Context Switch بالا و هزینه زیادی برای مدیریت CLR برای SQL Server دارد.
author
afarhad
فرهاد مهریاری
39 ماه قبل
این که میگین کوئری رو بهینه کنم دقیق متوجه نمی شم! چون دستور من یا insert هست یا select !!!!!
و اینکه جدول ایندکس هم داره
این هم جدول مکان های کاربران :


حجم اطلاعاتی زیاد در پایگاه داده

author
HamidJFard
حمید ج. فرد
39 ماه قبل
منظور این است که Index Edge Key با Where Clause همخوانی داشته باشه.


author
M.T
محمد طارمی
39 ماه قبل
سلام حمید عزیز
منظور شما از این جمله "استفاده از CLR Function باعث می شود تا نوع پردازش به Pre-emtive تغییر کندو باعث عملیات Context Switch بالا و هزینه زیادی برای مدیریت CLR برای SQL Server دارد. "

در چه حالتی است؟
در حالت External_Access و Unsafe است؟

ودر ضمن در برخی سناریو ها مانند SQL Concatenate که با 4 الی 5 روش قابل پیاده سازی است ،روش استفاده از SQLCLR UDAs سرعت بالاتری نسبت به بقیه دارد.
آیا این قبیل موضوعات باعث تداخل خواهد شد؟
با سپاس
author
HamidJFard
حمید ج. فرد
39 ماه قبل
با سلام

در هر حالتی چه Safe, Unsafe , External_Access هزینه بالایی دارد مخصوصا هم که از طریق آن به پایگاه داده متصل شود.

اصولا به دلیل اینکه اجراء CLR زیر نظر SQL Server نیست باید عملیات Pre-Emtive و Context Switch برای مدیریت آن انجام شود.

به امید خدا در مورد این موضوع و مدیریت CLR در SQL Server یک رخداد آنلاین با یاری ITPRO برگذار خواهیم کرد

برای ارسال پست ابتدا به سایت وارد شوید

مطالب مرتبط

در حال دریافت اطلاعات