HN user
That's not true. Scylla does multi-threading. Scylla is a single process, single address space. It does pin the threads to individual hyper threads but there are additional other workers in the background as well.
Many need SVB, we (ScyllaDB) received a great service from them in the past. Later on we just used them as one of our banks, obviously, going forward, we're diversifying our services.
The problem for startups is that debt provider who are also a bank require to move most of the business to that provider. It's not the case other types of debt providers. w.r.t debt - everybody use this mechanism, doesn't matter if you're small or big.
ScyllaDB uses AGPL, a good and valid license
There 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
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... - 1PB with 20 servers 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-c...
- Palo Alto Networks run 8600 clusters(!) of ScyllaDB 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.
Listening to SQLite creator podcast (https://corecursive.com/066-sqlite-with-richard-hipp/# ), it does feel that Glauber is right about weird collaboration standards. The guy is against gmail, git, etc. Fossil may be better for SQlite today, w/o many contributors, that's the problem Glauber is trying to solve
This is indeed what we (ScyllaDB) do, pretty much everywhere. It works great for 95% of our users. Discord wanted to add a level of guarantee since they observed a too high level of local disk failures.
Am ScyllaDB but Marc did completely independent work. The client vcpus don't matter that much, the experiment compares the server side, the client shouldn't suck. When we test ScyllaDB or other DBs, we run benchmarks for hours and days. This is just a stateless, static http daemon, so short timing is reasonable.
The whole intent is to make it a learning experience, if you wish to reproduce, try it yourself. It's aligned with past measurements of ours and also with former Linux optimizations by Marc.
Good point. This is more of a tcp stack comparison between the kernel and userspace. Seastar has a sharded (per core) stack, which is very beneficial when the number of threads is high
What's amazing is that the seastar tcp stack hasn't been changed over the past 7 years, while the kernel received plenty of improvements (in order to close the gap vs kernel bypass mechanisms). Still, for >> 99% of users, there is no need to bypass the kernel.
ScyllaDB uses Seastar as an engine and the DynamoDB compatible API use HTTP parsing, so this use case is real. Of course the DB has much more to do than this benchmark with a static http reply but Scylla also uses many more core in the server, thus it is close to real life. We do use the kernel's tcp stack, due to all of its features and also since we don't have capacity for a deeper analysis.
Some K/V workloads are affected by the networking stack and we recently seen issues if we chose not the ideal interrupt mode (multiqueue vs single queue in small machines)
Impressive stuff! Worth to try to run the OSv unikernel (one of my babies) in it.
Indeed quite a journey. If you love DynamoDB and like open source, give Scylla a try (disclosure me==founder): https://www.scylladb.com/alternator/
It's not the open source license which we can't forbid using, it's the enterprise version.
Hmm, AGPL is proprietary? This isn't aligned with the OSI.
Clickhouse and other solutions you mentioned are for analytics while Scylla and Cassandra are for real-time. You can't compare the two types of tech
It's possible to improve cql to a cql++ .. if you start going this path, it will lead to sql which isn't bad a all ;)
It's not 'fair' to compare CQL to SQL, if you compare CQL to DynamoDB's http api, which scylla implements as well, you'll see that cql is better: https://www.scylladb.com/2020/05/12/comparing-cql-and-the-dy...
LWT on Scylla is much faster than its C* implementation. As one of the co-founders, I agree that SQL and the relational model are superior than CQL. However, either they do not scale or even when they do (newsql), they are 10x slower and handle less volume, etc.
The right way to use NoSQL is when you know your scaling model. LWT helps you to serialize important tables.
Scylla consistently makes improvements in operations, consistency and functionality, so more to come, see what we'll announce at the summit next month
We did something in the neighborhood, check it out: https://www.scylladb.com/2016/02/16/fault-injection-filesyst...
Correct but Jepsen focuses on consistency and correctness and not on destructive. Scylla is exposed to range tombstone issue like many other LSMs. We recently have been improving them - check the most recent issues: https://github.com/scylladb/scylla/issues?q=is%3Aissue+is%3A...
The new direction is really promising. However, we at ScyllaDB (/me am a co-founder) already meet most of the requirements. We use C++20 with an advanced shard per core, we have an open format for the files, you can easily import/export them. One can use Scylla as a general DB and also run KairosDB for timeseries specific if needed.
Recently we have a MSc project to add Parquet which is a very good direction, couldn't agree more.
They do. CQL is 33% faster with Scylla than Scylla with DynamoDB. The lack of topology knowledge and lack of prepared statement hurt
ClickHouse achieved good (great) results. However, it's a bad comparison. Clickhouse is an analytics DB while Scylla is a realtime, random access one. /me am Scylla co-founder.
We could stack 100k rows in a single partition and be 1000x faster in this use case than the performance we demonstrate but we wanted to keep it real. Actually the use case we wanted to show is a single row per partition which would require more machines but surprisingly we couldn't provision that many on AWS.
The presented usecase by ClickHouse is 100x slower on writes (8M row/s) as they report. It doesn't matter since it's just a completely different use case. Use Clickhouse for analytics (I wonder why stop in SSE and not to go all the way to the GPU like SqreamDB) and use Scylla for OLTP
To some extent yes. It's not 100% protection. AGPL is just the right model, closes the loophole that GPL left. If you get to change the code, you must contribute the changes back. That's all
Kudos for AWS for the ability to launch so many services, many of them are competing with each other or complimentary.
At first I (disclosure, ScyllaDB co-founder) called their serverless a bluff but I gave it a try and it's nice to create a table without waiting for any server. That said, I know personally that Dynamo scales really slow so they wouldn't catch up the speed. It also say 1 digit ms latency but state the plan to improve jvm overhead.
Another funny thing is (regardless of tech) that AWS folks have wonderful people talking about open source but this very solution isn't open at all. It's impossible to figure out what's Cassandra and what's Dynamo. How about a diagram?
Lastly, it's pricey (for 1M iops you'll pay $3.5M/year!!) and doesn't have counters, UDT, materialized views and plenty other features.
If you got down here, hey, give ScyllaDB a try, it's OSS (AGPL) and as a service on AWS and has features that neither C* or MCS has - workload prioritization for instance. Dor
Pls let us know what you think about the results!
Agree it's annoying (I'm one of the co-founders) but it's the minimal 'eval' to make sure users succeed to maximize the value from their downloads. We mainly push them to slack and to share monitoring and logs with us, until they get to prod
My claim is only an assumption. However, after our experience with not reaching the reserve limit plus the example they provided that didn't scale to a million of iops lead my to this guesstimate. We on the other hand have plenty of examples how to reach a million iops per server with a simple data model. But ignore me, just give Scylla a try! Our support is awesome too
The benchmark was done as fair as possible but I'm the vendor, yes, don't take my word (despite good background in OSS and earlier achievements). Listen to our users:
- Here's a webinar by one of our customers explaining how they migrated from Mongo+Hive, received better consistency and simplicity while saving 5X: https://www.youtube.com/watch?v=1hXKd_rNyuE
- See how kiwi.com got a CRAZY gain with Scylla vs Cassandra: https://youtu.be/Bqh09LG_QDE?t=833
- See Grab (South east Asia Uber) about Dynamo vs Scylladb: https://www.scylladb.com/users/case-study-grab-hails-scylla-...
Go ahead and give it a try and see for yourself
There are tons of limitation on the on-demand, certainly it cannot go to extent of 120k ops. Check their example, they toy with a tiny workload.