4 ms·

"We separated storage and compute" No. just no. Compute where the data lives, else you incur traffic cost and latency. A lesson learned in life, known from t

"We separated storage and compute" No. just no. Compute where the data lives, else you incur traffic cost and latency. A lesson learned in life, known from the dawn of time..

wnolens 4y ago
Easy trade-off to get scalability. Writing log off-host is fast with 10G network and nvme on the other side (see Amazon Aurora, Microsoft hyper scale, etc)
manigandham 4y ago
This isn't binary as much as it's a continuum of abstractions already. Cloud servers already use virtualized disks where the actual drives can be in an entirely different building from the compute racks. Do you consider that separate? Separating storage and compute at the database nodes is just one architecture method that allows for simpler and more efficient scaling in modern cloud-based deployments where you have large pools object storage that's fast and close. I think you'd be surprised by what you can achieve with some metadata and caching.
userbinator 4y ago
The goal of the "cloud" is to extract maximum $$$ from its users. Once you realise that, it's not hard to see through the marketing propaganda and the rest of the decisions following. else you incur traffic cost and latency Thus, they are separated so they can charge you (more) for them separately.
- panarky 4y ago
  Zero bandwidth cost within the same zone.
dunkeylim 4y ago
What? This isn't controversial, Snowflake did this years ago and this is the main reason it became a $40B business. Amazon came out with Redshift, a cloud OLAP database, but it tied compute with data so teams couldn't scale compute and data separately and thus had to pay disproportional costs to their required workloads. Sure, there's good reasons to keep compute and data together. But there is obviously a massive market for technologies that keep them separate...
- TruthWillHurt 4y ago
  Snowflake is a BI data platform, which doesn't require low-latency and fast response like systems powered by RDBs do. Apples and oranges.
  - ranguna 4y ago
    I believe you were the one who implicitly started the apples and oranges comparison with your original post > "no. Just no." Conveys the feeling that there is no scenario where doing this is feasibly and you yourself just said it's acceptable for BI but not AI training. So the "no. Just no." actually means, "my use case does not allow for this, so I believe no one else should use this" which is a fallacy on its own. In conclusion, this is fairly usable, but like everything else, it's not for all use cases.
mattashii 4y ago
Do note that many installations of PostgreSQL already have some form of "separation of storage and compute" through a networked storage solution like NFS, EBS, or other SAN-like systems. The major part of what Neon does is remove the file system abstraction that is between that Storage and Compute, so that we can better utilize the available resources because we can better select what information is or isn't being lost. A good example of what removing the file system abstraction enables for us is effectively free PITR, (lagging) replicas, and data branching. This is because PostgreSQL's file-system-based storage engine expects to be the only one working on the data directory, which means that any FS attached to a replica cannot be shared. If you remove that file-system based storage engine and plug in a different storage engine, those expectations are removed too, and after some effort integrating into the smgr-APIs, we're now able to provide a storage layer that only needs to contain one copy of the data for N physical replicas, instead of N copies.
- TruthWillHurt 4y ago
  The fact some systems do it, doesn't mean it is correct or optimals. The latency of NFS & EBS or EFS is actually the reason many businesses *do not* use them for their databases. I've seen deployments that had to go bare-metal because the tiny latency of EBS caused their compute times to rise exponentialy (doing AI training).
  - mattashii 4y ago
    I agree that it does have its limitations, but databases are all about trade-offs. Talking about the "correctness" of a choice between tradeoffs is weird though. Running your database on hard drives nowadays is not a great choice - yet people still did that because the cost of hard drives was way cheaper than that of memory. Running your database in a way that doesn't guarantee that a 'committed' response actually retains the changes that it was responding on - yet people still ran their database in such configuration to scrape the barrel on performance. All Neon does is put up another option: If you don't mind the implications of networked storage, then here's one database system that has zero-cost cloning and does not lose data on single-node failure.

"We separated storage and compute" No. just no. Compute where the data lives, else you incur traffic cost and latency. A lesson learned in life, known from the dawn of time..

wnolens 4y ago

Easy trade-off to get scalability. Writing log off-host is fast with 10G network and nvme on the other side (see Amazon Aurora, Microsoft hyper scale, etc)

manigandham 4y ago

This isn't binary as much as it's a continuum of abstractions already. Cloud servers already use virtualized disks where the actual drives can be in an entirely different building from the compute racks. Do you consider that separate? Separating storage and compute at the database nodes is just one architecture method that allows for simpler and more efficient scaling in modern cloud-based deployments where you have large pools object storage that's fast and close. I think you'd be surprised by what you can achieve with some metadata and caching.

userbinator 4y ago

The goal of the "cloud" is to extract maximum $$$ from its users. Once you realise that, it's not hard to see through the marketing propaganda and the rest of the decisions following. else you incur traffic cost and latency Thus, they are separated so they can charge you (more) for them separately.

panarky 4y ago
Zero bandwidth cost within the same zone.

dunkeylim 4y ago

What? This isn't controversial, Snowflake did this years ago and this is the main reason it became a $40B business. Amazon came out with Redshift, a cloud OLAP database, but it tied compute with data so teams couldn't scale compute and data separately and thus had to pay disproportional costs to their required workloads. Sure, there's good reasons to keep compute and data together. But there is obviously a massive market for technologies that keep them separate...

TruthWillHurt 4y ago
Snowflake is a BI data platform, which doesn't require low-latency and fast response like systems powered by RDBs do. Apples and oranges.
- ranguna 4y ago
  I believe you were the one who implicitly started the apples and oranges comparison with your original post > "no. Just no." Conveys the feeling that there is no scenario where doing this is feasibly and you yourself just said it's acceptable for BI but not AI training. So the "no. Just no." actually means, "my use case does not allow for this, so I believe no one else should use this" which is a fallacy on its own. In conclusion, this is fairly usable, but like everything else, it's not for all use cases.

mattashii 4y ago

Do note that many installations of PostgreSQL already have some form of "separation of storage and compute" through a networked storage solution like NFS, EBS, or other SAN-like systems. The major part of what Neon does is remove the file system abstraction that is between that Storage and Compute, so that we can better utilize the available resources because we can better select what information is or isn't being lost. A good example of what removing the file system abstraction enables for us is effectively free PITR, (lagging) replicas, and data branching. This is because PostgreSQL's file-system-based storage engine expects to be the only one working on the data directory, which means that any FS attached to a replica cannot be shared. If you remove that file-system based storage engine and plug in a different storage engine, those expectations are removed too, and after some effort integrating into the smgr-APIs, we're now able to provide a storage layer that only needs to contain one copy of the data for N physical replicas, instead of N copies.

TruthWillHurt 4y ago
The fact some systems do it, doesn't mean it is correct or optimals. The latency of NFS & EBS or EFS is actually the reason many businesses *do not* use them for their databases. I've seen deployments that had to go bare-metal because the tiny latency of EBS caused their compute times to rise exponentialy (doing AI training).
- mattashii 4y ago
  I agree that it does have its limitations, but databases are all about trade-offs. Talking about the "correctness" of a choice between tradeoffs is weird though. Running your database on hard drives nowadays is not a great choice - yet people still did that because the cost of hard drives was way cheaper than that of memory. Running your database in a way that doesn't guarantee that a 'committed' response actually retains the changes that it was responding on - yet people still ran their database in such configuration to scrape the barrel on performance. All Neon does is put up another option: If you don't mind the implications of networked storage, then here's one database system that has zero-cost cloning and does not lose data on single-node failure.