اشتراکها
ml5.js is a high level JavaScript library for machine learning. The main idea of this project is to further reduce the barriers between lower level machine learning and creative outputs using JavaScript
نظرات مطالب
Senior Developer به چه کسی گفته می شود؟
با سلام و سپاس
من کمتر از 3 سال تجربه برنامه نویسی(به صورت حرفه ای) دارم ولی خودم رو از سطح Junior و Mid-Level خیلی بالاتر میبینم (بدون اعتماد به نفس کاذب) از طرفی با توجه به تعاریفی که جنابعالی از Senior Developer داشتید خودم رو در این سطح هم نمیدانم... به نظر شما من کدوم اصطلاح رو برای خودم به کار ببرم؟ (البته لازمه بگم که من فاصله خیلی زیادی رو بین Mid-Level و Senior Developer میبینم)
با سپاس
من کمتر از 3 سال تجربه برنامه نویسی(به صورت حرفه ای) دارم ولی خودم رو از سطح Junior و Mid-Level خیلی بالاتر میبینم (بدون اعتماد به نفس کاذب) از طرفی با توجه به تعاریفی که جنابعالی از Senior Developer داشتید خودم رو در این سطح هم نمیدانم... به نظر شما من کدوم اصطلاح رو برای خودم به کار ببرم؟ (البته لازمه بگم که من فاصله خیلی زیادی رو بین Mid-Level و Senior Developer میبینم)
با سپاس
فرض کنید در برنامهی خود «کیف پولی» را طراحی کردهاید که بر اساس آن، کاربر میتواند خرید کند. این کیف پول، از Id کاربر و موجودی فعلی او تشکیل میشود:
و برای مثال موجودی فعلی کاربر 1، مقدار 300 است:
اکنون کوئریهای متداول زیر را که از یک read و سپس update تشکیل شدهاند، درنظر بگیرید:
- دو عمل read و سپس update صورت گرفتهی فوق، مربوط به یک درخواست خرید است.
- در اینجا مقدار متغیر amount در ابتدای کار، مساوی 300 است که مربوط به همان insert ابتدایی است.
- سپس از این مقدار در کوئری دومی (برای مثال حاصل از خرید شماره یک)، 100 واحد کم میشود (برای مثال قیمت کل خرید است).
- در این حالت نتیجهی آن یا همان موجودی جدید کاربر، 200 خواهد بود.
معادل این عملیات در EF-Core چنین دستورات متداولی است:
سؤال: اگر کوئریهای فوق را در یک برنامهی ذاتا چند ریسمانی وب، دوبار به صورت همزمان اجرا کنیم، یعنی دو عمل خرید موازی را شبیه سازی کنیم، چه اتفاقی رخ میدهد؟ آیا موجودی نهایی اینبار برای مثال 100 میشود (با فرض 300 بودن موجودی ابتدایی)؟
پاسخ خیر است! و آنرا میتوانید در تصویر زیر مشاهده کنید:
در اینجا برای شبیه سازی اجرای موازی دو کوئری، از دستور WAITFOR TIME استفاده شدهاست که برای برای آزمایش آن میتوانید مقدار آنرا به یک دقیقه بعد تنظیم کرده و سپس آنرا در دو پنجرهی SQL server management studio اجرا کنید.
همانطور که مشاهده میکنید، با اجرای موازی این دو کوئری، یعنی دوبار خرید کردن همزمان، 100 واحد گم شدهاست ! به این مشکل همزمانی read و سپس update رخ داده، یک «race condition» گفته میشود و این روزها که مطالب منتشر شدهی از آسیب پذیریهای برنامههای وب ایرانی را بررسی میکنم، این مورد در صدر آنها قرار دارد!
علت اینجا است که عموما برنامه نویسها، برنامههای وب را در یک تک سشن باز شدهی توسط مرورگر خود آزمایش میکنند و در این حالت، همه چیز خوب است و اعمال آن به ترتیب پیش میروند. اما فراموش میکنند که میتوان قسمتهای مختلف برنامههای وب را به صورت همزمان، موازی و چندباره نیز اجرا کرد؛ حتی اگر آن قسمت متعلق به یک کاربر باشد.
سؤال: آیا استفاده تراکنشها این مشکل را حل نمیکنند؟!
عموما برنامه نویسها تصور میکنند که میتوانند تمام اینگونه مشکلات را با تراکنشها حل کنند:
همانطور که مشاهده میکنید، اینبار هرچند هر دو عملیات خرید داخل BEGIN TRAN و COMMIT TRAN قرار گرفتهاند، اما ... مشکل همزمانی هنوز پابرجا است! چون نوع پیشفرض تراکنش مورد استفاده، READ COMMITTED isolation level است و عدم دقت به آن ممکن است این تصور را ایجاد کند که با تعریف تراکنشها، تمام مشکلات همزمانی برطرف میشوند.
راهحلهای پیشنهادی جهت حل مشکل همزمانی عملیات read/update
برای حل مشکلات مرتبط با race condition و همزمانی درخواستهای read/update، میتوان از یکی از روشهای زیر استفاده کرد:
الف) بجای اینکه یکبار کوئری read و یکبار کوئری update به صورت جداگانه صادر شوند، فقط یکبار کوئری update داشته باشیم.
ب) پیاده سازی Row level locking؛ در صورت پشتیبانی بانک اطلاعاتی مورد استفاده از آن
ج) استفاده از تراکنشهایی از نوع SERIALIZABLE
د) پیاده سازی optimistic locking
این موارد را در ادامه با توضیحات بیشتری بررسی میکنیم.
الف) پرهیز از خواندن و به روز رسانی جداگانه
بجای اینکه مانند اعمال فوق، یکبار select داشته باشیم و یکبار update، بهتر است فقط یک دستور update بکارگرفته شود:
اینبار با خلاصه شدن دو دستور select و update به یک دستور update، دیگر پس از دو خرید همزمان، 100 واحد گم شده مشاهده نمیشود (!) و موجودی نهایی صحیح است.
ب) پیاده سازی Row level locking
همیشه امکان تغییر عملیات مورد نیاز، به سادگی حالت الف نیست. در یک چنین حالتهایی جهت حداقل شدن تغییرات مورد نیاز، میتوان از row level locking استفاده کرد:
در اینجا اضافه شدن WITH (UPDLOCK, HOLDLOCK) را به Select تعریف شده، مشاهده میکنید که به آنها locking hints هم گفته میشود و داخل BEGIN TRAN و COMMIT TRAN عمل میکنند (که نوع پیشفرض آن READ COMMITTED isolation level است). کار UPDLOCK، تبدیل shared lock پیشفرض، به update lock است و کار HOLDLOCK، نگه داشتن قفل صورت گرفته تا پایان کار تراکنش تعریف شدهاست.
با این تغییرات، هر تراکنش همزمان دیگری، تا زمانیکه قفل صورت گرفتهی بر روی ردیف select، رها نشود (یعنی تا زمانیکه تراکنش قفل کننده، به COMMIT TRAN برسد)، نمیتواند آنرا تغییر دهد. به همین جهت است که در تصویر فوق، هرچند هر دو عملیات همزمان اجرا شدهاند، اما یکی موجودی ابتدایی 300 را میبیند و دیگری پس از صبر کردن تا پایان تراکنش و رها شدن قفل، موجودی تغییر یافتهی جدیدی را مشاهده کرده و از آن استفاده میکند. به این ترتیب دیگر 100 واحدی که در اولین تصویر این مطلب مشاهده کردید، گم نشدهاست.
ج) استفاده از تراکنشهایی از نوع SERIALIZABLE
بجای استفاده از روش row level locking یاد شده، روش دیگری را که میتوان استفاده کرد، تغییر نوع پیشفرض تراکنش مورد استفادهاست. برای مثال اگر از یک SERIALIZABLE transaction استفاده کنیم؛ یعنی SET TRANSACTION ISOLATION LEVEL SERIALIZABLE را در ابتدای کار ذکر کنیم و برای مثال دو تراکنش همزمان را اجرا کنیم، اگر در تراکنش اول اطلاعاتی خوانده شود، در هیچ تراکنش دیگری نمیتوان این اطلاعات خوانده شده را تا پایان کار تراکنش اول، تغییر داد:
د) پیاده سازی optimistic locking
پیاده سازی optimistic locking و یا Optimistic concurrency control عموما در سمت برنامه رخ میدهد و توسط ORMها زیاد مورد استفاده قرار میگیرد؛ مانند اضافه کردن ستون اضافی version و یا timestamp به جداول تعریف شده. در این حالت تمام updateها به همراه یک where اضافی هستند تا بررسی کنند که آیا version دریافتی در حین خواندن ردیف در حال به روز رسانی، تغییر کردهاست یا خیر؟ اگر تغییر کردهاست، تراکنش را با خطایی خاتمه خواهند داد. این روش برخلاف حالتهای ب و ج، حتی خارج از یک تراکنش نیز کار میکند و مشکلات قفل کردن طولانی مدت رکوردها توسط آنها را به همراه ندارد.
CREATE TABLE accounts ( user_id INTEGER PRIMARY KEY, balance INTEGER NOT NULL );
INSERT INTO accounts(user_id, balance) VALUES (1, 300);
DECLARE @amount INT; SET @amount = ( SELECT balance FROM accounts WHERE user_id = 1 ); SELECT @amount as 'balance' UPDATE accounts SET balance = @amount - 100 WHERE user_id = 1; SELECT balance as 'balance after shopping' FROM accounts WHERE user_id = 1
- در اینجا مقدار متغیر amount در ابتدای کار، مساوی 300 است که مربوط به همان insert ابتدایی است.
- سپس از این مقدار در کوئری دومی (برای مثال حاصل از خرید شماره یک)، 100 واحد کم میشود (برای مثال قیمت کل خرید است).
- در این حالت نتیجهی آن یا همان موجودی جدید کاربر، 200 خواهد بود.
معادل این عملیات در EF-Core چنین دستورات متداولی است:
var account1 = context.Accounts.First(x => x.UserId == 1); account1.Balance -= 100; context.SaveChanges();
سؤال: اگر کوئریهای فوق را در یک برنامهی ذاتا چند ریسمانی وب، دوبار به صورت همزمان اجرا کنیم، یعنی دو عمل خرید موازی را شبیه سازی کنیم، چه اتفاقی رخ میدهد؟ آیا موجودی نهایی اینبار برای مثال 100 میشود (با فرض 300 بودن موجودی ابتدایی)؟
پاسخ خیر است! و آنرا میتوانید در تصویر زیر مشاهده کنید:
در اینجا برای شبیه سازی اجرای موازی دو کوئری، از دستور WAITFOR TIME استفاده شدهاست که برای برای آزمایش آن میتوانید مقدار آنرا به یک دقیقه بعد تنظیم کرده و سپس آنرا در دو پنجرهی SQL server management studio اجرا کنید.
همانطور که مشاهده میکنید، با اجرای موازی این دو کوئری، یعنی دوبار خرید کردن همزمان، 100 واحد گم شدهاست ! به این مشکل همزمانی read و سپس update رخ داده، یک «race condition» گفته میشود و این روزها که مطالب منتشر شدهی از آسیب پذیریهای برنامههای وب ایرانی را بررسی میکنم، این مورد در صدر آنها قرار دارد!
علت اینجا است که عموما برنامه نویسها، برنامههای وب را در یک تک سشن باز شدهی توسط مرورگر خود آزمایش میکنند و در این حالت، همه چیز خوب است و اعمال آن به ترتیب پیش میروند. اما فراموش میکنند که میتوان قسمتهای مختلف برنامههای وب را به صورت همزمان، موازی و چندباره نیز اجرا کرد؛ حتی اگر آن قسمت متعلق به یک کاربر باشد.
سؤال: آیا استفاده تراکنشها این مشکل را حل نمیکنند؟!
عموما برنامه نویسها تصور میکنند که میتوانند تمام اینگونه مشکلات را با تراکنشها حل کنند:
همانطور که مشاهده میکنید، اینبار هرچند هر دو عملیات خرید داخل BEGIN TRAN و COMMIT TRAN قرار گرفتهاند، اما ... مشکل همزمانی هنوز پابرجا است! چون نوع پیشفرض تراکنش مورد استفاده، READ COMMITTED isolation level است و عدم دقت به آن ممکن است این تصور را ایجاد کند که با تعریف تراکنشها، تمام مشکلات همزمانی برطرف میشوند.
راهحلهای پیشنهادی جهت حل مشکل همزمانی عملیات read/update
برای حل مشکلات مرتبط با race condition و همزمانی درخواستهای read/update، میتوان از یکی از روشهای زیر استفاده کرد:
الف) بجای اینکه یکبار کوئری read و یکبار کوئری update به صورت جداگانه صادر شوند، فقط یکبار کوئری update داشته باشیم.
ب) پیاده سازی Row level locking؛ در صورت پشتیبانی بانک اطلاعاتی مورد استفاده از آن
ج) استفاده از تراکنشهایی از نوع SERIALIZABLE
د) پیاده سازی optimistic locking
این موارد را در ادامه با توضیحات بیشتری بررسی میکنیم.
الف) پرهیز از خواندن و به روز رسانی جداگانه
بجای اینکه مانند اعمال فوق، یکبار select داشته باشیم و یکبار update، بهتر است فقط یک دستور update بکارگرفته شود:
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
اینبار با خلاصه شدن دو دستور select و update به یک دستور update، دیگر پس از دو خرید همزمان، 100 واحد گم شده مشاهده نمیشود (!) و موجودی نهایی صحیح است.
ب) پیاده سازی Row level locking
همیشه امکان تغییر عملیات مورد نیاز، به سادگی حالت الف نیست. در یک چنین حالتهایی جهت حداقل شدن تغییرات مورد نیاز، میتوان از row level locking استفاده کرد:
WAITFOR TIME '13:47:00'; SET NOCOUNT, XACT_ABORT ON; BEGIN TRAN; DECLARE @amount INT; SET @amount = ( SELECT balance FROM accounts WITH (UPDLOCK, HOLDLOCK) WHERE user_id = 1 ); SELECT @amount as 'initial user''s balance' UPDATE accounts SET balance = @amount - 100 WHERE user_id = 1; SELECT balance as 'user''s balance after shopping 1' FROM accounts WHERE user_id = 1; COMMIT TRAN;
در اینجا اضافه شدن WITH (UPDLOCK, HOLDLOCK) را به Select تعریف شده، مشاهده میکنید که به آنها locking hints هم گفته میشود و داخل BEGIN TRAN و COMMIT TRAN عمل میکنند (که نوع پیشفرض آن READ COMMITTED isolation level است). کار UPDLOCK، تبدیل shared lock پیشفرض، به update lock است و کار HOLDLOCK، نگه داشتن قفل صورت گرفته تا پایان کار تراکنش تعریف شدهاست.
با این تغییرات، هر تراکنش همزمان دیگری، تا زمانیکه قفل صورت گرفتهی بر روی ردیف select، رها نشود (یعنی تا زمانیکه تراکنش قفل کننده، به COMMIT TRAN برسد)، نمیتواند آنرا تغییر دهد. به همین جهت است که در تصویر فوق، هرچند هر دو عملیات همزمان اجرا شدهاند، اما یکی موجودی ابتدایی 300 را میبیند و دیگری پس از صبر کردن تا پایان تراکنش و رها شدن قفل، موجودی تغییر یافتهی جدیدی را مشاهده کرده و از آن استفاده میکند. به این ترتیب دیگر 100 واحدی که در اولین تصویر این مطلب مشاهده کردید، گم نشدهاست.
ج) استفاده از تراکنشهایی از نوع SERIALIZABLE
بجای استفاده از روش row level locking یاد شده، روش دیگری را که میتوان استفاده کرد، تغییر نوع پیشفرض تراکنش مورد استفادهاست. برای مثال اگر از یک SERIALIZABLE transaction استفاده کنیم؛ یعنی SET TRANSACTION ISOLATION LEVEL SERIALIZABLE را در ابتدای کار ذکر کنیم و برای مثال دو تراکنش همزمان را اجرا کنیم، اگر در تراکنش اول اطلاعاتی خوانده شود، در هیچ تراکنش دیگری نمیتوان این اطلاعات خوانده شده را تا پایان کار تراکنش اول، تغییر داد:
د) پیاده سازی optimistic locking
پیاده سازی optimistic locking و یا Optimistic concurrency control عموما در سمت برنامه رخ میدهد و توسط ORMها زیاد مورد استفاده قرار میگیرد؛ مانند اضافه کردن ستون اضافی version و یا timestamp به جداول تعریف شده. در این حالت تمام updateها به همراه یک where اضافی هستند تا بررسی کنند که آیا version دریافتی در حین خواندن ردیف در حال به روز رسانی، تغییر کردهاست یا خیر؟ اگر تغییر کردهاست، تراکنش را با خطایی خاتمه خواهند داد. این روش برخلاف حالتهای ب و ج، حتی خارج از یک تراکنش نیز کار میکند و مشکلات قفل کردن طولانی مدت رکوردها توسط آنها را به همراه ندارد.
Things I Wished More Developers Knew About Databases
- You are lucky if 99.999% of the time network is not a problem.
- ACID has many meanings.
- Each database has different consistency and isolation capabilities.
- Optimistic locking is an option when you can’t hold a lock.
- There are anomalies other than dirty reads and data loss.
- My database and I don’t always agree on ordering.
- Application-level sharding can live outside the application.
- AUTOINCREMENT’ing can be harmful.
- Stale data can be useful and lock-free.
- Clock skews happen between any clock sources.
- Latency has many meanings.
- Evaluate performance requirements per transaction.
- Nested transactions can be harmful.
- Transactions shouldn’t maintain application state.
- Query planners can tell a lot about databases.
- Online migrations are complex but possible.
- Significant database growth introduces unpredictability.
نظرات مطالب
C# 12.0 - Primary Constructors
یک نکتهی تکمیلی: backing fields تولید شدهی در حالت سازندههای اولیه، readonly نیستند.
اگر به کدهای #Low-Level C مطلب فوق دقت کنید، به یک چنین تعاریفی میرسیم:
private string <FirstName>k__BackingField;
public class AbcController : Controller { private readonly IMyService _myService; public AbcController(IMyService myService) { _myService = myService; } }
public class MyController(IMyService _myService) : ControllerBase { [HttpGet] public IActionResult RandomNumber() { var number = _myService.RandomNumber(); _myService = null; var number2 = MyRandom(); return Ok(number + number2); } public int MyRandom() { return _myService.RandomNumber(); } }