OrioleDB beta7: Benchmarks
orioledb.com
OrioleDB beta7: Benchmarks
1–10 of 17 posts
Re: OrioleDB beta7: Benchmarks
#2Some notable benchmarks from the OrioleDB beta7 release:
* 5.5x Faster at 500 Warehouses: In TPC-C benchmarks with 500 warehouses, OrioleDB outperformed PostgreSQL's default heap tables by 5.5 times. This highlights significant gains in workloads that stress shared memory cache bottlenecks.
* 2.7x Faster at 1000 Warehouses: Even when the data doesn't fit into the OS memory cache (at 1000 warehouses), OrioleDB was 2.7 times faster. Its index-organized tables improve data locality, reducing disk I/O and boosting performance.
Try it yourself:
Clone the OrioleDB repository from GitHub and follow the build instructions, or use their Docker image. https://github.com/orioledb/orioledb#installation Alternatively, run OrioleDB on Supabase. Read the blog post for more details. https://supabase.com/blog/orioledb-launch
Run your own workloads or existing benchmarks like go-tpc or HammerDB to see the performance differences firsthand. We Would love to hear about others' experiences with OrioleDB, especially in production-like environments or with different workloads.
Re: OrioleDB beta7: Benchmarks
#3[deleted]
Re: OrioleDB beta7: Benchmarks
#4> Our roadmap includes support for multi-master configurations, enhancing availability and fault tolerance. This will allow for read and write operations across multiple nodes, improving performance and resilience.
Fu--ing finally!
Re: OrioleDB beta7: Benchmarks
#5> Our roadmap includes support for multi-master configurations, enhancing availability and fault tolerance. This will allow for read and write operations across multiple nodes, improving performance and resilience. Fu--ing finally!
what's your use-case for multi-master that would not be supported by something like regional routed for read-replicas with high availability? i.e. do you have a specific need for low global write latency, or is it motivated by something else?
Re: OrioleDB beta7: Benchmarks
#6> Our roadmap includes support for multi-master configurations, enhancing availability and fault tolerance. This will allow for read and write operations across multiple nodes, improving performance and resilience. Fu--ing finally!
what's your use-case for multi-master that would not be supported by something like regional routed for read-replicas with high availability? i.e. do you have a specific need for low global write latency, or is it motivated by something else?
> do you have a specific need for low global write latency, or is it motivated by something else?
It's motivated by liking of reliable systems that keep working when a node fails.
There are a bunch of non-webscale companies that pick mysql over postgresql because they can use either percona xtradb cluster or galera cluster.
Having an open source multi-master solution would mean that postgresql could finally be used over there as well.
Re: OrioleDB beta7: Benchmarks
#7Earlier quoted context omitted.
what's your use-case for multi-master that would not be supported by something like regional routed for read-replicas with high availability? i.e. do you have a specific need for low global write latency, or is it motivated by something else?
> do you have a specific need for low global write latency, or is it motivated by something else? It's motivated by liking of reliable systems that keep working when a node fails. There are a bunch of non-webscale companies that pick mysql over postgresql because they can use either percona xtradb cluster or galera cluster. Having an open source multi-master solution would mean that postgresql could finally be used o…
yeah, fair shout
`columnar index` for hybrid analytical workloads and `multi-master` roadmap items haven't been put in an order on the schedule yet so maybe multi-master makes sense to do first. Both align with webscale requirements though. Columnar would move into the AlloyDB space and multi-master would be more like PlanetScale (although not quite the same audience in the latter case)
Re: OrioleDB beta7: Benchmarks
#8All my kudos for the OrioleDB team, they have been working for years with the Postgres core devs to get the extensibility patches they need for their storage extensions merged back.
It’s not just about building their extension but actually making Postgres better for everyone. I would have loved that big corps would have taken this approach, as it opens the doors to others to add features for different use cases and making postgres more of a DBMS framework
Re: OrioleDB beta7: Benchmarks
#9All my kudos for the OrioleDB team, they have been working for years with the Postgres core devs to get the extensibility patches they need for their storage extensions merged back. It’s not just about building their extension but actually making Postgres better for everyone. I would have loved that big corps would have taken this approach, as it opens the doors to others to add features for different use cases and m…
> I would have loved that big corps would have taken this approach, as it opens the doors to others to add features for different use cases
EDB and Cybertech definitely made a great start with Zheap[0] although the initiative stalled for whatever reason
Hopefully the community can support this effort to improve the Table AM API - it would be beneficial even beyond oriole. As you point out, a Pluggable Storage system in Postgres would open up a few new use cases
Re: OrioleDB beta7: Benchmarks
#10Earlier quoted context omitted.
what's your use-case for multi-master that would not be supported by something like regional routed for read-replicas with high availability? i.e. do you have a specific need for low global write latency, or is it motivated by something else?
> do you have a specific need for low global write latency, or is it motivated by something else? It's motivated by liking of reliable systems that keep working when a node fails. There are a bunch of non-webscale companies that pick mysql over postgresql because they can use either percona xtradb cluster or galera cluster. Having an open source multi-master solution would mean that postgresql could finally be used o…
Thank you, your feedback is appreciated.
The important design issue about building active-active multi-master on the base of raft protocol is about being able to apply changes locally without immediately putting them into a log (without sacrificing durability). MySQL implements a binlog, which is separate from a log, to ensure durability. OrioleDB implements copy-on-write checkpoints and row-level WAL. That gives us a chance to implement MM and durability using a single log.