Apakah kunci primer 5+ kolom buruk untuk tabel besar (100 juta +)?

Saya membaca tentang beberapa masalah DB kehidupan nyata, dan satu proyek memiliki 100 juta baris plus tabel yang memiliki 5 kolom sebagai utamanya. Saya pikir ini buruk, tetapi adakah yang bisa mengatakan dengan tepat mengapa?

Tabelnya adalah semacam tabel rollup / agregasi mikro, jadi 5 kolomnya seperti (hari, market_id, product_id ...). Pada awalnya saya berpikir bahwa kunci primer 5 kolom tidak ideal, tetapi semakin saya berpikir, saya tidak dapat benar-benar menemukan alasan yang bagus mengapa itu buruk.

Ini adalah diskusi larut malam dengan setengah insinyur perusahaan. Seseorang baru saja mengatakan ini adalah desain yang buruk, seorang insinyur senior setuju, tetapi tidak ada yang benar-benar mengerti mengapa. Jadi mencoba untuk meneliti masalah ini untuk diriku sendiri!

Ada masalah kinerja dengan kunci primer yang sangat kompleks. Dan itu mungkin tidak bertahan terhadap duplikasi serta kunci primer yang lebih sederhana.

Namun, ada satu pola desain yang sering menghasilkan tabel dengan kunci utama yang terdiri dari enam komponen. Ini tabel fakta skema bintang. Jika tabel fakta skema bintang memiliki enam dimensi, maka kunci utama akan memiliki enam komponen. Saya belum pernah melihat tabel fakta tanpa kunci primer yang dideklarasikan, dan saya pikir ini sepadan dengan biaya overhead, meskipun proses ETL masih harus ditulis dengan sangat hati-hati.

Beberapa basis data pelaporan meniru pola skema bintang bahkan jika itu tidak dirancang secara eksplisit seperti itu.

100 juta + baris tidak terlalu besar untuk tabel fakta, terutama dengan data besar saat ini.

Tabel yang dimaksud adalah tabel rollup / agregasi.

Maka itu tidak hanya baik, itu "benar".

Dan baunya seperti tabel Ringkasan, karena dimulai dengan day.

Apakah Anda memiliki beberapa indeks sekunder? Perlu diingat bahwa jika Anda menggunakan InnoDB, sisa kolom PRIMARY KEY akan ditempelkan di akhir indeks sekunder. Sekali lagi, ini tidak selalu menjadi masalah.

Baris 100M banyak untuk rollup. Kedengarannya meja itu terlalu halus. Yaitu, mungkin sebaliknya jika (date, a, b, c, d) Anda harus memiliki 4 rollup dengan PK seperti (date, a, b, c), (date, b, c, d), (date, c, d, a), (tanggal, d, a, b) (atau beberapa kombinasi yang sesuai). Saya melakukan itu, masing-masing mungkin hanya 10M baris, sehingga membuat laporan lebih cepat, sementara memiliki fleksibilitas yang hampir sama dalam laporan.

Atau mungkin beralih ke (minggu, a, b, c, d), yang mengarah ke mungkin hanya 14M baris. (Mungkin lebih.)

Menggunakan PARTISI untuk memfasilitasi pemangkasan --- Penelanan berkecepatan tinggi --- Tips Gudang Data --- Tabel Ringkasan . Ini merangkum banyak teknik yang telah saya kembangkan di beberapa proyek DW. Seperti yang Anda simpulkan, setiap proyek berbeda. Jumlah 'Ringkasan' Tabel Ringkasan (menurut pengalaman saya) adalah 3-7. Target dalam peringkasan adalah 10 baris Fakta -> 1 baris Ringkasan. (Itu mungkin 'median'.) Dalam kasus yang jarang terjadi, saya merangkum tabel Ringkasan. Dalam kasus langka lainnya, saya PARTITIONed tabel Ringkasan untuk efek yang baik; biasanya tabel ringkasan cukup kecil sehingga cukup cepat untuk akses langsung dari UI.

Yah, sebenarnya memiliki PK dengan 5+ kolom tidak selalu buruk dengan sendirinya.

Menjadi buruk setelah PK juga indeks berkerumun karena orang akan dihitung sebagai pengidentifikasi baris dan dengan demikian akan ditambahkan ke setiap baris dalam indeks NC. Ini secara drastis akan menambah ruang yang dibutuhkan.

Ini juga akan menjadi buruk setelah Anda benar-benar menggunakan PK oleh FK lain, karena Anda harus memiliki data semua 5+ kolom di tabel saat ini dan juga dari referensi. Sekali lagi ini akan meningkatkan penyimpanan banyak!

Dari segi kinerja, ini akan menjadi buruk setelah PK digunakan sebagai indeks - biarkan hanya di dalam tabel atau bersama dengan FK - karena PK-Key yang lebih besar berisi 5 kolom akan mengambil lebih banyak ruang, sehingga lebih sedikit entri akan muat dalam satu halaman dan selanjutnya lebih banyak halaman harus dibaca untuk menganalisis indeks.

Yang mengatakan - mungkin selalu ada alasan bagus untuk benar-benar melakukannya, seperti misalnya tabel fakta. Oleh karena itu jawaban terbaik sebenarnya adalah seperti dalam kebanyakan kasus: Tergantung!

Salam Dennis

Selama 15+ tahun saya tidak perlu kunci seperti itu, melihatnya kadang-kadang, dan itu hanya menyebabkan masalah. Banyak masalah. Pertama-tama kunci utama adalah untuk memegang integritas data, dan itu harus sintetik. Mereka seharusnya tidak memiliki ikatan dengan dunia nyata. Mengapa Setelah perubahan dunia nyata, dan itu pasti, kunci utama Anda hilang, dan Anda harus memperbaruinya, dan semua informasi terkait.

Bayangkan Anda perlu mengingat ker ini di beberapa tabel / database / layanan lain alih-alih satu bidang yang perlu Anda salin beberapa, dan Anda bisa lupa menyalinnya. Alih-alih kunci primer sysntetic, hanya sepotong data, Anda harus memberikan. Saya tidak menyebutkan keunikan indeks, yang mungkin dengan topik besar lain untuk diskusi.

Jadi ringkasan singkat, kunci primer sintaksis (penambahan otomatis, panduan, ..) mudah dikelola, disalin, ...

Jadi saya menganggap, kunci primer sintaksis, dan kunci lain untuk 5 kolom yang Anda sebutkan.

Akhirnya, jika tabel hanya agregat, dan tidak akan pernah ada orang yang perlu referensi baris demi kunci (tapi dunia berubah, percayalah padaku itu akan, setidaknya bagi saya itu berubah secara permanen), saya mungkin akan membiarkannya seperti itu (primer) kunci dengan lima baris), tetapi jika kita dulu punya, itu selalu menyebabkan banyak masalah. Jadi saya katakan.