4 ms·

This is the second article after the "caddy" one that I am having troble finding a usecase. Nginx eixsts, why do I need to learn caddy? Redis exists, why do I

This is the second article after the "caddy" one that I am having troble finding a usecase. Nginx eixsts, why do I need to learn caddy? Redis exists, why do I need to learn FundationDB?

deleted 3y ago
[deleted]
qaq 3y ago
If you don't have a use case that requires FoundationDB you def. do not have to learn it.
- abhishekjha 3y ago
  Well, for that the comparative features needs to be clearly laid out. It solves a problem that others have not solved. Which problem is that? And how better does it work than whatever there was?
  - mst 3y ago
    It's an analysis of a paper, not a feature checklist, so the article is for people who want to understand more about how FoundationDB works rather than trying to provide a "which system should I use" explanation. Though "super reliable distributed database presenting a single logical shard to client code" is a class of system for which I don't think there's anything else even close out there, and I suspect generally if that's something you -need- then you'll already know that.
  - qaq 3y ago
    It's a highly scalable (as in powers iCloud services with billion users) distributed transactional KV store. It's owned by Apple and mostly developed by Apple and Snowflake.
rapsey 3y ago
FoundationDB replaces MySQL/PostgreSQL (if the tradeoffs are acceptable) or Cassandra. It is a reliable distributed store. Unless you are running Redis only with nothing else, fdb and redis do not play in the same space.
- diogenes4 3y ago
  > FoundationDB replaces MySQL/PostgreSQL Only in terms of transactions across multiple data centers. In every other way vertically scaler sql performs better, especially for your dollar.
  - rapsey 3y ago
    Performance is not the only metric. High availability (i.e. no single point of failure) with strong consistency are very important for some.
    - diogenes4 3y ago
      Is availability not an aspect of performance? But of course, hence why i referenced multidc transactions.
      - rapsey 3y ago
        > Is availability not an aspect of performance? Not to my understanding. Can you elaborate?
        diogenes4 3y ago
        Well, an unavailable service has trivially (perfectly) bad performance. I'm not sure how you'd conceive of performance to exclude availability, or what that conception would give us.
- riku_iki 3y ago
  > FoundationDB replaces Cassandra I think they have different use cases: fdb when you want transactions, cassandra when you want throughput.
diogenes4 3y ago
These technologies are primarily aimed at B2B markets and market them accordingly. You likely need none of them. Any meaningful technology is open source.
- jen20 3y ago
  > Any meaningful technology is open source. Clearly untrue, however FoundationDB is open source, with a permissive license. https://github.com/apple/foundationdb https://github.com/apple/foundationdb So is much of the operational tooling for it: https://github.com/FoundationDB/fdb-kubernetes-operator https://github.com/FoundationDB/fdb-kubernetes-operator
yjftsjthsd-h 3y ago
I don't know enough to compare databases, but: > Nginx eixsts, why do I need to learn caddy? If you've learned to manage nginx, by all means use it, but for new users it's more like "caddy works with like 3 lines of configuration, including HTTPS, why would I learn nginx?"
- jddj 3y ago
  I don't want to derail too much but this is interesting, because I recently had the opposite experience. I hadn't spun up a webserver other than Kestrel for a long time, and was absolutely looking for the easiest solution for putting a reverse proxy in front of an API. No huge traffic requirements or low latency, seemed a perfect fit for caddy. Then I googled to make sure that the necessary featureset was there and saw that rate limiting is a plugin that's marked WIP. What's more, there seemed to be a couple to choose from. So I went through the certbot steps (very quick + straightforward) and wrote the short nginx config based on one page of getting started docs and was up and running.
  - damianh 3y ago
    Since you mention Kestrel I'll assume .NET so I suggest you take a look at yarp. It's fully programmable and "plugins" are just small pieces of middleware, a lot of which is available as a nuget package. (I'm the author of ProxyKit that predated yarp)
    - jddj 3y ago
      Oh, very nice. We do use YARP actually on some of those other projects, and I was going to mention it. It's great. This particular (small, internal) project was in Go, so I wanted to use the opportunity to forego any extra runtimes and just used nginx.
baq 3y ago
> Redis exists, why do I need to learn FundationDB? so you know that this question does not make sense.
- abhishekjha 3y ago
  From the article : >non-sharded, strict serializable, fault tolerant, key-value store that supports point writes, reads and range reads. k-v store, non-sharded, fault tolerant, reads and range reads. Redis has these. >strict serializable Redis's single threaded model does this (maybe, not entirely sure). Please help me understand why is this comparison orthongonal or does it really replace redis in ways that I don't understand.
  - jlokier 3y ago
    The short version: If you have precious data you want to be stored very reliably and consistently, choose FDB over Redis, (or choose a SQL database with a good reputation for reliable storage). The two words that come to mind are "durable", which is the "D" in ACID, and the extensive testing of FDB's distributed robustness properties in a wide range of testing and fault scenarios. If you want Redis to store durably, which means the data is reliably stored by the time the database replies to the client and won't magically disappear if there's a crash or power failure just after, you need to turn on its "fsync at every query" mode. This mode is very slow so durable storage is off by default in Redis. So by default Redit can lose the last 1 second of writes on power failure, kernel crash, or virtual machine abrupt termination. In other words, FDB is desiged for very reliable storage of every transactional write, and has been built and tested with that in mind. Whereas Redis is not; they consider losing recent data in some realistic scenarios to be an acceptable default, and even with "fsync on every query" mode turned on it does not have the same level of testing and focus on durable distributed storage as FDB. Without the "D", things built on top which fill out the rest of ACID transactions and database indexing aren't as reliable either. For example "C", consistency (with foreign keys, indexes, etc), is impossible to maintain if some of your recent writes may be lost while others are not. I don't know what guarantees Redis offers in this area, but it does not seem to be the focus. Whereas FDB authors make it clear this sort of thing is a core focus of the product which it is architected for and also heavily tested.
quickthrower2 3y ago
Well NGINX and Docker exist why do I need Caddy at least.
javier2 3y ago
Its more like if you are considering Cassandra, but would like transactions, take a look at FoundationDB first. Cassandra is coming with some tx support in v5 most likely(?).

This is the second article after the "caddy" one that I am having troble finding a usecase. Nginx eixsts, why do I need to learn caddy? Redis exists, why do I need to learn FundationDB?

deleted 3y ago

[deleted]

qaq 3y ago

If you don't have a use case that requires FoundationDB you def. do not have to learn it.

abhishekjha 3y ago
Well, for that the comparative features needs to be clearly laid out. It solves a problem that others have not solved. Which problem is that? And how better does it work than whatever there was?
- mst 3y ago
  It's an analysis of a paper, not a feature checklist, so the article is for people who want to understand more about how FoundationDB works rather than trying to provide a "which system should I use" explanation. Though "super reliable distributed database presenting a single logical shard to client code" is a class of system for which I don't think there's anything else even close out there, and I suspect generally if that's something you -need- then you'll already know that.
- qaq 3y ago
  It's a highly scalable (as in powers iCloud services with billion users) distributed transactional KV store. It's owned by Apple and mostly developed by Apple and Snowflake.

rapsey 3y ago

FoundationDB replaces MySQL/PostgreSQL (if the tradeoffs are acceptable) or Cassandra. It is a reliable distributed store. Unless you are running Redis only with nothing else, fdb and redis do not play in the same space.

diogenes4 3y ago
> FoundationDB replaces MySQL/PostgreSQL Only in terms of transactions across multiple data centers. In every other way vertically scaler sql performs better, especially for your dollar.
- rapsey 3y ago
  Performance is not the only metric. High availability (i.e. no single point of failure) with strong consistency are very important for some.
  - diogenes4 3y ago
    Is availability not an aspect of performance? But of course, hence why i referenced multidc transactions.
    - rapsey 3y ago
      > Is availability not an aspect of performance? Not to my understanding. Can you elaborate?
      - diogenes4 3y ago
        Well, an unavailable service has trivially (perfectly) bad performance. I'm not sure how you'd conceive of performance to exclude availability, or what that conception would give us.
riku_iki 3y ago
> FoundationDB replaces Cassandra I think they have different use cases: fdb when you want transactions, cassandra when you want throughput.

diogenes4 3y ago

These technologies are primarily aimed at B2B markets and market them accordingly. You likely need none of them. Any meaningful technology is open source.

jen20 3y ago
> Any meaningful technology is open source. Clearly untrue, however FoundationDB is open source, with a permissive license. https://github.com/apple/foundationdb https://github.com/apple/foundationdb So is much of the operational tooling for it: https://github.com/FoundationDB/fdb-kubernetes-operator https://github.com/FoundationDB/fdb-kubernetes-operator

yjftsjthsd-h 3y ago

I don't know enough to compare databases, but: > Nginx eixsts, why do I need to learn caddy? If you've learned to manage nginx, by all means use it, but for new users it's more like "caddy works with like 3 lines of configuration, including HTTPS, why would I learn nginx?"

jddj 3y ago
I don't want to derail too much but this is interesting, because I recently had the opposite experience. I hadn't spun up a webserver other than Kestrel for a long time, and was absolutely looking for the easiest solution for putting a reverse proxy in front of an API. No huge traffic requirements or low latency, seemed a perfect fit for caddy. Then I googled to make sure that the necessary featureset was there and saw that rate limiting is a plugin that's marked WIP. What's more, there seemed to be a couple to choose from. So I went through the certbot steps (very quick + straightforward) and wrote the short nginx config based on one page of getting started docs and was up and running.
- damianh 3y ago
  Since you mention Kestrel I'll assume .NET so I suggest you take a look at yarp. It's fully programmable and "plugins" are just small pieces of middleware, a lot of which is available as a nuget package. (I'm the author of ProxyKit that predated yarp)
  - jddj 3y ago
    Oh, very nice. We do use YARP actually on some of those other projects, and I was going to mention it. It's great. This particular (small, internal) project was in Go, so I wanted to use the opportunity to forego any extra runtimes and just used nginx.

baq 3y ago

> Redis exists, why do I need to learn FundationDB? so you know that this question does not make sense.

abhishekjha 3y ago
From the article : >non-sharded, strict serializable, fault tolerant, key-value store that supports point writes, reads and range reads. k-v store, non-sharded, fault tolerant, reads and range reads. Redis has these. >strict serializable Redis's single threaded model does this (maybe, not entirely sure). Please help me understand why is this comparison orthongonal or does it really replace redis in ways that I don't understand.
- jlokier 3y ago
  The short version: If you have precious data you want to be stored very reliably and consistently, choose FDB over Redis, (or choose a SQL database with a good reputation for reliable storage). The two words that come to mind are "durable", which is the "D" in ACID, and the extensive testing of FDB's distributed robustness properties in a wide range of testing and fault scenarios. If you want Redis to store durably, which means the data is reliably stored by the time the database replies to the client and won't magically disappear if there's a crash or power failure just after, you need to turn on its "fsync at every query" mode. This mode is very slow so durable storage is off by default in Redis. So by default Redit can lose the last 1 second of writes on power failure, kernel crash, or virtual machine abrupt termination. In other words, FDB is desiged for very reliable storage of every transactional write, and has been built and tested with that in mind. Whereas Redis is not; they consider losing recent data in some realistic scenarios to be an acceptable default, and even with "fsync on every query" mode turned on it does not have the same level of testing and focus on durable distributed storage as FDB. Without the "D", things built on top which fill out the rest of ACID transactions and database indexing aren't as reliable either. For example "C", consistency (with foreign keys, indexes, etc), is impossible to maintain if some of your recent writes may be lost while others are not. I don't know what guarantees Redis offers in this area, but it does not seem to be the focus. Whereas FDB authors make it clear this sort of thing is a core focus of the product which it is architected for and also heavily tested.

quickthrower2 3y ago

Well NGINX and Docker exist why do I need Caddy at least.

javier2 3y ago

Its more like if you are considering Cassandra, but would like transactions, take a look at FoundationDB first. Cassandra is coming with some tx support in v5 most likely(?).