تغییرات ساختار در تراکنش ها
شاید تعجب کنید، اما PostgreSQL اونقدر باحال هست که هیچ تغییری توی ساختار پایگاه داده رو ثبت نمی‌کنه تا زمانی که کل تراکنش با موفقیت انجام بشه! این ویژگی توی دنیای پایگاه‌های داده خیلی خاصه و خیالمون رو راحت میکنه.
بذارید با یه مثال براتون توضیح بدم. فرض کنید می‌خوایم یه ستون جدید به اسم "middle_name" به جدول "employees" اضافه کنیم. برای این کار، از دستورات زیر استفاده می‌کنیم:
دستور "BEGIN" شروع تراکنش رو مشخص میکنه و دستور "COMMIT" هم پایان تراکنش رو نشون میده. هر تغییری که بین این دو دستور انجام بشه، تا زمانی که دستور "COMMIT" اجرا نشه، ثبت نمیشه.
حالا اگه از دستور \d employees استفاده کنیم، می‌بینیم که ستون "middle_name" به جدول اضافه شده.
اما اگه یه تغییر پیچیده‌تر بخوایم انجام بدیم و یه اشتباه کوچولو توش داشته باشیم، چی میشه؟ مثلاً فرض کنید می‌خوایم چند تا ستون جدید برای آدرس به جدول اضافه کنیم، اما یادمون بره که برای ستون "postal_code" یه مقدار پیش‌فرض تعیین کنیم. دستورات زیر رو ببینید:
به خاطر اینکه کل این تغییرات داخل یه تراکنش قرار گرفتن، و چون برای ستون "postal_code" مقدار پیش‌فرض تعیین نکردیم، هیچ کدوم از تغییرات ثبت نمی‌شن! یعنی اگه دوباره از دستور \d employees استفاده کنیم، می‌بینیم که ستون‌های آدرس اضافه نشدن.
به این ویژگی فوق‌العاده می‌گن "Transactional DDL". توی پایگاه‌های داده دیگه که این ویژگی رو ندارن، ممکنه تغییرات نصفه و نیمه انجام بشن و همه چیز بهم بریزه. اما توی PostgreSQL، یا همه تغییرات با موفقیت انجام میشن، یا هیچ تغییری ثبت نمیشه.
#postgresql
@Code_Crafters
شاید تعجب کنید، اما PostgreSQL اونقدر باحال هست که هیچ تغییری توی ساختار پایگاه داده رو ثبت نمی‌کنه تا زمانی که کل تراکنش با موفقیت انجام بشه! این ویژگی توی دنیای پایگاه‌های داده خیلی خاصه و خیالمون رو راحت میکنه.
بذارید با یه مثال براتون توضیح بدم. فرض کنید می‌خوایم یه ستون جدید به اسم "middle_name" به جدول "employees" اضافه کنیم. برای این کار، از دستورات زیر استفاده می‌کنیم:
BEGIN;
ALTER TABLE employees ADD COLUMN middle_name VARCHAR(50) DEFAULT NULL;
COMMIT;
دستور "BEGIN" شروع تراکنش رو مشخص میکنه و دستور "COMMIT" هم پایان تراکنش رو نشون میده. هر تغییری که بین این دو دستور انجام بشه، تا زمانی که دستور "COMMIT" اجرا نشه، ثبت نمیشه.
حالا اگه از دستور \d employees استفاده کنیم، می‌بینیم که ستون "middle_name" به جدول اضافه شده.
اما اگه یه تغییر پیچیده‌تر بخوایم انجام بدیم و یه اشتباه کوچولو توش داشته باشیم، چی میشه؟ مثلاً فرض کنید می‌خوایم چند تا ستون جدید برای آدرس به جدول اضافه کنیم، اما یادمون بره که برای ستون "postal_code" یه مقدار پیش‌فرض تعیین کنیم. دستورات زیر رو ببینید:
BEGIN;
ALTER TABLE employees ADD COLUMN address_line_1 VARCHAR(50) DEFAULT NULL;
ALTER TABLE employees ADD COLUMN address_line_2 VARCHAR(50) DEFAULT NULL;
ALTER TABLE employees ADD COLUMN city VARCHAR(50) DEFAULT NULL;
ALTER TABLE employees ADD COLUMN province VARCHAR(50) DEFAULT NULL;
ALTER TABLE employees ADD COLUMN postal_code VARCHAR(50) NOT NULL;
COMMIT;
به خاطر اینکه کل این تغییرات داخل یه تراکنش قرار گرفتن، و چون برای ستون "postal_code" مقدار پیش‌فرض تعیین نکردیم، هیچ کدوم از تغییرات ثبت نمی‌شن! یعنی اگه دوباره از دستور \d employees استفاده کنیم، می‌بینیم که ستون‌های آدرس اضافه نشدن.
به این ویژگی فوق‌العاده می‌گن "Transactional DDL". توی پایگاه‌های داده دیگه که این ویژگی رو ندارن، ممکنه تغییرات نصفه و نیمه انجام بشن و همه چیز بهم بریزه. اما توی PostgreSQL، یا همه تغییرات با موفقیت انجام میشن، یا هیچ تغییری ثبت نمیشه.
#postgresql
@Code_Crafters
❤2
تراکنش‌های پیشرفته: نقطه‌ی نجات (SAVEPOINT)
یه ویژگی توپ دیگه از Postgres می‌خوام بهتون معرفی کنم که کار با تراکنش‌ها رو توی شرایط پیچیده خیلی راحت‌تر میکنه. اسمش "نقطه‌ی نجات" یا SAVEPOINT هست.
تصور کنید یه تراکنش دارید و چند تا دستور داخلش انجام می‌دید. شاید بخواهید یه جایی وسط کار، یه نقطه‌ی امن داشته باشید که اگه هر اتفاقی افتاد، بتونید به اونجا برگردید و همه چی رو از اول انجام بدید. SAVEPOINT دقیقا همینه!
بذار یه مثال بزنم. فرض کنید می‌خوایم یه کارمند جدید به اسم Bob Young اضافه کنیم، بهش چندتا وابسته اضافه کنیم و بعد تراکنش رو تموم کنیم. ولی ممکنه یه جا تو کار اشتباهی پیش بیاد. برای همین از SAVEPOINT استفاده می‌کنیم:
حالا اگه اسم Bob Young رو توی کارمندها Search کنیم، پیداش می‌کنیم، ولی وابسته‌هایش رو نمی‌بینیم. چرا؟ چون وقتی توی اضافه کردن وابسته‌ها یه خطایی پیش اومده، تراکنش رو به نقطه‌ی نجات برگردوندیم و فقط اضافه‌کردن Bob Young انجام شده.
می‌دونم این مثال یه کم مصنوعیه، ولی SAVEPOINT توی شرایط پیچیده‌تری که معمولاً برنامه‌نویس هم باهاش درگیره، خیلی کارآمد میشه. فعلاً شاید لازم نباشه ازش استفاده کنی، ولی خوبه بدونی همچین ویژگی‌ای وجود داره!
#postgresql
@Code_Crafters
یه ویژگی توپ دیگه از Postgres می‌خوام بهتون معرفی کنم که کار با تراکنش‌ها رو توی شرایط پیچیده خیلی راحت‌تر میکنه. اسمش "نقطه‌ی نجات" یا SAVEPOINT هست.
تصور کنید یه تراکنش دارید و چند تا دستور داخلش انجام می‌دید. شاید بخواهید یه جایی وسط کار، یه نقطه‌ی امن داشته باشید که اگه هر اتفاقی افتاد، بتونید به اونجا برگردید و همه چی رو از اول انجام بدید. SAVEPOINT دقیقا همینه!
بذار یه مثال بزنم. فرض کنید می‌خوایم یه کارمند جدید به اسم Bob Young اضافه کنیم، بهش چندتا وابسته اضافه کنیم و بعد تراکنش رو تموم کنیم. ولی ممکنه یه جا تو کار اشتباهی پیش بیاد. برای همین از SAVEPOINT استفاده می‌کنیم:
BEGIN;
INSERT INTO employees (first_name, last_name, start_date, salary, job_title, manager_id, department_id) VALUES ('Bob', 'Young', current_date, 1, 'Jr Director of the Highwire', 2, 2);
SAVEPOINT saved_employee; // این نقطه‌ی نجاته!
INSERT INTO dependents (first_name, last_name, employee_id) VALUES ('oldest', 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Bob' AND last_name = 'Young'));
INSERT INTO dependents (first_name, last_name, employee_id) VALUES (null, 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Bob' AND last_name = 'Young'));
ROLLBACK TO SAVEPOINT saved_employee; // اگه یه مشکلی پیش بیاد، به نقطه‌ی نجات برمی‌گردیم!
COMMIT;
حالا اگه اسم Bob Young رو توی کارمندها Search کنیم، پیداش می‌کنیم، ولی وابسته‌هایش رو نمی‌بینیم. چرا؟ چون وقتی توی اضافه کردن وابسته‌ها یه خطایی پیش اومده، تراکنش رو به نقطه‌ی نجات برگردوندیم و فقط اضافه‌کردن Bob Young انجام شده.
می‌دونم این مثال یه کم مصنوعیه، ولی SAVEPOINT توی شرایط پیچیده‌تری که معمولاً برنامه‌نویس هم باهاش درگیره، خیلی کارآمد میشه. فعلاً شاید لازم نباشه ازش استفاده کنی، ولی خوبه بدونی همچین ویژگی‌ای وجود داره!
#postgresql
@Code_Crafters
❤3👍1
محاصره در تراکنش ها
یه چیزی هست که شاید خیلی‌هاتون متوجهش نشده باشید. اونم اینه که توی PostgreSQL، حتی ساده‌ترین دستورات هم توی یه تراکنش انجام میشن! عجیبه نه؟
شاید بگید "خب چطور میشه فهمید؟ ما که تراکنشی شروع نکردیم!". ولی یه خورده صبر کنید... میتونیم یه دستوری اجرا کنیم که برامون نشون بده الان داخل کدوم تراکنشیم. بفرما:
حالا چی شد؟ یه عددی بهتون نشون داد، درسته؟ ولی ما که چیزی شروع نکردیم! چون اون عددی که دیدید، شناسه‌ی تراکنشیه که همین الان توش هستید.
حالا بازم همون دستور رو اجرا کنید. چی می‌بینید؟ اون عدد، یه واحد زیادتر شده! آره، این یعنی حتی همین یه دستور کوچیک، یه تراکنش جدید برا خودش باز کرده.
شاید بپرسید چرا انقدر ریزه‌کاری؟ خب، اینجوری PostgreSQL، خیالش راحته که هر تغییری که انجام میشه، یا کاملاً انجام میشه، یا اصلاً انجام نمیشه. اگه توی یه دستور مشکلی پیش بیاد، کل تراکنش باطل میشه و هیچ تغییری اعمال نمیشه.
پس یادتون باشه، توی PostgreSQL، همیشه تو یه تراکنش هستید، چه بخواهید، چه نخواهید! این یه جور مراقبت اضافه‌ست که داده‌هاتون رو سالم نگه می‌داره.
#postgresql
@Code_Crafters
یه چیزی هست که شاید خیلی‌هاتون متوجهش نشده باشید. اونم اینه که توی PostgreSQL، حتی ساده‌ترین دستورات هم توی یه تراکنش انجام میشن! عجیبه نه؟
شاید بگید "خب چطور میشه فهمید؟ ما که تراکنشی شروع نکردیم!". ولی یه خورده صبر کنید... میتونیم یه دستوری اجرا کنیم که برامون نشون بده الان داخل کدوم تراکنشیم. بفرما:
SELECT txid_current();
حالا چی شد؟ یه عددی بهتون نشون داد، درسته؟ ولی ما که چیزی شروع نکردیم! چون اون عددی که دیدید، شناسه‌ی تراکنشیه که همین الان توش هستید.
حالا بازم همون دستور رو اجرا کنید. چی می‌بینید؟ اون عدد، یه واحد زیادتر شده! آره، این یعنی حتی همین یه دستور کوچیک، یه تراکنش جدید برا خودش باز کرده.
شاید بپرسید چرا انقدر ریزه‌کاری؟ خب، اینجوری PostgreSQL، خیالش راحته که هر تغییری که انجام میشه، یا کاملاً انجام میشه، یا اصلاً انجام نمیشه. اگه توی یه دستور مشکلی پیش بیاد، کل تراکنش باطل میشه و هیچ تغییری اعمال نمیشه.
پس یادتون باشه، توی PostgreSQL، همیشه تو یه تراکنش هستید، چه بخواهید، چه نخواهید! این یه جور مراقبت اضافه‌ست که داده‌هاتون رو سالم نگه می‌داره.
#postgresql
@Code_Crafters
👍5❤2
چرا جنگو فریمورک محبوبی هست؟؟؟
بیاید یکم راجبش حرف بزنیم
جنگو خیلی از موارد برنامه نویسی مدرن رو براتون فراهم میکنه بدون اینکه خودتون راجبش حتی دانش کافی داشته باشید و بدونید، که میتونیم به design patterns و clean architecture اشاره کرد
بارها به بچه‌ها گوشزد کردم که business logic رو فراموش نکنید و جدی بگیرید ،کار سختی نیست یک فایل با نام services.py بسازید و موارد مربوط به orm رو داخلش بنویسید (یک دایرکتوری با نام services بسازید و ماژولهای پایتونی خودتون رو داخلش بزارید) حالا کافیه با dependency inversion principle رو بدونید و داخل کدهاتون رعایت کنید
خب چه اتفاقی افتاد؟؟؟
الان شما اومدین و app رو به سه لایه تقسیم کردید لایه application ، لایه service ، لایه infrastructure , خب این چه مزیتی داره برامون
بیایم ببینیم هر لایه شامل چه چیزی میشه؟؟؟
شما دارید ذره ذره به سمت bounded context ها میرید
خب اینکه گفتیم به چه معناست اصلا؟؟
نکته: ما همیشه میگیم تسک بزرگ رو به چند تسک کوچیکتر بشکنید (بصورت منطقی البته) یک کلاس بزرگ ننویسید یک تابع طولانی نسازید
ما اینهارو رعایت کردیم به کجا داریم میرسیم؟؟؟
جالبه بدونید که داریم به سبک معماری DDD نزدیک میشیم
بیایید ادامه بدیم
خب اصل SoC میاد وسط(پروژه میتونه به بخش‌های کوچکتر و قابل مدیریت تر تقسیم بشه، اجزا میتونه میکروسرویس یا ماژولهای مستقل در یک مونولیت باشند)
همین ترکیب بالا رو بزاریم داخل microservice ، پروژه خودمون رو به چند سرویس منطقی و درست تقسیم کنیم، مدلهای هر سرویس رو داخل یک دیتابیس جدا بزاریم ، FKهای مدل رو به Bigint تبدیل کنیم ارتباط بین سرویس‌ها رو مدیریت و هندل کنیم (اینجا rabbitmq سلام میرسونه) الزامات سرویس‌های بیس رو انجام بدیم (این شد bounded context)
چه اتفاقی داره میافته ؟؟؟
این معماری برای پروژه‌های بزرگ مناسبه و اگر یک پروژه قدیمی با حداقل 20 app دارید لازم نیست تعطیلش کنید فقط کافیه با DDD تبدیلش کنید
@code_crafters
بیاید یکم راجبش حرف بزنیم
جنگو خیلی از موارد برنامه نویسی مدرن رو براتون فراهم میکنه بدون اینکه خودتون راجبش حتی دانش کافی داشته باشید و بدونید، که میتونیم به design patterns و clean architecture اشاره کرد
بارها به بچه‌ها گوشزد کردم که business logic رو فراموش نکنید و جدی بگیرید ،کار سختی نیست یک فایل با نام services.py بسازید و موارد مربوط به orm رو داخلش بنویسید (یک دایرکتوری با نام services بسازید و ماژولهای پایتونی خودتون رو داخلش بزارید) حالا کافیه با dependency inversion principle رو بدونید و داخل کدهاتون رعایت کنید
خب چه اتفاقی افتاد؟؟؟
الان شما اومدین و app رو به سه لایه تقسیم کردید لایه application ، لایه service ، لایه infrastructure , خب این چه مزیتی داره برامون
بیایم ببینیم هر لایه شامل چه چیزی میشه؟؟؟
Application: urls, viewsمن این همه سردرد رو واسه چی دارم تحمل میکنم خدایی؟؟؟
درخواست‌های مشتری در این قسمت مورد پردازش قرار میگیره که داده‌های مورد نیاز رو از لایه service میگیره و اون رو تبدیل میکنه به مقداری که قابل خوندن واسه مشتری هست که میتونه http, drf, grpc و ... باشه
Service:
این لایه همون مبحث business logic رو ارائه میده و تمام موارد مورد نیاز رو در خودش هندل میکنه(وظیفه ذخیره و بازیابی موجودیت‌هارو برامون هندل میکنه) اینجا orm django کار میکنه لایه انتزاع از دیتابیس رو میسازه و بواسطه شی گرایی مارو از پیچیدگی کار رها میکنه
Infrastructure: migrations , models
تو این قسمت شما موجودیت‌ها و مجموعه‌ها رو در یک سیستم ذخیره ساز، ذخیره میکنید ،اینکار با استفاده از مدلهای جنگو و queries صورت میگیره ، بخش مایگریشن‌ها هم اینجا صورت میگیره
شما دارید ذره ذره به سمت bounded context ها میرید
خب اینکه گفتیم به چه معناست اصلا؟؟
نکته: ما همیشه میگیم تسک بزرگ رو به چند تسک کوچیکتر بشکنید (بصورت منطقی البته) یک کلاس بزرگ ننویسید یک تابع طولانی نسازید
ما اینهارو رعایت کردیم به کجا داریم میرسیم؟؟؟
جالبه بدونید که داریم به سبک معماری DDD نزدیک میشیم
بیایید ادامه بدیم
خب اصل SoC میاد وسط(پروژه میتونه به بخش‌های کوچکتر و قابل مدیریت تر تقسیم بشه، اجزا میتونه میکروسرویس یا ماژولهای مستقل در یک مونولیت باشند)
همین ترکیب بالا رو بزاریم داخل microservice ، پروژه خودمون رو به چند سرویس منطقی و درست تقسیم کنیم، مدلهای هر سرویس رو داخل یک دیتابیس جدا بزاریم ، FKهای مدل رو به Bigint تبدیل کنیم ارتباط بین سرویس‌ها رو مدیریت و هندل کنیم (اینجا rabbitmq سلام میرسونه) الزامات سرویس‌های بیس رو انجام بدیم (این شد bounded context)
چه اتفاقی داره میافته ؟؟؟
هر بخش داره بصورت مستقل توسعه داده میشهبه معماری DDD خوش آمدید
نگرانی حاصل از پیچیدگی داره رفع میشه
بهبود توسعه کد و پایداری داره بخوبی اتفاق میافته
پایگاه داده از شکستن داره خارج میشه
این معماری برای پروژه‌های بزرگ مناسبه و اگر یک پروژه قدیمی با حداقل 20 app دارید لازم نیست تعطیلش کنید فقط کافیه با DDD تبدیلش کنید
یک معماری میکروسرویس پیاده سازی کنید
که شامل چند سرویس میشه
هر سرویس در دل خودش چندتا app داره
هر app طبق DDD به سه لایه application , services , infrastructure تقسیم میشه و دیتابیس خودش رو داره
خود جنگو براتون clean architecture رو تا سطح بالایی براتون اتخاذ میکنه
در کدهاتون dependency inversion principle رو رعایت کنید
@code_crafters
❤4👍2
پارتیشن‌بندی | Partitioning
فکر کن یه انبار بزرگ داری پر از وسایل. بعضی هر روز استفاده میشن، بعضی یه ماه یه بار، بعضی سال به سال یه نگاه بندازیشون میکنی، و یه سری هم هستن که دیگه اصلا به کار نمیان. اگه همشون رو یه جا و به یه شکل نگه داری، انبارت هم شلوغ میشه، هم پیدا کردن سخته، هم نگهداری هزینه‌بر میشه.
پارتیشن‌بندی دقیقا همون چوب جادویی برای انبار داده‌هایت محسوب میشه! با پارتیشن‌بندی، داده‌هات رو بر اساس استفاده و اهمیتشون طبقه‌بندی میکنی. به این ترتیب، اون اطلاعاتی که زیاد به کار نمیان یا دیگه قدیمی شدن رو توی بخش‌های کم‌هزینه‌تر و دورتر انبار (مثلا آرشیو) می‌ذاری، درحالیکه چیزایی که همش دم دستت هستن رو جلوی دست نگه می‌داری (مثل دیتابیس اصلی).
حالا چطور این تقسیم و بخش‌بندی هزینه رو کم میکنه؟ یه مثال بزنیم: فرض کن انبارت پر از لباس‌های قدیمی باشه. خیلی از این لباس‌ها رو دیگه نمی‌پوشی. خب اگه همشون رو توی کمد رختخواب نگه داری، هم جای بیشتری می‌گیرن، هم هر وقت بخوای یه لباس جدید بذاری، باید همه رو جابه‌جا کنی و هم تمیز کردنشون سخته. ولی اگه اونایی که دیگه استفاده نمیشه رو ببری توی چمدون و زیر تخت بذاری، هم کمدت خلوت و مرتب‌تر میشه، هم دیگه لازم نیست هر دفعه همه رو جابه‌جا کنی و گردگیریشون کنی. پارتیشن‌بندی داده‌ها هم دقیقا همینطوره. اطلاعات قدیمی و کم‌کاربرد رو از دیتابیس اصلی درمیاری و به یه جای دیگه‌ای منتقل میکنی، مثلا یه هارددیسک دیگه‌ای یا یه سیستم آرشیو. اینجوری هم دیتابیس اصلی سریع‌تر و کوچیکتر میشه، هم هزینه‌ی نگهداری کم‌تر میشه.
پس پارتیشن‌بندی یه راه بی‌نظیره برای اینکه هم انبار اطلاعاتی منظمی داشته باشی، هم هزینه نگهداری رو مدیریت کنی. دیگه لازم نیست نگران انبار شلوغ و هزینه‌های اضافی باشی!
👩💻 #postgresql
@Code_Crafters
فکر کن یه انبار بزرگ داری پر از وسایل. بعضی هر روز استفاده میشن، بعضی یه ماه یه بار، بعضی سال به سال یه نگاه بندازیشون میکنی، و یه سری هم هستن که دیگه اصلا به کار نمیان. اگه همشون رو یه جا و به یه شکل نگه داری، انبارت هم شلوغ میشه، هم پیدا کردن سخته، هم نگهداری هزینه‌بر میشه.
پارتیشن‌بندی دقیقا همون چوب جادویی برای انبار داده‌هایت محسوب میشه! با پارتیشن‌بندی، داده‌هات رو بر اساس استفاده و اهمیتشون طبقه‌بندی میکنی. به این ترتیب، اون اطلاعاتی که زیاد به کار نمیان یا دیگه قدیمی شدن رو توی بخش‌های کم‌هزینه‌تر و دورتر انبار (مثلا آرشیو) می‌ذاری، درحالیکه چیزایی که همش دم دستت هستن رو جلوی دست نگه می‌داری (مثل دیتابیس اصلی).
حالا چطور این تقسیم و بخش‌بندی هزینه رو کم میکنه؟ یه مثال بزنیم: فرض کن انبارت پر از لباس‌های قدیمی باشه. خیلی از این لباس‌ها رو دیگه نمی‌پوشی. خب اگه همشون رو توی کمد رختخواب نگه داری، هم جای بیشتری می‌گیرن، هم هر وقت بخوای یه لباس جدید بذاری، باید همه رو جابه‌جا کنی و هم تمیز کردنشون سخته. ولی اگه اونایی که دیگه استفاده نمیشه رو ببری توی چمدون و زیر تخت بذاری، هم کمدت خلوت و مرتب‌تر میشه، هم دیگه لازم نیست هر دفعه همه رو جابه‌جا کنی و گردگیریشون کنی. پارتیشن‌بندی داده‌ها هم دقیقا همینطوره. اطلاعات قدیمی و کم‌کاربرد رو از دیتابیس اصلی درمیاری و به یه جای دیگه‌ای منتقل میکنی، مثلا یه هارددیسک دیگه‌ای یا یه سیستم آرشیو. اینجوری هم دیتابیس اصلی سریع‌تر و کوچیکتر میشه، هم هزینه‌ی نگهداری کم‌تر میشه.
پس پارتیشن‌بندی یه راه بی‌نظیره برای اینکه هم انبار اطلاعاتی منظمی داشته باشی، هم هزینه نگهداری رو مدیریت کنی. دیگه لازم نیست نگران انبار شلوغ و هزینه‌های اضافی باشی!
@Code_Crafters
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
سرعتِ جت با پارتیشن‌بندی: وقتی انبارت مرتب باشه، پیدا کردن وسایل هم سریع‌تره! 🚀
یکی از دلایلی که خیلی‌ها عاشق پارتیشن‌بندی هستن، افزایش سرعت جستجو توی داده‌هاست. تصور کن انبار وسایل‌ت مرتب و تفکیک شده باشه. اگه بخوای یه چیز خاص رو پیدا کنی، خیلی سریع‌تر پیداش میکنی، نه؟ پارتیشن‌بندی هم دقیقا همین کار رو با داده‌هات میکنه.
وقتی داده‌هات رو بر اساس تاریخ یا یه کلید خاص پارتیشن‌بندی میکنی، جستجوها به جای اینکه کل انبار رو زیر و رو کنن، مستقیم به بخش مربوطه می‌رن. مثل اینه که تو انبارت، برای هر دسته از وسایل یه قفسه جدا داشته باشی. حالا اگه دنبال کلاه زمستونی می‌گردی، مستقیم به قفسه‌ی لباس‌های زمستونی می‌ری، نه اینکه تک‌تک سبدهای خونه رو بگردی!
اینجوری جستجو خیلی سریع‌تر انجام میشه، مخصوصا وقتی از ایندکس‌ها یا همون برچسب‌های راهنما هم استفاده کنی. دیگه خبری از انتظارای طولانی برای پیدا کردن یه تیکه اطلاعات توی یه انبار داده‌های به‌هم‌ریخته نیست. همه چی مرتب و منظم، با دسترسی سریع و یه کلیک!
👩💻 #postgresql
@Code_Crafters
یکی از دلایلی که خیلی‌ها عاشق پارتیشن‌بندی هستن، افزایش سرعت جستجو توی داده‌هاست. تصور کن انبار وسایل‌ت مرتب و تفکیک شده باشه. اگه بخوای یه چیز خاص رو پیدا کنی، خیلی سریع‌تر پیداش میکنی، نه؟ پارتیشن‌بندی هم دقیقا همین کار رو با داده‌هات میکنه.
وقتی داده‌هات رو بر اساس تاریخ یا یه کلید خاص پارتیشن‌بندی میکنی، جستجوها به جای اینکه کل انبار رو زیر و رو کنن، مستقیم به بخش مربوطه می‌رن. مثل اینه که تو انبارت، برای هر دسته از وسایل یه قفسه جدا داشته باشی. حالا اگه دنبال کلاه زمستونی می‌گردی، مستقیم به قفسه‌ی لباس‌های زمستونی می‌ری، نه اینکه تک‌تک سبدهای خونه رو بگردی!
اینجوری جستجو خیلی سریع‌تر انجام میشه، مخصوصا وقتی از ایندکس‌ها یا همون برچسب‌های راهنما هم استفاده کنی. دیگه خبری از انتظارای طولانی برای پیدا کردن یه تیکه اطلاعات توی یه انبار داده‌های به‌هم‌ریخته نیست. همه چی مرتب و منظم، با دسترسی سریع و یه کلیک!
@Code_Crafters
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
انبار داده‌هات رو جورچین کن: با پارتیشن‌بندی‌های مختلف!
تصور کن یه انبار بزرگ داری پر از وسایل. حالا می‌خوای اونارو تو قفسه‌ها بچینی، ولی یه مدل چیدمان جواب نمیده. خب، پارتیشن‌بندی هم دقیقا همینطوره! راه‌های مختلفی برای تفکیک و چیدمان داده‌هات داری که به نوع اطلاعاتت بستگی داره.
چیدمان بر اساس بازه (Range): این محبوب‌ترین مدل برای دسته‌های زمانی یا داده‌های عددی مثل سال، ماه، روزه. مثلا میتونی اطلاعات فروش سال ۲۰۲۳ رو تو یه قفسه، سال ۲۰۲۴ رو تو یه قفسه دیگه بذاری. پیدا کردن اطلاعات یه سال خاص سریع و آسون میشه.
چیدمان بر اساس لیست (List): اگه داده‌هات یه دسته‌بندی مشخص دارن، مثل موقعیت جغرافیایی یا دسته‌های محصول، میتونی از این مدل استفاده کنی. مثلا اطلاعات مشتریای تهران رو تو یه قفسه، مشتریای مشهد رو تو یه قفسه دیگه بذاری. جستجو بر اساس دسته‌های خاص به راحتی انجام میشه.
چیدمان بر اساس هش (Hash): وقتی دسته‌بندی مشخصی برای داده‌هات نداری، میتونی از این مدل استفاده کنی. یه کد هش به هر تیکه اطلاعات اختصاص داده میشه و اونو تو قفسه مربوطه میذاره. شبیه یه انبار با برچسب‌های مخفیه!
چیدمان ترکیبی (Composite): اگه دلت می‌خواد از ترکیب مدلهای مختلف استفاده کنی، این گزینه ایده‌آله. مثلا میتونی داده‌های فروش رو هم بر اساس سال (بازه) و هم بر اساس نوع محصول (لیست) دسته بندی کنی. یه انبار مرتب و تفکیک‌شده‌ی دوبل!
این فقط یه نگاه کلی به مدلهای مختلف پارتیشن‌بندی بود. حالا میتونی انتخاب کنی که کدوم مدل برای انبار داده‌هایت بهتره و یه دیتابیس منظم و دسترسی‌پذیر بسازی!
👩💻 #postgresql
@Code_Crafters
تصور کن یه انبار بزرگ داری پر از وسایل. حالا می‌خوای اونارو تو قفسه‌ها بچینی، ولی یه مدل چیدمان جواب نمیده. خب، پارتیشن‌بندی هم دقیقا همینطوره! راه‌های مختلفی برای تفکیک و چیدمان داده‌هات داری که به نوع اطلاعاتت بستگی داره.
چیدمان بر اساس بازه (Range): این محبوب‌ترین مدل برای دسته‌های زمانی یا داده‌های عددی مثل سال، ماه، روزه. مثلا میتونی اطلاعات فروش سال ۲۰۲۳ رو تو یه قفسه، سال ۲۰۲۴ رو تو یه قفسه دیگه بذاری. پیدا کردن اطلاعات یه سال خاص سریع و آسون میشه.
چیدمان بر اساس لیست (List): اگه داده‌هات یه دسته‌بندی مشخص دارن، مثل موقعیت جغرافیایی یا دسته‌های محصول، میتونی از این مدل استفاده کنی. مثلا اطلاعات مشتریای تهران رو تو یه قفسه، مشتریای مشهد رو تو یه قفسه دیگه بذاری. جستجو بر اساس دسته‌های خاص به راحتی انجام میشه.
چیدمان بر اساس هش (Hash): وقتی دسته‌بندی مشخصی برای داده‌هات نداری، میتونی از این مدل استفاده کنی. یه کد هش به هر تیکه اطلاعات اختصاص داده میشه و اونو تو قفسه مربوطه میذاره. شبیه یه انبار با برچسب‌های مخفیه!
چیدمان ترکیبی (Composite): اگه دلت می‌خواد از ترکیب مدلهای مختلف استفاده کنی، این گزینه ایده‌آله. مثلا میتونی داده‌های فروش رو هم بر اساس سال (بازه) و هم بر اساس نوع محصول (لیست) دسته بندی کنی. یه انبار مرتب و تفکیک‌شده‌ی دوبل!
این فقط یه نگاه کلی به مدلهای مختلف پارتیشن‌بندی بود. حالا میتونی انتخاب کنی که کدوم مدل برای انبار داده‌هایت بهتره و یه دیتابیس منظم و دسترسی‌پذیر بسازی!
@Code_Crafters
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍1
بیا یه انبار داده‌های باحال بسازیم: مثال پارتیشن‌بندی با PostgreSQL
فکر کن یه عالمه داده درباره ترموستات‌های هوشمند داریم. دما، تاریخ، وضعیت روشن/خاموش و یه عالمه اطلاعات دیگه. خب، چطوری قراره این انبوه اطلاعات رو منظم و مرتب نگه داریم؟ اینجا با پارتیشن‌بندی تو PostgreSQL آشنا میشیم که حکم قفسه‌چین‌های حرفه‌ای رو دارن!
اول یه نگاهی به انبارمون بندازیم:
این دستور ۱۰ تا ردیف اول از جداول thermostat رو نشون میده. هر ردیف شامل تاریخ، شناسه‌ی ترموستات، دمای فعلی و وضعیتش هست. حالا میتونیم این انبار رو با پارتیشن‌بندی مرتب‌تر و کارآمدتر کنیم. تو قسمت بعدی قراره ببینیم چطور میشه این کار رو انجام داد!
آماده‌ای بریم سراغ جادوی پارتیشن‌بندی با PostgreSQL؟⚡️
👩💻 #postgresql
@Code_Crafters
فکر کن یه عالمه داده درباره ترموستات‌های هوشمند داریم. دما، تاریخ، وضعیت روشن/خاموش و یه عالمه اطلاعات دیگه. خب، چطوری قراره این انبوه اطلاعات رو منظم و مرتب نگه داریم؟ اینجا با پارتیشن‌بندی تو PostgreSQL آشنا میشیم که حکم قفسه‌چین‌های حرفه‌ای رو دارن!
اول یه نگاهی به انبارمون بندازیم:
SELECT * FROM thermostat LIMIT 10;
این دستور ۱۰ تا ردیف اول از جداول thermostat رو نشون میده. هر ردیف شامل تاریخ، شناسه‌ی ترموستات، دمای فعلی و وضعیتش هست. حالا میتونیم این انبار رو با پارتیشن‌بندی مرتب‌تر و کارآمدتر کنیم. تو قسمت بعدی قراره ببینیم چطور میشه این کار رو انجام داد!
آماده‌ای بریم سراغ جادوی پارتیشن‌بندی با PostgreSQL؟
@Code_Crafters
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1
ساخت قفسه‌های دیجیتالی: ایجاد جدول پارتیشن‌بندی‌شده
خب، حالا وقتشه دست به کار شیم و قفسه‌های دیجیتالیمون رو بسازیم! برای این کار، یه جدول جدید درست می‌کنیم که از همون اول پارتیشن‌بندی‌شده باشه. مثل اینکه قبل از چیدن وسایل تو انبار، قفسه‌ها رو آماده کنیم.
دستور زیر رو بزن تا جدول جدید iot_thermostat ساخته بشه:
اینجا به PostgreSQL میگیم که جدول iot_thermostat رو با پارتیشن‌بندی بر اساس بازه‌های زمانی (RANGE (thetime)) درست کنه. یعنی قراره اطلاعات ترموستات‌ها رو بر اساس تاریخشون توی قفسه‌های جداگانه بچینیم.
یادت باشه که واسه پیدا کردن سریع‌تر وسایل توی انبار، لازمه برچسب‌های راهنما داشته باشیم. برای این کار از ایندکس‌ها استفاده می‌کنیم. دستور زیر یه ایندکس روی فیلد thetime میسازه:
اینجوری PostgreSQL میتونه خیلی سریع‌تر اطلاعات رو بر اساس تاریخ پیدا کنه. دیگه لازم نیست کل انبار رو زیر و رو کنه!
حالا قفسه‌های دیجیتالیمون آماده‌ست که اطلاعات ترموستات‌ها رو توش بچینیم. تو قسمت بعدی می‌بینیم چطوری این کار رو انجام میدیم!
👩💻 #postgresql
@Code_Crafters
خب، حالا وقتشه دست به کار شیم و قفسه‌های دیجیتالیمون رو بسازیم! برای این کار، یه جدول جدید درست می‌کنیم که از همون اول پارتیشن‌بندی‌شده باشه. مثل اینکه قبل از چیدن وسایل تو انبار، قفسه‌ها رو آماده کنیم.
دستور زیر رو بزن تا جدول جدید iot_thermostat ساخته بشه:
CREATE TABLE iot_thermostat (
thetime timestamptz,
sensor_id int,
current_temperature numeric (3,1),
thermostat_status text
) PARTITION BY RANGE (thetime);
اینجا به PostgreSQL میگیم که جدول iot_thermostat رو با پارتیشن‌بندی بر اساس بازه‌های زمانی (RANGE (thetime)) درست کنه. یعنی قراره اطلاعات ترموستات‌ها رو بر اساس تاریخشون توی قفسه‌های جداگانه بچینیم.
یادت باشه که واسه پیدا کردن سریع‌تر وسایل توی انبار، لازمه برچسب‌های راهنما داشته باشیم. برای این کار از ایندکس‌ها استفاده می‌کنیم. دستور زیر یه ایندکس روی فیلد thetime میسازه:
CREATE INDEX ON iot_thermostat(thetime);
اینجوری PostgreSQL میتونه خیلی سریع‌تر اطلاعات رو بر اساس تاریخ پیدا کنه. دیگه لازم نیست کل انبار رو زیر و رو کنه!
حالا قفسه‌های دیجیتالیمون آماده‌ست که اطلاعات ترموستات‌ها رو توش بچینیم. تو قسمت بعدی می‌بینیم چطوری این کار رو انجام میدیم!
@Code_Crafters
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2
برچسب‌های روی قفسه‌ها: ایجاد پارتیشن‌های جداگانه
یادت باشه که قراره اطلاعات ترموستات‌ها رو بر اساس تاریخشون توی قفسه‌های جداگانه بچینیم. الان وقتشه که این قفسه‌ها رو با برچسب‌های مخصوصشون بسازیم. هر برچسب یه بازه‌ی زمانی رو مشخص میکنه تا PostgreSQL بدونه هر تیکه اطلاعات باید کجا بره.
دستور زیر قفسه‌هایی برای تاریخ‌های ۲۳ جولای تا ۴ آگوست میسازه:
یعنی از این به بعد، هر اطلاعاتی که مربوط به تاریخ ۲۳ جولای باشه، مستقیم میره توی قفسه iot_thermostat07232022 و با اطلاعات روزهای دیگه قاطی نمیشه. اینجوری هم انبارت مرتب میمونه، هم پیدا کردن وسایل راحت‌تر میشه.
حالا اگه بخوای اطلاعات یه روز خاص رو ببینی، فقط کافیه به قفسه مربوط به اون روز سر بزنی؛ نیازی نیست کل انبار رو بگردی. این یعنی سرعتِ جت در جستجو و دسترسی به داده‌ها!
👩💻 #postgresql
@Code_Crafters
یادت باشه که قراره اطلاعات ترموستات‌ها رو بر اساس تاریخشون توی قفسه‌های جداگانه بچینیم. الان وقتشه که این قفسه‌ها رو با برچسب‌های مخصوصشون بسازیم. هر برچسب یه بازه‌ی زمانی رو مشخص میکنه تا PostgreSQL بدونه هر تیکه اطلاعات باید کجا بره.
دستور زیر قفسه‌هایی برای تاریخ‌های ۲۳ جولای تا ۴ آگوست میسازه:
SQL
CREATE TABLE iot_thermostat07232022 PARTITION OF iot_thermostat FOR VALUES FROM ('2022-07-23 00:00:000') TO ('2022-07-24 00:00:000');
CREATE TABLE iot_thermostat07242022 PARTITION OF iot_thermostat FOR VALUES FROM ('2022-07-24 00:00:000') TO ('2022-07-25 00:00:000');
CREATE TABLE iot_thermostat07252022 PARTITION OF iot_thermostat FOR VALUES FROM ('2022-07-25 00:00:000') TO ('2022-07-26 00:00:000');
CREATE TABLE iot_thermostat07262022 PARTITION OF iot_thermostat FOR VALUES FROM ('2022-07-26 00:00:000') TO ('2022-07-27 00:00:000');
CREATE TABLE iot_thermostat07272022 PARTITION OF iot_thermostat FOR VALUES FROM ('2022-07-27 00:00:000') TO ('2022-07-28 00:00:000');
CREATE TABLE iot_thermostat07282022 PARTITION OF iot_thermostat FOR VALUES FROM ('2022-07-28 00:00:000') TO ('2022-07-29 00:00:000');
CREATE TABLE iot_thermostat07292022 PARTITION OF iot_thermostat FOR VALUES FROM ('2022-07-29 00:00:000') TO ('2022-07-30 00:00:000');
CREATE TABLE iot_thermostat07302022 PARTITION OF iot_thermostat FOR VALUES FROM ('2022-07-30 00:00:000') TO ('2022-07-31 00:00:000');
CREATE TABLE iot_thermosta07312022 PARTITION OF iot_thermostat FOR VALUES FROM ('2022-07-31 00:00:000') TO ('2022-08-01 00:00:000');
CREATE TABLE iot_thermostat08012022 PARTITION OF iot_thermostat FOR VALUES FROM ('2022-08-01 00:00:000') TO ('2022-08-02 00:00:000');
CREATE TABLE iot_thermostat08022022 PARTITION OF iot_thermostat FOR VALUES FROM ('2022-08-02 00:00:000') TO ('2022-08-03 00:00:000');
CREATE TABLE iot_thermostat08032022 PARTITION OF iot_thermostat FOR VALUES FROM ('2022-08-03 00:00:000') TO ('2022-08-04 00:00:000');
یعنی از این به بعد، هر اطلاعاتی که مربوط به تاریخ ۲۳ جولای باشه، مستقیم میره توی قفسه iot_thermostat07232022 و با اطلاعات روزهای دیگه قاطی نمیشه. اینجوری هم انبارت مرتب میمونه، هم پیدا کردن وسایل راحت‌تر میشه.
حالا اگه بخوای اطلاعات یه روز خاص رو ببینی، فقط کافیه به قفسه مربوط به اون روز سر بزنی؛ نیازی نیست کل انبار رو بگردی. این یعنی سرعتِ جت در جستجو و دسترسی به داده‌ها!
@Code_Crafters
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1
چیدن وسایل توی قفسه‌ها: وارد کردن اطلاعات به پارتیشن‌ها
خب، قفسه‌ها آماده‌ان، برچسب‌ها خوردن، حالا وقتشه وسایل رو توشون بچینیم! اینجا با یه دستور ساده، اطلاعات رو از جدول اصلی thermostat به جدول پارتیشن‌بندی‌شده iot_thermostat منتقل می‌کنیم:
نگران نباش، لازم نیست به PostgreSQL بگی کدوم اطلاعات باید کجا بره. خودش حواسش هست و هر تیکه اطلاعات رو بر اساس تاریخش، توی قفسه مناسبش میذاره. مثل یه ربات قفسه‌چین حرفه‌ای!🤖
برای اینکه مطمئن بشی همه چی درست انجام شده، میتونی یه نگاهی به یکی از قفسه‌ها بندازی:
این دستور ۱۰ تا ردیف اول از قفسه‌ی ۲۴ جولای رو نشون میده. اگه همه چی مرتب باشه، فقط اطلاعات مربوط به همون روز رو باید ببینی.
حالا انبار داده‌هات حسابی مرتب و منظم شده! هم پیدا کردن اطلاعات راحت‌تره، هم مدیریتش آسون‌تره. تبریک میگم، تو یه قفسه‌چین حرفه‌ای شدی!
👩💻 #postgresql
@Code_Crafters
خب، قفسه‌ها آماده‌ان، برچسب‌ها خوردن، حالا وقتشه وسایل رو توشون بچینیم! اینجا با یه دستور ساده، اطلاعات رو از جدول اصلی thermostat به جدول پارتیشن‌بندی‌شده iot_thermostat منتقل می‌کنیم:
INSERT INTO iot_thermostat SELECT * FROM thermostat;
نگران نباش، لازم نیست به PostgreSQL بگی کدوم اطلاعات باید کجا بره. خودش حواسش هست و هر تیکه اطلاعات رو بر اساس تاریخش، توی قفسه مناسبش میذاره. مثل یه ربات قفسه‌چین حرفه‌ای!
برای اینکه مطمئن بشی همه چی درست انجام شده، میتونی یه نگاهی به یکی از قفسه‌ها بندازی:
SELECT * FROM iot_thermostat07242022 LIMIT 10;
این دستور ۱۰ تا ردیف اول از قفسه‌ی ۲۴ جولای رو نشون میده. اگه همه چی مرتب باشه، فقط اطلاعات مربوط به همون روز رو باید ببینی.
حالا انبار داده‌هات حسابی مرتب و منظم شده! هم پیدا کردن اطلاعات راحت‌تره، هم مدیریتش آسون‌تره. تبریک میگم، تو یه قفسه‌چین حرفه‌ای شدی!
@Code_Crafters
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2
انبار مرتب، انبار بی‌دردسر: چرخش پارتیشن‌ها
حالا فرض کن دیگه به اطلاعات خیلی قدیمی نیاز نداری و فقط داده‌های اخیر مهم هستن. مثلا می‌خوای اطلاعات ۲۳ جولای رو تو یه جای دیگه آرشیو کنی و از انبار اصلی حذف کنی. اینجا یه ترفند جادویی به اسم چرخش پارتیشن به کار میاد!
با دستور زیر، قفسه مربوط به ۲۳ جولای (iot_thermostat07232022) رو از انبار اصلی جدا می‌کنیم:
حالا اون یه قفسه مستقل شده و دیگه تو انبار اصلی نیست. میتونی اونو به یه انبار آرشیو منتقل کنی تا فقط اطلاعات مهم و اخیر تو انبار اصلی باقی بمونن.
البته قرار نیست انبار خالی بمونه! باید یه قفسه جدید هم برای اطلاعات جدید بسازیم. دستور زیر یه قفسه با برچسب iot_thermostat0842022 ایجاد میکنه که اطلاعات ۴ و ۵ آگوست رو توش جا میده:
حالا با یه چرخش مرتب، قفسه‌های قدیمی رو آرشیو می‌کنیم و قفسه‌های جدید برای اطلاعات جدید اضافه می‌کنیم. اینجوری انبارت همیشه مرتب و منظم میمونه و فقط داده‌های مهم و قابل استفاده توش نگه می‌داری.
اگه قراره این چرخش رو هر روز انجام بدی، میتونی از یه ابزار به اسم cron job استفاده کنی تا همه چی به صورت خودکار و بدون زحمت انجام بشه. دیگه لازم نیست خودت قفسه‌ها رو جابه‌جا کنی!
یادت باشه، پارتیشن‌بندی یه ابزار جادوییه که بهت کمک میکنه انبار داده‌هات رو هم تمیز و مرتب نگه داری، هم مدیریت و دسترسی به اطلاعات رو آسون‌تر کنه. با چرخش پارتیشن هم میتونی اطلاعات قدیمی رو حفظ کنی، بدون اینکه انبار اصلیت شلوغ و بی‌نظم بشه. خب، حالا قفسه‌دار حرفه‌ای و مرتبی شدی!
👩💻 #postgresql
@Code_Crafters
حالا فرض کن دیگه به اطلاعات خیلی قدیمی نیاز نداری و فقط داده‌های اخیر مهم هستن. مثلا می‌خوای اطلاعات ۲۳ جولای رو تو یه جای دیگه آرشیو کنی و از انبار اصلی حذف کنی. اینجا یه ترفند جادویی به اسم چرخش پارتیشن به کار میاد!
با دستور زیر، قفسه مربوط به ۲۳ جولای (iot_thermostat07232022) رو از انبار اصلی جدا می‌کنیم:
ALTER TABLE iot_thermostat DETACH PARTITION iot_thermostat07232022;
حالا اون یه قفسه مستقل شده و دیگه تو انبار اصلی نیست. میتونی اونو به یه انبار آرشیو منتقل کنی تا فقط اطلاعات مهم و اخیر تو انبار اصلی باقی بمونن.
البته قرار نیست انبار خالی بمونه! باید یه قفسه جدید هم برای اطلاعات جدید بسازیم. دستور زیر یه قفسه با برچسب iot_thermostat0842022 ایجاد میکنه که اطلاعات ۴ و ۵ آگوست رو توش جا میده:
CREATE TABLE iot_thermostat0842022 PARTITION OF iot_thermostat
FOR VALUES FROM ('2022-08-04 00:00:000') TO ('2022-08-05 00:00:000');
حالا با یه چرخش مرتب، قفسه‌های قدیمی رو آرشیو می‌کنیم و قفسه‌های جدید برای اطلاعات جدید اضافه می‌کنیم. اینجوری انبارت همیشه مرتب و منظم میمونه و فقط داده‌های مهم و قابل استفاده توش نگه می‌داری.
اگه قراره این چرخش رو هر روز انجام بدی، میتونی از یه ابزار به اسم cron job استفاده کنی تا همه چی به صورت خودکار و بدون زحمت انجام بشه. دیگه لازم نیست خودت قفسه‌ها رو جابه‌جا کنی!
یادت باشه، پارتیشن‌بندی یه ابزار جادوییه که بهت کمک میکنه انبار داده‌هات رو هم تمیز و مرتب نگه داری، هم مدیریت و دسترسی به اطلاعات رو آسون‌تر کنه. با چرخش پارتیشن هم میتونی اطلاعات قدیمی رو حفظ کنی، بدون اینکه انبار اصلیت شلوغ و بی‌نظم بشه. خب، حالا قفسه‌دار حرفه‌ای و مرتبی شدی!
@Code_Crafters
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍1
نکته مهم در مورد کدهای ارائه شده در پست های قبلی:
اگر می‌خواهید کدهای مربوط به تراکنش‌ها و پارتیشن‌بندی را امتحان کنید، لازم نیست PostgreSQL را نصب کنید!
سایت CrunchyData (https://www.crunchydata.com/) که منبع اصلی مقاله ترجمه شده در پست های قبلی بود، یک ترمینال PostgreSQL تعاملی در سمت راست صفحه خود ارائه می‌دهد که می‌توانید از آن برای تست کدها بدون نیاز به نصب هیچ نرم‌افزاری استفاده کنید.
لینک‌های مربوط به ترمینال PostgreSQL:
تراکنش‌ها:
https://www.crunchydata.com/developers/playground/transactions
پارتیشن‌بندی:
https://www.crunchydata.com/developers/playground/partitioning
👩💻 #postgresql
@Code_Crafters
اگر می‌خواهید کدهای مربوط به تراکنش‌ها و پارتیشن‌بندی را امتحان کنید، لازم نیست PostgreSQL را نصب کنید!
سایت CrunchyData (https://www.crunchydata.com/) که منبع اصلی مقاله ترجمه شده در پست های قبلی بود، یک ترمینال PostgreSQL تعاملی در سمت راست صفحه خود ارائه می‌دهد که می‌توانید از آن برای تست کدها بدون نیاز به نصب هیچ نرم‌افزاری استفاده کنید.
لینک‌های مربوط به ترمینال PostgreSQL:
تراکنش‌ها:
https://www.crunchydata.com/developers/playground/transactions
پارتیشن‌بندی:
https://www.crunchydata.com/developers/playground/partitioning
@Code_Crafters
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2
This media is not supported in your browser
VIEW IN TELEGRAM
جوابی که مدیر شرکت در جویای عدم درگیری و وجود اختلاف بکندکار و فرانتکار میگیره
جدا از طنز دو کارگردان وودی آلن و کریستوفر نولان شاهکار هستند
#fun
@code_crafters
جدا از طنز دو کارگردان وودی آلن و کریستوفر نولان شاهکار هستند
#fun
@code_crafters
👍4🦄1
برای بررسی لاگ‌ها در سرور معمولا دو ابزار قدرتمند وجود دارد grafana loki و ELK
در ریپوی مربوط به grafana که در گیتهاب کانال با عنوان sysadmin_monitoring موجود می باشد، loki رو داکرایز کردیم و با ابزارهای دیگه و پلتفرم‌های دیگه میتونید بالا بیارید
در این ریپو هم ELK رو داکرایز و کانفیگ کردم
که با کلون کردنش میتونید ازش استفاده کنید یک فایل زیپ شده هم برای تمرین و تست گذاشتم براتون
خب بین دو پلتفرم loki و ELK کدوم رو اسفاده کنیم؟؟؟
پلتفرم loki برای پروژه‌های متوسط و سرورهای معمولی مناسب هست ELK هم برای سیستم‌های بزرگ و معمولا میکروسرویسی
خود ELK مخفف elastic logstash kibana هستش
لینک ریپو رو در زیر براتون گذاشتم
https://github.com/CodeCrafters-ir/ELK.git
#devops
#monitoring
@code_crafters
در ریپوی مربوط به grafana که در گیتهاب کانال با عنوان sysadmin_monitoring موجود می باشد، loki رو داکرایز کردیم و با ابزارهای دیگه و پلتفرم‌های دیگه میتونید بالا بیارید
در این ریپو هم ELK رو داکرایز و کانفیگ کردم
که با کلون کردنش میتونید ازش استفاده کنید یک فایل زیپ شده هم برای تمرین و تست گذاشتم براتون
خب بین دو پلتفرم loki و ELK کدوم رو اسفاده کنیم؟؟؟
پلتفرم loki برای پروژه‌های متوسط و سرورهای معمولی مناسب هست ELK هم برای سیستم‌های بزرگ و معمولا میکروسرویسی
خود ELK مخفف elastic logstash kibana هستش
لینک ریپو رو در زیر براتون گذاشتم
https://github.com/CodeCrafters-ir/ELK.git
#devops
#monitoring
@code_crafters
GitHub
GitHub - CodeCrafters-ir/ELK
Contribute to CodeCrafters-ir/ELK development by creating an account on GitHub.
❤5🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
وقتی ربات رو جهت تست روی هاست مشتری اجرا میکنی ، و همون لحظه مشتری پسورد یوزر هاست رو تغییر میده
#fun
@code_crafters
#fun
@code_crafters
😁9🤣2👍1
CodeCrafters
وقتی ربات رو جهت تست روی هاست مشتری اجرا میکنی ، و همون لحظه مشتری پسورد یوزر هاست رو تغییر میده #fun @code_crafters
از خاطرات دنیای فریلنسری بهتون بگم
یبار یک موتور جستجوی تصویر برای مشتری نوشتم با opencv که مبلغش بالا بود
کدهارو جهت تست روی سرور گذاشتم و بعد از گرفتن اولین خروجی ،مشتری پسورد رو تغییر داد و من رو بلاک کرد
اما من یک باگ داخل کدهام گذاشته بودم متاسفانه که باعث شد یکماه مشتری التماسم کنه
یبار یک موتور جستجوی تصویر برای مشتری نوشتم با opencv که مبلغش بالا بود
کدهارو جهت تست روی سرور گذاشتم و بعد از گرفتن اولین خروجی ،مشتری پسورد رو تغییر داد و من رو بلاک کرد
اما من یک باگ داخل کدهام گذاشته بودم متاسفانه که باعث شد یکماه مشتری التماسم کنه
😁13
چرا conda استفاده کنیم؟؟؟
اول اینکه نوع پایتون رو هم خودش براتون بالا میاره حین ساخت محیط و شما دیگه درگیر پیچیدگی و هندل کردن نصب و مدیریت چند نسخه مختلف پایتون نمیشید و حتی کار کردن باهاش از pyenv راحت تره و عوض کردن نسخه پایتونش هم راحت تره
۱-نصب پکیج هم داخلش راحته
۲-و علاوه بر خودش میتونید از pip هم استفاده کنید
۳- همچنین بروز رسانی پکیج
۲-و یا یک فایل حاوی ادرس‌های آن جهت نصب بسازید
۳-و یا بصورت yaml براتون قرار میده که از دو بخش تشکیل شده پکیج‌هایی که خودش نصب کرده و پکیج‌هایی که با pip نصب شده
۲-مشاهده وابستگی های آن
۳-مشاهده پکیج‌ها استفاده کننده آن
داخل کامنت ها هم نحوه نصبش رو در اوبونتو میزارم
#conda
#pip
#env
@code_crafters
اول اینکه نوع پایتون رو هم خودش براتون بالا میاره حین ساخت محیط و شما دیگه درگیر پیچیدگی و هندل کردن نصب و مدیریت چند نسخه مختلف پایتون نمیشید و حتی کار کردن باهاش از pyenv راحت تره و عوض کردن نسخه پایتونش هم راحت تره
conda create -n MyENV python=3.8دوم اینکه محیطی که براتون میسازه رو داخل home شما و در دایرکتوری مخصوص خودش میسازه و نه در مسیر جاری شما خب این مزیتش این هست که شما راحت هرجا باشید میتونید ۱-سریع فعال و ۲-غیرفعال و یا محیط خودتون رو تغییر بدید و یا بدون دغدغه نسبت به محل قرارگیریش محیط جدید بسازید و ۳-حذف هم کنید و بین محیط‌های مختلف راحت سویچ کنید
1- conda activate my_envمورد بعدی هم اینکه:
2- conda deactivate
3- conda env remove -n MyENV
۱-نصب پکیج هم داخلش راحته
۲-و علاوه بر خودش میتونید از pip هم استفاده کنید
۳- همچنین بروز رسانی پکیج
1- conda install PackName۱-لیست پکیج‌های نصب شده رو هم میتونید ببینید
2- pip install PackName
3- conda update PackName
۲-و یا یک فایل حاوی ادرس‌های آن جهت نصب بسازید
۳-و یا بصورت yaml براتون قرار میده که از دو بخش تشکیل شده پکیج‌هایی که خودش نصب کرده و پکیج‌هایی که با pip نصب شده
1- conda listکه بالطبع میتونید اون رو هم در یک محیط دیگه نصب کنید
2- conda list --explicit
3- conda env export > requirements.yml
conda create -f requirements.ymlگفتیم همه محیط‌ها رو در یک مسیر قرار میده که با دستور زیر هم میتونید لیست همه محیط هاتون رو ببینید
conda create -n MyENV -f requirements.yml
conda env list۱- اگه بخواید یک‌محیط رو‌حذف کنید ۲-یا یک پکیج رو حذف کنید
1- conda env remove -n MyENV --allبرای دیدن اطلاعات مربوط به محیط تون
2- conda remove PackName
conda infoجهت تست و بررسی سلامت محیط
conda doctorجهت تغییر نام محیط با شرط فعال نبودن محیط تون(فراموش نکنید conda یک محیط base داره که با دستور اولی فعال میشه)
conda activate۱-جستجوی پکیج با نمایش تاریخچه تگ آن
conda rename -n OldName NewName
۲-مشاهده وابستگی های آن
۳-مشاهده پکیج‌ها استفاده کننده آن
1- conda search PackNameادغام محیط شل با conda
2- conda repoquery depends PackName
3- conda repoquery whoneeds PackName
conda init bashپاک کردن پکیج‌های نا استفاده
conda cleanبرای کانفیگ از قبیل محیط نصب، پکیج‌ها محدودیت دانلود و ...
conda configموضوع جالب اینکه هنگام نصب پکیج تمام وابستگی‌ها رو اجرایی میکنه و نصب و حتی اگه نیاز به نسخه دیگری از پایتون باشه اون رو downgraid میکنه که منجر میشه تا حد ممکن براتون خطایی رخ نده و دردسر نکشید
conda config --help
داخل کامنت ها هم نحوه نصبش رو در اوبونتو میزارم
#conda
#pip
#env
@code_crafters
👍5❤1
خب بیاید یک کار کوچیک باهاش انجام بدیم
سیستم عامل من ubuntu 23.10 هستش که پایتون ۳.۱۱ روش نصب و من نیاز به نسخه ۳.۱۰ دارم و ...
و تک دستور زیر رو میزنم
طبق تصویر بالایی اکستنشن هارو با python intellisense, python debugger نصب کنید
تصویر پایین، بالا سمت راست (قرمز شده) کلیک میکنم و یک پنجره کشویی در vscode باز میکنه گزینه python environments و سپس محیط ML رو انتخاب میکنم( کرنل انتخاب شد)
در قسمت سمت راست فایل‌هام رو با .ipynb میسازم (قرمز شده)
الان محیط jupyter با intellisense دارم
#conda
#pip
#env
@code_crafters
سیستم عامل من ubuntu 23.10 هستش که پایتون ۳.۱۱ روش نصب و من نیاز به نسخه ۳.۱۰ دارم و ...
در حالت معمول من باید برم پایتون نسخه ۳.۱۰ رو نصب کنم بعد یک جایی محیطی بسازم که دست نخورده و محافظت شده بمونه برام و دپندنسی هارو نصب کنم و بعد پکیج‌های مدنظرم رو و ... 😢😢😢خب قبل از هرچیزی vscode و conda رو نصب میکنم
و تک دستور زیر رو میزنم
conda create -n ML python=3.10 scikit-learn jupyterهمین ،خودش تمام دپندنسی هارو برام نصب میکنه و تموم و با یک خط دستور راه هزار ساله قبلی رو رفتم،حالا کافیه هرجایی که دوست دارم یک work directory بسازم و vscode رو اجرا کنم و work directory رو باز کنم
طبق تصویر بالایی اکستنشن هارو با python intellisense, python debugger نصب کنید
تصویر پایین، بالا سمت راست (قرمز شده) کلیک میکنم و یک پنجره کشویی در vscode باز میکنه گزینه python environments و سپس محیط ML رو انتخاب میکنم( کرنل انتخاب شد)
در قسمت سمت راست فایل‌هام رو با .ipynb میسازم (قرمز شده)
الان محیط jupyter با intellisense دارم
#conda
#pip
#env
@code_crafters
👍2