The Brave New World I've been talking about makes high normal form database centric applications all the more appropriate. I know of at least two extant applications which implement this way. That said, the issue remains: what will the interTubes infrastructure look like in two years and further, and what sort of RDBMS architecture best exploits it? It's worth noting that there is precedent; Bill Gates got very rich by targeting software to not yet available hardware. That said, some comments on some comments.
[Chris]: [Robert asserts] threads are more efficient, processor-power-wise to spin up than processes, and therefore if you insist on a single-threaded multi-process model, you can't have sufficient performance to make your database system relevant.
No, that's not exactly what I said. The issue is lost cycles as one moves down to a single thread. It's more about the number of clients that can be supported "simultaneously". At one time I was also enamoured of thread count to execute queries in parallel; not so much now. For reporting generally, and BI/DW specifically, sure. But for OLTP, where my interest lies, not so much. There, client count is what matters. Clients run relatively discrete transactions on few rows; parallelism isn't much help for that sort of client. Yes, to some extent I've changed my mind.
Think of the issue this way: if it were true that scaling down threads to one per processor/core yielded a scale up in performance equivalently (only one of two threads yields twice the performance on that last thread), then the question gets more difficult. But threads and cores don't scale that way. Such reverse scaling could only happen if the core's frequency increased as the inverse of threads active. That just doesn't happen, you get a bin or two; that nasty frequency brick wall is the reason vendors have turned to multi-core and threads in the first place.
It's a matter of relative performance, not absolute. If the PG developers decide to not implement a threaded engine (some or all sub-systems), PG will inevitably be viewed as not worth the cost. I never said that this would happen tomorrow. Threading isn't a fad, but a hardware evolution. As the quote from Intel states, that's where they intend to go. Countering that is the massively parallel single thread/core machine, such as the Transputer or Thinking Machine or possibly an armada of ARM (which has been reported to be adding threaded cpu to its menu) cores on a chip. Whether a *nix could better manage such a machine (as opposed to a threaded one) is up in the air; experience from the 1980's when parallel machines were all the rage suggests not (Amdahl's Law put an end to them, and is still in effect). Some feel that the ARM armada will take down Intel. Way too early to bet on that. Couple that with the rapidly evolving web infrastructure, and we have a Brave New World where the interTubes is virtual RS-232 passed on virtual Cat-5; what's on the client end of the wire is just a terminal, prettily pixelated nevertheless only a terminal. That evolution matters to how a RDBMS (and its applications) is optimally architected.
Intel needed MicroSoft to bloat up its software in order to create demand for ever higher cycle count chips; it's the Wintel Monopoly for a reason. Now that frequency is near a brick wall, clients are devolving from PCs to wrist computers and such, the likes of Intel can't count on Office to justify new chips (unless Steve's boys and girls can parallelize Office; I don't see goods odds on that). Servers are pathologically multi-user, and therefore the logical vein to mine. That's what's happening and will continue.
[Chris}: Instead things like network connection/teardown, command parsing, and, well, actual work dwarf process/thread startup cycles by several orders of magnitude.
As I've said before, the main issue isn't process startup cycles versus thread, but all those cycles lost by running single threaded, which could be used for actual work. All that network stuff gets kicked to the curb in the Brave New World anyway; that's a large measure of the point. And, as above, the issue isn't just "startup cycles", but total processing cycles doing useful work. Throw away all but one thread, and you throw away nearly (threads - 1 + (bin bump))/threads of useful work. See this testing. That's the issue. They No Such Thing As A Free Lunch, and the cpu is about the most significant example.
Which is precisely why client multi-plexing is superior; with a threaded engine, you get twice (or more) active clients without the falderal. The comment on connection pooling reveals the same issue: auditability and transaction integrity if nothing else. You end up having to do all that manually, if at all. While connection pools were initially at the database end, they are now most commonly in the web-server, and motivated by the (un)connectedness of HTTP. Web server writers face the same issue as database server writers. When I was building servlet/applet thingees in the late 1990's and early 2000's, we had to build quick and dirty poolers ourselves. By about 2002, databases and web servers had integrated the support. Had to happen. Here's an example for Tomcat. Folks can, and do, argue about which piece of software should own the connection pool; I'll avoid that for now.
What's missing from the comments is discussion of my main point: with a threaded engine working on threaded (and likely with higher thread counts in the future) cpu's, high bandwidth connections, and client multi-plexing; one ends up with a RS-232 like environment. While I haven't explored it, there's an environment named Opa[1] (Wikipedia has a short article), which is said to include web server and database server all in one. That's just begging for a fully connected infrastructure. Ideally, and I haven't explored enough to know as I type, there would be a single "connection", from the client's perspective; Opa takes care of managing the database/web server interaction in a way which preserves transaction semantics and client identity.
Unless you've been building database applications from before 1995 (or thereabouts), which is to say only webbie thingees, the efficiency and user friendliness of *nix/RDBMS/RS-232/terminal is a foreign concept; just as it still is for mainframe COBOL coders writing to 3270 terminals, same semantics (I'll grant that javascript is more capable than 3270 edit language, and Wikipedia does it again, with this write up). In the web age, AJAX was the first widely known (and possibly absolute first) attempt to get back to that future, then there is Comet. Now, we have WebSocket, discussed in earlier posts.
The Achilles heel of those *nix/RDBMS/RS-232/VT-X00 applications was the limit on the number of clients that could be accommodated since the client patch remained while the user kept a session. The emerging hardware/infrastructure that I'm discussing may/should remove that restriction. This also means that developers must heed the mantra, "the user doesn't determine transaction scope". With HTTP (un)connectedness, that isn't much of an issue.
With ever lighter clients, database centric (as opposed to coder's wet dream of client centric) applications become far more appropriate. Databases which can support higher client count on a given hardware platform (through threading, that is) will eventually clobber those that can't. That MySql, kind of OS, has threaded engines will make it difficult for other OS databases that don't. The question will not be PG versus Oracle/DB2/SS but PG versus MySql. While that's true today, the performance and configuration differences will only get greater over time.
While I surely agree that writing a threaded server, of any kind, is far more difficult than letting the O/S take care of the details (by writing a process based server), it's clear that the cpu makers are going to threads for performance. Think of this as a game of musical chairs.
[1] There is this internship listed on their website (typos their's):
Adding support for relational databases in Opa. The Web developping platform Opa has so far concentrated on its own database engine as well as the connection to existing NoSQL databases. The goal of this ambitious internship is to create the fundations of a framework for connecting relational databases to Opa (starting with MySQL). Different levels of integration will be experimented and successively made available (roughly: an untyped low-level API, a dynamically typed API, and a statically typed API generated at compile time). This internship requires excellent skills in functional programming (Ocaml, F#, Haskell, Scala) and a very good knowledge of the SQL language and its concepts.
Subscribe to:
Post Comments (Atom)
4 comments:
I think, as I have written here this largely omits a couple of important issues.
The first is that thread vs process scheduling and CPU cycle utilization is largely a matter of the scheduler which is usually part of the OS kernel. On *nix systems, there is very little different in scheduling ability between processes and threads, though of course hyperthreading architectures result in some challenges there, but these are not specific to thread vs process either. Rather issues here are specific to the combination of the OS, the CPU, and the scheduler (if the OS supports multiple schedulers the way Linux does). Whatever issues may innately favor threads, lost CPU cycles due to inadequate ability to use hyperthreading is not one of them.
The second is that web applications don't make these problems go away. You either have additional I/O contention issues, or you can actually simply get more db connections, in a web architecture than you traditionally have to deal with in a thick client. Indeed, I would argue that performance-wise, traditional clients are far easier to optimize than web clients.
Here's an interesting take by Mike Stonebreaker as to why threads are a net performance cost: http://www.youtube.com/watch?v=uhDM4fcI2aI
Stonebreaker points out that something like a quarter of total cycles used on major RDBMS's is devoted to thread locking. He runs everything single threaded, sequentially, with one process running per core.
Stonebraker has been promoting his various attempts with column-store and DW (and the single threaded meme) since at least 2005. Not my favorite RDBMS guy. In one piece he claims that Dr. Codd's work was to "clean up" IMS. Not even close. Dr. Codd set out to *replace* IMS; IMS and the RM are antithetical.
Hardware has changed markedly since then, and the vector of change continues.
VoltDB is not a column store. It's a main memory row store suited to the niche market of high speed transaction processing, where transaction round tripping is not required, and where durability is only non-local.
Column stores make a lot of sense when looking at analytics in data warehousing, as he points out, and that's not where VoltDB is going.
Instead we are talking about something that focuses on raw speed: One million plus transactions per second. He then focuses entirely on getting rid of overhead and a major source of that overhead (he says about a quarter of processor cycles on most db's) is in locks to solve thread concurrency issues.
The point is that there is at least one case where getting rid of multithreading was an important part of achieving very high speed and for good reason.
Post a Comment