🔵 عنوان مقاله
Network Storage and Scaling Characteristics of a Distributed Filesystem (18 minute read)
🟢 خلاصه مقاله:
به‌کمک ریز‌بنچمارک‌ها، مقاله کارایی 3FS از DeepSeek را با جداسازی سهم شبکه و ذخیره‌سازی بررسی می‌کند؛ هم روی کلاسترهای مدرن و هم قدیمی. نتایج نشان می‌دهد 3FS حدود ۱ تا ۱.۲ میلی‌ثانیه سربار اضافه می‌کند، پیش از آن‌که ذخیره‌سازی به سقف برسد، عامل محدودکننده شبکه است، و سیستم با افزایش تعداد نودها و اندازه بلوک‌ها به‌خوبی مقیاس‌پذیر است. کارایی آن هم روی سخت‌افزار رده‌مصرفی و هم رده‌بالا مناسب است؛ بنابراین برای ناوگان‌های ناهمگون نیز گزینه‌ای قابل اتکاست و بیشترین بهبود معمولاً از بهینه‌سازی شبکه حاصل می‌شود.
#DistributedSystems #Filesystem #Benchmarking #NetworkIO #Storage #Scalability #HPC #DeepSeek
🟣لینک مقاله:
https://maknee.github.io/blog/2025/3FS-Performance-Journal-3/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Network Storage and Scaling Characteristics of a Distributed Filesystem (18 minute read)
🟢 خلاصه مقاله:
به‌کمک ریز‌بنچمارک‌ها، مقاله کارایی 3FS از DeepSeek را با جداسازی سهم شبکه و ذخیره‌سازی بررسی می‌کند؛ هم روی کلاسترهای مدرن و هم قدیمی. نتایج نشان می‌دهد 3FS حدود ۱ تا ۱.۲ میلی‌ثانیه سربار اضافه می‌کند، پیش از آن‌که ذخیره‌سازی به سقف برسد، عامل محدودکننده شبکه است، و سیستم با افزایش تعداد نودها و اندازه بلوک‌ها به‌خوبی مقیاس‌پذیر است. کارایی آن هم روی سخت‌افزار رده‌مصرفی و هم رده‌بالا مناسب است؛ بنابراین برای ناوگان‌های ناهمگون نیز گزینه‌ای قابل اتکاست و بیشترین بهبود معمولاً از بهینه‌سازی شبکه حاصل می‌شود.
#DistributedSystems #Filesystem #Benchmarking #NetworkIO #Storage #Scalability #HPC #DeepSeek
🟣لینک مقاله:
https://maknee.github.io/blog/2025/3FS-Performance-Journal-3/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
maknee.github.io
Network Storage and Scaling Characteristics of a Distributed Filesystem | Some blog
Personal website for some random tidbits I work on
❤2
🔵 عنوان مقاله
Sharding Our Core Postgres Database (Without Any Downtime)
🟢 خلاصه مقاله:
Gadget که یک پلتفرم توسعه JavaScript است، ابتدا تمام داده‌ها را در یک نمونه بزرگ Postgres نگه می‌داشت و با رشد کاربران به سقف مقیاس‌پذیری عمودی برخورد کرد. برای عبور از این محدودیت، معماری را به شاردینگ تغییر داد: انتخاب کلید شارد همسو با الگوی دسترسی (ترجیحاً در سطح tenant/project برای تک‌شارد بودن بیشتر کوئری‌ها)، افزودن لایه مسیریابی برای ارسال شفاف درخواست‌ها به شارد درست، و اجرای مهاجرت بدون توقف سرویس. روند انتقال مرحله‌ای بود: بک‌فیل داده‌های تاریخی، فعال‌سازی dual-read/dual-write برای همگام‌سازی، افزودن idempotency و منطق retry، و سوییچ تدریجی ترافیک با رصد مداوم تاخیر، خطا و lag. نتیجه، توزیع بار بین چند نمونه Postgres، حذف نقاط داغ، و کاهش ریسک عملیاتی بود—همه بدون downtime یا درخواست‌های از دست‌رفته. درس‌های کلیدی: انتخاب دقیق کلید شارد، لایه مسیریابی پایدار، بک‌فیل ایمن، گذار تدریجی و رصدپذیری کامل.
#Postgres #Sharding #DatabaseScaling #ZeroDowntime #DistributedSystems #DevOps #SRE
🟣لینک مقاله:
https://postgresweekly.com/link/174455/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Sharding Our Core Postgres Database (Without Any Downtime)
🟢 خلاصه مقاله:
Gadget که یک پلتفرم توسعه JavaScript است، ابتدا تمام داده‌ها را در یک نمونه بزرگ Postgres نگه می‌داشت و با رشد کاربران به سقف مقیاس‌پذیری عمودی برخورد کرد. برای عبور از این محدودیت، معماری را به شاردینگ تغییر داد: انتخاب کلید شارد همسو با الگوی دسترسی (ترجیحاً در سطح tenant/project برای تک‌شارد بودن بیشتر کوئری‌ها)، افزودن لایه مسیریابی برای ارسال شفاف درخواست‌ها به شارد درست، و اجرای مهاجرت بدون توقف سرویس. روند انتقال مرحله‌ای بود: بک‌فیل داده‌های تاریخی، فعال‌سازی dual-read/dual-write برای همگام‌سازی، افزودن idempotency و منطق retry، و سوییچ تدریجی ترافیک با رصد مداوم تاخیر، خطا و lag. نتیجه، توزیع بار بین چند نمونه Postgres، حذف نقاط داغ، و کاهش ریسک عملیاتی بود—همه بدون downtime یا درخواست‌های از دست‌رفته. درس‌های کلیدی: انتخاب دقیق کلید شارد، لایه مسیریابی پایدار، بک‌فیل ایمن، گذار تدریجی و رصدپذیری کامل.
#Postgres #Sharding #DatabaseScaling #ZeroDowntime #DistributedSystems #DevOps #SRE
🟣لینک مقاله:
https://postgresweekly.com/link/174455/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Gadget
Sharding our core Postgres database (without any downtime)
A deep dive into horizontal scaling: how we sharded our core db without any downtime or dropped requests.
🔵 عنوان مقاله
How Kafka Works (20 minute read)
🟢 خلاصه مقاله:
Apache Kafka یک پلتفرم متن‌باز پیام‌رسانی و رویدادمحور است که رکوردهای key-value را در logهای افزایشی و تغییرناپذیر ذخیره می‌کند. داده‌ها در topicها سازمان‌دهی و بین partitionها توزیع می‌شوند تا مقیاس‌پذیری افقی و پردازش موازی فراهم شود. ترتیب پیام‌ها در هر partition حفظ می‌شود، و مصرف‌کننده‌ها با تکیه بر offset می‌توانند بازپخش دقیق داده و بازیابی وضعیت انجام دهند؛ علاوه‌بر نگهداشت (retention)، log compaction آخرین رکورد هر key را نگه می‌دارد. کلاستر Kafka معمولاً حداقل سه broker دارد؛ هر partition یک leader و چند follower دارد و با ضریب تکرار پیش‌فرض 3 همتابی می‌شود. نوشتن‌ها به leader انجام می‌شود و followerها همگام‌سازی می‌کنند؛ پایداری با تنظیماتی مانند acks=all و مجموعه ISR کنترل می‌شود. مدل pull در مصرف به مدیریت backpressure کمک می‌کند و consumer groupها امکان مقیاس‌پذیری و تحمل خطا را فراهم می‌سازند. Kafka به‌صورت پیش‌فرض تحویل at-least-once ارائه می‌دهد و با idempotent producer و تراکنش‌ها به exactly-once می‌رسد. در معماری مدرن، پروتکل KRaft جایگزین ZooKeeper شده و هماهنگی، انتخابات leader و بازیابی را در خود Kafka متمرکز می‌کند و عملیات را ساده و سریع‌تر می‌سازد.
#ApacheKafka #KRaft #ZooKeeper #DistributedSystems #EventStreaming #Scalability #FaultTolerance #Messaging
🟣لینک مقاله:
https://newsletter.systemdesign.one/p/how-kafka-works?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How Kafka Works (20 minute read)
🟢 خلاصه مقاله:
Apache Kafka یک پلتفرم متن‌باز پیام‌رسانی و رویدادمحور است که رکوردهای key-value را در logهای افزایشی و تغییرناپذیر ذخیره می‌کند. داده‌ها در topicها سازمان‌دهی و بین partitionها توزیع می‌شوند تا مقیاس‌پذیری افقی و پردازش موازی فراهم شود. ترتیب پیام‌ها در هر partition حفظ می‌شود، و مصرف‌کننده‌ها با تکیه بر offset می‌توانند بازپخش دقیق داده و بازیابی وضعیت انجام دهند؛ علاوه‌بر نگهداشت (retention)، log compaction آخرین رکورد هر key را نگه می‌دارد. کلاستر Kafka معمولاً حداقل سه broker دارد؛ هر partition یک leader و چند follower دارد و با ضریب تکرار پیش‌فرض 3 همتابی می‌شود. نوشتن‌ها به leader انجام می‌شود و followerها همگام‌سازی می‌کنند؛ پایداری با تنظیماتی مانند acks=all و مجموعه ISR کنترل می‌شود. مدل pull در مصرف به مدیریت backpressure کمک می‌کند و consumer groupها امکان مقیاس‌پذیری و تحمل خطا را فراهم می‌سازند. Kafka به‌صورت پیش‌فرض تحویل at-least-once ارائه می‌دهد و با idempotent producer و تراکنش‌ها به exactly-once می‌رسد. در معماری مدرن، پروتکل KRaft جایگزین ZooKeeper شده و هماهنگی، انتخابات leader و بازیابی را در خود Kafka متمرکز می‌کند و عملیات را ساده و سریع‌تر می‌سازد.
#ApacheKafka #KRaft #ZooKeeper #DistributedSystems #EventStreaming #Scalability #FaultTolerance #Messaging
🟣لینک مقاله:
https://newsletter.systemdesign.one/p/how-kafka-works?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
newsletter.systemdesign.one
How Kafka Works
#91: Learn Everything About Apache Kafka’s Architecture, Including Brokers, KRaft, Topic Partitions, Tiered Storage, Exactly Once, Kafka Connect, Kafka Schema Registry and Kafka Streams
🎉1
🔵 عنوان مقاله
Stateless Postgres Query Router (SPQR) 2.7
🟢 خلاصه مقاله:
** SPQR 2.7 یک Stateless Postgres Query Router است که رویکردی عملی برای افقی‌سازی از طریق sharding ارائه می‌دهد و ابتدا در Yandex Cloud شکل گرفته است. این مدل با قراردادن یک لایه مسیریاب بین برنامه‌ها و مجموعه‌ای از shardهای Postgres، مسیریابی پرس‌وجو را متمرکز و مقیاس‌پذیری افقی را ساده می‌کند؛ ماهیت stateless آن نیز استقرار پشت Load Balancer، افزونگی و ارتقای بدون دردسر را ممکن می‌سازد. انتخاب کلید sharding، بازتوزیع داده و مدیریت پرس‌وجوهای چند-shard از چالش‌های عملیاتی آن است، اما جداسازی مسئولیت‌ها بین لایه مسیریابی و لایه ذخیره‌سازی، مسیر روشنی برای رشد مقیاس فراهم می‌کند. نسخه 2.7 نشان‌دهنده بلوغ این الگو و تناسب آن با محیط‌های cloud-native است، بی‌آنکه نیاز به ترک اکوسیستم Postgres باشد.
#Postgres #SPQR #YandexCloud #Sharding #DatabaseScaling #DistributedSystems #StatelessArchitecture #PostgreSQL
🟣لینک مقاله:
https://postgresweekly.com/link/174476/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Stateless Postgres Query Router (SPQR) 2.7
🟢 خلاصه مقاله:
** SPQR 2.7 یک Stateless Postgres Query Router است که رویکردی عملی برای افقی‌سازی از طریق sharding ارائه می‌دهد و ابتدا در Yandex Cloud شکل گرفته است. این مدل با قراردادن یک لایه مسیریاب بین برنامه‌ها و مجموعه‌ای از shardهای Postgres، مسیریابی پرس‌وجو را متمرکز و مقیاس‌پذیری افقی را ساده می‌کند؛ ماهیت stateless آن نیز استقرار پشت Load Balancer، افزونگی و ارتقای بدون دردسر را ممکن می‌سازد. انتخاب کلید sharding، بازتوزیع داده و مدیریت پرس‌وجوهای چند-shard از چالش‌های عملیاتی آن است، اما جداسازی مسئولیت‌ها بین لایه مسیریابی و لایه ذخیره‌سازی، مسیر روشنی برای رشد مقیاس فراهم می‌کند. نسخه 2.7 نشان‌دهنده بلوغ این الگو و تناسب آن با محیط‌های cloud-native است، بی‌آنکه نیاز به ترک اکوسیستم Postgres باشد.
#Postgres #SPQR #YandexCloud #Sharding #DatabaseScaling #DistributedSystems #StatelessArchitecture #PostgreSQL
🟣لینک مقاله:
https://postgresweekly.com/link/174476/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - pg-sharding/spqr: Stateless Postgres Query Router.
Stateless Postgres Query Router. Contribute to pg-sharding/spqr development by creating an account on GitHub.
🔵 عنوان مقاله
Inside Husky's query engine: Real-time access to 100 trillion events (10 minute read)
🟢 خلاصه مقاله:
Husky از Datadog با جداسازی سه بخش Planner، Router و Executor، اجرای پرس‌وجوها را در مقیاس بسیار بزرگ و به‌صورت بی‌درنگ ممکن می‌کند. Planner پرس‌وجو را به گراف منطقی از stageها تبدیل می‌کند، آن را به segmentهای قابل اجرا تقسیم کرده و برنامهٔ اجرا تولید می‌کند. Router براساس قواعد و شرایط زمان اجرا، هر segment را به backend مناسب مسیردهی می‌کند تا هم‌زمانی بالا، توازن بار و انعطاف در انتخاب مسیر تضمین شود. Executor کارها را به موتورهای تخصصی مانند SQL engine و custom operators می‌فرستد و نتایج موازی را ترکیب می‌کند. این تفکیک ماژولار باعث مقیاس‌پذیری، امکان اتصال backendهای جدید و بهینه‌سازی پویا برای هر پرس‌وجو می‌شود و دسترسی بی‌درنگ به حجم عظیمی از رویدادها را فراهم می‌کند.
#Datadog #Husky #QueryEngine #RealTimeAnalytics #DistributedSystems #Scalability #DataInfrastructure
🟣لینک مقاله:
https://www.datadoghq.com/blog/engineering/husky-query-architecture/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Inside Husky's query engine: Real-time access to 100 trillion events (10 minute read)
🟢 خلاصه مقاله:
Husky از Datadog با جداسازی سه بخش Planner، Router و Executor، اجرای پرس‌وجوها را در مقیاس بسیار بزرگ و به‌صورت بی‌درنگ ممکن می‌کند. Planner پرس‌وجو را به گراف منطقی از stageها تبدیل می‌کند، آن را به segmentهای قابل اجرا تقسیم کرده و برنامهٔ اجرا تولید می‌کند. Router براساس قواعد و شرایط زمان اجرا، هر segment را به backend مناسب مسیردهی می‌کند تا هم‌زمانی بالا، توازن بار و انعطاف در انتخاب مسیر تضمین شود. Executor کارها را به موتورهای تخصصی مانند SQL engine و custom operators می‌فرستد و نتایج موازی را ترکیب می‌کند. این تفکیک ماژولار باعث مقیاس‌پذیری، امکان اتصال backendهای جدید و بهینه‌سازی پویا برای هر پرس‌وجو می‌شود و دسترسی بی‌درنگ به حجم عظیمی از رویدادها را فراهم می‌کند.
#Datadog #Husky #QueryEngine #RealTimeAnalytics #DistributedSystems #Scalability #DataInfrastructure
🟣لینک مقاله:
https://www.datadoghq.com/blog/engineering/husky-query-architecture/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Datadog
Inside Husky’s query engine: Real-time access to 100 trillion events | Datadog
See how Husky enables interactive querying across 100 trillion events daily by combining caching, smart indexing, and query pruning.
❤1
🔵 عنوان مقاله
Spock: Logical Multi-Master PostgreSQL Replication
🟢 خلاصه مقاله:
این مقاله Spock را معرفی می‌کند؛ لایه‌ای برای Logical Multi‑Master Replication روی PostgreSQL که اجازه می‌دهد چند نود هم‌زمان عملیات نوشتن را بپذیرند و داده‌ها را بین خود همگام نگه دارند. برخلاف Physical Replication که به یک لیدر متکی است، Spock با استفاده از logical decoding تغییرات سطری را دریافت و روی نودهای دیگر اعمال می‌کند و بدین ترتیب امکان active‑active و حتی انتشار بخشی از DDL را فراهم می‌سازد.
نویسنده چالش‌های اصلی Multi‑Master را توضیح می‌دهد: تشخیص و رفع تضادهای نوشتن، سیاست‌های قابل پیکربندی مثل last‑update‑wins یا روش‌های سفارشی، مدیریت شناسه‌های یکتا و sequenceها، و تغییر توپولوژی بدون توقف. از نظر عملیاتی نیز نظارت بر lag، ثبت و رصد تضادها، و طراحی الگوهای اپلیکیشنی مثل upsert و عملیات idempotent ضروری است؛ استفاده از UUID به جای sequenceهای متمرکز می‌تواند تعارض‌ها را کم کند. نتیجه‌گیری این است که Spock جایگزین ساده برای سازگاری قوی سراسری نیست، اما برای سناریوهای active‑active با پذیرش eventual consistency گزینه‌ای قوی است.
در مقایسه با گزینه‌های دیگر (Built‑in Logical Replication تک‑مستر، Physical Streaming، و راهکارهایی مانند BDR یا Bucardo)، Spock تمرکز را بر Multi‑Master منطقی می‌گذارد و در قبال پیچیدگی بیشتر، استقلال از یک primary واحد را می‌دهد. از آن‌جا که این مطلب در Golang Weekly آمده، نکات پیاده‌سازی برای سرویس‌های Go نیز مطرح می‌شود: اتصال از طریق database/sql یا pgx به نود محلی برای کاهش تاخیر، مدیریت retry و conflict، و استفاده از الگوهایی مثل transactional outbox و CDC برای ساخت سیستم‌های رویدادمحور قابل اتکا.
#PostgreSQL #Spock #LogicalReplication #MultiMaster #Golang #DistributedSystems #DatabaseReplication #HighAvailability
🟣لینک مقاله:
https://postgresweekly.com/link/177326/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Spock: Logical Multi-Master PostgreSQL Replication
🟢 خلاصه مقاله:
این مقاله Spock را معرفی می‌کند؛ لایه‌ای برای Logical Multi‑Master Replication روی PostgreSQL که اجازه می‌دهد چند نود هم‌زمان عملیات نوشتن را بپذیرند و داده‌ها را بین خود همگام نگه دارند. برخلاف Physical Replication که به یک لیدر متکی است، Spock با استفاده از logical decoding تغییرات سطری را دریافت و روی نودهای دیگر اعمال می‌کند و بدین ترتیب امکان active‑active و حتی انتشار بخشی از DDL را فراهم می‌سازد.
نویسنده چالش‌های اصلی Multi‑Master را توضیح می‌دهد: تشخیص و رفع تضادهای نوشتن، سیاست‌های قابل پیکربندی مثل last‑update‑wins یا روش‌های سفارشی، مدیریت شناسه‌های یکتا و sequenceها، و تغییر توپولوژی بدون توقف. از نظر عملیاتی نیز نظارت بر lag، ثبت و رصد تضادها، و طراحی الگوهای اپلیکیشنی مثل upsert و عملیات idempotent ضروری است؛ استفاده از UUID به جای sequenceهای متمرکز می‌تواند تعارض‌ها را کم کند. نتیجه‌گیری این است که Spock جایگزین ساده برای سازگاری قوی سراسری نیست، اما برای سناریوهای active‑active با پذیرش eventual consistency گزینه‌ای قوی است.
در مقایسه با گزینه‌های دیگر (Built‑in Logical Replication تک‑مستر، Physical Streaming، و راهکارهایی مانند BDR یا Bucardo)، Spock تمرکز را بر Multi‑Master منطقی می‌گذارد و در قبال پیچیدگی بیشتر، استقلال از یک primary واحد را می‌دهد. از آن‌جا که این مطلب در Golang Weekly آمده، نکات پیاده‌سازی برای سرویس‌های Go نیز مطرح می‌شود: اتصال از طریق database/sql یا pgx به نود محلی برای کاهش تاخیر، مدیریت retry و conflict، و استفاده از الگوهایی مثل transactional outbox و CDC برای ساخت سیستم‌های رویدادمحور قابل اتکا.
#PostgreSQL #Spock #LogicalReplication #MultiMaster #Golang #DistributedSystems #DatabaseReplication #HighAvailability
🟣لینک مقاله:
https://postgresweekly.com/link/177326/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - pgEdge/spock: Logical multi-master PostgreSQL replication
Logical multi-master PostgreSQL replication. Contribute to pgEdge/spock development by creating an account on GitHub.