seancribbs

You mean AP, not CA.

CA doesn't exist.

The Solr version in the Release Candidate is actually 4.7.0.

mnesia is indeed a frequent choice by newbies for queryable storage in Erlang, but I've found few production systems use it for similar reasons to the ones you describe. Nowadays you're more likely to see external datastores (PostgreSQL, MySQL, etc) used except for transient/in-memory stuff which can be stuffed in ETS.

#!/usr/bin/env escript

main(_) -> io:format("hello, world").

Related: Datomic can be configured to use both Zookeeper and Riak, and the implementation is really clever: immutable data in Riak and strongly-consistent "pointers" in Zookeeper.

See http://www.infoq.com/presentations/Deconstructing-Database

Since they're not likely to approve my comment on their blog, here's what I said:

"Way to misrepresent[1] vector clock usage in Riak! LWW deliberately ignores the vector clock. No one would use that in production without a strong assurance that they will never have concurrent writes. Also note that later in the post[2] Kyle shows how using them properly leads to zero data-loss.

[1] https://yourlogicalfallacyis.com/strawman [2] http://aphyr.com/posts/285-call-me-maybe-riak"

To add on,

Cassandra addresses the problem that vector clocks were designed to solve by breaking up documents/objects/rows into units of data that can be updated and merged independently. This allows Cassandra to offer improved performance and simpler application design.

This is not solving the problem vector clocks solve, it is punting on the resolution issue. Perhaps LWW partial updates result in greater performance, but they only solve performance.

Listen to or watch http://thinkdistributed.io/blog/2012/08/28/causality.html

To be fair, both designs are valid choices, but jbellis should be honest about his tradeoffs and not simply cast aspersions on other valid designs because they aren't the one that C* chose.

Elixir has some good things about it (hygienic macros, protocols, and so on) but the syntax is not enough by itself to make us switch. "Ugh, Erlang syntax sucks" is a refrain heard around the Internet, but it has not hindered us from getting good engineers who are happy to develop with it. I daresay that the syntax is the least of your problems when learning Erlang; the message-passing concurrency and fault-tolerance models, and functional style are more difficult to understand. Those problems don't go away when you use Elixir instead.

If you want something Scheme-like on the Erlang runtime, there's LFE (Lisp-Flavored Erlang): https://github.com/rvirding/lfe

This is true, but Riak CS has special configuration requirements for the backing Riak cluster that might make it not the best choice for combining with your typical Riak applications.

That's still an oversimplification. POST only implies that the request is NOT idempotent, and that the request body is submitted to the origin server for "processing". Consider for example, resources that search for other resources via information in the request body and redirect to them. There's nothing wrong with this pattern, and in fact it works nicely for rapidly-changing server-side information since caching the result of a POST is not allowed.

The core problem in my mind, is not whether one should insert or update on PUT/POST, but whether one should even be considering HTTP-based APIs to be gateways to what amounts to a database. The domain concepts in the application might not map directly to a resource-centric design, and that's ok. When you focus on the resources, their behavior, and hypermedia, then you "get" REST. If your application isn't shaped like HTTP/REST, then maybe it shouldn't try to be.

Go to http://basho.com/resources/downloads/, static links are available if you navigate down the tree to the individual files. e.g. http://s3.amazonaws.com/downloads.basho.com/riak/1.2/1.2.0/o...

@rb2k_ Here's the relevant docs:

http://rdoc.info/gems/riak-client/Riak/RObject#indexes-insta... http://rdoc.info/gems/riak-client/Riak/Bucket#get_index-inst...

Apparently it's too hard to download yourself?

    wget http://downloads.basho.com.s3-website-us-east-1.amazonaws.com/riak/1.1/1.1.2/riak-1.1.2-1.fc15.x86_64.rpm
    rpm -Uvh riak-1.1.2-1.fc15.x86_64.rpm

To what point? Already large portions of Riak (the performance-critical ones) are in C, and have been for a long time.

There will be a minor gem release (pre/beta/something) next week that supports Riak 1.0 features, then in the next major release those will also bubble up to the Ripple document layer. Sorry for the delay.

Yes, the problem was not necessarily using a Bloom filter, but that it was too small. However, 1.0 is smarter about which vnodes it sends list-keys requests to and thus obviates the need for the Bloom filter (at least for that operation).

That is still under debate AFAIK. The latter form would allow you to compose multiple index lookups as well, which is why I'm for it (although the query planner might not support it yet).

The design of secondary indexes is much simpler, more tightly integrated, and more transparent than Riak Search. It will feel more like part of the same datastore, rather than something you have to deal with on the side.

On the contrary, QuickCheck is brilliant at testing stateful systems, as long as you can model the actions that occur and how they modify state (statem in eqc helps here).

Blog post about the release: http://blog.basho.com/2011/01/05/riak-0.14-released/

Riak has been open-source and freely available since August 2009.

Riak means "ripple" in Indonesian. This is both the name of a pre-release version of the software and a reference to how storage operations in the k/v store work.

We have quite a few customers in production. Most well-known one is Mochi Media, who have multiple clusters backing their online games APIs.

His argument actually seems to point to dynamically-typed functional programming, which is not surprising, considering his work with Scheme.

We uploaded the generated files to S3 at the end of each individual job. We could have used AMQP's 'ack' for each message, but it turned out not to be necessary.

This is the reality of many projects. We got the full dataset around 48 hours before the output was needed. See my comment above too.

The client was slow in delivering the data and we needed it within 48 hours, with the possibility of generating the output multiple times to discover any errors or other issues.

Kevin did those benchmarks (as I watched) on a single MBP using the Ruby client, specifically Ezra Zygmuntowicz's benchmark script. I would definitely consider his numbers circumstantial, but also the bottom end of what's possible considering the fact that it's a laptop and the performance characteristics of Ruby.