41–50 of 107 posts
Earlier quoted context omitted.
I was expecting constraint logic programming!
I thought it was going to be about trees until I saw the URL…
I clicked, found out, and was dissapointed that this wasn't about wood.
Maybe I should start that woodworking career change already.
This just in, Uber rediscovers what all us database people already knew, structured data is usually way easier to compress and store and index and query than unstructured blobs of text, which is why we kept telling you to stop storing json in your databases.
Earlier quoted context omitted.
Does anyone have a simple explanation of how it structures the log data?
Figure 2[2] from the article is pretty good. [2]: https://blog.uber-cdn.com/cdn-cgi/image/width=2216,quality=8...
Earlier quoted context omitted.
There's nothing wrong with storing json in your database if the tradeoffs are clear and it's used in a sensible way. Having structured data and an additional json/jsonb column where it makes sense can be very powerful. There's a reason every new release of Postgres improves on the performance and features available for the json data type. ( https://www.postgresql.org/docs/9.5/functions-json.html )
> There's nothing wrong with storing json in your database if the tradeoffs are clear and it's used in a sensible way. Of course. If there was, postgres wouldn't even support it. The GP's rant is usually thrown against people that default into json instead of thinking about it and maybe coming up with an adequate structure. There are way too many of those people.
Earlier quoted context omitted.
Maybe people do things like that because: - their application parses and generates JSON already, so it's low-effort. - the JSON can have various shapes: database records generally don't do that. - even if it has the same shape, it can change over time; they don't want to deal with the insane hassle of upgrade-time DB schema changes in existing installations The alternative to JSON-in-DB is to have a persistent object…
It's a hassle to change shape in a db possibly, but have you lived through changing the shape of data in a json store where historical data is important ? You either dont care abt the past and cant read it anymore, version your writer and reader each time you realize an address in a new country has yet another frigging field, or parse each json value to add the new shape in place in your store. Json doesnt solve the…
Disclaimer: I run Developer Relations for Lightrun. There is another way to tackle the problem for most normal, back-end applications: Dynamic Logging[0]. Instead of adding a large of amount of logs during development (and then having to deal with compressing and transforming them later) one can instead choose to only add the logs required at runtime. This is a workflow shift, and as such should be handled with care.…
This just in, Uber rediscovers what all us database people already knew, structured data is usually way easier to compress and store and index and query than unstructured blobs of text, which is why we kept telling you to stop storing json in your databases.
Postgres has excellent JSON support, it's one of my favorite features, it's a nice middle ground between having a schema for absolutely everything or standing up mongodb beside it because it's web scale. Us in particular, we leverage json-schema in our application for a big portion json data and it works great.
This means we can encode objects in your program directly into objects in the database. It also means we can natively encode documents, sub-documents, arrays, geo-spatial coordinates, floats, ints and decimals. This is a primary function of the driver.
This also allows us to efficiently index these fields, even sub-documents and arrays.
All MongoDB collections are compressed on disk by default.
(I work for MongoDB)
Disclaimer: I run Developer Relations for Lightrun. There is another way to tackle the problem for most normal, back-end applications: Dynamic Logging[0]. Instead of adding a large of amount of logs during development (and then having to deal with compressing and transforming them later) one can instead choose to only add the logs required at runtime. This is a workflow shift, and as such should be handled with care.…
We had a dashboard where you could flip on certain logging only as needed.
I really didn't know whether this was going to be an article about structuring sequential information or about a more efficient way to produce wood. Hacker news! I clicked, found out, and was dissapointed that this wasn't about wood. Maybe I should start that woodworking career change already.