4

I'm looking at building a radio play style streaming music player.

My biggest concern right now is figuring out which database paradigm will fit the problem of calculating the next song the best.

I'm leaning towards a graph db, but I'm concerned the graph will either be too big too perform or won't result in enough variety.

I have a list of acceptable databases, a rough max dataset size, and a preliminary set of filters and rankings.

Would this question be too opinion based or too broad if I provided aforementioned information?

Update asked the question here (now deleted)

3

I need help determining which database engine to use for this project XYZ

too broad, opinion based

I need help determining which document store to use for this project XYZ

opinion based, bad format, you've already assumed

I am having trouble determining which current databases on the market offer support for ACID transactions, direct JSON querying over simple objects, the ability to use mapreduce type querying, but still store my data in a strongly-typed schema, while allowing me to scale to approx 200queries per second per node, and preferably allow me to use distributed nodes so I can access the data in a redundant fashion from a web-farm.

now we're getting somewhere. Still a little opinion based, time-locality, but at least there's a question that helps people find and can help people in the future as well.

  • asked the question here – xenoterracide Jul 22 '15 at 22:49
  • I agree with Jack, you really missed the target a little bit, especially when you said "I haven't even written a sample app yet". I was trying to show that you need to have specific performance metrics in mind, and you were like "yeah, that would be cool". Your comment about "changing the backend is hard" is kind of a falsehood. It's true that for megalithic projects it can be awkward and time consuming to do so, but if you are truly building a simple front-end service that only needs to play music and display tracks and cover art, then it's not like there's a tremendous backend of work. – jcolebrand Jul 23 '15 at 14:46
  • well.. tremendous depends on how far in you are... I think obviously there's more to the entirety of the app, but "display tracks and cover art" is the easy part. Any database (or no database, you can embed that information in the metadata of any Track) can do that. Having an efficient next algorithm will be the hard part, imo. Any and all other problems are easy for any database, or don't have any sort of time constraint and can be batched. Anyways... I'm not going to argue for reopening. It was a long shot question for being on topic. – xenoterracide Jul 23 '15 at 15:24
  • So, finding the next track given a set of criteria will still not take a long time with an optimized query. An inefficient query will take approx the length of time of one song. When you get to that point, let us know, we'll help you fix things. – jcolebrand Jul 23 '15 at 15:40
4

I'm not sure how to answer this beyond "it depends". I think we'd need to see the whole question to judge, but the issue isn't topicality, there's nothing wrong in principle with soliciting advice from the experts here about which database to use. I think the difficulty will be doing so without your question being (a) too broad, or (b) opinion-based.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .