search

programsam / binkjs

Music archival site BINK, rewritten as a Node.js express app
0 stars 1 forks source link

NoSQL? #54

Closed programsam closed 3 years ago

programsam commented 7 years ago

Right now we are using MySQL and it's grand. But imagine how little work we'd do if we used cloudant or some other NoSQL.

The initial setup would be a pain, right, because we'd have to transliterated from MySQL to NoSQL for the data that already exists.

We'd also have to look into how you host a NoSQL database on the server, which, let's admit, we've never done.

And also count that we'd need to still run MySQL for the wikis and old BINK etc. I don't see media wiki moving to NoSQL any time soon.

Still worth considering.

programsam commented 6 years ago

Prior to docker people didn’t see it as the end of the world if a server ran multiple services... already my server runs Nginx, a few Node.js instances, and MySQL. Oh and a router in the Tor network. If we just add an instance of CouchDB would everything come to a screeching halt? Probably not.

So I’ve now setup and worked with Couch running in a Docker container. There’s a community-maintained CouchDB PPA. Not sure if it’s reliable or not or what you get from it’s packages. Maybe Mongo is a better alternative?

Then there’s the conversion. There are tools for doing this, but we’d be best served probably by writing our own script. So what do the types look like for BINK? Take jams for example:

Is jam1.locid set to a location ID still? Or do we actually link it in such that jam1.location = { id:6, name: “Bens House” }... if it’s the latter, how do we ensure that when I update Bens house, it’s changed everywhere? I think this is what CouchDB views are for. Like the view actually goes and looks up the location and stuffs it into the document when the view is loaded. Wouldn’t that be super badass? We already know that browsing would be easier — you just make a CouchDB index (did this on Plutus). Searching could probably be made to search many fields of a jam.

So I think it’s a flat 1 to 1. To try anyway? Each row in MySQL becomes a document in the database, with the columns of the row set as attributes of the document.

A design question is whether to store the different types of BINK entities in different databases or just set type = jam and then have views and indices that filter the things you don’t want.

This should be tried before any more work is done on BINK.js because it would require a serious refactor!!

programsam commented 6 years ago

Mongo is NOT a better alternative. It is technically nosql but isn’t a JSON REST API so not what we want.

programsam commented 6 years ago

Toughest part would be linking jams to other entities. That being said, this can be done in NoSQL best recommendation is to do a view that has all entities that are on a certain jam. I guess entities have a list of jams they are on.

programsam commented 6 years ago

Another note is that BINK entities all have monotonously increasing integers counting numbers for IDs. Which means there absolutely is a jam with ID 3 and a location with ID 3. They are in different tables so it’s no big deal. In Couch if we want any chance of linking things efficiently, we’d have to put them all in the same database with “type” field that lets you know what to expect for the schema. Ok so how do you identify?

programsam commented 6 years ago

Installed CouchDB on kn1.us. It’s stable and secure. Time to play and see how views could give us things like:

programsam commented 3 years ago

Given the amount of time I actually spend on this project, this is a very bad idea. Maybe in some far off distant future I would, but so far/right now, let's just stick w MySQL since we need it for the wikis anyway and it's generally available and easy to run/configure and etc. I don't see an immediate benefit for using NoSQL anyway. Nice idea though.