Database

Di mana situs menjadi cepat atau lambat: di database-nya.

Kami memasang, menyetel, mereplikasi, dan mencadangkan database di balik aplikasi Anda, dan kami membuktikan cadangannya dengan memulihkannya.

Minta penawaran Lihat paket hosting

Tujuh mesin, digambar sebagai satu skema

Setiap kotak adalah database yang kami pasang, setel, dan cadangkan. Garis-garisnya menunjukkan cara mereka bekerja sama dalam sistem yang kami jalankan - sebagian besar aplikasi membutuhkan dua atau tiga, bukan satu.

SQLitetertanam
Untuk
Aplikasi dan alat dengan satu file data dan satu penulis dalam satu waktu
Kami setel
journal_mode=WAL
Cadangan
Salinan online dari file, tidak pernah salinan file yang sedang dipakai
MySQLrelasional
Untuk
Toko, WordPress, dan sebagian besar aplikasi PHP
Kami setel
innodb_buffer_pool_size
Cadangan
Cadangan penuh ditambah binary log, ke titik waktu mana pun
Mengapa kami menjalankan MySQL
Redisdi memori
Untuk
Cache, sesi, antrean, dan penghitung
Kami setel
maxmemory-policy
Cadangan
Snapshot dan file append-only
PostgreSQLrelasional
Untuk
Akuntansi, ERP, laporan, dan query kompleks
Kami setel
shared_buffers · work_mem
Cadangan
Cadangan dasar ditambah WAL yang diarsipkan, ke titik waktu mana pun
MariaDBrelasional
Untuk
Pekerjaan yang sama dengan MySQL, ditambah cluster Galera
Kami setel
innodb_buffer_pool_size
Cadangan
mariabackup ditambah binary log, ke titik waktu mana pun
OpenSearch · Elasticsearchpencarian
Untuk
Pencarian di seluruh produk dan artikel, filter, log
Kami setel
JVM heap · shards
Cadangan
Snapshot; indeks dapat dibangun ulang dari database utama
MongoDBdokumen
Untuk
Data yang bentuknya terus berubah: event, katalog, konten
Kami setel
wiredTiger cacheSizeGB
Cadangan
Replica set, dengan oplog untuk titik waktu tertentu
  1. Ketika aplikasi sudah terlalu besar untuk satu file, ia pindah ke server database.
  2. MariaDB berawal sebagai fork dari MySQL; sebagian besar aplikasi bisa berpindah di antara keduanya tanpa perubahan.
  3. Redis berada di depan: jawaban berulang dan sesi tetap di memori.
  4. Cache yang sama di depan aplikasi PostgreSQL.
  5. Indeks pencarian diisi dari database utama, tidak pernah sebaliknya.
  6. JSONB di PostgreSQL menangani banyak pekerjaan dokumen sebelum MongoDB dibutuhkan.

Database mana untuk pekerjaan apa

Biasanya aplikasi yang menentukan, dan kami mengikutinya. Jika pilihannya terbuka, beginilah cara kami memilih.

Pekerjaan Pilihan pertama kami Juga bisa Alasan
Toko, situs WordPress, atau aplikasi PHP MySQL · MariaDB PostgreSQL Tempat aplikasi dibangun dan diuji, dengan dukungan paling luas.
Akuntansi, ERP, dan laporan dengan banyak join PostgreSQL MySQL 8 Transaksi yang ketat, window function, dan planner yang dibuat untuk query kompleks.
Cache, sesi, antrean, dan pembatasan laju Redis Memcached Jawaban dari memori. Simpan di sana hanya yang bisa dibangun ulang jika hilang.
Pencarian di seluruh produk atau artikel OpenSearch · Elasticsearch MySQL · PostgreSQL full-text Relevansi, salah ketik, filter, dan facet yang tidak bisa diberikan query LIKE. Untuk katalog kecil, pencarian full-text bawaan database sudah cukup.
Aplikasi mobile, alat desktop, atau layanan internal kecil SQLite —Tidak ada yang lain Tanpa server yang perlu dijalankan: satu file, dicadangkan dengan menyalinnya secara aman.
Event, log, atau data yang bentuknya terus berubah MongoDB PostgreSQL JSONB Dokumen yang fleksibel; PostgreSQL bila juga membutuhkan join dan transaksi.
Beban baca yang melampaui satu server MySQL · MariaDB · PostgreSQL replicas —Tidak ada yang lain Beban baca disebar ke replika sementara penulisan tetap di satu server utama.

Satu query lambat, ditemukan dan diperbaiki

Sebagian besar halaman lambat disebabkan satu query. Slow query log menyebutkannya, EXPLAIN menunjukkan mengapa ia lambat, dan satu indeks sering kali menjadi seluruh perbaikannya.

SELECT id, total, created_at
FROM orders
WHERE customer_id = 4821
ORDER BY created_at DESC
LIMIT 20;
Contoh query pada contoh tabel

Sebelum

type
ALL
key
NULL
Extra
Using where; Using filesort

Membaca setiap baris tabel, lalu mengurutkan yang ditemukan.

Perbaikannya: satu indeks

ALTER TABLE orders
  ADD INDEX idx_customer_created (customer_id, created_at);

Sesudah

type
ref
key
idx_customer_created
Extra
Backward index scan

Hanya membaca baris milik pelanggan ini, sudah berurutan.

Cadangan baru berarti setelah dipulihkan

Salinan malam saja akan kehilangan satu hari. Dengan menyimpan juga log perubahan, kami dapat mengembalikan database ke detik sebelum sebuah kesalahan.

Cadangan penuh setiap malam00:00 Dipulihkan sampai sini14:31:59 DELETE tanpa WHERE14:32:00
Setiap perubahan, ditulis ke log saat terjadi Diputar ulang ke atas cadangan
Contoh satu hari. Jam-jamnya rekaan.
  1. Pulihkan cadangan penuh terakhir

    Di server terpisah, sehingga database produksi tetap seperti apa adanya selama kami bekerja.

  2. Putar ulang log sampai sesaat sebelumnya

    Binary log untuk MySQL dan MariaDB, WAL yang diarsipkan untuk PostgreSQL, oplog untuk MongoDB.

  3. Periksa, lalu kembalikan datanya

    Baris yang hilang disalin kembali, atau salinan yang dipulihkan mengambil alih - keputusan ada di tangan Anda, dengan perbedaannya di depan mata.

Pemulihan ke titik waktu tertentu bergantung pada mesinnya:

  • MySQL · MariaDB · PostgreSQL · MongoDBke detik mana pun yang dicakup log
  • Redissampai penulisan terakhir di file append-only
  • SQLitesampai salinan terakhir file
  • OpenSearch · Elasticsearchsampai snapshot terakhir, lalu dibangun ulang dari sumbernya

Uji pemulihan adalah bagian dari perawatan yang kami sepakati dengan Anda: ke server terpisah, dengan jadwal tetap, dan setiap hasilnya dicatat. Cadangan yang belum pernah dipulihkan hanyalah harapan, bukan cadangan.

Pekerjaan lainnya

Apa yang dibutuhkan database sejak hari dipasang hingga hari di-upgrade, dan pengaturan yang disentuh setiap langkah.

  • Pemasangan dan penentuan ukuran

    Versi yang didukung aplikasi Anda, dari repositori resmi vendornya. Memori dibagi antara database, aplikasi, dan sistem sebelum hal lain diatur.

    innodb_buffer_pool_size · shared_buffers · maxmemory · -Xmx
  • Indeks dan query lambat

    Slow query log dibaca, query terburuk dijelaskan, dan indeks ditambah atau dihapus dengan alasan yang dicatat.

    slow_query_log · pg_stat_statements · EXPLAIN ANALYZE
  • Replikasi

    Salinan kedua yang mengikuti yang pertama, untuk menyebarkan beban baca dan mengambil alih saat server utama gagal.

    GTID · Galera · streaming replication · replica set
  • Keamanan

    Hanya mendengarkan di jaringan privat, satu pengguna per aplikasi dengan hak yang dibutuhkannya saja, dan koneksi terenkripsi di mana pun lalu lintas keluar dari server.

    bind-address · TLS · GRANT · SCRAM · ACL
  • Pemantauan

    Koneksi, jeda replikasi, ruang disk, dan query lambat, dengan peringatan sebelum batas tercapai, bukan sesudahnya.

    max_connections · Seconds_Behind_Source · pg_stat_replication
  • Upgrade

    Dilatih dulu pada salinan, replika sebelum server utama, dan jalan kembali ditulis sebelum kami mulai.

    pg_upgrade · mariadb-upgrade · rolling restart

Ceritakan apa yang sedang dilakukan database Anda

Mesin apa, seberapa besar, di mana berjalan, dan apa yang Anda khawatirkan. Kami melihatnya dulu, lalu memberi penawaran pemasangan atau perawatan setelah satu percakapan.

Minta penawaran Lihat paket hosting