4 ms·

What then? Asking out of curiosity/ignorance, not trolling

• mynameishere 18y ago
  I think this website (hacker news) just uses persisted hash tables. I'm not sure why he thinks databases indicate "lazy programming" though.
  • axod 18y ago
    It's really easy to just throw everything in a db, and then start worrying when you scale. It takes more programming to think how best to organize things - what stuff should be in memory? How best to store it in ram for performance/size? What should be on the disk as flat files? What needs to be in a db? Should parts of the db be cached in ram and just used for writes etc. Also does everything need to be in a db? Or are some things better dealt with by just passing messages around, queuing them up if needed etc.
    • ars 18y ago
      > Should parts of the db be cached in ram and just used for writes etc. You are working way too hard. Let the OS figure out what needs to be in ram - it does it automatically anyway, and it does a better job that you an since it's caches what actually used, and not what you think should be used. You should not use flat files for web apps - they don't handle concurrency very well. > Also does everything need to be in a db? Or are some things better dealt with by just passing messages around, queuing them up if needed etc. Message passing, and db are not interchangeable, so that's a false question.
      • abstractbill 18y ago
        You are working way too hard. Let the OS figure out what needs to be in ram - it does it automatically anyway, and it does a better job that you an since it's caches what actually used, and not what you think should be used. So why does memcached exist?
        • ars 18y ago
          > So why does memcached exist? To cache the results of complicated joins (or queries without indexes). It's pretty much pointless if all you are doing is caching the result of a simple query using an index.
          • abstractbill 18y ago
            It's pretty much pointless if all you are doing is caching the result of a simple query using an index. Not if your database is under heavy load, and you can easily shift some of that load by putting frequently accessed things in memcached instead.
            • ars 18y ago
              That's if you have two machines. The comparison was vs keeping stuff in a hash table in memory, and I was saying databases are no worse.
              • abstractbill 18y ago
                The comparison was vs keeping stuff in a hash table in memory, and I was saying databases are no worse. But that's clearly not true. In the most extreme case, that hash table is referenced simply by a variable in your program - it's already in your program's address-space! There's no way a database can come close to that.
                • gnaritas 18y ago
                  Not to mention that you can hash arbitrary objects in a hash table with no mapping of any kind. hash at: key put: anObject Databases are vastly more complicated and require me to completely disassembly the object graph anObject may contain into a set of tables and rows to store it, and then reassemble the graph from tables and rows back into their object form when fetching. The second one commits to using a relational database, one often easily triples the size of the code base. There's nothing simple about that.
      • axod 18y ago
        Often a database is used to do simple message passing - campfire, twitter, pretty sure they both use a db to pass messages around. >> "You should not use flat files for web apps - they don't handle concurrency very well." That's a silly blanket statement. If I have a single thread that deals with something, of course it can use a flat file to store it. The problem is, that some people decide to use webservers that cause concurrency issues by having multiple threads doing similar things for different users. It sounds like you're still thinking about standard accepted many threads, database, etc etc.
        • ars 18y ago
          Uh what? If you have just a single thread of course you don't have to worry about concurrency. Isn't that what I just said? And you are seriously making a webserver that serves just one request at a time? There is a good reason it's "standard accepted" to use many threads, and a database. I guess you could have just one thread, with a queue, and do just one thing at a time without a database. Don't know why you would want that though.
          • axod 18y ago
            My webserver is currently serving 5k clients in a single thread... If you follow "standard accepted", you won't get anywhere.
            • ars 18y ago
              Um, everyone's webserver can handle 5k requests (per day) in a single thread. Not sure how many requests your clients do per day since you didn't say. Can you handle 1 million requests (per day) on a single thread? By using just one thread you are serializing your bottlenecks (CPU, IO, network). If you have more than one, one can be waiting for IO, while the other uses CPU. Plus CPU speeds are not getting faster, the future is multi core.
              • abstractbill 18y ago
                Um, everyone's webserver can handle 5k requests (per day) He's not talking about the number of requests per day, he's talking about the number of simultaneous requests.
    • michaelneale 18y ago
      yeah but if you get its going quick - is that really lazy? If you value more getting it done and working over getting things "right" from the start - for many cases that is a good enough approach. Although what I find interesting is the data store in google app engine - if you can work within that sort of database, you have a much better chance of scaling if you need to (and like you said, you rarely need the relational part of a RDBMS anyway).