Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
jhugg
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
22 ms
·
181.
▲
by
jhugg
11y ago
Yeah, I don't doubt it. I can only speak from my experience.
182.
▲
by
jhugg
11y ago
View from the other side a bit. I've been the de-facto hardware purchaser for my startup as it's grown from 3 to 50 people. We used to be close to 50/50 mac/linux and would let you get whatever you want. Over the years,
183.
▲
by
jhugg
11y ago
VoltDB is pretty fantastic at counters. (VoltDB Engineer)
184.
▲
by
jhugg
11y ago
Well, those systems are largely not distributed, barring SQL Parallel Data Warehouse and, very arguably, RAC. Jepson tests network partitions... so less useful.
185.
▲
by
jhugg
11y ago
1) Slightly faster than requesting to pair with a BT device and entering a passcode. 2) Security benefits. Nobody can pair without being pretty obvious. 3) It’s a slick user experience. Feels like sci-fi when you do it. They could have used
186.
▲
by
jhugg
11y ago
This makes a lot of sense technically, but I fear for a world where I need a driver from vendor X to use my otherwise standard disk from vendor X. It’s the way with many server disk controllers today, but if it trickles down to cheaper mach
187.
▲
by
jhugg
11y ago
The proper time for austerity is when things are good. When things are bad, juice it up, especially if you can borrow at rates that are negative when inflation adjusted. The problem with austerity now to make the long term better is that it
188.
▲
Announcing Incremental MapReduce for VoltDB
(voltdb.com)
16 points
by
jhugg
11y ago
|
0 comments
189.
▲
by
jhugg
12y ago
Is that broadly true, or are you thinking of software engineers?
190.
▲
Three Fast Data Application Patterns
(highscalability.com)
5 points
by
jhugg
12y ago
|
0 comments
191.
▲
by
jhugg
12y ago
Totally lazy commenting by me here, but isn't there a mobile shell that was designed to work well over high latency, iffy connections. This? https://mosh.mit.edu Maybe we’re talking about the same problems.
192.
▲
by
jhugg
12y ago
Wow look at the downvotes. I guess I'm assuming that said PhD isn't doing nothing but unit tests all data, but rather writing unit tests for their code. Good unit tests are hard, often harder than product code. Smarts and experien
193.
▲
by
jhugg
12y ago
Would that be so bad?
194.
▲
by
jhugg
12y ago
That doesn’t seem like a terrible deal. $100/per CLA wouldn’t even be that bad for a thousand CLAs, i.e. it would scale for a while.
195.
▲
by
jhugg
12y ago
So there are plenty of systems that compile portions of a SQL plan to bytecode (LLVM or JVM) or machine code directly. Usually, the part you compile is the SQL plan and most importantly the predicate filters. Common operations like networki
196.
▲
by
jhugg
12y ago
FoundationDB solves completely different problems than Teradata. FDB isn't an analytical store.
197.
▲
by
jhugg
12y ago
I could have easily written the same post months ago, yes. None of these thoughts are new. It's actually precisely because FDB isn't a perceived competitor anymore that I can write this. As a vendor, I actually have much less of a
198.
▲
by
jhugg
12y ago
Right. I'm not being critical of the underlying KV tech. It seemed pretty impressive from what I know. My two points were: 1. The SQL thing wasn't gonna work they way they went about it. 2. Without SQL or some other powerful query
199.
▲
by
jhugg
12y ago
When I started VoltDB, Mike Stonebraker told me we had to be 10x faster than Oracle sitting on a RAM drive, or nobody would care. 5x wasn't interesting to him. It seems like FDB-SQL was closer to 1x, with a much better replication stor
200.
▲
by
jhugg
12y ago
Not even close. FDB did arbitrary multi-key transactions. Cassandra can only do Compare-And-Set on single keys IIRC.
201.
▲
by
jhugg
12y ago
I think this may slightly improve the too-fine-granularity locking, and it might make full table scans a bit more efficient, but otherwise most of what I wrote in the post applies. In fact the metadata problem has gotten worse and you might
202.
▲
by
jhugg
12y ago
So there is a point here. Apple is trying to compete with Google. Google has some amazing distributed systems, including Spanner, F1, MillWheel, etc... Apple has Cassandra and other OSS/COTS software. Not to ding Cassandra, but this is
203.
▲
by
jhugg
12y ago
Meh. Yes, it's critical about the "layers" model and about the SQL implementation in particular. Most of what I write isn't this critical, but I thought there was actually an interesting point here so I wrote it down. Ta
204.
▲
by
jhugg
12y ago
You mean for the SQL layer and client libs and the other things that were open, right? The core code was all closed. I would imagine maybe the SQL parser would be of value if it could be ressurected. Standalone SQL parsers are hard to find.
205.
▲
by
jhugg
12y ago
VoltDB has fantastic HA, but yes, not in the OSS version. You might be surprised how many apps deploy on VoltDB with cross-partition transactions making up a solid chunk of their workload. Yes, they're slower than partitioned operation
206.
▲
by
jhugg
12y ago
CAP doesn't really apply to non-distributed systems. So I'm with the original sentiment. There is no CA.
207.
▲
by
jhugg
12y ago
VoltDB. Multi-key tranactions. Serializable C in ACID. CP in CAP. Open source.
208.
▲
by
jhugg
12y ago
Seems to work for Mongo, but yeah. You pay me and the licensing question goes away. You still get to poke around the source.
209.
▲
by
jhugg
12y ago
Except it turns out no, the layer thing is practically hard to pull off. See my other comment. https://news.ycombinator.com/item?id=9262673
210.
▲
by
jhugg
12y ago
Except the SQL part didn't work well. If you want those same features, consider VoltDB. It makes different tradeoffs on what kinds of ops are fast , but has all of those features. Essentially arbitrary two-key transactions are slower.
More ›