[portland] python bridge talk questions / advice

[kirby urner]

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 <markgross at thegnar.org> 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
> Portland at python.org
> http://mail.python.org/mailman/listinfo/portland
>