Volba typu primárního klíče

hlasů
0

Mám tabulku, která bude mít potenciálně vysoký počet vložek za sekundu, a snažím se vybrat typ primárního klíče chci použít. Pro ilustraci řekněme, že je to uživatelé tabulky. Snažím se, aby si vybral mezi použitím GUID a BIGINT jako primární klíč a nakonec jako IDuživatele celé aplikace. Mám-li použít GUID, uložím výlet do databáze generovat nové ID, ale GUID není „user-friendly“, a to není možné rozdělit tabulku tímto ID (které mám v plánu udělat). Používání BIGINT je mnohem pohodlnější, ale vytváří to je problém - nemohu použít identity (zde je důvod, proč tam to), takže moje jediná volba je mít nějakou pomocnou tabulku, která by obsahovala poslední použitý ID a pak říkám to uloženy proc:

create proc GetNewID @ID BIGINT OUTPUT
as
begin
update HelperIDTable set @ID=id, id = id + 1 
end

získat nové id. Ale pak to pomocník tabulky je zřejmý problémové a já jsem zaujatý, kolik aktualizací za sekundu dokáže.

Moc se mi líbí myšlenka použití BIGINT jako pk, ale problém překážkou mě týká - existuje způsob, jak se zhruba odhadnout, kolik id se mohlo vyrobit za sekundu? Uvědomuji si, že velmi záleží na hardwaru, ale existují nějaké fyzické omezení a jaké míry se to díváme? 100 v / s? 1000 je / sec?

Jakékoli myšlenky na to, jak přistupovat k problému jsou vysoce ocenil! Tento problém se mi nedovolí spát mnoha noci teď!

Dík! Andrey

Položena 26/08/2009 v 22:16
zdroj uživatelem
V jiných jazycích...                            


5 odpovědí

hlasů
2

GUID se zdá být přirozenou volbou - a jestli opravdu musí být, mohl byste pravděpodobně argumentovat jej použít pro primární klíč tabulky - do jediné hodnoty, které jednoznačně identifikuje řádek v databázi.

Co bych důrazně doporučujeme, abyste udělat, je použít sloupec GUID jako clustering klíče, který SQL Server ve výchozím nastavení, pokud si výslovně to neříct.

Jako Kimberly Tripp - královny indexování - a jiní uvedli spoustu časů - GUID jako klíč clustering není optimální, protože vzhledem ke své nahodilosti, povede to k masivnímu straně a fragmentace indexu a celkově špatný výkon.

Ano, já vím - že je newsequentialid()v SQL Server 2005 a vyšší - ale ani to není skutečně plně sekvenční, a tím také trpí stejnými problémy jako GUID - jen o něco méně výrazně tak.

Pak je tu jiný problém, aby zvážila: shlukování klíč na stole bude přidána do každého jednotlivého vstupu na každý bez clusterů index na stole stejně - tedy opravdu chcete, aby se ujistil, že je to tak malé, jak je to možné. Typicky, INT s 2+ miliardy řádků by měla být dostatečná pro většinu tabulek - a ve srovnání s GUID jako klíč clustering, můžete ušetřit stovky MB úložného prostoru na disku a v paměti serveru.

Tak se to shrnout: pokud nemáte opravdu dobrý důvod, proč bych vždy doporučit INT IDENTITYpole jako primární / seskupený klíč na vašem stole.

Marc

Odpovězeno 26/08/2009 v 22:28
zdroj uživatelem

hlasů
1

Chcete primární klíč, z obchodních důvodů, nebo clustred klíč pro ukládání dat se týká? Viz stackoverflow.com/questions/1151625/int-vs-unique-identifier-for-id-field-in-database pro podrobnější příspěvek na téma PK vs. seskupený klíč.

Je to skutečně potřeba vypracovat, proč nelze použít identitu. Generování ID ručně, a speciálně na serveru s extra rountrip a aktualizace jen ke generování každé ID pro vložky nebude měřítku. Vy byste mít štěstí Tím se dosáhne nižších 100s za sekundu. Problém není jen rountrip a aktualizace času, ale především z interakce ID aktualizace generace s vložkou dávkování: bude vložka dávkování transakce serializovat generování ID. Woraround je oddělit vytváření ID na samostatném zasedání, takže to může autocommit, ale pak vložka dávkování je zbytečné, protože ID genartion není dávkovaný: to musí čekat na log spláchnutí po každém ID genrated s cílem spáchat. Ve srovnání s tímto uuid poběží kruhy kolem vaší ruční generování ID. Ale UUID jsou hrozné volbou pro clustred klíč, protože fragmentace.

Odpovězeno 26/08/2009 v 22:32
zdroj uživatelem

hlasů
1

Snažím se používat GUID PK pro všechny tabulky s výjimkou malých vyhledávacích tabulek. Koncept GUID zajišťuje, že identity objektu mohou být bezpečně vytvořeny v memeory bez zpáteční do databáze a ukládání později beze změny identity.

Když budete potřebovat „lidskou čitelný“ id můžete použít auto přírůstek int při uložení. Pro rozdělení můžete také vytvořit BIGINTs později databáze plánu pro mnoho uživatelů v jednom záběru.

Odpovězeno 26/08/2009 v 22:26
zdroj uživatelem

hlasů
0

Nápad, který vyžaduje seriózní testování: zkuste vytvořit (vložení) nových řádků v dávkách - řekněme 1000 čas (10,000 1M?). Ty by mohly mít master (aka zúžení) tabulku výpis další z nich použít, nebo můžete mít dotaz, který dělá něco podobného

 select min(id) where (name = '')

Generovat čerstvou dávku prázdný řádek v dopoledních hodinách, každou hodinu, nebo kdykoliv jste až do určitého počtu dispozici zdarma. To řeší pouze problematiku vytváření nových ID, ale pokud to je hlavní překážkou by to mohlo pomoci.

Opce tabulka oddílů: Za předpokladu, že bigint sloupec ID, jak se definuje oddíl? Pokud jste počítat s 1G řádků za den, můžete nastavit nový diskový oddíl ve večerních hodinách (Day1 = 1000000000 přes 1,999,999,999, day2 = 2000000000 přes 2,999,999,999, atd) a následně vyměnit ji, když je připraven. Ty jsou samozřejmě omezena na 1000 přepážek, takže se bigints budete dojdou oddílů, než vám dojdou ID.

Odpovězeno 26/08/2009 v 23:05
zdroj uživatelem

hlasů
0

se snaží zasáhnout svého db se scénářem, snad s využitím JMeter simulovat souběžných zásahů. Možná, že pak můžete jen změřit sami, kolik zátěže můžete zvládnout. Také vaše DB může způsobit hrdlo láhve. Která to je? Já bych prefure PostgreSQL těžkého zatížení, jako je Yahoo a skype splníte

Odpovězeno 26/08/2009 v 22:24
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more