PDA

View Full Version : سوال: بهترین ساختار دیتابیس برای لایک و بازنشر پست ها چیه



theboy
پنج شنبه 17 مرداد 1392, 05:26 صبح
سلام.
می خواستم بدونم بهترین ساختار دیتابیس(mysql) برای لایک و بازنشر پست ها چیه؟

مثال:

شیرترانیکس این روش رو بکار گرفته:
کلا یه قسمت(من آخر این تیبل و... دیتابیس رو اسماشونو یاد نگرفتم!:لبخند:) ساخته به نام likes و در اون سه ستون هست با عناوین آیدی،آیدی پست،آیدی کاربر(شاید بیشتر باشه اونایی که لازمه رو گفتم) بعد میاد برای هر پست یه چک از این table میگیره و اون مواردی که آیدیه پستشون با آیدی پست یکیه رو دریافت می کنه. حالا دوباره از table کاربران اونایی رو که آیدیشون مساویه آیدی هایی که از table لایکس گرفته بود هستند رو دریافت و نمایش میشده!:افسرده:
عیب از نظر من: فرض کنید در هر صفحه 10 پست نمایش بدیم و هر پست بین 100 تا 2000 تا لایک داشته باشه و کلا سایت یک میلیون تا لایک و بیست هزار تا کاربر داشته باشه؛ سرور رسما به باد میره.


نظر من:
توی table پست ها یه ستون به نام likes بسازم و آیدی کسانی که پست رو پسندیدن بریزم توش و با , جداشون کنم. حالا با php اونها رو دریافت و آیدی تک تکشون رو بدست بیارم(به کمک توابع str و استفاده از , که قبلا گذاشتم) حالا این آیدی ها رو وقف بدم با کاربرا و کاربرا رو نمایش بدم.

مشکل راه حل من:
فرض کنید وضعیت پست ها و کاربران مثل مثال قبلیه حالا اینکه php برای هر پست ورداره یه عبارت با شاید بالای ده-بیست هزار کاراکتر رو با توجه به , جدا کنه! دو به شکم که فشار این بیشتر میشه یا mysql.

نظر شما خیلی برام مهمه. اگه خودتون راه حل دیگه ای دارید بگید.
ممنون.

maysam.m
پنج شنبه 17 مرداد 1392, 08:18 صبح
راه حل اول قطعا بهتره

هر کاری یه سری مزایا و معایب داره
توی راه حل اول شما بعدا میتونی به راحتی تعداد لایک ها رو بدست بیاری و آی پی و سایر اطلاعات رو به جدول اضافه کنی اما در حالت دوم نمیشه

safa55
پنج شنبه 17 مرداد 1392, 11:03 صبح
سلام
همون روش اول بهتره .
یه سوال ؟؟؟
وقتی مثلا 20000 تا like رو از یک رکورد دیتابیس خوندی حالا می خوای اون رو داخل چی بریزی تا از هم جداشون کنی!!!!! حتما توی یک متغیر (اون هم در رم هست).
به نظرت وقت گیر نیست!!!

theboy
پنج شنبه 17 مرداد 1392, 19:56 عصر
راست میگید تاحالا به این فکر نکرده بودم.
ولی روش اول آخه هم واسه لایک ها و هم واسه بازنشر ها اونم تو هر صفحه 10 بار تکرار بشه بعد بره کاربرا رو انتخاب کنه خیلی سنگین نمیشه؟

روش دیگه ای سراغ ندارید؟


کلا به نظرتون ظرفیت mysql چقدره و همچین کاری براش متوسط رو به سخته یا وحشتناکه:لبخند:

Veteran
پنج شنبه 17 مرداد 1392, 23:56 عصر
سلام
همون روش اول بهتره .
یه سوال ؟؟؟
وقتی مثلا 20000 تا like رو از یک رکورد دیتابیس خوندی حالا می خوای اون رو داخل چی بریزی تا از هم جداشون کنی!!!!! حتما توی یک متغیر (اون هم در رم هست).
به نظرت وقت گیر نیست!!!
هدف چیه که ما 20 هزار لایک رو بخوایم از دیتابیس بخونیم ؟!
میتونیم تعداد رو با تابع count به دست بیاریم بعد بگیم این پست رو 20 هزار نفر لایک کرده ! همین ! قرار نیست که ما بیایم 20 هزار تا کاربری رو که پست رو لایک کردن رو به نمایش در بیاریم ! لازم نیست اصلا !
حالا اگر هم بخوایم نشون بدیم 20 هزار تارو باهم نشون نمیدیم ! مثلا 10 تا نشون میدیم.اگر کاربر خواست بیشتر ببینه روی مثلا گزینه more کلیک میکنه و ی درخواست ایجکس ارسال میشه 10 تای بعدی رو میخونه میاره
پس دیگه ما 20 هزار تا لایک رو نمیخونیم 10 تا 10 میخونیم میاریم نمایش میدیم

theboy
جمعه 18 مرداد 1392, 00:06 صبح
هدف چیه که ما 20 هزار لایک رو بخوایم از دیتابیس بخونیم ؟!
میتونیم تعداد رو با تابع count به دست بیاریم بعد بگیم این پست رو 20 هزار نفر لایک کرده ! همین ! قرار نیست که ما بیایم 20 هزار تا کاربری رو که پست رو لایک کردن رو به نمایش در بیاریم ! لازم نیست اصلا !
حالا اگر هم بخوایم نشون بدیم 20 هزار تارو باهم نشون نمیدیم ! مثلا 10 تا نشون میدیم.اگر کاربر خواست بیشتر ببینه روی مثلا گزینه more کلیک میکنه و ی درخواست ایجکس ارسال میشه 10 تای بعدی رو میخونه میاره
پس دیگه ما 20 هزار تا لایک رو نمیخونیم 10 تا 10 میخونیم میاریم نمایش میدیم
دوست عزیز ایشون این مشکل رو راجب راه حل من(راه دوم) گفتند.
که مثلا از table پست ها قسمت لایک ها رو که گرفتیم(آیدی کاربرا ها که با , جدا شده) باید بریزیمشون تو یه متغییر تا با , جداشون کنیم.

shahriyar3
جمعه 18 مرداد 1392, 00:36 صبح
یه تیبل سوم هم میتونی داشته باشی و تعداد مجموع لایک ها و پست آیدی و یوزر آیدی رو توش داشته باشی .
مثلا یوزر #1 - پست شماره 10# - تعداد مجموع لایک ها #1120

وقتی سیستم شما بزرگ بشه بحثش یکم پیچیده تر میشه مثلا بعد از یه مدتی تعداد پست ها به بالای چند میلیون پست میرسه پس باید از فیلتر های جدید استفاده کنید

theboy
جمعه 18 مرداد 1392, 00:52 صبح
یه تیبل سوم هم میتونی داشته باشی و تعداد مجموع لایک ها و پست آیدی و یوزر آیدی رو توش داشته باشی .
مثلا یوزر #1 - پست شماره 10# - تعداد مجموع لایک ها #1120

وقتی سیستم شما بزرگ بشه بحثش یکم پیچیده تر میشه مثلا بعد از یه مدتی تعداد پست ها به بالای چند میلیون پست میرسه پس باید از فیلتر های جدید استفاده کنید
خیلی عالی بود! بازم اگه پیشنهادی هست بگید.
فقط الان یه مشکلی به ذهنم میرسه! اون موقع باید هر بار که پست لایک میخوره یک بارکل لایک های پست شمرده بشن +1 بشن و ریخته بشن در دیتابیس. موقع لایک خوردن شمرده شن بهتره یا موقع نمایش؟(به نظرم تعداد لایک پست مسلما از تعداد نمایشش کمتره ولی خوب موقع نمایش دادنش بازم باید یه کوئری استفاده کرد که از آخرین لایک ستون تعداد رو نمایش بده!)

javadt
جمعه 18 مرداد 1392, 01:00 صبح
به نظر بنده هم راه حل اول بهتر
در آینده اگر تعداد بالاتر رفت مدیریت داده ها براتون راحت تر هست
فقط باید به صورت صحیح اطلاعات رو از اون جدول بخونید و از توابع خود mysql هم استفاده کنید و برای نمایش مثلا لایک ها حتما صفحه بندی کنید
اینجوری هم آمار خوبی از اطلاعاتتون دارید و هم فشار کمتری روی سرور میاره

shahriyar3
جمعه 18 مرداد 1392, 01:07 صبح
خیلی عالی بود! بازم اگه پیشنهادی هست بگید.
فقط الان یه مشکلی به ذهنم میرسه! اون موقع باید هر بار که پست لایک میخوره یک بارکل لایک های پست شمرده بشن +1 بشن و ریخته بشن در دیتابیس. موقع لایک خوردن شمرده شن بهتره یا موقع نمایش؟(به نظرم تعداد لایک پست مسلما از تعداد نمایشش کمتره ولی خوب موقع نمایش دادنش بازم باید یه کوئری استفاده کرد که از آخرین لایک ستون تعداد رو نمایش بده!)
چرا شمرده بشن؟
منظور شما از شمرده بشن چیه؟!! احتیاجی به دوباره شمرده شدن نیست دیگه . تعداد کل لایک ها آپدیت میشه با +1

theboy
جمعه 18 مرداد 1392, 05:04 صبح
به نظر بنده هم راه حل اول بهتر
در آینده اگر تعداد بالاتر رفت مدیریت داده ها براتون راحت تر هست
فقط باید به صورت صحیح اطلاعات رو از اون جدول بخونید و از توابع خود mysql هم استفاده کنید و برای نمایش مثلا لایک ها حتما صفحه بندی کنید
اینجوری هم آمار خوبی از اطلاعاتتون دارید و هم فشار کمتری روی سرور میاره
میشه بیشتر توضیح بدی؟



چرا شمرده بشن؟
منظور شما از شمرده بشن چیه؟!! احتیاجی به دوباره شمرده شدن نیست دیگه . تعداد کل لایک ها آپدیت میشه با +1
یعنی شما راه حل دوم رو پیشنهاد میدید؟ بعد راهی هست که بدون اینکه کل رشته رو بگیریم و پنج تا شو با , جدا کنیم، پنج تا عدد اول که با , جدا شدن رو دربیاریم؟

navid3d_69
جمعه 18 مرداد 1392, 10:15 صبح
من راه اول رو پیشنهاد می کنم شما با کش می تونین خیلی از بار سرور کم کنید مثل فیس بوک برای راه دوم و خود , می تونین توی کوئری قرار بدین با دستور in در SQL بهترین راه این هست که شما از روش اول استفاده کنید با این روش می تونین مثلا اگر کسی بلاک شد لایک نکنه و ... و لی روش دوم خیر بعد شما حساب کنید اگر یک پسی 1 میلیون لایک داشت توی چه فیلدی می خواید این id هارو با , جدا کنید؟ مثلا یکی یک کاربر 1552316 باشه شما این موارد رو حساب کنید . برای نمایش شما قرار نیست 20000 تا کاربر رو یک دفعه بخونید اصلا اگر بخونید 20000 تا کاربر رو چجوری می خواین به کاربر نمایش بدنی ؟ مثلا 50 تا 50 تا نمایش بدین به راحتی فکر نمی کنم جامعه مجازی مثل کلوب با اون تعداد کاربر و حتی بیشتر با Mysql مشکلی داشته باشه چون تا چند سال پیش هم فیس بوک با Mysql بوده

shahriyar3
جمعه 18 مرداد 1392, 15:38 عصر
یعنی شما راه حل دوم رو پیشنهاد میدید؟ بعد راهی هست که بدون اینکه کل رشته رو بگیریم و پنج تا شو با , جدا کنیم، پنج تا عدد اول که با , جدا شدن رو دربیاریم؟
نه دیگه خیلی واضح توضیح دادم که!! راه حل اول خیلی بهتره ولی من یکم سعی کردم کامل ترش کنم یعنی یک تیبل به چیزی که شما گفتین اضافه کردم که خوندن اطلاعات راحت تر بشه

plague
جمعه 18 مرداد 1392, 21:41 عصر
چندوقت پیش یه شبکه اجتماعی ساختم

سخت ترین قسمتش همین اشتراک گزاری بودکه 3-4 بار از اول نوشتمش

برای لایک حتما دیتبایس جدا باشه اصلا فکر زخیره کردن در خوده دیتابیس پست ها رو هم نکن که اشتباهه

ولی در خوده تیبل پست ها یه فیلد شمارنده بزار مثلا likes
بعد با هر لایک یدونه بهش اضافه کن و هر دیسلایک یدونه کم کن از مقدارش

اینجوری دیگه لازم نیست که بری تیبل لایک ها رو بشماری برای هر پست
برای اون شمارنده من از تریگر استفاده کردم که کاملا بهینه باشه و نیاز به کانکشن و کد نویسی اضافه نباشه به اضای هر لایک

theboy
شنبه 19 مرداد 1392, 02:59 صبح
دوستان یه سوال:
الان مثلا فیسبوک نزدیک یک میلیارد کاربر داره که مسلما تعداد لایکها روزانه از این عدد بیشتر نباشه کمترم نیست!
حالا چطوره که میاد برای هر پست آیدی کل کاربرای لایک کرده رو می گرده و با اونی که آیدیش بین دوستان شخص هست رو پیدا می کنه و نمایش میده!!
اون از mysql استفاده نمی کنه؟ از چی استفاده می کنه؟ زبونش که php هست.

یه سوال دیگه:
واسه سیستم دوستی، عضویت در گروه و... هم باید از همین روش استفاده کنم :| یعنی یه تیبل جدا برای آیدی گروه و آیدی شخص عضو شده! خیلی خیلی فشار زیاد میشه ها!



ولی در خوده تیبل پست ها یه فیلد شمارنده بزار مثلا likes

خوب اون موقع برای هر لایک باید دو تا query بفرستم که بدتر میشه! یعنی اول خود لایک رو ثبت کنم بعد برم تیبل پست ها و likes رو بروز کنم!



راستی میشه الان با mysql ساخت و اگه فشاری هم آورد تحمل کرد بعدا که سایت بزرگتر شد رفت رو oracle؟ کلا تبدیل یه سیستم کامل از mysql به oracle شدنیه؟ شما اینکار رو پیشنهاد میدید؟
(چون شنیدم oracle مناسب سایت های وحشتناک سنگینه و خیلی خوبه، منم خیلی دوست دارم موقع برنامه نویسی دستم باز باشه و نگران فشار سرور نباشم :گریه:)

navid3d_69
شنبه 19 مرداد 1392, 14:17 عصر
فیس بوک تا 2008 می دونم از mysql استفاده می کردن بعدش رو نمی دونم ببنید شما اگر سایتون به اون تعداد برسه باید سرور رو قوی کنید شما می تونید اول به همین روش سیستم رو بنویسید اگر بازدید زیاد بود کم کم با تخصص بیشتر برید سمت بهتر کردنش سایت شما روزه اول که 100000 تا لاک نمی خوره که مشکل داشته باشه

plague
شنبه 19 مرداد 1392, 15:32 عصر
خوب اون موقع برای هر لایک باید دو تا query بفرستم که بدتر میشه! یعنی اول خود لایک رو ثبت کنم بعد برم تیبل پست ها و likes رو بروز کنم!




اگه با دقت میخوندی راه حل برای این گفته بودم من :

برای اون شمارنده من از تریگر استفاده کردم که کاملا بهینه باشه و نیاز به کانکشن و کد نویسی اضافه نباشه به اضای هر لایک

theboy
شنبه 19 مرداد 1392, 16:32 عصر
اگه با دقت میخوندی راه حل برای این گفته بودم من :

برای اون شمارنده من از تریگر استفاده کردم که کاملا بهینه باشه و نیاز به کانکشن و کد نویسی اضافه نباشه به اضای هر لایک
ممنون.
ولی میشه بیشتر توضیح بدی؟ یا اگه میشه یه مثال ساده بزنی؟ تاحالا به گوشم نخورده...

plague
شنبه 19 مرداد 1392, 21:15 عصر
تریگر مکانیزمیه که میتونه کاری کنه تا در هنگام تغییر در یک تیبل به تناسب اون تغییر یا تغییراتی در تیبل های دیگه هم اتفاق بیفته
مثلا هر رکوردی که در تیبل کامنت ها اضافه شد
بره در تیبل پست ها
پست مربوط به اون کامنت رو پیدا کنه
و کانتر کامنتش رو یدونه افزایش بده (شبیه به این لایک )

ترگیر رو در سمت دیتبایس (مثلا در محیط phpmyadmin ) میشه ایجاد کرد ... فکر میکنم phpmyadmin یه سری دکمه و ویزارد داشته باشه براش من امتحان نکردم و همیشه با کد نوشتم
سینتکسش هم تقریبا شبیه sql هست

http://net.tutsplus.com/tutorials/databases/introduction-to-mysql-triggers/

theboy
شنبه 19 مرداد 1392, 23:47 عصر
بازم سر در نیاوردم ولی ممنون روش خوبی بود بیشتر مطالعه می کنم راجبش ;)

theboy
یک شنبه 20 مرداد 1392, 01:09 صبح
راستی دوستان به نظرتون بهترین انجین واسه شبکه اجتماعی چیه؟ innodb یا myisam ؟

navid3d_69
یک شنبه 20 مرداد 1392, 12:13 عصر
تریگر از نظر performance فکر نکنم که فرقی با دستور عادی کنه ولی این روش کوئری اضافه تر داره چون هم باید مثلا لایک رو اضافه کنید و هم بایدیک آپدیت برای شمارش توی خود جدول لایک بزارین

safa55
یک شنبه 20 مرداد 1392, 12:40 عصر
هدف چیه که ما 20 هزار لایک رو بخوایم از دیتابیس بخونیم ؟!
میتونیم تعداد رو با تابع count به دست بیاریم بعد بگیم این پست رو 20 هزار نفر لایک کرده ! همین ! قرار نیست که ما بیایم 20 هزار تا کاربری رو که پست رو لایک کردن رو به نمایش در بیاریم ! لازم نیست اصلا !
حالا اگر هم بخوایم نشون بدیم 20 هزار تارو باهم نشون نمیدیم ! مثلا 10 تا نشون میدیم.اگر کاربر خواست بیشتر ببینه روی مثلا گزینه more کلیک میکنه و ی درخواست ایجکس ارسال میشه 10 تای بعدی رو میخونه میاره
پس دیگه ما 20 هزار تا لایک رو نمیخونیم 10 تا 10 میخونیم میاریم نمایش میدیم
سلام دوست عزیز
شما راست می گید.
ولی من یک سوال دارم مگه می شه مقداری از فیلد که اطلاعاتی رو داره از دیتابیس خوند.اگه اره می شه یک مثال بزنید؟
مرسی ، شاید در جاهای دیگر هم بدرد بخوره

omidabedi
یک شنبه 20 مرداد 1392, 12:42 عصر
دوستان یه سوال:
الان مثلا فیسبوک نزدیک یک میلیارد کاربر داره که مسلما تعداد لایکها روزانه از این عدد بیشتر نباشه کمترم نیست!
حالا چطوره که میاد برای هر پست آیدی کل کاربرای لایک کرده رو می گرده و با اونی که آیدیش بین دوستان شخص هست رو پیدا می کنه و نمایش میده!!
اون از mysql استفاده نمی کنه؟ از چی استفاده می کنه؟ زبونش که php هست.

فیس بوک از noSQL استفاده میکنه :)
اون جریانش جداست


یه سوال دیگه:
واسه سیستم دوستی، عضویت در گروه و... هم باید از همین روش استفاده کنم :| یعنی یه تیبل جدا برای آیدی گروه و آیدی شخص عضو شده! خیلی خیلی فشار زیاد میشه ها!


خوب اون موقع برای هر لایک باید دو تا query بفرستم که بدتر میشه! یعنی اول خود لایک رو ثبت کنم بعد برم تیبل پست ها و likes رو بروز کنم!



راستی میشه الان با mysql ساخت و اگه فشاری هم آورد تحمل کرد بعدا که سایت بزرگتر شد رفت رو oracle؟ کلا تبدیل یه سیستم کامل از mysql به oracle شدنیه؟ شما اینکار رو پیشنهاد میدید؟
(چون شنیدم oracle مناسب سایت های وحشتناک سنگینه و خیلی خوبه، منم خیلی دوست دارم موقع برنامه نویسی دستم باز باشه و نگران فشار سرور نباشم :گریه:)

بهتر از پایه از PDO استفاده کنی که راحتتر بتونی از دیتابیس های مختلف استفاده کنی
پ.ن:به صورت کلی گفتم اما اطلاعی ندارم که PDO از oracle پشتیبانی میکنه یا نه.


بنظر من طراحی دیتابیس های بزرگ کاره هرکسی نیست
و کلا یه شاخه ی جداست برای مهندسی پایگاه داده

اما خب روش اول بهتره
چرا که مدیریت اماری اسان و کارامد روی اطلاعات داری

abolfazl-z
یک شنبه 20 مرداد 1392, 12:50 عصر
http://d2o0t5hpnwv4c1.cloudfront.net/2013_phpvsmysqli/tutorial_3.png

theboy
یک شنبه 20 مرداد 1392, 13:12 عصر
راستی چرا راه دور میریم!
کسی خبر داره همین vb که الان برنامه نویس داره ازش استفاده می کنه، سیستم تشکر رو چطوری پیداه کرده؟(اونم مثل روش اوله؟)

ویرایش:
از pdo خیلی خوشم اومد!
همین ویژگیش که با تغییر یه خط میشه دیتابیس رو تغییر داد برام عالیه!
فقط یه سری سوال pdo باعث افزایش سرعت و کاهش فشار هم میشه؟ بقیه دوستان استفاده ازش رو توصیه می کنند؟ روی هر هاستی pdo پیدا میشه یا باید کلی با مدیر هاست یا سرور سروکله بزنم؟

راستی به نظرتون اوراکل چقدر کار رو راحت تر می کنه(فشار رو کم می کنه؟)، مثلا به نظرتون اگه الان سایتی مثل کلوب بره رو اوراکل فشارش نصف میشه؟

navid3d_69
یک شنبه 20 مرداد 1392, 13:44 عصر
PDO رو که کم کم باید کار کنید چون دستور های Mysql داره توی ورژن های جدید حذف میشن بنظر من برای حل این که کدوم راه حل بهتر و بهنیه تر هست این بهتر هست که شما سایت رو اجرا کنید بعد که تعداد کاربران حدود 2000 تا شد الگوریتم های لایک رو تست کنید کدوم فشاره کمی میاره

نمی دونم orcale فشاری کمتری میاره یا نه ولی فکر کنم برای اجرا مقدار رم بیشتری می خواد

theboy
یک شنبه 20 مرداد 1392, 13:48 عصر
PDO رو که کم کم باید کار کنید چون دستور های Mysql داره توی ورژن های جدید حذف میشن بنظر من برای حل این که کدوم راه حل بهتر و بهنیه تر هست این بهتر هست که شما سایت رو اجرا کنید بعد که تعداد کاربران حدود 2000 تا شد الگوریتم های لایک رو تست کنید کدوم فشاره کمی میاره

نمی دونم orcale فشاری کمتری میاره یا نه ولی فکر کنم برای اجرا مقدار رم بیشتری می خواد
ای بابا:(
پس اون موقع یا باید pdo رو بی خیال شم یا کلا با oracle شروع کنم!

آقا یه سوال دیگه نهایت فشار mysql چقدر میشه؟ الان مثلا کلوب یا فیس نما ماهی چقدر پول سرور می دن؟ یا مشخصات سرورشون(رم و سی پی یو) چقدره؟

navid3d_69
یک شنبه 20 مرداد 1392, 13:54 عصر
ببنید بجز رم و سی پی یو سرعت هارد هم مهم هست من برای سایت هایی که خودم برای مشتری ها طراحی می کنم معمولا خودم هاست می دم مشکلی که با فشار داشتم وقتی تعداد مشتری ها زیاد شد خود datacenter به من پیشنهاد داد که سرور Webserver و database server رو جدا کنم و از وقتی جدا کردم 2 تا سرور کم قدرت تر هست ولی با مشتری های بیشتر حدود 50 % بار از کل سرور کم شده فکر کنم اگر شما هم جدا باشه بهتر باشه این مشاوره هم یکی از هاستینگ های معروف USA داد بهم

omidabedi
یک شنبه 20 مرداد 1392, 14:56 عصر
راستی چرا راه دور میریم!
کسی خبر داره همین vb که الان برنامه نویس داره ازش استفاده می کنه، سیستم تشکر رو چطوری پیداه کرده؟(اونم مثل روش اوله؟)

ویرایش:
از pdo خیلی خوشم اومد!
همین ویژگیش که با تغییر یه خط میشه دیتابیس رو تغییر داد برام عالیه!
فقط یه سری سوال pdo باعث افزایش سرعت و کاهش فشار هم میشه؟ بقیه دوستان استفاده ازش رو توصیه می کنند؟ روی هر هاستی pdo پیدا میشه یا باید کلی با مدیر هاست یا سرور سروکله بزنم؟

راستی به نظرتون اوراکل چقدر کار رو راحت تر می کنه(فشار رو کم می کنه؟)، مثلا به نظرتون اگه الان سایتی مثل کلوب بره رو اوراکل فشارش نصف میشه؟


PDO یک افزونه برای php هست که اکثر هاستینگ ها دارن
من از میهن وب هاست استفاده میکنم که داره!!!

safa55
یک شنبه 20 مرداد 1392, 19:07 عصر
از سوال اصلی زیاد فاصله نگرفتید!!!!
من چند روز پیش در این مورد چند جائی قیمت پرسیدم قیمت بالا بود.
اگه بخواهید یک سرور اختصاصی داشته باشید خودشم داخل ایران ، ناقابل باید 1.5 تومن ماهانه بپردازید.
یک سوال: یکی از دوستان در چند پست بالا نوشتن که می شه قسمتی از فیلد رو از دیتابیس خروجی گرفت .
کسی می دونه چه طوری؟(به پست من جواب دادن)

theboy
یک شنبه 20 مرداد 1392, 20:37 عصر
سوال من ساختار درست بود برای کاهش فشار که هرچقدرم بحث دور بشه رو کاهش فشار می چرخه :d
تا 2 میلیون باشه خوبه، مشکل اینجاست که میگن همین الان یه سایت جامعه مجازی که رتبش 4000در جهان هست و با شیرترانیکسه(که از همین روش استفاده میکنه) ماهیانه 4میلیون پول سرورشه! شما فرض کن اگه سایتش بیاد زیر هزار دیگه باید بیشتر از نصف در آمدش رو بده به سرور!
اگه مشکل شیرترانیکس از چیزای دیگه باشه و من با این روش بتونم با رتبه ی زیر هزار ایران 2 میلیون پول سرور بدم عالیه.

navid3d_69
یک شنبه 20 مرداد 1392, 22:25 عصر
عزیز خب بستگی به درآمد زایی که داره یکی ممکن هست سایتش روزی 1 میلیون بازدید داره ولی ماهی 1 میلیون در میاره
شما با 500$ ماهیانه می تونین یک سرور خیلی خب با هارد SSD بگیرید

AbiriAmir
یک شنبه 20 مرداد 1392, 22:48 عصر
دوست عزیز هر سیستمی 1 جور طراحی شده
دیتابیس های Relational ساختارشون اینطوره یعنی شما ناچارید از روش اول استفاده کنید (بسیار اصولی تر هست)
اما خوب معایبی هم داره از جمله همون موردی که خودتون گفتید که اون بر میگرده به کلا دیتابیس های relational
پس با انتقال از MySQL به اوراکل هم شاید سرعت شما بهتر بشه اما با توجه به این که Oracle هم یک دیتابیس Relational هست از لحاظ اردر (Order) بهبودی توی کار شما ایجاد نمیشه.
خوب چاره چیه؟
شما 1 محاسبه کن تا 1 حدودی MySQL رو میشه بهینه کرد و سرور ها رو Cluster کرد و ... (که با احتمال خیلی بالایی تا همین حدش جواب کار شما رو میده) اما اگر حس میکنید دیتابیستون از این حد هم بزرگتر هست باید روی دیتابیس های غیر رابطه ای مطالعه کنید...
موفق باشید

theboy
یک شنبه 20 مرداد 1392, 23:21 عصر
دوست عزیز هر سیستمی 1 جور طراحی شده
دیتابیس های Relational ساختارشون اینطوره یعنی شما ناچارید از روش اول استفاده کنید (بسیار اصولی تر هست)
اما خوب معایبی هم داره از جمله همون موردی که خودتون گفتید که اون بر میگرده به کلا دیتابیس های relational
پس با انتقال از MySQL به اوراکل هم شاید سرعت شما بهتر بشه اما با توجه به این که Oracle هم یک دیتابیس Relational هست از لحاظ اردر (Order) بهبودی توی کار شما ایجاد نمیشه.
خوب چاره چیه؟
شما 1 محاسبه کن تا 1 حدودی MySQL رو میشه بهینه کرد و سرور ها رو Cluster کرد و ... (که با احتمال خیلی بالایی تا همین حدش جواب کار شما رو میده) اما اگر حس میکنید دیتابیستون از این حد هم بزرگتر هست باید روی دیتابیس های غیر رابطه ای مطالعه کنید...
موفق باشید

من مطمئنم که mysql جواب کار منو میده، چون خوده فیسبوک تا 2007 که مسلما بالای 500 میلیون کاربر داشته رو mysql بوده! حالا سایت من تو ایران، فوق فوقش قراره 76 میلیون کاربر داشته باشه(تازه اگه فکر کنیم از نوزاد تا پیر همه اینترنت دارن و میان تو سایت عضو میشن!)
مسئله ای که مطرحه فشاریه که به سرور میاره! مثلا با یه سیستم ممکنه 100 تا کاربر همزمان آنلاین داشته باشیم رو یه هاست خوب، رو یه سیستم ممکنه 100 تا کاربر همزمان دهن یه سرور قوی رو مسواک کنند:لبخند:

میخوام هزینه سرورش به کمترین و به صرفه ترین صورت باشه. به طوری که اگه در آمد سایت میلیونی شد و به اوج اوجش رسید فوق فوقش 2 میلیون پول سرورش بشه.

AbiriAmir
دوشنبه 21 مرداد 1392, 17:55 عصر
خوب عرض کردم که
شما اگر میخواین از لحاظ Order سیستم شما پیشرفت کنه و بهینه بشه باید روی دیتابیس های NoSQL مطالعه کنید...

shahriyar3
دوشنبه 21 مرداد 1392, 20:44 عصر
من مطمئنم که mysql جواب کار منو میده، چون خوده فیسبوک تا 2007 که مسلما بالای 500 میلیون کاربر داشته رو mysql بوده! حالا سایت من تو ایران، فوق فوقش قراره 76 میلیون کاربر داشته باشه(تازه اگه فکر کنیم از نوزاد تا پیر همه اینترنت دارن و میان تو سایت عضو میشن!)
مسئله ای که مطرحه فشاریه که به سرور میاره! مثلا با یه سیستم ممکنه 100 تا کاربر همزمان آنلاین داشته باشیم رو یه هاست خوب، رو یه سیستم ممکنه 100 تا کاربر همزمان دهن یه سرور قوی رو مسواک کنند:لبخند:

میخوام هزینه سرورش به کمترین و به صرفه ترین صورت باشه. به طوری که اگه در آمد سایت میلیونی شد و به اوج اوجش رسید فوق فوقش 2 میلیون پول سرورش بشه.
چه اعتماد به نفسی داری ماشالا
طراحی دیتابیس تو همچین سیستم هائی 20-30 درصد کل ماجرا هست . دیتابیس بعد از طراحی تازه نیاز به نرمال سازی داره . نرمال سازی تو چند سطح انجام میشه . باید کد های سمت سرور شما performance عالی داشته باشه و گرنه روی عملکرد دیتابیس شما تاثیر میزاره جدا از اون کد های سمت سرور هم باید بهینه باشه تا فشار به سرور نیاره بعد از اینا کد های سمت کلاینت هم خیلی مهمه تو زمان لود
ببین مثلا شاید یک راه حل این باشه که از الگوریتم های lazy loading استفاده کنی تا بتونی جلوی اجرا شدن کد های اضافی رو بگیری
خیلی راه داری تا بخوای یک performance عالی داشته باشی با 75 میلیون عضو
عجله نکن پله پله برو جلو 10 تا پله رو نمیتونی با هم بری!!
فیس بوک و من یه جا خوندم هر صفحش یه project مجزا هست برای خودش و یک تیم داره که اختصاصی روی اون صفحه فقط کار میکنند و اینکه اون تیم مدیر پروژه دارن که تمرکزش روی همون بخش هست
فیس نما هم همینططور بود. اون موقع که تازه داشت تموم میشد یادمه سرمایه گذار داشت و برای خودش تیم جمع کرده بود براش کار میکردن
حالا شما همه اینها رو میخوای 1 تنه انجام بدی

theboy
دوشنبه 21 مرداد 1392, 23:50 عصر
چه اعتماد به نفسی داری ماشالا
طراحی دیتابیس تو همچین سیستم هائی 20-30 درصد کل ماجرا هست . دیتابیس بعد از طراحی تازه نیاز به نرمال سازی داره . نرمال سازی تو چند سطح انجام میشه . باید کد های سمت سرور شما performance عالی داشته باشه و گرنه روی عملکرد دیتابیس شما تاثیر میزاره جدا از اون کد های سمت سرور هم باید بهینه باشه تا فشار به سرور نیاره بعد از اینا کد های سمت کلاینت هم خیلی مهمه تو زمان لود
ببین مثلا شاید یک راه حل این باشه که از الگوریتم های lazy loading استفاده کنی تا بتونی جلوی اجرا شدن کد های اضافی رو بگیری
خیلی راه داری تا بخوای یک performance عالی داشته باشی با 75 میلیون عضو
عجله نکن پله پله برو جلو 10 تا پله رو نمیتونی با هم بری!!
فیس بوک و من یه جا خوندم هر صفحش یه project مجزا هست برای خودش و یک تیم داره که اختصاصی روی اون صفحه فقط کار میکنند و اینکه اون تیم مدیر پروژه دارن که تمرکزش روی همون بخش هست
فیس نما هم همینططور بود. اون موقع که تازه داشت تموم میشد یادمه سرمایه گذار داشت و برای خودش تیم جمع کرده بود براش کار میکردن
حالا شما همه اینها رو میخوای 1 تنه انجام بدی

بحث اعتماد به نفس نیست :لبخند:
بحث اینه که من باید یه همچین حالتی رو در نظر بگیرم چون وظیفه ی برنامه نویس ساخت اسکریپت به بهترین صورته برای ایده عال ترین شرایط(از نظر من) از طرفی باید هدف رو اون بگیرم که اگه سایت به رتبه 20هزار جهان رسید سرور نترکه:چشمک: