توجه ! این یک نسخه آرشیو شده میباشد و در این حالت شما عکسی را مشاهده نمیکنید برای مشاهده کامل متن و عکسها بر روی لینک مقابل کلیک کنید : یک دیتابیس بزرگ یا چندین دیتابیس کوچکتر
morsa
April 27th, 2011, 13:56
سلام به همه دوستان
با یه پروژه درگیرم که باید رکورد های زیادی دربر داشته باشه ! تقریبا 20 میلیون
و برای هر کاربر 5 جدول درست میشه
تعداد کاربران بیش از 1000 عدد خواهد بود
اما سوال : به نظر شما من از یک دیتا بیس بزرگ استفاده کنم و جدول ها رو برای هر کاربر کد گذاری کنم
ویا از تعداد زیادی دیتابیس اتفاده کنم.
لطفا در قالب مزایا و معایب و نتیجه گیری کلی ذکر کنید
با تشکر
مرتضی
ali2k
April 27th, 2011, 14:08
این سئوال کردن داره ؟ 1000 تا کاربر هر کدوم 5 تا جدول میشه 5000 جدول ! اصولا هر کسی با تنظیمات mysql آشنا باشه میدونه که 5000 جدول تو یک دیتابیس یا حالا اصلا بگو 100 تا دیتابیس یه فاجعه برای سرور هست ....
شما باید طراحی دیتابیس بخونی یه کتاب بخر 3 - 4 هزارتومن یه نگاه بنداز بهش میفهمی چیجوری باید طراحی کنی ...
maroofi
April 27th, 2011, 14:12
سنگین میشه عموجون.
Rezash
April 27th, 2011, 15:16
سلام به همه دوستان
با یه پروژه درگیرم که باید رکورد های زیادی دربر داشته باشه ! تقریبا 20 میلیون
و برای هر کاربر 5 جدول درست میشه
تعداد کاربران بیش از 1000 عدد خواهد بود
اما سوال : به نظر شما من از یک دیتا بیس بزرگ استفاده کنم و جدول ها رو برای هر کاربر کد گذاری کنم
ویا از تعداد زیادی دیتابیس اتفاده کنم.
لطفا در قالب مزایا و معایب و نتیجه گیری کلی ذکر کنید
با تشکر
مرتضی
تعریف جدول به ازای هر کاربر ؟!!
این یک ضعف شدید در طراحی دیتابیس به حساب میاد.
بستگی داره ، اکر قرار باشه در هر لود شدن به دیتابیس های مختلفی ارتباط بر قرار بشه عملا با کاهش سرعت و کارایی روبرو میشید ولی در حالت های خاص ممکنه به نفع باشه.
شما بگید قصد دارید چجور دیتابیسی رو طراحی کنید تا یک ساختار پیشنهادی اولیه پیشنهاد کنیم.
morsa
April 27th, 2011, 20:10
این سئوال کردن داره ؟ 1000 تا کاربر هر کدوم 5 تا جدول میشه 5000 جدول ! اصولا هر کسی با تنظیمات mysql آشنا باشه میدونه که 5000 جدول تو یک دیتابیس یا حالا اصلا بگو 100 تا دیتابیس یه فاجعه برای سرور هست ....
شما باید طراحی دیتابیس بخونی یه کتاب بخر 3 - 4 هزارتومن یه نگاه بنداز بهش میفهمی چیجوری باید طراحی کنی ...
ممنون از راهنمایی شما دوست عزیز !
گیر همون 3 - 4 هزار تومن هستم به جان تو !!
سیستم مای اس کیو ال اگر از نظر سخت افزاری تامین بشه تا 60و000 جدول و 60 میلیون رکورد رو بدون مشکل پشتیبانی می کنه !
سوال من این بود کدوم روش بهتره !
در حالت تک دیتابیس در هر جستجو اولیه باید جدول مورد نظر رو پیدا کنه ! 1/5000 زمان جستجو بعد ازاون تازه میرسه به عمل کئوری
از نظر امنیتی هم فقط نیاز به ست کردن یک پسورد می باشد
سنگین میشه عموجون.
دستت درد نکنه !
تعریف جدول به ازای هر کاربر ؟!!
این یک ضعف شدید در طراحی دیتابیس به حساب میاد.
بستگی داره ، اکر قرار باشه در هر لود شدن به دیتابیس های مختلفی ارتباط بر قرار بشه عملا با کاهش سرعت و کارایی روبرو میشید ولی در حالت های خاص ممکنه به نفع باشه.
شما بگید قصد دارید چجور دیتابیسی رو طراحی کنید تا یک ساختار پیشنهادی اولیه پیشنهاد کنیم.
ممنون ازپاسختون
سیستم طراحی و پیاده سازی اطلاعات یک سازمان بزرگ است که برای هر عضو 5 جدول باید ، سوابق ، پرداختی ها و ... که ممکن است برای هر جدول تا 50000 رکورد برای یک سال در نظر گرفته شود . تعداد اعضا هم بیش از 1000 نفر می باشد
سالانه اطلاعات بایگانی و از سیستم خارج می شوند !
امنیت این داده ها در درجه اول قرار دارد
به همین دلیل من سیستم رو بر مبنای 1000+1 دیتابیس طراحی کردم به شکلی که هر دیتابیس کاربر با یوزر پس مخصوص به خودش کانکت میشه !
و یک دیتابیس مادر که اطلاعات 1000 تای دیگه و یوزر ها رو ذخیره سازی میکنه !
البته این نکته رو باید اضافه کنم که هیچدیتاسنتری با این شرایط :"> به ما پا نداد و مجبور شدیم یه سرور راه اندازی کنیم !
حالا دوستان به جای نصیحت ، نقد کنند به صورت علمی ممنون میشم
یه نکته جالب ! جستجو درگوگل هر دقیقه 4 تن دی اکسید کربن وارد فضا می کند. این مواد از سیستم خنک کننده دیتاسنتر ها ناشی می شوند
حالا این دوستمون میگه 5000 جدول سنگینه !!
منتظر نظراتتون هستم
ممنون - مرتضی
Rezash
April 27th, 2011, 20:19
برای هر عضو 5 جدول باید ، سوابق ، پرداختی ها و ...
اين قسمت براي من نا مفهوم هست.
به جاي اينكه هر يوزر 5 جدول داشته باشه كلا 5 جدول داشته باشيم + يك ستون اضافه كه اين ستون id شخص رو در بر ميگيره.
Birserver
April 27th, 2011, 20:20
هنوز درس پایگاه داده رو پاس نکردم ولی از نظر سیستمی هر چقدر دیتابیس هاتون کمتر باشه بهتره. اینجوری فکر کنم سرعت دسترسی بالاتر از چندتا دیتابیس باشه. تو چندتا دیتابیس امنیت هم کمتره و به نحوی گسستگی اطلاعات هم صورت می گیره. بعضی مواقع مجبورید برای یه دیتابیس یه دیتاسنتر ایجاد کنید!
ali2k
April 27th, 2011, 20:40
یه نکته جالب ! جستجو درگوگل هر دقیقه 4 تن دی اکسید کربن وارد فضا می کند. این مواد از سیستم خنک کننده دیتاسنتر ها ناشی می شوند
حالا این دوستمون میگه 5000 جدول سنگینه !!
هنوز هم با اطمینان کامل میگم که 5000 جدول کاملا اشتباه هست ! ولی خب کلا باید سرتون به سنگ بخوره تا قبول کنید :)
راه حل درست شما 5 تا جدول هست ، برای هر جدول یک ستون به عنوان id کاربر تعریف می کنید و تمام اطلاعات همه این 1000 کاربر داخل همین 5 جدول قرار می گیرد.
حالا با گفته خود شما اگر 50000 رکورد هم برای هر کاربر در سال وجود داشته باشد ضربدر 1000 کاربر نهایت میشود 50 میلیون رکورد.
برای 50 میلیون رکورد باید ابتدا نوع کوئری ها تعیین شود و ایندکس گذاری صحیح براساس کوئری ها انجام شود.
سپس باید جدول ها با توجه به نوع کوئری ها پارتیشن بندی شود.
کلا همین سروری که این دیتابیس را بخواد بالا بیاره باید کلی رم + هارد سرعت بالا + سی پی یو درست حسابی داشته باشه چیزی که همش هزینه هست ... 5 میلیون هزینه همین سرور هست.
حالا شما برو 5000 تا جدول بساز بعدا بیاد اینجا تاپیک بزن "تو بد مخمصه ای گیر افتادم چیکار کنم" :دی
morsa
April 27th, 2011, 20:52
اين قسمت براي من نا مفهوم هست.
به جاي اينكه هر يوزر 5 جدول داشته باشه كلا 5 جدول داشته باشيم + يك ستون اضافه كه اين ستون id شخص رو در بر ميگيره.
سلام
درسته حق باشماست اما یک سری مسائل دیگه در این طراحی در نظر گرفته شده !
این 5 جدول یک رابطه خاصی با یکدیگر دارند . در بعضی از پردازش ها حتی 2 جدول به عنوان فهرست برای جدول بعدی در نظر گرفته شود !
الگریتم مورد نظر شما در ابتدا پیاده سازی شد اما حتی با حجم پایین اطلاعات زمان پردازش مناسبی نمی داد !
کاش می تونستم پروپوزال رو اینجا بزارم ولی ... !
نکته ای دیگه ! امنیت در این سیستم خیلی مهمه ! برای بکاپ گیری که توسط خود کاربران انجام میشه از اطلاعاتشون بکاپ گرفته میشه که در حالت جدا بودن این کار سریعتر و راحتره !
و بکاپ گیری توسط خود سرور توسط یک نرم افزار دست نویس انجام میشه که هر یک ساعت یه نسخه از اطلاعات بانک رو داخل یک هارد اکسترنال کپی میکنه !
کمک کنید ! تحلیل کنید ! ممنون
---------- Post added at 08:52 PM ---------- Previous post was at 08:45 PM ----------
هنوز هم با اطمینان کامل میگم که 5000 جدول کاملا اشتباه هست ! ولی خب کلا باید سرتون به سنگ بخوره تا قبول کنید :)
راه حل درست شما 5 تا جدول هست ، برای هر جدول یک ستون به عنوان id کاربر تعریف می کنید و تمام اطلاعات همه این 1000 کاربر داخل همین 5 جدول قرار می گیرد.
حالا با گفته خود شما اگر 50000 رکورد هم برای هر کاربر در سال وجود داشته باشد ضربدر 1000 کاربر نهایت میشود 50 میلیون رکورد.
برای 50 میلیون رکورد باید ابتدا نوع کوئری ها تعیین شود و ایندکس گذاری صحیح براساس کوئری ها انجام شود.
سپس باید جدول ها با توجه به نوع کوئری ها پارتیشن بندی شود.
کلا همین سروری که این دیتابیس را بخواد بالا بیاره باید کلی رم + هارد سرعت بالا + سی پی یو درست حسابی داشته باشه چیزی که همش هزینه هست ... 5 میلیون هزینه همین سرور هست.
حالا شما برو 5000 تا جدول بساز بعدا بیاد اینجا تاپیک بزن "تو بد مخمصه ای گیر افتادم چیکار کنم" :دی
چشم !
ببین دوست عزیز این که شما میگید کاملا منطقی هست ! تو پست قبلی به اقا رضا عرض کردم ! نمیشه جدول یک کاربر رو با جدول کاربر دیگه قاطی کرد !
به خاطر رابطه هایی که دارند .
درصورتی که به مشکل سنگین برخورد کنیم با شکستن دیتابیس ها با نرم افزار های دستی و تغییر شکل اونها میشه راحت مشکل رو حل کرد
شما اگر مزایا ومعایب هر کدوم رو بشمرید ممنون میشم
Talahost.Com
April 27th, 2011, 21:15
این 5 جدول یک رابطه خاصی با یکدیگر دارند . در بعضی از پردازش ها حتی 2 جدول به عنوان فهرست برای جدول بعدی در نظر گرفته شود !
الگریتم مورد نظر شما در ابتدا پیاده سازی شد اما حتی با حجم پایین اطلاعات زمان پردازش مناسبی نمی داد !
نمیشه جدول یک کاربر رو با جدول کاربر دیگه قاطی کرد !
به خاطر رابطه هایی که دارند .
پیشنهاد من هم اینه که جدول های جداگانه ایجاد نکنید.
کوری ها رو بهینه کنید. امنیت هم ربطی به جدا بودن یا نبودن جداول نداره.
Rezash
April 27th, 2011, 22:00
ضعف در در سخت افزار سرور رو نبايد عاملي براي ضعف در طراحي قرار بديد.
شديدا تاكيد ميكنم ايجاد 5 جدول براي هر كاربر يا يك ديتابيس براي هر كاربر يك ضعف شديد و در سطح بالا جبران نشدني براي پروژه شما به حساب مياد.
mysql در بزرگترين سايت هاي جهان با حجم وسيعي از اطلاعات داره كار ميكنه و مشكلي پيش نمياد.
اينكه شما سرعت مناسبي نگرفتيد رو بايد دنبال علتش باشيد و ضعفش رو پيدا كنيد نه اينكه با يك روش غير منطقي سعي در پوشوندش داشته باشيد.
در سطح بالا براي انتخاب و ساير دستورات بايد نهايت دقت رو به كار برد ، به عنوان مثال اگر در دو جدول با 5 ميليون ركورد اول join كنيم بعد شرط بذاريم (يا ...) و حالت برعكس ممكنه تفاوت مقايسه در حد ميليون ركورد باشه.
شما اطلاعاتي در مورد كارتون نداديد و مطمئن باشيد بيش از اين با اين اطلاعات نميشه راهنمايي كرد.
چه جور رابطه هايي داريم ؟ چرا ميگيد امنيت اين روش پايين تره ؟ اگر خود پروژه رو نمي تونيد توضيح بديد با يك مثال و شبيه سازي قضيه رو روشن كنيد.
morsa
April 28th, 2011, 10:28
سلام به همه دوستان
و ممنون از پیگیریتون و شرمنده از اینکه ناقص توضیح می دم
فرض کنید یه سازمان مثل استان قدس با طرف های مالی خودش که اشخاص حقیقی و حقوقی هستند در یک سیستم تبادل داده های مالی دارند
1 - هر شرکت و یا هر فرد به طور جداگانه دارای یک سیستم حسابداری کامل میباشد ( بدون در نظر گرفتن رابطه مالی با سازمان)
حالا کنار این شما فرض کنید از تعریف حسابهای داخلی ، حسابهای مشترک ، حسابهای شخصی و ... تا سیستم مکاتبات و پیگیری چک و ... ( این داستان ادامه دارد :-> )
ما یک گروه 5 نفره طراح هستیم که حدود 3 ماه داریم این سیستم رو پیاده سازی می کنیم
ولی حالا بعد از اتمام کار به سیستم دیتابیس مون شک کردیم به سفارش یکی از دوستان که مسئول راه اندازی سرور مونه که توی این فروم هم دست به کیبورد داره این مسئله رو اینجا مطرح کردم !
2 تا سرور راه انداری کردیم سرور اول سرور محاسبات و سایت و سرور دوم دیتاسنتر که فقط mysql نصبه !
و هردو از نظر سخت افزاری سنگین بسته شدن
این مسئله که تمام داده های این افراد داخل 5 جدول باشه بنا به الگریتم کاری و سفارشات بخش آی تی سازمان مردوده ! میمونه دوحالت یک دیتابیس با بیش از 5000 جدول و یا 1000 دیتابیس هر کدوم با 5 جدول
دوستان اگر مرجعی درباره هسته mysql و نحوه الگریتم کاری اون دارند بزارن میشه بررسی کرد
اگه سیستم کاری و موتور داخلی mysql به صورت شاخه ای باشه حالت 1000 دیتابیس بهتر به نظر میاد
یعنی اول دیتابیس پیداکنه ، بعد جدول رو بعد رکورد مورد نظر ! حالا به چه نوع پیمایشی جلو میره داخل هر کدوم مهم نیست
دوستان کمک کنند ممنون میشم !
Rezash
April 28th, 2011, 12:41
ببينيد اگر واقعا فكر ميكنم mysql توان كشش حجم اطلاعاتي شما رو نداره در اين صورت ميتونيد دسته بندي كنيد.
دسته بندي نبايد به ازاي هر يوزر و يا چند يوزر باشه.يك رابطه ي منطقي ايجاد كنيد.
اگر به سبكي كه ميگيد در ابتدا بايد با يك ديتابيس ارتباط برقرار كنيم ، ببينيم اين يوزر در كدام db يا جدول هست ، اطلاعات اون db رو بگيريم ، متصل بشيم و ...
ولي شما ميتونيد ديتابيس ها رو بر اساس سال ورود،حروف نام خانوادگي ! شماره ملي يا ... و ... با يك نسبت بندي درست انتخاب كنيم.
به عنوان يك مثال خيلي ساده اگر اول حرف اسم شخص a بود به ديتابيس a_db سريعا مراجعه كنيد.
البته من هنوزم اين روش رو درست نميدونم ولي شما چون خودتون بيشتر در جريان پروژه هستيد شايد بهتر ميدونيد.
ولي در اصل طراحي بايد جداول منحصر به فرد باشند و رابطه ها رو با كليد اصلي و فرعي و ايندكس گذاري مناسب ايجاد كنيم و با اين تكنيك ها سرعت جستجو و عمليات رو افزايش بديم.
در مورد اصول طراحي db در دانشگاهها معمولا كتاب آقاي رانكوهي تدريس ميشه.
morsa
April 28th, 2011, 13:17
ببينيد اگر واقعا فكر ميكنم mysql توان كشش حجم اطلاعاتي شما رو نداره در اين صورت ميتونيد دسته بندي كنيد.
دسته بندي نبايد به ازاي هر يوزر و يا چند يوزر باشه.يك رابطه ي منطقي ايجاد كنيد.
اگر به سبكي كه ميگيد در ابتدا بايد با يك ديتابيس ارتباط برقرار كنيم ، ببينيم اين يوزر در كدام db يا جدول هست ، اطلاعات اون db رو بگيريم ، متصل بشيم و ...
ولي شما ميتونيد ديتابيس ها رو بر اساس سال ورود،حروف نام خانوادگي ! شماره ملي يا ... و ... با يك نسبت بندي درست انتخاب كنيم.
به عنوان يك مثال خيلي ساده اگر اول حرف اسم شخص a بود به ديتابيس a_db سريعا مراجعه كنيد.
البته من هنوزم اين روش رو درست نميدونم ولي شما چون خودتون بيشتر در جريان پروژه هستيد شايد بهتر ميدونيد.
ولي در اصل طراحي بايد جداول منحصر به فرد باشند و رابطه ها رو با كليد اصلي و فرعي و ايندكس گذاري مناسب ايجاد كنيم و با اين تكنيك ها سرعت جستجو و عمليات رو افزايش بديم.
در مورد اصول طراحي db در دانشگاهها معمولا كتاب آقاي رانكوهي تدريس ميشه.
ممنون
اصرار شما بر اینه که تعداد دیتابیس ها کم بشه به هر شکلی که ممکنه
دسته بندی یوزر ها باساس اولویتها
دسته بندی گزینشی ( انتخاب دستی)
ولی چرا ! این برداشت من درسته :
هر چی تعداد دیتابیس بیشتر باشه سرعت کمتره !
چرا ؟؟
شاید کمی بی ممنطق به نظر برسد که اگر من با درخواست یا کوئری دستور جستجوی در دیتابیس m1258 رو بدم برای مثال با حجم 100000 رکورد
و mysql پارامترهای سایر دیتابیس ها مثل k546 , ... رو هم درنظر بگیره ( بازم برمیگرده به الگریتم داخلی)
البته امکان داره که با کش کردن یک بانک در یک جستجو ، زمانی که تعداد دیتابیس ها بیشتر باشه سیستم با افت سرعت مواجه بشه
اگر بشه جزئیات رو بدست اورد بهتر میشه تصمیم گرفت
morsa
April 30th, 2011, 10:12
سلام
تاجایی که من اطلاعات پیدا کردم ، سیستم mysql مبنای جستجوی درختی هست
با توافقی که با دوستان دخیل در پروژه ، شد مبنای طراحی رو بر مبنای 1000 دیتابیس قرار دادیم البته با این کنترل که نزاریم تعداد لینک ها به دیتابیس ها از یک تعداد مشخص بیشتر بشه
انشاا.. به مشکلی بر نمی خوریم وگر نه میشیم درس عبرتی برای سایرین !!!