Ditto re last night's group being thought provoking. Having joined JavaScript Admirers, also meeting at CubeSpace, I'm well aware of CouchDB these days, which is something like Tokyo Cabinet. We've been lucky enough to hear directly from one of the Apache developers. I'm giving a link to my write-up.
As a long time RDBMS guy (SQL engineer, though not under the hood to the pyParser level (yet)) I'm quite aware that a generic medical record (mine, yours, anyones) is going to be wildly different per the individual, which in SQL terms looks like a blindingly huge number of tables, many of them completely unoccupied by a given individuals data (e.g. I'm not an XX, but might have XY problems). These map/reduce stowages, on the other hand, are much more "liberal" in terms of being "semi-structured" as we say. That doesn't mean they're not fast or hard to consult. And in terms of each LMR being its own work of art, that's possible too (LMR = legal medical record, in contrast to CRR = clinical research record). If I were on the phone to OHSU right now (an affiliate), I'd be saying the lag in PyTyrant and it's non-inclusion on the Sourceforge page for that project, adds grains of sand to the pan on the side of an Erlang approach over this one. CouchDB is also about replication, large data centers, speed... My thinking these days is CouchDB for LMRs (as a pilot), with national registries (e.g. NCDR) sticking with SQL, meaning the client hospitals using SQL for research as well. You'd suppose they all do that already but actually only some hospitals do a lot of outcomes research (the teaching ones) and some of those still use pre-SQL architectures such as MUMPS (believe or not <-- Jack Palance voice). Anyway, an enjoyable gathering, would've liked to have beer but I'm tightly scheduled these days, not that much wiggle room, maybe next time. Links: http://mybizmo.blogspot.com/2009/03/ppug-2009310.html (last night) http://controlroom.blogspot.com/2009/02/wanderer-cubespace.html (CouchDB presentation) http://mybizmo.blogspot.com/2009/01/admiring-javascript.html (previous meeting) If you want to say "hi" in real time, I'm currently on rtsp://server1.isepp.org/mystream.sdp (I'm representing ISEPP @ Pycon this time around, last time I had ISEPP on my nametag was 1st Buckminsterfullerene Conference @ Santa Barbara, met Harold Kroto and like that, was a lot younger back then, web wrangling for BFI.org). Kirby On Wed, Mar 11, 2009 at 7:34 AM, mgross <[email protected]> wrote: > Last nights pdxpython meeting was pretty much the best I've ever been > too. I woke up thinking about some stuff related to python and a > possible bridge talk I'm starting to consider doing. > > One of the many things that stuck in my head from last meeting > (besides Machine learning--which was uber cool) was the pytyrant and > friends talk hitting on the performance of the database. > > What struck me is the performance delta in database throughput on > Michael's simple sample losing 2 orders of magnitude int run time by > using a loop-back network over direct to the file access. > > It got me thinking, hmm, I know a little about how to drill down on > performance > and scaling problems and, I know some experts in the performance area > I can ask questions of, and I have a few questions on what exactly are > the performance issues with python and django workloads? > (like, does my cheap-oh ISP have a legitimate point regarding its > refusal to support Django sites?) > > So my question to the list is can folks feed me some workloads I can > use in a side project I'm thinking of starting to drill down on the > performance and scaling issues with python and Django use for both web > applications and python code in general? > > My thought is that this investigation and results would make an > interesting bridge talk. > > Thanks for any advice or help! > > --mgross > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 189 bytes > Desc: Digital signature > URL: > <http://mail.python.org/pipermail/portland/attachments/20090311/044d2594/attachment.pgp> > _______________________________________________ > Portland mailing list > [email protected] > http://mail.python.org/mailman/listinfo/portland > _______________________________________________ Portland mailing list [email protected] http://mail.python.org/mailman/listinfo/portland
