logo
22.10.2020 22:18
1
Ak si vezmem nejaky jednoduchy binarny log, kde nechcem pouzivat vobec alebo vyhradne type-length-value/length-value(TLV/LV) format, ale chcem aj/len jednoducho oddelit zaznamy, aky znak alebo retazec by na to mohol byt najvhodnejsi?

Napriklad ak mam json, tak ten osetri, mimo ineho, aj \n(novy riadok LF) takze \n sa moze pouzit ako oddelovac zaznamov, naprikald ako v jsonl. Ale to je textovy format a mna zaujima binarny.

TLV respektive skor LV je fajn, lenze clovek musi zacat od 0 aby mohol potom skakat na dalsie zaznamy, kdezto s oddelovacom staci skocit hocikam a len citat dopredu kym sa nenajde oddelovac.

Uz som to riesil viac krat no nastastie nikdy neislo o nieco kde islo o rychle citanie a teda som mohol vzdy zacat od 0. Ale do buducna by som chcel vediet ako na to. Co fici, co sa pouziva, ako to riesia iny.
23.10.2020 08:45
2
Používám řídící ascii znaky, které nejsou vykreslitelné. V enterprise databázích můžeš často najít BELL alias \a, protože má svoji escape sekvenci. Když můžeš zapsat cokoliv tak stačí jít od začátku a používat znaky \01 \02 \03 atd.

Zároveň tyhle znaky můžeš bezpečně odstranit z ascii/utf textu, protože tam nemají nikdy co dělat. Ideální na ukládání formátů jako xml,json, na binární data musíš vždy používat offset a velikost případně je nejprve převést do ascii (base64).
23.10.2020 20:03
3
Asi to není co hledáš, ale existuje MessagePack.
23.10.2020 20:16
4
Původně odeslal TomášX
Zároveň tyhle znaky můžeš bezpečně odstranit z ascii/utf textu, protože tam nemají nikdy co dělat. Ideální na ukládání formátů jako xml,json, na binární data musíš vždy používat offset a velikost případně je nejprve převést do ascii (base64).
no hej, ale co ked uz mam hotovy zaznam v bytovej forme kedy nemam pristup k povodnym datam pred serializovanim alebo kompresiou. tzn. nemozem si diktovat ktore znaky sa escapuju a ktore nie. proste mam uz zaznam ako []byte pole a nic viac neviem.
23.10.2020 20:20
5
asi jsem dotaz pochopil jinak, ale pokud jde o hotové formáty, je jich opravdu dost. MessagePack je už poměrně přežitý, Z těch dnes nepoužívanějších kolem mě:

1) avro
binární plně strukturovaný formát, možnost mít schéma (používá json schema) uvnitř s daty, podpora napříč jazyky, docela parsování

2) protobuf
binární strukturovaný formát s podporou rpc, schéma je mimo data a je nutné sdílet dopředu

3) cap n proto
binární formát s nulovou režií pro enkodování/dekódování, nutnost k datům přistupovat přes getter/settery

4) arrow
právě se dostává do stabilní verze, nová hvězda, shodný paměťový layout pro data v paměti, na disku, na gpu, levné enkodóvání a parsování

5) thrift
primárně pro komunikaci mezi službami jako náhrada xmlrpc

6) messagePack (jak jsi zmiňoval)
pěkný formát s in-place editací bez enkodování, je ale těžké s ním pracovat mimo striktně typové jazyky (java, c++, D), má horší validace


Pak existují pěkné věci jako pandas, dataframe, ale to je jen pro python.
23.10.2020 21:33
6
Původně odeslal node
no hej, ale co ked uz mam hotovy zaznam v bytovej forme kedy nemam pristup k povodnym datam pred serializovanim alebo kompresiou. tzn. nemozem si diktovat ktore znaky sa escapuju a ktore nie. proste mam uz zaznam ako []byte pole a nic viac neviem.
tak to je boj s pravděpodobností, můžeš hledat tak dlouhou posloupnost, která tam “určitě” nebude.

Za dob kamených jsme používali trik s kompresí, komprese totiž nikdy nenechá třeba čtyři bajty po sobě nulové, takže gzip binárních hodnot a pak \00\00\00\00.

Lze také nejprve projít určitý blok k uložení, zjistit co tam není a vybrat si oddělovač, který nemá konflikt, takovýhle oddělovač pak můžeš uvést v třeba v prvních dvou bajtech každého bloku dat, který bude obsahovat N zpráv.