دو مدل از پرکاربردترین دیتابیس ها دیتابیس های سطری (row oriented) و دیتابیس های ستونی (column oriented, columnor or C-store) هستند. هدف ما اینجا اینه که بین این دو مدل دیتابیس مقایسه انجام بدیم.
دیتابیس های سطری دیتا رو رکورد به رکورد سازماندهی میکنند یعنی دیتاهای هر رکورد رو پشت هم دیگه ذخیره میکنند. دیتابیس های سطری روش قدیمی نگهداری و سازمندهی دیتا هستند و یه سری مزیت دارند که باعث میشه هنوز هم برای ذخیره سازی سریع دیتا مورد استفاده قرار بگیرند. دوتا دیتابیس معروف سطری postgres, Mysql
دیتابیس های ستونی دیتابیس هایی هستند که دیتا رو با field سازمندهی میکنند یعنی همه ی دیتاهای مربوط به یه field رو پشت سر همدیگه ذخیره میکنند. این دیتابیس ها محبوبیت بیشتری پیدا کردند و برای کويری زدن روی دیتا مزایای خوبی دارند. برای خوندن و محاسبه روی ستون‌های دیتا بسیار بهینه هستند. از دیتابیس های معروف ستونی میتونیم Clickhouse, Redshift رو نام ببریم.
همونطور که گفتیم این دیتابیس ها روش قدیمی نگهداری دیتا هستند. برای خوندن و نوشتن روی یک سطر از دیتا بهینه هستند که توی بعضی از معماری ها کاربرد داره و میتونه انتخاب خوبی باشه.
توی دیتابیس های سطری همونطور که از اسمش هم مشخصه دیتا به صورت سطر به سطر نگهداری میشه به طوری که اولین ستون هر سطر دقیقن بعد از آخرین ستون سطر قبلی قرار میگیره !
مثلن فکر کنید دیتای ما این شکلیه
تو یه دیتابیس سطری این دیتاها روی دیسک به صورت زیر نگهداری میشن:
این مدل ذخیره سازی باعث میشه نوشتن توی دیتابیس راحت باشه. چرا؟ چون تنها کاری که برای نوشتن سطر جدید باید انجام بشه این هست که دیتای جدید به انتهای دیتای قبلی اضافه بشه
مثلن اگر ما بخوایم دیتای زیر رو اضافه کنیم:
خیلی ساده به انتهای دیتای قبلی اضافه میشه و نتیجه میشه این:
دیتابیس های سطری همچنان کاربرد خودشون رو دارند و تو اپلیکیشن های که نوشتن توی دیتابیس براشون حايز اهمیت هست استفاده میشند. با این حال یه مورد دیگه استفاده از دیتابیس ها این هست که بتونیم دیتای ذخیره شده توی اونها رو آنالیز کنیم اینجا همون جایی که دیتابیس های سطری کندتر از دیتابیس های ستونی عمل میکنند.
دیتابیس های سطری برای بازیابی یه سطر یه یه مجموعه از سطرها خوب عمل میکنند ولی وقتی بخوایم aggregation انجام بدیم دیتای اضافی توی مموری لود میکنند.
مثلن فرض کنید میخوایم برای لیستی که بالا داشتیم مجموع سن افراد رو حساب کنیم. برای اینکه اینکار رو انجام بدیم باید همه ی نه تیکه ی دیتا توی مموری لود بشن بعد دیتای مورد نیاز از توشون جدا بشه تا بتونیم اونا رو با هم جمع بزنیم.
به علاوه با این شرایط تعداد دیسک هایی که ممکنه دیتابیس سطری بهش دسترسی پیدا کنه هم معمولاً بیشتره. مثلن فرض کنید که یه دیسک فقط میتونه به تعدادی بایت داشته باشه که سه تا ستون رو توی خودش ذخیره کنه شبیه شکل پایین:
حالا اگر بخوایم مجموع سن ها رو حساب کنیم کامپیوتر باید بین هر سه تا دیسک و روی همه ی ستون‌ها بگرده تا بتونه دیتای مورد نیاز رو پیدا کنه و عملیات جمع رو انجام بده.
بنابراین همونطور که دیدیم اگر بخوایم به دیتابیس های سطری دیتایی اضافه کنیم این کار سریع و ساده انجام میشه اما اگر بخوایم روی اون دیتا aggregation انجام بدیم هم مموری بیشتری استفاده میکنه و هم ممکنه نیاز به دسترسی به چندتا دیسک داشته باشه
ما روی دیتاهایی که جمع‌آوری کردیم آنالیز هم انجام میدیم این نوع از دیتابیس ها تو خوندن دیتا بهینه هستند. توی دیتابیس های ستونی دیتا به گونه‌ای نگهداری میشه که هر سطر از یه ستون دقیقن بعد از سطر قبلی همون ستون میاد.
مثلن همون دیتای که راجع به اسم، شهر و سن افراد داشتیم رو در نظر بگیرید. توی دیتابیس های ستونی دیتا اینجوری ذخیره میشه:
اگر بخوایم یه رکورد جدید به دیتابیس اضافه کنیم تغییرات به صورت زیر میشه:
اگر دیتا روی فقط یدونه دیسک ذخیره شده باشه، لود مموری موقع خوندن دیتا با دیتابیس سطری تفاوتی نداره چون به هر حال باید همه چی رو توی مموری لود کنه و دیتای مورد نظر رو ازش استخراج کنه. ولی اگر دیتا روی چندتا دیسک ذخیره شده باشه اینجاست که دیتابیس ستونی بهینه بودن خودش رو نشون میده
مثلن حالت زیر رو در نظر بگیرید
برای اینکه بخوایم یه aggregation روی دیتاها انجام بدیم مثلن جمع سن افراد رو حساب کنیم کامپیوتر فقط به یکی از دیسک ها نیاز داره (دیسک ۳) دیتایی که توی مموری لود میشه کمتره و به حداقل تعداد دیسک نیاز پیدا میکنیم در نتیجه سرعت کلی محاسبات هم افزایش پیدا میکنه.
البته موارد دیگه ای هم هست که میشه دیتابیس های سطری و ستونی رو با هم مقایسه کرد ولی تو این نوشته بهشون نمیپردازیم.
حالا با این اوصاف کدوم دیتابیس رو برای پروژه مون انتخاب کنیم؟ سطری بهتره یا ستونی ؟
نمیشه گفت کدوم بهتره. استفاده از هرکدوم یه trade-off داره. با توجه به نیازمندی پروژه باید دیتابیس مناسب رو انتخاب کنیم. حتی گاهی ممکنه نیاز به بیش از یک نوع دیتابیس داشته باشیم. اینکه برای همه ی پروژه هامون یه مدل دیتابیس انتخاب کنیم جوابگو نیست. مثلن وقتی شما بخواید دیتا در سطح ترابایت آنالیز کنید و کويری هایی داشته باشید که روی هزاران سطر از دیتا اجرا میشن دیتابیس های ستونی میتونن حتی تا صد برابر سرعت بالاتری نسبت به دیتابیس های سطری داشته باشند. پس نیازمندی پروژه هست که به ما میگه چه دیتابیسی انتخاب کنیم.
یه نکته ی پایانی هم راجع به دیتابیس های ستونی بگم. ما تو پروژه فعلیمون با تایم سری های سر و کار داریم و برای بخشی از کار دیتابیس کلیک هاوس رو انتخاب کردیم که یه دیتابیس ستونی هستش. همونطور که گفتیم دیتابیس های ستونی در زمینه ی write و update سرعت پایین‌تری نسبت به سطری ها دارند، با این حال دیتابیس های ستونی برای دیتاهایی که به صورت time-series هستند انتخاب مناسبیه. اگر بخوایم یه جایی وسط تاریخ هایی که داریم دیتا اضافه کنیم (که تو تایم سری ها به ندرت پیش میاد) توی دیتابیس های سطری که قاعدتاً چالش خاصی نداریم ولی تو دیتابیس ستونی تقریباً باید روی همه ی دیتا بگردیم تا بتونیم چنین کاری بکنیم. ولی خب وقتی با تایم سری ها سر و کار داریم در اغلب موارد دیتای جدید به انتهای جدول اضافه میشند و با این مشکل رو به رو نمیشیم.
امیدوارم این مطلب براتون مفید بوده باشه.
