Cloven

oh my god I wonder what dalton caldwell had for breakfast today

Redis is a particular product, not a catch-all for low latency in-memory data stores. So saying your product is a Redis (which you did, rather than making an analogy) was merely embarrassing attention grabbing marketing palaver which does discredit to your product and suggests that you don't have the attention to detail and critical thinking skills required to properly implement a product in this space. See: MongoDB.

I don't think you understand Redis. Redis is also a key-value store, but implements a variety of structures, not just RTree, and has a large number of operations on those data structures (http://redis.io).

Spacebase appears to be a significantly more primitive KV store that implements RTree. Not that that's bad; looks interesting, even though it appears that the product won't be free, and so in my opinion is probably doomed.

Using 'Redis' in the title is just embarrassing for Spacebase and, by extension, for YC too. No need to troll the professional developer community with ridiculous comparisons.

Product appears to have nothing to do with Redis and isn't even remotely compatible. Marketer uses buzzword to attempt to get credibility and hence immediately loses all credibility with actual market.

The good thing about the AppStore password timing out after 15 minutes is that you can hand your child the ipad/iphone/etc. and not get a surprise $5,000 itunes bill.

Maybe it's just me, but I find the e-paper Kindles to be absolutely terrible reading experiences. The text is still relatively low contrast, but the real deal killer is the refresh flash. It's jarring and disruptive and it is nothing like a page turn.

how about 'the evidence on display in front of us'?

Reading between the lines from both the posted note and their persistent failure to provide correct statuses: the ops guys over there are in full CYA desperation mode somewhere around 100% of the time, and a culture of 'it wasn't me', fuelled either by job fear, or promotion fear, or fear of being noticed by bezos, is in full bloom.

PHP is more expressive than python, ruby, or java. I see.

you are incorrect.

I would say there's a difference. PHP is bad because it has a wide variety of objectively awful design flaws, its standard library is a conflicted mess, and it's unperformant. Implementing it into a modern architecture is highly correlated with sloppiness and technical debt.

ORM is bad because the impedance mismatch between an object and a relational model is very difficult to get right.

Frequently, for example, one iterates over collections of objects in the OO paradigm. A naively written ORM, or one without sufficient introspection into the loop intent, can translate that into N select statements, each incurring a network round trip.

The end result is that OO programmers have to understand not only their object code, but also the relational model, and finally too the ORM's peculiarities and suboptimalities. So in attempting to solve one problem, most of the time you end up with three.

That said, there is a sweet spot in ORMs for simple code (e.g. most web apps, where ActiveRecord and Sequel and the like are fine). But there's no sweet spot for PHP code. Every line written is technical debt.

I wonder what Microsoft's hardware partners think of all this. It's not just competition, they actively disparaged the others by saying that it was as powerful as all the ultrabooks out there.

Beyond the other listed benefits: Percona also provides support contracts quite inexpensively, which can be worth their weight in diamonds. I bought a support contract after our Percona instance started to slow down, and the level of quality of the analysis and the results blew my mind. And I've been doing SQL for 25 years.

95% of even good developers wouldn't be able to tell when a sql sanitization function is poorly coded or has a hidden gotcha. Having the source is not nearly as important as trusting the upstream to be smart and to promptly resolve security issues when discovered.

first, poison all the employees and burn down the restaurant. Then, write recipes to ensure that this does not happen.

"At scale in production, adding a new node took days to complete all the handoffs..."

That's a bit of a headscratcher. What is happening during those 'days' and what is the primary limiting factor?

I keep meaning to get into Riak, but then stuff like this where the system has crazy moments that are impossible to coherently reason about keep popping up.

"Today, however, Prasad no longer feels the need for the security blanket. “In the tablet version of the server, we’re still using Node, but now the clients are talking directly from the load balancers to Node, there’s no nginx.”"

I thought the headline was just another SEO attention grab, but it's actually factually correct; there's no response to this sort of thing other than bemused incredulity.

That sounds like a lot of fun to maintain and keep version control on, especially when they're written by different people with different motivations.

datetime is a data format problem, not a data structure format problem.

Nirvana, good point about ops/sec not being a be-all end-all, but I'd continue to argue that you're looking at the problem the wrong way. As the technical director for my game company, my primary concern is not 'whether the database has an in memory database mode' or 'does the database have a distributed scalability solution', but 'will it do what I want?' tied with 'how much does it cost technically, organizationally, chronologically and monetarily to fulfil my requirement?'

That starts with, rationally enough, ops/sec. Because you would not believe the sheer number of databases or solutions that fall down horribly when you ask the ops/sec question. Anyone remember EJB 1.0? And the Riak answer should be "yes. We can do ops/sec. On 1 m1.large node, we do X,000 writes/sec and A,000 reads/sec. On 10 nodes, we do YY,000 writes/sec and BB,000 reads/sec. Our largest installation has QQQ nodes."

Then the question becomes "ok, how about complex queries that aren't just get/set?" And the Riak answer (note: I'm making these up, but you get the idea) is "well, our story continues to evolve, but first, understand that everything is a document, exposed to you as JSON over a web service. Then, we have a pretty complete map/reduce implementation which uses either Erlang or JS as the language of your choice. With a fairly complex query that hits thirty fields of a random complex document, across 3 nodes we do about X,000 queries/sec, and across 100 nodes we do about YY,000 queries/sec on m1.larges."

That sort of goal-driven questioning goes on for a while in a logical evaluator's mind. There are a lot of categories. "How do I support this thing? Ease of development? Do I have to know erlang? What's the first resource that your typical Riak installation runs out of first? What common design pattern or use case is totally crappy on Riak?"

I still like the idea of Riak quite a bit, but it's not enough to say that it has a scaling distributed solution and flowers and candy for everybody as a result, because that design makes it axiomatic that some use case will be pessimal. The database has been designed to fill some portion of the set of all database needs; which ones in particular is it best at, which is it less good at, and which is it not intended at all to address?

You show your 'superiority' (sic) to people whose prejudices (sic) make them unable (sic) to recognize it (sic) by talking like a reasonable adult at an appropriate level of abstraction.

(and by the way, redis can exist on more than 1 node. My facebook game involves 8 redis shards and can read-scale essentially infinitely, with a high degree of data safety)

I think the Riak pages are not geared at the people making the selection, e.g., architect-level technologists. The wiki is full of marketing claims ('Riak is the most powerful open-source, distributed database you'll ever put into production') ('Riak is the most boring database you’ll ever run in production').

But then suddenly:

'curl -v -X PUT -d '{"bar":"baz"}' -H "Content-Type: application/json" \ -H "X-Riak-Vclock: a85hYGBgzGDKBVIszMk55zKYEhnzWBlKIniO8mUBAA==" \ http://127.0.0.1:8091/riak/test/doc?returnbody=true

now, I understand why that is the way that it is -- the Riak guys are simultaneously very proud of their product, and also extremely technical -- but it's missing the middle ground. The middle ground is where you explain the characteristics of the system in non-marketing terms, describe what it's good at and what one could reasonably expect it to do, and describe also where it fails horribly and what you should not try to use it for. Once that's been outlined, _then_ bring out X-Riak-Vclock.

By comparison, e.g., redis.io has simple pages describing every command in the system and, critically, the associated algorithmic complexity and discussion of likely issues and problems. It describes what performance expectations are likely to be achieved on commodity hardware. And it allows you to test out your thoughts in real time right there on the page.

Personally, I have very little idea how, e.g., Riak compares to Redis. And I built Erlang and Riak from source and did the tutorial. I don't have a sense for how many ops/sec Riak can manage, what the equivalent to sinterstore and sunion look like, what the minimal real architecture for a production box setup should be. And a lot of the tutorial fills me with The Fear.

Which brings me to the last point: The Fear of Riak is pretty strong, and that's because very few people are running erlang on purpose in production. A lot of developers (and certainly devops people) have a hard enough time with their existing stack, without bringing on an entirely alien software, logging, alerting, monitoring, managing, and developing stack, and trying to understand how to reason about it. And, even those developers who can work up the courage to dive into erlang will have to deal with the fact that they will be novices for quite a long time on an extremely technical product that is designed to be at the core of their world.

1) no, rackspace boxes have two networks; an internal (inside the cloud) and an external (public)

Heavy Ruby is not designed for speed, and much of its heaviness causes slowness. It's entirely possible/likely that mruby will be in the same ballpark as luajit2 soon after release.

eazyBI looks very interesting, but your site and sales pitch seem pretty unpolished. How big is your team and where are you situated?

5 months to develop a trivial shell script? Where could you possibly work that this could remotely be true?

I guess that's what getting paid $45K to write a shell script does for your ego. What a shame.

1) 'This is what makes most complaints in the facebook-makes-money-off-of-you vein a complete misunderstanding of technology. [...] For the purposes of advertising, facebook does not need you to disclose relevant information to anyone but facebook.'

You didn't understand cstross's sentence. He said that the social networks are motivating their users to disclose information [that is] relevant to advertisers; he didn't say that they are disclosing the information directly to advertisers.

2) Handwaving about applications and like buttons aside, it's pragmatically trivial through the facebook ecosystem to capture a great deal of data about individuals that they might not natively believe they are exposing. I know this because I personally do this (for benign reasons).

So this compared Amazon's cc.4xl server @ 2.10 an hour against, e.g., Rackspace's 16G server at 0.96 an hour, and used its local storage in RAID 0 vs Rackspace's SAN storage? I'm pretty sure you couldn't have compared apples to oranges any better.

Have you looked at YCSB? It's a pathologically poorly designed benchmark. It essentially tests how good a developer is at implementing a Java wrapper around a toy object model and interfacing that with a database.

A proper benchmark would hold constant things which are reasonably expected to be constant: the use case scenario, the data, the warmup requirements, the concurrency, and the count. If feeling frisky, the hardware, operating system and networking environment. And then step back.

For example, "On an EC2 Extra Large instance running Ubuntu 11.10 with whatever tuning the package recommends, what is the transactions per second when 50 vendor-provided clients on the same LAN are attempting to write and read random records out of a pool of 10mm 5k records?"

I'm sorry, did you really criticize my logic on the grounds that it would not fit into a dialog box? The fact is, the dialog box is intentionally deceptive.

"This is the way forward people." Actually, the way forward is the direction we've already been going on; where there are no gatekeepers interrupting their collection of punitive tolls on software only long enough to lie about the software they don't collect their 30% from.