Database 100 terabyte pada PostgreSQL tanpa sharding


9

Apakah realistis untuk mengatur basis data 100 TB (sekitar 90 TB sebenarnya) pada PostgreSQL tanpa data sharding antara sejumlah node? Adakah kisah sukses / contoh tentang pemasangan serupa?


4
Saya membayangkan itu tergantung pada beban kerja Anda. Bagaimana data didistribusikan, dan bagaimana akan ditanyai? Jenis waktu respons seperti apa yang Anda butuhkan?
Frank Farmer

Nah, profil pemuatan dapat digambarkan sebagai sisipan yang sering (sekitar 50K per detik saat puncak), relatif jarang dipilih (rentang baris menurut pengguna dan stempel waktu). Data dapat dengan mudah dikosongkan / dipartisi oleh pengguna dan tanggal / timestamp

Jawaban:


9

50K menulis per detik yang perlu diserap lebih dari tantangan biasanya. Bahkan dalam tolok ukur sintetis dengan sisipan yang cukup sederhana, batas PostgreSQL cenderung mencapai sekitar 10 K / s - dan di sana Anda bahkan tidak memiliki binatang sebesar itu dalam hal ukuran basis data.

Juga sistem I / O untuk node PostgreSQL tunggal akan menarik karena bahkan dengan RAID 10 dan dengan asumsi bahwa insersi 50K akan sama dengan hanya 50K IOPS (yang mungkin salah, tetapi tergantung pada skema dan indeks basis data Anda ), Anda akan membutuhkan kira-kira seratus disk yang dipasangkan dengan array yang sangat baik yang menyelamatkan Anda dari membeli beberapa ratus disk untuk melayani penulisan yang tepat waktu.

Jika sharding itu mudah dan Anda mengharapkan beban tulis yang begitu besar maka pergilah untuk sharding. Menulis bisa sangat sulit untuk diukur.


Setuju. Ini adalah domain dari sistem tipe ExaData. Yang menyedihkan, mendapatkan IOPS 50k cukup sepele akhir-akhir ini dengan SSD - otoh ini akan menjadi mahal. Saya akan mengharapkan anggaran 7 digit yang lebih besar di sini untuk perangkat keras, termasuk kisaran menengah ke SAN kelas atas.
TomTom

Ya, ExaData adalah pilihan jika Anda ingin pergi "tumpukan solusi terintegrasi secara vertikal" yang mungkin tidak terlalu buruk mengingat tuntutan.
pfo

Ya. Ada keuntungan serius untuk hal seperti itu, keduanya, 100TB dan 50.000 IOPS tidak benar-benar berteriak "murah" ´. Exadata melakukan apa - 1 juta IOPS saat penuh dengan SSD?
TomTom

2
Untuk menambah komentar ini, saya pikir mengingat anggaran yang diperlukan untuk mendapatkan volume data dengan volume sisipan itu, saya akan tergoda untuk menggunakan mesin SQL berbayar, itu akan menjadi persentase kecil dari keseluruhan anggaran dan Anda akan mendapat dukungan yang jauh lebih baik.
Chopper3

Saya sangat setuju. Saat anggaran Anda untuk SAN mencapai beberapa ratus ribu banyak perubahan penilaian.
TomTom

1

Itu realistis dan akan berhasil. Kinerja lebih besar tergantung pada berapa banyak RAM yang Anda miliki. Semakin besar RAM, semakin besar cache, dan semakin lama PostgreSQL dapat men-cache data sebelum membongkar ke disk.

PostgreSQL akan menulis data ke cache, dan melepaskan cache dari waktu ke waktu. Jadi 50k INSERTs per detik tidak akan diterjemahkan ke 50k IOPS. Ini akan menjadi jauh lebih sedikit, karena itu akan mengelompokkan catatan bersama dan menulis semuanya sekaligus.

Basis data yang besar tidak menjadi masalah jika mayoritas pekerjaannya adalah INSERT. PostgreSQL harus mengubah indeks di sana-sini, tapi itu pekerjaan yang sangat mudah. Jika Anda memiliki banyak SELECT pada basis data ukuran ini, Anda benar-benar perlu shard.

Saya pernah bekerja pada Oracle DB (Oracle 10g) dengan 400TB pada server 16GB, satu contoh saja. Beban kerja basis data adalah INSERT utama juga, jadi beberapa SELECT per hari dan jutaan INSERT setiap hari. Kinerja jauh dari masalah.


1

Pada 100TB Anda memiliki beberapa tantangan penting. Apakah itu akan berhasil untuk Anda atau tidak tergantung pada bagaimana Anda ingin mengatasinya.

  1. Anda membutuhkan cara yang cukup untuk menyerap beban tulis. Ini tergantung pada beban tulis. Tetapi dengan penyimpanan yang cukup mengagumkan itu bisa diselesaikan. Kecepatan adalah masalah besar di sini. Akses baca yang sama harus dilihat dengan cermat.

  2. Sebagian besar database tidak terdiri dari banyak tabel bertubuh kecil tetapi sering memiliki satu atau dua yang sangat besar, yang dapat mencapai setengah dari ukuran db. PostgreSQL memiliki batas keras 32TB per tabel. Setelah itu jenis tid kehabisan penghitung halaman. Ini dapat ditangani oleh custom postgreSQL atau dengan tabel partisi tetapi ini merupakan tantangan serius yang perlu diatasi pada awalnya.

  3. PostgreSQL memiliki batasan nyata dalam berapa banyak RAM yang dapat digunakan untuk berbagai tugas. Jadi memiliki lebih banyak RAM mungkin atau mungkin tidak membantu Anda melampaui titik tertentu.

  4. Cadangan .... Cadangan menarik pada skala ini. 60TB db yang saya tahu harus menggunakan fs snapshot backup dan kemudian memalsukan cadangan untuk bartender untuk pengarsipan wal. Backup palsu ini adalah proksi untuk backup snapshot fs. Seperti yang saya katakan, "Itu bukan cadangan palsu. Itu cadangan alternatif!"

Ada orang dengan basis data yang mendekati kisaran ini. Saya telah bertemu setidaknya satu orang yang bekerja untuk sebuah bank di Belanda yang memiliki database PostgreSQL 60TB. Namun itu benar-benar tergantung pada beban kerja Anda dan ukuran dengan sendirinya bukan masalah.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.