Во "Big Tech" средини (знаете, со тони на корисници, масивни збирки на податоци и брзо менување на барањата), се потпираат на базата на податоци Ограничувањата за спречување на дуплирање на податоците – освен ако не е за нешто како финансиско помирување каде што секој пени мора да биде точен – искрено, може да не бидат толку ефикасни како што мислите. Плус, трошоците за одржување на нив може да бидат изненадувачки високи. Подобар пристап често е да се справи со поголемиот дел од дедуплирачката логика на слојот на апликацијата. Ако можете да избегнете користење на уникатен индекс на базата на податоци, размислете за тоа или барем размислете многу внимателно пред да го имплементирате еден. UNIQUE INDEX Зошто почнав да размислувам за уникатните индекси? Единствените индекси на базата на податоци звучат прилично веродостојно, нели? Последната линија на одбрана против дуплирање на податоци. Јас исто така мислев така. Додека реалноста не ми даде тежок повик за будење. Пред многу време, кога мојата коса беше многу пополна, морав да додадам композитен уникатен индекс на табела со десетици милиони редови (на пример, за полиња како и Звучи едноставно, нели?Па, целиот процес на промена се повлече за Во тоа време, задоцнувањето на репликацијата на господар-раб беше на ролери, и постојано бевме загрижени за потенцијалните прекршувања на услугата.Потоа, не можев да се запрашам: дали оваа "уникатност" на ниво на базата на податоци вреди сите тие напори и ризик? tenant_id is_deleted Денови Потоа имаше уште една непријатна ситуација.Бизнис-мудро, сите знаеме и Вашиот апликациски код сигурно ќе ги нормализира (на пример, до пониски) пред да проверите за дупликати за време на регистрацијата. Но, уникатниот индекс на базата на податоци (кој е често случај-чувствителен по претпоставка) не го гледа на тој начин. Понекогаш, поради историски податоци или синхронизација на податоци со странични канали кои не биле правилно нормализирани, ќе завршите со двете верзии на случај на "истиот" е-пошта во базата на податоци. Во такви случаи, уникатниот индекс или "врти слепо око" на оваа дупликација на ниво на бизнисот или, кога ќе се обидете да ги поправите податоците, неговите ригидни правила всушност се на вашиот начин. user@example.com USER@EXAMPLE.COM На пример, можеби "е-пошта уникатност" беше доволно порано, но сега барањето се менува на "идентитет + е-пошта уникатност". Петар и новиот Д. Како ги координирате овие два сета операции? Кој оди прв? Што ако нешто не е во ред меѓутоа? Извршувањето такви операции на големи маси се чувствува како секој пат да се деактивира бомба – сосема нервозно. DROP CREATE Овие искуства ме натераа да размислувам: во средини со големи обеми на податоци, висока конвергенција и брзо менување на барањата, дали традиционалниот пристап кон уникатните индекси сè уште е вистинскиот? Оваа статија е за споделување на моите размислувања за ова. 2. Зошто му веруваме толку многу? UNIQUE INDEX Единствен индекс Пред да се фрлам во жалбите, ајде да бидеме фер и да признаеме зошто уникатните индекси се толку популарни. Крајната гаранција за интегритет на податоците: Крајната бариера за да се спречи дуплирање на податоците. Лесно да се имплементира: Неколку линии на SQL при креирање на табела или додавање на DDL подоцна, и сте завршени. Схема како документација: Означена е во шемата; ова поле не може да има дупликати. Потенцијално зголемување на перформансите на прашањето: Бидејќи тоа е индекс, прашањата на овој клуч може да бидат побрзи. Овие придобивки се навистина прилично привлечни за мали проекти, или кога обемот на податоци е управуван и деловната логика не е премногу сложена. 3. Под објективот "Голема технологија": Дали тие бенефиции се уште се валидни? Единствен индекс Единствен индекс Ајде да ги испитаме секој од "предностите" споменати погоре и да видиме дали тие се уште се одржуваат во голема, брза технолошка средина. "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 Нека слојот на апликации ја направи работата - тоа е она што е добро во! Со оглед на сите овие проблеми со уникатните индекси на базата на податоци, одговорноста за обезбедување на уникатноста на податоците првенствено треба да падне на нашиот слој на апликации. Предностите на ракување со уникатноста на апликацискиот слој се многубројни: Флексибилен и прецизен: Што и да дефинира бизнисот како дупликат, можеме да ја кодираме логиката соодветно - чувствителност на случај, форматирање, сложени услови, можете да го именувате. Подобро корисничко искуство: Ако корисникот направи грешка, можеме да обезбедиме јасни, корисни повратни информации, како што е "Овој телефонски број е веќе регистриран. Ефикасно рано отфрлање: Прекинување дуплицира на слојот на сервисниот интерфејс или дури и на слојот на порталот, пред податоците дури и да ја погоди базата на податоци, заштедувајќи бесмислено патување. Интерфејс Idempotency: Ова е моќно оружје против дуплирани операции. Ако корисникот двапати кликне на копчето за поднесување или проблемот со мрежата предизвикува ретри, соодветната idempotency на слојот на апликацијата гарантира дека податоците не се дуплираат. Заклучок Размислете за користење на уникатен индекс само кога неговите придобивки (обично како апсолутна резервна точка за податоците од последниот извор во екстремни случаи) јасно и значително ги надминуваат безбројните проблеми што ги предизвикува во сложени средини со големи обеми на податоци и брза итерација (пречка за агилност, оперативна болка).
