4 ms·

So your argument has shape shifted from "This is terrible advice" to "this is terrible advice unless your at uber scale". Sounds like we are in agreement then

• koolba 10y ago
  > So your argument has shape shifted from "This is terrible advice" to "this is terrible advice unless your at uber scale". No my argument is this particular design is both unjustified for the use case and poorly thought out/implemented. The uuid as varchar(50) is a dead giveaway of amateur status.
  • jdiscar 10y ago
    Are you saying a NoSQL solution is better for this use case? Because that's what this article is asking. Sure, they could do things better (can't we always?), but that's not the point they're trying to make. Like you said, 10GB of data isn't very much, it really doesn't matter if you go with NoSQL or SQL. But SQL will probably give you more flexibility and will be easier to manage until you get really, really big.
    • manigandham 10y ago
      Actually yes, a single key-value database could handle all of their load with better functionality. Make that 2 nodes and you have HA and redundancy. Problem solved.
    • jbergens 10y ago
      I think you loose flexibility with sql. If the usage changes slightly and you need to index one or two more fields you would have to do an alter table and read through 200 GB of data deserializing all blobs to put the values into the new field. A good nosql would just add a secondary index. You might also have a hard time doing map-reduce on sql. It is often built into nosql systems.