How do websites store billion of accounts in a database, won't they cost a lot of storage?
mysql
>>106870885>billion1,000,000,000=1GB
>>106870906This is more retarded than op. An account's data wouldn't be 1 byte
>>106870890ThisIt doesn't take a lot of storage to store text data. It is practically nothing compared to storing pictures and videos.
>>106870885If your website has billions of accounts, you can probably find a way to monetize it to pay for storage.
>>106870890Get with the times gramps, we use postgres now.
>>106871283>she's rolling her own authstill a red flag. you are getting hacked.use firebase.
>>106870928Of course not, but he's making a good point. Let's say for example it's 200 characters per account, enough for basics, that's still just 400GB which fits on any computer these days. With a BILLION accounts which only the top 10 biggest services have.>>106872496>she's rolling her own auth>still a red flag.It's not hard, anon.>use firebase.Terrible idea, if you can't do basic auth, you can't configure firebase. As evidenced by the thousands of insecure firebase sites.
>>106870885data in a relational database is usually really compact unless you're doing something wrong. at some point once you max out your hard drive, databases have to be scaled, by storing parts of the database across many different servers.In general these kinds of situations have already been abstracted away and managed database services do it for you "so you don't have to".
>>106870885You store user name and encrypted password in a database When a user login, he provide your server with user and passwordYou validate it in server side, generate some kind of oauth jwt code and sent it to the userYour frontend on users side save this jwt in a local cookie You validate every request here after to the server with that jwtMuch of it have been implemented by most boiler plate code these days
>>106870885>cost a lot of storage?No. Most sites won't have billions of rows of transactional data in a table, if they do, you're popular enough to afford a few petabytes of storage.
that's why you hire auth specialists, op.their job is to remember all the accounts.they're amazing people.
>>106872496>hacked>firebasehave a tea
>>106870885math hard innit?
>>106870885You can store billions of accounts in a sqlite database.
>>106873572>You store user name and encrypted password in a databaseYou would hash the password using e.g. argon2id.>You validate it in server side, generate some kind of oauth jwt code and sent it to the userYou can use a jwt and lots of people do, but it's bad for auth because you can't cancel it on the spot for that user. Better to send a session token and store the hash of it in the db. And it's ok to use e.g. sha-256 for this since the session token will be randomly generated server side.
