https://blog.root.cz/sentan/ https://i.iinfo.cz/r/rss-88x31.gif 88 31 https://blog.root.cz/sentan/ Poslední přidané názory v blogu Nestrukturovaná data - NoSql experimenty cs Wed, 08 Apr 2015 06:58:12 GMT https://blog.root.cz/sentan/mongodb-zavislost-za-30-minut/#o869661?utm_source=rss&utm_medium=text&utm_campaign=rss hyv: Jako jednorázová záležitost pro převod starých read-only dat do nového systému budiž. Ovšem začínat s Mongo nový projekt s potenciálem růstu není rozumné, je to návrat zpět asi tak o dvě desetiletí. Mongo není jediné s podporou nestrukturovaného datového skladu JSON dokumentů, konkurence to umí také. his Wed, 08 Apr 2015 06:58:12 GMT blog.root.cz-blogComment-869661 https://blog.root.cz/sentan/mongodb-zavislost-za-30-minut/#o869659?utm_source=rss&utm_medium=text&utm_campaign=rss Na tento příspěvek jsem se rozhodnul reagovat. Především na výrok "Tady je hezky vidět, že schemaless je příčinou problému, nikoli řešením". Domnívám se, že zde došlo k neporozumění. Proč jsem na to právě Mongo použil? Právě proto, že je schemaless a že převod do takové databáze byl relativně rychlý a levný. Nedovedu si představit, že bych nejdříve musel projít celý dataset, připravit schéma, dlouze nahrávat (a normalizovat) a to do doby, než vyladím poslední chybu (která zapříčiní změnu schámatu). Takto se už v tom servisáci po rychlém zaškoleni (jednoduchý dotaz v JS) sami přehrabují a kontrolují si nastavení apod. Rozhodně bylo jednodušší v JSONu jim vysvětlit a pochopit pro ně dokument, ktery ma v sobě subdokumenty, než různé kartézské součiny, detektivní práci v čem se odlišují jednotlivé řádky nebo JOINy. Navíc to hnůj rozhodně není, už se to používá. Kdyby se to dělalo klasicky, nikdo to nezaplatí a ještě teď to není. hyv Tue, 07 Apr 2015 19:40:06 GMT blog.root.cz-blogComment-869659 https://blog.root.cz/sentan/mongodb-zavislost-za-30-minut/#o869658?utm_source=rss&utm_medium=text&utm_campaign=rss Ad „Historické záznamy ale byly kombinace binárních a textových dat zachycených na sběrnici, přímo uložených bez dalších úprav. Dispečer měl pouze možnost přes starou ovládací aplikaci sledované parametry a stavy kontrolovat, tuto možnost musela vždy servisní firma zadrátovat přímo do kódu. V průběhu osmi let byl počet linek rozšiřován a i linky samotné byly upravovány. Tzn. co linka a období, to drobné nuance ve významu a struktuře zaznamenaných dat. Navíc s každou rekonfigurací linky docházelo ke změnám v přijímaných větách dat z řídících a monitorovacích jednotek (další bloky od nově instalovaných senzorů apod.).“ Tady je hezky vidět, že „schemaless“ je příčinou problému, nikoli řešením. Ad „veškeré operace v databázi (místo SQL) provádíte jednoduše v JS.“ Jednoduše? SRSLY? Spíš mi to přijde jako pořádný krok zpátky. Celkově vzato: jako vidle k přeházení hnoje z jedné hromady na druhou je to možná dobré, ale pro nově pořizovaná data bych nic „schemaless“ nedoporučoval a radil bych to udělat pořádně. Jinak za pár let přijde někdo, kdo bude ve stejné pozici jako ty teď a bude se v tom hnoji muset přehrabovat. Franta Sun, 05 Apr 2015 11:28:45 GMT blog.root.cz-blogComment-869658 https://blog.root.cz/sentan/mongodb-zavislost-za-30-minut/#o869657?utm_source=rss&utm_medium=text&utm_campaign=rss Ja Mongo pouzival v praci. Firma bezela na Jablku (MacOS) a v te dobe (cca 2 roky) k tomu nebyl pouzitelny client na obycejny UPDATE dat. Nejen ze pravidelne padal ale po zapsani do databaze s fontem UTF-8 doslo k naprostemu rozhozeni pridanych dat. A pak to lovit a opravovat byla sila. norwi_ Thu, 26 Mar 2015 11:15:42 GMT blog.root.cz-blogComment-869657 https://blog.root.cz/sentan/mongodb-zavislost-za-30-minut/#o869656?utm_source=rss&utm_medium=text&utm_campaign=rss Pouzivam Mongo jako doplnkovou databazi k MySQL (proste referencni integritu v tomto reseni potrebuji). Na nestrukturovana data je to flexibilnejsi nez relacni databaze, ale zase nema jine veci (treba tu referencni integritu). Mam to zatim jako experiment. Uvidim jake budou poznatky z praxe. gt Wed, 25 Mar 2015 10:03:55 GMT blog.root.cz-blogComment-869656 https://blog.root.cz/sentan/mongodb-zavislost-za-30-minut/#o869655?utm_source=rss&utm_medium=text&utm_campaign=rss Moje zkusenosti s MongoDB - pekne, rychle, ale kdo to ma porad opravovat? Snad se za tech nekolik let zlepsili, ale naposled kdy jsem to zkoumal to bylo porad ve stavu, ze je nutne mit zdrojova data jeste ulozena bokem, a MongoDB se bere spis jako pracovni cache nez primarni uloziste. To same s replikaci - vetsinou to funguje, ale casem se data "rozjedou" a je nutne udelat resync (a pokud mate write-write repliku, tak si muzete vybrat, ktera data jsou ta "spravna"). CouchDB je trosinku jina hlavne v tom, jak se s daty pracuje - Mongo ma blize ke key-value databazi. U CouchDB neni problem, aby vyvojar pro 50MB dat vyrobil 50GB views na kterych zacne zaviset - v tu chvili se cele kouzlo ztraci, protoze je (na vetsine hardware) rychlejsi mit 50MB v RDBMS se silenou strukturou nez hledat neco v 50GB souboru. Jan Schermer Wed, 25 Mar 2015 07:48:03 GMT blog.root.cz-blogComment-869655 https://blog.root.cz/sentan/mongodb-zavislost-za-30-minut/#o869654?utm_source=rss&utm_medium=text&utm_campaign=rss S Mongo pracuje můj kolega - inspiroval jsem ho používáním CouchDB. Obě databáze, Mongo i CouchDB jsou trochu podobné. Kolega do MongoDB migruje systém webů s rozsáhlými sdílenými daty (MySql). Z aplikace vyhodil asi třetinu kódu - protokol pro předávání dat, o to se teď stará databáze. Prasečí kód (průměrný programátor MySql nezná join) přestěhoval do prasečí struktury dokumentů (každý dokument vypadá trochu jinak). Nevím, jak se to projevuje na rychlosti, ale na čitelnosti kódu prý ano. Já používám pro některé projekty databázi CouchDB - ve firmě máme vytvořenou trochu větší distribuovanou databázi zhruba přes šest počítačů. Podobně používám CouchDB v jednom složitějším serveru pro ukládání konfigurace a vnitřního stavu X různých datových struktur. CouchDB je naprosto blbovzdorná a schopná přežít kdeco. Dokumentové databáze se používají dobře a v mnoha případech mají své využití. Na druhou stranu si nedovedu představit, že bych do podobné databáze uložil některá jiná data, tady u mě vládne PostgreSQL, refereční integrita, joiny a spousta procesorových jader a disků. Takže souhlasím. Jsou aplikace, kde dokumentové databáze miluju. pb. Tue, 24 Mar 2015 16:05:10 GMT blog.root.cz-blogComment-869654 https://blog.root.cz/sentan/mongodb-zavislost-za-30-minut/#o869653?utm_source=rss&utm_medium=text&utm_campaign=rss Tak jako vždycky zázračně jednoduché řešení neexistují. U mongo postupně narazíte na: Žádná podpora pro relace mezi záznamy, inner/left/rig­ht/outer join si děláte ručně. Špatná podpora pro transakce. Náhrada většího SQL dotazu je nepřehledná. Global write lock, i když ve verzi 3 se to mírně zlepšilo. Žádná pokročilá správa cache, používá se disková cache z OS. Zabírá víc místa na HDD kvůli nutné duplicitě. Konkurence umí JSON také. Dokumenty bez pevného schématu lze uložit i do tradičního SQL, asi po dvou minutách přemýšlení, i když ne jako jeden záznam. Od konce loňského roku je pomalejší než SQL konkurence. Ve výsledku zjistíte, že motivace pro zahájení nového projektu s mongo je slabá. his Tue, 24 Mar 2015 14:34:36 GMT blog.root.cz-blogComment-869653 https://blog.root.cz/sentan/mongodb-zavislost-za-30-minut/#o869652?utm_source=rss&utm_medium=text&utm_campaign=rss Tak my jsme v praci zacali pouzivat mongo asi pred dvema mozna trema rokama. A neda se rict ze bychom litovali. Ano dnes sice uvazujeme ze jej mozna v budoucnu nahradime za PostgreSQL (JSONB, vylepseni replikace) diky tomu ze se Postgres znacne za posledni dobu vylepsil a uz jej na par veci pouzivame, tudiz by se zjednodusila architektura. Ale to hodne zavisi jak dopadnou vykonnostni testy pro nase ucely. Osobne typuji ze pokud je mongo 3 o tolik rychlejsi jak slibuji tak u monga zustaneme. Kozzi Tue, 24 Mar 2015 11:46:39 GMT blog.root.cz-blogComment-869652 https://blog.root.cz/sentan/mongodb-zavislost-za-30-minut/#o869651?utm_source=rss&utm_medium=text&utm_campaign=rss Byl bych rád, kdybyste se znovu ozval za pár let. Dost často pozoruju, že lidé, kteří použili mongodb po čase litovali nebo migrovali jinam. Dovedu si ale představit, že je perfektní např. na úlohu typu: Nahraju do toho složitá/nekon­zistentní/neod­povídajíci "moderním" požadavkům data, odladím si konverze/extrakce dat, a posléze CORE data uložím do relační databáze. pb Tue, 24 Mar 2015 09:15:43 GMT blog.root.cz-blogComment-869651