Seberapa besar terlalu besar untuk tabel PostgreSQL?

127

Saya sedang mengerjakan desain untuk proyek RoR untuk perusahaan saya, dan tim pengembangan kami telah mengalami sedikit perdebatan tentang desain, khususnya database.

Kami memiliki model yang disebut Messageyang perlu dipertahankan. Ini adalah model yang sangat, sangat kecil dengan hanya tiga kolom db selain id, namun kemungkinan akan ada BANYAK model ini saat kita pergi ke produksi. Kami melihat sebanyak 1.000.000 penyisipan per hari. Model hanya akan dicari oleh dua kunci asing yang dapat diindeks. Selain itu, model tidak perlu dihapus, tetapi kami juga tidak harus menyimpannya setelah berusia sekitar tiga bulan.

Jadi, yang kami ingin tahu adalah apakah menerapkan tabel ini di Postgres akan menghadirkan masalah kinerja yang signifikan? Apakah ada yang punya pengalaman dengan database SQL yang sangat besar untuk memberi tahu kami apakah ini akan menjadi masalah atau tidak? Dan jika ya, alternatif apa yang harus kita gunakan?

— Dylan Karr
sumber

dengan lapisan caching yang baik dan beberapa konfigurasi kecil di PG Anda akan baik-baik saja. Anda harus menangani masalah kinerja kasus per kasus dan menghindari pengoptimalan sebelumnya. Meskipun demikian, mempartisi dan mereplikasi selalu merupakan pilihan bagus yang dapat Anda manfaatkan begitu Anda mencapai kemacetan.

— Sam

Pertanyaan terkait disini dan disini .

— Erwin Brandstetter

Kami memproses sekitar 30 juta pesan per hari dalam satu database PostgreSQL 5+ TB, berfungsi dengan baik.

— Frank Heik

lihat juga stackoverflow.com/questions/3132444/…

— rogerdpack

FYI, saya kebetulan membaca postgresql.org/about hari ini dan memperhatikan bahwa (pada prinsipnya) jumlah baris dalam tabel tidak terbatas.

— Al Chou

Jawaban:

115

Baris per tabel tidak akan menjadi masalah itu sendiri.

Jadi secara kasar, 1 juta baris sehari selama 90 hari sama dengan 90 juta baris. Saya tidak melihat alasan Postgres tidak dapat menangani itu, tanpa mengetahui semua detail dari apa yang Anda lakukan.

Bergantung pada distribusi data Anda, Anda dapat menggunakan campuran indeks, indeks yang difilter, dan beberapa jenis tabel partisi untuk mempercepat setelah Anda melihat masalah kinerja apa yang mungkin Anda miliki atau tidak. Masalah Anda akan sama di RDMS lain yang saya ketahui. Jika Anda hanya membutuhkan desain data selama 3 bulan dalam proses untuk memangkas data, Anda tidak memerlukannya lagi. Dengan begitu Anda akan memiliki volume data yang konsisten di atas tabel. Keberuntungan Anda, Anda tahu berapa banyak data yang akan ada, uji volume Anda dan lihat apa yang Anda dapatkan. Menguji satu tabel dengan 90 juta baris semudah:

select x,1 as c2,2 as c3
from generate_series(1,90000000) x;

https://wiki.postgresql.org/wiki/FAQ

Limit   Value
Maximum Database Size       Unlimited
Maximum Table Size          32 TB
Maximum Row Size            1.6 TB
Maximum Field Size          1 GB
Maximum Rows per Table      Unlimited
Maximum Columns per Table   250 - 1600 depending on column types
Maximum Indexes per Table   Unlimited

— Kuberchaun
sumber

Saya setuju bahwa 90 juta baris tidak akan menjadi masalah bagi PostgreSQL. Tapi itu mungkin menjadi masalah bagi ORM dengan PostgreSQL. (Sebenarnya ORM dengan dbms apa pun.)

— Mike Sherrill 'Cat Recall'

@ MikeSherrill'Catcall 'Poin yang bagus, saya hanya fokus pada "Seberapa besar terlalu besar untuk tabel PostgreSQL?"

— Kuberchaun

@yeyo: Karena ORM biasanya menggunakan banyak kueri untuk mendapatkan data yang dapat dikembalikan hanya dengan satu atau dua. OP menggunakan Ruby on Rails.

— Mike Sherrill 'Cat Recall'

Ini agak terlambat tetapi saya pikir dalam banyak kasus (terutama dengan rel / rekaman aktif) adalah umum untuk sepenuhnya menghapus ORM dari persamaan dan menulis string sql mentah untuk menanyakan alasan kinerja. Jangan biarkan ORM Anda membuat keputusan data untuk Anda! Ini aksesori bukan yang penting.

— Stefan Theard

Tentang URL yang dikutip dalam URL tidak menunjukkan batasan ini saat ini - ada yang tahu ke mana itu dipindahkan?

— Dicukur

Cara lain untuk mempercepat kueri Anda secara signifikan pada tabel dengan> 100 juta baris adalah di kluster di luar jam kerja, tabel pada indeks yang paling sering digunakan dalam kueri Anda. Kami memiliki tabel dengan> 218 juta baris dan telah menemukan 30X peningkatan.

Selain itu, untuk tabel yang sangat besar, sebaiknya buat indeks pada kunci asing Anda.

— James Doherty
sumber

> di kelompok jam tidak aktif tabel pada indeks yang paling sering digunakan dalam kueri Anda .... dapatkah Anda menjelaskan bagaimana hal ini dilakukan?

— mata

Ya di sini adalah langkah demi langkah CONTOH: 1) Tabel yang saya maksud dalam contoh ini disebut investasi. 2) Indeks yang paling banyak digunakan dalam kueri adalah (bankid, record_date) Jadi, inilah langkah demi langkah Anda: 1) psql -c "drop index investment_bankid_rec_dt_idx;" dbname 2) psql -c "buat indeks investment_bankid_rec_dt_idx pada investasi (bankid, record_date);" 3) psql -c "cluster investment_bankid_rec_dt_idx pada investasi;" 4) vacuumdb -d ccbank -z -v -t investment Jadi pada langkah pertama dan kedua kita menjatuhkan indeks dan membuatnya kembali.

— James Doherty

Langkah 3 kita membuat cluster, ini pada dasarnya menempatkan tabel DB dalam urutan fisik indeks, jadi ketika postgresql melakukan query, ia menyimpan baris berikutnya yang paling mungkin. Langkah 4 kita vakum database untuk mengatur ulang statistik untuk perencana permintaan

— James Doherty