#Quick

من این مشکل رو زیاد دیدم؛ بیش از حداقل 20% پروژه‌های خدماتی که دوستان روش کار می‌کنن. می‌بینم که Postgresql به معنای واقعی کلمه OverKill هست. مخصوصا وقتی Sqlite کار رو در میاره.

شاید به روی خودتون نیارید ولی خیلی از شما هم ازین پروژه‌ها دیدید دیگه.

خواستم هم اهمیت SQLite رو یادآوری کنم
هم بگم پروژه‌هایی مثل rqlite هم وجود داره‌ها


مثال:
کاری به درست و غلط بودن دیزاین و ... ندارم و بحثم فقط همین مورد Sqlite هست.
یک کدی رو دیدم؛ طرف یک سیستم verification جدا براش طراحی کرده بود و تمام پروژه‌هاشون ازین سرویس استفاده می‌کرد. فکر کنم این سرویس یا .net بود یا golang بعد بحث اصلی سر این بود که Postgres بذارند یا MsSql من درجا پیشنهاد SQlite رو دادم.
این دیتابیس خیلی اهمیت زیادی نداره؛ هر کد قراره نهایتا ۱۰ دقیقه valid باشه. در صورت پاک شدن هم طرف یکبار دیگه درخواست میده (که من تاحالا پاک شدن خود به خود توش ندیدم).

چرا می‌خواید شر درست کنید برای تیم devops, server, database, ...
خیلی ها مشکلشون این هست که اطلاعات ندارند (هیچ‌وقت هم جرات تجربه کردن نداشتند)؛ خود SQLite روی SSD طبق بنچمارک‌ها.
بیش از 500 هزار insert در ثانیه رو پشتیبانی می‌کنه و برای read هم این مورد به بیش از 1 میلیون میرسه و این مورد بدون config های پرفورمنسی هست که توی داکیومنت خودش ارائه شده.
روی NVMe هم چندسال قبل تست کردیم؛ اعداد بهتر هم میشه.

اضافه کنم :
اینم rqlite اگر حتی خواستید SQlite رو بصورت distributed داشته باشید (قبلا توی اون کی کانال راجبش صحبت کردم با K8s )

#Quick

یک عادت خوبی که توی بچه‌های ایران هست که یک endpoint توی پروژه‌های بکند می‌سازند به اسم health-check اما ۹۰٪ اشتباه پیاده‌سازی میشه متأسفانه.

برای اونایی که نمی‌دونند، health-check برای این هست که بصورت اتوماتیک یک سیستم دیگه مثل k8s یا سیستم مانیتورینگ بتونه وضعیت بکند رو بررسی کنه و اگر جوابی نگرفت ایمیل بزنه یا اون pod رو ریست کنه.

حالا چرا میگم اشتباه پیاده‌سازی میشه، اول میرم سراغ مانیتورینگ:

فرض کن شما یک بکند داری که برای کار کردن به postgres, celery نیاز داره با این وضعیت سیستم شما وقتی سالم هست که به postgres شما بتونه یه درستی دسترسی بگیره و البته به celery (عملکرد celery, postgres رو اگر بخواید بررسی کنید نیاز به ۲ تا سیستم مانیتورینگ جدا دارید، برای شما توی سطح اپلیکیشن دسترسی به این سرویس‌ها مهم هست)

فکر کنم متوجه منظورم شدید؛ توی health-check باید دسترسی به سرویس‌هایی که بکند شما بدون اونا healthy نیست رو هم چک کنید.
توی مثال قبلی اگر celery برای شما اجبار نیست توی health-check کانکشن بهش رو تست نمی‌کنید.

حالا چرا k8s رو مثال زدم ؟ برای اینکه بگم استفاده از این endpoint برای بررسی pod ها کار درستی نیست:

هر pod بصورت جداگونه و بصورت تک سرویس در نظر گرفته میشه که به تنهایی می‌تونه restart بشه بدون اینکه به سیستم لطمه بزنه (من HA درنظرم گرفتم، k8s برای همینه دیگه) پس باید تو سریعتر زمانی که عملکرد خودش رو از دست میده restart بشه فکر کن load سیستم بره بالا در این شرایط هم از روی health-check نمی‌شه مطمئن بود آیا چون load شبکه رفت بالا جواب دیر میاد یا memory leakage داریم یا ...
پس سرویس رو از exception, ... مانیتور کنید با k8s تا جایی که می‌شه.

#Quick

اگر از vscode برای Rust استفاده می‌کنید حتما این extension رو نصب کنید که دستورات sql رو براتون وسط کدهای rs به خوبی highlight می‌کنه ( از حالت str& خالی در میاد)

الان اومد یک کدی رو بزنم چندتا از Sql Query هاش خیلی طولانی و سخت شد بدون highlight خوندنش قطعا آزار دهنده بود با سرچ به این رسیدم و بنظرم گزینه بسیار کمک کننده و عالی‌ای هست.

#Quick

مثالی برای یک بحث:

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

مثلاً توی بکند؛
چرا به سریالایزر نیاز داریم ؟ من مدل دیتابیس رو دارم پکیج‌های مورد نیاز برای کار با json, dict هم که وجود داره چرا مستقیم خودم اینکار رو نکنم و حتماً باید از serializer‌ استفاده کنم ؟

این مثلاً ازون سوالاتی هست که اگر پوزیشن کاری جنگو باشه، توی سطح mid می‌پرسم.
اما اگر غیر از اون باشه حتماً توی سطح junior می‌پرسم، یک نمونه از چیزهایی که میگم بکند رو فارغ از فریمورک یادبگیرید هم هست.

به جوابش فکر کنید، اگر نمی‌دونید هم تحقیق کنید.

#Quick

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

بعد می‌دیدم که خب هیچکدوم ازین پروژه‌ها مثلاً از ابزاری مثل Celery استفاده نکردن یا Celery داره ولی Flower نداره.

اول اینکه مگه توی دنیای فعلی میشه شما پروژه‌ای داشته باشی ولی celery توش نباشه؟ یا اینکه celery رو ببری روی پروداکشن ولی مانیتور نکنی (اینو توی خیلی پروژه‌ها هم دیدم).

یا یک مثال دیگه، هیچکدوم از پروژه‌ها رو نمی‌شد با تک کامند deploy کرد.
local, stage, production

بحث ci/cd نیست الان، ولی docker compose و ... باید به درستی نوشته بشه

و البته کلی نکات دیگه مثل این موضوع.

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

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

#Quick

و در نهایت :

استفاده از Insomnia, Postman توی شرکت برای پروژه‌های اصلی ممنوع شد.

بخاطر اینکه برای استفاده ازین ۲ ابزار حتماً باید اکانت داشته باشید و حتماً هم این ابزارها تمام اطلاعات رو با سرور‌هاشون Sync می‌کنند.

پیشنهاد خودشون Bruno بوده (پیشنهاد من بود) ولی هر ابزاری که بدون نیاز به اینترنت و sync بشه استفاده کرد مشکلی نداره.


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

#Quick

داشتم پروژه django شرکت رو می‌خوندم یک مشکل داریم سر بعضی endpointها و برخی تسک‌ها.
اولین کاری کردم این بوده که یک سری دیتا تست با faker بهش دادم مثه loadtest ولی بدون ابزار و بعد هم profiling گرفتم و ذخیره کردم.
چیز جالبی که دیدم؛ پروژه موقع کار کردن با redis به مشکل میخورد.
ولی redis منابعش بیشتر از حد مورد نیازش بود.

حجم دیتاهای تست رو کم کردم و مشکل حل شد؛ توی چندتا تست مختلف که زدم دیدم مسئله و مشگل از سمت پیکج redis هست توی پایتون و راهکار ساده رو هم خود redis داده (هرچند من برعکس بهش رسیدم)

$ pip install "redis[hiredis]"

بجای اینکه برای parse کردن دیتا از python استفاده کنه وقتی hiredis رو نصب کنید از C استفاده می‌کنه (بنچمارکاش هم توی گیت‌هاب hiredis هست ببینید)

مشکل خیلی ساده حل شد؛ ولی برای این حل ساده خیلی زمان و درک profiling لازم بود.

اهمیت profiling

#Quick
سوال مصاحبه یکی از دوستان بوده.

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

Pass by Value
Pass by Reference

اشاره می‌کنید؛ اما توی پایتون اینطوری نیست توی پایتون ما
Pass By Object Reference (Pass by Assignment)
رو داریم. اول برگردیم به این تعریف که:

همه چیز در پایتون نهایتا object هست.

وقتی یک آرگومان رو به تابع میدید؛ رفرنس اون آبجکت رو براش می‌فرستید و نه یک کپی از اون رو ولی این رفرنس رو بصورت pass by value می‌فرستید! گیج گننده شد؟ برای همین میگیم پایتون نه Pass By Reference هست نه Pass By Value

یک صندوق رو فرض کنید که توش وسایل شما قرار داره (این حکم object رو داره) حالا فرض کنید برای اینکه جاش رو یادتون نره آدرسش رو روی یک کاغذ نوشتید و توی جیبتون می‌ذارید (این میشه reference شما)
یکی از دوستانتون می‌خواد صندوق رو ببینه؛ شما فقط کافیه آدرس رو بهش بدید که برای اینکار شما آدرس رو روی یک کاغذ جدید می‌نویسید و اون رو بهش میدید (این میشه Pass reference by Value)

و این میشه مدل پایتون؛ اگر رفیق شما بره اونجا و از داخل صندوق چیزی برداره یا تغییراتی روی صندوق انجام بده؛ شما هم اون تغییرات رو خواهید دید. اگرم که صندوق رو ببینه و کارش که تموم شد کاغذ آدرس صندوق رو بندازه دور اونوقت صندوق هنوز سرجاش خواهد بود و شما صاحبش هستید.

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

مثال بالا میشه برای Object هایی که قابل تغییر هستند مثل list
اما اگر Object قابل تغییر نبود چی ؟ مثل Int
اونوقت رفیق شما هر تغییری که بخواد بده اول باید ی دونه از روی چیزی که مال شما هست برای خودش بسازه بعد تغییرش بده.

def demonstrate_passing_behavior(my_list, my_int):
    print("\n--- INSIDE FUNCTION ---")
    print(f"List ID: {id(my_list)}, Int ID: {id(my_int)}")

    my_list.append(4)
    print(f"List after append: {my_list}, ID(append): {id(my_list)}")

    print("Copy of the original list")
    my_list = list(my_list)
    print(f"List copy and reassignment: {my_list}, ID(copy): {id(my_list)}")

    print("Modifying integer...")
    my_int = my_int + 10
    print(f"Int after modification: {my_int}, ID(modified) : {id(my_int)}")


original_list = [1, 2, 3]
original_int = 5

print(f"Original list: {original_list}, ID: {id(original_list)}")
print(f"Original int: {original_int}, ID: {id(original_int)}")

demonstrate_passing_behavior(original_list, original_int)

print("\n--- AFTER FUNCTION CALL ---")
print(f"Original list: {original_list}, ID: {id(original_list)}")
print(f"Original int: {original_int}, ID: {id(original_int)}")

چه تغییرات قشنگی داریم روی؛ PostgreSql 18 شماهم دیدید ؟
برای من سه موردش خیلی جذاب هست؛
اولیش بالاخره؛ Asynchronous I/O بله منم خوندم فعلا فقط روی Read ولی همینم خوبه ۲-۳ برابر سرعت بیشتر اونم مفتی کیه که بدش بیاد ؟

دومیش؛ پشتیبانی کامل از UUIDv7 یعنی بدون دردسر می‌تونی حتی روی distributed system هم primary key کاملا یونیک داشته باشی.
تازه اگر پست‌های قبلی رو دنبال کرده باشید می‌دونید UUIDv7 برای ایندکس هم عملکرد بهتری داره (مشکلی که خیلی از پروژه‌ها با UUIDv4 داشتند و حالا تقریبا حل شده)

نهایتا یک سری Optimization های خاص که بصورت اتومات کوئری شما رو قبل از اجرا بهبود میده مثلا اگر OR زیاد باشه و بشه با Any تغییرش میده و ...


و یک اشاره هم بکنم به این پست (حدودا همین موقع‌ها ۲ سال پیش):
https://xn--r1a.website/pyHints/117
هنوزم دیر نشده؛ وقت بذارید براش و درکش کنید!


پ.ن؛
از دوستان اشاره کردند، created_at هم اگر یادمون بره به چخ نمی‌ریم 😁
شوخی خوبی بود، اگر نگرفتید:
بخاطر این هست که UUIDv7 بر اساس زمان هست

#Quick
یکی از دلایل خوب استفاده از containar اینه که آپدیت ورژن‌ها ساده‌تر باشه!

پروژه‌ای رو داشتم که هنوز از Postgres 12 استفاده می‌کرد؛ ۱۴ نوامبر ۲۰۲۴ پشتیبانی این نسخه تموم شده (سرچ کردم حفظ نیستم).
بعد بنده خدا مدیر شرکت می‌خواست optimization بزنه که مشکلاتش کمتر بشه، همین که ابزارهایی که استفاده می‌کردند رو آپدیت کردم و البته معماری سیستم رو کمی بهتر (مثلاً برای دسترسی به یک سری سرویس‌های داخلی چون نتونسته بودند کانفیگ کنند، درخواست‌ها رو از اینترنت رد می‌کردند که خودش باعث میشه latency زیاد بشه) بیش از ۷۰-۸۰٪ مشکلاتشون حل شد.
بخصوص میزان مصرف منابع!

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