News for hackers. Stuff that matters.
Re:Monoliths Are the Future by rjkennedy98 on Thursday January 30, 2020 @01:14PM (#22193690)
This is what Kafka is for. You put Kafka on top of your database to expose data and events. Now BI can take the events put them into their system as they want.
Re:Monoliths Are the Future by BrentOzar on Thursday January 30, 2020 @01:29PM (#22193844)
> You put Kafka on top of your database to expose data and events. Now BI can take the events put them into their system as they want.

Right, that's the data warehouse method that I described. "Put them into their system" is a lot harder work than just typing in "put Kafka on top of your database."

Re:Monoliths Are the Future by jsjohnst on Thursday January 30, 2020 @01:54PM (#22194148)
Things like Maxwell[0] help a lot with the getting stuff into Kafka from the DB, but I agree with your point entirely. Kafka is not something I’d recommend unless you’ve got a team dedicated to maintaining it. Thankfully Confluent is rising up to fill that need and reasonably priced. Confluent also has an offering for streaming binlogs into Kafka too.

[0] http://maxwells-daemon.io/

Re:Monoliths Are the Future by skywhopper on Thursday January 30, 2020 @01:51PM (#22194117)
Worth pointing out that running Kafka is itself no small thing. So now you've added BI and also Kafka, which itself requires a bundle of services to operate. And you have to keep BI and Kafka in sync with all your various other data stores' schemas, and with each other.

Which all gets back to the point of the OP.

Re:Monoliths Are the Future by gunnarmorling on Thursday January 30, 2020 @02:54PM (#22194812)
Shameless plug: feeding data from operational databases to DWH is one main use case of change data capture as e.g. implemented by Debezium (https://debezium.io/) for MySQL, Postgres, MongoDB, and more, using Apache Kafka as the messaging layer.

Disclaimer: working on Debezium

Re:Monoliths Are the Future by chrisjc on Thursday January 30, 2020 @03:59PM (#22195501)
Data Warehouses are (usually) not optimized for individual inserts, updates, deletes (DMLs). Loading data into DWHs is usually done through copy/ingestion commands where aggregated/batched data is copied from blob storage (s3, azure, etc...) to a staging table in the DWH.

In a non-append-only scenario, Debezium tracks each source operation (insert, update, delete) from the replication log (oplog, binlog, etc) as an individual operation that's emitted into a kafka topic. How does one efficiently replicate this to a Data Warehouse in an efficient manner?

I have not been able to use Debezium as way to replicate to a Data Warehouse for this very reason. At least not without having to resort to very complicated data warehouse merge strategies.

Note, there exist Data Warehouses that allow tables to be created in either OLAP or OLTP flavor. I understand that Debezium could easily replicate to an OLTP staging table. But are there any solutions if this isn't an option?

Re:Monoliths Are the Future by Yeroc on Thursday January 30, 2020 @03:07PM (#22194963)
Curious how support is for commercial databases like SQL Server and Oracle? In the larger, older, enterprises these databases are rampant...
Re:Monoliths Are the Future by zomglings on Friday January 31, 2020 @12:23AM (#22199313)
> You put Kafka on top of your database

Your casual tone is at odds with what I've seen when teams run Kafka clusters in production. Not a decision I would take so lightly.

Re:Monoliths Are the Future by bfung on Thursday January 30, 2020 @01:57PM (#22194192)
Without tone of voice over text, unsure if the suggestion is in sincerity or sarcasm.

The article talks about micro services being split up due to fad as opposed to deliberate, researched reasons. Putting Kafka over the database also makes the data distributed when in most cases, it’s not necessary!