6 ms·

Neon CEO here. There are a number of ideas in the database space that the industry is adopting across the board: - Separation of storage and compute (Neon, Al

by nikita 4y ago

Neon CEO here. There are a number of ideas in the database space that the industry is adopting across the board: - Separation of storage and compute (Neon, AlloyDB, Aurora). Every cloud database should built one. It's a big undertaking, but benefits are undeniable. - Good query processor for analytics (Snowflake, Velox, Singlestore) - Open source. Especially in OLTP open source == trust - HTAP. Can run mixed workload (Singlestore, Unistore): both OLTP (apps) and OLAP (reporting). This has always been a dream, but we still live in the world of dedicated systems: E.g. Snowflake and Postgres. - Shared nothing sharding (Vitess). This is the most controversial as you lose compatibility with the mothership (MySQL for Vitess). So it's unclear this will be the dominant architecture in the future. I think the world may get to "dynamic sharding" where storage stays separate and compute can be multinode and the user can easily and instantly change the number of nodes.

swyx 4y ago
since you were also a founder of Singlestore, just wondering - what will be Neon's take on HTAP workloads? trying to see how much you mean it that the industry is "adopting (HTAP) across the board"
- nikita 4y ago
  I wouldn't say HTAP is an across the board trend. The need is mostly in the enterprise where we see high value mixed workloads. Neon will take a Postgres centric POV. I consider a few approaches, but not committing to any particular at this point. The reason to not commit is that there is a lot more opportunity for Neon in serverless, devtools, and edge. And it makes a ton more sense to partner for OLAP workloads. So what is Postgres centric POV: - Plugins like Timescale and Citus - Seamless integration with sending CDC to Snowflake, Singlestore, Databricks, Clickhouse, and Motherduck - FDW for integration with Snowflake, Singlestore, Clickhouse, Databricks, and Motherduck - We looked at putting DuckDB on Neon storage with Jordan Tigani, but it was too big of a lift as DuckDB doesn't push all data through the WAL. Maybe in the future.
  - zX41ZdbW 4y ago
    Let's commit this to ClickBench: https://github.com/neondatabase/neon/pull/2855 https://github.com/neondatabase/neon/pull/2855 So, NeonDB can be compared with other serverless Postgres offerings.
    - nikita 4y ago
      The reason we run OLAP bench is because when you separate storage full table get impacted: you fetch pages from remote storage one by one and the mitigation is prefetch. So our goal is to be on par with vanilla Postgres. We don't care about winning OLAP benchmarks.
      - zX41ZdbW 4y ago
        ClickBench is still ok to compare non-OLAP databases on OLAP workloads - filter away the column-oriented DBMS, and you will be left with the comparison of non-OLAP databases. I think it makes sense to add NeonDB for the sake of completeness.
        nikita 4y ago
        I think lots and lots of benchmarks are useful internally. They highlight where the soft spots are. This is however very different from publishing benchmark results. As a dbaas vendor we should publish benchmarks that your user base really cares about which demonstrate that the system is mature and can handle the core workload your users expect you to handle. That is why publishing an OLAP benchmark results for an OLTP system makes very very little sense. (BTW OLAP systems like Clickhouse should really publish TPC-DS SF1000+ results) For OLTP systems there is TPC-C but it's actually not that telling as it is so simple. I can start seeing that people in OLTP care more and more about latencies, hence all the edge related work and optimization of the drivers. So Neon will be publishing end-to-end latencies benchmarks and also make sure it is on par with vanilla Postgres on a broad set of benchmarks. Those we will run internally and the results will simply be commits on our github.
  - swyx 4y ago
gavinray 4y ago
Really enjoyed the talk from your engineer Heikki at Andy's CMU "Databases!" seminar series earlier this year, great stuff =) https://www.youtube.com/watch?v=rES0yzeERns https://www.youtube.com/watch?v=rES0yzeERns Also, it's been neat to have mostly worked our replacing our old Heroku integration at Hasura with you folks.
emptysea 4y ago
I’m not well versed in the tech but is Spanner the sort of dynamic sharding approach your talking about?
- gavinray 4y ago
  Scylla also uses a shared-nothing sharding approach, they have an open-source "asynchronous I/O engine" toolkit that is used inside of ScyllaDB called Seastar They have some good reading on this approach in the Seastar docs if you're curious, it's a great general introduction to Shared Nothing: https://seastar.io/shared-nothing/#:~:text=The%20Seastar%20Model%3A%20Shared%2Dnothing,not%20shared%20memory%20between%20threads https://seastar.io/shared-nothing/#:~:text=The%20Seastar%20M.... https://www.linuxfoundation.org/webinars/under-the-hood-of-a-shard-per-core-database-architecture https://www.linuxfoundation.org/webinars/under-the-hood-of-a... This is usually generalized to some variation of "Physical-OS-thread-per-CPU-core" architecture, where each CPU core gets it's own dedicated chunk of data. You use hashing or some other mechanism to route requests for data to the right core. Each CPU core can have user-land concurrency or "virtual threads" (fibers/coroutines/etc) as well, so you're not limited to sequential code necessarily. A combination of thread-per-core x userland-coroutines-per-thread is how modern query processing approaches like "Morsel-Driven Parallelism" work. CPU-1-OS-THREAD-1 COROUTINE_1 COROUTINE_2 CPU-2-OS-THREAD-2 COROUTINE_35 ... COROUTINE_102 https://db.in.tum.de/~leis/papers/morsels.pdf https://db.in.tum.de/~leis/papers/morsels.pdf
  - AtlasBarfed 4y ago
    Scylla is a C++ rewrite of cassandra, the threading has been better as well with thread-per-core. Cassandra 4.0 has some thread-per-core rearchitecture so it remains to be seen if Scylla has performance advantages it used to tout. I have not checked if Scylla ever caught up to Cassandra 3.0's feature set, last I checked it had not. It may be "going its own way" on features as well. I believe (they can correct me). My personal recommendation would be to start with Cassandra, and when operations allow it, move to scylla if performance testing shows it is better. There is also exotic stuff like Rocksandra. Cassandra and Scylla are fundamentally similar in operations (add/remove nodes, scaling, etc). The scylla folks will contend the operations are easier since they get more perf per node so you need less nodes. It's a good idea with cassandra / scylla to bootstrap with a performance testing, data loading, provisioning loop. It gets you used to operations and the tooling for backups, loads, and load testing and metrics.
jandrewrogers 4y ago
The separation of storage and compute is controversial, though it is definitely convenient for cloud operators. It is literally going backward in terms of the available storage bandwidth, and many modern database architectures can very effectively use all the storage bandwidth available in modern systems. There is not enough network bandwidth, and won’t be for the foreseeable future, for running storage over networks to be efficient. Database workloads are also starting to move to edge environments, which make it even worse. The resource mismatch currently leaves a lot of compute sitting idle in practice. Another issue with this model is that it tends to offer poor ratios of bandwidth to storage size. This is at odds with the desire to run mixed workloads in a single system.
- gavinray 4y ago
  > The separation of storage and compute is controversial I don't think it's a controversial topic, it's an emerging trend. See for example this slide from the recent RocksDB meetup on their vision for the next 3 years of RocksDB's future: https://twitter.com/GavinRayDev/status/1600666127025156096 https://twitter.com/GavinRayDev/status/1600666127025156096 Disaggregated storage is becoming quite a hot topic, and there are several technologies fueling this. There are two major advances happening in terms of disk I/O right now (that aren't to do with async IO uring stuff) 1. NVMe Zones + NVMe FDP specs, which are ways for userland applications to control placement of writes on drive (like a software Flash-Translation-Layer) 2. NVMe-over-Fabrics or similar technologies (with rdma/tcp) enables the access of a remote disk with 'comparable' latency to that of a local one. E.g. if local disk access is 100us, AWS can give you 110us with NVMe-OF. These two advances support the growing trend of disaggregated storage --- Full credit to Arun George from the Samsung Memory group for explaining this to me.
  - jandrewrogers 4y ago
    The storage-over-fabric latency improvements allow it to work well for software that was not particularly optimized for storage performance, which has obvious benefits that I am not arguing. There is a good reason storage-over-fabric has been a popular database deployment model for decades, it does have advantages, but this emerging trend is nothing new nor are the issues that it has. For systems that are highly optimized for storage performance, storage bandwidth tends to be more important than storage latency and that is what is being sacrificed for the sake of disaggregating storage. I see integer factor reductions in workload throughput when deployed on disaggregated storage versus the usually NVMe JBOD, and that factor tracks real-world storage bandwidth pretty well, particularly at high storage densities. At scale, these economics start to matter quite a lot. To be clear, disaggregated storage has no effect on database design generally, seeing as how it has been widely used for decades. It does put an artificial floor on achievable throughput for many workloads due to the bandwidth bottleneck. When people realize this then the pendulum swings the other way (again), so I wouldn't want to overfit for disaggregated storage.
zX41ZdbW 4y ago
The most developed analytical query engine as of today is ClickHouse [1]. It is open-source, has the separation of storage and compute and the best performance. ClickHouse is a source of inspiration for many emerging database engines: Velox, Doris, DuckDB, Datafusion... [1] https://github.com/ClickHouse/ClickHouse https://github.com/ClickHouse/ClickHouse Disclaimer: I work on ClickHouse.
- ddorian43 4y ago
  > has the separation of storage and compute and the best performance. This part is not yet production ready though. And it's unclear when it will be. Though no other open source OLAP does it either AFAIK.
  - _dark_matter_ 4y ago
    SparkSQL + delta lake definitely counts as an open source OLAP separated compute/storage.
Ataraxy 4y ago
I actually look forward to Neon but won't actually use it for real until pricing becomes available.
- nikita 4y ago
  Stay tuned. It's coming very very soon.
fulafel 4y ago
Regarding separation of storage and compute, do those DBs you mention enable merging the application backend code and db compute node to a single process? Meaning I would deploy my application to the DB compute node and use its runtime, or have the compute node present as a component I can import to my backend code as a library. I think this is one powerful thing about Datomic (and maybe XTDB?).

by nikita 4y ago

swyx 4y ago

since you were also a founder of Singlestore, just wondering - what will be Neon's take on HTAP workloads? trying to see how much you mean it that the industry is "adopting (HTAP) across the board"

nikita 4y ago
I wouldn't say HTAP is an across the board trend. The need is mostly in the enterprise where we see high value mixed workloads. Neon will take a Postgres centric POV. I consider a few approaches, but not committing to any particular at this point. The reason to not commit is that there is a lot more opportunity for Neon in serverless, devtools, and edge. And it makes a ton more sense to partner for OLAP workloads. So what is Postgres centric POV: - Plugins like Timescale and Citus - Seamless integration with sending CDC to Snowflake, Singlestore, Databricks, Clickhouse, and Motherduck - FDW for integration with Snowflake, Singlestore, Clickhouse, Databricks, and Motherduck - We looked at putting DuckDB on Neon storage with Jordan Tigani, but it was too big of a lift as DuckDB doesn't push all data through the WAL. Maybe in the future.
- zX41ZdbW 4y ago
  Let's commit this to ClickBench: https://github.com/neondatabase/neon/pull/2855 https://github.com/neondatabase/neon/pull/2855 So, NeonDB can be compared with other serverless Postgres offerings.
  - nikita 4y ago
    The reason we run OLAP bench is because when you separate storage full table get impacted: you fetch pages from remote storage one by one and the mitigation is prefetch. So our goal is to be on par with vanilla Postgres. We don't care about winning OLAP benchmarks.
    - zX41ZdbW 4y ago
      ClickBench is still ok to compare non-OLAP databases on OLAP workloads - filter away the column-oriented DBMS, and you will be left with the comparison of non-OLAP databases. I think it makes sense to add NeonDB for the sake of completeness.
      - nikita 4y ago
        I think lots and lots of benchmarks are useful internally. They highlight where the soft spots are. This is however very different from publishing benchmark results. As a dbaas vendor we should publish benchmarks that your user base really cares about which demonstrate that the system is mature and can handle the core workload your users expect you to handle. That is why publishing an OLAP benchmark results for an OLTP system makes very very little sense. (BTW OLAP systems like Clickhouse should really publish TPC-DS SF1000+ results) For OLTP systems there is TPC-C but it's actually not that telling as it is so simple. I can start seeing that people in OLTP care more and more about latencies, hence all the edge related work and optimization of the drivers. So Neon will be publishing end-to-end latencies benchmarks and also make sure it is on par with vanilla Postgres on a broad set of benchmarks. Those we will run internally and the results will simply be commits on our github.
- swyx 4y ago

gavinray 4y ago

Really enjoyed the talk from your engineer Heikki at Andy's CMU "Databases!" seminar series earlier this year, great stuff =) https://www.youtube.com/watch?v=rES0yzeERns https://www.youtube.com/watch?v=rES0yzeERns Also, it's been neat to have mostly worked our replacing our old Heroku integration at Hasura with you folks.

emptysea 4y ago

I’m not well versed in the tech but is Spanner the sort of dynamic sharding approach your talking about?

gavinray 4y ago
Scylla also uses a shared-nothing sharding approach, they have an open-source "asynchronous I/O engine" toolkit that is used inside of ScyllaDB called Seastar They have some good reading on this approach in the Seastar docs if you're curious, it's a great general introduction to Shared Nothing: https://seastar.io/shared-nothing/#:~:text=The%20Seastar%20Model%3A%20Shared%2Dnothing,not%20shared%20memory%20between%20threads https://seastar.io/shared-nothing/#:~:text=The%20Seastar%20M.... https://www.linuxfoundation.org/webinars/under-the-hood-of-a-shard-per-core-database-architecture https://www.linuxfoundation.org/webinars/under-the-hood-of-a... This is usually generalized to some variation of "Physical-OS-thread-per-CPU-core" architecture, where each CPU core gets it's own dedicated chunk of data. You use hashing or some other mechanism to route requests for data to the right core. Each CPU core can have user-land concurrency or "virtual threads" (fibers/coroutines/etc) as well, so you're not limited to sequential code necessarily. A combination of thread-per-core x userland-coroutines-per-thread is how modern query processing approaches like "Morsel-Driven Parallelism" work. CPU-1-OS-THREAD-1 COROUTINE_1 COROUTINE_2 CPU-2-OS-THREAD-2 COROUTINE_35 ... COROUTINE_102 https://db.in.tum.de/~leis/papers/morsels.pdf https://db.in.tum.de/~leis/papers/morsels.pdf
- AtlasBarfed 4y ago
  Scylla is a C++ rewrite of cassandra, the threading has been better as well with thread-per-core. Cassandra 4.0 has some thread-per-core rearchitecture so it remains to be seen if Scylla has performance advantages it used to tout. I have not checked if Scylla ever caught up to Cassandra 3.0's feature set, last I checked it had not. It may be "going its own way" on features as well. I believe (they can correct me). My personal recommendation would be to start with Cassandra, and when operations allow it, move to scylla if performance testing shows it is better. There is also exotic stuff like Rocksandra. Cassandra and Scylla are fundamentally similar in operations (add/remove nodes, scaling, etc). The scylla folks will contend the operations are easier since they get more perf per node so you need less nodes. It's a good idea with cassandra / scylla to bootstrap with a performance testing, data loading, provisioning loop. It gets you used to operations and the tooling for backups, loads, and load testing and metrics.

jandrewrogers 4y ago

The separation of storage and compute is controversial, though it is definitely convenient for cloud operators. It is literally going backward in terms of the available storage bandwidth, and many modern database architectures can very effectively use all the storage bandwidth available in modern systems. There is not enough network bandwidth, and won’t be for the foreseeable future, for running storage over networks to be efficient. Database workloads are also starting to move to edge environments, which make it even worse. The resource mismatch currently leaves a lot of compute sitting idle in practice. Another issue with this model is that it tends to offer poor ratios of bandwidth to storage size. This is at odds with the desire to run mixed workloads in a single system.

gavinray 4y ago
> The separation of storage and compute is controversial I don't think it's a controversial topic, it's an emerging trend. See for example this slide from the recent RocksDB meetup on their vision for the next 3 years of RocksDB's future: https://twitter.com/GavinRayDev/status/1600666127025156096 https://twitter.com/GavinRayDev/status/1600666127025156096 Disaggregated storage is becoming quite a hot topic, and there are several technologies fueling this. There are two major advances happening in terms of disk I/O right now (that aren't to do with async IO uring stuff) 1. NVMe Zones + NVMe FDP specs, which are ways for userland applications to control placement of writes on drive (like a software Flash-Translation-Layer) 2. NVMe-over-Fabrics or similar technologies (with rdma/tcp) enables the access of a remote disk with 'comparable' latency to that of a local one. E.g. if local disk access is 100us, AWS can give you 110us with NVMe-OF. These two advances support the growing trend of disaggregated storage --- Full credit to Arun George from the Samsung Memory group for explaining this to me.
- jandrewrogers 4y ago
  The storage-over-fabric latency improvements allow it to work well for software that was not particularly optimized for storage performance, which has obvious benefits that I am not arguing. There is a good reason storage-over-fabric has been a popular database deployment model for decades, it does have advantages, but this emerging trend is nothing new nor are the issues that it has. For systems that are highly optimized for storage performance, storage bandwidth tends to be more important than storage latency and that is what is being sacrificed for the sake of disaggregating storage. I see integer factor reductions in workload throughput when deployed on disaggregated storage versus the usually NVMe JBOD, and that factor tracks real-world storage bandwidth pretty well, particularly at high storage densities. At scale, these economics start to matter quite a lot. To be clear, disaggregated storage has no effect on database design generally, seeing as how it has been widely used for decades. It does put an artificial floor on achievable throughput for many workloads due to the bandwidth bottleneck. When people realize this then the pendulum swings the other way (again), so I wouldn't want to overfit for disaggregated storage.

zX41ZdbW 4y ago

The most developed analytical query engine as of today is ClickHouse [1]. It is open-source, has the separation of storage and compute and the best performance. ClickHouse is a source of inspiration for many emerging database engines: Velox, Doris, DuckDB, Datafusion... [1] https://github.com/ClickHouse/ClickHouse https://github.com/ClickHouse/ClickHouse Disclaimer: I work on ClickHouse.

ddorian43 4y ago
> has the separation of storage and compute and the best performance. This part is not yet production ready though. And it's unclear when it will be. Though no other open source OLAP does it either AFAIK.
- _dark_matter_ 4y ago
  SparkSQL + delta lake definitely counts as an open source OLAP separated compute/storage.

Ataraxy 4y ago

I actually look forward to Neon but won't actually use it for real until pricing becomes available.

nikita 4y ago
Stay tuned. It's coming very very soon.

fulafel 4y ago

Regarding separation of storage and compute, do those DBs you mention enable merging the application backend code and db compute node to a single process? Meaning I would deploy my application to the DB compute node and use its runtime, or have the compute node present as a component I can import to my backend code as a library. I think this is one powerful thing about Datomic (and maybe XTDB?).