abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 06:00 | Komunita

    Vydání Debianu 11 s kódovým jménem Bullseye je naplánováno na sobotu 14. srpna.

    Ladislav Hagara | Komentářů: 3
    včera 23:55 | Nová verze

    Google Chrome 92, konkrétně verze 92.0.4515.107, byl v úterý prohlášen za stabilní. Opraveno bylo 35 bezpečnostních chyb. Pete LePage doteď nepublikoval oficiální přehled novinek (New in Chrome, YouTube). Publikován byl jenom seznam novinek v nástrojích pro vývojáře (YouTube). Sundar Pichai dnes na Twitteru oznámil vylepšení integrované hry chrome://dino/.

    Ladislav Hagara | Komentářů: 6
    včera 08:00 | Nová verze

    Firewall firewalld (Wikipedie, GitHub) dospěl do verze 1.0.0. Upozornit je nutno na nekompatibilní změny. Zrušena byla podpora Pythonu 2.

    Ladislav Hagara | Komentářů: 0
    včera 01:11 | Komunita

    Milí priatelia Mozilly, tím Mozilla.sk hľadá pomoc v radoch dobrovoľníkov, ktorí sú ochotní pomáhať nám s týmto projektom. Vítaná je akákoľvek pomoc, no aktuálne hľadáme hlavne ľudí, ktorí by sa starali o aktuálnosť lokalizovaných článkov na stránkach podpory SUMO. Projekt je doteraz veľmi sviežo udržiavaný, no naše kapacity prekročili všetky limity a už nestíhame. Ak sa nám v najbližšej dobe nepodarí rozšíriť tím, bude nutné zo stránok

    … více »
    Ladislav Hagara | Komentářů: 19
    22.7. 12:00 | Nová verze

    PeerTube (Wikipedie), svobodná decentralizovaná platforma pro pro sdílení a přehrávání videí, byla vydána ve verzi 3.3. Z novinek lze zmínit možnost snadné úpravy úvodní stránky, vyhledávání v seznamech videí nebo kratší odkazy na videa.

    Ladislav Hagara | Komentářů: 28
    22.7. 09:00 | Komunita

    Vývojáři svobodného (GPLv3) šachového enginu Stockfish (Wikipedie) na svém blogu informují, že podali žalobu na společnost ChessBase (Wikipedie): ChessBase prodává šachový engine Fat Fritz 2 vycházející z enginu Stockfish a své uživatele neinformuje o GPL licenci a neposkytuje jim zdrojové kódy.

    Ladislav Hagara | Komentářů: 12
    22.7. 08:00 | Komunita

    Alyssa Rosenzweig se v příspěvku na blogu společnosti Collabora věnuje reverznímu inženýrství GPU Mali G78 s mikroarchitekturou a instrukční sadou Valhall. Po měsíci práce byla vydána referenční instrukční sada (pdf).

    Ladislav Hagara | Komentářů: 2
    22.7. 07:00 | Zajímavý software

    LiveKit je nedávno uvolněna open source platforma pro realtimovou komunikaci. Zdrojové kódy jsou k dispozici na GitHubu.

    Ladislav Hagara | Komentářů: 0
    21.7. 13:11 | Nová verze

    Po čtyřech měsících vývoje od vydání verze 5.7 byla vydána nová verze 5.8 svobodného open source redakčního systému WordPress. Kódové označení Tatum bylo vybráno na počest amerického jazzového klavíristy Arta Tatuma (Yesterdays).

    Ladislav Hagara | Komentářů: 25
    21.7. 08:00 | Bezpečnostní upozornění

    Společnost Qualys zveřejnila na svém blogu informace o v upstreamu již opravených bezpečnostních chybách CVE-2021-33909 v Linuxu (txt) a CVE-2021-33910 v systemd (txt). Chyba v Linuxu (fs/seq_file.c) je zneužitelná k lokální eskalaci práv.

    Ladislav Hagara | Komentářů: 7
    Preferuji
     (62%)
     (28%)
     (10%)
    Celkem 317 hlasů
     Komentářů: 61, poslední dnes 12:19
    Rozcestník

    Dotaz: 3700 tabuliek

    21.6. 14:36 elon
    3700 tabuliek
    Přečteno: 1088×

    Dobry den,

    rad by som poznal vas nazor na nasledujuci usecase, popripade rady ako dalej.

     

    Mame prisne strukturovane vedecke data. Logicky su rozdelene do tabuliek podla prefixu. Kazda tabulka zodpoveda inemu prefixu. V podstate su to key-value tabulky (80% citanie, 20% zapis) s tym, ze hodnota ma 7 atributov a je rozdelena do stlpcov. Kluc stlpec VARCHAR(38) s unique btree indexom. Ostatne stlpce su VARCHAR(64).

     

    Historicky sme ukladali data do jednej Postgresovej super tabulky.

    Potom sme super tabulku rozdelili na particie (podla prefixu)

    Zitili sme, ze Postgres ma velky overhead - vyexportovane CSV malo 5GB, tabulka na disku zaberala 7GB.

    Ked sa velkost databazy dostala na velkost cca 10TB uz sa s Postgresom nedalo rozumne pracovat.

    Importovanie dat z 10GB CSV (prikaz COPY) trval viac ako 24hodin.

    Rozhodli sme sa opustit Postgres a tabulky vyexportovat do 3700 SQLITE databaz podla prefixu na 10GBE NFS storage.

    3-4 roky to bolo fajn. Data pribudali. Dostali sme sa na hranicu 30TB a kazda SQLITE databaza na priemerne cca 11GB.

     

    SQLITE je super, velmi dobre sa s tym pracuje, majma Python, Pandas. No zaciname pomaly narazat na limity SQLITE aj pri pouzivani tuningu s .PRAGMA parametrami.

     

    Rad by som sa opytal ci by ste mi vedeli odporucit nejaku technologiu na ukladanie tabuliek a import dat v rozumnom case. Hlavnu prioritu ma integrita dat, podpora pythonu. Davame prednost single serveru pred clustrom. Dakujem.


    Řešení dotazu:


    Odpovědi

    Heron avatar 21.6. 16:25 Heron | skóre: 52 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Moc nerozumím, proč jste opustili postgresql. Jasně, jedna DB (tabulka) o velikosti 10TB už něco váží, zejména update indexů trvá, ale to se dá obejít tím, že se dropne index, nalijou se tam data a na konci index opět vytvoří. Rozdělit data do jednotlivých tables / databases můžete klidně i v postgresu. 11GB per database není vůbec nic.

    Takže zkuste udělat totéž, co děláte se sqlite (tedy takto nasekaná data vrátit zpět do PG) a uvidíte.

    Ale celkem fascinující řešení nad sqlite. Je to skvělá knihovna pro robustní ukládání dat a single user přístup.
    21.6. 17:00 Kit | skóre: 45 | Brno
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    SQLite na NFS není dobře.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    Heron avatar 22.6. 10:53 Heron | skóre: 52 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Proč? Pozor je potřeba dát pouze pokud se má sdílet jeden soubor mezi více klientů (pro zápis), tam je NFS skutečně nevhodný (https://www.sqlite.org/faq.html#q5), proto jsem taky psal "single user přístup". Jinak je SQLite skvělá robustní knihovna pro ukládání dat, viz také odkazovaný článek níže.
    23.6. 09:25 elon
    Rozbalit Rozbalit vše Re: 3700 tabuliek

    Ano, samozrejme chapeme vyhody a nevyhody NFS a single user access.

     

    Vyhodou je akasi "kniznica" SQLite databaz, ked administrator ma povolenie prepisovat subory. Ostatni kolegovia len citanie. Dalsiu velku vyhodu, ktoru sme ziskali je portabilita. Staci si nakopirovat databazu/databazy ku sebe na pocitac. Ak chce clovek pracovat nemusi mat pripojenie k serveru.

    21.6. 21:33 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Nenapsal jste, co s těmi daty děláte. Ale také bych se přikláněl k použití PostgreSQL, nevidím důvod, proč by to neměla zvládnout.
    22.6. 00:23 debian+ | skóre: 25 | blog: analyzy
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Zmeň ukladanie v tabuľkách indexovanie z typu z Btree na HASH tabuľky (v MariaDB je default BTree a dá sa v nej zmeniť). BTree ma limity.

    Ak to más zdielané, tak neťahaj cez NFS, ale trebars sa dotazuj cez HTTP.

    Hm. Také veci by ma bavili optimalozovať. Indexoval som pri štatistikách, ktoré som robil do 5M stránkoch, všetko sám programoval a prístup k dátam bol rýchly.
    debian.plus@protonmail.com
    22.6. 09:25 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    O MariaDB nebyla v dotazu vůbec řeč. U databáze, na kterou jsou kladené trošku větší nároky, bych MySQL/MariaDB zvažoval jedině v případě, kdy bych odněkud věděl, že zrovna tenhle use case zvládá MySQL/MariaDB skvěle.
    22.6. 11:00 debian+ | skóre: 25 | blog: analyzy
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Spominal typ indexovanie BTree a na take velke mnozstvo nie je hodne. Vyslo mi vypoctom, ze tam ma (max) 20-30 milion zaznamov na DB.

    O MariaDB pisem, lebo ako referencie mojej skusenosti.

    P.S.: Ako to robia profici vid., resp. este kukni orig. subory: https://www.root.cz/clanky/vymenit-200-milionu-certifikatu-za-den-let-s-encrypt-pripravuje-nejhorsi-scenar/
    debian.plus@protonmail.com
    22.6. 12:05 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Vhodnost indexu závisí hlavně na datech a na tom, co je potřeba s daty dělat. Na základě hash indexu např. záznamy neseřadíte.
    23.6. 10:49 elon
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    U nas je na prvom mieste integrita dat. Musim datam ulozenym v DB verit. Nesmu sa poskodit popripade inak degradovat.

    Rychlost pristupu nie je moc dolezita. S SQLite databazou sa da super pracovat v Python, ci uz cez Pandas alebo SQL Alchemy.

    HTTP je zbytocna vrstva. Potrebujeme priamy pristup k datam, neviem si predtstavit ako by sme v Pandas pracovali datami obalenymi v HTTP.
    24.6. 10:39 Kit | skóre: 45 | Brno
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    HTTP není úplně zbytečnou vrstvou, zejména pokud se nachází na stejném serveru jako data. Při vyhledávání je řádově rychlejší než přímý přístup k datům. V případě SQLite se velmi dobře uplatní cache souborového systému.

    Data z HTTP serveru se dají přenášet jako plain, JSON, XML, HTML nebo cokoli dalšího, nejlépe rovnou s potřebnou agregací.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    25.6. 19:09 debian+ | skóre: 25 | blog: analyzy
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Btree je náročný na memory (pre low cost maschiny), tak som si vytvoril iný spôsob, ktoré nebude naročne na RAM pamät, bude rychle a a dôkaze nekonečno spracovať dát ("key" => "value" typu) a pôjde to aj bežnom železe.
    debian.plus@protonmail.com
    26.6. 00:51 samalama
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    ... a dôkaze nekonečno spracovať dát...

    ja som vzdycky vedel, ze na to mas...
    26.6. 01:05 debian+ | skóre: 25 | blog: analyzy
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    …a dokáže nekonečno spracovať…
    debian.plus@protonmail.com
    AraxoN avatar 22.6. 07:58 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Na key-value údaje je SQL overkill. Neskúšali ste Berkeley DB?
    22.6. 09:23 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Co na tom NoSQL databáze bude moci udělat efektivněji? Zejména když jsou tam sekundární indexy.
    AraxoN avatar 22.6. 09:59 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Aké sekundárne indexy? OP píše len o primárnom indexe.

    A nehovorím o NoSQL databázach, len o Berkeley DB. To je súbor na disku, ktorý obsahuje strom s údajmi. Nič viac.

    Čo by na tom mohlo byť rýchlejšie? Nerobí sa komunikácia medzi procesmi, neparsuje sa SQL, nerieši sa konkurenčný prístup, copy-on-write, ACID ani ďalšie veci, ktoré plnohodná databáza má, ale v danom use-case možno nie sú potrebné.

    Ak neveríte, vyskúšajte si to. Berkeley DB je na key-value databázy niekoľkonásobne rýchlejšia než SQL, a vo väčšine prípadov je dokonca rýchlejšia než memcached.
    22.6. 12:08 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Aha, přehlédl jsem se, viděl jsem „každý stlpec“ a ono je to „kluc stlpec“. Omlouvám se.
    A nehovorím o NoSQL databázach, len o Berkeley DB. To je súbor na disku, ktorý obsahuje strom s údajmi. Nič viac.
    Berkeley DB je jedna z NoSQL databází. Ano, vznikla dřív, než se jim tak začalo říkat, to ale na věci nic nemění.
    23.6. 11:03 elon
    Rozbalit Rozbalit vše Re: 3700 tabuliek

    Berkley DB, bol horucim kandidatom ked sme odchadzali od Postgres.

     

    Pamatam si, ze najvacsimi nevyhodami boli: lebo Oracle, lebo licencia, lebo Java, lebo SQLite ma lepsiu podporu v Python.

    Takze viac politicke rozhodnutie ako logicke :).

    23.6. 13:41 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Asi si pletete Berkeley DB s Berkeley DB Java Edition.
    AraxoN avatar 23.6. 17:38 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Myslel som pôvodnú Berkeley DB, knižnicu napísanú v C, dostupnú pod BSD licenciou. Produkty, ktoré pod týmto menom do sveta uvádza Oracle, nepoznám.
    Heron avatar 22.6. 10:48 Heron | skóre: 52 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Pokud je prioritou odolnost vůči poškození dat, doporučuju tento článek. Je sice již staršího data, ale ledacos napoví. Na straně 12 je porovnání odolnosti různých databází proti chybám v FS. SQLite z toho vyšel jako vítěz, na druhém místě PostgreSQL.
    22.6. 14:14 okbobcz | skóre: 3
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Tam děláte něco divného - import 10GB CSV by Postgres měl zvládnout do 10-20 minut - 24 hodin je úlet - tam muselo něco být hodně špatně.

    Teoreticky si dovedu představit, že vám bloatnul index, ale ani to by vám nemělo prodloužit import na 24 hodin.

    Jinak Postgres má docela velkou režii - je to multiuživatelská databáze - optimalizovaná na OLTP. Řádek v Postgresu má docela velkou hlavičku 21 bajtů.

    Pokud máte indexy, tak je důležité, aby se podstatné části indexu udržely v RAM. Jakmile vám začnou vypadávat z cache, a musí se opakovaně načítat, tak se jakákoliv databáze brutálně zpomalí. Klasické doporučení říká, že RAM ku velikosti db by měla být 1/10 max 1/100. Takže na 30T db byste měli mít 3T RAM (v nejhorším případě 300GB)
    22.6. 17:06 Xerces
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Hodně samozřejmě záleží na použitém HW, ale import 10GB za den to je málo i na sekretářku. :-) Myslím, že když budete hledat, tak se vám to musí povést optimalizovat. Zkušenost z nedávné doby ... Nahrání cca 1,2TB z textových souborů na 8-mi jádru (SMT4) 2h včetně indexů. Ale nebyl to tedy PostgreSQL.
    23.6. 10:35 elon
    Rozbalit Rozbalit vše Re: 3700 tabuliek

    Hlavny problem Postgresu bol v particiach.

     

    Pouzivalili sme particie zalozene na LIST. Nieco ako

    CREATE TABLE abcdefgh (id INTEGER, kluc VARCHAR(38), prefix VARCHAR(3), hodnota1 INTEGER, hodnota2 VARCHAR(64) ) PARTITION BY LIST(prefix);

    CREATE TABLE abcdefgh_part_prefix PARTITION OF abcdefgh FOR VALUES IN ('prefix1');

     

    Problem bol velky overhead na disku a potom pri importe CSV Postgres musel kazdy jeden riadok urobit:

    - match na prefix (prefixov je cca 3700) aby zaznam zaradil do pozadovane particie

    - prehladat zlozeny unique index stlpcov kluc+prefix aby sa vyhol duplicitam

     

    Pri importe sme prepli tabulku do unlogged modu. Prinieslo to zrychlenie, avsak nerelevantne.

    23.6. 13:44 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Myslím, že je to jen otázka správného postupu při importu dat, případně vyladění databáze. Víc by určitě dokázal poradit Pavel Stěhule.
    24.6. 09:59 okbobcz | skóre: 3
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    tam mohl dělat problém vyšší počet partitions - pro starší verze se doporučovaly tak nižší stovky partitions. a pak je potřeba asi mít dostatečně nadimenzovaný shared buffers - aby se gró toho indexu udrželo v shared_bufferu
    22.6. 16:51 Xerces
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Doufám, že to nebude vypadat, jako že rýpu, ale můžete alespoň naznačit co je to za vědecká data, kde je primární klíč varchar(38)?
    22.6. 18:23 a1bert | skóre: 22
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    hadam nejaka LGBT :D
    23.6. 10:39 elon
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Velmi zjednodusene su to materialove tabulky s niekolkymi fyzikalno-chemickymi parametrami, ktore boli namerane alebo inak ziskane.
    23.6. 11:12 Ovrscout
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Sqlite je obecně dost rychlé pokud neděláte nějaké fujky věci(což použití skrze NFS může být, s touto kombinací nemám zkušenost)

    Ale než budete optimalizovat, nebo měnit technologii, tak by bylo dobré najít a změřit kde vlastně je problém. Aby jste nebil překvapen.

    Pár bodíků pro začátek:
    • Jaké jsou typy dotazů a jak dlouho trvají -> nejsou některé abnormálně pomalé? Kde vás trápí rychlost?
    • Jaké jsou počty dotazů - dle typů dotazu - které se typicky posílá na jednu databázi (pro jednu úlohu, za minutu, atp).
    • Jaký je souběh přístupu k všem databázím na NFS?
    • Jaký je rozdíl v rychlosti při přístupu k databázi z NFS(za běžného vytížení ostatními i pokud běží jen jedna aplikace - pokud možno) a z lokálního disku?
    • Na serveru, i clientu/ech zkontrolovat/doměřit vytížení sítě, CPU, Disku a RAM jestli někde nejste plně vytíženi.
    Je to docela dost práce, ale mohlo by z toho vypadnout kde je problém. Případně to může vést k potřebě změřit/zkontrolovat další věci(indexy, parametrizované dotazy, velikost cache(včetně místa pro indexy ),sqlite temp soubory, ..., síť, atp.). Až pak bych zvažoval různá řešení od tuningu jednotlivých komponent až po změny v architektuře (třeba lokální cache?), a až nakonec případná změna DB.
    23.6. 11:13 Ovrscout
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    chjo, "Nebyl"
    28.6. 10:46 elon
    Rozbalit Rozbalit vše Re: 3700 tabuliek

    Toto su pekne otazky na ktore by sme sa mali zamerat. Mate uplnu pravdu uzkym hrdlom je NFS a import data nez NFS. Dakujem za tipy.

     

    Tieto otazky vychadzaju zo standardneho modelu databazovych systemov - Client/Server. Pouzivali sme tuto architekturu pri rieseni s Postgresql. No koli pomalosti sposobenynou velym mnozstvom particii zalozenych na PARTITION BY LIST(prefix) a UNIQUE contraint sme presli na SQLite. https://www.abclinuxu.cz/poradna/databaze/show/470578#19

    V sucasnoti pouzivame SQLite databazy ako "kniznicu" pristupnu cez NFS s prisne strukturovanymi datami. Kolegovia vedia pracovat s SQLite databazami v read-only cez NFS share alebo si SQLite databazy nakopiruju k sebe na PC. Len administrator ma pravo zapisu/prepisu novych dat - prave koli tomu ze SQLite nie je vhodna na multi access.

     

    Problem nastava, ked administrator dostane balik napr. 50-80GB surovych dat. Jedna sa o velky CSV subor. Musi data roztriedit podla prefixov (3700) a naimportovat data do jednotlivych SQLite databaz (3700).

    Toto je asi najvacsi problem. Triedenie a importovanie podla prefixov.

     

    Zatial to vyzera, ze najlepsim riesenim bude SSH pristup na server a import nebude robit cez NFS ale lokalne na servery. No nie som moc spokojny s tymto riesenim.

    28.6. 11:02 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Zatial to vyzera, ze najlepsim riesenim bude SSH pristup na server a import nebude robit cez NFS ale lokalne na servery. No nie som moc spokojny s tymto riesenim.
    Já bych zkusil PostgreSQL. Odpadnou vám tím problémy se sdílením dat, protože je budete mít na jednom serveru, ke kterému se může připojit kdokoli.
    23.6. 17:28 j
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Problem je, ze ty vic udaju neuvadis nez uvadis ...

    +20TB za 4 roky = cca 5TB rocne => rekneme 25GB/den (pracovni). Pokud budu vychazet z tvyho udaje 20%, tak to znamena, ze se denne precte cca 100GB. Na to vazne netreba nijak uber HW ani SW. Ovsem tyhle cisla by sis mel realne zjistit a overit. Ve skutecnosti pak nesejde na GB, ale na mnoztvi dotazu.

    Jak se s tema datama pracuje? Bezne v databazich byva 90+% dat, ke kterym se vubec nepristupuje a prave to mnoztvi dat se kteryma se realne pracuje ovlivnuje dimenzovani naprosto vseho.

    Rekneme ze z kristalovy koule vyvestim, ze realne pracujes s desetinasobkem denni davky = 1TB dat => ramka serveru by mela byt aspon 1TB. To je ti ovsem nanic s sqlite.

    U storage nehraje roli konektivita, ale IOps. To je limitujici faktor. NFS bych pak povazoval za ... hodne blbej napad, stejne jako jiny sitofilesystemy. Vkladas overhead tam, kde na to libovolna databaze je nejcitlivejsi = na store. Tam patri FC/iSCSI, pokud to neni lokalni uloziste.

    ---

    Dete s tim guuglem dopice!
    28.6. 10:56 elon
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Ano,

    mate pravdu najvacsim problemom je NFS. Preto ideme vyskusat pristup cez SSH a triedenie/import/aktualizacia dat priamo na servery. s tym ze NFS zostane stale na citanie. Aj ked toto riesenie sa mi moc nepaci. Ale vyzera ze nateraz je to asi najpouzitelnejsie.

    Stale hladame sposob/technologiu ako pracovat lepsie pracovat s tymito datami.
    Řešení 1× (Jеdna)
    28.6. 03:10 debian+ | skóre: 25 | blog: analyzy
    Rozbalit Rozbalit vše Re: 3700 tabuliek
    Kukni aj tohle.
    debian.plus@protonmail.com

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.