بکاپ گرفتن از دیتابیس پستگرس و ارسال آن به یک گروه خصوصی و تنظیم زمان بندی جهت اجرای مداوم آن در لینوکس


سناریو از چه قرار خواهد بود
ما یک دیتابیس پستگرس داریم و روی داکر بصورت کانتینر در سرور اجرا شده و میخوایم ازش بکاپ گرفته و در تلگرام اون رو داشته باشیم

ابتدا تلگرام رو آماده میکنیم
مراحل زیر رو گام بگام باهم پیش میریم

مرحله اول:
ابتدا یک بات تلگرامی میسازیم

به بات پدر @BotFather رفته  و استارت رو میزنیم
درخواست newbot/ رو میزنیم
از ما یک اسم میخواد که اسمش رو میزاریم backup
از ما یوزرنیم میخواد که با bot اتمام شود که ترکیبی مینویسیم bakup<projectname>bot

و بعد از اتمام پیغام موفقیت و در آن token bot رو میگیریم و نگه میداریم و این توکن رو با نام BOT_TOKEN میشناسیم

مرحله دوم:
یک گروه خصوصی ساخته و بات بالا رو به همراه کاربرانی که میخواهیم به فایل‌های بکاپ دسترسی داشته باشن رو اضافه میکنیم

به ربات @raw_data_bot رفته استارت رو میزنیم سپس chat رو انتخاب میکنیم و از میان لیست باز شده گروه خصوصی ساخته شده رو بهش میدیم و chat id رو ازش میگیریم و نگه میداریم و با نام CHAT_ID اون رو میشناسیم

اماده سازی سرور
مراحل رو گام بگام پیش میریم

مرحله اول:
با دستور docker ps نام کانتینر پستگرس رو نگه میداریم و با نام CONTAINER_NAME میشناسیم

نام دیتابیس ما در پستگرس رو هم با DB_NAME میشناسیم

اگر پسورد شما با نام دیتابیس متفاوت هست اون رو هم نگه دارید و اگه پورت پیش فرض رو هم تغییر داده‌اید اون رو هم لازم دارید(ما تصور میکنیم که پورت پیش فرض و پسورد دیتابیس با نام اون یکسان است)

مرحله دوم:
ساخت یک دایرکتوری برای بکاپ‌ها

در یک مسیر دلخواه در سرور یک دایرکتوری با اسم backups میسازیم 
mkdir backups
chmod 777 backups
cd backups

سپس مسیر آنرا با دستور زیر خواهیم گرفت
pwd 
این مسیر رو نگه میداریم و با نام PATH میشناسیم

مرحله سوم:
ساخت یک فایل حاوی کدهای بش اسکریپت
یک فایل با نام backup.sh ساخته و کدهای زیر رو در اون قرار میدیم

sudo nano backup.sh

کدهای زیر رو در اون بزارید

#!/bin/bash

docker exec -t <CONTAINER_NAME> pg_dumpall -c -U <DB_NAME> > <PATH> backup_$(date +%Y%m%d-%H%M).sql


curl -s -X POST -F chat_id=<CHAT_ID> -F caption=<CAPTION> -F document=@$(ls -t <PATH> backup_*.sql | head -1) https://api.telegram.org/bot<BOT_TOKEN>/sendDocument


find <PATH> -type f -name "backup_*.sql" -mtime +7 -exec rm {} \;

توضیحات کد
در خط اول به کانتینر وصل شده و فایل بکاپ رو گرفته و در دایرکتوری backups ذخیره میکنیم درون اسم فایل بکاپ تایم رو هم میگذاریم

در خط دوم فایل بکاپ گرفته رو به تلگرام انتقال میدهیم

در خط سوم هر فایل بکاپی که یک هفته از آن گذشته باشه رو حذف میکنیم(بکاپ‌های یک هفته‌ای رو نگه میداریم فقط)

نکته: درون فایل بش اسکریپتی مقادیری رو که گفتیم با این نام میشناسیم رو با مقدار مطابق خودشون در این فایل جابجا کرده و فایل رو ذخیره میکنیم در مقدار <CAPTION> متن دلخواه خود را بزارید


بعد از اتمام یکبار با دستور زیر فایل بش اسکریپت رو اجرا کرده و نتیجه کار رو میبینیم

sudo ./backup.sh

زمان بندی کردن بکاپ گیری جهت اجرا شدن در بازه‌های زمانی متداول

اینکار رو با استفاده از کرون‌جاب‌های لینوکس انجام میدهیم

دستور crontab -e رو میزنیم

سپس یک ادیتور انتخاب میکنیم

و مقدار زیر رو به فایل اصافه کرده و ذخیره میکنم
0 24 * * * <PATH>backup.sh

هر روز ساعت دوازده شب یک فایل بکاپ براتون ارسال خواهد شد در تلگرام


#postgresql

@code_crafters

باینری ها در PostgreSQL: ذخیره سازی اطلاعات خام

تصور کنید می‌خواهید عکسی از گربه‌تان را در PostgreSQL ذخیره کنید. چطور می‌توانید این کار را انجام دهید؟

پایگاه داده PostgreSQL نوع داده‌ای به نام bytea را ارائه می‌دهد که برای ذخیره اطلاعات باینری مانند تصاویر، فایل‌های صوتی و ویدئوها ایده‌آل است.

تفاوت باینری و رشته‌های کاراکتری:

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

فرمت‌های ذخیره سازی:

هگزادسیمال: هر بایت به عنوان دو رقم شانزده‌گانی نمایش داده می‌شود (مثلاً "00" برای بایت صفر). این فرمت خوانایی بیشتری دارد.
نوع Escape: برخی از بایت‌ها با کاراکترهای خاص علامت‌گذاری می‌شوند. این فرمت قدیمی‌تر است و کاربرد کمتری دارد.

کاربردها:

۱.ذخیره تصاویر، فایل‌های صوتی و ویدئوها
۲.ذخیره داده‌های باینری مانند کدهای برنامه
۳.ذخیره اطلاعات رمزنگاری شده

مثال:

فرض کنید می‌خواهید تصویر گربه‌تان را با نام cat.jpg در پایگاه داده ذخیره کنید:

INSERT INTO photos (name, data)
VALUES ('cat.jpg', BYTEA('\xFF\xD8\xFF\xE0'));

نکات:

پایگاه داده PostgreSQL از نوع داده BLOB (Binary Large Object) نیز برای ذخیره داده‌های باینری پشتیبانی می‌کند. فرمت ورودی BLOB با bytea متفاوت است، اما توابع و عملگرهای مشابهی دارند.
می‌توانید از توابع و عملگرهای مختلفی برای کار با داده‌های bytea استفاده کنید، مانند LENGTH(), SUBSTRING() و COMPARE().

نتیجه:

نوع داده bytea یک ابزار قدرتمند برای ذخیره و مدیریت داده‌های باینری در PostgreSQL است. با استفاده از این نوع داده، می‌توانید انواع مختلف اطلاعات را به طور کارآمد و ایمن ذخیره کنید.

#PostgreSQL
@Code_Crafters

ذخیره سازی اطلاعات خام ولی در حجم بالا با Blob در PostgreSQL

در پایگاه داده PostgreSQL نوع داده‌ای به نام bytea را ارائه می‌دهد که برای ذخیره اطلاعات باینری مانند تصاویر، فایل‌های صوتی و ویدئوها ایده‌آل است. اما گاهی اوقات با داده‌های باینری خیلی بزرگتر از حد معمول سروکار داریم. در اینجاست که مفهوم BLOB یا "Binary Large Object" به کمک ما می‌آید.

تعریف BLOB چیست؟

در واقع BLOB یک نوع داده در PostgreSQL است که برای ذخیره داده‌های باینری بسیار بزرگ مانند:

۱. فایل‌های چند گیگابایتی
۲. مجموعه داده‌های علمی
۳. تصاویر با وضوح بالا
۴. فایل‌های ویدئویی با کیفیت بالا

استفاده می‌شود.

مزایای استفاده از BLOB:

* ذخیره سازی داده‌های حجیم: BLOB ها می‌توانند داده‌هایی با حجم تا 1 ترابایت را ذخیره کنند.
* کارایی: BLOB ها برای ذخیره سازی داده‌های باینری بهینه شده‌اند و می‌توانند عملکرد بهتری نسبت به ذخیره سازی داده‌های باینری در قالب رشته‌های متنی ارائه دهند.
* انعطاف پذیری: BLOB ها می‌توانند برای ذخیره هر نوع داده باینری، صرف نظر از نوع و فرمت آن، استفاده شوند.

نحوه استفاده از BLOB:

برای استفاده از BLOB در PostgreSQL، باید مراحل زیر را انجام دهید:

1. نوع داده BLOB را در جدول خود تعریف کنید:

CREATE TABLE my_table (
  id INT PRIMARY KEY,
  data BYTEA
);

2. با استفاده از دستور INSERT، داده‌های BLOB را در جدول ذخیره کنید:

INSERT INTO my_table (id, data)
VALUES (1, lo_import('image.jpg'));

3. با استفاده از دستور SELECT، داده‌های BLOB را از جدول بازیابی کنید:

SELECT data FROM my_table WHERE id = 1;

نکات مهم:

برای ذخیره و بازیابی BLOB ها، باید از توابع lo_import و lo_export استفاده کنید.
پایگاه داده PostgreSQL ابزارهای مختلفی برای مدیریت BLOB ها ارائه می‌دهد، مانند توابع و عملگرهای خاص.
برای اطلاعات بیشتر در مورد BLOB ها، می‌توانید به مستندات PostgreSQL مراجعه کنید.

مثال:

فرض کنید می‌خواهید یک ویدیو با حجم 2 گیگابایت را در PostgreSQL ذخیره کنید. می‌توانید مراحل زیر را انجام دهید:

1. نوع داده BLOB را در جدول خود تعریف کنید:

CREATE TABLE videos (
  id INT PRIMARY KEY,
  title VARCHAR(255),
  data BYTEA
);

2. با استفاده از دستور INSERT، ویدیو را در جدول ذخیره کنید:

INSERT INTO videos (id, title, data)
VALUES (1, 'My Video', lo_import('video.mp4'));

3. با استفاده از دستور SELECT، ویدیو را از جدول بازیابی کنید:

SELECT data FROM videos WHERE id = 1;

با استفاده از BLOB ها، می‌توانید هر نوع داده باینری را در PostgreSQL ذخیره کنید و به آنها دسترسی داشته باشید. این امر PostgreSQL را به یک راه حل قدرتمند برای ذخیره سازی و مدیریت داده‌های باینری تبدیل می‌کند.

در ادامه، چند نمونه دیگر از کاربردهای BLOB در PostgreSQL آورده شده است:

۱. ذخیره سازی اسناد و مدارک
۲. ذخیره سازی تصاویر و ویدیوها
۳. ذخیره سازی فایل‌های صوتی
۴. ذخیره سازی پایگاه داده‌های NoSQL
۵. ذخیره سازی داده‌های رمزنگاری شده

جمع بندی:

در واقع BLOB ها یک ابزار قدرتمند برای ذخیره سازی داده‌های باینری در PostgreSQL هستند. با استفاده از BLOB ها، می‌توانید داده‌های حجیم را به طور کارآمد و ایمن ذخیره کنید.

#PostgreSQL
@Code_Crafters

خب در ادامه پست های استفاده از ایندکس در جداول دیتابیس قرار در این پست با Multi-Column Indexes اشنا بشیم/

ایندکس‌های چندستونی (Multi-Column Indexes) برای بهبود کارایی جستجو در جداولی که به طور مکرر از چندین ستون در کوئری‌های خود استفاده می‌کنند، بسیار مفید هستند. این نوع ایندکس‌ها بر روی بیش از یک ستون از جدول ایجاد می‌شوند و می‌توانند به طور همزمان ترتیب چند ستون را برای بهبود سرعت جستجو حفظ کنند.

ویژگی‌های ایندکس‌های چندستونی
1. ترتیب ستون‌ها:
   - ترتیب ستون‌هایی که در ایندکس تعریف می‌شوند بسیار مهم است.
   - ایندکس ابتدا بر اساس ستون اول مرتب می‌شود و سپس در داخل هر مقدار ستون اول، بر اساس ستون دوم و به همین ترتیب ادامه می‌یابد.
   - انتخاب ترتیب مناسب ستون‌ها بر اساس الگوهای کوئری معمول، می‌تواند تاثیر زیادی بر کارایی جستجو داشته باشد.

2. بهبود کارایی:
   - ایندکس‌های چندستونی می‌توانند کارایی کوئری‌هایی را که از این ستون‌ها در شرط WHERE، ORDER BY، و GROUP BY استفاده می‌کنند، بهبود بخشند.
   - در کوئری‌هایی که فقط از ستون اول ایندکس استفاده می‌کنند نیز می‌تواند بهبود کارایی ایجاد کند.

3. محدودیت‌ها:
   - ایندکس‌های چندستونی می‌توانند فضای بیشتری را نسبت به ایندکس‌های تک‌ستونی اشغال کنند.
   - به‌روزرسانی‌های جداولی که دارای ایندکس‌های چندستونی هستند می‌توانند زمان‌برتر باشند به دلیل نیاز به بروزرسانی ساختار ایندکس.

مثال‌ها و کد

فرض کنید یک جدول به نام employees داریم که شامل ستون‌های first_name، last_name، و department_id است و می‌خواهیم یک ایندکس چندستونی بر روی ستون‌های last_name و department_id ایجاد کنیم.

ایجاد ایندکس چندستونی
در SQL، ایجاد یک ایندکس چندستونی به شکل زیر است:

CREATE INDEX idx_lastname_department ON employees (last_name, department_id);

این ایندکس ابتدا بر اساس last_name و سپس بر اساس department_id مرتب می‌شود.

استفاده از ایندکس چندستونی در کوئری‌ها

مثال 1: جستجو بر اساس هر دو ستون

SELECT * FROM employees WHERE last_name = 'Doe' AND department_id = 5;

در این کوئری، هر دو ستون last_name و department_id استفاده شده‌اند، بنابراین ایندکس idx_lastname_department به طور کامل بهره‌برداری می‌شود و کارایی جستجو افزایش می‌یابد.

مثال 2: جستجو بر اساس ستون اول

SELECT * FROM employees WHERE last_name = 'Doe';

در این کوئری، تنها ستون last_name استفاده شده است که ستون اول ایندکس است. بنابراین ایندکس هنوز هم می‌تواند کارایی جستجو را بهبود بخشد.

مثال 3: جستجو بر اساس ستون دوم

SELECT * FROM employees WHERE department_id = 5;

در این کوئری، تنها ستون department_id استفاده شده است که ستون دوم ایندکس است. این کوئری نمی‌تواند از ایندکس idx_lastname_department بهره‌برداری کند و به احتمال زیاد از اسکن کامل جدول استفاده خواهد کرد.

به‌روزرسانی و حذف ایندکس
برای حذف یک ایندکس چندستونی:

DROP INDEX idx_lastname_department ON employees;

نکات مهم
1. انتخاب ستون‌ها: ستون‌هایی را انتخاب کنید که در بیشتر کوئری‌ها استفاده می‌شوند و ترتیب آنها را بر اساس بیشترین تاثیر بر کارایی جستجو تعیین کنید.
2. نگهداری و به‌روزرسانی: با افزایش تعداد ایندکس‌ها، عملیات نوشتن (INSERT, UPDATE, DELETE) کندتر می‌شود. به همین دلیل، باید توازن مناسبی بین تعداد ایندکس‌ها و نیازهای جستجو برقرار کرد.
3. تحلیل کارایی: استفاده از ابزارهای تحلیل کارایی (مانند EXPLAIN در SQL) برای بررسی تاثیر ایندکس‌ها بر کوئری‌ها مفید است.

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


#database
#postgresql

در ادامه پست ها راجب استفاده از ایندکس در دیتابیس, در این پست قراره نحوه استفاده از Multi-Column Indexes ها در جنگو ببینیم. همچنین اگه نمیدونید که Multi-Column Indexe چیه و دقیقا چیکار میکنه, اول این پست رو مطالعه کنید.

1. تعریف مدل با ایندکس چندستونی
فرض کنید یک مدل به نام Employee داریم که شامل فیلدهای first_name، last_name، و department_id است. برای ایجاد ایندکس چندستونی بر روی last_name و department_id، می‌توانید از ویژگی Meta در مدل استفاده کنید.

from django.db import models

class Employee(models.Model):
    first_name = models.CharField(max_length=100)
    last_name = models.CharField(max_length=100)
    department_id = models.IntegerField()

    class Meta:
        indexes = [
            models.Index(fields=['last_name', 'department_id']),
        ]

    def __str__(self):
        return f'{self.first_name} {self.last_name}'
 

در این کد، یک ایندکس چندستونی بر روی last_name و department_id تعریف شده است.



2. استفاده از ایندکس در کوئری‌ها
پس از ایجاد ایندکس، می‌توانید کوئری‌هایی بنویسید که از این ایندکس بهره‌مند شوند. به عنوان مثال:

مثال 1: جستجو بر اساس هر دو ستون

from .models import Employee

employees = Employee.objects.filter(last_name='Doe', department_id=5)
 

در این کوئری، هر دو ستون last_name و department_id استفاده شده‌اند، بنابراین ایندکس به طور کامل بهره‌برداری می‌شود و کارایی جستجو افزایش می‌یابد.

مثال 2: جستجو بر اساس ستون اول

employees = Employee.objects.filter(last_name='Doe')
 

در این کوئری، تنها ستون last_name استفاده شده است که ستون اول ایندکس است. بنابراین ایندکس هنوز هم می‌تواند کارایی جستجو را بهبود بخشد.

مثال 3: جستجو بر اساس ستون دوم

employees = Employee.objects.filter(department_id=5)
 

در این کوئری، تنها ستون department_id استفاده شده است که ستون دوم ایندکس است. این کوئری نمی‌تواند از ایندکس چندستونی بهره‌برداری کند و به احتمال زیاد از اسکن کامل جدول استفاده خواهد کرد.

3. تحلیل کارایی
برای تحلیل کارایی کوئری‌ها و مشاهده اینکه آیا ایندکس‌ها استفاده می‌شوند یا خیر، می‌توانید از ابزارهایی مانند django-debug-toolbar استفاده کنید که اطلاعات کوئری‌ها و ایندکس‌ها را نمایش می‌دهد.

نتیجه‌گیری
با استفاده از ایندکس‌های چندستونی در Django، می‌توانید کارایی جستجوهای پیچیده را بهبود ببخشید. با تعریف درست ایندکس‌ها و استفاده بهینه از آن‌ها در کوئری‌ها، می‌توانید به طور قابل توجهی زمان پاسخ‌دهی دیتابیس را کاهش دهید.

#database
#postgresql


@code_crafters

خب سلام دوباره در ادامه مجموعه پست های دیتابیس تو این یکی قراره با معماری Vitess اشنا بشیم و متوجه بشیم یوتوب چگونه 2.49 میلیارد کاربر خودش رو با MySQL هندل میکنه.
توجه این پست بر اساس تحقیق هستش و ممکنه با پیاده‌سازی واقعی فرق داشته باشه.



روزی روزگاری، سه نفر که تو PayPal کار می‌کردن، تصمیم گرفتن یه سایت دوستیابی درست کنن. اما مدل کسب‌وکارشون شکست خورد. برای همین ایده‌شون رو عوض کردن و یه سایت اشتراک‌گذاری ویدئو درست کردن و اسمش رو گذاشتن یوتیوب.

اونا عناوین ویدئوها، توضیحات و اطلاعات کاربران رو تو MySQL ذخیره کردن. وقتی کاربرهای بیشتری به سایت پیوستن، اونا MySQL رو به حالت رهبر-دنبال‌کننده (leader-follower replication topology) تنظیم کردن تا بتونن بهتر مقیاس‌پذیری کنن. اما تکرار در MySQL تک‌نخی (single-threaded) است. بنابراین دنبال‌کننده‌ها نمی‌تونستن در عملیات نوشتن شدید به رهبر برسند و داده‌های جدید رو به‌روز کنن. با این حال، نرخ رشدشون خیلی زیاد بود و به یک میلیارد کاربر رسیدن و به دومین سایت پربازدید در جهان تبدیل شدن.

بنابراین با اضافه کردن یه حافظه نهان (cache) مقیاس‌پذیری کردن و همه رویدادها رو از لاگ باینری MySQL (binary log) بارگذاری کردن. این یعنی تکرار به حافظه وابسته شد و سرعت بیشتری پیدا کرد. اگرچه این کار به طور موقت مشکل مقیاس‌پذیری اونا رو حل کرد، مشکلات جدیدی به وجود اومد.

در اینجا به برخی از اونا اشاره می‌کنم:

1. پارتیشن‌بندی (Sharding):
اولین کاری که باید کرد این که MySQL باید پارتیشن‌بندی بشه تا نیازهای ذخیره‌سازی رو مدیریت کنه. اما بعد از پارتیشن‌بندی، معاملات (transactions) و پیوستن جداول (joins) سخت میشه. بنابراین منطق برنامه (application logic) باید این رو مدیریت کنه. این یعنی منطق برنامه باید بفهمه که کدوم پارتیشن‌ها رو باید پرس‌وجو کنه و این باعث افزایش احتمال زمان خرابی (downtime) میشه.

2. عملکرد (Performance):
و(leader-follower replication topology) باعث میشه که داده‌های قدیمی از دنبال‌کننده‌ها خونده بشه. بنابراین منطق برنامه باید خوندن داده‌ها رو به رهبر هدایت کنه اگر داده‌های جدید لازم باشه. و این نیاز به پیاده‌سازی منطق اضافی داره.

3. حفاظت (Protection):
ریسک اینکه برخی پرس‌وجوها خیلی طول بکشه تا داده‌ها رو برگردونن وجود داره. همچنین تعداد زیادی از اتصالات MySQL به طور همزمان می‌تونه مشکل‌ساز بشه و ممکنه دیتابیس رو از کار بندازه.

اونا می‌خواستن یه لایه انتزاعی روی MySQL برای سادگی و مقیاس‌پذیری ایجاد کنند. بنابراین Vitess رو ساختن. در اینجا نحوه ارائه مقیاس‌پذیری بالا توسط Vitess رو توضیح می‌دم:

1. تعامل با پایگاه داده:(Interacting with Database)
اونا یه سرور جانبی (sidecar server) جلو هر نمونه MySQL نصب کردن و اسمش رو گذاشتند VTTablet.

این سرور جانبی به اونا اجازه می‌داد:
- کنترل سرور MySQL و مدیریت پشتیبان‌گیری از پایگاه داده
- بازنویسی کوئری‌های سنگین با اضافه کردن محدودیت (limit clause)
- کش کردن داده‌های پر دسترس برای جلوگیری از مشکل Thundering Herd

2. مسیریابی کوئری‌ها(Routing SQL Queries):

یه سرور پراکسی بدون حالت (stateless proxy server) برای مسیریابی کوئری‌ها تنظیم کردند و اسمش رو گذاشتند VTGate.

این سرور پراکسی بهشون اجازه می‌داد:
- پیدا کردن VTTablet صحیح برای مسیریابی کوئری بر اساس اسکیما و طرح پارتیشن‌بندی
- پایین نگه داشتن تعداد اتصالات MySQL از طریق تجمیع اتصالات (connection pooling)
- صحبت با لایه کاربردی به پروتکل MySQL
- عمل کردن مانند یه سرور MySQL یکپارچه برای سادگی
- محدود کردن تعداد معاملات در یک زمان برای عملکرد بهتر

همچنین برای مقیاس‌پذیری بیشتر، سرورهای VTGate متعددی راه‌اندازی کردند.

3. اطلاعات حالت:
تصویر چهارم در کامنت ها
یه پایگاه داده توزیع‌شده کلید-مقدار (distributed key-value database) راه‌اندازی کردند تا اطلاعات مربوط به اسکیما، طرح‌های پارتیشن‌بندی و نقش‌ها رو ذخیره کنه.

این پایگاه داده همچنین روابط بین پایگاه‌های داده مثل رهبر و دنبال‌کننده‌ها رو مدیریت می‌کنه.

در ادمه از Zookeeper برای پیاده‌سازی این پایگاه داده کلید-مقدار استفاده کرندند.

علاوه بر این، این داده‌ها رو در VTGate برای عملکرد بهتر کش میکردند.
برای به‌روزرسانی پایگاه داده کلید-مقدار، یه سرور HTTP راه‌اندازی کردند و اسمش رو گذاشتند VTctld. این سرور فهرست کامل سرورها و روابطشون رو می‌گیره و سپس پایگاه داده کلید-مقدار رو به‌روزرسانی می‌کنه.


#database
#postgresql


@code_crafters