To anyone who is on the fence about putting FoundationDB into production (or at least evaluating it for their use cases), what is the number one thing you think is missing or you're worried about? i.e. - a SQL interface, - pre-packaged data structure libraries, - monitoring, - limitations of FoundationDB itself, - etc. I'm working on a talk for the upcoming FoundationDB Summit and I'd love to address some real-world…
One of my constant pain point with all distributed data stores is that it's really hard to find out how they behave if something breaks. Be it the network, local storage and so on. How do I find out what's wrong? Are there guides on how to fix a problem? What happens if I lost more nodes than required to automatically recover? How does backup and restore work? Any estimates on how long a restore will take? Are there…
FoundationDB 6.0 released, featuring multi-region support
21–30 of 72 posts
Re: FoundationDB 6.0 released, featuring multi-region support
#22Earlier quoted context omitted.
+1 for a SQL layer/interface. Would massively increase utility of FDB.
Haven't tested yet, but I was wondering if it's possible to use TiDB as SQL layer. [0] [0]: https://github.com/apple/foundationdb/issues/198
Re: FoundationDB 6.0 released, featuring multi-region support
#23To anyone who is on the fence about putting FoundationDB into production (or at least evaluating it for their use cases), what is the number one thing you think is missing or you're worried about? i.e. - a SQL interface, - pre-packaged data structure libraries, - monitoring, - limitations of FoundationDB itself, - etc. I'm working on a talk for the upcoming FoundationDB Summit and I'd love to address some real-world…
Re: FoundationDB 6.0 released, featuring multi-region support
#24To anyone who is on the fence about putting FoundationDB into production (or at least evaluating it for their use cases), what is the number one thing you think is missing or you're worried about? i.e. - a SQL interface, - pre-packaged data structure libraries, - monitoring, - limitations of FoundationDB itself, - etc. I'm working on a talk for the upcoming FoundationDB Summit and I'd love to address some real-world…
I'd be very interested in usage for time-series, but it looks like to get a working example up I'd need to fully parse the documentation and tutorials in order to do it as there is no "Let's build a Timeseries Database on FoundationDB from scratch"
Re: FoundationDB 6.0 released, featuring multi-region support
#25To anyone who is on the fence about putting FoundationDB into production (or at least evaluating it for their use cases), what is the number one thing you think is missing or you're worried about? i.e. - a SQL interface, - pre-packaged data structure libraries, - monitoring, - limitations of FoundationDB itself, - etc. I'm working on a talk for the upcoming FoundationDB Summit and I'd love to address some real-world…
One of the huge problems is a lack of consistency constraints. Since during development data make became broken in various ways (and we have done several times). And right now there are no way to implement simplest constraints on database level.
Re: FoundationDB 6.0 released, featuring multi-region support
#26To anyone who is on the fence about putting FoundationDB into production (or at least evaluating it for their use cases), what is the number one thing you think is missing or you're worried about? i.e. - a SQL interface, - pre-packaged data structure libraries, - monitoring, - limitations of FoundationDB itself, - etc. I'm working on a talk for the upcoming FoundationDB Summit and I'd love to address some real-world…
We are actually spend two weeks rewriting our code from SQL to FoundationDB (we have built our own simple ORM). One of the huge problems is a lack of consistency constraints. Since during development data make became broken in various ways (and we have done several times). And right now there are no way to implement simplest constraints on database level.
Re: FoundationDB 6.0 released, featuring multi-region support
#27To anyone who is on the fence about putting FoundationDB into production (or at least evaluating it for their use cases), what is the number one thing you think is missing or you're worried about? i.e. - a SQL interface, - pre-packaged data structure libraries, - monitoring, - limitations of FoundationDB itself, - etc. I'm working on a talk for the upcoming FoundationDB Summit and I'd love to address some real-world…
We use Postgresql heavily and it's not really a viable replacement. Even if there were an SQL layer, I doubt it would be fully featured enough for our needs. We may evaluate FDB as a distributed cache, but haven't had the time.
Re: FoundationDB 6.0 released, featuring multi-region support
#28So, FoundationDB is a pretty low level distributed key-value store with transactions. Most applications will need something higher level, like a SQL or document db frontend which could be built on top. I'm curios what people have started using FoundationDB for. Any interesting stories to share?
a) Rewrite SQL code. In our case we are using Node.JS and all SQL libraries are very very slow. Even replacing one with another is enormous work. b) Rewrite to a new language. It was also an option since querying Postgres can take 1ms, but parsing response can easily take 100ms+. That trashed our event loop and causes awful latency. c) Rewrite to high performance NoSQL database.
We picked a last one. In context of a Node.js we were able to write really thin layer on top of FDB that works super-fast and in a way we needed.
In my previous startup we eventually ditched all SQL from our codebase too since SQL databases is just too slow for low latency messaging apps. There are no simple way to shard data, there are always random locks around your database (which blocks connections). Locks are really hard to debug sometimes. How to scale single SQL server? All of this is doable, but in FDB it was basically free.
We migrated to FDB and got almost x100 improvement in latency/performance. And unlike SQL-code that was very carefully crafted we can do nasty things. Like - "hey, let's just pull this key every 100ms and check for a new value" or "hey, let's do it on 10s of instances at the same time?". In this situations Postgres started to consume all available CPU. You can easily creep out SQL with a single instance of your app. We haven't managed this to do with FDB for 1/2 of the cost. We are often in situation when someone commit something with a bug and, for example, started to pull data every millisecond in N^2 streams where N is number of online users. In this situations we just can't see any impact at all on our platform. Just spikes in monitoring.
FDB is wonderful thing - it allows you to forget about optimizing performance of your queries, forget about managing backups and replication. It just works!
Re: FoundationDB 6.0 released, featuring multi-region support
#29Re: FoundationDB 6.0 released, featuring multi-region support
#30Earlier quoted context omitted.
We are actually spend two weeks rewriting our code from SQL to FoundationDB (we have built our own simple ORM). One of the huge problems is a lack of consistency constraints. Since during development data make became broken in various ways (and we have done several times). And right now there are no way to implement simplest constraints on database level.
Could you give an example of what you mean? This is very relevant for my talk.
There are almost no easy way to ensure that everything is OK.
Also I have fear that we probably deleted something and there are no way to prohibit modification of certain keys.