sergei

5 ms·

1.
by sergei 13y ago
Several problems here: 1. Unlike your dataset, the tpcc dataset for the benchmark was not memory resident. Total dataset size was 786G. Just shrinking the dataset to fit in memory would substantially change the numbers. 2. The tpcc workload
2.
by sergei 13y ago
What do you base your performance claim vs Clustrix on?
3.
by sergei 13y ago
I frequently see apps with thousands of distinct query signatures. Having a developer manually chose indexes, join ordering, aggregation method, (just to name a few) for every single query, and then select multiple plans because input param
4.
by sergei 13y ago
In practice, you end up with apps which dynamically build up predicates in different sections of the code. And when you combine that with many predicates, many tables, and other constraints such as ordering or aggregates, things get complex
5.
by sergei 13y ago
A decent cost based optimizer will be right most of the time, and you have hints for the cases where it falters. Your approach is simply hiding the query optimizer choices inside of the app, making it more fragile. Let's say I have two fiel
6.
by sergei 13y ago
Check out a previous comment thread on the subject: https://news.ycombinator.com/item?id=5068489
7.
by sergei 13y ago
Check out a previous comment thread on the subject: https://news.ycombinator.com/item?id=5068489
8.
Clustrix 5.0 SQL DB now Generally Available on AWS Marketplace(clustrix.com)
18 points by sergei 13y ago|2 comments
9.
by sergei 14y ago
Yes, but they are in-memory only. I think the largest database they support is 50GB. It's the kind of solution that works really well if you have key-value store problem where you want really low latencies. Telco call session state and sess
10.
by sergei 14y ago
1) Both joins and aggregates are processed in parallel. In short, the larger your cluster, the faster we evaluate a complex query because we can bring more hardware to the problem. You can get a better idea of how we scale distributed joins
11.
by sergei 14y ago
It's a good question. We built the entire database from the ground up, without any MySQL code. So while we support most of the frequently used features, we don't support everything. You can get a list of unsupported features and differences
12.
by sergei 14y ago
Try it. You'll like it :)
13.
by sergei 14y ago
It's different from a typical sharding approach (including what MongoDB does). In their model, you take a single key and distribute your data using that key (e.g. user_id). The problem surfaces when you look at secondary indexes. If you hav
14.
by sergei 14y ago
Some reading material on the distributed approach: http://www.clustrix.com/blog/bid/242790/Scaling-Distributed-... http://www.clustrix.com/Portals/146389/docs/clustrix_a_new_a...
15.
Clustrix, a distributed SQL DB, launches on AWS(clustrix.com)
115 points by sergei 14y ago|38 comments
16.
by sergei 15y ago
San Francisco, CA Clustrix: Systems Developers Clustrix has developed a highly scalable distributed database system from the ground up. We are looking for skilled systems developers to help us with the next generation of Clustrix Database.
17.
by sergei 16y ago
The problem with Mongo's concurrency approach is that when you introduce writes to the equation (which take out an exclusive lock on the database), the system becomes unusable. Here's a link to some of the benchmarking work I did. Ignoring
18.
Profile Driven Performance Optimization(sergeitsar.blogspot.com)
3 points by sergei 16y ago|0 comments
19.
Exploring the Limits of Datacenter Temprature(perspectives.mvdirona.com)
2 points by sergei 16y ago|0 comments
20.
Clustrix as a Document Store: Blending SQL and JSON Documents (sergeitsar.blogspot.com)
18 points by sergei 16y ago|0 comments
21.
by sergei 16y ago
Sorry, but "hardware failure" is a fault, and when you can't deal with it, you're not tolerant. And with larger clusters, you see hardware faults on a regular basis. So saying we're ok in the nominal mode is not fault tolerance.
22.
by sergei 16y ago
1. Yes, I recognize that MongoDB will automatically fail over when we go from N nodes in the set to N - 1. But how do I get back to N nodes? That's completely manual. 2. What happens when I read an update that succeeded on the master but th
23.
by sergei 16y ago
1. Say I have a 2 node replica set. Now a replica dies, permanently. How is the recovery automated? These are quotes directly from your docs: http://www.mongodb.org/display/DOCS/Resyncing+a+Very+Stale+R... "1. Delete all data. If you stop
24.
by sergei 16y ago
The article is not about the DBMS interface. It's about Fault Tolerance (what happens when stuff breaks) and Availability (can I still use my database when there is a fault). MongoDB claims to support both. So does Clustrix. I'm comparing b
25.
MongoDB vs. Clustrix: Fault Tolerance and Availability(sergeitsar.blogspot.com)
34 points by sergei 16y ago|23 comments
26.
by sergei 16y ago
A large part of the message I'm trying to convey is: 1. A DBMS is much more than just the interface. I'm going to write more on the subject. Whether you're using SQL, datalog, BSON, etc. -- there's a broader set of desirable features that's
27.
by sergei 16y ago
I updated the post with the benchmark source.
28.
by sergei 16y ago
OK. Fair enough. I'll post the benchmarks.
29.
by sergei 16y ago
I chose Mongo because it gets a lot more attention on HN than any other database. I don't remember the last time I saw a post on Cassandra on here...
30.
by sergei 16y ago
These folks disagree with you. There are many more behind them. http://gigaom.com/cloud/clustrix-lifts-the-curtain-on-early-... And plenty of folks use MySQL (and PogreSQL to a much lesser extent). You just can't scale those.

More ›