https://virgool.ir/feed/@aminalaeefa2026-11-12 02:06:35https://files.virgool.ir/upload/users/181746/avatar/cFPCeS.pnghttps://virgool.ir/@aminalaeehttps://virgool.ir/@aminalaee/قوانین-معروف-در-توسعه-نرم-افزار-tw7ypgohykefتوسعه نرم‌افزار مثل هر حوزه تخصصی دیگه‌ای یک سری قوانین و اصول خودش رو داره. لیست زیر مجموعه‌ای از نقل قول‌ها و قوانینی هست که معمولا برنامه‌نویس‌ها، معماران نرم‌افزار و مدیران خیلی از اونها استفاده میکنن.خیلی از قوانین عمومی هستن و مختص به توسعه نرم‌افزار نیستن ولی تلاش کردم تا ارتباط و نحوه مقابله با اونها رو در زمینه کار تخصصی خودم پیدا کنم. اطلاع داشتن از این قوانین دید خوبی به افراد میده تا در حد امکان در کارهای تخصصی خودشون بتونن از بروز اونها جلوگیری کنند و در صورت بروز آمادگی مقابله با اونها رو داشته باشند. قانون مورفی (Murphy's Law)یکی از معروف‌ترین قوانین هست که فقط هم مختص توسعه نرم‌افزار نیست:هر چیزی که ممکنه خراب بشه، حتما خراب میشهاستفاده از ورژن کنترل، متدلوژی TDD و توسعه نرم‌افزار به روش تدافعی و غیره همه روش‌هایی برای جلوگیری از این قانون هستندقانون پارکینسون (Parkinson's Law)این قانون درباره مدیریت زمان و برنامه‌ریزی برای انجام کارهاست که میگه:هر کار به اندازه زمانی که برای آن تخصیص داده شده طول می‌کشداستفاده از ابزارهای مدیریت پروژه آنلاین، جلسات فردی و تیمی منظم، داشتن اهداف مشخص، زمانبندی دقیق برای انجام کارها و جلوگیری از multi-tasking همه از مواردی هستن که به جلوگیری از قانون پارکینسون کمک میکنه.قانون بروکس (Brook's Law)آقای Fred Brooks نویسنده کتاب معروف The Mythical Man-Month این قانون رو در کتابش مطرح میکنه:اضافه کردن نیروی انسانی به یک پروژه نرم‌افزاری با تاخیر، تاخیر اون رو بیشتر میکنهبا اضافه شدن افراد جدید به پروژه مدت زمانی طول میکشه تا افراد بتونن با پروژه آشنایی پیدا کنند و موثر باشند. همچنین با اضافه شدن افراد پیچیدگی ارتباطات هم بیشتر میشه و در نتیجه باعث میشه کارها کندتر پیش بره.بازبینی کدها، اصلاح معماری و استفاده از متدلوژی‌های توسعه نرم‌افزار مناسب تیم قطعا نتیجه بهتری نسبت به اضافه کردن نیروی انسانی به پروژه نرم‌افزاری در حال تاخیر داره.قانون هافستدر (Hofstadter's law)از این قانون مجدد در کتاب The Mythical Man-Month و متدلوژی XP صحبت شده:انجام کار همیشه بیشتر از چیزی که فکر می‌کنید طول میکشه، حتی وقتی قانون هافستدر رو در نظر بگیریداین قانون درباره پیچیدگی تخمین زمان مورد نیاز برای کارهاست که خصوصا در توسعه نرم‌افزار زیاد با اون سر و کار داریم. نوع قانون دلالت بر خود هست و این پیچیدگی که خود قانون از خودش استفاده میکنه، بازتابی از پیچیدگی تخمین زمان تحویل کار هست. تخمین زمان یک مهارت کلیدی در توسعه نرم‌افزار هست که با استفاده از دانش قبلی انجام کار مشابه، کمک گرفتن از افراد با تجربه و تقسیم کار به چند مرحله به تخمین دقیق‌تر ما کمک میکنه.قانون کانوی (Conway's Law)قانون کانوی درباره ساختار سازمانی هست و به طور خلاصه میگه هر بخشی از نرم‌افزار نشان دهنده ساختار سازمانی هست که اون رو تولید کرده. به طور دقیق:هر سازمانی که سیستمی را طراحی می‌کند، ساختار طرح خروجی یک کپی از ساختار ارتباط درون سازمان خواهد بوددر بسیاری از شرکت‌ها افراد بر اساس توانایی‌ها در تیم‌های مختلف Frontend, Backend, DevOps و غیره قرار می‌گیرن. روش بهتر این هست که مثل طراحی میکروسرویس افراد که روی یک محصول یا سرویس کار می‌کنند در یک تیم قرار بگیرند تا ارتباط و خروجی بهتری داشته باشند.برای مقابله با این قانون محل استقرار افراد درون تیم‌ها باید حول محور هدف و خروجی باشه تا دستیابی به اون هدف راحت‌تر بشه و پیچیدگی ارتباطات درون تیم‌ها کمتر بشه.قانون پاستل یا قانون قدرتمندی (Postel's Law) جان پاستل یکی از تاثیرگذارترین افراد در شکل‌گیری اینترنت، TCP و DNS این قانون رو مطرح میکنه که:در ارسال‌ها محافظه‌کار باشید، ولی در دریافت روشن‌فکر باشیداین قانون رو در طراحی‌های اولیه پروتکل TCP مطرح کرده و همین باعث قدرتمند بودن این پروتکل شده. مصداق این قانون در پیاده‌سازی زبان‌های برنامه‌نویسی ویژگی ارث بری و Polymorphism هست که در ورودی بتونیم با generic ها تایپ‌های مختلفی بگیریم ولی در خروجی محدودیت داشته باشیم.اصل پارتو یا قانون ۸۰-۲۰ (Pareto Principle)اصل پارتو که به نام‌های قانون ۸۰-۲۰ و قانون افراد اندک اساسی هم معروف هست میگه:۸۰ درصد رخدادها از ۲۰ درصد دلایل به وجود می‌آیندارتباط این اصل با حوزه کاری توسعه نرم‌افزار به این شکله که معمولا ۸۰ درصد باگ‌های نرم‌افزار مربوط به ۲۰ درصد پروژه هستند که با استفاده از ابزارهای Linter و Static Analysis به صورت اتوماتیک میتونیم این مشکلات رو راحت‌تر پیدا کنیم.همچنین میشه گفت ۸۰ درصد کارها در یک سازمان توسط ۲۰ درصد افراد انجام میشه و مشخص کردن این که چه افرادی بیشترین کار رو انجام میدن کار سختی هست ولی به لطف ابزارهای آنلاین contribution های افراد و کیفیت انجام کارها راحت‌تر پیگیری میشه.اصل پیتر (Peter Principle)اصل پیتر یک مفهوم مدیریتی است که میگه انتخاب یک نامزد برای موقعیت جدید بر اساس عملکرد موفقیت آمیز فرد در نقش فعلی‌اش صورت میگیره نه بر اساس سنجش توانایی‌ها برای موقعیت جدید. به همین دلیل با مدیرانی در سازمان‌ها مواجه میشیم که شایستگی جایگاه خودشون رو ندارن. به طور دقیق:کارکنان تا آنجا که موفقیت‌آمیز عمل کنند ارتقا می‌یابند و فقط هنگام رسیدن به «مرز بی‌کفایتی» متوقف می‌شوند و در همان سمت باقی می‌ماننداصل پیتر حالت خاصی از «پدیده همه‌جانبگی» (ubiquitous observation) است: هر آنچه (درست) کار می‌کند در حالتی پیشرفته‌تر و چالش‌برانگیزتر به کار گرفته خواهد شد تا آنجا که دیگر کارایی از خود نشان ندهد.اثر دانینگ–کروگر (Dunning–Kruger effect)اثر دانینگ–کروگر یک خطای ذهنی و روانشانسی هست که میگه افراد کم‌تجربه توانایی خودشون رو خیلی بیشتر از چیزی که واقعا هست می‌دونن و توهم خود بزرگ‌بینی دارن و افراد حرفه‌ای این اشتباه رو می‌کنند که چون انجام کاری برای خودشون ساده هست پس برای بقیه هم همینطوره، که اشتباهه. این اثر بر اساس تحقیق دو روانشناس انجام شده و میگه:تخمین نادرست فرد بی‌لیاقت، از اشتباه در ارزیابی خود ناشی می‌شود؛ درحالی‌که تخمین نادرست افراد بسیار بالیاقت، از اشتباه در ارزیابی دیگران نشئت می‌گیردبه شخصه در خیلی از محیط‌ها با این مساله روبرو شدم که افراد کم‌تجربه به دلیل دید محدودی که نسبت به کارها دارن دید درستی از خودشون ندارن. یکی از بهترین کارهایی که برای مقابله با این اثر میشه انجام داد اینه که همیشه در حال یادگیری باشیم تا به خودمون مغرور نشیم و از دیگران فیدبک صادقانه درباره کارمون بگیریم. البته خیلی از وقت‌ها افراد شاید مستقیم نتونن مشکلات رو بهتون بگن و میشه ازشون در قالب سوال پرسید که مثلا به نظر اونها یک برنامه‌نویس یا مدیر خوب چه ویژگی‌هایی داره و اینطوری خودمون رو با اون معیارها مقایسه کنیم.قانون لینوس (Linus's Law)لینوس توروالدز خالق کرنل لینوکس این قانون رو میگه:هرچه چشم‌ها بیشتر باشند باگ‌ها کم عمق‌ترنداین جمله به نقل از لینوس توروالدز در کتاب «کلیسا و بازار» نوشته اریک ریموند گفته شده که تفاوت بین دو روش توسعه نرم‌افزار رو توضیح میده. روش کلیسا که میگه کد توسعه داده شده در بین release ها عمومی نیست و با هر release کد به صورت متن باز منتشر میشه که نمونه‌های این نرم‌افزارها GCC, Emacs هستن. روش بازار روشی هست که هسته لینوکس در دسترس عموم و در بستر اینترنت توسعه داده میشه و شروع کننده اون رو لینوس توروالدز میدونه.طرفداران متن باز بودن نرم‌افزرها اعتقاد دارن وقتی کد در دسترس عموم باشه با دقت و کیفیت بهتری توسعه نرم‌افزار انجام میشه و باگ‌های کمتری خواهد داشت.قانون مور (Moore's Law)نخستین بار آقای مور از بنیان‌گذاران اینتل این قاعده رو بیان میکنه که:تعداد ترانزیستورهای روی یک تراشه با مساحت ثابت هر ۲ سال ، به طور تقریبی دو برابر می‌شودنسخه‌های دیگه‌ای از این قاده مطرح شده که سرعت پردازش کامپیوترها هر ۲ سال تقریبا دو برابر میشه. یا هزینه واحدهای کامپیوتری هر ۲ سال تقریبا دو برابر میشه.اطلاع داشتن از چنین قواعدی باعث میشه در طراحی و توسعه نرم‌افزارها دید بهتری از آینده داشته باشیم و پیش‌بینی های دقیق‌تری داشته باشیم. از نمونه‌های عدم آینده‌نگری در نرم‌افزارها میشه به مشکل سال ۲۰۳۸ اشاره کرد که در این سال timestamp روی سیستم‌های ۳۲ بیتی overflow میشه یا مشکل Y2K که تقویم‌های کامپیوترها بعد از سال ۱۹۹۹ و شروع سال ۲۰۰۰ به مشکل خوردن.قانون ویرث (Wirth's Law)این قانون رو آقای نیکولاس ویرث خالق زبان برنامه‌نویسی پاسکال میگه:سرعت کند شدن نرم‌افزار بیشتر از افزایش سرعت سخت‌افزار هستنسخه‌های دیگه‌ای از این قانون وجود داره مثل چیزی که بیل گیتس میگه که هر ۱۸ ماه به طور میانگین سرعت نرم‌افزارها نصف میشه تاثیر قانون مور رو خنثی میکنه.قانون ۹۰-۹۰ (Ninety-Ninety rule)این قانون یک شوخی درباره زمانبندی توسعه نرم‌افزار هست که معمولا تحویل محصول در تیم‌ها با تاخیر انجام میشه و عدم قطعیت همیشه در نرم‌افزار هست. این قانون میگه:۹۰ درصد کد در ۱۰ درصد زمان توسعه داده میشه. ۱۰ درصد مابقی کد ۹۰ درصد زمان رو میگیره.این مجموع ۱۸۰ درصدی یک شوخی هست که همیشه توسعه نرم افزار بیشتر از چیزی که فکر می‌کنیم زمان میبره.اصل Knuth's principleاین قانون درباره بهینه‌سازی کد هست که میگه:بهینه‌سازی قبل از موعد عامل همه بدی‌هاستروش استاندارد توسعه کد این هست که شما کد رو در وضعیتی که فکر میکنید خوبه توسعه میدین و بعد از پیدا شدن مشکلات سرعت، به دنبال رفع اونها برید. بهینه کردن قبل از موعد فقط باعث پیچیده و کند شدن توسعه میشه.یک بار دنبال مقاله پارتیشن کردن دیتابیس Postgres بودم که اولش گفته بود اگر نمیدونین پارتیشن کردن دیتابیس چیه حتمن به اون نیازی ندارید!قانون نورویگ (Norvig's Law)قانون نورویگ یکی از قوانین بدبینانه هست که میگه:هر تکنولوژی که به درصد نفوذ بیشتر از ۵۰ درصدی میرسه، هرگز دیگر افزایش ۲ برابری نخواهد داشت (در هیچ بازه زمانی)طبیعیه که مثلا استفاده کنندگان از تلفن هوشمند وقتی از ۱ میلیون به ۲ میلیون در کشور میرسه افزایش دوبرابری بوده ولی وقت مثلا ۳۰ میلیون استفاده کننده در کشور داریم هرگز افزایش ۲ برابری یعنی ۶۰ میلیون مشترک نخواهیم داشت.امین علاییامین علاییSun, 24 May 2020 16:55:45 +0430https://virgool.ir/@aminalaee/rest-api-best-practices-amweu8agxozcREST APIچند سال تجربه خودم در طراحی و پیاده سازی REST API ها و کار در تیم‌های مختلف و با Legacy Code ها، خیلی پیش اومده که API هایی دیدم که خیلی از استانداردها دور بوده. با سرچ کردن درباره Best Practice ها و تجربه خودم یه لیست آماده کردم از نکاتی درباره طراحی REST API ها که اگه رعایت بشه انتقال کدها و استفاده از اونها رو راحت‌تر میکنه.در URL ها بهتره از اسم استفاده کنید و از فعل استفاده نکنید. مثلا استفاده از /api/users/ بهتر از استفاده از /api/users/create/ هست.در URL یا از اسم‌های مفرد یا اسم‌های جمع استفاده کنید. هر کدوم رو انتخاب می‌کنید مهم نیست ولی در تمام پروژه فقط از یکی استفاده کنید. مثلا یا /api/users/ رو انتخاب کنید یا /api/user/ ولی ثبات رو در انتخاب نام‌ها رعایت کنیدبه جای استفاده از فعل در URL باید از متدهای مختلف HTTP استفاده کنید. مثلا:متد GET: برای دریافت آیتم‌هامتد POST: برای ساخت آیتم‌هامتد UPDATE: برای آپدیت آیتم‌هامتد DELETE: برای حذف آیتم‌هاپروتکل HTTP متد‌های GET, OPTIONS, HEAD, TRACE رو به نام متد‌های امن معرفی می‌کنه که این متدها نباید بتونن وضعیت سرور رو تغییر بدن. از این متدها باید درست استفاده کنید.رابطه‌ها باید از طریق زیر URL ها فراخوانی شوند. مثلا برای دریافت لیست عکس‌های یک کاربر باید یک URL مثل /api/users/{id}/photos/ داشته باشید.ورژن‌بندی API یا باید در URL یا در HEADER های ریکوئست باشه. مثلا /api/v1/users/ ورژن‌بندی در URL داره.فیلتر، sort و pagination باید فقط در ریکوئست‌های GET قابل دسترس باشه. مثلا:Filter: /api/v1/users?name=AliSort: /api/v1/users?order_by=name&order=descPagination: /api/v1/users?page=1&per_page=10احراز هویت کاربران بهتره با استفاده از JWT و احراز هویت سرویس‌های متصل به API با استفاده از API KEY انجام بشه.از Status Code های HTTP و معنی اونها باید درست استفاده کنید. لیست کامل کدها در اینجا هست. مثلا:1xx: از کدهای سری یک برای پاسخ‌های اطلاعاتی2xx: سری کدهای دو برای پاسخ‌های موفقیت آمیز3xx: سری کدهای سه برای Redirect4xx: سری کدهای چهار برای خطای سمت کاربر5xx: سری کدهای پنج برای خطای سمت سرورامین علاییامین علاییSun, 17 May 2020 11:07:56 +0430https://virgool.ir/@aminalaee/postgresql-distributed-architecture-ynwtuma9vxeeچند وقت پیش ما یک دیتابیس حجیم در PostgreSQL داشتیم که روزانه چند ده میلیون رکورد رو Insert میکردیم و میخواستیم حجم Insert های ورودی رو باز هم افزایش بدیم. اضافه کردن سخت افزار به سرور فعلی منطقی نبود و چاره‌ای نداشتیم جز این که به صورت افقی سیستم رو Scale کنیم و تعداد سرورها رو افزایش بدیم. تو این مطلب سعی می‌کنم تجربه پیاده سازی و استفاده از این معماری رو توضیح بدم.دیتابیس‌های توزیع شده (Distributed Databases)معماری دیتابیس توزیع شدهدیتابیس‌های توزیع شده دیتابیس هایی هستن که محل ذخیره سازی اونها به یک پردازنده مشترک متصل نشده و از طریق شبکه با هم در ارتباط هستن. ممکنه این سرورها در یک نقطه فیزیکی کنار هم باشند یا از نظر جغرافیایی در نقاط مختلفی قرار گرفته باشند.یک دیتابیس توزیع شده که درست طراحی شده باشه هم از نظر معماری و هم شبکه شفاف یا Transparent هست. به این معنی که استفاده کننده از اون متوجه معماری و ارتباط سرورهای متصل به دیتابیس نمیشه و انگار به یک دیتابیس با یک Node متصل هست.استفاده از این معماری مزایا و معایب خودش رو داره. از مزایای اون میشه به high availability و fault tolerance اشاره کرد و از مهمترین معایب اون پیچیده شدن و سخت‌تر شدن نگهداری و عیب‌یابی سیستم هست.کوئری‌های توزیع شده (Distributed Queries)برای این که روی یک دیتابیس توزیع شده بتونیم کوئری بزنیم باید کارهایی از قبل انجام بدیم. فرض کنید تو یک دیتاسنتر ما چند تا سرور داریم که دیتای این سرورها کپی یا duplicate هم نیست. برای کوئری زدن روی این دیتابیس‌ها مجبور بودیم مستقیم به هر دیتابیس وصل بشیم و دیتای اون رو بخونیم ولی طبیعیتا نیاز داشتیم تا دیتای همه سرورها رو در کنار هم داشته باشیم. با یه سرچ ساده به یک سری راه حل رسیدیم و نیازهای خودمون رو با اونها بررسی کردیم:dblink extensionPostgres Foreign Data Wrapper (fdw) extensionPrestoافزونه dblink:یکی از extension های postgres هست که ساده ترین روش پیاده سازی کوئری‌های توزیع شده روی دیتابیس رو داره ولی روش بهینه‌ای نیست. مدل کار کردن این افزونه به این شکل هست که موقع کوئری زدن، دیتا از روی دیتابیس‌های remote روی یک سرور جمع میشه و دیتای اضافه‌ای مثل آمار و index ها رو نداره در نتیجه برای پردازش دیتای حجیم مشکلات performance ای داره.افزونه fdw:یکی دیگه از افزونه‌های postgres هست که از ورژن ۹.۳ همراه دیتابیس نصب میشه. نسخه ارتقا پیدا کرده همون dblink هست که مراحل پیاده سازی پیچیده تری داره ولی سرعت بالاتری هم داره. روش کارش هم به این صورته که در کنار جدول‌های اصلی یک سری جدول خارجی foreign table از دیتابیس های دیگه رو میتونه نمایش بده و در نتیجه کوئری های تجمیع شده انجام بده. دیتابیس و جدول‌های خارجی که این افزونه نمایش میده مثل یک symlink در کنار دیتابیس اصلی نشون داده میشه.نرم افزار Presto:یک Distributed Query Engine هست که توسط فیسبوک و زبان Java توسعه داده شده. از Presto برای کوئری‌های big data در حد چندین ترابایت در فیسبوک استفاده میشه. به دلیل استفاده از Java خیلی سبک نیست ولی مراحل پیاده سازی و مستندات اون به شدت ساده هست. نکته مثبت دیگه این که فقط مختص Postgres نیست و خیلی دیگه از دیتابیس‌ها رو میشه به عنوان منبع ورودی بهش وصل کرد. از معایب اون هم میشه به client اختصاصی اشاره کرد که برای انجام کوئری باید از اون استفاده کرد و در نتیجه transparency در اون رعایت نمیشه و ممکنه در یکپارچه سازی با سیستم‌های دیگه به مشکل خورد.با توجه به این بررسی‌ها ما سراغ افزونه fdw رفتیم و در ادامه نحوه پیاده سازی اون رو برای یک نمونه توضیح میدم.فرض کنید در دیتاسنتر ما سرور A رو تا الان داشتیم و حالا تصمیم گرفتیم سرور B رو اضافه کنیم. این دیتابیس‌ها قرار هست هر کدوم بخشی از دیتا رو نگه دارن و کپی هم نباشند. سرور A رو به عنوان دیتابیس اصلی و سرور B رو به عنوان دیتابیس فرعی در نظر میگیریم و یک جدول نمونه blog_post رو روی هر دو دیتابیس ایجاد میکنیم. برای پیاده سازی fdw مراحل زیر رو انجام میدیم.روی سرور اصلی (سرور A) دیتابیس و جدول های مورد نیاز رو ایجاد میکنیم:$ create database blog; $ \c blog; $ create table blog_post (id serial primary key, title text, body text);حالا با استفاده از دستور explain تست میکنیم که کوئری روی چه جدول‌هایی اجرا میشه:$ explain select * from blog_post; QUERY PLAN ------------------------------------------------------------- Seq Scan on blog_post (cost=0.00..18.50 rows=850 width=68)همونجور که انتظار داشتیم کوئری فقط روی جدول blog_post اجرا شده.حالا سراغ دیتابیس فرعی (سرور B) میریم و اول تنظیمات رو برای postgres انجام میدیم تا دسترسی از دیتابیس اصلی به این دیتابیس وجود داشته باشه. برای کوتاه شدن مطلب این قسمت رو ننوشتم ولی با یک سرچ ساده میشه این تغییرات رو انجام داد.پس از این که دسترسی بین سرور اصلی و فرعی برقرار شد حالا دیتابیس و جدول‌های مورد نیاز رو روی دیتابیس فرعی ایجاد می‌کنیم:$ create database blog; $ \c blog; $ create table blog_post_b (id serial primary key, title text, body text);دیتابیس و جدول تستی رو سرور فرعی ایجاد شده. نکته مهم این که اسم جدول در دیتابیس فرعی باید با اسم جدول در دیتابیس اصلی متفاوت باشه. برای همین اسم جدول رو blog_post_b گذاشتیم.مجدد به دیتابیس اصلی بر می‌گردیم و با دستورات زیر fdw رو راه اندازی می‌کنیم. ابتدا افزونه fdw رو برای دیتابیس blog فعال می‌کنیم:$ \c blog; $ create extension postgres_fdw;بعد دیتابیس فرعی B رو با استفاده از fdw در دیتابیس اصلی به عنوان یک دیتابیس خارجی ایجاد میکنیم. دیتابیس اصلی دیتابیس فرعی رو به عنوان یک symlink یا shortcut در کنار خودش می‌بینه:$ create server master_server foreign data wrapper postgres_fdw options (host '{ip of server B}', port '5432' , dbname 'blog');با دستور زیر نام کاربری و پسورد دیتابیس فرعی رو جهت اتصال از دیتابیس اصلی وارد می‌کنیم:$ create user mapping for '{local postgres user}' server master_server options (user '{username of postgres on B}', password '{password of postgres on B}');دسترسی دیتابیس خارجی ایجاد شده رو به کاربر فعلی میدیم:$ alter server master_server owner to '{local postgres user}';در نهایت جدول blog_post_b که در دیتابیس فرعی وجود داره رو به عنوان یک جدول خارجی در دیتابیس اصلی وارد میکنیم:$ create foreign table blog_post_b () inherits(blog_post) server master_server;در دستور بالا گفتیم جدول خارجی blog_post_b از جدول اصلی blog_post ارث بری می‌کنه که هم باعث میشه ساختار جدول جدید با جدول اصلی یکی باشه و هم کوئری‌هایی که روی جدول اصلی زده میشه هم در جدول اصلی و هم وارث‌های اون یعنی دیتابیس B انجام بشه.دوباره کوئری رو اجرا میکنیم:$ explain select * from blog_post; QUERY PLAN ---------------------------------------------------------------------------- Append (cost=0.00..136.70 rows=891 width=68 -> Seq Scan on blog_post (cost=0.00..0.00 rows=1 width=68) -> Foreign Scan on blog_post_b (cost=100.00..136.70 rows=890 width=68)همون طور که می‌بینید تنظیمات به درستی انجام شده و هر کوئری که روی جدول blog_post دیتابیس اصلی انجام میشه روی دیتابیس اصلی و دیتابیس فرعی انجام میشه و در نهایت دیتای تجمیع شده به کاربر داده میشه.همچنین کاربر نیازی نداره تا دیتا رو join کنه و متوجه معماری و شبکه دیتابیس توزیع شده نخواهد شد.در ادامه میتونیم trigger هایی برای postgres تعریف کنیم تا دیتا رو بر اساس دیتای ورودی بین دیتابیس‌ها پخش کنه و یک معماری distributed کامل رو توسط fdw پیاده سازی کنیم که با توجه به شرایط پروژه ما نیازی به انجام این کار نبود.امین علاییامین علاییTue, 28 Apr 2020 15:09:40 +0430