توجه ! این یک نسخه آرشیو شده میباشد و در این حالت شما عکسی را مشاهده نمیکنید برای مشاهده کامل متن و عکسها بر روی لینک مقابل کلیک کنید : mysql واسه وبلاگدهی مناسب هست؟
iroo
April 13th, 2017, 18:49
سلام و خسته نباشید
یک سرویس وبلاگدهی داریم که 600 تا وبلاگ داره با 370.000 تا پست
حجم دیتابیس کم مونده بشه 1 گیگ
برای این حجم دیتابیس هاست خیلی قوی تهیه کرده بودم که باز هاستینگ می گفت 4 هسته CPU رو مصرف میکنه و بیشترش هم مربوط به دیتابیس هست!!!!
حالا سرویس هایی مثل رز بلاگ این همه اطلاعات رو توی mysql ذخیره می کنند؟ مثلا الان میتونه حجم دیتابیس رز بلاگ 50 گیگ باشه؟
اگه بخوام مثلا یه سرویس وبلاگ دهی بنویسم در حد رز بلاگ استفاده از mysql خوب هست یا بد؟
این همه پست و...
ممنون میشم راهنمائیم کنید
Azade.Kaveh
April 13th, 2017, 19:45
بله کاملا مناسب هست mysql به شزطی که به اندازه مصرف ( حجم یا بازدید ها ) منابع در اختیارش قرار بدین !
+ باید واسه هر وبلاگ یک table جدا ساخت ! مثل سیستم اشتراکی وردپرس ( وبلاگ دهی وردپرس ) ( + در my.cnf ست کنید که هر table در یک فایل جداگانه باشه ) اینطوری فشار خاصی نمیاد .
موفق باشید .
rezaonline.net
April 14th, 2017, 17:48
یک سرویس وبلاگدهی داریم که 600 تا وبلاگ داره با 370.000 تا پست
حجم دیتابیس کم مونده بشه 1 گیگ
این حجم اصلا زیاد نیست .
در اصل خود طراحی دیتابیس یک تخصص هست و باید حسابی روش کار بشه .
توی حیطه کاری شما مباحثی مثل ایندکس گذاری صحیح ، دیتاتایپ صحیح ، پارتیشن بندی صحیح حتی کلاسترینگ هم شاید لازم باشه .
برای این حجم دیتابیس هاست خیلی قوی تهیه کرده بودم که باز هاستینگ می گفت 4 هسته CPU رو مصرف میکنه و بیشترش هم مربوط به دیتابیس هست!!!!
به هاستینگتون بگید لاگ ها رو ارائه بدن
slow query ها رو ارائه بدن .
اسکریپتتون هم باید بررسی بشه ، باید درست و صحیح از کش در لایه اسکریپت استفاده بشه .
کانفیگ mysql هم خودش خیلی مهمه .
اگه بخوام مثلا یه سرویس وبلاگ دهی بنویسم در حد رز بلاگ استفاده از mysql خوب هست یا بد؟
mysql جوابگوی نیاز شما هست اما اگر تخصصی تر میتونید کار کنید دیتابیس های بهتری هستن که در حجم رکورد بالاتر بهتر جواب میدهند و کارایی بهتری دارند مثل postgresql
AhrimanSefid
April 14th, 2017, 19:38
سلام
800 هزار وبلاگ داریم با حداقل هر وبلاگ 10 پست.
با یک کانفیگ درست mysql و سخت افزار راحت جواب می ده.
30gig فقط دیتابیس ما.
35752
bluehost
April 14th, 2017, 20:39
سلام
باید mysql رو بهینه سازی کنید تا مشکلی نداشته باشید از این بابت و حجمی که فرمودید اونقدر هم زیاد نیست
موفق باشید
Hasanmilani
April 16th, 2017, 09:48
سلام ممنون از مطلب مفیدتون
moslem95
April 16th, 2017, 10:05
با سلام
حجم دیتابیستون زیاد نیست روی اسکریپت و بهینه سازی mysql باید کار کنید.از مدیر سرور بخواید که لاگ query ها رو بهتون بدن تا بتونید مشکل رو حل کنید.
موفق باشید.
firebox
April 16th, 2017, 10:47
از دیتابس های NoSQL استفاده کنید، تو حجم کاری بالا ، دیتابس های RDBMS از نظر کارایی نسبت به NoSQL حتی نزدیک هم نیستن .
این رو هم بگم ، تو چند سال اخیر دیتابس های NoSQL به طور کامل تکامل یافتن و میشه ازشون برای هر پروژه ای استفاده کرد.
TakCloud
April 16th, 2017, 11:07
سلام و خسته نباشید
یک سرویس وبلاگدهی داریم که 600 تا وبلاگ داره با 370.000 تا پست
حجم دیتابیس کم مونده بشه 1 گیگ
برای این حجم دیتابیس هاست خیلی قوی تهیه کرده بودم که باز هاستینگ می گفت 4 هسته CPU رو مصرف میکنه و بیشترش هم مربوط به دیتابیس هست!!!!
حالا سرویس هایی مثل رز بلاگ این همه اطلاعات رو توی mysql ذخیره می کنند؟ مثلا الان میتونه حجم دیتابیس رز بلاگ 50 گیگ باشه؟
اگه بخوام مثلا یه سرویس وبلاگ دهی بنویسم در حد رز بلاگ استفاده از mysql خوب هست یا بد؟
این همه پست و...
ممنون میشم راهنمائیم کنید
باسلام
۱ گیگ حجم بسیار بالایی برای دیتابیس نیست دوست عزیز که شما از الان استرس دارید
اگر به درستی کانفیگ شود هیچ مشکلی نخواهید داشت
M.Abooali
April 16th, 2017, 13:21
بنده دیتابیس هایی نزدیک 1 ترابایت رو هم با mysql مدیریت کردم.
در خصوص دیتابیس دقت کنید حجم دیتابیس در اصل ملاک نیست. چند نکته در سط بالا اهمیت بالا دارند:
1. تعداد کانکشن های همزمان به دیتابیس.
وابستگی مستقیم دارد با تعداد سشیون ها (بازدید های) فعال شماست.
2. تعداد متوسط کوئری ها از هر تیبل به نسبت تعداد سطر های تیبل.
این فاکتور نشات گرفته از مدل ارتباطی اسکریپت شما با دیتابیس است.
3. کامند های SQL متوسط به هر تیبل به نسبت ستون های آن تیبل.
و همینطور تخصصی که بریم جلو فاکتورها جزئیی تر هم خواهد شد تا اونجا که دوستان به مواردی مثل ایندکس ها و ... اشاره کردند. داشتن یک اسکریپت حرفه ای و قدرتمند بار کمتری روی دیتابیس شما ایجاد میکند با وجود ذخیره کل اطلاعات مورد نیاز در دیتابیس.
مشکل عمده این است که طراحی دیتابیس و ساختار اون کاملا امری تخصصی هست که متاسفانه به شکل غیر علمی عمدتاً انجامش می دهند. اتفاقا همین جا بدنیست اشاره کنم وردپرس اصلا مثال خوبی نبود وردپرس خودش یکی از بزرگترین نقاط ضعفش استراکپر دیتابیسش هست. دقیقا به همین دلیل هم هست که به ندرت سایت های پر بازدید وردپرسی باقی بمانند. چون مصرف منابع سر به فلک خواهد کشید. جوملا هنوز از وردپرس در این زمینه بهتر است اما قابل قبول نیست باز.
از cms های معروف شاید بهترین ساختار دیتابیس را دروپال و اپن کارت (فروشگاه ساز) داشته باشند. اگر به ساختار اونها تخصصی نگاه کنید متوجه می شوید چه الگوهای متفاوتی به نسبت دیگر اسکریپت ها لحاظ شده است در مقابل با میلیون ها بازدید کننده شما به منابع زیادی احتیاج نخواهید داشت. هر چند این اسکریت ها در ابعاد دیگر حسابی از وردپرس یا جوملا و رقبای خودشان عقب هستند.
در خصوص سیستم شما اگر صرفا بخواهید کمتر از 10% بهینه سازی کنید ممکن است با اقداماتی مثل اصلاح برخی تنظیمات mysql و دیتابیس به این مقدار دست پیدا کنید. اما اگر دنبال آن هستید که بیش از 10% بهینه سازی را تجربه کنید قطعا ناچار هستید در کدهای خود و ساختار دیتابس (تیبل ها و ستون ها) دستکاری جدی داشته باشید به نوعی بازنویسی کدهاتون منظور هست.
---- در خصوص NoSQL
در مورد شما پیشنهادش نمی کنم. استفاده از این متد ذخیره سازی زمانی که ما یک استراکچر روشن و ثابت داریم بی معنی هست. بحث تخصصیش خارج از حوصله این تاپیک هست.
firebox
April 16th, 2017, 14:27
---- در خصوص NoSQL
در مورد شما پیشنهادش نمی کنم. استفاده از این متد ذخیره سازی زمانی که ما یک استراکچر روشن و ثابت داریم بی معنی هست. بحث تخصصیش خارج از حوصله این تاپیک هست.
منظورتون از استراکچر ثابت چیه ؟ چرا استفادش تو دیتابس NoSQL بی معنی هست ؟
M.Abooali
April 16th, 2017, 23:34
منظورتون از استراکچر ثابت چیه ؟ چرا استفادش تو دیتابس NoSQL بی معنی هست ؟
این سوال شما خودش یک بحث مفصل هست. معمولا افراد تا قبل از آشنایی با nosql تصور می کنند بهتر از RDBMS وجود ندارد که اشتباه است و بعد از آشنایی با nosql نیز تا یک مدت فکر می کنند بهترین انتخاب است خصوصا با خودنمایی مانگو.
اما بعد از یک مدت تجربه و کار این سوال برای هر کسی پیش خواهد آمد حالا که هم RDBMS پایه ها و هم nosql پایه ها را بلد هستم برای پروژه جدید کدام رو استفاده کنم؟ پس از تحقیق نتیجه خواهید گرفت که این امر وابسته است و مطلق نیست. شرح ابعاد گوناگونش اینجا دشوار و خارج از حوصله است. شاید باید در خصوصش یک کتاب نوشت. بنده فقط در خصوص هر کیس کاری میتونم نظر بدم که کدوم گزینه مناسب تر است. چون قصد برگزاری کلاس آموزشی رو ندارم. یک تصویر بسیار مفید که راهنمای خوبی است در این زمینه:
در مورد یک سیستم وبلاگ دهی از نظر شخص بنده RDBMS انتخاب درست تری می باشد. اما چرا nosql مناسب نیست؟
از اون جهت که شما ناچار هستید به ذخیره چندباره (یا نوبتی) اطلاعات و بازخوانی چندباره اون،(دقیقا به دلیل فقدان A در تصویر فوق) یا به زبان خودمانیش چون در حالت nosql از جیزی با مفهوم join (در sql) خبری نیست.
به این ترتیب پهنه دیتابیس شما خیلی وسیع تر از حالت RDBMS خواهد شد. حجم کدهای شما نیز طبیعتا بیشتر خواهد شد. در خصوص پرفرمنس هم چندان نباید خوش بین باشید چون با این وضعیت در صورت بالا بردن اون ریسک از دست رفتن دیتا در nosql نیز بالاتر خواهد رفت (اگر دلیلش را نمی دانید در خصوصش قبل از سوال در اینجا سرچ کنید).
لازم به اشاره است که سیستم وبلاگ دهی شامل فضاهای نسبتا جدای اطلاعاتی است (شبیه انجمن یک سامانه مشترک نیست). مقصود من پست ها، کامنت ها و این موارد برای هر وبلاگ است. حتی شما میتونید هر وبلاگ را تبدیل به یک دیتابیس جدا کنید و به لطف RDBMS کوئری هایی فرا دیتابیسی داشته باشید !
به طور مثال شما قطعا برای دانستن آمار کل تعداد پست ها قرار نیست برید تک تک تیبل های وبلاگها رو آنالیز کنید و جمع بزنید بیاید بخونید.و این اطلاعات رو دارید از تیبل آمار کلی سایت بلاگ دهی می خونید. تا اینجا مشکل نیست. همین کیس را در nosql تصور کنید و بخواهید این آمار در وبلاگ ها نمایش داده شود.
به زبان دیگر،زمانی که شما صدها بار ناچارید چندین فایل را باز کنید برای خواندن یک اطلاعات بهتر نیست این اطلاعات در یک محل باشند یا حداقل به هم ریلیت باشند با قابلیت جوین ؟ قطعا پاسخ شما مثبت است و اینجاست که بنده RDBMS را به nosql در این پروژه ترجیح می دهم. چه از نظر کدنویسی چه پرفرمنس نتیجه مطلوب تری دارد.
firebox
April 24th, 2017, 00:08
منظورتون از استراکچر ثابت چیه ؟ چرا استفادش تو دیتابس NoSQL بی معنی هست ؟
این سوال شما خودش یک بحث مفصل هست. معمولا افراد تا قبل از آشنایی با nosql تصور می کنند بهتر از RDBMS وجود ندارد که اشتباه است و بعد از آشنایی با nosql نیز تا یک مدت فکر می کنند بهترین انتخاب است خصوصا با خودنمایی مانگو.
اما بعد از یک مدت تجربه و کار این سوال برای هر کسی پیش خواهد آمد حالا که هم RDBMS پایه ها و هم nosql پایه ها را بلد هستم برای پروژه جدید کدام رو استفاده کنم؟ پس از تحقیق نتیجه خواهید گرفت که این امر وابسته است و مطلق نیست. شرح ابعاد گوناگونش اینجا دشوار و خارج از حوصله است. شاید باید در خصوصش یک کتاب نوشت. بنده فقط در خصوص هر کیس کاری میتونم نظر بدم که کدوم گزینه مناسب تر است. چون قصد برگزاری کلاس آموزشی رو ندارم. یک تصویر بسیار مفید که راهنمای خوبی است در این زمینه:
در مورد یک سیستم وبلاگ دهی از نظر شخص بنده RDBMS انتخاب درست تری می باشد. اما چرا nosql مناسب نیست؟
از اون جهت که شما ناچار هستید به ذخیره چندباره (یا نوبتی) اطلاعات و بازخوانی چندباره اون،(دقیقا به دلیل فقدان A در تصویر فوق) یا به زبان خودمانیش چون در حالت nosql از جیزی با مفهوم join (در sql) خبری نیست.
به این ترتیب پهنه دیتابیس شما خیلی وسیع تر از حالت RDBMS خواهد شد. حجم کدهای شما نیز طبیعتا بیشتر خواهد شد. در خصوص پرفرمنس هم چندان نباید خوش بین باشید چون با این وضعیت در صورت بالا بردن اون ریسک از دست رفتن دیتا در nosql نیز بالاتر خواهد رفت (اگر دلیلش را نمی دانید در خصوصش قبل از سوال در اینجا سرچ کنید).
لازم به اشاره است که سیستم وبلاگ دهی شامل فضاهای نسبتا جدای اطلاعاتی است (شبیه انجمن یک سامانه مشترک نیست). مقصود من پست ها، کامنت ها و این موارد برای هر وبلاگ است. حتی شما میتونید هر وبلاگ را تبدیل به یک دیتابیس جدا کنید و به لطف RDBMS کوئری هایی فرا دیتابیسی داشته باشید !
به طور مثال شما قطعا برای دانستن آمار کل تعداد پست ها قرار نیست برید تک تک تیبل های وبلاگها رو آنالیز کنید و جمع بزنید بیاید بخونید.و این اطلاعات رو دارید از تیبل آمار کلی سایت بلاگ دهی می خونید. تا اینجا مشکل نیست. همین کیس را در nosql تصور کنید و بخواهید این آمار در وبلاگ ها نمایش داده شود.
به زبان دیگر،زمانی که شما صدها بار ناچارید چندین فایل را باز کنید برای خواندن یک اطلاعات بهتر نیست این اطلاعات در یک محل باشند یا حداقل به هم ریلیت باشند با قابلیت جوین ؟ قطعا پاسخ شما مثبت است و اینجاست که بنده RDBMS را به nosql در این پروژه ترجیح می دهم. چه از نظر کدنویسی چه پرفرمنس نتیجه مطلوب تری دارد.
درسته از هر دیتابس باید به جای خودش استفاده کرد ، اما این لزوما به این معنی نیست که هر کدوم فقط برای یک موارد خاص استفاده کنیم ، برای مثال از دیتابس های NoSQL هم میشه برای مدل های رابطه ای استفاده کرد (به خصوص دیتابس MongoDB)
من برنامه نویسی رو با php و Mysql شروع کردم ، حدود ۳ سال پیش بود که از php مهاجرت کردم ، بعد از اون هم با دیتابس های NoSQL شروع به کار کردم ( MongoDB و Cassandra) و البته هنوز هم از MySQL استفاده میکنم.
یک باور غلطی که در مورد دیتابس های NoSQL وجود داره این هست که دیتابس NoSQL به هیچ وجه به درد مدل رابطه ای نمی خورن ، در صورتی که با دیتابس های NoSQL به راحتی میتونی مدل رابطه ای One to One و One to Many و حتی Many to Many رو انجام بدید ، بدون اینکه بخواهید صرفا denormalization رو انجام بدید و پراکنده گی داده ها رو افزایش بدید.
به نظر من ، تعریف ساختار های رابطه ای پیچیده ساختاریافته رو خیلی راحت تر میشه تو JSON objects انجام داد ، برای مثال همین گرفتن بازدید هر پست و بازدید کل یک بلاگ که خودتون بهش اشاره کردید ، برای این کار میتونی آمار بازدید هر پست رو به صورت Embedded تو خود همون پست ذخیره کنید و برای بازدید کل با یک aggregate کوئری ساده جمع بازدید های کل پست ها رو دریافت کنید.
در ضمن MongoDB از نسخه ۲.۳ به بعد قابلیت lookup رو به aggregate pipline اضافه کرده که این امکان رو بهتون میده دادهای ۲ تا کالکشن رو به هم مرتبط کنید. (همون کار Join در Mysql).
M.Abooali
April 24th, 2017, 05:58
این که ما میتونیم تو کار خودمان دیتا رو پیوست کنیم خاص NoSQL نیست. حتی جدا از json ما با هر الگوی دلخواهی می تونیم این کار رو بکنیم همانطور که مثلا در اپن کارت یا برخی فروشگاه سازهای عجیب و غریب شاهدش هستیم با یک سری الگو ها (و گاه همین json) سعی شده در ستون سطر گاه تیبل های دیتابیس صرفه جویی شود.
مثلا هر پلاگین، تنظیماتش و مسائل مربوط بهش در یک سلول به صورت جیسان ذخیره می شوند اینطور لازم نیست هر پلاگین تیبل خودش را داشته باشد یا ...
اما هدف را گم نکنیم. این که آیا چیزی امکان پذیر است یا خیر، یک بحث است. این که آیا میتوان php را روی ویندوز ران کرد یا مثلا asp را روی لینوکس... یک بحث است ...
اما این که کدام بهینه تر و ما را به شکل درست تری به مقصود میرساند یک بحث.
بنده تجربیات محدودی در زمینه NoSQL دارم. اما تجربه مواردی رو داشتم که کاملا احساس کردم این مورد باید حتما با NoSQL کار شود. منظورم این هست اونقدرها برام گنگ نیست که کجا کدوم گزینه برتر است. البته این مطلق نیست ممکنه با کسب تجربه بیشتر نظرات من تغییر کند.
نظری که اینجا دادم با توجه به دانش و تجربیات فعلیم هست.
firebox
April 24th, 2017, 15:11
این که ما میتونیم تو کار خودمان دیتا رو پیوست کنیم خاص NoSQL نیست. حتی جدا از json ما با هر الگوی دلخواهی می تونیم این کار رو بکنیم همانطور که مثلا در اپن کارت یا برخی فروشگاه سازهای عجیب و غریب شاهدش هستیم با یک سری الگو ها (و گاه همین json) سعی شده در ستون سطر گاه تیبل های دیتابیس صرفه جویی شود.
مثلا هر پلاگین، تنظیماتش و مسائل مربوط بهش در یک سلول به صورت جیسان ذخیره می شوند اینطور لازم نیست هر پلاگین تیبل خودش را داشته باشد یا ...
اما هدف را گم نکنیم. این که آیا چیزی امکان پذیر است یا خیر، یک بحث است. این که آیا میتوان php را روی ویندوز ران کرد یا مثلا asp را روی لینوکس... یک بحث است ...
اما این که کدام بهینه تر و ما را به شکل درست تری به مقصود میرساند یک بحث.
بنده تجربیات محدودی در زمینه NoSQL دارم. اما تجربه مواردی رو داشتم که کاملا احساس کردم این مورد باید حتما با NoSQL کار شود. منظورم این هست اونقدرها برام گنگ نیست که کجا کدوم گزینه برتر است. البته این مطلق نیست ممکنه با کسب تجربه بیشتر نظرات من تغییر کند.
نظری که اینجا دادم با توجه به دانش و تجربیات فعلیم هست.
میدونم تو MySQL هم میشه از JSON استفاده کرد ، اما تو دیتابس مثل MongoDB هر داکیومنت به صورت JSON ذخیره میشه ، این انعطاف پذیری بالایی در اختیارمون قرار میده ، شما هر زمان بخواهید میتونید ساختار داده ها رو تغییر بدید ، یا حتی یک ساختار ثابت تعریف کنید (Mongodb ولیدیتور های داخلی داره ، که میشه باهاش نوع داده ها رو چک کنید)
در مورد مثال تون در مورد php روی ویندوز یا asp رو لینوکس و نسبت دادنش به NoSQL ، این مقایسه بیشتر شبیه این هست ، مثل برنامه نویسی توی زبان C و زبان Python ، تو زبان C نسبت به Python برنامه نوشتن برنامه با سرعت کمتری انجام میشه و نسبتا سخت تره (البته این در مورد همه افراد صدق نمیکنه ، اما به طور کلی به همین صورت هست) ، اما در عوض سرعت و کارایی برنامه نهایی اون سخت ها رو جبران میکنه.
در مورد دیتابس های NoSQL هم همینطوره ، ممکنه کارهایی که با دیتابس های SQL به راحتی انجام بدید ، توی NoSQL نیاز به کوئری پیچیده تری داشته باشید ، اما در پایان اون افزایش کارایی که اپلیکیشن تون به دست میاره ، ارزش اش رو داره.
planday
April 26th, 2017, 18:24
من به یگ مساله معتقدم هرکسی صلاح کار خودش رو بهتر از دیگران میدونه... اگر برنامه ای که نوشتید و بانک اطلاعاتی شما اختصاصی و طبق استاندارد نوشته شده چرا که نه خیلی هم خوبه ولی اگر هرکسی از راه رسیده یک برنامه نوشته و ... خب بهترین هم ممکنه جوابگو نباشه