.NET Tips | جستجوها: نتایج مشابه «آیا دنیای ما صرفا یک شبیه سازی کامپیوتری است؟!»، صفحه: ۵۲

مطالب دوره‌ها

تنظیمات امنیتی دسترسی به سرور RavenDB

تا اینجا اگر مباحث را دنبال کرده باشید، برای اتصال به RavenDB از اعتبارسنجی خاصی استفاده نشد و در حالت پیش فرض، بدون تنظیم خاصی، موفق به اتصال به سرور آن شدیم. بدیهی این مورد در دنیای واقعی به دلایل امنیتی قابل استفاده نیست و نیاز است دسترسی به سرور RavenDB را محدود کرد. برای مثال SQL Server حداقل از دو روش Windows authentication و روش توکار خاص خودش برای اعتبارسنجی دسترسی به داده‌ها استفاده می‌کند. اما RavenDB چطور؟

حالت پیش فرض دسترسی به سرور RavenDB

اگر فایل Raven.Server.exe.config را در یک ویرایشگر متنی باز کنید، یک چنین تنظیماتی در آن قابل مشاهده هستند:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="Raven/Port" value="*"/>
    <add key="Raven/DataDir" value="~\Database\System"/>
    <add key="Raven/AnonymousAccess" value="Admin"/>
  </appSettings>
<runtime>
<loadFromRemoteSources enabled="true"/>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="Analyzers;Plugins"/>
</assemblyBinding>
</runtime>
</configuration>

کلید Raven/AnonymousAccess چندین مقدار مختلف را می‌تواند داشته باشد، مانند Get ، All و None.
حالت پیش فرض دسترسی به RavenDB برای کاربران اعتبارسنجی نشده، حالت Get است (خواندن اطلاعات) و هیچگونه دسترسی تغییر اطلاعات آن‌را ندارند (حالت Read only). اگر این کلید به All تنظیم شود، کلیه کاربران، قابلیت Read و Write را خواهند داشت. حالت None به این معنا است که تنها کاربران اعتبارسنجی شده می‌توانند به دیتابیس دسترسی پیدا کنند.
اگر علاقمند هستید که مجوزهای یک کاربر متصل را مشاهده کنید، از فرمان ذیل استفاده نمائید:

 var json = ((ServerClient) store.DatabaseCommands).CreateRequest("GET", "/debug/user-info").ReadResponseJson();

نکته بسیار مهم
اگر مجوز RavenDB را نخریده باشید، مقدار Admin تنها مقداری است که در اینجا می‌توانید تنظیم کنید. به این معنا که کلیه کاربران، دسترسی Admin را به سرور خواهند داشت. (و بدیهی است فقط برای آزمایش سیستم مناسب است)
سعی در تنظیم حالت اعتبار سنجی زمانیکه از مجوز AGPL استفاده می‌کنید، با یک استثناء از طرف سرور متوقف خواهد شد.

Windows authentication

اعتبار سنجی پیش فرض مورد استفاده نیز Windows authentication است. به این معنا که تنها کاربری با دارا بودن اکانت معتبری بر روی سیستم و یا دومین ویندوزی، امکان کار با RavenDB را خواهد داشت. در این حالت کلیه کاربران دومین به سرور دسترسی خواهند داشت. اگر این حالت مطلوب شما نیست، می‌توان از گروه‌های ویژه کاربران تعریف شده بر روی سیستم و یا بر روی دومین ویندوزی استفاده کرد.
این تنظیمات باید بر روی دیتابیس System صورت گیرند، در قسمت Settings و حالت Windows authentication :

اعتبارسنجی OAuth

شاید دسترسی به سرور RavenDB همیشه از طریق Windows authentication مطلوب نباشد. برای این حالت از روش اعتبارسنجی سفارشی خاصی به نام OAuth نیز پشتیبانی می‌شود. این حالت به صورت توکار در سرور RavenDB پیاده سازی شده است و یا می‌توان با پیاده سازی اینترفیس IAuthenticateClient کنترل بیشتری را اعمال کرد. البته با دریافت افزونه Raven.Bundles.Authentication به یک نمونه پیاده سازی شده آن دسترسی خواهید داشت. پس از دریافت آن، فایل اسمبلی مربوطه را به درون پوشه افزونه‌های سرور کپی کنید تا آماده استفاده شود.

 PM> Install-Package RavenDB.Bundles.Authentication -Pre

کار با آن هم بسیار ساده است. ابتدا کلیدهای لازم را در سمت سرور، در قسمت تنظیمات بانک اطلاعاتی سیستم ایجاد کنید:

فایل کانفیگ سرور را برای افزودن سطر ذیل ویرایش کنید:

<add key="Raven/AuthenticationMode" value="OAuth"/>

سپس DocumentStore کلاینت به نحو ذیل باید آغاز شود:

 var documentStore = new DocumentStore
{
  ApiKey = "sample/ThisIsMySecret",
  Url = "http://localhost:8080/"
};

‫۱۱ سال و ۲ ماه قبل، جمعه ۲۲ شهریور ۱۳۹۲، ساعت ۱۶:۵۵

ابوالفضل روشن ضمیر

نظرات مطالب

بررسی برخی تغییرات در Angular 8

TypeScript 3.4.x Support

انگیولار 8، از (3.4) typescript و نگارش‌های بالاتر پشتیبانی می‌کند. اگر می‌خواهیم از انگیولار 8 برای App ‌های جدید استفاده کنیم، نیاز است typescript را به نگارش 3.4 و یا بالاتر ارتقاء دهیم.

Ivy Rendering Engine

یکی از مهمترین و مورد انتظارترین ویژگی‌های انگیولار 8، موتور IVY می‌باشد. IVY یک Angular Compiler جدید می‌باشد و هم چنین یک ابزار که به عنوان یک rendering pipeline جدید عمل می‌کند. مزیت Ivy این است که به طور قابل توجهی bundle‌های کوچکی را تولید می‌کند (سایز bundle‌ها را کاهش میدهد) و همچنین به آسانی می‌تواند کامپایل سریعی را انجام دهد. بنابراین Ivy، اساس نوآوری در دنیای انگیولار می‌باشد. Ivy در انگیولار 8 به صورت پیش نمایشی می‌باشد. هدف اصلی این نسخه این است که بازخورد‌ها را از جامعه توسعه دهندگان انگیولار، مرتبط با Ivy دریافت کند. پیشنهاد شده است که در این روزها از Ivy برای حالت ارائه‌ی نهایی (Production) استفاده نشود.

در ngconf سال 2019، (Brad Green)، هدایت کننده فنی تیم انگیولار گفت که در صورت استفاده از Ivy، از مزایای زیر برخوردار هستیم:

کامپایل سریعتری را فراهم می‌کند (انتشار در انگیولار 9)
بررسی type در قالب‌ها، خیلی بیشتر بهبود یافته است؛ به‌گونه‌ای که می‌توان خطاهای بیشتری را در زمان build گرفت که باعث می‌شود کاربران در زمان runtime به آن خطاها برخورد نکنند (انتشار در انگیولار 9).
bundle‌های با سایز کوچکتری در مقایسه با سایز bundle‌های کامپایل شده‌ی جاری
کد‌های تولید شده توسط Angular compiler، بسیار آسان‌تر، برای خواندن و درک انسان است.
آخرین و مهمترین ویژگی مورد علاقه من این است که می‌توان قالب‌ها (templates) را debug کرد. من یقین دارم که این ویژگی توسط تعداد زیادی از توسعه دهندگان مورد توجه قرار خواهد گرفت .

همانطور که در متن بالا گفته شده است اگر بخواهید در یک پروژه‌ی انگیولار، Ivy را شامل کنید، علاوه بر حالت گفته شده‌ی در متن‌، می‌توانید به صورت دستی تنظیم بالا را به پروژه‌ی انگیولار اضافه کنید (بعد از ارتقاء به انگیولار 8). پیشنهاد شده‌است که اگر می‌خواهیم از Ivy در Application ‌ها استفاده کنیم، Application را در حالت debug، همراه با AOT compilation اجرا کنید:

ng serve --aot

Bye Bye @angular/http

از نگارش 8 انگیولار، پشتیبانی از angular/http@ متوقف می‌شود. تا نگارش 7 انگیولار، امکان استفاده‌ی از angular/http@ برای ما فراهم بود؛ اما استفاده‌ی از angular/http@ منسوخ شده بود و در نگارش 4 انگیولار یک فراخوانی امن و کارآمد HTTP را با استفاده از angular/common/http@ فراهم کردند.

PNPM Support

در نگارش 8 انگیولار، پشتیبانی از یک package manager جدید به نام PNPM وجود دارد که شامل NPM و Yarn می‌باشد.

Support for New Builders/Architect API

نگارش جدید Angular CLI این اجازه را به ما می‌دهد که از نسخه‌ی جدید Builders که به عنوان Architect API شناخته می‌شود، استفاده کنیم. انگیولار از Builders API برای اجرای عملیاتی مثل server, build, test, lint و e2e استفاده می‌کند. در ضمن می‌توانیم از builders در فایل angular.json استفاده کنیم:

"projects": {  
  "app-name": {  
    "architect": {  
      "build": {  
        "builder": "@angular-devkit/build-angular:browser",  
      },  
      "serve": {  
        "builder": "@angular-devkit/build-angular:dev-server",  
      },  
      "test": {  
        "builder": "@angular-devkit/build-angular:karma",  
      },  
      "lint": {  
        "builder": "@angular-devkit/build-angular:tslint",  
      },  
      "e2e": {  
        "builder": "@angular-devkit/build-angular:protractor",  
      }  
    }  
  }  
}

‫۵ سال و ۳ ماه قبل، یکشنبه ۲ تیر ۱۳۹۸، ساعت ۲۲:۲۲

علی یگانه مقدم

مطالب

مروری بر Blazor (قسمت اول)

Blazer یک فریمورک جدید تحت وب هست که این امکان را به برنامه نویسان دات نت میدهد تا از طریق Open Web Standards بتوانند کدهای خود را در مرورگر اجرا و تجربه جدیدی از ساخت برنامه‌های تک صفحه‌ای را داشته باشند. در این نوشتار قصد داریم ساختار و نحوه کارکرد این فناوری را بررسی نماییم. قبل از هر چیزی به دوران قبل از ایجاد Web Assembly برمی‌گردیم :

همانطور که در شکل زیر می‌بینید، زمانی تنها جاوااسکریپت فرمانروای یک مرورگر محسوب می‌شد. در این حالت کدهای جاوااسکریپت به هر شکلی که نوشته شده باشند در اختیار parser قرار میگیرند و یک درخت از کدهای نوشته شده ایجاد شده و از طریق یک کامپایلر، کد‌ها به سطح پایین‌تری مشابه بایت کدها تبدیل می‌گردند و سپس از طریق یک مفسر دسترسی به بخش‌های مختلف api یک مرورگر در اختیار این کدها قرار میگیرند تا کار مورد نظر انجام شود.

در تصویر بعدی Web Assembly به بخش مفسر تزریق میشود و از طریق آن زبان‌های مختلف باید بر اساس Web Standard، به کدهای سطح‌های پایین‌تری کامپایل شوند. در اینجا این نکته مدنظر باشد که کدهایی که به سطح پایین‌تری کامپایل میشوند، تنها در داخل مرورگر شناخته شده میباشند و در خارج از دنیای وب قابل استفاده نیستند و نمیتوانند در سطح سیستم عامل قابل اجرا باشند. به همین جهت به شکل یک sandbox مورد استفاده قرار میگیرند و از این لحاظ، مشکلات امنیتی را در خارج از مرورگر ایجاد نمی‌کنند.

در شکل سوم Blazor که ترکیبی از نام Browser + Razor میباشد اضافه میشود. Blazor در اینجا وظیفه دارد محتوای فایل دریافتی را که شامل کدهای HTML و CSS و جاوااسکریپت است، به کدهای قابل فهمی برای مرورگر تبدیل کند. سپس mono وارد کار میشود. همانطور که می‌دانید mono جهت پشتیبانی از اجرای چندسکویی پروژه‌های دات نت اضافه شده که در اینجا هم همان وظیفه را منتها برای مرورگرهای مختلف، دارد. بدین جهت مونوی کامپایل شده بر روی Web Assembly قرار میگیرد تا کدهای دریافتی را تفسیر نماید. Blazor در اینجا dll‌های لازم را در mono بارگذاری میکند و سپس mono کدها را برای Web Assembly تفسیر میکند.

اگر در تصویر بالا درقت کنید دو فایل Blazor.js و mono.js نیز وجود دارند که یک ارتباط به صورت Introp layer با Web Assembly برقرار کرده‌اند. البته در حال حاضر این ارتباط توسط Web Assembly پشتیبانی نمی‌شود. در صورت پیاده سازی و پشتیبانی Web Assembly از این بخش، میتوان با جاوااسکریپت هم با آن ارتباط برقرار کرد و یک ارتباط دو طرفه‌ای بین کدهای js و دات نت برقرار نمود؛ بدین صورت میتوان در دات نت توابع js را صدا زد و در js توابع دات نت صدا زده شوند.

همچنین مایکروسافت تنها به استفاده از Web Assembly اکتفا نکرده و از طریق SignalR نیز این بستر را فراهم کرده است. با ایجاد یک سوکت به سمت سرور، تغییرات صفحه در سمت سرور، محاسبه و سپس بازگشت داده می‌شوند. در این حالت نیازی به ارسال فایل‌های dll نسبت به روش قبل نمی‌باشد. برای استفاده از این حالت میتوانید از بین گزینه‌های موجود در ایجاد پروژه، Blazor Server-side را مورد استفاده قرار دهید. البته این روش هم مزایا و معایب خودش را دارد.

جهت مقایسه این دو بخش به بررسی نکات مثبت و منفی میپردازیم:

1- در حالت استفاده از Web Assembly، حجمی حدود نزدیک به دو مگابایت بایدجابجا شود؛ ولی در حال سمت سرور، حجم صفحه حدود 100 کیلوبایت خواهد شد.

2- در حالت سمت سرور، تغییرات به دلیل رفت و برگشت به سرور با کمی تاخیر روبرو میشوند.

3- در حالت سمت سرور کارکرد آفلاین از دست میرود.

4- در حالت سرور، به دلیل اینکه همه کارها سمت سرور انجام میشود، ترافیک سرور را بالاتر میبرند.

5- استفاده از حالت سرور، معماری ساده‌تر و پیچیدگی‌های کمتری در سمت کلاینت دارد.

‫۵ سال و ۶ ماه قبل، جمعه ۱۶ فروردین ۱۳۹۸، ساعت ۲۳:۰۰

حیدری محمد

مطالب

سیستم‌های توزیع شده در NET. - بخش اول - نیازمندی

در حوزه کاری ما همیشه نیازمندی‌های جدید باعث پیشرفت، ارتقاء و پیچیده‌تر شدن سیستم‌های سخت افزاری و نرم افزاری می‌شوند. بطور مثال زمانیکه نیاز شد چندین سیستم از داده‌های مشترکی استفاده کنند، در معماری Single Tier قسمت Database از سایر قسمت‌ها جدا شد و در سخت افزار دیگری قرار گرفت. به این صورت این معماری تبدیل به Two Tier شد و سپس برای اینکه تغییرات، کمترین تاثیر را در سیستم ما داشته باشد و با کمترین هزینه به Platform‌های دیگر نیز سرویس بدهیم، قسمت Presentation از سایر قسمت‌ها جدا شد و در سخت افزارهای دیگری قرار گرفت. به این صورت تبدیل به معماری Three Tier شد و همینطور نیازهای جدید باعث شد معماری N Tier پیچیده‌تر شود. البته پیچیدگی که باعث تکامل آن شد یا بطور مثال نیاز به پردازش تعداد بیشتری عملیات بصورت همزمان، که باعث شد سیستم‌های ما از حالت Single Task تبدیل به Parallel System و سپس Distributed system شوند. واقعیت این است که در دنیای امروز، نیازهای جدیدی بوجود آمده‌اند؛ نیازهایی که یک سخت افزار به تنهایی قادر به ارائه راهکاری برای آنها نیست. واقعا یک سخت افزار که یک سرویس را ارائه می‌دهد، چه خصوصیاتی باید داشته باشد که مثلا در ثانیه حدود 50 میلیون عملیات را بصورت همزمان انجام دهد؛ یا مثلا سرویس مورد نظر حدود 400 میلیون کاربر فعال که روزانه بیشتر وقت خود را به استفاده از این سرویس اختصاص می‌دهند داشته باشد؟

آیا میدانستید که Facebook در حال حاضر بیشتر از 400 میلیون کاربر فعال دارد که حدود 200 میلیون از این کاربران هر روز از این سرویس استفاده می‌کنند؟ آماری که این سرویس داده به این صورت است که تا سال 2010، کاربرانش در هر روز حدود 16 بیلیون دقیقه از وقت خودشان را به استفاده از این سرویس اختصاص داده‌اند. در هر هفته کاربران این سرویس حدود 6 بیلیون مطلب را که شامل عکس و متن بوده را به اشتراک گذاشته‌اند. هر ماه بیشتر از 3 بیلیون عکس توسط این سرویس Upload شده‌است. کاربرانش روزانه بیشتر از 1 بیلیون عکس را توسط این سرویس مشاهده کرده‌اند. این سرویس در ثانیه حدود 50 میلیون عملیات را انجام می‌دهد!

آیا میدانستید که سرویس Twitter در حال حاضر 350 میلیون کاربر فعال دارد که حدود 100 میلیون از این کاربران روزانه از این سرویس استفاده می‌کنند و هر روز کاربران این سرویس 500 میلیون توییت را ارسال می‌کنند. این سرویس در فینال جام جهانی حدود 618,725 توییت را در یک دقیقه دریافت کرده‌است.
و یا سرویس Telegram حدود 100 میلیون کاربر فعال دارد که بصورت متوسط در هر روز 220 هزار کاربر جدید در آن ثبت نام می‌کنند. کاربران این سرویس روزانه 15 بیلیون پیام را ارسال می‌کنند و 700 میلیون عکس را به اشتراک می‌گذارند.
چه سروری به تنهایی می‌تواند این آمار و ارقام را پوشش دهد؟ هزینه خرید و نگهداری آن چقدر است؟ چقدر باید هزینه کنیم تا این سرور از دسترس خارج نشود؟ یک سرور به تنهایی چه راهکاری را می‌تواند ارائه دهد که هیچوقت از دسترس خارج نشود؟
بهتر است بدانید که سرویس Facebook روی بیش از 60,000 سرور ارائه می‌شود! چه سروری به تنهایی می‌تواند کارآیی 60,000 سرور را داشته باشد؟
چه نوع پایگاه داده ای که روی یک سرور سرویس ارائه می‌دهد، قادر است روزانه به بیشتر از 1 تریلیون درخواست، پاسخ دهد؟ اصلا چه سروری به تنهایی قادر است این حجم داده را که هر روز رو به افزایش است، نگهداری کند؟

بهتر است بدانید پایگاه داده سرویس‌های شرکت Apple، روی بیش از 75,000 Node قرار دارند که روزانه حدود 10 پتابایت داده ذخیره می‌کنند. یا Netflix که از 2,500 Node استفاده می‌کند و روزانه 420 ترابایت داده را در قالب 1 تریلیون درخواست دریافت می‌کند یا Easou که پایگاه داده آن روی 270 Node قرار دارد و روزانه 300 ترابایت داده را در قالب 800 میلیون درخواست دریافت می‌کند! اینها اعداد و ارقامی نیستند که ما بتوانیم با SqlServerی که روی یک سرور قرار دارد، پوشش دهیم.

چه تعداد سرویس را در کشورمان می‌شناسید که در زمان بالا رفتن تعداد درخواست از دسترس خارج می‌شوند؟ چه تعداد سرویس را می‌شناسید که تنها راهکاری را که می‌توان در این زمان برای آنها ارائه داد، ارتقاء سخت افزار آنهاست؟ پس از مدتی با بالا رفتن تعداد کاربران، دوباره سخت افزار را ارتقاء می‌دهیم. تا کجا باید این کار را تکرار کنیم؟ چقدر هزینه کنیم برای سخت افزاری که ممکن است به هر دلیلی در هر لحظه از دسترس خارج شود؟ آیا با توجه به آمار تعداد کاربران، تعداد درخواست و حجم داده‌ی سرویس‌هایی که می‌شناسید و قابل مقایسه با آمار ذکر شده است، باز هم از دسترس خارج می‌شوند؟

در سری مقالات Distributed systems in .NET من سعی می‌کنم شما را با خصوصیات و اصطلاحات موجود در سیستمهای توزیع شده آشنا کنم و ابزارهایی را که در NET. برای پیاده سازی این نوع سیستم‌ها وجود دارد، به شما معرفی کنم و با هم ببینیم که این نوع سیستم‌ها چه راهکاری را برای رفع نیازمندی‌های ما ارائه می‌دهند.

نمونه‌ای از طراحی یک سیستم توزیع شده

‫۷ سال و ۱۰ ماه قبل، پنجشنبه ۲۵ آذر ۱۳۹۵، ساعت ۲۲:۱۰

ایمان رحیمی نیا

مطالب

معرفی Actor Based Programming و توسعه نرم افزار های مقیاس پذیر و دارای عملیات همزمان بسیار زیاد - قسمت اول

مقدمه :

زمانیکه هدفمان تولید سامانه‌ی نرم افزاری باشد که تعداد بسیار زیادی از کاربران با آن سرو کار دارند و اتفاقاً این سامانه قرار است عملیات بسیار حساسی (نظیر عملیات بانکی و مالی، مخابراتی و ...) را انجام دهد و عدم سرویس دهی مناسب آن قابل تحمل نبوده و باعث خسارات مالی، نارضایتی و ... گردد می‌بایست از روش‌های خاصی برای توسعه‌ی این گونه سیستم‌ها استفاده نمود. این نرم افزار‌ها برای اینکه بتوانند به تعداد درخواست‌های بسیار زیاد همزمان پاسخگو باشند و سرویس خود را با کیفیت مناسب ارائه دهند، می‌بایست دارای ویژگی‌های خاصی نظیر مقیاس پذیری (scalable) و تحمل پذیری در مقابل خطا (fault tolerance) باشند.

خوب حالا که صورت مسئله مشخص شد، یکی از راه حل‌های موجود را که مدل Actor Based است، بررسی می‌کنیم.

مدل Actor Based یکـی از مـدل هـای اسـتاندارد بـرای توسـعه‌ی نـرم افزارهـایی بـا قابلیـت اطمینـان بسـیار بالا، تحمل پذیر درمقابـل خطـا و پاسـخ دهـی بسـیار سـریع مـی باشـد. در ایـن مـدل، وظـایف نـرم افـزار بـه مجموعــه‌ای از Actor هــا تقســیم (توزیع) گردیـده و هــر یــک از Actor هــا بــه صــورتی کــاملاً ایزولـه، در نــخ(thread) خـاص خودشـان اجـرا شـده و بخشـی از وظـایف سیسـتم را انجـام مـی دهنـد. سـپس بـا اتصـال Actor هـا بـه یکـدیگر، یـک خـط لولـه (Pipeline) تشـکیل شـده و بـا اسـتفاده از مکـانیزم هـای ارسـال و دریافت پیـام، امکـان همکـاری و برقـراری ارتبـاط بـین Actor هـا فـراهم شـده و در نتیجـه وظیفـه‌ی اصـلی و کلی نرم افـزار بـا حرکـت در یـک خـط لولـه و عبـور از Actor هـای مختلـف بـه صـورت مـوازی و همزمـان انجام خواهد شد. با توجه بـه اینکـه هـر یـک از پیـام‌هـای وارده بـه یـک Actor در یـک thread جداگانـه اجـرا مـی‌شـود، امکــان اینکــه در یــک لحظــه چنــدین Thread در یــک Actor در حــال اجــرا باشـنـد و جــود دارد و درنتیجه باید مکانیزم‌هایی وجود داشته باشد کـه تضـمین کنـد پیـام هـای وارد شـده بـه خـط لولـه، بـه ترتیـب معین شده، اجـرا و از خط لوله خارج می‌شوند.

در این مدل هر یک از Actor هـا مـی تواننـد بـه صـورت توزیـع شـده و بـر روی سـروری مجزا اجـرا شـوند. خوشـبختانه فریمـورک هـای متفـاوت و بسـیار قـوی جهـت توسـعه بـه روش Actor Base وجـود دارند؛ بـه عنـوان مثال TPL DataFlow در Net. یکـی از نمونه‌های ساده آن بـوده کـه در سـال 2012 توسط Microsoft معرفـی شـد و Akka هم یک نمونه‌ی بسیار پخته‌تر و در بستر جاوا مطرح می‌باشد که پیاده سازی دات نتی آن هم با نام Akka.net موجود است. Erlang نیز محصول Ericsson بوده و دنیای خاص خود را دارد.

در این روش وظیفه توسعه دهنده این است که اولاً یک خط لوله از اکتور‌ها را تشکیل داده (کانفیگ) و یک عمل بزرگ را به چندین عمل کوچک‌تر تقسیم نموده و هر کدام را به یک اکتور جهت اجرا ارسال نماید. تصویر نمونه زیر یک خط لوله متشکل از 4 اکتور را نشان می‌دهد که از طریق ارسال پیام با یکدیگر در ارتباط هستند تا با همکاری یکدیگر عملی را انجام دهند. این ساختار، Pipeline یا خط لوله نامیده می‌شود.

در قسمت بعدی با جزئیات بیشتر و با نمونه‌های عملی این روش را بررسی می‌کنیم.

‫۹ سال و ۳ ماه قبل، چهارشنبه ۱۴ مرداد ۱۳۹۴، ساعت ۱۳:۵۰

وحید نصیری

مطالب

امکان استفاده از یک هارد SSD بجای RAM در SQL Server 2014

Buffer Pool یکی از مصرف کنندگان اصلی حافظه در SQL Server است. برای مثال زمانیکه اطلاعاتی را از بانک اطلاعاتی دریافت می‌کنید، این داده‌ها در Buffer Pool کش می‌شوند. همچنین SQL Server اطلاعات کلیه Execution Plans را نیز در Plan Cache که جزئی از Buffer Pool است، برای استفاده‌ی مجدد نگهداری می‌کند. هر چقدر حافظه‌ی فیزیکی سرور شما بیشتر باشد، مقدار Buffer Pool نیز به همین میزان افزایش خواهد یافت که البته حداکثر آن‌را می‌توان در تنظیمات حافظه‌ی سرور محدود کرد (Max Server Memory setting).
در دنیای واقعی میزان حافظه‌ی فیزیکی سرورها محدود است. در SQL Server 2014 راه حلی برای این مشکل تحت عنوان Buffer Pool Extensions ارائه شده‌است که محل قرارگیری آن‌را در تصویر ذیل مشاهده می‌کنید:

Buffer Pool Extensions از یک فایل ساده که به آن Extension File نیز گفته می‌شود، تشکیل شده‌است و امکان ذخیره سازی آن بر روی هاردهای سریعی مانند SSD Driveها میسر است. این فایل، ساختاری را همانند page file، در سیستم عامل ویندوز دارد. در این حالت بجای اضافه کردن RAM بیشتر به سرور، یک Extension File را می‌توان بکار گرفت. هر زمان که Buffer Pool اصلی تحت فشار قرار گیرد (به میزان حافظه‌ای بیش از حافظه‌ی فیزیکی سرور نیاز باشد)، از این افزونه‌ی فایلی استفاده خواهد شد.
اطلاعات جزئیات Buffer Pool را توسط کوئری ذیل می‌توان بدست آورد:

 Select * from sys.dm_os_buffer_descriptors

نحوه‌ی فعال سازی و تنظیم Buffer Pool Extensions

قبل از هر کاری بهتر است وضعیت افزونه‌ی Buffer pool را بررسی کرد:

 select * from sys.dm_os_buffer_pool_extension_configuration

همانطور که ملاحظه می‌کنید، در حالت پیش فرض غیرفعال است.
سپس یک فایل یک گیگابایتی را به عنوان افزونه‌ی Buffer pool ایجاد می‌کنیم.

 ALTER SERVER CONFIGURATION
SET BUFFER POOL EXTENSION ON
 (FILENAME = 'd:\BufferPoolExt.BPE', SIZE = 1GB);

توصیه شده‌است که این فایل را در یک درایور پر سرعت SSD قرار دهید؛ ولی محدودیتی از لحاظ محل قرارگیری ندارد (هر چند به نظر فقط در حالتیکه از SSD Drive استفاده شود واقعا کار می‌کند).
اینبار اگر کوئری اول را اجرا کنیم، چنین خروجی قابل مشاهده است:

این فایل به صورت خودکار در حین ری‌استارت یا خاموش شدن سرور، حذف شده و با راه اندازی مجدد آن، باز تولید خواهد شد.

تغییر اندازه‌ی افزونه‌ی Buffer pool

اگر سعی کنیم، یک گیگابایت را مثلا به 10 گیگابایت افزایش دهیم:

 ALTER SERVER CONFIGURATION
SET BUFFER POOL EXTENSION ON
 (FILENAME = 'd:\BufferPoolExt.BPE', SIZE = 10GB);

با خطای ذیل مواجه خواهیم شد:

 Could not change the value of the 'BPoolExtensionPath' property

برای رفع این مشکل، ابتدا باید افزونه‌ی Buffer pool را غیرفعال کرد:

 ALTER SERVER CONFIGURATION
SET BUFFER POOL EXTENSION OFF

سپس می‌توان مجددا اندازه و یا مسیر دیگری را مشخص کرد. بهتر است اندازه‌ی این فایل را حدود 16 برابر حداکثر میزان حافظه‌ی سرور (Max Server Memory) تعیین کنید.
همچنین توصیه شده‌است که پس از غیرفعال کردن این افزونه، بهتر است یکبار instance جاری را ری استارت کنید.

چه زمانی بهتر است از افزونه‌ی Buffer pool استفاده شود؟
در محیط‌های read-heavy OLTP، استفاده از یک چنین افزونه‌ای می‌تواند میزان کارآیی و پاسخگویی سیستم را به شدت افزایش دهد (تا 50 درصد).

سؤال: آیا غیرفعال کردن افزونه‌ی Buffer pool سبب از دست رفتن اطلاعات می‌شود؟
خیر. BPE، تنها clean pages را در خود ذخیره می‌کند؛ یعنی تنها اطلاعاتی که Commit شده‌اند در آن حضور خواهند داشت و در این حالت حذف آن یا ری استارت کردن سرور، سبب از دست رفتن اطلاعات نخواهند شد.

برای مطالعه بیشتر

Buffer Pool Extension
SQL Server 2014 Buffer Pool Extensions
Do you require a SSD to use the Buffer Pool Extension feature in SQL Server 2014
Buffer Pool Extensions in SQL Server 2014
SQL Server 2014 – Buffer Pool Extension

‫۱۰ سال و ۵ ماه قبل، پنجشنبه ۱۵ خرداد ۱۳۹۳، ساعت ۲۰:۱۵

ناصر طاهری

مطالب

اصول طراحی شی گرا SOLID - #بخش پنجم اصل DIP

بخش‌های پیشین :

اصول طراحی شی گرا SOLID - #بخش اول اصل SRP

اصول طراحی شی گرا SOLID - #بخش دوم اصل OCP

اصول طراحی شی گرا SOLID - #بخش سوم اصل LSP

اصول طراحی شی گرا SOLID - #بخش چهارم اصل ISP

اصل 5) D – DIP– Dependency Inversion principle

مقایسه با دنیای واقعی:

همان مثال کامپیوتر را دوباره در نظر بگیرید.این کامپیوتر دارای قطعات مختلفی مانند RAM ، هارد دیسک، CD ROM و ... است که هر کدام به صورت مستقل به مادربرد متصل شده اند. این به این معنی است که اگر قسمتی از کار بیفتد میتوان آن را با یک قطعه‌ی جدید به آسانی تعویض کرد . حالا فقط تصور کنید که تمامی قطعات شدیداً به یکدیگر متصل شده اند آنوقت دیگر نمیتوانستیم قطعه ای را از مادربرد برداریم و به همین خاطر اگر مثلا RAM از کار بیفتد ، یاید یک مادربرد جدید خریداری کنید که برای شما گران تمام می‌شود.

به مثال زیر توجه کنید :

public class CustomerBAL
{
    public void Insert(Customer c)
    {
        try
        {
            //Insert logic
        }
        catch (Exception e)
        {
            FileLogger f = new FileLogger();
            f.LogError(e);
        }
    }
}

public class FileLogger
{
    public void LogError(Exception e)
    {
        //Log Error in a physical file
    }
}

در کد بالا کلاسCustomerBAL مستقیما به کلاس FileLogger وابسته است که استثناء‌های رخ داده را بر روی یک فایل فیزیکی لاگ میکند. حالا فرض کنید که چند روز بعد مدیریت تصمیم میگیرد که از این به بعد استثناء‌ها بر روی یک Event Viewer لاگ شوند. اکنون چه میکنید؟ با تغییر کدها ممکن است با خطاهای زیادی روبرو شوید(درصورت تعداد بالای کلاسهایی که از کلاس FileLogger استفاده میکنند و فقط تعداد محدودی از آنها نیاز دارند که بر روی Event Viewer لاگ کنند.)

DIP به ما میگوید : " ماژول‌های سطح بالا نباید به ماژولهای سطح پایین وابسته باشند، هر دو باید به انتزاعات وابسته باشند. انتزاعات نباید وابسته به جزئیات باشند، بلکه جزئیات باید وابسته به انتزاعات باشند. ".

در طراحی ساخت یافته، ماژولهای سطح بالا به ماژولهای سطح پایین وابسته بودند. این مسئله دو مشکل ایجاد می‌کرد:

1- ماژول‌های سطح بالا (سیاست گذار) به ماژول‌های سطح پایین (مجری) وابسته هستند. در نتیجه هر تغییری در ماژول‌های سطح پایین ممکن است باعث اشکال در ماژول‌های سطح بالا گردد.

2- استفاده مجدد از ماژول‌های سطح بالا در جاهای دیگر مشکل است، زیرا وابستگی مستقیم به ماژول‌های سطح پایین دارند.

راه حل با توجه به اصل DIP :

public interface ILogger
{
    void LogError(Exception e);
}

public class FileLogger:ILogger
{
    public void LogError(Exception e)
    {
        //Log Error in a physical file
    }
}
public class EventViewerLogger : ILogger
{
    public void LogError(Exception e)
    {
        //Log Error in a Event Viewer
    }
}
public class CustomerBAL
{
    private ILogger _objLogger;
    public CustomerBAL(ILogger objLogger)
    {
        _objLogger = objLogger;
    }

    public void Insert(Customer c)
    {
        try
        {
            //Insert logic
        }
        catch (Exception e)
        {            
            _objLogger.LogError(e);
        }
    }
}

در اینجا وابستگی‌های کلاس CustomerBAL از طریق سازنده آن در اختیارش قرار گرفته است. یک اینترفیس ILogger تعریف شده‌است به همراه دو پیاده سازی مختلف از آن مانند FileLogger و EventViewerLogger.

یکی از انواع فراخوانی آن نیز می‌تواند به شکل زیر باشد:

var customerBAL = new CustomerBAL (new EventViewerLogger());
customerBAL.LogError();

اطلاعات بیشتر در دوره آموزشی "بررسی مفاهیم معکوس سازی وابستگی‌ها و ابزارهای مرتبط با آن ".

‫۱۱ سال و ۱ ماه قبل، یکشنبه ۷ مهر ۱۳۹۲، ساعت ۰۰:۲۰

وحید نصیری

مطالب

آشنایی با mocking frameworks (چارچوب‌های تقلید) - قسمت اول

این مطلب در ادامه‌ی مطالب آزمو‌ن‌های واحد یا unit testing است.
نوشتن آزمون واحد برای کلاس‌هایی که با یک سری از الگوریتم‌ها ، مسایل ریاضی و امثال آن سر و کار دارند، ساده است. عموما این نوع کلاس‌ها وابستگی خارجی آنچنانی ندارند؛ اما در عمل کلاس‌های ما ممکن است وابستگی‌های خارجی بسیاری پیدا کنند؛ برای مثال کار با دیتابیس، اتصال به یک وب سرویس، دریافت فایل از اینترنت، خواندن اطلاعات از انواع فایل‌ها و غیره.
مطابق اصول آزمایشات واحد، یک آزمون واحد خوب باید ایزوله باشد. نباید به مرزهای سیستم‌های دیگر وارد شده و عملکرد سیستم‌های خارج از کلاس را بررسی کند.
این مثال ساده را در نظر بگیرید:
فرض کنید برنامه شما قرار است از یک وب سرویس لیستی از آدرس‌های IP یک کشور خاص را دریافت کند و در یک دیتابیس محلی آن‌ها را ذخیره نماید. به صورت متداول این کلاس باید اتصالی را به وب سرویس گشوده و اطلاعات را دریافت کند و همچنین آن‌ها را خارج از مرز کلاس در یک دیتابیس ثبت کند. نوشتن آزمون واحد برای این کلاس مطابق اصول مربوطه غیر ممکن است. اگر کلاس آزمون واحد آن‌را تهیه نمائید، این آزمون، integration test نام خواهد گرفت زیرا از مرزهای سیستم باید عبور نماید.

همچنین یک آزمون واحد باید تا حد ممکن سریع باشد تا برنامه نویس از انجام آن بر روی یک پروژه بزرگ منصرف نگردد و ایجاد این اتصالات در خارج از سیستم، بیشتر سبب کندی کار خواهند شد.

برای این ایزوله سازی روش‌های مختلفی وجود دارند که در ادامه به آن‌ها خواهیم پرداخت:

روش اول: استفاده از اینترفیس‌ها
با کمک یک اینترفیس می‌توان مشخص کرد که یک قطعه از کد "چه کاری" را قرار است انجام دهد؛ و نه اینکه "چگونه" باید آن‌را به انجام رساند.
یک مثال ساده از خود دات نت فریم ورک، اینترفیس IComparable است:


   public static string GetComparisonText(IComparable a, IComparable b)
   {
       if (a.CompareTo(b) == 1)
           return "a is bigger";
       if (a.CompareTo(b) == -1)
           return "b is bigger";
       return "same";
   }

در این مثال چون از IComparable استفاده شده، متد ما از هر نوع داده‌ای جهت مقایسه می‌تواند استفاده کند. تنها موردی که برای آن مهم خواهد بود این است که a راهی را برای مقایسه با b ارائه دهد.

اکنون با توجه به این توضیحات، برای ایزوله کردن ارتباط با دیتابیس و وب سرویس در مثال فوق، می‌توان اینترفیس‌های زیر را تدارک دید:

    public interface IEmailSource
   {
       IEnumerable<string> GetEmailAddresses();
   }

   public interface IEmailDataStore
   {
       void SaveEmailAddresses(IEnumerable<string> emailAddresses);

   }

در اینجا استفاده و تعریف اینترفیس‌ها چندین خاصیت را به همراه خواهد داشت :
الف) به این صورت تنها مشخص می‌شود که چه کاری را قصد داریم انجام دهیم و کاری به پیاده سازی آن نداریم.
ب) ساخت کلاس بدون وجود یا دسترسی به یک دیتابیس میسر می‌شود. این مورد خصوصا در یک کار تیمی که قسمت‌های مختلف کار به صورت همزمان در حالت پیشرفت و تهیه است حائز اهمیت می‌شود.
ج) با توجه به اینکه در اینجا به پیاده سازی توجهی نداریم، می‌توان از این اینترفیس‌ها جهت تقلید دنیای واقعی استفاده کنیم. (که در اینجا mocking نام گرفته است)

جهت تقلید رفتار و عملکرد این دو اینترفیس، به کلاس‌های تقلید زیر خواهیم رسید:


public class MockEmailSource : IEmailSource
{
   public IEnumerable<string> EmailAddressesToReturn { get; set; }
   public IEnumerable<string> GetEmailAddresses()
   {
       return EmailAddressesToReturn;
   }
}

public class MockEmailDataStore : IEmailDataStore
{
   public IEnumerable<string> SavedEmailAddresses { get; set; }
   public void SaveEmailAddresses(IEnumerable<string> emailAddresses)
   {
       SavedEmailAddresses = emailAddresses;
   }

}

تا اینجا اولین قدم در مورد ایزوله سازی کلاس‌هایی که به مرز سیستم‌های دیگر وارد می‌شوند، برداشته شد. اما به مرور زمان مدیریت این اینترفیس‌ها و افزودن رفتارهای جدید به کلاس‌های مشتق شده از آن‌ها مشکل می‌شود. به همین جهت تا حد ممکن از پیاده سازی دستی آن‌ها خودداری شده و روش پیشنهادی استفاده از mocking frameworks است.

ادامه دارد ....

‫۱۵ سال و ۷ ماه قبل، چهارشنبه ۱۶ اردیبهشت ۱۳۸۸، ساعت ۰۲:۲۴

وحید نصیری

مطالب

مونیتور کردن وضعیت یک سایت در دات نت

فرض کنید می‌خواهیم وضعیت یک سایت را از لحاظ قابلیت دسترسی مونیتور کنیم، آیا Up است، Down است و امثال آن. یک سری از وب سرورها ping را بسته‌اند (ICMP Replies). بنابراین الزاما با استفاده از این روش ساده نمی‌توان به مقصود رسید.
خوشبختانه انجام این‌کار با استفاده از فضای نام استاندارد System.Net و کلاس HttpWebRequest ، بدون نیاز به هیچگونه کلاس یا کامپوننت خارجی، به سادگی قابل انجام است. کلاس زیر به همین منظور تهیه شده است:


using System;
using System.Net;

  public class CSiteMonitor
  {
      public struct UrlHeaderInfo
      {
          public DateTime _lastModified;
          public string _statusCode;
          public string _errorMessage;
      }

      /// <summary>
      /// آیا آدرس اینترنتی وارد شده معتبر است؟
      /// </summary>
      /// <param name="url">آدرس مورد نظر جهت بررسی</param>
      /// <returns></returns>
      public static bool IsValidURL(string url)
      {
          try
          {
              Uri uri = new Uri(url);
              return (uri.Scheme == Uri.UriSchemeHttp) || (uri.Scheme == Uri.UriSchemeHttps);
          }
          catch { return false; }
      }
      /// <summary>
      /// آدرس اینترنتی جهت بررسی
      /// </summary>
      /// <param name="url"></param>
      /// <returns></returns>
      /// <exception cref="ArgumentException">آدرس اینترنتی وارد شده معتبر نیست</exception>
      public static UrlHeaderInfo GetSiteHeaderInfo(string url)
      {
          if (!IsValidURL(url))
              throw new ArgumentException("آدرس اینترنتی وارد شده معتبر نیست", "url");

          UrlHeaderInfo hhi = new UrlHeaderInfo { _lastModified = DateTime.Now, _statusCode = "NOK!", _errorMessage = string.Empty };

          HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);
          //request.Proxy
          request.Method = "HEAD";
          request.AllowAutoRedirect = true;
          request.UserAgent = "Mozilla/5.0 (Windows; U; Windows NT 5.0; ; rv:1.8.0.7) Gecko/20060917 Firefox/1.9.0.1";
          request.Timeout = 1000 * 300;
          request.AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate;
        
          try
          {
              using (HttpWebResponse response = (HttpWebResponse) request.GetResponse())
              {
                  hhi._statusCode = response.StatusCode.ToString();
                  hhi._lastModified = response.LastModified;
              }
          }
          catch (Exception ex)
          {
              hhi._errorMessage = ex.Message;
          }

          return hhi;
      }
  }

توضیحات:
- در متد GetSiteHeaderInfo نیاز بود تا از یک تابع بیش از یک خروجی داشته باشیم. راه‌های زیاد برای انجام این‌کار هست.برای مثال:
الف)ارائه خروجی‌ها به صورت یک آرایه. زیاد جالب نیست، چون اگر شخصی دقیقا مستندات متد شما را مطالعه نکند نمی‌داند که ترتیب خروجی‌ها چگونه است و هر کدام چه معنایی دارند.
ب)ارائه خروجی‌ها با استفاده از آرگومان‌هایی از نوع out یا ref . در دنیای شیء گرایی این نوع روش‌ها را باید منسوخ شده در نظر گرفت و صرف سازگاری با زبان‌هایی مانند C که این روش در آن‌ها رواج دارد (استفاده از آرگومان‌هایی از نوع اشاره‌گر) باید به آن نگاه کرد و نه بیشتر.
ج)خروجی‌ها را به صورت یک کلاس یا struct درنظر گرفت تا استفاده کننده دقیقا بداند که فیلد خروجی چه معنایی دارد و هم چنین دقیقا چه تعداد خروجی مد نظر است.

- حتما باید از try/finally جهت اطمینان حاصل نمودن از بسته شدن response استفاده شود، در غیر اینصورت پس از دو خطای متوالی حاصل شده عملا دیگر نمی‌توان از شیء response استفاده کرد. البته همانطور که پیش تر نیز ذکر شد، عبارت using توسط کامپایلر به try/finally بست داده می‌شود، بنابراین جهت خوانایی بیشتر کد بهتر است از این روش استفاده شود.
- جهت بلاک نشدن درخواست بهتر است از یک UserAgent کمک گرفته شود.
- جهت بررسی اعتبار یک آدرس اینترنتی یا می‌توان از Regular expressions استفاده کرد یا از شیء Uri که روش آن‌را ملاحظه می‌کنید.
- اگر در شبکه داخلی خود از پروکسی استفاده می‌شود، می‌توان قسمت request.Proxy را با شیء پروکسی تنظیم شده مطابق مشخصات پروکسی سرور خود، بکار برد.
- در این مثال بیشتر هدف پیاده سازی کلاس دریافت اطلاعات هدر سایت بود و از ارائه کدهای مربوط به تایمر یا یک ترد جهت بررسی متوالی وضعیت سایت صرفنظر شد.

مثالی در مورد نحوه‌ی استفاده از کلاس فوق:


CSiteMonitor.UrlHeaderInfo info = CSiteMonitor.GetSiteHeaderInfo("http://www.google.com");
MessageBox.Show(info._statusCode);

‫۱۵ سال و ۱۰ ماه قبل، سه‌شنبه ۱۵ بهمن ۱۳۸۷، ساعت ۱۷:۳۷

وحید نصیری

مطالب دوره‌ها

طراحی روابط و ارجاعات در RavenDB

در قسمت‌های قبل، با پیش زمینه‌ی ذهنی طراحی مدل‌های RavenDB به همراه اصول مقدماتی کوئری نویسی آن آشنا شدیم. در این قسمت قصد داریم معادل‌های روابط موجود در بانک‌های اطلاعاتی رابطه‌ای را در RavenDB و مطابق ذهنیت غیر رابطه‌ای آن، مدلسازی کنیم و مثال‌های بیشتری را بررسی نمائیم.

مدیریت روابط در RavenDB

یکی از اصول طراحی مدل‌ها در RavenDB، مستقل بودن اسناد یا documents است. به این ترتیب کلیه اطلاعاتی که یک سند نیاز دارد، داخل همان سند ذخیره می‌شوند (به این نوع شیء، Root Aggregate هم گفته می‌شود). اما این اصل سبب نخواهد شد تا نتوان یا نباید ارتباطی را بین اسناد تعریف کرد. بنابراین سؤال مهم اینجا است که چه اطلاعات مرتبطی باید داخل یک سند ذخیره شوند و چه اطلاعاتی باید به سند دیگری ارجاع داده شوند. برای پاسخ به این سؤال سه روش ذیل را باید مدنظر داشت:

الف) Denormalized references
فرض کنید در دنیای رابطه‌ای دو جدول سفارش و مشتری را دارید. در این حالت، جدول سفارش تنها شماره آی دی اطلاعات مشتری را از جدول مشتری یا کاربران سیستم، در خود ذخیره خواهد کرد. به این ترتیب از تکرار اطلاعات مشتری در جدول سفارشات جلوگیری می‌گردد. اما اگر اطلاعات پرکاربرد مشتری را در داخل جدول سفارش قرار دهیم به آن denormalized reference گفته می‌شود.
ایجاد denormalized reference یکی از روش‌های مرسوم در دنیای NoSQL و RavenDB است؛ خصوصا جهت سهولت نمایش اطلاعات. به این ترتیب ارجاع به سندهای دیگر کمتر شده و ترافیک شبکه نیز کاهش می‌یابد. برای مثال در اینجا نام و آدرس مشتری را داخل سند ثبت شده قرار می‌دهیم و از سایر اطلاعات او (که اهمیت نمایشی ندارند) مانند کلمه عبور و امثال آن صرفنظر خواهیم کرد.
اینجا است که یک سری از سؤالات مطرح خواهند شد مانند : «اگر آدرس مشتری تغییر کرد، چطور؟»
بنابراین بهترین حالت استفاده از روش denormalized references محدود خواهد شد به موارد ذیل:
الف) قید اطلاعاتی که به ندرت تغییر می‌کنند. برای مثال نام یک شخص یا نام یک کشور، استان یا شهر.
ب) ثبت اطلاعات تکراری که در طول زمان تغییر می‌کنند، اما باید تاریخچه‌ی آن‌ها حفظ شوند. برای مثال اگر آدرس مشتری تغییر کرده است، واقعا اجناس سندهای قبلی او، صرفنظر از آدرس جدیدی که اعلام کرده است، به آدرس قبلی او ارسال شده‌اند و این تاریخچه باید در سیستم حفظ شوند.
ج) اطلاعاتی که ممکن است بعدها حذف شوند؛ اما نیاز است سابقه اسناد قبلی تخریب نشوند. برای مثال کارخانه‌ای را درنظر بگیرید که امسال یک سری چینی خاص را تولید می‌کند و می‌فروشد. سال بعد خط تولید خود را عوض کرده و سری اجناس دیگری را شروع به تولید و فروش خواهد کرد. در بانک‌های اطلاعاتی رابطه‌ای نمی‌توان اجناسی را که در جداول دیگر ارجاع دارند، به این سادگی‌ها حذف کرد. در اینجا باید از روش‌هایی مانند تعریف فیلد بیتی IsDeleted برای مخفی کردن ظاهری رکوردهای موجود کمک گرفت. اما در دنیای رابطه‌ای، اطلاعات مهم محصول را در سند اصلی ثبت کنید. بعد هر زمانیکه نیازی به محصول نبود، کلا تعریف آن‌را حذف نمائید.

ب) Includes
Includes در RavenDB برای پوشش مشکلات denormalization ارائه شده است. در اینجا بجای اینکه یک شیء کپی اطلاعات پرکاربرد شیء‌ایی دیگر را در خود ذخیره کند، تنها ارجاعی (یک Id رشته‌ای) از آن شیء را در سند مرتبط ذخیره خواهد کرد.

public class Order
{
    public string CustomerId { get; set; }
    public LineItem[] LineItems { get; set; }
    public double TotalPrice { get; set; }
}
 
public class Customer
{
    public string Name { get; set; }
    public string Address { get; set; }
    public short Age { get; set; }
    public string HashedPassword { get; set; }
}

برای نمونه در کلاس Order شاهد یک Id رشته‌ای ارجاع دهنده به کلاس Customer هستیم. هرگاه که نیاز به بارگذاری اطلاعات شیء Order به همراه کل اطلاعات مشتری او تنها در یک رفت و برگشت به بانک اطلاعاتی باشد، می‌توان از متد الحاقی Include مختص RavenDB استفاده کرد:

var order = session.Include<Order>(x => x.CustomerId)
                   .Load("orders/1234");
 
// این کوئری از کش سشن خوانده می‌شود و کاری به سرور ندارد
var cust = session.Load<Customer>(order.CustomerId);

همانطور که مشاهده می‌کنید، با ذکر متد Include، اعلام کرده‌ایم که مایل هستیم تا اطلاعات سند مشتری متناظر را نیز داشته باشیم. در این حالت در Load بعدی که بر اساس Id مشتری انجام شده، دیگر رفت و برگشتی به سرور انجام نشده و اطلاعات مشتری از کش سشن جاری که پیشتر با فراخوانی Include مقدار دهی شده است، دریافت می‌گردد.
حتی می‌توان چند سند مرتبط را با هم بارگذاری کرد؛ با حداقل رفت و برگشت به سرور:

var orders = session.Include<Order>(x => x.CustomerId)
    .Load("orders/1234", "orders/4321");
 
foreach (var order in orders)
{
    // این کوئری‌ها سمت کلاینت هستند و به سرور ارسال نمی‌شوند
    var cust = session.Load<Customer>(order.CustomerId);
}

همچنین امکان استفاده از متد Include در LINQ API نیز پیش بینی شده است. برای این منظور باید از متد Customize استفاده کرد:

var orders = session.Query<Order>()
    .Customize(x => x.Include<Order>(o => o.CustomerId))
    .Where(x => x.TotalPrice > 100)
    .ToList();
 
foreach (var order in orders)
{
    // این کوئری‌ها سمت کلاینت اجرا می‌شوند
    var cust = session.Load<Customer>(order.CustomerId);
}

Includeهای یک به چند

اکنون فرض کنید به کلاس سفارش، آرایه تامین کننده‌ها نیز افزوده شده است (رابطه یک به چند):

public class Order
{
    public string CustomerId { get; set; }
    public string[] SupplierIds { get; set; }
    public LineItem[] LineItems { get; set; }
    public double TotalPrice { get; set; }
}

بارگذاری یکباره روابط یک به چند نیز با Include میسر است:

var orders = session.Include<Order>(x => x.SupplierIds)
    .Load("orders/1234", "orders/4321");
 
foreach (var order in orders)
{
    foreach (var supplierId in order.SupplierIds)
    {
        // از کش سشن خوانده می‌شود
        var supp = session.Load<Supplier>(supplierId);
    }
}

Includeهای چند سطحی

در اینجا کلاس سفارشی را در نظر بگیرید که دارای خاصیت ارجاع دهنده نیز هست. این خاصیت به شکل یک کلاس تعریف شده است و نه به شکل یک آی دی رشته‌ای:

public class Order
{
    public string CustomerId { get; set; }
    public string[] SupplierIds { get; set; }
    public Referral Refferal { get; set; }
    public LineItem[] LineItems { get; set; }
    public double TotalPrice { get; set; }
}

public class Referral
{
    public string CustomerId { get; set; }
    public double CommissionPercentage { get; set; }
}

متد Include امکان ارجاع به خواص تو در تو را نیز دارد:

var order = session.Include<Order>(x => x.Refferal.CustomerId)
    .Load("orders/1234");
 
// از کش سشن خوانده می‌شود
var referrer = session.Load<Customer>(order.Refferal.CustomerId);

همچنین این متد با مجموعه‌ها نیز کار می‌کند. برای مثال اگر تعریف متد LineItem به صورت زیر باشد:

public class LineItem
{
    public string ProductId { get; set; }
    public string Name { get; set; }
    public int Quantity { get; set; }
    public double Price { get; set; }
}

برای بارگذاری یکباره اسناد مرتبط می‌توان به روش ذیل عمل کرد:

var order = session.Include<Order>(x => x.LineItems.Select(li => li.ProductId))
    .Load("orders/1234");
 
foreach (var lineItem in order.LineItems)
{
    // از کش سمت کلاینت خوانده می‌شود
    var product = session.Load<Product>(lineItem.ProductId);
}

و به صورت خلاصه برای باگذاری اسناد مرتبط، دیگر از دو کوئری پشت سر هم ذیل استفاده نکنید:

var order = session.Load<Order>("orders/1");
var customer = session.Load<Customer>(order.CustomerId);

این دو کوئری یعنی دوبار رفت و برگشت به سرور. با استفاده از Include می‌توان تعداد رفت و برگشت‌ها و همچنین ترافیک شبکه را کاهش داد. به علاوه سرعت کار نیز افزایش خواهد یافت.

ج) تفاوت بین Reference و Relationship

برای درک اینکه آیا اطلاعات یک شیء مرتبط را بهتر است داخل شیء اصلی (Aggregate rooe) ذخیره کرد یا خیر، باید مفاهیم ارجاع و ارتباط را بررسی کنیم.
اگر به مثال سفارش و مشتری دقت کنیم، یک سفارش را بدون مشتری نیز می‌توان تکمیل کرد. برای مثال بسیاری از فروشگاه‌ها به همین نحو عمل می‌کنند و اگر شماره Id مشتری را به سندی اضافه می‌کنیم، صرفا جهت این است که بدانیم این سند متعلق به شخص دیگری نیست. بنابراین «ارجاعی» به کاربر در جدول سفارش می‌تواند وجود داشته باشد.
اکنون اقلام سفارش را درنظر بگیرید. هر آیتم سفارش تنها با بودن آن سفارش خاص است که معنا پیدا می‌کنند و نه بدون آن. این آیتم می‌تواند ارجاعی به محصول مرتبط داشته باشد. اینجا است که می‌گوییم اقلام سند با سفارش «در ارتباط» هستند؛ اما یک سند ارجاعی دارد به مشتری.
از این دو مفهوم برای تشخیص تشکیل Root Aggregate استفاده می‌شود. به این ترتیب تشخیص داده‌ایم اقلام سند، Root Aggregate را تشکیل می‌دهند؛ بنابراین ذخیره سازی تمام آن‌ها داخل یک سند RavenDB معنا پیدا می‌کند.

چند مثال برای درک بهتر نحوه طراحی اسناد در RavenDB

الف) Stackoverflow
صفحه نمایش یک سؤال و پاسخ‌های آن و همچنین رای‌های هر آیتم را درنظر بگیرید. در اینجا کاربران همزمانی ممکن است به یک سؤال رای بدهند، پاسخ‌هایی را ارائه دهند و یا کاربر اصلی، سؤال خویش را ویرایش کند. به این ترتیب با قرار دادن کلیه آیتم‌های این سند داخل آن، به مشکلات همزمانی برخواهیم خورد. برای مثال واقعا نمی‌خواهیم که به علت افزوده شدن یک پاسخ، کل سند قفل شود.
بنابراین ذخیره سازی سؤال در یک سند و ذخیره سازی لیست پاسخ‌ها در سندی دیگر، طراحی بهتری خواهد بود.

ب) سبد خرید و آیتم‌های آن
زمانیکه کاربری مشغول به خرید آنلاین از سایتی می‌شود، لیست اقلام انتخابی او یک سفارش را تشکیل داده و به تنهایی معنا پیدا نمی‌کنند. به همین جهت ذخیره سازی اقلام سفارش به صورت یک Root aggregate در اینجا مفهوم داشته و متداول است.

ج) یک بلاگ و کامنت‌های آن
در اینجا نیز کاربران، مجزای از مطلب اصلی ارسال شده ممکن است نظرات خود را ویرایش کنند یا اینکه بخواهیم نظرات را جداگانه لیست کنیم. بنابراین این دو (مطالب و نظرات) موضوعاتی جداگانه بوده و نیازی نیست به صورت یک Root aggregate تعریف شوند.

بنابراین در حین طراحی اسناد NoSQL باید به اعمال و «محدوده‌های تراکنشی» انجام شده دقت داشت تا اینکه صرفا عنوان شود این یک رابطه یک به چند یا چند به چند است.

‫۱۱ سال و ۲ ماه قبل، دوشنبه ۱۸ شهریور ۱۳۹۲، ساعت ۰۵:۳۰