I've been seeing the altchans ramp up their shilling since the New Zealand kebab removal. I'm thinking of throwing my hat into the ring. What's the best database solution for an imageboard? MySQL, PostgreSQL, SQLite? One of the non-relational databases like MongoDB I know it gets Stephen Lynx all wet.
How do you justify your choice?
Other urls found in this thread:
youtube.com
gay.imageboard.on.nimp.org
gay.imageboard.on.nimp.org
twitter.com
Your altchan won't even get 1PPH so literally anything will work.
shit thread btw
Yeah I figured that. I'm asking hypothetically, for an imageboard that gets actual traffic, what would be best.
A guy like me would just say fuck it imma gonna just use tinyIB And stick to using a flat pack
Nope im not gonna get a ssl cert either because fuck logic
Yeeeeeeeeer
when in doubt, and when not in doubt, and when it's sunny or not sunny, and on days ending in 'y', or if a flipped coin is pulled by gravity into any of ( Heads | Tails | Side | Floating_Perpetually | Annihilated ) states, then use SQLite.
...
That wasn't intended to be green
Stephen Lynx here.
To be fair, db choices aren't too crucial for a database. Relational databases are easy to not fuck up but more laborious to work with. Document databases like mongo are much easier to develop because you don't have a schema to worry about, but it's much easier to fuck up.
Now, that changes if you wish to store files in the db. That was why I picked mongo, because of gridfs. If you wish to store files on the filesystem, then that doesn't matter. Most of the performance bottleneck will be on your cache and the building of the final HTML to be served.
So coming from someone with quite some experience in the field my advice is: don't bike shed around dbs. Just pick something that fits your overall design, you just have to know WHAT your overall design is.
Fucked right off the bat smh
Oh yeah, there's the license thing with mongo. But in my opinion that only matters for services offering mongodb cloud things. Mongo as a corporation wanted to force people into using THEIR solution, so they designed a shitty license to fuck cloud services over.
IMO, if they ever fuck up their licensing so much that it affects the actual community, it will get forked and people will move over. So that doesn't really concern me, tbh.
Don't take me wrong, I am not defending their kikery, just saying that I don't see it as a threat for people running their own thing.
mongo is made by nsa
they by default permit admin login online and when some hackers noticed that there's a shitton of mongodbs on the web available to everyone (ISPs, phone companies, etc.) the devs just sent out shills telling everyone that this was fake news and that everyone who uses mongodb remembered to firewall it.
which was evidently wrong.
other than that i don't think it fucking matters. also you forgot to mention redis.
Oh yeah, the authentication thing.
Here's what I know about it: when you compile it yourself, by default it used to be open. BUT their repositories for both rhel and ubuntu were closed off for remote connections.
But so many people fucked it up that they changed it, now you always have to open up remote connections manually.
LOL MongoDB
Use the filesystem.
go ask on halfchan/g/
what fucking pack? fuck off niggers
PostgreSQL is the only fat SQL DB worth using. SQLite is the only slim SQL DB worth using. As for NoSQL, I don't see the point unless you're looking to cut dev time by 15% at the cost of your sanity. You often end up with a hard-to-maintain mess that you query with either some SQL analogue (like CouchDB's JS query language) or a low-functionality HTTP URI meta-language.
For most server applications, I'd go PostgreSQL. It's fast, it's hard, it's stable, it's easy to maintain, it's easy to replicate and it has good documentation. That or don't bother and use flat files, keeping mappings and indexes in RAM. It was viable for 4chan during its prime (or it would have been if it was coded correctly) so I don't see why you couldn't do it for your two posts per day IB.
The current state of /tech
...
So just use client side rendering?
That's what all those sites that don't work without JS do. They just dump JSONs over and work with them with JS on the client side. Literal CIA niggers. xD
It's true that you reduce server (and probably client too, if done correctly) load by using JSON, but by doing that you drop any legacy HTML whatsoever.
Most of the time legacy is an euphemism for garbage.
Giving the client the raw data serialized as json sounds way better than dumping it into an html document.
How do you extract the data from html?
these days legacy means the good thing that just worked and modern is the bloated slow and heavy thing that never works properly and is much harder to use.
one example could be the scales in grocery stores.. they used to be simple machines where you put your thing and press a number but they changed them to some modern touch screen thing so now you have to press two buttons to do the thing that you could do with one button on the old system. i thought that tech was supposed to make things easier but its actually making things harder.
ok gramps. a touchscreen really isn't that hard to grok.
still harder than the old system. there the buttons were always visible and just work. on this new system you have to press multiple virtual buttons and try to find your shit in the menus that they will some day change just so it would not be too easy to use. its just another case of putting computers where they dont belong.
If you have to ask it, you don't need it.
Will work, but, being file lock based, can produce some unique problems, when mixed with multiple processes/threads.
Somewhat similar situation to nosql. Shit, unless you go into hardcore optimizations.
So PostgreSQL
+ good implementation of standard SQL
+ sane default behaviour
+ 'CREATE TABLE nosql (id SERIAL PRIMARY KEY, document JSONB NOT NULL)', and you have mongodb that actually stores your data.
+ nice documentation
You don't. Have separate json endpoint or use Accept header.
Not in web. All attempts in web3.0, SPA imageboards I saw where pure shit.
JSON could be a way to go, but I'd rather see some more static structures with it, with pre-defined rules like in static HTML, if that makes sense. Contemporary Web is too JS-heavy. Even putting privacy and security issues aside, JS is slower because it needs to load and execute and not bug out LOL.
JSON is pretty nice, it's primitive as FUCK. Even Cat-v niggers like it.
The best solution is to hang yourself
SQLite is the only respectable one. Other than that just roll your own bro.
Dynamic type fags can hang themselves. You are literally cancer and make messes that are poorly designed and documented.
literally wrong seeing as everything is shit nowadays and overly complex for what it needs to do,
are Web imageboards really the best choice anymore?
I would actually rather use a bulletin board type thing, maybe having a lot of those would be better than imageboards on the web.
SQL is for when you need to query data in ways you've never queried it before. If you know something about your data (ex, posts are contained in threads that are contained in boards) you can do much better just using your filesystem and a caching layer.
Is correct. Interactive stuff should be in a thick application, or at least not over HTTP. You don't need to do shit like "Update in x seconds" or use web sockets that break without js. Use network sockets like they were meant to be used, 2-sided.
And where can I find a guide teaching pajeets how to do this? SQL is as simple and easy as taking a dump in the street. What you're talking about sounds a little more involved.
sql is not easy if you want good performance. not even the best cpu in the world is enough for postgres if you dont know how to properly optimize your shit.
Isn't that what sqlite is?
No, it doesn't. Don't think schemas are the be all end all.
goodbye ACID
People in the know don't use databases they use flat files. No database laws apply ;^)
You could supply type information in JSON LMAO.
Anyway, I don't see how it is relevant. Is XML-ish HTTP shit better somewhat? Is HTML typed LOL?
What I'm talking about is static content should remain static. JSON is too primitive by itself to supply it without JS or application that KNOWS what to do with it, and possibly expect some meaningful shit on user screen.
TOP LARP
Yeah that's sort of what I was trying to tell somebody but they called me a nigger
Pretty sure it still counts as a database in most countries. It certainly does in the UK.
It's either something that will be LITERALLY the same or HTML. Json is just the most practical for this kind of task.
No you can't. It's still valid JSON to call a string an int. Additionally I want it required in the format. I have never seen someone bundle types into JSON
Both are trash too.
Well, a string always could be read as int, I guess. Just point at the beginning and read 4 bytes, this is a legit int32 LOL. Whatcha gonna do about it, kid?
I don't see what you're getting at. Do you expect everybody on the Internet follow some specific standard of communicating structured generic binary data, when languages don't align on that in general? Or do you imply that you gonna shove BLOB data streams around and your apps are going to know what's up because you wrote them? If second, well, that's what everybody does when doing something that doesn't concern everybody, I guess.
Good joke. The UK specifically doesn't.
the ideal data interchange format is tiny SQLite files.
Imagine having to have SQLite dependency to be able to read/serve DNS requests.
You clearly don't know json. Json differentiates numbers, strings, booleans, nulls, arrays and dictionaries.
He probably implied that if you call something that is semantically a string an integer because you are a dipshit (like "someArbitraryString": 1337), you could be in trouble. There is no error if you assign 1337 or "1337" to that shit.
Building a JSON document or an HTML document in this case is very close in terms of performance.
When a real document (i.e. anything but an "app") is involved, JS should always extend HTML and should not be a hard requirement. Not only is this good for accessibility, usability and SEO (with parentheses, if you want) but it also implicitly prevents you from building a spaghetti monolith.
I'd do it this way:
gay.imageboard.on.nimp.org
gay.imageboard.on.nimp.org
Adding ?limit=50 makes it so the resulting view has at most 50 posts (by default the newest ones).
Adding ?since=20190329T190256Z makes it so the resulting view has posts new than the specified time.
I really can't think of anything else that a thread "api" would need unless you want liveposting.
it really depends on the data model of the information you are collecting; your database choice should be influenced on a decision you have made about how data relate to one another in abstract, because this informs the concrete implementation. Do a data model first before you touch a keyboard.
relational databases make sense for a number of object-like things which each have various fields of data which they do not share; customer data for a point-of-sale system works well because each customer has a name, address, phone number, orders associated with that customer alone.
non-relational databases work better when you're collecting a lot of different fields and don't know how they should relate to each other, but you want to do business intelligence operations to that data. IE: If you are storing posts from a social media source into a db so you can do inferences and provide feedback stats for a CRM system, you will want to use a non-relational system (possibly with Scala).
Hope this helps
...
Oracle XML DB
I'm not sure if I understood this particular example in contrast with a previous one.
You could relate posts to a user, to a place it was posted etc, and you could relate some stuff to the post as well, like, the amount of likes, replies etc.
I understand what you are saying but if you are doing BI for a social media segment you want to do analysis with posts as the main input to the db (indidivual users do not matter in this context)
your model would also be useful, but the sort of overhead for it would only be worth it if you want to identify brand promoters vs brand detractors and bad actors, where user persona is a factor of your analysis
In case of HTML, that would imply dynamic page generation on server-side, which is a spook. Like, that would mean unzipping HTML generator each time a user makes a GET request. Worst case scenario it knocks our shit out momentarily.
Hell no.
Kiss caching goodbye. That's a terrible idea.
sqlite is technically the best but when it's not enough, postgres
?
Why? Most users would hit a cache.
There should be a header that specifies the entire data type the body should be. This doesn't need to be sent every request or even in the same request, but it must remain consistent with the body.
Maybe he thinks that every user would request a slightly different number of replies for shits and giggles, instead of 99% using the default.
SQLite has the driver embedded into your software and it's not persistently running in host OS, not intended for high throughput but has great portability. Everything else is pretty much the same thing, just different flavors. By selecting a specific one you can optimize for certain tasks but if you don't have a pressing need to do this, you can just pick the default - MySQL is a database server of choice for web apps. Also it supports a bunch of different database drivers optimized for specific loads, but again, if you don't have specific pressing requirements then just stick with default.
As far as selecting particular implementation goes, what you do is create a benchmark that simulates your load accurately (or test it on live service, provided your system won't fail if you switch the database) and test all available configurations to see which one works best for you.
Never really was into web but what's the advantage of using a DB over “lol just files” or whatever?
ACID
A database is "lol just files" except it's a huge, fully featured, tightly integrated "lol just files" that often comes with features like durability (see post above), sorting, indexing, lookups, automation, views, operations-as-transactions and more. As you increase the complexity of an ad-hoc "lol just files", it eventually becomes indiscernible from an ad-hoc database.
The only best DB is sqlite read/written directly to/from the disk block device. Skip the filesystem middle man, they just want you to believe it's necessary.
In my experience there's no practical difference if what's being implemented is a small system with relatively little data and few users.
However as the data expands and the amount of users increase, database becomes faster, more stable and reliable over just using files especially if you're using NTFS
based
HAPAS ARE SUPERIOR TO WHITES
HAPAS ARE SUPERIOR TO WHITES
HAPAS ARE SUPERIOR TO WHITES
HAPAS ARE SUPERIOR TO WHITES
HAPAS ARE SUPERIOR TO WHITES
I'm seeing a lot of bot posts spammed around here. Be careful anons
HAPAS ARE SUPERIOR TO WHITES
Sqlite is the best db until you outgrow it and need distributed architecture / sharding. Then you're fucked and have to hire a team of 30 engineers to figure out how to make it scale.
LOL, I wish I thought of doing that!
Fuck off moshe.
Fuck you Masonic shills.