• 2 Posts
  • 457 Comments
Joined 2 years ago
cake
Cake day: June 20th, 2023

help-circle
  • You really have to see what the db is doing to understand where the bottlenecks are, i.e. find the query plans. It’s ok if it’s just single selects. Look for stuff like table scans that shouldn’t happen. How many queries per second are there? Remember that SSD’s have been a common thing for maybe 10 years. Before that it was HDD’s everywhere, and people still ran systems with very high throughput. They had much less ram then than now too.





  • Newegg doesn’t seem to sell the Crucial MX500 any more*, only the BX500. But if the 870 evo is comparable, I might get that, since I have a couple of MX500s now and am happy with them. I hadn’t realized that Team Group was legit at all! I’ll keep that in mind. Thanks!

    *Note: The MX500 appears on Newegg’s web site, but the actual sellers are “Newegg Marketplace” randos rather than Newegg itself, and I prefer to buy directly from Newegg when possible.






  • HMB is host memory buffer or something like that. It means instead of having a ram buffer in the drive, the OS software uses some of the host computer’s memory for disk buffering. That makes the drive cheaper but I haven’t heard claims of it being any faster. Consumer drives seem to all use it now, and Linux supports it, but maybe not when you wrap up the HMB drive in a SATA shell.

    I guess $90 for 1TB is pretty good. I have been suspicious of the EVO drives but at least they aren’t QVO.

    Thanks!


  • Thanks, I wasn’t really thinking about transfer speeds, it’s just the PCIe drives are cheaper (depending) and more re-usable if I get a newer laptop later. I think you are right though that it’s not worth messing with adapters.

    I dunno if there’s such a thing as a reliable brand. The brands have reliable and unreliable models. Particularly I have the idea that I should be avoiding QLC drives, but that TLC these days is ok.



  • Java isn’t exactly hard, and it’s not particularly fundamental. It’s just bureaucratic, and Python will be both more enjoyable and more useful. Java was trendy in the 1990s and lingers on because so much Java code is still around. If your goal is to use a serious type system (Lisp and Python don’t have that), Haskell will be far more enlightening than Java. If you want to use the JVM for some reason, Clojure (a Lisp dialect that run in it) might interest you.

    For low level fundamentals, you want assembly language! That gives you almost no assistance and you have to do EVERYTHING yourself, organizing the program in your own head. For old fashioned imperative programming with lots of organizational assistance, try Ada.

    You will probably have to learn C at some point, but save it for later when it will be easier for you to spot the weaknesses.







  • What? Problems like this usually come down to some missing indexes. Can you view the query plan for your slow queries? See how long they are taking? IDK about SQL Server but usually there is a command called something like ANALYZE, that breaks down a query into the different parts of its execution plan, executes it, and measures how long each part takes. If you see something like “FULL TABLE SCAN” taking a long time, that can usually be fixed with an index.

    If this doesn’t make any sense to you, ask if there are any database gurus at your company, or book a few hours with a consultant. If you go the paid consultant route, say you want someone good at SQL Server query optimization.

    By the way I think some people in this thread are overestimating the complexity of this type of problem or are maybe unintentionally spreading FUD. I’m not a DB guru but I would say that by now I’m somewhat clueful, and I got that way mostly by reading the SQLlite docs including the implementation manuals over a few evenings. That’s probably a few hundred pages but not 2000 or anything like that.

    First question: how many separate tables does your DB have? If less than say 20, you are probably in simple territory.

    Also, look at your slowest queries. They likely say SELECT something FROM this JOIN that JOIN otherthing bla bla bla. How many different JOINs are in that query? If just one, you probably need an index; if two or three, it might take a bit of head scratching; and if 4 or more, something is possibly wrong with your schema or how the queries are written and you have to straighten that out.

    Basically from having seen this type of thing many times before, there is about a 50% chance that it can be solved with very little effort, by adding indexes based on studying the slow query executions.