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

Bedrock – Rock-solid distributed data

bedrockdb.com

Post reply on HN
Print view View original

1–10 of 110 posts

Re: Bedrock – Rock-solid distributed data

#2

Post by badminton1 »

I don't want to be a jerk but... just for the sake of common sense:

- Faster? Provide a benchmark. Faster is a relative thing, faster than what? faster under which conditions?

- More reliable... than what? under which conditions? how do you know it is more reliable?

- More powerful? I thought SQLite is more constrained than other SQL databases. e.g: No stored procedures. Powerful? how? compared to exactly what?

Nullius in verba. I don't take your statements as granted, give me a proof, otherwise it's just flatus vocis.

Re: Bedrock – Rock-solid distributed data

#4

Post by thesmallestcat »

You'd have to be nuts to depend on something backed by Expensify. They'll probably fire the maintainers.

Edit: Turns out it's authored by the CEO! So you'd have to be nuts to use it, period. But, um, poke the source if you're curious. This is a good intro https://github.com/Expensify/Bedrock/tree/master/libstuff#li... I can't imagine a more ironic and hilarious backdrop for the "We Fire People" campaign. Must be tough finding people who can keep up with a brain that big.

Re: Bedrock – Rock-solid distributed data

#6

Post by quinthar »

sonofgod wrote: post #3

Where do you make your CAP Theorem tradeoffs? When shouldn't people use Bedrock? https://sqlite.org/whentouse.html is a wonderful page - full of discouragement to would-be SQlite users to know when they're in a use-case better served by some other tool.

Heh, yep, we definitely had that sent to us. The point of Bedrock is to resolve those points and make SQLite usable in the enterprise.

As for the CAP theorem, we compromise on "C". Each slave responds based on its current state, which might be a different state than other slaves or the master. However, every response returns the "commitCount" of the database at the time the response was generated. Then when you submit a new request, you can specify that commitCount and the slave will wait until it is at least as recent as that.

This way you can safely act upon the response of one request, and then make a second request to another.

Re: Bedrock – Rock-solid distributed data

#7

Post by quinthar »

badminton1 wrote: post #2

I don't want to be a jerk but... just for the sake of common sense: - Faster? Provide a benchmark. Faster is a relative thing, faster than what? faster under which conditions? - More reliable... than what? under which conditions? how do you know it is more reliable? - More powerful? I thought SQLite is more constrained than other SQL databases. e.g: No stored procedures. Powerful? how? compared to exactly what? Nulli…

Thanks for all that Latin! Yes, it's been open sourced for under 24 hours. Those are all good suggestions.

Re: Bedrock – Rock-solid distributed data

#8

Post by quinthar »

dsl wrote: post #5

For all the emphasis put on multi-datacenter replication, it would be awesome to see it documented! Really looking forward to playing with this. Cool stuff.

There's a bit of that here: http://bedrockdb.com/multizone.html

But yes, lots more details to add over time. Thanks for asking!

Re: Bedrock – Rock-solid distributed data

#9

Post by thesmallestcat »

quinthar wrote: post #6
sonofgod wrote: post #3

Where do you make your CAP Theorem tradeoffs? When shouldn't people use Bedrock? https://sqlite.org/whentouse.html is a wonderful page - full of discouragement to would-be SQlite users to know when they're in a use-case better served by some other tool.

Heh, yep, we definitely had that sent to us. The point of Bedrock is to resolve those points and make SQLite usable in the enterprise. As for the CAP theorem, we compromise on "C". Each slave responds based on its current state, which might be a different state than other slaves or the master. However, every response returns the "commitCount" of the database at the time the response was generated. Then when you submi…

So you're ensuring consistency by blocking on all queries? And it's up to the client to enforce this to any degree? And if there's one master and a global clock, sounds like you threw out the "P" too. Frankly this thing sounds simplistic and unusable, and it's sorta offensive to hear SQLite called unusable in the enterprise, whatever that means.
Post reply on HN