برچسب: برنامه‌نویسی

مانگو دی‌بی دقیقا چیه؟ خداحافظی با جدول‌ها

خب، بریم سر اصل مطلب. مانگو دی‌بی یک دیتابیس از نوع NoSQL و سند-گرا (Document-Oriented) هست. این یعنی چی؟ یعنی به جای اینکه داده‌ها رو توی سطر و ستون ذخیره کنه، اون‌ها رو توی ساختارهایی شبیه به اسناد JSON ذخیره می‌کنه. اگه با برنامه‌نویسی جاوا اسکریپت آشنا باشید، حتما با JSON کار کردید. JSON یه فرمت متنی ساده برای نمایش داده‌ها به صورت زوج‌های «کلید-مقدار» هست. مثلا اطلاعات یه کاربر میتونه این شکلی باشه:

{
  "نام": "سارا",
  "نام_خانوادگی": "رضایی",
  "سن": 25,
  "علاقمندی‌ها": ["کتاب", "موسیقی", "سفر"]
}

مانگو دی‌بی داده‌ها رو در قالبی به اسم BSON ذخیره می‌کنه که مخفف Binary JSON هست. BSON در واقع نسخه باینری یا دودویی JSON هست که کارایی بالاتری داره و از انواع داده‌ای بیشتری مثل تاریخ و داده‌های باینری هم پشتیبانی می‌کنه.

مزیت اصلی این مدل سند-گرا، انعطاف‌پذیری فوق‌العاده اونه. هر سند میتونه ساختار منحصر به فرد خودش رو داشته باشه. مثلا توی همون دیتابیس کاربرها، یه کاربر میتونه فیلد «ایمیل» داشته باشه و یکی دیگه نداشته باشه. یا یه کاربر فیلد «آدرس» داشته باشه که خودش شامل چند فیلد دیگه مثل شهر و خیابون هست. این ویژگی باعث میشه مدل داده‌ای دیتابیس شما خیلی به مدل داده‌ای اپلیکیشن شما نزدیک باشه و کار کردن باهاش برای توسعه‌دهنده‌ها خیلی راحت‌تر و سریع‌تر بشه. دیگه لازم نیست برای هر تغییر کوچیکی، کل ساختار دیتابیس رو عوض کنید.

معماری و اجزای اصلی مانگو دی‌بی

برای اینکه بهتر با کارکرد مانگو دی‌بی آشنا بشیم، بیایید اجزای اصلیش رو بشناسیم و با معادلشون توی دنیای دیتابیس‌های رابطه‌ای (RDBMS) مقایسه کنیم. این مقایسه کمک می‌کنه تصویر واضح‌تری تو ذهنتون شکل بگیره.

جزء در مانگو دی‌بی	معادل در RDBMS	توضیحات
دیتابیس (Database)	دیتابیس (Database)	بالاترین سطح ساختار که مجموعه‌ای از کالکشن‌ها رو در خودش نگه میداره.
کالکشن (Collection)	جدول (Table)	گروهی از اسناد مرتبط. مثلا کالکشن «کاربران» یا کالکشن «محصولات».
سند (Document)	سطر (Row)	واحد اصلی ذخیره‌سازی داده که یک شی BSON با زوج‌های کلید-مقدار هست.
فیلد (Field)	ستون (Column)	یک ویژگی یا صفت خاص درون یک سند که داده‌ها رو نگه میداره.

همونطور که می‌بینید، مفاهیم خیلی شبیه به هم هستن، اما فلسفه پشتشون کاملا متفاوته. توی مانگو دی‌بی، یک کالکشن میتونه اسنادی با ساختارهای کاملا متفاوت رو در خودش جا بده. این یعنی شما یک «شمای پویا» یا Schema-less دارید. لازم نیست از قبل تعریف کنید که هر سند چه فیلدهایی باید داشته باشه.

برای مثال، فرض کنید یک دیتابیس به اسم «GeeksforGeeks» داریم. داخل این دیتابیس دو تا کالکشن داریم و داخل هر کالکشن هم دو تا سند. داده‌های ما داخل این سندها و در قالب فیلدها ذخیره میشن.

ویژگی‌های کلیدی که مانگو دی‌بی رو خاص می‌کنن

حالا که با کلیات مانگو دی‌بی آشنا شدیم، بیایید ببینیم چه ویژگی‌هایی باعث شده این دیتابیس اینقدر محبوب بشه.

۱. انعطاف‌پذیری و مدل سند-گرا

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

۲. مقیاس‌پذیری افقی (Horizontal Scaling) با شاردینگ (Sharding)

یکی از بزرگترین چالش‌ها در دنیای داده‌های بزرگ (Big Data) اینه که وقتی حجم داده‌ها خیلی زیاد میشه، چطور سیستم رو مدیریت کنیم. دو راه کلی وجود داره: مقیاس‌پذیری عمودی (Vertical Scaling) و مقیای‌پذیری افقی (Horizontal Scaling).

• مقیاس‌پذیری عمودی: یعنی همون سرور فعلی رو قوی‌تر کنیم. مثلا رم و سی‌پی‌یو بیشتری بهش اضافه کنیم. این کار مثل اینه که ماشینتون رو با یه مدل قوی‌تر عوض کنید. اما این روش محدودیت داره و خیلی گرونه.
• مقیاس‌پذیری افقی: یعنی به جای قوی‌تر کردن یک سرور، تعداد سرورها رو زیاد کنیم و داده‌ها رو بین اونها تقسیم کنیم. این روش خیلی به‌صرفه‌تر و انعطاف‌پذیرتره.

مانگو دی‌بی از پایه برای مقیاس‌پذیری افقی طراحی شده. این کار رو با استفاده از تکنیکی به اسم شاردینگ (Sharding) انجام میده. در شاردینگ، داده‌های یک کالکشن بزرگ بر اساس یک کلید مشخص (shard key) به تکه‌های کوچکتری به اسم «چانک» (chunk) تقسیم میشن و هر تکه روی یک سرور مجزا (که بهش میگن shard) ذخیره میشه. این کار باعث میشه فشار کاری بین چندین ماشین پخش بشه و سیستم بتونه حجم عظیمی از داده و درخواست رو مدیریت کنه. این ویژگی، مانگو دی‌بی رو برای اپلیکیشن‌های بزرگ و با رشد سریع، ایده‌ال می‌کنه.

۳. دسترسی بالا (High Availability) با تکثیر (Replication)

هیچ‌کس دوست نداره سیستمش از کار بیفته. مانگو دی‌بی برای اطمینان از اینکه دیتابیس شما همیشه در دسترسه، از مکانیزمی به اسم تکثیر یا Replication استفاده می‌کنه. این کار از طریق چیزی به اسم مجموعه تکثیر (Replica Set) انجام میشه.

یک Replica Set شامل چند کپی از داده‌های شما روی سرورهای مختلفه. این مجموعه یک سرور اصلی (Primary) و چند سرور ثانویه (Secondary) داره. تمام عملیات نوشتن (write) به صورت پیش‌فرض روی سرور اصلی انجام میشه. سرورهای ثانویه به طور مداوم داده‌ها رو از سرور اصلی کپی می‌کنن و یک نسخه به‌روز از داده‌ها رو نگه می‌دارن.

حالا اگه سرور اصلی به هر دلیلی از کار بیفته (مثلا به خاطر مشکل سخت‌افزاری)، مجموعه تکثیر به طور خودکار یک «انتخابات» برگزار می‌کنه و یکی از سرورهای ثانویه رو به عنوان سرور اصلی جدید انتخاب می‌کنه. این فرآیند که بهش Failover میگن، باعث میشه سیستم شما با کمترین وقفه به کارش ادامه بده. جالبه بدونید که برای جلوگیری از دوپاره شدن مغز (split-brain) در انتخابات، اگه فقط یک سرور ثانویه داشته باشید، باید یک عضو سوم به اسم داور (Arbiter) هم به مجموعه اضافه بشه که فقط در انتخابات رای میده و داده‌ای ذخیره نمی‌کنه.

۴. کوئری‌های قدرتمند و ایندکس‌گذاری

مانگو دی‌بی فقط برای ذخیره داده نیست، بلکه ابزارهای خیلی قدرتمندی برای دسترسی و تحلیل داده‌ها هم فراهم می‌کنه. شما می‌تونید کوئری‌های موردی (Ad hoc queries) بزنید، یعنی بدون نیاز به تعریف قبلی، هر نوع جستجویی رو روی داده‌ها انجام بدید. این کوئری‌ها می‌تونن بر اساس فیلدهای خاص، محدوده‌های مشخص (range query) و حتی عبارت‌های باقاعده (regular-expression) باشن.

برای اینکه این کوئری‌ها سریع اجرا بشن، مانگو دی‌بی از ایندکس‌گذاری (Indexing) پشتیبانی می‌کنه. درست مثل فهرست آخر یک کتاب که به شما کمک می‌کنه سریع‌تر به یک مطلب برسید، ایندکس‌ها هم به دیتابیس کمک می‌کنن تا اسناد مورد نظر شما رو بدون جستجوی کامل در کل کالکشن پیدا کنه. شما می‌تونید روی هر فیلدی در سند، ایندکس اولیه (primary) یا ثانویه (secondary) بسازید.

۵. تجمیع داده‌ها (Aggregation)

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

• پایپ‌لاین تجمیع (Aggregation Pipeline): این روش اصلی و پرکاربردترین روشه. مثل یک خط مونتاژ کار می‌کنه که داده‌ها از مراحل مختلفی عبور می‌کنن و در هر مرحله یک عملیات خاص روشون انجام میشه (مثلا گروه‌بندی، فیلتر کردن، محاسبه).
• تابع Map-Reduce: این یک روش قدیمی‌تر برای پردازش دسته‌ای داده‌هاست، اما پایپ‌لاین تجمیع معمولا کارایی بهتری داره.
• متدهای تجمیع تک‌منظوره: برای کارهای ساده‌تر مثل شمارش یا پیدا کردن مقادیر متمایز.

۶. ذخیره‌سازی فایل با GridFS

مانگو دی‌بی یک محدودیت داره: هر سند نمی‌تونه بزرگتر از ۱۶ مگابایت باشه. پس اگه بخوایم فایل‌های بزرگ مثل ویدیو یا عکس‌های باکیفیت رو ذخیره کنیم چی؟ برای این کار، مانگو دی‌بی یک راه‌حل داخلی به اسم GridFS داره. GridFS فایل‌های بزرگ رو به تکه‌های کوچکتر (chunks) تقسیم می‌کنه و هر تکه رو به عنوان یک سند مجزا در کالکشن‌های مخصوص ذخیره می‌کنه. اینطوری شما می‌تونید از تمام ویژگی‌های مانگو دی‌بی مثل تکثیر و شاردینگ برای فایل‌های بزرگ هم استفاده کنید.

ابزارهای اصلی برای کار با مانگو دی‌بی

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

• mongod: این کلمه مخفف MongoDB Daemon هست و در واقع سرور اصلی دیتابیس شماست. مثل موتور ماشین می‌مونه. تا وقتی این سرور رو اجرا نکنید، هیچ دیتابیسی وجود نداره که بهش وصل بشید. این سرور به صورت پیش‌فرض روی پورت 27017 منتظر اتصال کلاینت‌ها می‌مونه.
• mongo و mongosh: اینها شل (Shell) یا کلاینت شما هستن. یعنی ابزاری که باهاش به سرور (mongod) وصل میشید و دستوراتتون رو اجرا می‌کنید؛ مثل کوئری زدن، اضافه کردن داده یا کارهای مدیریتی. mongo نسخه قدیمی‌تر این شل بود که از نسخه ۵.۰ به بعد مانگو دی‌بی، منسوخ شده. نسخه جدید و بهبودیافته اون mongosh نام داره که ویژگی‌هایی مثل هایلایت کردن دستورات، تاریخچه دستورات و لاگین بهتر رو ارائه میده. پس اگه می‌خواید با دیتابیس تعامل داشته باشید، باید از mongosh استفاده کنید.
• mongos: این یکی کمی پیشرفته‌تره و وقتی کاربرد داره که شما از شاردینگ استفاده می‌کنید. mongos مخفف MongoDB Shard هست و مثل یک پراکسی یا روتر عمل می‌کنه. وقتی شما داده‌هاتون رو روی چندین سرور (shard) پخش کردید، کلاینت شما (مثلا mongosh) نمی‌دونه که داده مورد نظرش روی کدوم سرور قرار داره. mongos اینجا وارد عمل میشه. کلاینت شما به mongos وصل میشه و mongos وظیفه داره کوئری‌ها و درخواست‌های نوشتن رو به شارد یا شاردهای درست هدایت کنه.

پس به طور خلاصه: شما mongod رو اجرا می‌کنید تا سرور دیتابیس راه بیفته. بعد با mongosh بهش وصل میشید تا با داده‌هاتون کار کنید. و اگه دیتابیس شما خیلی بزرگ و شارد شده باشه، mongos هم به عنوان یک واسط بین شما و شاردها عمل می‌کنه.

مانگو دی‌بی اطلس (MongoDB Atlas): دیتابیس در ابرها

راه انداختن و مدیریت یک دیتابیس، مخصوصا اگه بزرگ و توزیع‌شده باشه، کار ساده‌ای نیست. باید نگران نصب، پیکربندی، پشتیبان‌گیری، امنیت و خیلی چیزهای دیگه باشید. شرکت مانگو دی‌بی برای حل این مشکل، یک سرویس ابری به اسم MongoDB Atlas رو ارائه کرده.

اطلس یک سرویس «دیتابیس به عنوان سرویس» (DBaaS) کاملا مدیریت شده است. یعنی شما دیگه لازم نیست خودتون سرور راه بندازید یا نگران نگهداری اون باشید. فقط با چند کلیک یک کلاستر (مجموعه‌ای از سرورها) مانگو دی‌بی روی پلتفرم‌های ابری معروفی مثل Amazon Web Services (AWS)، Google Cloud Platform و Microsoft Azure ایجاد می‌کنید و شرکت مانگو دی‌بی تمام کارهای مدیریتی رو براتون انجام میده. این سرویس امکاناتی مثل پشتیبان‌گیری خودکار، مانیتورینگ، امنیت پیشرفته و مقیاس‌پذیری راحت رو فراهم می‌کنه و به شما اجازه میده روی توسعه اپلیکیشن خودتون تمرکز کنید. جالبه بدونید که تا سال ۲۰۲۴، ۷۰ درصد درآمد شرکت مانگو دی‌بی از همین سرویس اطلس بوده.

موارد استفاده مانگو دی‌بی: کجا به کار میاد؟

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

• سیستم‌های مدیریت محتوا (CMS): به خاطر انعطاف‌پذیری بالا، مانگو دی‌بی برای ذخیره انواع محتوا مثل مقالات، وبلاگ‌ها و سایت‌های خبری که ساختارهای متنوعی دارن، عالیه.
• اپلیکیشن‌های موبایل: مانگو دی‌بی به راحتی میتونه داده‌های سمت بک‌اند اپلیکیشن‌های iOS و اندروید رو ذخیره کنه و به توسعه‌دهنده‌ها اجازه میده اپلیکیشن‌هاشون رو به صورت یکپارچه مقیاس‌پذیر کنن.
• تجارت الکترونیک (E-commerce): فروشگاه‌های آنلاین میتونن از مانگو دی‌بی برای مدیریت کاتالوگ محصولات، پروفایل کاربران، سبدهای خرید و تاریخچه تراکنش‌ها استفاده کنن.
• اینترنت اشیا (IoT): دستگاه‌های IoT حجم عظیمی از داده‌های سنسورها رو تولید می‌کنن. مقیاس‌پذیری و انعطاف‌پذیری مانگو دی‌بی اون رو برای ذخیره و پردازش این داده‌ها ایده‌ال می‌کنه.
• بازی‌های آنلاین: ذخیره پروفایل بازیکنان، امتیازات، دستاوردها و وضعیت بازی که ساختارهای پیچیده‌ای دارن، با مدل سند-گرای مانگو دی‌بی خیلی راحت‌تره.
• تحلیل داده‌های آنی (Real-Time Analytics): توانایی مانگو دی‌بی در پردازش سریع داده‌ها، اون رو برای سیستم‌های مانیتورینگ، تشخیص تقلب و ارائه پیشنهادهای شخصی‌سازی شده مناسب می‌کنه.
• شبکه‌های اجتماعی: مدیریت روابط پیچیده بین کاربران، محتوای تولید شده توسط کاربر و تعاملات زنده، با مانگو دی‌بی به خوبی امکان‌پذیره.
• کاربردهای داده‌های بزرگ (Big Data): مانگو دی‌بی به خوبی با ابزارهای اکوسیستم داده‌های بزرگ مثل Apache Hadoop و Spark ادغام میشه و برای کارهایی مثل مدل‌سازی ریسک و تحلیل‌های پیش‌بینی‌کننده استفاده میشه.

مقایسه مانگو دی‌بی با رقبای سنتی: MySQL

برای اینکه جایگاه مانگو دی‌بی رو بهتر درک کنیم، خوبه که اون رو با MySQL به عنوان نماینده دیتابیس‌های رابطه‌ای مقایسه کنیم.

ویژگی	مانگو دی‌بی (MongoDB)	مای‌اس‌کیو‌ال (MySQL)
مدل داده	سند-گرا (Document-Oriented)، بدون شما (Schema-less)	رابطه‌ای (Relational)، با شمای از پیش تعریف شده
زبان کوئری	MQL (زبانی شبیه JSON)	SQL (زبان کوئری ساختاریافته)
مقیاس‌پذیری	افقی (Horizontal) با شاردینگ داخلی	عمدتا عمودی (Vertical)، مقیاس‌پذیری افقی پیچیده‌تره
موارد استفاده	داده‌های بزرگ، اپلیکیشن‌های مدرن، داده‌های نیمه‌ساختاریافته	سیستم‌های تراکنشی، داده‌های با ساختار مشخص، جاهایی که یکپارچگی داده حیاتیه
انعطاف‌پذیری	بسیار بالا، تغییر ساختار داده آسان است	کم، تغییر شما نیازمند فرآیندهای پیچیده است

چه زمانی MySQL بهتره؟ وقتی یکپارچگی داده‌ها و ایزوله‌سازی (isolation) حرف اول رو میزنه، مثل سیستم‌های مدیریت تراکنش‌های مالی، MySQL به خاطر ساختار سفت و سختش انتخاب بهتریه.

چه زمانی مانگو دی‌بی بهتره؟ وقتی سرعت، دسترسی بالا و توانایی کار با داده‌های متنوع و در حال تغییر اولویت داره، انعطاف‌پذیری و عملکرد بالای مانگو دی‌بی اون رو به گزینه بهتری تبدیل می‌کنه.

تاریخچه و لایسنس: یک مسیر پر فراز و نشیب

مانگو دی‌بی توسط شرکتی به اسم 10gen در سال ۲۰۰۷ شروع به توسعه پیدا کرد. این شرکت که بعدها در سال ۲۰۱۳ اسم خودش رو به MongoDB Inc. تغییر داد، در ابتدا قصد داشت یک محصول پلتفرم به عنوان سرویس (PaaS) بسازه که مانگو دی‌بی یکی از اجزای اون بود. اما در سال ۲۰۰۹، اونها مدل توسعه رو به سمت متن‌باز تغییر دادن. مانگو دی‌بی در تاریخ ۲۰ اکتبر ۲۰۱۷ با نماد MDB در بورس NASDAQ عرضه عمومی شد.

یکی از بحث‌برانگیزترین اتفاقات در تاریخ مانگو دی‌بی، تغییر لایسنس اون بود. نسخه‌هایی که قبل از ۱۶ اکتبر ۲۰۱۸ منتشر شدن، تحت لایسنس AGPL بودن که یک لایسنس متن‌باز شناخته شده است. اما بعد از این تاریخ، شرکت مانگو دی‌بی لایسنس نرم‌افزار سرور خودش رو به Server Side Public License (SSPL) تغییر داد.

این لایسنس جدید که توسط خود مانگو دی‌بی نوشته شده، شبیه به لایسنس‌های متن‌باز هست اما یک شرط مهم داره: اگه شما نرم‌افزار مانگو دی‌بی رو به عنوان یک «سرویس» عمومی ارائه بدید، باید کل سورس کد سرویس خودتون رو هم تحت همین لایسنس SSPL منتشر کنید. این تغییر برای جلوگیری از این بود که شرکت‌های بزرگ ارائه‌دهنده خدمات ابری، از مانگو دی‌بی به صورت تجاری استفاده کنن بدون اینکه به جامعه اون کمک کنن.

این تغییر باعث شد که بنیاد نرم‌افزار متن‌باز (OSI) اعلام کنه که SSPL یک لایسنس متن‌باز نیست. در نتیجه، توزیع‌های لینوکسی معروفی مثل Debian، Fedora و Red Hat Enterprise Linux، مانگو دی‌بی رو از مخازن رسمی خودشون حذف کردن.

انتقادات و چالش‌ها: نگاهی بی‌طرفانه

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

• امنیت: در نسخه‌های قدیمی‌تر، تنظیمات پیش‌فرض امنیتی مانگو دی‌بی ضعیف بود و به هر کسی اجازه دسترسی کامل به دیتابیس رو می‌داد. این موضوع باعث شد که هکرها به ده‌ها هزار دیتابیس حمله کنن، اطلاعات رو سرقت کنن یا برای پس دادن اونها باج بخوان. البته از نسخه ۲.۶ به بعد، این مشکل حل شد و به صورت پیش‌فرض، دیتابیس فقط به اتصالات از خود ماشین (localhost) اجازه دسترسی میده.
• عدم وجود JOINهای پیچیده: در دیتابیس‌های رابطه‌ای، شما می‌تونید با دستور JOIN داده‌ها رو از جدول‌های مختلف به هم وصل کنید. مانگو دی‌بی به صورت ذاتی از JOIN به اون شکل پشتیبانی نمی‌کنه. به جای اون، شما باید از طریق جاسازی اسناد (embedding) یا ارجاع (referencing) روابط رو مدیریت کنید. این موضوع گاهی برای کسانی که از دنیای SQL میان، چالش‌برانگیزه و باعث میشه در اپلیکیشن‌های خیلی پیچیده که روابط زیادی دارن، برخی به سمت SQL برگردن.
• مصرف بالای حافظه: مانگو دی‌بی برای افزایش کارایی، از حافظه رم به مقدار زیادی استفاده می‌کنه که میتونه هزینه‌های سخت‌افزاری رو بالا ببره.
• انتقادات فنی و یکپارچگی داده: در گذشته، گزارش‌هایی مثل گزارش معروف Jepsen (یک شرکت تحقیقاتی در زمینه ایمنی سیستم‌های توزیع‌شده) مشکلاتی رو در مورد یکپارچگی داده‌ها در سناریوهای خاصی از خرابی شبکه در مانگو دی‌بی پیدا کرده بود. این گزارش‌ها نشون می‌داد که در شرایط خاص، ممکنه دیتابیس داده‌های قدیمی (stale reads) برگردونه یا حتی داده‌هایی که تایید شدن رو به عقب برگردونه (rollback). شرکت مانگو دی‌بی در نسخه‌های بعدی (مثل نسخه ۳.۴ و بالاتر) بسیاری از این مشکلات رو برطرف کرد و ادعا کرد که تست‌های Jepsen رو با موفقیت پشت سر گذاشته. اما گزارش‌های جدیدتر Jepsen در مورد نسخه‌های جدیدتر مثل ۴.۲.۶، همچنان به برخی مشکلات و پیچیدگی‌ها در تضمین کامل یکپارچگی داده‌ها در تراکنش‌ها اشاره داشت. البته این مشکلات هم در پچ‌های بعدی مورد توجه قرار گرفتن و در نسخه ۵.۰، پیش‌فرض‌های مربوط به تایید نوشتن داده (write concern) برای افزایش ایمنی، تقویت شدن.

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

پرسش و پاسخ‌های متداول (FAQ)

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

• سوال ۱: پس مانگو دی‌بی فقط برای داده‌های «بدون ساختار» خوبه؟

  نه لزوما. اصطلاح بهتر «داده‌های نیمه‌ساختاریافته» یا داده‌هایی هست که ساختار ثابتی ندارن. مانگو دی‌بی برای هر اپلیکیشنی که داده‌هاش به راحتی در قالب جدول‌های سفت و سخت جا نمیگیرن یا ساختارشون در طول زمان زیاد تغییر می‌کنه، عالیه. حتی برای داده‌های ساختاریافته هم میشه ازش استفاده کرد، اما انعطاف‌پذیریش در کار با داده‌های متنوع نقطه قوت اصلیشه.

• سوال ۲: فرق بین mongo و mongosh دقیقا چی بود؟

  هر دو ابزارهایی برای اتصال به سرور مانگو دی‌بی و اجرای دستورات هستن. mongo نسخه قدیمی‌تره که دیگه توسعه داده نمیشه. mongosh نسخه جدید، مدرن و پیشنهادی هست که امکانات بهتری مثل رنگی بودن دستورات و تاریخچه بهتر رو ارائه میده. همیشه سعی کنید از mongosh استفاده کنید.

• سوال ۳: این «کرسر» (Cursor) که گاهی در موردش صحبت میشه چیه؟

  وقتی شما یک کوئری find در مانگو دی‌بی اجرا می‌کنید، دیتابیس تمام نتایج رو یک‌جا برای شما ارسال نمی‌کنه، چون ممکنه نتایج خیلی زیاد باشن و حافظه زیادی مصرف کنن. به جای اون، یک کرسر (Cursor) برمی‌گردونه. کرسر مثل یک «اشاره‌گر» به مجموعه‌ی نتایج روی سرور عمل می‌کنه. شما با استفاده از این کرسر می‌تونید نتایج رو یکی یکی یا به صورت دسته‌ای (batch) از سرور بگیرید. متدهایی مثل hasNext() (که چک می‌کنه آیا نتیجه دیگه‌ای وجود داره) و next() (که نتیجه بعدی رو برمی‌گردونه) روی همین کرسر کار می‌کنن.

• سوال ۴: اگه اینقدر انعطاف‌پذیر و خوبه، چه زمانی نباید از مانگو دی‌بی استفاده کنم؟

  مانگو دی‌بی برای همه کارها بهترین راه‌حل نیست. اگه اپلیکیشن شما داده‌های بسیار رابطه‌ای داره و نیاز به JOINهای پیچیده بین چندین جدول دارید (مثلا یک سیستم بانکی پیچیده)، و یکپارچگی و ثبات داده‌ها (ACID properties) در سطح تراکنش‌های چند جدولی برای شما حیاتی‌تر از هر چیز دیگه‌ای هست، احتمالا یک دیتابیس رابطه‌ای مثل MySQL یا PostgreSQL انتخاب بهتری باشه.

• سوال ۵: جریان این لایسنس SSPL چیه؟ یعنی مانگو دی‌بی دیگه متن‌باز نیست؟

  از نظر فنی، سورس کد مانگو دی‌بی همچنان در دسترسه (source-available)، اما لایسنس SSPL توسط بنیاد متن‌باز به عنوان یک لایسنس «متن‌باز» واقعی تایید نشده. دلیلش هم محدودیتی هست که برای ارائه‌دهندگان خدمات ابری ایجاد می‌کنه. برای یک توسعه‌دهنده معمولی که از مانگو دی‌بی در اپلیکیشن خودش استفاده می‌کنه، این موضوع معمولا تفاوت خاصی ایجاد نمی‌کنه. اما اگه قصد دارید خود مانگو دی‌بی رو به عنوان یک سرویس تجاری به دیگران بفروشید، باید شرایط این لایسنس رو به دقت بررسی کنید. نسخه Community مانگو دی‌بی همچنان برای استفاده رایگانه.

حالا بیایم سر تعریف اصلی. هوش مصنوعی (Artificial Intelligence یا AI) یعنی توانایی یه ماشین برای انجام دادن کارهای شناختی که ما معمولا به ذهن انسان نسبتش میدیم. کارهایی مثل درک کردن، استدلال کردن، یاد گرفتن، تعامل با محیط، حل مسئله و حتی خلاقیت. شاید خودتونم ندونین ولی احتمالا تا حالا کلی با AI سر و کار داشتین؛ دستیارهای صوتی مثل سیری و الکسا یا اون ربات‌های چت که تو بعضی سایت‌ها بهتون کمک میکنن، همشون بر پایه تکنولوژی AI کار میکنن.

این ماشین‌های هوشمند روز به روز دارن سریع‌تر و پیچیده‌تر میشن. مثلا بعضی کامپیوترها به مرحله‌ای به اسم «اگزااسکیل» رسیدن. یعنی میتونن توی یک ثانیه، به اندازه‌ای محاسبه انجام بدن که یه نفر آدم باید ۳۱ میلیارد و ۶۸۸ میلیون و ۷۶۵ هزار سال وقت بذاره تا انجامش بده. دیگه فقط بحث محاسبه نیست، کامپیوترها دارن مهارت‌ها و قدرت درکی پیدا میکنن که یه زمانی فقط مخصوص ما انسان‌ها و چندتا گونه دیگه بود.

اما ارزش واقعی AI به خود سیستم‌هاش نیست، بلکه به اینه که شرکت‌ها چطور از این سیستم‌ها برای کمک به انسان‌ها استفاده میکنن و چقدر میتونن عملکردشون رو شفاف توضیح بدن تا اعتماد بقیه رو جلب کنن.

از کجا شروع کنیم؟ بیایم با یادگیری ماشین آشنا بشیم

خب، وقتی میگیم AI، در واقع داریم در مورد یه خانواده بزرگ از تکنولوژی‌ها حرف میزنیم. یکی از مهم‌ترین اعضای این خانواده یادگیری ماشین (Machine Learning یا ML) هست.

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

این روزها حجم داده‌هایی که تولید میشه اونقدر زیاد و پیچیده است که ما انسان‌ها از پس پردازشش برنمیایم. همین موضوع، هم پتانسیل یادگیری ماشین رو بیشتر کرده و هم نیازمون بهش رو. از دهه ۱۹۷۰ که استفاده از یادگیری ماشین گسترده شد، تاثیرات بزرگی تو صنایع مختلف داشته، مثلا تو تحلیل تصاویر پزشکی یا پیش‌بینی خیلی دقیق وضعیت آب و هوا.

به طور کلی، سه مدل اصلی برای یادگیری ماشین وجود داره:

• یادگیری نظارت شده (Supervised learning): تو این مدل، الگوریتم رو با داده‌های برچسب‌دار آموزش میدیم. یعنی چی؟ یعنی مثلا بهش کلی عکس گربه نشون میدیم و بهش میگیم «اینا گربه هستن». هدف اینه که مدل یاد بگیره بین ورودی (عکس) و خروجی (برچسب گربه) یه نقشه پیدا کنه تا بعدا بتونه عکس‌های جدیدی که تا حالا ندیده رو هم درست تشخیص بده.
• یادگیری نظارت نشده (Unsupervised learning): اینجا دیگه از داده‌های برچسب‌دار خبری نیست. الگوریتم باید خودش الگوها رو تو داده‌های بدون ساختار پیدا کنه. نتیجه نهایی از قبل مشخص نیست. الگوریتم خودش داده‌ها رو بر اساس ویژگی‌هاشون دسته‌بندی میکنه. این مدل برای پیدا کردن الگوها و مدل‌سازی توصیفی خیلی خوبه.
• یادگیری تقویتی (Reinforcement learning): این مدل رو میشه به «یادگیری با آزمون و خطا» توصیف کرد. یه «عامل» (Agent) یاد میگیره که یه کار مشخص رو با سعی و خطا انجام بده. اینقدر این کار رو تکرار میکنه تا عملکردش به یه سطح قابل قبول برسه. وقتی کار رو خوب انجام میده تشویق (تقویت مثبت) میشه و وقتی بد انجام میده تنبیه (تقویت منفی). مثلا آموزش دادن به یه دست رباتیک برای برداشتن یه توپ، یه نمونه از این نوع یادگیریه.

یه روش ترکیبی هم به اسم یادگیری نیمه نظارت شده (Semi-supervised learning) وجود داره که توش فقط بخشی از داده‌ها برچسب دارن.

یک پله عمیق‌تر: یادگیری عمیق و شبکه‌های عصبی

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

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

ایده اصلی یادگیری عمیق استفاده از شبکه‌های عصبی (Neural Networks) هست. این شبکه‌ها از نحوه تعامل نورون‌ها تو مغز انسان الهام گرفته شدن. یه شبکه عصبی از لایه‌های به هم پیوسته از گره‌ها (که شبیه نورون هستن) تشکیل شده. داده‌ها وارد این شبکه میشن و از چندین لایه عبور میکنن. هر لایه ویژگی‌های پیچیده‌تری از داده رو تشخیص میده. مثلا لایه اول ممکنه یه چیزی رو به عنوان یه شکل خاص تشخیص بده و لایه بعدی، بر اساس این اطلاعات، بفهمه که اون شکل یه تابلوی ایست هست. یادگیری عمیق هم مثل یادگیری ماشین، از تکرار برای اصلاح خودش و بهتر کردن قدرت پیش‌بینی‌اش استفاده میکنه.

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

چند نوع شبکه عصبی معروف هم داریم که خوبه اسمشون رو بدونین:

• شبکه‌های عصبی پیشخور (Feedforward Neural Networks – FF): یکی از قدیمی‌ترین مدل‌ها که داده‌ها فقط در یک جهت، از لایه‌ها عبور میکنن تا به خروجی برسن.
• شبکه‌های عصبی بازگشتی (Recurrent Neural Networks – RNN): این مدل‌ها بر خلاف مدل قبلی، از داده‌های سری زمانی یا دنباله‌ای استفاده میکنن و یه جورایی «حافظه» دارن از اتفاقی که تو لایه قبلی افتاده. برای همین تو تشخیص گفتار و ترجمه خیلی به کار میان.
• حافظه طولانی/کوتاه مدت (Long/Short Term Memory – LSTM): اینم یه مدل پیشرفته از RNN هست که میتونه چیزهایی که چندین لایه قبل اتفاق افتاده رو با استفاده از «سلول‌های حافظه» به خاطر بسپره.
• شبکه‌های عصبی کانولوشنی (Convolutional Neural Networks – CNN): این‌ها جزو معروف‌ترین شبکه‌های عصبی هستن و بیشتر تو تشخیص تصویر استفاده میشن. لایه‌های مختلفش بخش‌های متفاوتی از یه عکس (مثل رنگ‌ها و لبه‌ها) رو فیلتر میکنن تا در نهایت تصویر رو تشخیص بدن.
• شبکه‌های مولد تخاصمی (Generative Adversarial Networks – GAN): تو این سیستم، دو تا شبکه عصبی با هم رقابت میکنن. یکی (مولد) سعی میکنه مثال‌های جدید بسازه و اون یکی (تفکیک‌کننده) سعی میکنه تشخیص بده که این مثال‌ها واقعی هستن یا ساختگی. این رقابت در نهایت باعث بهتر شدن خروجی میشه. از این مدل برای ساختن عکس‌های واقعی و حتی آثار هنری استفاده شده.

جدیدترین پدیده: هوش مصنوعی مولد (Generative AI)

و اما میرسیم به بحث داغ این روزها: هوش مصنوعی مولد (Generative AI یا Gen AI).

هوش مصنوعی مولد به مدل‌های یادگیری عمیقی گفته میشه که میتونن در جواب به یه درخواست یا «پرامپت» (Prompt) از طرف کاربر، محتوای جدید و اورجینال مثل متن‌های طولانی، عکس‌های باکیفیت، ویدیوهای واقعی یا صدا تولید کنن. ابزارهایی مثل ChatGPT و DALL-E (که عکس تولید میکنه) نشون دادن که این تکنولوژی پتانسیل تغییر دادن خیلی از شغل‌ها رو داره.

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

فرایند کار هوش مصنوعی مولد معمولا سه مرحله داره:

• شروع با یک مدل پایه (Foundation Model): همه چیز با یه مدل پایه شروع میشه. این مدل یه مدل یادگیری عمیق خیلی بزرگه که روی حجم عظیمی از داده‌های خام و بدون برچسب (مثلا ترابایت‌ها متن و عکس از اینترنت) آموزش دیده. این آموزش خیلی سنگین، زمان‌بر و گرونه و به هزاران پردازنده گرافیکی (GPU) و میلیون‌ها دلار هزینه نیاز داره. این مدل‌ها که معروف‌ترینشون مدل‌های زبان بزرگ (Large Language Models یا LLM) هستن، میتونن به صورت خودکار به پرامپت‌ها جواب بدن.
• تنظیم دقیق (Fine-tuning): بعد از ساخت مدل پایه، باید اون رو برای یه کار مشخص (مثلا تولید یه نوع محتوای خاص) تنظیم کرد. این کار با روش‌های مختلفی مثل آموزش بیشتر با داده‌های مرتبط انجام میشه.
• ارزیابی و بهبود مداوم: توسعه‌دهنده‌ها و کاربرها به طور مرتب خروجی‌های این ابزارها رو ارزیابی میکنن و مدل رو حتی هفته‌ای یک بار برای دقت و مرتبط بودن بیشتر، دوباره تنظیم میکنن.

سفری به گذشته: تاریخچه هوش مصنوعی

برای اینکه بفهمیم الان کجا هستیم، باید بدونیم از کجا شروع کردیم. ایده «ماشینی که فکر میکنه» به یونان باستان برمیگرده، اما اگه بخوایم تاریخ مدرنش رو بررسی کنیم، باید از اینجا شروع کنیم:

• دهه ۱۹۴۰ و ۱۹۵۰:
  • ۱۹۴۳: وارن مک‌کالک و والتر پیتس یه مدل از نورون‌های مصنوعی رو پیشنهاد دادن که پایه و اساس شبکه‌های عصبی شد.
  • ۱۹۵۰: آلن تورینگ، که بهش «پدر علم کامپیوتر» هم میگن، یه مقاله به اسم «ماشین‌های محاسباتی و هوش» منتشر کرد و این سوال رو پرسید: «آیا ماشین‌ها میتونن فکر کنن؟». اون یه آزمایشی به اسم «بازی تقلید» رو هم معرفی کرد که امروز به «آزمون تورینگ» معروفه. این آزمون توانایی یه ماشین برای نشون دادن رفتار هوشمندانه رو میسنجه.
  • ۱۹۵۶: این سال یه نقطه عطف بود. جان مک‌کارتی، دانشمند کامپیوتر، برای اولین بار از عبارت «هوش مصنوعی» تو یه کارگاه تو کالج دارتموث استفاده کرد. همون سال، آلن نیوول، جی. سی. شاو و هربرت سایمون اولین برنامه کامپیوتری هوش مصنوعی به اسم «Logic Theorist» رو ساختن.
• چهار مرحله تکامل AI (به روایت رادنی بروکس، فیزیکدان MIT):
  • هوش مصنوعی نمادین (Symbolic AI – از ۱۹۵۶): به این روش، هوش مصنوعی کلاسیک یا حتی GOFAI (مخفف هوش مصنوعی خوب و قدیمی) هم میگن. ایده اصلی اینجا استفاده از نمادها و استدلال منطقی برای حل مسئله بود. مثلا: ژرمن شپرد یه سگه، سگ یه پستانداره، همه پستانداران خونگرم هستن؛ پس ژرمن شپرد باید خونگرم باشه. مشکل اصلی این روش این بود که انسان‌ها باید دانش خودشون از دنیا رو به صورت دستی وارد سیستم میکردن. برای همین این سیستم‌ها با پیچیدگی‌های دنیای واقعی مشکل داشتن و نمیتونستن از داده‌های زیاد یاد بگیرن. این روش تا اواخر دهه ۱۹۸۰ روش غالب بود.
  • شبکه‌های عصبی (با پیشرفت‌هایی در سال‌های ۱۹۵۴، ۱۹۶۹، ۱۹۸۶ و ۲۰۱۲): همونطور که گفتیم، این تکنولوژی پشت رشد انفجاری هوش مصنوعی مولد امروزیه. با اینکه ایده‌اش از دهه ۴۰ مطرح بود، فراز و نشیب‌های زیادی داشت. در سال ۱۹۶۹ دو تا محقق MIT نشون دادن که شبکه‌های عصبی فقط میتونن کارهای خیلی ساده انجام بدن. اما در سال ۱۹۸۶، جفری هینتون و همکارانش این مشکل رو حل کردن. در نهایت در سال ۲۰۱۲، هینتون و دو تا از دانشجوهاش قدرت یادگیری عمیق رو با استفاده از شبکه‌های عصبی با لایه‌های خیلی بیشتر نشون دادن و تمرکز دنیا رو به این سمت بردن.
  • رباتیک سنتی (Traditional Robotics – از ۱۹۶۸): تو دهه‌های اول هوش مصنوعی، محقق‌ها برای پیشبرد تحقیقاتشون ربات میساختن. این ربات‌ها معمولا تو محیط‌های خیلی کنترل شده کار میکردن و رفتارهای کاملا برنامه‌ریزی شده رو تکرار میکردن. با اینکه این ربات‌ها به پیشرفت خود AI کمک زیادی نکردن، اما تو یه زمینه به اسم «مکان‌یابی و نقشه‌برداری همزمان» (SLAM) خیلی تاثیرگذار بودن که به ساخت ماشین‌های خودران و حتی ربات‌های جاروبرقی امروزی کمک کرد.
  • رباتیک مبتنی بر رفتار (Behavior-based Robotics – از ۱۹۸۵): محقق‌ها دیدن که حشرات با تعداد کمی نورون، خیلی خوب تو دنیای واقعی مسیریابی میکنن. پس سعی کردن ربات‌هایی بسازن که بتونن با دانش ناقص و دستورالعمل‌های متناقض، مشکلات رو حل کنن. این ربات‌ها هم تو دلشون شبکه‌های عصبی دارن.
• دهه ۱۹۸۰ تا امروز:
  • دهه ۱۹۸۰: شبکه‌های عصبی که از الگوریتم «پس‌انتشار» (backpropagation) برای آموزش خودشون استفاده میکردن، به طور گسترده تو کاربردهای AI استفاده شدن. اما بعدش به خاطر محدودیت‌ها، یه دوره رکود دیگه به اسم «زمستان دوم AI» به وجود اومد.
  • ۱۹۹۷: کامپیوتر «دیپ بلو» شرکت IBM، گری کاسپاروف، قهرمان شطرنج جهان رو شکست داد. این یه اتفاق خیلی مهم بود.
  • ۲۰۱۶: برنامه «آلفاگو» شرکت دیپ‌مایند، که با یه شبکه عصبی عمیق کار میکرد، لی سدول، قهرمان جهان تو بازی «گو» رو شکست داد. این پیروزی خیلی مهم بود چون تعداد حرکات ممکن تو بازی گو فوق‌العاده زیاده.
  • ۲۰۲۲: ظهور مدل‌های زبان بزرگ یا LLMها، مثل ChatGPT، یه تغییر عظیم تو عملکرد هوش مصنوعی و پتانسیلش ایجاد کرد.

انواع هوش مصنوعی: از ضعیف تا فوق هوشمند

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

دسته‌بندی بر اساس قابلیت:

• هوش مصنوعی ضعیف یا محدود (Weak AI یا Narrow AI): این‌ها سیستم‌های هوش مصنوعی هستن که برای انجام یه کار مشخص یا مجموعه‌ای از کارهای محدود طراحی و آموزش دیدن. تقریبا تمام هوش مصنوعی که ما امروز میبینیم و استفاده میکنیم از این نوعه. دستیار صوتی الکسا، الگوریتم‌های تشخیص تقلب کارت اعتباری یا موتور جستجوی گوگل همشون نمونه‌هایی از هوش مصنوعی محدود هستن.
• هوش مصنوعی قوی یا عمومی (Strong AI یا Artificial General Intelligence – AGI): این نوع هوش مصنوعی، توانایی درک، یادگیری و به کار بردن دانش در طیف وسیعی از کارها رو در سطحی برابر یا حتی فراتر از هوش انسان داره. این سطح از AI در حال حاضر فقط در حد تئوری وجود داره و هنوز هیچ سیستمی بهش نرسیده. بعضی محقق‌ها معتقدن رسیدن به AGI به افزایش خیلی زیادی تو قدرت محاسباتی نیاز داره. رادنی بروکس، رباتیک‌دان MIT و یکی از بنیان‌گذاران iRobot، معتقده که AGI تا سال ۲۳۰۰ از راه نمیرسه.
• هوش مصنوعی فوق هوشمند (Artificial Superintelligence – ASI): این دیگه سطح بعدیه که توش ماشین میتونه تو همه زمینه‌ها از انسان برتر عمل کنه. این هم مثل AGI فعلا در قلمرو علمی-تخیلی قرار داره.

دسته‌بندی بر اساس عملکرد:

1. نوع ۱: ماشین‌های واکنشی (Reactive Machines): این سیستم‌ها حافظه ندارن و فقط برای یه کار خاص طراحی شدن. مثل کامپیوتر شطرنج‌باز دیپ بلو که کاسپاروف رو شکست داد. اون میتونست مهره‌ها رو تشخیص بده و حرکت بعدی رو پیش‌بینی کنه، ولی از تجربه‌های قبلی برای بازی‌های آینده‌اش استفاده نمیکرد.
2. نوع ۲: حافظه محدود (Limited Memory): این سیستم‌ها حافظه دارن و میتونن از تجربیات گذشته برای تصمیم‌گیری‌های آینده استفاده کنن. بعضی از عملکردهای تصمیم‌گیری تو ماشین‌های خودران اینجوری طراحی شدن.
3. نوع ۳: نظریه ذهن (Theory of Mind): این یه اصطلاح روانشناسیه. وقتی در مورد AI به کار میره، یعنی سیستمی که میتونه احساسات رو بفهمه، نیت انسان‌ها رو درک کنه و رفتارشون رو پیش‌بینی کنه. این نوع AI هنوز به طور کامل وجود نداره.
4. نوع ۴: خودآگاهی (Self-awareness): تو این دسته، سیستم‌های AI یه حسی از «خود» دارن که بهشون آگاهی میده. ماشین‌هایی که خودآگاهی دارن، وضعیت فعلی خودشون رو درک میکنن. این نوع AI هم هنوز وجود نداره.

AI در دنیای واقعی: کاربردها و مزایا

خب، این همه در مورد تئوری و تاریخ حرف زدیم. حالا بیایم ببینیم این هوش مصنوعی تو دنیای واقعی به چه دردی میخوره.

مزایای کلی هوش مصنوعی:

• اتوماسیون (Automation): هوش مصنوعی میتونه کارهای تکراری و خسته‌کننده رو خودکار کنه، چه کارهای دیجیتال مثل جمع‌آوری و وارد کردن داده، چه کارهای فیزیکی مثل جابجا کردن بسته‌ها تو انبار. این کار باعث میشه ما انسان‌ها وقتمون برای کارهای خلاقانه‌تر و باارزش‌تر آزاد بشه.
• کاهش خطای انسانی: AI میتونه خطاهای دستی تو پردازش داده، تحلیل یا مونتاژ رو از بین ببره چون الگوریتم‌ها هر بار یه فرایند رو به همون شکل دقیق تکرار میکنن.
• تصمیم‌گیری سریع و دقیق: هوش مصنوعی میتونه سریع‌تر و دقیق‌تر از انسان‌ها پیش‌بینی کنه و تصمیم‌های مبتنی بر داده بگیره.
• در دسترس بودن همیشگی: AI خسته نمیشه و به استراحت نیاز نداره. ربات‌های چت میتونن ۲۴ ساعته جواب مشتری‌ها رو بدن.
• افزایش ایمنی: با خودکار کردن کارهای خطرناک مثل کار با مواد منفجره یا کار در اعماق اقیانوس، دیگه نیازی نیست انسان‌ها رو در معرض خطر قرار بدیم.

کاربردها در صنایع مختلف:

• خدمات مشتری: شرکت‌ها از ربات‌های چت و دستیارهای مجازی برای جواب دادن به سوالات مشتری‌ها، پیگیری سفارش‌ها و حل مشکلات استفاده میکنن. این ابزارها با استفاده از پردازش زبان طبیعی (Natural Language Processing – NLP) زبان ما رو میفهمن و جواب میدن.
• کشف تقلب: الگوریتم‌های یادگیری ماشین میتونن الگوهای تراکنش‌ها رو تحلیل کنن و موارد مشکوک مثل خریدهای غیرعادی رو به سرعت تشخیص بدن.
• تجربه مشتری شخصی‌سازی شده: فروشگاه‌ها و بانک‌ها از AI برای پیشنهاد دادن محصولات و خدماتی که احتمالا دوست دارین، استفاده میکنن.
• استخدام و منابع انسانی: پلتفرم‌های استخدامی مبتنی بر AI میتونن رزومه‌ها رو بررسی کنن، کاندیداها رو با شرح شغل تطبیق بدن و حتی مصاحبه‌های اولیه رو انجام بدن.
• توسعه نرم‌افزار: ابزارهای تولید کد با هوش مصنوعی مولد میتونن کارهای کدنویسی تکراری رو ساده کنن و سرعت توسعه برنامه‌ها رو بالا ببرن.
• تعمیر و نگهداری پیش‌بینی‌کننده: مدل‌های یادگیری ماشین میتونن داده‌های سنسورها رو تحلیل کنن و پیش‌بینی کنن که یه دستگاه کی به تعمیر نیاز داره تا از کار افتادن ناگهانیش جلوگیری بشه.
• بهداشت و درمان: AI تو تحلیل تصاویر پزشکی برای تشخیص زودهنگام بیماری‌ها، طراحی برنامه‌های درمانی شخصی‌سازی شده و حتی کشف داروهای جدید به کار میره.
• حمل و نقل: ماشین‌های خودران یه مثال بارز هستن. علاوه بر این، AI برای مدیریت ترافیک، پیش‌بینی تاخیر پروازها و بهینه‌سازی مسیرهای کشتی‌رانی هم استفاده میشه.

بر اساس یه نظرسنجی در سال ۲۰۲۲، پذیرش مدل‌های هوش مصنوعی از سال ۲۰۱۷ بیش از دو برابر شده و سرمایه‌گذاری تو این حوزه هم به همین نسبت افزایش پیدا کرده. حوزه‌هایی که شرکت‌ها بیشترین ارزش رو از AI میبینن شامل بازاریابی و فروش، توسعه محصول و خدمات، و استراتژی و امور مالی شرکتی هست.

چالش‌ها، خطرات و بحث‌های اخلاقی

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

محدودیت‌ها و خطرات مدل‌های AI:

• خروجی‌های اشتباه: خروجی‌های مدل‌های هوش مصنوعی مولد ممکنه خیلی متقاعدکننده به نظر برسن، ولی گاهی اوقات اطلاعاتی که تولید میکنن کاملا اشتباهه.
• سوگیری (Bias): این مدل‌ها بر اساس داده‌هایی که باهاشون آموزش دیدن کار میکنن. اگه اون داده‌ها (که معمولا از اینترنت گرفته میشن) شامل سوگیری‌های جنسیتی، نژادی و … باشن، خروجی مدل هم این سوگیری‌ها رو منعکس و حتی تقویت میکنه. مثلا آمازون یه ابزار استخدام مبتنی بر AI ساخته بود که ناخواسته به نفع کاندیداهای مرد عمل میکرد چون داده‌های آموزشی‌اش این سوگیری رو داشتن.
• امکان سواستفاده: میشه از این مدل‌ها برای فعالیت‌های غیراخلاقی یا مجرمانه استفاده کرد. بعضی کاربرها سعی میکنن مدل‌ها رو «جیل‌بریک» (Jailbreak) کنن، یعنی کاری کنن که قوانین خودشون رو بشکنن و محتوای مضر یا غیرقانونی تولید کنن.
• هزینه‌های بالا: توسعه و آموزش مدل‌های AI، به خصوص مدل‌های بزرگ، خیلی گرونه. مثلا مدیرعامل OpenAI گفته که آموزش مدل GPT-4 بیشتر از ۱۰۰ میلیون دلار هزینه داشته.
• پیچیدگی فنی و کمبود متخصص: ساختن و نگهداری سیستم‌های AI به دانش فنی خیلی بالایی نیاز داره و تعداد متخصص‌های این حوزه نسبت به تقاضا کمه.
• جابجایی شغلی: با خودکار شدن کارها، این نگرانی وجود داره که بعضی شغل‌ها از بین برن و این موضوع باعث نابرابری اقتصادی بشه.
• تاثیرات زیست‌محیطی: مراکز داده‌ای که این مدل‌ها رو اجرا میکنن، مقدار زیادی انرژی و آب مصرف میکنن که روی محیط زیست تاثیر منفی داره.

چطور میشه با این خطرات مقابله کرد؟

• انتخاب دقیق داده‌های آموزشی: باید خیلی مراقب بود که داده‌های اولیه شامل محتوای سمی یا سوگیرانه نباشن.
• استفاده از مدل‌های تخصصی: به جای استفاده از یه مدل عمومی، شرکت‌ها میتونن از مدل‌های کوچیک‌تر و تخصصی‌تر استفاده کنن یا یه مدل عمومی رو با داده‌های خودشون سفارشی‌سازی کنن.
• حفظ عامل انسانی (Human in the loop): خیلی مهمه که یه انسان واقعی خروجی مدل AI رو قبل از انتشار یا استفاده نهایی، چک کنه.
• شفافیت و حاکمیت: باید مشخص باشه که یه سیستم خودکار داره استفاده میشه و نحوه کارش توضیح داده بشه. همچنین باید ساختارهای نظارتی برای مسئولیت‌پذیری وجود داشته باشه.

قوانین و مقررات برای هوش مصنوعی

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

• منشور حقوق هوش مصنوعی (AI Bill of Rights): دولت آمریکا در سال ۲۰۲۲ یه سندی به اسم «طرح اولیه برای منشور حقوق هوش مصنوعی» آماده کرد. این سند پنج تا اصل اساسی داره:
  1. حق داشتن سیستم‌های ایمن و موثر.
  2. محافظت در برابر تبعیض توسط الگوریتم‌ها.
  3. محافظت در برابر سواستفاده از داده‌ها.
  4. حق دانستن اینکه یک سیستم خودکار در حال استفاده است.
  5. حق انصراف و دسترسی به یک انسان برای حل مشکلات.
• قانون هوش مصنوعی اتحادیه اروپا (EU’s AI Act): این قانون که قراره در سال ۲۰۲۴ اجرایی بشه، یه مقررات جامع برای AI هست که با قوانین حفاظت از داده و امنیت سایبری فعلی هم هماهنگه.

در حال حاضر بیشتر از ۶۰ کشور یا اتحادیه، استراتژی‌های ملی برای استفاده مسئولانه از AI دارن، از جمله برزیل، چین، سنگاپور، کره جنوبی و آمریکا.

یک نگاه هنری: فیلم «A.I. Artificial Intelligence»

حالا که با جنبه‌های علمی و فنی هوش مصنوعی آشنا شدیم، جالبه ببینیم دنیای هنر و سینما چطور به این موضوع نگاه کرده. یکی از معروف‌ترین فیلم‌ها در این زمینه، فیلم «A.I. Artificial Intelligence» ساخته استیون اسپیلبرگ در سال ۲۰۰۱ هست.

A.I. Artificial Intelligence
کارگردان	استیون اسپیلبرگ
فیلمنامه	استیون اسپیلبرگ
داستان	ایان واتسون
بر اساس	داستان کوتاه «اسباب‌بازی‌های فوق‌العاده تمام تابستان دوام می‌آورند» نوشته برایان آلدیس
بازیگران اصلی	هیلی جوئل آزمنت، جود لا، فرانسیس اوکانر
بودجه	۹۰ تا ۱۰۰ میلیون دلار
فروش	۲۳۵.۹ میلیون دلار

داستان فیلم در یک نگاه:

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

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

پرسش و پاسخ کلاسی

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

سوال ۱: فرق دقیق بین هوش مصنوعی، یادگیری ماشین و یادگیری عمیق چیه؟

جواب: این سه تا مثل عروسک‌های تودرتوی روسی هستن. هوش مصنوعی (AI) وسیع‌ترین مفهومه و به طور کلی به هر تکنولوژی‌ای گفته میشه که رفتار هوشمندانه انسان رو شبیه‌سازی میکنه. یادگیری ماشین (ML) یه زیرمجموعه از AI هست که به سیستم‌ها اجازه میده به جای برنامه‌ریزی مستقیم، از روی داده‌ها یاد بگیرن. و یادگیری عمیق (Deep Learning) هم یه زیرمجموعه تخصصی‌تر از یادگیری ماشینه که از شبکه‌های عصبی با لایه‌های خیلی زیاد برای حل مسائل پیچیده‌تر استفاده میکنه.

سوال ۲: آیا ChatGPT همون هوش مصنوعی قوی یا AGI هست که در موردش صحبت کردیم؟

جواب: نه. با اینکه ChatGPT و مدل‌های مشابه خیلی پیشرفته هستن، اما هنوز در دسته هوش مصنوعی ضعیف یا محدود (Narrow AI) قرار میگیرن. اونها برای یه کار مشخص، یعنی پردازش و تولید زبان، آموزش دیدن و نمیتونن مثل انسان در طیف وسیعی از کارهای مختلف فکر و استدلال کنن. اونها آگاهی یا درک واقعی ندارن و فقط در تشخیص الگوهای زبانی خیلی خوب عمل میکنن.

سوال ۳: چرا میگن «داده» برای هوش مصنوعی اینقدر مهمه؟

جواب: چون مدل‌های یادگیری ماشین و یادگیری عمیق، اساسا با تحلیل حجم عظیمی از داده‌ها «یاد میگیرن». کیفیت و کمیت داده‌های آموزشی مستقیما روی عملکرد، دقت و حتی «بی‌طرف» بودن مدل AI تاثیر میذاره. اگه داده‌های ورودی کم، اشتباه یا سوگیرانه باشن، خروجی هوش مصنوعی هم همین مشکلات رو خواهد داشت. در واقع داده مثل کتاب درسی برای یه دانش‌آموز میمونه.

سوال ۴: آیا الان قانونی برای کنترل هوش مصنوعی وجود داره؟

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

پلی‌رایت چیه و به چه دردی میخوره؟

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

این ابزار با یه API واحد، بهت اجازه میده که تعاملات کاربر رو توی مرورگرهای کرومیوم (Chromium)، فایرفاکس (Firefox) و وب‌کیت (WebKit) شبیه‌سازی کنی.

مهمترین کاربردهای پلی‌رایت اینها هستن:

• تست End-to-End: از اول تا آخر یه سناریوی کاربری رو تست میکنه. مثلا از لاگین کردن گرفته تا اضافه کردن محصول به سبد خرید و پرداخت.
• وب اسکرپینگ (Web Scraping): برای استخراج اطلاعات از وبسایت‌ها به صورت خودکار استفاده میشه.
• مانیتورینگ عملکرد: عملکرد وبسایت رو زیر نظر میگیره تا ببینه همه چیز روان و سریع اجرا میشه یا نه.

پلی‌رایت یه ویژگی خیلی مهم داره و اونم اینه که میتونه تست‌ها رو در حالت headless اجرا کنه. یعنی مرورگر باز میشه و کارها رو انجام میده، اما شما هیچ رابط کاربری گرافیکی یا پنجره‌ای ازش نمیبینید. همه چیز توی پس‌زمینه و از طریق خط فرمان اتفاق میفته. البته اگه بخواید، میتونید تنظیمش کنید که مرورگر رو به صورت کامل (non-headless) هم نشون بده.

این ابزار روی پلتفرم‌های مختلف مثل ویندوز، لینوکس و macOS کار میکنه و میتونی با زبان‌های برنامه‌نویسی مختلفی مثل TypeScript، جاوااسکریپت، پایتون، دات‌نت و جاوا ازش استفاده کنی.

ویژگی‌هایی که پلی‌رایت رو متمایز میکنه

• Auto-wait (انتظار خودکار): یکی از دلایل اصلی که تست‌ها شکننده (flaky) میشن و گاهی کار میکنن و گاهی نه، اینه که اسکریپت تست زودتر از آماده شدن یه دکمه یا یه بخش از صفحه، میخواد روش کلیک کنه. پلی‌رایت به طور خودکار منتظر میمونه تا اون عنصر «قابل استفاده» بشه و بعد کارش رو انجام میده. اینطوری نیاز به استفاده از تایم‌اوت‌های مصنوعی که باعث دردسر میشن، از بین میره.
• Web-first assertions (ادعاهای وب-محور): دستورات بررسی (assertions) توی پلی‌رایت مخصوص دنیای وب طراحی شدن. یعنی به طور خودکار یه شرط رو چک میکنن و اگه درست نبود، چند بار دیگه هم تلاش میکنن تا شاید اون شرط برقرار بشه.
• Tracing (ردیابی): میتونی تست‌ها رو طوری تنظیم کنی که اگه شکست خوردن، یه گزارش کامل شامل ویدیو، اسکرین‌شات و تمام اتفاقاتی که افتاده رو بهت بده. اینجوری پیدا کردن دلیل مشکل خیلی راحت‌تر میشه.
• ایزوله‌سازی کامل: پلی‌رایت برای هر تست، یه «کانتکست مرورگر» (browser context) جدید میسازه که مثل یه پروفایل کاملا نو و دست‌نخورده مرورگر میمونه. این کار باعث میشه تست‌ها روی هم اثر نذارن و کاملا از هم جدا باشن. ساختن این کانتکست‌ها هم خیلی سریعه و فقط چند میلی‌ثانیه طول میکشه.
• پشتیبانی از سناریوهای پیچیده: میتونی سناریوهایی رو تست کنی که شامل چند تب، چند کاربر مختلف یا حتی چند مبدا (origin) متفاوت هستن.
• رویدادهای قابل اعتماد (Trusted events): پلی‌رایت از پایپ‌لاین ورودی واقعی مرورگر استفاده میکنه. یعنی وقتی میگه روی یه چیزی کلیک کرده، اون کلیک از نظر مرورگر با کلیک یه کاربر واقعی هیچ فرقی نداره.

نصب و راه‌اندازی اولیه پلی‌رایت

خب، حالا که فهمیدیم پلی‌رایت چیه، بریم ببینیم چطور باید نصبش کنیم. قبل از هر چیز، باید Node.js نسخه ۲۰، ۲۲ یا ۲۴ روی سیستمت نصب باشه. سیستم‌عاملت هم میتونه ویندوز ۱۰ به بالا، macOS 14 به بالا، یا توزیع‌های لینوکس مثل دبیان ۱۲/۱۳ و اوبونتو ۲۲.۰۴/۲۴.۰۴ باشه.

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

# با استفاده از npm
npm init playwright@latest

# با استفاده از yarn
yarn create playwright

# با استفاده از pnpm
pnpm create playwright

وقتی این دستور رو اجرا میکنی، چند تا سوال ازت میپرسه:

• میخوای از TypeScript استفاده کنی یا JavaScript؟
• اسم پوشه تست‌هات چی باشه؟ (معمولا tests یا e2e)
• میخوای یه فایل workflow برای GitHub Actions اضافه بشه؟ (برای اجرای تست‌ها به صورت خودکار در محیط CI/CD خوبه)
• مرورگرهای پلی‌رایت نصب بشن؟ (که معمولا جواب «بله» هست)

بعد از اینکه این مراحل تموم شد، این فایل‌ها و پوشه‌ها به پروژه‌ات اضافه میشن:

• playwright.config.ts: فایل اصلی تنظیمات پلی‌رایت. اینجا مشخص میکنی تست‌ها روی چه مرورگرهایی، با چه تنظیماتی و … اجرا بشن.
• package.json: وابستگی‌های پروژه اینجا اضافه میشه.
• tests/example.spec.ts: یه فایل تست نمونه خیلی ساده.
• tests-examples/demo-todo-app.spec.ts: یه فایل تست نمونه کامل‌تر که میتونی ازش الگو بگیری.

بعد از نصب اولیه، باید مرورگرها رو نصب کنی. این دستور هر سه مرورگر اصلی (کرومیوم، فایرفاکس و وب‌کیت) رو دانلود میکنه:

npx playwright install

اجرای تست نمونه

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

# با استفاده از npm
npx playwright test

# با استفاده از yarn
yarn playwright test

# با استفاده از pnpm
pnpm exec playwright test

چند تا نکته برای اجرای تست‌ها:

• اگه میخوای پنجره مرورگر رو ببینی، از فلگ --headed استفاده کن.
• اگه میخوای تست‌ها فقط روی یه مرورگر خاص اجرا بشن، از --project=chromium استفاده کن.
• برای اجرای فقط یه فایل تست خاص: npx playwright test tests/example.spec.ts
• برای باز کردن رابط کاربری گرافیکی تست: --ui

گزارش تست HTML

بعد از اینکه تست‌ها تموم شدن، میتونی گزارش HTML رو ببینی. این گزارش بهت یه داشبورد کامل میده که میتونی تست‌ها رو بر اساس مرورگر، وضعیت (موفق، ناموفق، رد شده) فیلتر کنی. اگه تستی شکست خورده باشه، میتونی روش کلیک کنی و خطاها، فایل‌های ضمیمه و مراحل اجرا رو ببینی. این گزارش معمولا فقط وقتی تستی شکست بخوره به طور خودکار باز میشه، اما میتونی با دستور زیر هم به صورت دستی بازش کنی:

npx playwright show-report

مدیریت مرورگرها: قلب تپنده پلی‌رایت

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

نصب مرورگرها و وابستگی‌ها

همونطور که گفتیم، دستور اصلی برای نصب مرورگرها اینه:

npx playwright install

اما میتونی کارهای دیگه‌ای هم انجام بدی:

• نصب یک مرورگر خاص:

  npx playwright install webkit

• دیدن لیست تمام مرورگرهای قابل نصب:

  npx playwright install --help

• نصب وابستگی‌های سیستمی: این دستور مخصوصا توی محیط‌های CI (Continuous Integration) خیلی به درد میخوره، چون تمام پکیج‌های مورد نیاز روی سیستم‌عامل رو نصب میکنه.

  npx playwright install-deps

• نصب وابستگی‌های یک مرورگر خاص:

  npx playwright install-deps chromium

• ترکیب نصب مرورگر و وابستگی‌ها:

  npx playwright install --with-deps chromium

انواع مرورگرها و تنظیماتشون

پلی‌رایت میتونه تست‌ها رو روی موتورهای اصلی رندر وب (کرومیوم، وب‌کیت، فایرفاکس) و همچنین مرورگرهای برنددار مثل گوگل کروم (Google Chrome) و مایکروسافت اج (Microsoft Edge) اجرا کنه.

کرومیوم (Chromium)

به طور پیش‌فرض، پلی‌رایت از بیلد اوپن‌سورس کرومیوم استفاده میکنه. یه نکته جالب اینه که پروژه کرومیوم همیشه از نسخه‌های نهایی مرورگرهایی مثل کروم جلوتره. یعنی وقتی نسخه N گوگل کروم تازه منتشر شده، پلی‌رایت już از کرومیوم نسخه N+1 پشتیبانی میکنه. این بهت کمک میکنه که مشکلات احتمالی وبسایتت با نسخه‌های آینده کروم رو زودتر پیدا کنی.

پلی‌رایت دو تا بیلد از کرومیوم رو ارائه میده:

1. بیلد معمولی کرومیوم: برای عملیات headed (با رابط کاربری).
2. پوسته headless کرومیوم (chromium headless shell): یه نسخه سبک‌تر که فقط برای اجرای headless استفاده میشه.

اگه تست‌هات رو فقط در حالت headless اجرا میکنی (مثلا روی CI)، میتونی موقع نصب با اضافه کردن فلگ --only-shell از دانلود کردن بیلد کامل کرومیوم جلوگیری کنی و در فضا صرفه‌جویی کنی.

npx playwright install --with-deps --only-shell

حالت headless جدید کروم:

یه حالت headless جدید هم وجود داره که میتونی با استفاده از کانال «chromium» فعالش کنی. طبق مستندات خود کروم:

حالت Headless جدید، در واقع خود مرورگر واقعی کروم هست و به همین دلیل معتبرتر، قابل اعتمادتر و با امکانات بیشتره. این باعث میشه برای تست‌های end-to-end با دقت بالا یا تست افزونه‌های مرورگر مناسب‌تر باشه.

برای استفاده از این حالت، باید فلگ --no-shell رو موقع نصب بزنی تا پوسته headless قدیمی دانلود نشه.

npx playwright install --with-deps --no-shell

گوگل کروم و مایکروسافت اج

پلی‌رایت میتونه با نسخه‌های برنددار کروم و اج که روی سیستم شما نصب هستن هم کار کنه (البته به طور پیش‌فرض اونها رو نصب نمیکنه). پلی‌رایت از کانال‌های Stable و Beta این مرورگرها پشتیبانی میکنه.

کانال‌های موجود اینها هستن: chrome, msedge, chrome-beta, msedge-beta, chrome-dev, msedge-dev, chrome-canary, msedge-canary.

اگه این مرورگرها روی سیستمت نصب نیستن، میتونی با خود پلی‌رایت نصبشون کنی:

npx playwright install msedge

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

چه زمانی از کروم/اج استفاده کنیم و چه زمانی نه؟

• حالت پیش‌فرض (کرومیوم): در بیشتر موارد، استفاده از کرومیوم پیش‌فرض پلی‌رایت بهترین گزینه‌ست. چون جلوتر از نسخه‌های پایدار هست، بهت این اطمینان رو میده که آپدیت‌های آینده کروم وبسایتت رو خراب نمیکنه.
• تست رگرسیون (Regression testing): بعضی وقت‌ها سیاست‌های تست شرکت ایجاب میکنه که تست‌ها حتما روی نسخه‌های عمومی و پایدار فعلی مرورگرها اجرا بشن. در این حالت، میتونی از کانال‌های chrome یا msedge استفاده کنی.
• کدک‌های مدیا (Media codecs): کرومیوم به خاطر مسائل لایسنس، همه کدک‌های ویدیویی و صوتی که کروم و اج دارن رو شامل نمیشه. اگه وبسایتت به این کدک‌های خاص وابسته هست، باید از نسخه‌های رسمی استفاده کنی.
• سیاست‌های سازمانی (Enterprise policy): کروم و اج به سیاست‌های سازمانی احترام میذارن. این سیاست‌ها ممکنه محدودیت‌هایی مثل پروکسی شبکه یا افزونه‌های اجباری ایجاد کنن که جلوی تست رو میگیرن. در این شرایط، راحت‌ترین کار اینه که برای تست‌های lokal از کرومیوم باندل شده استفاده کنی و روی سرورهای CI که معمولا این محدودیت‌ها رو ندارن، از کانال‌های پایدار استفاده کنی.

فایرفاکس (Firefox)

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

وب‌کیت (WebKit)

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

چالش‌های پیشرفته: داکر، فایروال و مشکلات رایج

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

پیش‌نصب مرورگرها در داکر برای CI

یکی از مشکلات رایج اینه: یه نفر میخواد یه کانتینر داکر برای محیط CI بسازه که مرورگرها و وابستگی‌های پلی‌رایت از قبل روش نصب باشن تا مراحل تست سریع‌تر اجرا بشه. اون شخص دستور playwright install-deps رو توی Dockerfile اجرا میکنه و به نظر میاد مرورگر نصب میشه. اما وقتی به مرحله تست میرسه و دستور npx playwright install chromium رو توی پروژه اجرا میکنه، میبینه که مرورگر داره دوباره از اول دانلود میشه!

این سوال مطرح میشه: چطور میشه مرورگرها رو در یک کانتینر داکر پیش‌نصب کرد بدون اینکه در مرحله تست دوباره دانلود بشن؟

مستندات پلی‌رایت به طور خاص میگن که install-deps برای محیط‌های CI مفیده، اما باید مطمئن بشیم که مسیر نصب مرورگرها در مرحله ساخت ایمیج داکر و مرحله اجرای تست یکی باشه تا پلی‌رایت بتونه پیداشون کنه.

ایمیج رسمی داکر پلی‌رایت:

برای حل این مشکل، خود پلی‌رایت یه ایمیج رسمی داکر ارائه میده که روی اوبونتو ۲۴.۰۴ ساخته شده. توصیه میشه که از نسخه‌ای از این ایمیج استفاده کنید که با نسخه پلی‌رایت پروژه‌تون یکی باشه. اگه نسخه پلی‌رایت توی ایمیج داکر با نسخه پروژه‌تون نخونه، پلی‌رایت نمیتونه فایل‌های اجرایی مرورگر رو پیدا کنه.

docker pull mcr.microsoft.com/playwright:v1.50.0-noble

نصب پشت فایروال یا پروکسی

به طور پیش‌فرض، پلی‌رایت مرورگرها رو از CDN مایکروسافت دانلود میکنه. بعضی شرکت‌ها یه پروکسی داخلی دارن که دسترسی مستقیم به اینترنت رو میبنده. در این حالت، باید پلی‌رایت رو تنظیم کنی که از طریق پروکسی دانلود کنه:

# در Bash (لینوکس/macOS)
HTTPS_PROXY=https://192.0.2.1 npx playwright install

# در PowerShell (ویندوز)
$Env:HTTPS_PROXY="https://192.0.2.1"
npx playwright install

اگه پروکسی شما از گواهی‌های دیجیتال (CA) نامعتبر استفاده میکنه و با خطای self signed certificate in certificate chain مواجه میشید، باید متغیر محیطی NODE_EXTRA_CA_CERTS رو تنظیم کنید.

مدیریت مسیر نصب مرورگرها

پلی‌رایت مرورگرها رو توی پوشه‌های کش مخصوص سیستم‌عامل ذخیره میکنه:

• ویندوز: %USERPROFILE%\AppData\Local\ms-playwright
• macOS: ~/Library/Caches/ms-playwright
• لینوکس: ~/.cache/ms-playwright

اگه بخوای این مسیر رو تغییر بدی، میتونی از متغیر محیطی PLAYWRIGHT_BROWSERS_PATH استفاده کنی. این کار بهت اجازه میده که مرورگرها رو توی یه پوشه اشتراکی نصب کنی و همه پروژه‌ها از همون استفاده کنن.

# موقع نصب
PLAYWRIGHT_BROWSERS_PATH=$HOME/pw-browsers npx playwright install

# موقع اجرای تست
PLAYWRIGHT_BROWSERS_PATH=$HOME/pw-browsers npx playwright test

مشکل در NixOS: داستان کتابخانه‌های داینامیک

یه چالش خیلی خاص برای کاربرای توزیع لینوکس NixOS پیش میاد. وقتی میخوان یه اسکریپت ساده پلی‌رایت رو اجرا کنن، با خطا مواجه میشن که میگه یه سری کتابخانه‌های اشتراکی (shared objects) پیدا نشدن.

مشکل چیه؟

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

راه حل چیه؟

چند تا راه وجود داره، اما بهترین و ساده‌ترین راه اینه:

1. استفاده از playwright-core: به جای پکیج کامل playwright، از پکیج playwright-core استفاده کنید. این پکیج مرورگرها رو به صورت خودکار دانلود نمیکنه.
2. استفاده از کرومیوم خود NixOS: کرومیومی که از طریق Nixpkgs نصب میشه، به صورت استاتیک لینک شده و به کتابخانه‌های خارجی نیازی نداره.
3. مشخص کردن مسیر اجرایی: توی کدتون، به پلی‌رایت بگید که به جای استفاده از کرومیوم خودش، از کرومیومی که روی سیستم نصب هست استفاده کنه.

// به جای require('playwright')
const { chromium } = require('playwright-core');

const browser = await chromium.launch({
  // مسیر کرومیومی که با which chromium پیدا کردید
  executablePath: '/home/jack/.nix-profile/bin/chromium',
  headless: false
});

اینطوری پلی‌رایت دیگه دنبال وابستگی‌های داینامیک نمیگرده و مشکل حل میشه.

اون روی سکه: شناسایی و بلاک کردن پلی‌رایت

با اینکه پلی‌رایت یه ابزار قدرتمند برای تست هست، اما میشه ازش برای کارهای دیگه‌ای مثل کلاهبرداری خودکار، پر کردن اعتبارنامه‌ها (credential stuffing) و جمع‌آوری داده هم سوءاستفاده کرد. به همین دلیل، خیلی از وبسایت‌ها سعی میکنن ربات‌هایی که با پلی‌رایت ساخته شدن رو شناسایی و بلاک کنن.

چطور پلی‌رایت در حالت headless شناسایی میشه؟

• ویژگی Navigator WebDriver: پلی‌رایت در حالت headless، مقدار navigator.webdriver رو توی جاوااسکریپت true میکنه.
• الگوهای زمانی و تعاملی غیرعادی: اسکریپت‌های پلی‌رایت خیلی سریع‌تر از یه کاربر واقعی کار میکنن. کلیک‌های سریع، زمان بارگذاری صفحه غیرطبیعی و نبود هیچ زمان بیکاری (idle time)، نشونه‌های ربات هستن.
• نبود حرکات واقعی موس: تعاملات پلی‌رایت حرکات ارگانیک موس یا اسکرول کردن طبیعی رو تولید نمیکنه.
• هدرهای HTTP سفارشی: درخواست‌های ارسالی توسط پلی‌رایت ممکنه هدرهای ناقص یا ناهماهنگی مثل sec-ch-ua یا user-agent داشته باشن.
• انگشت‌نگاری (Fingerprinting): تست‌های انگشت‌نگاری از طریق WebGL، Canvas و Audio API در حالت headless نتایج متفاوتی نسبت به یه مرورگر واقعی تولید میکنن.

چطور میشه پلی‌رایت رو بلاک کرد؟

• چالش‌های مبتنی بر جاوااسکریپت: استفاده از تکنیک‌های انگشت‌نگاری برای ردیابی حرکات موس یا رندر WebGL.
• تشخیص ناهنجاری رفتاری: تحلیل رفتار کاربر مثل لاگین‌های متوالی سریع یا حجم بالای درخواست.
• کپچا (CAPTCHA) و محدودیت نرخ (Rate Limiting): استفاده از کپچاهای پیشرونده و محدود کردن تعداد درخواست‌ها در یک بازه زمانی.
• بررسی درخواست در سمت سرور: مانیتور کردن هدرهای HTTP غیر استاندارد و الگوهای ترافیک انبوه.

یک بحث مهم: موتور مرورگر در برابر خود مرورگر

یه بحث جالبی که توسط یکی از متخصصان به اسم Maaret Pyhäjärvi مطرح شده اینه که وقتی میگیم «پلی‌رایت همه مرورگرهای اصلی رو اتوماتیک میکنه»، داریم یه کم ماجرا رو ساده‌سازی میکنیم.

موتورهای مرورگر، خود مرورگرها نیستن.

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

ایشون اشاره میکنه که با اومدن WebDriver Bidi برای همه مرورگرها، این پروتکل جایگزین CDP میشه و ممکنه شرایط رو تغییر بده.

پرسش و پاسخ

سوال ۱: آیا حتما باید هر سه مرورگر کرومیوم، فایرفاکس و وب‌کیت رو نصب کنم؟

نه، اجباری نیست. شما میتونید موقع نصب مشخص کنید که فقط یک یا دو مرورگر خاص نصب بشن. مثلا با دستور npx playwright install chromium فقط کرومیوم نصب میشه. این کار به خصوص در محیط‌های CI برای صرفه‌جویی در فضا و زمان خیلی مفیده.

سوال ۲: فرق بین playwright و playwright-core چیه؟

پکیج playwright نسخه کامل هست که شامل خود کتابخانه و اسکریپت‌های دانلود خودکار مرورگرهاست. اما playwright-core یه نسخه سبک‌تره که فقط API اصلی پلی‌رایت رو داره و مرورگرها رو به صورت خودکار دانلود نمیکنه. این پکیج برای سناریوهای خاصی مثل کار با NixOS یا وقتی که میخواید از یه مرورگر از قبل نصب شده روی سیستم استفاده کنید، کاربرد داره.

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

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

سوال ۴: headless mode دقیقا یعنی چی؟

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

سوال ۵: چرا تست‌های من روی CI شکست میخورن ولی روی کامپیوتر خودم درست کار میکنن؟

این یکی از رایج‌ترین مشکلاته و دلایل زیادی میتونه داشته باشه. یکی از دلایل اصلی که به پلی‌رایت مرتبطه، میتونه مربوط به وابستگی‌های سیستمی باشه. ممکنه روی سیستم عامل سرور CI شما، پکیج‌ها و کتابخانه‌هایی که مرورگرها برای اجرا شدن بهشون نیاز دارن، نصب نباشه. به همین دلیله که دستور npx playwright install-deps خیلی مهمه و باید قبل از اجرای تست‌ها در محیط CI اجرا بشه. دلیل دیگه میتونه تفاوت در نسخه مرورگرها یا خود پلی‌رایت بین دو محیط باشه.

سوال ۶: آپدیت کردن پلی‌رایت چطوریه و چه نکته‌ای داره؟

برای آپدیت کردن پلی‌رایت، از دستور npm install -D @playwright/test@latest (یا معادلش در yarn/pnpm) استفاده میکنید. نکته بسیار مهم اینه که بعد از آپدیت خود پکیج پلی‌رایت، تقریبا همیشه باید مرورگرها رو هم آپدیت کنید. چون هر نسخه جدید پلی‌رایت برای نسخه‌های جدیدتر و مشخصی از مرورگرها طراحی شده. اگه این کار رو فراموش کنید و تست‌ها رو اجرا کنید، خود پلی‌رایت یه خطای واضح بهتون میده و میگه که فایل اجرایی مرورگر رو پیدا نکرده و ازتون میخواد که npx playwright install رو اجرا کنید.

“`