پایگاه-داده (Database) چیست؟
پایگاه داده یا دیتابیس، مجموعهای سازمانیافته از دادههاست که یک نرمافزار جداگانه (سامانه مدیریت پایگاه داده) آن را ذخیره، جستوجو و بهروزرسانی میکند. هر سایت پویا و هر سیستم مدیریت محتوا دستکم به یک پایگاه داده نیاز دارد، چون متن مطالب، مشخصات کاربران، سفارشها و تنظیمات سایت بهجای فایلهای پراکنده، در جدولهای همین پایگاه داده نگهداری میشود.
دیتابیس (Database) در لغت به معنی پایگاه داده است؛ محلی برای نگهداری منظم اطلاعات وبسایت شما. هنگام کار با سیستمهای مدیریت محتوا مانند وردپرس، با هر بار باز شدن یک صفحه، اطلاعات از دیتابیس فراخوانی میشوند، در قالب سایت قرار میگیرند و در مرورگر شما به نمایش درمیآیند.
دیتابیس چه چیزی را نگه میدارد و چه چیزی را نه؟
هر داده ساختیافته و متنی در دیتابیس جای میگیرد: مشخصات کاربران، رمزهای عبور هششده، متن نوشتهها و دیدگاهها، سفارشها و تنظیمات افزونهها. در مقابل، تصاویر و ویدیوها بهصورت فایل روی دیسک ذخیره میشوند و معمولاً فقط مسیر آنها در جدولها ثبت میشود؛ به همین دلیل پایگاه داده را نباید با فایل منیجر یکی دانست.
در یک هاست اشتراکی، این دو بخش روی یک سرور کنار هم قرار دارند: فایلها در مسیر public_html و جدولها داخل سرویس دیتابیس همان سرور. یادآوری این تفکیک مهم است، چون بکآپ فقط زمانی کامل است که هم فایلها و هم دیتابیس را شامل شود.
دو خانواده اصلی: رابطهای و NoSQL
پایگاه داده رابطهای (SQL)
در مدل رابطهای، دادهها در جدولهایی با ساختار از پیش تعریفشده مینشینند و با زبان SQL پرسوجو میشوند. MySQL و MariaDB (که انشعابی از MySQL است و با آن سازگاری بالایی دارد) رایجترین گزینهها در دنیای هاستینگاند و تقریباً همه سیستمهای مدیریت محتوای PHP روی آنها اجرا میشوند. PostgreSQL انتخاب متداول پروژههای سنگینتر و برنامههای سفارشی است و امکانات پیشرفتهتری در نوع داده و پرسوجو ارائه میکند.
مزیت اصلی این خانواده، ارتباط میان جدولها و پشتیبانی از تراکنش است؛ یعنی چند عملیات یا با هم انجام میشوند یا هیچکدام. برای فروشگاهی که باید همزمان موجودی انبار را کم و فاکتور را ثبت کند، این ویژگی حیاتی است.
پایگاه داده NoSQL
در NoSQL خبری از ساختار ثابت جدول نیست. MongoDB داده را به شکل سند ذخیره میکند، Redis انباری کلید-مقدار در حافظه است که بیشتر برای کش و نگهداری نشستها به کار میرود و Elasticsearch برای جستوجوی متنی سریع ساخته شده. اینها جایگزین دیتابیس رابطهای نیستند، بلکه برای الگوهای دادهای متفاوت طراحی شدهاند و اغلب در کنار آن مینشینند.
جدول، سطر، ستون و کلید
ساختار یک دیتابیس رابطهای شبیه یک فایل صفحهگسترده است. هر جدول مانند یک شیت، هر ستون یک فیلد با نوع داده مشخص (مثل INT، VARCHAR، TEXT یا DATETIME) و هر سطر یک رکورد کامل است. ستونی که هر سطر را بهطور یکتا مشخص میکند کلید اصلی (PRIMARY KEY) نام دارد و ستونی که به کلید اصلی جدول دیگری اشاره میکند کلید خارجی (FOREIGN KEY) است. همین کلیدها هستند که مثلاً هر دیدگاه را به نوشته و هر نوشته را به نویسندهاش وصل میکنند.
در یک نصب وردپرس، محتوای نوشتهها و برگهها در جدول wp_posts، تنظیمات سایت و افزونهها در wp_options و کاربران در wp_users ذخیره میشوند. پیشوند wp_ ثابت نیست و در فایل wp-config.php با متغیر $table_prefix تعیین میشود. اگر سایت شما وردپرسی است، آشنایی با همین چند جدول در هاست وردپرس بیشتر مشکلات روزمره را برایتان قابل تشخیص میکند.
ایندکس و طراحی کوئری؛ جایی که سرعت سایت تعیین میشود
وقتی سایتی کند است، مقصر اغلب نه پهنای باند بلکه کوئریهای ضعیف است. اگر ستونی که در شرط WHERE جستوجو میکنید ایندکس نداشته باشد، موتور دیتابیس مجبور است کل جدول را سطر به سطر بخواند. روی جدول کوچک این پیمایش عملاً بیهزینه است، اما هرچه تعداد سطرها بیشتر شود هزینه همان کوئری بالاتر میرود و میتواند به گلوگاه سرعت صفحه تبدیل شود.
برای دیدن نقشه اجرای یک کوئری کافی است پیش از آن EXPLAIN بگذارید:
EXPLAIN SELECT * FROM wp_posts WHERE post_status = 'publish';
اگر خروجی نشان داد که پیمایش کامل جدول رخ میدهد، ساخت ایندکس روی ستون پرکاربرد راهحل است:
CREATE INDEX idx_email ON users (email);
ایندکس رایگان نیست؛ فضای دیسک مصرف میکند و درج و بهروزرسانی را کندتر میکند، پس فقط روی ستونهایی بسازید که واقعاً در شرط، مرتبسازی یا اتصال جدولها به کار میروند. برای یافتن کوئریهای سنگین هم میتوانید slow_query_log را فعال و آستانه long_query_time را تنظیم کنید. در وردپرس، حجیم شدن ردیفهای با autoload فعال در wp_options یکی از دلایل شناختهشده کندی است، چون در هر بارگذاری صفحه خوانده میشوند.
دیتابیس در کجای معماری هاست قرار میگیرد؟
روی هاست اشتراکی، سرویس دیتابیس روی همان سروری اجرا میشود که فایلهای شما را نگه میدارد؛ به همین دلیل مقدار DB_HOST معمولاً localhost است و تنظیمات موتور دیتابیس در اختیار مدیر سرور قرار دارد، نه شما.
روی سرور مجازی ابری با دسترسی روت، خودتان MySQL یا MariaDB را نصب و پیکربندی میکنید؛ یعنی میتوانید پارامترهایی مانند innodb_buffer_pool_size را در my.cnf متناسب با رم سرور تنظیم کنید. این آزادی به همان اندازه مسئولیت هم میآورد: بکآپ، بهروزرسانی و امنسازی دیتابیس بر عهده خودتان است.
در معماریهای بزرگتر، دیتابیس را از وبسرور جدا و روی یک سرور مستقل اجرا میکنند تا منابع پردازشی این دو با هم رقابت نکنند. در این حالت DB_HOST دیگر localhost نیست و اتصال باید از شبکه داخلی و با محدود کردن دسترسی به IP وبسرور انجام شود. روی همان ماشین، چیدمان دیسک هم اهمیت دارد؛ برای بار نوشتن تصادفی پایگاه داده معمولاً آرایه RAID 10 انتخاب پیشفرض است.
ساخت و مدیریت دیتابیس در کنترل پنل
در سیپنل، از بخش Databases و گزینه MySQL Databases میتوانید یک پایگاه داده جدید بسازید، کاربر تعریف کنید و سپس آن کاربر را با سطح دسترسی لازم به دیتابیس اضافه کنید. برای مرور جدولها و اجرای کوئری هم phpMyAdmin در دسترس است. نام دیتابیس، نام کاربر و رمز عبور، همان مقادیری هستند که هنگام نصب سیستم مدیریت محتوا وارد میکنید.
هشدار: دستورهایی مانند DROP DATABASE و DROP TABLE بدون هیچ تأییدیهای دادهها را حذف میکنند و بازگشتی ندارند. پیش از هر تغییر ساختاری، ابتدا خروجی بگیرید:
mysqldump -u USER -p DBNAME > backup.sql
چند عادت که دیتابیس را سالم نگه میدارد
- بکآپ منظم بگیرید و بازگردانی آن را دستکم یک بار روی محیط آزمایشی تست کنید؛ بکآپ تستنشده یعنی بکآپ نامطمئن.
- برای متن فارسی از کدگذاری
utf8mb4استفاده کنید تا حروف فارسی و ایموجی بدون خرابی ذخیره شوند. - برای هر سایت یک کاربر مجزا با کمترین سطح دسترسی لازم بسازید و از یک کاربر مشترک برای همه دیتابیسها استفاده نکنید.
- دادههای بیمصرف مانند نسخههای پیشین نوشتهها، دیدگاههای اسپم و مقادیر منقضیشده موقت را دورهای پاک کنید.
- حجم دیتابیس و زمان پاسخ کوئریها را زیر نظر بگیرید تا رشد غیرعادی را زود تشخیص دهید.
اگر مطمئن نیستید پروژه شما با دیتابیس روی هاست اشتراکی جواب میدهد یا به سرور مستقل نیاز دارد، پیش از مهاجرت حجم داده و تعداد کوئریهای همزمان را بسنجید یا از مشاوره تخصصی کمک بگیرید؛ انتخاب درست معماری ارزانتر از جابهجاییهای پیدرپی تمام میشود.