Dalam lingkungan "Big Tech" (kamu tahu, jenis dengan banyak pengguna, dataset besar, dan kebutuhan yang berkembang pesat), bergantung pada database Keterbatasan untuk mencegah duplikasi data – kecuali itu untuk sesuatu seperti persetujuan keuangan di mana setiap sen harus akurat – jujur, mungkin tidak efektif seperti yang Anda pikirkan. Plus, biaya mempertahankannya bisa mengejutkan tinggi. Pendekatan yang lebih baik seringkali adalah untuk menangani sebagian besar logika deduplikasi di lapisan aplikasi. Jika Anda dapat menghindari menggunakan indeks unik database, pertimbangkan untuk melakukannya, atau setidaknya pikirkan dengan sangat hati-hati sebelum menerapkan satu. UNIQUE INDEX Mengapa saya mulai memikirkan kembali indeks unik? karena saya terbakar. Indeks unik database terdengar cukup dapat diandalkan, kan? Garis terakhir pertahanan terhadap duplikasi data. Saya juga sering berpikir demikian. Sampai realita memberi saya panggilan bangun yang keras. Lama yang lalu, ketika rambut saya jauh lebih lengkap, saya harus menambahkan indeks unik komposit ke tabel dengan puluhan juta baris (seperti, untuk bidang seperti dan Terdengar sederhana, bukan? baiklah, seluruh proses perubahan ditarik untuk Selama waktu ini, keterlambatan replikasi master-slave berada di rollercoaster, dan kami terus-menerus khawatir tentang hiccups layanan potensial. tenant_id is_deleted hari Kemudian ada situasi yang tidak menyenangkan lainnya. bisnis bijaksana, kita semua tahu dan Kode aplikasi Anda pasti akan menormalkan mereka (misalnya, ke lowcase) sebelum memeriksa untuk duplikat selama pendaftaran. Tetapi indeks unik database (yang sering kasus-sensitif oleh default) tidak melihatnya dengan cara itu. Terkadang, karena data historis atau sinkronisasi data saluran samping yang tidak benar-benar normal, Anda akan berakhir dengan kedua versi kasus dari "sama" email dalam database. Dalam kasus seperti itu, indeks unik baik "mengalihkan mata" ke duplikasi tingkat bisnis ini atau, ketika Anda mencoba memperbaiki data, aturan kakunya benar-benar mendapatkan jalan Anda. user@example.com USER@EXAMPLE.COM Misalnya, mungkin "e-mail unik" sudah cukup sebelumnya, tapi sekarang persyaratan berubah menjadi "ID penyewa + e-mail unik." Ped dan satu yang baru d. Bagaimana Anda mengkoordinasikan dua set operasi ini? mana yang pertama? bagaimana jika ada yang salah di antara keduanya? melakukan operasi seperti itu di atas meja besar terasa seperti menghancurkan bom setiap kali – sangat merusak saraf. DROP CREATE Pengalaman ini memaksa saya untuk berpikir: dalam lingkungan dengan volume data besar, konsistensi tinggi, dan persyaratan yang berubah dengan cepat, apakah pendekatan tradisional untuk indeks unik masih tepat? Artikel ini bertujuan untuk berbagi pemikiran saya tentang hal ini. 2. Mengapa kita mempercayainya begitu banyak? Indeks yang unik Indeks yang unik Sebelum saya menyelam ke dalam keluhan, mari kita jujur dan mengakui mengapa indeks unik begitu populer. The ultimate safeguard for data integrity: The ultimate barrier to prevent duplicate data. Mudah untuk menerapkan: Beberapa baris SQL saat membuat tabel atau menambahkan DDL kemudian, dan Anda selesai. Skema sebagai dokumentasi: Ini ditandai dalam skema; bidang ini tidak dapat memiliki duplikat. Potensi peningkatan kinerja kueri: Karena itu adalah indeks, kueri pada kunci ini dapat lebih cepat. Manfaat ini benar-benar cukup menarik untuk proyek-proyek kecil, atau ketika volume data dapat dikelola dan logika bisnis tidak terlalu kompleks. 3. Di bawah lensa "Big Tech": Apakah manfaat itu masih berlaku? UNIQUE INDEX Indeks yang unik Mari kita memeriksa masing-masing "manfaat" yang disebutkan di atas dan lihat apakah mereka masih bertahan dalam lingkungan teknologi yang besar dan pesat. "The ultimate safeguard"? Is this safeguard reliable? What exactly is it safeguarding against? It doesn't fully recognize business-level "duplicates"! Except the email case sensitivity issue I mentioned earlier (which could be solved by using but introduce more complexity in the DB layer), or phone numbers with or without , or usernames with or without special characters stripped... these nuances, which business logic considers "the same," are beyond the grasp of a database's simplistic "byte-for-byte identical" unique index. It can't prevent "logical duplicates" at the business layer. collation +44 The application layer has to do the heavy lifting anyway. Since all these complex "sameness" checks must be handled in the application code (you can't just throw raw database errors at users, can you?), the application layer is the true workhorse ensuring "business data uniqueness." The database's unique index is, at best, an "auxiliary police officer" whose standards might not even align with the business rules. In distributed systems, it's merely a "local bodyguard." Once you shard your tables in a distributed scenario, an in-table unique index can't ensure global uniqueness. Global uniqueness then relies on ID generation services or application-level global validation. At this point, the "safeguard" provided by the local database index becomes even less significant. This "ultimate safeguard" might miss the mark, has limited coverage, and relying solely on it is a bit precarious. "Easy to implement"? One-time setup, week-long headache. Adding a unique index to a brand new table is indeed just one SQL statement. But more often, you're changing the rules for an old table that's been running for ages and has accumulated mountains of data. Trying to alter a unique index on a table with tens of millions of rows (e.g., changing from a single-field unique to a composite unique) could mean several minutes of table locking! Online DDL tools might save you from service downtime, but the entire process can still be lengthy, resource-intensive, and risky. Agile? Not so fast! In scenarios with rapid iteration, multi-region synchronization, and compliance requirements, a single unique index change at the database level can hold you up for days. So much for agility. So, that initial "simplicity" is like bait compared to the "hell" of modifying it later. "Schema as documentation"? The documentation might not match reality! Yes, a unique index in the table structure acts as a form of "technical documentation." But "documentation" can be misleading. If the "uniqueness" defined by this index doesn't align with the actual, more complex business rules (like the case-insensitivity example), then this "documentation" is not only useless but can also mislead future developers. If changing this "documentation" (i.e., modifying the unique index) involves an epic struggle, why not write down the business rules properly in actual design documents, wikis, or code comments? Those are far easier to update. "A potential query performance boost"? Is the tail wagging the dog? This is a common misconception, or rather, an overemphasized "added value." If you simply want to speed up queries on a specific field or set of fields, you can absolutely create a regular, non-unique index for them! A non-unique index will boost query speeds just fine, and it comes without the write overhead, DDL pains, and rigid business logic constraints of a unique index. Master-slave index inconsistency can instantly "paralyze" replication: I've seen it happen multiple times: the unique index configuration on the primary database is updated (e.g., a field is added, or a constraint is changed), but the index on the replica isn't modified in sync. Then, as soon as data changes on the primary (e.g., a row is inserted that would be considered a duplicate on the replica, or the primary can write it but the replica can't due to the incorrect/outdated index), the binlog is applied to the replica, and bam! . Replication just dies. When this happens, you get data lag, read-write splitting is affected, and it can even impact failover capabilities. What a nightmare, right? Slave_SQL_Running: No Biarkan lapisan aplikasi melakukan pekerjaan - It's What It's Good At! Mengingat semua masalah ini dengan indeks unik database, tanggung jawab untuk memastikan keunikan data harus terutama jatuh pada lapisan aplikasi kami. Keuntungan menangani keunikan pada lapisan aplikasi adalah banyak: Fleksibel dan akurat: Apa pun yang perusahaan didefinisikan sebagai duplikat, kami dapat mengkodekan logika sesuai – sensitivitas kasus, pemformatan, kondisi kompleks, Anda menyebutnya. Pengalaman Pengguna yang Lebih Baik: Jika pengguna membuat kesalahan, kami dapat memberikan umpan balik yang jelas dan berguna, seperti "Nombor telepon ini sudah terdaftar. Efisien Early Rejection: Intercept menduplikasi pada lapisan antarmuka layanan atau bahkan lapisan gateway, sebelum data bahkan mencapai database, menghemat perjalanan putaran yang tidak masuk akal. Interface Idempotency: Ini adalah senjata yang kuat terhadap operasi duplikat. Jika pengguna mengklik dua kali pada tombol kirim, atau masalah jaringan menyebabkan retry, idempotensi yang tepat pada lapisan aplikasi memastikan data tidak duplikat. Kesimpulan Hanya pertimbangkan untuk menggunakan indeks unik ketika manfaatnya (biasanya sebagai backstop data terakhir dalam kasus ekstrim) jelas dan secara signifikan melebihi kerumitan masalah yang menyebabkan di lingkungan yang kompleks dengan volume data besar dan iterasi cepat (menghalangi kelincahan, kesakitan operasional). Prioritaskan mekanisme keunikan lapisan aplikasi yang kuat (validasi front-end, pemrosesan asynchronous, idempotency, generasi ID global, dll.).
