پستگرس: یه دیتابیس بهجای دهها ابزار دیگه
خلاصهٔ کاملتر
نویسنده که از سال ۲۰۰۳ با PostgreSQL کار میکنه میگه قدرت این دیتابیس از سه جا میاد: خیلی پایدار و باثباته، نصب و اجرا و اسکیل کردنش سادهست، و از همه مهمتر، میتونه جای خیلی از سیستمهای جدا رو بگیره و زیرساخت رو سادهتر کنه. اولین نسخهی PostgreSQL به سال ۱۹۹۶ برمیگرده؛ یعنی یه تکنولوژی قدیمیه، اما هر نسخهی جدیدش قابلیتهای خیلی مدرنی مثل ذخیرهی JSON، پارتیشنبندی و کوئریهای بازگشتی (CTE) بهش اضافه شده.
به گفتهی نویسنده، PostgreSQL میتونه جای Elasticsearch و Solr رو برای جستجوی متنی بگیره، همونطوری که Contentful و Instacart این کارو انجام دادن؛ دیگه لازم نیست دو تا سیستم جدا رو سینک نگه داشت. با پشتیبانی خوبی که از JSON و ایندکس GIN داره، جای MongoDB رو هم میتونه بگیره؛ گاردین هم دقیقاً همین کارو کرده. و با استفاده از SELECT ... FOR UPDATE و SELECT ... SKIP LOCKED میشه یه جدول ساده رو تبدیل به صف پیام کرد و بهجای Kafka یا RabbitMQ ازش استفاده کرد.
برای دادههای سریزمانی حجیم هم با پلاگین TimescaleDB میشه بهجای ClickHouse از PostgreSQL استفاده کرد، و با اکستنشن pgvector حتی میشه از همون PostgreSQL بهعنوان دیتابیس برداری برای پروژههای هوش مصنوعی و LLM هم بهره برد. برای کش هم پیشنهاد نویسنده استفاده از جدولهای UNLOGGEDه که تقریباً به سرعت Redis میرسن؛ حتی میشه با تریگر، رفتار expire شدن خودکار رو هم شبیهسازی کرد.
نویسنده یه مثال جالب هم از تجربهی خودش میده: تو یکی از پروژهها برای ذخیره و خوندن حجم زیادی دادهی باینری کوچیک، PostgreSQL از خود فایلسیستم هم سریعتر بود. برای دادههای سلسلهمراتبی هم نوع دادهی LTREE رو جایگزین کوئریهای بازگشتی پیچیده معرفی میکنه. جمعبندی نویسنده اینه که قبل از اضافه کردن هر ابزار جدید، اول باید پرسید: PostgreSQL از پسش برنمیاد؟
نکات کلیدی:
- اولین نسخهی PostgreSQL از سال ۱۹۹۶ وجود داره و هنوز فعالانه توسعه پیدا میکنه
- با ایندکس GIN و ستون JSON میتونه جای MongoDB رو بگیره
- با SELECT ... FOR UPDATE و SKIP LOCKED میشه صف پیام ساخت، بهجای Kafka یا RabbitMQ
- اکستنشن TimescaleDB برای دادهی سریزمانی و pgvector برای کاربردهای هوش مصنوعی در دسترسه
- جدولهای UNLOGGED میتونن بهجای Redis برای کش سریع استفاده بشن
