partitioning vs replication vs sharding

[@SaharAhsani]

توضیحاتتون خیلی واضح و شفاف هست ممنونم ازتون🌸🌸

[@mehrdadmoslemi-zo8vw]

replication کاربرد متفاوتی دارد و صورت مسئله ايکه مربوط به رپلیکیشن هست متفاوت است

[@webgeek_ir]

بسیار عالی

[@kiarash-amiri]

درود برشما مخلصیم❤

[@bahramhosseini5377]

خیلی ساده و خوب توضیح دادی دمت گرم👍😉

[@kiarash-amiri]

مرسی، درود بر تو بهرام جان

[@mohammadfallah3656]

خیلی خوب وبا کیفیت توضیح دادی. تشکر

[@kiarash-amiri]

درود بر شما محمد جان، مرسی رفیق

[@aliomidian4062]

دمت گرم

[@kiarash-amiri]

مرسی، مخلصیم رفیق

[@raziyehnikookolah6107]

Good topic

[@kiarash-amiri]

So glad you found it helpful!

[@manoochehrkateb218]

عالی مهندس استفاده کردیم . فقط یه سوالی ذهنمو درگیر کرد . وقتی داشتید ریپلیکت رو توضیح میدادین گفتید رکوئستا توی نود های مختلف پخش میشه ، خب این باعث کاهش ریسپانس تایم نمیشه درسته ؟ فقط ha رو بالاتر میبره .

[@raminsadeghnasab9310]

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

[@manoochehrkateb218]

@@raminsadeghnasab9310 دیتابیس اضافه کنی سرعت خواندنت میره بالا ؟! مثلا من اگه ده تا ریپلیکت داشته باشم با ۱۰ تا رکوئست در دقیقه زودتر از وقتیه که ریپلیکت نداشته باشم ؟!

[@manoochehrkateb218]

@@raminsadeghnasab9310 مثلا اگر ده تا رکوئست در دقیقه داشته باشم وقتی ده تا ریپلیکت داشته باشم سرعت خواندنم پایین تره وقتیه که ریپلیکت نداشته باشم ؟!

[@kiarash-amiri]

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

[@farzad5128]

یه سوالی داشتم کیارش اینکه مثلا اینستاگرام از ده یا پونزده سال پیش که شروع بکار کرده جدول لایک های کاربران و یا بزرگترین جدولش از نظر تعداد سطر یه عدد بزرگیه. اینم میدونیم که هر جدولی باید یه کلید اصلی منحصر داشته باشه. سوال اولم اینه که ایا کمپانی های بزرگ کلید اصلیشون عدده یا رشته؟ کاری به اون رشته منحصری که مثلا یوتیوب داخل لینکاش هست ندارم. حالا اگر کلید اصلیه جدولاشون عدده، به هر حال این عدد سقفی داره مثلا برای mysql دو بتوان ۶۴ هست یا همون bigint و یه هرحال یجا تموم میشه. این مشکل چطور رفع شده؟ یا اگر رشته است ایا میشه ابر داده رو رشته، کلید اصلی کرد؟

[@kiarash-amiri]

درود بر تو فرزاد جان سوال جذابی پرسیدی، ببین من مطالعه ای نکردم که اون ور دارن به چه شکل به طور واقعی هندل می کنن، ولی برای یوتیوب رو قبلا که یه مقاله خونده بودم از یه string که 11 تا کاراکتر داره استفاده می کنن که توی اون می تونه از a-z و A-Z و 0-9 و کاراکتر های خاص هم استفاده بشه، که در کل می کنه ۶۴ تا کاراکتر و در کل میشه 64^11 که خیلی عدد گنده ایه همین! اگرم می پرسی چرا ۱۱ چرا ۱۰ نه مثلا! چون که بین همین ۱۰ تا ۱۱ خیلییییی فاصله وجود داره و حتی اگه بازم کم بیارن اگه رشترو ۱۲ کاراکتری بکنن باز دیگه خیلی بزرگ میشه! می تونی این تفاوت رو تو لیک زیر خواستی ببینی wolframalpha.com/input?i=64**10 wolframalpha.com/input?i=64**11 wolframalpha.com/input?i=64**12 یه کار دیگه ای هم که ممکنه انجام بدن این می تونه باشه که مثلا اون id در حد پارتیشن یا شارد یونیک باشه! و لازم باشه برای رسیدن به سطر id و پارتیشن key رو با هم بشناسی

[@farzad5128]

@@kiarash-amiri ممنون از پاسخت. پس میشه به قطع گفت که کلیدهای اصلی جدول های کمپانی های بزرگ، عدد نیست؟ آیا همین رشته ی کوتاهی که در لینک های یوتیوب میبینیم همون کلیدهای اصلی جدول هستن؟ طبق گفته خودت الان آی دی یا همون کلید اصلی همین ویدیو خودت qw1067H3ESc است که یازده کرکتره. ایا پس از ۲۰ سال فعالیت یوتیوب و هزاران رکورد در میلی ثانیه این عدد بزرگه رو به اتمام نیست؟ البته همین تولید یک رشته یازده رقمی یونیک بصورت جهانی در میلی ثانیه و غیر متوالی خودش یه چالش بزرگه :/ ایا سرعت جستجو برای ایندکس عددی بیشتر از رشته نیست یا اینکه اصلا مهم نیست؟ و اینکه موضوع به این مهمی و البته مبهم، چرا پاسخ ها و راه حل های مشخصی براش وجود نداره و هر کمپانی برای خودش یه مسیری رفته؟ من هر سرچی میزنم راجب این موضوعات همه مطالب بر اساس فرضیات هستند و کسی راه حلی نداره. شاید بهتره بگم چرا داکیومنت های دیتابیس های اوپن سورس این مباحث پیشرفته رو راهنمایی نکردن و توضیحاتی ندارن. یجا هم گفتی یوتیوب از مای اس کیو ال استفاده میکنه. چندجای دیگه هم خونده بودم. ایا واقعا دیتابیس های رابطه ای میتونن حجم عظیمی از ورودی رو بدلیل کند بودن رایت هندل کنن؟

[@amirphl7834]

به نظر من این مثالی که از کاربرد پارتیشن زدی نه برای حل مشکل زمان کوئری برای ۲۰۰ میلیون ریکورد مناسبه نه برای ۷۵ درصد حجم داک ها. اگر ۲۰۰ میلیون رکورد رو ۲ تا تیبل کنی، در هر صورت ایندکس هر ۲ رو بازم باید آپدیت نگه داری، هر ۲ هم تو مموری نگه داری. پس فرقی نمیکنه. الان هم دیسک‌های ssd خیلی ارزونن. دیگه تقریبا همه همه چی رو میبرن رو اس اس دی، مگر مثلا دیتای hdfs که شاید بره رو hdd. نظر شخصی من بود. شاید یه سری چیزها رو در نظر نگرفتم یا دارم اشتباه میکنم. همین شاردینگ خیلی روی جوین‌ها افکت میذاره.

[@kiarash-amiri]

امیر جان درود برتو چند تا مورد: ۱- برای مثال ها خیلی بستگی داره به هر سیستم متفاوته، مثلا همون ۲۰۰ میلیون رکوردی که گفتم دوتا پارتیشن می کنیم، سر حجم index نکتش اینکه باید ببنیم روی چی index ست شده! یعنی نمیشه گفت ۱۰۰ میلیون رکورد index فلان قدر حجمش میشه! و در کل دو تا پارتیشنی که گفتم مثال بود با توجه به سیستم می تونه هر اندازه ای ست بشه ۲ـ در مورد هارد هم که گفتی بعضی از هارد هایی که تو کمپانی ها برای سرور ها استفاده میشه به شدت گرونه! و scale هم خیلی مهمه یعنی 75 درصد چقدر؟ یعنی 75 درصد ۱۰۰۰ ترابایت میشه ۷۵۰ ترابایت!! به منظور تو scale بالا میتونه خیلی هزینه رو کاهش بده در مورد نکته ای که از افکت شاردینگ رو جوین‌ها هم گفتی منظورت رو نفهمیدم، بیشتر میشه توضیح بدی

[@amirphl7834]

فرض کن ایندکس یک بی تری روی آیدی باشه. من حس میکنم اگر پارتیشن کنی (هر تعداد که میخواد باشه)، حجم ایندکس تغییر نمیکنه. نقل قول: Whether horizontal partitioning changes the index size depends on the specifics of how indexing is implemented in your database system. In some cases, the index size may remain relatively unchanged because each partition may still require its own index to efficiently query the data within that partition. در مورد ۲، احتمالا یه کمپانی که ۱۰۰۰ ترابایت دیتا داره، شاید بره ذخیره سازی سمت اچ دی اف اس و همونطور که گفتم روی دیسک ببره دیتا رو. حرف شما درسته و در اسکیل بالا امروزه شاید به صرفه تر باشه. به نظرم ۱۰ سال دیگه اینقدر قیمت اس اس دی میاد پایین که حتی تو اسکیل هم اس اس دی میبره. اگر یک شارد در سرور ۱ و شارد دیگه در سرور ۲ باشه، برای جوین زدن احتمالا یک سری دیتا از سرور ۱ رو باید با سرور ۲ ترکیب کنی. اینجا باید هزینه نتورک آی او بدی. اینو مقایسه کن با جوین زدن وقتی دیتا تو یک سرور هست و فقط کافیه تو مموری لود کنیم و جوین بزنیم.

[@kiarash-amiri]

@@amirphl7834 امیر جان تو همین متنی که فرستادی گفته "امکانش هست" که ایندکس تغییر کنه، حالا در چه صورتی؟ در صورتی که ایندکسی که روی یک پارتیشن میزاری با ایندکس یه پارتیشن دیگه تفاوت داشته باشه! که خب این طبیعیه یعنی اگه دو تا پارتیشن که فیلد های یکسان و حجم یکسان دارن چه دلیل داره حجم ایندکسشون متفاوت باشه نکته جوین زدنت رو هم تازه متوجه شدم، اره کاملا درست میگی کلا هزینه کوری هایی که نیاز به دیتای دوتا شارد داره افزایش پیدا می کنه، یا حتی همون جوری که تو ویدیو بهش اشاره کردم قابلیت transaction رو هم کامل از دست میدیم