Vlákno názorů k článku
MySQL má nástupce InnoDB
od LINkeR - Zdravim vsetkych diskutujucich. Zaujimal by ma Vas nazor...
-
LINkeR (neregistrovaný)Zdravim vsetkych diskutujucich. Zaujimal by ma Vas nazor na postgresql, kedze ho tu nikto ani len nespomenul. V akych ohladoch by ste videli nedostatky, popripade vyhody oproti mysql a oracle. Nie som nejaky DB odbornik, skor ma to zaujima z dovodu, ze som uz mal tu cest s multiple master replikaciou pri mysql a po pade jednej z DB to bol celkom zazitok dat znova dohromady. Ale to len tak na okraj. Dakujem za nazory :)
-
AraxoN (neregistrovaný)S Postgresom robím už 7 rokov a zatiaľ nesklamal. Už dávno podporuje transakcie, referencie viewy, triggre, storované procedúry, namespaces - všetko to, o čo sa MySQL urputne snaží už X rokov so zmiešanými výsledkami. Nevýhody? Najväčšia potiaž z môjho pohľadu je s diakritikou - zoradzovanie a vyhľadávanie vo varcharoch po slovensky (česky) s diakritikou sa nastavuje veľmi temným spôsobom a funguje len pre niektoré kódovania, rozbehať to s unicode je nemožné (alebo som nenašiel to správne howto).
-
Pokud chcete pouzivat UTF, musite cluster inicializovat s UTF locales. Pak funguje diakritika bez problemu - nevim, co si pod mam predstavit pod pojmem temny zpusob :). Proste urcite, ktere locales se ma pouzit - musi ale sedet locales a kodovani. Problem nastava teprve tehdy, kdyz chcete pouzit vic locales naraz, napr. radit podle ceskych nebo slovenskych pravidel - to uz zavani magii.
http://www.pgsql.cz/index.php/Instalace_PostgreSQL -
AraxoN (neregistrovaný)jj, to je ten temný spôsob. Oproti MySQL rozhodne temný.
K tomu ďalšiemu: Potrebujeme v aplikáciách vyhľadávanie s diakritikou a zoradzovanie s diakritikou. T.j. ak dám ORDER BY stlpec, tak si poradie predstavujem takto: ('Biela', 'Čierna', 'Fialová', 'Modrá', 'Šedá', 'Zelená', 'Žltá'). Za uspokojivé nepovažujem ('Biela', 'Fialová', 'Modrá', 'Zelená', 'Šedá', 'Žltá', 'Čierna'), a ani ('Biela', 'Šedá', 'Fialová', 'Čierna', 'Žltá', 'Modrá', 'Zelená'). Takisto nepovažujem za úspech takýto select:
db=# SELECT * FROM tabulka WHERE stlpec LIKE 'šedá%';
(0 rows)
Jediná kombinácia kódovaní a slovenských locales, ktorá nám funguje je sk_SK.ISO-8859-2, a nie je to tým, že by sme iné locales nemali v systéme vygenerované. -
Pokud pouzivate Latin2, tak je jen jedno lokales, ktere muzete pouzit a to sk_SK.ISO-8859-2. Zadne jine Vam nemuze splnovat Vase pozadavky. Dale LIKE je CASE SENSITIVE - tudiz Vas priklad funguje spravne - Vy chcete ale pouzit ILIKE.
PostgreSQL je zalozene na Locales - pokud Vam v systemu chodi, tak PostgreSQL pojede take. Neni to idealni (COLLATES based respektuje standard a dovoluje i jine kousky), jelikoz jeste v 8.2 muzete vygenerovat cluster tak, ze Vam nesedi locales a kodovani. Zadny dalsi figl v tom neni. -
AraxoN (neregistrovaný)Ten select som písal po pamäti, v skutočnosti tam máme asi niečo ako LOWER(stlpec) LIKE LOWER('šedá%'), čo funguje... za ten ILIKE ďakujem - to vyzerá ako správnejšie riešenie.
Kódovanie databáz máme MULE_INTERNAL, s inými to tiež nejak správne nefachalo... Takže problém je v tom, že locales v distribúcii napísal nejaký nedôsledný šlendrián? To by sa dalo napraviť - asi sa na to ešte pozriem... -
PostgreSQL se používá i na Slovensku - spíš bych to tipoval na problém mezí židlí a klávesnicí :) - obyčejně to jsou ty chyby, kdy celý večer marně hledáte chybu nebo řešení - a v okamžiku, kdy máte za zády kámoše, kterému se svěřujete s problémem, tak naprosto jasně uvidíte v čem je problém. Malá poznámka: kódování databáze je jedna věc a locales a jeho kódování věc druhá. Locales se nastavuje pro celý cluster ve chvíli, kdy se inicializuje. Až 8.3 kontroluje shodu kódování locales a databáze. Takže pokud budete mít cluster inicializovaný s cs_CZ.Latin2, tak v UTF8 databázích, které bezproblémově vytvoříte, budete mít problém s diakritikou - dá li P.B, tak 8.4 by mohla mít nastavení locales na databázi - toto hloupé omezení pochází z dob, kdy inicializace nebo přepnutí locales bylo pomalé - to již neplatí.
p.s. schválně si to zkuste, kde budete moci (v případě problémů jsem na ICQ, které jednoduše vygooglujete). -
Lenin (neregistrovaný)Postgres ma nekolik problemu. jednak cas od casu mrsi indexy a v db tak byt v unique sloupci vic stejnyh hodnot a za druhe jeho free space management kde se nastavuje staticka pocet bloku ve kterych se bude sledovat volne misto taktne receno ne prilis skalovatelny. Pokud databaze tuto velikost presvihne zacne strasne rychle narustat.
-
to je psano po 5 pivech ne? Ze by PostgreSQL mrsil indexy, tak o tom nic nevim. Byly reportovany podobne pripady, vzdy se nakonec ukazalo, ze slo o zavadu hw - obycejne je problem v redici, ktery jaksi nezapisuje, co by zapisovat mel. Pokud presvihnete max_fsm_pages tak neni problem hodnotu teto promenne zvysit. Dokonce kvuli tomu ani nemusite iniciovat cluster - v kazdem pripade je to signalizace, ze musite casteji volat VACUUM. A pokud to nerespektujete, tak budete mit velky problem s mrtvymi zaznamy. Jinak kdyby max_fsm_pages nebylo limitovano, tak Vam hrozi vycerpani pameti - mazete stale a tabulka volnych bloku se Vam bude neustale rozrustat.
-
Lenin (neregistrovaný)Jak casteji? Ja mam vsude autovacuum. Problem s mrtvymi zaznamy nemam, mne jen databaze dost rychle narusta.
Maji ostatni databaze neco jako staticka velikost max_fsm_pages? DB2 ne, Oracle9 taky ne. To da taky rozum, proc nastavovat nejaky konfiguracni parametr podle predpokladane velikosti db, ktery naviz zpusobuje problemy kdyz se podhodnoti.
Nikdo vas nenuti tu bitmapu ukladat do pameti, ukladejte si ji na disk jako ostatni. -
Jak casteji? Ja mam vsude autovacuum. Problem s mrtvymi zaznamy nemam, mne jen databaze dost rychle narusta.
Pak Vás ani nemůže limitovat max_fsm_pages. Ve starších verzích nízká hodnota max_fsm_pages zabránila dokončení vacua - což byl problém - muselo se spustit FULL VACUUM. Pokud máte pocit, že problém je v max_fsm_pages pak tuto hodnotu zvedněte nebo zvedněte četnost VACUUM. A nebo je někde jiný problém, který nedokáži od stolu ani odhadnout.
Maji ostatni databaze neco jako staticka velikost max_fsm_pages? DB2 ne, Oracle9 taky ne. To da taky rozum, proc nastavovat nejaky konfiguracni parametr podle predpokladane velikosti db, ktery naviz zpusobuje problemy kdyz se podhodnoti.
Jiné databáze buďto vůbec nepoužívají MVCC nebo používají jinou variantu - u Oracle se například musel nastavovat rollback segment. Optimální hodnota max_fsm_pages souvisí s velikostí tabulky jen okrajově - důležitá je četnost operace vacuum a počet UPDATE a DELETE operací.
Nikdo vas nenuti tu bitmapu ukladat do pameti, ukladejte si ji na disk jako ostatni.
Ona je uložené také na disku, ale pouze v paměti je k ni dostatečně rychlý přístup. Hlavně ostatní databáze nemají VACUUM. Neni to uplne top tema. S max_fsm_byl problem, dokud prilis nizka hodnota blokovala VACUUM. Ted se spis aktualne resi, jak uplne odbourat VACUUM a nebo jej co mozna nejvice eliminovat - napr. HOT. Dost by mely zmenit tzv. visibility maps, ktere do jiste miry prebiraji funkci fsm a navic pomahaji v urychleni VACUUM a COUNT(*).
