-
April 27th, 2011, 13:56
#1
یک دیتابیس بزرگ یا چندین دیتابیس کوچکتر
سلام به همه دوستان
با یه پروژه درگیرم که باید رکورد های زیادی دربر داشته باشه ! تقریبا 20 میلیون
و برای هر کاربر 5 جدول درست میشه
تعداد کاربران بیش از 1000 عدد خواهد بود
اما سوال : به نظر شما من از یک دیتا بیس بزرگ استفاده کنم و جدول ها رو برای هر کاربر کد گذاری کنم
ویا از تعداد زیادی دیتابیس اتفاده کنم.
لطفا در قالب مزایا و معایب و نتیجه گیری کلی ذکر کنید
با تشکر
مرتضی
-
-
April 27th, 2011 13:56
# ADS
-
April 27th, 2011, 14:08
#2
پاسخ : یک دیتابیس بزرگ یا چندین دیتابیس کوچکتر
این سئوال کردن داره ؟ 1000 تا کاربر هر کدوم 5 تا جدول میشه 5000 جدول ! اصولا هر کسی با تنظیمات mysql آشنا باشه میدونه که 5000 جدول تو یک دیتابیس یا حالا اصلا بگو 100 تا دیتابیس یه فاجعه برای سرور هست ....
شما باید طراحی دیتابیس بخونی یه کتاب بخر 3 - 4 هزارتومن یه نگاه بنداز بهش میفهمی چیجوری باید طراحی کنی ...
-
تعداد تشکر ها از ali2k به دلیل پست مفید
-
April 27th, 2011, 14:12
#3
پاسخ : یک دیتابیس بزرگ یا چندین دیتابیس کوچکتر
امیر خسرو معروفی
جهت ارتباط با من از پیغام خصوصی استفاده کنید.
-
تعداد تشکر ها از maroofi به دلیل پست مفید
-
April 27th, 2011, 15:16
#4
عضو دائم
پاسخ : یک دیتابیس بزرگ یا چندین دیتابیس کوچکتر

نوشته اصلی توسط
morsa
سلام به همه دوستان
با یه پروژه درگیرم که باید رکورد های زیادی دربر داشته باشه ! تقریبا 20 میلیون
و برای هر کاربر 5 جدول درست میشه
تعداد کاربران بیش از 1000 عدد خواهد بود
اما سوال : به نظر شما من از یک دیتا بیس بزرگ استفاده کنم و جدول ها رو برای هر کاربر کد گذاری کنم
ویا از تعداد زیادی دیتابیس اتفاده کنم.
لطفا در قالب مزایا و معایب و نتیجه گیری کلی ذکر کنید
با تشکر
مرتضی
تعریف جدول به ازای هر کاربر ؟!!
این یک ضعف شدید در طراحی دیتابیس به حساب میاد.
بستگی داره ، اکر قرار باشه در هر لود شدن به دیتابیس های مختلفی ارتباط بر قرار بشه عملا با کاهش سرعت و کارایی روبرو میشید ولی در حالت های خاص ممکنه به نفع باشه.
شما بگید قصد دارید چجور دیتابیسی رو طراحی کنید تا یک ساختار پیشنهادی اولیه پیشنهاد کنیم.
-
تعداد تشکر ها ازRezash به دلیل پست مفید
-
April 27th, 2011, 20:10
#5
پاسخ : یک دیتابیس بزرگ یا چندین دیتابیس کوچکتر

نوشته اصلی توسط
ali2k
این سئوال کردن داره ؟ 1000 تا کاربر هر کدوم 5 تا جدول میشه 5000 جدول ! اصولا هر کسی با تنظیمات mysql آشنا باشه میدونه که 5000 جدول تو یک دیتابیس یا حالا اصلا بگو 100 تا دیتابیس یه فاجعه برای سرور هست ....
شما باید طراحی دیتابیس بخونی یه کتاب بخر 3 - 4 هزارتومن یه نگاه بنداز بهش میفهمی چیجوری باید طراحی کنی ...
ممنون از راهنمایی شما دوست عزیز !
گیر همون 3 - 4 هزار تومن هستم به جان تو !!
سیستم مای اس کیو ال اگر از نظر سخت افزاری تامین بشه تا 60و000 جدول و 60 میلیون رکورد رو بدون مشکل پشتیبانی می کنه !
سوال من این بود کدوم روش بهتره !
در حالت تک دیتابیس در هر جستجو اولیه باید جدول مورد نظر رو پیدا کنه ! 1/5000 زمان جستجو بعد ازاون تازه میرسه به عمل کئوری
از نظر امنیتی هم فقط نیاز به ست کردن یک پسورد می باشد

نوشته اصلی توسط
maroofi
سنگین میشه عموجون.
دستت درد نکنه !

نوشته اصلی توسط
Rezash
تعریف جدول به ازای هر کاربر ؟!!
این یک ضعف شدید در طراحی دیتابیس به حساب میاد.
بستگی داره ، اکر قرار باشه در هر لود شدن به دیتابیس های مختلفی ارتباط بر قرار بشه عملا با کاهش سرعت و کارایی روبرو میشید ولی در حالت های خاص ممکنه به نفع باشه.
شما بگید قصد دارید چجور دیتابیسی رو طراحی کنید تا یک ساختار پیشنهادی اولیه پیشنهاد کنیم.
ممنون ازپاسختون
سیستم طراحی و پیاده سازی اطلاعات یک سازمان بزرگ است که برای هر عضو 5 جدول باید ، سوابق ، پرداختی ها و ... که ممکن است برای هر جدول تا 50000 رکورد برای یک سال در نظر گرفته شود . تعداد اعضا هم بیش از 1000 نفر می باشد
سالانه اطلاعات بایگانی و از سیستم خارج می شوند !
امنیت این داده ها در درجه اول قرار دارد
به همین دلیل من سیستم رو بر مبنای 1000+1 دیتابیس طراحی کردم به شکلی که هر دیتابیس کاربر با یوزر پس مخصوص به خودش کانکت میشه !
و یک دیتابیس مادر که اطلاعات 1000 تای دیگه و یوزر ها رو ذخیره سازی میکنه !
البته این نکته رو باید اضافه کنم که هیچدیتاسنتری با این شرایط
به ما پا نداد و مجبور شدیم یه سرور راه اندازی کنیم !
حالا دوستان به جای نصیحت ، نقد کنند به صورت علمی ممنون میشم
یه نکته جالب ! جستجو درگوگل هر دقیقه 4 تن دی اکسید کربن وارد فضا می کند. این مواد از سیستم خنک کننده دیتاسنتر ها ناشی می شوند
حالا این دوستمون میگه 5000 جدول سنگینه !!
منتظر نظراتتون هستم
ممنون - مرتضی
-
-
April 27th, 2011, 20:19
#6
عضو دائم
پاسخ : یک دیتابیس بزرگ یا چندین دیتابیس کوچکتر
برای هر عضو 5 جدول باید ، سوابق ، پرداختی ها و ...
اين قسمت براي من نا مفهوم هست.
به جاي اينكه هر يوزر 5 جدول داشته باشه كلا 5 جدول داشته باشيم + يك ستون اضافه كه اين ستون id شخص رو در بر ميگيره.
-
-
April 27th, 2011, 20:20
#7
پاسخ : یک دیتابیس بزرگ یا چندین دیتابیس کوچکتر
هنوز درس پایگاه داده رو پاس نکردم ولی از نظر سیستمی هر چقدر دیتابیس هاتون کمتر باشه بهتره. اینجوری فکر کنم سرعت دسترسی بالاتر از چندتا دیتابیس باشه. تو چندتا دیتابیس امنیت هم کمتره و به نحوی گسستگی اطلاعات هم صورت می گیره. بعضی مواقع مجبورید برای یه دیتابیس یه دیتاسنتر ایجاد کنید!
-
-
April 27th, 2011, 20:40
#8
پاسخ : یک دیتابیس بزرگ یا چندین دیتابیس کوچکتر
یه نکته جالب ! جستجو درگوگل هر دقیقه 4 تن دی اکسید کربن وارد فضا می کند. این مواد از سیستم خنک کننده دیتاسنتر ها ناشی می شوند
حالا این دوستمون میگه 5000 جدول سنگینه !!
هنوز هم با اطمینان کامل میگم که 5000 جدول کاملا اشتباه هست ! ولی خب کلا باید سرتون به سنگ بخوره تا قبول کنید 
راه حل درست شما 5 تا جدول هست ، برای هر جدول یک ستون به عنوان id کاربر تعریف می کنید و تمام اطلاعات همه این 1000 کاربر داخل همین 5 جدول قرار می گیرد.
حالا با گفته خود شما اگر 50000 رکورد هم برای هر کاربر در سال وجود داشته باشد ضربدر 1000 کاربر نهایت میشود 50 میلیون رکورد.
برای 50 میلیون رکورد باید ابتدا نوع کوئری ها تعیین شود و ایندکس گذاری صحیح براساس کوئری ها انجام شود.
سپس باید جدول ها با توجه به نوع کوئری ها پارتیشن بندی شود.
کلا همین سروری که این دیتابیس را بخواد بالا بیاره باید کلی رم + هارد سرعت بالا + سی پی یو درست حسابی داشته باشه چیزی که همش هزینه هست ... 5 میلیون هزینه همین سرور هست.
حالا شما برو 5000 تا جدول بساز بعدا بیاد اینجا تاپیک بزن "تو بد مخمصه ای گیر افتادم چیکار کنم" :دی
-
-
April 27th, 2011, 20:52
#9
پاسخ : یک دیتابیس بزرگ یا چندین دیتابیس کوچکتر

نوشته اصلی توسط
Rezash
اين قسمت براي من نا مفهوم هست.
به جاي اينكه هر يوزر 5 جدول داشته باشه كلا 5 جدول داشته باشيم + يك ستون اضافه كه اين ستون id شخص رو در بر ميگيره.
سلام
درسته حق باشماست اما یک سری مسائل دیگه در این طراحی در نظر گرفته شده !
این 5 جدول یک رابطه خاصی با یکدیگر دارند . در بعضی از پردازش ها حتی 2 جدول به عنوان فهرست برای جدول بعدی در نظر گرفته شود !
الگریتم مورد نظر شما در ابتدا پیاده سازی شد اما حتی با حجم پایین اطلاعات زمان پردازش مناسبی نمی داد !
کاش می تونستم پروپوزال رو اینجا بزارم ولی ... !
نکته ای دیگه ! امنیت در این سیستم خیلی مهمه ! برای بکاپ گیری که توسط خود کاربران انجام میشه از اطلاعاتشون بکاپ گرفته میشه که در حالت جدا بودن این کار سریعتر و راحتره !
و بکاپ گیری توسط خود سرور توسط یک نرم افزار دست نویس انجام میشه که هر یک ساعت یه نسخه از اطلاعات بانک رو داخل یک هارد اکسترنال کپی میکنه !
کمک کنید ! تحلیل کنید ! ممنون
---------- Post added at 08:52 PM ---------- Previous post was at 08:45 PM ----------

نوشته اصلی توسط
ali2k
هنوز هم با اطمینان کامل میگم که 5000 جدول کاملا اشتباه هست ! ولی خب کلا باید سرتون به سنگ بخوره تا قبول کنید
راه حل درست شما 5 تا جدول هست ، برای هر جدول یک ستون به عنوان id کاربر تعریف می کنید و تمام اطلاعات همه این 1000 کاربر داخل همین 5 جدول قرار می گیرد.
حالا با گفته خود شما اگر 50000 رکورد هم برای هر کاربر در سال وجود داشته باشد ضربدر 1000 کاربر نهایت میشود 50 میلیون رکورد.
برای 50 میلیون رکورد باید ابتدا نوع کوئری ها تعیین شود و ایندکس گذاری صحیح براساس کوئری ها انجام شود.
سپس باید جدول ها با توجه به نوع کوئری ها پارتیشن بندی شود.
کلا همین سروری که این دیتابیس را بخواد بالا بیاره باید کلی رم + هارد سرعت بالا + سی پی یو درست حسابی داشته باشه چیزی که همش هزینه هست ... 5 میلیون هزینه همین سرور هست.
حالا شما برو 5000 تا جدول بساز بعدا بیاد اینجا تاپیک بزن "تو بد مخمصه ای گیر افتادم چیکار کنم" :دی
چشم !
ببین دوست عزیز این که شما میگید کاملا منطقی هست ! تو پست قبلی به اقا رضا عرض کردم ! نمیشه جدول یک کاربر رو با جدول کاربر دیگه قاطی کرد !
به خاطر رابطه هایی که دارند .
درصورتی که به مشکل سنگین برخورد کنیم با شکستن دیتابیس ها با نرم افزار های دستی و تغییر شکل اونها میشه راحت مشکل رو حل کرد
شما اگر مزایا ومعایب هر کدوم رو بشمرید ممنون میشم
-
-
April 27th, 2011, 21:15
#10
پاسخ : یک دیتابیس بزرگ یا چندین دیتابیس کوچکتر
این 5 جدول یک رابطه خاصی با یکدیگر دارند . در بعضی از پردازش ها حتی 2 جدول به عنوان فهرست برای جدول بعدی در نظر گرفته شود !
الگریتم مورد نظر شما در ابتدا پیاده سازی شد اما حتی با حجم پایین اطلاعات زمان پردازش مناسبی نمی داد !
نمیشه جدول یک کاربر رو با جدول کاربر دیگه قاطی کرد !
به خاطر رابطه هایی که دارند .
پیشنهاد من هم اینه که جدول های جداگانه ایجاد نکنید.
کوری ها رو بهینه کنید. امنیت هم ربطی به جدا بودن یا نبودن جداول نداره.
-