Administrace komentářů

Ako uz bolo napisane, tabulka per databazu, ci dokonca per cluster je pristup realizovatelny aj v postgrese. Potom cez FDW mozno vyriesit efektivny pristup k shardom.

• Vykon importu dat do pgsql sa da ladit roznymi sposobmi - od naznaceneho drop/create indexu pred a po importe, cez prvotny raw import do docasnej tabulky za vyuzitia server side COPY alebo psql \copy alebo cez file_fdw, nasledny import do cielovej tabulky vo forme zlozitejsieho insert selectu, a tiez kombinaciou vsetkych.
• Zo skusenosti s bottleneckmi pri importe - mohol byt nevhodne napisany UPSERT (on conflict...) namiesto selektivneho insertu iba novych dat a updatu iba existujucich, resp. pouzitie inych foriem pomalych constraintov; najhorsi pristup, co som kedy videl bol foreach v nejakej procke.
• HDD overhead cisto texty obsahujucej databazy oproti CSV je logicky: DB musi okrem hodnot ukladat aj dlzky hodnot, indexy (to si jeden proste nepomoze - ak je dovod mat index, tak to zerie disk) a samozrejme mrtve riadky kvoli MVCC a casom aj index bloat. Dalsim dovodom vsak mohla byt denormalizacia a nevhodne zvolene datove typy (varchar->int alebo ->jsonb).
• Za cenu vyssieho naroku na diskovu kapacitu, je mozne v zavislosti od dat a dotazov zvysit rychlost r/w pristupu cez vertikalny partitioning.
• S postgresom by sa vam lahsie vyuzili moznosti paralelneho spracovania dotazov.

To sqlite riesenie vsak vyzera elegantne a ak vam vyhovuje, tak nie je co riesit. Ak potrebujete dalej skalovat, potom zvazte dalsi level shardingu, kedy najpocetnejsie prefixy rozbijete na mensie tabulky, pricom datovu integritu zabezpecite na aplikacnej urovni pocas importu. Tiez sa da uplatnit (opat v zavislosti na povahe a pouziti dat) vertikalny partitioning - teda u vas skor vertikalny sharding => rozne stlpce toho isteho prefixu v roznych tabulkach - u vas sqlite databazach - spajanych cez datovo a vypoctovo nenarocne integer ID (na ktore si v dalsej tabulke/databaze prelozite ten hrozny VARCHAR(38)).

Ja by som import (t.j. write) riesil cez copy-on-write. Idealne cez spominane SSH. A to tak, ze by som importoval do kopie aktualnej verzie databazy a na NFS ju zverejnoval premenovanim (snapshot FS?). Nevyhodou by mohlo byt, ze pocas importu by sa priebezne zapisalo na disk viac nez raz tolko dat, ako tam uz bolo - takze by sa asi rychlejsie zodrali - ale tak disky su lacne :P

Ak je spracovanie (read) vzdy riesene cez download a lokalny pristup, tak by mozno stala za zvazenie p2p distribucia - cez lokalnu torrent siet.

Skoda, ze nevidime priklad dat a dotazov nad nimi. Mozno by sa ukazali cesty smerujuce k vyssim normalnym formam.