Pouzitie RavenDB

Ahojte,
myslím, že toto je vhodné miesto na otázku ohľadom RavenDB.
Prešiel som si jej featury a mám pocit, že poskytuje obdobné veci ako MongoDB a zároveň o nej nie je veľa zmienok (zaujali ma „materializované pohľady“, automatické indexovanie, TTL, attachments,…).

Ak ste ju použili tak na aké use-case?

Aké vidíte výhody/nevýhody oproti MonboDb?

S akými problémami ste si pri RavenDb prešli, čo nemusia byť začiatočníkovi jasné.

Nerobí problém, že všetky dokumenty v databáze sú ako keby v jednej veľkej kolekcii?

Nerobia RavenDB problém ad-hok dopyty?
(Napríklad, keby chcem robiť aplikáciu na hľadanie logov, tak mi nebude robiť za každým dopytom nový index nad XY GB dát?).

To je veľa otázok, začnem z kraja:

  1. use cases
  • všade tam, kde je predpoklad, že budeš mať množstvo rôznych dát. Typický príklad finstat, dátovych zdrojov sú desiatky. Každý nový začleňovať do sql schémy by bolo neúnosné, takto proste ukladáme jsony
  • všade tam, kde potrebuješ pristupovať ku všetkým dátam naraz a vo veľkom počte, sql je super ak pracuješ nad subsetom, ak máš robiť queries nad miliónmi záznamov, tak potrebuješ riadne železo, tu má RavenDB s lucene indexami troška navrch
  • kde nie je vhodný: všade tam, kde nie je tolerancia, aby bol medzi indexom a raw dátami časový rozdiel. V SQL pristupuješ cez indexy priamo k reálnym dátam v rámci transakcie, v RavenDB sú indexy mimo transakcie, teda ACID je len key-value časť RavenDB, teda vyťahovanie informácii cez ID.
  • ešte scenár nevhodnosti je: ak silno používaš číselníky, teda potrebuješ meniť historickú hodnotu, v RavenDB musíš potom patchovať dáta. Ale ako ja vysvetľujem, lepšie je zmeniť dáta raz za pol roka, ako ich joinovať pri každom query.
  1. Mongo nemá ACID podporu ukladania dát, to zistíš až o ne prídeš (pozeram, že už to pridali), teda musí bežať vždy v clustri. Mongo nemá MapReduce indexy, čo je pre nás must have.
  2. Problémami sme prešli kopec (používame od verzie 2.0), aktuálne ale je ale verzia 5. A tu vidím pre začiatočníkov dva problémy:
  • zmeniť filozofiu myslenia, keď zaučam nových ľudí, tak s tým je najväčší problém. Ľudia čo robia celý život v SQL sa ťažko dostávajú z myslenia normalizovať dáta. Tiež využívajú indexy na to, na čo nie sú určené, teda do nich tlačia raw json dáta.
  • autoindexy - my to vypíname, lebo veľa ľudí si myslí, že za nich autoindexy vyriešia problém. Nie indexy sú ten najdôležitejší nástroj práce s RavenDB.
  • MapReduce - to je koncept, čo ľudia ťažko chápu, ale je to vlastne alternatíva k joinom/group by v sql, akurát je predpočítana a teda násobne rýchlejšia
  1. Kolekcie: Zatiaľ sme s kolekciami nemali problém, sú vynikajúci koncept ak robíš správu db a v RavenDB 5 je každá kolekcia akoby osobitný databázový priestor, nad ktorým je index cez ID. U nás je kolekcia jeden typ root objektu.
  2. Ad-hoc dopyty: Robia. Ako píšem vyššie, už pri návrhu musíš mysliet na indexy. Ak potrebuješ dynamické možnosti queryovania, využi SQL ETL https://ravendb.net/docs/article-page/5.0/Csharp/server/ongoing-tasks/etl/sql

Vdaka za obsiahlu odpoved. Mnohe mi to objasnilo.

S Lucene aj Mongom som uz pracoval, preto som sa pytal na porovnanie prave s nim.

Na SQL ETL sa pozriem a uvidim, ci to bude pre moje use case.

RavenDB ma zaujala, hlavne tym, ze je trochu ina ako Mongo, ktore je propagovane a spominane kam sa clovek pozrie.

Mongo je fajn, lebo je jednoduche a free. Ked ale firmy narastu, tak prechadzaju inde, prave z dovodov, ze Mongo nezapisuje na disk safe, takze ak bezis len jednu instanciu, tak urcite v nejakej faze prides o data.
Ak mas cas a zacinas na zelenej luke, tak by sa ti mohol pacit Marten, chlapik ho vytvoril pred 4 rokmi, lebo nebol spokojny s RavenDB a pacili sa mu jeho koncepty.

Vdaka za spomenutie Marten, mas s nim prakticke skusenosti?

Ja som davnejsie skusal nieco podobne YesSql len pre MS SQL.

No parkrat som pouzil LiteDB co je dotnetova embedded databaza s rovnakym API ako ma Mongo, ale mavyse SQL syntax a tranzakcie. Mam ju v nejakych desktopovych aplikaciach a zatial bez problemov.

IMHO: Na MS SQL som si postavil aj queue (PassiveMQ), ktora kopiruje API Azure Queue storage, bolo to lahsie ako nasadit RabbitMQ.

Dosiaľ som nemal príležitosť. Mám to len v škatuľke, že keď budem musieť, tak viem, kde hľadať. Momentálne sme spokojný a trošku aj vendor locknuty na RavenDB.