PDA

View Full Version : حرفه ای: کسی از دوستان با دیتابیس MYSQL & PHP سایتی با 30-80 میلیون رکورد طراحی کرده؟



i-php-i
شنبه 17 خرداد 1393, 03:34 صبح
برای یه پروژه بزرگ با چند نفر مشورت کردم که از چه دیتابیسی استفاده کنم.

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

شما تا حالا با MYSQL سایتی طراحی کردید که توی یکی دوتا از جدولهاش 30 تا 80 میلیون رکورد ذخیره کرده باشه؟
می تونید سایتی مثال بزنید که با استفاده از نسخه رایگان MYSQL بدون مشکل تونسته باشه چندین میلیون رکورد و بازدید کننده رو جوابگو باشه؟

lord_viper
شنبه 17 خرداد 1393, 08:37 صبح
بستگی به منابع سرور و کوئری که میزنید داره
اگه بخواهید رو هاست معمولی یا اشتراکی همچین کاری رو انجام بدید - خیر جواب نمیده
اما اگه یک سرور اختصاصی بگیرید جواب میده

MMSHFE
شنبه 17 خرداد 1393, 09:30 صبح
برای یه پروژه بزرگ با چند نفر مشورت کردم که از چه دیتابیسی استفاده کنم.

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

شما تا حالا با MYSQL سایتی طراحی کردید که توی یکی دوتا از جدولهاش 30 تا 80 میلیون رکورد ذخیره کرده باشه؟
می تونید سایتی مثال بزنید که با استفاده از نسخه رایگان MYSQL بدون مشکل تونسته باشه چندین میلیون رکورد و بازدید کننده رو جوابگو باشه؟

اتفاقاً برای انجام یک پروژه خاص تو شرکت نیاز بود تصمیم بگیریم از چی استفاده کنیم و با توجه به امکاناتی که داشتیم بین گزینه های SQLite و PGSQL و MySQL و MariaDB و MongoDB تست بنچمارک گرفتیم و مقالات مختلفی رو خوندیم و آخر سر به این نتیجه رسیدیم که MySQL از همه توی اون پروژه خاص بهتر جواب میده.
درمورد سایت نمونه هم میتونید cloob.com رو بررسی کنید (با PHP و MySQL نوشته شده).

rezaonline.net
شنبه 17 خرداد 1393, 09:34 صبح
تا الان روی جهان پی ، جدول تراکنش ها 1.5 میلیون رکورد داریم ، نه کندی سرعت هست نه مشکل خاصی ایجاد کرده :) قبل از شروع پروژه هم من روی این جدول تا ده میلیون تست کردم مشکلی نداشت بعدش رو تست نکردم اما بعید میدونم Mysql روی میلیون رکورد مشکلی داشته باشه ، با خیال راحت استفاده کنید البته ، حتما کوئری های بهینه بزنید و همچنین دیتاتایپ فیلدهاتون رو مناسب انتخاب کنید رعایت ایندکس گذاری مناسب ، باعث سرعت در خواندن اطلاعات در رکوردهای بالا میشود

metal gear solid 4
شنبه 17 خرداد 1393, 10:36 صبح
80 میلیون رکورد برای MySQL مثل جُکه. شما طراحی درستی داشته باشید MySQL تا میلیاردها رکورد رو هم به خوبی جواب میده.
اگر باورنمیکنید از فیسبوک بپرسید!!!!!

eshpilen
شنبه 17 خرداد 1393, 11:10 صبح
فیسبوک داستانش فرق میکنه.
میدونی چندتا سرور داره؟ از چندتا فناوری و زبان استفاده میکنه؟ چقدر برنامه نویسان زیاد و مخوفی داره؟ همه چی رو هم دستکاری کرده و حتی ابزارها و فناوریها و استانداردهای جدیدی رو بوجود آورده.
اونا دیتابیس و پردازش توزیع شده کار میکنن به گمانم!

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

Unique
شنبه 17 خرداد 1393, 14:03 عصر
دوستان همه توضیحات مناسب را دادند ،‌ من هم تجربه استفاده از MySQL و هم MSSQL توی پروژه های بزرگ را دارم. عامل های زیادی تاثیر گذارند از جمله :

- سرویس دهنده مناسب برای Database ، توی پروژه های خیلی خیلی بزرگ بهتره MySQL Server روی یک سرور و فقط برای این کار در نظر گرفته بشه تا بتونه از همه منابع به راحتی استفاده کنه
- تنظیمات و Config مناسب و ایده آل MySQL. یکی از مهمترین موضوعات Config صحیح برای MySQL هست که خودش خیلی خیلی تاثیر گذاره
- طراحی و نرمال سازی و ایندکس گذاری صحیح پایگاه داده
- نوشتن query های متناسب با وضعیت FK ها و ایندکس ها (مثلا استفاده از multi index برای query که بهش احتیاج داره)
- استفاده صحیح و به جا از trigger ها ُ‌و Stored Procedure ها !
و ...

در ضمن ۸۰ میلیون اصلا رقمی نیست. من تجربه ۳۰ تا ۴۰ میلیون رکورد را دارم.
وقتی چنین پروژه اساسی مطرح باشه باید منابع مالی هم وجود داشته باشه که به راحتی میشه سرور های قدرتمند تری استفاده کرد.

راستی چرا بعضی MySQL را انقدر دسته کم میگیریم ؟!
یک نکته دیگه هم اینکه به مرور زمان به قدری تجربه پیدا میکنید که بهینه سازی و بهبود کیقیت query ها براتون جالب و راحت میشه.

i-php-i
شنبه 17 خرداد 1393, 14:34 عصر
تا الان روی جهان پی ، جدول تراکنش ها 1.5 میلیون رکورد داریم ، نه کندی سرعت هست نه مشکل خاصی ایجاد کرده :) قبل از شروع پروژه هم من روی این جدول تا ده میلیون تست کردم مشکلی نداشت بعدش رو تست نکردم اما بعید میدونم Mysql روی میلیون رکورد مشکلی داشته باشه
از چه سخت افزاری (هارد، رم و cpu) برای این کار استفاده کردید؟

روی جدولهایی که چند میلیون رکورد ذخیره کردن LEFT JOIN یا عملگر LIKE استفاده کردید؟

rezaonline.net
شنبه 17 خرداد 1393, 16:40 عصر
از چه سخت افزاری (هارد، رم و cpu) برای این کار استفاده کردید؟

روی جدولهایی که چند میلیون رکورد ذخیره کردن LEFT JOIN یا عملگر LIKE استفاده کردید؟

سرور مجازی معمولی
روی اون جدول تراکنش ها ، خیر جوین استفاده نشده اما like چرا لازم بوده و استفاده شده .
روی سایر جداول که به اندازه این جدول فشار ندارند استفاده شده .
حتی روی جدول صورت حساب به دلیل نیاز از lock table هم استفاده شده :) که اونم هم حدودا 35 هزار رکورد دارد

mysql همانطور که گفتن به خوبی از پسش بر میاد اگر خیلی بخواید حساسیت به خرج بدید میتونید از percona استفاده کنید که کمی سرعت عمل و مصرف منابعش از mysql کمتره ، در کل پرفورمنسش کمی بالاتره رایگان هم هست و تفاوتی با mysql نداره .

انتقال دیتابیس از MySQL به سایت دیتابیس ها مثل pgsql در شرایط بحرانی به راحتی قابل انجام است

under22
شنبه 17 خرداد 1393, 16:44 عصر
میخواستم بدونم کاربرد lock table دقیقا برای چه مواقعی استفاده میشه ؟؟
منظورم کاربردش هست

metal gear solid 4
شنبه 17 خرداد 1393, 17:19 عصر
فیسبوک داستانش فرق میکنه.
میدونی چندتا سرور داره؟ از چندتا فناوری و زبان استفاده میکنه؟ چقدر برنامه نویسان زیاد و مخوفی داره؟ همه چی رو هم دستکاری کرده و حتی ابزارها و فناوریها و استانداردهای جدیدی رو بوجود آورده.
اونا دیتابیس و پردازش توزیع شده کار میکنن به گمانم!

برادر من، نهایتاً MySQL این حجم وسیع اطلاعات رو داره مدیریت میکنه. حالا روی یک سرور یا روی هزاران سرور. باید گفت فاکتور اصلی سخت افزار سروره. من نمیگم MySQL ایرادی نداره که اگه نداشت HBase یا Big Table گوگل بوجود نمی اومدن. انواع اقسام noSQL ها ایجاد نمیشد. اما این اعداد و ارقام 1 میلیون. 2 میلیون 50 میلیون برای MySQL چیزی نیست.
من خودم روی یک سرور با 64 گیگ رم، 2 میلیارد رکورد روی یک جدول از نوع innoDB رو به راحتی 100 رکورد تصادفی رو با مرتب سازی بر اساس ID در کمتر از 0.5 ثانیه کوئری گرفتم. همه چیز به سخت افزار، بهینه بودن ساختار جدول و کوئری بستگی داره. وقتی جدول شما Warm باشه و Buffer pool هم از جدول شما اطلاعات رو گرفته باشه به راحتی MySQL از پس این تعداد رکوردها بر میاد.


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

rezaonline.net
شنبه 17 خرداد 1393, 22:40 عصر
میخواستم بدونم کاربرد lock table دقیقا برای چه مواقعی استفاده میشه ؟؟
منظورم کاربردش هست
بعضی وقت ها لازمه جدولی رو مثلا از خوندن قفل کنی تا یک عملیات خاص رو انجام بدی بعد اجازه بدی !
درخواستهایی که به روی این جدول ارسال میشن منتظر میمونن تا جدول باز بشه .

کاربردش برای من در جدول تسویه حساب به این شکله
اول جدول رو از نوشتن قفل میکنم
بعد یک تراکنش(transaction) رو شروع میکنم
مبلغ موجودی حساب رو میگیرم و به مبلغ پرداختی اضافه میکنم و در جدول رکورد جدید اضافه میکنم
جدول رو باز میکنم و کامیت میکنم.
چون ممکنه همزمان ده نفر مشغول پرداخت مبلغ به حساب اون کاربر باشن دیگه اینطوری تداخلی پیش نمیاد .

beh3000
سه شنبه 15 مهر 1393, 08:23 صبح
سلام ببخشین این تاپیک رو بالا میارم داشتم مطالعه میکردم



وقتی جدول شما Warm باشه و Buffer pool هم از جدول شما اطلاعات رو گرفته باشه

این جمله یعنی چه ؟ در مورد warm و buffer pool میشه بیشتر توضیح بدین ؟