https://virgool.io/feed/@develop یه بک اند دولوپر :) fa 2026-04-15 09:48:02 https://files.virgool.io/upload/users/199072/avatar/wNdjEb.png?height=120&width=120 https://virgool.io/@develop https://virgool.io/@develop/cohesion-vs-coupling-a3lipxuo1pba احتمالا در مورد این موضوع شنیده اید که می گویند ما باید تمرکز کنیم که روی کدی که کار میکنیم Coupling کمتر با Cohesion بیشتر داشته باشیم. در این مطلب راجب این موضوع بیشتر صحبت میکنیم و باهم نمونه کد هایی بررسی میکنیم.تفاوت در کجاست؟ در واقع Cohesion تعداد کانکشن های در داخل یک بخش از کد میشود. اگر تعداد Cohesion ما کم باشد احتمال زیاد بخش های مختلف کد ما مرز بندی (boundaries) درستی ندارند و اونا ها رو به درستی از هم جدا نکرده ایم چون در داخل اون بخش کد لاجیک مرتبط به هم وجود ندارد.از سوی دیگر Coupling نشان دهنده میزان مستقل بودن یک بخش از بخش های دیگر است. تعداد کانکشن بین دو یا چند بخش است. هرچه تعداد کمتر باشد، Coupling کمتر است.یک بخش میتواند یک متد , یک کلاس , مجموعه ای از کلاس ها و یا یک ماژول باشد. Cohesion و Coupling در سطح های مختلفی قابل بکار گیری هستند.چگونه به Cohesion زیاد و Coupling کم برسیم؟در اصل Cohesion زیاد به معنی نگه داشتن کنار همدیگر بخش هایی از یک کد هست که به یکدیگر مرتبط هستند آن ها را در یک بخش دسته بندی می کنیم. Coupling کم در مورد این است که این دسته بندی را طوری انجام دهیم که بخش هایی که به هم مربوط نیستند در دسته های مختلف قرار بگیرند در این صورت ارتباط بین بخش های مختلف کم می شود و Coupling ما هم کم می شود.در تئوری، نحوه کار بسیار ساده به نظر می رسد اما در عمل، باید به مقدار کافی domain model خودمون را بشناسیم تا متوجه بشیم که کدام بخش از کد واقعاً به هم مرتبط هستند.یعنی که بر خلاف معیارهایی مانند پیچیدگی، میزان Coupling و Cohesion در کد به طور مستقیم قابل اندازه گیری نیست. این به شدت به domain model وابسته هست. رعایت این اصل سخت است به دلیلی این که قابل اندازه گیری نیست.انواع کد از نظر Cohesion و Couplingاول - ایده آل: کدی است که از این موضوع پیروی می کند که دارای Coupling کم و Cohesion بالا است. ما می توانیم چنین کدی را با این تصویر نشان دهیم:دایره های همرنگ، بخش هایی از کد مربوط به یکدیگر را نشان می دهند.دوم - God Object: این مورد در نتیجه Coupling بالا و Cohesion بالا شکل می گیرد. این یک آنتی پترن است و به معنی یک قطعه کد است که همه کارها را یکجا انجام می دهد: سوم:‌ نوع سوم زمانی اتفاق می‌افتد که مرزهای بین کلاس‌ها یا ماژول‌های مختلف ضعیف انتخاب شوند برخلاف God Object، کدهای این نوع دارای مرز هستند. مشکل اینجاست که آنها به درستی انتخاب نشده اند و اغلب معنای واقعی دامنه را منعس نمی کنند و domain model در آن ها به درستی مشخص نیست چنین کدی Single Responsibility Principle را نقض می کند. چهارم - جداسازی زیادی:‌ گاهی اوقات زمانی اتفاق می افتد که یک برنامه نویس سعی می کند یک کد را آنقدر جدا کند که کد کاملاً فوکوس خودش را از دست می دهد: مشکلات در رعایت اصل Cohesion و Couplingزمانی که یک برنامه نویس سعی می‌کند دستورالعمل Coupling کم و Cohesion بالا را پیاده‌سازی کند تلاش زیادی می کند که Coupling را کم کند اما موضوع Cohesion را به طور کامل فراموش می‌کند. این منجر به وضعیتی می شود که در آن کد decoupled شده است اما در عین حال فوکوس مشخصی در domain model ندارد. اجزای آن به قدری از یکدیگر جدا شده اند که درک مفهوم اون ها خیلی سخت می شود. به طور مثال این کار است. همانطور که مشاهده می کنید که از یک طرف، کلاس Order کاملاً از Product و حتی OrderLine جدا شده است. منطق محاسبات را به یک interface به نام OrderPriceCalculator واگذار شده است و ایجاد order line توسط یک factory انجام می شود این جداسازی اغلب با دیدگاه "interfaces everywhere" ایجاد می شود. یعنی وسوسه جایگزینی هر class با یک interface، حتی اگر آن واسط نشان دهنده یک انتزاع نباشد.حالا کد بالا رو چگونه بازنویسی کنیم؟ ما باید ارتباطات بین Order، OrderLine و Product را دوباره مشخص کنیم.درک رابطه cohesion و coupling مهم است. coupling کامل یک کد بدون آسیب زدن به cohesion ممکن نیست و ایجاد کد کاملاً همراه با cohesion بدون استفاده از coupling غیرممکن است.تعادل، کلید ایجاد کدی با cohesion بالا و coupling کم است.جمع بندی:بسیاری از توسعه دهندگان در برنامه ای که توسعه می دهند مدل ها فقط برای ذخیره‌سازی برای داده‌هایی هستند که از پایگاه داده به UI منتقل می‌کنند. با استفاده بهتر از مدل ها میتوانیم کد بهتری داشته باشیم.رسیدن به سطح جدایی که می‌خواهیم در بیشتر موارد ممکن است اما همیشه ممکن نیست. هیچ چیزی نمی تواند جلوی ما را برای ساخت یک مدل تمیز و با cohesion بالا بگیرد.تعداد زیادی از پروژه هایی که شکست میخورند زیر انبوهی از کد های کثیف و اسپاگتی دفن شده اند انقدر این مشکل بزرگ می شود که دیگر برنامه نویس های پروژه نمی توانند فیچر یا تغییرات جدیدی در سیستم بدهند چون هر تغییر مثل دومینو تمام پروژه رو با خطا های ریز و درشت مواجه می کند یکی از مواردی که با رعایت کردنش باعث میشه که پروژه به این سمت نرود رعایت اصل cohesion بالا و coupling کم هست. با رعایت این اصول شما می توانی از فاجعه جلوگیری کنید. علی قایینی علی قایینی Thu, 04 Aug 2022 23:36:36 +0430 https://virgool.io/@develop/%DA%86%DA%AF%D9%88%D9%86%D9%87-%DA%A9%D8%A7%D9%86%D8%AA%DB%8C%D9%86%D8%B1-%D8%A7%D9%BE%D9%84%DB%8C%DA%A9%D8%B4%D9%86-%D9%87%D8%A7%DB%8C-golang-%D8%B1%D8%A7-%D9%81%D8%B4%D8%B1%D8%AF%D9%87-%DA%A9%D9%86%DB%8C%D9%85-qn3w3tkt7oeh وقتی می‌خواهیم اپلیکشن های Go رو containerize کنیم ساخت image ضروری است. build یک image با حجم زیاد به این معنی است که شما به دیتا های بیشتری برای انتقال بین image repository، CI/CD و deploy نیاز دارید. ایجاد یک image کوچکتر برای صرفه جویی در زمان ضروری است. در این مطلب ، نحوه کاهش image کانتینر برنامه های Go خود را با استفاده از Docker بررسی خواهیم کرد.یک برنامه با زبان Golang داریم به صورت زیر:از پکیج httprouter استفاده کردیم تا از دستور go mod download در dockerfile استفاده کنیم.یک Dockerfile میسازیم: این Dockerfile رو با تگ example:initial بیلد میکنیم: این image ایی که بیلد کردیم سایزش 337 مگ شد. حالا باید Dockerfile رو بهتر کنیم:ساخت مولتی استیج به ما کمک می کند تا چیزهای بی اهمیت را در image پایه رها کنید و شروع به استفاده از یک image جدید برای اجرای برنامه های خود کنیم.FROM golang:1.17.3-alpine3.14 as baseهمانطور که می بینیم، می توانیم برای استیج های خودمون نام بذاریم، بنابراین اگر می خواهیم چیزهایی را از آن استیج کپی کنیم، می توانید نام استیج را در خط COPY وارد می کنیم.می توانیم از یکdistroless image به عنوان image رانر خودمون برای کوچکتر کردن image خود استفاده کنید. همچنین برای برخی از زبان های برنامه نویسی دیگر نیز موجود است. با توجه به مستندات آن:“Distroless” images contain only your application and its runtime dependencies. They do not contain package managers, shells or any other programs you would expect to find in a standard Linux distribution.در مورد مثالی که از فلگ CGO_ENABLED=0 استفاده می‌کنید، می‌توانید از gcr.io/distroless/static به عنوان یک image رانر استفاده کنید. اما اگر نیاز دارید که فلگ ها روشن باشند، باید از gcr.io/distroless/base با مراجعه به اسناد استفاده کنید.بیایید دوباره بیلد کنیم و آن را به این صورت تگ میگذاریم example:multistageبیاید باز هم image را بهتر کنیم:ابزار UPX به ما کمک می کند اندازه باینری خودمون را کمتر کنیم، و تنها مختص برنامه های Go نیست. می توانید UPX را در خط 4 نصب کنید و برای استفاده از کش سازنده، دستور UPX را در خط 13 اجرا کنید. upx -9 به این معنی است که می خواهیم بهتر فشرده سازی کنیم، می توانید با استفاده از upx -h فلگ های موجود را ببینید.داکرفایل خودمون رو با تگ example:with-upx بیلد میکنیم:استفاده از Go Flags:برای غیرفعال کردن symbol table و DWARF generation که قرار است دیتا هایی برای دیباگ ایجاد کند، فلگ های -ldflags "-s -w" را اضافه کنید. با استفاده از دستور go tool link -h می توانید سایر گزینه های موجود را مشاهده کنید.بیایید dockerfile جدید رو با تگ example:latest بیلد کنیم:همچنین می‌توانید از مراحل این مطلب برای بیلد image کانتینر دیگری در کنار برنامه‌های Go استفاده کنید. به خصوص بیلد چند استیجی ای که بیش از نیمی از اندازه image را کاهش می دهد. اما با این حال، فقط شما می دانید چه چیزی برای شما بهترین است.منابع: https://jmrobles.medium.com/gos-best-friend-upx-the-executable-compressor-e4f4872f1d8ahttps://medium.com/@treeder/multi-stage-docker-builds-for-creating-tiny-go-images-e0e1867efe5a علی قایینی علی قایینی Tue, 25 Jan 2022 13:21:18 +0330 https://virgool.io/golangpub/%D8%A7%D9%84%DA%AF%D9%88%DB%8C-circuit-breaker-%D8%AF%D8%B1-%D8%A7%D8%B1%D8%AA%D8%A8%D8%A7%D8%B7%D8%A7%D8%AA-%D9%85%DB%8C%D8%A7%D9%86-%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-aurdszudvg6a نیاز ارتباط با سرویس های دیگر در داخل هر نرم افزاری یک امر اجتناب ناپذیر و معمول هست. تفاوت مهم ارتباطات داخلی با ارتباط با سرویس های خارجی این هست که ممکن هست درخواست ما با خطا مواجه شود یا کلا پاسخی دریافت نکند. حالا اگه سرویس ما کاربران زیادی داشته باشد این انتظار های طولانی برای دریافت جواب باعث می شود منابع سخت افزاری سرویس ما پر شده و سرویس ما هم نیز دیگر توان پاسخ به درخواست های دیگران را نداشته باشد. حالا اگر سرویس دیگری به سرویس ما وابسته باشد به همین طریق آن سرویس نیز توان پاسخ گویی خودش را از دست می دهد و همینطور مانند دومینو همه سرویس ها از کار می افتند. در این جا Circuit Breaker به کمک ما می آید.الگوی Circuit Breaker چیست ؟روش کار در circuit breaker ساده است. تمام ارتباطات ما با سرویس های دیگر باید از circuit breaker ما رد شود، که بتواند خطا ها را کنترل می کند. هنگامی که خطا ها به یک تعداد مشخص رسید، circuit breaker جریان را متوقف می کند و تمام ارتباطات بعدی با circuit breaker بدون اینکه ارتباطی برقرار شود، با خطا بر می گردند.انواع وضعیت در Circuit Breakerقطع کننده مدار دارای سه وضعیت است: بسته (Close)، باز (Open) و نیمه باز (Half-Open)بسته (Close): وقتی همه چیز عادی است، circuit breaker در حالت بسته باقی مانده و تمام ارتباطات به سرویس ها منتقل می شوند. هنگامی که تعداد خرابی ها از یک تعداد از پیش تعیین شده بیشتر شود، circuit breaker به حالت Open می رود.باز (Open): در این وضعیت circuit breaker برای ارتباطات بدون اجرای واقعی ارتباط، خطا برمی گرداند.حالت نیمه باز (Half-Open): پس از مدت زمانی circuit breaker به حالت نیمه باز سوئیچ می شود تا وجود خطا را بررسی کند. اگر در این حالت تنها یک ارتباط خراب شود، یکبار دیگر circuit breaker قطع می شود. در صورت موفقیت ، circuit breaker مجدداً به حالت بسته و طبیعی بر می گردد.پیاده سازی در Golangاین الگوی در Golang را میتوان با استفاده از gobreaker به شکلی ساده پیاده سازی کرد.ابتدا با دستور زیر gobreaker را دریافت می کنیم.go get github.com/sony/gobreakerاگه بخوایم تکه کد بالا رو بررسی کنیم در خط ۲ برای broker یک نام انتخاب کردیم.‍‍st.Name = &quotHTTP GET&quotدر خط بعدی (۳) با یک تابع مشخص کردیم در چه صورت circuit breaker ما باز شود و دیگر ریکوست از آن عبور نکند.‍‍st.ReadyToTrip = func(counts gobreaker.Counts) bool { failureRatio := float64(counts.TotalFailures) / float64(counts.Requests) return counts.Requests >= 3 && failureRatio >= 0.6 } که در این مثال ما یک نسبت ریکوست هایی که موفق نشد به تعداد کل گرفتیم که اگه 60 درصد یا بیشتر ریکوست ها موفق نشده باشند circuit breaker باز شود و دیگر ریکوست زده نشود.در خط ۸ ام به بعد تنظیماتی که انجام دادم رو برای gobreaker ارسال میکنیم و تابع ارسال درخواست http خودمان را می نویسیمcb = gobreaker.NewCircuitBreaker(st) body, err := cb.Execute(func() (interface{}, error) { resp, err := http.Get(&quothttp://example.com&quot) if err != nil { return nil, err } return resp, nil })این یک مثال ساده از پیاده سازی circuit breaker در Golang بود این پترن در زبان های دیگر هم پیاده سازی شده که میتونید از آن ها استفاده کنید. gobreaker github: https://github.com/sony/gobreakerمنابع:CircuitBreaker (martin fowler)Circuit Breaker Pattern علی قایینی علی قایینی Tue, 23 Mar 2021 23:35:14 +0430 https://virgool.io/@develop/%D8%A7%D9%84%DA%AF%D9%88%DB%8C-saga-%D8%AF%D8%B1-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-microservices-gsqei1ultkq6 تراکنش ها (Transaction) بخش اساسی اپلیکیشن ها هستند. بدون آنها، حفظ ثبات اطلاعات (data consistency) غیرممکن خواهد بود. یکی از انواع تراکنش ها Two-Phase Commit نامیده می شوند. که به طور خلاصه انجام اولین تراکنش به اتمام دومین تراکنش بستگی دارد. به طور مثال ثبت سفارش به این بستگی دارد که از موجودی انبار نیز کم شود.هنگامی که با میکروسرویس کار می کنید، پیچیده تر می شود. هر سرویس دارای دیتابیس مختص خود است و دیگر نمی توان از Two-Phase Commit برای حفظ ثبات اطلاعات کل سیستم خود استفاده کنید.هنگامی که این توانایی را از دست می دهید، دیتابیس های RDBMS گزینه مناسبی برای ذخیره سازی محسوب نمی شود ، به همین دلیل است که اکثر شرکت هایی که با میکروسرویس کار می کنند از NoSQL نیز استفاده می کنند.برای توضیح بیشتر این مشکل، معماری Microservices سیستم فروشگاهی زیر را در نظر بگیرید:در مثال بالا شما نمی توانید تمام عملیات های پرداخت، بروز رسانی موجودی انبار و ارسال به سیستم تحویل را در یک تراکنش ACID انجام دهید. به دلیل توزیع شده بودن سیستم نیاز به تراکنشی در محیط توزیع شده داریم.الگوی ‌‌SAGA:الگوی SAGA دنباله ای از تراکنش ها است. که هر تراکنش را در یک سرویس به روز می کند. تراکنش اول توسط یک درخواست خارجی متناسب با عملکرد سیستم آغاز می شود و سپس هر مرحله بعدی با اتمام مرحله قبلی انجام می شود.الگوی saga با استفاده از مثال بالا به شکل زیر است.برای اجرای saga ، روش های مختلفی وجود دارد، اما محبوب ترین آن ها عبارتند از:روش اول (Events/Choreography): هنگامی که هیچ هماهنگ کننده ای وجود ندارد، هر سرویس رویدادهای (event) تولید می کند که سرویس دیگر به آن گوش می دهد و تصمیم می گیرد که آیا اقدامی باید انجام دهد یا نه.روش دوم (Command/Orchestration): وقتی یک سرویس هماهنگ کننده مسئولیت متمرکز کردن تصمیم گیری saga و توالی منطق کسب و کار را بر عهده دارد. روش Choreography:در این روش ، هر تراکنش هنگام انجام کار خود رویدادی را منتشر می کند. تراکنشی دیگر که این رویداد را دریافت می کند رفتار مناسب را انجام می دهد. کار وقتی تمام می شود که تمام تراکنش ها انجام شود.در Choreography این فرآیند و ارتباطات توسط خود تراکنش ها اداره می شود.مزایای Choreography:پیاده سازی آسان و سادهاگر تعداد تراکنش ها کم باشد، مناسب است.مناسب سازمان های چابک (agile)معایب Choreography:وقتی تعداد تراکنش ها افزایش می یابد بسیار پیچیده می شود.ممکن است باعث ایجاد وابستگی در بین سرویس ها شود.روش Orchestration:در این روش، یک سرویس جداگانه وجود دارد که کل فرایند را هماهنگ می کند. این سرویس مدیریت می کند که چه زمانی کدام سرویس اجرا شود. اگر یکی از تراکنش ها به دلایلی از کار بیفتد Orchestrator مسئولیت برگشت (rollback) تراکنش هایی قبلاً انجام شده را بر عهده دارد.مزایای Orchestration:پیاده سازی آسان و سادهدرک ساده و نگهداری آسان.افزایش تعداد تراکنش ها باعث افزایش پیچیدگی نمی شود.معایب Orchestration:تمام منطق کسب و کار در Orchestration نوشته می شود. انتخاب اینکه از کدام روش استفاده کنیم بستگی به سازمان و نیاز سیستم است.منابع:Microservice Integration — SAGA PatternSaga Pattern | Application Transactions Using MicroservicesA Closer Look at the Saga Pattern in Microservices علی قایینی علی قایینی Fri, 28 Aug 2020 12:09:48 +0430 https://virgool.io/@develop/%D9%86%DA%A9%D8%A7%D8%AA-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%AF%DB%8C%D8%AA%D8%A7%D8%A8%DB%8C%D8%B3-%D8%AF%D8%B1-mongodb-p52o7hfvklpp دیتابیس مونگو یک پایگاه داده محبوب است که اجازه می‌دهد بدون اجبار از پیروی schema خاصی، داده‌ها ذخیره شوند.داده‌ها در قالب JSON ذخیره می‌شوند و می‌توانند شامل ساختارهای مختلفی باشند. به‌عنوان مثال در یک collection می‌توانیم دو document زیر را داشته باشیم:برای به‌دست آوردن بهترین نتیجه از MongoDB، باید اصول طراحی دیتابیس را بدانیم. قبل از مراجعه به برخی نکات طراحی دیتابیس، باید بدانیم که MongoDB چگونه داده‌ها را ذخیره می‌کند.چگونه داده ها در MongoDB ذخیره می شوند؟اگر از دیتابیس‌های RDBMS نظیر SQL Server، PostgreSQL، MySQL به سمت MongoDB آمده‌اید احتمالاً مفاهیم مثل table و row و column را در ذهن دارید. این مفاهیم در MongoDB وجود ندارند و داده‌ها در collections و documents‌ها ذخیره می‌شوند.تصویر زیر ساختار MongoDB را با RDBMS‌ها مقایسه می‌کند.مقایسه مفاهیم MongoDB و RDBMSنکات و ترفندهای طراحی دیتابیستفاوت Normalization با Denormalization:با توجه به این که MongoDB با document کار می‌کند، درک مفاهیم Normalization و Denormalization بسیار مهم است. این دو روش نحوه ذخیره داده‌های MongoDB را تعریف می‌کنند.تعریف Normalization – به معنای ذخیره داده‌ها در چندین collection با رفرنس‌دهی بین آن‌ها است. داده‌ها یک بار تعریف می‌شوند و آپدیت را ساده‌تر می‌کنند. وقتی صحبت از خواندن داده‌ها می‌شود، نقطه ضعف normalization به چشم می‌آید. اگر می‌خواهید داده‌ها را از چندین collection دریافت کنید، باید چندین کوئری (Query) بزنید. در نتیجه عملیات خواندن کندتر انجام می‌گیرد.تعریف Denormalization – تعداد زیادی داده را در یک document به صورت تو در تو ذخیره می‌کند. این مدل عملیات خواندن عملکرد بهتری خواهد داشت اما در اینزرت (Insert) و آپدیت‌ها کندتر خواهد بود. این روش ذخیره داده‌ها فضای بیشتری را برای ذخیره‌سازی اشغال می‌کند.برای انتخاب یکی از روش‌ها بالا باید به موارد زیر توجه کرد.اگر دیتابیسی دارید که نیازی به به‌روزرسانی منظم ندارد، دارای document‌های کوچک است که اندازه آن به آهستگی رشد می‌کند، اجرای سریع بروزرسانی آنچنان مهم نیست، اما برای خواندن به عملکرد خوبی نیاز دارید، پس denormalization ممکن است انتخاب خوبی باشد.اگر دیتابیس شما دارای document‌های بزرگی است که دارای به روزرسانی مداوم است و می‌خواهید عملکرد خوبی در نوشتن داشته باشید، پس normalization ممکن است انتخاب خوبی باشد.روابط یک به چند (One-to-N)مدل‌سازی روابط “یک به چند” در MongoDB نسبت به RDBMS ظریف‌تر است. کسانی که تازه به سراغ MongoDB آمده‌اند، به سراغ ذخیره آرایه‌ای از داده‌ها در جدول Parent می‌روند و این همیشه بهترین راه حل نیست. همانطور که در اولین نکته مشاهده کردیم، دانستن زمان استفاده از normalization یا denormalization بسیار مهم است. بنابراین قبل از هر چیزی باید بدانیم منظور از چند در عبارت “یک به چند” دقیقاً چه می‌باشد؟ تعداد کم، زیاد یا خیلی زیاد؟ هر رابطه یک روش مدل‌سازی متفاوت خواهد داشت.برای مثال برای ذخیره‌سازی رابطه “یک به تعداد کمی” بهترین روش ذخیره به صورت تو در تو است. به فیلد addresses در document زیر توجه کنید.در رابطه “یک به چند” دو collection را در نظر می‌گیریم. collection  محصولات و collection قطعات. هر محصول با استفاده از “ObjectID” به قطعات خود اشاره می‌کند.دیگر نکات در طراحی دیتابیسایندکس گذاریبرای حفظ عملکرد خوب دیتابیس خود، باید یک ایندکس گذاری خوب پیاده سازی کنید که عملکرد نوشتن و خواندن شما را سریع‌تر می‌کند. دانستن مزایا و محدودیت‌های ایندکس گذاری برای MongoDB در انجام این کار بسیار مهم است. به خاطر داشته باشید که MongoDB در نگهداری document‌ها برای یک مرتب سازی، محدودیت ۳۲MB دارد. اگر از ایندکس استفاده نکنید، دیتابیس مجبور می‌شود ضمن مرتب سازی، مقدار زیادی از document‌ها را نگه دارد. اگر MongoDB به این محدودیت برخورد کند، سپس دیتابیس خطا یا یک مجموعه خالی را بر می‌گرداند.اتمی بودن (Atomicity)اتمی در دیتابیس به این معنی است که کل عملیات‌ها باید به عنوان یک عملیات واحد به‌طورکلی از بین برود یا موفق شود. اگر تراکنش والدین دارای بسیاری از عملیات‌های فرعی باشد، حتی اگر یک عملیات نیز انجام نشود کل عملیات‌ها شکست می‌خورند. عملیات‌ها در MongoDB در سطح document انجام می‌شوند. هیچ عملیات نوشتنی نمی‌تواند بیش از یک document را تحت تأثیر قرار دهد. این‌ها به عنوان عملیات جداگانه‌ای رفتار می‌کنند. یک عملیات نوشتن تنها می‌تواند داده‌ها را برای یک موجودیت اینزرت یا آپدیت کند. از این رو، این عملیات نوشتن اتمی را تسهیل می‌کند.با این حال، ساختارهایی که ارائه‌دهنده اتمی بودن در عملیات اینزرت هستند ممکن است برنامه را برای استفاده از داده‌ها محدود کنند. همچنین ممکن است روش‌های تغییر برنامه محدود شود. برای طراحی دیتابیسی انعطاف پذیر باید به نکته اتمی بودن نیز دقت شود.ایجاد collection با document های بزرگمونگو اجازه می‌دهد که document‌های بزرگ تا ۱۶ مگابایت در collection قرار گیرند. اما پشتیبانی از document‌های بزرگ به این معنی نیست که ذخیره این حجم از داده داخل یک document ایده خوبی است. اگر document جداگانه‌ای به اندازه چند کیلوبایت نگه دارید، MongoDB به بهترین وجه کار می‌کند. document بزرگ باعث ایجاد چندین مشکل در عملکرد خواهد شد.برای درک بهتری از 16 مگابایت این کتاب جنگ جهانی تنها 360 کیلوبایت حجم دارد.نتیجه گیریبرای درک کامل از MongoDB همراه با داشتن دید کامل از آنچه می‌خواهید با MongoDB پیاده کنید، این دو کمک بسیار زیادی در طراحی مناسب دیتابیس می‌کنند.منابع:۱ - MongoDB Design: Tips AND Tricks۲ - MongoDB Data Modeling with Document Structure۳ - Things I Wish I’d Known When Starting with MongoDB علی قایینی علی قایینی Sat, 11 Jul 2020 12:59:40 +0430 https://virgool.io/@develop/%D8%A7%D8%AD%D8%B1%D8%A7%D8%B2-%D9%87%D9%88%DB%8C%D8%AA-%D9%88-%D8%AF%D8%B3%D8%AA%D8%B1%D8%B3%DB%8C-%D9%87%D8%A7-%D8%AF%D8%B1-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-microservice-s2dlom8saxwu معماری میکروسرویس مزایای بسیاری را برای اپلیکیشن از جمله تبدیل تیم های بزرگ به تیم های کوچک توسعه ، چرخه های توسعه کوتاه تر، انعطاف پذیری در انتخاب زبان و قابلیت مقیاس پذیری بیشتر را فراهم می کند.از طرفی با بسیاری از مشکلات پیچیده سیستم های توزیع شده نیز مواجه می شویم. یكی از این چالش ها نحوه پیاده سازی احراز هویت (authentication) و دسترسی ها (authorization) به صورت ایمن و كارآمد در معماری میکروسرویس است. در این مطلب سعی می کنیم در مورد این موضوع صحبت کنیم.تفاوت بین احراز هویت و دسترسی هااحراز هویت (authentication) مشخص می کند شما چه کسی هستید و شما می توانید با نام کاربری و رمز عبور از اپلیکیشن استفاده کنید.دسترسی ها (authorization) مشخص می کند که کاربر چه کاری می تواند انجام دهد به طور مثال آیا دسترسی ویرایش پست ها را دارد یا ندارد.احراز هویت و دسترسی ها در مونولیتیکدر معماری مونولیتیک تمام اپلیکیشن در داخل یک پروسه کار ها را انجام می دهند که وظیفه احراز هویت و مدیریت دسترسی ها به عهده ماژول اعتبار سنجی هست.بعد از لاگین کاربر ماژول اعتبارسنجی اطلاعات کاربر را بررسی می کند و پس از تایید شدن هویت کاربر یک session به همراه یک شناسه یکتا برای کاربر ساخته می شود. و در داخل session اطلاعات مربوط به کاربر را مانند نام کاربر ، نقش و دسترسی را وارد می کند. سرور شناسه session را به سمت کلاینت بر می گرداند. کلاینت شناسه را در داخل یک کوکی ذخیره می کند و در درخواست های بعدی آن را به برنامه ارسال می کند. سپس اپلیکیشن می تواند از شناسه session برای تأیید هویت کاربر استفاده کند ، بدون نیاز به وارد کردن نام کاربری و رمز عبور برای تأیید اعتبار در هر بار.احراز هویت در پروژه مونولیتیک مشکلات احراز هویت و دسترسی در میکروسرویسدر معماری میکروسرویس، یک اپلیکیشن به چندین میکروسرویس مجزا تقسیم می شود و هر میکروسرویس منطق یک ماژول در اپلیکیشن مونولیتیک پیاده سازی می کند. پس از تقسیم شدن کار ها ما نیاز به احراز هویت در میکروسرویس هایی که کاملا از هم جداگانه کار می کنند داریم. اگر از معماری مونولیتیک به میکروسرویس مهاجرت کنیم با مشکلات زیر در زمینه احراز هویت مواجه می شویم.منطق احراز هویت و دسترسی باید در هر میکروسرویس انجام شود و این بخش از منطق کلی باید در هر میکروسرویس به طور مکرر پیاده سازی شود.میکروسرویس باید بر محوریت یک منطق کسب و کار باشد به طور مثال میکروسرویس سفارشات فقط وظیفه حوزه سفارشات را به عهده دارد پس منطق احراز هویت و دسترسی نباید در میکروسرویس ها موجود باشد. در پروتکل HTTP سرور می تواند درخواست های مشتری را به هر node در cluster در صورت لزوم ارسال کند. stateless بودن HTTP مزیت حفظ تعادل بار را به ما می دهد. می توان درخواست های کاربر را در هر سرور توزیع کرد. برای سرویس هایی که نیازی به تأیید اعتبار ندارند ، مانند مرور صفحات خبر ، مشکلی وجود ندارد. با این حال ، بسیاری از خدمات ، از جمله خرید آنلاین و سیستم های مدیریت شرکت ، نیاز به تأیید هویت کاربر دارند. بنابراین ، لازم است که وضعیت ورود کاربر را به روشی بر اساس پروتکل HTTP ذخیره کنید تا از نیاز کاربر برای انجام تأیید برای هر درخواست ، جلوگیری شود. روش سنتی استفاده از یک session در سمت سرور برای مشخص شدن وضعیت کاربر است اما این مسئله بر گسترش افقی (horizontal expansion) سرور تأثیر می گذارد.احراز هویت و دسترسی در معماری میکروسرویس پیچیده تر است، از جمله دسترسی کاربران به میکروسرویس ها، دسترسی شخص ثالث (third-party) میکروسرویس ها و دسترسی میکروسرویس ها به یک دیگر.راه حل های احراز هویت و دسترسی در میکروسرویس۱ - استفاده session توزیع شده:به منظور استفاده کامل از مزایای معماری میکروسرویس و دستیابی به مقیاس پذیری و انعطاف پذیری میکروسرویس ها نیاز است یکی از روش های زیر برای مدیریت سشن ها انتخاب شود.روش اول - sticky session: در این روش اطمینان حاصل می کنیم که کلیه درخواست های یک کاربر خاص به همان سرور ارسال شده که اولین درخواست مربوط به آن کاربر را دریافت کرده است، بنابراین اطمینان حاصل می کند که داده های سشن همیشه برای کاربر خاصی صحیح است. با این حال ، این راه حل بستگی به متعادل کننده بار (load balancer) دارد وقتی متعادل کننده بار به هر دلیلی مجبور شود درخواست کاربر را به سرور دیگری ارسال کند، تمام داده های جلسه کاربر از بین می رود.روش دوم - session replication: در این روش هر سشن که ذخیره می شود از طریق شبکه در تمام سرور ها همگام سازی می شود. همگام سازی سشن باعث اشغال شدن پهنای باند شبکه می شود. زمانی که داده های سشن تغییر می کند ، داده ها باید برای همه سرور های دیگر همگام سازی شوند. هرچه موارد بیشتر باشد ، همگام سازی پهنای باند شبکه بیشتری اشغال می شود.روش سوم - centralized session storage: در این روش وقتی کاربر به یک میکروسرویس دسترسی پیدا می کند، می توانید داده های کاربر را از محل ذخیره سشن مشترک بدست آورد که کلیه میکروسرویس ها می توانند داده های سشن مشابه را بخوانند. نقطه ضعف این راه حل این است که ذخیره سازی جلسات مشترک به یک مکانیسم محافظت خاص نیاز دارد و بنابراین باید از طریق یک روش مطمئن به آنها دسترسی پیدا کنید.۲ - استفاده از توکن در سمت کاربر:روش سنتی استفاده از یک سشن در سمت سرور برای ذخیره وضعیت کاربر است. از آنجا که سرور stateful است، تأثیر آن بر گسترش افقی سرور است. توصیه می شود برای ذخیره وضعیت ورود کاربر در معماری میکروسرویس از توکن استفاده کنید.تفاوت اصلی بین توکن و سشن در ذخیره سازی متفاوت است. سشن ها در سرور ذخیره می شوند. توکن ها توسط خود کاربر نگهداری می شوند و به طور معمول به صورت کوکی در مرورگر ذخیره می شوند. توکن اطلاعات هویت کاربر را در اختیار دارد و هر بار که درخواست به سرور ارسال می شود ، بنابراین سرور می تواند هویت کاربر را تعیین کند و مشخص کند که آیا به جای درخواست شده دسترسی دارد یا خیر.توکن برای نشان هویت کاربر است. بنابراین برای جلوگیری از جعل توسط کاربر، باید محتوای توکن رمزگذاری شود. JWT یک استاندارد (RFC 7519) است که ساختار توکن و محتوی توکن را تعریف می کند ، آن را رمزگذاری می کند و برای زبان های مختلفی کتابخانه دارد. نمونه ای از jwt توکن را در قسمت زیر مشاهده میکنیم.eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6MTIzLCJuYW1lIjoiTWVuYSBNZXNlaGEiLCJpc19hZG1pbiI6dHJ1ZSwiZXhwaXJlIjoxNTU4MjEzNDIwfQ.Kmy_2WCPbpg-aKQmiLaKFLxb5d3rOC71DHexncH_AcQdبا استفاده از توکن برای تأیید اعتبار کاربر، سرور وضعیت کاربر را ذخیره نمی کند. کاربر باید با هر درخواست توکن را برای تأیید اعتبار به سرور ارسال کند.تأیید اعتبار کاربر با توکن به شرح زیر است:۳ - روش Single sign-on:ایده Single sign-on ساده است ، یعنی کاربران فقط باید یک بار وارد برنامه شوند ، سپس می توانند به کلیه خدمات در میکروسرویس ها دسترسی پیدا کنند. این راه حل بدین معنی است که هر میکروسوریس باید مانند میکروسرویس زیر با میکرو سرویس تأیید اعتبار ارتباط برقرار کند:این می تواند باعث ایجاد ترافیک بسیار زیاد شبکه شود. هنگامی که ده ها میکروسرویس وجود دارد، اشکالاتی در مورد این راه حل خودشون رو نشون میدن.۴ - استفاده از توکن در سمت کاربر به همراه API Gateway:مراحل احراز هویت کاربر مشابه روش دوم است. تفاوت در این است که API Gateway به عنوان ورودی درخواست خارجی اضافه می شود. این یعنی که همه درخواست ها باید از API Gateway رد بشوند.در این حالت خروج از سیستم مشکلی ایجاد نمی کند زیرا API Gateway می تواند هنگام خروج از سیستم توکن کاربر را از بین ببرد.نتیجه گیری:چند روش پیاده سازی احراز هویت معماری میکروسرویس رو با هم بررسی کردیم که هرکدوم مزایا و معایب خاص خودشون را داشتند. اگه بخوایم از روش های فوق نتیجه گیری کنیم احتمالا به ساختار زیر خواهیم رسید:امیدوارم که این مطلب مفید بوده باشه.منابع :‌Authentication and Authorization of End User in Microservice ArchitectureMicroservices Authentication and Authorization Solutions علی قایینی علی قایینی Fri, 19 Jun 2020 23:35:47 +0430 https://virgool.io/@develop/%DB%B5-%D8%A7%D8%B4%D8%AA%D8%A8%D8%A7%D9%87-%D8%AF%D8%B1-%DB%8C%D8%A7%D8%AF%DA%AF%DB%8C%D8%B1%DB%8C-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-microservice-qtg0pa4evoca هنگامی که ما در حال یادگیری یک تکنولوژی جدید هستیم. ما همیشه به آنچه که قبلا در پروژه‌های گذشته تجربه کرده‌ایم تکیه می کنیم. به همین دلیل با پیش فرض ذهنی خودمون بعضی چیز ها رو نتیجه گیری میکنیم که عمدتا درست از کار در نمیاد مخصوصا زمانی که در حال یادگیری یکی از جدیدترین و مهم ترین مفاهیم در حال حاضر هستیم یعنی میکروسرویس.در این مطلب ، ما در مورد پنج اشتباه اصلی که هنگام یادگیری موضوع میکروسرویس مرتکب می شویم بحث خواهیم کرد.اشتباه شماره ۱ : "شبیه هم پنداشتن SOA و میکروسرویس" اگرچه SOA و Microservice هر دو سبک معماری هستند ولی تفاوت های زیادی با هم دارند.معماری سرویس گرا (SOA)رویکرد آن، اتصال اپلیکشن های موجود از طریق یک نمونه ESB، از طریق پروتکل‌های ارتباطی مختلف است.اتصال و تحویل پیام بین نقاط نهایی باید در درون ESB انجام شود.سرویس داخل ESB باید با یک زبان نوشته شود و از پروتکل های ارتباطی HTTP استفاده کند. مانند: (rest, soap, ...) هزینه زیاد انتقال داده های بزرگ بین بخش ها با توجه به کد کردن و دیکد کردن آن ها.مقیاس پذیری عمودی (Vertically scalable)وابستگی کل سیستم به ESBمعماری میکروسرویس (Microservice)رویکرد آن ایجاد یک اپلیکشن است که می تواند در یک محیط جدا شده با بانک اطلاعاتی خود اجرا شود.سرویس ها به طور مستقیم باهم ارتباط برقرار می کنند از این طریق میکروسرویس می تواند به یک رویداد خاص دریافت شده پاسخ دهد.میکروسرویس را می توان به هر زبان برنامه نویسی (جاوا ، پایتون ، جاوا اسکریپت و پی اچ پی و ...) نوشت.قرارداد های Rest را دنبال می کند و امکان استفاده از پروتکل های ارتباطی باینری مثل Google protobuf یا Twitter Finagle وجود دارد.مطابقت با فیچر های پروژه مونولتیک فعلی.تاب‌آوری در رویداد خطا (Fault tolerance).مقیاس پذیری افقی (Horizontally scalable).میکروسرویس ها خود را در API Gateway ثبت می کنند و بطور خودکار توسط میکرو سرویس های دیگر پیدا می شوند.اشتباه شماره ۲: "اگر من از REST استفاده کنم، پس میکروسرویس دارم"در معماری میکروسرویس رویکرد ارتباط با rest تنها یکی از ویژگی های اصلی است. برای اینکه یک برنامه به عنوان یک راه حل میکروسرویس ارائه شود باید تمام خصوصیات توصیف شده با ۱۲ عامل را داشته باشد.اشتباه شماره ۳: "میکروسرویس ها می توانند در همان کانتینر اجرا شوند"میکروسرویس باید: با تمام منابع لازم در محیط خود کاملاً منزوی کار کند.کاملا مستقل عمل کند.امکان دنبال کردن و trace کردن را داشته باشد.میکروسرویس های دیگر باید به صورت خودکار آن را پیدا کنند.این ها برای حفظ مقیاس پذیری مناسب و تاب‌آوری در رویداد خطا ضروری هستند.اشتباه ۴: "همه میکروسرویس باید با یک زبان برنامه‌نویسی نوشته شوند"هنگامی که میکروسرویس ها روی کانتینر های مختلف کار می کنند و کار های مربوط به خودشان را انجام می دهند نیازی به اجرای کار های خرد به یک زبان برنامه نویسی خاص نیست و با توجه به نیاز هر میکروسرویس میتوان یک زبان برنامه نویسی را انتخاب کرد.با توجه به این موضوع، می‌توانید تیم‌های کوچک‌تر، هر یک با تخصص خاص از عملکرد کسب‌وکار و زبان‌های برنامه‌نویسی، برای تسهیل در تکامل راه‌حل های کسب‌ و کار به طور مستقل فعالیت داشته باشند.اشتباه شماره ۵: "میکروسرویس ، همانطور که از نام آن پیداست ، باید کوچک باشد" میکرو در میکروسرویس منطق کسب‌ و کار را که امروزه در برنامه مونولتیک وجود دارد ، نشان می دهد.کلمه میکرو راجب اندازه صحبت نمی کند راجب حداقل منطق کسب کار هست در مقایسه با کل منطق کسب و کار در مونولتیک.مشکلات کسب و کار به قطعات کوچکتر تقسیم می شود تا به راحتی کلیه درخواست های مربوط به هر مشکل کسب و کار مشخص شود.در این مطلب ۵ اشتباه را بررسی کردیم. آیا شما با اشتباهات دیگری برخورد کرده اید؟‌ علی قایینی علی قایینی Thu, 28 May 2020 20:51:39 +0430 https://virgool.io/@develop/%D8%A7%DB%8C%D9%86%D8%AF%DA%A9%D8%B3-%D8%AF%D8%B1-sql-%DA%86%DB%8C%D8%B3%D8%AA-%D9%88-%DA%86%DA%AF%D9%88%D9%86%D9%87-%DA%A9%D8%A7%D8%B1-%D9%85%DB%8C-%DA%A9%D9%86%D8%AF-gyvtapdguy5z "ایندکس باعث می شود کوئری ها سریع شود" این ساده ترین تعریف از ایندکس ها هست.با استفاده از عبارت ‍`create index‍` میتوانیم ایندکس بسازیم. با ساخت ایندکس یک کپی از داده ها در جای دیگر ساخته می شود که مانند فهرست یک کتاب به داده ها در داخل جدول اصلی اشاره دارند. توجه داشته باشید که هر ایندکس فضای ذخیره سازی مخصوص خودش را لازم دارد.جست و جو با کمک ایندکس مانند پیدا کردن شماره ای در دفتر تلفن است که با توجه به مرتب بودن شماره ها خیلی سریع شماره ها رو پیدا میکنیم اما ایندکس ها در دیتابیس پیچیده تر از یک دفترچه تلفن هستند زیرا به طور مداوم داده ها در حال تغییر (update, delete, insert) هستند و با این حال دیتابیس باید ایندکس ها رو مرتب نگه دارد.دیتابیس از دو ساختار برای پاسخگویی به این چالش استفاده می کند: doubly linked listThe Search Tree (B-Tree) این دو ساختار ، بیشتر ویژگیهای عملکرد دیتابیس را توضیح می دهند.هدف اولیه هر ایندکس فراهم آوردن یک نمایش منظم از داده‌های ایندکس است. ذخیره داده ها به صورت متوالی امکان پذیر نیست زیرا یک عبارت درج باید داده ها را جابجا کند تا فضای جدیدی را فراهم کند. انتقال مقادیر زیادی از داده بسیار زمان بر است بنابراین کوئری insert بسیار کند می شود. راه حل مسئله ایجاد نظمی منطقی است که مستقل از نظم فیزیکی در حافظه باشد.نظم منطقی از طریق یک لیست مضاعف (doubly linked list) مرتبط برقرار می شود. هر گره (node) به دو ورودی جدول پیوند دارد ، شبیه یک زنجیر. گره های جدید با به روز کردن پیوندهای آنها بین دو گره موجود وارد می شوند تا به گره جدید مراجعه کنند.نحوه ذخیره ایندکس در node های پایانیتصویر بالا نشان دهنده نحوه ذخیره ایندکسی است که روی ستون "column 2" گذاشته شده است اگر دقت کنید در ایندکس دیتای ستون "column 2" را داریم و در شناسه ی ردیف در جدول اصلی اشاره دارد.اما هنوزم دیتابیس نمیتواند به سرعت مقدار را پیدا کند و ردیف را برگرداند زیرا در این حالت دیتابیس باید بین تمام مقادیر ستون "column 2" جست و جو کند تا ردیف خواسته شده را پیدا کند. برای حل این مشکل دیتابیس ها از درخت جست و جو (‌B-tree) استفاده میکنند.در روش بالا دیتابیس با استفاده از قسمت بندی داده های ایندکس سریع تر به آن ها می رسند مانند یک درخت که یک تنه اصلی دارد و بعد شاخه های اصلی و بعد شاخه های ریز تر به این صورت به راحتی می توانیم به شاخه های کوچک تر برسیم. با استفاده از این روش هم تغییرات در ایندکس سریع تر انجام میشود و هم جست و جوی داده سریعتر به نتیجه میرسد.مثالی از پیدا کردن عدد 57در مثال بالا ما به دنبال عدد 57 میگردیم دیتابیس از گره های اول شروع میکند و به جلو میرود. در گره اول دیتابیس با سه عدد (39, 83, 98) مواجه میشود باید داخل گره ای شود که از 57 بزرگتر است پس 83 را انتخاب میکند در مرحله بعد با اعداد (46, 53, 57, 83) مواجه می شود داخل گره 57 می شود که حاوی اطلاعات 57 هم هست.مزیت ایندکس:افزایش قابل توجه سرعت کوئری های select.معایب ایندکس:کاهش سرعت کوئری های insert و update.اشغال بیشتر فضای حافظه.انواع ایندکس:ایندکس index (برای افزایش سرعت در جستجوی مقدار)ایندکس unique (علاوه بر افزایش سرعت در جستجوی مقدار، یکتا بودن مقدار ستون رو هم چک می کند) ایندکس full-text (برای افزایش سرعت در جستجوی مقدارهایی از جنس متون نسبتا طولانی)ایندکس spatial (برای افزایش سرعت در جستجوی مقدارهایی از جنس موقعیت های مکانی)ایندکس primary (کلید اصلی جدول هست و علاوه بر جلوگیری از ورود مقدار تکراری از ورود null ها هم جلوگیری میکند)خب تا اینجا متوجه شدیم ایندکس چی هست و چطوری کار میکند و انواع مختلفش چی هست در مطلب بعدی بررسی می کنیم کوئری هامون رو چگونه بنویسیم تا بیشترین بهره وری رو از ایندکس هامون داشته باشیم. علی قایینی علی قایینی Sun, 24 May 2020 14:34:48 +0430 https://virgool.io/@develop/%DA%86%D9%87-%D9%85%D9%88%D9%82%D8%B9-%D8%A7%D8%B2-%D9%85%D9%88%D9%86%DA%AF%D9%88-mongodb-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%DA%A9%D9%86%DB%8C%D9%85-rzceqcbiaz2v قبل از هر چیزی یک توضیح مختصر راجب مونگو بدیم:مونگو یک پایگاه داده سند گرا (document base) و مقیاس پذیر و NoSQL هست که به ما انعطاف پذیری بالایی میده تا اطلاعات خودمون رو بدون ساختار مشخصی ذخیره کنیم. هر ابجکت حاوی اطلاعات در مونگو داکیومنت (document) نام می گیرد و داکیومنت ها در داخل collection ذخیره می شوند به جای ذخیره اطلاعات در ستون ها و ردیف ها در دیتابیس های رابطه ای. تفاوت ذخیره اطلاعات در مونگو با دیتابیس های رابطه ایهدف مونگو ذخیره اطلاعات با عملکرد بالا و دسترس پذیری بالا هست. مونگو به راحتی نصب و راه اندازی میشه. مونگو برای ذخیره اطلاعات در داکیومنت ها از Json یا Bson استفاده میکنه.اگه با اصطلاحات مونگو آشنا نیستید‌ تصویر زیر ترجمه اصطلاحات مونگو به SQL Server را نشان میدهد:اصطلاحات در مونگوبرگردیم به بحث اصلی و بررسی کنیم چه زمانی مونگو رو انتخاب کنیم.مزیت ها: سند گرا (document base)عملکرد بالادسترسی بالا به وسیله (Replication)مقیاس پذیری بالا (Sharding)پویا بودن و بدون نیاز به ساختار از پیش تعیین شدهمنعطف بودن به جهت داشتن فیلد های متفاوت در هر داکیومنتعدم استفاده از join ارائه اطلاعات در فرمت JSON و BSONپشتیبانی از توابع و ایندکس های جغرافیایی (موقعیت های مکانی)زبان پرس و جوی سند گرا و با قدرت مشابه SQLمعایب:پیاده نشدن خاصیت ACID به خوبی دیتابیس های RDBMSوجود نداشتن function و stored procedureمونگو رو در چه پروژه هایی پیاده سازی کنیم؟وبلاگ ها و مدیریت محتواکاتالوگ محصولات فروشگاهلاگ با سرعت بالا و کش مدیریت پیکربندی (configuration)نگهداری اطلاعات بر پایه لوکیشن و موقعیت مکانیشبکه های اجتماعیجایی که ممکن است در آینده ساختار اطلاعات تغییر کند چه جاهایی از مونگو استفاده نکنیم؟ سیستم هایی که به تراکنش های زیادی (transactional systems) نیاز دارند.سیستم هایی که ساختار مشخص و ثابتی دارند.این یه مرور سریع برای استفاده کردن یا استفاده نکردن از مونگو بود که خیلی تیتر وار به مسائل پرداخته شد. علی قایینی علی قایینی Sun, 24 May 2020 00:08:29 +0430