‍ پستگرس که «در لطافت طبعش خلاف نیست»، به قول سعدی علیه الرحمه «در باغ لاله روید و در شوره زار خس». مفسرین بر این باورند که منظور شیخ این بوده است که این دیتابیس، گاهی اوقات بسیار عالی و خوب عمل می‌کند و برای بسیاری از کاربردهای امروزی که نیاز به کوئری‌های پیچیده روی حجم عظیم دیتای ورودی داریم، ما را با چالش‌های جدی مواجه می‌کند.
در وبینار زیر، به این پرسش اساسی پاسخ می‌دهیم که اگر با پستگرس در مواجهه با داده‌های زیاد به چالش برخوردیم،‌ چه کنیم و اصلا آیا پستگرس برای خیلی از نیازمندیهای امروز می‌تواند گزینه مناسبی باشد یا نه ؟ مروری بر راه‌حل‌های کلاسیک این مساله و راه‌حل‌هایی که در چند سال اخیر پیش روی ما قرار گرفته است می‌پردازیم.
دیتابیس‌هایی مبتنی بر پستگرس مانند ParadeDB، دیتابیس‌هایی با پروتکل پستگرس مانند CockroachDB و RisingWave‌ و افزونه‌هایی مانند Hydra را بررسی می کنیم.
اگر در حال استفاده از پستگرس هستید و نگرانی‌هایی راجع به آن در مواجهه با نیازمندیهای جدید دارید،‌ شاید این وبینار که به صورت عملی برگزار خواهد شد، برای شما مفید باشد.
https://anisa.co.ir/fa/news/2-uncategorised/298-workshop-23.html
#پستگرس #Postgres #PostgreSQL

اگر با پستگرس کار می‌کنید و

- قصد راه‌اندازی CDC را بر روی آن دارید، مثلا قصد دارید به ازای هر کاربر جدید یا هر سفارش جدید، یک رخداد جدید به صورت خودکار ایجاد شده و به کافکا ارسال گردد تا در یک پایپ‌لاین پردازش داده، اقدام مناسب برای آن رخداد (مثلا ایجاد یک کدتخفیف سفارشی و ارسال به مشتری)‌ انجام شود.

- یا می‌خواهید یک بکاپ از برخی جداول اصلی خود روی یک یا چند نود پستگرس دیگر ایجاد کنید

- و یا قصد دارید پردازش‌های تحلیلی خود را به جای پستگرس بر روی کلیک‌هوس انجام بدهید و بار پردازش‌های سنگین را از دوش پستگرس بردارید

برای تمامی این موارد، می توانید از PeerDB‌ استفاده کنید. به صورت خیلی شیک و مجلسی و با یک Web UI‌ ساده، جداول مورد نظر را انتخاب می کنید، مقصد انتقال (پستگرس یا کلیک‌هوس یا کافکا و ... ) را مشخص کرده و بقیه کار را به PeerDB‌ بسپرید. این ابزار که بر محور پستگرس ایجاد شده است، می‌تواند دستیار خوب شما در انتقال داده‌ها از پستگرس به هر مقصد دیگری باشد (البته لیست مقاصد انتقال با جذب سرمایه اخیر این ابزار در حال گسترش است). مزایایی مثل سرعت چندبرابر نسبت به ابزارهای فعلی را می‌توانید در مستندات این ابزار مفید پیدا کنید.

PeerDB: Our infrastructure is designed for real-time streaming from Postgres. If your application is latency-sensitive you can configure refresh intervals as low as a few seconds

PeerDB : https://docs.peerdb.io/quickstart/quickstart


#پستگرس #Postgres #PeerDB #PostgreSQL

اخیرا که درگیر انتقال داده‌ها از پستگرس به YugaByteDB (یک نسخه مقیاس‌پذیر و منطبق بر پستگرس) بودیم، ابزار ساده اما بسیار مفیدی را پیدا کردم با نام pgsync که برای جابجایی جداول بین این دو دیتابیس کمک زیادی به ما کرد.
هر چند جای بهبود زیادی دارد -مثلا روابط و وابستگی بین جداول را تشخیص نمی‌دهد و اینکار را باید خودمان به صورت دستی در فایل تنظیمات آن وارد کنیم- اما کار با آن ساده و نتیجه کار کاملا رضایت بخش است .
هم می تواند اسکیما را بررسی کرده و جداول مقصد را بسازد و هم امکان انتقال داده ها در دسته های ده هزارتایی را دارد و هم می‌توان جداولی که باید ابتدا منتقل شوند را گروه‌بندی کرده و در فایل تنظیمات آن یعنی .pgsync.yml وارد کرد و به صورت گروه به گروه،‌ عملیات انتقال را انجام داد.
https://github.com/ankane/pgsync
#postgres #postgresql #yugabytedb #db_migration

‍ از استانداردسازی تا ساده‌سازی: آینده‌ی Iceberg در مهندسی داده

🔍تحلیلی بر دو تحول مهم: DuckLake و مقاله جدید MinIO


احتمالاً توی یک سال گذشته، بارها چشم‌تون به مقالات، ابزارها، یا گفتگوهایی افتاده که حول‌وحوش موضوعی به اسم #Iceberg می‌چرخن — یه استاندارد باز و ساخت‌یافته برای ذخیره داده‌ها به‌صورت خام، اما با قابلیت‌هایی شبیه پایگاه داده:

📌امکان اجرای کوئری‌های تحلیلی مستقیم روی فایل‌های Parquet

📌پشتیبانی از schema evolution و تراکنش‌های ACID

📌و جداسازی کامل ذخیره‌سازی از موتور پردازش

🧊 به‌جرات میشه گفت که #Iceberg یکی از ترندهای داغ این روزهای مهندسی داده‌ست — از Google BigQuery گرفته تا AWS S3، از Dremio تا Snowflake و پروژه Polaris، همگی در حال پشتیبانی مستقیم یا بومی از Iceberg هستن.

و البته این موضوع فقط جهانی نیست — همین چند هفته پیش، در یکی از جلسات مشاوره‌ که با یکی از شرکت‌های بزرگ فولادی کشور بود، موضوع جلسه بررسی بهترین راه برای طراحی، راه‌اندازی، و مدیریت یک Lakehouse مبتنی بر Iceberg بود. کاری که تیم فنی این شرکت، نسخه اولیه آنرا راه اندازی کرده بود. 🚀

🔄 اما دو اتفاق باعث شد که احساس کنم : آینده‌ی Iceberg بسیار ساده‌تر و سبک‌تر خواهد بود.

🌟 اولی معرفی DuckLake بود - https://ducklake.select.

در دنیایی که پر بود از سرویس‌های کاتالوگ مختلف (Hive Metastore، Glue، Project Nessie، JDBC Metastore و...)، #DuckLake اومد و گفت:

«همه‌ی اینا رو بذارید کنار! من با یه دیتابیس SQL ساده، همه کارهای مدیریت متادیتا و فایل‌های داده رو انجام می‌دم.»

📦 داده‌ها همون Parquet هستن روی object storage، اما متادیتا داخل یه دیتابیس ساده مثل #DuckDB یا #Postgres ذخیره می‌شن. همه چیز از طریق #SQL مدیریت می‌شه. بدون نیاز به سرویس‌های جانبی، بدون پیچیدگی. دقیقاً شبیه #SQLite برای دیتالیک‌ها.

🔥 و استقبال خوبی هم ازش شده. چون ساده‌تر از Iceberg معمولی راه می‌افته و سربار کمتری داره.

🧠 دومین اتفاق، مقاله‌ای بود که همین چند روز پیش از طرف MinIO منتشر شد.
https://blog.min.io/the-case-for-native-iceberg-catalog-apis-and-unified-governance-in-object-storage

این مقاله به یه نقطه‌ضعف مهم در معماری‌های فعلی دیتالیک اشاره می‌کرد:

«متادیتا و دسترسی به فایل‌های واقعی داده، در دو سیستم جداگانه کنترل می‌شن. همین باعث می‌شه امنیت و حاکمیت داده ناقص باقی بمونه.»

یعنی ممکنه کاربر به جدول Iceberg مجوز نداشته باشه، ولی هنوز بتونه مستقیم فایل‌های #Parquet رو از #S3 یا #MinIO بخونه! 😬

استوریج MinIO پیشنهاد داده که APIهای Iceberg Catalog به‌صورت بومی در خود پلتفرم ذخیره‌سازی تعبیه بشن، طوری که هم متادیتا و هم دسترسی به فایل‌ها، از یک‌جا و با یک مدل امنیتی مدیریت بشن. این یعنی سادگی بیشتر، امنیت بهتر، و مدیریت یکپارچه‌تر.

🔮 پیش‌بینی من؟
ما داریم به سمتی می‌ریم که: Iceberg دیگه یه «ابزار حرفه‌ای مخصوص متخصص‌ها» نیست — بلکه تبدیل می‌شه به یک استاندارد ساده، امن، و در دسترس برای همه تیم‌های داده

🌊 به‌زودی، ساخت یک دریاچه‌داده قدرتمند، به اندازه راه‌اندازی یک دیتابیس ساده خواهد بود. و Iceberg ستون اصلی این تحول باقی می‌مونه.

#ApacheIceberg #DuckLake #MinIO #DataLakehouse #MetadataGovernance #ObjectStorage #OpenTableFormats #SQL #دیتالیک #مهندسی_داده #Parquet #BigData

‍ الگوی Outbox و داستان یک راهکار هوشمندانه در پستگرس

اخیراً مقاله‌ای از صادق دوستی در Dev.to خواندم که نشان داد با تجربه و تسلط، می‌توان برای چالش‌های بزرگ، راه‌حل‌هایی هوشمندانه و ساده پیدا کرد. یعنی در دنیای فنی، گاهی غرق پیچیدگی‌ها می‌شویم و راه‌حل‌های ساده اما عمیق را نادیده می‌گیریم. این پست ادای دینی است به صادق عزیز Sadeq Dousti و مقالات ارزشمندش، و مروری بر مشکل پیاده‌سازی الگوی Outbox با PostgreSQL در حجم بالای داده و راه‌حلی خلاقانه برای آن.

https://dev.to/msdousti/postgresql-outbox-pattern-revamped-part-1-3lai/



🎯 الگوی Outbox چیست؟

در یک فروشگاه آنلاین، ثبت سفارش باید چند کار را انجام دهد:

✅ذخیره در پایگاه داده

✅ارسال ایمیل تأیید

✅به‌روزرسانی موجودی

✅اطلاع به واحد ارسال

این اکشن‌ها به بروکرهایی مثل Kafka ارسال می‌شوند تا هر واحد کار خود را انجام دهد.

❓ اگر ارسال پیام به بروکر با خطا مواجه شود؟

Outbox وارد می‌شود! سفارش در پایگاه داده ذخیره شده و یک پیام در جدول Outbox ثبت می‌شود. یک سرویس جداگانه پیام‌ها را خوانده و به بروکر می‌فرستد. در صورت خطا، پیام در جدول باقی می‌ماند تا دوباره برای پردازش ارسال شود اما ...



🔍 چالش: حجم بالای داده‌ها

با افزایش پیام‌ها در Outbox:

⚠️کوئری‌های خواندن پیام‌های منتشرنشده کند می‌شوند.

⚠️ایندکس‌ها به دلیل آپدیت‌های مکرر غیربهینه می‌شوند.

⚠️مصرف منابع سیستم افزایش می‌یابد.



💡 راه‌حل: پارتیشن‌بندی هوشمند

صادق دوستی پیشنهاد می‌کند جدول Outbox را به دو پارتیشن تقسیم کنیم:

outbox_unpublished: پیام‌های منتشرنشده (published_at IS NULL)

outbox_published: پیام‌های منتشرشده (published_at NOT NULL)

با این کار، پیام‌های جدید به outbox_unpublished می‌روند و پس از انتشار، به‌صورت خودکار به outbox_published منتقل می‌شوند. بنابراین کوئری‌ها فقط روی پارتیشن سبک‌تر اجرا می‌شوند.



🎉 مزایا:

✅سرعت بالا: کوئری‌ها روی پارتیشن کوچک‌تر اجرا می‌شوند.

✅مدیریت آسان: حذف پیام‌های قدیمی با TRUNCATE سریع است.

✅بهینه‌سازی منابع: ایندکس‌ها کوچک و کارآمد می‌مانند.



🏁 جمع‌بندی

الگوی Outbox برای هماهنگی سیستم‌های توزیع‌شده عالی است، اما پیاده‌سازی نادرست آن مشکل‌ساز می‌شود. پارتیشن‌بندی هوشمند صادق دوستی این الگو را بهینه‌تر و سریع‌تر می‌کند.

🔗 برای جزئیات بیشتر، حتا مقاله صادق در Dev.to را بخوانید!

#outbox #postgres #performance #database #dataengineering

#مهندسی_داده

‍ چرا بسیاری از تیم‌ها 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 فکر کنیم — این بار با بلوغ بیشتر و ابزارهای بهتر.

‍ از Postgres تا Lakehouse زنده در کمتر از یک ثانیه -  نگاهی به Mooncake و استراتژی جسورانه Databricks

مدت‌ها بود که پروژه Pg_mooncake رو زیر نظر داشتم تا ببینم کی به مرحله نهایی می‌رسه ،  پروژه‌ای نوآور که می‌خواست Postgres رو با Iceberg ترکیب کنه و داده‌های تحلیلی و عملیاتی رو روی یک پایه مشترک بیاره.

و حالا… دیدم که Databricks این تیم خلاق رو هم خریداری کرده! درست مثل خرید قبلی‌شون یعنی Neon (نسخه‌ی cloud-native از Postgres).

لینک خبر :
https://www.linkedin.com/posts/databricks_were-excited-to-announce-that-databricks-activity-7379138538652696576-2pbr

به‌نظر می‌رسه دیتابریکز داره با قدرت وارد فضای Lakehouse + OLTP + AI می‌شه.  چیزی که خودشون اسمش رو گذاشتن Lakebase؛ پایگاه‌داده‌ای مبتنی بر Postgres که برای Agentهای هوش مصنوعی بهینه‌سازی شده و عملاً نیاز به ETL رو از بین می‌بره.

💡 اما Mooncake دقیقاً چی بود و چرا مهمه؟

به زبان ساده، Mooncake کمک می‌کنه داده‌هایی که در Postgres ذخیره می‌شن به کمک یک افزونه پستگرس که با rust نوشته شده، تقریباً بلافاصله و بدون نیاز به ابزارهای پیچیده، داخل یک لیک‌هوس با فرمت آیس‌برگ یا دلتا ذخیره شده و برای تحلیل و گزارش های سنگین با انواع کوئری انجین ها مثل ترینو، استارراکز، اسپارک و حتی کلیک‌هوس آماده بشن.
با ترکیب Postgres و Iceberg و با استفاده از امکانات خود mooncake:

🔰 داده‌ها به‌صورت زنده (real-time) همگام می‌شن حتی با آپدیت و حذف
🔰 تحلیل‌ها با کمک DuckDB سریع انجام می‌شن،
🔰 و همه‌چی بدون پیچیدگی ETL یا کپی‌کاری، در همون لحظه قابل استفاده‌ست.

یه جور پل بین ذخیره‌سازی عملیاتی و تحلیل زنده‌ست - دقیقاً همون چیزی که خیلی از شرکت‌ها مدت‌هاست دنبالش بودن.


🎯 واقعاً مشخص نیست دقیقاً چه استراتژی‌ بزرگی پشت این خریدهاست، اما چیزی که واضحه اینه که Databricks داره آینده پایگاه‌های داده Postgres-محور رو با هوش مصنوعی و تحلیل real-time بازتعریف می‌کنه.

👋 به تیم Mooncake تبریک می‌گم، و مشتاقم ببینم در ادامه چه اتفاقات بزرگی رقم می‌زنن!

شروع رسمی دوره پستگرس کاربردی در مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses/

#Databricks #Mooncake #Postgres #Iceberg #Lakehouse #OLTP #AI #Lakebase #DataEngineering #OpenSourc