|
Rex-Goliath posted:because you can store full entities which can be as complex as you want without having to deal with setting up all the tables and relationships first. if you’re using xml you can also use namespaces to version your schema which allows you to refractor data on a production system with zero downtime or gymnastics which is nice this smells like MarkLogic evangelism Rex-Goliath posted:if you know what you’re doing though you can build some pretty crazy poo poo in months that would be effectively impossible for a relational system like healthcare.gov 
|
#
?
Jan 15, 2019 22:30
|
|
|
|
| # ? May 3, 2024 15:42 |
|
|
gonadic io posted:There is always a schema. Whether this schema explicitly exists in a file, or is implicitly constructed by the fields that the code looks for is up to you. 
|
|
#
?
Jan 15, 2019 22:37
|
|
|
i wonder how much computational power is spent both serializing and deserializing json
|
|
#
?
Jan 15, 2019 22:39
|
|
|
Share Bear posted:i wonder how much computational power is spent both serializing and deserializing json anything > 0 cycles is a waste imho
|
|
#
?
Jan 15, 2019 22:40
|
|
|
apache did this https://avro.apache.org/ so I'm going to guess a heckin' lot
|
|
#
?
Jan 15, 2019 22:48
|
|
|
Rex-Goliath posted:refractor data on a production system with zero downtime or gymnastics which is nice lol
|
|
#
?
Jan 15, 2019 22:52
|
|
|
https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats there's no shortage
|
|
#
?
Jan 15, 2019 22:52
|
|
|
Rex-Goliath posted:if you know what you’re doing though you can build some pretty crazy poo poo in months that the victim company will spend millions fixing for the next decade
|
|
#
?
Jan 15, 2019 22:53
|
|
|
what if you just used a filesystem as a database? wouldn't that be like peak unix because ~everything's a file~
|
|
#
?
Jan 15, 2019 22:58
|
|
|
Farmer Crack-rear end posted:what if you just used a filesystem as a database? wouldn't that be like peak unix because ~everything's a file~ I would also like to know what the downside of doing this is for small document stores just a giant directory, and the index is the file name
|
|
#
?
Jan 15, 2019 22:59
|
|
|
bring back the mainframe it was wrong for us to have ever left it
|
|
#
?
Jan 15, 2019 22:59
|
|
|
i did this at the last company i worked for and quit my job. now i'm doomed to forever look over my shoulder for the guy who replaced me.
|
|
#
?
Jan 15, 2019 23:01
|
|
|
abigserve posted:I would also like to know what the downside of doing this is for small document stores besides the db handling resource contention and consistency, nothing really. how is that even different from small data sets that you can hold in a single file that you load at run time?
|
|
#
?
Jan 15, 2019 23:01
|
|
|
destroy every last database they are the man's tool for keeping us down and branding us like cattle rise up rise up except mongo it may or may not brand you as cattle depending
|
|
#
?
Jan 15, 2019 23:04
|
|
|
abigserve posted:I would also like to know what the downside of doing this is for small document stores the downside is that most filesystems are sort of shockingly bad at reliably storing data. with postgres you can safely assume that if you insert a row, subsequent queries will either not see that row or will see the complete row that you inserted. doing this with a filesystem requires an akward dance of writing to a temporarily file, fsyncing it (and then calling the non-portable real fsync for your platform that actually works) and then moving it to the final location and praying that moves are actually an atomic operation.
|
|
#
?
Jan 15, 2019 23:10
|
|
|
thankfully if you're in nosql land you probably don't care about any of that in the first place just yolo that poo poo to disk
|
|
#
?
Jan 15, 2019 23:13
|
|
|
Rex-Goliath posted:because you can store full entities which can be as complex as you want without having to deal with setting up all the tables and relationships first. cool so it enables me to be super sloppy with my design
|
|
#
?
Jan 15, 2019 23:13
|
|
|
My Linux Rig posted:cool so it enables me to be super sloppy with my design my current client has multiple different applications using the same tables to store different data. relational isn’t some magic wand to fix stupid like some of you are pretending it is
|
|
#
?
Jan 15, 2019 23:18
|
|
|
defining a schema is a-ok but managing schema changes gets tired quickly that said i only see document databases proposed in the worst places, like "that place we keep writing inconsistent data to? the one we do tons of ad-hoc queries on? let's use a semipersistent key-value store with two supported language bindings"
|
|
#
?
Jan 15, 2019 23:25
|
|
|
imo a good use for memory based document sores is as an ephemeral cache when you want a more powerful queries than you get with a typical k/v store.
|
|
#
?
Jan 15, 2019 23:31
|
|
|
abigserve posted:apache did this https://avro.apache.org/ so I'm going to guess a heckin' lot avro is mysteriously slow, i've never seen a benchmark where it parses faster than json no real reason it should be that way afaik but for current implementations thrift or protocol buffers will beat it handsomely if you're worried about cycles 
|
|
#
?
Jan 15, 2019 23:41
|
|
|
i wish i had an excuse to gently caress around with foundationdbs document and record layers at work but atm storing our data in foundationdb instead of the existing mysql database would be the purest of wankery
|
|
#
?
Jan 15, 2019 23:53
|
|
|
suffix posted:defining a schema is a-ok but managing schema changes gets tired quickly writing code that deals with objects with a bunch of different shapes because you didn't migrate the existing data to the new schema is pretty tiring too
|
|
#
?
Jan 16, 2019 00:16
|
|
|
suffix posted:avro is mysteriously slow, i've never seen a benchmark where it parses faster than json for reference I would never use avro over protocol buffers or regular json and in fact when i had the explicit option recently I serialized JSON itself but I reckon the fellas at apache know more about it then I do and the concept of it makes sense, so it must have some use
|
|
#
?
Jan 16, 2019 00:44
|
|
|
Farmer Crack-rear end posted:what if you just used a filesystem as a database? wouldn't that be like peak unix because ~everything's a file~ from earlier: DONT THREAD ON ME posted:i've been reading about this revolutionary new document store called a file system
|
|
#
?
Jan 16, 2019 02:04
|
|
|
After review, Fedora has determined that the Server Side Public License v1 (SSPL) is not a Free Software License. you're not finding a new mongodb in fedoras repos anytime soon
|
|
#
?
Jan 16, 2019 09:00
|
|
|
suffix posted:defining a schema is a-ok but managing schema changes gets tired quickly i sort of have the opposite view: designing a schema and the software that operates on it is indeed duplicated and not very useful work, when it comes to schema migration, management and general future-proofing though the schema is great to have overall the schema bit ought to integrate better still with type systems, typically any error from the database is just fatal: the software is unlikely to have the means to understand or even report it in an intelligible way (this is where i as usual allude to kx k/q where tables are first class types). still, even without that whenever you find yourself having two systems interacting with the same database (even if, as will often be the case with nosql stuff, one gatekeeps for the other) a reasonably powerful schema system and well designed schema is great
|
|
#
?
Jan 16, 2019 11:06
|
|
|
Tankakern posted:After review, Fedora has determined that the Server Side Public License v1 (SSPL) is not a Free Software License. they should also retroactively remove all the old versions, too
|
|
#
?
Jan 16, 2019 15:35
|
|
|
Tankakern posted:After review, Fedora has determined that the Server Side Public License v1 (SSPL) is not a Free Software License. 
|
|
#
?
Jan 16, 2019 16:03
|
|
|
good news
|
|
#
?
Jan 16, 2019 17:25
|
|
|
Cybernetic Vermin posted:typically any error from the database is just fatal: the software is unlikely to have the means to understand or even report it in an intelligible way one nice thing about spring is that it translates the garbo jdbc exceptions into a useful hierarchy, so you can actually catch them and recover. almost nobody does, though (they're not checked exceptions)
|
|
#
?
Jan 16, 2019 17:45
|
|
|
Tankakern posted:After review, Fedora has determined that the Server Side Public License v1 (SSPL) is not a Free Software License. oh man, why did i focus on fedora rhel 8 wont have mongodb available, that's gotta hurt
|
|
#
?
Jan 16, 2019 20:10
|
|
|
does this mean people running ubuntu in prod will feel vindicated?
|
|
#
?
Jan 16, 2019 20:13
|
|
|
lancemantis posted:does this mean people running ubuntu in prod will feel vindicated? no, if they were running a proper server os they'd be free from mongo
|
|
#
?
Jan 16, 2019 20:28
|
|
|
suffix posted:avro is mysteriously slow, i've never seen a benchmark where it parses faster than json avro isn’t designed to be fast to serialize/deserialize it’s designed to be fast to query. it’s a column store as a file like orc or parquet. the rpc stuff is mostly just so you can have a single byte encoding end to end
|
|
#
?
Jan 16, 2019 22:08
|
|
|
yeah avro is designed to be transparently forward/backwards compatible, not just "make this into a string".
|
|
#
?
Jan 16, 2019 22:15
|
|
|
CRIP EATIN BREAD posted:yeah avro is designed to be transparently forward/backwards compatible, not just "make this into a string". then why do we have so many different avro versioning issues and have to hard-break i.e. upgrade two apps at the same time so often??
|
|
#
?
Jan 16, 2019 23:26
|
|
|
gonadic io posted:then why do we have so many different avro versioning issues and have to hard-break i.e. upgrade two apps at the same time so often?? have you considered the possibility you are wrong and bad? avro writes the schema into the file so you’re either overriding that or explicitly providing a read schema instead of getting it from the file
|
|
#
?
Jan 17, 2019 01:08
|
|
|
Bing if u string
|
|
#
?
Jan 17, 2019 01:12
|
|
|
|
| # ? May 3, 2024 15:42 |
|
|
lancemantis posted:does this mean people running ubuntu in prod will feel vindicated? ubuntu also will not include mongodb, probably debian already decided to drop it, and ubuntu typically just has outdated versions of whatever debian shipped
|
|
#
?
Jan 17, 2019 01:28
|
|