Názory k článku PostgreSQL 9.4: transakční SQL JSON databáze
-
Na podpoře OLAPu se pracuje na více frontách - PostgreSQL XC a PostgresXL, a v EDB mají v plánu multi CPU sort - implementovaný pomocí bgworkers (příští rok . O PostgreSQL XC mluvil pan Beneš na letošním P2D2 - docela si to pochvaloval - můžete také vyzkoušet stado http://stormdb.com/community/stado.
-
MilanK (neregistrovaný)
Když vidím to prosazování JSONu, rád bych se zeptal, jestli někdo připravuje PostgreSQL pro přímou komunikaci s WWW prohlížečem, třeba nějaké univerzální SQL REST API. Dnes už toho Javascript v prohlížeči umí tolik, že je často zbytečné vkládat mezi aplikaci v prohlížeči a SQL server nějaký další aplikační (HTTP) server, který jen přehazuje data z jednoho do druhého. PostgreSQL má přeci dostatek funkcí na definování přístupových práv a udržení integrity dat, umí obsloužit více současných klientů, umí vnitřně zpracovat větší data bez nutnosti neefektivního posílání ven (stored procedures).
-
Asi by mohlo byt zajimave i http://s2x.co/ . Neni to sice asi uplne RESTove API, ale treba vam to pomuze.
-
franci (neregistrovaný)
Dobrý den,
děkuji za článek. Zrovna dneska jsem řešil problém s 9.3.3, kdy v tabulce na masteru vznikly duplicitní primarní klíče (nad integerem, reindex i smazání/vytvoření klíče prošlo bez chyby, záznamy se lišily jen v ctid, žádná velká zátěž a tabulka měla kolem 400 záznamů). Abych pravdu řekl, na další větší analýzu nebyl čas. Doufám, že upgrade na 9.3.4 problém vyřešil.
PF
-
Díky za zajímavý článek. Jedna z věcí, které bych uvítal jsou package - podobně jako to je třeba v Oracle DB. Podstatně to zlepšuje čitelnost, organizovanost a správu kódu. Je velký rozdíl mít např. 10 packages a v nich 10 procedur/funkcí s obsahově příbuzným kódem než na jedné hromadě stovky procedur a funkcí hledat právě tu jedinou. Neuvažuje se o něčem takovém?
Díky Petr. -
Něco, co by se chovalo úplně stejně jako packages se v postgresu neplánuje - i když se o tom mluví - chybí shoda v designu jelikož packages v Oracle jsou trochu něco jiného než Modules v ANSI/SQL a ani jedno z nich nepočítá s podporou více jazyků, které má Postgres.
Packages je ale možné z určitého pohledu nahradit schématy - použil jsem to v Orafce i v dalších aplikacích a pokud mi jde o logické členění, tak schémata mohou packages zastoupit.
-
tomas_unreg (neregistrovaný)
Dekuji za skvely clanek.
Mohl bych tohle tema zneuzit na moji otazku?
Je nejak v PostgreSQL mozne (na klasickem serveru, Linux, 4C/8T, 32GB, RAID1) docilit toho, aby se dalo delat (v jedne tabulce, s cca 10M zaznamy) kolem 500-1000 updatu behem jedne sekundy? Je to jednoduchy dotaz s jednou podminkou ve WHERE kde se zmeni pouze jeden INT za jinou hodnotu.
Snazim se, ale nedari se mi dostat pres cca 100 zmen behem jedne sekundy.
Dekuji
Tom -
sigma (neregistrovaný)
Pouštíte každý update v smostatné transakci, nebo v nějakých blocích? Ten RAID1 je jaký a nad jakými disky? Můžete narážet na IOPS limit rotačních disků, pokud se po každém UPDATE dělá flush() a nemáte tam SSD ani writeback cache na tom RAIDu - pak je limit kolem těch 100 IOPS.
-
Pokud je každý příkaz v samostatné transakci, tak pak automaticky končí zápisem do transakčního logu a fsyncem logu. Tam se toho moc dělat nedá - limit je max iops disku. Jedinou korektní možností (vypnutí fsyncu neberu jako korektní možnost jelikož tím riskujete databázi) je zapnutí asynchronního commitu - resp. vypnutí výchozího synchronního commitu - nastavení
synchronous_commit offhttp://www.postgresql.org/docs/9.3/static/wal-async-commit.html . V případě havárie riskujete, že přijdete o některé commitnuté transakce, máte ale garantováno, že databáze bude konzistentní. -
Omlouvám se, že v této oblasti neznám terminologii - PostgreSQL se používá ve výrobních linkách - buďto pro podporu jednotlivých operací (typicky jde o sběr dat) nebo jako databáze pro řízení procesu výrobní linky. Byl jsem u toho, když Postgresem nahrazovala starší verze Oracle v jedné větší fabrice v ČR.
ČLÁNKY DO MAILU