This media is not supported in your browser
VIEW IN TELEGRAM
سال نو مبارک:) ❤️
امید وارم سال ۱۴۰۴ پر از شادی و خبرای خوب برای همگیمون باشه
امید وارم سال ۱۴۰۴ پر از شادی و خبرای خوب برای همگیمون باشه
❤🔥20❤1🔥1
خب خب خب NoSQL 🚀
امروز میخوام درباره یه موضوع جذاب تو دنیای دیتابیسها باهاتون حرف بزنم NoSQL اگه دنبال یه راهحل برای مدیریت دادههای بزرگ، انعطافپذیر و سریع هستین، Nosql گزینه خیلی خوبیه. بیاین با هم ببینیم NoSQL چیه.
🧠 NoSQL چیه؟
NoSQL (که مخفف "Not Only SQL" هست) یه دسته از دیتابیسهای غیررابطهایه که برعکس دیتابیسهای سنتی رابطهای (مثل MySQL یا PostgreSQL) از ساختار جدول و اسکیما (schema) ثابت استفاده نمیکنه (schema less). این دیتابیسها برای مدیریت دادههای بدون ساختار (unstructured)، نیمهساختار (semi-structured) یا ساختاریافته (structured) طراحی شدن و بهتون انعطافپذیری و مقیاسپذیری بالایی میدن.
به زبان ساده، NoSQL اومد که بگه "دادههات هر شکلی که هستن، من مدیریتشون میکنم 😎"
📚 انواع NoSQL
NoSQL چند مدل اصلی داره که هر کدوم برای یه نوع داده و کاربرد خاص بهینه شدن:
1️⃣ Key-Value (کلید-مقدار):
سادهترین نوعه، مثل یه دیکشنری بزرگ. یه کلید میدی، یه مقدار میگیری
2️⃣ Document (سندی):
دادهها رو به صورت داکیومنت (مثل JSON یا XML) ذخیره میکنه. هر داکیومنت میتونه ساختار متفاوتی داشته باشه.
3️⃣ Column-Family (ستونی):
دادهها رو تو ستونها ذخیره میکنه و برای دیتاهای بزرگ و تحلیلی عالیه.
4️⃣ Graph:
دادهها رو به صورت گراف (node) و یال (edge) ذخیره میکنه، مناسب روابط پیچیده هست.
چرا NoSQL به وجود اومد؟ 🚀
دیتابیسهای رابطهای (RDBMS) برای سالها پادشاه بودن، ولی با رشد تکنولوژی و دادهها، مشکلاتی پیش اومد:
حجم دادهها: وب، اپلیکیشنهای موبایل و IoT حجم دادهها رو به شکل انفجاری زیاد کردن و RDBMSها تو مقیاس بزرگ کند شدن.
ساختار ثابت: جدولهای RDBMS نیاز به اسکیما دارن و تغییرشون سخت بود، ولی دادههای امروزی انعطافپذیر و متنوع شدن.
مقیاسپذیری عمودی: RDBMSها فقط با ارتقای سختافزار (vertical scaling) بزرگ میشن، که گرون و محدوده.
سرعت: تو اپلیکیشنهای بلادرنگ (مثل چت یا بازی آنلاین)، تاخیر RDBMS جواب نمیداد.
NoSQL اومد که:
مقیاسپذیری افقی:
با اضافه کردن سرورهای بیشتر (horizontal scaling) بزرگ بشه.
انعطافپذیری:
بدون نیاز به اسکیما، هر نوع دادهای رو مدیریت کنه.
سرعت:
برای عملیات سریع و بلادرنگ بهینه بشه.
🔍 مزایا و معایب NoSQL
✅ مزایا:
مقیاسپذیری: به راحتی با اضافه کردن نود (node) بزرگ میشه.
انعطافپذیری: برای دادههای متنوع و بدون ساختار عالیه.
سرعت: تو عملیات سنگین و بلادرنگ حرف نداره.
توزیعشده: به صورت ذاتی برای سیستمهای توزیعشده طراحی شده.
❌ معایب:
عدم تطابق کامل (Consistency): تو بعضی مدلها (مثل BASE به جای ACID)، ممکنه دادهها لحظهای ناسازگار باشن.
یادگیری: هر نوع NoSQL دستورات خاص خودش رو داره و یادگیریش زمان میبره.
کمبود تراکنش پیچیده: برای عملیات پیچیده مثل تراکنشهای بانکی، RDBMS هنوز بهتره.
🎯 کجا از NoSQL استفاده کنیم؟
اپلیکیشنهای وب و موبایل: برای ذخیره دادههای کاربرها (مثل پروفایلها).
دادههای بلادرنگ: چت، اعلانها، بازیهای آنلاین.
دادههای بزرگ: تحلیل لاگها، IoT، سریهای زمانی.
پروژههای مقیاسپذیر: وقتی نمیدونی دادههات چقدر قراره رشد کنن.
جمعبندی ✍️
NoSQL یه انقلاب تو دنیای دیتابیسها بود که برای دنیای مدرن و دادهمحور امروز طراحی شده. با انعطافپذیری، سرعت و مقیاسپذیریش، یه انتخاب خوب برای پروژههاییه که نمیخوان تو چارچوبهای سفت و سخت RDBMS گیر کنن. از MongoDB برای اپلیکیشنهای وب گرفته تا ScyllaDB برای دادههای بلادرنگ، NoSQL برای هر نیازی یه جواب داره.
➖➖➖➖➖➖➖➖➖
امروز میخوام درباره یه موضوع جذاب تو دنیای دیتابیسها باهاتون حرف بزنم NoSQL اگه دنبال یه راهحل برای مدیریت دادههای بزرگ، انعطافپذیر و سریع هستین، Nosql گزینه خیلی خوبیه. بیاین با هم ببینیم NoSQL چیه.
🧠 NoSQL چیه؟
NoSQL (که مخفف "Not Only SQL" هست) یه دسته از دیتابیسهای غیررابطهایه که برعکس دیتابیسهای سنتی رابطهای (مثل MySQL یا PostgreSQL) از ساختار جدول و اسکیما (schema) ثابت استفاده نمیکنه (schema less). این دیتابیسها برای مدیریت دادههای بدون ساختار (unstructured)، نیمهساختار (semi-structured) یا ساختاریافته (structured) طراحی شدن و بهتون انعطافپذیری و مقیاسپذیری بالایی میدن.
به زبان ساده، NoSQL اومد که بگه "دادههات هر شکلی که هستن، من مدیریتشون میکنم 😎"
📚 انواع NoSQL
NoSQL چند مدل اصلی داره که هر کدوم برای یه نوع داده و کاربرد خاص بهینه شدن:
1️⃣ Key-Value (کلید-مقدار):
سادهترین نوعه، مثل یه دیکشنری بزرگ. یه کلید میدی، یه مقدار میگیری
مثال: Redis، DynamoDB
2️⃣ Document (سندی):
دادهها رو به صورت داکیومنت (مثل JSON یا XML) ذخیره میکنه. هر داکیومنت میتونه ساختار متفاوتی داشته باشه.
مثال: MongoDB، CouchDB
3️⃣ Column-Family (ستونی):
دادهها رو تو ستونها ذخیره میکنه و برای دیتاهای بزرگ و تحلیلی عالیه.
مثال: Cassandra، ScyllaDB
4️⃣ Graph:
دادهها رو به صورت گراف (node) و یال (edge) ذخیره میکنه، مناسب روابط پیچیده هست.
مثال: Neo4j، ArangoDB
چرا NoSQL به وجود اومد؟ 🚀
دیتابیسهای رابطهای (RDBMS) برای سالها پادشاه بودن، ولی با رشد تکنولوژی و دادهها، مشکلاتی پیش اومد:
حجم دادهها: وب، اپلیکیشنهای موبایل و IoT حجم دادهها رو به شکل انفجاری زیاد کردن و RDBMSها تو مقیاس بزرگ کند شدن.
ساختار ثابت: جدولهای RDBMS نیاز به اسکیما دارن و تغییرشون سخت بود، ولی دادههای امروزی انعطافپذیر و متنوع شدن.
مقیاسپذیری عمودی: RDBMSها فقط با ارتقای سختافزار (vertical scaling) بزرگ میشن، که گرون و محدوده.
سرعت: تو اپلیکیشنهای بلادرنگ (مثل چت یا بازی آنلاین)، تاخیر RDBMS جواب نمیداد.
NoSQL اومد که:
مقیاسپذیری افقی:
با اضافه کردن سرورهای بیشتر (horizontal scaling) بزرگ بشه.
انعطافپذیری:
بدون نیاز به اسکیما، هر نوع دادهای رو مدیریت کنه.
سرعت:
برای عملیات سریع و بلادرنگ بهینه بشه.
🔍 مزایا و معایب NoSQL
✅ مزایا:
مقیاسپذیری: به راحتی با اضافه کردن نود (node) بزرگ میشه.
انعطافپذیری: برای دادههای متنوع و بدون ساختار عالیه.
سرعت: تو عملیات سنگین و بلادرنگ حرف نداره.
توزیعشده: به صورت ذاتی برای سیستمهای توزیعشده طراحی شده.
❌ معایب:
عدم تطابق کامل (Consistency): تو بعضی مدلها (مثل BASE به جای ACID)، ممکنه دادهها لحظهای ناسازگار باشن.
یادگیری: هر نوع NoSQL دستورات خاص خودش رو داره و یادگیریش زمان میبره.
کمبود تراکنش پیچیده: برای عملیات پیچیده مثل تراکنشهای بانکی، RDBMS هنوز بهتره.
🎯 کجا از NoSQL استفاده کنیم؟
اپلیکیشنهای وب و موبایل: برای ذخیره دادههای کاربرها (مثل پروفایلها).
دادههای بلادرنگ: چت، اعلانها، بازیهای آنلاین.
دادههای بزرگ: تحلیل لاگها، IoT، سریهای زمانی.
پروژههای مقیاسپذیر: وقتی نمیدونی دادههات چقدر قراره رشد کنن.
جمعبندی ✍️
NoSQL یه انقلاب تو دنیای دیتابیسها بود که برای دنیای مدرن و دادهمحور امروز طراحی شده. با انعطافپذیری، سرعت و مقیاسپذیریش، یه انتخاب خوب برای پروژههاییه که نمیخوان تو چارچوبهای سفت و سخت RDBMS گیر کنن. از MongoDB برای اپلیکیشنهای وب گرفته تا ScyllaDB برای دادههای بلادرنگ، NoSQL برای هر نیازی یه جواب داره.
#️⃣ #db #nosql
➖➖➖➖➖➖➖➖➖
🥷 CHANNEL | GROUP
👍10❤5❤🔥1🔥1👌1
Ninja Learn | نینجا لرن
این داداشمون میگه ۸ تا از سریع ترین زبان های برنامه نویسی اینان و پایتون از سه تای پایینیش سریع تره :)))))))) #️⃣ #wtf ➖➖➖➖➖➖➖➖➖ 🥷 CHANNEL | GROUP
جالبه بدونید c# از go هم سریع تره :)
👎17👍4
توی این مقاله درمورد اصول نامگذاری کامیت ها صحبت میکنم :]
ممنون میشم با لایک و کامنت حمایت کنید ❤️
لینک مقاله
➖➖➖➖➖➖➖➖➖
ممنون میشم با لایک و کامنت حمایت کنید ❤️
لینک مقاله
#️⃣ #refrence
➖➖➖➖➖➖➖➖➖
🥷 CHANNEL | GROUP
Medium
A Guide to Writing Effective Migration Messages in Alembic
Alembic is a lightweight database migration tool designed to work with SQLAlchemy, allowing developers to manage changes to their database…
🔥15💔1
چرا نباید لاجیک پروژه رو تو سریالایزرهای DRF پیادهسازی کنیم؟ 🚫
یه موضوع مهم هست که چرا نباید لاجیک پروژهمون رو تو سریالایزرها پیادهسازی کنیم؟ خیلی از افرادی که میشناسم متاسفانه اینکارو میکنن (پیاده سازی لاجیک توی سریالایزر ها) اگه شماهم حزو این دسته افراد هستید این پست براتون مناسبه
اول از همه سریالایزر تو DRF چیه؟
سریالایزرها تو DRF مسئول تبدیل دادهها بین فرمتهای مختلف (مثل JSON و مدلهای Django) هستن. کارشون اینه که دادهها رو بگیرن، اعتبارسنجی (validation) کنن و به شکل مناسب تحویل بدن. مثلاً یه مدل
🚫 چرا این کار بده؟
بعضیها عادت دارن تو متدهای سریالایزر (مثل
1⃣ نقض اصل Single Responsibility:
سریالایزرها برای تبدیل و اعتبارسنجی دادهها طراحی شدن، نه برای مدیریت لاجیک پروژه.
وقتی لاجیک رو اونجا مینویسین، کدتون از یه سریالایزر ساده تبدیل میشه به سریالایزر خیلی گنده که بعداً نگهداریش سخت میشه.
2⃣ کاهش Readability و Testability:
اگه لاجیک تو سریالایزر باشه، پیدا کردنش تو پروژه سختتره و تست کردنش هم پیچیده میشه. مثلاً برای تست یه محاسبه، باید کل سریالایزر رو تست کنین، نه فقط اون لاجیک خاص.
3⃣ مشکلات Scalability:
تو پروژههای بزرگ، وقتی لاجیکها تو سریالایزرها پخش بشن، دیگه نمیتونین به راحتی تغییرشون بدین یا جابهجاشون کنین. یه تغییر کوچیک تو لاجیک ممکنه کل API رو به هم بریزه.
4⃣ وابستگی بیش از حد:
سریالایزرها به مدلها و دادهها وابسته ان. اگه لاجیک پروژه رو اونجا بذارین، هر تغییری تو مدلها یا ساختار دادهها میتونه لاجیکتون رو خراب کنه.
5⃣ سخت شدن دیباگ:
وقتی یه باگ پیش میاد، نمیدونین مشکل از تبدیل دادهست یا از لاجیک پروژه، چون همهچیز قاطی شده.
سخن اخر 🗣
پیادهسازی لاجیک پروژه تو سریالایزرهای DRF مثل اینه که بخوای با چاقو سوپ بخوری؛ میشه، ولی چرا؟! سریالایزرها برای تبدیل و اعتبارسنجی دادهها طراحی شدن، نه برای نگه داشتن لاجیک پیچیده. با انتقال لاجیک به مدلها یا سرویسها، کدتون تمیزتر، قابلنگهداریتر و حرفهایتر میشه. دفعه بعد که خواستین تو سریالایزر لاجیک بنویسین، یه لحظه وایسید و بگین: اینجا جای این کارا نیست 😊
➖➖➖➖➖➖➖➖➖
یه موضوع مهم هست که چرا نباید لاجیک پروژهمون رو تو سریالایزرها پیادهسازی کنیم؟ خیلی از افرادی که میشناسم متاسفانه اینکارو میکنن (پیاده سازی لاجیک توی سریالایزر ها) اگه شماهم حزو این دسته افراد هستید این پست براتون مناسبه
اول از همه سریالایزر تو DRF چیه؟
سریالایزرها تو DRF مسئول تبدیل دادهها بین فرمتهای مختلف (مثل JSON و مدلهای Django) هستن. کارشون اینه که دادهها رو بگیرن، اعتبارسنجی (validation) کنن و به شکل مناسب تحویل بدن. مثلاً یه مدل
User
رو به JSON تبدیل میکنن یا برعکس. تا اینجا همهچیز اوکیه، ولی مشکل از جایی شروع میشه که بخوایم لاجیک اصلی پروژه رو تو همین سریالایزرها پیاده سازی کنیم.🚫 چرا این کار بده؟
بعضیها عادت دارن تو متدهای سریالایزر (مثل
to_representation
یا validate
) لاجیکهای پیچیده بنویسن، مثلاً محاسبات، فیلتر کردن دادهها یا حتی آپدیت دیتابیس. اما این کارا چندتا مشکل بزرگ به وجود میاره1⃣ نقض اصل Single Responsibility:
سریالایزرها برای تبدیل و اعتبارسنجی دادهها طراحی شدن، نه برای مدیریت لاجیک پروژه.
وقتی لاجیک رو اونجا مینویسین، کدتون از یه سریالایزر ساده تبدیل میشه به سریالایزر خیلی گنده که بعداً نگهداریش سخت میشه.
2⃣ کاهش Readability و Testability:
اگه لاجیک تو سریالایزر باشه، پیدا کردنش تو پروژه سختتره و تست کردنش هم پیچیده میشه. مثلاً برای تست یه محاسبه، باید کل سریالایزر رو تست کنین، نه فقط اون لاجیک خاص.
3⃣ مشکلات Scalability:
تو پروژههای بزرگ، وقتی لاجیکها تو سریالایزرها پخش بشن، دیگه نمیتونین به راحتی تغییرشون بدین یا جابهجاشون کنین. یه تغییر کوچیک تو لاجیک ممکنه کل API رو به هم بریزه.
4⃣ وابستگی بیش از حد:
سریالایزرها به مدلها و دادهها وابسته ان. اگه لاجیک پروژه رو اونجا بذارین، هر تغییری تو مدلها یا ساختار دادهها میتونه لاجیکتون رو خراب کنه.
5⃣ سخت شدن دیباگ:
وقتی یه باگ پیش میاد، نمیدونین مشکل از تبدیل دادهست یا از لاجیک پروژه، چون همهچیز قاطی شده.
سخن اخر 🗣
پیادهسازی لاجیک پروژه تو سریالایزرهای DRF مثل اینه که بخوای با چاقو سوپ بخوری؛ میشه، ولی چرا؟! سریالایزرها برای تبدیل و اعتبارسنجی دادهها طراحی شدن، نه برای نگه داشتن لاجیک پیچیده. با انتقال لاجیک به مدلها یا سرویسها، کدتون تمیزتر، قابلنگهداریتر و حرفهایتر میشه. دفعه بعد که خواستین تو سریالایزر لاجیک بنویسین، یه لحظه وایسید و بگین: اینجا جای این کارا نیست 😊
#️⃣ #backend #drf #django #api
➖➖➖➖➖➖➖➖➖
🥷 CHANNEL | GROUP
👍20❤3
Forwarded from Denver
🛠 چند alias کاربردی برای هر کاربر لینوکس
حتما با alias ها آشنایی دارین، همون لقب دادن به دستوراتمون.
کاربردش چیه؟ میتونیم کلی دستور طولانی یا حتی دستورایی که تایپ کردنشون هر دفعه مثل یه کابوس میمونه رو توی دستور مورد نظر خودمون خلاصه کنیم.
با این aliasها توی فایل
🔗برای راحتی کار میتونید فایل آماده ی alias هارو از لینک زیر دانلود کنید:
فایل آماده ی alias ها
📌 نکته: بعد از اضافه کردن aliasها، فراموش نکن که ترمینالت رو یه بار ببندی و باز کنی یا دستور زیر رو وارد کنی:
➖➖➖➖➖➖➖➖➖➖
حتما با alias ها آشنایی دارین، همون لقب دادن به دستوراتمون.
کاربردش چیه؟ میتونیم کلی دستور طولانی یا حتی دستورایی که تایپ کردنشون هر دفعه مثل یه کابوس میمونه رو توی دستور مورد نظر خودمون خلاصه کنیم.
ساده تر بگیم، درواقع با اینکار داریم به شل(zsh, bash, fish) میگیم که دستور مورد نظر a معادل دستور طولانی b هست.
با این aliasها توی فایل
~/.bashrc
یا ~/.zshrc
میتونی کلی زمان تو ترمینال صرفهجویی کنی 💻⚡️# ====== System Management ======
alias update="sudo apt update && sudo apt upgrade -y" # Fast system update
alias clean="sudo apt autoremove && sudo apt autoclean" # Clean cache and unnecessary packages
alias reboot="sudo reboot" # Reboot the system
alias ping="ping -c 5" # Ping with 5 packets
# ====== Navigation Shortcuts ======
alias home='cd ~' # Go to home directory
alias cd..='cd ..' # One directory up
alias ..='cd ..' # One directory up (short)
alias ...='cd ../..' # Two directories up
alias ....='cd ../../..' # Three directories up
alias .....='cd ../../../..' # Four directories up
# ====== File Search ======
alias f="find . -name" # Find file by name in current directory and subdirectories
# ====== Listing (ls) Aliases ======
alias la='ls -Alh' # List all files including hidden
alias ls='ls --color=always' # Enable colored output
alias lx='ls -lXBh' # Sort by extension
alias lk='ls -lSrh' # Sort by size
alias lc='ls -lcrh' # Sort by change time
alias lu='ls -lurh' # Sort by access time
alias lr='ls -lRh' # Recursive listing
alias lt='ls -ltrh' # Sort by date
alias lw='ls -xAh' # Wide listing format
alias ll='ls -Flsh' # Long listing format with type indicators
alias labc='ls -lap' # Alphabetical listing with hidden files
alias lf="ls -l | egrep -v '^d'" # List only files
alias ldir="ls -l | egrep '^d'" # List only directories
🔗برای راحتی کار میتونید فایل آماده ی alias هارو از لینک زیر دانلود کنید:
فایل آماده ی alias ها
📌 نکته: بعد از اضافه کردن aliasها، فراموش نکن که ترمینالت رو یه بار ببندی و باز کنی یا دستور زیر رو وارد کنی:
source ~/.bashrc # or ~/.zshrc
#️⃣ #linux #terminal #tools
➖➖➖➖➖➖➖➖➖➖
🐧 CHANNEL | GROUP
❤13
آیا پایتون همیشه کنده؟ 🐢
چیزی که همیشه از زبون همه ی برنامه نویسا میشنویم (مخصوصا جامعه محترم C#) اینه که پایتون خیلی کنده (نسبت به زبان های دیگه هرچند این مقایسه اشتباهه بعضی جاها)
خب اره، درسته پایتون کنده (البته در حالت pure)
توی این پست میخوام بگم که چرا کنده و چجوری میشه سریعش کرد؟
چرا پایتون کنده ؟ 🤓
همونجور که میدونید پایتون به صورت پیشفرض با CPython اجرا میشه، که یه مفسر (interpreter) برای پایتونه و با زبان C نوشته شده. CPython کد پایتون رو به بایتکد (bytecode) تبدیل میکنه و بعد اون رو تو یه ماشین مجازی (VM) اجرا میکنه. این فرایند باعث میشه پایتون نسبت به زبانهای کامپایلشده مثل C یا Rust کندتر باشه، چون
تفسیر خطبهخط انجام میده و به جای کامپایل مستقیم به کد ماشین، پایتون تو زمان اجرا تفسیر میشه.
GIL (Global Interpreter Lock) تو CPython، یه قفل سراسری هست که جلوی اجرای چند نخ (thread) همزمان رو میگیره و برای کارهای multithreading مشکلساز میشه.
داینامیک تایپ بودن پایتون تایپها رو تو زمان اجرا چک میکنه، که یه کم سرعت رو پایین میاره.
ولی خبر خوب اینه که پایتون راه ها و ابزارهایی داره که میتونن این کندی رو برطرف کنن و پرفورمنس رو حسابی بالا ببرن
راه ها و ابزارهایی برای افزایش سرعت 📚
1️⃣ PyPy 🌟
Pypy یه مفسر جایگزین برای پایتونه که از JIT (Just-In-Time Compilation) استفاده میکنه.
و کارکردش اینجوریه که کد پایتون رو به جای تفسیر ساده، تو زمان اجرا به کد ماشین کامپایل میکنه. این یعنی برای حلقهها و عملیات تکراری خیلی سریعتره.
مزیتشم اینه تو بعضی موارد تا ۷ برابر سریعتر از CPython عمل میکنه
و باید توجه داشت باشید برای کدهایی که با C extensionها (مثل NumPy) کار میکنن، کامل سازگار نیست.
2️⃣ Cython ⚡
Cython یه ابزار که کد پایتون رو به C تبدیل میکنه و بعد کامپایلش میکنه.
اینجوری کار میکنه که میتونی تایپهای استاتیک (مثل
و تا چندین برابر سریعتر از CPython میشه، بهخصوص برای محاسبات سنگین.
3️⃣ Numba 🔥
Numba یه کامپایلر JIT برای پایتونه که با دکوریتور
کارکردش اینجوریه که کد پایتون رو تو زمان اجرا به کد ماشین تبدیل میکنه، بدون نیاز به تغییر زیاد تو کدنویسی.
برای حلقهها و محاسبات عددی (مثل کار با آرایهها) تا ۱۰۰ برابر سریعتر میشه
4️⃣ CPython با C Extensions 🛠️
میتونی بخشهای کند پروژت یا جاهایی که به سرعت بالا نیاز داری رو با C بنویسی و به CPython وصل کنی.
اینجوریه که کد C رو به صورت ماژول میسازی و تو پایتون لودش میکنی.
و سرعت C رو با سادگی پایتون ترکیب میکنی. کتابخونههایی مثل NumPy و Pandas از این روش استفاده میکنن.
و در اخر پایتون همیشه کند نیست 🙃
حقیقت اینه که پایتون به تنهایی برای خیلی از کارها به اندازه کافی سریعه، بهخصوص تو پروژههایی که I/O (مثل شبکه یا دیتابیس) گلوگاه اصلیه، نه CPU. ولی وقتی پای محاسبات سنگین وسط میاد، ابزارهایی مثل PyPy، Cython و Numba میتونن پرفورمنس رو چند برابر کنن. مثلاً:
یه حلقه ساده با Numba میتونه از ۵ ثانیه به ۰.۰۵ ثانیه برسه
PyPy تو برنامههای واقعی تا ۷ برابر سرعت رو بالا برده.
چیزی که همیشه از زبون همه ی برنامه نویسا میشنویم (مخصوصا جامعه محترم C#) اینه که پایتون خیلی کنده (نسبت به زبان های دیگه هرچند این مقایسه اشتباهه بعضی جاها)
خب اره، درسته پایتون کنده (البته در حالت pure)
توی این پست میخوام بگم که چرا کنده و چجوری میشه سریعش کرد؟
چرا پایتون کنده ؟ 🤓
همونجور که میدونید پایتون به صورت پیشفرض با CPython اجرا میشه، که یه مفسر (interpreter) برای پایتونه و با زبان C نوشته شده. CPython کد پایتون رو به بایتکد (bytecode) تبدیل میکنه و بعد اون رو تو یه ماشین مجازی (VM) اجرا میکنه. این فرایند باعث میشه پایتون نسبت به زبانهای کامپایلشده مثل C یا Rust کندتر باشه، چون
تفسیر خطبهخط انجام میده و به جای کامپایل مستقیم به کد ماشین، پایتون تو زمان اجرا تفسیر میشه.
GIL (Global Interpreter Lock) تو CPython، یه قفل سراسری هست که جلوی اجرای چند نخ (thread) همزمان رو میگیره و برای کارهای multithreading مشکلساز میشه.
داینامیک تایپ بودن پایتون تایپها رو تو زمان اجرا چک میکنه، که یه کم سرعت رو پایین میاره.
ولی خبر خوب اینه که پایتون راه ها و ابزارهایی داره که میتونن این کندی رو برطرف کنن و پرفورمنس رو حسابی بالا ببرن
راه ها و ابزارهایی برای افزایش سرعت 📚
1️⃣ PyPy 🌟
Pypy یه مفسر جایگزین برای پایتونه که از JIT (Just-In-Time Compilation) استفاده میکنه.
و کارکردش اینجوریه که کد پایتون رو به جای تفسیر ساده، تو زمان اجرا به کد ماشین کامپایل میکنه. این یعنی برای حلقهها و عملیات تکراری خیلی سریعتره.
مزیتشم اینه تو بعضی موارد تا ۷ برابر سریعتر از CPython عمل میکنه
و باید توجه داشت باشید برای کدهایی که با C extensionها (مثل NumPy) کار میکنن، کامل سازگار نیست.
2️⃣ Cython ⚡
Cython یه ابزار که کد پایتون رو به C تبدیل میکنه و بعد کامپایلش میکنه.
اینجوری کار میکنه که میتونی تایپهای استاتیک (مثل
int
یا float
) به متغیرها اضافه کنی تا سرعتش بیشتر بشه. بعد Cython این کد رو به C تبدیل میکنه و یه فایل باینری سریع تحویلت میده.و تا چندین برابر سریعتر از CPython میشه، بهخصوص برای محاسبات سنگین.
3️⃣ Numba 🔥
Numba یه کامپایلر JIT برای پایتونه که با دکوریتور
@jit
کار میکنه.کارکردش اینجوریه که کد پایتون رو تو زمان اجرا به کد ماشین تبدیل میکنه، بدون نیاز به تغییر زیاد تو کدنویسی.
برای حلقهها و محاسبات عددی (مثل کار با آرایهها) تا ۱۰۰ برابر سریعتر میشه
4️⃣ CPython با C Extensions 🛠️
میتونی بخشهای کند پروژت یا جاهایی که به سرعت بالا نیاز داری رو با C بنویسی و به CPython وصل کنی.
اینجوریه که کد C رو به صورت ماژول میسازی و تو پایتون لودش میکنی.
و سرعت C رو با سادگی پایتون ترکیب میکنی. کتابخونههایی مثل NumPy و Pandas از این روش استفاده میکنن.
و در اخر پایتون همیشه کند نیست 🙃
حقیقت اینه که پایتون به تنهایی برای خیلی از کارها به اندازه کافی سریعه، بهخصوص تو پروژههایی که I/O (مثل شبکه یا دیتابیس) گلوگاه اصلیه، نه CPU. ولی وقتی پای محاسبات سنگین وسط میاد، ابزارهایی مثل PyPy، Cython و Numba میتونن پرفورمنس رو چند برابر کنن. مثلاً:
یه حلقه ساده با Numba میتونه از ۵ ثانیه به ۰.۰۵ ثانیه برسه
PyPy تو برنامههای واقعی تا ۷ برابر سرعت رو بالا برده.