3 ms·
We (I'm a co-founder) run the following: - 1B (10^9) rows/sec with 86 servers https://www.scylladb.com/2019/12/12/how-scylla-scaled-to-one-billion-rows-a-s
by thekozmo 4y ago
We (I'm a co-founder) run the following:
- 1B (10^9) rows/sec with 86 servers
https://www.scylladb.com/2019/12/12/how-scylla-scaled-to-one-billion-rows-a-second/ https://www.scylladb.com/2019/12/12/how-scylla-scaled-to-one...
- 1PB with 20 servers
https://www.scylladb.com/presentations/operating-at-monstrous-new-scales-benchmarking-petabyte-workloads-on-scylladb/ https://www.scylladb.com/presentations/operating-at-monstrou...
- Comcast moved from 970 Cassandra nodes (and 60 nodes of cache) to 78 Scylla nodes - https://www.scylladb.com/2020/01/15/comcast-sprinting-from-cassandra-to-scylla/ https://www.scylladb.com/2020/01/15/comcast-sprinting-from-c...
- Palo Alto Networks run 8600 clusters(!) of ScyllaDB
https://www.scylladb.com/2022/06/14/how-palo-alto-networks-replaced-kafka-with-scylladb-for-stream-processing/ https://www.scylladb.com/2022/06/14/how-palo-alto-networks-r...
ScyllaDB excels in throughput and latency, we have also a better compaction algorithm that saves 37% of storage compared to C*.
Usually one can replace lots of small nodes with gigantic nodes that have more
resources and it allows much better management.
To run 100PB Scylla will need more than 300 nodes, even thousands but definitely
not what Apple throw at the problem.
- thekozmo 4y agoThere is no magic behind Scylla, mainly lots of hard work, hundreds of years of engineering, based on the former C* design which is based on Dynamo/Bigtable. The JVM is part of the problem, not all of it. The main issue is that it hides the hardware and makes tracing harder - instruction level and block level. At Scylla we strive for efficiency, every operation is tagged with a priority class for the CPU and I/O schedulers. Folks are welcome to read the blogs about those topic. Lots of details and hard work