Vlákno názorů k článku
Populární MongoDB se chystá na burzu. Nejvíce chce zatopit Oraclu
od OB - Hezká statistika. Naše aplikace nepoužívají žádné vendor-specific feature,...
-
OB (neregistrovaný)
Hezká statistika. Naše aplikace nepoužívají žádné vendor-specific feature, protože podporují vícero databází a jakékoli neuniverzální SQL je proto nepohodlné a problematické (výhybky máme jenom tam, kde je to nutné z důvodu funkčnosti -např. rozdílná syntaxe pro TOP- nebo kde bylo možné performance problémy vyřešit pouze pomocí hintů). Ale jsou to velké projekty, a proto najít, přepsat a přetestovat všechny části, které mají try-catch implementaci, je prostě pracné = drahé. Nemapatuju si přesně odhady, ale bylo to tolik, že to management bez rozmýšlení zamítl.
-
Pavel Stehule (neregistrovaný)
Záleží na tom jak je aplikace napsaná - podle statistik NTT cca 50 procent jde do několika dnů, 25% do 10 pracovních dnů, a zbytek mohou trvat měsíce - Oracle má hodně specifik, ať už nestandardní ztotožnění NULLu s prázným řetězcem, generické typy date, number a v jejich případě hodně tolerantní typový systém. Tam je pak migrace pracná - většinou je to srovnatelné se značným refaktoringem. Případně mohou aplikace využívat některé specifické vlastnosti Oracle - ať to některé balíčky nebo sekuritní nebo korporátní fíčury. Takových aplikací zase ve výsledku moc není - i když někteří vývojáři byly kreativní.
-
OB (neregistrovaný)
Ano, já vím - to jsem právě původně psal: v PostgreSQL se totéž dělá jinak (složitěji), proto je pracné a drahé portovat z ostatních databází na PostgreSQL. A proto těžko bude PostgreSQL významnou konkurencí pro Oracle - Oracle se nasazuje pro velké projekty, a u těch bude portace příliš drahá...
-
Pavel Stehule (neregistrovaný)
Pokud spadne libovolný příkaz v transakci, pak je nutné transakci rollbackovat .. tím máte vždy garantovanou konzistenci databáze. Postgres Vám nedovolí ignorovat chyby - ne jednoduše. Pokud očekáváte problémy s některými příkazy uvnitř transakce, tak byste měl použít SAVEPOINTs.
-
OB (neregistrovaný)
Nějak mi to nedává smysl - můžete to prosím trochu rozvést?
>> Tam není co opravovat - dokud aplikace neukončí transakci, tak Postgres sám o sobě ji nemá co ukončovat.
Nepsal jsem nic o ukončování transakce ze strany databáze, s tématem to ani nijak nesouvisí - nechápu, co řešíte.
>> Tady se jedná o zřejmou aplikační chybu.
Od kdy jsou try-catch konstrukce "zřejmou aplikační chybou"? Problém PostgreSQL je, že try-catch logiku neumožňuje - jakmile např. spadne insert kvůli duplicitním hodnotám, už není možné v transakci nijak pokračovat (každý další dotaz ve stejné TX spadne s chybou "current transaction is aborted, commands ignored until end of transaction block"). Přitom z aplikace není problém spadlý insert legitimně ošetřit a v transakci pokračovat - v mnoha use casech jde o nejjednodušší a nejefektivnější řešení, a všechny normální databáze to umožňují...
>> Postgres se rozhodně nesnaží emulovat chyby v designu Oracle.
Tak ten je dobrej :)
-
OB (neregistrovaný)
Mimochodem, zrovna PostgreSQL se u nás neuchytil, protože je složité na něj přejít - chová se zásadně jinak než ostatní databáze v případě, že uprostřed transakce nějaký dotaz skončí s chybou, viz např. zde:
https://stackoverflow.com/questions/10399727/psqlexception-current-transaction-is-aborted-commands-ignored-until-end-of-traKdyž už máte odladěnou a léty prověřenou složitou aplikaci, tak přeportovat ji na PostgreSQL je extrémně drahé. A právě takové aplikace typicky běhají nad Oraclem (pro jednoduchá/menší řešení je Oracle zbytečně drahý). Takže zrovna PostgreSQL pro Oracle moc konkurencí není (pokud tedy mezitím chování transakcí neopravili - je to asi rok a půl, co jsem to zkoušel prošťouchnout).
-
OB (neregistrovaný)
Ani jedno. Oracle je řešení pro velké databáze, PostgreSQL je levné řešení pro menší objemy dat, Mongo je šikovné úložiště pro některé use case - ale jen pokud vyvíjíte v Javě. V naší firmě se používá asi 6 různých databází - právě proto, že každá nabízí za jiné peníze jinou muziku...
