Hi, Ori, My interpretation on the MV usage in Martin's talk is exactly what you have mentioned: it is considered as a "view" instead of a regular table in DB, hence, read-only and possibly, derived data that already went through the business logic.
On Thu, Mar 26, 2015 at 1:55 PM, Yan Fang <yanfang...@gmail.com> wrote: > I guess you mean "Martin", not "Matrin", here is the link for Ori's > question. To give everyone a background. > > https://thestrangeloop.com/sessions/turning-the-database-inside-out-with-apache-samza > > > Fang, Yan > yanfang...@gmail.com > +1 (206) 849-4108 > > On Thu, Mar 26, 2015 at 3:15 AM, Ori Cohen <o...@ori-cohen.com> wrote: > > > Hi everyone > > > > Based on Matrin's StrangeLoop "turning the database inside out" what I > > understand is that he meant for Samza to be a tool to pull sequential > event > > data from a pub-sub such as Kafka, then process the data to generate > > materialized views. The next piece of the puzzle I couldn't figure out. > > The materialized views are meant to be used as a cache level and to be > > read-from instead of reading directly from the DB or other application > > cache. So the data store to which Samza would output the data to is > another > > DB layer, maybe mem-based like redis. This like the traditional DB, > because > > it also gets both reads and writes, so what is the point? If it will be > > optimized for read, than data consistency will take more time. > > Is it because the store data is eventually consistent and the store holds > > data already processed by business logic? > > If views are meant to subscribe to changes in the stores (the actual > > materialized views), then we need additional Kafka topics or other > pub-sub > > mechanism that will contain change events of the materialized views, > which > > complicates things even more. > > > > Please help me out here. > > > > Regards, > > Ori > > >
