Menggunakan basis data hanya untuk penyimpanan data sama dengan memanggil Unix antarmuka untuk bekerja dengan file. Oleh karena itu, saya ingin mengingatkan Anda tentang fungsi basis data yang terkenal dan tidak terlalu ingin saya lihat lebih sering di aplikasi tempur berbasis web.
tl; dr
Di bawah ini adalah tentang otentikasi, pengguna, hak akses, integritas data, PLRT Asing, pencatatan dan statistik. Tidak ada yang baru.
Catatan
- Maksud saya Ruby on Rails dan Postgres, tetapi sebagian besar referensi dapat ditoleransi dengan baik dalam bahasa dan DBMS lainnya.
- Saya tidak akan mengatakan sesuatu yang baru, semua ini telah lama dijelaskan dalam dokumentasi dan artikel. Saya hanya ingin mengingatkan sekali lagi tentang alat dan di mana mereka dapat diterapkan untuk membuat hidup sedikit lebih baik.
Otentikasi rekan / identifikasi
Hal yang benar-benar sehat, yang hampir tidak ada yang menggunakan. Ini memetakan pengguna Unix ke pengguna basis data. Dalam kasus pertama, pengguna lokal dipetakan, dan yang kedua, pengguna jarak jauh. Keuntungannya adalah Anda dapat membuang host, nama pengguna dan kata sandi dari konfigurasi (dan nama database juga dapat dibuang), tetapi semuanya akan berfungsi seperti sebelumnya. Plus, akan lebih mudah untuk masuk ke konsol untuk debugging langsung (hanya psql dari terminal bukan semua -h -U -W -d dan sebagainya).
Dokumentasi PG tentang rekan dan identitas .
Nuansa: cocok jika Anda tidak hanya melakukan root dan superuser di server; dan dalam kasus ident, Anda mengontrol jaringan, perangkat keras dan yakin bahwa tidak ada penyusup dan penyabot.
Contoh Penggunaan
Keamanan Anda tidak dapat menghapus kata sandi dari basis data dan menghubungkannya dari lingkungan lokal atau dari tempat lain. Tidak ada kata sandi dan tidak ada yang perlu diseret.
Kontrol akses. Jika ada beberapa peran akses ke produksi atau server lain dan mereka sudah dibagi di tingkat unix, maka akan lebih mudah untuk mengikat pengguna database kepada mereka. Dalam hal ini, basis kode yang sama akan terhubung di bawah pengguna basis data yang berbeda. Sebagai contoh, dukungan teknis dan pengembang naik ke konsol rel yang sama, tetapi untuk beberapa itu dibaca saja, dan untuk yang kedua penuh.
Hak akses
Di Unix, semua orang berpikir tentang mereka dan mereka terlihat sangat condong untuk bekerja dari root atau di 'chmod 777' . Namun dalam database semuanya berbeda. Pengguna super dan pergi. Meskipun semuanya ada tidak kurang (dan mungkin bahkan lebih) keren.
Ada hierarki peran peran (agak mirip grup di Unix), ada akses dari berbagai tingkatan: ke objek tertentu (seperti izin file), ke operator tertentu (seperti aturan dalam sudoers ), bahkan ke baris tertentu . Singkatnya, semuanya ada di sana. Gunakan itu.
Area Aplikasi
Dalam versi minimum, bersama dengan rekan / identitas di atas, Anda dapat memisahkan pengguna untuk migrasi / penyebaran dan pengguna untuk operasi harian aplikasi. Ini, setidaknya, akan melindungi terhadap panggilan DDL saat runtime. Tentu saja, ada banyak kasus memodifikasi struktur basis data "saat panas". Ini adalah penerapan nol-downtime, dan berbagai perbaikan terbaru, dan pembangunan kembali indeks dengan persetujuan (dan kadang-kadang tanpa). Tetapi, secara umum, aplikasi DDL seharusnya tidak.
Pilihan lain: jika Anda memiliki "microservices", tetapi karena alasan tertentu, mereka menggunakan database yang sama, maka dengan jelas berbagi akses ke objek database adalah ide yang sangat bagus. Memang, antarmuka interaksi harus dilokalkan mungkin, dan akses anarkis ke semua data berkontribusi pada erosi logika dan tanggung jawab.
Kendala integritas
Di Rails 5, setidaknya entah bagaimana, pekerjaan dimulai dengan referensi dan integritas data. Tetapi, dalam kasus umum, banyak pengembang percaya bahwa validasi dalam model atau lingkungannya sudah cukup untuk menjaga status data yang konsisten. Sayangnya, ini sama sekali tidak benar.
Validasi dapat dilewati, Anda dapat langsung ke database dan menjalankan sql, Anda dapat membersihkan selama migrasi. Secara umum, banyak yang bisa dilakukan. Karena itu, segala sesuatu yang bergantung pada logika bisnis harus dipaku oleh database. Ini adalah satu-satunya cara untuk menjaga integritas data dan tidak mendapatkan "kejutan" pada penyebaran berikutnya.
Pembungkus data asing
Ini adalah tentang menghubungkan satu database ke database lain untuk mengakses tabel remote sebagai milik mereka. Keuntungan utama adalah bahwa aplikasi web tidak berpartisipasi dengan cara apa pun, tetapi ada banyak optimisasi ketika dua database identik bekerja (secara umum, pushdown adalah untuk adapter yang berbeda, tetapi semuanya rumit di sana, sehingga lebih mudah untuk mengasumsikan bahwa bundel PG-PG bekerja dengan baik, dan yang lainnya - bagaimana kelanjutannya).
Menggunakan FDW
Alih-alih mengkonfigurasi dengan koordinat beberapa database dalam aplikasi web, jauh lebih mudah untuk meninggalkan satu koneksi ke database dan mengelola semuanya di level database. Di sana, dengan sendirinya, masalah hak akses dan pilihan objek yang memerlukan akses akan diselesaikan.
Plus, di masa depan, Anda dapat mengganti tabel eksternal dengan tampilan yang terwujud atau hanya sebuah tabel, tetapi jangan ubah apa pun di aplikasi web.
Namun, Anda dapat terhubung ke tipe eksotis MS Access dan masalah dengan pembatasan penggunaan relasi dalam model menghilang. Lagi pula, jika Anda memiliki 2+ koneksi, maka Anda tidak akan melakukan penggabungan dua pangkalan di tingkat aplikasi web, meskipun ORM (khususnya, ActiveRecord) akan dengan jujur mencoba melakukan ini ... dan akan jatuh. Dan pada tingkat basis data, ini dapat dilakukan, dalam beberapa kasus, hampir tanpa overhead.
Penebangan
Hampir semua orang tahu tentang dia dan menggunakan segalanya. Tapi untuk jaga-jaga, izinkan saya mengingatkan Anda: jangan ragu untuk mencatat permintaan panjang. Di luar kotak, di PG, tidak aktif. Perlu menyodok log_min_duration_statement . Mengenai artinya, ada banyak holivar dan, mungkin, mereka gagap, tetapi untuk awalnya, luangkan beberapa detik. Karena jika Anda memiliki aplikasi besar, Anda tidak akan membacanya dan Anda sendiri tahu apa yang harus dilakukan, tetapi jika kecil, maka Anda tidak punya waktu untuk menangani rem kecil dan hanya hal-hal fatal yang mengganggu Anda.
Ingat juga tentang N +1. Basis data tidak akan mengatakan apa-apa tentang itu. Gunakan alat pihak ketiga. Misalnya, peluru dan akal sehat.
Statistik
Harus diingat bahwa itu dan itu bisa bau. Pada awalnya, semuanya baik-baik saja. Namun seiring waktu, biasanya, hasil berikut: laju perubahan data kira-kira sama, dan ukuran tabel lebih besar. Akibatnya, tabel vakum / analisis mulai terjadi lebih jarang dan pada beberapa titik penjadwal mulai ketinggalan. Dalam kasus terbaik, permintaan masuk ke pencatatan di atas, dalam kondisi terburuk - Anda hanya menderita dan tidak mengerti mengapa. Secara umum, lihat pg_stat_user_tables dan pg_stat_user_tables tanggal vakum / analisis dengan beban pada tabel.
Dan terkadang Anda dapat menggunakan statistik untuk perkiraan perkiraan. Ini sangat berguna, tetapi cukup tepat, karena PG bukan Oracle dan count seluruh tabel tidak dilakukan di O (1), meskipun saya benar-benar ingin.
Akhirnya
Terima kasih sudah membaca. Jika tidak sulit, jawab pertanyaan di bawah ini. Mengingat artikel baru-baru ini tentang GQL, bukannya SQL, itu mulai banyak mengganggu saya.