Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Endianness #34

Closed
at15 opened this issue May 18, 2017 · 1 comment
Closed

Endianness #34

at15 opened this issue May 18, 2017 · 1 comment

Comments

@at15
Copy link
Member

at15 commented May 18, 2017

Came across the little and big endian problem when trying to start the on disk storage #32 . Looked around some existing tsdb but couldn't figure out which they are really using and why

Prometheus

InfluxDB

SQLite

Gob

Floating-point numbers are always sent as a representation of a float64 value. That value is converted to a uint64 using math.Float64bits. The uint64 is then byte-reversed and sent as a regular unsigned integer. The byte-reversal means the exponent and high-precision part of the mantissa go first. Since the low bits are often zero, this can save encoding bytes. For instance, 17.0 is encoded in only three bytes (FE 31 40)

Parquet

Arrow

BDB

small endian system

254	fe 0 0 0
255	ff 0 0 0
256	 0 1 0 0
257	 1 1 0 0

sort badly

256
257
254
255

big endian system

254	0 0 0 fe
255	0 0 0 ff
256	0 0 1 0
257	0 0 1 1
@at15
Copy link
Member Author

at15 commented Jun 10, 2017

currently using big endian for all the numbers that are read/write manually, for meta data, use protobuf (should be little endian I suppose), for data blocks, use varint (should be little endian)

@at15 at15 added this to BACKLOG in Local disk storage Jun 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

1 participant