• 1 رای - 5 میانگین
  • 1
  • 2
  • 3
  • 4
  • 5
Postgres vs MySQL InnoDb
#1
در یکی از گروه های Database تلگرام یکی(https://telegram.me/anouri) همچین مطلبی نوشت:

چرا مهندسین uber دیتابیس خود را از postgresql به mysql تغییر دادند؟
معماری postgresql:

"- معماری ناکارآمد برای نوشتن
- و replication نا کارآمد
- مشکلاتی در خرابی جدوال
- پشتیبانی ضعیف از ریپلیکیشن MVCC
- ارتقاء به نسخه جدید سخته
مقایسه postgresql و innodb برای mysql و روشی که برای دسترسی به جدوال و ایندکس ها به کار رفته مشخص میکنه که دلیل این مشکل کجاست.
در واقع این دو دیتابیس از دو روش متفاوت برای ایندکس گذاری و نوشتن اطلاعات استفاده میکنن .
فرمت اطلاعات روی دیسک:
هر دیتابیس رابطه ای باید چند وظیفه زیر رو انجام بده
- ایجاد و تغییر و حذف (insert/update/delete)
- امکات تغییر ساختار جداول
- امکان MVCC یا multiversion concurrency control به این معنی که هر ترنزکشن برای هر اتصال (connection) باید ویوی خود را از دیتا داشته باشه.
در واقع postgresql اطلاعات رو بصورت تغییر ناپذیر در دیسک ذخیره میکنه و از مکانیزمی که اون رو tuples مینامه استفاده میکنه. برای هر tuples یک شناسه منحصر به فرد به اسم ctid استفاده میشه.
فهمیدن ctids کمک میکنه که postgresql چطور اطلاعات رو روی دیسک نگهداری میکنه. در واقعtuple رو میشه به محل واقعی رکورد روی دیسک تعبیر کرد.
این مکانیزم باعث میشه postgresql برای پیدا کردن رکورد در ساختار ایندکس کنار اطلاعات فیلدهای ایندکس ctid رو هم نگه داری کنه .
این مکانیزم باعث میشه نوشتن اطلاعات یا insert اطلاعات بیشتر رو روی دیسک بنویسه .
1- باید اطلاعات رکورد روی دیسک ذخیره بشه
2- اضافه کردن رکورد به ایندکس primary برای tuple جدید
3- بروز رسانی ایندکس های دیگه برای tuple جدید
هم چنین postgresql برای تضمین integrity اطلاعات رو در WAL ذخیره میکنه. Write Ahead Logging
لذا مقدار دیتای مورد نیاز برای نوشتن بیشتر هم میشه.
و مشکلات replication و خرابی جدول و ... که در اینجا توضیح داده نشده.
در مقابل mysql - innodb مکانیزم MVCC رو ساپورت میکنه . در مقابل postgresql در اینجا ادرس رکورد در ساختار ایندکس نگهداری نمیشه و لذا برای پیدا کردن یک رکورد بر اساس ایندکس ابتدا pk باید در جدول ایندکس پیدا بشه و سپس در جدول ایندکس کلیدی باید محل اون روی دیسک پیدا بشه. اینجا روشی است که از postgresql متفاوت هست.

برای مطالعه بیشتر میتونید
https://eng.uber.com/mysql-migration/
رو دقیق بخونید."


من با بعضیاش برخورد کردم، اما بقیه هم اینارو تجربه کردن واقاً؟ درسته؟
وبلاگ: Yousha.Blog.ir


 کد کمتر => خطای کمتر => قابل فهمتر => خوانایی بالاتر => نگهداری بهتر

  پاسخ
تشکر شده توسط : farhadhp undefined Maysam.m Reza admin
#2
منم دیدم این پستو.
بعضیا هم تایید کردن بعضیام میگفتم دروغه و مثل اوراکل منتها اپن سورس!
همیشه برای یادگیری، موضوعاتی هست!

فرهاد حسن پور / بیرگیک

  پاسخ
تشکر شده توسط :
#3
والا از این مقاله من چیز زیادی حالیم نشد.
اما تجربه شخصی من تا این حده که
mysql انجین innodb کلیه دیتابیس ها جداول و ایندکس ها رو توی یه فایل ibdata1 قرار میده
برعکس postgres به ازای هر دیتابیس یک فولدر میسازه با فایلهای متعدد و زیاد و این به نظرم بهتره

یه بنچ مارک قبلا گرفتم از جفتشون روی حجم بالا با داده های عینا مشابه
میزان مصرف هارد postgres دو برابر mysql بود
نکته جالب اینجا بود با حذف رکورد ها و خالی کردن جداول postgres بلافاصله هارد خالی شد ولی mysql اینجوری نبود (قشنگ یادمه چهل و خورده ای گیگ دیتا توش بود)

مساله دیگه توی postgres بهش برخوردم توی update هست
وقتی یه رکورد رو آپدیت میکنم وقتی دستور select * from tbl رو میزنم بدون هیچ sort کردنی ، رکوردی که آپدیت کردم میره ته لیست قرار میگیره .
یعنی فکر کن رکورد 1 و 2 و 3 رو دارم حالا رکورد 1 رو آپدیت میکنم لیست اینجوری میشه 2 و 3 و 1
انگار delete و insert میکنه

در کل من از postgresql خیلی راضیم خدام ازش راضی باشه Big Grin
اکثرا هم دیدم از mysql مهاجرت میکنن ولی دیگه نوبره postgres رو ول کنی بری روی mysql Dodgy
وبلاگ rezaonline.net/blog
سفارش برنامه نویسی reza.biz
Php , mysql , postgresql , redis , Yii and ... Cool
  پاسخ
تشکر شده توسط : Y.P.Y
#4
چیزهایی که uber در مورد ساختار postgresql گفته بعضی از مواردش درسته ولی بعضی های دیگه به نظر میاد اشتباه باشه. مخصوصا سر ایندکسها. البته من ساختار درستی ازشون ندیدم ولی ایجاد ایندکس روی postgresql به مراتب سریعتر از mysql هست .
اینا تجربه خوب و بد من در مورد postgresql هست
۱- نسخه های minor برای آپدیت هیچ مشکلی نداره و سریع آپدیت میشه ولی نسخه های اصلی که فیچر های جدید داره کار سختی هست. باید هر دو دیتابی stop بشه و بعد فایلها رو کپی کنه از یه جدول به جدول دیگه. آخر کار هم analyze بزنی . البته برای دیتابیس هایی که باید همیشه آنلاین باشن اگه رپلیکیشن وجود داشته باشه به طریقی بدون downtime میشه آپگرید کرد. ولی خب آپگرید کردن همیشه دردسر داشته برای mysql هم دردسرهای خودش رو داره. ولی postgresql تقریبا هر سال یک نسخه با فیچر های جدید میده
۲- اضافه و حذف ستون (به جز alter کردن) و ایندکس توی postgresql خیلی سریع انجام میشه. دلیل هم به خاطر ساختار فایلش هست
۳- postgresql به شدت به هارد و رم حساسه. یک مقدار مشکل داخلش می تونه دردسر ساز بشه. البته مشکل رو هر سال دارن بهتر می کنن. من هم به مشکلاتی خوردم که مجبور شدم وارد ctid بشم و یکسری از رکوردها رو مجبور شدم حذف کنم. ولی مشکل اگه توی رپلیکیشن بوده خیلی راحتت حل کردم. فقط گذاشتم دوباره سینک بشه
۴-pgsql بر خلاف mysql قابلیت توسعه راحتتری داره. پلاگین های خیلی زیادی داره و این توی خیلی از موارد بهم کمک کرده
۴- یه cluster درست و حسابی نداشته ولی من مشکلی با رپلیکیشن باهاش نداشتم
۵- به نظرم من postgresql استانداردتره. data type های درست و حسابی تره داره.
۶- بهینه سازی داخل pg به مراتب راحتتر از mysql برام بوده. خروجی explain analyze همیشه قابل درکتر از explain mysql بوده
۷- نمی دونم چرا uber از خود رپلیکیشن pgsql مستقیم استفاده کرده یا از pgpool یا امثال اینا استفاده کرده من مشکلی توی این زمینه ازش ندیدم

سطح دیتایی که uber داره کار می کنه سطح خیلی بالایی هست و تعداد تراکنش هاش هم خیلی زیاده. mysql توی زمینه cluster کردن ابزارهای جانبی بیشتری نسبت به pgsql داره.
اما من توی بهینه سازی هایی که انجام دادم با pgsql خیلی راحتتر بودم و حتی سوئیچ از mysql به pgsql باعث شده سرعتش خیلی بهتر بشه.

این مطلب هم خوبه
http://use-the-index-luke.com/blog/2016-...-databases
اینجا هم بحثهای جالبی شده
https://news.ycombinator.com/item?id=12166585
  پاسخ
تشکر شده توسط : Y.P.Y Reza Alaa


پرش به انجمن:


کاربران در حال بازدید این موضوع: 1 مهمان