Në mjediset "Big Tech" (ju e dini, lloji me ton përdorues, grupe të mëdha të të dhënave dhe kërkesat në zhvillim të shpejtë), duke u mbështetur në bazat e të dhënave kufizimet për të parandaluar të dhënat e dyfishuara – përveç nëse është për diçka si pajtimi financiar ku çdo cent duhet të jetë i saktë – sinqerisht, mund të mos jetë aq efektive sa mendoni. Plus, kostoja e ruajtjes së tyre mund të jetë çuditërisht e lartë. Një qasje më e mirë është shpesh për të trajtuar pjesën më të madhe të logjikës deduplication në shtresën e aplikacionit. UNIQUE INDEX Pse fillova të rishikoj indekset unike? Indekset unike të bazës së të dhënave tingëllojnë mjaft të besueshme, apo jo? Linja e fundit e mbrojtjes kundër dyfishimit të të dhënave. Unë kam menduar kështu gjithashtu. Kurdo që një fushë në një tabelë duhet të jetë unike, unë rastësisht do të godas një indeks unik mbi të. Derisa realiteti më dha një thirrje zgjimi të ashpër. Një kohë të gjatë më parë, kur flokët e mi ishin shumë më të plota, unë duhej të shtoja një indeks unik përbërëse në një tabelë me dhjetëra milionë rreshta (të themi, për fusha si dhe tingëllon e thjeshtë, apo jo?E pra, i tërë procesi i ndryshimit u tërhoq për Gjatë kësaj kohe, vonesa e replikimit master-slave ishte në një rollercoaster, dhe ne ishim vazhdimisht të shqetësuar për pengesat e mundshme të shërbimit. tenant_id is_deleted Ditët Pastaj ka pasur një situatë tjetër të pakëndshme. biznesi i mençur, ne të gjithë e dimë dhe janë në mënyrë efektive e njëjta email. Kodi i aplikacionit tuaj me siguri do të normalizojë ato (p.sh., për të ulur) para se të kontrolloni për kopje gjatë regjistrimit. Por indeksi unik i bazës së të dhënave (i cili është shpesh rast-të ndjeshme nga default) nuk e sheh atë në këtë mënyrë. Ndonjëherë, për shkak të të dhënave historike ose sinkronizimet anësore të të dhënave që nuk ishin normalizuar siç duhet, ju do të përfundojë me të dy versionet rast të "e njëjta" e-mail në bazë të të dhënave. Në raste të tilla, indeksi unik ose "ktheh një sy të verbër" në këtë dyfishim të nivelit të biznesit ose, kur ju përpiqeni për të rregulluar të user@example.com USER@EXAMPLE.COM Për shembull, ndoshta "unike e-mail" ishte e mjaftueshme më parë, por tani kërkesa ndryshon në "ID qira + unike e-mail." i madh. kodi i aplikimit duhet të ndryshojë, e drejtë? Pjetri dhe një tjetër Si i koordinoni këto dy grupe operacionesh?Cila shkon e para?Çfarë nëse diçka shkon gabim në mes?Të kryesh operacione të tilla në tavolina të mëdha është si të shkatërrosh një bombë çdo herë – krejtësisht nervoze. DROP CREATE Këto përvoja më detyruan të mendoj: në mjedise me vëllime të mëdha të të dhënave, njëkohshmëri të lartë dhe kërkesa që ndryshojnë shpejt, a është qasja tradicionale për indekset unike ende e duhura? Ky artikull është për të ndarë mendimet e mia në lidhje me këtë. 2. Përse i besojmë kaq shumë? Indeksi i vetëm Indeksi i vetëm Para se të zhytem në ankesat, le të jemi të drejtë dhe të pranojmë pse indekset unike janë kaq të njohura. Mbrojtja përfundimtare për integritetin e të dhënave: Barriera përfundimtare për të parandaluar të dhënat e dyfishuara. Lehtë për të zbatuar: Disa rreshta të SQL kur krijoni një tabelë ose shtoni një DDL më vonë, dhe ju jeni gati. Skema si dokumentacion: Është e shënuar në skemë; ky fushë nuk mund të ketë kopje. Një rritje e mundshme e performancës së pyetjes: Meqenëse është një indeks, pyetjet në këtë çelës mund të jenë më të shpejta. Këto përfitime janë me të vërtetë mjaft tërheqëse për projekte të vogla, ose kur vëllimet e të dhënave janë të menaxhueshme dhe logjika e biznesit nuk është shumë komplekse. 3. Nën lente "Big Tech": A janë këto përfitime ende të vlefshme? Indeksi i vetëm Indeksi i vetëm Le të shqyrtojmë secilin nga "përfitimet" e përmendura më sipër dhe të shohim nëse ato ende qëndrojnë në një mjedis teknologjik në shkallë të gjerë dhe të shpejtë. "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 Le shtresën e aplikimit të bëjë punën - kjo është ajo që është e mirë në! Duke pasur parasysh të gjitha këto probleme me indekset unike të bazës së të dhënave, përgjegjësia për sigurimin e unike të të dhënave duhet të bjerë kryesisht në shtresën tonë të aplikacioneve. Përfitimet e trajtimit të unike në shtresën e aplikimit janë të shumta: Fleksibël dhe të saktë: Çfarëdo që biznesi e përcakton si një kopje, ne mund të kodojmë logjikën në përputhje me këtë – ndjeshmëria e rastit, formatimi, kushtet komplekse, ju e quani atë. Përvoja më e mirë e përdoruesit: Nëse një përdorues bën një gabim, ne mund të sigurojmë reagime të qarta dhe të dobishme, të tilla si "Ky numër telefoni është tashmë i regjistruar. Efektive Early Rejection: Intercept duplicates në shtresën e ndërfaqes së shërbimit ose madje edhe shtresën e portës, para se të dhënat madje të godasë bazën e të dhënave, duke kursyer një udhëtim të pakuptimtë. Interface Idempotency: Kjo është një armë e fuqishme kundër operacioneve të dyfishta.Nëse një përdorues klikon dy herë butonin e dorëzimit, ose një problem i rrjetit shkakton një retry, idempotency e duhur në shtresën e aplikacionit siguron që të dhënat nuk janë të dyfishuara.Një indeks unik nuk mund të ndihmojë me këtë. Konkludimi Konsideroni përdorimin e një indeksi unik vetëm kur përfitimet e tij (zakonisht si një backstop absolut i të dhënave të fundit në raste ekstreme) e tejkalojnë qartë dhe në mënyrë të konsiderueshme problemet e shumta që shkaktojnë në mjedise komplekse me vëllime të mëdha të të dhënave dhe iterim të shpejtë (kërcënim për agility, dhimbje operacionale). Priorizoni mekanizmat e fuqishëm të unitetit të shtresës së aplikacionit (validimi i frontit, përpunimi asinkron, idempotency, gjenerimi global ID, etj.).
