.NET Tips | جستجوها: نتایج مشابه «معماری میکروسرویس‌ها»، صفحه: ۱۵

مطالب

آموزش MDX Query - قسمت پنجم – باز کردن یک پایگاه داده ی Multidimensional در محیط BIMS و ساخت یک پروژه ی جدید.

در این قسمت در ابتدا نحوه‌ی باز کردن یک پایگاه داه‌ی چند بعدی را در محیط BIMS بررسی کرده و سپس چگونگی ساخت یک MDB را از پایه بررسی می‌کنیم. برای ادامه دادن این قسمت نیاز می‌باشد که پایگاه داده‌ی AdventureWorkDW2008 را در SSAS نصب کرده باشید .

در ابتدا مطابق شکل زیر منوی File سپس زیر منوی Open و Analysis Service Database را انتخاب نمایید.

در ادامه می‌بایست نام Server را مشخص نمایید و دقت داشته باشید که در اینجا منظور از نام سرور، نام سرور SSAS می‌باشد (در صورتیکه بر روی خود سرور در حال کار می‌باشید از . به جای نام سرور استفاده کنید). سپس در قسمت Database، نام پایگاه داده‌ی چند بعدی را انتخاب نمایید. در صورتی که به جز Adventure Work DW 2008 ، پایگاه داده‌های چند بعدی دیگری را در SSAS داشته باشید، یک لیست از آنها را مشاهده خواهید کرد و در صورتیکه لیست شما خالی می‌باشد، احتمال دارد نام سرور اشتباه باشد یا روی سرویس SSAS مربوط به آن سرور هیچ پایگاه داده‌ی چند بعدی نصب نباشد.

حال مسیری را برای ذخیره سازی پروژه‌ی جدید در نظر بگیرید:

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

همان طور که مشخص می‌باشد، یک شیء درون شاخه‌ی Data Source وجود دارد که مشخص کننده‌ی ارتباط این پروژه با پایگاه داده‌ی Data Warehouse است. برای مشاهده‌ی این ارتباط، بر روی Adventure Work DW کلیک راست کنید و سپس گزینه‌ی Open را انتخاب نمایید. در ادامه گزینه‌ی Edit را بزنید.

سپس در پنجره‌ی جدید، تنظیمات رشته‌ی ارتباطی با DW را مشاهده نمایید

با زدن کلید Test Connection باید پیام Test Connection Succeeded را مشاهده نمایید. اکنون پنجره‌ها را با زدن کلید OK ببندید.

در قسمت Data Source View سه شی تعریف شده است؛ براساس دسته بندی مورد نظر و جاری در Business موجود در Adventure Work .

با کلیک راست کردن بر روی Adventure Works DW و انتخاب گزینه‌ی Open، اقدام به باز کردن DSV انتخاب شده کنید. در صفحه‌ی باز شده می‌توانید انواع دیاگرام تهیه شده را مشاهده نمایید و همچنین لیستی از جداول موجود در این DSV مشخص می‌باشد.

با کلیک راست کردن در فضای خالی دیاگرام ، امکان Add/Remove کردن جداول را به دیاگرام دارید.

در شکل بالا بعد از انتخاب یک جدول در سمت راست و انتقال آن به سمت چپ می‌توانید با زدن دکمه‌ی Add Related Table براساس کلید‌های خارجی، جداول مرتبط با جدول انتخاب شده را به صورت خودکار انتخاب نمایید و به قسمت چپ انتقال دهید.

شما در ساخت Cube مشخص می‌نمایید که Cube را از کدام DSV خواهید ساخت. بنابراین انتخاب جداول در DSV ‌ها می‌بایست براساس نوع Business شما باشد تا در ساخت Cube به مشکلی برخورد نکنید.

در ساختار درختی موجود در پنجره‌ی Solution در شاخه‌ی Cube، می‌توانید Adventure Works را باز کنید (کلیک راست و انتخاب Open ) .

در شکل بالا در سمت چپ، می‌توانید Measure ‌ها و Dimension ‌های موجود در این Cube را مشاهده کنید. همچنین در قسمت بالا چندین Tab وجود دارند که در هر کدام تنظیمات بیشتری را بر روی Cube اعمال می‌کنیم. با توجه به اینکه طراحی Cube ‌ها کاری تخصصی می‌باشد و نیاز به اطلاعات زیادی دارد اجازه دهید مقاله ای در خصوص طراحی Cube در SSAS جداگانه انتشار داده شود و فعلا در همین حد بسنده کنیم. با این حال در صورت نیاز می‌توانید برای اطلاعات بیشتر در این خصوص کتاب Microsoft SQL Server Analysis Services 2008 With MDX از انتشارات Wrox را مطالعه نمایید.

در Solution Explorer در شاخه‌ی ،Dimensions می‌توانید تمامی بعدهایی که در تمامی Cube ‌های شما استفاده شده‌اند را مشاهده نمایید.

با انتخاب یک بعد (ترجیحا بعد Date ) و با کلیک راست کردن و انتخاب گزینه‌ی Open آن را باز نمایید.

در پنجره‌ی باز شده می‌توانید 4 Tab در بالا را مشاهد نمایید و در Tab نخست، Attribute ها و همچنین ساختار Hierarchies و در آخر Data source View را مشاهده نمایید.

در Attribute relationships می توانید ارتباط صفت‌های یک بعد را مشخص نمایید.

در Browsing Tab می‌توانید محتوای Dimension را بررسی نمایید (البته اگر در پروژه‌ی جدید قرار دارید حتما می‌بایست پروژه را Deploy کرده باشید. در حالتیکه یک پایگاه داه‌ی چند بعدی را باز می‌کنید، نیازی به Deploy کردن نمی‌باشد؛ زیرا حتما قبلا این کار انجام شده است (زیرا شما پایگاه داده‌ی چند بعدی را بعد از Deploy کردن پروژه‌ی SSAS خواهید داشت ))

در صورتیکه مانند روش بالا یک پایگاه داده‌ی چند بعدی را باز کنیم، دیگر نیازی به Deploy کردن نمی‌باشد و فقط برای اعمال تغییرات روی پایگاه داده‌ی چند بعدی باید پروژه را Process کنیم و برای این منظور روی نام پروژه کلیک راست کرده و گزینه‌ی Process را انتخاب کنید. با این کار تغییرات اعمال شده در BIMS روی پایگاه داده‌ی SSAS اعمال می‌گردند و داده‌ها با توجه به ساختار Cube ‌ها دوباره پردازش می‌شوند.

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

در ابتدا BIMS را باز کرده و سپس به منوی File رفته و در قسمت New گزینه‌ی Project را انتخاب می‌کنیم. سپس در صفحه‌ی باز شده، مطابق شکل زیر عمل کرده و یک پروژه از نوع Analysis Service Multidimensional … می‌سازیم.

سپس برروی شاخه‌ی Data Source کلیک راست کرده و گزینه‌ی New Data Source را می‌زنیم و پنجره‌های ویزارد را به جلو می‌رویم.

در ابتدا باید یک Connection به DW تولید کنیم. برای این منظور در پنجره‌ی فوق دکمه‌ی New را زده و اطلاعات را مطابق شکل زیر پر می‌کنیم.

و سپس OK را میزنیم.

در صورتی که SSAS در یک سرور دیگر نصب شده است در پنجره‌ی بعدی نیاز می‌باشد نام کاربری را که به سرویس SSAS در آن سرور دسترسی دارد را وارد کنیم.

در صورتی که SSAS روی سیستم Local نصب شده است و کاربری که با آن Login هستیم دسترسی کافی به SSAS را دارد، گزینه‌ی Use the credentials of the current user را انتخاب می‌کنیم.

در صفحه‌ی آخر یک نام برای DS انتخاب می‌کنیم.

سپس نیاز می‌باشد یک DSV بسازیم. برای این منظور روی شاخه‌ی Data Source View کلیک راست کرده و گزینه‌ی New را انتخاب کرده و سپس در پنجره‌ی Wizard باید Data Source ساخته شده در مرحله‌ی قبل را انتخاب کرده و سپس Next را بزنیم. در اینجا بر اساس بیزینس‌های مختلف، راه کار‌های گوناگونی را داریم. به عبارت دیگر می‌توان جداول Fact و Dimension ‌های مرتبط با آن‌را بر اساس زیر سیستم‌های مختلف انتخاب کرده و برای هر کدام از آنها یک DSV بسازیم. به نظر من می‌توانیم تمامی جداول را در این مرحله انتخاب کرده و سپس این تفکیک بندی را در سطح Cube ‌ها انجام داد. به طور کلی دقت داشته باشید به هیچ عنوان DSV و Cube ‌های سیستم را خیلی تفکیک نکنید. زیرا در نوشتن کوئری‌ها و Join بین Cube ‌ها با مشکل و سختی روبرو خواهید شد. (از لحاظ تجربی تفکیک بندی به شرطی صورت گیرد که نیازی به Join کردن Cube ‌ها در MDX Query ‌ها نباشد.)

سپس یک نام برای DSV خود انتخاب کرده و Finish را بزنید.

خوب؛ آخرین مرحله ساخت Cube می‌باشد (البته در طراحی Cube مطالب بسیاری وجود دارند که در یک مقاله‌ی دیگر تلاش خواهم کرد تمامی آن موارد را توضیح دهم.)

برای ساخت Cube ، روی شاخه‌ی Cube کلیک راست کرده و گزینه‌ی New را بزنید.

سپس Use Existing Table را انتخاب کرده و Next را بزنید.

در پنجره‌ی بعدی باید DSV را انتخاب کرد و بعد جداول مورد نیاز در طراحی Cube را انتخاب کنید. فراموش نکنید در صورت انتخاب یک Fact تمامی Dimension ‌های مرتبط با آن را انتخاب نماید. دکمه Next را بزنید.

در پنجره‌ی بعدی باید جداول Fact را انتخاب کرده و دکمه‌ی Next را بزنید.

سپس در پنجره‌ی بعدی دایمنشن را انتخاب نمایید. (ترجیحا اجازه بدهید خود BIMS برای شما Dimension ‌ها را بسازد، هرچند که خود شما می‌توانید بعدا به صورت دستی Dimension ‌ها را ایجاد کنید).

بعد از زدن دکمه‌ی Next نامی برای Cube خود انتخاب نمایید و سپس دکمه‌ی Finish را بزنید.

بعد از ساخت Cube ، چندین دایمنشن به صورت خودکار ساخته می‌شوند . البته گاهی نیاز می‌باشد که اقدام به ساخت ساختار‌های سلسله مراتبی در Dimension ‌ها کنیم (این مورد را در یک مقاله جداگانه آموزش خواهم داد.)

پروژه با کلید‌های ترکیبی Ctrl+Shift+B ساخته می‌شود و بعد از اطمینان از درست بودن ساخت پروژه، آن را باید Deploy کرد.

برای Deploy کردن یک پروژه کافی است بعد از تنظیم کردن رشته‌ی ارتباطی در DS (قبلا توضیح داده شده است) روی پروژه کلیک راست کرده و گزینه‌ی Deploy را بزنیم.

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

مهمان

نظرات مطالب

اجرای وظایف زمان بندی شده با Quartz.NET - قسمت دوم

ممنون از شما آقا سعید

بله در بعضی موارد سرور می‌تواند از خود من باشد و در بعضی موارد دسترسی ریموت برای نصب و کنترل سرویس را دارم.

درمورد برنامه‌های وب برای این کار : من یکبار این کار را انجام دادم و از cache expiration استفاده کردم. ولی چون این برنامه‌ی وب هیچ request ای نداشت برنامه down شد و عملیات زمان بندی متوقف شد.

پس میشه گفت استفاده از سرویس‌های ویندوزی، راه حل متداولی هست؟

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

مهمان

نظرات مطالب

اجرای وظایف زمان بندی شده با Quartz.NET - قسمت دوم

سرور متعلق به خودتون است؟ دسترسی بالایی دارید مثل دسترسی نصب و همچنین دسترسی اجرای برنامه به صورت سرویس؟ اگر بله، استفاده از سرویس‌های ویندوز nt روش متداولی است. اگر نه، برنامه‌های وب با حداقل دسترسی همین کار رو می‌تونند انجام بدن.

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

سجاد کاردل

مطالب

آموزش Cache در ASP.NET Core - (قسمت اول : مفاهیم اولیه)

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

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

این حافظه، Ram هست و عمل Caching به اینصورت خواهد بود که هر وقت دیتای مورد نظر یکبار از دیتابیس واکشی شود، از دفعات بعد، آن دیتا را در Ram ذخیره میکند و برای درخواست‌های بعدی به دیتابیس Query نمیزند و دیتای مورد نیازش را از Ram میگیرد.

این امر در کنار مزایایی که دارد ، حساسیت بالایی هم بهمراه خواهد داشت؛ چرا که حافظه مورد استفاده Ram، یک حافظه محدود هست همچنین میتواند برای هر سخت افزاری متفاوت باشد. پس پیاده سازی این سیستم نیاز به دو دو تا چهارتا و ساختار درست دارد؛ در غیر اینصورت Cache کردن دیتای غلط میتواند به تنهایی وب‌سایتتان را Down کند؛ پس خیلی باید به این موضوع دقت داشت.

چه زمانی بهتر است از کش استفاده کنیم؟

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

آیا تمام اطلاعات را میتوان کش کرد؟

خیر.

سخت افزاری که برای کش استفاده میکنیم یعنی Ram، بسیار گران‌تر از دیتابیس برای ما تمام میشود؛ چرا که محدود است.
اگر همه دیتاهارا کش کنید، عمل سرچ میان آن زمان بیشتری خواهد برد.

پس اکنون میدانید که میتوانیم داده‌های بی نهایتی را در دیتابیس ذخیره کنیم و فقط با ارزش‌ترین‌ها و پر مصرف‌ترین هارا در حافظه کش، ذخیره میکنیم.

عملیات Cache در Asp.Net Core توسط اینترفیس‌های IMemoryCache و IDistributedCache مدیریت میشود و میتوانید با تزریق این اینترفیس‌ها براحتی از متدهایشان استفاده کنید؛ اما قبل از استفاده لازم است با عملکرد هر یک از آن‌ها آشنا شویم.

روش اول : In-memory Caching (Local Caching)

معمول‌ترین و ابتدایی‌ترین روش برای کش کردن اطلاعات، روش Local Caching و بصورت In-Memory است که اطلاعات را در حافظه Ram همان سروری که برنامه در آن اجرا میشود، کش میکند.

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

اما شرایطی را فرض کنید که برنامه از چندین سرور برای اجرا شدن استفاده میکند و به طبع هر سرور درخواست‌های خودش را داراست که ما باید برای هر یک بصورت جداگانه‌ای یک کش In-Memory را در حافظه Ram هرکدام ایجاد کنیم.

فرض کنید دیتای ما 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 باشد. بخشی از دیتا در Server 1 کش میشود (1 , 3 , 5 , 9) و بخشی دیگر در Server 2 کش خواهد شد (2 , 4 , 6 ,7 , 8 , 10).

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

برای مثال اگر Server 1 به هر دلیلی از بین برود یا Down شود، اطلاعات کش درون آن نیز پاک خواهد شد و بعد از راه اندازی باید همه آن را دوباره از دیتابیس بخواند.
هر کدام از سرور‌ها کش‌های جدایی دارند و باهم Sync نیستند و امکان وجود یک داده‌ی حیاتی در یکی و عدم وجود آن در دیگری، بالاست. فرض کنید برنامه برای هر درخواست، نیاز به اطلاعات دسترسی کاربری را دارد. دسترسی‌های کاربر، در Server 1 کش شده، اما در Server 2 موجود نیست. در Server 2 به دلیل عدم وجود این کش، برنامه برای درخواست‌های معمول خود و چک کردن دسترسی کاربر یا باید هربار به دیتابیس درخواستی را ارسال کند که این برخلاف خواسته ماست و یا باید دیتای مربوط به دسترسی‌های کاربر را بعد از یکبار درخواست، از دیتابیس در خودش کش کند که این‌هم دوباره کاری به حساب میاید و دوبار کش کردن یک دیتا، امر مطلوبی نخواهد بود.

روش هایی وجود دارد که بتوان از سیستم Local Caching در حالت چند سروری هم استفاده کرد و این مشکلات را از بین برد، اما روش استاندارد در حالت چند سروری، استفاده از Distributed Cache‌ها است.

روش دوم : Distributed Caching

در این روش برنامه‌ی ما برای اجرا شدن از چندین سرور شبکه شده به هم، در حال استفاده هست و Cache برنامه، توسط سرورها به اشتراک گذاشته شده.

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

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

■ با خراب شدن یا Down شدن یک سرور، کش موجود در سرور‌های دیگر پاک نمیشود و کماکان قابل استفاده است.

■ به حافظه Ram یک سرور محدود نیست و مشکلات زیادی همچون کمبود سخت افزاری و محدودیت‌های حافظه‌ی Ram را تا حد معقولی کاهش میدهد.

طریقه استفاده از Cache در Asp.Net Core :

بر خلاف ASP.NET web forms و ASP.NET MVC در نسخه‌های Core به بعد، Cache بصورت از پیش ثبت شده، وجود ندارد. کش در Asp.Net Core با فراخوانی سرویس‌های مربوطه‌ی آن قابل استفاده است و نیاز است قبل از استفاده، سرویس آن را در کلاس Startup برنامه فراخوانی کنید.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.AddMemoryCache();
}

اینترفیس IMemoryCache از سیستم تزریق وابستگی‌ها در Core استفاده میکند و برای استفاده از اینترفیس آن، پس از اضافه کردن MemoryCache به Startup ، باید در کنترلر، عمل تزریق وابستگی (DI) را انجام دهید؛ سپس متد‌های مورد نیاز برای کش، در دسترس خواهد بود.

public class HomeController : Controller
{
    private readonly IMemoryCache  _cache;
    public HomeController(IMemoryCache  cache)
    {
        _cache = cache;
    }
    ....
}

برای ذخیره‌ی کش میتوانید از متد Set موجود در این اینترفیس استفاده کنید.

public IActionResult Set()
{
  _cache.Set("CacheKey", data , TimeSpan.FromDays(1));
  return View();
}

در پارامتر اول این متد (CacheKey)، یک کلید، برای اطلاعاتی که میخواهیم کش کنیم قرار میدهیم. دقت کنید که این کلید، شناسه‌ی دیتای شماست و باید طوری آن را در نظر گرفت که با صدا زدن این کلید از سرویس کش، همان دیتای مورد نظر را برگشت دهد (هر Object دیتا، باید کلید Unique خود را داشته باشد).

در پارامتر دوم، دیتای مورد نظر را که میخواهیم کش کنیم، به متد میدهیم و در پارامتر سوم نیز زمان اعتبار و تاریخ انقضای دیتای کش شده را وارد میکنیم؛ به این معنا که دیتای کش شده، بعد از مدت زمان گفته شده، از حافظه کش(Ram) حذف شود و برای دسترسی دوباره و کش کردن دوباره اطلاعات، نیاز به خواندن مجدد از دیتابیس باشد.

برای دسترسی به اطلاعات کش شده میتوانید از متد Get استفاده کنید.

public IActionResult Get()
{
  string data = _cache.Get("CacheKey");
  return View(data);
}

تنها پارامتر ورودی این متد، کلید از قبل نسبت داده شده به اطلاعات کش هست که با استفاده از یکسان بودن کلید در ورودی این متد و کلید Set شده از قبل در حافظه Ram، دیتا مربوط به آن را برگشت میدهد.

متد TryGetValue برای بررسی وجود یا عدم وجود یک کلید در حافظه کش هست و یک Boolean را خروجی میدهد.

public IActionResult Set()
  {
        DateTime data;
       // Look for cache key.
       if (!_cache.TryGetValue( "CacheKey" , out data))
       {
              // Key not in cache, so get data.
              data= DateTime.Now;

            // Save data in cache and set the relative expiration time to one day
             _cache.Set( "CacheKey" , data, TimeSpan.FromDays(1));
        }
        return View(data);
  }

این متد ابتدا بررسی میکند که کلیدی با نام "CacheKey" وجود دارد یا خیر؟ در صورت عدم وجود، آن را میسازد و دیتای مورد نظر را به آن نسبت میدهد.

با استفاده از متد GetOrCreate میتوانید کار متد‌های Get و Set را باهم انجام دهید و در یک متد، وجود یا عدم وجود کش را بررسی و در صورت وجود، مقداری را return و در صورت عدم وجود، ابتدا ایجاد کش و بعد return مقدار کش شده را انجام دهید.

 public IActionResult GetOrCreate()
{
         var data = _cache.GetOrCreate( "CacheKey" , entry =>
         entry.SlidingExpiration = TimeSpan.FromSeconds(3);
         return View(data);
});
    return View(data);
}

برای مدیریت حافظه‌ی Ram شما باید یک Expiration Time را برای کش‌های خود مشخص کنید؛ تا هم حافظه Ram را حجیم نکنید و هم در هر بازه‌ی زمانی، دیتای بروز را از دیتابیس بخوانید. برای این کار option‌های متفاوتی از جمله absolute expiration و sliding expiration وجود دارند.

در اینجا absolute expiration به این معنا است که یک زمان قطعی را برای منقضی شدن کش‌ها مشخص میکند؛ به عبارتی میگوییم کش با کلید فلان، در تاریخ و ساعت فلان حذف شود. اما در sliding expiration یک بازه زمانی برای منقضی شدن کش‌ها مشخص میکنیم؛ یعنی میگوییم بعد از گذشت فلان دقیقه از ایجاد کش، آن را حذف کن و اگر در طی این مدت مجددا خوانده شد، طول مدت زمان آن تمدید خواهد شد.

این تنظیمات را میتوانید در قالب یک option زمان Set کردن یک کش، به آن بدهید.

MemoryCacheEntryOptions options = new MemoryCacheEntryOptions();
options.AbsoluteExpiration = DateTime.Now.AddMinutes(1);
options.SlidingExpiration = TimeSpan.FromMinutes(1);
_cache.Set("CacheKey", data, options );

در مثال بالا هردو option اضافه شده یک کار را انجام میدهند؛ با این تفاوت که absolute expiration تاریخ now را گرفته و یک دقیقه بعد را به آن اضافه کرده و تاریخ انقضای کش را با آن تاریخ set میکند. اما sliding expiration از حالا بمدت یک دقیقه اعتبار دارد.

یکی از روش‌های مدیریت حافظه Ram در کش‌ها این است که برای حذف شدن کش‌ها از حافظه، اولویت بندی‌هایی را تعریف کنید. اولویت‌ها در چهار سطح قابل دسترسی است:

NeverRemove = 3
High = 2
Normal = 1
Low = 0

این اولویت بندی‌ها زمانی کاربرد خواهند داشت که حافظه اختصاصی Ram، برای کش‌ها پر شده باشد و در این حالت سیستم کشینگ بصورت خودمختار، کش‌های با الویت پایین را از حافظه حذف میکند و کش‌های با الویت بیشتر، در حافظه باقی میمانند. این با شماست که الویت را برای دیتا‌های خود تعیین کنید؛ پس باید با دقت و فکر شده این کار را انجام دهید.

MemoryCacheEntryOptions options = new MemoryCacheEntryOptions();
// Low / Normal / High / NeverRemove
options.Priority = CacheItemPriority.High;
cache.Set("CacheKey", data, options);

به این صورت میتوانید الویت‌های متفاوت را در قالب option به کش‌های خود اختصاص دهید.

در این مقاله سعی شد مفاهیم اولیه Cache، طوری گفته شود، تا برای افرادی که میخواهند به تازگی این سیستم را بیاموزند و در پروژه‌های خود استفاده کنند، کاربردی باشد و درک نسبی را نسبت به مزایا و محدودیت‌های این سیستم بدست آورند.

در قسمت دوم همین مقاله بطور تخصصی‌تر به این مبحث میپردازیم و یک پکیج آماده را معرفی میکنیم که خیلی راحت‌تر و اصولی‌تر کش را برای ما پیاده سازی میکند.

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

سام ناصری

مطالب

استفاده از درایوها در Window Azure Storage جهت استفاده در RavenDB

در تلاش برای راه اندازی دیتابیس RavenDB بر روی Windows Azure چند مقاله ‌ای خوندم که گاهی خیلی گیج کننده بود. الان تقریباً به نتایجی رسیده‌ام و دوست دارم در این مقاله نکاتی رو که به نظرم دانستن آنها بایسته است را مطرح کنم. باشد که مفید واقع شود.

پیش زمینه 1، یکی دیگر از روشهای راه اندازی RavenDB:

راه اندازی سرویس، نصب بر روی IIS و استفاده به صورت توکار، روش‌هایی هستند که در خود مستندات نچندان کامل RavenDB در حال حاضر مطرح شده است. راه دیگری که برای راه اندازی RavenDB می‌تواند مورد استفاده قرار گیرد، از طریق برنامه نویسی است. یعنی سرور RavenDB را با اجرای کد بالا می‌آوریم. نگران نباشید، این کار خیلی سخت نیست و به سادگی از طریق نمونه سازی از کلاس HttpServer و ارائه پارامترهای پیکره‌بندی و فراخوانی یک و یا دو متود می‌تواند صورت گیرد. مزیت این روش در پویایی و انعطاف پذیری آن است. شما می‌توانید هر تعداد سرور را با هر پیکره‌بندی پویایی، بالا بیاورید.

به کلمه HttpServer خوب دقت کنید. بله، درست است؛ این یک سرور کامل است و تمام درخواست‌های Http را طبق قواعد RavenDB و البته HTTP پاسخ می‌دهد. حتی studio ی RavenDB ,که یک برنامه Silverlight است, نیز سرو میشود. (برنامه Silverlight در ریسورسهای RavenDB.Database.dll توکار(embed) شده است.)

کد مینیمالیست نمونه، یک RavenDB http server در قالب یک برنامه Console Application:

static void Main(string[] args)
{
    var configuration = new Raven.Database.Config.RavenConfiguration() {
        AccessControlAllowMethods = "All",
        AnonymousUserAccessMode = Raven.Database.Server.AnonymousUserAccessMode.All,
        DataDirectory = @"C:\Sam\labs\HttpServerData",
        Port = 8071,
    };
    var database = new Raven.Database.DocumentDatabase(configuration);
    var server = new Raven.Database.Server.HttpServer(configuration, database);
    database.SpinBackgroundWorkers();
    server.StartListening();

    Console.WriteLine("RavenDB http server is running ...");
    Console.ReadLine();
}

با اجرای برنامه فوق، پایگاه داده شما در پورت 8071 ماشین، فعال است و آماده پاسخگویی. استودیوی RavenDB نیز از طریق مسیر http://127.0.0.1:8071 قابل دسترسی است.

چرا این مطلب را گفتم، چون برای راه اندازی RavenDB در Azure می‌خواهیم از این روش استفاده کنیم. در یک worker role دیگر ما نه IIS داریم و نه یک virtual machine در اختیار داریم تا یک service را بر روی آن نصب کنیم. پس بهترین گزینه برای ما راه اندازی سرور RavenDB از طریق برنامه نویسی است.

پیش زمینه 2، چندساکنی در RavenDB و مسیر داده ها:(Multi Tenancy)

یک سرور RavenDB می‌تواند چندین پایگاه داده را میزبانی کند. هر چند به طور پیش فرض تک ساکنی برگزیده شده است. اما شما می‌توانید پایگاه‌های داده جدید را به سیستم اضافه کنید. مشکلی که من با مستندات RavenDB دارم این است که به طور پیش فرض درباره زمانی مصداق پیدا می‌کنند که RavenDB در حالت تک ساکنی مورد استفاده قرار میگیرد.

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

توجه داشته باشید که در RavenDB اگر در هنگام ساخت پایگاه داده، مسیری را مطرح نکنید، مسیر پیش فرض انتخاب خواهد شد. همچنین در حالت چندساکنی هم هیچ ارتباطی بین پایگاه‌های داده بعدی با پایگاه داده <system> وجود ندارد و همواره مسیر پیش فرض به صورت ~/Databases/dbName خواهد بود که dbName نام پایگاه داده مورد نظر شما است. مهم است که بدانید که ~ در مسیر فوق دارای تعریف رسمی ای نیست و آنچه از کد بر می‌آید ~ مسیر BaseDirectory برای AppDomain جاری است. پس با توجه اینکه نوع برنامه میزبان سرور چیست (IIS, Windows Service, Worker Role) مقدار آن می‌تواند متفاوت باشد.

تعریف Worker Role برای RavenDB

در واقع مطلب اصلی درباره نحوه استفاده از CloudDrive در Web Role یا Worker Role است. همانطور که میدانید Web Role و Worker Role هر دو برای ذخیره سازی داده‌ها مناسب نیستند. در واقع بایستی با این رویکرد به آنها نگاه کنید که فقط کدهای اجرایی بر روی آنها قرار بگیرند و نه چیز دیگری. در مورد استفاده پایگاه داده RavenDB در Windows Azure می‌توانید آن را به صورت یک Worker Role تعریف کنید. اما برای اینکه داده‌ها را ذخیره کنید بایستی از یک Cloud Drive استفاده کنید.

خوب، در ابتد لازم است که کمی درباره‌ی CloudDrive بدانیم؛ خواندن این مطلب درباره‌ی اولین انتشار Windows Azure Drive خالی از لطف نیست.

حالا برای اینکه RavenDB را راه بیاندازیم باید نخست Wroker Role را بسازیم و سپس قطعه کدی بنویسیم تا درایو مجزا و مختصی را برای اینکه RavenDB اطلاعات را در آن بریزد بسازد. در آخر باید Worker Role را تنظیم کنیم تا درایو ساخته شده را در خود mount کند.

برای ساختن درایو قطعه کد زیر آن را انجام میدهد:

CloudStorageAccount storageAccount = CloudStorageAccount.FromConfigurationSetting(connectionString);
// here is when later on you may add code for inititalizing CloudDrive chache
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
blobClient.GetContainerReference("drives").CreateIfNotExist();

CloudDrive cloudDrive = storageAccount.CreateCloudDrive(
    blobClient
    .GetContainerReference("drives")
    .GetPageBlobReference("ravendb4.vhd")
    .Uri.ToString()
);

try
{
    // create a 1GB Virtual Hard Drive
    cloudDrive.Create(1024);
}
catch (CloudDriveException /*ex*/ )
{
    // the most likely exception here is ERROR_BLOB_ALREADY_EXISTS
    // exception is also thrown if the drive already exists 
}

در کد فوق نامهای drives و ravendb.vhd کاملاً اختیاری هستند. اما باید از قواعد نامگذاری container پیروی کنند.

برای سوار کردن درایو قطعه کد زیر آن را انجام میدهد:

string driveLetter = cloudDrive.Mount(25, DriveMountOptions.Force);

توجه داشته باشید که کد سوار کردن درایو، قاعدتاً، بایستی در Worker Role صورت بگیرد و همچنین باید قبل از راه اندازی RavenDB باشد.

این یک ایراد طراحی Windows Azure است که شما نمیتوانید حرف درایو را خودتان انتخاب کنید، بلکه خروجی متود Mount مشخص میکند که درایو در چه حرف درایوی سوار شده است. و شما محدود هستند که کدهای خود را به گونه ای بنویسید که مسیر ذخیره سازی اطلاعات در Cloud Drive را ثابت فرض نکند و ارجاعات به این مسیرها شامل حرف درایو نباشد.

رفع مشکل کندی درایو در Windows Azure با تعریف کش:

کد فوق برای راه اندازی درایو مورد نظر ما کافی است. اما هنوز دارای یک مشکل اساسی و مهم است و آن اینست که بسیار کند عمل خواهد کرد.

با فراخوانی متود CloudDrive.InitializeCache این متود به طور اتوماتیک برای تمام درایوهای mount شده یک کش محلی فراهم میکند و در نتیجه network I/O کمتری صورت خواهد گرفت. توجه داشته باشید که در صورت استفاده از این متود بایستی کش را برای Worker Role تعریف کنید. در صورت عدم استفاده از این متود کارائی پایگاه داده شما به شدت افت میکند. کد زیر را قبل از تعریف هر نوع درایوی قرار دهید.

LocalResource localCache = RoleEnvironment.GetLocalResource("RavenCache");
CloudDrive.InitializeCache(localCache.RootPath, localCache.MaximumSizeInMegabytes);

در کد فوق RavenCache نام یک Local Storage است که شما در تنظیمات Worker Role تعریف میکنید.(نام آن اختیاری است.) برای تعریف Local Storage بایستی در قسمت تنظیمات Worker Role رفته و آنگاه زبانه Local Storage رفته و سپس یک Local Storage را به مانند تصویر زیر اضافه کنید. نام که میتواند هر نامی باشد. اندازه را به اندازه مجموع درایوهایی که میخواهید در Worker Role تعریف کنید قرار دهید(در مثال برنامه ما در اینجا مقدار 1024) و گزینه Clean on role recycle را آنتیک کنید.

حال که درایو مورد نیاز ما آماده است قدم دیگر این است که پورتی را که RavenDB میخواهد در آن فعال شود را تعریف کنیم. برای اینکار بایستی در قسمت تنظیمات Worker Role در زبانه Endpoints رفته و یک endpoint جدید به آن مطابق تصویر زیر ارائه کنیم.

حال که پورت هم تنظیم شده است میتوانیم RavenDB را در Worker Role راه بیاندازیم:

var config = new RavenConfiguration
{
    DataDirectory = driveLetter,
    AnonymousUserAccessMode = AnonymousUserAccessMode.All,
    HttpCompression = true,
    DefaultStorageTypeName = "munin",
    Port = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["Raven"].IPEndpoint.Port,
    PluginsDirectory = "plugins"
};

try
{
    documentDatabase = new DocumentDatabase(config);
    documentDatabase.SpinBackgroundWorkers();
    httpServer = new HttpServer(config, documentDatabase);
    try
    {
        httpServer.StartListening();
    }
    catch (Exception ex)
    {
        Trace.WriteLine("StartRaven Error: " + ex.ToString(), "Error");

        if (httpServer != null)
        {
            httpServer.Dispose();
            httpServer = null;
        }
    }
}
catch (Exception ex)
{
    Trace.WriteLine("StartRaven Error: " + ex.ToString(), "Error");

    if (documentDatabase != null)
    {
        documentDatabase.Dispose();
        documentDatabase = null;
    }
}

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

محسن دلاوری

مطالب

نگه‌داری ساده‌تر نرم‌افزار با معماری Vertical Slices - قسمت اول

معمولا معماری‌های ارائه شد،ه بر اساس جداسازی لایه‌های نرم‌افزار می‌باشد. برای مثال در معماری Hexagonal که آن‌را به Port & Adaptor هم میشناسیم، نرم‌افزار، با استفاده از لایه‌های Domain، Application، Infra و ... تفکیک می‌شوند. منطق تجاری در Domain پیاده سازی می‌شود و رابط‌های مربوط به کار با دیتا تعریف می‌شوند. در لایه‌ی Application، Portها و Adaptorهای مورد نیاز برای استفاده، پیاده‌سازی می‌شوند. در لایه‌ی Infra، رابط‍‌های تعریف شده در Domain پیاده‌سازی شده و در لایه‌ی Application، Adaptorهای پیاده‌سازی شده مورد استفاده قرار میگیرند.

تمام این اتفاقات در سطح لایه‌های برنامه اتفاق می‌افتند و بر همین اساس ما نیاز داریم برای جلوگیری از تغییرات بزرگ، از Abstraction استفاده کنیم و بسیار زیاد استفاده میکنیم. Abstraction یکی از راه‌های غیرمستقیم (InDirection) کردن دسترسی فراخوان به منبع یا تارگت مورد نظر می‌باشد که مزایای زیادی را مانند استفاده‌ی مجدد، جداسازی بخش‌هایی که باعث پیچیدگی می‌شوند و همچنین مخفی کردن وابستگی‌ها برای ما دارد.

Abstraction

می‌دانیم که غیرمستقیم کردن دسترسی به منابع در طراحی نرم‌افزار یک اصل است. اما Abstraction تنها راه جداسازی نیست. راه دیگر طراحی زیرساخت می‌باشد. مانند استفاده از Message Queue (مانند استفاده از MediatR) و یا Load Balancer.

البته منظور این نیست که استفاده‌ی غیر مستقیم از لایه‌های نمایش داده شده را حذف کنیم. مشخصا MediatR در اینجا جداسازی خوبی را برای ما ایجاد کرده که مزایای آن بر کسی پوشیده نیست. مسئله‌ی مهمی که معمولا به آن توجهی نمی‌شود، هزینه‌ی Abstraction می‌باشد. اگر بخواهیم درباره‌ی هزینه‌های Abstraction صحبت کنیم، اشاره به موارد زیر قابل تامل است:

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

دوم کارآیی پایین. البته فقط صحبت در مورد مصرف زیاد حافظه و یا CPU نیست. یکی از این موارد، به دلیل Generic تعریف شدن Repositoryها می‌باشد که باعث می‌شود داده‌های بیشتر از نیازی را به لایه‌های دیگر ارسال کنیم. برای بررسی دقیق‌تر می‌توانید این مقاله‌ را مطالعه بفرمایید.

اما Vertical Slices چگونه به ما در این زمینه کمک میکند. در این معماری، ما به جای تمرکز بر روی لایه‌ها، تمرکز خود را روی فیچرها میگذاریم. در واقع نرم‌افزار را به قسمت‌های بسیار کوچکتری تقسیم میکنیم و از Abstraction اضافی جلوگیری میکنیم. در این صورت اگر تغییری لازم به اعمال شدن دارد، در سطح فیچر اعمال می‌شود و نه در سطح لایه‌ها. در ضمن دیگر Repository و یا Specification ی برای تست وجود ندارد؛ پس میزان تست‌های نوشته شده کاهش پیدا می‌کنند و طبیعتا برای تست Integration میتوانیم کل فیچر را تست کنیم.

در اینجا ما بجای تمرکز بر روی ساختار کل کدبیس، تمرکز خود را بر روی ساختار کدبیس یک فیچر خاص نگه میداریم.

در Vertical Slices Arch ما مشکلی با اشتراک‌گذاری Domain بین فیچر‌ها نداریم. زیرا Domain ما به هیچ فریموورکی وابسته نیست و بصورت مستقیم مورد استفاده قرار میگیرد. لطفا به تصویر زیر توجه بفرمایید:

Vertical Slices Arch

زمانیکه این فیچرهای کوچک توسعه داده می‌شوند، دلیلی برای تعریف Repository و یا Specificationهای بی مورد نداریم. پس میتوانیم به راحتی آن‌ها را حذف کنیم و به صورت مستقیم از EF و یا هر ORM دیگری استفاده کنیم و یا میتوانیم به راحتی از Raw Query‌ها و مزیت آن‌ها بهره‌مند شویم. نگه‌داری یک فیچر کوچک که Command، Handler و Viewها و سایر نیازمندی‌هایش(به استثنای Domain) داخل خودش قرار گرفته و شامل یک ساختار ویژه‌ی خودش با توجه به نیازمندی‌های تعریف شده می‌باشد، بسیار کار ساده‌تری است تا نگه‌داری یک سری لایه که به صورت گسترده از Abstraction در آن‌ها استفاده شده‌است.

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

محمد رعیت پیشه

مطالب

کار با اسکنر در برنامه های تحت وب (قسمت اول)

در اکثر برنامه‌های سازمانی، مثل برنامه‌های مدیریت آرشیو اسناد، همواره این نیاز جزو خواسته‌های کاربران بوده که بتوانند به صورت مستقیم و از طریق تنها یک کلیک، تصویر مورد نظر را اسکن کرده و به صورت خودکار در برنامه وارد کنند؛ یعنی بدون اینکه نیاز باشد با استفاده از یک برنامه دیگر ابتدا تصویر را اسکن کرده و سپس در فرم وب، فایل اسکن شده را Browse کنند.
این نیاز اساسا به معنی دسترسی به سخت افزار کاربر از طریق مرورگر می‌باشد که به دلایل متعددی امکان پذیر نیست! مشکلات امنیتی ایجاد شده در این راه بسیار جدی است. اما خوشبختانه راههایی برای رسیدن به این هدف وجود دارند:

1- ActiveX : که به صورت native فقط در IE پشتیبانی می‌شود (در نسخه‌های جدیدتر IE نیاز به بروز رسانی پلاگین ActiveX controls می‌باشد) و برای استفاده‌ی از آن در مرورگر‌های Firefox و Chrome هم باید از پلاگین‌های جانبی روی هر مرورگر استفاده کرد که مثلا برای اجرای بر روی Firefox، باید افزونه‌ی IE Tab را نصب کرد که تنها کارش این است که سایت را از طریق موتور IE در پنجره‌ی فایرفاکس اجرا کند! که البته این مورد مثل این می‌ماند که سایت در IE باز شده باشد که ممکن است زیاد خوشایند نباشد؛ در غیر اینصورت باید پروژه را از اول بر مبنای اجرای بر روی IE طراحی و پیاده سازی کرد. در ضمن از مشکلات اجرای پلاگین نوشته شده توسط برنامه نویس در IE و نسخه‌های مختلف آن هم چشم پوشی می‌کنیم. یکی از مزیت‌های این روش نسبت به بقیه این هست که دانلود و نصب پلاگین مورد نیاز به صورت خودکار و توسط مرورگر انجام می‌شود.

2- استفاده از یک کامپوننت جانبی : مثل کامپوننت‌های LEADTOOLS که ابزارهای متنوع و SDK‌های بسیار قدرتمندی را برای اینکار و کارهای دیگر، مانند کار با اسکن تصاویر مغزی، پردازش تصویر، بارکد خوان‌ها، مدیریت اسناد و ... فراهم کرده است. قیمت این ابزار بسیار زیاد است و در برخی موارد امکانات فراهم آورده بسیار بیشتر است از خواسته‌ی ما. این ابزار، هم در HTML & Javascript و هم در DotNet قابل استفاده است و مستندات نسبتا خوبی هم در این زمینه ارائه کرده است. همچنین کامپوننت Dynamsoft که باز هم غیر رایگان هست و قیمت بالایی نیز دارد.

اگر روال کار کامپوننت‌های بالا را مورد بررسی قرار دهید (از طریق اجرای Demo ها، اینجا و اینجا) متوجه خواهید شد که هر دو نیاز به نصب یک سرویس یا App سمت کلاینت جهت اجرای دستورات خود دارند. پس می‌شود اینطور نتیجه گرفت که انجام اینکار بدون اینکه چیزی سمت کاربر نصب شود، ممکن نیست و در هر دو، لینک نصب فایل exe سرویس برای دانلود قرار داده شده است. بر این اساس به راه حل سومی خواهیم رسید که خودمان این سرویس را جهت تعامل با اسکنر سمت کاربر طراحی و پیاده سازی نماییم.

اما چطور ممکن است که با اجرای یک فایل exe سمت کاربر (با این فرض که کاربر در یک دامین مطمئن قرار دارد و می‌شود درخواست نصب سرویس را نمود) این امکان را برای کاربر فراهم نمود که با یک کلیک در مرورگر، اسکنر به صورت خودکار اسکن را آغاز کرده و سپس تصویر حاصل را به یکی از کنترلر‌های ما در سمت سرور ارسال نماید؟

برای اینکار ما با دو صورت مساله مواجه هستیم؛ اول اینکه چطور تصویر را سمت کاربر اسکن کنیم و دوم اینکه چطور این تصویر را به سرور ارسال نماییم!
برای مساله‌ی اول از کتابخانه Windows Image Acquisition (WIA) استفاده خواهیم نمود که این کتابخانه به ما این امکان را میدهد تا با سخت افزارهایی که از TWAIN پشتیبانی می‌کنند، بتوانیم ارتباط برقرار نماییم.

برای مساله‌ی دوم هم نیاز به پیاده سازی یک WCF Service و اجرای آن (هاست کردن) در سمت کلاینت داریم. در واقع با صدا زدن متدهای این سرویس، از کتابخانه‌ی بالا استفاده کرده و اسکن را انجام می‌دهیم.

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