Viktor, Yep.
Best wishes, --greg On Thu, Jul 23, 2009 at 10:08 AM, Viktor Klang <[email protected]>wrote: > > > On Thu, Jul 23, 2009 at 6:46 PM, Meredith Gregory < > [email protected]> wrote: > >> Viktor, >> >> Yes. For example, in the biotech case the data is coming in from a >> device-based origin. > > > This is interesting. Analyzing the AST of the query for the data, then > identify the different data sources and then query each for all relevant > data since last refresh, then push that into partitions and then schedule > the Jobs and execute SQL and then merge/reduce the results. > > >> >> >> Best wishes, >> >> --greg >> >> On Thu, Jul 23, 2009 at 2:35 AM, Viktor Klang <[email protected]>wrote: >> >>> >>> >>> On Wed, Jul 22, 2009 at 11:52 PM, Meredith Gregory < >>> [email protected]> wrote: >>> >>>> Alex, Viktor, >>>> >>>> i think write semantics could get complicated quickly, actually. >>>> However, i was initially responding to the idea that trad business object >>>> models don't give way to analytics. Being able to make read-only queries >>>> against large volumes of data using the original business object schema >>>> seems to me like a win -- even if it's only used to populate a db that's >>>> sliced up in a different way for further analytics processing. >>> >>> >>> So basically, what's needed on top of HadoopDB is a service that updates >>> data as needed from external data sources. >>> >>> >>>> >>>> >>>> Best wishes, >>>> >>>> --greg >>>> >>>> On Wed, Jul 22, 2009 at 2:44 PM, Alex Cruise <[email protected]>wrote: >>>> >>>>> >>>>> Viktor Klang wrote: >>>>> > Absolutely, perhaps I'm tainted by write-heavy systems and perhaps >>>>> I'm >>>>> > just failing to see the overhead we're talking about. >>>>> > Perhaps I overlooked it, but the paper didn't mention performance for >>>>> > small writes and potentially multiple nodespanning transactions. >>>>> HadoopDB makes no claim to any support for writes at all, I'm just >>>>> speculating that It Should Be Possible given my understanding of its >>>>> architecture, which is admittedly limited and based solely on reading >>>>> the paper and a bit of the code. :) >>>>> > I'm inclined to believe that some sort of immutable records storage >>>>> > would simlify the semantics (analytic queries are IMHO very seldom >>>>> > demanding real-time snapshots) >>>>> Analytical queries against static data are exactly what it's for. I >>>>> have no experience with its competition, namely parallel/distributed >>>>> column-oriented databases, so I can't say whether they're any happier >>>>> with writes. >>>>> >>>>> FYI I brought up HadoopDB on the NoSQL list too but so far not too many >>>>> takers... >>>>> >>>>> -0xe1a >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> L.G. Meredith >>>> Managing Partner >>>> Biosimilarity LLC >>>> 1219 NW 83rd St >>>> Seattle, WA 98117 >>>> >>>> +1 206.650.3740 >>>> >>>> http://biosimilarity.blogspot.com >>>> >>>> >>>> >>> >>> >>> -- >>> Viktor Klang >>> >>> Rogue Scala-head >>> >>> Twttr: viktorklang >>> >>> >>> >> >> >> -- >> L.G. Meredith >> Managing Partner >> Biosimilarity LLC >> 1219 NW 83rd St >> Seattle, WA 98117 >> >> +1 206.650.3740 >> >> http://biosimilarity.blogspot.com >> >> >> > > > -- > Viktor Klang > > Rogue Scala-head > > Twttr: viktorklang > > > > -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
