PDA

View Full Version : بهینه ترین حالت دیتابیس MYSQL در سایت های آمارگیر



Weblove
دوشنبه 11 اسفند 1393, 13:15 عصر
سلام
بهینه ترین حالت دیتابیس MYSQL در سایت های آمارگیر مثل پرشین استت به نظر شما چیست ؟
لطفا راهنمایی بفرمایید

Weblove
دوشنبه 11 اسفند 1393, 16:51 عصر
شدنیه ترکیبی از فایل و MYSQL ؟ ( برای بهینه تر شدن )
لطفا ایده بدید

golbafan
دوشنبه 11 اسفند 1393, 17:24 عصر
نوع و قدرت سرور شما هم مهمه
میتونید جواب سوالتون رو در فروم مای اسکیوال پیدا کنید و یا کمی سرچ در گوگل

Weblove
دوشنبه 11 اسفند 1393, 17:50 عصر
بهینه باشه یعنی در بالاترین شرایط کمترین سرور رو نیاز داشته باشه

tem988
دوشنبه 11 اسفند 1393, 19:28 عصر
سلام
این سایت ها احتمالا از همین mysql استفاده میکنند ولی با روش های مختلف.
آمارگیر برای ثبت آی پی ها و رفر ها روی فایل پیشنهاد نمیشه چون طبقه بندیشون سخته و نمیشه زیاد مانورد داد.
ولی برای اینکه کارتون راه بیفته باید mysql استفاده کنید و تنها راهی که میشه به بهترین نحو نتیجه گرفت تقسیم بندی جدولهایی که رکورد بالایی دارند.
این روش تقسیم بندی هم خودم تست کردم 70% فشار روی سرور رو کاهش میده.

Weblove
دوشنبه 11 اسفند 1393, 22:13 عصر
میشه در مورد این تقسیم بندی کمی توضیح بدید ؟

golbafan
دوشنبه 11 اسفند 1393, 23:06 عصر
میشه در مورد این تقسیم بندی کمی توضیح بدید ؟

منظور ایشون پارتیشن بندی جداول هست:

http://dev.mysql.com/doc/refman/5.1/en/partitioning.html

http://planet.sito.ir/%D9%BE%D8%A7%D8%B1%D8%AA%DB%8C%D8%B4%D9%86-%D8%A8%D9%86%D8%AF%DB%8C-%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA-%D8%AF%D8%B1-%D9%BE%D8%A7%DB%8C%DA%AF%D8%A7%D9%87-%D8%AF%D8%A7%D8%AF%D9%87/

Weblove
سه شنبه 12 اسفند 1393, 12:18 عصر
تا اینجا به نتیچه رسیدیم که برای بهینه تر شدن از دو عامل میتونیم استفاده کنیم
1 - ترکیب مناسبی از فایل و مای اس کیو ال
2 - پارتیشن بندی جداول

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

freeman99
سه شنبه 12 اسفند 1393, 20:45 عصر
اگر میتونی اول یه نمونه کوچکتر (در مقیاس کوچک/آزمایشی) درست کن و در عمل تست کن.
فکر نمیکنم فقط با تئوری و پرسیدن و تحقیق و جواب از چند نفر دیگه بیایم یه سیستم جدی و عملیاتی درست کنیم کار بهینه ای باشه و بشه تمام موارد و نکات رو درآورد. خیلی وقتا اصلا شما بیش از حدی که در عمل لازمه ممکنه بهینه سازی کنی یکسری جزییاتی رو و صرفا وقت و انرژی خودت رو تلف کنی و برنامه رو بیخودی پیچیده کنی.
مسائل پرفورمنس معمولا نیاز به تست و تجربه عملی دارن و پیدا کردن bottleneck ها. البته بهینه سازیهای خیلی بزرگ و واضح و بدیهی رو که میدونیم تقریبا حتمی است یا خیلی محتمل است که در عمل نیاز یا خیلی مفید باشن میشه از قبل پیشبینی و پیاده کرد.
برای بهینه سازی صدها ایده میشه داشت، هزاران جزییات هست، ولی همه رو که در هر برنامه ای استفاده نمیکنن. مثل اینکه بیای همه جور ادویه رو توی یک غذایی بریزی به امید اینکه خوشمزه ترین غذای دنیا بشه!!
البته یه راه هم اینکه از منابع اصلی تر در این مورد تحقیق کنی و ببینی چه تجربیاتی داشتن و چه روشها و ساختاری رو استفاده کردن!

Weblove
سه شنبه 12 اسفند 1393, 21:59 عصر
کاملا درست میفرمایید
اما این مرحله ی اخره
در مرحله اول متوجه شدم که از دو موردی که بالا نوشتم می تونم استفاده کنم
قبل از این به استفاده از فایل فکر کرده بودم اما واقعا در مورد پارتیشن بندی چیزی نمیدونستم

freeman99
سه شنبه 12 اسفند 1393, 22:55 عصر
پارتیشن بندی قبلا خوندما، اما دقیق یادم نیست چی بود و واسه چی استفاده میشد!
ولی ایدهء تقسیم یک جدول به چند جدول که شاید نوع ساده تر و بدوی تر و محدودتری از پارتیشن بندی باشه بارها به ذهنم رسیده برای چیزهای مختلف. اصلا شاید این روش برای بعضی کارها بهتر هم باشه.
مثلا فرض کنید یک جدول بزرگ از نامهای کاربری یا IP یا چیزهای مشابه داریم، میتونیم بیایم محدوده های مختلفی از رکوردها رو در یک جدول ذخیره کنیم، محدودهء دیگری رو در جدول دیگر، و همینطور الی آخر.
مثلا نامهای کاربری که از حروف A تا D شروع میشن در یک جدول، نامهای کاربری از D تا G در جدول دیگر، ... موقعی که کاربری رو میخوای چک کنی اول چک میکنی که در چه محدوده ای واقع شده و بعد برای جدول مربوطه کوئری میدی. خب طبیعتا کوئری ای که در یک جدول با صد هزار رکورد اجرا میشه سرعت اجراش میتونه نسبت به جدولی که یک میلیون رکورد داره بیشتر باشه. حتی این تقسیم بندی میتونه دینامیک باشه بر اساس تعداد کاربران با هر توالی حروفی و نه لزوما یک محدودهء فیکس شده.
البته این مثالی که من زدم فرضی و خیلی خام بود. لزوما تقسیم بندی به این شکل نیست و لزوما برای چنین چیزی این کار مناسب نیست. در بعضی موارد این روش حتی میتونه بعضی عملیات رو کندتر هم بکنه! پس باید مورد رو دید و اینکه کار اصلی و عمدهء ما با اون اطلاعات چیه و آیا چنین روشی بازدهی کافی داره یا نه (چون بهرحال بطور معمول کد رو پیچیده تر و حجیم تر میکنه).
در کل سادگی و راه سرراست اولین گزینه است و راههای دیگر فقط موقعی که ضرورت بود و واضح بودن. در خیلی موارد که روش ساده تر اصلا سریعتر هم هست یا جزو یکی از سریعترین روشهاست (اینو فقط من نمیگما، توی منابع و کتابها خوندم :لبخند:).

golbafan
سه شنبه 12 اسفند 1393, 23:41 عصر
در لینکهایی که براتون گزاشتم کامل توضیح داده که پارتیشن بندی چیه و چرا استفاده میشه:
http://planet.sito.ir/%D9%BE%D8%A7%D8%B1%D8%AA%DB%8C%D8%B4%D9%86-%D8%A8%D9%86%D8%AF%DB%8C-%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA-%D8%AF%D8%B1-%D9%BE%D8%A7%DB%8C%DA%AF%D8%A7%D9%87-%D8%AF%D8%A7%D8%AF%D9%87/

بطور کلی وقتی داده ها میلیونی میشن برای اینکه جستجو در همه رکوردها صورت نگیره ما جدول رو پارتیشن بندی میکنیم مثلا به 120 قسمت بر اساس تاریخ مثلا
بعد اگر تاریخ ها مثلا در طول 10 سال باشه، هر پارتیشن حدودا یک ماه رو دربر میگیره

و سرعت جستجو و ثبت 120 برابر خواهد شد

البته هنگام پارتیشن بندی ، انجین شما هم مهمه

اگر از myIsam استفاده بشه خیلی سرعت بالا میره چون هر پارتیشن یک فایل مجزا میشه
در غیر اینصورت اینکار مجازی انجام میشه و همه پارتیشن ها در یک فابل قرار میگیرن

tem988
چهارشنبه 13 اسفند 1393, 19:52 عصر
سلام
منظورم از تقسیم بندی پارتیشن بندی نبود روی سرور 64 گیگ رم با cpu E5-2690 تست کردم روی امار بالا و رکورد میلیونی البته حجم دیتابیس هم بالای 50 گیگ جواب نداد.
در کل پارتیشن بندی برای سایت آمار گیرم تاثیری نداره چون هم حجم دیتابیس بالاست هم رکوردها.

منظورم از تقسیم بندی یوزرهاست مثلا ما میایم لوگهای هر 2 هزار یوزرو توی یک جدول به نام log_1 و 2 هزار تای بعدی رو توی جدول log_2
همین روشو با پارتیشن هم تست کردم روی انجینهای مختلف جدول ولی نتیجه ی خوبی نداشت و راضی کننده نبود.
این روش تقسیم بندی رو تست کردم و خیلی خوب جواب داده در کل راضی بودم.

و یک مورد دیگه فیلدهای که حجم دیتاشون بالاست روی فایل باشه و بقیه موارد که int یا varchar روی دیتابیس.

golbafan
جمعه 15 اسفند 1393, 20:18 عصر
سلام
منظورم از تقسیم بندی پارتیشن بندی نبود روی سرور 64 گیگ رم با cpu E5-2690 تست کردم روی امار بالا و رکورد میلیونی البته حجم دیتابیس هم بالای 50 گیگ جواب نداد.
در کل پارتیشن بندی برای سایت آمار گیرم تاثیری نداره چون هم حجم دیتابیس بالاست هم رکوردها.

منظورم از تقسیم بندی یوزرهاست مثلا ما میایم لوگهای هر 2 هزار یوزرو توی یک جدول به نام log_1 و 2 هزار تای بعدی رو توی جدول log_2
همین روشو با پارتیشن هم تست کردم روی انجینهای مختلف جدول ولی نتیجه ی خوبی نداشت و راضی کننده نبود.
این روش تقسیم بندی رو تست کردم و خیلی خوب جواب داده در کل راضی بودم.

و یک مورد دیگه فیلدهای که حجم دیتاشون بالاست روی فایل باشه و بقیه موارد که int یا varchar روی دیتابیس.

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

البته این روش تقسیم بندی که شما میفرمایید برای مثلا هر 2000 رکورد یوزرها یک جدول درست کنیم به اسم log1 الی آخر کاملا اشتباه و غیر اصولیه :متعجب:

علت: اگر فقط جدول log رو داشته باشیم و پارتیشن بندی کنیم، با اینکه فایلها مجزا شده و کوچک میشوند ولی میتوان با استفاده از یک کوئری مثلا select * from log کارهای مورد نیاز رو انجام داد. در حالی که با روش پیشنهادی شما برای هر جدول نیاز به یک کوئری متفاوت هست و من بعید میدونم سرعت رو زیاد کنه!!!
تازه باید همیشه چک کنید چند تا جدول ایجاد شده و اسمهاشون رو دربیارید بعد اگر آمار کلی بخواهید باید کلی join بزنید که غیر اصولیه...

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

MMSHFE
شنبه 16 اسفند 1393, 08:16 صبح
جاهایی که سرعت ذخیره سازی مهمتر از سرعت واکشی اطلاعاته و به دلیل پارتیشن بندی (ذخیره Logهای هر کاربر در یک جدول)، نیاز خاصی به Relationها در عمل ندارین، میتونید روی DBMSهایی مثل Redis و MongoDB و امثال اونها هم فکر کنید.

freeman99
شنبه 16 اسفند 1393, 11:49 صبح
RBMSهایی مثل Redis و MongoDB و امثال اونها هم فکر کنید.
مهندس منظورت از RBMS همون RDBMS بود؟
R در RDBMS همون Relational است، بنابراین فکر نمیکنم درمورد دیتابیس های NoSQL صدق بکنه.

MMSHFE
شنبه 16 اسفند 1393, 12:28 عصر
اشتباه تایپی بود. اصلاحش کردم. منظورم DBMS بود. ضمناً NoSQL به معنای عدم وجود SQL نیست، بلکه مخفف Not Only SQL هست یعنی علاوه بر امکانات SQL یکسری امکانات دیگه هم وجود داره اما مهمترین کاربردش در مواردی هست که رکوردها دارای فیلدهای متفاوت هستن و نمیشه یا بهینه نیست که اونها رو توی جدول قرار داد.

tem988
یک شنبه 17 اسفند 1393, 19:55 عصر
اینکه شما میفرمایید پارتیشن بندی بر اساس کاربر است
کلا پارتیشن بندی برای همینه که جداول کوچک بشن و تکه تکه

البته این روش تقسیم بندی که شما میفرمایید برای مثلا هر 2000 رکورد یوزرها یک جدول درست کنیم به اسم log1 الی آخر کاملا اشتباه و غیر اصولیه :متعجب:

علت: اگر فقط جدول log رو داشته باشیم و پارتیشن بندی کنیم، با اینکه فایلها مجزا شده و کوچک میشوند ولی میتوان با استفاده از یک کوئری مثلا select * from log کارهای مورد نیاز رو انجام داد. در حالی که با روش پیشنهادی شما برای هر جدول نیاز به یک کوئری متفاوت هست و من بعید میدونم سرعت رو زیاد کنه!!!
تازه باید همیشه چک کنید چند تا جدول ایجاد شده و اسمهاشون رو دربیارید بعد اگر آمار کلی بخواهید باید کلی join بزنید که غیر اصولیه...

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

شما پارتیشن بندی رو روی آمار بالا تست کنید من 100% مطمئنم به نتیجه نمیرسید چون خودم اینقدر تست کردم که تعدادش از دستم در رفته ولی هر دفعه پارتیشن رو حذف کردم.

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

توی پارتیشن بندی همه نوع رو تست کردم هم بر اساس آیدی و هم بر اساس حروف الفبا که میشه username کاربر و فیلدها هم index بودن.

دیتابیس mango همونظور که آقای شهرکی گفتن برای ذخیره اطلاعات خوبه ولی توی تست هایی که انجام دادم برای گرفتن به مشکل میخورید سرعتش نسبت به mysql کمتره و همچنین کوئریهای پیچیده رو نمیشه روش اجرا کرد.

اگر در پارتیشن بندی به تست خوبی رسیدید اطلاع بدید.

golbafan
یک شنبه 17 اسفند 1393, 20:09 عصر
شما پارتیشن بندی رو روی آمار بالا تست کنید من 100% مطمئنم به نتیجه نمیرسید چون خودم اینقدر تست کردم که تعدادش از دستم در رفته ولی هر دفعه پارتیشن رو حذف کردم.
موقع ثبت نام کاربر کافیه آیدی کاربر رو جک کنید و اسم جدول رو برای یوزر ذخیره کنید موقع سلکت اسم جدول رو میزارید توی کوئری و همچنین میتونید دستی اینکارو انجام بدید با شرط و ... اسم جدول رو برای هر چند هزار یوزر مشخص کنید.
توی پارتیشن بندی همه نوع رو تست کردم هم بر اساس آیدی و هم بر اساس حروف الفبا که میشه username کاربر و فیلدها هم index بودن.
دیتابیس mango همونظور که آقای شهرکی گفتن برای ذخیره اطلاعات خوبه ولی توی تست هایی که انجام دادم برای گرفتن به مشکل میخورید سرعتش نسبت به mysql کمتره و همچنین کوئریهای پیچیده رو نمیشه روش اجرا کرد.
اگر در پارتیشن بندی به تست خوبی رسیدید اطلاع بدید.

سلام دوست عزیز
میشه بگید چفدر رکورد داشتید؟

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

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

روشی که من گفتم من در آوردی نیست بلکه حالت استانداردی هست که در oracle, sqlserver, mysql و خیلی دیتابیسهای معروف دیگه استفاده میشه

لطفا مطالب زیر رو جهت افزایش آگاهیتون مطالعه فرمایید:
http://en.wikipedia.org/wiki/Partition_%28database%29
http://dev.mysql.com/doc/refman/5.5/en/partitioning.html
http://www.oracle.com/us/products/database/options/partitioning/index.htm
http://msdn.microsoft.com/en-us/library/ms190787.aspx
http://www.postgresql.org/docs/current/interactive/ddl-partitioning.html
http://www.sybase.com/detail?id=1036923
http://www.mongodb.org/display/DOCS/Sharding
http://scimore.com/wiki/Distributed_schema
http://community.voltdb.com/docs/UsingVoltDB/ChapAppDesign#DesignPartition