/tech/ - Tech

Technology.

catalog
Mode: Reply
Name
E-mail
Subject
Message

Max message length: 8192

Files

Max file size: 20.00 MB

Max files: 3

Password

(used to delete files and postings)

Misc

Remember to follow the rules


(94.89 KB 500x645 cockshottvulture3.jpg)
Relational/SQL vs NoSQL Comrade 08/13/2019 (Tue) 03:02:44 No. 2593
what is the advantages of nosql over traditional dbs?

why did programmers from 2006->2015ish all start writing and useing their own databases. whats the point?

people say oh its faster for the programmer because they dont have to write a schema but literally the only thing to change a schema is an alter table statement anyway which takes 30 seconds
>what is the advantages of nosql over traditional dbs?
Sometimes it's faster for certain operations, and can be easier to turn distributed

>why did programmers from 2006->2015ish all start writing and useing their own databases. whats the point?
Largely due to idiocy.
"We can make our whole stack javascript and store everything in Mongo with JSON, and save on labor by only training people in JS!"
"SQL is scary, relations are scary, give me plain object storage"
"We are too stupid to optimize our queries or use indexes, I guess we should just switch over to Mongo cuz marketing said it's faster"

>people say oh its faster for the programmer because they dont have to write a schema but literally the only thing to change a schema is an alter table statement anyway which takes 30 seconds
It's insane how many unsubstantiated claims about productivity are pushed in this field. Like sure bro, you are so productive writing hundreds of needless tests and hunting down runtime errors because type systems are too much work. Sure, having to duplicate data needlessly or re-implement your own hack version of relational DB in Mongo is so productive.
>>466
I would use mongo because it's ez pz to scale tbh.
>>471
>Sometimes it's faster for certain operations, and can be easier to turn distributed
this, plus, sometimes you want to store unstructured data for some reason.
In 99% of the cases, you do not want to use nosql.
I used to work at a well known tech company, we built something with a nosql db. I tried to push back, but I was a junior at the time and the project had already started when I joined. Didn't want to rub anyone the wrong way, so I just rolled with it.
A year later, the scaling pain was so huge, costs were unmanageable, and that was "pre deployment" (aka just having clients randomly ping the server and write an entry to the database). The minimum size of each entry was ridiculously large (>2kbs I believe), and we were building a service for a large large number of users.
And to make matters even more painful, it was a microservice architecture (no docker or k8), which meant that to test a change, you had to run a shit ton of microservices locally (which some required running in certain order).
One of the biggest pains was doing joins in code instead of in the database. Every "type" of data was it's own microservice. For example, creating an employee might have implied calling a user microservice, which gets the record from the calling user, then calls the business microservice (to check if the user has "admin" permissions in the business or something), then makes a get on the user db to verify the new employee doesn't exist, then finally create an employee in the user database. That whole shit could take an easy second, sometimes 1.5 seconds. Even worse-er, this was distributed, so sometimes data was not co-located, which meant that it had to make cross continent requests to nosql dbs. Absolute fucking nightmare.
And to add insult to injury, the data was very very structured.
All of this could have been done much cleaner, cheaper, quicker, and more performant with a nice SQL database, perhaps cockroach or postgres. All the microservices shit would've become moot once it's SQL and you can actually use the database. Even IF they decided to keep the terrible microservices architecture and have a db per type, a SQL database would've been many times cheaper and more performant (which in this case, meant millions).
NEVER AGAIN.
>>474
the only legitimate argument for nosql is its easier to horizontally scale but for small->medium size projects you should always go with a relational DB. The only projects which should really consider a nosql data store are facebook/google planet scale apps which have to serve millions if not billions of users. even then id just use a more 'cache'y nosql store like redis and have it write to postgres in the back end.

Not doing joins in the query language means you do it in the application layer which is 7x slower.
nosql describes many different things with more differences between them than differences with traditional SQL RDBMS. It doesn't make sense to compare nosql to sql as a whole, you need to compare the actual nosql implementation you are considering using to SQL directly (and also compare it to the various other nosql implementations which likely do something similar)

t. someone who works on databases
>>488
i think this mostly refers to mongo, graph DBs are a different beast
LET TODAY BE A WARNING AGAINST THE SOFTWARE NAMED MONGODB
MON GOD B
THIS MEANS "AMON (A.K.A. THE DEVIL) IS GOD" IN EBONICS
HERETICAL SOFTWARE BEGONE
(131.70 KB 1280x720 topology.jpg)
>>505
mongoError: Topology was destroyed
there's no need to ACID, transactions, or rollbacks, i said, laughing.

EVERYTHING IS FINE
SQL IS BETTER BECAUSE YOU GET ACID, TRANSACTIONS, ROLLBACK, ETC. FOR FREE.

databases like postgres have literal decades of engineering behind them making them rock solid. it even have json store if you want
(537.89 KB 708x708 abadi.png)
Any thoughts on Daniel Abadi and his DB work?
>>2604
>Daniel Abadi
never heard of him
>>2605
GAVIN-MENDEL GLEASON is a tech guy and marxist affiliated with Cockshott whos making a graph database
https://t.co/efUszC4EA2

Delete
Report

no cookies?