✍️Iman Hosseini PourIman Hosseini Pour
مدت زیادی هست که #Redis Stack منتشر شده ولی هنوز خیلی ها به Redis به چشم یک دیتابیس Key-Value ساده نگاه میکنند و از 90 درصد قابلیت هاش استفاده نمیکنند. پیشنهاد میکنم داکیومنت مربوط بهش رو حتما بخونیدتا تمام ویژگی هایی رو که داره ببینید.
دوتا از ویژگی های خوبی که Redis Stack داره به اسم Redis Search و Redis JSON هست.
- تا قبل از Redis JSON برای ذخیره کردن JSON ها در Redis، معادل Serialize شده رو به صورت Key-Value ذخیره میکردن و یا گاهی به صورت Map باهاش رفتار میکردن. حالا شما با Redis JSON میتونید مثل یک document oriented database مثل MongoDB
رفتار کنید. ( البته Query ها به صورت پیش فرض محدودیت هایی دارند )
- تا قبل از Redis Search برای سرچ کردن تنها گزینه موجود استفاده از Glob Pattern ها بود که حتی داخل خود داکیومنت هم پیشنهاد کرده بودن که اگر روی Production هستید سعی کنید زیاد استفاده از Glob pattern نکنید. و این موضوع با در نظر گرفتن این نکته که Redis به صورت ذاتی Single thread هست و Event loop رو با این کار در حجم زیاد دیتا بلاک میکنید منطقی هست. البته این موضوع برای دوستان #JavaScript و #NodeJS کاملا به صورت واضح قابل درک هست. حالا شما با استفاده از Redis Search میتونید روی دیتا مورد نظرتون Index بزارید و باتوجه به اون Index و Schema که تعریف کردین Query بزنید و دیتا رو خیلی سریع و تمیز دریافت کنید. انتظار قدرت SQL و بقیه دیتابیس ها مثل MongoDB رو نداشته باشید ولی در بعضی سناریو ها واقعا ترکیب Redis Json و Redis Search میدرخشه.
➖➖➖➖➖➖➖➖
👑 @Database_Academy
مدت زیادی هست که #Redis Stack منتشر شده ولی هنوز خیلی ها به Redis به چشم یک دیتابیس Key-Value ساده نگاه میکنند و از 90 درصد قابلیت هاش استفاده نمیکنند. پیشنهاد میکنم داکیومنت مربوط بهش رو حتما بخونیدتا تمام ویژگی هایی رو که داره ببینید.
دوتا از ویژگی های خوبی که Redis Stack داره به اسم Redis Search و Redis JSON هست.
- تا قبل از Redis JSON برای ذخیره کردن JSON ها در Redis، معادل Serialize شده رو به صورت Key-Value ذخیره میکردن و یا گاهی به صورت Map باهاش رفتار میکردن. حالا شما با Redis JSON میتونید مثل یک document oriented database مثل MongoDB
رفتار کنید. ( البته Query ها به صورت پیش فرض محدودیت هایی دارند )
- تا قبل از Redis Search برای سرچ کردن تنها گزینه موجود استفاده از Glob Pattern ها بود که حتی داخل خود داکیومنت هم پیشنهاد کرده بودن که اگر روی Production هستید سعی کنید زیاد استفاده از Glob pattern نکنید. و این موضوع با در نظر گرفتن این نکته که Redis به صورت ذاتی Single thread هست و Event loop رو با این کار در حجم زیاد دیتا بلاک میکنید منطقی هست. البته این موضوع برای دوستان #JavaScript و #NodeJS کاملا به صورت واضح قابل درک هست. حالا شما با استفاده از Redis Search میتونید روی دیتا مورد نظرتون Index بزارید و باتوجه به اون Index و Schema که تعریف کردین Query بزنید و دیتا رو خیلی سریع و تمیز دریافت کنید. انتظار قدرت SQL و بقیه دیتابیس ها مثل MongoDB رو نداشته باشید ولی در بعضی سناریو ها واقعا ترکیب Redis Json و Redis Search میدرخشه.
➖➖➖➖➖➖➖➖
👑 @Database_Academy
👍1🤩1
📌 Database Administration (DBA) Engineering Manager
📝 Type: Visa Sponsorship
🌍 Relocation Package: ✅
🏢 Company: TradingView
📍 Location: UNITED KINGDOM
⌨️ Category: #Programming
🔗 Tags: #javascript #python #reactjs #typescript #golang #mysql #postgresql #redis #kubernetes #aws #cloud
📝 Type: Visa Sponsorship
🌍 Relocation Package: ✅
🏢 Company: TradingView
📍 Location: UNITED KINGDOM
⌨️ Category: #Programming
🔗 Tags: #javascript #python #reactjs #typescript #golang #mysql #postgresql #redis #kubernetes #aws #cloud
🔵 عنوان مقاله
Kafka is Fast, I'll Use Postgres
🟢 خلاصه مقاله:
الهامگرفته از پستی درباره استفاده از Postgres بهجای Redis، نویسنده بررسی میکند آیا Postgres میتواند در بسیاری از سناریوهایی که معمولاً به Kafka فکر میکنیم «بهقدر کافی خوب» باشد یا نه. نتیجه این است که Kafka برای مقیاس بسیار بالا، نگهداری طولانیمدت رویدادها، پخش به چندین مصرفکننده، و بازپخش تاریخچه انتخاب برتر است، اما هزینه عملیاتی و پیچیدگی بیشتری دارد. در مقابل، Postgres با الگوهایی مثل transactional outbox، صف مبتنی بر جدول با SKIP LOCKED، LISTEN/NOTIFY برای اعلام سبک، و حتی logical decoding برای جریان تغییرات، میتواند نیازهای متداول را با سادگی عملیاتی و تضمینهای تراکنشی قوی پوشش دهد. البته محدودیتهایی مانند مدیریت دستی نگهداری و offset، محدودیتهای LISTEN/NOTIFY، و برنامهریزی برای بازپخش وجود دارد. جمعبندی: اگر نرخ رویداد متوسط، تعداد مصرفکننده کم، و سادگی عملیاتی اولویت دارد، Postgres انتخاب عملی است؛ و وقتی به پخش گسترده، بازپخش طولانی و توان عبوری بسیار بالا نیاز دارید، Kafka مناسبتر است.
#Postgres #Kafka #Redis #معماری_سیستم #پیام_محور #Outbox #EventDriven
🟣لینک مقاله:
https://postgresweekly.com/link/176354/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Kafka is Fast, I'll Use Postgres
🟢 خلاصه مقاله:
الهامگرفته از پستی درباره استفاده از Postgres بهجای Redis، نویسنده بررسی میکند آیا Postgres میتواند در بسیاری از سناریوهایی که معمولاً به Kafka فکر میکنیم «بهقدر کافی خوب» باشد یا نه. نتیجه این است که Kafka برای مقیاس بسیار بالا، نگهداری طولانیمدت رویدادها، پخش به چندین مصرفکننده، و بازپخش تاریخچه انتخاب برتر است، اما هزینه عملیاتی و پیچیدگی بیشتری دارد. در مقابل، Postgres با الگوهایی مثل transactional outbox، صف مبتنی بر جدول با SKIP LOCKED، LISTEN/NOTIFY برای اعلام سبک، و حتی logical decoding برای جریان تغییرات، میتواند نیازهای متداول را با سادگی عملیاتی و تضمینهای تراکنشی قوی پوشش دهد. البته محدودیتهایی مانند مدیریت دستی نگهداری و offset، محدودیتهای LISTEN/NOTIFY، و برنامهریزی برای بازپخش وجود دارد. جمعبندی: اگر نرخ رویداد متوسط، تعداد مصرفکننده کم، و سادگی عملیاتی اولویت دارد، Postgres انتخاب عملی است؛ و وقتی به پخش گسترده، بازپخش طولانی و توان عبوری بسیار بالا نیاز دارید، Kafka مناسبتر است.
#Postgres #Kafka #Redis #معماری_سیستم #پیام_محور #Outbox #EventDriven
🟣لینک مقاله:
https://postgresweekly.com/link/176354/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TopicPartition
Kafka is fast -- I'll use Postgres
Why you should just use Postgres instead of Kafka for small-scale message queuing and pub-sub patterns. Benchmarks and practical tests included.
🔵 عنوان مقاله
Redis is Fast - I'll Cache in Postgres
🟢 خلاصه مقاله:
** این مقاله مقایسهای بین استفاده از Postgres و Redis برای کارهای کش ساده ارائه میکند و نتیجه میگیرد که هرچند Redis از نظر سرعت خام برتر است، در بسیاری از سناریوها این برتری آنقدر نیست که اضافهکردن یک سیستم جداگانه را توجیه کند. اگر دادههای پرتکرار در حافظه Postgres جا شوند و با یک جدول کلید-مقدار ساده (بههمراه expires_at و ایندکس مناسب)، prepared statements و connection pooling کار کنید، تأخیر بهحد کافی پایین و پایدار خواهد بود. زمانی Redis منطقی است که به تأخیر بسیار کم و QPS بسیار بالا نیاز دارید، کش مشترک بین سرویسها میخواهید، یا به قابلیتهای خاص آن مثل data structures، pub/sub و eviction policies نیاز دارید. در غیر این صورت، سادگی عملیاتی، هزینه کمتر و کاهش نقاط خرابی با استفاده از Postgres ارزشمندتر است؛ و در صورت آشکار شدن گلوگاه عملکردی، میتوان بعداً Redis را پشت یک رابط مناسب اضافه و بهتدریج مهاجرت کرد.
#Redis #Postgres #Caching #Performance #Databases #Architecture #DevOps #Scalability
🟣لینک مقاله:
https://postgresweekly.com/link/174758/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Redis is Fast - I'll Cache in Postgres
🟢 خلاصه مقاله:
** این مقاله مقایسهای بین استفاده از Postgres و Redis برای کارهای کش ساده ارائه میکند و نتیجه میگیرد که هرچند Redis از نظر سرعت خام برتر است، در بسیاری از سناریوها این برتری آنقدر نیست که اضافهکردن یک سیستم جداگانه را توجیه کند. اگر دادههای پرتکرار در حافظه Postgres جا شوند و با یک جدول کلید-مقدار ساده (بههمراه expires_at و ایندکس مناسب)، prepared statements و connection pooling کار کنید، تأخیر بهحد کافی پایین و پایدار خواهد بود. زمانی Redis منطقی است که به تأخیر بسیار کم و QPS بسیار بالا نیاز دارید، کش مشترک بین سرویسها میخواهید، یا به قابلیتهای خاص آن مثل data structures، pub/sub و eviction policies نیاز دارید. در غیر این صورت، سادگی عملیاتی، هزینه کمتر و کاهش نقاط خرابی با استفاده از Postgres ارزشمندتر است؛ و در صورت آشکار شدن گلوگاه عملکردی، میتوان بعداً Redis را پشت یک رابط مناسب اضافه و بهتدریج مهاجرت کرد.
#Redis #Postgres #Caching #Performance #Databases #Architecture #DevOps #Scalability
🟣لینک مقاله:
https://postgresweekly.com/link/174758/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Dizzy zone
Redis is fast - I'll cache in Postgres
There are books & many articles online, like this one arguing for using Postgres for everything. I thought I’d take a look at one use case - using Postgres instead of Redis for caching. I work with APIs quite a bit, so I’d build a super simple HTTP server…