PDA

View Full Version : حرفه ای: معماری MySQL برای امور خاص



sedamorde
شنبه 09 بهمن 1389, 00:46 صبح
سلام دوستان
من چند تا سؤال در مورد طراحی دیتابیس پروژه ای که انجام میدیم دارم، اگر شما بتونید کمکم کنید خیلی ممنون میشم.

میخوام برای 30000 کاربر یک بانک بسازم که اطلاعات بسیار بسیار زیادی را قرار نگهداری کنه برای همین خیلی مهم که بهترین راه ها را انتخاب کنم.

حدود 50 عدد صحیح را میخوام در یک table نگهداری کنم برای این کار 2 روش به ذهن خود رسید:
1- 50 فیلد در نظر بگیرم
2- 10 تا فیلد در نظر بگیرم و اعداد را به این صورت نگهداری کنم : 100-200-300-400-500 بعد داخل برنامه - را جدا کنم (explode) و مقدارها را در array قرار بدم.

البته من این دو روش را تست کردم و 11.000 رکورد مشابه وارد دو جدول که به ترتیب روش 1 و 2 ساخته شده بود کردم، حجم جدول 1 برابر بود با 1.5 MB و جدول 2 برابر 2.1 MB شد! به نظر شما بهترین روش چیه!؟

سوال بعدی من اینکه اگر از روش 1 استفاده کنم بهتر تمام فیلدها در یک table باشه یا در چند table؟ البته برنامه هر بار به تمام این فیلدها نیاز داره! در کتابی خوندم (خیلی معتبر نبود) که table بیشتر بهتر از فیلد بیشتره!
اگر کسی هم میدونه که MySQL حداکثر چه مقدار داده ای را میتونه نگهداری کنه و در ثانیه میتونه به چند نفر پاسخگو باشه ممنون میشم بگه.

مرسی :)

sedamorde
یک شنبه 10 بهمن 1389, 09:22 صبح
هیچ کس نظری نداره؟ :|

idinex
جمعه 15 بهمن 1389, 14:27 عصر
به نظر من بهتره براي هر عدد يك فيلد در نظر بگيري . چونكه دسترسي دقيق به هر عدد ميسر ميشه و شما دقيقا مي دوني داري كدوم عدد رو فرا خواني مي كني. و ميشه هر عددي كه خواستي ايندكس كني و يكي چيز خيلي مهم وجود داره كه اگر شما فيلدها رو يكي كني مجبوري از فيلدهاي رشته اي استفاده كني .

ولي وقتي هر عدد در يك فيلد باشه مي تونه به صورت عددي ذخيره كني كه خوب مسلما ذخيره اطلاعات به صورت عدد خيلي بهتره

اسفاده از چند تيبل به امر normalize مربوط ميشه و براي جلوگيري از افزونگي داده ها بكار ميره. در صورتي كه شما حتما بايد همه فيلدها رو پر كني زياد فرقي نداره.

از لحاظ حجم دادها در هر table و در نسخه ماي اسكيو ال ۵ ، به صورت نظري ميشه حدود ۲۸۱ ترابايت اطلاعات رو در هر table نگهداري كرد.

اما تعداد پاسخگويي به كاربران در يك زمان كه Concurrency گفته مي شود ، كاملا به تنظيم سرور ماي اسكيوال و امكانات سخت افزاري سرور بستگي داره.

sedamorde
شنبه 16 بهمن 1389, 11:35 صبح
idinex جان ممنون، خوشحالم بالاخره یه نفر پیدا شد به من کمک کنه :)

من خیلی تحقیق کردم و به این نتیجه رسیدم که normalize خیلی مهم و (همانطور که شما اشاره کردید) چون من به تمام فیلدها نیاز دارم بهتره که تعداد table ها بیشتر باشه و به صورت رشته ای چیزی ذخیره نکنم، اینطوری کار کردن با دیتابیس هم ساده تر میشه. یعنی فکر کنم بهتره که من این 50 فیلد را در 10 table ذخیره کنم. حالا تنها چیزی که نمیدونم اینکه اگر تعداد رکوردها زیاد بشه سرعت چقدر کم میشه!؟ چون با این تقسیم بندی حجم table ها کمتر میشه اما 30000 رکورد میشه 300000 رکورد که البته در 10 فایل قرار میگیره و فکر کنم سرعت بهتری پیدا میکنه!
به هر حال اگر باز هم نظری دارید خوشحال میشم بشنوم.
تشکر

idinex
شنبه 16 بهمن 1389, 22:31 عصر
خوشحالم كه براتون مفيد بوده
من تاكيدم روي دو مورده.

۱- از اونجاييكه شما بايد همه ركوردها رو پر كنيد پس همش رو در يك تيبل نگهداريد. چرا ؟
به اين علت كه خوندن اطلاعات از يك تيبل سريعتر است تا خواندن اطلاعات از چند تيبل و احتمالا Join كردن table ها. زماني توصيه ميشه اطلاعات در چند تيبل ذخيره بشن كه قرار نيست همه فيلدها پر بشوند. مثلا فكر كنيد اطلاعات يك كاربر را مي خواهند ذخيره كنند و قرار است سه مورد از تخصصهاي يك فرد در ديتابيس ذخيره شود
مي توان سه فيلد با عنوانهاي skill1, skill2, skill3 در نظر بگيرند. حال اگر يك كاربر فقط يك مهارت داشت دو فيلد ديگر خالي مي ماند. پس مهارت هاي يك فرد را در يك تيبل جدا ذخيره مي كنند و كد كاربري كاربر را به آن ركورد اختصاص مي دهند . به اين ترتيب هر كاربر مي تواند بي نهايت مورد را به عنوان مهارت ذخيره كند. پس جدا نمودن فيلدها زماني ضرورت مي يابد كه اصولا قرار نيست همه فيلدها پر شوند و به احتمال قوي برخي از فيلدها خالي مي مانند. پس زمانيكه شما همه فيلدها را پر مي كنيد نيازي به ذخيره فيلدها در چند تيبل نيست و خصوصا همانطور كه قبلا گفتم جدا سازي فيلدها در چند تيبل موجب كند شدن خواندن اطلاعات هم مي شود.

اما تعداد ۳۰۰/۰۰۰ ركورد اصولا عددي نيست كه جاي نگراني داشته باشد. مهمتر اينكه فيلدهاي شما عددي هستند. براي اينكه خيال شما راحت شود من در يك تست ساده كه بر روي ۸/۰۰۰/۰۰۰ ركورد اطلاعات انجام دادم ، زماني كه بر لود اطلاعات مورد نظر صرف مي شد. بسيار ناچيز و در حد يك صدم ثانيه بود.

بنابراين اگر ايندكس گذاري درست باشد و همچين ديتابيس هم درست پيكر بندي شود جاي هيچ گونه نگراني نيست

موفق و پيروز باشيد

sedamorde
دوشنبه 18 بهمن 1389, 01:07 صبح
مرسی دوست عزیز
برای شما پیام دادم تا اگر شما با هم بیشتر با هم صحبت کنیم.

شاید برای دیگران هم این نکته جالب باشه، من دو table درست کردم و دقیقا 1.000.000 داده در هر کدوم از آنها وارد کردم (البته به صورت عدد بود بیشترش). 250MB حجم هر table شد. با php به صورت رندم رکوردهایی را انتخاب کردم و برام جالب بود که فقط چند صدم ثانیه طول کشید تا پردازش بشه!

idinex
دوشنبه 18 بهمن 1389, 18:04 عصر
خواهش می کنم.

خیلی خوب شده که تست کردید. فکر کنم خیالتون هم در مورد سرعت دیتابیس MySQL راحت شده باشه

موفق باشید

DddError
جمعه 13 اسفند 1389, 14:44 عصر
مزایای جدول 2nf نسبت به 3nf در چیه؟


یعنی در چه زمانی می صرفه که ما جدول رو به فرم سوم تبدیل نکنیم از فرم دوم استفاده کنیم؟