Forwarded from Bardia & Erfan
🤨 دارک مود؛ ناجی چشم‌ها یا یه توهم مدرن...؟!
خیلیا فکر می‌کنن دارک مود برای چشم سالم‌تره، اما تحقیقات علمی چی میگن؟ بررسی مطالعات جدید نشون میده که دارک مود هم مزایا داره، هم معایب!
مزایای علمی دارک مود :
▪️کاهش نور آبی : نور آبی زیاد، ریتم خواب رو مختل می‌کنه، و دارک مود می‌تونه به خواب بهتر کمک کنه.
▪️کاهش مصرف باتری : روی نمایشگرهای OLED، رنگ‌های تیره مصرف انرژی کمتری دارن.
▪️کاهش خیرگی در محیط‌های کم‌نور : وقتی نور اطراف کم باشه، دارک مود فشار کمتری به چشم وارد می‌کنه.
معایب علمی دارک مود :
▪️کاهش خوانایی متن در روز: چشم انسان به خوندن متن تیره روی پس‌زمینه روشن عادت داره، و دارک مود توی نور زیاد باعث خستگی چشم میشه.
▪️برخی تحقیقات نشون میدن که چشم توی حالت دارک مود بیشتر مجبور به تطبیق و تمرکز میشه، که می‌تونه خستگی ایجاد کنه.
▪️برخلاف تصور عموم، تغییر تم به تنهایی تأثیر زیادی روی کاهش خشکی و خستگی چشم نداره، بلکه میزان پلک زدن و استراحت دادن به چشم مهم‌تره.
خیلیا فکر می‌کنن دارک مود برای چشم سالم‌تره، اما تحقیقات علمی چی میگن؟ بررسی مطالعات جدید نشون میده که دارک مود هم مزایا داره، هم معایب!
مزایای علمی دارک مود :
▪️کاهش نور آبی : نور آبی زیاد، ریتم خواب رو مختل می‌کنه، و دارک مود می‌تونه به خواب بهتر کمک کنه.
▪️کاهش مصرف باتری : روی نمایشگرهای OLED، رنگ‌های تیره مصرف انرژی کمتری دارن.
▪️کاهش خیرگی در محیط‌های کم‌نور : وقتی نور اطراف کم باشه، دارک مود فشار کمتری به چشم وارد می‌کنه.
معایب علمی دارک مود :
▪️کاهش خوانایی متن در روز: چشم انسان به خوندن متن تیره روی پس‌زمینه روشن عادت داره، و دارک مود توی نور زیاد باعث خستگی چشم میشه.
▪️برخی تحقیقات نشون میدن که چشم توی حالت دارک مود بیشتر مجبور به تطبیق و تمرکز میشه، که می‌تونه خستگی ایجاد کنه.
▪️برخلاف تصور عموم، تغییر تم به تنهایی تأثیر زیادی روی کاهش خشکی و خستگی چشم نداره، بلکه میزان پلک زدن و استراحت دادن به چشم مهم‌تره.
❤2
Forwarded from Gopher Academy
کدوم هوش مصنوعی رو انتخاب می کنید واسه کارهای برنامه نویسی؟
Anonymous Poll
48%
GPT
12%
Grok
42%
Claude
17%
other
چرا بسیاری از تیم‌ها ORM را کنار می‌گذارند و سراغ SQL خام می‌روند؟
اخیرا در مدیوم با تعداد زیادی از مقاله‌ها مواجه می‌شوم که یک پیام مشترک دارند:
«ما ORM را کنار گذاشتیم و به SQL خام مهاجرت کردیم — و دیگر برنمی‌گردیم.»
نکته جالب اینجاست که این تصمیم‌ها معمولاً از سر عشق به SQL گرفته نشده‌اند، بلکه از دل دردسرهای ORM زاده شده‌اند.
در چند مقاله‌ی اخیر که مطالعه کردم، تیم‌های مختلفی با تکنولوژی‌های مختلف (از Java + Postgres گرفته تا Go + SQLAlchemy) تجربه‌ی مهاجرت از ORM را به اشتراک گذاشته‌اند — نه فقط برای بهبود سرعت، بلکه برای بازگشت به شفافیت، کنترل و عقلانیت.
مشکل کجا بود؟ چرا ORM جوابگو نبود؟
اگرچه ORM در شروع پروژه‌ها خیلی مفید است (خصوصاً برای CRUDهای سریع و MVPها)، اما با رشد سیستم، مشکلاتی کم‌کم خود را نشان می‌دهند:
* معضل N+1 Query
کوئری‌هایی که ساده به نظر می‌رسند، در باطن ده‌ها یا صدها درخواست اضافه تولید می‌کنند.
* کدهای پیچیده اما غیرشفاف
برای کوئری‌های پیچیده‌تر مثل Window Function، CTE یا Join چندجدولی، باید به انواع annotationها، chainهای مبهم، یا زبان‌های خاص ORM (مثل JPQL) متوسل شد — که در نهایت باز هم می‌رسیم به نوشتن SQL، فقط با دردسر بیشتر.
* ضعف در دیباگ و پروفایلینگ
در ORM، به‌سختی می‌شود فهمید دقیقاً چه کوئری‌ای به دیتابیس رفته. این یعنی دیباگِ کندی‌ها تقریباً کورکورانه است.
* ناسازگاری با مدل واقعی داده‌ها
دیتابیس با row و index و join کار می‌کند؛ ORM با کلاس و رابطه شی‌گرایانه. این تطبیق، به‌ویژه در سیستم‌های پیچیده، منجر به کدهایی می‌شود که بیشتر شبیه «جنگیدن با ORM» هستند.
چرا SQL خام یک تفاوت واقعی ایجاد کرد؟
بعد از مهاجرت، همه تیم‌ها روی این دستاوردها تأکید داشتند:
* کنترل کامل
می‌دانیم چه کوئری نوشته‌ایم، چه زمانی اجرا می‌شود، و چگونه می‌توان آن را بهینه کرد.
* شفافیت
کوئری واضح است، بدون «جادوی مخفی». این یعنی همه تیم — از جونیور تا لید — متوجه می‌شود چه اتفاقی می‌افتد.
* هماهنگی بیشتر با منطق دامنه
به‌جای تعریف business logic در repository و annotation، همه‌چیز در لایه‌های مشخص خدماتی و use-case محور قرار می‌گیرد.
* استفاده کامل از قدرت دیتابیس
ویژگی‌هایی مثل Window Function، CTE، JSONB و Partial Index که در ORM اغلب یا پشتیبانی نمی‌شوند یا با پیچیدگی زیاد ممکن‌اند، در SQL خام به‌راحتی قابل استفاده‌اند.
نگهداری و مقیاس‌پذیری چطور مدیریت شد؟
برای جلوگیری از بی‌نظمی، تیم‌ها:
* کوئری‌ها را در فایل‌های جدا و نسخه‌دار نگه داشتند
* از template و query loaderهای سبک استفاده کردند
* روی هر کوئری تست (یا حداقل EXPLAIN) نوشتند
* قواعد ساده ولی سخت‌گیرانه‌ای برای امنیت (مثل پارامترگذاری) اعمال کردند
در نتیجه، برخلاف تصور اولیه، نگهداشت SQL خام هم قابل مدیریت و حتی لذت‌بخش شد.
کی باید ORM را کنار گذاشت؟
تجربه‌ی مشترک تیم‌ها نشان می‌دهد:
* برای پروژه‌های کوچک، MVPها یا پنل‌های ادمین، ORM عالی است.
* اما در پروژه‌های داده‌محور، با ترافیک بالا، کوئری‌های پیچیده و نیاز به کنترل عملکرد، ORM به‌جای کمک، تبدیل به مانع می‌شود.
جمع‌بندی
بسیاری از ما با ORMها بزرگ شده‌ایم اما آیا هنوز ORM بهترین ابزار ماست؟ یا فقط آسان‌ترین است؟
در دنیایی که عملکرد، شفافیت و کنترل ارزش بیشتری از سرعت اولیه دارند، شاید وقت آن است که دوباره به SQL خام یا ترکیب آن با ORm فکر کنیم — این بار با بلوغ بیشتر و ابزارهای بهتر.
<Mojtaba Banaie/>
اخیرا در مدیوم با تعداد زیادی از مقاله‌ها مواجه می‌شوم که یک پیام مشترک دارند:
«ما ORM را کنار گذاشتیم و به SQL خام مهاجرت کردیم — و دیگر برنمی‌گردیم.»
نکته جالب اینجاست که این تصمیم‌ها معمولاً از سر عشق به SQL گرفته نشده‌اند، بلکه از دل دردسرهای ORM زاده شده‌اند.
در چند مقاله‌ی اخیر که مطالعه کردم، تیم‌های مختلفی با تکنولوژی‌های مختلف (از Java + Postgres گرفته تا Go + SQLAlchemy) تجربه‌ی مهاجرت از ORM را به اشتراک گذاشته‌اند — نه فقط برای بهبود سرعت، بلکه برای بازگشت به شفافیت، کنترل و عقلانیت.
مشکل کجا بود؟ چرا ORM جوابگو نبود؟
اگرچه ORM در شروع پروژه‌ها خیلی مفید است (خصوصاً برای CRUDهای سریع و MVPها)، اما با رشد سیستم، مشکلاتی کم‌کم خود را نشان می‌دهند:
* معضل N+1 Query
کوئری‌هایی که ساده به نظر می‌رسند، در باطن ده‌ها یا صدها درخواست اضافه تولید می‌کنند.
* کدهای پیچیده اما غیرشفاف
برای کوئری‌های پیچیده‌تر مثل Window Function، CTE یا Join چندجدولی، باید به انواع annotationها، chainهای مبهم، یا زبان‌های خاص ORM (مثل JPQL) متوسل شد — که در نهایت باز هم می‌رسیم به نوشتن SQL، فقط با دردسر بیشتر.
* ضعف در دیباگ و پروفایلینگ
در ORM، به‌سختی می‌شود فهمید دقیقاً چه کوئری‌ای به دیتابیس رفته. این یعنی دیباگِ کندی‌ها تقریباً کورکورانه است.
* ناسازگاری با مدل واقعی داده‌ها
دیتابیس با row و index و join کار می‌کند؛ ORM با کلاس و رابطه شی‌گرایانه. این تطبیق، به‌ویژه در سیستم‌های پیچیده، منجر به کدهایی می‌شود که بیشتر شبیه «جنگیدن با ORM» هستند.
چرا SQL خام یک تفاوت واقعی ایجاد کرد؟
بعد از مهاجرت، همه تیم‌ها روی این دستاوردها تأکید داشتند:
* کنترل کامل
می‌دانیم چه کوئری نوشته‌ایم، چه زمانی اجرا می‌شود، و چگونه می‌توان آن را بهینه کرد.
* شفافیت
کوئری واضح است، بدون «جادوی مخفی». این یعنی همه تیم — از جونیور تا لید — متوجه می‌شود چه اتفاقی می‌افتد.
* هماهنگی بیشتر با منطق دامنه
به‌جای تعریف business logic در repository و annotation، همه‌چیز در لایه‌های مشخص خدماتی و use-case محور قرار می‌گیرد.
* استفاده کامل از قدرت دیتابیس
ویژگی‌هایی مثل Window Function، CTE، JSONB و Partial Index که در ORM اغلب یا پشتیبانی نمی‌شوند یا با پیچیدگی زیاد ممکن‌اند، در SQL خام به‌راحتی قابل استفاده‌اند.
نگهداری و مقیاس‌پذیری چطور مدیریت شد؟
برای جلوگیری از بی‌نظمی، تیم‌ها:
* کوئری‌ها را در فایل‌های جدا و نسخه‌دار نگه داشتند
* از template و query loaderهای سبک استفاده کردند
* روی هر کوئری تست (یا حداقل EXPLAIN) نوشتند
* قواعد ساده ولی سخت‌گیرانه‌ای برای امنیت (مثل پارامترگذاری) اعمال کردند
در نتیجه، برخلاف تصور اولیه، نگهداشت SQL خام هم قابل مدیریت و حتی لذت‌بخش شد.
کی باید ORM را کنار گذاشت؟
تجربه‌ی مشترک تیم‌ها نشان می‌دهد:
* برای پروژه‌های کوچک، MVPها یا پنل‌های ادمین، ORM عالی است.
* اما در پروژه‌های داده‌محور، با ترافیک بالا، کوئری‌های پیچیده و نیاز به کنترل عملکرد، ORM به‌جای کمک، تبدیل به مانع می‌شود.
جمع‌بندی
بسیاری از ما با ORMها بزرگ شده‌ایم اما آیا هنوز ORM بهترین ابزار ماست؟ یا فقط آسان‌ترین است؟
در دنیایی که عملکرد، شفافیت و کنترل ارزش بیشتری از سرعت اولیه دارند، شاید وقت آن است که دوباره به SQL خام یا ترکیب آن با ORm فکر کنیم — این بار با بلوغ بیشتر و ابزارهای بهتر.
<Mojtaba Banaie/>
💔1
Forwarded from AI Labdon
🤖 علاقه‌مند به دنیای هوش مصنوعی هستی؟
🏖 دنبال می‌کنی که چطور AI داره دنیا رو متحول می‌کنه؟
🍻پس جای درستی اومدی!
🎯 در کانال ما هر روز:
🔍 جدیدترین اخبار و دستاوردهای دنیای AI
🧠 تحلیل تخصصی در حوزه یادگیری ماشین، دیپ لرنینگ و مدل‌های زبانی
💼 بررسی کاربردهای هوش مصنوعی در پزشکی، صنعت، آموزش، امنیت و اقتصاد
🛠 معرفی ابزارها، دوره‌ها و منابع یادگیری
📈 بررسی ترندها و آینده فناوری‌های مرتبط با هوش مصنوعی
🍄همه‌ی این‌ها به زبان ساده، خلاصه و قابل فهم برای همه علاقه‌مندان — از مبتدی تا حرفه‌ای!
👇👇👇👇👇👇
https://t.iss.one/ai_labdon
🏖 دنبال می‌کنی که چطور AI داره دنیا رو متحول می‌کنه؟
🍻پس جای درستی اومدی!
🎯 در کانال ما هر روز:
🔍 جدیدترین اخبار و دستاوردهای دنیای AI
🧠 تحلیل تخصصی در حوزه یادگیری ماشین، دیپ لرنینگ و مدل‌های زبانی
💼 بررسی کاربردهای هوش مصنوعی در پزشکی، صنعت، آموزش، امنیت و اقتصاد
🛠 معرفی ابزارها، دوره‌ها و منابع یادگیری
📈 بررسی ترندها و آینده فناوری‌های مرتبط با هوش مصنوعی
🍄همه‌ی این‌ها به زبان ساده، خلاصه و قابل فهم برای همه علاقه‌مندان — از مبتدی تا حرفه‌ای!
👇👇👇👇👇👇
https://t.iss.one/ai_labdon
Forwarded from Notification
🔵 عنوان مقاله
VectorChord 0.5: Scalable, Fast, and Disk-Friendly Vector Search
🟢 خلاصه مقاله:
این پروژه یک افزونه متن‌باز جست‌وجوی برداری برای PostgreSQL است که با مجوزهای AGPLv3 یا ELv2 عرضه می‌شود. مهم‌ترین ویژگی آن سازگاری با انواع داده و نحو پرس‌وجوی pgvector است، بنابراین می‌تواند در بسیاری از سامانه‌های موجود به‌صورت جایگزین کم‌دردسر (drop-in) به کار رود. سازندگان وعده افزایش قابل‌توجه کارایی نسبت به pgvector داده‌اند؛ بدین معنا که اجرای پرس‌وجوهای شباهت برداری با تأخیر کمتر و توان عملیاتی بالاتر ممکن می‌شود، هرچند میزان بهبود به سناریو و بار کاری وابسته است. تکیه بر PostgreSQL مزیت استقرار ساده در زیرساخت فعلی و حذف نیاز به سرویس جداگانه را حفظ می‌کند. دوگانه‌مجوز بودن نیز انعطاف برای استفاده متن‌باز و مسیرهای استفاده تجاری را فراهم می‌سازد. این دست ابزار معمولاً برای جست‌وجوی معنایی، RAG، سامانه‌های توصیه‌گر و پردازش چندرسانه‌ای کاربرد دارد. کد منبع و اطلاعات بیشتر از طریق مخزن GitHub در دسترس است.
🟣لینک مقاله:
https://postgresweekly.com/link/173145/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
VectorChord 0.5: Scalable, Fast, and Disk-Friendly Vector Search
🟢 خلاصه مقاله:
این پروژه یک افزونه متن‌باز جست‌وجوی برداری برای PostgreSQL است که با مجوزهای AGPLv3 یا ELv2 عرضه می‌شود. مهم‌ترین ویژگی آن سازگاری با انواع داده و نحو پرس‌وجوی pgvector است، بنابراین می‌تواند در بسیاری از سامانه‌های موجود به‌صورت جایگزین کم‌دردسر (drop-in) به کار رود. سازندگان وعده افزایش قابل‌توجه کارایی نسبت به pgvector داده‌اند؛ بدین معنا که اجرای پرس‌وجوهای شباهت برداری با تأخیر کمتر و توان عملیاتی بالاتر ممکن می‌شود، هرچند میزان بهبود به سناریو و بار کاری وابسته است. تکیه بر PostgreSQL مزیت استقرار ساده در زیرساخت فعلی و حذف نیاز به سرویس جداگانه را حفظ می‌کند. دوگانه‌مجوز بودن نیز انعطاف برای استفاده متن‌باز و مسیرهای استفاده تجاری را فراهم می‌سازد. این دست ابزار معمولاً برای جست‌وجوی معنایی، RAG، سامانه‌های توصیه‌گر و پردازش چندرسانه‌ای کاربرد دارد. کد منبع و اطلاعات بیشتر از طریق مخزن GitHub در دسترس است.
🟣لینک مقاله:
https://postgresweekly.com/link/173145/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
vectorchord.ai
Scalable, fast, and disk-friendly vector search in Postgres, vectorchord is the successor of pgvecto.rs.
Forwarded from Notification
🔵 عنوان مقاله
Indexing JSONB in Postgres
🟢 خلاصه مقاله:
اJSONB در PostgreSQL برای داده‌های نیمه‌ساخت‌یافته بسیار کاربردی است، اما سرعت بازیابی به انتخاب شاخص درست بستگی دارد. برای پرس‌وجوهای مبتنی بر وجود کلید معمولاً GIN بهترین گزینه است؛
ا jsonb_ops دامنهٔ وسیع‌تری از عملگرها را پشتیبانی می‌کند، در حالی‌که jsonb_path_ops برای شمول بهینه‌تر و کوچکتر است.
اگر مرتب روی یک مقدار اسکالر داخل JSONB فیلتر یا مرتب‌سازی می‌کنید (مثل data->>'sku')، شاخص B-tree روی یک عبارت یا ستون تولیدشده معمولاً سبک‌تر و سریع‌تر است. برای داده‌های سنگینِ نوشتاری، هزینهٔ نگهداری GIN را در نظر بگیرید و در صورت امکان از شاخص‌های جزئی و بیان‌محور استفاده کنید. در کل، شاخص را مطابق الگوی واقعی پرس‌وجو بسازید و نتیجه را با بنچمارک روی بار کاری خودتان تأیید کنید.
🟣لینک مقاله:
https://postgresweekly.com/link/173137/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Indexing JSONB in Postgres
🟢 خلاصه مقاله:
اJSONB در PostgreSQL برای داده‌های نیمه‌ساخت‌یافته بسیار کاربردی است، اما سرعت بازیابی به انتخاب شاخص درست بستگی دارد. برای پرس‌وجوهای مبتنی بر وجود کلید معمولاً GIN بهترین گزینه است؛
ا jsonb_ops دامنهٔ وسیع‌تری از عملگرها را پشتیبانی می‌کند، در حالی‌که jsonb_path_ops برای شمول بهینه‌تر و کوچکتر است.
اگر مرتب روی یک مقدار اسکالر داخل JSONB فیلتر یا مرتب‌سازی می‌کنید (مثل data->>'sku')، شاخص B-tree روی یک عبارت یا ستون تولیدشده معمولاً سبک‌تر و سریع‌تر است. برای داده‌های سنگینِ نوشتاری، هزینهٔ نگهداری GIN را در نظر بگیرید و در صورت امکان از شاخص‌های جزئی و بیان‌محور استفاده کنید. در کل، شاخص را مطابق الگوی واقعی پرس‌وجو بسازید و نتیجه را با بنچمارک روی بار کاری خودتان تأیید کنید.
🟣لینک مقاله:
https://postgresweekly.com/link/173137/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Indexing JSONB in Postgres | Crunchy Data Blog
Level up with JSONB by adding GIN indexes. Also review when not to use a GIN index and how to leverage expression indexes.
🔵 عنوان مقاله
Indexing JSONB in Postgres
🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد چگونه با بهره‌گیری درست از قابلیت‌های ایندکس در پستگرس، بازیابی داده از JSONB را سریع و بهینه کنیم. هسته پیام این است که انتخاب نوع ایندکس باید بر اساس الگوی پرس‌وجو باشد: برای جست‌وجوهای شامل‌بودن و وجود کلید، GIN گزینه اصلی است (نسخه پیش‌فرض برای عملگرهای متنوع و jsonb_path_ops برای ایندکس کوچکتر و سریع‌ترِ خاص پرس‌وجوهای @>). برای فیلتر و سورت بر روی مقادیر اسکالر داخل JSONB، ایندکس‌های بی‌تری روی عبارت‌های استخراج‌شده (مثل user_id یا زمان) کاراترند؛ همچنین می‌توان از ایندکس‌های جزئی و پوششی برای کاهش هزینه خواندن استفاده کرد. باید میان سرعت خواندن، اندازه ایندکس و سربار نوشتن توازن برقرار کرد، با EXPLAIN صحت استفاده از ایندکس را سنجید و از ایندکس‌گذاری بیش‌ازحد پرهیز نمود؛ در موارد پرتکرار، تبدیل چند کلید مهم به ستون‌های تولیدی و ایندکس‌کردن آن‌ها تعادلی عملی میان انعطاف و کارایی ایجاد می‌کند.
🟣لینک مقاله:
https://postgresweekly.com/link/173137/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Indexing JSONB in Postgres
🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد چگونه با بهره‌گیری درست از قابلیت‌های ایندکس در پستگرس، بازیابی داده از JSONB را سریع و بهینه کنیم. هسته پیام این است که انتخاب نوع ایندکس باید بر اساس الگوی پرس‌وجو باشد: برای جست‌وجوهای شامل‌بودن و وجود کلید، GIN گزینه اصلی است (نسخه پیش‌فرض برای عملگرهای متنوع و jsonb_path_ops برای ایندکس کوچکتر و سریع‌ترِ خاص پرس‌وجوهای @>). برای فیلتر و سورت بر روی مقادیر اسکالر داخل JSONB، ایندکس‌های بی‌تری روی عبارت‌های استخراج‌شده (مثل user_id یا زمان) کاراترند؛ همچنین می‌توان از ایندکس‌های جزئی و پوششی برای کاهش هزینه خواندن استفاده کرد. باید میان سرعت خواندن، اندازه ایندکس و سربار نوشتن توازن برقرار کرد، با EXPLAIN صحت استفاده از ایندکس را سنجید و از ایندکس‌گذاری بیش‌ازحد پرهیز نمود؛ در موارد پرتکرار، تبدیل چند کلید مهم به ستون‌های تولیدی و ایندکس‌کردن آن‌ها تعادلی عملی میان انعطاف و کارایی ایجاد می‌کند.
🟣لینک مقاله:
https://postgresweekly.com/link/173137/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Indexing JSONB in Postgres | Crunchy Data Blog
Level up with JSONB by adding GIN indexes. Also review when not to use a GIN index and how to leverage expression indexes.
❤1
🔵 عنوان مقاله
Bypass Postgres Catalog Overhead with Direct Partition Hash Calculations
🟢 خلاصه مقاله:
کار اصلی مقاله نشان می‌دهد که در جداول پارتیشن‌بندی‌شده‌ی PostgreSQL، هزینه‌ی مراجعه مکرر به کاتالوگ برای مسیردهی رکوردها می‌تواند با افزایش تعداد پارتیشن‌ها یا همزمانی بالا به گلوگاه تبدیل شود. راه‌حل پیشنهادی، محاسبه مستقیم هش پارتیشن بر اساس کلید پارتیشن و ارسال تعیین‌شده رکورد به پارتیشن درست است؛ رویکردی که با دور زدن مسیر وابسته به کاتالوگ، سربار برنامه‌ریز/اجرا را کم کرده و تأخیرهای دُم را پایدارتر می‌کند. نکته‌ی کلیدی هماهنگی دقیق الگوریتم هش، کالیشن و نگاشت پارتیشن بین برنامه و پایگاه داده و مدیریت ایمن تغییرات هنگام افزودن/بازچینی پارتیشن‌هاست. بخش دوم توضیح می‌دهد چرا PostgreSQL بستر مناسبی برای اجرای گردش‌کارِ پایدار است: تراکنش‌ها و WAL برای دوام، قیود و کلیدهای تکرارنشدنی برای درستی، و امکاناتی مانند SKIP LOCKED و لاک‌های مشورتی برای زمان‌بندی و صف. ترکیب این دو ایده—ذخیره وضعیت و صف کار در جداول هش‌پارتیشن و مسیردهی مستقیم با محاسبه هش—سامانه‌ای می‌سازد که هم مقیاس‌پذیر است و هم قابل اتکا، بدون قربانی‌کردن سازگاری در بارهای نوشتاری سنگین و همزمان.
🟣لینک مقاله:
https://postgresweekly.com/link/173139/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Bypass Postgres Catalog Overhead with Direct Partition Hash Calculations
🟢 خلاصه مقاله:
کار اصلی مقاله نشان می‌دهد که در جداول پارتیشن‌بندی‌شده‌ی PostgreSQL، هزینه‌ی مراجعه مکرر به کاتالوگ برای مسیردهی رکوردها می‌تواند با افزایش تعداد پارتیشن‌ها یا همزمانی بالا به گلوگاه تبدیل شود. راه‌حل پیشنهادی، محاسبه مستقیم هش پارتیشن بر اساس کلید پارتیشن و ارسال تعیین‌شده رکورد به پارتیشن درست است؛ رویکردی که با دور زدن مسیر وابسته به کاتالوگ، سربار برنامه‌ریز/اجرا را کم کرده و تأخیرهای دُم را پایدارتر می‌کند. نکته‌ی کلیدی هماهنگی دقیق الگوریتم هش، کالیشن و نگاشت پارتیشن بین برنامه و پایگاه داده و مدیریت ایمن تغییرات هنگام افزودن/بازچینی پارتیشن‌هاست. بخش دوم توضیح می‌دهد چرا PostgreSQL بستر مناسبی برای اجرای گردش‌کارِ پایدار است: تراکنش‌ها و WAL برای دوام، قیود و کلیدهای تکرارنشدنی برای درستی، و امکاناتی مانند SKIP LOCKED و لاک‌های مشورتی برای زمان‌بندی و صف. ترکیب این دو ایده—ذخیره وضعیت و صف کار در جداول هش‌پارتیشن و مسیردهی مستقیم با محاسبه هش—سامانه‌ای می‌سازد که هم مقیاس‌پذیر است و هم قابل اتکا، بدون قربانی‌کردن سازگاری در بارهای نوشتاری سنگین و همزمان.
🟣لینک مقاله:
https://postgresweekly.com/link/173139/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Shayon Mukherjee
Bypass PostgreSQL catalog overhead with direct partition hash calculations
Eliminating PostgreSQL catalog traversal overhead with local partition calculations for up to 20x faster hash partition queries.
🔵 عنوان مقاله
Postgres 17.6, 16.10, 15.14, 14.19, 13.22, and 18 Beta 3 Released
🟢 خلاصه مقاله:
تمام نسخه‌های پشتیبانی‌شده‌ی پستگرس به‌روزرسانی شدند: 13.22، 14.19، 15.14، 16.10 و 17.6، به‌همراه انتشار بتای سوم نسخه 18. این نسخه‌ها برای رفع چند آسیب‌پذیری امنیتی و اعمال اصلاحات متعدد عرضه شده‌اند. انتشار نهایی پستگرس 18 حدود یک ماه دیگر انتظار می‌رود و توصیه می‌شود مدیران سامانه‌ها با بررسی یادداشت‌های انتشار، برنامهٔ به‌روزرسانی را در اولویت قرار دهند.
🟣لینک مقاله:
https://postgresweekly.com/link/173129/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres 17.6, 16.10, 15.14, 14.19, 13.22, and 18 Beta 3 Released
🟢 خلاصه مقاله:
تمام نسخه‌های پشتیبانی‌شده‌ی پستگرس به‌روزرسانی شدند: 13.22، 14.19، 15.14، 16.10 و 17.6، به‌همراه انتشار بتای سوم نسخه 18. این نسخه‌ها برای رفع چند آسیب‌پذیری امنیتی و اعمال اصلاحات متعدد عرضه شده‌اند. انتشار نهایی پستگرس 18 حدود یک ماه دیگر انتظار می‌رود و توصیه می‌شود مدیران سامانه‌ها با بررسی یادداشت‌های انتشار، برنامهٔ به‌روزرسانی را در اولویت قرار دهند.
🟣لینک مقاله:
https://postgresweekly.com/link/173129/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostgreSQL News
PostgreSQL 17.6, 16.10, 15.14, 14.19, 13.22, and 18 Beta 3 Released!
The PostgreSQL Global Development Group has released an update to all supported versions of PostgreSQL, including 17.6, 16.10, 15.14, 14.19, …
❤2
🔵 عنوان مقاله
adopted a new usage-based pricing model
🟢 خلاصه مقاله:
این مقاله از تغییر به مدل قیمت‌گذاری مصرف‌محور خبر می‌دهد: پرداخت به‌ازای مصرف با حداقل ماهانه ۵ دلار. هدف، هم‌راستاسازی هزینه با میزان استفاده و افزایش انعطاف است؛ کاربران کم‌مصرف معمولاً حداقل را می‌پردازند و پرمصرف‌ها متناسب با مصرف هزینه می‌دهند. این رویکرد پیش‌بینی‌پذیری صورت‌حساب را کاهش می‌دهد، بنابراین بهتر است کاربران الگوی مصرف خود را برآورد و آن را مدیریت کنند.
🟣لینک مقاله:
https://postgresweekly.com/link/173153/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
adopted a new usage-based pricing model
🟢 خلاصه مقاله:
این مقاله از تغییر به مدل قیمت‌گذاری مصرف‌محور خبر می‌دهد: پرداخت به‌ازای مصرف با حداقل ماهانه ۵ دلار. هدف، هم‌راستاسازی هزینه با میزان استفاده و افزایش انعطاف است؛ کاربران کم‌مصرف معمولاً حداقل را می‌پردازند و پرمصرف‌ها متناسب با مصرف هزینه می‌دهند. این رویکرد پیش‌بینی‌پذیری صورت‌حساب را کاهش می‌دهد، بنابراین بهتر است کاربران الگوی مصرف خود را برآورد و آن را مدیریت کنند.
🟣لینک مقاله:
https://postgresweekly.com/link/173153/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Neon
Neon’s New Pricing, Explained: Usage-Based With a $5 Minimum - Neon
We just rolled out a major pricing update, including two of our most requested changes: more storage for Free users, and a $5 /month plan.
❤1
🔵 عنوان مقاله
a guide on how to migrate existing Postgres databases
🟢 خلاصه مقاله:
یک راهنمای عملی برای مهاجرت پایگاه‌های داده موجود PostgreSQL معرفی می‌شود که در Golang Weekly برجسته شده و روی نیازهای توسعه‌دهندگان Go تمرکز دارد. رویکرد کلی، فرایندی و مرحله‌به‌مرحله است: ارزیابی دقیق وضعیت فعلی، انتخاب راهبرد متناسب با محدودیت‌های زمان‌اختلال، خودکارسازی گام‌ها، و اعتبارسنجی مستمر.
این راهنما بر برنامه‌ریزی دقیق (شناخت طرح‌واره‌ها، حجم داده، ایندکس‌ها، افزونه‌ها و تفاوت نسخه‌ها) و تمرین مهاجرت در محیط staging تأکید دارد. راهبردهای رایج مانند ارتقای درجا، قطع‌وبرقراری آبی/سبز و روش‌های مبتنی بر تکرار/همگام‌سازی مقایسه می‌شوند. الگوهای ایمن تغییر طرح‌واره (expand/contract)، ساخت ایندکس‌های همزمان، پرکردن تدریجی داده‌های حجیم، پشتیبان‌گیری و برنامه بازگشت از نکات کلیدی هستند.
برای تیم‌های Go، نسخه‌بندی SQL، اجرای مهاجرت در CI/CD، اسکریپت‌های تکرارپذیر، پایش لحظه‌ای و هماهنگی انتشار کد با تغییرات دیتابیس (مثلاً با feature flag) توصیه می‌شود. همچنین به یکپارچگی داده، قفل‌ها و تراکنش‌های طولانی، و اعتبارسنجی پس از مهاجرت پرداخته می‌شود. در نهایت، ملاحظات فضای ابری و یک چک‌لیست پیش از اجرا ارائه می‌گردد تا مهاجرت PostgreSQL با ریسک کمتر و وقفه حداقلی انجام شود.
🟣لینک مقاله:
https://postgresweekly.com/link/173132/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
a guide on how to migrate existing Postgres databases
🟢 خلاصه مقاله:
یک راهنمای عملی برای مهاجرت پایگاه‌های داده موجود PostgreSQL معرفی می‌شود که در Golang Weekly برجسته شده و روی نیازهای توسعه‌دهندگان Go تمرکز دارد. رویکرد کلی، فرایندی و مرحله‌به‌مرحله است: ارزیابی دقیق وضعیت فعلی، انتخاب راهبرد متناسب با محدودیت‌های زمان‌اختلال، خودکارسازی گام‌ها، و اعتبارسنجی مستمر.
این راهنما بر برنامه‌ریزی دقیق (شناخت طرح‌واره‌ها، حجم داده، ایندکس‌ها، افزونه‌ها و تفاوت نسخه‌ها) و تمرین مهاجرت در محیط staging تأکید دارد. راهبردهای رایج مانند ارتقای درجا، قطع‌وبرقراری آبی/سبز و روش‌های مبتنی بر تکرار/همگام‌سازی مقایسه می‌شوند. الگوهای ایمن تغییر طرح‌واره (expand/contract)، ساخت ایندکس‌های همزمان، پرکردن تدریجی داده‌های حجیم، پشتیبان‌گیری و برنامه بازگشت از نکات کلیدی هستند.
برای تیم‌های Go، نسخه‌بندی SQL، اجرای مهاجرت در CI/CD، اسکریپت‌های تکرارپذیر، پایش لحظه‌ای و هماهنگی انتشار کد با تغییرات دیتابیس (مثلاً با feature flag) توصیه می‌شود. همچنین به یکپارچگی داده، قفل‌ها و تراکنش‌های طولانی، و اعتبارسنجی پس از مهاجرت پرداخته می‌شود. در نهایت، ملاحظات فضای ابری و یک چک‌لیست پیش از اجرا ارائه می‌گردد تا مهاجرت PostgreSQL با ریسک کمتر و وقفه حداقلی انجام شود.
🟣لینک مقاله:
https://postgresweekly.com/link/173132/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Planetscale
Postgres Imports — PlanetScale
Learn how to use PlanetScale to power your application.
❤2
🔵 عنوان مقاله
VectorChord 0.5: Scalable, Fast, and Disk-Friendly Vector Search
🟢 خلاصه مقاله:
VectorChord 0.5 یک افزونه متن‌باز جست‌وجوی برداری برای PostgreSQL است که با مجوز دوگانه AGPLv3/ELv2 عرضه می‌شود و بر سرعت، مقیاس‌پذیری و کارایی دیسک تأکید دارد. این ابزار با انواع داده و دستورهای pgvector سازگار است، بنابراین بسیاری از برنامه‌های فعلی می‌توانند با تغییرات حداقلی آن را بیازمایند یا مهاجرت دهند. هدف آن ارائه بهبود چشمگیر کارایی و پشتیبانی از مجموعه‌داده‌های بزرگ‌تر (حتی فراتر از حافظه) است و برای کاربردهایی مانند جست‌وجوی معنایی، RAG و سیستم‌های توصیه مناسب توصیف می‌شود. مخزن GitHub پروژه شامل کد، مستندات و راهنمای ارزیابی عملکرد است و گزینه‌ای عملی برای تیم‌هایی است که می‌خواهند در اکوسیستم Postgres بمانند اما جست‌وجوی برداری سریع‌تر و مقیاس‌پذیرتری داشته باشند.
🟣لینک مقاله:
https://postgresweekly.com/link/173145/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
VectorChord 0.5: Scalable, Fast, and Disk-Friendly Vector Search
🟢 خلاصه مقاله:
VectorChord 0.5 یک افزونه متن‌باز جست‌وجوی برداری برای PostgreSQL است که با مجوز دوگانه AGPLv3/ELv2 عرضه می‌شود و بر سرعت، مقیاس‌پذیری و کارایی دیسک تأکید دارد. این ابزار با انواع داده و دستورهای pgvector سازگار است، بنابراین بسیاری از برنامه‌های فعلی می‌توانند با تغییرات حداقلی آن را بیازمایند یا مهاجرت دهند. هدف آن ارائه بهبود چشمگیر کارایی و پشتیبانی از مجموعه‌داده‌های بزرگ‌تر (حتی فراتر از حافظه) است و برای کاربردهایی مانند جست‌وجوی معنایی، RAG و سیستم‌های توصیه مناسب توصیف می‌شود. مخزن GitHub پروژه شامل کد، مستندات و راهنمای ارزیابی عملکرد است و گزینه‌ای عملی برای تیم‌هایی است که می‌خواهند در اکوسیستم Postgres بمانند اما جست‌وجوی برداری سریع‌تر و مقیاس‌پذیرتری داشته باشند.
🟣لینک مقاله:
https://postgresweekly.com/link/173145/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
vectorchord.ai
Scalable, fast, and disk-friendly vector search in Postgres, vectorchord is the successor of pgvecto.rs.
👍2
🔵 عنوان مقاله
'self-driving' Postgres
🟢 خلاصه مقاله:
منظور از «Postgres خودران» سامانه‌ای است که با تکیه بر تله‌متری داخلی و معیارهای میزبان، تنظیمات و نگهداشت‌های روزمره را به‌صورت خودکار انجام می‌دهد تا کارایی پایدار با حداقل دخالت انسانی حفظ شود. این سامانه با چرخه مشاهده–تصمیم–اقدام، پارامترهای حافظه و موازی‌سازی، تنظیمات autovacuum/ANALYZE، مدیریت شاخص‌ها و زمان‌بندی وظایف نگهداشت (مانند VACUUM و REINDEX) را به‌صورت ایمن و مرحله‌ای بهینه می‌کند و در صورت افت نسبت به اهداف سطح خدمت (SLO) به‌سرعت بازمی‌گردد. با خط‌کش‌های ایمنی، آزمایش کاناری/نسخه پشتیبان، ثبت شفاف تصمیم‌ها و امکان تأیید انسانی برای ریسک‌های بالا، هدف آن کاهش کار تکراری و خطای انسانی و تقویت نقش DBA است، نه جایگزینی کامل آن.
🟣لینک مقاله:
https://postgresweekly.com/link/173135/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
'self-driving' Postgres
🟢 خلاصه مقاله:
منظور از «Postgres خودران» سامانه‌ای است که با تکیه بر تله‌متری داخلی و معیارهای میزبان، تنظیمات و نگهداشت‌های روزمره را به‌صورت خودکار انجام می‌دهد تا کارایی پایدار با حداقل دخالت انسانی حفظ شود. این سامانه با چرخه مشاهده–تصمیم–اقدام، پارامترهای حافظه و موازی‌سازی، تنظیمات autovacuum/ANALYZE، مدیریت شاخص‌ها و زمان‌بندی وظایف نگهداشت (مانند VACUUM و REINDEX) را به‌صورت ایمن و مرحله‌ای بهینه می‌کند و در صورت افت نسبت به اهداف سطح خدمت (SLO) به‌سرعت بازمی‌گردد. با خط‌کش‌های ایمنی، آزمایش کاناری/نسخه پشتیبان، ثبت شفاف تصمیم‌ها و امکان تأیید انسانی برای ریسک‌های بالا، هدف آن کاهش کار تکراری و خطای انسانی و تقویت نقش DBA است، نه جایگزینی کامل آن.
🟣لینک مقاله:
https://postgresweekly.com/link/173135/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres FM
Postgres FM | Self-driving Postgres
Nikolay and Michael discuss self-driving Postgres — what it could mean, using self-driving cars as a reference, and ideas for things to build and optimize for in this area. Here are some links to t...
❤1
Forwarded from AI Labdon
برگه تقلب برنامه نویسی رو از اینجا پیدا کن
▪️اگه داری برنامه نویسی رو یاد میگیری یا دنبال کار میگردی و مصاحبه میری این چیت شیت ها( برگه تقلب ها) گزینه های خیلی خوبی هست برای مرور...
▪️تقریبا اکثر زبان ها و ابزارهارو پوشش میده و میتونی استفاده کنی ؛ نکته جذابش اینه که پرکابرد ترین پرامپت های ChatGPT هم داره :))
آدرس سایت:
Quickref.me
▪️اگه داری برنامه نویسی رو یاد میگیری یا دنبال کار میگردی و مصاحبه میری این چیت شیت ها( برگه تقلب ها) گزینه های خیلی خوبی هست برای مرور...
▪️تقریبا اکثر زبان ها و ابزارهارو پوشش میده و میتونی استفاده کنی ؛ نکته جذابش اینه که پرکابرد ترین پرامپت های ChatGPT هم داره :))
آدرس سایت:
Quickref.me
👍1🤡1
🔵 عنوان مقاله
Vector Search Isn't the Answer to Everything. So What Is?
🟢 خلاصه مقاله:
** این مقاله توضیح می‌دهد که جست‌وجوی برداری به‌تنهایی پاسخ‌گوی همه نیازهای بازیابی اطلاعات نیست و رویکرد بهینه، ترکیب جست‌وجوی متنی/کلیدواژه‌ای PostgreSQL با جست‌وجوی معنایی مبتنی بر pgvector است. نویسنده با نگاهی عملی، مراحل ساخت یک سیستم هیبریدی را—including مدل‌سازی و تکه‌کردن داده، تولید بردارها، شاخص‌گذاری، اجرای همزمان مسیرهای متنی و برداری و ادغام امتیازها—شرح می‌دهد و به ارزیابی دقت، تاخیر، هزینه و نگهداری اشاره می‌کند. جمع‌بندی: با PostgreSQL و pgvector می‌توان بدون زیرساخت جداگانه، جست‌وجویی کارآمدتر و دقیق‌تر ساخت.
🟣لینک مقاله:
https://postgresweekly.com/link/173138/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Vector Search Isn't the Answer to Everything. So What Is?
🟢 خلاصه مقاله:
** این مقاله توضیح می‌دهد که جست‌وجوی برداری به‌تنهایی پاسخ‌گوی همه نیازهای بازیابی اطلاعات نیست و رویکرد بهینه، ترکیب جست‌وجوی متنی/کلیدواژه‌ای PostgreSQL با جست‌وجوی معنایی مبتنی بر pgvector است. نویسنده با نگاهی عملی، مراحل ساخت یک سیستم هیبریدی را—including مدل‌سازی و تکه‌کردن داده، تولید بردارها، شاخص‌گذاری، اجرای همزمان مسیرهای متنی و برداری و ادغام امتیازها—شرح می‌دهد و به ارزیابی دقت، تاخیر، هزینه و نگهداری اشاره می‌کند. جمع‌بندی: با PostgreSQL و pgvector می‌توان بدون زیرساخت جداگانه، جست‌وجویی کارآمدتر و دقیق‌تر ساخت.
🟣لینک مقاله:
https://postgresweekly.com/link/173138/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TigerData Blog
Vector Search Isn't the Answer to Everything. So What Is? A Technical Deep Dive
TigerData’s Jacky Liang argues that vector search alone isn't sufficient for many AI applications since it provides similarity when users need exact relevance.
❤2
🔵 عنوان مقاله
Why Postgres is a Good Choice for Durable Workflow Execution
🟢 خلاصه مقاله:
این مطلب توضیح می‌دهد که چرا پستگرس یک گزینه عملی و قابل اعتماد برای اجرای گردش‌کارهای پایدار است، به‌ویژه در برنامه‌های Go. پستگرس با تراکنش‌های ACID و WAL، دوام و درستی را تضمین می‌کند؛ با الگوهایی مثل outbox/inbox، کلیدهای idempotency و محدودیت‌های یکتا می‌توان اثرات جانبی را حتی در صورت تکرار، فقط یک‌بار اعمال کرد. امکاناتی مانند SELECT … FOR UPDATE SKIP LOCKED، قفل‌های مشورتی و LISTEN/NOTIFY ساخت صف‌های کاری، زمان‌بندی وظایف و هماهنگی بین کارگرها را ساده می‌کند. نگهداری وضعیت و لاگ‌ها در جداول SQL، مشاهده‌پذیری، اشکال‌زدایی و بازیابی را آسان می‌سازد. از نظر عملیاتی، پستگرس با پشتیبان‌گیری، تکرار و پارتیشن‌بندی بالغ است و در بسیاری از بارهای کاری نیاز به موتورهای اختصاصی را برطرف می‌کند؛ هرچند در مقیاس‌های بسیار بزرگ یا ارکستراسیون پیچیده، ابزارهای تخصصی همچون Kafka یا Temporal مناسب‌ترند. نتیجه: برای طیف وسیعی از سیستم‌ها، پستگرس انتخاب پیش‌فرضی عالی برای اجرای گردش‌کارهای پایدار است.
🟣لینک مقاله:
https://postgresweekly.com/link/173140/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Why Postgres is a Good Choice for Durable Workflow Execution
🟢 خلاصه مقاله:
این مطلب توضیح می‌دهد که چرا پستگرس یک گزینه عملی و قابل اعتماد برای اجرای گردش‌کارهای پایدار است، به‌ویژه در برنامه‌های Go. پستگرس با تراکنش‌های ACID و WAL، دوام و درستی را تضمین می‌کند؛ با الگوهایی مثل outbox/inbox، کلیدهای idempotency و محدودیت‌های یکتا می‌توان اثرات جانبی را حتی در صورت تکرار، فقط یک‌بار اعمال کرد. امکاناتی مانند SELECT … FOR UPDATE SKIP LOCKED، قفل‌های مشورتی و LISTEN/NOTIFY ساخت صف‌های کاری، زمان‌بندی وظایف و هماهنگی بین کارگرها را ساده می‌کند. نگهداری وضعیت و لاگ‌ها در جداول SQL، مشاهده‌پذیری، اشکال‌زدایی و بازیابی را آسان می‌سازد. از نظر عملیاتی، پستگرس با پشتیبان‌گیری، تکرار و پارتیشن‌بندی بالغ است و در بسیاری از بارهای کاری نیاز به موتورهای اختصاصی را برطرف می‌کند؛ هرچند در مقیاس‌های بسیار بزرگ یا ارکستراسیون پیچیده، ابزارهای تخصصی همچون Kafka یا Temporal مناسب‌ترند. نتیجه: برای طیف وسیعی از سیستم‌ها، پستگرس انتخاب پیش‌فرضی عالی برای اجرای گردش‌کارهای پایدار است.
🟣لینک مقاله:
https://postgresweekly.com/link/173140/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
www.dbos.dev
Why Postgres is a Good Choice for Durable Workflow Execution | DBOS
In this blog post, we’ll dive deep into why we chose to build DBOS durable workflow execution on the PostgreSQL DBMS.
🔵 عنوان مقاله
PlanetScale's new Postgres offering
🟢 خلاصه مقاله:
** پلنت‌اسکیل دسترسی به سرویس جدید پایگاه‌داده PostgreSQL خود را آغاز کرده است و اعلام کرده همه افراد در لیست انتظار طی این هفته دعوت می‌شوند. همچنین برای تسهیل مهاجرت، راهنمای گام‌به‌گامی منتشر کرده که مراحل آماده‌سازی، انتقال داده و قطع‌و‌وصل کم‌ریسک را برای جابه‌جایی پایگاه‌داده‌های موجود به پلتفرم آن‌ها توضیح می‌دهد.
🟣لینک مقاله:
https://postgresweekly.com/link/173130/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PlanetScale's new Postgres offering
🟢 خلاصه مقاله:
** پلنت‌اسکیل دسترسی به سرویس جدید پایگاه‌داده PostgreSQL خود را آغاز کرده است و اعلام کرده همه افراد در لیست انتظار طی این هفته دعوت می‌شوند. همچنین برای تسهیل مهاجرت، راهنمای گام‌به‌گامی منتشر کرده که مراحل آماده‌سازی، انتقال داده و قطع‌و‌وصل کم‌ریسک را برای جابه‌جایی پایگاه‌داده‌های موجود به پلتفرم آن‌ها توضیح می‌دهد.
🟣لینک مقاله:
https://postgresweekly.com/link/173130/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Planetscale
Announcing PlanetScale for Postgres — PlanetScale
PlanetScale now supports Postgres
🔵 عنوان مقاله
Postgres Logging for Performance Optimization
🟢 خلاصه مقاله:
** این مقاله نشان می‌دهد که لاگ‌گیری در PostgreSQL، با وجود نادیده‌گرفته‌شدنش، ابزاری کلیدی برای بهینه‌سازی کارایی است. الیزابت با راهنمایی جامع و عملی از ابتدا تا انتها، سطوح لاگ، انتخاب این‌که چه پرس‌وجوهایی را ثبت کنیم، قالب‌بندی، چرخش و نگهداشت لاگ‌ها، و شیوه‌های پردازش و تحلیل آن‌ها را پوشش می‌دهد تا لاگ‌ها به بینش‌های قابل‌اقدام برای پیدا کردن گلوگاه‌ها و تأیید بهبودهای عملکردی تبدیل شوند.
🟣لینک مقاله:
https://postgresweekly.com/link/173127/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres Logging for Performance Optimization
🟢 خلاصه مقاله:
** این مقاله نشان می‌دهد که لاگ‌گیری در PostgreSQL، با وجود نادیده‌گرفته‌شدنش، ابزاری کلیدی برای بهینه‌سازی کارایی است. الیزابت با راهنمایی جامع و عملی از ابتدا تا انتها، سطوح لاگ، انتخاب این‌که چه پرس‌وجوهایی را ثبت کنیم، قالب‌بندی، چرخش و نگهداشت لاگ‌ها، و شیوه‌های پردازش و تحلیل آن‌ها را پوشش می‌دهد تا لاگ‌ها به بینش‌های قابل‌اقدام برای پیدا کردن گلوگاه‌ها و تأیید بهبودهای عملکردی تبدیل شوند.
🟣لینک مقاله:
https://postgresweekly.com/link/173127/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Postgres Logging for Performance Optimization | Crunchy Data Blog
Review key logging configurations in Postgres plus how to log key performance metrics.