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

We built a distributed DB capable of running across 100s of global locations

macrometa.co

Post reply on HN
Print view View original

21–29 of 29 posts

Re: We built a distributed DB capable of running across 100s of global locations

#21

Post by ctesh »

willvarfar wrote: post #12

This is actually exciting. Most sales pitches for secret sauce services are much flimsier and don't ooze the actual technical possibilities and promises that this one does. So, does it solve the double-spend problem or not? The prose is a bit ambiguous on that. I don't want to work that out for myself. I want to be told one way or another, and perhaps given some simple examples like "users x and y both want to do z a…

Thanks for pointing out the ambiguous bits - I’ll clean it up in the next few days.

Yes it does solve the double spend - it let’s you mark (check box) a collection with a SPOT property (single point of truth) which restricts the number of edge region that collection is replicated across. Additionally the spot collection is replicated across two separate data centers (and separate availability zones in those data centers) to provide high availability. The developer doesn’t need to deal with the complexity of where and how this is done - they continue to access the collection like a regular one and the DB will redirect the queries (and do things like joins) between the regular and spot collection.

I’m writing a faq and will include your questions there.

Jepsen is in the plans - we hope to get a report out in the summer.

Re: We built a distributed DB capable of running across 100s of global locations

#22

Post by ctesh »

kilburn wrote: post #17
ctesh wrote: post #2

The TL/DR on how: 1. Causal consistency with the ability to create collections (tables) with strict consistency - uses vector clocks and not wall clock timestamps for ordering DB operations 2. Streams to propagate DB changes from one geo location (node) to another with guaranteed ordering and reliable delivery 3. Generalized Operational CRDTs to make all DB operations Associative, Commutative, Idempotent and Distribu…

Translation: There are two "modes" of operation of this product: "regular" and "SPOT collections". In regular operation mode, the system will lose concurrent writes and cannot enforce ACID (the classical one) transactions. Your data is however highly available, eventually consistent and copied around the globe for faster access. With SPOT collections you get ACID transactions but lose the distribution advantages. Tha…

Yes - you hit the nail in the head - that is indeed how SPOT and regular collections work.

We think we provide the flexibility of both very strict acid behavior using spot collections Along with the strong eventual consistency model for everything else. Important to understand that as a developer you don’t need to deal with any of it - it’s handled for you once you have marked a collection as a spot.

This is not related to gun in any way. We love what gun does and it’s approach and they do some very clever things (including work on the end device). We sit as a back end database as a service in 25 global pops and process dB operations (and code expressed as functions or containers) at the closest location (by latency or geo physical location) to the user or device using an app or api rubbing against us.

we wrote our own operational CRDT engine And streams to solve this.

Re: We built a distributed DB capable of running across 100s of global locations

#23

Post by ctesh »

raghava wrote: post #18

This looks pretty neat! Considering that there's a FaaS layer too, which could be used along with the DB layer offering, what degree of vendor-lockin are users getting into? Also, this product seems only targeted at those direly needing edge computing, thus missing out on many who might be using Firebase and Serverless (Lambda/Functions etc) for the works. Is that intentional?

You bring up a great point. One absolutely can use us as a firebase alternative. We have a few customers using us with lambda and container services directly on their favorite cloud provider in just 2 locations for high availability of their apps.

The edge computing position is intentional in that we think the edge is a way to build globally distributed apps and apis. Our goal is to make as simple to build and run an app in 25 regions as it is to build an app against say firebase or dynamodb.

Re: We built a distributed DB capable of running across 100s of global locations

#24

Post by the_arun »

ctesh wrote: post #9
the_arun wrote: post #8

Earlier quoted context omitted.

REST interface is good, but could we add business valdation before mutating data? Because bulk of the work backend does is this business logic. How could we do this?

Hello and greetings the_arun. The short answer is yes. Macrometa integrates a function as service (FaaS) which can be hooked into the database and be triggered by events on a stream or a data collection. So you can for example do the following: Expose a RESTful or GraphAPI (included deep nested queries in graphQL) for one or more collections - when mutating, attach a validation function to the collection as a trigger…

Thanks for the details. This sounds very similar to Amazon's DynamoDB? Are there features to make macrometa better than DynamoDB?

Re: We built a distributed DB capable of running across 100s of global locations

#25

Post by ctesh »

the_arun wrote: post #24
ctesh wrote: post #9

Earlier quoted context omitted.

Hello and greetings the_arun. The short answer is yes. Macrometa integrates a function as service (FaaS) which can be hooked into the database and be triggered by events on a stream or a data collection. So you can for example do the following: Expose a RESTful or GraphAPI (included deep nested queries in graphQL) for one or more collections - when mutating, attach a validation function to the collection as a trigger…

Thanks for the details. This sounds very similar to Amazon's DynamoDB? Are there features to make macrometa better than DynamoDB?

Shares some feature overlap with dynamodb (key/value and document dB interfaces). Where we differentiate - global replications across all our 25 global POPs (50 by end of 2019). Integrated graphQL generator (rest as well), real-time: dB will notify clients of changes to data I.e. no need to poll, rightly integrated with streams and pub/sub, run functions and containers as triggers or stored procedures to the DB, geo query: query by lat/long/height, elastic search integrated (July 2019). There’s more - will announce in April

Re: We built a distributed DB capable of running across 100s of global locations

#26

Post by durga_mm »

willvarfar wrote: post #12

This is actually exciting. Most sales pitches for secret sauce services are much flimsier and don't ooze the actual technical possibilities and promises that this one does. So, does it solve the double-spend problem or not? The prose is a bit ambiguous on that. I don't want to work that out for myself. I want to be told one way or another, and perhaps given some simple examples like "users x and y both want to do z a…

Hi willvarfar - I am one of the authors of the post. Very good feedback. Appreciate much. I will update the post or write a separate post on `double-spend` problem with clear example.

Re: We built a distributed DB capable of running across 100s of global locations

#27

Post by durga_mm »

ignoramous wrote: post #11

Great work. Building a distributed database isn't easy at all and takes considerable effort. I'd like to see more on failure scenarios. Here's a few preliminary questions I have (admittedly, I haven't read the entire post, apologies if my queries are answered already): What is the SLA for durability and availability of the db? - how are scenarios like edge locations going down for multiple minutes handled? Are the wr…

Hi Ignoramous - Thanks. Very helpful comment with good questions. I will update or cover in the next post.

Regards

Re: We built a distributed DB capable of running across 100s of global locations

#28

Post by durga_mm »

CharlesW wrote: post #6

Shouldn't this be a "Show HN", since the submitter is the company CEO/President?

Hi CharlesW - Thanks. Probably we will publish another post with details on how people can try out the global edge fabric. That probably would be good fit for "Show HN"?

Regards

Re: We built a distributed DB capable of running across 100s of global locations

#29

Post by durga_mm »

zzzcpan wrote: post #19

So, does it actually have CRDT operations? Doesn't seem like any of the interfaces expose them. Can you use a convergent counter, for example? Also product page [1] has some weird claims. There is no such thing as "Strong Session Consistency", this is just another name for weak consistency guarantees. And Strong Eventual Consistency, which is a thing, requires using mergeable conflict-free operations that you don't s…

Hi zzzcpan - Yes. The global edge fabric internally uses CRDT operations. It is a conscious choice to not expose the CRDT data types. The idea being the developer work with APIs & Query layer as they do with other databases and underneath the system take care of translating to necessary CRDT operations. Convergent counter is in the works and will be available shortly.

The system has strong consistency within a region (aka datacenter) and strong eventual consistency across data centers. Answering your question, yes we do converge (merge) the changes across regions using conflict-free operations.

Intent prioritization rules comes into picture only when it is impossible for the system to determine the intent of the developer when two conflicting changes occur across regions.

I hope the above helps.

Regards

Post reply on HN