🔵 عنوان مقاله
Billions of Edges Per Second with Postgres
🟢 خلاصه مقاله:
مقالهای که بررسی میکنیم به معرفی OneSparse میپردازد، که یک افزونه برای پایگاه داده Postgres است و از کتابخانه SuiteSparse’s GraphBLAS استفاده میکند تا جداول را به ماتریسهای پراکنده با کارایی بالا تبدیل کند و بدون نیاز به پایگاه داده گراف خارجی، این تبدیل را معکوس میکند. این افزونه نیاز به توضیحاتی دارد تا به درک کامل آن دست یابیم، و خوشبختانه، میشل در این زمینه به تفصیل به بررسی و شرح آن پرداخته است. استفاده از این افزونه میتواند به بهبود چشمگیر عملیات و ذخیرهسازی دادهها در پایگاههای داده تحت سیستم Postgres کمک کند، چراکه با استفاده از رویکرد ماتریسهای پراکنده، میتوان سرعت و کارایی را در مواجهه با دادههای بزرگ و پیچیده بهینهسازی کرد.
🟣لینک مقاله:
https://postgresweekly.com/link/171889/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Billions of Edges Per Second with Postgres
🟢 خلاصه مقاله:
مقالهای که بررسی میکنیم به معرفی OneSparse میپردازد، که یک افزونه برای پایگاه داده Postgres است و از کتابخانه SuiteSparse’s GraphBLAS استفاده میکند تا جداول را به ماتریسهای پراکنده با کارایی بالا تبدیل کند و بدون نیاز به پایگاه داده گراف خارجی، این تبدیل را معکوس میکند. این افزونه نیاز به توضیحاتی دارد تا به درک کامل آن دست یابیم، و خوشبختانه، میشل در این زمینه به تفصیل به بررسی و شرح آن پرداخته است. استفاده از این افزونه میتواند به بهبود چشمگیر عملیات و ذخیرهسازی دادهها در پایگاههای داده تحت سیستم Postgres کمک کند، چراکه با استفاده از رویکرد ماتریسهای پراکنده، میتوان سرعت و کارایی را در مواجهه با دادههای بزرگ و پیچیده بهینهسازی کرد.
🟣لینک مقاله:
https://postgresweekly.com/link/171889/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
اگه حافظه سرور به خاطر حجم بالای کش redis پر بشه چیکار باید کرد؟!
یه وقتایی هست که اپلیکیشنت زیر بار هست و به خاطر حجم زیاد کلیدهای کش٬ حافظه سرورت overload میشه مخصوصا وقتی برای کلیدهای کش ttl ست نکرده باشی و اونجاست که اپ داون میشه. توی این شرایط eviction policies هست که میاد وسط و میتونه سریع رم سرورت رو خالی کنه تا مشکل رفع بشه. اما این مفهوم redis eviction policies چی هست و چطور میشه کانفیگش کرد؟
توی مقاله زیر درباره انواع policy توضیح دادم که چی هست و چطور باید کانفیگ کنی تا اپلیکیشنت رو از کرش کردن در این مواقع بحرانی نجات بده
https://farshadth.medium.com/understanding-redis-eviction-policies-5b7e913ced2b
<Farshad Tofighi/>
➖➖➖➖➖➖➖➖
https://t.me/addlist/QtXiQlynEJwzODBk
یه وقتایی هست که اپلیکیشنت زیر بار هست و به خاطر حجم زیاد کلیدهای کش٬ حافظه سرورت overload میشه مخصوصا وقتی برای کلیدهای کش ttl ست نکرده باشی و اونجاست که اپ داون میشه. توی این شرایط eviction policies هست که میاد وسط و میتونه سریع رم سرورت رو خالی کنه تا مشکل رفع بشه. اما این مفهوم redis eviction policies چی هست و چطور میشه کانفیگش کرد؟
توی مقاله زیر درباره انواع policy توضیح دادم که چی هست و چطور باید کانفیگ کنی تا اپلیکیشنت رو از کرش کردن در این مواقع بحرانی نجات بده
https://farshadth.medium.com/understanding-redis-eviction-policies-5b7e913ced2b
<Farshad Tofighi/>
➖➖➖➖➖➖➖➖
https://t.me/addlist/QtXiQlynEJwzODBk
❤1🔥1
🔵 عنوان مقاله
Postgres 18 Beta 2 Released
🟢 خلاصه مقاله:
نسخه دوم بتا از Postgres 18 اخیراً در دسترس قرار گرفته است و انتظار میرود که نسخه نهایی آن در چند ماه آینده منتشر شود. برای اطلاع از جدیدترین اطلاعات، مراجعه به یادداشتهای پیشنویس انتشار همچنان بهترین روش است، اما این پست شامل برخی از تغییرات و اصلاحاتی است که از زمان نسخه بتا 1 صورت گرفتهاند. این اصلاحات و تغییرات نشاندهنده تلاشهای مستمر برای بهبود کیفیت و کارایی نرمافزار هستند، بهطوری که کاربران میتوانند انتظار داشته باشند نسخه نهایی تجربه کاربری بهتری را ارائه دهد. این فرآیند بررسی مداوم و بهروزرسانیهای مکرر، به دقت نیازمندیهای جدید کاربران و رفع نواقص قبلی میپردازد.
🟣لینک مقاله:
https://postgresweekly.com/link/172192/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres 18 Beta 2 Released
🟢 خلاصه مقاله:
نسخه دوم بتا از Postgres 18 اخیراً در دسترس قرار گرفته است و انتظار میرود که نسخه نهایی آن در چند ماه آینده منتشر شود. برای اطلاع از جدیدترین اطلاعات، مراجعه به یادداشتهای پیشنویس انتشار همچنان بهترین روش است، اما این پست شامل برخی از تغییرات و اصلاحاتی است که از زمان نسخه بتا 1 صورت گرفتهاند. این اصلاحات و تغییرات نشاندهنده تلاشهای مستمر برای بهبود کیفیت و کارایی نرمافزار هستند، بهطوری که کاربران میتوانند انتظار داشته باشند نسخه نهایی تجربه کاربری بهتری را ارائه دهد. این فرآیند بررسی مداوم و بهروزرسانیهای مکرر، به دقت نیازمندیهای جدید کاربران و رفع نواقص قبلی میپردازد.
🟣لینک مقاله:
https://postgresweekly.com/link/172192/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostgreSQL News
PostgreSQL 18 Beta 2 Released!
The PostgreSQL Global Development Group announces that the second beta release of PostgreSQL 18 is now [available for download](https://www.postgresql.org/download/). This …
Forwarded from AI Labdon
جزئیات تیم فوقهوش مصنوعی متا (فیسبوک) فاش شده !
تیمی که متا برای توسعه هوش مصنوعی فوقپیشرفته خود تشکیل داده، شامل ۴۴ نفر است که:
۵۰٪ از چین هستند،
۷۵٪ دارای مدرک دکتری (PhD) هستند و ۷۰٪ محققاند،
۴۰٪ از OpenAI، ۲۰٪ از DeepMind و ۱۵٪ از Scale جذب شدهاند،
۲۰٪ در سطح L8+ (سطح بالای شغلی) فعالیت میکنند،
۷۵٪ مهاجران نسل اول هستند.
هر یک از این افراد احتمالاً سالانه بین ۱۰ تا ۱۰۰ میلیون دلار حقوق دریافت میکنند!
هرچی top اینجاس
فقط سابقه هاشون رو نگاه کنید
یکشون 37 سال سابقه کار داره YoE
به احتمال زیاد از 14 سالگی کد میزنه
➖➖➖➖➖➖➖➖
https://t.me/addlist/QtXiQlynEJwzODBk
تیمی که متا برای توسعه هوش مصنوعی فوقپیشرفته خود تشکیل داده، شامل ۴۴ نفر است که:
۵۰٪ از چین هستند،
۷۵٪ دارای مدرک دکتری (PhD) هستند و ۷۰٪ محققاند،
۴۰٪ از OpenAI، ۲۰٪ از DeepMind و ۱۵٪ از Scale جذب شدهاند،
۲۰٪ در سطح L8+ (سطح بالای شغلی) فعالیت میکنند،
۷۵٪ مهاجران نسل اول هستند.
هر یک از این افراد احتمالاً سالانه بین ۱۰ تا ۱۰۰ میلیون دلار حقوق دریافت میکنند!
هرچی top اینجاس
فقط سابقه هاشون رو نگاه کنید
یکشون 37 سال سابقه کار داره YoE
به احتمال زیاد از 14 سالگی کد میزنه
➖➖➖➖➖➖➖➖
https://t.me/addlist/QtXiQlynEJwzODBk
🔵 عنوان مقاله
Lessons from Scaling Postgres Queues to 100K Events Per Second
🟢 خلاصه مقاله:
RudderStack انتخاب کرد به جای استفاده از سیستمهایی مانند Kafka، از Postgres به عنوان سیستم صفبندی اصلی خود استفاده کند. تیم RudderStack در این مقاله تجربیات و درسهایی را که در فرایند توسعه و بهینهسازی این سیستم به دست آوردهاند، به اشتراک گذاشتهاند. این تجربیات شامل توضیحاتی در مورد تنظیمات خاص پیکربندی Postgres است. تیم توانست با انجام تغییرات و تنظیمات دقیق بر روی Postgres، آن را به گونهای ارتقا دهد که بتواند نیازهای سیستم صفبندی را در مقیاس بزرگ تأمین کند. این رویکرد به آنها امکان داد تا سیستمی با کارایی بالا و سازگار با نیازهای ویژهی خود ایجاد کنند. این مقاله نه تنها به اشتراکگذاری تجربیات بلکه به تفصیل منافع استفاده از Postgres در موارد خاص تکنیکی را پوشش میدهد.
🟣لینک مقاله:
https://postgresweekly.com/link/172194/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Lessons from Scaling Postgres Queues to 100K Events Per Second
🟢 خلاصه مقاله:
RudderStack انتخاب کرد به جای استفاده از سیستمهایی مانند Kafka، از Postgres به عنوان سیستم صفبندی اصلی خود استفاده کند. تیم RudderStack در این مقاله تجربیات و درسهایی را که در فرایند توسعه و بهینهسازی این سیستم به دست آوردهاند، به اشتراک گذاشتهاند. این تجربیات شامل توضیحاتی در مورد تنظیمات خاص پیکربندی Postgres است. تیم توانست با انجام تغییرات و تنظیمات دقیق بر روی Postgres، آن را به گونهای ارتقا دهد که بتواند نیازهای سیستم صفبندی را در مقیاس بزرگ تأمین کند. این رویکرد به آنها امکان داد تا سیستمی با کارایی بالا و سازگار با نیازهای ویژهی خود ایجاد کنند. این مقاله نه تنها به اشتراکگذاری تجربیات بلکه به تفصیل منافع استفاده از Postgres در موارد خاص تکنیکی را پوشش میدهد.
🟣لینک مقاله:
https://postgresweekly.com/link/172194/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
RudderStack
Lessons from scaling PostgreSQL queues to 100K events
This post is a chronicle of the critical, hard-won lessons learned while maturing PostgreSQL into a highly performant and resilient queuing system.
🔵 عنوان مقاله
How Matrix Discovered and Recovered from a Postgres Corruption Issue
🟢 خلاصه مقاله:
ماتریکس یک سیستم ارتباطی غیر متمرکز محبوب است که برای کاربران تازهکار، یک 'سرور خانگی' ارائه میدهد. این سرور خانگی توسط یک نمونه بزرگ Postgres پشتیبانی میشود و اخیراً با مشکلات فساد شاخص (index corruption) مواجه شده است. در ادامه، داستان دقیقی از پشت پرده این مشکل ارائه شده است. این مسئله نشاندهنده چالشهایی است که گاهی اوقات در مدیریت دیتابیسهای بزرگ و پیچیده به وقوع میپیوندد و اهمیت مانیتورینگ دقیق و بهموقع سیستمها برای جلوگیری از بروز خرابیهای اساسی را برجسته میسازد.
🟣لینک مقاله:
https://postgresweekly.com/link/172202/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How Matrix Discovered and Recovered from a Postgres Corruption Issue
🟢 خلاصه مقاله:
ماتریکس یک سیستم ارتباطی غیر متمرکز محبوب است که برای کاربران تازهکار، یک 'سرور خانگی' ارائه میدهد. این سرور خانگی توسط یک نمونه بزرگ Postgres پشتیبانی میشود و اخیراً با مشکلات فساد شاخص (index corruption) مواجه شده است. در ادامه، داستان دقیقی از پشت پرده این مشکل ارائه شده است. این مسئله نشاندهنده چالشهایی است که گاهی اوقات در مدیریت دیتابیسهای بزرگ و پیچیده به وقوع میپیوندد و اهمیت مانیتورینگ دقیق و بهموقع سیستمها برای جلوگیری از بروز خرابیهای اساسی را برجسته میسازد.
🟣لینک مقاله:
https://postgresweekly.com/link/172202/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
matrix.org
How we discovered, and recovered from, Postgres corruption on the matrix.org homeserver
Matrix, the open protocol for secure decentralised communications
🔵 عنوان مقاله
How Darkhorse Emergency Tamed Complex PostgreSQL Schemas
🟢 خلاصه مقاله:
در مقالهای که مورد بررسی قرار گرفته، نویسنده به توضیح نحوه بهکارگیری مدیریت طرحبندی اظهاری توسط Atlas در شرکت Darkhorse Emergency میپردازد، جایی که پیشتر از اسکریپتهای SQL شکننده برای توسعه سیستم پستگرس سنگین به لحاظ منطق استفاده میشده است. با استفاده از رویکرد Atlas، Darkhorse موفق به اجرای سریعتر مهاجرتها و استقرارهای ایمنتر شده است، همچنین تعداد بیشتری از توسعهدهندگان قادر به مشارکت در پایگاه داده شدهاند. این تغییر به Darkhorse اجازه داده تا بتواند بدون خطر خرابی یا از دست دادن دادهها، ساختار پایگاه دادهاش را به شکل ایمنتری توسعه دهد. مدیریت طرحبندی اظهاری از طریق Atlas به این معنی است که تغییرات دادهای میتوانند به صورت برنامهریزیشده و مدیریتشده اعمال شوند، که در نتیجه خطرات مرتبط با دستیاری های پایگاه داده را کاهش میدهد.
🟣لینک مقاله:
https://postgresweekly.com/link/172191/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How Darkhorse Emergency Tamed Complex PostgreSQL Schemas
🟢 خلاصه مقاله:
در مقالهای که مورد بررسی قرار گرفته، نویسنده به توضیح نحوه بهکارگیری مدیریت طرحبندی اظهاری توسط Atlas در شرکت Darkhorse Emergency میپردازد، جایی که پیشتر از اسکریپتهای SQL شکننده برای توسعه سیستم پستگرس سنگین به لحاظ منطق استفاده میشده است. با استفاده از رویکرد Atlas، Darkhorse موفق به اجرای سریعتر مهاجرتها و استقرارهای ایمنتر شده است، همچنین تعداد بیشتری از توسعهدهندگان قادر به مشارکت در پایگاه داده شدهاند. این تغییر به Darkhorse اجازه داده تا بتواند بدون خطر خرابی یا از دست دادن دادهها، ساختار پایگاه دادهاش را به شکل ایمنتری توسعه دهد. مدیریت طرحبندی اظهاری از طریق Atlas به این معنی است که تغییرات دادهای میتوانند به صورت برنامهریزیشده و مدیریتشده اعمال شوند، که در نتیجه خطرات مرتبط با دستیاری های پایگاه داده را کاهش میدهد.
🟣لینک مقاله:
https://postgresweekly.com/link/172191/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
atlasgo.io
Case Study: How Darkhorse Emergency Tamed Complex PostgreSQL Schemas with Atlas | Atlas | Manage your database schema as code
Learn how Darkhorse Emergency transformed their complex PostgreSQL schema management with Atlas, enabling faster, safer migrations and broader team collaboration.
Forwarded from Bardia & Erfan
بازجویی دوباره از مدیرعامل تلگرام در فرانسه
▪️پاول دورف، مدیرعامل تلگرام، روز گذشته برای سومین بار در دادگاهی در پاریس حاضر شد تا به اتهاماتی مرتبط با تسهیل جرایم سازمانیافته در بستر این پیامرسان پاسخ دهد. او به همراه چهار وکیلش در جلسهای رسمی شرکت کرد.
▪️این پرونده مربوط به بازداشت دورف در سال ۲۰۲۴ در فرانسه است؛ موضوع اصلی، نقش احتمالی تلگرام در انتشار محتوای غیرقانونی و ضعف در نظارت بر آنهاست.
▪️تیم حقوقی او با انتشار بیانیهای تأکید کردهاند:
▪️پاول دورف، مدیرعامل تلگرام، روز گذشته برای سومین بار در دادگاهی در پاریس حاضر شد تا به اتهاماتی مرتبط با تسهیل جرایم سازمانیافته در بستر این پیامرسان پاسخ دهد. او به همراه چهار وکیلش در جلسهای رسمی شرکت کرد.
▪️این پرونده مربوط به بازداشت دورف در سال ۲۰۲۴ در فرانسه است؛ موضوع اصلی، نقش احتمالی تلگرام در انتشار محتوای غیرقانونی و ضعف در نظارت بر آنهاست.
▪️تیم حقوقی او با انتشار بیانیهای تأکید کردهاند:
«ما هم مشروعیت کیفرخواست صادرشده علیه موکلمان و هم روند بعضی از اقدامات تحقیقاتی را، که در تضاد با قوانین داخلی و مقررات اتحادیه اروپا بودهاند، بهطور جدی زیر سوال میبریم.»
مقاله خیلی جذابیه. نکات بسیار ارزشمندی رو میگه. نکات مهمی رو در مورد استفاده از PostgreSQL میگه وقتی که شما همزمان Write-Heavy و Read-Heavy هستی.
مقاله ایده های جالب و متفاوتی رو ارائه میکنه:
داشتن جداولی با حداکثر ۱۰۰ هزار رکورد برای داشتن index scanهای سریع و جلوگیری از کاهش عملکرد PostgreSQL
استفاده از index-only scans و مکانیزمی شبیه loose index scan برای کم کردن io operations
داشتن استراتژی compaction و VACUUM Analyze برای جلوگیری از عملکرد read queries با بزرگ شدن جدول دیتابیس
استفاده از دستور COPY به جای Insert برای batch insertهای زیاد و سنگین
استفاده از golang string type به جای byte slice برای transfer داده که عملکرد تقریبا ۲ برابر بهتری داشته!
Lessons from scaling PostgreSQL queues to 100k events per second
https://www.rudderstack.com/blog/scaling-postgres-queue/
<Hossein Nazari/>
مقاله ایده های جالب و متفاوتی رو ارائه میکنه:
داشتن جداولی با حداکثر ۱۰۰ هزار رکورد برای داشتن index scanهای سریع و جلوگیری از کاهش عملکرد PostgreSQL
استفاده از index-only scans و مکانیزمی شبیه loose index scan برای کم کردن io operations
داشتن استراتژی compaction و VACUUM Analyze برای جلوگیری از عملکرد read queries با بزرگ شدن جدول دیتابیس
استفاده از دستور COPY به جای Insert برای batch insertهای زیاد و سنگین
استفاده از golang string type به جای byte slice برای transfer داده که عملکرد تقریبا ۲ برابر بهتری داشته!
Lessons from scaling PostgreSQL queues to 100k events per second
https://www.rudderstack.com/blog/scaling-postgres-queue/
<Hossein Nazari/>
RudderStack
Lessons from scaling PostgreSQL queues to 100K events
This post is a chronicle of the critical, hard-won lessons learned while maturing PostgreSQL into a highly performant and resilient queuing system.
Forwarded from Bardia & Erfan
نسخه 11.14 تلگرام منتشر شد
جستجوی پستها
حالا میتونی پستای کانالهای عمومی رو مستقیم سرچ کنی (فعلاً فقط برای پریمیومیها)
آلبوم استوری
استوریهاتو میتونی تو آلبوم بچینی، مثل خاطره سفر یا معرفی محصول تو کانالها
مجموعه هدیهها
هدایاتو دستهبندی کن! مثلا نایابها، موضوعیها و هرچی دلت خواست
امتیاز پروفایل
با خرید هدیه و پیام پولی، امتیاز میگیری و اعتبارت تو تلگرام بالا میره
هدایای خاص برای پریمیومیها
هدایای خفن و محدود فقط برای کاربرای پریمیوم میاد
مینیاپ جدید BotFather
رباتسازی راحتتر از همیشه شده؛ مستقیم از مینیاپ جدید مدیریت کن
جستجوی پستها
حالا میتونی پستای کانالهای عمومی رو مستقیم سرچ کنی (فعلاً فقط برای پریمیومیها)
آلبوم استوری
استوریهاتو میتونی تو آلبوم بچینی، مثل خاطره سفر یا معرفی محصول تو کانالها
مجموعه هدیهها
هدایاتو دستهبندی کن! مثلا نایابها، موضوعیها و هرچی دلت خواست
امتیاز پروفایل
با خرید هدیه و پیام پولی، امتیاز میگیری و اعتبارت تو تلگرام بالا میره
هدایای خاص برای پریمیومیها
هدایای خفن و محدود فقط برای کاربرای پریمیوم میاد
مینیاپ جدید BotFather
رباتسازی راحتتر از همیشه شده؛ مستقیم از مینیاپ جدید مدیریت کن
Forwarded from Software Engineer Labdon
🐧 ویرایشگر کد Zed :
امکان غیرفعالسازی هوش مصنوعی
🔹اZed چیست؟
اZed یک ویرایشگر کد مدرن و متنباز است که ویژگیهای منحصربهفردی ارائه میدهد:
✅ سبک و سریع (حتی روی سیستمهای ضعیف)
✅ پشتیبانی از چندین زبان برنامهنویسی
✅ امکانات پیشرفته مانند دیباگر داخلی و Git Integration
🔹 ویژگی جدید:
غیرفعالسازی هوش مصنوعی در آخرین آپدیت + امکان خاموش کردن کامل قابلیتهای هوش مصنوعی اضافه شده است.
🔸 مزایای این قابلیت:
- حفظ حریم خصوصی
(عدم ارسال کدها به سرورهای خارجی)
- کاهش مصرف منابع سیستم
- تمرکز بیشتر روی کدنویسی بدون مزاحمت پیشنهادات AI
- امکان استفاده از مدلهای محلی به جای سرویس ابری
🔹 نحوه غیرفعالسازی:
- باز کردن تنظیمات (Ctrl+, یا Cmd+,)
- جستجوی "AI"
- غیرفعال کردن گزینههای مربوطه
🔹 مقایسه با سایر ویرایشگرها:
- سرعت: Zed > VS Code > JetBrains
- هوش مصنوعی: Zed (انعطافپذیر) - VS Code (وابسته به افزونه) - JetBrains (پولی)
- متنباز بودن: Zed و VS Code متنباز هستند
🔹 دانلود:
🌐 وبسایت رسمی: zed.dev
📥 برای ویندوز، مک و لینوکس در دسترس است.
👤 نویسنده: امیرحسین قاسمزاده
📚 منبع: zed.dev
➖➖➖➖➖➖➖➖
https://t.me/addlist/QtXiQlynEJwzODBk
امکان غیرفعالسازی هوش مصنوعی
🔹اZed چیست؟
اZed یک ویرایشگر کد مدرن و متنباز است که ویژگیهای منحصربهفردی ارائه میدهد:
✅ سبک و سریع (حتی روی سیستمهای ضعیف)
✅ پشتیبانی از چندین زبان برنامهنویسی
✅ امکانات پیشرفته مانند دیباگر داخلی و Git Integration
🔹 ویژگی جدید:
غیرفعالسازی هوش مصنوعی در آخرین آپدیت + امکان خاموش کردن کامل قابلیتهای هوش مصنوعی اضافه شده است.
🔸 مزایای این قابلیت:
- حفظ حریم خصوصی
(عدم ارسال کدها به سرورهای خارجی)
- کاهش مصرف منابع سیستم
- تمرکز بیشتر روی کدنویسی بدون مزاحمت پیشنهادات AI
- امکان استفاده از مدلهای محلی به جای سرویس ابری
🔹 نحوه غیرفعالسازی:
- باز کردن تنظیمات (Ctrl+, یا Cmd+,)
- جستجوی "AI"
- غیرفعال کردن گزینههای مربوطه
🔹 مقایسه با سایر ویرایشگرها:
- سرعت: Zed > VS Code > JetBrains
- هوش مصنوعی: Zed (انعطافپذیر) - VS Code (وابسته به افزونه) - JetBrains (پولی)
- متنباز بودن: Zed و VS Code متنباز هستند
🔹 دانلود:
🌐 وبسایت رسمی: zed.dev
📥 برای ویندوز، مک و لینوکس در دسترس است.
👤 نویسنده: امیرحسین قاسمزاده
📚 منبع: zed.dev
➖➖➖➖➖➖➖➖
https://t.me/addlist/QtXiQlynEJwzODBk
❤1
خلاصهای مفید و مختصر از مقاله «Scalability Challenge: How to Remove Duplicates in a Large Data Set (~100M)» از Pankaj Tanwar
🎯 ۱. مسئله واقعی
فرض کن دنبال ارسال push notification به کاربران موبایل هستیم و نباید چندبار به یک دستگاه واحد برای یک کمپین، پیام ارسال شود. تگ دستگاهها توسط push token مشخص میشود که بین ۳۲ بایت تا ۴ کیلوبایت حجم دارد و ممکن است یک شناسه بین چند پروفایل کاربر مشترک باشد (مثلاً در زمان نصب مجدد اپ). در نتیجه باید میان ~۱۰۰ میلیون توکن، موارد تکراری حذف شود. اگر بخواهیم همه را در حافظه نگه داریم، حدود ۲۵ گیگابایت رم نیاز است!
🔧 ۲. راهحل: استفاده از Bloom Filter
Pankaj پیشنهاد میدهد از Bloom Filter استفاده کنیم:
با استفاده از یک آرایهی بیت و تعدادی تابع hash، هر توکن به یک یا چند بیت نگاشت میشود.
برای بررسی تکراری بودن، فقط درستی بیتها را چک میکنیم؛ در صورت همه “on”، احتمال duplicate بالا است.
با این روش، حافظه لازم برای ۱۰۰ میلیون توکن و خطای احتمالی کمتر از ۰.۱٪ تا حداکثر خطا تنظیمشده، به حدود ۱۷۱ مگابایت کاهش مییابد (در مقایسه با ۲۵ GB قبلی)
✅ چرا این روش مفید است؟
حافظه بسیار پایین در مقابل دو نسخه نگهداری (25GB → 171MB)
زمان پاسخ سریع: فقط چند عملیات hash و خواندن بیت
پیادهسازی ساده و مقیاسپذیر ، بهویژه برای جریان بلادرنگ (streaming)
🔍 نکات فنی اضافی
Bloom Filter احتمال false positive (تشخیص اشتباه تکراری) دارد، اما هیچ false negative ندارد؛ یعنی اگر فیلتر اعلام کند تکراری نیست، قطعاً نیست.
انتخاب اندازه بیتمپ (m) و تعداد hash functionها (k) باید بر اساس n (تعداد ورودی) و نرخ خطای مورد قبول تنظیم شود.
هشهای سریع و کارآمد مثل MurmurHash یا FNV بهتر از SHA یا MD5 هستند
🎯 ۱. مسئله واقعی
فرض کن دنبال ارسال push notification به کاربران موبایل هستیم و نباید چندبار به یک دستگاه واحد برای یک کمپین، پیام ارسال شود. تگ دستگاهها توسط push token مشخص میشود که بین ۳۲ بایت تا ۴ کیلوبایت حجم دارد و ممکن است یک شناسه بین چند پروفایل کاربر مشترک باشد (مثلاً در زمان نصب مجدد اپ). در نتیجه باید میان ~۱۰۰ میلیون توکن، موارد تکراری حذف شود. اگر بخواهیم همه را در حافظه نگه داریم، حدود ۲۵ گیگابایت رم نیاز است!
🔧 ۲. راهحل: استفاده از Bloom Filter
Pankaj پیشنهاد میدهد از Bloom Filter استفاده کنیم:
با استفاده از یک آرایهی بیت و تعدادی تابع hash، هر توکن به یک یا چند بیت نگاشت میشود.
برای بررسی تکراری بودن، فقط درستی بیتها را چک میکنیم؛ در صورت همه “on”، احتمال duplicate بالا است.
با این روش، حافظه لازم برای ۱۰۰ میلیون توکن و خطای احتمالی کمتر از ۰.۱٪ تا حداکثر خطا تنظیمشده، به حدود ۱۷۱ مگابایت کاهش مییابد (در مقایسه با ۲۵ GB قبلی)
✅ چرا این روش مفید است؟
حافظه بسیار پایین در مقابل دو نسخه نگهداری (25GB → 171MB)
زمان پاسخ سریع: فقط چند عملیات hash و خواندن بیت
پیادهسازی ساده و مقیاسپذیر ، بهویژه برای جریان بلادرنگ (streaming)
🔍 نکات فنی اضافی
Bloom Filter احتمال false positive (تشخیص اشتباه تکراری) دارد، اما هیچ false negative ندارد؛ یعنی اگر فیلتر اعلام کند تکراری نیست، قطعاً نیست.
انتخاب اندازه بیتمپ (m) و تعداد hash functionها (k) باید بر اساس n (تعداد ورودی) و نرخ خطای مورد قبول تنظیم شود.
هشهای سریع و کارآمد مثل MurmurHash یا FNV بهتر از SHA یا MD5 هستند
در ادامه یک خلاصهی کاربردی و دقیق از مقالهی Gunnar Morling با عنوان «Postgres Replication Slots: Confirmed Flush LSN vs. Restart LSN»:
---
موضوع مقاله
در PostgreSQL، replication slots نقش حیاتی در نگهداری و مدیریت WAL (Write-Ahead Log) دارند تا مصرفکنندگان (مانند replicas یا ابزارهای CDC مثل Debezium) بتوانند بعد از قطع ارتباط، با اطمینان ادامه دهند. برای این منظور، دو شاخص LSN مهم وجود دارد:
---
اهمیت درک تفاوت آنها
* اگر
* تعداد WALی که باید نگهداشته شوند برابر است با فاصلهی بین این دو LSN — این فاصلۀ WAL مصرفی در سیستم را تعیین میکند.
* اگر این فاصله بسیار بزرگ شود، ممکن است disk overflow (WAL bloat) رخ دهد و یا replication slot منسوخ شود.
---
نکته کلیدی از جامعه PostgreSQL
یکی از کاربران در StackOverflow توضیح داده:
ا>
---
جمعبندی مفید
ا* `confirmed_flush_lsn`: نشاندهنده پیشرفت واقعی مصرفکننده (چه را دریافت کردهایم).
ا* `restart_lsn`: نشاندهنده حداقل WALی که برای ادامه decoding نیاز داریم.
ا* فاصله بین این دو LSN نشانگر حجم WAL مورد نیاز است که باید حفظ شود تا سیستم replication به درستی کار کند.
ا* در تولید، مانیتور کردن این شاخصها و تنظیماتی مثل
---
موضوع مقاله
در PostgreSQL، replication slots نقش حیاتی در نگهداری و مدیریت WAL (Write-Ahead Log) دارند تا مصرفکنندگان (مانند replicas یا ابزارهای CDC مثل Debezium) بتوانند بعد از قطع ارتباط، با اطمینان ادامه دهند. برای این منظور، دو شاخص LSN مهم وجود دارد:
confirmed_flush_lsn
و restart_lsn
. دانستن تفاوت این دو برای عیبیابی replication و بهینهسازی نگهداری WAL ضروری است ---
اهمیت درک تفاوت آنها
* اگر
confirmed_flush_lsn
پیشرفت کرده اما restart_lsn
همچنان ایستا باشد، به این معنی است که هنوز WAL قدیمی برای complete decoding مورد نیاز است.* تعداد WALی که باید نگهداشته شوند برابر است با فاصلهی بین این دو LSN — این فاصلۀ WAL مصرفی در سیستم را تعیین میکند.
* اگر این فاصله بسیار بزرگ شود، ممکن است disk overflow (WAL bloat) رخ دهد و یا replication slot منسوخ شود.
---
نکته کلیدی از جامعه PostgreSQL
یکی از کاربران در StackOverflow توضیح داده:
ا>
restart_lsn
نمیتواند پیش رود تا تراکنشهای باز که از آن شروع شدهاند، کامل شوند؛ در حالی که confirmed_flush_lsn
با هر تراکنش commitشده پیش میرود. ([Database Administrators Stack Exchange][3])---
جمعبندی مفید
ا* `confirmed_flush_lsn`: نشاندهنده پیشرفت واقعی مصرفکننده (چه را دریافت کردهایم).
ا* `restart_lsn`: نشاندهنده حداقل WALی که برای ادامه decoding نیاز داریم.
ا* فاصله بین این دو LSN نشانگر حجم WAL مورد نیاز است که باید حفظ شود تا سیستم replication به درستی کار کند.
ا* در تولید، مانیتور کردن این شاخصها و تنظیماتی مثل
max_slot_wal_keep_size
به جلوگیری از بروز مشکلات ناشی از نگهداری بیش از حد WAL کمک میکند.❤1
درود! مقالهای تحت عنوان «Postgres HA Full-Sync» در سایت Multigres پیدا نکردم، اما در معرفی پروژه Multigres بخشهای مرتبط با High Availability (HA) و سینک کامل (full sync) بهوضوح وجود داشت. در ادامه خلاصهای کاربردی و جامع در اختیار داری:
---
## معرفی Multigres
Multigres یک پروژهایست بهمنظور ساخت نسخهای مشابه با Vitess برای PostgreSQL، اما کاملاً سازگار با اکوسیستم Postgres. این معماری با هدف افزایش مقیاسپذیری، HA و توزیع جهانی طراحی شده است و همچنان به عملکرد استاندارد PostgreSQL وفادار است.([Supabase][1], [multigres.com][2])
---
ویژگیهای برجسته مرتبط با HA و Full Sync
* High Availability (اHA):
* پشتیبانی از failover خودکار و ترفیع خودکار replica در صورت خرابی، بنابراین سیستم همیشه آنلاین باقی میماند
* اHorizontal Sharding:
* امکان تقسیم دیتابیس به بخشهای جداگانه روی سرورهای مختلف با مدیریت خودکار—این قابلیت به افزایش مقیاسپذیری کمک میکند.([multigres.com][2])
* اConnection Pooling و Query Routing:
* لایههای اتصال و هدایت پرسوجوها به سمت shardها یا replicaهای مناسب، بهینهسازی عملکرد و کارایی را در پی دارد.([multigres.com][2])
* اCloud-Native Architecture:
* طراحی شده برای اجرا در محیطهای Kubernetes با قابلیتهایی مانند backup خودکار و مدیریت کلاستر در مناطق جغرافیایی مختلف.([multigres.com][2])
---
در مورد "Full Sync"
در محتوای فراخوانشده اشاره مستقیمی به مفهوم full-sync replication نشده است. اما با توجه به اطلاعات اشاره شده، Multigres احتمالاً از تکنیکهایی مانند:
* اFailover خودکار و مراکز هماهنگ شده
* سینک دوباره دادهها بین replica و shards پس از قطعی
* رفتار مبتنی بر مدلهای مشابه دو فازی (Two-Phase Synchronization) مانند آنچه در پادکست پروژه ذکر شد([Postgres FM][3])
برای حفظ هماهنگی و جلوگیری از دادههای ناپایدار یا از دست رفته استفاده میکند.
---
## معرفی Multigres
Multigres یک پروژهایست بهمنظور ساخت نسخهای مشابه با Vitess برای PostgreSQL، اما کاملاً سازگار با اکوسیستم Postgres. این معماری با هدف افزایش مقیاسپذیری، HA و توزیع جهانی طراحی شده است و همچنان به عملکرد استاندارد PostgreSQL وفادار است.([Supabase][1], [multigres.com][2])
---
ویژگیهای برجسته مرتبط با HA و Full Sync
* High Availability (اHA):
* پشتیبانی از failover خودکار و ترفیع خودکار replica در صورت خرابی، بنابراین سیستم همیشه آنلاین باقی میماند
* اHorizontal Sharding:
* امکان تقسیم دیتابیس به بخشهای جداگانه روی سرورهای مختلف با مدیریت خودکار—این قابلیت به افزایش مقیاسپذیری کمک میکند.([multigres.com][2])
* اConnection Pooling و Query Routing:
* لایههای اتصال و هدایت پرسوجوها به سمت shardها یا replicaهای مناسب، بهینهسازی عملکرد و کارایی را در پی دارد.([multigres.com][2])
* اCloud-Native Architecture:
* طراحی شده برای اجرا در محیطهای Kubernetes با قابلیتهایی مانند backup خودکار و مدیریت کلاستر در مناطق جغرافیایی مختلف.([multigres.com][2])
---
در مورد "Full Sync"
در محتوای فراخوانشده اشاره مستقیمی به مفهوم full-sync replication نشده است. اما با توجه به اطلاعات اشاره شده، Multigres احتمالاً از تکنیکهایی مانند:
* اFailover خودکار و مراکز هماهنگ شده
* سینک دوباره دادهها بین replica و shards پس از قطعی
* رفتار مبتنی بر مدلهای مشابه دو فازی (Two-Phase Synchronization) مانند آنچه در پادکست پروژه ذکر شد([Postgres FM][3])
برای حفظ هماهنگی و جلوگیری از دادههای ناپایدار یا از دست رفته استفاده میکند.
❤2
Forwarded from Bardia & Erfan
🎯 آمادگی کامل IELTS با تدریس خصوصی و آنلاین
👑به دنبال نمره بالا در آیلتس هستی؟
🟢با استاد Mansourian، مدرس با تجربه مهارتهای
🩵Speaking
🩵Writing
🩵Reading
🩵Listening
رو به بهترین شکل تقویت کن.
📌 کلاسها به صورت آنلاین، خصوصی و روزانه برگزار میشه.
📈 پیشرفت سریع + برنامهریزی دقیق برای رسیدن به هدفت.
💬 همین الان فالو کن و مسیر موفقیتت رو شروع کن!
👇پیج استاد توی انستاگرام 👇
https://www.instagram.com/english_razi_ielts
👑به دنبال نمره بالا در آیلتس هستی؟
🟢با استاد Mansourian، مدرس با تجربه مهارتهای
🩵Speaking
🩵Writing
🩵Reading
🩵Listening
رو به بهترین شکل تقویت کن.
📌 کلاسها به صورت آنلاین، خصوصی و روزانه برگزار میشه.
📈 پیشرفت سریع + برنامهریزی دقیق برای رسیدن به هدفت.
💬 همین الان فالو کن و مسیر موفقیتت رو شروع کن!
👇پیج استاد توی انستاگرام 👇
https://www.instagram.com/english_razi_ielts
👌🏾Soheib Kiani
۲۰ تکنیک پیشرفته برنامهریزی منابع و مدیریت Performance در دیتابیسهای توزیعشده
Backend High Load
هر یک از این موارد، دانشی عمیق و عملی برای مهندس backend پیشرفته محسوب میشه:
Dynamic Partitioning
ایجاد پارتیشنهای پویا بر اساس زمان یا متریک خاص برای مدیریت حجم اطلاعات (مثلاً زمانبندی حذف خودکار دیتاهای منقضی)
Directory-based Sharding
استفاده از دیتابیس lookup برای نگاشت داده به shardهای مختلف، مناسب برای کنترل رشد داده به تفکیک ویژگی خاص
Range-based Sharding
تقسیم دادهها بر اساس بازه (مثلاً تاریخ یا ID)، به ویژه برای دیتاهای زمانمحور و تحلیلی
Hash-based Sharding
توزیع داده بر اساس هش یک کلید (key)، مناسب جهت پخش یکنواخت بار
Vertical Partitioning
تقسیم جداول بر اساس ستونهای پرمصرف یا کمتر مصرفشده و ذخیره هر بخش روی سرورهای مجزا برای افزایش بهرهوری
Replication (Master-Slave, Multi-Master)
تکثیر دادهها روی چندین node برای دسترسی بالا، redundancy و عملکرد بهتر خواندن؛ شامل Replication همزمان/غیرهمزمان
Change Data Capture (CDC) Replication
ایجاد همگامسازی بلادرنگ دادههای تغییر یافته، برای replication و ETLهای مقیاسپذیر
Data Consistency Models
انتخاب بین eventual consistency، strong consistency برای trade-off سرعت و دقت در سیستمهای توزیعشده
Multi-level Caching
بهرهگیری همزمان از cacheهای local (مثلاً memory app)، shared (مثلاً Redis/Memcached) و edge (CDN) برای حداکثر سرعت و کاهش بار دیتابیس
Cache Invalidation Strategies
استفاده از مکانیزمهایی مثل TTL، event-based، یا manual invalidation برای جلوگیری از stale data و اختلاف دیتا
Consistent Hashing for Distributed Cache
برای جلوگیری از hotspot و توزیع منصفانه کلیدها در cacheهای توزیعشده
Cache Replication
راهاندازی cache master-slave یا cluster برای افزایش دسترسی، توازن بار، و تحمل خرابی (Redis Sentinel, Cluster Mode)
Sharded Cache Architectures
تفکیک و توزیع کلیدهای cache روی چند سرور به شکلی که قابلیت گسترش و توازن بار داشته باشد
Cache Stampede Protection
پیادهسازی سیاستهایی مثل lock یا request coalescing برای جلوگیری از هجوم همزمان درخواستها هنگام miss شدن cache
Read/Write Splitting
هدایت درخواستهای خواندن به replicaها و نوشتن به master (در replication)، برای بهرهوری بیشتر از منابع
Vertical & Horizontal Scalability
استفاده درست از scale-up (افزایش منابع سرور) و scale-out (افزودن node جدید و sharding) وابسته به نیاز پروژه
Automated Partition Rebalancing
جابجایی یا تقسیم خودکار دادهها بین shardها با تغییر توزیع بار، کاهش hotspot و جلوگیری از ترافیک غیرمتعادل
Dynamic Resource Allocation
اختصاص خودکار منابع (مثل CPU, Memory) به shardها و cacheها مبتنی بر مانیتورینگ و نیاز لحظهای
Hybrid Partitioning Strategies
ترکیب partitioning افقی و عمودی برای استفاده بهینه و شخصیسازی تقسیم دیتا در سناریوهای خاص
Advanced Monitoring & Performance Tuning
رهگیری دقیق متریکهایی مثل hit ratio, latency, eviction rate و تنظیمات fine-tune (مثلاً policyهای eviction cache یا تنظیمات replication lag)
۲۰ تکنیک پیشرفته برنامهریزی منابع و مدیریت Performance در دیتابیسهای توزیعشده
Backend High Load
هر یک از این موارد، دانشی عمیق و عملی برای مهندس backend پیشرفته محسوب میشه:
Dynamic Partitioning
ایجاد پارتیشنهای پویا بر اساس زمان یا متریک خاص برای مدیریت حجم اطلاعات (مثلاً زمانبندی حذف خودکار دیتاهای منقضی)
Directory-based Sharding
استفاده از دیتابیس lookup برای نگاشت داده به shardهای مختلف، مناسب برای کنترل رشد داده به تفکیک ویژگی خاص
Range-based Sharding
تقسیم دادهها بر اساس بازه (مثلاً تاریخ یا ID)، به ویژه برای دیتاهای زمانمحور و تحلیلی
Hash-based Sharding
توزیع داده بر اساس هش یک کلید (key)، مناسب جهت پخش یکنواخت بار
Vertical Partitioning
تقسیم جداول بر اساس ستونهای پرمصرف یا کمتر مصرفشده و ذخیره هر بخش روی سرورهای مجزا برای افزایش بهرهوری
Replication (Master-Slave, Multi-Master)
تکثیر دادهها روی چندین node برای دسترسی بالا، redundancy و عملکرد بهتر خواندن؛ شامل Replication همزمان/غیرهمزمان
Change Data Capture (CDC) Replication
ایجاد همگامسازی بلادرنگ دادههای تغییر یافته، برای replication و ETLهای مقیاسپذیر
Data Consistency Models
انتخاب بین eventual consistency، strong consistency برای trade-off سرعت و دقت در سیستمهای توزیعشده
Multi-level Caching
بهرهگیری همزمان از cacheهای local (مثلاً memory app)، shared (مثلاً Redis/Memcached) و edge (CDN) برای حداکثر سرعت و کاهش بار دیتابیس
Cache Invalidation Strategies
استفاده از مکانیزمهایی مثل TTL، event-based، یا manual invalidation برای جلوگیری از stale data و اختلاف دیتا
Consistent Hashing for Distributed Cache
برای جلوگیری از hotspot و توزیع منصفانه کلیدها در cacheهای توزیعشده
Cache Replication
راهاندازی cache master-slave یا cluster برای افزایش دسترسی، توازن بار، و تحمل خرابی (Redis Sentinel, Cluster Mode)
Sharded Cache Architectures
تفکیک و توزیع کلیدهای cache روی چند سرور به شکلی که قابلیت گسترش و توازن بار داشته باشد
Cache Stampede Protection
پیادهسازی سیاستهایی مثل lock یا request coalescing برای جلوگیری از هجوم همزمان درخواستها هنگام miss شدن cache
Read/Write Splitting
هدایت درخواستهای خواندن به replicaها و نوشتن به master (در replication)، برای بهرهوری بیشتر از منابع
Vertical & Horizontal Scalability
استفاده درست از scale-up (افزایش منابع سرور) و scale-out (افزودن node جدید و sharding) وابسته به نیاز پروژه
Automated Partition Rebalancing
جابجایی یا تقسیم خودکار دادهها بین shardها با تغییر توزیع بار، کاهش hotspot و جلوگیری از ترافیک غیرمتعادل
Dynamic Resource Allocation
اختصاص خودکار منابع (مثل CPU, Memory) به shardها و cacheها مبتنی بر مانیتورینگ و نیاز لحظهای
Hybrid Partitioning Strategies
ترکیب partitioning افقی و عمودی برای استفاده بهینه و شخصیسازی تقسیم دیتا در سناریوهای خاص
Advanced Monitoring & Performance Tuning
رهگیری دقیق متریکهایی مثل hit ratio, latency, eviction rate و تنظیمات fine-tune (مثلاً policyهای eviction cache یا تنظیمات replication lag)
❤2
Forwarded from Bardia & Erfan
🤨 دارک مود؛ ناجی چشمها یا یه توهم مدرن...؟!
خیلیا فکر میکنن دارک مود برای چشم سالمتره، اما تحقیقات علمی چی میگن؟ بررسی مطالعات جدید نشون میده که دارک مود هم مزایا داره، هم معایب!
مزایای علمی دارک مود :
▪️کاهش نور آبی : نور آبی زیاد، ریتم خواب رو مختل میکنه، و دارک مود میتونه به خواب بهتر کمک کنه.
▪️کاهش مصرف باتری : روی نمایشگرهای OLED، رنگهای تیره مصرف انرژی کمتری دارن.
▪️کاهش خیرگی در محیطهای کمنور : وقتی نور اطراف کم باشه، دارک مود فشار کمتری به چشم وارد میکنه.
معایب علمی دارک مود :
▪️کاهش خوانایی متن در روز: چشم انسان به خوندن متن تیره روی پسزمینه روشن عادت داره، و دارک مود توی نور زیاد باعث خستگی چشم میشه.
▪️برخی تحقیقات نشون میدن که چشم توی حالت دارک مود بیشتر مجبور به تطبیق و تمرکز میشه، که میتونه خستگی ایجاد کنه.
▪️برخلاف تصور عموم، تغییر تم به تنهایی تأثیر زیادی روی کاهش خشکی و خستگی چشم نداره، بلکه میزان پلک زدن و استراحت دادن به چشم مهمتره.
خیلیا فکر میکنن دارک مود برای چشم سالمتره، اما تحقیقات علمی چی میگن؟ بررسی مطالعات جدید نشون میده که دارک مود هم مزایا داره، هم معایب!
مزایای علمی دارک مود :
▪️کاهش نور آبی : نور آبی زیاد، ریتم خواب رو مختل میکنه، و دارک مود میتونه به خواب بهتر کمک کنه.
▪️کاهش مصرف باتری : روی نمایشگرهای OLED، رنگهای تیره مصرف انرژی کمتری دارن.
▪️کاهش خیرگی در محیطهای کمنور : وقتی نور اطراف کم باشه، دارک مود فشار کمتری به چشم وارد میکنه.
معایب علمی دارک مود :
▪️کاهش خوانایی متن در روز: چشم انسان به خوندن متن تیره روی پسزمینه روشن عادت داره، و دارک مود توی نور زیاد باعث خستگی چشم میشه.
▪️برخی تحقیقات نشون میدن که چشم توی حالت دارک مود بیشتر مجبور به تطبیق و تمرکز میشه، که میتونه خستگی ایجاد کنه.
▪️برخلاف تصور عموم، تغییر تم به تنهایی تأثیر زیادی روی کاهش خشکی و خستگی چشم نداره، بلکه میزان پلک زدن و استراحت دادن به چشم مهمتره.
❤1