<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های حسین بیگی</title>
        <link>https://virgool.io/feed/@husseinbeygi</link>
        <description></description>
        <language>fa</language>
        <pubDate>2026-04-15 06:03:18</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/1602834/avatar/thIjWO.jpeg?height=120&amp;width=120</url>
            <title>حسین بیگی</title>
            <link>https://virgool.io/@husseinbeygi</link>
        </image>

                    <item>
                <title>حکایت شیخ و مریدان : SystemDesign قسمت سوم</title>
                <link>https://virgool.io/@husseinbeygi/%D8%AD%DA%A9%D8%A7%DB%8C%D8%AA-%D8%B4%DB%8C%D8%AE-%D9%88-%D9%85%D8%B1%DB%8C%D8%AF%D8%A7%D9%86-systemdesign-%D9%82%D8%B3%D9%85%D8%AA-%D8%B3%D9%88%D9%85-l3opfm5lpsdf</link>
                <description>روزی مریدان آماده بودند برای رفتن به اردو که همگی مطمئن بودند که شیخ حتما یک ضد حالی به مریدان خواهد زد از این رو خود را آماده کرده بودند.بعد از بازی محبوب آن دوران یعنی تیله بازی شیخ مریدان را جمع کرد تا برود روی منبر.مریدی پرسید یا شیخ موضوع بحث امروز چیست؟شیخ گفت : LoadBalancer ای مرید!میپرسی چیست ؟ (مرید زیر لب گفت: نه والا! کی پرسید؟)در حقیقت Load Balancer ترافیک ورودی را بین سرور هایی که به وی گفته شده، عادلانه تقسیم میکند.عکس زیر را بنگریددر عکس بالا کاربران به یک IP عمومی، مستقیم متصل میشوند. با این کار دیگر کاربر ها نمیتوانند با سرور ها متصل شوند. برای امنیت بیشتر Ip  های سرور ها را نیز Private میکنیم که دیگر نور علی نور شود و این IP ها فقط برای اتصال سرور ها به یکدیگر استفاده میشوند این یعنی دیگر از طریق اینترنت(البته صیانت نشده منظورم است) دیگر نمیتوان به سرور ها متصل شد و Loadbalancer ما از راه IP های Private به سرور ها وصل میشود.در عکس بالا، بعد ازاینکه سرور دوم و LoadBalancer اضافه شد ما موفق شدیم که مشکل no failover را حل کنیم و با این کار میزان آماده به کاری سرور ها را بالاتر بردیم. بگذار با جزئیات بیشتری بگویم:·        اگر سرور 1 به یغما برود، تمام ترافیک ها به سرور 2 ارسال میشود، این باعث میشود که سایت نیز همراه سرور اول به یغما نرود و خب مانیز یک سرور سالم و دست و پا نشکسته را اضافه میکنیم که ترافیک پخش شود.·        اگر ترافیک در سرور های ما افزایش پیدا کند (مثلا در سیستم ناد هنگام انتخاب واحد) ما سرور های بیشتری اضافه میکنم و LoadBalancer ها به طور اتومات ترافیک ها را پخش میکنند. تا دانشجوی بدبخت موهایش از استرس نریزد.آنچه در قسمت بعد خواهید خواند :حال که لایه های سرور ما اوضاعش میزان شده، برای دیتابیس های ما چطور؟؟اگر یک دیتابیس به کما رفت چه؟؟؟</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Sat, 02 Jul 2022 00:13:34 +0430</pubDate>
            </item>
                    <item>
                <title>حکایت شیخ و مریدان : SystemDesign قسمت دوم</title>
                <link>https://virgool.io/@husseinbeygi/%D8%AD%DA%A9%D8%A7%DB%8C%D8%AA-%D8%B4%DB%8C%D8%AE-%D9%88-%D9%85%D8%B1%DB%8C%D8%AF%D8%A7%D9%86-systemdesign-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-fx4djpn0g6ga</link>
                <description>حکایت شیخ و مریدان : SystemDesign قسمت دوم
در همین حین که مریدان آماده زنگ ورزش بودند که به مانند آهویی لگد زنان استراحتی کنند که شیخ وارد شد و گفت : خایله خب، برم سراغ Vertical scaling vs Horizontal scalingمریدان که همگی شلوار آبی که کنارش سه خط سفید آدیداس بود که آن را هم روی شلوار لی پوشیده و منتظر زنگ ورزش بودند ، قفل کردند!شیخ ادامه داد : شما برای افزایش منابع سیستمتان دو راه دارید :1- Vertical scalingخب این یعنی ما برای سرور هایی که الان داریم منابع بیشتری در نظر بگیریم!یعنی اگر 5 تا سرور داریم، رم و CPU و... را افزایش دهیم. که به آن اصطلاحا Scale-up هم میگویند.2- Horizontal scalingاین یعنی تعداد سرور هایی که داریم را افزایش دهیم! که به آن اصطلاحا Scale-out هم میگویند.مریدی گفت : یا شیخ از کجا بفهمیم که کدامش برای ما لازم است؟؟؟شیخ گفت : اگر ترافیک سیستم کم است بروید سراغ Vertical scaling اصلا همین سادگی که دارد، واقعاااااا جذابش کرده. اما خب اگر سادگی دارد مطمئن باشید که محدودیت هم دارد مثلا:- افزایش هم حداکثری دارد شما که نمیتوانید نامحدود رم و CPU داشته باشید. میشود؟؟؟- نقطه ضعف این حالت این است Failover و redundancy خوبی ندارد، اگر سرور بره یغما برود، سایت به یغما رفته و این یعنی پول بی پول.و خب طبعا Horizontal scaling برای برنامه هایی که بزرگ هستند و نمیتوانند با محدودیت های Vertical scaling کنار بیایند، بهتر است.در قسمت قبل شروع به طراحی سیستمی کردیم، اگر سرور آفلاین شود دیگر کاربر بدبخت به سایت دسترسی ندارد، حال اگر تعداد زیادی کاربر به سرور متصل شوند و درخواست ها زیاد شود، سرور کند شده و گند میخورد به تجربه کاربری مثلا سایت انتخاب واحد دانشگاه ها(خدا لعنتت کنه ناد که پیرم کردی).دوای درد این مسئله Load Balancer  هستش.در زیر عکسی از روضه هایی که خواندم اوردم تا شاید پند بگیرید.  حالا بروید و بدرید و ورزش کنید که قسمت بعد همین است.</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Fri, 24 Jun 2022 22:20:24 +0430</pubDate>
            </item>
                    <item>
                <title>حکایت شیخ و مریدان : SystemDesign قسمت اول</title>
                <link>https://virgool.io/@husseinbeygi/%D8%AD%DA%A9%D8%A7%DB%8C%D8%AA-%D8%B4%DB%8C%D8%AE-%D9%88-%D9%85%D8%B1%DB%8C%D8%AF%D8%A7%D9%86-systemdesign-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-djrkxdu7nlxi</link>
                <description>خودم :  قبل از شروع بگم که این قسمت میشه 9 امین مقاله ای که نوشتم، و تصمیم گرفتم از این به بعد روی طراحی سیستم ها که خب علاقه خودمم هست بیشتر بخونم و بنویسم. از این به بعد یک سری مطالب به صورت دنباله نوشته میشن و از سطوح ساده تا پیشرفته ادامه داره.همچنین چون خیلی درگیر شدم شاید کمی تاخیر داشته باشه که از الان عذرخواهی میکنم.به هرحال دم اونایی که از اول این مطالب با من همراه بودن و خوندن و نظر دادن گرم!روزی شیخ به مکتب خانه آمد و کتابی در دستش داشت و رو به مریدان کرد و گفت: زین بعد مطالب را فقط برروی طراحی سیستم می گذاریم. مریدی پرسید: چرا؟ شیخ گفت : چون دلم میخواهد!همین. مریدان که همه کف کرده بودند گفتند : یا شیخ چند جلسه است؟ شیخ گفت : تا وقتی که دیگر حسش نباشد!حال بس است شروع کنیم.سپس شیخ بر منبر خود نشست وشروع کرد.در اولین مرحله باید یاد بگیریم که اصلا این سیستم هایی که طراحی میکنیم چه گونه قرار است کارکنند! و یک سری مطالب ابتدایی را مرور میکنیم. فعلا همه چیز را بروی یک سرور در نظر بگیرید!مشتری آدرس سرور شما را در مرورگرش میزند!یا با تلفن همراهش برنامه شما را باز میکند!در این مرحله درخواست مشتری شما یک سر میزند به DNS  و میگوید ای DNS این آدرس که دادن دست من به کدام مکان است؟ DNS نگاهی به آدرس میکند کمی بین رفقایش پچ پچ میکنند و بالاخره یکی از آن ها میگوید یافتم یافتم!و آدرس را برمیگرداند! موبایل که حال تازه فهمید که آدرس(IP) اصلی چه است با یک HTTP ریز درخواست ها را مستقیم میفرستد به سرور ما!چه جالب. حال سرور ما یا یک HTML برمیگرداند که مرورگر آنرا نشان دهد یا JSON – XML  و... برمیگرداند که برنامه ما زبانش را میفهمد. حال نکته جالب این است که اگر بخواهیم یا شرایط میزان درخواست ها به سرور زیاد شود میتوانیم سرور های API  که برای موبایل هست را از سرور های Web جدا کنیم که بتوانیم راحت برابر نیاز آنان را گسترش (scale) کنیم.از این رو مسئله ای که پیش می آید که یا برادر ما باید داده های مشتری را درجایی ذخیره کنیم یا نه؟؟؟؟برای اینکار از دیتابیس استفاده میکنم که کارش این است که گفتم (همه میدانیم چیست- بیشتر به صورت سرجهازی نوشتمش)در زیر عکس از روضه هایی که خواندم نمایش داده شده:مریدی پرسید : یا شیخ از کجا بدانیم چه دیتابیسی استفاده کنیم؟شیخ گفت شما میتوانید یا از دیتابیس های رابطه ای و یا غیر رابطه ای استفاده کنید. دیتابیس های رابطه ای را که به آن RDBMS نیز میگویند داده های شما را در جدول ها که دارای ردیف و ستون می­باشند ذخیره میکنند.محبوب ترین ها هم که SqlServer ، Oracle ،Mysql،PostgresSQL و... می­باشند.دیتابیس های غیر رابطه ای را که عموما NoSQL می­گویند در چهار دسته بندی قرار می­گیرند.Key-value , graph , column store , document store  که هرکدام روضه خود را میخواهد که جلوتر میگوییم.برای بیشتر کار های همان RDBMS ها زیاد هم هستند، چرا که 40 سال است که کار میکنند و بیشتر نیاز ها را برطرف میکنند. اما خب تا نباشد چیزکی مردم نسازند NoSql .اگر شما نیاز های زیر را داشتید نگاهی هم به غیر رابطه ای بیاندازید بد نیست :  1-نیاز وحشتناکی به latency پایین دارید2- داده های شما از ساختارش مشخص نیست! شلم شوربا میباشد.3-کارتان با خروجی های JSON – XML – YAML  اینا راه می افتد4-حجم داده های شما خیلی زیاد است!مریدان گفتند : یا شیخ خسته نباشی! تایم خشتک رسیده!  شیخ نگاهی به ساعت کرد و گفت : بدرید که باقیش باشد برای بعد.</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Fri, 17 Jun 2022 21:13:26 +0430</pubDate>
            </item>
                    <item>
                <title>مهندسی جالب دریافت ایموجی های Disney Hotstar</title>
                <link>https://virgool.io/@husseinbeygi/%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-%D8%AC%D8%A7%D9%84%D8%A8-%D8%AF%D8%B1%DB%8C%D8%A7%D9%81%D8%AA-%D8%A7%DB%8C%D9%85%D9%88%D8%AC%DB%8C-%D9%87%D8%A7%DB%8C-disney-hotstar-ilq6utjednht</link>
                <description>چجوری Disney Hotstar 5میلیارد ایموجی رو دریافت و پردازش میکنه.پستی دیدم از Alex Xu که ترجمش خالی از لطف نبود و میتونست یک تصویر از بالا در نحوه طراحی سیستم های بزرگ بهم بده:قبلش بگم اصلا برنامه چی بوده، ببینید دیزنی یک سرویسی داره که اجازه میده زمانی که شما داری یک مسابقه رو نگاه میکنی بتونی با ایموجی احساساتت رو ابراز کنی.حالا یک مطلب توی بلاگ مهندسی اینها نوشته شده که خلاصش رو توی پست Alex Xu دیدم!1.کلاینت های ما از راه HTTP ایموجی ها رو میفرستن به یک وب سرور GO که خب این زبان به خاطر توانایی هاش توی concurrency انتخاب شده.2.از اونجایی که میزان داده ها خیلی زیاده خب طبیعتا Kafka میاد وسط تا بتونه بافر مانند یک صفی از ایموجی ها رو داشته باشه.(خودم : این باعث میشه که کاربر هیچ وقت حس نکنه که ایموجیش ثبت نشده در حقیقت اگر سرویس ها شلوغ باشن کافکا این امر رو برعهده میگیره و به مرور زمان داده ها رو میده به سرویس ها !اینجوری از دید کاربر انگار ری اکشنش توی سیستم ثبت شده!)3.حالا این ایموجی ها توسط Spark که این امر هر دو ثانیه اتفاق می­افته که شاید بگیدد خب چرا کمتر نباشه خب در حقیقت برای کمتر کردن این زمان باید منابع سیستم ها افزایش پیدا کنه!دیگه باید بالانسش انتخاب بشه.4.خب دوباره این داده هایی که پردازش شدن ریخته میشن توی یک کافکا دیگه!5.حالا سرویس های PubSub ایموجی ها از کافکا می­گیرن!6.اون سرویس های PubSub ایموجی ها رو به کلاینت های دیگه می فرستن!7.زیر ساخت های PubSub استفاده شده هم جالبن!اومدن از پرتکل های Socketio, NATS, MQTT, and gRPC, and settled with MQTT استفاده کردن.(اگه علاقمند هستید توی کامنت ها منابع رو گذاشتم)نکته جالب این که تقریبا همین روش رو لینکدین برای هندل لایک هاش استفاده میکنه.Sources:[1] Capturing A Billion Emo(j)i-ons: https://lnkd.in/e24qZK2s[2] Building Pubsub for 50M concurrent socket connections: https://lnkd.in/eKHqFeef[3] Streaming a Million Likes/Second: Real-Time Interactions on Live Video: https://lnkd.in/eUthHjv4</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Tue, 14 Jun 2022 22:39:15 +0430</pubDate>
            </item>
                    <item>
                <title>حکایت شیخ و مریدان : Idempotency</title>
                <link>https://virgool.io/@husseinbeygi/%D8%AD%DA%A9%D8%A7%DB%8C%D8%AA-%D8%B4%DB%8C%D8%AE-%D9%88-%D9%85%D8%B1%DB%8C%D8%AF%D8%A7%D9%86-idempotency-t4vg5tson9qw</link>
                <description>روزی شیخ خندان در کنار جوی آب نشسته بود و گذر عمر میدید که مریدی بر وی نازل شد و گفت : یا شیخ اگر چیز خنده داری هم هست، بگو ماهم بخندیم(انتقامش را از شیخ گرفت!)شیخ نگاهی به وی کرد و گفت : آری، هست! بشین تا برایت بگویم!مرید که تازه فهمیده بود که یک منبر رفته در پاچه اش! نشست و گفت : بگو یا شیخ.....شیخ گفت : در مهندسی نرم‌افزار مخصوصا زمانی که داری API را طراحی میکنی، مبحثی وجود دارد با نام Idempotency بگو خب...مرید گفت : خب! این که میگویی چیست!!!!!شیخ ادامه داد : این در علم کامپیوتر و ریاضیات یعنی عملی را بدون هیچ تغییری تکرار کنی و دقیقا همان نتیجه را بگیری! یا اینجوری بگم هر چند بار که یک درخواست را به سرور فرستادی، هیچ عوارض جانبی برای سرور بدبخت نداشته باشد!!!!مرید پرید و گفت : گرفتی مارو؟؟؟ مگر میشود جز این؟؟؟شیخ گفت : گوش کن یره!جنومرگ!!!بگذار مثالی بزنم : فکر کن کاربر یک عملیات POST انجام میده بعدش حالا به هر دلیلی TimeOut اتفاق می افته!الان چی شد؟ عملیات انجام شد؟ نشد؟ شد جوابش نیومده؟ نشده و جوابی نداره؟ شد شد نشد نشد ولش کن؟؟؟؟ الان دوباره درخواست ارسال کنه؟؟ نکنه ؟ اگه رفرش کنه بعد دوبار توی دیتابیس ذخیره بشه چی؟؟ (مثل سند های حسابداری که میتونه حساب ها رو بهم بزنه)! چه بدبختیه! نه؟؟؟؟؟خب جواب این در اینه که API ها Idempotent باشن!مرید گفت : وَع!(نماد تعجب مرید!) خب چرا پیش فرض همشون Idempotent نیستند؟؟دردسر درست کردن هااا.شیخ گفت : بدان و اگاه باش که متد های OPTIONS, GET, HEAD, PUT, DELETE  پیش فرض Idempotent هستند! اما متد های POST  و PATCH  به صورت پیش فرض Idempotent نیستند!(آره.PUT  پیش فرض Idempotent هستش!!!) حالا چرا این دوتا نیستند؟؟؟ چون این دوتا ذاتا قراره یک وضعیتی رو توی سرور تغییر بدن! خب اگه Idempotent باشن که نمیتونن کارشونو درست انجام بدن!مرید پرسید: یا شیخ چگونه از این باگ خلقت فرار کنیم؟؟؟؟شیخ گفت : چند راه داری!البته یادت باشد همیشه به اندازه انسان های روی زمین راه های رسیدن به خدا هست!(مارمولک)اولین راه : سعی کنی یکی از Property هایی که به سمت سرور میفرستی را دستی کنی و در زمانی که درخواستی اومد ریز یک کوئری بزنی دیتابیس ببینی هست یا نه! مثلا (شماره سند یا شماره پرداخت و....)دومین راه : مثل خفن ها دیتا را (مثلا Json) را هش کنی ! آن طرف چک کنی که آیا این هش قبلا به اینجا سرزده یا نه(البته این راه برای عملیات هایی که می خواهید حتما از صحت داده هم اطمینان حاصل کنید، پیشنهاد میشود کلا برکات زیادی دارد، بسته به خلاقیت شما!)سومین راه : در هدر های خود یک هدر جدید مثلا(IdemCode) بگذارید بعدش ریز یک Middleware اون وسط های بگذارید تا چک کند که اوضاع در چه حال است!برای این میتوانید یک Expire  بگذارید تا دردسر حجم داده ایجاد نشود!مرید گفت : این همه روضه چه ربطی داشت به خنده؟؟؟؟شیخ گفت : دوستی این روضه ها را پیاده نکرده و حالا به مانند آهویی که در جنگل گم شده، میماند! داشتم به وی میخندیدم!مرید به صورت مارادونایی خشتکش درید و با زاویه به ده رفت تا مریدان دیگر را از این برکت بک اند آگاه کند!</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Sat, 11 Jun 2022 19:51:15 +0430</pubDate>
            </item>
                    <item>
                <title>حکایت شیخ و مریدان : اصول پایه طراحی API</title>
                <link>https://virgool.io/@husseinbeygi/%D8%AD%DA%A9%D8%A7%DB%8C%D8%AA-%D8%B4%DB%8C%D8%AE-%D9%88-%D9%85%D8%B1%DB%8C%D8%AF%D8%A7%D9%86-%D8%A7%D8%B5%D9%88%D9%84-%D9%BE%D8%A7%DB%8C%D9%87-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-api-vxwhabiy59ei</link>
                <description>روزی شیخ با ناراحتی تمام بر مکتب خانه آمد و گفت : چه خبرررتونه؟؟ چه خبرتونه؟؟؟؟؟؟مریدان همه قفل کردند و یکی به آرامی گفت : یا شیخ چرا آمپر چسباندی!!!؟؟؟شیخ گفت: امروز برای مشاوره به استارت آپی رفته بودم!API طراحی کرده بودند که افتضاح بودن را به لول جدیدی رسانده بود.بنشینید که بروم روی منبر که خدای ناکرده شما از این اشتباهات بچه گانه نکنید.البته بگویم طراحی یک API خودش یک درس 5 واحدی میباشد!این چیز هایی که گویم در حداصول اولیه است!1-     کمی ثبات داشته باشید!رنگ و وارنگ آدرس گذاری نکنید. یک مدل را در پیش گرفته و مطابق همان پترن ادامه بدهید.در نام گذاری ها یک قانون را درپیش گرفته مانند snake_caseیا تمام نام ها جمع باشد یا تمام نام ها مفرد ! هرکس هرچی تو حالش بود.نباشد! یا GET /users و یا GET /userحواستان به مسائل authentication و authorization باشداز http-headerها استفاده کنید!کنتور نمی اندازد به مولا!از http-status-code ها استفاده کنید ( مورد داشتیم همه را 200 بر میگردانده و فقط پیام آن فرق میکرده)از methods ها درست استفاده کنید نه اینکه RESTful بنویسید اما DELETE ها همهGET باشد!2-     تمام api ها باید محافظت شده باشند و تعدادی public شوند نه اینکه همه public باشند و تعدادی محافظت بشن!3-     چه میکروسرویس و لودبالانسر دارید و چه ندارید حتما  /healthداشته باشید! کارش این است که حال واحوال API را گزارش میکند!4-     ورژن بزنید آقا!ورژن بزنید، بخدا شاخ نمیزند ! بلکه فردا روزی اگر API تغییر کرد! کلاینت بدبخت یکهو قفل نکند!مثل آدم کارش را بکند نهایت بهش تایم میدهید که آپدیت کند!5-     برای تاکید دوباره از HTTP status codes استفاده کنید.نه اینکه اینطور باشد که همیشه نتیجه OK باشد و شما فقط پیام را تغییر دهید!6-     از HTTP methods استفاده کنید! مورد داریم که با GET عمل DELETE را انجام میدهد!چه وضعشه!حال برای یاد آوری :a.        GET برای خواندن دادهb.       POST برای نوشتن داده ای که وجود نداردc.        Patch برای آپدیت بخشی از داده هاd.       Put برای کلا جایگزین کردن داده ها با داده جدیدe.        DELETE هم برای حذف آن7-     قشنگ منطقی آدرس ها طراحی کنید!مثلا GET /users بهتر است یا GET /getusers یا مثلا GET /deleteuser/{id} یا DELETE /user/{id}8-     به کاربر بنده خدا قشنگ بفهمانید که کجا را اشتباه فرستاده! الحمد الله همه یاد گرفته اند می نویسند &quot;خطایی رخ داده . با مدیر تماس بگیرید&quot; خب اگه من به اون مدیر دسترسی داشتم که از خجالتش در میامدم(یاد سیستم ناد که برای دانشگاه ما بود افتادم)9-     حدالامکان اپدیت ها را Patch طراحی کنید!یعنی سعی کنید که کل داده ها را باهم آپدیت نکنید!10-  آقا در دیتابیس یا سرور Pageکنید، حسش را ندارید همه را می فرستید فرانت که چی!!!!فردا روز را هم فکر کنید! ردیف ها زیاد شد که دیگر فرانت خونش جاری میشود!عبدالباقی طور پروژه نسازید.11-  اگر شما از دیتابیس های کاردرست مثل SQL Server یا Oracle استفاده میکنید دلیل بر این نیست که ول کنید به امان خدا!همان هم نیاز به طراحی و افزایش پرفرمنس دارد!(الحمد الله که لایسنس در جای ما معنی ندارد اگر خودم شخصا کوچ میکردم به Postgres البته دارم یادش میگیرم هاااا، شاخ که نمیزند)مریدان که از مطالب کیف کرده بودند رو به خوش خط مکتب کردند و گفتند : نوشتی! وی گفت نه! عکس میگیرم! مریدان گفتند از چه؟؟؟و در اینجا بود که وی فهمید که .......</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Mon, 06 Jun 2022 21:24:57 +0430</pubDate>
            </item>
                    <item>
                <title>حکایت شیخ و مریدان : consistent hashing</title>
                <link>https://virgool.io/@husseinbeygi/%D8%AD%DA%A9%D8%A7%DB%8C%D8%AA-%D8%B4%DB%8C%D8%AE-%D9%88-%D9%85%D8%B1%DB%8C%D8%AF%D8%A7%D9%86-consistent-hashing-a22j61dvmpa0</link>
                <description>روزی شیخ در حال گذر از بازار بود که مریدی بر وی یکهو نازل گشت و پرسید!یا شیخ مسئلتون؟شیخ نگاهی به وی کرد و گفت : شما؟ مرید گفت : یا شیخ از دیشب تصمیم گرفتم که مرید شما بشوم!حال آمده­ام از دموی شما استفاده کنم تا در صورت رضایت از پکیج های شما را خریداری کنم! شیخ گفت : تو میتوانی یک سوال را به صورت تستی بپرسی.حال بپرس! مرید گفت : یا شیخ فرق پایتون با پای­اسکریپت چیست! شیخ گفت : پای اسکریپت کوچک شده پایتون است!(مرید که برای درآمد 30 میلیون تومانی از برنامه نویسی در 1 ماه به شیخ مراجعه کرده بود، قفل کرد]رجوع شود به م.م[).مرید خندید و گفت : بچه جان علم نرم افزار پیچیدگی های خاص خودش را دارد!بشین تا از برایت ریز یک منبر بروم!فکر کن یک سیستمی داری که بزرگ شده و حال مجبور شده­ای علیرغم فرار از این موضوع Sharding را پیاده سازی کنی!حال مجبوری به سرور بگویی که برای دریافت اطلاعات این کلاینت به کدام دیتابیس رجوع کند.سوالی که پیش می­آید این است.چگونه؟خب یک راهش این است که هش کنی!و سپس هش را بر تعداد Node های خود MOD بگیری تا همیشه یک عددی در میان کد Node خود بدست آوری. سپس هروقت که درخواستی از کلاینت آمد بدون مشکل راهش را پیدا میکند!اما اگر یکی از سرور ها به گفت پوف! و دیگر روشن نشد چه؟(مثل لپتاپ من)آن وقت مشتری ها را چه کنیم؟؟مسئله این است که اگر تا دیروز 3 سرور داشتی و MOD عمل هش را بر 3 میگرفتی، الان دیگر 2 عدد سرور داری! یا اصلا این هیچ!فرض مثال یک سرور به سرور هایت اضافه کردی!آنوقت که دیگر نمیتوانی بر 3 MOD بگیری و این یعنی اگر کلاینت اطلاعاتش، در Node سوم باشد، به اشتباه به Node دوم رجوع خواهد کرد!همچنین گفت: آیا از هش های نامطمئن خود خسته شده اید؟پیشنهاد ما به شما Consistent Hashing .....  الگورتیمی است هلو!اصلا آدم عشق میکند به والله! در این الگورتیم ما هش ها را به صورت دایره ای فرض میکنیم و تعداد Node های خود را در درون آن میگذاریم و پس از هش کردن داده آن را به 2π تقسیم میکنیم و فرزند این تقسیم یک درجه از صفر تا 360 خواهد بود! و آن درجه را در درون دایره میگذاریم!حال دو راه داریم که جهت عقربه های ساعت و یا خلاف آن حرکت کنیم! به اولین سرور که رسیدیم، زدیم به خال!   )یک عکس از بلاگ های بلاد فرنگ کش رفتم، ببینم باهم...(در عکس ما چهار سرور داریم که دلمان میخواهد که اسم های عجیب بگذاریم (ZEPPO-CHICO-HARPO-GROUC) آن عدد ها هم که میبینید، مشخصه هایی هستند که تصمیم گرفتیم هش کنیم و MOD آن را بگیریم!سپس با یک چرخش قهرمانانه، به راحتی مشخص میشود که کدام کاربر ها مال کدام سرور ها هستند! در این صورت اگر فردا Node کم یا زیاد شود باز هم تغییری در خروجی الگوریتم نخواهد داشت!چون اصلا به تعداد آن ها کاری ندارد.!و این را بدان که این الگورتیم را بسیار برابر نیاز های خود تغییر میدهند و این مثال و دستور العملی که من گفتم یک حالت عمومی از این الگورتیم بود!این الگورتیم در میکروسرویس ها  و لود بلانسر ها کاربرد دارد.بسیاری از بانک ها به طور پیش فرض از این استفاده میکنند مانند apache Cassandra (چِش خوشگله)و شاید باورتان نشود اما دیسکورد هم از این روش استفاده میکند.کجایش را دیگر نمیدانم!  در کل منظورم این بود که دانستن این الگورتیم، شاخ نمیزند. اشکال شرعی هم ندارد!</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Tue, 31 May 2022 20:34:14 +0430</pubDate>
            </item>
                    <item>
                <title>حکایت شیخ و مریدان : Sharding</title>
                <link>https://virgool.io/@husseinbeygi/%D8%AD%DA%A9%D8%A7%DB%8C%D8%AA-%D8%B4%DB%8C%D8%AE-%D9%88-%D9%85%D8%B1%DB%8C%D8%AF%D8%A7%D9%86-sharding-e1oc5au8oo23</link>
                <description>روزی شیخ در زیر درختی نشسته بود ودرحال نشانه گیری بود که با پلخمون خود بزنه زیر چینگ چغوک!(با تیر کمان دستی خود بزنه زیر نوک گنجشک) که مریدی چغوک را پرانده و گفت:- یا شیخ خوش رکاب را بین المللی کردیم، و به عنوان لژیونر استارتاپ های ده­مان فرستادیم بلاد فرنگ!-باریکلا!نوش جونتون!برو که شکار را پراندی.-آری اما به مشکلی بر خوردیم عجیب!-چه شده ای مرید؟رنگت مانند پارس سفید پلاک کرج شد!-ای شیخ سیستم عجیب کند شده!چه کنیم؟؟پارتیشن هم کردیم اما رم و cpu را چگونه هندل کنیم؟؟؟تازه به طرز عجیبی میزان کانکشن ها به دیتابیس هم زیاد شده که این خود نیز مصداق ترافیک همت می باشد!به جان ما!شیخ به نماد همیشگی دستی به ریش خود کشید و گفت : بشین که بریم روی منبر!ببین مرید بابا!الان اوضاع شما فرق میکند دیگر روی یک سرور کار نمیشود کرد!از این رو برو و به DBAdmin خود بگو که برنامه Sharding را هماهنگ کند تا اوضاع به مانند خودروی ملی نشده!ای شیخ این که گفتی یعنی چه؟؟؟شیخ گفت :Sharding به مانند Partition می­باشد اما در اندازه سرور!یعنی شما به جای اینکه جدول را به مانند تکه های ته قوطی رانی کنی!سرور را این کار میکنی!(پیاده سازیش پوستت را میکند به مولا!)العجب!برگام شیخ!بیشتر بگو؟؟چگونه اینکار کنیم؟؟چگونه­اش که دیتابیس به دیتابیس متفاوت است، اما الگورتیم پیاده سازی را به تو میگویم!حلش باشد برای بعد.بگذار از سر کلاینت توضیح را شروع کنیم!مشتری تو در بلاد فرنگ درخواست چهارپای VIP میدهد، حال شما ID مخصوص مشتری را میگیری(فقط  IDنیست بسته به نوع ساختار پروژه میتونه هرچیزی باشه)و سپس با الگورتیم  Consistent Hashing(مقاله بعد در همین مورد هستش) آن را هش میکنی!سپس متوجه میشوی که به کدام سرور وصل شود  و اطلاعاتش در کدام سرور قرار دارند! به این صورت بار مشتریان خود را در بین سرور ها پخش می­نمایی!از نعمات دینوی این کار بگویم که :1-هم برای داده ها و هم برای منابع امکان Scalability داری2-امنیت بیشتر میشود چون میتوانی بنا به داده های مشتری ها آنان را درسرور های جداگانه بگذاری3-سایز جدول­هایت کوچک تر میشود که این خود یعنی Index کوچک یعنی ایول!4- هزاران جوایز غیر نقدی دیگراما بدان و اگاه باش که این روش بسیار هزینه های فنی و مالی و مغز و اعصابی به بار می­آورد.اگر دیگر راهی نداشتی این کار را بکن!زیرا پیچیدگی های راه اندازی، یک بدبختی!نگهداری سرور ها، یک بدبختی!</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Sat, 28 May 2022 21:35:11 +0430</pubDate>
            </item>
                    <item>
                <title>حکایت شیخ و مریدان : Pagination in SQL</title>
                <link>https://virgool.io/@husseinbeygi/%D8%AD%DA%A9%D8%A7%DB%8C%D8%AA-%D8%B4%DB%8C%D8%AE-%D9%88-%D9%85%D8%B1%DB%8C%D8%AF%D8%A7%D9%86-pagination-in-sql-xkvocfhhprey</link>
                <description>روزی شیخ به مکتب آمد و به مریدان گفت : امروز برنامه آزاد است، سوالی بپرسید.در همین حین مریدی برخواست و به شیخ گفت:ای شیخ مسئلتون، جدولی داریم 1 میلیون رکورد دارد!- باریکلا!- ارادت! حال برای نمایش تمام داده ها صفحه بندی کردیم، کارهرآدم عاقلی!!!اما وقتی صفحات به انتهای خود نزدیک میشوند کوئری ها سنگین شده و انگار دیگر صفحه بندی هم فایده ای ندارد!چه کنیم؟؟شیخ دستی به موهای بلند روغن زده خود کشید و گفت : بگو ببینم از مرید چگونه صفحه بندی کردی؟؟؟مرید گفت : در دیتابیس با استفاده از OFFSET.شیخ گفت : همین اشتباه است!بدانید و آگاه باش ای مرید!زمانی که یک جدول را کوئری میزنی که رکورد زیادی دارد، دیتابیس به این صورت عمل میکند که تمام رکورد ها را گرفته(بدبخت IO) و اضافی هایش را دور میریزد!به همین علت به این مشکل برخوردی!زمانی که میگویی به من 100 ردیف بده که از بین 100000 تا 100100 باشدOFFSET پدر پرفرمنس را در میاورد!مرید که خشتک را دریده بود گفت : ای شیخ، اگر این نکنیم، پس چه بکنیم؟؟-شیخ گفت:کاری کنید که به آن اصطلاحا SEEK میگویند!بروید و هنگام تعویض صفحه آخرین ID که در صفحه وجود داشت برگردانید، سپس با یک کوئری ساده به همراه اندکی INDEX زیبا چنان قشنگ بروید بالای سر ردیف که من نیز خشتک بدرم!از آنجا تعدادی را بگیرید و برگردانید!انتخاب اینکه کوئری را چگونه بزنید هم دستت خودتان است!اینگونه نیازی به گشت و گذار و حرام کردن IO بیچاره نیازی نیست!اما یادتان باشد! این راه حل ها را باید مناسب موضوع انتخاب کنید و به مانند طبیب ده همه را قرص سرماخوردگی ندهید!لینک منبع برای مطالعه بیشتر و دقیق تر : https://use-the-index-luke.com/no-offset</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Tue, 24 May 2022 21:12:29 +0430</pubDate>
            </item>
                    <item>
                <title>حکایت شیخ و مریدان : Partitioning</title>
                <link>https://virgool.io/@husseinbeygi/%D8%AD%DA%A9%D8%A7%DB%8C%D8%AA-%D8%B4%DB%8C%D8%AE-%D9%88-%D9%85%D8%B1%DB%8C%D8%AF%D8%A7%D9%86-partitioning-ezzdljqaspl6</link>
                <description>روزی شیخ به استراحت خود می­پرداخت که مریدان بر وی درآمدند و گفتند: یا شیخ!شیخ که چشمانش را بسته بود با آرامی اندکی باز کرد و گفت : چه شده ای مریدان!کله سحر به دیدار آمده اید!مریدان گفتند: یا شیخ ساعت12 ظهر است!کله سحر کجا بود؟؟؟شیخ گفت : حال بگویید ببینم چه شده است؟؟بدک نیست منبری برویم!مریدان همی گفتند : ای شیخ جدولی داریم 1 میلیون ردیف دارد!شما که از خودی و غریبه نیستی!کوئری که میگیریم با دیگر دوستان همی به بازی حکم می­پردازیم!چه کنیم؟؟از سیستم هم که نگویم که دیگر سیاه است!شیخ گفت:بدانید و اگاه باشید روزی بزرگی به من گفت بهترین راه کوئری زدن جدول 1 میلیون ردیفه این است که جدول 1 میلیون ردیفه را کوئری نزنی!مریدان که با شنیدن این سخن کف از فکشان میریخت گفتند یا شیخ تسمه تایم پاره کردیم!مارا روشن کن!شیخ فرمود : جدول را پارتیشن کنید.منظور این است!مریدی پرسید : یا شیخ، اصلا این چیزا که میگویی یعنی چه؟؟؟شیخ نگاهی نافذ کرد و ادامه داد: بروید و جداول بزرگ دیتابیس خود را چندین تکه کنید سپس هنگام کوئری زدن فقط با بخشی از داده ها کار میکنید نه همه آن! تازه به عنوان هدیه کلیه مسائل پارتیشن را هم خودی دیتابیس هندل میکند!دیگر چه میخواید؟؟؟مثالی بزنم برایتان که بیا و ببین فکر کن جدولی داریم 1 میلیون رکورد دارد اگر بخواهیم برای آن Indexایجاد کنیم. کمک میکند اما معجزه که نمیکند!پس جدول را به 10 جدول کوچکتر تقسیم میکنیم و در قسمتی از جدول مشخص میکنیم که این جدول چه دارد مثلا میگوییم ردیف های این جدول از 1 تا 100000 میباشد!سپس هنگام کوئری زدن اگر ردیف 240213 (میدونم عدد رو نخوندی) را بخواهیم طبعا به جدول دوم و با Index همان جدول در ثانیه ای به آن میرسیم!بله.البته خاطر نشان میکنم که دو نوع پارتیشن بندی داریم، عمودی و افقی!عموی به معنای اینکه شما جدول از ستون ها تقسیم میکنی و افقی به معنای اینکه شما جدول را از ردیف ها تقسیم میکنی !برای عمودی مثالی بزنم که قرمه سبزی وار جا بیافتد. فکر کنید جدولی داریم که ستون آخر آن به دلیل نامعلومی Blobبوده و ما در آن عکس ذخیره میکنیم(نکنید!برای مثال است به والله) حال داده ها زیاد شده و هنگام کوئری گرفتن سرور به روغن ریزی می­افتد!در صورتی که میدانیم این عکس ها آنچنان لازم نیستند جدول را به صورت عمودی پارتیشن میکنیم و داده سنگین را خارج!بدین صورت در هنگام کوئری زدن هزینه را کم کرده و عشق میکنیم!لازم باشد کوئری میزنیم و عکس را نیز میگیریم.مریدان با شنیدن این سخنان برگ ریزان خشتک ها دریدندو سر به آبشار نیارگار گذاشتند!</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Sun, 22 May 2022 18:19:05 +0430</pubDate>
            </item>
                    <item>
                <title>حکایت شیخ و مریدان : Bloom Filter</title>
                <link>https://virgool.io/husseinbeygi/%D8%AD%DA%A9%D8%A7%DB%8C%D8%AA-%D8%B4%DB%8C%D8%AE-%D9%88-%D9%85%D8%B1%DB%8C%D8%AF%D8%A7%D9%86-bloom-filter-h7hg6rp5fsao</link>
                <description>مریدی «تگری زنان» نزد شیخ برفت و گفت یا شیخ حالم دریاب که بغایت رسید. شیخ فرمود : مریدا تو را چه شده ؟مرید گفت : یا شیخ چندی پیش استارتاپی زدیم در خصوص حمل و نقل درون قلعه با چهارپایان که نامش را خوش رکاب گذاشته ایم!شیخ گفت : خب!؟؟نوش جان!چه شده که به ما رجوع کردی؟؟مرید گفت : در این استارت آپ ما در بخش ثبت نام به کاربران اجازه میدهیم نام کاربری را برای خود انتخاب کنند!و یک Index و محدودیتUNIQUE  هم زده ایم تنگش!حال که میزان ثبت نام روزانه ما زیاد شده، از آن رو هم مردم ما به پاس چشم و هم چشمی به مانند تاریخ زایمان به دنبال نام های عجیب و خاص هستند و در بیکاری خود نشسته و یکی یکی نام ها را امتحان میکنند که لاکچری ترینشان را برای خودشان بردارند!بگو خب!شیخ گفت : خب!مرید ادامه داد : حال این مرض مردم شهر برای ما دردسر شده!میزان IO دیتابیس بالا رفته و نرم افزار در حیاتی ترین جای خود کند عمل میکند!شیخ گفت : خب حذفش کن!مرید گفت : A/B تست کردیم 100 درصد نارضایتی خالص بدون حتی اندکی پالم!نمیشود!راه بده جان ما!شیخ دستی به ریش خود کشید و گفت چیزی برتو گویم که خود نیز صبح شنبه فهمیدم!برای این مشکل الگوریتمی طراحی شده به نام BloomFilterحال بنشین تا از برایش روی منبر بروم!به خاطر داشته باش که این الگوریتم بسی پیچیده و جای کار دارد و میتوان به میزان دلخواه آن را پیشرفته کرد.اما به صورت ساده که مطلب را بیان کند ادامه میدهم فکر کن مثلا همین &quot;کوپال&quot; خودمان میخواهد در خوش رکاب ثبت نام کند!در مرحله اول نام شخص را هش کن!بعد باقیمانده آن را بر عددی بدست آور (مثلا 64) و تو عددی خواهی یافت بین 0 تا 63 و آن را در RAM یا Redis ذخیره کن!یا مثلا بیتی را یک کن!نمیدانم روشش با خودت!سری بعد اگر شفتالو خانم آمد برای ثبت نام بعد از اجرای دستور بالا برو و در Redis نگاه کن و ببین آیا این عدد ثبت شده!یا یک شده است!اگر نبود که 100 درصد مطمئن باش که درست است و برو ثبت نام کن!اگر بود حال دو راه می باشد!که یا ثبت نام شده و یا نشده، چرا چونکه شاید روزی نامی بعد از هش کردن و باقیمانده گرفتن عددش با یکی دیگر از نام های قبلی یکی شودو وقتی به Redis رجوع میکنی میبینی که هست! از این رو یا تو تصمیم میگیری که بروی و در دیتابیس هم چک کنی!و یا نه!برایتان صرفه ندارد و به شخص میگویی نامی دیگر انتخاب کن!خط القرآن که نیست!این روش در بسیاری از سیستم های بزرگ استفاده میشود که در کل باعث کاهش IO به دیتابیس و کاهش هزینه میشود! برای مثال همین جیمیل مثلا اگر دقت کرده باشی بروی و نام &quot;دست دراز 886&quot; را بزنی میگوید این نام ثبت شده میخواهی &quot;دراز دست 889&quot; را امتحان کنی!؟خدا خیر داده اصلا حسش ندارد که به دیتابیس برود.البته تصمیم استفاده از این روش با طراح سیستم است!بعد از این سخن، مرید نعره‌ زد و خشتک درید و لپ‌ تاپ‌ خود را به زمین کوبید فغان کشان به کشتی مروارید سیاه پناه برد!!</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Wed, 18 May 2022 23:33:50 +0430</pubDate>
            </item>
                    <item>
                <title>حکایت شیخ و مریدان : جدول های ستون محور (Columnar) و ردیف محور (Row Store)</title>
                <link>https://virgool.io/@husseinbeygi/%D8%AD%DA%A9%D8%A7%DB%8C%D8%AA-%D8%B4%DB%8C%D8%AE-%D9%88-%D9%85%D8%B1%DB%8C%D8%AF%D8%A7%D9%86-%D8%AC%D8%AF%D9%88%D9%84-%D9%87%D8%A7%DB%8C-%D8%B3%D8%AA%D9%88%D9%86-%D9%85%D8%AD%D9%88%D8%B1-columnar-%D9%88-%D8%B1%D8%AF%DB%8C%D9%81-%D9%85%D8%AD%D9%88%D8%B1-row-store-b2ot7yrooepc</link>
                <description>روزی شیخ به زیر درخت همیشگی آمد و دید مریدان ریختند سر مرید دیگری و او را به سخره گرفتند!شیخ صدایش را ته گلویش انداخت و گفت :چِخِه یَره (لفظی مشهدی به معنای کنار بروید)!چه خبر است آنجا؟؟مریدان که میدانستند شیخ ناراحت شده، کنار رفتند و یکی گفت: یا شیخ طرف لیترالی میگه که ما جدول داریم در دیتابیس که ردیفاش توی ستوناشه!اسکل کرده مارو!شیخ دست به ریش خود کشید و گفت:لیترالی!!!!مردک تو جمع کل مسافت های مسافرت های خانوادگی و غیر خانوادگیتان به اندازه مستراح رفتن های من نمیشود تازه من مدتی توی فاز مرتاضی بودم!بعد برای من اجنبی بازی در میاوری؟؟؟؟بعد هم داریم! بنشینید تا بگویم!سپس رو به مرید اجنبی کرد و گفت : تو عوض نشستن، سیت داون کن!همی که شیخ نفسی گرفت تا سخن بگوید ناگهان آیفون ۱۳پرو مکس گلد وی زنگ خورد!بعد از پاسخ دادن، شیخ با لبخندی به مریدان گفت:ریا نباشد شب ماکارونی داریم!سپس رو به مرید اجنبی کرد و گفت : همون اسپاگتی شما ها!حال بدانید و آگاه باشید که میتوانیم در دوحالت جداول را طراحی کنیم!جدول های ردیف محور(Row Store) و جدول های ستون محور( Columnar یا Column Store)!یادتان باشد که جداول ردیف محور در زمانی که خوانده میشوند، چندین ردیف به همراه تمام (تاکید میکنم تمام) ستون ها برای شما می آیند!الله اکبر یعنی بدانید که اگرشما در هنگام Select  گرفتن نام ستون ها را هم نگذارید و ستاره بگذارید به حال IO فرقی نمیکند!چرا؟؟؟چون Page  به Page مطالب را میخواند!اما به هرحال کار خوبی نیست!نکنید!از جای دیگر بیرون میزند!همچنین این جدول ها برای یافتن ردیفی نیاز به IO بیشتری دارند!(توضیح این که چرا دارند حقیقتش ویدئو میخواد متنی سخته K) اما نکته جذاب این است که زمانی که ردیف را یافتی، همه ستون ها را داری.ایول!اما حال برویم روی منبر برای Columnar اصل جنس این است!قبلی را همه میشناسید.در جداول ستون محور زمانی که یک (Block) خوانده می شود چندین ستون در همان بلاک به همراه ردیف های مشخص شده (یا تمام ردیف ها!)می­آید!یعنی که اگر شما 10 میلیون ردیف داشته باشید!بله دیگه!در عوض با کمترین IO بیشترین ردیف را میگیری!چه باحال!اما وای به روزی که چندین ستون را بخواهی!صدای دیسک در میاید! اگر SSD نباشد میگه!ششششش!خخخخخخخ!قیق قیق قیق!مریدان که با دانستن این حجم اندکی از دریای عظیم اطلاعات در خصوص این دو نوع جدول، خشتک ها را دریده بودند که ناگهان مریدی که اندکی کمتر جو گیر بود پرسید!؟؟خب یعنی چی؟؟چه فایده یا شیخ!به چه درد میخورد!؟؟؟؟شیخ گفت : در حالت ردیف محور، جدول ما مناسب نوشتن و خواندن های متعدد میباشد (OLTP) مانند کار های ما!اما همیشه که هدف نوشتن و خواندن های کوچک نیست!پس این مهندسان علم داده چه کاره­اند؟؟آنها بهترین استفاده را از جدول های ستون محور میکنند، زیرا این جداول جون میدهند برای علم داده (OLAP)  فشرده سازی به علت اینکه در یک ستون میتواند چندین داده تکراری باشد عالی است!تجمع کردن داده ها سخن از بشر میگیرد!از کوئری های سنگین نگویم که خوراک کار است!اما بدرد نوشتن در جدول نمیخورد!مثالی بزنم : تصور کنید جدولی داریم با 100 میلیون رکورد(هستش. به والله توی IOT  خیلی پیش میاد) بعد شما به دلیلی ناشناخته جو میگیردت که ستون دما ها را میانگین بگیری!(ایندکس نداریم ها!!!)در جدول ردیف محور باید تمام ردیف ها را بگیری که یادت باشد IO همه ستون ها را میدهد،و ما فقط یکی را میخواهیم، بعد عدد های ستون دما را جمع بزنی و تقسیم بر تعداد کنی!خب این مشخص است که پدر IO  به چشمانش میاید!اما در جدول ستون محور به راحتی ستون دما را میگیری ردیف ها را نیز مفت تو چنگت و مثل خوردن ته دیگ ماکارونی میانگین میگیری!تازه اگر فشرده سازی و تجمع سازی داده ها هم باشد که دیگر نور علا نور است!پس مریدان با علم اینکه کار هر جدول نیست، آنالایز کردن – جدول ستون محور میخواهد و مهندس کهن!(چی شد)خشتک ها را دریده و سر به بیابان گذاشتند!</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Tue, 17 May 2022 22:24:04 +0430</pubDate>
            </item>
                    <item>
                <title>داستان Stored Procedure و گوربه</title>
                <link>https://virgool.io/husseinbeygi/%D8%AF%D8%A7%D8%B3%D8%AA%D8%A7%D9%86-stored-procedure-%D9%88-%DA%AF%D9%88%D8%B1%D8%A8%D9%87-vxyvyee2zbul</link>
                <description>خایله خبدر دنیایی که همه از این ORM  قشنگا استفاده میکنن، شما اونی باش که Stored Procedure مینویسه!واستا یک دقه!!فوش نده! بزار بگمما توی علم کامپیوتر یک مفهومی داریم به اسم IO که همه میدونیم چیه!آفرین(اینجا) همون هارد و فضای ذخیره سازی و اگه تحت شبکه باشه اون TCP  که همه باهم دست به دست هم دادن به مهر که کوئری مارو کنن آباد، هستش(خرده نگیر مهندس میدونم زیاد تر از این حرفاس).استفاده از این IO خیلی گرونه( از ماکارونی هم گرونه تره!) در حدی که هر رفت و برگشت به DB یک گوربه میمیره!پس بیایم گوربه ها رو با کم کردن استفاده از IO نجات بدیم.بله!حالا یک مثالی بزنم برات که کیف کنی!شما در نظر بگیر ما یک جدولی داریم مثلا کاربر ها توی اونن بعد یک جدول دیگه داریم که مثلا عکس ها توی اونن یک جدول دیگه داریم که قراره این داده ها رو توی اون ذخیره کنیم در حالت غیر یک پارچه و اینکه شما از سی شارپ و DBContext که داری بیای اینو هندل کنیاولش با Linq  زیبا یک کوئری میزنی و داده هایی که میخوای رو از جدول کاربر ها میگیری!(رفت و برگشت)تازه ما در نظر میگیریم که شما حواست بوده و به جایIEnumerable  از IQueryable استفاده کردی Jبعد در خط بعدی میای دوباره یک رفت برگشت دیگه میکنی و داده هایی که از عکس ها میخوای میگیری!حالا همه اینا رو با یک رفت و برگشت دیگه اضافه میکنی به جدول سوم!سه تا گوربه مرد!سه بار رفتی و برگشتی به DB بدبخت بیچاره!اونم که صداش در نمیاد!حالا در نظر بگیر یک SP بنویسی که یک رفت برگشت میزنی و فقط به دیتا بیس میگی که اون قضیه بود که بهت گفته بودم ! دمت گرم اجراش کن! دیتا بیس هم که از قبل میدونه چی کار میخواد بکنه به راحتی اجرا میکنه!در این حالت ما یک گوربه تلفات میدیم!به جای سه گوربه!پس سریع تره!حال همین خودش هم داستان داره که سریع تر بشه!ولی خب از همون حالت قبلی بهتره!اونایی که در خط SP نیستن و خون گوربه ها رو پایه مال میکنن! هم میتونن یک Profiler باز کنن و ببین چه غوغایی اون پشته!اگه Profiler نداری ! توی EF بیا لاگ مربوط به کوئری های تولید شده رو فعال کن که برات لاگ بگیره ! همه شلم شوربا رو نشون نمیده ولی خب خالی از لطف نیست!</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Mon, 16 May 2022 21:35:31 +0430</pubDate>
            </item>
                    <item>
                <title>حکایت شیخ و مریدان : انتخاب GUID برای کلید اصلی</title>
                <link>https://virgool.io/husseinbeygi/%D8%AD%DA%A9%D8%A7%DB%8C%D8%AA-%D8%B4%DB%8C%D8%AE-%D9%88-%D9%85%D8%B1%DB%8C%D8%AF%D8%A7%D9%86-%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8-guid-%D8%A8%D8%B1%D8%A7%DB%8C-%DA%A9%D9%84%DB%8C%D8%AF-%D8%A7%D8%B5%D9%84%DB%8C-l0of35k8b2fa</link>
                <description>روزی شیخ در سایه­­ی درختی در انتهای دهاتشان نشسته بود و از آرامش و صدای کلاغان لذت میبرد که ناگهان مریدی بر وی نازل گشت و به صورت آتش به اختیار وی را تکان های نامردانه­ای داد و گفت:یا شیخ.مسئلتون ؟شیخ که هنوز در ریکاوری از آن حرکت عجیب مرید بود گفت:-مسئلتون و درد، مردک نمی بینی در حال لذت بردنم؟؟؟ حال بگو ببینم چه شده؟مرید گفت : ای شیخ آیا استفاده از GUID برای کلید اصلی(Primary Key)  جایز است؟؟؟شیخ گفت : خیر!بدان و آگاه باش ای بشر که این کار جز درد و بدبختی برای DB ندارد!!مرید که سخت قفل کرده بود گفت: واااااااااات؟؟؟برای چه؟؟؟شیخ گفت : زمانی که شما جدول را میسازی عموما دو مسئله وجود دارد که معمولا با هم گرفته میشوند یکی کلید اصلی (Primary Key) و دیگری Clusterd Index!مرید که قیافه­اش به میزان کافی گیج شده بودن را نشان میداد، استثنا هیچ نگفت و شیخ ادامه داد:بله!وقتی میای میگی این ستون Id مرا Primary Key  بکن بانک اطلاعاتی به صورت پیش فرض یک Clustered Index نیز برای آن می­سازد!خب این Primary Key  را که همه میدانیم یعنی چه!تکراری نباشد!NULL نباشد!و از این حرفها، اما بحث اصلی روی Clustered Index می باشد!تاحالا فکر کردی که این Clustered Index چه میکنه؟؟؟اصلا فرقش با Non-Clustered Index چیه؟؟؟چرا فقط یکی ازش میسازن؟؟؟و دیگه نمیشه ازش ساخت!(توی جدول هاااا)مرید گفت:خیر شیخ!اصلا تاکنون نفکریده بودم! شما که غریبه نیستی اصلا نمیدونستم اینا جدان!شیخ ادامه داد: زمانی که Clustered Index میسازیم، جدول ما به صورت خودکار و زمان ورود داده بر اساس این Clustered Index مرتب میشود!یعنی اگر شما Clustered Index را یک ستون نرمال عددی در نظر بگیری اگر ابتدا ID 3 را وارد کنی و بعد ID 2 را وارد کنی، ردیف دومی که اضافه بشه میره قبل ردیف اول میشینه!(که حالا این خودش چجوری این کار میکنه بسته به دیتابیس روش کارش متفاوته که خارج از حوصله این روضه هایی هستش که میخونم!)حالا اگه شما بیای این ستون رو Identity قرار بدی عالی میشه یعنی دیگه هزینه جابه جایی هم نمیدی!و پیج های داده هات مرتب هستن(یکم توی پست IO در این خصوص رفتم روی منبر!)حالا چه فایده داره!وقتی میگی من فلان داده رو میخوام، دیتابیس ما باهوشه و بلده چجوری سریع بره سراغش(رجوع شود به ساختمان داده بخش B-Tree ( اگه از GUID استفاده کنی عملا گند زدی به این مرتب سازی!چون تصادفی هستش دیتابیس دردسر زیادی داره که مرتب سازی کنه! آره اینجوریاس!مرید گفت : یا شیخ!ملتفت فرمودی!اما شرایطی هستش که نمیشه Identity استفاده کرد مثلا Id یک جدول بسته به تراکنش جداول دیگه هستش و بسیار هم دردسر ساز.امکان داره در دو تراکنش ایزوله ما یکهو دوتا Id یکسان تولید کنیم!و هزاران خطاهای ارزنده دیگر!حال چه کنیم؟؟؟شیخ گفت:بدان و آگاه باش که میتوانی از Sequential Table ها استفاده کنید خب!مرید گفت : شیخ جواب نمی­دهد به مولا!!شیخ گفت :ای بابا تو هم گیری هاااااا!دو تا ستون تعریف کن یکی رو عددی بزار Clustered Index را روی آن و دیگری را GUID کن Primary Key را روی آن!هرچه باشد از اینکه هردو یکی باشد بهتر است!مرید که کف کرده بود، خشتک درید و به سر بر کوه های آلپ نهاد!</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Mon, 16 May 2022 21:33:41 +0430</pubDate>
            </item>
                    <item>
                <title>ACID  چیست؟</title>
                <link>https://virgool.io/husseinbeygi/hb-acid-zai271c3iw4c</link>
                <description>1.Atomictyرک پوست کنده بگم یعنی یا تمام دستورات اجرا میشن یا نمیشن!یکمش بشه ، نصفش بشه ، باباش نذاشت که اجرا بشه، رفت دید اندازش نیست و اینا نداریم.یا همش یا هیچیش!2.Consistencyدر این بحث ما دوتا مورد داریم ، یکی Data Consistency یکی هم Read Consistency خب اینا یعنی چی؟؟؟؟Data Consistencyشما نگا کنن این مورد رو خود کاربر تعیین میکنه مثلا در دیتا بیس های Relational  ما از کلید های خارجی استفاده میکنیم که رو هوا داده وارد نشه!یکم منطق و دلیل پشتش باشه.البته اگه بررسی کنید متوجه میشید که این بخش Atomicty بی ربط به اینجا نیست!چرا؟چون شما فکر کن یک پولی انتقال میدی، بعد دیتا بیس (حالا به هر دلیلی) کرش میکنه ! الله اکبر پوله کجا رفت ! اگه Atomicty نبود که رفت هوا ولی چون هست!برمیگرده سرجاش!حالا اگه شما نگاه کنین اگه نبود که Data Consistency خراب میشد!حالا مثال ! فکر کن یک جدول داری که توش لایک ها رو  مثلا همین لینکدین! ذخیره میکنی ! بعد میبینی که اگه لایک ها زیادبشه اون موقع معنی نمیده که بری توی جدول لایک هات کوئری بزنی تعداد بگیری! یک فیلد توی جدول پست ها اضافه می کنی که سیستم هر ازگاهی میره با صله رحم به جدول لایک پست ها یک کوئری میگیره و تعداد رو توی این فیلد میزاره!بعدا که خواستی میخونیش!چرا چون سریع تره!حالا اگه پست بیانسه! موقع نمایش لایک هاش به جای 12503 لایک بگی که 12K لایک خورده ! زمین به اسمون میاد!؟ نه!پس همین کارو میکنی ! اما اگه برنامه موجودی حسابه و انتقال پول دیگه از این خبرا نیست و طراحیش سخت تره!اصلا یک علتی هم که مردم میان  Delete Cascade میزارن توی بانک ها همینه!شما فکر کن یک پستی حذف بشه! بعد رکورد هایی که لایک ها رو نگه میداشته، نشه!چی بشه! کی جمع کنه اون همه داده یتیم رو!Read Consistencyاین بحث خیلی بزرگه! ولی خب چون امروزه همه یاد گرفتن که برن سراغ میکروسرویس ها ( مونولوتیک دور نندازین، انقدر ها هم بدرد نخور نیست!)و بعدش بیان با یک CQRS  به لطف کتابخانه های متعدد، Read رو بدن به  این دیتابیس قشنگا مثل ردیس و Write  و رو بدن به مثلا SQL Server   حالا داستان اینه که در سیستم های خیلی خیلی بزرگ زمان میبره که ردیس بدبخت با این بانک اصلی هماهنگ بشه!این یکی از مسائلی قابل مثال برای Read Consistency هستش! که یک بحث جالبی پیش اومده به اسم eventual Consistency  که یعنی دیر و زود داره ولی سوخت سوز نداره! بالاخره اینا باهم هماهنگ میشن!( یک مطلب کامل برای همین خواهم نوشت!)یعنی بالاخره آقا در سیستم های خیلی بزرگ گاهی پیش میاد که ما داده ای رو ذخیره کنیم و زمانی طول بکشه هرچند کوتاه) این داده هماهنگ بشن!خب!3.Isolationاگه یک Transaction اجرا بشه چهار اتفاق میتونه بی افته1- داده بخونی که  امکان داره اصلا کامیت نشده باشه!یا ابالفضل!(Dirty Read)2- داده بخونی! کامیت باشه ها!اما توی لیست رکورد های خروجی نباشه!دوباره مجبوری کوئری بگیری(non-repeatable Read)  مثال بزنم ! فکر کن داری جمع خرید های امروز رو میگیری به همراه لیستشون و قبل اینکه برسی به دستور SELECT آخر که مال خروجی گرفتن هستش، یک بنی بشری میاد تعداد خرید هارو آپدیت میکنه(مثلا دستی توسط صندوق دار) شما 12 تا آیتم داری که دستی حساب میکنی جمعش میشه 1200 تومن ، بعد اومدی SUM که توی دیتابیس گرفتی رو نگاه میکنی میبینی نوشته 1000 تومن یعنی چی؟ یعنی دارای non-repeatable Read شدی ! مجبوری دوباره گزارش بگیری.3- قبلیه با یک لاک کردن ردیف یا ستون یا جدول یا... قابل حل هستش ! نمیزاری که آپدیت کنن!ولی اگه یکی جدید اضافه کردن چی؟جمع دستی کالا ها که تعدادش 12 تا هستش شده 1200 تومن ولی جمع سیستمی میگه 1400 تومن! اون یکی کو؟؟؟؟اضافه شده ولی توی لیست نیست!(phantom Read)4- شما فکر کن یک ردیفی رو  میخوای اپدیت کنی!و transaction رو اجرا میکنی!هم زمان یک بنی بشر دیگه ای هم داره روی همون داده همین کارو میکنه!شما دکمه ذخیره رو میزنی میبینی یک چیز دیگه آپدیت شده!(یا بالعکس) به این مسئله میگن  (lost Update)برای روضه هایی که بالا خوندم اومدن راه هایی در نظر گرفتن که این بسته به حساسیت داده به روش های مختلف جبران میشه!1-Read uncommitted یعنی آقا هیچ کاری نکن اصلا اگه حتی داده کامیت نشده بود هم بخون!(تمام تراکنش ها از هم خبر دارن و روی هم تاثیر میزارن حتی اونایی که امکان داره وسط راه  Roleback بشن!و شماDirty Read رو داری! )2-Read Commited تراکنش ها فقط تغییرات کامیت شده رو میبینن! Dirty Readحل شده اینجا!3-Repeatable Read اینجا دیتابیس مطمئن میشه که وسط راه کسی به دیتا کُخ نریزه(مشهدی هستش یعنی تغییر نده) حالا چجوری مثلا با لاک کردن داده(خودش یک درس سه واحدیه!)4-SnapShot یعنی شما فکر کن در زمان شروع تراکنش یکی عکس از دیتابیس میگیره و با همون داده ها کار میکنه!مشکل ها همه حل میشه!5-Serializable  این دیگه معرکس! اصلا همزمانی وجود نداره! همه تراکنش ها پشت سر هم اجرا میشن!اینجا هم حل میشه!حالا این داستان هارو هر دیتابیسی یک جور کنترل میکنه!اره خلاصه!مثال Postgres  میاد Repeatable Read رو مثل snapshot هندل میکنه!حالا این یعنی چی؟؟یعنی اگه من یک داده ای رو ذخیره کردم و سیستم رو خاموش کردم، بعدش که اومدم سراغش بهتره سرجاش باشه ! همه دیتابیس ها این کار نمیکنن مثلا ردیس(البته می کنه ها شما باید براش تنظیم کنی) این خودشم سه روش داره که باشه بعدا یکی یکی مطلب میزارم براش!</description>
                <category>حسین بیگی</category>
                <author>حسین بیگی</author>
                <pubDate>Sat, 14 May 2022 22:03:19 +0430</pubDate>
            </item>
            </channel>
</rss>