مفهوم Offsite SEO
اس کیوال سرور
امنیت
توسعه وب
دات نت فریم ورک
دبلیو پی اف و سیلور لایت
سی و مشتقات
محیطهای مجتمع توسعه
مرورگرها
ویندوز
- شما عالم به مطلب خود هستید، بنابراین سطح آنرا باید برای خوانندهی غیرمطلع تنظیم کنید.
- قبل از شروع کردن به کد نویسی و ارائهی راه حلی، کمی توضیح دهید که چرا دارید اینکار را انجام میدهید. ابتدا باید نیازی را خلق کنید.
- اگر زمان مطالعهی مطلب شما به بیش از 4 دقیقه برسد، شانس خوانده شدن آن زیر 40 درصد خواهد بود.
- ارائه تصاویر مرتبط با بحث را فراموش نکنید. یک تصویر بهتر است از هزاران کلمه.
اهمیت code review
معرفی پروژه DNTFrameworkCore
پروژه DNTFrameworkCore که قصد پشتیبانی از آن را دارم، یک زیرساخت سبک وزن و توسعه پذیر با پشتیبانی از طراحی چند مستاجری با کمترین وابستگی به کتابخانههای ثالث میباشد که با تمرکز بر کاهش زمان و افزایش کیفیت توسعه بخش منطق تجاری پروژههای تحت وب، توسعه داده شده است. به مرور زمان مطالب و مستندات آن نیز کامل خواهد شد. برای برخی از امکانات از جمله اعتبارسنجی خودکار، مدیریت تراکنش ها، شماره گذاری خودکار و ... آزمون واحد نیز در نظر گرفته شده است که در آینده نزدیک با تکمیل آزمون واحد بخشهای دیگر، انتشار آنها نیز انجام خواهد شد.
برای نصب و استفاده از بستههای نیوگت آن، دستورات زیر را اجرا کنید:
PM>Install-Package DNTFrameworkCore PM>Install-Package DNTFrameworkCore.EntityFramework PM>Install-Package DNTFrameworkCore.Web PM>Install-Package DNTFrameworkCore.Web.EntityFramework
به منظور بررسی دقیقتر امکانات آن میتوانید پروژه TestAPI موجود در مخزن گیت هاب را بررسی کنید.
نمونه API پیاده سازی شده:
[Route("api/[controller]")] public class TasksController : CrudController<ITaskService, int, TaskReadModel, TaskModel, TaskFilteredPagedQueryModel> { public TasksController(ITaskService service) : base(service) { } protected override string CreatePermissionName => PermissionNames.Tasks_Create; protected override string EditPermissionName => PermissionNames.Tasks_Edit; protected override string ViewPermissionName => PermissionNames.Tasks_View; protected override string DeletePermissionName => PermissionNames.Tasks_Delete; }
نیاز به علامتگذاری خواصی که باید رمزنگاری شوند
میخواهیم خاصیت یا خاصیتهای مشخصی، از یک مدل را رمزنگاری شده به سمت کلاینت ارسال کنیم. به همین جهت ویژگی خالی زیر را به پروژه اضافه میکنیم تا از آن تنها جهت علامتگذاری این نوع خواص، استفاده کنیم:
using System; namespace EncryptedModelBinder.Utils { [AttributeUsage(AttributeTargets.Property, AllowMultiple = false)] public class EncryptedFieldAttribute : Attribute { } }
رمزنگاری خودکار مدل خروجی از یک اکشن متد
در ادامه کدهای کامل یک ResultFilter را مشاهده میکنید که مدل ارسالی به سمت کلاینت را یافته و سپس خواصی از آنرا که با ویژگی EncryptedField مزین شدهاند، به صورت خودکار رمزنگاری میکند:
namespace EncryptedModelBinder.Utils { public class EncryptedFieldResultFilter : ResultFilterAttribute { private readonly IProtectionProviderService _protectionProviderService; private readonly ILogger<EncryptedFieldResultFilter> _logger; private readonly ConcurrentDictionary<Type, bool> _modelsWithEncryptedFieldAttributes = new ConcurrentDictionary<Type, bool>(); public EncryptedFieldResultFilter( IProtectionProviderService protectionProviderService, ILogger<EncryptedFieldResultFilter> logger) { _protectionProviderService = protectionProviderService; _logger = logger; } public override void OnResultExecuting(ResultExecutingContext context) { var model = context.Result switch { PageResult pageResult => pageResult.Model, // For Razor pages ViewResult viewResult => viewResult.Model, // For MVC Views ObjectResult objectResult => objectResult.Value, // For Web API results _ => null }; if (model is null) { return; } if (typeof(IEnumerable).IsAssignableFrom(model.GetType())) { foreach (var item in model as IEnumerable) { encryptProperties(item); } } else { encryptProperties(model); } } private void encryptProperties(object model) { var modelType = model.GetType(); if (_modelsWithEncryptedFieldAttributes.TryGetValue(modelType, out var hasEncryptedFieldAttribute) && !hasEncryptedFieldAttribute) { return; } foreach (var property in modelType.GetProperties()) { var attribute = property.GetCustomAttributes(typeof(EncryptedFieldAttribute), false).FirstOrDefault(); if (attribute == null) { continue; } hasEncryptedFieldAttribute = true; var value = property.GetValue(model); if (value is null) { continue; } if (value.GetType() != typeof(string)) { _logger.LogWarning($"[EncryptedField] should be applied to `string` proprties, But type of `{property.DeclaringType}.{property.Name}` is `{property.PropertyType}`."); continue; } var encryptedData = _protectionProviderService.Encrypt(value.ToString()); property.SetValue(model, encryptedData); } _modelsWithEncryptedFieldAttributes.TryAdd(modelType, hasEncryptedFieldAttribute); } } }
- در اینجا برای رمزنگاری از IProtectionProviderService استفاده شدهاست که در بستهی DNTCommon.Web.Core تعریف شدهاست. این سرویس در پشت صحنه از سیستم Data Protection استفاده میکند.
- سپس رخداد OnResultExecuting، بازنویسی شدهاست تا بتوان به مدل ارسالی به سمت کلاینت، پیش از ارسال نهایی آن، دسترسی یافت.
- context.Result میتواند از نوع PageResult صفحات Razor باشد و یا از نوع ViewResult مدلهای متداول Viewهای پروژههای MVC و یا از نوع ObjectResult که مرتبط است به پروژههای Web Api بدون هیچ نوع View سمت سروری. هر کدام از این نوعها، دارای خاصیت مدل هستند که در اینجا قصد بررسی آنرا داریم.
- پس از مشخص شدن شیء Model، اکنون حلقهای را بر روی خواص آن تشکیل داده و خواصی را که دارای ویژگی EncryptedFieldAttribute هستند، یافته و آنها را رمزنگاری میکنیم.
روش اعمال این فیلتر باید به صورت سراسری باشد:
namespace EncryptedModelBinder { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddDNTCommonWeb(); services.AddControllersWithViews(options => { options.Filters.Add(typeof(EncryptedFieldResultFilter)); }); }
رمزگشایی خودکار مدل دریافتی از سمت کلاینت
تا اینجا موفق شدیم خواص ویژهای از مدلها را رمزنگاری کنیم. مرحلهی بعد، رمزگشایی خودکار این اطلاعات در سمت سرور است. به همین جهت نیاز داریم تا در سیستم Model Binding پیشفرض ASP.NET Core مداخله کرده و منطق سفارشی خود را تزریق کنیم. بنابراین در ابتدا یک IModelBinderProvider سفارشی را تهیه میکنیم تا در صورتیکه خاصیت جاری در حال بررسی توسط سیستم Model Binding دارای ویژگی EncryptedFieldAttribute بود، از EncryptedFieldModelBinder برای پردازش آن استفاده کند:
namespace EncryptedModelBinder.Utils { public class EncryptedFieldModelBinderProvider : IModelBinderProvider { public IModelBinder GetBinder(ModelBinderProviderContext context) { if (context == null) { throw new ArgumentNullException(nameof(context)); } if (context.Metadata.IsComplexType) { return null; } var propName = context.Metadata.PropertyName; if (string.IsNullOrWhiteSpace(propName)) { return null; } var propInfo = context.Metadata.ContainerType.GetProperty(propName); if (propInfo == null) { return null; } var attribute = propInfo.GetCustomAttributes(typeof(EncryptedFieldAttribute), false).FirstOrDefault(); if (attribute == null) { return null; } return new BinderTypeModelBinder(typeof(EncryptedFieldModelBinder)); } } }
namespace EncryptedModelBinder.Utils { public class EncryptedFieldModelBinder : IModelBinder { private readonly IProtectionProviderService _protectionProviderService; public EncryptedFieldModelBinder(IProtectionProviderService protectionProviderService) { _protectionProviderService = protectionProviderService; } public Task BindModelAsync(ModelBindingContext bindingContext) { if (bindingContext == null) { throw new ArgumentNullException(nameof(bindingContext)); } var logger = bindingContext.HttpContext.RequestServices.GetRequiredService<ILoggerFactory>(); var fallbackBinder = new SimpleTypeModelBinder(bindingContext.ModelType, logger); var valueProviderResult = bindingContext.ValueProvider.GetValue(bindingContext.ModelName); if (valueProviderResult == ValueProviderResult.None) { return fallbackBinder.BindModelAsync(bindingContext); } bindingContext.ModelState.SetModelValue(bindingContext.ModelName, valueProviderResult); var valueAsString = valueProviderResult.FirstValue; if (string.IsNullOrWhiteSpace(valueAsString)) { return fallbackBinder.BindModelAsync(bindingContext); } var decryptedResult = _protectionProviderService.Decrypt(valueAsString); bindingContext.Result = ModelBindingResult.Success(decryptedResult); return Task.CompletedTask; } } }
پس از این تعاریف نیاز است EncryptedFieldModelBinderProvider را به صورت زیر به سیستم معرفی کرد:
namespace EncryptedModelBinder { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddDNTCommonWeb(); services.AddControllersWithViews(options => { options.ModelBinderProviders.Insert(0, new EncryptedFieldModelBinderProvider()); options.Filters.Add(typeof(EncryptedFieldResultFilter)); }); }
یک مثال
فرض کنید مدلهای زیر تعریف شدهاند:
namespace EncryptedModelBinder.Models { public class ProductInputModel { [EncryptedField] public string Id { get; set; } [EncryptedField] public int Price { get; set; } public string Name { get; set; } } } namespace EncryptedModelBinder.Models { public class ProductViewModel { [EncryptedField] public string Id { get; set; } [EncryptedField] public int Price { get; set; } public string Name { get; set; } } }
اکنون کنترلر زیر زمانیکه رندر شود، View متناظر با اکشن متد Index آن، یکسری لینک را به اکشن متد Details، جهت مشاهدهی جزئیات محصول، تولید میکند. همچنین اکشن متد Products آن هم فقط یک خروجی JSON را به همراه دارد:
namespace EncryptedModelBinder.Controllers { public class HomeController : Controller { public IActionResult Index() { var model = getProducts(); return View(model); } public ActionResult<string> Details(ProductInputModel model) { return model.Id; } public ActionResult<List<ProductViewModel>> Products() { return getProducts(); } private static List<ProductViewModel> getProducts() { return new List<ProductViewModel> { new ProductViewModel { Id = "1", Name = "Product 1"}, new ProductViewModel { Id = "2", Name = "Product 2"}, new ProductViewModel { Id = "3", Name = "Product 3"} }; } } }
@model List<ProductViewModel> <h3>Home</h3> <ul> @foreach (var item in Model) { <li><a asp-action="Details" asp-route-id="@item.Id">@item.Name</a></li> } </ul>
و اگر یکی از لینکها را درخواست کنیم، خروجی model.Id، به صورت معمولی و رمزگشایی شدهای مشاهده میشود (این خروجی یک رشتهاست که هیچ ویژگی خاصی به آن اعمال نشدهاست. به همین جهت، اینبار این خروجی معمولی مشاهده میشود). هدف از اکشن متد Details، نمایش رمزگشایی خودکار اطلاعات است.
و یا اگر اکشن متدی که همانند اکشن متدهای Web API، فقط یک شیء JSON را باز میگرداند، فراخوانی کنیم نیز میتوان به خروجی رمزنگاری شدهی زیر رسید:
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: EncryptedModelBinder.zip
مدل برنامه
در اینجا قصد داریم لیستی را با ساختار کلاس Product در اختیار Kendo UI گرید قرار دهیم:
namespace KendoUI03.Models { public class Product { public int Id { set; get; } public string Name { set; get; } public decimal Price { set; get; } public bool IsAvailable { set; get; } } }
پیشنیاز تامین داده مخصوص Kendo UI Grid
برای ارائه اطلاعات مخصوص Kendo UI Grid، ابتدا باید درنظر داشت که این گرید، درخواستهای صفحه بندی خود را با فرمت ذیل ارسال میکند. همانطور که مشاهده میکنید، صرفا یک کوئری استرینگ با فرمت JSON را دریافت خواهیم کرد:
/api/products?{"take":10,"skip":0,"page":1,"pageSize":10,"sort":[{"field":"Id","dir":"desc"}]}
{ "Data": [ {"Id":1500,"Name":"نام 1500","Price":2499.0,"IsAvailable":false}, {"Id":1499,"Name":"نام 1499","Price":2498.0,"IsAvailable":true} ], "Total":1500, "Aggregates":null }
میتوان برای تمام اینها، کلاس و Parser تهیه کرد و یا ... پروژهی سورس بازی به نام Kendo.DynamicLinq نیز چنین کاری را میسر میسازد که در ادامه از آن استفاده خواهیم کرد. برای نصب آن تنها کافی است دستور ذیل را صادر کنید:
PM> Install-Package Kendo.DynamicLinq
تامین کنندهی داده سمت سرور
همانند مطلب کار با Kendo UI DataSource ، یک ASP.NET Web API Controller جدید را به پروژه اضافه کنید و همچنین مسیریابیهای مخصوص آنرا به فایل global.asax.cs نیز اضافه نمائید.
using System.Linq; using System.Net.Http; using System.Web.Http; using Kendo.DynamicLinq; using KendoUI03.Models; using Newtonsoft.Json; namespace KendoUI03.Controllers { public class ProductsController : ApiController { public DataSourceResult Get(HttpRequestMessage requestMessage) { var request = JsonConvert.DeserializeObject<DataSourceRequest>( requestMessage.RequestUri.ParseQueryString().GetKey(0) ); var list = ProductDataSource.LatestProducts; return list.AsQueryable() .ToDataSourceResult(request.Take, request.Skip, request.Sort, request.Filter); } } }
ProductDataSource.LatestProducts صرفا یک لیست جنریک تهیه شده از کلاس Product است. در نهایت با استفاده از متد الحاقی جدید ToDataSourceResult، به صورت خودکار مباحث صفحه بندی سمت سرور به همراه مرتب سازی اطلاعات، صورت گرفته و اطلاعات نهایی با فرمت DataSourceResult بازگشت داده میشود. DataSourceResult نیز در Kendo.DynamicLinq تعریف شده و سه فیلد یاد شدهی Data، Total و Aggregates را تولید میکند.
تا اینجا کارهای سمت سرور این مثال به پایان میرسد.
تهیه View نمایش اطلاعات ارسالی از سمت سرور
اعمال مباحث بومی سازی
<head> <meta charset="utf-8" /> <meta http-equiv="Content-Language" content="fa" /> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Kendo UI: Implemeting the Grid</title> <link href="styles/kendo.common.min.css" rel="stylesheet" type="text/css" /> <!--شیوه نامهی مخصوص راست به چپ سازی--> <link href="styles/kendo.rtl.min.css" rel="stylesheet" /> <link href="styles/kendo.default.min.css" rel="stylesheet" type="text/css" /> <script src="js/jquery.min.js" type="text/javascript"></script> <script src="js/kendo.all.min.js" type="text/javascript"></script> <!--محل سفارشی سازی پیامها و مسایل بومی--> <script src="js/cultures/kendo.culture.fa-IR.js" type="text/javascript"></script> <script src="js/cultures/kendo.culture.fa.js" type="text/javascript"></script> <script src="js/messages/kendo.messages.en-US.js" type="text/javascript"></script> <style type="text/css"> body { font-family: tahoma; font-size: 9pt; } </style> <script type="text/javascript"> // جهت استفاده از فایل: kendo.culture.fa-IR.js kendo.culture("fa-IR"); </script> </head>
- سپس سه فایل kendo.culture.fa-IR.js، kendo.culture.fa.js و kendo.messages.en-US.js نیز اضافه شدهاند. فایلهای fa و fa-Ir آن هر چند به ظاهر برای ایران طراحی شدهاند، اما نام ماههای موجود در آن عربی است که نیاز به ویرایش دارد. به همین جهت به سورس این فایلها، جهت ویرایش نهایی نیاز خواهد بود که در پوشهی src\js\cultures مجموعهی اصلی Kendo UI موجود هستند (ر.ک. فایل پیوست).
- فایل kendo.messages.en-US.js حاوی تمام پیامهای مرتبط با Kendo UI است. برای مثال«رکوردهای 10 تا 15 از 1000 ردیف» را در اینجا میتوانید به فارسی ترجمه کنید.
- متد kendo.culture کار مشخص سازی فرهنگ بومی برنامه را به عهده دارد. برای مثال در اینجا به fa-IR تنظیم شدهاست. این مورد سبب خواهد شد تا از فایل kendo.culture.fa-IR.js استفاده گردد. اگر مقدار آنرا به fa تنظیم کنید، از فایل kendo.culture.fa.js کمک گرفته خواهد شد.
راست به چپ سازی گرید
تنها کاری که برای راست به چپ سازی Kendo UI Grid باید صورت گیرد، محصور سازی div آن در یک div با کلاس مساوی k-rtl است:
<div class="k-rtl"> <div id="report-grid"></div> </div>
تامین داده و نمایش گرید
در ادامه کدهای کامل DataSource و Kendo UI Grid را ملاحظه میکنید:
<script type="text/javascript"> $(function () { var productsDataSource = new kendo.data.DataSource({ transport: { read: { url: "api/products", dataType: "json", contentType: 'application/json; charset=utf-8', type: 'GET' }, parameterMap: function (options) { return kendo.stringify(options); } }, schema: { data: "Data", total: "Total", model: { fields: { "Id": { type: "number" }, //تعیین نوع فیلد برای جستجوی پویا مهم است "Name": { type: "string" }, "IsAvailable": { type: "boolean" }, "Price": { type: "number" } } } }, error: function (e) { alert(e.errorThrown); }, pageSize: 10, sort: { field: "Id", dir: "desc" }, serverPaging: true, serverFiltering: true, serverSorting: true }); $("#report-grid").kendoGrid({ dataSource: productsDataSource, autoBind: true, scrollable: false, pageable: true, sortable: true, filterable: true, reorderable: true, columnMenu: true, columns: [ { field: "Id", title: "شماره", width: "130px" }, { field: "Name", title: "نام محصول" }, { field: "IsAvailable", title: "موجود است", template: '<input type="checkbox" #= IsAvailable ? checked="checked" : "" # disabled="disabled" ></input>' }, { field: "Price", title: "قیمت", format: "{0:c}" } ] }); }); </script>
- در اینجا ذکر contentType الزامی است. زیرا ASP.NET Web API بر این اساس است که تصمیم میگیرد، خروجی را به صورت JSON ارائه دهد یا XML.
- با استفاده از parameterMap، سبب خواهیم شد تا پارامترهای ارسالی به سرور، با فرمت صحیحی تبدیل به JSON شده و بدون مشکل به سرور ارسال گردند.
- در قسمت schema باید نام فیلدهای موجود در DataSourceResult دقیقا مشخص شوند تا گرید بداند که data را باید از چه فیلدی استخراج کند و تعداد کل ردیفها در کدام فیلد قرار گرفتهاست.
- نحوهی تعریف model را نیز در اینجا ملاحظه میکنید. ذکر نوع فیلدها در اینجا بسیار مهم است و اگر قید نشوند، در حین جستجوی پویا به مشکل برخواهیم خورد. زیرا پیش فرض نوع تمام فیلدها string است و در این حالت نمیتوان عدد 1 رشتهای را با یک فیلد از نوع int در سمت سرور مقایسه کرد.
- در اینجا serverPaging، serverFiltering و serverSorting نیز به true تنظیم شدهاند. اگر این مقدار دهیها صورت نگیرد، این اعمال در سمت کلاینت انجام خواهند شد.
پس از تعریف DataSource، تنها کافی است آنرا به خاصیت dataSource یک kendoGrid نسبت دهیم.
- autoBind: true سبب میشود تا اطلاعات DataSource بدون نیاز به فراخوانی متد read آن به صورت خودکار دریافت شوند.
- با تنظیم scrollable: false، اعلام میکنیم که قرار است تمام رکوردها در معرض دید قرارگیرند و اسکرول پیدا نکنند.
- pageable: true صفحه بندی را فعال میکند. این مورد نیاز به تنظیم pageSize: 10 در قسمت DataSource نیز دارد.
- با sortable: true مرتب سازی ستونها با کلیک بر روی سرستونها فعال میگردد.
- filterable: true به معنای فعال شدن جستجوی خودکار بر روی فیلدها است. کتابخانهی Kendo.DynamicLinq حاصل آنرا در سمت سرور مدیریت میکند.
- reorderable: true سبب میشود تا کاربر بتواند محل قرارگیری ستونها را تغییر دهد.
- ذکر columnMenu: true اختیاری است. اگر ذکر شود، امکان مخفی سازی انتخابی ستونها نیز مسیر خواهد شد.
- در آخر ستونهای گرید مشخص شدهاند. با تعیین "{format: "{0:c سبب نمایش فیلدهای قیمت با سه رقم جدا کننده خواهیم شد. مقدار ریال آن از فایل فرهنگ جاری تنظیم شده دریافت میگردد. با استفاده از template تعریف شده نیز سبب نمایش فیلد bool به صورت یک checkbox خواهیم شد.
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید:
KendoUI03.zip
آیا جداول بهینه سازی شدهی برای حافظه، همان DBCC PINTABLE منسوخ شده هستند؟
در نگارشهای قدیمیتر اس کیوال سرور، دستوری وجود داشت به نام DBCC PINTABLE که سبب ثابت نگه داشتن صفحات جداول مبتنی بر دیسک یک دیتابیس، در حافظه میشد. به این ترتیب تمام خواندنهای مرتبط با آن جدول، از حافظه صورت میگرفت. مشکل این روش که سبب منسوخ شدن آن گردید، اثرات جانبی آن بود؛ مانند خوانده شدن صفحات جدیدتر (با توجه به اینکه ساختار پردازشی و موتور بانک اطلاعاتی تغییری نکرده بود) و نیاز به حافظهی بیشتر تا حدی که کل کش بافر سیستم را پر میکرد و امکان انجام سایر امور آن مختل میشدند. همچنین اولین ارجاعی به یک جدول، سبب قرار گرفتن کل آن در حافظه میگشت. به علاوه ساختار این سیستم نیز همانند روش مبتنی بر دیسک، بر اساس همان روشهای قفل گذاری، ذخیره سازی اطلاعات و تهیه ایندکسهای متداول بود.
اما جداول بهینه سازی شدهی برای حافظه، از یک موتور کاملا جدید استفاده میکنند؛ با ساختار جدیدی برای ذخیره سازی اطلاعات و تهیه ایندکسها. دسترسی به اطلاعات آنها شامل قفل گذاریهای متداول نیست و در آن حداقل زمان دسترسی به اطلاعات درنظر گرفته شدهاست. همچنین در آنها data pages یا index pages و کش بافر نیز وجود ندارد.
نحوهی ذخیره سازی و مدیریت اطلاعات جداول بهینه سازی شده برای حافظه
جداول بهینه سازی شده برای حافظه، فرمت ردیفهای کاملا جدیدی را نیز به همراه دارند و جهت قرارگرفتن در حافظه ودسترسی سریع به آنها بهینه سازی شدهاند. برخلاف جداول مبتنی بر دیسک سخت که اطلاعات آنها در یک سری صفحات خاص به نامهای data or index pages ذخیره میشوند، اینگونه جداول، دارای ظروف مبتنی بر صفحه نیستند و از مفهوم چند نگارشی برای ذخیره سازی اطلاعات استفاده میکنند؛ به این معنا که ردیفها به ازای هر تغییری، دارای یک نگارش جدید خواهند بود و بلافاصله در همان نگارش اصلی به روز رسانی نمیشوند.
در اینجا هر ردیف دارای یک timestamp شروع و یک timestamp پایان است. timestamp شروع بیانگر تراکنشی است که ردیف را ثبت کرده و timestamp پایان برای مشخص سازی تراکنشی بکار میرود که ردیف را حذف کرده است. اگر timestamp پایان، دارای مقدار بینهایت باشد، به این معنا است که ردیف متناظر با آن هنوز حذف نشدهاست. به روز رسانی یک ردیف در اینجا، ترکیبی است از حذف یک ردیف موجود و ثبت ردیفی جدید. برای یک عملیات فقط خواندنی، تنها نگارشهایی که timestamp معتبری داشته باشند، قابل مشاهده خواهند بود و از مابقی صرفنظر میگردد.
در OLTP درون حافظهای که از روش چندنگارشی همزمانی استفاده میکند، برای یک ردیف مشخص، ممکن است چندین نگارش وجود داشته باشند؛ بسته به تعداد باری که یک رکورد به روز رسانی شدهاست. در اینجا یک سیستم garbage collection همیشه فعال، نگارشهایی را که توسط هیچ تراکنشی مورد استفاده قرار نمیگیرند، به صورت خودکار حذف میکند؛ تا مشکل کمبود حافظه رخ ندهد.
آیا میتوان به کارآیی جداول بهینه سازی شده برای حافظه با همان روش متداول مبتنی بر دیسک اما با بکارگیری حافظهی بیشتر و استفاده از یک SSD RAID رسید؟
خیر! حتی اگر کل بانک اطلاعاتی مبتنی بر دیسک را در حافظه قرار دهید به کارآیی روش جداول بهینه سازی شدهی برای حافظه نخواهید رسید. زیرا در آن هنوز مفاهیمی مانند data pages و index pages به همراه یک buffer pool پیچیده وجود دارند. در روشهای مبتنی بر دیسک، ردیفها از طریق page id و row offset آنها قابل دسترسی میشوند. اما در جداول بهینه سازی شدهی برای حافظه، ردیفهای جداول با یک B-tree خاص به نام Bw-Tree در دسترس هستند.
میزان حافظهی مورد نیاز برای جداول بهینه سازی شدهی برای حافظه
باید درنظر داشت که تمام جداول بهینه سازی شدهی برای حافظه، به صورت کامل در حافظه ذخیره خواهند شد. بنابراین بدیهی است که نیاز به مقدار کافی حافظه در اینجا ضروری است. توصیه صورت گرفته، داشتن حافظهای به میزان دو برابر اندازهی اطلاعات است. البته در اینجا چون با یک سیستم هیبرید سر و کار داریم، حافظهی کافی جهت کار buffer pool مختص به جداول مبتنی بر دیسک را نیز باید درنظر داشت.
همچنین اگر به اندازهی کافی حافظه در سیستم تعبیه نشود، شاهد شکست مداوم تراکنشها خواهید بود. به علاوه امکان بازیابی و restore جداول را نیز از دست خواهید داد.
البته لازم به ذکر است که اگر کل بانک اطلاعاتی شما چند ترابایت است، نیازی نیست به همین اندازه یا بیشتر حافظه تهیه کنید. فقط باید به اندازهی جداولی که قرار است جهت قرار گرفتن در حافظه بهینه سازی شوند، حافظه تهیه کنید که حداکثر آن 256 گیگابایت است.
چه برنامههایی بهتر است از امکانات OLTP درون حافظهای SQL Server 2014 استفاده کنند؟
- برنامههایی که در آنها تعداد زیادی تراکنش کوتاه مدت وجود دارد به همراه درجهی بالایی از تراکنشهای همزمان توسط تعداد زیادی کاربر.
- اطلاعاتی که توسط برنامه زیاد مورد استفاده قرار میگیرند را نیز میتوان در جداول بهینه سازی شده جهت حافظه قرار داد.
- زمانیکه نیاز به اعمال دارای write بسیار سریع و با تعداد زیاد است. چون در جداول بهینه سازی شدهی برای حافظه، صفحات دادهها و ایندکسها وجود ندارند، نسبت به حالت مبتنی بر دیسک، بسیار سریعتر هستند. در روشهای متداول، برای نوشتن اطلاعات در یک صفحه، مباحث همزمانی و قفلگذاری آنرا باید در نظر داشت. در صورتیکه در روش بهینه سازی شدهی برای حافظه، به صورت پیش فرض از حالتی همانند snapshot isolation و همزمانی مبتنی بر نگارشهای مختلف رکورد استفاده میشود.
- تنظیم و بهینه سازی جداولی با تعداد Read بالا. برای مثال، جداول پایه سیستم که اطلاعات تعاریف محصولات در آن قرار دارند. این نوع جداول عموما با تعداد Readهای بالا و تعداد Write کم شناخته میشوند. چون طراحی جداول مبتنی بر حافظه از hash tables و اشارهگرهایی برای دسترسی به رکوردهای موجود استفاده میکند، اعمال Read آن نیز بسیار سریعتر از حالت معمول هستند.
- مناسب جهت کارهای data warehouse و ETL Staging Table. در جداول مبتنی بر حافظه امکان عدم ذخیره سازی اطلاعات بر روی دیسک سخت نیز پیش بینی شدهاست. در این حالت فقط اطلاعات ساختار جدول، ذخیرهی نهایی میگردد و اگر سرور نیز ری استارت گردد، مجددا میتواند اطلاعات خود را از منابع اصلی data warehouse تامین کند.
محدودیتهای جداول بهینه سازی شدهی برای حافظه در SQL Server 2014
- تغیر اسکیما و ساختار جداول بهینه سازی شدهی برای حافظه مجاز نیست. به بیان دیگر دستور ALTER TABLE برای اینگونه جداول کاربردی ندارد. این مورد جهت ایندکسها نیز صادق است. همان زمانیکه جدول ایجاد میشود، باید ایندکس آن نیز تعریف گردد و پس از آن این امکان وجود ندارد.
تنها راه تغییر اسکیمای اینگونه جداول، Drop و سپس ایجاد مجدد آنها است.
البته باید درنظر داشت که SQL Server 2014، اولین نگارش این فناوری را ارائه دادهاست و در نگارشهای بعدی آن، بسیاری از این محدودیتها قرار است که برطرف شوند.
- جداول بهینه سازی شدهی برای حافظه حتما باید دارای یک ایندکس باشند. البته اگر یک primary key را برای آنها تعریف نمائید، کفایت میکند.
- از unique indexها پشتیبانی نمیکند، مگر اینکه از نوع primary key باشد.
- حداکثر 8 ایندکس را میتوان بر روی اینگونه جداول تعریف کرد.
- امکان تعریف ستون identity در آن وجود ندارد. اما میتوان از قابلیت sequence برای رسیدن به آن استفاده کرد.
- DML triggers را پشتیبانی نمیکند.
- کلیدهای خارجی و قیود را پشتیبانی نمیکند.
- حداکثر اندازهی یک ردیف آن 8060 بایت است. بنابراین از نوعهای دادهای max دار و XML پشتیبانی نمیکند.
این مورد در حین ایجاد جدول بررسی شده و اگر اندازهی ردیف محاسبهی شدهی آن توسط SQL Server 2014 بیش از 8060 بایت باشد، جدول را ایجاد نخواهد کرد.
اگر سرور را ری استارت کنیم، چه اتفاقی برای اطلاعات جداول بهینه سازی شدهی برای حافظه رخ میدهد؟
حالت DURABILTY انتخاب شدهی در حین ایجاد جدول بهینه سازی شدهی برای حافظه، تعیین کنندهای این مساله است. اگر SCHEMA_ONLY انتخاب شده باشد، کل اطلاعات شما با ری استارت سرور از دست خواهد رفت؛ البته اطلاعات ساختار جدول حفظ خواهد گردید. اگر حالت SCHEMA_AND_DATA انتخاب شود، اطلاعات شما پس از ریاستارت سرور نیز در دسترس خواهد بود. این اطلاعات به صورت خودکار از لاگ تراکنشها بازیابی شده و مجددا در حافظه قرار میگیرند.
حالت SCHEMA_ONLY برای مصارف برنامههای data warehouse بیشتر کاربرد دارد. جایی که اطلاعات قرار است از منابع دادهی مختلفی تامین شوند.
برای مطالعه بیشتر
SQL Server 2014: NoSQL Speeds with Relational Capabilities
SQL Server 2014 In-Memory OLTP Architecture and Data Storage
Overview of Applications, Indexes and Limitations for SQL Server 2014 In-Memory OLTP Tables
Microsoft SQL Server 2014: In-Memory OLTP Overview
SQL Server in Memory OLTP for Database Developers
Exploring In-memory OLTP Engine (Hekaton) in SQL Server 2014 CTP1