‍ از 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

همروندی و مدیریت تراکنش‌ها در Airflow: تجربه عملی از Postgres تا MinIO

🔹 در ادامه‌ی کارگاه‌های عملی مدرسه مهندسی داده سپهرام Sepahram Data Eng. School، یک ویدئو آموزشی یک‌ساعته آماده کردم که به یکی از مسائل بسیار مهم در طراحی پایپ‌لاین‌های داده با ایرفلو (Apache Airflow) می‌پردازد: موضوع همروندی (Concurrency).

در این ویدئو یک دگ (DAG) کاربردی را در ایرفلو نسخه 3.1 بررسی می‌کنیم که وظیفه‌اش انتقال تراکنش‌ها از پستگرس (Postgres) به MinIO است.


این دگ شامل چند مرحله است:

🔰سنسور برای انتظار تراکنش‌های جدید.

🔰تسک پردازش (Transform) برای استخراج تراکنش‌های خام از پایگاه داده.

🔰ذخیره‌سازی در MinIO به صورت JSON برای استفاده در مراحل بعدی (مثل ذخیره در Lakehouse).

🔰به‌روزرسانی وضعیت تراکنش‌ها در پستگرس به‌عنوان "پردازش‌شده".


❓ اما چالش کجا پیش می‌آید؟

وقتی چند بار این دگ را همزمان اجرا کنیم، هر بار ممکن است مجموعه‌ی مشابهی از تراکنش‌ها انتخاب شود و چندین بار پردازش شود. این همان مشکل اجرای ناخواسته‌ی موازی (Duplicate Processing) است.

برای حل این مسئله، در ویدئو چند راه‌حل بررسی شده است:

🟠 راه‌حل‌های محدود کردن همروندی

✨ گزینه depends_on_past: ایرفلو دگ یا تسک بعدی را تنها در صورتی اجرا می‌کند که اجرای قبلی همان تسک از دگ‌های قبلی تکمیل شده باشد.

✨ گزینه max_active_runs: می‌توانیم تعیین کنیم که حداکثر چند اجرای همزمان از یک دگ فعال باشد (مثلاً فقط یک اجرای فعال در لحظه).

✨ گزینه pool (در این دگ خاص بررسی نشد): ابزاری برای محدود کردن تعداد اجرای همزمان یک تسک مشخص.


🟢 راه‌حل‌های واقعی برای موازی‌سازی

اگر بخواهیم اجرای موازی واقعی برای سناریوی فوق (ترکیب ایرفلو و یک دیتابیس رابطه‌ای)، داشته باشیم، باید به سراغ تکنیک‌های سطح دیتابیس برویم. یکی از مهم‌ترین آنها:
- قفل‌گذاری موقت هنگام انتخاب سطرها با دستور FOR UPDATE SKIP LOCKED: با این تکنیک می‌توانیم در لحظه‌ی انتخاب رکوردها (SELECT) ردیف‌های انتخاب‌شده را قفل کنیم تا پردازش‌های دیگر نتوانند آنها را همزمان بردارند. این کار نیاز دارد که انتخاب (SELECT) و به‌روزرسانی (UPDATE) در همان تراکنش انجام شود تا رفتار اتمیک تضمین گردد.

💡 نکته‌ی اصلی این کارگاه این بود که:
طراحی پایپ‌لاین‌های داده با ایرفلو تنها به نوشتن چند تسک و اتصال آنها به هم خلاصه نمی‌شود. بلکه باید همه‌ی شرایط مرزی، اجرای همزمان دگ‌ها، قفل‌های دیتابیس و حتی طراحی ذخیره‌سازی (مثل MinIO یا Lakehouse) را با دقت بررسی کنیم.

📌 کدهای کامل این دگ در گیت‌هاب موجود است:

👉 https://github.com/sepahram-school/workshops/tree/main/2-Airflow-Concurrency-Control-SQL

🎥 امیدوارم این ویدئو برای تمام کسانی که در پروژه‌های واقعی با ایرفلو کار می‌کنند و دغدغه‌ی پایداری و دقت پایپ‌لاین‌های داده دارند، مفید و الهام‌بخش باشد.


کانال تلگرام BigData.IR - وب‌سایت مهندسی داده : https://t.iss.one/bigdata_ir

دوره‌های تخصصی سپهرام : https://sepahram.ir/courses

آدرس ویدئو در یوتیوب :

https://www.youtube.com/watch?v=sS6Ma40sngU

به تازگی کتاب Platform Engineering on Kubernetes نوشته‌ی Mauricio Salatino رو خوندم و واقعاً می‌تونم بگم یکی از منابع تحول‌آفرین در این حوزه‌ست.
پست اخیر Sajad Hamreh در لینکدین
چیزی که برای من خیلی جالب بود، این بود که کتاب فاصله بین دانش تئوری Kubernetes و عملیات واقعی Platform Engineering رو پر می‌کنه. یعنی نه صرفاً توضیح تئوریه و نه صرفاً دستورالعمل خشک، بلکه قدم‌به‌قدم نشون می‌ده چطور پلتفرمی بسازیم که واقعاً در دنیای واقعی کار کنه.
✅ از مباحث پایه Kubernetes شروع می‌کنه و به استراتژی‌های پیچیده‌تر مثل GitOps، progressive delivery، service mesh integration و multi-tenancy می‌رسه.
✅ فصل‌های مربوط به developer portals و self-service capabilities واقعاً برای من ارزشمند بودن؛ چون توی خیلی از منابع دیگه کمتر بهشون پرداخته می‌شه، در حالی که برای پذیرش موفق پلتفرم حیاتی هستن.
✅ نکته مهم دیگه اینه که با ابزارهایی مثل ArgoCD و Crossplane مثال‌های عملی زده که بلافاصله می‌شه در پروژه‌ها به‌کار برد.
✅ تجربه‌ی عمیق نویسنده هم در بخش‌های troubleshooting و هشدار درباره‌ی pitfalls کاملاً مشهوده؛ چیزهایی که به‌معنای واقعی کلمه جلوی سردردهای بعدی رو می‌گیرن.

برای من، پیام اصلی کتاب این بود که Platform Engineering یک تمرین صرفاً فنی نیست، بلکه یک محصوله؛ محصولی برای توسعه‌دهنده‌ها که اگر درست طراحی بشه، می‌تونه بهره‌وری کل سازمان رو متحول کنه.

کتاب Platform Engineering on Kubernetes

‍ کافکا 4.1 و قابلیت جدید Share Groups: نزدیک شدن Kafka به یک صف توزیع شده واقعی

یکی از چالش‌های قدیمی #Kafka این بود که وقتی می‌خواستید آن را مانند یک صف واقعی استفاده کنید و هر تعداد کانسیومر لازم برای پردازش سریع پیام‌ها داشته باشید، محدودیت پارتیشن‌ها مانع می‌شد.
یعنی اگر یک تاپیک ۴ پارتیشن داشت، فقط ۴ کانسیومر می‌توانستند همزمان پیام بخوانند و بقیه باید منتظر می‌ماندند. این محدودیت باعث می‌شد انعطاف لازم برای استفاده از Kafka به‌عنوان یک صف توزیع‌شده واقعی وجود نداشته باشد، در حالی که قدرت Kafka در مقیاس‌پذیری و توان عملیاتی بالا یکی از نقاط قوت اصلی‌اش است.

🎯 راهکار Kafka 4.1 با KIP-932

در نسخه ۴.۱ و با معرفی KIP-932، یک لایه مدیریتی جدید اضافه شد که پیام‌ها را از پارتیشن‌ها دریافت می‌کند و سپس آن‌ها را به کانسیومرهای اشتراکی تحویل می‌دهد. این لایه، مدیریت کامیت‌ها و تخصیص پیام‌ها را خودش انجام می‌دهد و به Kafka اجازه می‌دهد بدون تغییر معماری اصلی، رفتاری مشابه صف‌های توزیع‌شده واقعی ارائه دهد. قبلا مدیریت دریافت پیام‌ها با خود کانسیومرها بود و هر کانسیومر هنگام جوین شدن به یک گروه مصرف کننده و بعد از عملیات Rebalance، پارتیشن‌هایی که به او اختصاص داده شده بود را دریافت می‌کرد و مستقیما به لیدر آن پارتیشن‌ها پیام می فرستاد. الان پیام ها از این لایه جدید دریافت می‌شوند.

🟢نحوه کار Share Groups

🔰معرفی Share Group Coordinator در بروکرها

🔰مدیریت و پیگیری وضعیت پردازش پیام‌ها برای هر کانسیومر

🔰تخصیص پیام‌ها به کانسیومرها به‌صورت اشتراکی

🔰مدیریت acknowledgment پیام‌ها به‌صورت فردی


🟠ویژگی‌های اصلی Share Groups

🔰تعداد کانسیومرها بیشتر از پارتیشن‌ها → انعطاف بالا در پردازش موازی

🔰تایید acknowledgment فردی → پردازش دقیق‌تر و مدیریت خطاها

🔰پردازش موازی → افزایش کارایی و throughput سیستم


❓ وضعیت فعلی در Python

تا نسخه ۴.۱، کلاینت‌های Python مانند confluent-kafka و kafka-python از Share Groups پشتیبانی نمی‌کنند.

در حال حاضر فقط کلاینت Java از این ویژگی بهره‌مند است و انتظار می‌رود در آینده به سایر کلاینت‌ها اضافه شود.


🚀 سایر بهبودهای نسخه ۴.۱ برای توسعه‌دهندگان

✨ ارتقای مکانیزم Kafka Streams (KIP-1071) → پروتکل rebalance جدید برای کاهش زمان بازتخصیص و رفتار پیش‌بینی‌پذیرتر وظایف

✨ امنیت بهتر با JWT (KIP-1139) → پشتیبانی از jwt_bearer برای احراز هویت امن بدون credential ثابت

✨ بهبود متریک‌ها و مانیتورینگ (KIP-877 & KIP-1109) → استانداردسازی متریک‌ها، اضافه شدن تگ‌های مفید و اصلاح نام تاپیک‌ها

✨ امکان Shutdown نرم‌تر کانسیومرها (KIP-1092) → جلوگیری از ریبالانس غیرضروری هنگام توقف کانسیومرها

✨ رفع deadlock در send callbackها (KIP-1118) → بهبود ثبات تولیدکننده پیام

✨ مدیریت شفاف‌تر تراکنش‌ها (KIP-1050) → دسته‌بندی بهتر خطاها و مدیریت هوشمندتر تراکنش‌ها


💡 نسخه ۴.۱ Kafka با این تغییرات، تجربه کار با پردازش موازی، صف‌گونه و Event-Driven را بهبود داده و ابزارهای توسعه‌دهنده را برای مدیریت امنیت، متریک‌ها و rebalance ساده‌تر و قابل اعتمادتر کرده است.

✅ پی‌نوشت: دوره کافکا از مدرسه مهندسی داده سپهرام Sepahram Data Eng. School در حال برگزاری است و این مباحث را با جزییات بیشتر در آن بررسی می کنیم . https://sepahram.ir/courses/apachekafka-redpanda/

✅کانال تلگرام سپهرام : https://t.iss.one/sepahram_school

‍ ورکشاپ جدید مدرسه مهندسی داده سپهرام - آشنایی با ساختار فیزیکی پستگرس منتشر شد!

در ادامه‌ی کارگاه‌های عملی مدرسه مهندسی داده سپهرام، این‌بار به سراغ سازوکار ذخیره‌سازی فیزیکی داده‌ها در #PostgreSQL رفتیم.

در این جلسه با اجرای #PostgreSQL نسخه ۱۸ در محیط Docker، ساختار درونی ذخیره داده‌ها را از نزدیک بررسی کردیم.

خلاصه اینکه : ✨فایل‌های داده در پستگرس از واحدهایی به نام Page (یا Block) تشکیل می‌شوند؛ هر Page معمولاً ۸ کیلوبایت حجم دارد و کوچک‌ترین بخش قابل خواندن یا نوشتن در دیسک است.

✨ هر Page شامل اطلاعات مدیریتی، اشاره‌گرهای رکوردها، فضای خالی، و خود داده‌هاست. هنگام درج یا به‌روزرسانی رکورد، #PostgreSQL بر اساس فضای خالی موجود تصمیم می‌گیرد که داده را در همان Page یا Page جدید ذخیره کند. این رفتار در عمل، پایه‌ی مفهومی به نام Heap است - یعنی ذخیره‌سازی بدون ترتیب خاص.

✨در کارگاه دیدیم که با به‌روزرسانی رکوردها، نسخه‌های جدید در انتهای Page درج می‌شوند و نسخه‌های قبلی تا اجرای فرآیند VACUUM در فایل باقی می‌مانند. همچنین با تعیین fillfactor=70 برای جدول users2، مشاهده کردیم که چگونه فضای آزاد در Page باعث درج نسخه‌های جدید در همان Page می‌شود.


📘 آنچه در این کارگاه انجام دادیم:

🔰راه‌اندازی PostgreSQL 18 با Docker

🔰بررسی ساختار پوشه‌های base و global و مفهوم OID

🔰درج و به‌روزرسانی داده‌ها و تحلیل رفتار Pageها

🔰بررسی عملی Heap و نقش پارامتر fillfactor


📺 فیلم کامل ورکشاپ در یوتیوب مدرسه:

🔗 https://youtu.be/H3ET3i7XsXw

💾 فایل‌ها و اسکریپت‌ها در گیت‌هاب سپهرام:

👉 https://github.com/sepahram-school/workshops

دوره در حال برگزاری پستگرس : https://sepahram.ir/courses/postgresql

‍ برای لیک‌هوس کدام استاندارد را انتخاب کنیم؟

نگهداری داده‌ها در چند پایگاه داده جدا وقتی حجم داده‌ها بسیار زیاد شود و نیازهای هوش مصنوعی هم در میان باشد، به سرعت دردسرساز می‌شود. دیتابیس‌هایی مثل Oracle یا SQL Server وقتی داده‌ها زیاد شوند، به مرور کند می‌شوند و نیاز به راهکاری مدرن داریم.

به همین دلیل، لیک‌هوس (Data Lakehouse) محبوب شده است: یک بستر متمرکز برای ذخیره دادهٔ خام به صورت منظم که حاکمیت داده، دیتاکاتالوگ و گزارش‌دهی سریع را ممکن می‌کند و همزمان امکان یکپارچه‌سازی کل داده‌های سازمان و سرویس‌دهی به بخش‌های تحلیل داده و هوش مصنوعی را ممکن می‌کند.

سؤال اصلی: بین Delta / Iceberg / Hudi کدام‌یک را برای سازمان خود انتخاب کنیم؟ (فرض می‌کنیم با اصول لیک‌هوس آشنا هستید)


⚡️ معیارهای مقایسه

قبل از انتخاب، معیارهای زیر را باید بررسی کنیم :

🔰روش به‌روزرسانی داده‌ها: رکوردها چطور آپدیت می‌شوند؟

🔰سازگاری با ابزارها: Spark، Flink، Trino/Presto و سایر ابزارها چقدر پشتیبانی می‌شوند؟

🔰محبوبیت در صنعت: چقدر استفاده می‌شوند؟

🔰مقیاس‌پذیری و هزینه عملیاتی: آیا در حجم بالا پایدار و مقرون‌به‌صرفه هستند؟

🔰قابلیت بازگشت به گذشته و ایزوله‌سازی: می‌توان وضعیت داده‌ها را در گذشته بازسازی کرد یا snapshot گرفت؟

🔰انعطاف تغییر ساختار داده‌ها: تغییرات ساختار جداول چقدر آسان است؟


🔄 روش‌های به‌روزرسانی

✅روش CoW (Copy-on-Write): فایل را بازنویسی می‌کنیم. خواندن سریع، نوشتن سنگین

✅ روش MoR (Merge-on-Read): آپدیت‌ها جدا نوشته می‌شوند و هنگام خواندن با فایل اصلی ادغام می‌شوند. نوشتن سریع، خواندن کمی پیچیده‌تر

✅ روش MERGE INTO: اگر رکورد هست آپدیت کن، نیست درج کن


📊 مرور استانداردهای لیک‌هوس

✨ قالب Delta: بهترین گزینه برای تیم‌های Spark-محور؛ MERGE آسان، OPTIMIZE برای فایل‌های کوچک، time travel خوب

✨ استاندارد Iceberg: محبوب و رایج، سازگار با انواع انجین‌ها، عالی برای مصرف‌کنندگان متعدد و اسکن‌های طولانی؛ snapshot و branching قوی

✨ قالب Hudi: مناسب CDC و نوشتن لحظه‌ای با محوریت MoR؛ نوشتن سریع اما کمتر در معماری‌های نوین دیده می‌شود

🏗 معماری پیشنهادی ساده

🎯لایه Bronze - داده خام:

📌با Spark از Kafka بخوانید و در قالب Delta ذخیره کنید.

🎯لایه Silver - داده پردازش‌شده:

📌پردازش‌ها را با Spark انجام دهید و خروجی را دوباره در Delta ذخیره کنید.

📌این کار آپدیت‌ها و پردازش سریع را بهینه می‌کند.

🎯لایه Gold - داده تحلیلی و مصرف‌کننده نهایی:

📌داده‌های آماده را به صورت منظم مثلا هر یک ساعت به Iceberg منتقل کنید.

📌مزیت‌ها: اسکن سریع، پارتیشن‌بندی دینامیک، امکان بازگشت به گذشته (مثلاً داشبورد روز گذشته).

📌ابزارهای BI و تحلیل را به این لایه متصل کنید.


✅ چک‌لیست ساده قبل از پیاده‌سازی

🔑یک catalog با قرارداد مشخص بسازید (مثل دفترچه راهنما برای داده‌ها)

🔑از فرمت ستونی استاندارد (مثل Parquet یا ORC) استفاده کنید

🔑قواعد پارتیشن‌بندی و مرتب‌سازی داده‌ها را تعیین کنید

🔑برنامه زمان‌بندی برای ادغام فایل‌ها (Compaction/OPTIMIZE) داشته باشید

🔑یک راهنمای تغییر ساختار جداول و تست صحت داده‌ها آماده کنید

🔑ممکن است متوجه شوید که قالب نادرستی را انتخاب کرده‌اید. مسیر تبدیل بین فرمت‌ها و خروج از هر استاندارد را طراحی کنید

📝 جمع‌بندی

هر روش نیاز به آزمون و بررسی دارد، اما به نظر می‌رسد با ترکیب Delta + Iceberg می‌توان یک لیک‌هوس مقیاس‌پذیر و منعطف برای سازمان ساخت.

کدام چارچوب نرم افزاری را برای ایجاد یک سامانه مبتنی بر عامل‌های هوشمند انتخاب کنیم ؟
چارچوب‌های ایجاد برنامه‌های مبتنی بر عامل‌های هوشمند بسیار متنوع شده‌اند و تصمیم گیری در خصوص انتخاب آنها خود نیاز به بررسی فراوان و دانش مناسب دارد.
این مقاله وب‌سایت کلیک‌هوس که به بررسی دوازده فریمورک جدید حوزه عامل‌های هوشمند پرداخته است می تواند یک منبع جدید و قابل اعتماد در این حوزه باشد.
https://clickhouse.com/blog/how-to-build-ai-agents-mcp-12-frameworks

‍ ظهور Apache Flink Agents: نقطه عطفی در پردازش جریان و هوش مصنوعی لحظه‌ای

در دنیای پردازش جریان سازمانی، دو فرمانروا داریم: Apache Spark و Apache Flink. اما فلینک به دلیل امکان پردازش تک رویداد به صورت مقیاس‌پذیر، در محیط‌هایی که به ازای هر رخداد نیاز به پردازش جداگانه است، تبدیل به de-facto standard شده است.

✨ چند روز پیش خبر جذابی منتشر شد: معرفی Flink Agents، زیرپروژه‌ای جدید که با حمایت شرکت #Confluent عرضه شده و یک گام بزرگ در ترکیب پردازش جریان با پیشرفت‌های هوش مصنوعی به حساب می‌آید.
https://flink.apache.org/2025/10/15/apache-flink-agents-0.1.0-release-announcement

🎯 عامل‌های هوشمند فلینک امکان ساخت عامل‌های هوشمند مبتنی بر رویداد را مستقیماً روی runtime جریان Flink فراهم می‌کند. این پروژه ترکیبی است از قدرت Flink در پردازش جریان با مقیاس بزرگ، تاخیر میلی‌ثانیه‌ای، تحمل خطا و مدیریت state با قابلیت‌های عامل‌های هوشمند مانند LLMها، ابزارها، حافظه و ارکستراسیون پویا.

💡 چرا این خبر مهم است؟

سیستم‌های هوشمند فعلی اغلب منتظر دستور کاربر هستند، اما در صنایع فروشگاه‌های آنلاین، مالی، IoT و لجستیک، تصمیمات حیاتی باید همین لحظه و بر اساس رویدادهای زنده گرفته شوند:

⚡️ شکست تراکنش

⚡️اختلال در سنسورها

⚡️فعالیت لحظه‌ای کاربر

عامل‌های هوشمند Flink این امکان را می‌دهد که عامل‌ها همیشه فعال، واکنش‌گرا و مقیاس‌پذیر باشند و مانند میکروسرویس‌های رویدادمحور عمل کنند.


نحوه کار Flink Agents

🔰هر عامل به عنوان میکروسرویس رویدادمحور روی جریان‌های داده Flink اجرا می‌شود.

🔰دو منبع داده DataStream و Table APIs به عنوان ورودی و خروجی عامل‌ها عمل می‌کنند، بنابراین عامل‌ها مستقیماً با داده‌های ساختاریافته و هوش مصنوعی تعامل دارند.

🔰حافظه عامل‌ها در Flink state مدیریت می‌شود و قابلیت replay و آزمایش مجدد فراهم می‌شود.

🔰تعامل با LLMها، vector DBها و ابزارهای MCP برای تصمیم‌گیری و پردازش پیچیده امکان‌پذیر است.

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

قابلیت‌های کلیدی

✅ مقیاس بزرگ و تاخیر میلی‌ثانیه‌ای – پردازش جریان‌های حجیم در زمان واقعی

✅ تضمین صحت عملیات و اثرات جانبی - Exactly-Once Action Consistency

✅ یکپارچگی داده و AI – ترکیب پردازش داده و هوش مصنوعی بدون کد glue

✅ چندزبان – پشتیبانی Python و Java

✅ همیشه فعال و خودمختار – بدون انتظار برای درخواست کاربر

✨ جمع‌بندی
با Flink Agents، می‌توان عامل‌های هوشمند همیشه فعال و واکنش‌گرا را مستقیماً در جریان‌های داده‌ای پیاده‌سازی کرد. این پروژه می‌تواند نقطه عطفی در پردازش لحظه‌ای و تصمیم‌گیری خودکار در مقیاس بزرگ باشد.

پ.ن: عکس از مقاله زیر برداشته شده است :‌

https://www.kai-waehner.de/blog/2025/08/18/the-future-of-data-streaming-with-apache-flink-for-agentic-ai/

انواع دوره‌های تخصصی در حوزه مهندسی داده : https://t.iss.one/sepahram_school

‍ افزایش سرعت APIها: چگونه جایگزینی JSON با فرمت‌های باینری هزینه‌های پنهان را حذف می‌کند

📌 امروزه JSON در همه‌جا حضور دارد: از خروجی APIها و پیام‌های بین میکروسرویس‌ها تا فایل‌های لاگ و داده‌های بین سیستم‌ها.
با این حال، JSON برای مسیرهای حساس به تاخیر و حجم بالای داده همیشه بهینه نیست. Parsing متن و حجم payload باعث مصرف اضافی CPU و افزایش latency می‌شود و روی دستگاه‌های موبایل یا IoT، فشار حافظه و منابع را افزایش می‌دهد.

⚡️ خبر خوب این است که تنها با تغییر فرمت سریالایز داده‌ها هنگام ارسال در شبکه می‌توان به طور قابل توجهی هم سرعت انتقال داده‌ها و هم سرعت پردازش را افزایش داد. تجربه عملی نشان داده است که جایگزین‌های باینری می‌توانند سرعت APIها را تا ۵ برابر افزایش دهند و مصرف منابع را کاهش دهند.

🔹 گزینه‌های پیشنهادی:

🔰قالب Protobuf: مناسب RPCهای تایپ‌شده و میکروسرویس‌ها با اسکیمای ثابت. سرعت parse بالا و حجم payload کوچک از مزایای آن است. نیاز به تولید کد مصرف‌کننده (codegen) دارد و مدیریت نسخه‌بندی اسکیمای داده‌ها ضروری است.

🔰قالب FlatBuffers: سریع‌تر از Protobuf و توسط گوگل توسعه داده شده است. ایده‌آل برای مسیرهای خواندن پرتکرار (hot read paths) که هزینه ایجاد اشیاء اهمیت دارد. مانند Protobuf، نیاز به تولید کد مصرف‌کننده دارد و تغییر در ساختار داده نیازمند بازسازی schema است.

🔰کتابخانه MessagePack: ساختاری مشابه JSON دارد اما باینری و سریع‌تر است. نیازی به کامپایلر ندارد و تنها نصب کتابخانه کافی است. مناسب مسیرهایی که انعطاف JSON لازم است ولی می‌خواهید performance بالاتر داشته باشید.

🔰کتابخانه CBOR: مناسب دستگاه‌های IoT و موبایل با پهنای باند محدود و payloadهای کوچک. سبک، سریع و نیازی به تولید کد ندارد؛ تنها نصب کتابخانه کافی است.

💡 نکته عملی: یک endpoint حساس را انتخاب کنید، JSON را با یک فرمت باینری جایگزین کنید و عملکرد را اندازه‌گیری کنید. اغلب، تفاوت سرعت و مصرف منابع به وضوح قابل لمس خواهد بود.

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

📖 منبع: Forget JSON - These 4 Data Formats Made My APIs 5× Faster

دوره‌های تخصصی مهندسی داده: https://sepahram.ir/courses

آشنایی با الگوریتم Raft : بدون درد و خونریزی

امروز به وب‌سایتی برخوردم که با استفاده از اسلایدهای تعاملی، الگوریتم معروف Raft را به شکلی ساده و کاربردی توضیح داده است.

📎 https://thesecretlivesofdata.com/raft/

✨اگر با جزئیات این الگوریتم آشنا نیستید، پیشنهاد می‌کنم حتماً از این وب‌سایت استفاده کنید. در عرض چند دقیقه می‌توانید با اصول کلی Raft به صورت بصری، تعاملی و جذاب آشنا شوید و دیدی عملی نسبت به عملکرد آن پیدا کنید.

💡الگوریتم Raft امروزه به استانداردی رایج در حوزه سیستم‌های توزیع‌شده تبدیل شده و برای حل مسائل اجماع، انتخاب رهبر، و تکرار داده‌ها بین رهبر و پیروان (Leader/Follower) به کار می‌رود. این الگوریتم به‌قدری تأثیرگذار بوده که باعث شده Apache ZooKeeper از سیستم‌هایی مانند Kafka و ClickHouse حذف شود.

بیایید با هم این الگوریتم و موضوع اجماع را به صورت مفید و مختصر مرور کنیم:

🎯 الگوریتم اجماع (Raft) به زبان ساده

🔰هر نود در ابتدا در حالت Follower قرار دارد.

🔰اگر پس از یک مدت مشخص، هیچ پیامی از رهبر دریافت نکند، نود یک شمارنده انتخاب رهبر افزایش می‌دهد و خود را به عنوان Candidate معرفی می‌کند.

🔰 نود Candidate به سایر نودها پیام می‌فرستد و از آن‌ها می‌خواهد به او رأی دهند.

🔰هر نود فقط در صورتی رأی می‌دهد که قبلاً به همان شمارنده رأی نداده باشد.

🔰اگر Candidate اکثریت آراء را دریافت کند، تبدیل به Leader می‌شود و شروع به ارسال heartbeat و هماهنگ‌سازی داده‌ها با Followers می‌کند.

🔰اگر هیچ Candidate اکثریت آراء را به دست نیاورد، رأی‌گیری دوباره با یک timeout تصادفی شروع می‌شود تا احتمال رأی مساوی کاهش یابد.


📌چرا بعد از انتخاب رهبر، Log Replication مهم است؟

پس از انتخاب رهبر، یک چالش مهم پیش می‌آید: چگونه تضمین کنیم که همه نودها داده‌های یکسان و همگام داشته باشند؟

در سیستم‌های توزیع‌شده، ممکن است Followers داده‌های قدیمی یا ناقص داشته باشند. بدون یک مکانیزم هماهنگ‌سازی، اختلاف داده‌ها باعث ناسازگاری سیستم و خطاهای احتمالی می‌شود. Log Replication این مشکل را حل می‌کند: Leader تمام تغییرات را ابتدا در log خودش ثبت کرده و سپس به Followers ارسال می‌کند، تا همه سرورها در نهایت یک وضعیت یکسان و مطمئن داشته باشند.

🔄 تکرار داده‌ها Log Replication:

✅هر درخواست جدید از کلاینت ابتدا در Leader ثبت می‌شود و سپس به Followers کپی می‌شود.

✅داده‌ها زمانی committed محسوب می‌شوند که اکثر نودها آن را ذخیره کرده باشند.

✅ رهبر یا Leader پس از commit شدن داده، آن را نهایی کرده و پاسخ مناسب به کلاینت ارسال می‌کند.

✅اگر Leader سقوط کند، Followers با استفاده از آخرین log خود، مجدداً هماهنگ می‌شوند و رهبر جدید انتخاب می‌شود.


🚀 ایمنی و سازگاری داده‌ها

✨هیچ دو نودی نمی‌توانند برای یک شاخص log، داده متفاوتی داشته باشند.

✨Leader همواره آخرین داده‌های commit شده را در اختیار دارد.

✨سرورها تنها داده‌ها را append می‌کنند و عملیات overwrite یا delete انجام نمی‌دهند.

✨تغییر اعضای cluster با مکانیزم Joint Consensus انجام می‌شود تا سیستم در طول تغییر وضعیت همواره پاسخگو باقی بماند.


الگوریتم Raft نمونه‌ای عالی از یک الگوریتم اجماع ساده، عملی و قابل فهم است که بسیاری از شرکت‌ها مانند MongoDB و HashiCorp از آن در سیستم‌های توزیع‌شده خود استفاده می‌کنند.


🎬 : فیلم زیر از سایت رسمی الگوریتم Raft در گیت‌هاب تهیه شده است. 👇👇👇

https://raft.github.io

توضیح سریع و ساده الگوریتم اجماع Raft - در ادامه مطللب آموزشی بالا

‍ دو منبع عالی برای یادگیری سریع و عمیق Airflow 3 📚

چند ماه از انتشار رسمی Airflow 3 می‌گذرد و حالا وقت آن است که ببینیم دقیقاً چه چیزهایی تغییر کرده و چرا این نسخه نقطه عطف مهمی در مسیر این پلتفرم محبوب مدیریت جریان کاری داده (workflow orchestration) محسوب می‌شود.

در این نوشته می‌خواهیم دو منبع فوق‌العاده را معرفی کنیم که به‌جای خواندن ده‌ها صفحه مستندات یا تماشای ویدیوهای پراکنده، شما را مستقیم و مؤثر به قلب Airflow 3 می‌برند.
گاهی برای درک عمیق‌تر و تجربه‌ی واقعی، باید سراغ منابعی رفت که با نگاه حرفه‌ای نوشته شده‌اند - منابعی که نه‌تنها توضیح می‌دهند چطور کار می‌کند، بلکه کمک می‌کنند در عمل بهتر بسازید.

حالا که چند ماه از انتشار نسخه ۳ می‌گذرد، اگر هنوز با نسخه ۲ کار می‌کنید، باید بدانید از خیلی از قابلیت‌های جدید و بهینه‌سازی‌های Airflow 3 بی‌نصیب مانده‌اید.

دو منبع زیر بهترین نقطه‌ی شروع برای درک تفاوت‌ها و یادگیری عملی نسخه ۳ هستند 👇

1️⃣ جزوه مروری بر امکانات ایرفلو ۳ از Astronomer

یک مرور سریع و فشرده (حدود ۹ صفحه) از همه‌ی قابلیت‌های جدید Airflow 3 - ایده‌آل برای کسانی که می‌خواهند در چند دقیقه بفهمند دقیقاً چه تغییراتی در انتظارشان است. البته با این پیش‌فرض که با ایرفلو قبلا آشنا هستید.

2️⃣ کتاب Practical Guide to Apache Airflow 3 از Manning

اگر می‌خواهید با Airflow 3 به‌صورت واقعی و پروژه‌محور کار کنید، این کتاب انتخاب فوق‌العاده‌ای است.

از ساخت اولین pipeline تا معماری جدید، UI به‌روز، نسخه‌بندی DAGها و حتی اجرای inference با OpenAI - همه‌چیز در قالب مثال‌های عملی و توضیحات تصویری ارائه شده است آنهم در ۱۴۰ صفحه، مفید و مختصر

📘 فهرست فصل‌ها در یک نگاه:

✅آشنایی با Airflow 3

✅ساخت اولین pipeline

✅قابلیت اطمینان و زمان‌بندی

✅ واسط کاربری جدید و DAG Versioning

✅معماری داخلی نسخه ۳

✅حرکت به محیط Production

✅اجرای inference

✅مهاجرت از نسخه ۲

✅آینده Airflow


💡 اگر به دنبال یادگیری جدی نسخه ۳ و امکانات جذاب و کاربردی آن هستید:

✨ با جزوه Astronomer شروع کنید تا دید کلی بگیرید،

✨ و سپس با کتاب Manning جلو بروید تا Airflow 3 را به‌صورت عملی و حرفه‌ای تجربه کنید.

برای دانلود این دو pdf به دو پست قبلی، مراجعه کنید. 👆👆👆

کانال مدرسه مهندسی داده سپَهرام : آموزش‌های تخصصی مهندسی داده : @sepahram_school

#ApacheAirflow #DataEngineering #ETL #WorkflowAutomation #ManningBooks #Astronomer #OpenAI #Airflow3 #DataOps

🎥 ویدئوی جدید منتشر شد: رپلیکیشن در کافکا — درک عمیق از مکانیزم تکثیر داده‌ها

در این جلسه از دوره تخصصی آموزش کافکا، به یکی از بنیادی‌ترین و در عین حال کمتر درک‌شده‌ترین بخش‌های کافکا یعنی رپلیکیشن (Replication) پرداخته‌ایم.
📦 جایی که داده‌های هر پارتیشن در چندین بروکر تکرار می‌شوند تا سیستم در برابر خطا، قطعی و از دست رفتن داده مقاوم بماند.

در این ویدئو موارد زیر بررسی می‌شوند:

🔹 رپلیکیشن در سطح پارتیشن چگونه عمل می‌کند؟

🔹 تفاوت نقش رهبر (Leader) و پیرو (Follower) چیست؟

🔹 مفهوم ISR (In-Sync Replicas) دقیقاً چه نقشی در پایداری داده دارد؟

🔹شاخص High Watermark چگونه تعیین می‌شود و چرا در مصرف داده حیاتی است؟

🔹 ارتباط بین تنظیمات replication.factor، min.insync.replicas و acks چیست و چطور باید مقدار مناسب را انتخاب کنیم؟

🔹 در صورت خرابی بروکر یا تأخیر در همگام‌سازی، چه اتفاقی می‌افتد و چطور می‌توان از unclean leader election جلوگیری کرد؟

🎯 اگر می‌خواهید بدانید کافکا در پشت‌صحنه چگونه با چند بروکر داده‌ها را همگام نگه می‌دارد و چه مکانیزم‌هایی باعث حفظ پایداری سیستم می‌شود، این ویدئو را از دست ندهید.

📺 تماشای کامل ویدئو در یوتیوب:
👉 https://youtu.be/l30jp3iXooE

🔗 سایر دوره‌ها و آموزش‌های مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses

‍ آشنایی با مکانیزم همروندی در پستگرس و ضرورت اجرای منظم Vacuum

یکی از پرسش‌های کلیدی در طراحی پایگاه داده این است که:

🔍 وقتی چندین تراکنش به‌صورت همزمان قصد تغییر رکوردهای مشابه را دارند، سیستم چگونه تصمیم می‌گیرد کدام تغییر اعمال شود؟

پستگرس برای پاسخ به این چالش از مکانیزم MVCC (Multi-Version Concurrency Control) استفاده می‌کند - روشی که اجازه می‌دهد تراکنش‌ها بدون قفل‌های سنگین، همزمان روی داده‌ها کار کنند.


مکانیزم MVCC در پستگرس

در این مدل، هنگام تغییر یک رکورد، نسخه‌ی جدیدی از همان ردیف (tuple) در جدول درج می‌شود یعنی به ازای تراکنش‌های مختلفی که قصد تغییر یک رکورد را دارند، تعداد نسخه های زیادی از آن رکورد به صورت همزمان ایجاد می‌شود؛ اگر در همان صفحه (page) فضای کافی وجود داشته باشد، نسخه‌(ها)ی جدید در همان‌جا ذخیره می‌شود، وگرنه در صفحه‌ی دیگری قرار می‌گیرد.

برخلاف تصور رایج، کل صفحه کپی نمی‌شود - بلکه فقط ردیف(های) جدید افزوده می‌شود و نسخه‌ی قبلی به‌عنوان «مرده» (dead tuple) علامت‌گذاری می‌شود.
اگر تراکنش commit شود، نسخه‌ی جدید قابل مشاهده می‌شود؛ در غیر این صورت، ردیف‌های جدید هرگز برای سایر تراکنش‌ها دیده نمی‌شوند.

✨ مفهوم Page در پستگرس چیست؟

در PostgreSQL، داده‌ها مستقیماً به‌صورت خطی روی دیسک ذخیره نمی‌شوند، بلکه در قالب واحدهایی به نام Page (صفحه) سازمان‌دهی می‌شوند.

هر Page معمولاً حجمی برابر با ۸ کیلوبایت دارد و شامل چندین tuple (یا همان ردیف داده) است.

وقتی داده‌ای جدید درج می‌شود، PostgreSQL ابتدا بررسی می‌کند که آیا در یکی از صفحات موجود فضای کافی برای آن وجود دارد یا نه:

✅ اگر فضا کافی باشد، ردیف جدید در همان صفحه قرار می‌گیرد.

📦 اگر صفحه پر باشد، ردیف جدید در صفحه‌ای دیگر ذخیره می‌شود و ممکن است اندازهٔ فایل جدول افزایش پیدا کند.

در واقع، Page واحد پایهٔ ذخیره‌سازی و بازیابی داده‌ها در پستگرس است؛ همهٔ عملیات خواندن و نوشتن در نهایت در سطح صفحات انجام می‌شود.

🔹 نکته جالب اینجاست که ساختار داخلی جداول در پستگرس به‌صورت #Heap (پشته‌ای/درهم/بدون هیچ ترتیب‌ خاصی) پیاده‌سازی شده است؛
یعنی برخلاف ساختارهای مرتب‌شده مثل B-Tree، ردیف‌ها به‌ترتیب خاصی ذخیره نمی‌شوند : هر رکورد «هرجا که یک پیج، فضای خالی داشته باشد» درج می‌شود.

🎯 ضرورت فرآیند VACUUM

با گذر زمان، رکوردهای قدیمی (dead tuples) باید پاک‌سازی شوند تا فضای جدول بی‌دلیل افزایش نیابد. این وظیفه بر عهده‌ی فرآیند #VACUUM است.

فرآیند VACUUM فضای اشغال‌شده توسط تاپل‌های مرده (رکوردهایی که بازنویسی شده‌اند و نسخه قدیمی آن‌ها باید پاک شود) را برای استفاده‌ی مجدد در همان فایل آزاد می‌کند اما اگر بخواهیم این فضای آزاد شده از حذف رکوردهای مرده از سایز فایل کم شوند و به سیستم عامل برگردند، نیاز به VACUUM FULL داریم که می‌تواند آن فضا را واقعاً به سیستم‌عامل بازگرداند.

در کارگاه عملی این جلسه، با استفاده از PostgreSQL 18 در محیط Docker و ابزار DBeaver، گام‌به‌گام بررسی کردیم که:

🔰مکانیزم MVCC چگونه نسخه‌های مختلف رکوردها را مدیریت می‌کند،

🔰و VACUUM چگونه فضا را بازیابی و از wraparound جلوگیری می‌کند.


🎥 مشاهده ویدئوی کامل در یوتیوب:

👉 https://youtu.be/TtHSDJgFI6g

📌 نکته: در محیط‌های تولیدی، هرگز autovacuum را غیرفعال نکنید - این گزینه فقط برای اهداف آموزشی در این کارگاه موقتاً خاموش شده بود.

Sepahram Data Eng. School

دوره کاربردی پستگرس : https://sepahram.ir/courses/postgresql

‍ لیک‌هوس در مسیر بلوغ: نگاهی به نسخه جدید #RisingWave و ادغام عمیق آن با #Iceberg

در دنیای امروز که هر سازمان مجموعه‌ای از سرویس‌ها و جریان‌های داده‌ای متنوع دارد، نیاز به بستری متمرکز برای ذخیره و مدیریت «خودِ داده‌ها» بیش از همیشه احساس می‌شود: بستری مستقل از ابزارها و موتورهای پردازشی، جایی که داده‌ها به‌صورت خام و ساخت‌یافته نگهداری شوند.

این معماری نه‌تنها نظم داده‌ها را تضمین می‌کند، بلکه بستر ایده‌آلی برای توسعه سامانه‌های هوش مصنوعی و مدل‌های یادگیری ماشین فراهم می‌سازد؛ زیرا داده‌های تمیز و استاندارد، پایه‌ی هر سیستم هوشمند هستند.

📌 اینجا همان جایی است که مفهوم #Lakehouse اهمیت خود را نشان می‌دهد: ترکیبی از داده‌های ساخت‌یافته‌ی خام به همراه یک استاندارد سازمان‌دهی مانند #ApacheIceberg که باعث می‌شود داده‌ها در مقیاس وسیع قابل ذخیره‌سازی، مدیریت و تحلیل باشند.

🚀با این حال، فناوری‌هایی چون Iceberg هنوز در مدیریت متادیتا، snapshotها و عملیات نگهداری، چالش‌هایی دارند. در همین نقطه است که نسخه‌ی جدید #RisingWave v2.6 می‌تواند فرآیند به کارگیری و مدیریت لیک‌هوس را تسهیل کند ✨


⚡️ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper = ترکیب برنده!

✅ در این نسخه، RisingWave، به‌عنوان یک پایگاه داده جریانی سازگار با #PostgreSQL، به‌صورت بومی با Iceberg ادغام شده است. داده‌ها به‌صورت لحظه‌ای از #Kafka دریافت، در RisingWave پردازش، و سپس به شکل استاندارد در Lakehouse ذخیره می‌شوند.

✅این ارتباط از طریق #Lakekeeper برقرار می‌شود: یک #REST Catalog استاندارد که رابط رسمی میان RisingWave و Iceberg است.

✅ کتابخانه Lakekeeper علاوه بر مدیریت متادیتا و کنترل دسترسی‌ها (با پشتیبانی از #OpenFGA)، امکان راه‌اندازی و تنظیم #Lakehouse را به‌دلخواه شما فراهم می‌کند؛ مثلاً با استفاده از #MinIO یا هر فایل‌سیستم دیگر.

✅ سپس RisingWave با تنظیمات شما و در «لیک‌هوس شما» شروع به درج داده‌ها می‌کند.

✅ داده‌های غیرجریانی سازمان نیز می‌توانند با ابزارهایی مانند #ApacheSpark یا #PyIceberg به این بستر منتقل شوند تا یک Lakehouse کامل شکل گیرد: جایی که RisingWave بخش داده‌های جریانی را مدیریت می‌کند.

این ترکیب، از نظر فنی استاندارد و از نظر معماری، منعطف و آینده‌نگر است.

همچنین، عملیات نگهداشت و بهینه‌سازی داده‌ها مستقیماً در خود RisingWave انجام می‌شود، و بار سنگین مدیریت #Lakehouse از دوش تیم‌های داده برداشته می‌شود. 💪

🧠 ویژگی‌های کلیدی نسخه‌ی RisingWave ۲.۶

🔰 پشتیبانی از داده‌های برداری (Vector) برای جست‌وجوی شباهت

🔰حالت جدید Copy-on-Write برای snapshotهای تمیزتر در Iceberg

🔰دستور VACUUM FULL برای پاک‌سازی و فشرده‌سازی داده‌ها

🔰سازگاری کامل با #Lakekeeper REST Catalog

🔰تنوع sinkهای جدید برای #Snowflake، #Redshift، #Elasticsearch

🔰حالت Memory-Only برای پردازش‌های فوق‌سریع


🎥 به‌زودی ویدیویی منتشر می‌کنم که در آن ساخت یک #Lakehouse عملی با

#MinIO + #Lakekeeper + #Spark + #Trino + #StarRocks

را گام‌به‌گام بررسی می‌کنیم. 🚀

به باور من، مسیر آینده‌ی زیرساخت‌های داده به‌سمتی پیش می‌رود که #Lakehouse بستر اصلی ذخیره و تحلیل داده‌ها شود،

و ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper یکی از گزینه‌های خوب سازمانی برای شروع این مسیر است. 🌟

ما در داتین به‌دنبال همکاری متخصص و پرانگیزه هستیم تا در نقش کارشناس ارشد زیرساخت کلان داده تیم پایگاه داده را همراهی کند. کارشناس ارشد زیرساخت کلان داده در داتین با پذیرفتن مسئولیت‌های زیر به پیش‌برد اهداف تیم کمک می‌کند:
- نصب و راه اندازی دیتابیس های NoSQL ای مثل Cassandra, elastic
- نصب و راه اندازی دیتابیس PostgreSQL
- نصب و راه اندازی Kafka
- راه اندازی کلاسترینگ و HA
- مانیتورینگ دیتابیس ها
دانش و مهارت های مورد نیاز:
- آشنا با مفاهیم NoSQL , SQL
- آشنا با مفاهیم دیتابیس های NoSQL ای نظیر elastic, Arangodb , Cassandra
- آشنا با مفاهیم دیتابیس PostgreSQL
- آشنا با مفاهیم Partitioning و Sharding
- آشنا با مفاهیم HA . کلاسترینگ و Replica Set
- آشنا با سیستم عامل Linux , windows Server
نکات حائز اهمیت:
محیط کاری پویا و یادگیری بالا
کار تیمی