دیتابیس بهینه

[under22]

سلام دوستان
من قرار پایگاه داده ایی طراحی کنم که حداقل 5 میلیون رکورد داره و بعدا هم بیشتر میشه شاید 7 میلیارد خلاصه قرار خیلی سنگین بشه . راه کار های زیادی هم پیدا کردم گفتم باهاتو به اشتراک بزارم
از دوستان حرفه ایی میخام که کمکم کنن و نکاتی بگن که تو بهینه طراحی کردن کمکم کنه و مرجعی بشه برای بهینه سازی .
در ادامه راهکار ها رو میزارم برای تبادل سطح علمی خودم و دوستان .
چند مورد شنیدم که Index گذاری کن فیلد هایی که جستجو زیاد میشه و index multi هم استفاده کن که من index multi رو بلد نیستم راهنماییم کنید؟؟
فیلد هایی که قرار جستجو به صورت like انجام بدی انجام نده و از full text استفاده کن که اگه میشه بهم یاد بدید بلد نیستم !!

[سعید صابری]

اگه میلیاردی هست برو سراغ Nosql

[under22]

من شنیدم برای کار با php بهترین پایگاه داده mysql هست ولی mongodb هم هست که عالیه حتی facebook هم از اون استفاده میکنه ولی متاسفانه افراد کمی هستن که بتونن ازش استفاده کنن منجمله من !

[سعید صابری]

فکر کنم facebook از mysql و nosql استفاده می کنه.البته هر کی یه چیزی میگه.
بهترین گزینه برای php، mysql است. ولی برای دیتابیس های حجیم به این بزرگی جواب نمیده.

[us1234]

از نظر insert هر تعداد رکورد را میشه در mysql ثبت کرد ولی همه دردسر ها سر سرچ ها و Select ها پیش میاد شما باید اول شرح بدید این رکورد ها قراره چه استفاده ای ازش بشه ؟

[under22]

حجم دیتابیس که خیلی زیاده . اما از نظر جستجو و ارتباطات باید بگم که جستجو دونش زیاد میشه هم ترکیبی هم تک فیلدی مثل یه فروشگاه آنلاین مثل دیجی کلا.
join های زیادی هم قرار زده بشه .
الآن من نمیدونم دیتابیس رو چطوری بسازم که بهینه ترین حالت رو داشته باشه

[us1234]

مشابه سوال شما اینجا مطرح شده :
http://serverfault.com/questions/168...s-192-trillion
http://www.sitepoint.com/forums/show...urn-of-results

اطلاعات فنی مثل نوع تیبل ( MyISAM و InnoDB و... ) داده شده است و همچنین نوع ایندکس گذاری .
ولی یک راه کار مناسب برای تیبل ها که تعداد رکورد ها واقعا بالایی دارند ( چند میلیارد به بالا ) این است که اطلاعاتی که خواستگاه زیادی دارد و ممکن از در روز 2 یا 3 بار بیشتر سرچ شوند در یک تیبل دیگه نگهداری شود ممکن از در نگاه اول این کار باعث شود که اطلاعات یکپارچگی خود را از دست بده ولی در سرچ های اول فشاری که به سرور میاره را خیلی کم میکنه اگر کد در تیبل کوچک نتیجه را پیدا نکرد شروع به سرچ در جدول بزرگ تر میکنه . ( مشابه اش را عمدتا دیدید در سایتهایی که قسمت آرشیو دارند یا سرچ پیشرفته هست )

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

[i-php-i]

منم برای طراحی سایتی با تعداد رکورد بالا نیاز به راهنمایی و بدست آوردن اطلاعات بیشتر دارم، احتمالا حداکثر 25 میلیون رکورد توی دیتابیس ذخیره بشه. اگر به نتیجه رسیدید لطفا توی این تاپیک عنوان کنید. ممنون

[under22]

من مقداری تحقیق کردم فقط به چند تا نتجیه رسیدم یکی ایندکس گذاری تک فیلدی با ایندکس گذاری ترکیبی .
نوشتن دستورات بهینه sql . برای مثال از عملگر between و like حدال امکان استفاده نشه یا معادلش به صورت بهینه نوشته بشه .
کش کردن دیتا بیس (اگه از فریمورک php استفاده می کنید خیلی سادس)
تعریف بهینه فیلد ها . برای مثال اگه میخواهید 0 یا 1 رو ذخیره کنید از نوع tinyint که فقط اندازه یک بیت از استفاده بشه .
اگه دوستان راحل دیگه دارن پیشنهاد کنن

[i-php-i]

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

[under22]

من هنوز دیتابیس رو طراحی نکردم ولی کلا اگه این نکته هایی که میگم رعایت mysql تا میلیارد رکورد هیچ مشکلی نداره .
استفاده از stored procedure (وقتی از این استفاده می کنید برای دفعه اول کوئری رو کش میکنه و سرعت رو تا 45% بیشتر میکنه)
یکی ایندکس گذاری تک فیلدی با ایندکس گذاری ترکیبی .
نوشتن دستورات بهینه sql . برای مثال از عملگر between و like حدال امکان استفاده نشه یا معادلش به صورت بهینه نوشته بشه .
کش کردن دیتا بیس (اگه از فریمورک php استفاده می کنید خیلی سادس)
تعریف بهینه فیلد ها . برای مثال اگه میخواهید 0 یا 1 رو ذخیره کنید از نوع tinyint که فقط اندازه یک بیت از استفاده بشه .

[i-php-i]

من هنوز دیتابیس رو طراحی نکردم ولی کلا اگه این نکته هایی که میگم رعایت mysql تا میلیارد رکورد هیچ مشکلی نداره .

اگر نسخه رایگان و عمومی mysql بتونه این کار رو انجام بده که عالیه، منبع معتبری برای این مطلب سراغ ندارید؟

[under22]

منابع این مطالب تو خود سایت Mysql هست . خیالتون راحت اگه اون موارد بالا رو رعایت کنید اصلا چند میلیاردم داده داشته باشید هیچ مشکلی پیش نمیاد .
فقط تو مواردی می تونیم بگیم که باز هم موارد بال رو انجام بدیم مشکل داریم که هم داده ها خیلی خیلی زیاد باشن (برای مثال از 10 میلیاردم بیشتر باشن) هم اینکه داده ها حجیم باشن که اون موقع باید برای دیتابیس یه سرور جدا تهیه کرد .
تازه اگه شما از stored procedure استفاده کنید غیر از این که وقتی کوئری رو دفعه دوم درخواست کنید 45% سریعتره که اینکار حمله sql injection رو صفر میکنه . (منبعش تو سایت Mysql) دو تا مزیت عمده داره

[سعید صابری]

در حالت عادی با این حجم mysql جوابگو نخواهد بود.امتحان این موضوع خیلی سخت نخواهد بود.50-60 میلیون رکورد اینسرت کنید و بعدش انتخاب و....
ببینید جواب میده یا خیر.

در حالت غیر معمول که سراغ بحث های دیگه باید بریم که فکر کنم هزینه بر خواهد بود.وقتی یک دیتابیس رایگان عملکرد بهتری در این زمینه داره چرا از ابتدا درست انتخاب نکنید؟

nosql واقعا ساخته شده برای دیتابیس های بزرگ.زمان بازدهی اصلا قابل مقایسه با بیشتر دیتابیس ها نیست.

[under22]

شما اشتباه می کنید . چند میلیون رکورد اصلا چیزی واسه mysql نیست تو میلیارد رکوردم اگه بهینه طراحی کرده باشید بازم جوابگو هست .
اگه داده هاتوت دیگه از خیلی زیاد باشه مثلا بیشتر از میلیارد باید مثله فیسبوک و کلوپ اون رو رو سرور های جدا اجرا کنید تا بتواند از همه سیستم ایتفاده کنه و جوابگو باشه .
فیسوک و کلوپ از Mysql استفاده می کنند البته فیسبوک بخشیش از Mysql هست (بیشترش با mysql هست)
من با فردی صحبت کردم که تجربه ذخیره میلیون تو Mysql رو داشته و هیچ مشکلی نداشته
چرا mysql رو اینقدر ضعیف جلوه می دید
nosql برای مواقعی خوبه که طول داده ما خیلی متغییر باشه برای مثال معلوم نیست داده ما 10 میشه ی 10 مگابایت و داده های ما خیلی سنگیه البته این سنگنی از لحاظ کلی نه از لحاظ فیلدی مقادیر ما خیلی زیاد باشه

[سعید صابری]

من با فردی صحبت کردم که تجربه ذخیره میلیون تو Mysql رو داشته و هیچ مشکلی نداشته

یکی دیگه از کسایی در حال حاضر داره از mysql (در شبکه خارج از نت) ذخیره میلیونی رکورد داره خود منم!فکر کنم دیتابیس عمرش به 9-10 سالی میرسه تقریبا ازش راضیم.فکر کنم تعداد رکورد به 30 به بالا که رسید برای جستجوی ساده تا چندها دقیقه زمان میبرد مجبور شدم از هزار راه برای سبک کردن بار دیتابیس استفاده کنم و هر روز که بار دیتابیس سنگین تر میشه روز از نو روزی از نو....

به نظر من برای به نتیجه رسیدن بحث یکی از دوستان یک جدول تک فیلدی در mysql و nosql ایجاد کنم.مقدار زیادی رکورد اینسرت کنه بعد زمان ها بزاره.

[nazanin_asadi_1]

منم مشکلم همینه حجم زیاد رکوردها هستش


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


این کوئری رو یک بار اجرا کنید :

CREATE TABLE `table1` (

  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

  PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_persian_ci;



INSERT INTO table1(id)VALUES(""),(""),(""),(""),(""),(""),("")  ,(""),(""),(""),(""),(""),(""),(""),(""),(""),("")  ,(""),(""),("");;

حالا این کوئری رو 17 بار اجرا کنید تا تعداد رکوردها به 2.5 میلیون برسه

INSERT INTO table1(id)(

SELECT "" from table1

)

الان که تست میکنم روی لوکال با 2.6 میلیون رکورد برای رسیدن به آخرین رکورد زمان زیر رو دارم

Showing rows 2621430 - 2621439  ( 2,621,440 total, Query took 1.5437 sec)

اینم روی هاست اشتراکی تست گرفتم

Showing rows 2621425 - 2621439 (2621440 total, Query took 1.8466 sec)

درباره دیتابیس nosql هم اطلاعاتی ندارم

[under22]

شما اگه موارد بالا رو رعایت کنید این زمان خیلی کم میشه .
مشا تایپیک های بالا رو بخونید .
برای مثال شما تو ساخت جدولتون اصلا index تعریف نکردید .
وقتی ایندکس تعریف می کنید فایل ها اون فیلد به صورت شاخص گذاری ذخیره میشه که این کمک میکنه برای مثال تو 70 میلیون با 6 یا 7 مقایسه رکود مورد نظر شما رو پیدا میکنه .
حالا غیر از ایندکس بقیه موارد رو هم رعایت کنید عالی میشه اصلا 2 یا 10 میلیون رکورد برای mysql هیچی نیست اگه بهینه طراحی کنید

[nazanin_asadi_1]

شما اگه موارد بالا رو رعایت کنید این زمان خیلی کم میشه .
مشا تایپیک های بالا رو بخونید .
برای مثال شما تو ساخت جدولتون اصلا index تعریف نکردید .
وقتی ایندکس تعریف می کنید فایل ها اون فیلد به صورت شاخص گذاری ذخیره میشه که این کمک میکنه برای مثال تو 70 میلیون با 6 یا 7 مقایسه رکود مورد نظر شما رو پیدا میکنه .
حالا غیر از ایندکس بقیه موارد رو هم رعایت کنید عالی میشه اصلا 2 یا 10 میلیون رکورد برای mysql هیچی نیست اگه بهینه طراحی کنید

دوست عزیز تا اونجا که من میدونم برای فیلدی که خودش کلید هستش نیازی به ایندکس گذاری نداره (چون خودش ایندکس هست )
موارد بالا رو هم که هی میگی اگه نگاه کنی می بینی که فقط یک فیلد هستش فقط یک فیلد که اونم اتونامبر هستش و کلید هم هستش و نوع موتور هم InnoDB هستش

[under22]

دوست عزیز تا اونجا که من میدونم برای فیلدی که خودش کلید هستش نیازی به ایندکس گذاری نداره (چون خودش ایندکس هست )
موارد بالا رو هم که هی میگی اگه نگاه کنی می بینی که فقط یک فیلد هستش فقط یک فیلد که اونم اتونامبر هستش و کلید هم هستش و نوع موتور هم InnoDB هستش

شما راست می گی من حواسم نبود .
خب فکر کنم این نزدیک به 2 ثانیه یا 1.8 ثانیه زمان خوبی باشه به خصوص که وقتی این رو کش کنید دفعه دوم زیر نیم ثانیه بهش دسترسی پیدا می کنید و اگه این رو با stored procedure استفاده کنید بهترم میشه و یک دفعه هم تو خود Mysql کش میکنه اینطوری دو دفعه کش صورت میگیره .
تو تالار PHP آقا رضا که سایت های بزرگی رو با بازدید بالا زدن با Mysql زدن من هم باهاشون حرف زدم میگفت تا 5 میلیون رکورد داشته دیتابیسش ولی با رعایت اصول که گفتم و یک سرور خوب با کانفیگ mysql خوب تا میلیارد رو جواب میشه داد مثل این سایت که آقار رضا زده و 5 میلیون رکورد داره . http://jahanpay.com/

[nazanin_asadi_1]

شما راست می گی من حواسم نبود .
خب فکر کنم این نزدیک به 2 ثانیه یا 1.8 ثانیه زمان خوبی باشه به خصوص که وقتی این رو کش کنید دفعه دوم زیر نیم ثانیه بهش دسترسی پیدا می کنید و اگه این رو با stored procedure استفاده کنید بهترم میشه و یک دفعه هم تو خود Mysql کش میکنه اینطوری دو دفعه کش صورت میگیره .
تو تالار PHP آقا رضا که سایت های بزرگی رو با بازدید بالا زدن با Mysql زدن من هم باهاشون حرف زدم میگفت تا 5 میلیون رکورد داشته دیتابیسش ولی با رعایت اصول که گفتم و یک سرور خوب با کانفیگ mysql خوب تا میلیارد رو جواب میشه داد مثل این سایت که آقار رضا زده و 5 میلیون رکورد داره . http://jahanpay.com/

این شد یه چیزی سعی کن تا متن رو نخوندی جواب ندی تا اینجوری سوتفاهم پیش نیاد

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

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

الان همین یک جدول رو با همون یک فیلد رو بهینش کن نتیجش رو ببینیم حالا فقط صفحه بندیش هست جستجوش و JOIN شدنش با جدولهای دیگه که بماند

[under22]

این شد یه چیزی سعی کن تا متن رو نخوندی جواب ندی تا اینجوری سوتفاهم پیش نیاد

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

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

الان همین یک جدول رو با همون یک فیلد رو بهینش کن نتیجش رو ببینیم حالا فقط صفحه بندیش هست جستجوش و JOIN شدنش با جدولهای دیگه که بماند

ببنید کش تو PHP میاد دفعه اول کل کوئری رو کش میکنه بعد ما یک کوئری خیلی سبکتر از کوئری اول بهش میدیم و دفعه بعد میاد اون کوری سبکه رو اجرا میکنه اگه تغییری داده نشده باشه میاد از کش میخونه اگه تغییری داده شده باشه کش رو پاک میکنه و کوئری بزرگه رو اجرا میکنه و دوباره کشش میکنه . برای مثال ما یک کوئری سنگین داری که یک join هم داره ما این رو کش میکنیم و کوئری کوچیک رو اینطوری می نویسیم

SELECT MAX(update_time) from tb_product

خب معلومه این کوئری خیلی خیلی سبکتره از کوئری اصلیه هست و هر دفعه این کوئری اجرا میشه تا اینکه بیاد بزرگه رو اجرا کنه اگه تغییری ایجاد نشده باشه .
من اگه بخام این کوئری شما رو بهینه کنم اول میاد این کوئری رو تو Mysql به صورت stored procedure می نویسم و تو برنامه PHP هم میاد صداش می کنم و کشش می کنم و شرط کش هم اینگونه می نویسم . اینطوری دو دفعه کش میشه

SELECT MAX(id) from tb_product

به نظره بنده این میتونه بهینه باشه و تا 1 میلیاردو جوابگو هست اگه هم بیشتر شد باید خود کوئری بهینه بشه که باید با یک فرد خبره مشورت بشه

[under22]

برای مثال این کوئری نثبت به کوئر پایین خیلی بهینه تره و خودش رو تو حجم های بالا نشون میده

SELECT id,name from tb_product

این کوئری سریعتر از کوئری پایینی است .

SELECT * from tb_product

این یه مثال ساده بود

[nazanin_asadi_1]

برای مثال این کوئری نثبت به کوئر پایین خیلی بهینه تره و خودش رو تو حجم های بالا نشون میده

SELECT id,name from tb_product

این کوئری سریعتر از کوئری پایینی است .

SELECT * from tb_product

این یه مثال ساده بود

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


الان من 5242880 رکورد دارم که توی همون جدولی هستش که ساختارش رو توی پست 17 گذاشتم و فقط یک فیلد داره با نام ID که هم کلیده هم ایندکس هم اتونامبره

الان وقتی میخوام به آخرین رکورد هاش با phpmyadmin برم 5 ثانیه زمان میبره حالا اگه اینو بخوام JOIN کنم با جدول های دیگه و سطرهای دیگه هم بهش اضافه بشه دیگه باید به فکر یه سرور (یا چند سرور ) باشیم ساختار پیچیده ای نیست

[under22]

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

[us1234]

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

ولی برای افت سرعت باید راهکار پیدا کنیم .
بهترین راه :
کش کردن .
کش کردن چندین نوع دارد .یک نوع ساده که اکثرا استفاده می کنند یک خروجی از دیتابیس را روی هارد نگه داری میکنند در این نوع کشها چون عملیات پردازشی mysql و تعداد کانکشن ها به دیتابیس کم شده و عملیات خواندن از فایل انجام میشود به مراتب سرعت اجرا می تواند بالا رود ( در هاستینگ های معتبر سرور mysql از سرور هاست جداست در این گونه موارد سروری که برای mysql در نظر گرفته اند از هارد های ssd استفاده می کند پس ممکن است کش کردن سرعت را کمتر نیز کند !!) .
نوع بعدی کش ها : کش در رم RAM نمونه بارز Memcached . این گونه کش ها که نسبتا زمان کمتر از نوع اول ، کوئری را ذخیره می کنند ( زمان دست برنامه نویس است ولی عمدتا 1 دقیقا تا 1 ساعت در نظر گرفته میشود به دلایل خاص که اگر نیاز بود توضیح داده میشود ) ساختار این کش به دلیل استفاده از جدول هش و ذخیره در رم سرور سرعت را به مراتب خیلی خیلی بالا تر می برد .

کتابخانه های وجود دارند که به accelerators معروف هستند . کاربرد اینگونه شتاب دهنده ها پیچیده است و بهترین بازدهی را از سرور دارند . یک بخش مهم در یک accelerator کش است که استفاده از آن خیلی بهینه تر از کش ها دیگر است . بخصوص http://eaccelerator.net/

بعد از این توضیحات در خصوص سوال نحوه بهینه کردن تیبل بعد از join باید بگم که شما نتیجه پردازش شده ( یعنی عملیات تاریخ یا هر کار دیگه ای که قرار است با نتایج کوئری مذکور انجام شود ) را به صورت کش نگهداری کنید .

در کل تا معماری کد ها و سیستم شما مشخص نشود نمیشود راهکاری مناسبی پیشنهاد داد .

[nazanin_asadi_1]

من الان همین جدولی که در پست 17 گفتم رو روی سرور هم ایجاد کردم و الان تعداد رکوردهاش رو با اجرای اون کوئری به 5 میلیون رسوندم الان بازه زمانیش برای رسیدن به آخرین صفحه از رکوردها (از داخل phpmyadmin) ما بین 3 تا 4 ثانیه هستش

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

هر چند باید این نکته رو هم در نظر داشت که هر که بامش بیش برفش بیشتر . اگه کسی تعداد رکوردهاش به 5 میلیون میرسه دیگه نباید روی هاست های اشتراکی بمونه (البته با توجه به کاربرانش ) باید بره سمت سرور مجازی بعد خود سرور و ...

اگه قرار بود فیس بوک روی هموس هاست بمونه که الان به اینجا نمی رسید

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

[Restlesa]

سلام به همگی
میشه در رابطه با stored procedure یه توضیحی بدین ؟؟؟
با تشکر

[under22]

سلام به همگی
میشه در رابطه با stored procedure یه توضیحی بدین ؟؟؟
با تشکر

وقتی از stored procedure استفاده می کنید علاوه بر اینکه خطر حمله sql injection صفر میشه وقتی برای بار دوم اون رو صدا می زنید دیگه نمیاد کوئری رو اجرا کنه بلکه دفعه اول اون رو داخل خود mysql کش میکنه و باعث میشه حدودا 45% سریعتر باشه .
اگه باز هم تو سرعت مشکل داشته باشید باید کش کنید کش تو PHP انواع زیادی سریعترینشون apc cache , memchache هست که واسه ساتی های خیلی بزرگ استفاده میشه .

[Restlesa]

طریقه استفاده از stored procedure و memchache به چه صورته ؟؟؟

[under22]

طریقه استفاده از stored procedure و memchache به چه صورته ؟؟؟

برای استفاده از stored procedure باید اون رو مثل یک فانکشن php تو خود Mysql تعریف کنید .
این کتاب آموزشش هست .
لینک
memcache اکثرا تو یک سرور جدا استفاده میشه ولی apc طبق مقایسه ها و الگوریتم هایی که داره از memcache سریعتر حدودا 3 برابر سریعتره . کلا سریعترین کشی هست که وجود داره .
برای استفاده از هر جفتشون باید تو سرورتون نصب باشه

[Restlesa]

یه منبع آموزشی سراغ نداری برام قرار بدی ؟؟؟
بر فرض مثال memcache و یا apc بر روی سرور نصب هستن. حالا چه طوری باید ازشون استفاده کرد ؟؟؟ آیا کلاس خاصی برای اینکار وجود داره ؟؟؟

[under22]

من اول بهتون apc کش رو پیشنهاد می کنم چون هم سریعتر و هم نیاز خیلی زیاد به رم نداره چون memcache خیلی رم میخواد .
دوم اینکه سعی کنید خودتن رو درگیر یادگیری یا نوشتن کلاسش نکنید وقتتون رو سعی کنید تا یک فریمورک PHP رو یاد بگیرید اون موقع شما فقط کش رو هر جا احتیاج داشته باشید بنویسید اون موقع فقط تو کانفیگ نوع کش رو عوض می کنید به همین راحتی .
اکثر هاست های اشتراکی apc , memcache رو فعال نمی کنن نمی کنن ولی هاست های بریتینا apc رو براتون فعال می کنن .
بهترین فریمورک هم برای یادگیری فعلا Yii هست . شما فقط به بازدهیش با apc و بدون apc نگاه کنید .
لینک
شما اگه اصول رو رعایت کنید و کش هم استفاده کنید هیچ مشکلی پیش نمیاد . من خودم چون پروژه هام خیلی سنگین نیست از کش فایل استفاده می کنم که همه هاست ها ساپورت میکنه و بازدهی خوبی هم داره ولی نه مثل کش هایی که قبلا گفته بودم .

[سعید صابری]

فکر کنم خواندن این تاپیک برای همه خالی از لطف نباشه
https://barnamenevis.org/showthread.p...A7%D8%B3%D8%AA!

[Restlesa]

من اول بهتون apc کش رو پیشنهاد می کنم چون هم سریعتر و هم نیاز خیلی زیاد به رم نداره چون memcache خیلی رم میخواد .
دوم اینکه سعی کنید خودتن رو درگیر یادگیری یا نوشتن کلاسش نکنید وقتتون رو سعی کنید تا یک فریمورک PHP رو یاد بگیرید اون موقع شما فقط کش رو هر جا احتیاج داشته باشید بنویسید اون موقع فقط تو کانفیگ نوع کش رو عوض می کنید به همین راحتی .
اکثر هاست های اشتراکی apc , memcache رو فعال نمی کنن نمی کنن ولی هاست های بریتینا apc رو براتون فعال می کنن .
بهترین فریمورک هم برای یادگیری فعلا Yii هست . شما فقط به بازدهیش با apc و بدون apc نگاه کنید .
لینک
شما اگه اصول رو رعایت کنید و کش هم استفاده کنید هیچ مشکلی پیش نمیاد . من خودم چون پروژه هام خیلی سنگین نیست از کش فایل استفاده می کنم که همه هاست ها ساپورت میکنه و بازدهی خوبی هم داره ولی نه مثل کش هایی که قبلا گفته بودم .

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

[Restlesa]

یه سوال دیگه برای فیلدهایی که تنها 5 عدد 1 تا 5 رو می گیرن از نوع enum استفاده بشه بهتر و بهینه تر یا از tinyint ؟؟؟ برای فیلدهایی که بصورت boolean هستن چه طور ؟؟؟

[meysam7972]

بچه ها با سلام
میشه به سوال منم جواب بدین؟
میشه از طریق صفحات php اتصال به سرور ویندوزی کرد

[nazanin_asadi_1]

بچه ها با سلام
میشه به سوال منم جواب بدین؟
میشه از طریق صفحات php اتصال به سرور ویندوزی کرد

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

درباره سوالت هم با php چطوری میخوای به سرور وصل بشی ؟ اصلا قضیه چیه سوالتو توی یه تایپیک جدید کامل توضیح بده اینجا دیگه کامنت نزار

[under22]

یه سوال دیگه برای فیلدهایی که تنها 5 عدد 1 تا 5 رو می گیرن از نوع enum استفاده بشه بهتر و بهینه تر یا از tinyint ؟؟؟ برای فیلدهایی که بصورت boolean هستن چه طور ؟؟؟

متاسفانه بنده نمی دونم که اگه دستی خودمو بخواهیم از apc استفاده کنیم به چه صورت هست ولی میتونی تو سایت خود Php.net بری بخونی .
برای انتخاب درست نوع فیلدت یه نگاه به لینک زیر بکن خودت متوجه میشی .
لینک
در ضمن اگه چیزی که میخای ذخیره کنی به صورت رشته بود و طولش تقربا همیشه یکی بود و یکی یا دو تا حرف بالا پایین بود حتما از char استفاده کن . چون char طولش ثابته و متغییر نیست بخاطر همین یه خورده حجم دیتابیست زیاد میشه ولی در عوض سرعتت میره بالا تر نسبت به varchar

[سعید صابری]

یه سوال دیگه برای فیلدهایی که تنها 5 عدد 1 تا 5 رو می گیرن از نوع enum استفاده بشه بهتر و بهینه تر یا از tinyint ؟؟؟ برای فیلدهایی که بصورت boolean هستن چه طور ؟؟؟

تست سرعت enum,tinyint,bit

Avg 100 iteration time, 10,000 inserts (lower better)
data type	myisam	memory	innodb
enum	0.9934	0.8971	tba
bit	1.009	0.9056	tba
tinyint	1.0335	0.8987	tba
Avg 100 iteration 10k ins Inserts/Second (higher better)
data type	myisam	memory	innodb
enum	10066.4385	11147.02932	tba
bit	9910.8028	11042.4028	tba
tinyint	9675.8587	11127.1837	tba