AWS oznámilo open source fork Elasticsearch

DocumentDB je kompatibiliní s MongoDB 3.x, tedy pět let starou verzí. To jsem zvědav, jakej relict udělají z ElasticSearche.

Otázkou je, zda je to problém? Např. Azure má CosmosDB (což je opravdu hrozná databáze) a to má sice MongoDB API ale neumí ani 1/3 co MongoDB 3.x. Kdybych si mohl vybrat, tak raději použijí staré MongoDB než CosmosDB. My nakonec přešli na MongoDB Atlas a jsme spokojeni. Podle mě záleží případ od případu a spoustě lidem bude ta stará verze stačit.

Z pohledu vývojáře stoprocentně, jinak člověk začne časem řešit věci, které jsou v nové verzi vyřešené. Může to být nějaké design flaw, které se podařilo odstranit nebo prostě jen rychlost.

CosmosDB ale narozdil od MongoDB neni obycejna dokumentova databaze. Umoznuje totiz napriklad grafove struktury a operace nad nimi (Gremlin API).

Mongo možná je "obyčejná" dokumentová databáze ale narozdíl od CosmosDB je funkční a dá se použít v produkci na větších projektech, to samé se o CosmosDB opravdu říct nedá. Kvantita neznamená kvalitu. A po zkušenostech s CosmosDB moc nevěřím, že ta grafová část bude použitelná. Ty cally s Microsoftem jak nám vysvětlovali, jak ty omezení obejít. Už nás přestalo bavit jim dělat testery, protože ta databáze není připravená pro produkční použití. Vždyť jejich API pro mongo neumí ani $text operátor a regexp má neskutečně moc problémů. Taky jejich pricing model, že si platíte počet RU za sekundu a je to statické (teď tedy poskytují i dynamické, ale pro se mění jednou za hodinu a když v poslední vteřině hodiny a první vteřině následující hodiny máte peek a pak nic, tak zaplatíte za obě dvě hodiny obrovskou částku) a nemůžete to nijak překročit, takže vám zbývá jenom ty dotazy a ukládání do databáze opakovat a opakovat dokud to neprojde. Navíc je to šíleně pomalé operace co v neoptimalizovaném MongoDB trvala několik vteřin v CosmosDB trvali desítky minut. Takhle si opravdu cloudovou databázi nepředstavují.

Nepochopili ste princip CosmosDB. MongoDb driver pre Cosmos je pre timi, co prechadzajz na Comos, aby sa ulahcil prechod. Cosmos toho podporuje ovela viac (change feedy, tranzakcie, planetarna replikacia, konzistencia napriec geolokaciami....).
Ak chcete naplno vyuzit Cosmos, treba pouzit CosmosDb API (bud cez SQL alebo restove - kniznica je k tomu dostupna v kazdom rozumnom jazyku).

Nehovoriac o tom, ze od Monmga ludia odchazdaju, na zaciatok sa zda fajn, ale postupom casu zistite, ze konkurencia ma lepsi vykon, tranzakcie a plno fetaure navyse (napriklad RavenDb).

Podobne se chlapkove z EnterpriseDB vysmivali "konkurenci" jaky ze archiacky form PostgreSQL nabizeji. Tohle je trochu problem opensource, ze vznikaji forky, ktere pak uz ale dale nestihaji dohanet upstream.

To jste asi špatně pochopil, to nebyl posměch, ale spíše povzdech až pláč. Já s tím jejich cloudem musím pracovat a vím, že když se někdo pustí moc dovnitř, tak se už nikdy nedostane ven. AWS si vytváří standardy samo pro sebe a svou velikosti je protlačuje. Začít používat jejich služby je křišťálově čistý vendor lock-in, což začne tlačit v momentě, kdy přijdete na to, že ty jejich služby nejsou zas tak dobré. Kdykoli tak udělají podobnou kličku, jako udělali s ElasticSearch, tak nakonec celej ten technologickej dluh dopadne i na mě, protože s tím budu muset pracovat.

No a na Azure je to ještě několikanásobně víc, vše na co se tam sáhne tak nefunguje. Nakonec přechod mezi cloudy je obrovský problém, právě kvůli tomu, že se využije nějaká jejich technologie, ale to je jejich cílem.

Osobně bych přístup k DB vždy řešil (a řeším) přes vlastní abstraktní vrstvu, abych se vyhnul prorůstání vrstev a závislosti na dodavateli a umožnil změnu. Jde to i ve vašem případě Azurů a Amazonů?