Bagaimana melakukan penyatuan koneksi
Setiap platform memiliki antarmuka penyatuan koneksi yang berbeda. Anda harus membaca dokumentasi untuk platform spesifik yang Anda gunakan (Ruby+Rails atau apa pun), atau menggunakan lapisan tengah gabungan umum seperti PgBouncer.
Jawaban yang berkaitan dengan satu alat (misalnya, PHP dengan Zend Framework) tidak akan ada hubungannya dengan jawaban yang berkaitan dengan alat lain (seperti Ruby on Rails). Bahkan jika Anda memilih sesuatu seperti PgBouncer, masih ada detail terkait cara platform menangani masa pakai transaksi, mode pengumpulan untuk dipilih berdasarkan kebutuhan aplikasi, dll.
Jadi, Anda harus terlebih dahulu menentukan apa yang Anda gunakan dan apa yang perlu Anda lakukan dengannya. Lalu pelajari cara mengatur penyatuan koneksinya. (Dengan banyak alat itu hanya otomatis).
Jika Anda masih buntu setelah membaca dokumentasi untuk platform yang Anda pilih , tanyakan detail dan spesifik baru pertanyaan yang diberi tag dengan tepat untuk platform.
Penggabungan dan middleware
Jangan biarkan aplikasi Anda terhubung langsung ke PostgreSQL. Terutama jika melalui Internet dari klien acak.
Gunakan server web di dekat server PostgreSQL dan minta agar server menerima permintaan layanan web untuk memperantarai akses ke database melalui API web yang terdefinisi dengan baik dengan transaksi singkat yang dicakup untuk meminta sebanyak mungkin.
Ini bukan hanya kasus kebijaksanaan yang diterima - ada alasan bagus untuk melakukannya, dan masalah serius dengan menjalankan PostgreSQL dari perangkat acak melalui Internet.
Aplikasi Android berbicara langsung ke Pg
Masalah saat berbicara dengan Pg langsung melalui Internet dari banyak klien meliputi:
-
Setiap backend PostgreSQL memiliki biaya, baik idle atau tidak. PgBouncer dalam mode pengumpulan transaksi membantu dalam beberapa hal.
-
Koneksi terputus secara acak saat Anda bekerja melalui Internet. WiFi turun, perubahan alamat IP pada layanan IP dinamis, layanan seluler yang memudar atau kehabisan kapasitas atau hanya terhuyung-huyung seiring dengan kehilangan paket yang tinggi di sana. Ini membuat Anda memiliki banyak koneksi PostgreSQL dalam status tak tentu, mungkin dengan transaksi terbuka, memberi Anda
<IDLE> in transactionmasalah dan kebutuhan untuk mengizinkan lebih banyak koneksi daripada yang benar-benar berfungsi. -
Ini transaksional - jika sesuatu tidak selesai, Anda dapat menghentikan transaksi dan tahu itu tidak akan berpengaruh.
Keuntungan memiliki lapisan tengah
Server yang menanggapi permintaan layanan web HTTP dari aplikasi Anda di perangkat Android untuk bertindak sebagai perantara untuk akses database bisa menjadi keuntungan besar.
-
Anda dapat menentukan API berversi, jadi saat Anda memperkenalkan fitur baru atau perlu mengubah API, Anda tidak perlu merusak klien lama. Ini dimungkinkan dengan Pg menggunakan prosedur tersimpan atau banyak tampilan tetapi bisa menjadi kikuk.
-
Anda secara ketat mengontrol cakupan akses database dan masa berlaku transaksi.
-
Anda dapat menentukan API idempoten, di mana menjalankan permintaan yang sama beberapa kali hanya memiliki satu efek. (Saya sangat menyarankan melakukan ini karena poin berikutnya).
-
Semuanya tanpa kewarganegaraan dan dapat memiliki time-out yang singkat. Jika sesuatu tidak berhasil, Anda hanya perlu mencobanya lagi.
-
Setiap koneksi database berjalan melalui kumpulan, jadi Anda tidak memiliki sesi menganggur. Setiap backend database bekerja keras untuk throughput maksimum.
-
Anda dapat mengantri pekerjaan daripada mencoba melakukan banyak hal secara bersamaan dan meronta-ronta server. (Anda juga dapat melakukannya dengan PgBouncer dalam mode pengumpulan transaksi).
... dan ulangi suntingan Anda untuk mengubah arti pertanyaan:
Kinerja
Performa "Juga" Anda benar-benar merupakan pertanyaan yang sama sekali berbeda (dan sebaiknya diposting seperti itu). Versi yang sangat singkat:sama sekali tidak mungkin untuk diprediksi tanpa lebih banyak info tentang beban kerja, seperti jumlah permintaan db per permintaan aplikasi klien, jenis data, jenis kueri, ukuran data, frekuensi kueri, kepraktisan caching, .. .... tanpa henti. Siapa pun yang mengklaim dapat menjawab pertanyaan itu secara pasti adalah paranormal sejati pertama dalam sejarah atau benar-benar penuh.
Anda perlu mencari tahu kira-kira seperti apa ukuran data Anda, pola kueri, dll. Cari tahu seberapa banyak Anda mampu untuk men-cache di cache midlayer seperti redis/memcached, seberapa basi Anda bisa membiarkannya, tingkat pembatalan cache apa yang Anda butuhkan. Tentukan apakah dataset "panas" Anda (yang banyak Anda akses) akan muat di RAM atau tidak. Tentukan apakah indeks untuk tabel yang sering ditanyakan akan sesuai dengan RAM atau tidak. Cari tahu apa keseimbangan baca/tulis kasar Anda dan berapa banyak tulisan Anda yang cenderung hanya disisipkan (tambahkan) atau OLTP yang lebih teratur (masukkan/perbarui/hapus). Buat kumpulan data dan beberapa beban kerja klien. Lalu Anda dapat mulai menjawab pertanyaan itu - mungkin. Untuk melakukannya dengan benar, Anda juga harus mensimulasikan klien yang terhenti/hilang, dll.
Lihat mengapa ini bukan hanya "Juga?".
