https://virgool.io/feed/@saeedeh.ghoshooni back-end developer fa 2026-06-19 12:16:12 https://files.virgool.io/upload/users/55786/avatar/Tet9OV.png?height=120&width=120 https://virgool.io/@saeedeh.ghoshooni https://virgool.io/@saeedeh.ghoshooni/%D8%AF%DB%8C%D8%AA%D8%A7%D8%A8%DB%8C%D8%B3-%D9%87%D8%A7%DB%8C-%D8%B3%D8%B7%D8%B1%DB%8C-%DB%8C%D8%A7-%D8%B3%D8%AA%D9%88%D9%86%DB%8C-thkqxbd3twdr دو مدل از پرکاربردترین دیتابیس ها دیتابیس های سطری (row oriented) و دیتابیس های ستونی (column oriented, columnor or C-store) هستند. هدف ما اینجا اینه که بین این دو مدل دیتابیس مقایسه انجام بدیم.دیتابیس های سطری دیتا رو رکورد به رکورد سازماندهی میکنند یعنی دیتاهای هر رکورد رو پشت هم دیگه ذخیره میکنند. دیتابیس های سطری روش قدیمی نگهداری و سازمندهی دیتا هستند و یه سری مزیت دارند که باعث میشه هنوز هم برای ذخیره سازی سریع دیتا مورد استفاده قرار بگیرند. دوتا دیتابیس معروف سطری postgres, Mysqlدیتابیس های ستونی دیتابیس هایی هستند که دیتا رو با field سازمندهی میکنند یعنی همه ی دیتاهای مربوط به یه field رو پشت سر همدیگه ذخیره میکنند. این دیتابیس ها محبوبیت بیشتری پیدا کردند و برای کويری زدن روی دیتا مزایای خوبی دارند. برای خوندن و محاسبه روی ستون‌های دیتا بسیار بهینه هستند. از دیتابیس های معروف ستونی میتونیم Clickhouse, Redshift رو نام ببریم.درباره ی دیتابیس های سطری:همونطور که گفتیم این دیتابیس ها روش قدیمی نگهداری دیتا هستند. برای خوندن و نوشتن روی یک سطر از دیتا بهینه هستند که توی بعضی از معماری ها کاربرد داره و میتونه انتخاب خوبی باشه.توی دیتابیس های سطری همونطور که از اسمش هم مشخصه دیتا به صورت سطر به سطر نگهداری میشه به طوری که اولین ستون هر سطر دقیقن بعد از آخرین ستون سطر قبلی قرار میگیره !مثلن فکر کنید دیتای ما این شکلیهتو یه دیتابیس سطری این دیتاها روی دیسک به صورت زیر نگهداری میشن:‌این مدل ذخیره سازی باعث میشه نوشتن توی دیتابیس راحت باشه. چرا؟ چون تنها کاری که برای نوشتن سطر جدید باید انجام بشه این هست که دیتای جدید به انتهای دیتای قبلی اضافه بشهمثلن اگر ما بخوایم دیتای زیر رو اضافه کنیم:خیلی ساده به انتهای دیتای قبلی اضافه میشه و نتیجه میشه این:دیتابیس های سطری همچنان کاربرد خودشون رو دارند و تو اپلیکیشن های که نوشتن توی دیتابیس براشون حايز اهمیت هست استفاده میشند. با این حال یه مورد دیگه استفاده از دیتابیس ها این هست که بتونیم دیتای ذخیره شده توی اونها رو آنالیز کنیم اینجا همون جایی که دیتابیس های سطری کندتر از دیتابیس های ستونی عمل میکنند.دیتابیس های سطری برای بازیابی یه سطر یه یه مجموعه از سطرها خوب عمل میکنند ولی وقتی بخوایم aggregation انجام بدیم دیتای اضافی توی مموری لود میکنند.مثلن فرض کنید میخوایم برای لیستی که بالا داشتیم مجموع سن افراد رو حساب کنیم. برای اینکه اینکار رو انجام بدیم باید همه ی نه تیکه ی دیتا توی مموری لود بشن بعد دیتای مورد نیاز از توشون جدا بشه تا بتونیم اونا رو با هم جمع بزنیم.به علاوه با این شرایط تعداد دیسک هایی که ممکنه دیتابیس سطری بهش دسترسی پیدا کنه هم معمولاً بیشتره. مثلن فرض کنید که یه دیسک فقط میتونه به تعدادی بایت داشته باشه که سه تا ستون رو توی خودش ذخیره کنه شبیه شکل پایین:حالا اگر بخوایم مجموع سن ها رو حساب کنیم کامپیوتر باید بین هر سه تا دیسک و روی همه ی ستون‌ها بگرده تا بتونه دیتای مورد نیاز رو پیدا کنه و عملیات جمع رو انجام بده.بنابراین همونطور که دیدیم اگر بخوایم به دیتابیس های سطری دیتایی اضافه کنیم این کار سریع و ساده انجام میشه اما اگر بخوایم روی اون دیتا aggregation انجام بدیم هم مموری بیشتری استفاده میکنه و هم ممکنه نیاز به دسترسی به چندتا دیسک داشته باشهدرباره ی دیتابیس های ستونی:ما روی دیتاهایی که جمع‌آوری کردیم آنالیز هم انجام میدیم این نوع از دیتابیس ها تو خوندن دیتا بهینه هستند. توی دیتابیس های ستونی دیتا به گونه‌ای نگهداری میشه که هر سطر از یه ستون دقیقن بعد از سطر قبلی همون ستون میاد.مثلن همون دیتای که راجع به اسم، شهر و سن افراد داشتیم رو در نظر بگیرید. توی دیتابیس های ستونی دیتا اینجوری ذخیره میشه:اگر بخوایم یه رکورد جدید به دیتابیس اضافه کنیم تغییرات به صورت زیر میشه:‌اگر دیتا روی فقط یدونه دیسک ذخیره شده باشه، لود مموری موقع خوندن دیتا با دیتابیس سطری تفاوتی نداره چون به هر حال باید همه چی رو توی مموری لود کنه و دیتای مورد نظر رو ازش استخراج کنه. ولی اگر دیتا روی چندتا دیسک ذخیره شده باشه اینجاست که دیتابیس ستونی بهینه بودن خودش رو نشون میدهمثلن حالت زیر رو در نظر بگیریدبرای اینکه بخوایم یه aggregation روی دیتاها انجام بدیم مثلن جمع سن افراد رو حساب کنیم کامپیوتر فقط به یکی از دیسک ها نیاز داره (دیسک ۳) دیتایی که توی مموری لود میشه کمتره و به حداقل تعداد دیسک نیاز پیدا میکنیم در نتیجه سرعت کلی محاسبات هم افزایش پیدا میکنه.البته موارد دیگه ای هم هست که میشه دیتابیس های سطری و ستونی رو با هم مقایسه کرد ولی تو این نوشته بهشون نمیپردازیم.جمع بندی حالا با این اوصاف کدوم دیتابیس رو برای پروژه مون انتخاب کنیم؟ سطری بهتره یا ستونی ؟نمیشه گفت کدوم بهتره. استفاده از هرکدوم یه trade-off داره. با توجه به نیازمندی پروژه باید دیتابیس مناسب رو انتخاب کنیم. حتی گاهی ممکنه نیاز به بیش از یک نوع دیتابیس داشته باشیم. اینکه برای همه ی پروژه هامون یه مدل دیتابیس انتخاب کنیم جوابگو نیست. مثلن وقتی شما بخواید دیتا در سطح ترابایت آنالیز کنید و کويری هایی داشته باشید که روی هزاران سطر از دیتا اجرا میشن دیتابیس های ستونی میتونن حتی تا صد برابر سرعت بالاتری نسبت به دیتابیس های سطری داشته باشند. پس نیازمندی پروژه هست که به ما میگه چه دیتابیسی انتخاب کنیم.یه نکته ی پایانی هم راجع به دیتابیس های ستونی بگم. ما تو پروژه فعلیمون با تایم سری های سر و کار داریم و برای بخشی از کار دیتابیس کلیک هاوس رو انتخاب کردیم که یه دیتابیس ستونی هستش. همونطور که گفتیم دیتابیس های ستونی در زمینه ی write و update سرعت پایین‌تری نسبت به سطری ها دارند، با این حال دیتابیس های ستونی برای دیتاهایی که به صورت time-series هستند انتخاب مناسبیه. اگر بخوایم یه جایی وسط تاریخ هایی که داریم دیتا اضافه کنیم (که تو تایم سری ها به ندرت پیش میاد) توی دیتابیس های سطری که قاعدتاً چالش خاصی نداریم ولی تو دیتابیس ستونی تقریباً باید روی همه ی دیتا بگردیم تا بتونیم چنین کاری بکنیم. ولی خب وقتی با تایم سری ها سر و کار داریم در اغلب موارد دیتای جدید به انتهای جدول اضافه میشند و با این مشکل رو به رو نمیشیم.امیدوارم این مطلب براتون مفید بوده باشه. سعیده قشونی سعیده قشونی Sat, 20 Feb 2021 20:36:38 +0330 https://virgool.io/@saeedeh.ghoshooni/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-apache-kafka-he80vk2fqzbm این روزا به خاطر پروژه ای که درگیرش هستیم حسابی مشغول خوندن داکیومنت های مختلف برای stream processing بودم در نهایت تیم ما تصمیم گرفت از آپاچی کافکا استفاده کنه. اینجا تصمیم دارم یه خلاصه‌ای از اون رو با شما هم به اشتراک بذارم.کافکا چیه ؟ به زبون ساده کافکا یه سیستم پیام رسانی و کاربرد اصلیش هم توی این مدل سیستم هاست ولی چون زمان پاسخگویی خیلی خوبی داره تو سیستم‌های stream processing هم استفاده میشه که هدف اصلی تیم ما بود.وظیفه ی یه سیستم پیام رسانی این هست که دیتا رو از یه اپلیکیشن به یه اپلیکیشن دیگه انتقال بده بنابراین اپلیکیشن ها میتونن روی دیتا تمرکز کنند نه شیوه ی به اشتراک گذاشتن اون.دو مدل برای انتقال پیام وجود داره یکی نقطه به نقطه یا همون point to point و دیگری مدل انتشار اشتراک یا همون publish-subscribe که به اختصار بهش pub-sub گفته میشه.کافکا هر دو مدل رو ساپورت میکنه برای همین یه توضیح مختصری راجع به اونها میدیم.مدل point to point:توی این سیستم پیام ها تو یه صف هستند. یک یا تعداد بیشتری consumer میتونن مسیج های توی صف رو مصرف کنند ولی یه پیام خاص فقط میتونه توسط یکی از consumerها مصرف بشه. به محض اینکه consumer پیامی رو از توی صف میخونه اون پیام از صف حذف میشه.یه مثال رایج اگر بخوایم از این مدل بزنیم میشه به سیستمی که سفارش‌ها رو پردازش میکنه اشاره کرد که تو اون هر سفارش ای توسط یه دونه پردازش کننده، پردازش میشه در عین حال چن تا پردازش کننده میتونن به طور همزمان کار کنند.شکل پایین ساختار این مدل رو نشون میده:مدل pub-sub:توی این مدل پیام ها تو یه تاپیک هستند. برخلاف مدل نقطه به نقطه مصرف کننده ها یا همون consumerها میتونن تو یدونه یا تعداد بیشتری تاپیک subscribe کنند و همه ی مسیج های توی اون تایپک رو مصرف کنند. توی این سیستم به message producer میگیم publisher و به message consumer میگیم subscriber. یه مثال خوبش میشه دیش TV که کانال‌های مختلفی مثل فیلم و موزیک و ورزش و … publish میکنه و هرکس میتونه تو مجموعه کانال‌های خودش subscribe کنه و هر زمان که اون کانال‌های subscribed شده در دسترس باشند اونها رو دریافت کنه.شکل پایین ساختار این مدل رو نشون میده حالا بر اساس این چیزایی که گفتیم میتونیم تعریف دقیق‌تری از کافکا ارائه بدیم. کافکا یه سیستم انتقال پیام توزیع شده بر اساس مدل pub-sub هستش که میتونه حجم زیادی از دیتا رو مدیریت کنه و این امکان رو به شما بده که بتونید پیام‌ها رو از یه نقطه به یه نقطه ی دیگه ارسال کنید. همچنین کافکا یه پلت فرم یکپارچه است که قابلیت پاسخ‌گویی در لحظه یا همون real-time رو داره تو رسوندن پیام کمترین تأخیر رو ساپورت میکنه و به شما گارانتی میده که در صورتی که machine failure اتفاق بیفته به خوبی قابلیت تحمل خطا رو داره. کافکا بسیار سریعه و میتونه حدود دو میلیون write در ثانیه انجام بده. علاوه بر این‌ها کافکا دیتا رو روی دیسک نگه میداره که همین باعث میشه بتونه data loss رو مدیریت کنه.قبل از اینکه بخوایم توی کافکا عمیق بشیم بهتره با اصطلاحات اصلی که توی کافکا به کار میرن آشنا بشیم.شکل پایین یه تصویر کلی از کافکا بهمون میدهTopics:به جریانی از داده‌ها که به دسته بندی خاصی متعلق هستند گفته میشه. برای مثال تاپیک میتونه معادل یه جدول تو دیتابیس باشه یا هر دسته بندی دیگه ای. داده‌ها توی تاپیک ها نگهداری میشه و تاپیک ها هم خودشون به پارتیشن ها تقسیم میشن. کافکا برای هر تاپیک حداقل یه پارتیشن نگه میداره. هرکدوم از این پارتیشن ها شامل پیام هایی میشن که این پیام‌ها دنباله ای هستند که ترتیب دارند و این ترتیبشون غیرقابل تغییره.Partitions:تاپیک ها پارتیشن های زیادی دارند بنابراین اونا میتونن حجم دلخواهی از داده رو مدیریت کنن.Partition offset:همونطور که گفتیم پیام‌ها توی تاپیک ها نگهداری میشن که اونها هم از پارتیشن ها تشکیل شدند. هر پیامی که پارتیشن میشه تو دنباله ی پیام‌ها آیدی یکتایی داره که بهش offset گفته میشه.Replicas of a partition:اون ها چیزی نیستند جز backup یه پارتیشن. Replica ها هیچ وقت دیتا نمیخونن و نمینویسن. برای جلوگیری از، از دست رفتن داده ازش استفاده میشه.Brokers:بروکرها سیستم‌های ساده‌ای هستند که وظیفه ی اونها نگهداری داده‌های publish شده س. هر broker ممکنه صفر یا تعداد بیشتری پارتیشن به ازای هر تاپیک داشته باشه.فرض کنید اگر n تا پارتیشن تو یه تاپیک باشه و n تعداد بروکر داشته باشیم هر بروکر یه پارتیشن خواهد داشت.اگر n تا پارتیشن تو یه تاپیک باشه و بیشتر از nتا broker داشته باشیم (n+m) در این صورت nتا broker اول یدونه پارتیشن دارند و m تای بعدی برای این تاپیک خاص هیچ پارتیشنی ندارند.اگر n تا پارتیشن تو یه تاپیک داشته باشیم و کمتر از n تا بروکر (n-m) در این صورت هر broker یک یا تعداد بیشتری پارتیشن داره که بین broker ها به اشتراک گذاشته شده . این سناریو به دلیل اینکه توزیع بار بین broker ها نامساوی هست پیشنهاد نمیشه.Kafka cluster:کافکا ای که بیشتر از یدونه broker داشته باشه کافکا cluster نامیده میشه. . یه کافکا cluster میتونه به راحتی و بدون اینکه نیاز باشه از کار بندازیمش بسط پیدا کنه . کلاستر از brokerهاش برای بالانس کردن بار استفاده میکنه. بروکرهای کافکا state رو نگه نمیدارن. یه بروکر کافکا میتونه صدها هزار read , write در ثانیه رو مدیریت کنه و هر بروکر میتونه مسیج هایی در سطح ترابایت رو مدیریت کنه بدون اینکه روی کارایی تأثیری بذاره.Producers :کار producerها اینه که پیام‌ها رو به یک یا تعداد بیشتری تاپیک کافکا انتشار بدن. اونها دیتا رو به broker ها ارسال می کنند. هر بار که یه producer میاد پیامی رو به یه بروکر منتشر میکنه، بروکر اون پیام رو به آخرین بخش فایل اضافه میکنه. Producer ها همچنین میتونن پیام‌ها رو به پارتیشنی به انتخاب خودشون ارسال کنند. هر موقه یه بروکر جدید استارت بشه همه ی producerها اون رو سرچ میکنند و به طور اتوماتیک مسیجی رو به بروکر جدید ارسال میکنند. producerهای کافکا اینطوری نیستند که منتظر acknowledgment از طرف بروکر بمونن و به همون سرعتی که بروکر بتونه مدیریت کنه پیام ها رو ارسال میکنند.Consumers:اونها دیتا رو از brokerها میخونن. Consumer ها توی یک یا تعداد بیشتری تاپیک subscribe میکنند و مسیج های منتشر شده رو از broker ها میگیرن و اونها رو استفاده می کنند. همونطور که گفتیم بروکرهای کافکا state رو نگه نمیدارن consumer باید اینکه چه تعدادی از مسیج ها مصرف شدند رو نگه داره و این کار رو با استفاده از پارتیشن offset انجام میده. اگر consumer یه مسیج خاص رو ack کنه به این معنی هستش که consumer همه ی مسیج های قبلی رو استفاده کرده.Leader:برای یه پارتیشن مشخص leader میشه node ای که مسئولیت همه ی readها و write ها رو داره. هر پارتیشن یه سرور داره که براش به عنوان leader عمل میکنه.Follower:گره یا همون node ای که دستورالعمل های leader رو فالو میکنه بهش میگیم follower. اگر leader به هر دلیلی fail بشه یکی از فالوور ها به طور اتوماتیک leader میشه. یه follower مثل یه consumer نرمال عمل میکنه یعنی مسیج ها رو میگیره و داده‌های خودش رو آپدیت میکنه.شکل پایین یه کافکا کلاستر رو نشون میده:همینطور که توی شکل هم مشخصه کلاستر کافکا یه بخشی هم به اسم Zookeeper داره.Zookeeper به بیان ساده یه سرویس توزیع شده برای کانفیگ کردن و همزمان سازیه. Zookeeper برای مدیریت و تنظیم کردن کافکا بروکر به کار میره. یه رابط بین بروکرهای و consumers هاست. سرویس Zookeeper اساساً برای این به کار میره که به producer و consumer درباره ی حضور یه برورکر جدید در سیستم کافکا یا fail شدن یه بروکر تو سیستم کافکا خبر بده. وقتی Zookeeper در باره ی حضور یا fail شدن یه بروکر تو سیستم کافکا خبر میده producer و consumer تصمیم میگیرن و شروع میکنند به تنظیم کردن تسک هاشون با یه بروکر دیگه. همچنین انتخاب کافکا بروکری که leader میشه توسط Zookeeper انجام میشه.با توجه به این توضیح ها حالا میتونیم یه مقدار تو کافکا عمیق‌تر بشیم.کافکا هم میتونه مدل pub-sub رو فراهم کنه و هم مدل queue . تو هر دوتاش کافکا ویژگی‌های زیر رو داره:- fast- reliable- persisted-fault tolerance- zero downtimeتوی هر دو حالت producer ها پیام رو به تاپیک ارسال میکنند و consumer میتونه هر کدوم از این سیستم ها رو بر اساس نیاز خودش انتخاب کنه. الان ما مرحله به مرحله میخوایم بررسی کنیم چه‌جوری consumer میتونه به انتخاب خودش مسیجینگ سیستم رو انتخاب کنه !توی هر دو حالت producer ها پیام رو به تاپیک ارسال میکنند و consumer میتونه هر کدوم از این سیستم ها رو بر اساس نیاز خودش انتخاب کنه. الان ما مرحله به مرحله میخوایم بررسی کنیم چه‌جوری consumer میتونه به انتخاب خودش مسیجینگ سیستم رو انتخاب کنه !Work flow of pub-sub messaging:- تو بازه های منظم producer ها به تاپیک پیام ارسال میکنند- کافکا بروکر میاد همه ی پیام ها رو توی پارتیشن هایی که برای اون تاپیک خاص کانفیگ شدند ذخیره میکنه. بروکر مطمن میشه که پیام‌ها به طور مساوی بین پارتیشن ها به اشتراک گذاشته بشند. اگر producer دو تا پیام ارسال کنه و دو تا پارتیشن هم داشته باشیم کافکا یکی از پیام‌ها رو توی پارتیشن اول و پیام دیگه رو توی پارتیشن دوم ذخیره میکنه.- کانسیومر تو یه تاپیک خاص subscribe میکنه- به محض اینکه consumer تو یه تاپیک subscribe میکنه کافکا میاد offset فعلی اون تاپیک رو به consumer میده و همچنین اون offset رو توی Zookeeper هم ذخیره میکنه.-consumer میاد تو بازه های منظم برای مثال هر ۱۰۰ میلی ثانیه یه بار به کافکا ریکوئست میزنه تا پیام‌های جدید رو بگیره- به محض اینکه کافکا پیام‌ها رو از producerهادریافت میکنه اونها رو به consumerها forward میکنه.- کانسیومر پیام رو دریافت و پردازش میکنه- به محض اینکه پیام‌ها پردازش شدند consumer میاد به بروکر کافکا یه ack میفرسته- به محض اینکه کافکا یه ack دریافت کنه میاد offset رو به مقدار جدید تغییر میده و توی Zookeeper هم اون رو آپدیت میکنه. چونکه offset ها توی Zookeeper نگهداری میشن consumer میتونه حتی اگر سرور به مشکل بخوره هم پیام بعدی رو درست بخونه- مراحل بالا تا زمانی که consumer ریکوئست زدن رو متوقف کنه ادامه پیدا میکنند- کانسیومر این آپشن رو داره که یه offset از یه تاپیک رو در هر زمانی rewind/skip کنه و همه ی پیام های متعاقب (بعدی) رو بخونه.Workflow of queue messaging / consumer group :توی این سیستم به جای یدونه consumer یه گروه از consumerها که group id یکسانی دارند تو یه تاپیک subscribe میکنند. به زبون ساده اگر بخوایم بگیم consumer هایی که تو یه تاپیک subscribe میکنند و group id یکسانی دارند یه گروه در نظر گرفته میشند و مسیج ها بین اونها به اشتراک گذاشته میشن- تو بازه های منظم producer پیام رو به تاپیک میفرسته- کافکا همه ی مسیج ها رو تو ی پارتیشن هایی که برای اون تاپیک خاص کانفیگ شده ذخیره میکنه- یدونه consumer تو یه تاپیک خاص subscribe میکنه برای مثال topic-01 و group id رو هم Group-1 در نظر میگیریم.- کافکا با این consumer به همون شیوه ی pub-sub messaging تعامل میکنه. تا وقتی که consumer جدیدی توی همون تاپیک subscribe کنه یعنی توی topic-01 و با همون group آیدی Group-1- به محض اینکه این consumer جدید میرسه کافکا به share mode سوییچ میکنه و دیتا رو بین دو consumer به اشتراک میذاره. این به اشتراک گذاری تا زمانی که تعداد consumer ها به تعداد پارتیشن هایی که برای اون تاپیک خاص کانفیگ شده برسه ادامه پیدا میکنه- به محض اینکه تعداد consumer ها از تعداد پارتیشن ها بیشتر بشه consumer جدید هیچ پیام دیگری دریافت نمیکند تا زمانی که یکی از consumer های موجود unsubscribe کنه. این سناریو به این دلیل هست که توی کافکا هر consumer حداقل به یه پارتیشن اختصاص داده میشه و به محض اینکه همه ی پارتیشن ها به consumer های موجود اختصاص داده بشن consumer جدید باید در انتظار بمونه- به این ویژگی consumer group هم گفته میشه. کافکا از این دو تا سیستم بهترینشون رو به شیوه ای ساده و کارآمد ارائه میده.از اینجا به بعد کار دیگه ساده ست. شما باید کافکا و نیازمندی هاش مثل Zookeeper رو روی سیستمتون نصب کنید و بر اساس نیازتون ازش استفاده کنید.امیدوارم این مطلب براتون مفید بوده باشه.منابع: https://kafka.apache.orghttps://www.tutorialspoint.com/apache_kafka/index.htm سعیده قشونی سعیده قشونی Tue, 21 Jul 2020 14:14:38 +0430