🔵 عنوان مقاله
Apache Parquet vs. Newer File Formats (BtrBlocks, FastLanes, Lance, Vortex) (7 minute read)
🟢 خلاصه مقاله:
Apache Parquet بیش از یک دهه فرمت ستونی غالب بوده و به لطف چیدمان ستونی، فشردهسازی مؤثر و پشتیبانی گسترده در اکوسیستمهایی مثل Spark و Iceberg، برای اسکنهای حجیم و تحلیلهای دستهای عالی عمل میکند. اما با تغییر نیازها به سمت AI و سختافزارهای جدید مثل NVMe، SIMD و GPU، فرمتهای تازهای مانند BtrBlocks، FastLanes، Lance، Vortex و Nimble معرفی شدهاند که روی دسترسی کمتأخیر، بهرهگیری از SIMD/GPU و خواندن گزینشی داده تمرکز دارند. این فرمتها معمولاً با بازطراحی کُدگذاری و چیدمان صفحات، سربار پردازش را کاهش میدهند و برای پایپلاینهای AI و تحلیل تعاملی مناسبتر میشوند. در مقابل، Parquet از بلوغ و سازگاری گسترده برخوردار است و ابزارها و عملیات پایدارتری دارد. راهبرد منطقی، حفظ Parquet برای تبادل و تحلیل عمومی و استفاده هدفمند از فرمتهای جدید در سناریوهایی است که بهبود ملموسی در تأخیر یا هزینه محاسباتی روی NVMe/GPU نشان میدهند.
#ApacheParquet #FileFormats #ColumnarStorage #AI #GPU #NVMe #SIMD #DataEngineering
🟣لینک مقاله:
https://dipankar-tnt.medium.com/apache-parquet-vs-newer-file-formats-btrblocks-fastlanes-lance-vortex-cdf02130182c?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Apache Parquet vs. Newer File Formats (BtrBlocks, FastLanes, Lance, Vortex) (7 minute read)
🟢 خلاصه مقاله:
Apache Parquet بیش از یک دهه فرمت ستونی غالب بوده و به لطف چیدمان ستونی، فشردهسازی مؤثر و پشتیبانی گسترده در اکوسیستمهایی مثل Spark و Iceberg، برای اسکنهای حجیم و تحلیلهای دستهای عالی عمل میکند. اما با تغییر نیازها به سمت AI و سختافزارهای جدید مثل NVMe، SIMD و GPU، فرمتهای تازهای مانند BtrBlocks، FastLanes، Lance، Vortex و Nimble معرفی شدهاند که روی دسترسی کمتأخیر، بهرهگیری از SIMD/GPU و خواندن گزینشی داده تمرکز دارند. این فرمتها معمولاً با بازطراحی کُدگذاری و چیدمان صفحات، سربار پردازش را کاهش میدهند و برای پایپلاینهای AI و تحلیل تعاملی مناسبتر میشوند. در مقابل، Parquet از بلوغ و سازگاری گسترده برخوردار است و ابزارها و عملیات پایدارتری دارد. راهبرد منطقی، حفظ Parquet برای تبادل و تحلیل عمومی و استفاده هدفمند از فرمتهای جدید در سناریوهایی است که بهبود ملموسی در تأخیر یا هزینه محاسباتی روی NVMe/GPU نشان میدهند.
#ApacheParquet #FileFormats #ColumnarStorage #AI #GPU #NVMe #SIMD #DataEngineering
🟣لینک مقاله:
https://dipankar-tnt.medium.com/apache-parquet-vs-newer-file-formats-btrblocks-fastlanes-lance-vortex-cdf02130182c?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
Apache Parquet vs. Newer File Formats (BtrBlocks, FastLanes, Lance, Vortex)
For over a decade, Apache Parquet has been the cornerstone of analytical data storage. Parquet emerged in the Hadoop era as an open…
🔵 عنوان مقاله
PostgreSQL R2DBC Driver 1.1
🟢 خلاصه مقاله:
PostgreSQL R2DBC Driver 1.1 دسترسی Reactive و غیرمسدودکننده به PostgreSQL را برای برنامههای Java فراهم میکند. با تکیه بر R2DBC و پشتیبانی از backpressure، اجرای کوئریها و استریم نتایج بهصورت asynchronous انجام میشود و زیر بار بالا کارایی و بهرهوری منابع بهبود مییابد. این درایور با Project Reactor، Spring WebFlux و Spring Data R2DBC یکپارچه است و اجازه میدهد کل مسیر از HTTP تا دیتابیس Reactive باقی بماند و قابلیتهایی مثل ترکیب، لغو و مدیریت جریانها را فراهم میکند. نسخه 1.1 بر بلوغ و پایداری تمرکز دارد و با بهبود همخوانی با R2DBC SPI و بهینهسازی رفتار تحت فشار، برای استفاده تولیدی مناسبتر شده است. اگر معماری شما Reactive است یا به همزمانی بالا و استریم داده نیاز دارید، این درایور انتخاب مناسبی است؛ در سناریوهای ساده و مسدودکننده، JDBC همچنان میتواند گزینهای عملی باشد.
#PostgreSQL #R2DBC #Java #SpringWebFlux #ReactiveProgramming #NonBlocking #Databases #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175405/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostgreSQL R2DBC Driver 1.1
🟢 خلاصه مقاله:
PostgreSQL R2DBC Driver 1.1 دسترسی Reactive و غیرمسدودکننده به PostgreSQL را برای برنامههای Java فراهم میکند. با تکیه بر R2DBC و پشتیبانی از backpressure، اجرای کوئریها و استریم نتایج بهصورت asynchronous انجام میشود و زیر بار بالا کارایی و بهرهوری منابع بهبود مییابد. این درایور با Project Reactor، Spring WebFlux و Spring Data R2DBC یکپارچه است و اجازه میدهد کل مسیر از HTTP تا دیتابیس Reactive باقی بماند و قابلیتهایی مثل ترکیب، لغو و مدیریت جریانها را فراهم میکند. نسخه 1.1 بر بلوغ و پایداری تمرکز دارد و با بهبود همخوانی با R2DBC SPI و بهینهسازی رفتار تحت فشار، برای استفاده تولیدی مناسبتر شده است. اگر معماری شما Reactive است یا به همزمانی بالا و استریم داده نیاز دارید، این درایور انتخاب مناسبی است؛ در سناریوهای ساده و مسدودکننده، JDBC همچنان میتواند گزینهای عملی باشد.
#PostgreSQL #R2DBC #Java #SpringWebFlux #ReactiveProgramming #NonBlocking #Databases #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175405/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
Release v1.1.0.RELEASE · pgjdbc/r2dbc-postgresql
⭐ New Features
Expose API to subscribe to Postgres notice messages #570
Add codecs for DayOfWeek, Month, MonthDay, Period, Year, YearMonth #591
Make CodecMetadata.getDataTypes() more flexible #600...
Expose API to subscribe to Postgres notice messages #570
Add codecs for DayOfWeek, Month, MonthDay, Period, Year, YearMonth #591
Make CodecMetadata.getDataTypes() more flexible #600...
متغیرهای سیستمی در SQL Server
در SQL Server، متغیرهایی که با @@ شروع میشوند به عنوان متغیرهای سیستمی شناخته میشوند و اطلاعات مهمی درباره وضعیت سرور، کوئریها، تراکنشها و تنظیمات جاری ارائه میدهند.
این متغیرها توسط SQL Server مدیریت میشوند و کاربر فقط میتواند مقادیر آنها را بخواند، نه تغییر دهد.
نکته پرفرمنس: استفاده مکرر از متغیرهای سیستمی روی کوئریهای سنگین تاثیری مستقیم روی سرعت ندارد، اما بررسیهای مکرر یا استفاده نادرست در کوئریهای پیچیده میتواند منجر به کدهای نامفهوم یا غیر بهینه شود.
در SQL Server، متغیرهایی که با @@ شروع میشوند به عنوان متغیرهای سیستمی شناخته میشوند و اطلاعات مهمی درباره وضعیت سرور، کوئریها، تراکنشها و تنظیمات جاری ارائه میدهند.
این متغیرها توسط SQL Server مدیریت میشوند و کاربر فقط میتواند مقادیر آنها را بخواند، نه تغییر دهد.
نکته پرفرمنس: استفاده مکرر از متغیرهای سیستمی روی کوئریهای سنگین تاثیری مستقیم روی سرعت ندارد، اما بررسیهای مکرر یا استفاده نادرست در کوئریهای پیچیده میتواند منجر به کدهای نامفهوم یا غیر بهینه شود.
❤1👍1
🔵 عنوان مقاله
Postgres 18 Released
🟢 خلاصه مقاله:
Postgres 18 طبق برنامه منتشر شد. این نسخه جهش انقلابی نیست، اما مجموعهای از بهبودهای هدفمند ارائه میدهد که در عمل به اجرای سریعتر کوئریها، استفاده مؤثرتر از ایندکسها، I/O کارآمدتر و نگهداری سبکتر (VACUUM/autovacuum) منجر میشود. بهینهسازیهای تکرار و بازیابی نیز پایداری و توان عملیاتی را برای سناریوهای High Availability بهتر میکنند. علاوه بر این، گزینههای پیکربندی و پایش شفافتر و سختگیریهای امنیتی تازه، مدیریت و تیونینگ را سادهتر میسازد. برای ارتقا، یادداشتهای نسخه را بررسی کنید، سازگاری اکستنشنها را بسنجید و روی محیط Stage با بار کاری واقعی تست بگیرید.
#Postgres #PostgreSQL #Database #Performance #Release #SQL #OpenSource #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/174773/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres 18 Released
🟢 خلاصه مقاله:
Postgres 18 طبق برنامه منتشر شد. این نسخه جهش انقلابی نیست، اما مجموعهای از بهبودهای هدفمند ارائه میدهد که در عمل به اجرای سریعتر کوئریها، استفاده مؤثرتر از ایندکسها، I/O کارآمدتر و نگهداری سبکتر (VACUUM/autovacuum) منجر میشود. بهینهسازیهای تکرار و بازیابی نیز پایداری و توان عملیاتی را برای سناریوهای High Availability بهتر میکنند. علاوه بر این، گزینههای پیکربندی و پایش شفافتر و سختگیریهای امنیتی تازه، مدیریت و تیونینگ را سادهتر میسازد. برای ارتقا، یادداشتهای نسخه را بررسی کنید، سازگاری اکستنشنها را بسنجید و روی محیط Stage با بار کاری واقعی تست بگیرید.
#Postgres #PostgreSQL #Database #Performance #Release #SQL #OpenSource #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/174773/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostgreSQL News
PostgreSQL 18 Released!
The [PostgreSQL Global Development Group](https://www.postgresql.org) today announced the release of [PostgreSQL 18](https://www.postgresql.org/docs/18/release-18.html), the latest version of the world's most advanced …
تا حالا فکر کردین استراتژی redis برای پاک کردن کلیدهای cache که ttl اونها اکسپایر شده چیه؟
در واقع redis دو تا استراتژی داره که از ترکیب این دو برای مدیریت این موضوع استفاده میکنه.
1️- استراتژی اول که بهش میگن lazy expiration ساده ترینشه اینه که وقتی درخواستی برای گرفتن یه کلید اومد اول چک میکنه اون کلید اکسپایر شده یا نه اگه آره اون رو همونجا پاک میکنه و نال برمیگردونه.
2- خب اگه یه کلید برای مدتها صدا زده نشه چی؟ اینجاست که میرسیم به استراتژی دوم یعنی active expiration و به این شکله که میاد مثلا هر 100 میلی ثانیه توی لوپ یه batch که شامل مثلا 20 کلید تصادفی هست رو بررسی میکنه و اونایی که اکسپایر شدن رو پاک میکنه. اگه توی اون لوپ بیشتر از 25 درصد کلیدها پاک بشن اون رو زباله تشخیص میده و حدس میزنه کلیدهای بیشتری هم اکسپایر شدن پس یه batch دیگه اجرا میکنه و در نهایت لوپ تموم میشه تا دوباره لوپ بعدی.
برای همین برخلاف تصور، کلیدهای cache بالافاصله با اتمام ttl حذف نمیشن و ممکنه برای مدتی توی حافظه سرور باقی بمونن مخصوصا اگه حجم کلیدها بالا باشه.
پ.ن: چک کردن تعداد کلیدها در هر لوپ و تعداد اجرای لوپ در ثانیه توی کانفیگ redis قابل تنظیمه، ولی نکته ای که هست هر چی تعداد رو بالاتر ببرین کلیدها سریعتر حذف میشن اما cpu بیشتری درگیر میشه.
@ | <Farshad Tofighi/>
در واقع redis دو تا استراتژی داره که از ترکیب این دو برای مدیریت این موضوع استفاده میکنه.
1️- استراتژی اول که بهش میگن lazy expiration ساده ترینشه اینه که وقتی درخواستی برای گرفتن یه کلید اومد اول چک میکنه اون کلید اکسپایر شده یا نه اگه آره اون رو همونجا پاک میکنه و نال برمیگردونه.
2- خب اگه یه کلید برای مدتها صدا زده نشه چی؟ اینجاست که میرسیم به استراتژی دوم یعنی active expiration و به این شکله که میاد مثلا هر 100 میلی ثانیه توی لوپ یه batch که شامل مثلا 20 کلید تصادفی هست رو بررسی میکنه و اونایی که اکسپایر شدن رو پاک میکنه. اگه توی اون لوپ بیشتر از 25 درصد کلیدها پاک بشن اون رو زباله تشخیص میده و حدس میزنه کلیدهای بیشتری هم اکسپایر شدن پس یه batch دیگه اجرا میکنه و در نهایت لوپ تموم میشه تا دوباره لوپ بعدی.
برای همین برخلاف تصور، کلیدهای cache بالافاصله با اتمام ttl حذف نمیشن و ممکنه برای مدتی توی حافظه سرور باقی بمونن مخصوصا اگه حجم کلیدها بالا باشه.
پ.ن: چک کردن تعداد کلیدها در هر لوپ و تعداد اجرای لوپ در ثانیه توی کانفیگ redis قابل تنظیمه، ولی نکته ای که هست هر چی تعداد رو بالاتر ببرین کلیدها سریعتر حذف میشن اما cpu بیشتری درگیر میشه.
@ | <Farshad Tofighi/>
👍3
🔵 عنوان مقاله
ChartDB (Tool)
🟢 خلاصه مقاله:
ChartDB ابزاری برای تبدیل سریع schema پایگاهداده به ER diagram است که با ویرایش هوشمند مبتنی بر AI، همکاری همزمان و همگامسازی خودکار با دیتابیس زنده، کار تیمهای مهندسی را ساده میکند. از Postgres، MySQL، SQL Server و Oracle پشتیبانی میکند، DDL تمیز تولید میکند و مستندات قابل اشتراکگذاری با نسخهبندی ارائه میدهد تا مدلها و مستندات همیشه بهروز و قابل پیگیری بمانند.
#DatabaseDesign #ERD #DataModeling #AI #DevTools #Postgres #MySQL #SQLServer
🟣لینک مقاله:
https://chartdb.io/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
ChartDB (Tool)
🟢 خلاصه مقاله:
ChartDB ابزاری برای تبدیل سریع schema پایگاهداده به ER diagram است که با ویرایش هوشمند مبتنی بر AI، همکاری همزمان و همگامسازی خودکار با دیتابیس زنده، کار تیمهای مهندسی را ساده میکند. از Postgres، MySQL، SQL Server و Oracle پشتیبانی میکند، DDL تمیز تولید میکند و مستندات قابل اشتراکگذاری با نسخهبندی ارائه میدهد تا مدلها و مستندات همیشه بهروز و قابل پیگیری بمانند.
#DatabaseDesign #ERD #DataModeling #AI #DevTools #Postgres #MySQL #SQLServer
🟣لینک مقاله:
https://chartdb.io/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
chartdb.io
ChartDB - Database schema diagrams visualizer
Free and Open-source database diagrams editor, visualize and design your database with a single query.
Tool to help you draw your DB relationship diagrams and export DDL noscripts.
Tool to help you draw your DB relationship diagrams and export DDL noscripts.
🔵 عنوان مقاله
IBM Invites CockroachDB to Infest Its Mainframes with 'PostgreSQL'
🟢 خلاصه مقاله:
**اصل خبر از The Register این است که IBM بهدنبال ارائه یک گزینه سازگار با PostgreSQL روی مینفریمهای خود است؛ اشاره به CockroachDB بهخاطر سازگاری آن با پروتکل PostgreSQL است و تیتر طنزآمیز را توضیح میدهد. هدف، آسانتر کردن مدرنسازی، استفاده از مهارتهای رایج Postgres و کاهش اصطکاک مهاجرت در محیطهای هیبریدی است. باید دید عملکرد روی مینفریم، ابزارهای عملیاتی، امنیت/انطباق و مسیرهای مهاجرت چگونه مدیریت میشوند و اینکه IBM واقعاً با CockroachDB شریک میشود یا راهحل سازگار دیگری ارائه میکند.
#IBM #CockroachDB #PostgreSQL #Mainframe #TheRegister #Database #EnterpriseIT #Modernization
🟣لینک مقاله:
https://postgresweekly.com/link/175399/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
IBM Invites CockroachDB to Infest Its Mainframes with 'PostgreSQL'
🟢 خلاصه مقاله:
**اصل خبر از The Register این است که IBM بهدنبال ارائه یک گزینه سازگار با PostgreSQL روی مینفریمهای خود است؛ اشاره به CockroachDB بهخاطر سازگاری آن با پروتکل PostgreSQL است و تیتر طنزآمیز را توضیح میدهد. هدف، آسانتر کردن مدرنسازی، استفاده از مهارتهای رایج Postgres و کاهش اصطکاک مهاجرت در محیطهای هیبریدی است. باید دید عملکرد روی مینفریم، ابزارهای عملیاتی، امنیت/انطباق و مسیرهای مهاجرت چگونه مدیریت میشوند و اینکه IBM واقعاً با CockroachDB شریک میشود یا راهحل سازگار دیگری ارائه میکند.
#IBM #CockroachDB #PostgreSQL #Mainframe #TheRegister #Database #EnterpriseIT #Modernization
🟣لینک مقاله:
https://postgresweekly.com/link/175399/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Register
IBM invites CockroachDB to infest its mainframes with PostgreSQL
: Vendors promote bridge to modern architecture for legacy systems, but Db2 not going anywhere just yet
🔵 عنوان مقاله
pg_statement_rollback v1.5: Server Side Rollback at Statement Level
🟢 خلاصه مقاله:
pg_statement_rollback v1.5 امکان «rollback در سطح هر دستور» را بهصورت سروری در Postgres ارائه میکند؛ رفتاری شبیه آنچه در Oracle و Db2 وجود دارد. بهجای اینکه با خطای یک دستور، کل تراکنش در Postgres از کار بیفتد، فقط همان دستور برگشت داده میشود و تراکنش فعال میماند. این کار پیچیدگی مدیریت SAVEPOINT در لایه اپلیکیشن را کاهش میدهد، تابآوری تراکنشهای طولانی و بارگذاریهای حجیم را بیشتر میکند، و مهاجرت از Oracle/Db2 به Postgres را سادهتر میسازد. نسخه 1.5 پشتیبانی از Postgres 18 را اضافه کرده است.
#PostgreSQL #pg_statement_rollback #StatementLevelRollback #TransactionManagement #Oracle #Db2 #Postgres18
🟣لینک مقاله:
https://postgresweekly.com/link/175404/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pg_statement_rollback v1.5: Server Side Rollback at Statement Level
🟢 خلاصه مقاله:
pg_statement_rollback v1.5 امکان «rollback در سطح هر دستور» را بهصورت سروری در Postgres ارائه میکند؛ رفتاری شبیه آنچه در Oracle و Db2 وجود دارد. بهجای اینکه با خطای یک دستور، کل تراکنش در Postgres از کار بیفتد، فقط همان دستور برگشت داده میشود و تراکنش فعال میماند. این کار پیچیدگی مدیریت SAVEPOINT در لایه اپلیکیشن را کاهش میدهد، تابآوری تراکنشهای طولانی و بارگذاریهای حجیم را بیشتر میکند، و مهاجرت از Oracle/Db2 به Postgres را سادهتر میسازد. نسخه 1.5 پشتیبانی از Postgres 18 را اضافه کرده است.
#PostgreSQL #pg_statement_rollback #StatementLevelRollback #TransactionManagement #Oracle #Db2 #Postgres18
🟣لینک مقاله:
https://postgresweekly.com/link/175404/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - HexaCluster/pg_statement_rollback: Server side rollback at statement level for PostgreSQL like Oracle or DB2
Server side rollback at statement level for PostgreSQL like Oracle or DB2 - HexaCluster/pg_statement_rollback
Forwarded from Future Pulse Persian
♨️ پیام جنجالی پاول دروف به کاربران فرانسوی ؛ هشدار درباره قانون «کنترل چت» اتحادیه اروپا
▪️طبق پیغام جدید پاول دروف ، ظاهراً اتحادیه اروپا قرار بوده قانونی تصویب کنه که تمام اپلیکیشنها رو مجبور به اسکن همه پیامهای خصوصی کاربران میکرد! چیزی شبیه یک سیستم جاسوسی سراسری روی گوشی همه مردم.
▪️فرانسه، با حمایت وزیران کشور سابق و فعلی در رأس این طرح قرار داشت. به عقدیده دروف چنین طرحی به بهانه «مبارزه با جرم» معرفی شده، اما در واقع هدفش مردم عادی و جاسوسی از مردمه.
+ چرا که مجرمان واقعی بهراحتی از VPN یا ابزارهای مخفی استفاده میکنن، در حالیکه پیامهای مقامات و پلیس از این نظارت معاف هستند!
♨️ پیام جنجالی پاول دروف به کاربران فرانسوی ؛ هشدار درباره قانون «کنترل چت» اتحادیه اروپا
▪️طبق پیغام جدید پاول دروف ، ظاهراً اتحادیه اروپا قرار بوده قانونی تصویب کنه که تمام اپلیکیشنها رو مجبور به اسکن همه پیامهای خصوصی کاربران میکرد! چیزی شبیه یک سیستم جاسوسی سراسری روی گوشی همه مردم.
▪️فرانسه، با حمایت وزیران کشور سابق و فعلی در رأس این طرح قرار داشت. به عقدیده دروف چنین طرحی به بهانه «مبارزه با جرم» معرفی شده، اما در واقع هدفش مردم عادی و جاسوسی از مردمه.
+ چرا که مجرمان واقعی بهراحتی از VPN یا ابزارهای مخفی استفاده میکنن، در حالیکه پیامهای مقامات و پلیس از این نظارت معاف هستند!
❤1
🔵 عنوان مقاله
full feature set here
🟢 خلاصه مقاله:
این بهروزرسانی اعلام میکند که مجموعه کامل قابلیتها اکنون بهصورت عمومی در دسترس است و بهطور رسمی از Postgres 18 پشتیبانی میکند. تمام مسیرهای عملیاتی—from provisioning و migrations تا monitoring، HA، backups، pooling و performance tuning—در برابر Postgres 18 اعتبارسنجی شدهاند و برای اکثر اپلیکیشنها نیازی به تغییر کد نیست. برای ارتقا، راهنمای گامبهگام برای in‑place و blue/green همراه با preflight checks، الگوهای rollout و مسیر بازگشت فراهم است؛ فقط توجه داشته باشید برخی extensions شخصثالث ممکن است با Postgres 18 کمی عقب باشند. این نسخه مزایای بهبودهای عملکردی، پایداری و امنیتی را ارائه میدهد؛ تنظیمات جدید بهصورت محافظهکارانه فعال میشوند و گزینههای پیشرفته قابل تنظیم هستند. پشتیبانی در محیطهای cloud و on‑prem عرضه شده، تصاویر و قالبهای CI/CD بهروزرسانی شدهاند و اسناد و راهنمای مهاجرت آماده است؛ تیم پشتیبانی برای ارزیابی، پایلوت و استقرار تولید در دسترس است.
#Postgres18 #PostgreSQL #Database #Compatibility #Upgrade #DevOps #Release #DBA
🟣لینک مقاله:
https://postgresweekly.com/link/175106/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
full feature set here
🟢 خلاصه مقاله:
این بهروزرسانی اعلام میکند که مجموعه کامل قابلیتها اکنون بهصورت عمومی در دسترس است و بهطور رسمی از Postgres 18 پشتیبانی میکند. تمام مسیرهای عملیاتی—from provisioning و migrations تا monitoring، HA، backups، pooling و performance tuning—در برابر Postgres 18 اعتبارسنجی شدهاند و برای اکثر اپلیکیشنها نیازی به تغییر کد نیست. برای ارتقا، راهنمای گامبهگام برای in‑place و blue/green همراه با preflight checks، الگوهای rollout و مسیر بازگشت فراهم است؛ فقط توجه داشته باشید برخی extensions شخصثالث ممکن است با Postgres 18 کمی عقب باشند. این نسخه مزایای بهبودهای عملکردی، پایداری و امنیتی را ارائه میدهد؛ تنظیمات جدید بهصورت محافظهکارانه فعال میشوند و گزینههای پیشرفته قابل تنظیم هستند. پشتیبانی در محیطهای cloud و on‑prem عرضه شده، تصاویر و قالبهای CI/CD بهروزرسانی شدهاند و اسناد و راهنمای مهاجرت آماده است؛ تیم پشتیبانی برای ارزیابی، پایلوت و استقرار تولید در دسترس است.
#Postgres18 #PostgreSQL #Database #Compatibility #Upgrade #DevOps #Release #DBA
🟣لینک مقاله:
https://postgresweekly.com/link/175106/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - pgcentralfoundation/pgrx: Build Postgres Extensions with Rust!
Build Postgres Extensions with Rust! Contribute to pgcentralfoundation/pgrx development by creating an account on GitHub.
🔵 عنوان مقاله
Ratcheting with Postgres CONSTRAINT
🟢 خلاصه مقاله:
خلاصه «ratcheting» روشی برای سفتوسخت کردن تدریجی قوانین داده در Postgres با تکیه بر CONSTRAINT است. بهجای اعمال یکباره و پرریسک محدودیتها، ابتدا قواعد را بهصورت نرم اعمال میکنیم (ثبت و پایش تخلفات در اپلیکیشن) و سپس معادل آنها را بهصورت NOT VALID اضافه میکنیم تا فقط نوشتارهای جدید بررسی شوند. بعد از پاکسازی و بکفیل، با VALIDATE CONSTRAINT قاعده برای کل داده معتبر میشود. برای قیود چندردیفی یا چندتراکنشی میتوان از DEFERRABLE و INITIALLY DEFERRED استفاده کرد. الگوهای رایج شامل تبدیل فیلدهای اختیاری به الزامی با بکفیل و سپس SET NOT NULL، افزودن FOREIGN KEY بهصورت NOT VALID و اعتبارسنجی پس از رفع یتیمها، استفاده از ایندکسهای UNIQUE جزئی برای یکتایی شرطی، و بهکارگیری EXCLUDE برای جلوگیری از تداخلهای زمانی/فضایی است. این رویکرد باعث میشود قیود بهتدریج از اسناد و منطق اپلیکیشن به لایه خود Postgres منتقل شوند و با عملکرد بهتر، ریسک کمتر و سادگی بیشتر، یکپارچگی داده را تضمین کنند.
#Postgres #SQL #DataIntegrity #DatabaseMigrations #Constraints #EXCLUDE #DEFERRABLE #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/175397/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Ratcheting with Postgres CONSTRAINT
🟢 خلاصه مقاله:
خلاصه «ratcheting» روشی برای سفتوسخت کردن تدریجی قوانین داده در Postgres با تکیه بر CONSTRAINT است. بهجای اعمال یکباره و پرریسک محدودیتها، ابتدا قواعد را بهصورت نرم اعمال میکنیم (ثبت و پایش تخلفات در اپلیکیشن) و سپس معادل آنها را بهصورت NOT VALID اضافه میکنیم تا فقط نوشتارهای جدید بررسی شوند. بعد از پاکسازی و بکفیل، با VALIDATE CONSTRAINT قاعده برای کل داده معتبر میشود. برای قیود چندردیفی یا چندتراکنشی میتوان از DEFERRABLE و INITIALLY DEFERRED استفاده کرد. الگوهای رایج شامل تبدیل فیلدهای اختیاری به الزامی با بکفیل و سپس SET NOT NULL، افزودن FOREIGN KEY بهصورت NOT VALID و اعتبارسنجی پس از رفع یتیمها، استفاده از ایندکسهای UNIQUE جزئی برای یکتایی شرطی، و بهکارگیری EXCLUDE برای جلوگیری از تداخلهای زمانی/فضایی است. این رویکرد باعث میشود قیود بهتدریج از اسناد و منطق اپلیکیشن به لایه خود Postgres منتقل شوند و با عملکرد بهتر، ریسک کمتر و سادگی بیشتر، یکپارچگی داده را تضمین کنند.
#Postgres #SQL #DataIntegrity #DatabaseMigrations #Constraints #EXCLUDE #DEFERRABLE #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/175397/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Andrewjudson
Ratcheting with Postgres CONSTRAINT
🔥1
🔵 عنوان مقاله
Postgres Migrations Using Logical Replication
🟢 خلاصه مقاله:
** مهاجرت به Postgres با تکیه بر Logical Replication به الگوی رایج برای جابهجایی کموقفه تبدیل شده است؛ دادهها بهصورت جریان تغییرات منتقل میشوند، اسکیما از پیش هماهنگ میشود و کاتاور کنترلشده انجام میگیرد. در خبرها، یادداشت Elizabeth Christensen به تیتر طنزآمیز The Register درباره IBM و CockroachDB اشاره میکند، اما اصل ماجرا این است که IBM به ارائه گزینهای Postgres‑like روی مینفریم فکر میکند؛ نشانهای از پذیرش گسترده اکوسیستم Postgres و امکان استقرارهای ناهمگون که با Logical Replication به مهاجرتهای مرحلهای کمک میکند. در بُعد کارایی، Aksman و Hein از TigerData در TimescaleDB نشان میدهند چرا DISTINCT روی دادههای سریزمانی کند میشود و چگونه SkipScan با «پرش» در محدودههای ایندکس، این کوئریها را سریعتر و بهینهتر میکند. همچنین Sebastian Insausti به بهبودهای عملیاتی و گزینههای یکپارچهسازی در Postgres 16 میپردازد که مدیریت عملیات، مشاهدهپذیری و معماریهای هیبریدی مبتنی بر Logical Replication را سادهتر میکند. توصیه عملی: همسانسازی اسکیما، توجه به sequences/constraints/triggers، کوتاه نگهداشتن تراکنشها برای کاهش lag، رصد دقیق تاخیر اعمال، تمرین کاتاور و داشتن مسیر بازگشت تا اطمینان از صحت دادهها.
#Postgres
#LogicalReplication
#TimescaleDB
#SkipScan
#CockroachDB
#IBM
#PostgreSQL
#Postgres16
🟣لینک مقاله:
https://postgresweekly.com/link/175398/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres Migrations Using Logical Replication
🟢 خلاصه مقاله:
** مهاجرت به Postgres با تکیه بر Logical Replication به الگوی رایج برای جابهجایی کموقفه تبدیل شده است؛ دادهها بهصورت جریان تغییرات منتقل میشوند، اسکیما از پیش هماهنگ میشود و کاتاور کنترلشده انجام میگیرد. در خبرها، یادداشت Elizabeth Christensen به تیتر طنزآمیز The Register درباره IBM و CockroachDB اشاره میکند، اما اصل ماجرا این است که IBM به ارائه گزینهای Postgres‑like روی مینفریم فکر میکند؛ نشانهای از پذیرش گسترده اکوسیستم Postgres و امکان استقرارهای ناهمگون که با Logical Replication به مهاجرتهای مرحلهای کمک میکند. در بُعد کارایی، Aksman و Hein از TigerData در TimescaleDB نشان میدهند چرا DISTINCT روی دادههای سریزمانی کند میشود و چگونه SkipScan با «پرش» در محدودههای ایندکس، این کوئریها را سریعتر و بهینهتر میکند. همچنین Sebastian Insausti به بهبودهای عملیاتی و گزینههای یکپارچهسازی در Postgres 16 میپردازد که مدیریت عملیات، مشاهدهپذیری و معماریهای هیبریدی مبتنی بر Logical Replication را سادهتر میکند. توصیه عملی: همسانسازی اسکیما، توجه به sequences/constraints/triggers، کوتاه نگهداشتن تراکنشها برای کاهش lag، رصد دقیق تاخیر اعمال، تمرین کاتاور و داشتن مسیر بازگشت تا اطمینان از صحت دادهها.
#Postgres
#LogicalReplication
#TimescaleDB
#SkipScan
#CockroachDB
#IBM
#PostgreSQL
#Postgres16
🟣لینک مقاله:
https://postgresweekly.com/link/175398/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Postgres Migrations Using Logical Replication | Crunchy Data Blog
Instructions and tips for using logical replication to migrate Postgres to a new platform or host.
🔵 عنوان مقاله
A SQL Heuristic: ORs Are Expensive (10 minute read)
🟢 خلاصه مقاله:
OR در SQL اغلب باعث کندی میشود، چون بسیاری از query plannerها برای OR بین ستونهای مختلف به sequential scan یا index merge/bitmap OR متوسل میشوند، در حالیکه AND بهطور طبیعی با compound indexها جور است. یک راه مؤثر، بازنویسی OR به چند کوئریِ ایندکسپسند و ترکیب آنها با UNION/UNION ALL است تا هر شاخه از ایندکس مناسب خود استفاده کند و زمان اجرا گاهی تا ۱۰۰ برابر کاهش یابد. راهحل پایدارتر، بازطراحی schema با extension tables است تا بهجای OR روی چند خاصیتِ پراکنده، با JOIN به جدولهای باریک و ایندکسشده دسترسی پیدا کنید. همیشه با EXPLAIN/EXPLAIN ANALYZE اندازهگیری کنید؛ در جداول کوچک یا OR روی یک ستون (مشابه IN) شاید مشکل نداشته باشید، اما بهطور کلی: AND را با compound index هماهنگ کنید، از OR بین ستونها بپرهیزید، در صورت لزوم از UNION بهره ببرید و برای مسیرهای پرتردد، بازطراحی schema را در نظر بگیرید.
#SQL #DatabasePerformance #QueryOptimization #Indexes #PostgreSQL #MySQL #DataModeling #EXPLAIN
🟣لینک مقاله:
https://ethanseal.com/articles/ors-are-expensive?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
A SQL Heuristic: ORs Are Expensive (10 minute read)
🟢 خلاصه مقاله:
OR در SQL اغلب باعث کندی میشود، چون بسیاری از query plannerها برای OR بین ستونهای مختلف به sequential scan یا index merge/bitmap OR متوسل میشوند، در حالیکه AND بهطور طبیعی با compound indexها جور است. یک راه مؤثر، بازنویسی OR به چند کوئریِ ایندکسپسند و ترکیب آنها با UNION/UNION ALL است تا هر شاخه از ایندکس مناسب خود استفاده کند و زمان اجرا گاهی تا ۱۰۰ برابر کاهش یابد. راهحل پایدارتر، بازطراحی schema با extension tables است تا بهجای OR روی چند خاصیتِ پراکنده، با JOIN به جدولهای باریک و ایندکسشده دسترسی پیدا کنید. همیشه با EXPLAIN/EXPLAIN ANALYZE اندازهگیری کنید؛ در جداول کوچک یا OR روی یک ستون (مشابه IN) شاید مشکل نداشته باشید، اما بهطور کلی: AND را با compound index هماهنگ کنید، از OR بین ستونها بپرهیزید، در صورت لزوم از UNION بهره ببرید و برای مسیرهای پرتردد، بازطراحی schema را در نظر بگیرید.
#SQL #DatabasePerformance #QueryOptimization #Indexes #PostgreSQL #MySQL #DataModeling #EXPLAIN
🟣لینک مقاله:
https://ethanseal.com/articles/ors-are-expensive?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔵 عنوان مقاله
Hands on Postgres 18: Async I/O, B-Tree Skip Scan, UUIDv7
🟢 خلاصه مقاله:
بنیانگذار pganalyze در یک وبینار، قابلیتهای مهم Postgres 18 را بهصورت عملی مرور میکند؛ از جمله Async I/O، B-Tree Skip Scan و UUIDv7. بخش Async I/O (از ۴:۲۰ تا ۲۲:۳۰) برجستهتر است و نشان میدهد چگونه همپوشانی محاسبه و ورودی/خروجی میتواند تأخیر را کم و توان عملیاتی را در بارهای I/O-محور افزایش دهد. B-Tree Skip Scan اسکن روی ایندکسهای مرکب را وقتی فیلتر شامل ستون اول نیست کاراتر میکند و هزینه پرسوجو را پایین میآورد. UUIDv7 نیز با نظم زمانی بهتر، locality ایندکس را بهبود میدهد و درجها را پیوستهتر میکند. نتیجه اینکه این وبینار راهنمایی عملی برای ارزیابی و بهکارگیری قابلیتهای جدید Postgres 18 ارائه میدهد، و بخش Async I/O ارزش تماشای ویژهای دارد.
#Postgres18 #PostgreSQL #AsyncIO #BTree #UUIDv7 #DatabasePerformance #pganalyze
🟣لینک مقاله:
https://postgresweekly.com/link/175388/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Hands on Postgres 18: Async I/O, B-Tree Skip Scan, UUIDv7
🟢 خلاصه مقاله:
بنیانگذار pganalyze در یک وبینار، قابلیتهای مهم Postgres 18 را بهصورت عملی مرور میکند؛ از جمله Async I/O، B-Tree Skip Scan و UUIDv7. بخش Async I/O (از ۴:۲۰ تا ۲۲:۳۰) برجستهتر است و نشان میدهد چگونه همپوشانی محاسبه و ورودی/خروجی میتواند تأخیر را کم و توان عملیاتی را در بارهای I/O-محور افزایش دهد. B-Tree Skip Scan اسکن روی ایندکسهای مرکب را وقتی فیلتر شامل ستون اول نیست کاراتر میکند و هزینه پرسوجو را پایین میآورد. UUIDv7 نیز با نظم زمانی بهتر، locality ایندکس را بهبود میدهد و درجها را پیوستهتر میکند. نتیجه اینکه این وبینار راهنمایی عملی برای ارزیابی و بهکارگیری قابلیتهای جدید Postgres 18 ارائه میدهد، و بخش Async I/O ارزش تماشای ویژهای دارد.
#Postgres18 #PostgreSQL #AsyncIO #BTree #UUIDv7 #DatabasePerformance #pganalyze
🟣لینک مقاله:
https://postgresweekly.com/link/175388/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
YouTube
Webinar Recording: Hands on Postgres 18: Async I/O, B-tree Skip Scan, UUIDv7
The release of PostgreSQL 18 introduced significant changes that directly influence performance at scale: from the introduction of asynchronous I/O, which changes how Postgres interacts with the disk both in the cloud and on-premise, to new planner optimizations…
🔵 عنوان مقاله
SkipScan in TimescaleDB: Why DISTINCT Was Slow, How We Built It, and How You Can Use It
🟢 خلاصه مقاله:
SkipScan در TimescaleDB مشکل دیرینهی کندی کوئریهای DISTINCT را هدف میگیرد؛ جایی که برای یافتن مقادیر یکتا، اسکنهای بزرگ و تکراری روی ایندکس انجام میشود. این ویژگی با «پرش» از میان بلوکهای مقادیر تکراری و رفتن مستقیم به مقدار یکتای بعدی، تعداد خواندنها و مقایسهها را کاهش میدهد و DISTINCT و DISTINCT ON را مخصوصاً روی هایپرتیبلهای بزرگ سریعتر میکند. برای بهرهگیری عملی، ایندکسهای B-tree چندستونه همراستا با کلیدهای DISTINCT و ترتیب ORDER BY بسازید؛ برنامهریز بهصورت خودکار در الگوهای مناسب SkipScan را انتخاب میکند و در غیر این صورت به مسیرهای عادی برمیگردد. بیشترین سود زمانی است که دادهها تکرار زیاد و همجواری مناسب در ایندکس داشته باشند.
همزمان، Aksman و Hein از TigerData با همراهی Sebastian Insausti به بهبودهای عملیاتی و گزینههای یکپارچهسازی در Postgres 16 میپردازند؛ از رصد و تنظیمپذیری بهتر گرفته تا سادهتر شدن نگهداری و همگامسازی و تقویت اکوسیستم الحاقات و اتصال به سامانههای دیگر. این تغییرات عملیاتی، در کنار بهینهسازیهایی مانند SkipScan، Postgres 16 را به پایهای توانمندتر برای بارهای تحلیلی و زمانمحور تبدیل میکند.
#TimescaleDB #Postgres16 #SkipScan #DISTINCT #DatabasePerformance #TimeSeries #SQL #Postgres
🟣لینک مقاله:
https://postgresweekly.com/link/175400/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
SkipScan in TimescaleDB: Why DISTINCT Was Slow, How We Built It, and How You Can Use It
🟢 خلاصه مقاله:
SkipScan در TimescaleDB مشکل دیرینهی کندی کوئریهای DISTINCT را هدف میگیرد؛ جایی که برای یافتن مقادیر یکتا، اسکنهای بزرگ و تکراری روی ایندکس انجام میشود. این ویژگی با «پرش» از میان بلوکهای مقادیر تکراری و رفتن مستقیم به مقدار یکتای بعدی، تعداد خواندنها و مقایسهها را کاهش میدهد و DISTINCT و DISTINCT ON را مخصوصاً روی هایپرتیبلهای بزرگ سریعتر میکند. برای بهرهگیری عملی، ایندکسهای B-tree چندستونه همراستا با کلیدهای DISTINCT و ترتیب ORDER BY بسازید؛ برنامهریز بهصورت خودکار در الگوهای مناسب SkipScan را انتخاب میکند و در غیر این صورت به مسیرهای عادی برمیگردد. بیشترین سود زمانی است که دادهها تکرار زیاد و همجواری مناسب در ایندکس داشته باشند.
همزمان، Aksman و Hein از TigerData با همراهی Sebastian Insausti به بهبودهای عملیاتی و گزینههای یکپارچهسازی در Postgres 16 میپردازند؛ از رصد و تنظیمپذیری بهتر گرفته تا سادهتر شدن نگهداری و همگامسازی و تقویت اکوسیستم الحاقات و اتصال به سامانههای دیگر. این تغییرات عملیاتی، در کنار بهینهسازیهایی مانند SkipScan، Postgres 16 را به پایهای توانمندتر برای بارهای تحلیلی و زمانمحور تبدیل میکند.
#TimescaleDB #Postgres16 #SkipScan #DISTINCT #DatabasePerformance #TimeSeries #SQL #Postgres
🟣لینک مقاله:
https://postgresweekly.com/link/175400/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TigerData Blog
SkipScan in TimescaleDB: Why DISTINCT Was Slow, How We Built It, and How You Can Use It
Learn how TimescaleDB's SkipScan transforms DISTINCT queries from multi-second waits to milliseconds by jumping between values instead of scanning every row.
Forwarded from AI Labdon
اگه برنامه نویس هستید و از هوش مصنوعی برای کدنویسی استفاده میکنید، واقعاً به خودتون لطف میکنید که OpenSpec رو چک کنید. این ابزار به شما کمک میکنه کنترل کامل پروژه رو دست بگیرید و از AI به عنوان یک همکار قابل اعتماد استفاده کنید!
تا حالا با دستیارهای کدنویسی هوش مصنوعی (مثل Cursor یا Copilot) کار کردید و به جای چیزی که دقیقاً در ذهن داشتید، یک چیز کاملاً دیگه تحویل گرفتید؟ یا یک بخش رو نوشته و یک بخش دیگه رو براتون خراب کرده
من جدیدا ابزاری رو پیدا کردم به اسم OpenSpec که داره این بازی رو برای همیشه عوض میکنه.
ایدهاش ساده و ناب هست: شما و هوش مصنوعی، قبل از نوشتن حتی یک خط کد، روی «چیزی که باید ساخته بشه» به توافق کامل میرسید.
دیگه خبری از پرامپتهای مبهم در چت و خروجیهای غیرقابل پیشبینی نیست. OpenSpec یک فرآیند کاری سبک و قدرتمند اضافه میکنه که پروژهها رو اینطوری پیش میبره:
۱. پیشنهاد تغییر (Change Proposal): شما به AI میگید چه قابلیتی رو میخواید اضافه کنید. AI یک ساختار کامل از مشخصات، وظایف و پیشنهادها رو براتون میسازه.
۲. بازبینی و هماهنگی: شما و AI با هم مشخصات رو دقیق میکنید تا همه چیز شفاف و بدون ابهام باشه.
۳. پیادهسازی: AI بر اساس مشخصات نهایی و توافق شده، کدنویسی رو انجام میده.
۴. آرشیو: بعد از اتمام کار، تغییرات به آرشیو منتقل میشن و مشخصات اصلی پروژه رو بهروز میکنن.
چرا این ابزار به خوبی جواب میده
- بدون نیاز به کلید API: نصب کن و استفاده کن. ساده و سریع.
- با ابزارهای فعلی شما کار میکنه: با Claude Code, Cursor, GitHub Copilot, Windsurf و دهها ابزار دیگه یکپارچه میشه.
- قابل پیشبینی و شفاف: دیگه نمیخواد حدس بزنید AI چی میسازه. همه چیز از قبل مشخصه.
- عالی برای پروژههای موجود: نه فقط برای پروژههای جدید، بلکه برای تغییر و توسعه کدهای قدیمی هم عالیه.
- مستندسازی خودکار: هر تغییری با مشخصات و وظایفش ثبت میشه و یک سند زنده از پروژه میسازه.
اینم آدرس گیتهابش که همه چیز اماده یک جا هست!
https://github.com/Fission-AI/OpenSpec
اگر نتونستنید دستی نصبش کنید ، میتونید فایل README[.]md رو کپی کنید ، بدید به همون ابزار Ai که براتون کد میزنه مثل Claude Code, Cursor, GitHub Copilot ، بگید نصبش کن!
<POURYA/>
تا حالا با دستیارهای کدنویسی هوش مصنوعی (مثل Cursor یا Copilot) کار کردید و به جای چیزی که دقیقاً در ذهن داشتید، یک چیز کاملاً دیگه تحویل گرفتید؟ یا یک بخش رو نوشته و یک بخش دیگه رو براتون خراب کرده
من جدیدا ابزاری رو پیدا کردم به اسم OpenSpec که داره این بازی رو برای همیشه عوض میکنه.
ایدهاش ساده و ناب هست: شما و هوش مصنوعی، قبل از نوشتن حتی یک خط کد، روی «چیزی که باید ساخته بشه» به توافق کامل میرسید.
دیگه خبری از پرامپتهای مبهم در چت و خروجیهای غیرقابل پیشبینی نیست. OpenSpec یک فرآیند کاری سبک و قدرتمند اضافه میکنه که پروژهها رو اینطوری پیش میبره:
۱. پیشنهاد تغییر (Change Proposal): شما به AI میگید چه قابلیتی رو میخواید اضافه کنید. AI یک ساختار کامل از مشخصات، وظایف و پیشنهادها رو براتون میسازه.
۲. بازبینی و هماهنگی: شما و AI با هم مشخصات رو دقیق میکنید تا همه چیز شفاف و بدون ابهام باشه.
۳. پیادهسازی: AI بر اساس مشخصات نهایی و توافق شده، کدنویسی رو انجام میده.
۴. آرشیو: بعد از اتمام کار، تغییرات به آرشیو منتقل میشن و مشخصات اصلی پروژه رو بهروز میکنن.
چرا این ابزار به خوبی جواب میده
- بدون نیاز به کلید API: نصب کن و استفاده کن. ساده و سریع.
- با ابزارهای فعلی شما کار میکنه: با Claude Code, Cursor, GitHub Copilot, Windsurf و دهها ابزار دیگه یکپارچه میشه.
- قابل پیشبینی و شفاف: دیگه نمیخواد حدس بزنید AI چی میسازه. همه چیز از قبل مشخصه.
- عالی برای پروژههای موجود: نه فقط برای پروژههای جدید، بلکه برای تغییر و توسعه کدهای قدیمی هم عالیه.
- مستندسازی خودکار: هر تغییری با مشخصات و وظایفش ثبت میشه و یک سند زنده از پروژه میسازه.
اینم آدرس گیتهابش که همه چیز اماده یک جا هست!
https://github.com/Fission-AI/OpenSpec
اگر نتونستنید دستی نصبش کنید ، میتونید فایل README[.]md رو کپی کنید ، بدید به همون ابزار Ai که براتون کد میزنه مثل Claude Code, Cursor, GitHub Copilot ، بگید نصبش کن!
<POURYA/>
GitHub
GitHub - Fission-AI/OpenSpec: Spec-driven development (SDD) for AI coding assistants.
Spec-driven development (SDD) for AI coding assistants. - Fission-AI/OpenSpec
کلید فراموششده بهینهسازی دیتابیس : Collation در MySQL
به عنوان برنامهنویس، همیشه روی ایندکس و کوئریها تمرکز میکنیم، اما یک تنظیم ساده در دیتابیس میتواند همه چیز را تغییر دهد: Collation
Collation چیست؟
تعیین میکند MySQL چگونه دادههای متنی را مقایسه و مرتبسازی میکند.
انتخاب اشتباه = مشکلات پنهان
دو نوع اصلی:
نوع یک : ci) Case-Insensitive_)
مقایسهها بدون توجه به حروف بزرگ و کوچک انجام میشود. برای مثال کوئری زیر همه ی مواردی مثل ali , Ali , ALI را برمی گرداند.
SELECT * FROM users WHERE username = 'ALI'
در این مثال collation ستون username برابر utf8mb4_unicode_ci می باشد.
نوع دو : bin) Case-Sensitive_)
مقایسهها حساس به حروف بزرگ و کوچک است. برای مثال کوئری زیر فقط ALI
را برمی گرداند.
SELECT * FROM users WHERE username = 'ALI'
در این مثال collation ستون username برابر utf8mb4_bin می باشد.
چرا مهم است؟
عملکرد: collationهای _bin معمولاً سریعترند.
دقت: اگر حساسیت به حروف بزرگ/کوچک مهم است، _bin ضروری است.
یکپارچگی داده: از ذخیره مقادیر تکراری ناخواسته جلوگیری میکند.
نکته طلایی:
قبل از طراحی جدول، از خود بپرسید:
"آیا در این فیلد، 'Ali' با 'ali' تفاوت دارد؟"
پاسخ این سؤال، collation مناسب را به شما میگوید.
<Babak Mirhosseini/>
به عنوان برنامهنویس، همیشه روی ایندکس و کوئریها تمرکز میکنیم، اما یک تنظیم ساده در دیتابیس میتواند همه چیز را تغییر دهد: Collation
Collation چیست؟
تعیین میکند MySQL چگونه دادههای متنی را مقایسه و مرتبسازی میکند.
انتخاب اشتباه = مشکلات پنهان
دو نوع اصلی:
نوع یک : ci) Case-Insensitive_)
مقایسهها بدون توجه به حروف بزرگ و کوچک انجام میشود. برای مثال کوئری زیر همه ی مواردی مثل ali , Ali , ALI را برمی گرداند.
SELECT * FROM users WHERE username = 'ALI'
در این مثال collation ستون username برابر utf8mb4_unicode_ci می باشد.
نوع دو : bin) Case-Sensitive_)
مقایسهها حساس به حروف بزرگ و کوچک است. برای مثال کوئری زیر فقط ALI
را برمی گرداند.
SELECT * FROM users WHERE username = 'ALI'
در این مثال collation ستون username برابر utf8mb4_bin می باشد.
چرا مهم است؟
عملکرد: collationهای _bin معمولاً سریعترند.
دقت: اگر حساسیت به حروف بزرگ/کوچک مهم است، _bin ضروری است.
یکپارچگی داده: از ذخیره مقادیر تکراری ناخواسته جلوگیری میکند.
نکته طلایی:
قبل از طراحی جدول، از خود بپرسید:
"آیا در این فیلد، 'Ali' با 'ali' تفاوت دارد؟"
پاسخ این سؤال، collation مناسب را به شما میگوید.
<Babak Mirhosseini/>
🔵 عنوان مقاله
How to Do UPDATE ... LIMIT
🟢 خلاصه مقاله:
در Postgres نمیتوان مستقیم از UPDATE ... LIMIT یا DELETE ... LIMIT استفاده کرد؛ هرچند در برخی لهجههای SQL مثل MySQL این امکان وجود دارد. راهحل استاندارد این است که ابتدا در یک زیرکوئری یا CTE با ORDER BY و LIMIT، شناسهٔ ردیفهای هدف را انتخاب کنید و سپس با UPDATE/DELETE روی همان شناسهها عمل کنید. برای محیطهای همزمان، استفاده از SELECT ... FOR UPDATE SKIP LOCKED در زیرکوئری باعث میشود هر پردازش فقط ردیفهای قفلنشده را بردارد و تداخل رخ ندهد. حتماً ORDER BY بگذارید تا انتخاب N ردیف قابل پیشبینی باشد و برای کارایی، ایندکس مناسب روی فیلترها و مرتبسازیها داشته باشید. در حجمهای بزرگ، عملیات را به صورت batch تکراری انجام دهید تا از تراکنشهای طولانی و فشار روی سیستم جلوگیری شود.
#Postgres #SQL #UPDATE #DELETE #LIMIT #CTE #SkipLocked #MySQL
🟣لینک مقاله:
https://postgresweekly.com/link/175093/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How to Do UPDATE ... LIMIT
🟢 خلاصه مقاله:
در Postgres نمیتوان مستقیم از UPDATE ... LIMIT یا DELETE ... LIMIT استفاده کرد؛ هرچند در برخی لهجههای SQL مثل MySQL این امکان وجود دارد. راهحل استاندارد این است که ابتدا در یک زیرکوئری یا CTE با ORDER BY و LIMIT، شناسهٔ ردیفهای هدف را انتخاب کنید و سپس با UPDATE/DELETE روی همان شناسهها عمل کنید. برای محیطهای همزمان، استفاده از SELECT ... FOR UPDATE SKIP LOCKED در زیرکوئری باعث میشود هر پردازش فقط ردیفهای قفلنشده را بردارد و تداخل رخ ندهد. حتماً ORDER BY بگذارید تا انتخاب N ردیف قابل پیشبینی باشد و برای کارایی، ایندکس مناسب روی فیلترها و مرتبسازیها داشته باشید. در حجمهای بزرگ، عملیات را به صورت batch تکراری انجام دهید تا از تراکنشهای طولانی و فشار روی سیستم جلوگیری شود.
#Postgres #SQL #UPDATE #DELETE #LIMIT #CTE #SkipLocked #MySQL
🟣لینک مقاله:
https://postgresweekly.com/link/175093/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
CYBERTEC PostgreSQL | Services & Support
How to do UPDATE ... LIMIT in PostgreSQL
There is no UPDATE ... LIMIT in PostgreSQL. This article shows how to achieve the same result and how to avoid potential pitfalls.
🔵 عنوان مقاله
results of its latest State of Developer Ecosystem Report
🟢 خلاصه مقاله:
گزارش جدید State of Developer Ecosystem از JetBrains نشان میدهد که برای نخستین بار، Postgres از MySQL در اکوسیستم JetBrains محبوبتر شده است. این تغییر حاکی از جابهجایی ترجیحات توسعهدهندگان به سمت قابلیتها و انعطافپذیری Postgres است؛ هرچند MySQL همچنان در بسیاری از محیطهای وب و پروژههای قدیمی نقش پررنگی دارد. ابزارها و ادغامهای اکوسیستم JetBrains و گسترش سرویسهای ابری مدیریتشده نیز میتواند در این روند مؤثر بوده باشد و نشان میدهد انتخاب پایگاهداده بیش از پیش بر اساس تناسب با نیاز هر پروژه انجام میشود.
#JetBrains #Postgres #MySQL #DeveloperEcosystem #Database #StateOfDeveloperEcosystem #SoftwareTrends
🟣لینک مقاله:
https://postgresweekly.com/link/175719/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
results of its latest State of Developer Ecosystem Report
🟢 خلاصه مقاله:
گزارش جدید State of Developer Ecosystem از JetBrains نشان میدهد که برای نخستین بار، Postgres از MySQL در اکوسیستم JetBrains محبوبتر شده است. این تغییر حاکی از جابهجایی ترجیحات توسعهدهندگان به سمت قابلیتها و انعطافپذیری Postgres است؛ هرچند MySQL همچنان در بسیاری از محیطهای وب و پروژههای قدیمی نقش پررنگی دارد. ابزارها و ادغامهای اکوسیستم JetBrains و گسترش سرویسهای ابری مدیریتشده نیز میتواند در این روند مؤثر بوده باشد و نشان میدهد انتخاب پایگاهداده بیش از پیش بر اساس تناسب با نیاز هر پروژه انجام میشود.
#JetBrains #Postgres #MySQL #DeveloperEcosystem #Database #StateOfDeveloperEcosystem #SoftwareTrends
🟣لینک مقاله:
https://postgresweekly.com/link/175719/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Jetbrains
The State of Developer Ecosystem in 2025
Explore key software developer statistics for 2025 in the State of Developer Ecosystem Report. Trends, insights, and tools shaping the developer world.
🔵 عنوان مقاله
A Postgres Trip Report from PGConf NYC 2025
🟢 خلاصه مقاله:
کلر، میزبان پادکست Talking Postgres، دو هفته پس از برگزاری موفق PGConf NYC 2025 گزارشی مفصل و صریح منتشر کرده است؛ او علاوه بر بیان برداشتها و روندهای برجسته و گفتگوهایش با اعضای جامعه، با مجموعهای از عکسها حالوهوای رویداد را برای کسانی که حضور نداشتند زنده میکند. این گزارش بدون ورود به ریزجزئیات جلسات، روی نکات کاربردی، روندهای قابلتوجه و حالوهوای روبهرشد جامعه Postgres تمرکز دارد و برای تازهواردها و متخصصان بهطور یکسان مفید است.
#Postgres #PGConfNYC #PGConf2025 #Databases #OpenSource #Conference #TalkingPostgres
🟣لینک مقاله:
https://postgresweekly.com/link/175715/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
A Postgres Trip Report from PGConf NYC 2025
🟢 خلاصه مقاله:
کلر، میزبان پادکست Talking Postgres، دو هفته پس از برگزاری موفق PGConf NYC 2025 گزارشی مفصل و صریح منتشر کرده است؛ او علاوه بر بیان برداشتها و روندهای برجسته و گفتگوهایش با اعضای جامعه، با مجموعهای از عکسها حالوهوای رویداد را برای کسانی که حضور نداشتند زنده میکند. این گزارش بدون ورود به ریزجزئیات جلسات، روی نکات کاربردی، روندهای قابلتوجه و حالوهوای روبهرشد جامعه Postgres تمرکز دارد و برای تازهواردها و متخصصان بهطور یکسان مفید است.
#Postgres #PGConfNYC #PGConf2025 #Databases #OpenSource #Conference #TalkingPostgres
🟣لینک مقاله:
https://postgresweekly.com/link/175715/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TECHCOMMUNITY.MICROSOFT.COM
Postgres Trip Report from PGConf NYC 2025 (with lots of photos) | Microsoft Community Hub
Overview of my Postgres speaker, sponsor, & attendee experience at PGConf NYC 2025, with quotes from attendees, talk highlights, and lots of photographs.
❤2🍾1
Forwarded from Future Pulse Persian
دارم پادکست پاول دوروف مال تلگرام رو میبینم
نکته جالبش اینجا اگر برادر نابغش نبود هیچ وقت تلگرامی وجود نداشت
نکته دیگه اینه اگر دقت کرده باشید پاول برعکس مارک زاکربرگ ، ایلان ماسک و . . .
زندگی خیلی لاکچری داره ولی ایلان و زاکربرگ همیشه ساده پوشن و خیلی زنی بی آلایشی از خودشون نشون میدن
حتی مارک و ایلان نهایتا ۶ تا ۸ ساعت میخوابن و پاول ۱۲ ساعت
دلیلش از نظر من خیلی جالبه
ایلان و زاکربرگ تمام سهام شرکتشون برای خودشون نیست! سرمایه گذار های بزرگی پشتشونه و هروقت بیان خودشون رو اینطور نشون بدن قطعابا فشار زیادی مواجه میشن
ولی پاول مالک خودش هست و برادرش و کلا ۴۰ برنامه نویس
هیچ وقت هم جواب به کسی نمیده
نکات خیلی زیادی داره این شخص پیشنهاد میکنم حتما درموردش مطالعه کنید
https://www.youtube.com/watch?v=qjPH9njnaVU
نکته جالبش اینجا اگر برادر نابغش نبود هیچ وقت تلگرامی وجود نداشت
نکته دیگه اینه اگر دقت کرده باشید پاول برعکس مارک زاکربرگ ، ایلان ماسک و . . .
زندگی خیلی لاکچری داره ولی ایلان و زاکربرگ همیشه ساده پوشن و خیلی زنی بی آلایشی از خودشون نشون میدن
حتی مارک و ایلان نهایتا ۶ تا ۸ ساعت میخوابن و پاول ۱۲ ساعت
دلیلش از نظر من خیلی جالبه
ایلان و زاکربرگ تمام سهام شرکتشون برای خودشون نیست! سرمایه گذار های بزرگی پشتشونه و هروقت بیان خودشون رو اینطور نشون بدن قطعابا فشار زیادی مواجه میشن
ولی پاول مالک خودش هست و برادرش و کلا ۴۰ برنامه نویس
هیچ وقت هم جواب به کسی نمیده
نکات خیلی زیادی داره این شخص پیشنهاد میکنم حتما درموردش مطالعه کنید
https://www.youtube.com/watch?v=qjPH9njnaVU
❤2