دسته: شبکه

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

یک نکته مهم که باید بدونید اینه که gRPC-Web الان به مرحله «عرضه عمومی» یا همون «Generally Available» رسیده. این یعنی چی؟ یعنی دیگه یک پروژه آزمایشی و نصفه و نیمه نیست. کاملا پایداره و شرکت‌ها و برنامه‌نویس‌ها میتونن با خیال راحت در محصولات نهایی و تجاری خودشون ازش استفاده کنن.

نکته کلیدی اینه که کلاینت‌های gRPC-Web نمیتونن مستقیم با سرویس‌های gRPC صحبت کنن. این وسط به یک واسطه یا یک جور مترجم نیاز دارن. این مترجم یک «پراکسی» یا «gateway» مخصوصه. به طور پیش‌فرض، کتابخانه gRPC-Web از پراکسی به اسم Envoy استفاده میکنه که پشتیبانی از gRPC-Web به صورت داخلی در اون تعبیه شده. پس روند کار اینطوری میشه: اپلیکیشن توی مرورگر شما درخواستش رو به زبان gRPC-Web به Envoy میفرسته، بعد Envoy اون درخواست رو ترجمه میکنه و به زبان gRPC اصلی به سرویس پشتیبان یا همون بک‌اند میفرسته. جواب رو هم به همین صورت برعکس ترجمه میکنه و به مرورگر برمیگردونه.

نگران نباشید، در آینده قراره این وضعیت بهتر هم بشه. تیم توسعه‌دهنده gRPC-Web انتظار داره که پشتیبانی از این تکنولوژی مستقیما به فریمورک‌های تحت وب در زبان‌های مختلف مثل پایتون، جاوا و نود جی‌اس اضافه بشه. این یعنی شاید در آینده دیگه نیازی به اون پراکسی جداگانه نباشه. اگه دوست دارید بیشتر در مورد برنامه‌های آینده بدونید، میتونید سند نقشه راه یا «roadmap» این پروژه رو مطالعه کنید.

چرا اصلا باید از gRPC و gRPC-Web استفاده کنیم؟

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

تمام پیچیدگی‌های ارتباط بین این زبان‌ها و محیط‌های مختلف توسط خود gRPC مدیریت میشه و شما دیگه درگیر جزئیات نمیشید. علاوه بر این، شما از تمام مزایای کار با «پروتکل بافر» یا همون «Protocol Buffers» هم بهره‌مند میشید. این مزایا شامل سریال‌سازی بهینه (یعنی تبدیل داده‌ها به فرمتی فشرده و سریع برای انتقال)، یک زبان تعریف رابط کاربری ساده (IDL) و قابلیت به‌روزرسانی آسان رابط‌ها میشه.

حالا gRPC-Web این وسط چه نقشی داره؟ gRPC-Web به شما این امکان رو میده که از داخل مرورگرها، با یک API کاملا طبیعی و آشنا برای برنامه‌نویس‌های وب، به همین سرویس‌های gRPC که ساختید دسترسی پیدا کنید.

محدودیت‌های مرورگر و راه حل‌های موجود

یک حقیقت مهم وجود داره که باید بدونیم: امکان فراخوانی مستقیم یک سرویس gRPC از مرورگر وجود نداره. چرا؟ چون gRPC از ویژگی‌های پروتکل HTTP/2 استفاده میکنه و هیچ مرورگری اون سطح از کنترل دقیق روی درخواست‌های وب رو که برای پشتیبانی از یک کلاینت gRPC لازمه، در اختیار ما قرار نمیده. مثلا ما نمیتونیم مرورگر رو مجبور کنیم حتما از HTTP/2 استفاده کنه و حتی اگه میتونستیم، به فریم‌های خام HTTP/2 در مرورگرها دسترسی نداریم.

اینجا gRPC روی ASP.NET Core دو تا راه حل سازگار با مرورگر ارائه میده:

• gRPC-Web
• gRPC JSON transcoding

آشنایی با gRPC-Web

این همون تکنولوژی هست که داریم در موردش صحبت میکنیم. gRPC-Web به اپلیکیشن‌های مرورگر اجازه میده تا با استفاده از کلاینت gRPC-Web و پروتکل بافر، سرویس‌های gRPC رو فراخوانی کنن.

• این روش خیلی شبیه به gRPC معمولیه، اما یک پروتکل انتقال داده کمی متفاوت داره که باعث میشه با HTTP/1.1 و مرورگرها سازگار باشه.
• برای استفاده از این روش، اپلیکیشن مرورگر باید یک کلاینت gRPC رو از روی همون فایل .proto که تعریف کردیم، تولید کنه.
• این روش به اپلیکیشن‌های مرورگر اجازه میده از مزایای پیام‌های باینری که عملکرد بالا و مصرف شبکه کمی دارن، بهره‌مند بشن.

خبر خوب اینه که دات نت (.NET) به صورت داخلی از gRPC-Web پشتیبانی میکنه.

آشنایی با gRPC JSON transcoding

این یک راه حل جایگزینه. این روش به اپلیکیشن‌های مرورگر اجازه میده تا سرویس‌های gRPC رو طوری فراخوانی کنن که انگار دارن با یک RESTful API معمولی با فرمت JSON کار میکنن.

• در این حالت، اپلیکیشن مرورگر نیازی به تولید کلاینت gRPC نداره و اصلا لازم نیست چیزی در مورد gRPC بدونه.
• RESTful API‌ها به صورت خودکار از روی سرویس‌های gRPC ساخته میشن. این کار با اضافه کردن یک سری حاشیه‌نویسی یا «metadata» مربوط به HTTP به فایل .proto انجام میشه.
• این روش به یک اپلیکیشن اجازه میده که هم از gRPC و هم از JSON web API‌ها پشتیبانی کنه، بدون اینکه لازم باشه برای هر کدوم سرویس‌های جداگانه‌ای بسازه و کار تکراری انجام بده.

دات نت همچنین از ساخت JSON web API از روی سرویس‌های gRPC هم پشتیبانی داخلی داره. فقط یادتون باشه که برای استفاده از gRPC JSON transcoding به دات نت ۷ یا بالاتر نیاز دارید.

یک آموزش پایه‌ای: بیایید دست به کار بشیم

خب، تئوری کافیه. بیایید با یک مثال عملی ببینیم چطور میشه از gRPC-Web استفاده کرد. در این آموزش یاد میگیریم که:

• چطور یک سرویس رو در یک فایل .proto تعریف کنیم.
• چطور با استفاده از کامپایلر پروتکل بافر، کد کلاینت رو تولید کنیم.
• چطور از API ی gRPC-Web برای نوشتن یک کلاینت ساده برای سرویسمون استفاده کنیم.

فرض ما اینه که شما یک آشنایی اولیه با پروتکل بافرها دارید.

مرحله ۱: تعریف سرویس در فایل echo.proto

اولین قدم در ساخت یک سرویس gRPC، تعریف متدهای سرویس و انواع پیام‌های درخواست و پاسخ اونها با استفاده از پروتکل بافرهاست. در این مثال، ما یک سرویس به نام EchoService رو در فایلی به اسم echo.proto تعریف میکنیم. این فایل مثل یک نقشه اولیه برای ارتباط ما عمل میکنه.

message EchoRequest {
  string message = 1;
}

message EchoResponse {
  string message = 1;
}

service EchoService {
  rpc Echo(EchoRequest) returns (EchoResponse);
}

این تعریف خیلی ساده است. ما یک درخواست به نام EchoRequest داریم که یک پیام متنی میگیره. یک پاسخ به نام EchoResponse داریم که اون هم یک پیام متنی برمیگردونه. و یک سرویس به نام EchoService داریم که یک متد به نام Echo داره. این متد یک EchoRequest میگیره و یک EchoResponse برمیگردونه. کارش اینه که هر پیامی بهش بدی، همون رو بهت برگردونه. مثل یک اکو یا پژواک صدا.

مرحله ۲: پیاده‌سازی سرور بک‌اند gRPC

حالا که نقشه رو داریم، باید سرور رو بسازیم. در مرحله بعد، ما رابط EchoService رو با استفاده از Node.js در بک‌اند پیاده‌سازی میکنیم. این سرور که اسمش رو EchoServer میذاریم، درخواست‌های کلاینت‌ها رو مدیریت میکنه. برای دیدن جزئیات کامل کد، میتونید به فایل node-server/server.js در مثال‌های رسمی gRPC-Web مراجعه کنید.

یک نکته مهم اینه که شما میتونید سرور رو با هر زبانی که gRPC ازش پشتیبانی میکنه پیاده‌سازی کنید. این یکی از قدرت‌های gRPC هست.

یک تیکه کد از سرور نود جی‌اس این شکلیه:

function doEcho(call, callback) {
  callback(null, {message: call.request.message});
}

همونطور که میبینید، این تابع خیلی ساده است. یک درخواست (call) میگیره، پیام داخلش رو برمیداره و در یک پیام جدید به عنوان پاسخ (callback) برمیگردونه.

مرحله ۳: پیکربندی پراکسی Envoy

همونطور که قبلا گفتیم، برای اینکه درخواست مرورگر به سرور بک‌اند ما برسه، به یک مترجم یا پراکسی نیاز داریم. در این مثال، ما از پراکسی Envoy استفاده میکنیم. فایل پیکربندی کامل Envoy رو میتونید در envoy.yaml ببینید.

برای اینکه Envoy درخواست‌های gRPC رو به سرور بک‌اند ما فوروارد کنه، به یک بلوک تنظیمات شبیه به این نیاز داریم:

admin:
  address:
    socket_address: { address: 0.0.0.0, port_value: 9901 }
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 8080 }
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          codec_type: auto
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: echo_service }
          http_filters:
          - name: envoy.grpc_web
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_web.v3.GrpcWeb
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
  - name: echo_service
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http2_protocol_options: {}
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: echo_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: node-server
                port_value: 9090

این تنظیمات شاید در نگاه اول پیچیده به نظر بیاد، ولی بیایید با هم بررسیش کنیم:

• listeners: این بخش تعریف میکنه که Envoy روی چه آدرس و پورتی منتظر درخواست‌های ورودی باشه. اینجا روی پورت 8080 منتظر میمونه.
• http_filters: اینجاست که جادو اتفاق میفته. ما دو تا فیلتر مهم داریم. یکی envoy.grpc_web که درخواست‌های gRPC-Web رو میشناسه و پردازش میکنه. دومی envoy.filters.http.router هست که درخواست رو به مقصد مناسبش هدایت میکنه.
• clusters: این بخش تعریف میکنه که سرور بک‌اند ما کجاست. ما یک کلاستر به اسم echo_service تعریف کردیم که به آدرس node-server و پورت 9090 اشاره میکنه.

پس سناریو اینطوریه: مرورگر یک درخواست gRPC-Web به پورت 8080 میفرستسه. Envoy این درخواست رو دریافت میکنه، با استفاده از فیلتر grpc_web اون رو ترجمه میکنه و به سرور gRPC بک‌اند ما که روی پورت 9090 قرار داره، ارسال میکنه. پاسخ سرور رو هم به همین ترتیب برعکس ترجمه میکنه و برای مرورگر میفرسته.

گاهی اوقات لازمه یک سری تنظیمات مربوط به CORS هم اضافه کنید تا مرورگر اجازه داشته باشه محتوا رو از یک مبدا دیگه درخواست بده.

مرحله ۴: تولید پیام‌های پروتوباف و کلاینت سرویس

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

protoc -I=$DIR echo.proto \
--js_out=import_style=commonjs:$OUT_DIR

• protoc: این همون کامپایلر پروتکل بافر هست.
• -I=$DIR: به کامپایلر میگه فایل‌های .proto رو کجا پیدا کنه.
• --js_out=import_style=commonjs:$OUT_DIR: این قسمت میگه که خروجی جاوااسکریپت بساز. import_style=commonjs باعث میشه که فایل‌های تولید شده از سیستم ماژول require() ی CommonJS استفاده کنن که در دنیای Node.js خیلی رایجه. $OUT_DIR هم پوشه خروجی رو مشخص میکنه.

خب، این فقط کلاس‌های مربوط به پیام‌ها رو ساخت. ما به کدهای مربوط به کلاینت سرویس هم نیاز داریم. برای این کار، به یک پلاگین مخصوص برای protoc به اسم protoc-gen-grpc-web نیاز داریم.

اول باید این پلاگین رو دانلود و نصب کنید. میتونید فایل باینری protoc رو از صفحه رسمی پروتکل بافر و پلاگین protoc-gen-grpc-web رو از صفحه گیت‌هاب gRPC-Web دانلود کنید. بعد باید مطمئن بشید که هر دوی این فایل‌ها اجرایی هستن و در PATH سیستم شما قرار دارن تا از هر جایی قابل دسترس باشن.

یک راه دیگه برای نصب پلاگین اینه که از سورس کد کامپایلش کنید. برای این کار باید از ریشه مخزن gRPC-Web دستور زیر رو اجرا کنید:

cd grpc-web
sudo make install-plugin

بعد از اینکه پلاگین آماده شد، با دستور زیر میتونیم کد کلاینت سرویس رو تولید کنیم:

protoc -I=$DIR echo.proto \
--grpc-web_out=import_style=commonjs,mode=grpcwebtext:$OUT_DIR

این دستور خیلی شبیه دستور قبلیه، ولی از --grpc-web_out استفاده میکنه که مخصوص پلاگین ماست. بیایید پارامترهاش رو بررسی کنیم:

• mode: این پارامتر میتونه grpcwebtext (که پیش‌فرض هست) یا grpcweb باشه. این دو حالت در نحوه کدگذاری داده‌ها تفاوت دارن که بعدا بیشتر در موردش صحبت میکنیم.
• import_style: این پارامتر هم میتونه closure (که پیش‌فرض هست) یا commonjs باشه. ما از commonjs استفاده کردیم تا با خروجی قبلیمون هماهنگ باشه.

این دستور به طور پیش‌فرض یک فایل به نام echo_grpc_web_pb.js تولید میکنه که شامل کد کلاینت ماست.

مرحله ۵: نوشتن کد کلاینت جاوااسکریپت

بالاخره رسیدیم به قسمت شیرین ماجرا. حالا آماده‌ایم که کد جاوااسکریپت سمت کلاینت رو بنویسیم. این کد رو در یک فایلی به نام client.js قرار میدیم.

const {EchoRequest, EchoResponse} = require('./echo_pb.js');
const {EchoServiceClient} = require('./echo_grpc_web_pb.js');

var echoService = new EchoServiceClient('http://localhost:8080');

var request = new EchoRequest();
request.setMessage('Hello World!');

echoService.echo(request, {}, function(err, response) {
  // اینجا میتونیم با پاسخ سرور کار کنیم
  // مثلا response.getMessage() رو چاپ کنیم
});

بیایید این کد رو با هم تحلیل کنیم:

1. در دو خط اول، ما کلاس‌هایی که در مرحله قبل تولید کردیم (EchoRequest, EchoResponse, EchoServiceClient) رو با استفاده از require وارد برنامه‌مون میکنیم.
2. بعد یک نمونه جدید از EchoServiceClient میسازیم و آدرس پراکسی Envoy خودمون (http://localhost:8080) رو بهش میدیم.
3. یک نمونه جدید از EchoRequest میسازیم و پیام «Hello World!» رو داخلش قرار میدیم.
4. در نهایت، متد echo رو روی سرویسمون فراخوانی میکنیم. به عنوان ورودی، درخواست (request)، یک آبجکت خالی برای متادیتا ({}) و یک تابع callback بهش میدیم. این تابع زمانی اجرا میشه که پاسخی از سرور دریافت بشه. این پاسخ میتونه خطا (err) یا جواب موفقیت‌آمیز (response) باشه.

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

{
  "name": "grpc-web-commonjs-example",
  "dependencies": {
    "google-protobuf": "^3.6.1",
    "grpc-web": "^0.4.0"
  },
  "devDependencies": {
    "browserify": "^16.2.2",
    "webpack": "^4.16.5",
    "webpack-cli": "^3.1.0"
  }
}

این فایل مشخص میکنه که پروژه ما به پکیج‌های google-protobuf و grpc-web نیاز داره. همچنین برای ساختن فایل نهایی برای مرورگر، از ابزارهایی مثل browserify یا webpack استفاده میکنیم.

مرحله ۶: کامپایل کتابخانه جاوااسکریپت

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

اول با دستور npm install پکیج‌های مورد نیاز رو نصب میکنیم.

بعد با دستوری مثل این، فایل نهایی رو میسازیم:

npx webpack client.js

این دستور فایل client.js ما و تمام وابستگی‌هاش رو در یک فایل به نام main.js در پوشه dist قرار میده. حالا کافیه این فایل dist/main.js رو در صفحه HTML خودمون قرار بدیم و نتیجه رو ببینیم!

یک راه سریع برای شروع

اگر حوصله انجام تمام این مراحل رو به صورت دستی ندارید، یک راه سریع‌تر هم وجود داره. میتونید از مثال‌های آماده خود gRPC-Web استفاده کنید:

$ git clone https://github.com/grpc/grpc-web
$ cd grpc-web
$ docker-compose up node-server envoy commonjs-client

این دستورات با استفاده از داکر، همه چیز رو براتون آماده میکنه: سرور نود جی‌اس، پراکسی Envoy و یک کلاینت نمونه. بعد کافیه مرورگر خودتون رو باز کنید و به آدرس http://localhost:8081/echotest.html برید تا همه چیز رو در عمل ببینید.

نگاهی عمیق‌تر به ویژگی‌ها و گزینه‌ها

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

انواع RPC و پشتیبانی در gRPC-Web

gRPC در حالت کلی چهار نوع متد یا RPC رو پشتیبانی میکنه:

1. Unary RPCs: یک درخواست میفرستی و یک پاسخ میگیری. مثل همین مثال Echo ما.
2. Server-side Streaming RPCs: یک درخواست میفرستی و یک جریان از پاسخ‌ها رو به صورت پشت سر هم دریافت میکنی.
3. Client-side Streaming RPCs: یک جریان از درخواست‌ها رو میفرستی و در نهایت یک پاسخ میگیری.
4. Bi-directional Streaming RPCs: یک جریان دوطرفه از درخواست‌ها و پاسخ‌ها به صورت همزمان داری.

gRPC-Web در حال حاضر فقط از دو نوع اول پشتیبانی میکنه. یعنی Unary RPC و Server-side Streaming RPC. استریمینگ سمت کلاینت و دوطرفه فعلا پشتیبانی نمیشن. البته برای استریمینگ سمت سرور هم یک شرط وجود داره: باید حتما از حالت grpcwebtext استفاده کنید.

حالت‌های مختلف انتقال داده (mode)

وقتی داشتیم کد کلاینت رو تولید میکردیم، یک پارامتر به اسم mode دیدیم. این پارامتر دو تا مقدار میتونه داشته باشه:

• mode=grpcwebtext: این حالت پیش‌فرض هست.
  • Content-type درخواست میشه application/grpc-web-text.
  • داده‌ها یا همون payload به صورت base64 کدگذاری میشن. این یعنی داده‌های باینری به فرمت متنی تبدیل میشن.
  • هم از Unary و هم از Server-side streaming پشتیبانی میکنه.
• mode=grpcweb: این حالت از فرمت باینری پروتوباف استفاده میکنه.
  • Content-type درخواست میشه application/grpc-web+proto.
  • داده‌ها به صورت باینری و خام پروتوباف فرستاده میشن. این حالت معمولا بهینه‌تر و کم‌حجم‌تره.
  • فقط از Unary call پشتیبانی میکنه. استریمینگ سمت سرور در این حالت کار نمیکنه.

استایل‌های مختلف ایمپورت (import_style)

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

• import_style=closure: این حالت پیش‌فرض هست و از سیستم ماژول goog.require() کتابخانه Closure گوگل استفاده میکنه.
• import_style=commonjs: این حالت از require() ی CommonJS استفاده میکنه که برای کار با ابزارهایی مثل Webpack و Browserify خیلی مناسبه.
• import_style=commonjs+dts: (آزمایشی) این حالت علاوه بر کد CommonJS، یک فایل تایپینگ .d.ts هم برای پیام‌های پروتوباف و کلاینت سرویس تولید میکنه. این برای کار با TypeScript خیلی مفیده.
• import_style=typescript: (آزمایشی) این حالت مستقیما کد کلاینت سرویس رو به زبان TypeScript تولید میکنه.

پشتیبانی از TypeScript

خبر خوب برای طرفدارهای TypeScript اینه که gRPC-Web به صورت آزمایشی از این زبان پشتیبانی میکنه. حالا ماژول grpc-web رو میشه به عنوان یک ماژول TypeScript وارد کرد.

برای استفاده از این قابلیت، باید موقع تولید کد از پلاگین protoc-gen-grpc-web، یکی از این دو گزینه رو بهش بدید:

• import_style=commonjs+dts: کد CommonJS به همراه فایل‌های تایپینگ .d.ts تولید میکنه.
• import_style=typescript: کد کاملا TypeScript تولید میکنه.

یک نکته خیلی مهم: شما نباید import_style=typescript رو برای فلگ --js_out استفاده کنید. این فلگ فقط باید روی import_style=commonjs تنظیم بشه. در واقع --js_out کد جاوااسکریپت پیام‌ها (echo_pb.js) رو تولید میکنه و --grpc-web_out فایل‌های TypeScript مربوط به سرویس (EchoServiceClientPb.ts) و تایپینگ پیام‌ها (echo_pb.d.ts) رو میسازه. این یک راه حل موقتیه تا زمانی که خود --js_out به صورت کامل از TypeScript پشتیبانی کنه.

پس دستور کامل برای تولید کد TypeScript با فرمت باینری این شکلی میشه:

protoc -I=$DIR echo.proto \
--js_out=import_style=commonjs,binary:$OUT_DIR \
--grpc-web_out=import_style=typescript,mode=grpcweb:$OUT_DIR

و کد سمت کلاینت در TypeScript میتونه این شکلی باشه:

import * as grpcWeb from 'grpc-web';
import {EchoServiceClient} from './EchoServiceClientPb';
import {EchoRequest, EchoResponse} from './echo_pb';

const echoService = new EchoServiceClient('http://localhost:8080', null, null);

const request = new EchoRequest();
request.setMessage('Hello World!');

const call = echoService.echo(request, {'custom-header-1': 'value1'},
  (err: grpcWeb.RpcError, response: EchoResponse) => {
    if (err) {
      console.log(`Received error: ${err.code}, ${err.message}`);
    } else {
      console.log(response.getMessage());
    }
  });

call.on('status', (status: grpcWeb.Status) => {
  // ...
});

همونطور که میبینید، همه چیز تایپ-سیف و مشخصه.

کلاینت مبتنی بر Promise

علاوه بر مدل callback که دیدیم، میتونید از یک کلاینت مبتنی بر Promise هم استفاده کنید. این مدل کدنویسی برای خیلی‌ها خواناتر و مدرن‌تره.

// Create a Promise client instead
const echoService = new EchoServicePromiseClient('http://localhost:8080', null, null);

// ... (request is the same as above)

echoService.echo(request, {'custom--header-1': 'value1'})
  .then((response: EchoResponse) => {
    console.log(`Received response: ${response.getMessage()}`);
  }).catch((err: grpcWeb.RpcError) => {
    console.log(`Received error: ${err.code}, ${err.message}`);
  });

فقط یک نکته مهم رو در نظر داشته باشید: وقتی از Promise استفاده میکنید، دیگه نمیتونید به callback‌های .on(...) (مثلا برای metadata و status) دسترسی داشته باشید.

تاریخچه و وضعیت فعلی gRPC در مرورگر

جالبه بدونید که داستان gRPC در مرورگر چطور شروع شد. در تابستان ۲۰۱۶، یک تیم در گوگل و یک شرکت به نام Improbable به صورت مستقل از هم شروع به کار روی چیزی کردن که میشد اسمش رو گذاشت «gRPC برای مرورگر». خیلی زود از وجود هم باخبر شدن و با هم همکاری کردن تا یک مشخصات فنی یا «spec» برای این پروتکل جدید تعریف کنن.

مشخصات فنی gRPC-Web

همونطور که گفتیم، پیاده‌سازی کامل مشخصات gRPC مبتنی بر HTTP/2 در مرورگرها غیرممکنه. به خاطر همین، مشخصات gRPC-Web با در نظر گرفتن این محدودیت‌ها و با تعریف تفاوت‌هاش با gRPC اصلی نوشته شد. این تفاوت‌های کلیدی عبارتند از:

• پشتیبانی از هر دو پروتکل HTTP/1.1 و HTTP/2.
• ارسال هدرهای تریلر gRPC در انتهای بدنه درخواست/پاسخ.
• الزامی بودن استفاده از یک پراکسی برای ترجمه بین درخواست‌های gRPC-Web و پاسخ‌های gRPC HTTP/2.

دو پیاده‌سازی اصلی

تیم‌های گوگل و Improbable هر کدوم پیاده‌سازی خودشون رو از این مشخصات ارائه دادن. این دو پیاده‌سازی در دو مخزن جداگانه قرار داشتن و برای مدتی با هم سازگار نبودن.

• کلاینت Improbable:
  • با زبان TypeScript نوشته شده.
  • در npm با نام @improbable-eng/grpc-web موجوده.
  • یک پراکسی به زبان Go هم داره که هم به صورت پکیج و هم به صورت یک برنامه مستقل قابل استفاده است.
  • از هر دو Fetch و XHR برای ارسال درخواست‌ها استفاده میکنه و به صورت خودکار بر اساس قابلیت‌های مرورگر یکی رو انتخاب میکنه.
• کلاینت Google:
  • با زبان جاوااسکریپت و با استفاده از کتابخانه Google Closure نوشته شده.
  • در npm با نام grpc-web موجوده.
  • در ابتدا با یک افزونه برای NGINX به عنوان پراکسی عرضه شد، ولی بعدا روی فیلتر HTTP پراکسی Envoy تمرکز کرد.
  • فقط از XHR برای ارسال درخواست‌ها استفاده میکنه.

بیایید این دو رو در یک جدول با هم مقایسه کنیم:

کلاینت / ویژگی	روش انتقال	Unary	استریم سمت سرور	استریم سمت کلاینت و دوطرفه
Improbable	Fetch/XHR	✔️	✔️	❌ (با یک روش آزمایشی وب‌سوکت)
Google (grpcwebtext)	XHR	✔️	✔️	❌
Google (grpcweb)	XHR	✔️	❌ (فقط در انتها نتیجه رو برمیگردونه)	❌

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

آینده و مسیر پیش رو

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

• یک فرمت کدگذاری پیام‌ها شبیه JSON ولی بهینه‌تر.
• پراکسی‌های درون-فرایندی برای Node، پایتون، جاوا و غیره (تا نیاز به پراکسی جدا مثل Envoy کمتر بشه).
• ادغام با فریمورک‌های محبوب مثل React، Angular و Vue.
• استفاده از Fetch API برای استریمینگ بهینه‌تر از نظر حافظه.
• پشتیبانی از استریمینگ دوطرفه.

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

پس اگه امروز میخواید با gRPC-Web شروع کنید، بهترین گزینه کلاینت گوگل هست. این کلاینت تضمین‌های سازگاری API قوی‌ای داره و توسط یک تیم اختصاصی پشتیبانی میشه.

مزایای استفاده از gRPC-Web

حالا که با جزئیات فنی آشنا شدیم، بیایید یک بار دیگه مزایای معماری gRPC-Web رو مرور کنیم.

• gRPC سرتاسری (End-to-end gRPC): به شما اجازه میده کل خط لوله RPC خودتون رو با استفاده از پروتکل بافرها طراحی کنید. دیگه لازم نیست یک لایه اضافه برای تبدیل درخواست‌های HTTP/JSON به gRPC در بک‌اند داشته باشید.
• هماهنگی بیشتر بین تیم‌های فرانت‌اند و بک‌اند: وقتی کل ارتباط با پروتکل بافر تعریف میشه، دیگه مرز بین تیم «کلاینت» و تیم‌های «میکروسرویس‌ها» کمرنگ‌تر میشه. ارتباط کلاینت-بک‌اند فقط یک لایه gRPC دیگه در کنار بقیه لایه‌هاست.
• تولید آسان کتابخانه‌های کلاینت: وقتی سروری که با دنیای بیرون در ارتباطه، یک سرور gRPC باشه، تولید کتابخانه‌های کلاینت برای زبان‌های مختلف (روبی، پایتون، جاوا و …) خیلی راحت‌تر میشه و دیگه نیازی به نوشتن کلاینت‌های HTTP جداگانه برای هر کدوم نیست.

دیدگاه دنیای واقعی: gRPC-Web در مقابل REST

جالبه بدونید که همیشه همه با یک تکنولوژی موافق نیستن. در یک بحث در وبسایت ردیت، یک مهندس ارشد پیشنهاد کرده بود که تیمشون از gRPC-Web به سمت استفاده از REST Handler‌های معمولی حرکت کنه. دلیل این پیشنهاد این بود که در یک استارتاپ که سرعت توسعه و رسیدن به بازار اولویت داره، این کار میتونه مفید باشه.

نگرانی‌هایی که در مورد این تغییر مطرح شده بود اینها بودن:

• از دست دادن یک تعریف نوع (type definition) یکپارچه که پروتوباف فراهم میکنه.
• نیاز به ابداع مجدد چرخ و نوشتن کدهای تکراری.
• نیاز به ارتباط و مستندسازی بیشتر بین تیم‌ها.

در مقابل، تنها مزیت مسیر HTTP/REST این عنوان شده بود که درک و فهم اون برای بعضی‌ها ساده‌تره. این بحث نشون میده که انتخاب بین این تکنولوژی‌ها همیشه یک سری بده‌بستان (trade-off) داره و به شرایط پروژه بستگی داره. هر دو روش، چه استفاده از پروتوباف برای تولید کلاینت gRPC-Web و چه استفاده از OpenAPI برای تولید کلاینت REST، در سطح بالا یک هدف مشترک دارن: تولید خودکار کلاینت از روی یک تعریف مشخص.

پرسش و پاسخ

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

1. سوال ۱: gRPC دقیقا چیه؟

جواب: gRPC یک چارچوب RPC (Remote Procedure Call) مدرن، متن‌باز و با کارایی بالاست که توسط گوگل ساخته شده. به زبان ساده، یک روش خیلی سریع و بهینه برای اینه که سرویس‌های مختلف در یک سیستم کامپیوتری بتونن با هم صحبت کنن و از هم سرویس بگیرن، حتی اگه در کامپیوترهای مختلف و با زبان‌های برنامه‌نویسی متفاوتی نوشته شده باشن. این چارچوب از پروتکل HTTP/2 برای انتقال داده استفاده میکنه.

2. سوال ۲: چرا نمیتونیم مستقیم از gRPC توی مرورگر استفاده کنیم و به gRPC-Web نیاز داریم؟

جواب: چون gRPC روی ویژگی‌های سطح پایین پروتکل HTTP/2 ساخته شده. مرورگرهای وب امروزی به برنامه‌نویس‌ها اجازه دسترسی و کنترل مستقیم روی این ویژگی‌ها رو نمیدن. برای همین، یک «پل» یا «مترجم» به اسم gRPC-Web ساخته شده که یک پروتکل کمی متفاوت و سازگار با محدودیت‌های مرورگر داره. این پروتکل بعدا توسط یک پراکسی (مثل Envoy) به gRPC استاندارد ترجمه میشه.

3. سوال ۳: فایل .proto چیه و چه نقشی داره؟

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

4. سوال ۴: پراکسی Envoy چیه و چرا در معماری gRPC-Web مهمه؟

جواب: Envoy یک پراکسی سرویس مدرن و با کارایی بالاست. در دنیای gRPC-Web، نقش یک مترجم رو بازی میکنه. درخواست‌هایی که از مرورگر با پروتکل gRPC-Web میان رو دریافت میکنه، اونها رو به پروتکل استاندارد gRPC (که روی HTTP/2 کار میکنه) تبدیل میکنه و به سرور بک‌اند میفرسته. پاسخ سرور رو هم به همین ترتیب برعکس ترجمه میکنه و برای مرورگر میفرسته. بدون وجود یک پراکسی مثل Envoy، ارتباط مستقیم بین مرورگر و سرور gRPC ممکن نیست. البته پراکسی‌های دیگه‌ای مثل پراکسی Go، Apache APISIX و Nginx هم این قابلیت رو دارن.

5. سوال ۵: تفاوت اصلی بین دو حالت mode=grpcwebtext و mode=grpcweb چیه؟

جواب: تفاوت اصلی در نحوه کدگذاری و انتقال داده‌هاست.

• grpcwebtext داده‌ها رو به صورت متنی (Base64) کدگذاری میکنه و هم از درخواست‌های تکی (Unary) و هم از استریمینگ سمت سرور پشتیبانی میکنه.
• grpcweb داده‌ها رو به صورت باینری و خام پروتوباف منتقل میکنه که بهینه‌تره، ولی فقط از درخواست‌های تکی (Unary) پشتیبانی میکنه.

6. سوال ۶: آیا میتونم از gRPC-Web برای آپلود فایل یا چت دوطرفه استفاده کنم؟

جواب: در حال حاضر، خیر. gRPC-Web از استریمینگ سمت کلاینت و استریمینگ دوطرفه پشتیبانی نمیکنه. این قابلیت‌ها در نقشه راه پروژه قرار دارن ولی هنوز پیاده‌سازی نشدن. پس برای کارهایی مثل آپلود فایل (که نیاز به استریم سمت کلاینت داره) یا یک اپلیکیشن چت زنده (که نیاز به استریم دوطرفه داره)، gRPC-Web فعلا راه حل کاملی نیست.

داستان بلوتوث از کجا شروع شد؟

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

بلوتوث یک تکنولوژی بی‌سیم با برد کوتاهه که تو باند فرکانسی ۲.۴ گیگاهرتز ISM کار میکنه. این باند فرکانسی برای استفاده عموم آزاده و نیازی به مجوز نداره. کارش هم انتقال داده و ساختن شبکه‌های شخصی کوچیک (PAN) هست.

احتمالا همین الان دور و بر همه‌مون کلی دستگاه بلوتوثی هست: گوشی موبایل، لپ‌تاپ، هدفون و اسپیکر. جالبه بدونید که فقط تو سال ۲۰۲۱، بیشتر از ۴.۷ میلیارد دستگاه بلوتوثی تو کل دنیا تولید و عرضه شده. این نشون میده که بلوتوث یکی از پرکاربردترین تکنولوژی‌های دنیاست.

اگه از مردم تو خیابون بپرسید بلوتوث چیه، اکثرشون یه شناخت کلی ازش دارن. اما پشت پرده، این یک استاندارد فنی نسبتا پیچیده‌ است که توسط یک گروه به اسم گروه علایق ویژه بلوتوث (Bluetooth Special Interest Group) یا به اختصار SIG مدیریت میشه. این گروه در طول سال‌ها، نسخه‌های مختلفی از مشخصات فنی بلوتوث رو منتشر کرده. دو تا از معروف‌ترین پروتکل‌های این استاندارد، «بلوتوث کلاسیک» و «بلوتوث کم‌مصرف» هستن.

تا سال ۲۰۱۰، تمرکز اصلی روی بهتر کردن بلوتوث کلاسیک بود. اما تو همین سال، گروه SIG نسخه ۴.۰ بلوتوث رو منتشر کرد. این نسخه یک مسیر متفاوت رو در پیش گرفت و یک پروتکل جدید به اسم بلوتوث کم‌مصرف (BLE) رو به دنیا معرفی کرد.

بلوتوث کم‌مصرف (BLE) دقیقا چیه؟

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

ارتباط داده با رادیوی LE (که مخفف Low Energy هست) در بسته‌های کوچیک و کوتاه اتفاق میفته که لازم نیست خیلی پشت سر هم باشن. یک سناریوی معمولی برای BLE این شکلیه: دستگاه رادیوش رو برای مدت کوتاهی روشن میکنه، چند بایت یا چند کیلوبایت داده رو منتقل یا دریافت میکنه، و بعد دوباره رادیو رو خاموش میکنه و به حالت خواب (Sleep Mode) برمیگرده.

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

مقایسه بلوتوث کلاسیک و بلوتوث کم‌مصرف (BLE)

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

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

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

ویژگی	بلوتوث کلاسیک (Classic Bluetooth)	بلوتوث کم‌مصرف (BLE)
هدف اصلی	انتقال مداوم داده (مثل صدا)	انتقال بسته‌های کوچک داده به صورت دوره‌ای
مصرف انرژی	بالا	بسیار پایین (تا ۱۰۰ برابر کمتر از کلاسیک)
سرعت انتقال داده	بالاتر	پایین‌تر
کاربرد اصلی	هدفون، اسپیکر، انتقال فایل	سنسورها، گجت‌های پوشیدنی، دستگاه‌های پزشکی
حالت کاری	همیشه متصل و فعال	بیشتر اوقات در حالت خواب، برای مدت کوتاه فعال

چرا BLE اینقدر خوبه؟ (مزیت‌ها)

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

• مصرف انرژی پایین: حتی وقتی با بقیه تکنولوژی‌های کم‌مصرف مقایسه‌اش میکنیم، BLE باز هم بهینه و کم‌مصرفه. راز این مصرف کم اینه که رادیوی دستگاه تا جای ممکن خاموش میمونه و فقط برای فرستادن مقدار کمی داده با سرعت پایین برای مدت کوتاهی روشن میشه.
• هزینه پایین برای شروع توسعه: ماژول‌ها و چیپست‌های BLE در مقایسه با تکنولوژی‌های مشابه، قیمت پایین‌تری دارن. این به خاطر اینه که استفاده ازش خیلی زیاد شده و رقابت تو بازار بالا رفته.
• دسترسی آزاد به مستندات فنی: برای بیشتر پروتکل‌ها و تکنولوژی‌های بی‌سیم دیگه، شما باید عضو رسمی اون گروه یا کنسرسیوم بشید تا بتونید به مشخصات فنیش دسترسی داشته باشید. عضویت تو این گروه‌ها میتونه خیلی گرون باشه (حتی تا هزاران دلار در سال). اما برای BLE، مستندات فنی نسخه‌های اصلی (مثل 4.0, 4.2, 5.0, 5.1, 5.2, 5.3 و غیره) رو میتونید به صورت رایگان از وب‌سایت Bluetooth.com دانلود کنید.
• وجود گسترده در گوشی‌های هوشمند: این شاید بزرگترین مزیت BLE نسبت به رقباش مثل ZigBee، Z-Wave و Thread باشه. تقریبا همه مردم دنیا یک گوشی هوشمند دارن و تقریبا تمام این گوشی‌ها سخت‌افزار BLE رو داخلشون دارن. این به توسعه‌دهنده‌ها یک پایگاه کاربری بالقوه خیلی بزرگ برای اپلیکیشن‌هاشون میده.

آیا BLE هیچ محدودیتی نداره؟

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

• سرعت انتقال داده (Throughput): سرعت انتقال داده تو BLE توسط نرخ داده رادیوی فیزیکی محدود میشه. این نرخ به نسخه بلوتوثی که استفاده میشه بستگی داره.
  • برای نسخه‌های بلوتوث قبل از ۵.۰، این نرخ روی ۱ مگابیت بر ثانیه (Mbps) ثابته.
  • اما برای بلوتوث ۵.۰ و بالاتر، این نرخ بسته به حالت و لایه فیزیکی (PHY) که استفاده میشه، متغیره. میتونه مثل نسخه‌های قبلی ۱ مگابیت بر ثانیه باشه، یا وقتی از قابلیت سرعت بالا (high-speed) استفاده میشه به ۲ مگابیت بر ثانیه برسه.
  • وقتی هم از قابلیت برد بلند (long-range) استفاده میشه، این نرخ به ۵۰۰ یا ۱۲۵ کیلوبیت بر ثانیه (Kbps) کاهش پیدا میکنه.
  • نکته مهم: این نرخ‌ها مربوط به لایه رادیوییه. سرعتی که کاربر نهایی در سطح اپلیکیشن تجربه میکنه، خیلی کمتر از این حرف‌هاست.
• برد (Range): تکنولوژی BLE برای کاربردهای با برد کوتاه طراحی شده، برای همین برد عملکردش محدوده. چند تا عامل روی برد BLE تاثیر میذارن:
  • فرکانس کاری: این تکنولوژی تو طیف فرکانسی ۲.۴ گیگاهرتز ISM کار میکنه که خیلی تحت تاثیر موانعی مثل اشیای فلزی، دیوارها و آب (مخصوصا بدن انسان) قرار میگیره.
  • طراحی آنتن: عملکرد و طراحی آنتن دستگاه BLE خیلی مهمه.
  • پوشش فیزیکی دستگاه: قاب و بدنه دستگاه روی عملکرد آنتن تاثیر میذاره، مخصوصا اگه آنتن داخلی باشه.
  • جهت‌گیری دستگاه: این مورد هم به موقعیت قرارگیری آنتن مربوط میشه (مثلا تو گوشی‌های هوشمند). به طور کلی برد BLE بین ۰ تا ۲۵ متر بهینه است و در شرایط ایده‌آل میتونه تا ۱۰۰ متر هم برسه.
• نیاز به دروازه (Gateway) برای اتصال به اینترنت: برای اینکه داده رو از یک دستگاه که فقط BLE داره به اینترنت بفرستید، به یک دستگاه دیگه نیاز دارید که هم BLE داشته باشه و هم به اینترنت وصل باشه (مثلا یک گوشی هوشمند یا یک دستگاه مخصوص). این دستگاه واسط، داده رو از دستگاه BLE میگیره و بعد به اینترنت منتقل میکنه.

BLE رو کجاها میبینیم؟ (کاربردهای واقعی)

وقتی BLE تو سال ۲۰۱۰ معرفی شد، تمرکزش بیشتر روی کاربردهای اینترنت اشیا (IoT) بود که تو اونها حجم کمی از داده با سرعت پایین منتقل میشه. تو این ده سال اخیر، BLE تو کاربردهای خیلی متنوعی از دستگاه‌های مصرفی گرفته تا تولیدات صنعتی استفاده شده. بیایید چند تا از رایج‌ترین کاربردهاش رو ببینیم:

• اتوماسیون خانگی: بخش بزرگی از بازار خانه هوشمند به لطف استفاده از بلوتوث LE ممکن شده. این تکنولوژی به دستگاه‌هایی مثل لامپ‌های هوشمند، ترموستات‌های هوشمند، قفل‌های هوشمند و سنسورهایی که دود یا باز بودن پنجره رو تشخیص میدن، اجازه میده با هم ارتباط برقرار کنن.
• ردیاب‌های تناسب اندام: خیلی از ما ساعت‌های هوشمند یا مچ‌بندهای سلامتی داریم که ضربان قلب، تعداد قدم‌ها و چیزای دیگه رو ردیابی میکنن. این دستگاه‌های سلامتی و ردیاب فعالیت، با استفاده از BLE با اپلیکیشن‌های روی گوشیمون ارتباط برقرار میکنن. این انتقال‌های کوتاه و سریع داده در فاصله نزدیک، یک مثال عالی برای کاربرد BLE هست.
• دستگاه‌های صوتی: همه ما با هدفون‌های بلوتوثی آشناییم، اما معمولا این دستگاه‌ها از بلوتوث کلاسیک استفاده میکنن. یکی از جدیدترین پیشرفت‌ها در زمینه بلوتوث کم‌مصرف، چیزی به اسم LE Audio هست. این استاندارد جدید چندین مزیت نسبت به بلوتوث سنتی داره، از جمله کیفیت صدای بهتر، مصرف انرژی کمتر و پشتیبانی از سمعک‌ها.
• ردیابی تماس (Contact Tracing): سیستم‌های هوشمند ردیابی تماس دارن برای کمک به جلوگیری از شیوع بیماری‌های عفونی استفاده میشن. به جای گزارش‌دهی دستی، ردیابی تماس با استفاده از BLE به صورت مداوم «تگ»های BLE یا گوشی‌های هوشمند اطراف رو اسکن میکنه تا به صورت ناشناس تماس‌های نزدیک بین افراد رو ثبت کنه. مثلا در یک محیط کاری، به هر کارمند یک تگ BLE داده میشه و اگه یک نفر بیمار بشه، به راحتی میشه فهمید چه کسانی با اون در تماس نزدیک بودن.
• تگ‌های پیدا کردن اشیا: با شلوغ شدن سفرها، بعضی‌ها تگ‌هایی مثل AirTag یا Tile رو به چمدونشون وصل میکنن تا اگه گم شد بتونن پیداش کنن. این دستگاه‌های ردیاب دقیق که با BLE کار میکنن، فقط برای چمدون نیستن. میتونید اونها رو به هر چیزی که فکر میکنید ممکنه گم بشه وصل کنید، مثل دوچرخه یا کلید ماشین، و موقعیتش رو از طریق یک اپلیکیشن روی گوشی پیدا کنید.
• تبلیغات هدفمند: تصور کنید تو یک فروشگاه لباس هستید و یهو یک نوتیفیکیشن روی گوشیتون میاد که یک کوپن تخفیف برای همون فروشگاهی که توش هستید بهتون میده. این نوع تبلیغات شخصی‌سازی شده و مبتنی بر مکان، دقیقا کاریه که تبلیغ‌کننده‌ها و صاحبان فروشگاه‌ها میتونن انجام بدن. این کار به لطف پیشرفت‌های بلوتوث ۵.۰ و تکنولوژی پخش همگانی «بیکن»های بلوتوثی ممکنه.
• مدیریت انبار: مدیران انبارها دارن از راهکارهای مبتنی بر BLE برای ردیابی دما و رطوبت محموله‌های حساس، تشخیص افتادن بسته‌های شکننده و حتی پیدا کردن بهینه‌ترین مکان برای نگهداری دارایی‌ها در انبار استفاده میکنن. پتانسیل زیادی وجود داره که هوش مصنوعی و BLE با هم ترکیب بشن و یک زنجیره لجستیک واقعا هوشمند ایجاد کنن.
• ایمنی کارکنان: تگ‌های BLE میتونن به روش‌های مختلفی به حفظ ایمنی کارکنان کمک کنن. مثلا دکمه‌های وحشت (Panic buttons) برای کارمندان بانک یا هتل که در معرض خطر هستن. این افراد میتونن با فشار دادن تگ BLE به صورت نامحسوس درخواست کمک کنن. یا سیستم‌های تشخیص سقوط (Fall detection) در سایت‌های ساختمانی یا خانه‌های سالمندان که به محض تشخیص سقوط، به صورت خودکار هشدار ارسال میکنن.

بیکن‌های BLE (BLE Beacons)

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

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

خب، حالا بریم سراغ بخش فنی ماجرا: معماری BLE

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

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

پشته پروتکل بلوتوث به طور کلی به سه بخش یا زیرسیستم اصلی تقسیم میشه: اپلیکیشن (Application)، میزبان (Host) و کنترلر (Controller). داخل هر کدوم از این بلوک‌ها، لایه‌های مشخصی وجود داره.

لایه‌های پروتکل BLE

اگه شما توسعه‌دهنده‌ای هستید که میخواید اپلیکیشن‌های BLE بنویسید، لازم نیست خیلی نگران لایه‌هایی که پایین‌تر از لایه مدیر امنیت (Security Manager) و پروتکل ویژگی (Attribute Protocol) هستن باشید. اما دونستن کلیات این لایه‌ها میتونه مفید باشه. بیایید یه نگاهی بهشون بندازیم.

• لایه فیزیکی (Physical Layer – PHY):
  این لایه به رادیوی فیزیکی اشاره داره که برای ارتباط و مدوله/دمدوله کردن داده استفاده میشه. این لایه تو همون باند فرکانسی ISM (طیف ۲.۴ گیگاهرتز) کار میکنه.
• لایه پیوند (Link Layer):
  این لایه با لایه فیزیکی (رادیو) در ارتباطه و برای لایه‌های بالاتر یک راه برای تعامل با رادیو فراهم میکنه. این لایه مسئول مدیریت وضعیت رادیو و همچنین الزامات زمانی برای پایبندی به مشخصات فنی بلوتوث کم‌مصرفه.
• رابط کنترلر میزبان (Host Controller Interface – HCI):
  لایه HCI یک پروتکل استاندارد هست که توسط مشخصات بلوتوtoh تعریف شده و به لایه میزبان (Host) اجازه میده با لایه کنترلر (Controller) ارتباط برقرار کنه. این لایه‌ها میتونن روی چیپ‌های جداگانه باشن یا هر دو روی یک چیپ باشن.
• پروتکل کنترل و تطبیق پیوند منطقی (L2CAP):
  لایه L2CAP مثل یک لایه تقسیم‌کننده پروتکل عمل میکنه. این لایه چندین پروتکل رو از لایه‌های بالاتر میگیره و اونها رو تو بسته‌های استاندارد BLE قرار میده. بعد این بسته‌ها رو به لایه‌های پایین‌تر میفرسته.
• پروتکل ویژگی (Attribute Protocol – ATT):
  پروتکل ATT تعریف میکنه که یک سرور چطور داده‌هاش رو در اختیار یک کلاینت قرار میده و این داده‌ها چطور ساختاردهی شدن.
• پروفایل ویژگی عمومی (Generic Attribute Profile – GATT):
  این لایه یکی از مهم‌ترین لایه‌ها برای توسعه‌دهنده‌هاست. GATT فرمت داده‌ای که توسط یک دستگاه BLE ارائه میشه رو تعریف میکنه. همچنین رویه‌های لازم برای دسترسی به این داده‌ها رو مشخص میکنه.
  
  تو GATT دو تا نقش اصلی وجود داره: سرور (Server) و کلاینت (Client).
  
  
  
  • سرور: دستگاهیه که داده‌هایی که کنترل میکنه یا در اختیار داره رو به بقیه نشون میده.
  
  
  • کلاینت: دستگاهیه که با سرور ارتباط برقرار میکنه تا داده‌های سرور رو بخونه یا رفتارش رو کنترل کنه.
  
  

  یادتون باشه که یک دستگاه BLE میتونه همزمان هم سرور باشه و هم کلاینت.

  برای فهمیدن GATT، باید با دو مفهوم کلیدی آشنا بشید: سرویس‌ها (Services) و مشخصه‌ها (Characteristics).

  
  
  • سرویس (Service): یک گروه از یک یا چند «ویژگی» (Attribute) هست. هدفش اینه که ویژگی‌های مرتبط که یک کارکرد خاص رو روی سرور انجام میدن، کنار هم جمع کنه. مثلا، «سرویس باتری» که توسط خود گروه SIG تعریف شده، شامل یک مشخصه به اسم «سطح باتری» هست.
  
  
  • مشخصه (Characteristic): همیشه بخشی از یک سرویسه و یک تیکه از اطلاعات یا داده رو نشون میده که سرور میخواد در اختیار کلاینت بذاره. مثلا، «مشخصه سطح باتری» میزان شارژ باقی‌مونده باتری رو نشون میده که کلاینت میتونه اون رو بخونه.
  
  

  در BLE، شش نوع عملیات روی مشخصه‌ها وجود داره:

  • دستورها (Commands)
  • درخواست‌ها (Requests)
  • پاسخ‌ها (Responses)
  • اعلان‌ها (Notifications)
  • نشانه‌ها (Indications)
  • تاییدها (Confirmations)
• پروفایل دسترسی عمومی (Generic Access Profile – GAP):
  این هم یکی دیگه از لایه‌های بسیار مهم برای توسعه‌دهنده‌هاست. GAP یک چارچوب تعریف میکنه که میگه دستگاه‌های BLE چطور با هم تعامل کنن. این شامل موارد زیر میشه:
  
  
  
  • نقش‌های دستگاه‌های BLE
  
  
  • تبلیغات (Advertising) – (پخش همگانی، کشف، پارامترهای تبلیغ، داده تبلیغ)
  
  
  • برقراری ارتباط (Connection) – (شروع ارتباط، پذیرش ارتباط، پارامترهای ارتباط)
  
  
  • امنیت
  
  
  
  

  نقش‌های مختلف یک دستگاه BLE اینها هستن:

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

  یادتون باشه که یک دستگاه میتونه همزمان چند تا نقش داشته باشه. مثلا گوشی هوشمند شما میتونه در نقش مرکزی باشه وقتی به ساعت هوشمندتون وصله، و همزمان در نقش پیرامونی باشه وقتی به کامپیوترتون وصله.

  
  

ردیابی موقعیت با BLE

یکی از جذاب‌ترین کاربردهای BLE، استفاده از اون برای ردیابی موقعیت در فضاهای داخلیه، جایی که GPS کار نمیکنه. این کار معمولا با دو روش انجام میشه: استفاده از سنسورها یا استفاده از بیکن‌ها.

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

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

آینده موقعیت‌یابی با BLE: با معرفی بلوتوث ۵.۱ و قابلیت جدیدش به اسم جهت‌یابی (Direction Finding)، قراره دقت موقعیت‌یابی با BLE به سطح زیر یک متر و حتی سانتی‌متر برسه. این قابلیت جدید به دستگاه‌ها اجازه میده نه تنها قدرت سیگنال، بلکه زاویه رسیدن سیگنال (Angle of Arrival – AoA) رو هم محاسبه کنن که باعث میشه موقعیت‌یابی خیلی دقیق‌تر بشه.

پرسش و پاسخ‌های رایج در مورد BLE

• سوال ۱: پس BLE همون بلوتوث معمولیه؟
  نه. با اینکه هر دو زیرمجموعه استاندارد بلوتوث هستن، اما دو تا پروتکل جدا و ناسازگار با هم هستن. بلوتوث کلاسیک برای انتقال مداوم داده مثل صدا طراحی شده و مصرف انرژی بالایی داره. BLE برای انتقال‌های کوتاه و کم‌حجم داده طراحی شده و مصرف انرژیش فوق‌العاده پایینه.
• سوال ۲: چرا BLE برای اینترنت اشیا (IoT) اینقدر مهمه؟
  دو دلیل اصلی وجود داره: اول، مصرف انرژی خیلی پایینش که باعث میشه دستگاه‌های باتری‌خور بتونن برای ماه‌ها یا سال‌ها کار کنن. دوم، برای اکثر کاربردهای IoT مثل سنسورها، فقط لازمه حجم کمی از داده (مثلا فقط دمای فعلی) به صورت دوره‌ای ارسال بشه که BLE برای این کار کاملا بهینه است.
• سوال ۳: BLE به زبان ساده چطور کار میکنه؟
  سه مرحله اصلی داره:
  1. تبلیغ (Advertising): دستگاه‌های پیرامونی (مثل یک سنسور) بسته‌های کوچیک داده رو به صورت مداوم پخش میکنن تا حضور خودشون رو اعلام کنن.
  2. اسکن (Scanning): دستگاه‌های مرکزی (مثل یک گوشی) به این بسته‌های تبلیغاتی گوش میدن تا دستگاه‌های اطراف رو پیدا کنن.
  3. اتصال (Connection): وقتی دستگاه مرکزی یک دستگاه پیرامونی رو پیدا کرد، میتونه بهش درخواست اتصال بده و بعد از اون، دو دستگاه میتونن داده رو به صورت دوطرفه رد و بدل کنن.
• سوال ۴: نقش‌های مختلف دستگاه‌های BLE چی هستن؟
  چهار نقش اصلی وجود داره:
  • پیرامونی (Peripheral): دستگاهی که تبلیغ میکنه و منتظر اتصال میمونه (مثل ساعت هوشمند).
  • مرکزی (Central): دستگاهی که اسکن میکنه و اتصال رو برقرار میکنه (مثل گوشی موبایل).
  • پخش‌کننده (Broadcaster): دستگاهی که فقط تبلیغ میکنه و قابل اتصال نیست (مثل بیکن‌ها).
  • ناظر (Observer): دستگاهی که فقط به تبلیغات گوش میده و وصل نمیشه.
• سوال ۵: چند تا مثال واقعی از کاربرد BLE میزنید؟
  حتما. ردیاب‌های تناسب اندام (مثل فیت‌بیت)، ساعت‌های هوشمند، تجهیزات پزشکی بی‌سیم (مثل مانیتورهای قند خون)، قفل‌های هوشمند در خانه، لامپ‌های هوشمند، تگ‌های پیدا کردن وسایل (مثل ایرتگ)، و سیستم‌های موقعیت‌یاب داخلی در فروشگاه‌ها و فرودگاه‌ها، همگی از BLE استفاده میکنن.

دیتابیس یعنی چی؟

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

مدل رابطه‌ای یا Relational یعنی چی؟

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

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

SQL چیه؟

خب، حالا که یه انبار مرتب داریم، چطوری باهاش حرف بزنیم؟ چطوری بهش بگیم «لیست همه کاربرایی که اهل تهران هستن رو بهم بده»؟ اینجا SQL وارد میشه. اس‌کیو‌ال (SQL) که مخفف Structured Query Language یا «زبان پرس‌وجوی ساختاریافته» هست، یه زبان برنامه‌نویسیه که برای بازیابی، آپدیت، حذف و کلا مدیریت داده‌ها توی دیتابیس‌های رابطه‌ای استفاده میشه. مای‌اس‌کیو‌ال هم اسمش رو از همین SQL گرفته و از این زبان برای مدیریت و پرس‌وجو از داده‌ها استفاده میکنه.

تلفظ درستش چیه؟

تلفظ رسمی این اسم «مای‌اس‌کیو‌ال» (My S-Q-L) هست، ولی خیلی‌ها بهش «مای‌سیکوئل» (My Sequel) هم میگن که یه تلفظ رایجه.

پس به طور خلاصه، مای‌اس‌کیو‌ال یه سیستم مدیریت دیتابیسه که داده‌ها رو توی جدول‌های منظم نگهداری میکنه و با استفاده از زبان SQL به ما اجازه میده با این داده‌ها کار کنیم.

بخش دوم: چرا اینقدر طرفدار داره و کجاها به کار میاد؟

محبوبیت مای‌اس‌کیو‌ال اتفاقی نیست. چند تا دلیل کلیدی وجود داره که باعث شده این سیستم بعد از حدود ۳۰ سال هنوزم یکی از اولین انتخاب‌ها برای خیلی از پروژه‌ها باشه.

۱. اوپن سورس بودن و جامعه بزرگ

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

این نرم‌افزار تحت مجوزی به اسم GNU General Public License (GPL) منتشر میشه که یه سری قوانین مشخص داره. البته اگه شرکتی نخواد از این مجوز استفاده کنه یا بخواد کد مای‌اس‌کیو‌ال رو توی یه محصول تجاری قرار بده، میتونه نسخه تجاریش رو بخره.

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

۲. کارایی، پایداری و مقیاس‌پذیری بالا

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

• مقیاس‌پذیری (Scalability): یکی از ویژگی‌های مهم مای‌اس‌کیو‌ال، معماری تکثیر (Replication) داخلیشه. این ویژگی به شرکت‌های بزرگی مثل فیسبوک اجازه میده که اپلیکیشن‌هاشون رو برای پشتیبانی از میلیاردها کاربر مقیاس‌پذیر کنن. یعنی وقتی کسب‌وکار رشد میکنه و تعداد کاربرها زیاد میشه، مای‌اس‌کیو‌ال هم میتونه پا به پاش بزرگ بشه.
• تراکنش‌های ACID: برنامه‌نویس‌ها روی دو تا قابلیت کلیدی مای‌اس‌کیو‌ال خیلی حساب میکنن: یکی همین مقیاس‌پذیری و اون یکی پشتیبانی از تراکنش‌های ACID. این کلمه مخفف چهارتا خاصیته: «اتمی بودن (Atomicity)، سازگاری (Consistency)، ایزوله‌سازی (Isolation) و دوام (Durability)». این چهارتا ویژگی تضمین میکنن که تراکنش‌های دیتابیس به شکل قابل اعتماد و دقیقی پردازش بشن. با این قابلیت، مای‌اس‌کیو‌ال میتونه تضمین کنه که همه تغییرات داده‌ها به شکلی پایدار و مطمئن انجام میشن، حتی اگه وسط کار سیستم به مشکل بخوره یا برق بره.

۳. سادگی در استفاده و سازگاری گسترده

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

این سیستم با پلتفرم‌های تکنولوژی و زبان‌های برنامه‌نویسی مختلفی مثل جاوا، پایتون، پی‌اچ‌پی (PHP) و جاوااسکریپت سازگاری بالایی داره. یه نکته جالب دیگه اینه که از تکثیر (replication) بین نسخه‌های مختلف هم پشتیبانی میکنه. یعنی یه اپلیکیشن که با مای‌اس‌کیو‌ال نسخه ۵.۷ کار میکنه، میتونه به راحتی به نسخه ۸.۰ تکثیر بشه.

علاوه بر این، مای‌اس‌کیو‌ال انعطاف‌پذیری خوبی برای توسعه اپلیکیشن‌های دیتابیس سنتی (SQL) و اپلیکیشن‌های بدون اسکیما (NoSQL) داره. این یعنی برنامه‌نویس‌ها میتونن داده‌های رابطه‌ای و اسناد JSON رو توی یک دیتابیس و یک اپلیکیشن با هم ترکیب کنن.

۴. مقرون به صرفه بودن

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

کاربردهای واقعی مای‌اس‌کیو‌ال

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

• وب‌سایت‌های فروشگاهی (Ecommerce): برای مدیریت اطلاعات مشتریان و محصولات.
• سیستم‌های مدیریت محتوا (CMS): برای ارائه محتوای وب‌سایت‌ها.
• اپلیکیشن‌های مالی: برای ردیابی امن تراکنش‌ها و داده‌های مالی.
• شبکه‌های اجتماعی: برای ذخیره پروفایل کاربران و تعاملاتشون.

بخش سوم: سرور چیه و چرا مای‌اس‌کیو‌ال بهش نیاز داره؟

خب، حالا که فهمیدیم مای‌اس‌کیو‌ال چیه، بیاید در مورد یه مفهوم کلیدی دیگه حرف بزنیم: «سرور». شاید شنیده باشید که میگن «سرور مای‌اس‌کیو‌ال». این یعنی چی؟

مفهوم موتور (Engine) دیتابیس

هر سیستم مدیریت دیتابیس رابطه‌ای (RDBMS) یه چیزی به اسم «موتور» (Engine) داره. این موتور در واقع اون بخشیه که کوئری‌های شما رو تفسیر میکنه و نتایج رو برمیگردونه. بدون این موتور، دیتابیس شما چیزی بیشتر از یه فضای ذخیره‌سازی ساده نیست. به این موتور به طور کلی میگن «سرور».

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

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

شاید بپرسید چرا اینقدر پیچیده‌اش کنیم؟ چرا داده‌ها رو توی یه فایل متنی ساده نریزیم؟ خب، میتونید این کار رو بکنید. میتونید داده‌هاتون رو سریالایز کنید و توی یه فایل متنی ذخیره کنید. ولی وقتی این کار رو میکنید، تمام مسئولیت ذخیره‌سازی و مدیریت داده‌ها میفته گردن کد خودتون.

یه مفهوم کلیدی توی دیتابیس‌های مبتنی بر SQL، همون اصول ACID هست که قبلا در موردش حرف زدیم. سرور دیتابیس این توانایی رو داره که چندین کوئری همزمان رو مدیریت و صف‌بندی کنه و در عین حال، این اصول رو حفظ کنه. دیتابیس‌ها برای کارایی بالا به حافظه (RAM) و پردازنده (CPU) زیادی نیاز دارن و باید به فضای ذخیره‌سازی با تاخیر کم (low-latency) دسترسی داشته باشن.

مدل کلاینت/سرور

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

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

چرا سرور رو روی یه سخت‌افزار جدا میذارن؟

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

1. منابع سیستم: دیتابیس‌ها به شدت به ورودی/خروجی (IO) وابسته‌ان. اگه حافظه کافی برای بارگذاری همه چیز توی رم وجود نداشته باشه، باید از فایل سیستم استفاده بشه. ممکنه روی کامپیوتر شما منابع کافی برای اجرای همزمان دیتابیس و برنامه اصلی با کارایی مطلوب وجود نداشته باشه.
2. امنیت: نسخه‌های تجاری و سازمانی موتورهای دیتابیس برای رسیدن به کارایی بالاتر، نیاز دارن که به سطح پایین‌تری از سیستم دسترسی داشته باشن و امتیازات امنیتی بیشتری بگیرن. این موضوع میتونه یه ریسک امنیتی بزرگ برای داده‌های شرکتی باشه. به همین دلیل، موتور دیتابیس معمولا روی یه سرور اختصاصی با یه زمینه امنیتی خاص میزبانی میشه که کاربرای عادی اصلا اجازه لاگین به کنسولش رو ندارن. چون این سرورها میتونن آسیب‌پذیر باشن، معمولا از فایروال‌ها برای مقاوم‌سازیشون در برابر حملات استفاده میشه.
3. مدیریت: مدیریت همه این موارد روی یه کامپیوتر شخصی یا ایستگاه کاری میتونه خیلی دردسرساز باشه.

بحث مرکزی‌سازی: آیا همیشه خوبه که یه سرور دیتابیس برای همه سرویس‌ها داشته باشیم؟

یه سوالی که برای خیلی از مدیران سیستم پیش میاد اینه که آیا بهتره یه ماشین مجازی (VM) یا سرور اختصاصی فقط برای مای‌اس‌کیو‌ال داشته باشیم و بقیه سرویس‌ها (مثل Nextcloud و…) به اون وصل بشن، یا اینکه برای هر سرویس، یه سرور مای‌اس‌کیو‌ال جدا روی همون ماشین مجازی خودش نصب کنیم؟

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

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

خب، حالا که با مفاهیم اولیه آشنا شدیم، بیاید ببینیم چطوری میشه مای‌اس‌کیو‌ال رو دانلود و نصب کرد. مای‌اس‌کیو‌ال در چند نسخه مختلف ارائه میشه که هر کدوم برای یه سری کاربردها مناسبن.

نسخه‌های مختلف مای‌اس‌کیو‌ال

• MySQL Enterprise Edition: این نسخه جامع‌ترین مجموعه از ویژگی‌های پیشرفته، ابزارهای مدیریتی و پشتیبانی فنی رو برای مای‌اس‌کیو‌ال شامل میشه. هدفش رسیدن به بالاترین سطح از مقیاس‌پذیری، امنیت، قابلیت اطمینان و آپ‌تایم (uptime) هست.
• MySQL NDB Cluster CGE: این نسخه یه دیتابیس تراکنشی اوپن سورس و real-time هست که برای دسترسی سریع و همیشه روشن به داده‌ها در شرایطی با توان عملیاتی بالا (high throughput) طراحی شده. این نسخه شامل MySQL NDB Cluster Manager و همه چیزهایی که در نسخه Enterprise Edition هست هم میشه.
• MySQL Community (GPL) Downloads: این همون نسخه اوپن سورس و رایگان مای‌اس‌کیو‌ال هست که تحت مجوز GPL منتشر میشه و اکثر افراد از این نسخه برای پروژه‌هاشون استفاده میکنن.
• MySQL برای ISVها، OEMها و VARها: جالبه بدونید که بیش از ۲۰۰۰ تا ISV (فروشنده نرم‌افزار مستقل)، OEM (سازنده تجهیزات اصلی) و VAR (نماینده فروش با ارزش افزوده) به مای‌اس‌کیو‌ال به عنوان دیتابیس تعبیه شده (embedded) در محصولاتشون اعتماد میکنن. این کار بهشون کمک میکنه تا اپلیکیشن‌ها، سخت‌افزارها و دستگاه‌هاشون رو رقابتی‌تر کنن، سریع‌تر به بازار عرضه کنن و هزینه تمام شده کالاهاشون رو کاهش بدن.

راهنمای نصب با MySQL Installer

برای نصب مای‌اس‌کیو‌ال روی ویندوز، یه ابزار خیلی راحت به اسم MySQL Installer وجود داره. این ابزار یه تجربه نصب جادوگر-محور (wizard-based) رو برای تمام نیازهای نرم‌افزاری مای‌اس‌کیو‌ال شما فراهم میکنه.

• نسخه 8.0.43: اینستالرهای نسخه‌های ۵.۷ تا ۸.۰ شامل آخرین ورژن‌های محصولات مای‌اس‌کیو‌ال هستن.
• نکته مهم در مورد نسخه‌های جدید: توجه داشته باشید که سری ۸.۰ آخرین سری هست که MySQL Installer داره. از نسخه ۸.۱ به بعد، باید از فایل MSI یا آرشیو Zip خود محصول مای‌اس‌کیو‌ال برای نصب استفاده کنید. همچنین، سرور مای‌اس‌کیو‌ال نسخه ۸.۱ و بالاتر، ابزاری به اسم MySQL Configurator رو هم همراه خودش داره که به پیکربندی سرور کمک میکنه.

کدوم فایل رو انتخاب کنیم؟

وقتی میخواید اینستالر رو دانلود کنید، دو تا گزینه اصلی دارید:

1. mysql-installer-web-community: اگه موقع اجرای اینستالر به اینترنت وصل هستید، این فایل رو انتخاب کنید. این نسخه حجم کمتری داره و فایل‌های مورد نیاز رو موقع نصب دانلود میکنه.
2. mysql-installer-community: اگه موقع اجرای اینستالر به اینترنت دسترسی ندارید، این فایل رو انتخاب کنید. این نسخه همه فایل‌های لازم رو داخل خودش داره و حجمش بیشتره.

یه نکته فنی هم اینه که خود برنامه MySQL Installer ۳۲ بیتی هست، ولی میتونه هم باینری‌های ۳۲ بیتی و هم ۶۴ بیتی رو نصب کنه.

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

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

مشخصات دیتابیس مورد نظر:

• نسخه مای‌اس‌کیو‌ال: ۸.۴
• اندازه دیتابیس: حدود ۱ ترابایت، پخش شده در حدود ۱۵۰ تا جدول.
• مشخصات جداول: طولانی‌ترین جدول حدود ۱۰ میلیارد ردیف داره و میانگین طول جداول ۱۰۰ میلیون ردیفه.
• نوع کاربری:
  • نوشتن (Writes) خیلی کم: به جز بارگذاری اولیه، آپدیت‌ها به صورت ساعتی یا روزانه توسط خزنده‌های وب (crawlers) مختلف انجام میشه و فقط یه کاربر مینویسه.
  • کوئری‌های (Queries) کم ولی پیچیده: کوئری‌ها شامل تعداد زیادی JOIN و WHERE هستن و فقط یه کاربر برای گزارش‌گیری روزانه و تحلیل‌های موردی ازشون استفاده میکنه.

سخت‌افزار جدید پیشنهادی:

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

• پردازنده (CPU): AMD Ryzen 9 7900X
  • چرا این انتخاب شده؟ بر اساس نوع کاربری که کوئری‌های پیچیده ولی تکی داره، عملکرد تک‌هسته‌ای (single core performance) خیلی کلیدیه. این پردازنده میتونه تا فرکانس ۵.۶ گیگاهرتز بوست بشه که برای این کار عالیه.
• حافظه (RAM): 4x 32GB DDR5 ECC UDIMM 2Rx8 4800
  • چرا ECC؟ عبارت ECC مخفف Error-Correcting Code هست. این نوع رم میتونه خطاهای کوچیک حافظه رو به صورت خودکار شناسایی و تصحیح کنه. برای یه سرور دیتابیس که پایداری داده‌ها حیاتیه، استفاده از رم ECC یه تصمیم هوشمندانه است.
• مادربورد (Motherboard): AsRock Rack B650D4U-2L2T/BCM
  
• فضای ذخیره‌سازی (Storage):
  • درایوهای اصلی: 4x Samsung PM9A3 1920GB 2.5″ in a ZFS RAID 10
    
  • کش نوشتن (SLOG): 1x Intel Optane P4800X as ZFS SLOG vdev
    
• سیستم عامل (OS): Debian 12
  

مقایسه با سخت‌افزار فعلی:

سخت‌افزار فعلی این کاربر یه Intel Xeon E3-1230 v6 با ۳۲ گیگابایت رم غیر-ECC و یه SSD معمولی بوده. ارتقای پیشنهادی یه جهش عظیم در عملکرد محسوب میشه.

یه سوال مهم: Ryzen یا EPYC؟

کاربر یه سوال خوب هم پرسیده: آیا بهتر نیست به جای این سیستم، یه سرور مبتنی بر پردازنده استفاده شده EPYC (مثلا مدل 7F52) ببندم؟

• مزایای EPYC: این پردازنده ۴ برابر کش L3 بیشتری داره و از رم بیشتری هم پشتیبانی میکنه.
• معایب EPYC: فرکانس بوستش فقط تا ۳.۹ گیگاهرتز میرسه، در حالی که Ryzen تا ۵.۶ گیگاهرتز میره.

اینجا یه بده‌بستان (trade-off) وجود داره. برای کاربری خاص این شخص که عملکرد تک‌هسته‌ای مهمه، Ryzen 7900X با فرکانس بالاترش احتمالا انتخاب بهتریه. اما برای سناریوهایی با تعداد کاربران همزمان زیاد، EPYC با کش و هسته‌های بیشترش میتونه برنده باشه.

بخش ششم: مدیریت مای‌اس‌کیو‌ال با وب‌مین (Webmin) – یه راهنمای کامل

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

شروع کار با ماژول مای‌اس‌کیو‌ال در وب‌مین

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

ساختن یه دیتابیس جدید

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

1. روی لینک «Create a new database» کلیک کنید.
2. یه اسم برای دیتابیس جدیدتون توی فیلد «Database name» وارد کنید. اسم باید فقط شامل حروف و اعداد باشه و فاصله نداشته باشه.
3. روی دکمه «Create» کلیک کنید. به همین راحتی!

ساختن یه جدول جدید

حالا که دیتابیس رو داریم، باید توش جدول بسازیم.

1. روی آیکون دیتابیسی که ساختید کلیک کنید.
2. تعداد فیلدهایی (ستون‌هایی) که میخواید جدولتون داشته باشه رو وارد کنید و روی دکمه «Create a new table» کلیک کنید.
3. یه اسم برای جدولتون توی فیلد «Table name» وارد کنید.
4. نوع جدول (Table type): اینجا میتونید نوع موتور ذخیره‌سازی جدول رو انتخاب کنید. رایج‌ترین‌ها اینان:
   
5. تعریف فیلدها (Initial fields):
   
6. وقتی همه فیلدها رو تعریف کردید، روی دکمه «Create» کلیک کنید.

مشاهده و ویرایش محتوای جدول

اگه میخواید داده‌های داخل یه جدول رو ببینید، ویرایش کنید، یا ردیف جدیدی اضافه کنید:

1. روی آیکون دیتابیس و بعد روی آیکون جدول مورد نظرتون کلیک کنید.
2. روی دکمه «View Data» کلیک کنید.
3. لیستی از ردیف‌های جدول به شما نشون داده میشه. اگه جدول شما کلید اصلی داشته باشه، میتونید:
   

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

پشتیبان‌گیری (Backup) و بازیابی (Restore)

بکاپ گرفتن از دیتابیس‌های مهم یکی از حیاتی‌ترین کارهاست. وب‌مین این کار رو خیلی ساده کرده.

برای ساختن بکاپ:

1. وارد صفحه دیتابیس مورد نظر بشید.
2. روی دکمه «Backup Database» کلیک کنید.
3. توی فیلد «Backup to file»، آدرس فایلی که میخواید بکاپ توش ذخیره بشه رو وارد کنید (مثلا /tmp/backup.sql).
4. یه گزینه مهم به اسم «Add drop table statements to backup?» وجود داره. اگه این رو روی «Yes» بذارید، موقع بازیابی بکاپ، اگه جدولی با همون اسم از قبل وجود داشته باشه، اول حذف میشه و بعد داده‌های جدید جایگزین میشن. این برای بکاپ‌های معمولی خوبه. اگه روی «No» بذارید، داده‌های بکاپ به داده‌های موجود اضافه میشن.
5. روی «Backup Now» کلیک کنید.

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

برای بازیابی بکاپ:

1. وارد صفحه دیتابیسی بشید که میخواید بکاپ رو توش بازیابی کنید.
2. روی دکمه «Execute SQL» کلیک کنید.
3. به بخش «Select SQL commands file to execute on database» برید.
4. فایل بکاپتون رو از روی سرور یا کامپیوتر خودتون انتخاب کنید.
5. روی «Execute» کلیک کنید.

مدیریت کاربران و دسترسی‌ها (Permissions)

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

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

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

حالا که با نسخه سنتی مای‌اس‌کیو‌ال آشنا شدیم، بیاید یه نگاهی به آینده و نسخه‌های ابریش بندازیم. اوراکل یه سرویس ابری خیلی قدرتمند برای مای‌اس‌کیو‌ال به اسم HeatWave ارائه میده.

HeatWave چیه؟

HeatWave در واقع یه شتاب‌دهنده کوئری درون-حافظه‌ای (in-memory) برای دیتابیس مای‌اس‌کیو‌ال هست. این تنها سرویس دیتابیس ابری مای‌اس‌کیو‌اله که چنین شتاب‌دهنده‌ای رو ارائه میده و میتونه تراکنش‌ها (transactions) رو با تحلیل‌های همزمان (real-time analytics) ترکیب کنه.

این یعنی چی؟ یعنی دیگه نیازی به فرآیندهای پیچیده، زمان‌بر و پرهزینه ETL (Extract, Transform, Load) برای انتقال داده‌ها به یه دیتابیس تحلیلی جداگونه نیست. شما میتونید روی همون داده‌های تراکنشی خودتون، به صورت همزمان تحلیل‌های سنگین انجام بدید. این کار باعث افزایش فوق‌العاده زیاد عملکرد مای‌اس‌کیو‌ال برای کارهای تحلیلی و ترکیبی میشه.

ویژگی‌های پیشرفته HeatWave:

• HeatWave AutoML: به توسعه‌دهنده‌ها و تحلیل‌گرای داده اجازه میده که مدل‌های یادگیری ماشین (Machine Learning) رو به صورت کاملا خودکار داخل HeatWave MySQL بسازن، آموزش بدن، پیاده‌سازی کنن و خروجی‌هاشون رو توضیح بدن.
• HeatWave GenAI: کاربران میتونن از هوش مصنوعی مولد (Generative AI) یکپارچه و خودکار هم استفاده کنن.
• HeatWave Autopilot: این ویژگی با استفاده از اتوماسیون مبتنی بر یادگیری ماشین، به صورت خودکار به بهبود عملکرد مای‌اس‌کیو‌ال و کاهش هزینه‌ها کمک میکنه، بدون اینکه به تخصص در زمینه تیونینگ دیتابیس نیاز باشه.

این سرویس روی پلتفرم‌های ابری مختلفی مثل Oracle Cloud Infrastructure (OCI)، Amazon Web Services (AWS) و Microsoft Azure در دسترسه.

بخش هشتم: وقتی همه چیز خراب میشه: راهنمای عیب‌یابی (Troubleshooting)

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

چطور بفهمیم سرور مای‌اس‌کیو‌ال کار میکنه یا نه؟

گاهی وقتا یه برنامه نمیتونه به دیتابیس وصل بشه و خطای «Unable to connect to MySQL server» میده. اولین قدم اینه که ببینیم اصلا سرور مای‌اس‌کیو‌ال در حال اجرا هست یا نه. چند تا راه برای این کار توی ترمینال لینوکس وجود داره:

• sudo service mysql status یا sudo service mysqld status
• ps aux | grep mysql (این دستور همه پروسه‌هایی که کلمه mysql توشون هست رو نشون میده)
• lsof -i :3306 (این دستور چک میکنه که آیا پروسه‌ای به پورت پیش‌فرض مای‌اس‌کیو‌ال یعنی ۳۳۰۶ گوش میده یا نه)

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

اگه سرور در حال اجرا بود، مشکل میتونه از جای دیگه باشه. مثلا:

• خطای احراز هویت: نام کاربری یا پسورد اشتباهه.
• اسم اشتباه دیتابیس: اسم دیتابیسی که میخواید بهش وصل بشید رو اشتباه وارد کردید.
• فایروال: ممکنه فایروال سرور یا کلاینت، اتصال به پورت ۳۳۰۶ رو مسدود کرده باشه.

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

mysql -u <username> -p <database-name>

یه مشکل رایج در XAMPP (روی مک)

یه مشکل رایج که برای توسعه‌دهنده‌ها پیش میاد، مخصوصا اونایی که از پکیج‌هایی مثل XAMPP استفاده میکنن، اینه که مای‌اس‌کیو‌ال بعد از ری‌استارت کردن کامپیوتر دیگه روشن نمیشه. توی پنل مدیریت XAMPP چراغش قرمز میمونه و وقتی سعی میکنید وارد phpMyAdmin بشید، با خطای #2002 - No such file or directory مواجه میشید.

این مشکل معمولا به این دلیله که یه پروسه قدیمی از مای‌اس‌کیو‌ال هنوز توی پس‌زمینه در حال اجراست و جلوی اجرا شدن پروسه جدید رو میگیره. راه حلش اینه که اون پروسه قدیمی رو به صورت دستی از بین ببرید (kill کنید).

راه حل قدم به قدم در ترمینال مک:

1. ترمینال رو باز کنید و دستور sudo su رو تایپ کنید و پسوردتون رو وارد کنید تا دسترسی روت بگیرید.
2. دستور ps aux | grep mysql رو وارد کنید. این دستور لیستی از پروسه‌های مربوط به مای‌اس‌کیو‌ال رو به شما نشون میده.
3. توی لیست، باید شناسه پروسه (process ID یا PID) رو پیدا کنید. این یه عدد هست که معمولا در ستون دوم قرار داره.
4. حالا با دستور kill -9 {process id} اون پروسه رو از بین ببرید. مثلا: kill -9 739.
5. حالا به پنل XAMPP برگردید و دوباره سعی کنید مای‌اس‌کیو‌ال رو استارت کنید. به احتمال زیاد مشکل حل میشه.

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

سوال: مای‌اس‌کیو‌ال چیست و چرا استفاده میشود؟

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

سوال: تفاوت بین SQL و مای‌اس‌کیو‌ال چیست؟

جواب: SQL یه زبان برنامه‌نویسیه که برای مدیریت و تحلیل داده‌های ذخیره شده در دیتابیس‌ها طراحی شده. مای‌اس‌کیو‌ال یه سیستم مدیریت دیتابیسه که بخشی از اسمش رو از SQL گرفته و از زبان SQL برای مدیریت داده‌ها در دیتابیس‌ها استفاده میکنه.

سوال: آیا نسخه ابری از مای‌اس‌کیو‌ال وجود دارد؟

جواب: بله. HeatWave MySQL یه سرویس دیتابیس کاملا مدیریت شده است و تنها سرویس ابریه که بر اساس MySQL Enterprise Edition ساخته شده. این سرویس عملکرد کوئری‌های مای‌اس‌کیو‌ال رو به شدت بهبود میده و تحلیل‌های همزمان روی داده‌های تراکنشی رو ممکن میکنه. این سرویس روی OCI، AWS و Microsoft Azure در دسترسه.

سوال: مای‌اس‌کیو‌ال در مقایسه با سایر دیتابیس‌ها چگونه است؟

جواب: مای‌اس‌کیو‌ال یه دیتابیس رابطه‌ای اوپن سورسه. این یعنی داده‌ها رو در ردیف‌ها و ستون‌ها ذخیره میکنه و روابط بین اونها رو در اسکیماها تعریف میکنه. دیتابیس‌های رابطه‌ای محبوب دیگه‌ای هم وجود دارن که اوپن سورس نیستن، مثل Oracle Database. همچنین دیتابیس‌های محبوبی وجود دارن که اصلا رابطه‌ای نیستن. به این‌ها دیتابیس‌های NoSQL میگن، مثل MongoDB.

• پردازش تراکنش آنلاین (OLTP): فکر کنید به خرید و فروش‌های لحظه‌ای توی یه فروشگاه آنلاین یا تراکنش‌های بانکی. این‌ها کارهایی هستن که باید سریع و دقیق انجام بشن.
• انبار داده (DW): تصور کنید یه شرکت میخواد تمام داده‌های فروش چند سال گذشته‌اش رو تحلیل کنه تا ببینه چه محصولاتی بیشتر فروش رفتن. این حجم عظیم از داده‌ها توی انبار داده نگهداری و تحلیل میشه.

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

یه نگاه کوتاه به تاریخچه

داستان اوراکل از سال ۱۹۷۷ شروع شد. لری الیسون به همراه دو تا از دوست‌ها و همکارای سابقش، باب ماینر و اد اوتس، یه شرکت مشاوره به اسم «آزمایشگاه‌های توسعه نرم‌افزار» یا همون SDL رو راه انداختن. این شرکت بعدا به شرکت اوراکل تبدیل شد. SDL اولین نسخه نرم‌افزار اوراکل رو توسعه داد. جالبه بدونید که اسم «اوراکل» از اسم رمز یه پروژه میاد که CIA بودجه‌اش رو تامین میکرد و الیسون قبلا توی شرکت Ampex روی اون کار کرده بود. حتی اولین مشتری اوراکل هم خود CIA بود و بهشون اجازه داد از این اسم رمز برای محصول جدیدشون استفاده کنن.

یه نکته جالب اینه که الیسون میخواست پایگاه داده‌اش با System R شرکت IBM سازگار باشه، اما IBM کدهای خطای نرم‌افزارش رو منتشر نکرد. با این حال، تا سال ۱۹۸۵ اوراکل تبلیغ میکرد که برنامه‌هایی که برای SQL/DS یا DB2 نوشته شدن، بدون هیچ تغییری روی اوراکل هم اجرا میشن.

هیچوقت نسخه‌ای به اسم Oracle v1 وجود نداشت. دلیلش هم این بود که الیسون معتقد بود «هیچکس دلش نمیخواد نسخه ۱ یه محصول رو بخره».

بخش دوم: معماری اوراکل؛ چطور کار میکنه؟

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

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

دو بخش اصلی: پایگاه داده و نمونه (Instance)

1. پایگاه داده: مجموعه‌ای از داده‌هاست که به عنوان یک واحد در نظر گرفته میشن. هدفش هم ذخیره و بازیابی اطلاعات مرتبطه. پایگاه داده یه ساختار فیزیکی و یه ساختار منطقی داره.
2. نمونه (Instance): هر بار که یه پایگاه داده استارت میخوره، یه قسمتی از حافظه به اسم System Global Area (SGA) بهش اختصاص داده میشه و یه سری فرایندهای پس‌زمینه (Background Processes) هم شروع به کار میکنن. به ترکیب این فرایندها و حافظه میگیم یه «نمونه اوراکل».

این دو تا از هم جدا هستن. این جدایی به ما اجازه میده که نحوه ذخیره‌سازی فیزیکی داده‌ها رو بدون اینکه روی دسترسی به ساختارهای منطقی تاثیری بذاره، مدیریت کنیم.

بخش سوم: ساختار فیزیکی؛ فایل‌های واقعی روی دیسک

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

1. فایل‌های داده (Datafiles): هر پایگاه داده اوراکل حداقل یه فایل داده داره. تمام داده‌های پایگاه داده، مثل داده‌های جدول‌ها و ایندکس‌ها، به صورت فیزیکی توی این فایل‌ها ذخیره میشن. ویژگی‌های این فایل‌ها اینه که میتونن به یه پایگاه داده تعلق داشته باشن، اندازه‌شون میتونه به صورت خودکار زیاد بشه و میشه اونها رو به صورت آنلاین (در دسترس) یا آفلاین (غیرقابل دسترس) قرار داد. وقتی یه کاربر اطلاعاتی رو میخواد، اگه اون اطلاعات توی حافظه موقت (Cache) نباشه، از روی این فایل‌ها خونده و در حافظه ذخیره میشه. برای بالا بردن عملکرد، داده‌های جدید یا تغییر کرده فورا روی دیسک نوشته نمیشن، بلکه توی حافظه جمع میشن و بعدا به صورت یکجا توسط یه فرایند پس‌زمینه به اسم DBWn روی فایل‌ها نوشته میشن.
2. فایل‌های لاگ دوباره‌کاری (Redo Log Files): هر پایگاه داده اوراکل حداقل دو تا از این فایل‌ها داره. به مجموعه این فایل‌ها میگیم Redo Log. کار اصلی Redo Log اینه که تمام تغییراتی که روی داده‌ها اعمال میشه رو ثبت کنه. اگه یه مشکلی پیش بیاد (مثلا برق بره) و داده‌های تغییر کرده روی فایل‌های داده نوشته نشن، میشه از روی این فایل‌ها تغییرات رو بازیابی کرد تا هیچ کاری از دست نره. این فایل‌ها برای محافظت از پایگاه داده در برابر خرابی خیلی حیاتی هستن. اوراکل حتی اجازه میده چند نسخه از این فایل‌ها رو روی دیسک‌های مختلف داشته باشید تا اگه یکی خراب شد، بقیه سالم بمونن. به فرایند اعمال اطلاعات این فایل‌ها در زمان بازیابی میگن Rolling Forward.
3. فایل‌های کنترل (Control Files): هر پایگاه داده اوراکل یه فایل کنترل داره. این فایل اطلاعات مربوط به ساختار فیزیکی پایگاه داده رو نگه میداره. مثلا:

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

   • اسم پایگاه داده
   • اسم و مکان فایل‌های داده و فایل‌های Redo Log
   • اطلاعات مربوط به زمان ایجاد پایگاه داده

بخش چهارم: ساختار منطقی؛ سازماندهی داده‌ها به شکل مجازی

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

1. فضای جدولی (Tablespaces): یه پایگاه داده به واحدهای ذخیره‌سازی منطقی به اسم Tablespace تقسیم میشه. این فضاها ساختارهای منطقی مرتبط رو با هم گروه‌بندی میکنن. مثلا میشه تمام آبجکت‌های یه اپلیکیشن رو توی یه Tablespace جدا گذاشت تا مدیریت‌شون راحت‌تر بشه. هر پایگاه داده حداقل یه Tablespace به اسم SYSTEM داره. یه Tablespace میتونه آنلاین (در دسترس) یا آفلاین (غیرقابل دسترس) باشه.
2. اسکیما (Schema): اسکیما مجموعه‌ای از آبجکت‌های پایگاه داده هست. آبجکت‌های اسکیما مستقیما به داده‌های پایگاه داده اشاره دارن. این آبجکت‌ها شامل چیزهایی مثل جدول‌ها، ویوها، سکانس‌ها، رویه‌های ذخیره شده، مترادف‌ها، ایندکس‌ها، کلاسترها و لینک‌های پایگاه داده هستن. هیچ رابطه‌ای بین Tablespace و Schema وجود نداره؛ یعنی آبجکت‌های یه اسکیما میتونن توی Tablespaceهای مختلف باشن و یه Tablespace هم میتونه آبجکت‌هایی از اسکیماهای مختلف رو نگه داره.
3. بلوک‌های داده، اکستنت‌ها و سگمنت‌ها (Data Blocks, Extents, and Segments): اوراکل برای کنترل دقیق مصرف فضای دیسک از این سه ساختار منطقی استفاده میکنه.

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

   • بلوک داده (Data Block): کوچک‌ترین واحد ذخیره‌سازی داده در اوراکل هست. هر بلوک داده معادل تعداد مشخصی بایت از فضای فیزیکی دیسک هست. اندازه این بلوک‌ها موقع ساختن پایگاه داده مشخص میشه.
   • اکستنت (Extent): سطح بعدی، اکستنت هست. اکستنت تعداد مشخصی بلوک داده پشت سر هم هست که در یک تخصیص واحد برای ذخیره نوع خاصی از اطلاعات به دست میاد.
   • سگمنت (Segment): سطح بالاتر از اکستنت، سگمنت هست. سگمنت مجموعه‌ای از اکستنت‌هاست که برای یه ساختار منطقی خاص تخصیص داده شده. انواع مختلف سگمنت داریم:
     • سگمنت داده (Data Segment): هر جدول غیرکلاستری یه سگمنت داده داره که تمام داده‌هاش اونجا ذخیره میشه.
     • سگمنت ایندکس (Index Segment): هر ایندکس یه سگمنت ایندکس داره که داده‌هاش رو ذخیره میکنه.
     • سگمنت بازگشتی (Rollback Segment): برای ذخیره موقت اطلاعات «undo» یا بازگشتی استفاده میشه. این اطلاعات برای بازیابی تراکنش‌های ناتمام یا ایجاد نماهای سازگار با خواندن (Read-Consistent Views) به کار میره.
     • سگمنت موقت (Temporary Segment): وقتی یه دستور SQL برای اجرا به یه فضای کاری موقت نیاز داره، اوراکل این سگمنت‌ها رو ایجاد میکنه. بعد از اتمام دستور، این فضا آزاد میشه.

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

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

• جدول (Table): واحد اصلی ذخیره‌سازی داده توی پایگاه داده اوراکل هست. داده‌ها توی سطرها و ستون‌ها ذخیره میشن. هر جدول یه اسم و مجموعه‌ای از ستون‌ها داره. هر ستون هم اسم، نوع داده (مثلا CHAR, DATE, NUMBER) و عرض مشخصی داره.
• ویو (View): یه ویو مثل یه نمایش سفارشی از داده‌های یک یا چند جدول هست. میشه بهش به عنوان یه «کوئری ذخیره شده» هم نگاه کرد. ویوها خودشون داده‌ای رو ذخیره نمیکنن، بلکه داده‌ها رو از جدول‌های پایه‌ای که روی اون‌ها ساخته شدن، میگیرن. از ویوها معمولا برای ساده‌سازی دسترسی به داده، ایجاد امنیت (مثلا فقط ستون‌های خاصی رو نشون بدیم) یا نمایش داده از چند جدول به صورت یکجا استفاده میشه.
• ویوی محقق شده (Materialized View): این نوع ویو، برخلاف ویوهای عادی، نتایج یه کوئری رو توی یه آبجکت جدا ذخیره میکنه. یعنی واقعا فضا اشغال میکنه و داده داره. این کار باعث میشه عملکرد کوئری‌ها، مخصوصا توی محیط‌های انبار داده، خیلی بهتر بشه. اسم دیگه‌اش «اسنپ‌شات» (Snapshot) هست.
• سکانس (Sequence): یه لیست سریالی از اعداد منحصر به فرد تولید میکنه. معمولا برای ستون‌هایی مثل شماره کارمندی یا کد محصول استفاده میشه تا مطمئن باشیم هیچ دو سطری شماره یکسان ندارن. کار برنامه‌نویسی رو خیلی راحت میکنه چون دیگه لازم نیست خودمون نگران تولید اعداد منحصر به فرد باشیم.
• ایندکس (Index): یه ساختار اختیاریه که برای بالا بردن سرعت بازیابی داده‌ها ساخته میشه. دقیقا مثل فهرست آخر یه کتاب که به شما کمک میکنه یه مطلب رو سریع‌تر پیدا کنید، ایندکس هم به اوراکل کمک میکنه سطر مورد نظر رو سریع‌تر پیدا کنه. ایندکس‌ها روی یک یا چند ستون از یه جدول ساخته میشن و بعد از ساخته شدن، به صورت خودکار توسط اوراکل نگهداری و استفاده میشن.
• کلاستر و هش کلاستر (Cluster and Hash Cluster): اینها هم ساختارهای اختیاری برای ذخیره‌سازی داده‌های جدول هستن. کلاسترها گروهی از جدول‌ها هستن که چون ستون‌های مشترکی دارن و معمولا با هم استفاده میشن، به صورت فیزیکی کنار هم ذخیره میشن. این کار زمان دسترسی به دیسک رو کم میکنه.
• مترادف (Synonym): یه اسم مستعار برای یه جدول، ویو، سکانس یا واحد برنامه هست. از مترادف‌ها برای ساده کردن دسترسی به آبجکت‌ها یا مخفی کردن اسم و مالک واقعی اون‌ها استفاده میشه.
• لینک پایگاه داده (Database Link): یه آبجکت نام‌گذاری شده هست که یه «مسیر» از یه پایگاه داده به پایگاه داده دیگه رو توصیف میکنه. این لینک‌ها توی پایگاه داده‌های توزیع شده برای دسترسی به داده‌های روی سرورهای دیگه استفاده میشن.
• واحدهای برنامه (Program Units): این‌ها شامل رویه‌ها (Procedures)، توابع (Functions) و پکیج‌ها (Packages) میشن. این واحدها مجموعه‌ای از دستورات SQL و PL/SQL هستن که به عنوان یه واحد قابل اجرا برای انجام یه کار خاص گروه‌بندی میشن.
  • PL/SQL: این زبان رویه‌ای اوراکل، یه افزونه برای SQL هست. به شما اجازه میده منطق برنامه‌نویسی مثل IF...THEN یا حلقه‌ها رو به دستورات SQL اضافه کنید. استفاده از PL/SQL ذخیره شده توی پایگاه داده باعث میشه ترافیک شبکه کم بشه و امنیت و عملکرد برنامه بالا بره.

بخش ششم: مغز متفکر اوراکل؛ حافظه و فرایندها

اوراکل برای مدیریت و دسترسی به پایگاه داده از ساختارهای حافظه و فرایندها استفاده میکنه. همه این ساختارها توی حافظه اصلی (RAM) کامپیوترهایی که سیستم پایگاه داده رو تشکیل میدن، وجود دارن.

ساختارهای حافظه

1. System Global Area (SGA): این یه ناحیه حافظه مشترکه که داده‌ها و اطلاعات کنترلی یه نمونه اوراکل رو نگه میداره. وقتی یه نمونه استارت میخوره، SGA تخصیص داده میشه و وقتی خاموش میشه، آزاد میشه. کاربرانی که به سرور وصل هستن، داده‌های توی SGA رو به اشتراک میذارن. برای عملکرد بهتر، SGA باید تا جای ممکن بزرگ باشه (البته به شرطی که توی حافظه واقعی جا بشه). SGA خودش چند تا بخش داره:
   • Database Buffer Cache: جدیدترین بلوک‌های داده‌ای که استفاده شدن اینجا ذخیره میشن. چون داده‌های پراستفاده توی حافظه نگه داشته میشن، نیاز به خوندن و نوشتن از روی دیسک (I/O) کم میشه و عملکرد بالا میره.
   • Redo Log Buffer: ورودی‌های Redo Log (لیست تغییرات) قبل از اینکه روی فایل‌های Redo Log نوشته بشن، اینجا ذخیره میشن.
   • Shared Pool: این بخش شامل ساختارهای حافظه مشترک مثل نواحی SQL مشترک هست. هر دستور SQL منحصر به فردی که به پایگاه داده فرستاده میشه، باید پردازش بشه. اطلاعات پردازش اون، مثل درخت تجزیه و نقشه اجرا، توی یه ناحیه SQL مشترک ذخیره میشه. اگه چند اپلیکیشن همون دستور رو اجرا کنن، از همین ناحیه مشترک استفاده میکنن و اینطوری در مصرف حافظه صرفه‌جویی میشه.
   • Large Pool: یه ناحیه اختیاری در SGA هست که برای کارهای سنگینی مثل بکاپ و بازیابی، فرایندهای I/O سرور و حافظه نشست‌ها در پیکربندی سرور چند رشته‌ای استفاده میشه.
2. Program Global Area (PGA): این یه بافر حافظه هست که داده‌ها و اطلاعات کنترلی یه فرایند سرور رو نگه میداره. هر فرایند سرور PGA مخصوص به خودش رو داره و این حافظه مشترک نیست.

فرایندها (Processes)

یه فرایند مثل یه «رشته کنترلی» توی سیستم‌عامل هست که میتونه یه سری مراحل رو اجرا کنه. اوراکل دو نوع کلی فرایند داره:

1. فرایندهای کاربر (User Processes): این فرایندها کد یه برنامه کاربردی (مثلا یه برنامه نوشته شده با Pro*C/C++) یا یه ابزار اوراکل (مثل Oracle Enterprise Manager) رو اجرا میکنن. فرایند کاربر با فرایندهای سرور ارتباط برقرار میکنه.
2. فرایندهای اوراکل (Oracle Processes): اینها خودشون دو دسته‌ان:
   • فرایندهای سرور (Server Processes): اوراکل این فرایندها رو برای رسیدگی به درخواست‌های فرایندهای کاربر متصل ایجاد میکنه. فرایند سرور با فرایند کاربر ارتباط برقرار میکنه و با اوراکل تعامل میکنه تا درخواست‌ها رو انجام بده. مثلا اگه یه کاربر داده‌ای رو بخواد که توی بافرهای پایگاه داده نیست، فرایند سرور مرتبط، بلوک‌های داده مناسب رو از فایل‌های داده میخونه و توی SGA میذاره.
   • فرایندهای پس‌زمینه (Background Processes): اوراکل برای هر نمونه یه سری فرایند پس‌زمینه ایجاد میکنه. این فرایندها به صورت ناهمزمان I/O انجام میدن و بر سایر فرایندهای اوراکل نظارت میکنن تا موازی‌سازی رو افزایش بدن و عملکرد و قابلیت اطمینان رو بهتر کنن. بعضی از این فرایندهای مهم اینها هستن:
     • DBWn (Database Writer): بلوک‌های تغییر کرده رو از Database Buffer Cache روی فایل‌های داده مینویسه. این کار رو معمولا زمانی انجام میده که حافظه بافر آزاد کم باشه.
     • LGWR (Log Writer): ورودی‌های Redo Log رو روی دیسک مینویسه.
     • CKPT (Checkpoint): در زمان‌های مشخص، به DBWn سیگنال میده که تمام بافرهای تغییر کرده رو روی دیسک بنویسه. به این رویداد میگن «چک‌پوینت».
     • SMON (System Monitor): وقتی یه نمونه که خراب شده دوباره استارت میخوره، بازیابی رو انجام میده. همچنین سگمنت‌های موقت بی‌استفاده رو پاک میکنه.
     • PMON (Process Monitor): وقتی یه فرایند کاربر با شکست مواجه میشه، بازیابی فرایند رو انجام میده. یعنی حافظه کش رو پاک میکنه و منابعی که اون فرایند استفاده میکرده رو آزاد میکنه.
     • ARCn (Archiver): فایل‌های Redo Log آنلاین رو وقتی پر میشن، در محل ذخیره‌سازی آرشیو کپی میکنه. این فرایند فقط وقتی فعاله که پایگاه داده در حالت ARCHIVELOG باشه.
     • RECO (Recoverer): تراکنش‌های توزیع شده‌ای که به خاطر مشکلات شبکه یا سیستم بلاتکلیف موندن رو حل میکنه.

بخش هفتم: تراکنش‌ها و یکپارچگی داده؛ چطور اوراکل نظم رو حفظ میکنه؟

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

اوراکل این مشکلات رو با استفاده از قفل‌ها (Locks) و یه مدل سازگاری چند نسخه‌ای (Multiversion Consistency Model) حل میکنه. اساس این ویژگی‌ها مفهوم تراکنش (Transaction) هست.

تراکنش (Transaction) چیه؟

یه تراکنش یه واحد منطقی از کاره که شامل یک یا چند دستور SQL میشه که توسط یه کاربر اجرا میشن. یه تراکنش با اولین دستور SQL قابل اجرای کاربر شروع میشه و وقتی به صراحت Commit (ثبت نهایی) یا Rollback (لغو و بازگشت به حالت قبل) بشه، تموم میشه.

مثال بانکی:

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

1. کاهش موجودی حساب پس‌انداز.
2. افزایش موجودی حساب جاری.
3. ثبت این تراکنش در دفتر روزنامه تراکنش‌ها.

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

• Commit: تغییرات ناشی از تمام دستورات SQL توی یه تراکنش رو دائمی میکنه.
• Rollback: هر تغییری که در نتیجه دستورات SQL در تراکنش ایجاد شده رو لغو میکنه.
• Savepoint: برای تراکنش‌های طولانی، میشه نشانگرهای میانی به اسم Savepoint تعریف کرد. اینطوری میشه یه تراکنش رو به بخش‌های کوچیک‌تر تقسیم کرد و در صورت نیاز، فقط تا یه Savepoint مشخص کار رو به عقب برگردوند.

سازگاری خواندن (Read Consistency)

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

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

قفل‌ها (Locks)

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

دو نوع اصلی قفل وجود داره: قفل انحصاری (Exclusive Lock) و قفل اشتراکی (Share Lock). روی یه منبع (مثل یه سطر یا جدول) فقط یه قفل انحصاری میشه گذاشت، اما میشه چندین قفل اشتراکی روی همون منبع داشت.

بخش هشتم: امنیت در اوراکل

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

1. امنیت سیستم (System Security): مکانیزم‌هایی که دسترسی و استفاده از پایگاه داده رو در سطح سیستم کنترل میکنن. مثل:
   • نام کاربری و رمز عبور معتبر برای اتصال به پایگاه داده.
   • تخصیص فضای دیسک برای کاربران.
   • محدودیت منابع سیستم برای کاربران.
   • ممیزی (Auditing) اقدامات کاربران.
2. امنیت داده (Data Security): مکانیزم‌هایی که دسترسی و استفاده از پایگاه داده رو در سطح آبجکت‌های اسکیما کنترل میکنن. مثل:
   • اینکه چه کاربرانی به چه آبجکت‌هایی دسترسی دارن.
   • چه عملیاتی روی اون آبجکت‌ها میتونن انجام بدن.

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

• کاربران (Users): هر پایگاه داده اوراکل یه لیست از نام‌های کاربری داره. برای دسترسی به پایگاه داده، کاربر باید با یه نام کاربری و رمز عبور معتبر وصل بشه.
• امتیازات (Privileges): امتیاز یعنی حق اجرای یه نوع خاص از دستور SQL. دو نوع امتیاز داریم:
  • امتیازات سیستم (System Privileges): به کاربر اجازه میده یه کار خاص در سطح کل سیستم انجام بده. مثلا امتیاز ساختن یه Tablespace.
  • امتیازات آبجکت (Schema Object Privileges): به کاربر اجازه میده یه کار خاص روی یه آبجکت مشخص انجام بده. مثلا امتیاز حذف کردن سطرها از یه جدول خاص.
• نقش‌ها (Roles): نقش‌ها گروه‌های نام‌گذاری شده از امتیازات مرتبط هستن که به کاربران یا نقش‌های دیگه داده میشن. مدیریت امتیازات از طریق نقش‌ها خیلی راحت‌تره. مثلا میشه یه نقش برای یه اپلیکیشن ساخت و تمام امتیازات لازم برای اجرای اون اپلیکیشن رو به اون نقش داد. بعد اون نقش رو به کاربرانی که باید از اپلیکیشن استفاده کنن، تخصیص داد.

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

اوراکل در طول سال‌ها نسخه‌های مختلفی رو منتشر کرده. نام‌گذاری نسخه‌ها هم یه قرارداد خاصی داره. مثلا پسوندهای «c»، «g» و «i» به ترتیب به معنی «Cloud»، «Grid» و «Internet» بودن. در نسخه فعلی یعنی Oracle Database 23ai، پسوند «ai» به معنی «هوش مصنوعی» (Artificial Intelligence) هست. در ادامه یه جدول از نسخه‌های مهم اوراکل و ویژگی‌های کلیدی‌شون رو میبینید:

نسخه پایگاه داده اوراکل	تاریخ انتشار اولیه	ویژگی‌های برجسته
Oracle v2	1979	اولین پایگاه داده رابطه‌ای SQL تجاری موجود.
Oracle v6	1988	قفل‌گذاری در سطح سطر، بکاپ و بازیابی آنلاین.
Oracle7	ژوئن 1992	رویه‌های ذخیره شده PL/SQL، تریگرها.
Oracle8i Database	1998	پروتکل‌های اینترنتی بومی و جاوا.
Oracle9i Database	2001	Oracle Real Application Clusters (RAC)، Oracle XML DB.
Oracle Database 10g	2003	مدیریت خودکار پایگاه داده، زیرساخت Grid، Oracle ASM.
Oracle Database 11g	سپتامبر 2007	Active Data Guard، Secure Files، Exadata.
Oracle Database 12c	ژوئیه 2013	معماری چندمستاجری (Multitenant)، In-Memory Column Store، JSON بومی.
Oracle Database 18c	فوریه 2018	یکپارچه‌سازی با Active Directory، توابع جدول چندریختی.
Oracle Database 19c (LTR)	فوریه 2019	ایجاد خودکار ایندکس، نگهداری آمار به صورت Real-Time.
Oracle Database 21c (IR)	دسامبر 2020	جداول بلاک‌چین، اجرای جاوا اسکریپت در پایگاه داده.
Oracle Database 23ai (LTR)	۲ می ۲۰۲۴	جستجوی برداری هوش مصنوعی (AI Vector Search)، دوگانگی رابطه‌ای JSON، پشتیبانی از میکروسرویس‌های تراکنشی.

(LTR مخفف Long Term Release و IR مخفف Innovation Release هست)

بخش دهم: پرسش و پاسخ از دنیای واقعی

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

سوال ۱: من یه مدیر پایگاه داده SQL Server هستم. یاد گرفتن اوراکل چقدر سخته؟

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

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

این یه سوال فنی رایجه. چند تا راه برای این کار وجود داره. یه راه ساده استفاده از این کوئری هست:

select sys_context('USERENV','SERVER_HOST') from dual

این دستور نیاز به هیچ امتیاز خاصی نداره و برای همین استفاده ازش توی رویه‌های ذخیره شده راحته. البته این پارامتر یعنی SERVER_HOST فقط از نسخه 10G به بعد در دسترسه. با استفاده از sys_context میشه اطلاعات مفید دیگه‌ای هم به دست آورد:

select
  sys_context ( 'USERENV', 'DB_NAME' ) db_name,
  sys_context ( 'USERENV', 'SESSION_USER' ) user_name,
  sys_context ( 'USERENV', 'SERVER_HOST' ) db_host,
  sys_context ( 'USERENV', 'HOST' ) user_host
from dual

این کوئری اسم پایگاه داده، اسم کاربر نشست، هاست پایگاه داده و هاست کاربر رو برمیگردونه.

سوال ۳: نمیتونم سرور رو متوقف کنم و پیام «Cannot stop/start server – Oracle database server is in existing mode» رو میگیرم. مشکل چیه؟

یه کاربری با نسخه 9.0.00 با این مشکل مواجه شده بود. وقتی از دستورات stop_all و start_all استفاده میکرد، این پیام رو دریافت میکرد. به نظر میرسید که با وجود این پیام، تمام فرایندهای EM واقعا متوقف میشدن. برای start_all هم این پیام اول نشون داده میشد ولی بعد از چند ثانیه رمز DBO رو میپرسید و فرایندها رو شروع میکرد. این کاربر اشاره کرده بود که پایگاه داده‌اش روی یه سرور اختصاصی نیست و با پایگاه داده‌های دیگه به اشتراک گذاشته شده. این پیام از اسکریپت‌های CM میاد و مدیران پایگاه داده (DBA) نتونسته بودن توضیحش بدن. اینجور مشکلات معمولا به پیکربندی خاص اون محیط برمیگرده.

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

یه کاربری که سرورهاش فقط میزبان پایگاه داده اوراکل (نسخه 11g) بودن، این سوال رو پرسیده بود. نصب اوراکل به همراه جاوا انجام شده بود (مثلا در مسیر \OraHome_1\product\11.2.0\dbhome_1\jdk). تیم عملیات شبکه بهش گفته بود که باید تمام نسخه‌های جاوا رو نگهداری و آپدیت کنه. اون کاربر ترجیح میداد اگه جاوا ضروری نیست، اون رو حذف کنه تا از زحمت نگهداریش خلاص بشه. واقعیت اینه که خیلی از ویژگی‌های داخلی اوراکل به جاوا وابسته هستن. بنابراین، جاوا به عنوان بخشی از نصب پایگاه داده اوراکل مورد نیازه و حذف کردنش میتونه مشکلات جدی ایجاد کنه.

سوال ۵: بکاپ پایگاه داده روی سرور فیزیکی اوراکل در لینوکس چطور کار میکنه؟

یه کاربر که با نرم‌افزار Veeam کار میکرد، میخواست بدونه بکاپ‌گیری از اوراکل روی سرورهای فیزیکی لینوکس چطوریه، چون Veeam بیشتر برای ماشین‌های مجازی بهینه شده. نرم‌افزارهایی مثل Veeam Agent for Linux (VAL) میتونن از سرورهای فیزیکی لینوکس بکاپ بگیرن. این بکاپ‌ها کل ماشین رو شامل میشن و به صورت فایل‌سیستمی سازگار هستن. در نسخه‌های جدیدتر این ابزارها، ویژگی‌هایی برای اطمینان از سازگاری تراکنشی (Transaction Consistency) پایگاه داده اوراکل هم اضافه شده. این یعنی قبل از بکاپ، پایگاه داده در حالتی قرار میگیره که بکاپ گرفته شده سالم و قابل بازیابی باشه.

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

خب، بریم سر اصل مطلب. مانگو دی‌بی یک دیتابیس از نوع 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 تاثیر میذاره. اگه داده‌های ورودی کم، اشتباه یا سوگیرانه باشن، خروجی هوش مصنوعی هم همین مشکلات رو خواهد داشت. در واقع داده مثل کتاب درسی برای یه دانش‌آموز میمونه.

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

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