Tidak ada jawaban sederhana untuk pertanyaan Anda, tetapi di sini ada beberapa hal untuk dipikirkan.
Pertama, skala bukanlah satu-satunya hal yang perlu dikhawatirkan. Apa yang Anda lakukan dengan data Anda. Jika Anda memiliki 500 tabel 30 TB data, dan Anda melakukan OLTP sederhana dengan pelaporan yang sangat sedikit, saya tidak berpikir Anda akan memiliki terlalu banyak masalah. Ada database 32TB di PostgreSQL di luar sana. Namun, pada saat yang sama kinerja akan agak menurun karena harus menabrak disk pada segalanya. Demikian pula jika Anda memiliki 50TB jika data tetapi memiliki set yang biasanya mencapai sekitar 100GB, maka Anda dapat membangun server dengan RAM yang cukup untuk menjaga bagian db dalam memori dan Anda berwarna emas.
Di sisi lain jika Anda mencoba untuk mengambil mode (nilai paling umum) dari 1TB data, tidak masalah sistem apa yang Anda gunakan, ini akan terasa menyakitkan dengan atau tanpa sharding. (Sunting: Sharding mungkin malah memperburuk masalah ini . )
Masalah utama yang akan Anda hadapi dengan db besar di MySQL dan PostgreSQL melibatkan fakta bahwa tidak ada yang mendukung paralelisme intraquery. Dengan kata lain, kueri dijalankan sebagai satu blok oleh satu utas, dan tidak dapat dipecah menjadi beberapa bagian dan dijalankan secara terpisah. Ini paling sering menjadi masalah ketika menjalankan kueri analitik besar atas sejumlah besar data. Di sinilah Postgres-XC dan Green Plum datang untuk menyelamatkan karena mereka memisahkan penyimpanan dari eksekusi, dan dapat melakukan ini di tingkat koordinator. Perhatikan bahwa Postgres-XC dan Green Plum pada dasarnya menggunakan sharding secara internal tetapi koordinator menegakkan semua konsistensi secara global.
Dengan paralelisme intraquery, Anda dapat memecah kueri, memiliki prosesor yang berbeda / saluran I / O disk menjalankan bagian dari itu, dan melaporkan kembali potongan-potongan hasil yang ditetapkan untuk dirakit dan dikembalikan ke aplikasi. Sekali lagi, ini biasanya paling membantu dalam analitik daripada beban pemrosesan transaksi.
Hal kedua adalah bahwa beberapa sistem, seperti Vertica atau Greenplum, menyimpan kolom informasi bersama. Ini membuat sistem lebih sulit untuk digunakan dari perspektif OLTP dan menurunkan kinerja di sana, tetapi secara drastis meningkatkan kinerja untuk beban kerja analitik yang besar. Jadi ini adalah tradeoff khusus beban kerja.
Jadi jawabannya adalah begitu Anda mendapatkan ukuran di atas 1-2 TB, Anda mungkin menemukan diri Anda dihadapkan dengan sejumlah pertukaran antara sistem dan beban kerja. Sekali lagi ini khusus untuk database, ukuran set kerja, dll. Namun pada titik ini Anda benar-benar harus pergi dengan sistem kepingan salju, yaitu yang unik dan disesuaikan dengan beban kerja Anda.
Ini tentu saja berarti bahwa batas umumnya tidak dapat diukur.
Sunting : Saya sekarang telah bekerja dengan basis data 9TB yang menangani campuran dukungan keputusan dan beban kerja pemrosesan transaksional dalam PostgreSQL. Tantangan tunggal terbesar adalah bahwa jika Anda memiliki pertanyaan yang mengenai sebagian besar kumpulan data, Anda harus menunggu beberapa saat untuk jawabannya.
Namun dengan perhatian yang hati-hati pada fundamental (termasuk indeks, autovacuum, bagaimana ini bekerja pada level rendah, dll) dan sumber daya komputasi yang memadai, ini sepenuhnya dapat dikelola (dan saya perkirakan akan dapat dikelola dengan baik hingga kisaran 30TB dalam Pg).
Sunting2 : Setelah Anda menuju 100TB meskipun apa yang berhasil akan tergantung pada set data Anda. Saya sedang mengerjakan satu sekarang yang tidak akan skala ke kisaran ini karena akan mencapai batas 32TB per tabel di PostgreSQL terlebih dahulu.
