Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
remon
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
21 ms
·
181.
▲
by
remon
13y ago
Mayer always struck me as one of the least competent of the big tech CEOs. Almost every time her name hits the news it's due to something that, one way or another, reflects poorly on Yahoo. Having marketing in charge of editorial/
182.
▲
by
remon
13y ago
"Someone in 2001 wrote..." click X
183.
▲
by
remon
13y ago
Great article. I understood quite a few of those words!
184.
▲
by
remon
13y ago
I agree. That said, all these people using HN as a soap box is probably not ideal either.
185.
▲
by
remon
13y ago
Nothing at all other than the ever surfacing assumption by a lot of people that financial traffic is done on ACID like principles (rather than eventual consistency which it actually is). MySQL was a random example as should have been somewh
186.
▲
by
remon
13y ago
Yeah, so, you don't work on financial infrastructure. That stuff is almost exclusively eventually consistent. And I wasn't arguing that you should use MongoDB or anything else instead. Merely that claims that ACID is the holy grai
187.
▲
by
remon
13y ago
In other news; water is wet.
188.
▲
by
remon
13y ago
What is crazy is people claiming a bank uses a transactional database for their financial transaction processing or that all parts of that system are "ACID". Both are false. Don't like MongoDB? Fair enough, it isn't grea
189.
▲
by
remon
13y ago
Worked at a bank as what? Working at a bank clearly doesn't make someone an expert on their IT infrastructure. The actual financial transaction infrastructure isn't ACID.
190.
▲
by
remon
13y ago
Very few financial systems are ACID. Why do people still think banks run on bloody MySQL?
191.
▲
by
remon
13y ago
In case you're being sarcastic; http://en.wikipedia.org/wiki/Tulip_mania Not international but in all other ways it's somewhat similar. Fun story too.
192.
▲
by
remon
13y ago
"..on January 8th, 2010"
193.
▲
by
remon
13y ago
I see what you mean but allow me to theorycraft a bit more : Changes and removal of packages are considerably more rare than additions and either happens relatively infrequently. This makes cluster wide cache invalidation relatively trivial
194.
▲
Microsoft releases wonderfully loopy experimental GIF-jiggler
(theregister.co.uk)
6 points
by
remon
13y ago
|
1 comments
195.
▲
by
remon
13y ago
I agree that from a functionality perspective this is largely true, at least on paper. That said, if running costs become a significant bottleneck CouchDB becomes a less obvious choice. Sometimes there's a reluctance to migrate from on
196.
▲
by
remon
13y ago
Certainly less than reinventing the wheel. You have to include development cost, maintenance and so forth that is not needed or significantly reduced on hosted content delivery services. See my post in this thread for details.
197.
▲
by
remon
13y ago
1) Not trivial at all. As documented in a rather broad range of papers and whatnot. You're almost certainly oversimplifying the problem. 2) For gigantic DBs the preallocation overhead is almost non-existent. 3) Fair enough. Your last p
198.
▲
by
remon
13y ago
I'll be that guy; I'm a little confused as to why this would require $200,000 (the requested total funding requested) to solve. From the site itself : 614,680,691 requests per month come down to ~230 request per second. Allowing f
199.
▲
by
remon
13y ago
You had me until the "like Cassandra" bit ;) If there's one thing where Cassandra loses the battle with other NoSQL tech then cluster managements is probably it. Also, it's a bit unfair to compare RDBMSs with Cassandra.
200.
▲
by
remon
13y ago
Why "continue to cripple"? It's actually one of the things that can be changed quite easily at some point in time and doesn't introduce insurmountable backwards compatibility issues. And as I mentioned (and you cut out o
201.
▲
by
remon
13y ago
It's constant overhead with some spikiness to it. See my reply in this thread for details.
202.
▲
by
remon
13y ago
This is not true at all. The actual realization the past years is that strictly enforced relationality (is that a word?) and transactions are constructs that are not always or even rarely actually needed. Eventual consistency, schemaless da
203.
▲
by
remon
13y ago
Although it is true that MongoDB uses a lot of disk compared to your average RDMS there are reasons for that. 1) MongoDB (and various other NoSQL solution) are schemaless and thus have to store document fields along with the values for each