Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Drasi: Microsoft's open source data processing platform for event-driven systems

github.com

Post reply on HN
Print view View original

31–40 of 87 posts

Re: Drasi: Microsoft's open source data processing platform for event-driven systems

#31

Post by stackskipton »

otterley wrote: post #22

Looks very Azure-centric. Both installation guides ( https://drasi.io/how-to-guides/install-sample-applications/b... and https://drasi.io/how-to-guides/install-sample-applications/c... ) require Azure to work. And then there's this: > Installing Drasi in an EKS cluster can be significantly more complex than a standard installation on other platforms. Instead of downloading a CLI binary using the provided installation…

Azure SRE here, it doesn't appear to have any Azure dependencies. CLI rebuild seems to be that "drasi init" assumes Azure Kubernetes Service built in StorageClasses for Kubernetes PVC for Redis and Mongo and thus fails when running against EKS. I assume same thing would be required on GKE. Yes, it should be more modular but MVP.

As for other stuff, it's using Gremlin Query Language or Postgres which are both open. In fact, it's going out of way it's not to use Azure authenication as loading connection string as Kubernetes secret is 100% AGAINST Azure Kubernetes Best Practice. Best Practice would be Workload Identity.

Re: Drasi: Microsoft's open source data processing platform for event-driven systems

#32

Post by [deleted] »

otterley wrote: post #22

Looks very Azure-centric. Both installation guides ( https://drasi.io/how-to-guides/install-sample-applications/b... and https://drasi.io/how-to-guides/install-sample-applications/c... ) require Azure to work. And then there's this: > Installing Drasi in an EKS cluster can be significantly more complex than a standard installation on other platforms. Instead of downloading a CLI binary using the provided installation…

[deleted]

Re: Drasi: Microsoft's open source data processing platform for event-driven systems

#33

Post by hobofan »

woozyolliew wrote: post #12
gigatexal wrote: post #3

Oh this very much reminds me of [feldera]( https://feldera.com ) — they do incremental loads and computations using some novel approaches (most of which i am too dumb to follow). Really nice folks too.

Or the related Materialize stuff https://materialize.com/

I took a brief look into Drasi and it looks like it doesn't do any of the differential/timely dataflow stuff (like Materialize does), or any other sophisticated incremental view maintenance methods that are rooted in Microsoft Research.

Re: Drasi: Microsoft's open source data processing platform for event-driven systems

#34

Post by resters »

This is a very solid pattern. Many systems that are built using traditional relational database systems would lend themselves to far simpler designs using this paradigm. It is not necessarily immediately obvious but nonetheless quite true.

Re: Drasi: Microsoft's open source data processing platform for event-driven systems

#36

Post by bob1029 »

stackskipton wrote: post #31
otterley wrote: post #22

Looks very Azure-centric. Both installation guides ( https://drasi.io/how-to-guides/install-sample-applications/b... and https://drasi.io/how-to-guides/install-sample-applications/c... ) require Azure to work. And then there's this: > Installing Drasi in an EKS cluster can be significantly more complex than a standard installation on other platforms. Instead of downloading a CLI binary using the provided installation…

Azure SRE here, it doesn't appear to have any Azure dependencies. CLI rebuild seems to be that "drasi init" assumes Azure Kubernetes Service built in StorageClasses for Kubernetes PVC for Redis and Mongo and thus fails when running against EKS. I assume same thing would be required on GKE. Yes, it should be more modular but MVP. As for other stuff, it's using Gremlin Query Language or Postgres which are both open. In…

> CLI rebuild seems to be that "drasi init" assumes Azure Kubernetes Service built in StorageClasses for Kubernetes PVC for Redis and Mongo and thus fails when running against EKS. I assume same thing would be required on GKE. Yes, it should be more modular but MVP.

None of these words are in the Bible.

Re: Drasi: Microsoft's open source data processing platform for event-driven systems

#37

Post by unit149 »

resters wrote: post #34

This is a very solid pattern. Many systems that are built using traditional relational database systems would lend themselves to far simpler designs using this paradigm. It is not necessarily immediately obvious but nonetheless quite true.

Beginning with Boolean operators: and / or - this relational service model can distribute queries. Curious why Cypher [0] abandons this syntax.

Re: Drasi: Microsoft's open source data processing platform for event-driven systems

#39

Post by 3abiton »

dtquad wrote: post #25
otterley wrote: post #22

Looks very Azure-centric. Both installation guides ( https://drasi.io/how-to-guides/install-sample-applications/b... and https://drasi.io/how-to-guides/install-sample-applications/c... ) require Azure to work. And then there's this: > Installing Drasi in an EKS cluster can be significantly more complex than a standard installation on other platforms. Instead of downloading a CLI binary using the provided installation…

That is usual for new Microsoft open source projects. It takes 1-2 months for the Azure dependencies to go away.

I'm curious about the other examples? I get it though, as many of these projects are built fulfilling a specific need within MS infrastructure.

Re: Drasi: Microsoft's open source data processing platform for event-driven systems

#40

Post by inkyoto »

CharlieDigital wrote: post #16
leeoniya wrote: post #13

Earlier quoted context omitted.

> while most of the queries could also be translated to relational SQL, Cypher's linear construction using WITH clauses is far, far easier to reason about, IMO. https://prql-lang.org/

Didn't look too deeply, but one of the keys with Cypher (at least in the context of graph databases) is that it has a nice way of representing `JOIN` operations as graph traversals. MATCH (p:Person)-[r]-(c:Company) RETURN p.Name, c.Name Where `r` can represent any relationship (AKA `JOIN`) between the two collections `Person` and `Company` such as `WORKS_AT`, `EMPLOYED_BY`, `CONTRACTOR_FOR`, etc. So I'd say that line…

> […] Where `r` can represent any relationship […]

… and «-[r]-» can represent any relationship direction, which obviates the need for constructing separate queries for inverse traversing relationships. Kinda like running a compiler forward and backward.

Post reply on HN