نمایش نسخه قابل چاپ
سلام به همه دوستان
با یه پروژه درگیرم که باید رکورد های زیادی دربر داشته باشه ! تقریبا 20 میلیون
و برای هر کاربر 5 جدول درست میشه
تعداد کاربران بیش از 1000 عدد خواهد بود
اما سوال : به نظر شما من از یک دیتا بیس بزرگ استفاده کنم و جدول ها رو برای هر کاربر کد گذاری کنم
ویا از تعداد زیادی دیتابیس اتفاده کنم.
لطفا در قالب مزایا و معایب و نتیجه گیری کلی ذکر کنید
با تشکر
مرتضی
این سئوال کردن داره ؟ 1000 تا کاربر هر کدوم 5 تا جدول میشه 5000 جدول ! اصولا هر کسی با تنظیمات mysql آشنا باشه میدونه که 5000 جدول تو یک دیتابیس یا حالا اصلا بگو 100 تا دیتابیس یه فاجعه برای سرور هست ....
شما باید طراحی دیتابیس بخونی یه کتاب بخر 3 - 4 هزارتومن یه نگاه بنداز بهش میفهمی چیجوری باید طراحی کنی ...
سنگین میشه عموجون.
تعریف جدول به ازای هر کاربر ؟!!نقل قول:
نوشته اصلی توسط morsa
این یک ضعف شدید در طراحی دیتابیس به حساب میاد.
بستگی داره ، اکر قرار باشه در هر لود شدن به دیتابیس های مختلفی ارتباط بر قرار بشه عملا با کاهش سرعت و کارایی روبرو میشید ولی در حالت های خاص ممکنه به نفع باشه.
شما بگید قصد دارید چجور دیتابیسی رو طراحی کنید تا یک ساختار پیشنهادی اولیه پیشنهاد کنیم.
ممنون از راهنمایی شما دوست عزیز !نقل قول:
نوشته اصلی توسط ali2k
گیر همون 3 - 4 هزار تومن هستم به جان تو !!
سیستم مای اس کیو ال اگر از نظر سخت افزاری تامین بشه تا 60و000 جدول و 60 میلیون رکورد رو بدون مشکل پشتیبانی می کنه !
سوال من این بود کدوم روش بهتره !
در حالت تک دیتابیس در هر جستجو اولیه باید جدول مورد نظر رو پیدا کنه ! 1/5000 زمان جستجو بعد ازاون تازه میرسه به عمل کئوری
از نظر امنیتی هم فقط نیاز به ست کردن یک پسورد می باشد
دستت درد نکنه !نقل قول:
نوشته اصلی توسط maroofi
ممنون ازپاسختوننقل قول:
نوشته اصلی توسط Rezash
سیستم طراحی و پیاده سازی اطلاعات یک سازمان بزرگ است که برای هر عضو 5 جدول باید ، سوابق ، پرداختی ها و ... که ممکن است برای هر جدول تا 50000 رکورد برای یک سال در نظر گرفته شود . تعداد اعضا هم بیش از 1000 نفر می باشد
سالانه اطلاعات بایگانی و از سیستم خارج می شوند !
امنیت این داده ها در درجه اول قرار دارد
به همین دلیل من سیستم رو بر مبنای 1000+1 دیتابیس طراحی کردم به شکلی که هر دیتابیس کاربر با یوزر پس مخصوص به خودش کانکت میشه !
و یک دیتابیس مادر که اطلاعات 1000 تای دیگه و یوزر ها رو ذخیره سازی میکنه !
البته این نکته رو باید اضافه کنم که هیچدیتاسنتری با این شرایط :"> به ما پا نداد و مجبور شدیم یه سرور راه اندازی کنیم !
حالا دوستان به جای نصیحت ، نقد کنند به صورت علمی ممنون میشم
یه نکته جالب ! جستجو درگوگل هر دقیقه 4 تن دی اکسید کربن وارد فضا می کند. این مواد از سیستم خنک کننده دیتاسنتر ها ناشی می شوند
حالا این دوستمون میگه 5000 جدول سنگینه !!
منتظر نظراتتون هستم
ممنون - مرتضی
اين قسمت براي من نا مفهوم هست.نقل قول:
برای هر عضو 5 جدول باید ، سوابق ، پرداختی ها و ...
به جاي اينكه هر يوزر 5 جدول داشته باشه كلا 5 جدول داشته باشيم + يك ستون اضافه كه اين ستون id شخص رو در بر ميگيره.
هنوز درس پایگاه داده رو پاس نکردم ولی از نظر سیستمی هر چقدر دیتابیس هاتون کمتر باشه بهتره. اینجوری فکر کنم سرعت دسترسی بالاتر از چندتا دیتابیس باشه. تو چندتا دیتابیس امنیت هم کمتره و به نحوی گسستگی اطلاعات هم صورت می گیره. بعضی مواقع مجبورید برای یه دیتابیس یه دیتاسنتر ایجاد کنید!
هنوز هم با اطمینان کامل میگم که 5000 جدول کاملا اشتباه هست ! ولی خب کلا باید سرتون به سنگ بخوره تا قبول کنید :)نقل قول:
یه نکته جالب ! جستجو درگوگل هر دقیقه 4 تن دی اکسید کربن وارد فضا می کند. این مواد از سیستم خنک کننده دیتاسنتر ها ناشی می شوند
حالا این دوستمون میگه 5000 جدول سنگینه !!
راه حل درست شما 5 تا جدول هست ، برای هر جدول یک ستون به عنوان id کاربر تعریف می کنید و تمام اطلاعات همه این 1000 کاربر داخل همین 5 جدول قرار می گیرد.
حالا با گفته خود شما اگر 50000 رکورد هم برای هر کاربر در سال وجود داشته باشد ضربدر 1000 کاربر نهایت میشود 50 میلیون رکورد.
برای 50 میلیون رکورد باید ابتدا نوع کوئری ها تعیین شود و ایندکس گذاری صحیح براساس کوئری ها انجام شود.
سپس باید جدول ها با توجه به نوع کوئری ها پارتیشن بندی شود.
کلا همین سروری که این دیتابیس را بخواد بالا بیاره باید کلی رم + هارد سرعت بالا + سی پی یو درست حسابی داشته باشه چیزی که همش هزینه هست ... 5 میلیون هزینه همین سرور هست.
حالا شما برو 5000 تا جدول بساز بعدا بیاد اینجا تاپیک بزن "تو بد مخمصه ای گیر افتادم چیکار کنم" :دی
سلامنقل قول:
نوشته اصلی توسط Rezash
درسته حق باشماست اما یک سری مسائل دیگه در این طراحی در نظر گرفته شده !
این 5 جدول یک رابطه خاصی با یکدیگر دارند . در بعضی از پردازش ها حتی 2 جدول به عنوان فهرست برای جدول بعدی در نظر گرفته شود !
الگریتم مورد نظر شما در ابتدا پیاده سازی شد اما حتی با حجم پایین اطلاعات زمان پردازش مناسبی نمی داد !
کاش می تونستم پروپوزال رو اینجا بزارم ولی ... !
نکته ای دیگه ! امنیت در این سیستم خیلی مهمه ! برای بکاپ گیری که توسط خود کاربران انجام میشه از اطلاعاتشون بکاپ گرفته میشه که در حالت جدا بودن این کار سریعتر و راحتره !
و بکاپ گیری توسط خود سرور توسط یک نرم افزار دست نویس انجام میشه که هر یک ساعت یه نسخه از اطلاعات بانک رو داخل یک هارد اکسترنال کپی میکنه !
کمک کنید ! تحلیل کنید ! ممنون
---------- Post added at 08:52 PM ---------- Previous post was at 08:45 PM ----------
چشم !نقل قول:
نوشته اصلی توسط ali2k
ببین دوست عزیز این که شما میگید کاملا منطقی هست ! تو پست قبلی به اقا رضا عرض کردم ! نمیشه جدول یک کاربر رو با جدول کاربر دیگه قاطی کرد !
به خاطر رابطه هایی که دارند .
درصورتی که به مشکل سنگین برخورد کنیم با شکستن دیتابیس ها با نرم افزار های دستی و تغییر شکل اونها میشه راحت مشکل رو حل کرد
شما اگر مزایا ومعایب هر کدوم رو بشمرید ممنون میشم
نقل قول:
این 5 جدول یک رابطه خاصی با یکدیگر دارند . در بعضی از پردازش ها حتی 2 جدول به عنوان فهرست برای جدول بعدی در نظر گرفته شود !
الگریتم مورد نظر شما در ابتدا پیاده سازی شد اما حتی با حجم پایین اطلاعات زمان پردازش مناسبی نمی داد !
پیشنهاد من هم اینه که جدول های جداگانه ایجاد نکنید.نقل قول:
نمیشه جدول یک کاربر رو با جدول کاربر دیگه قاطی کرد !
به خاطر رابطه هایی که دارند .
کوری ها رو بهینه کنید. امنیت هم ربطی به جدا بودن یا نبودن جداول نداره.
ضعف در در سخت افزار سرور رو نبايد عاملي براي ضعف در طراحي قرار بديد.
شديدا تاكيد ميكنم ايجاد 5 جدول براي هر كاربر يا يك ديتابيس براي هر كاربر يك ضعف شديد و در سطح بالا جبران نشدني براي پروژه شما به حساب مياد.
mysql در بزرگترين سايت هاي جهان با حجم وسيعي از اطلاعات داره كار ميكنه و مشكلي پيش نمياد.
اينكه شما سرعت مناسبي نگرفتيد رو بايد دنبال علتش باشيد و ضعفش رو پيدا كنيد نه اينكه با يك روش غير منطقي سعي در پوشوندش داشته باشيد.
در سطح بالا براي انتخاب و ساير دستورات بايد نهايت دقت رو به كار برد ، به عنوان مثال اگر در دو جدول با 5 ميليون ركورد اول join كنيم بعد شرط بذاريم (يا ...) و حالت برعكس ممكنه تفاوت مقايسه در حد ميليون ركورد باشه.
شما اطلاعاتي در مورد كارتون نداديد و مطمئن باشيد بيش از اين با اين اطلاعات نميشه راهنمايي كرد.
چه جور رابطه هايي داريم ؟ چرا ميگيد امنيت اين روش پايين تره ؟ اگر خود پروژه رو نمي تونيد توضيح بديد با يك مثال و شبيه سازي قضيه رو روشن كنيد.
سلام به همه دوستان
و ممنون از پیگیریتون و شرمنده از اینکه ناقص توضیح می دم
فرض کنید یه سازمان مثل استان قدس با طرف های مالی خودش که اشخاص حقیقی و حقوقی هستند در یک سیستم تبادل داده های مالی دارند
1 - هر شرکت و یا هر فرد به طور جداگانه دارای یک سیستم حسابداری کامل میباشد ( بدون در نظر گرفتن رابطه مالی با سازمان)
حالا کنار این شما فرض کنید از تعریف حسابهای داخلی ، حسابهای مشترک ، حسابهای شخصی و ... تا سیستم مکاتبات و پیگیری چک و ... ( این داستان ادامه دارد :-> )
ما یک گروه 5 نفره طراح هستیم که حدود 3 ماه داریم این سیستم رو پیاده سازی می کنیم
ولی حالا بعد از اتمام کار به سیستم دیتابیس مون شک کردیم به سفارش یکی از دوستان که مسئول راه اندازی سرور مونه که توی این فروم هم دست به کیبورد داره این مسئله رو اینجا مطرح کردم !
2 تا سرور راه انداری کردیم سرور اول سرور محاسبات و سایت و سرور دوم دیتاسنتر که فقط mysql نصبه !
و هردو از نظر سخت افزاری سنگین بسته شدن
این مسئله که تمام داده های این افراد داخل 5 جدول باشه بنا به الگریتم کاری و سفارشات بخش آی تی سازمان مردوده ! میمونه دوحالت یک دیتابیس با بیش از 5000 جدول و یا 1000 دیتابیس هر کدوم با 5 جدول
دوستان اگر مرجعی درباره هسته mysql و نحوه الگریتم کاری اون دارند بزارن میشه بررسی کرد
اگه سیستم کاری و موتور داخلی mysql به صورت شاخه ای باشه حالت 1000 دیتابیس بهتر به نظر میاد
یعنی اول دیتابیس پیداکنه ، بعد جدول رو بعد رکورد مورد نظر ! حالا به چه نوع پیمایشی جلو میره داخل هر کدوم مهم نیست
دوستان کمک کنند ممنون میشم !
ببينيد اگر واقعا فكر ميكنم mysql توان كشش حجم اطلاعاتي شما رو نداره در اين صورت ميتونيد دسته بندي كنيد.
دسته بندي نبايد به ازاي هر يوزر و يا چند يوزر باشه.يك رابطه ي منطقي ايجاد كنيد.
اگر به سبكي كه ميگيد در ابتدا بايد با يك ديتابيس ارتباط برقرار كنيم ، ببينيم اين يوزر در كدام db يا جدول هست ، اطلاعات اون db رو بگيريم ، متصل بشيم و ...
ولي شما ميتونيد ديتابيس ها رو بر اساس سال ورود،حروف نام خانوادگي ! شماره ملي يا ... و ... با يك نسبت بندي درست انتخاب كنيم.
به عنوان يك مثال خيلي ساده اگر اول حرف اسم شخص a بود به ديتابيس a_db سريعا مراجعه كنيد.
البته من هنوزم اين روش رو درست نميدونم ولي شما چون خودتون بيشتر در جريان پروژه هستيد شايد بهتر ميدونيد.
ولي در اصل طراحي بايد جداول منحصر به فرد باشند و رابطه ها رو با كليد اصلي و فرعي و ايندكس گذاري مناسب ايجاد كنيم و با اين تكنيك ها سرعت جستجو و عمليات رو افزايش بديم.
در مورد اصول طراحي db در دانشگاهها معمولا كتاب آقاي رانكوهي تدريس ميشه.
ممنوننقل قول:
نوشته اصلی توسط Rezash
اصرار شما بر اینه که تعداد دیتابیس ها کم بشه به هر شکلی که ممکنه
دسته بندی یوزر ها باساس اولویتها
دسته بندی گزینشی ( انتخاب دستی)
ولی چرا ! این برداشت من درسته :
هر چی تعداد دیتابیس بیشتر باشه سرعت کمتره !
چرا ؟؟
شاید کمی بی ممنطق به نظر برسد که اگر من با درخواست یا کوئری دستور جستجوی در دیتابیس m1258 رو بدم برای مثال با حجم 100000 رکورد
و mysql پارامترهای سایر دیتابیس ها مثل k546 , ... رو هم درنظر بگیره ( بازم برمیگرده به الگریتم داخلی)
البته امکان داره که با کش کردن یک بانک در یک جستجو ، زمانی که تعداد دیتابیس ها بیشتر باشه سیستم با افت سرعت مواجه بشه
اگر بشه جزئیات رو بدست اورد بهتر میشه تصمیم گرفت
سلام
تاجایی که من اطلاعات پیدا کردم ، سیستم mysql مبنای جستجوی درختی هست
با توافقی که با دوستان دخیل در پروژه ، شد مبنای طراحی رو بر مبنای 1000 دیتابیس قرار دادیم البته با این کنترل که نزاریم تعداد لینک ها به دیتابیس ها از یک تعداد مشخص بیشتر بشه
انشاا.. به مشکلی بر نمی خوریم وگر نه میشیم درس عبرتی برای سایرین !!!
باتشکر از همه دوستان