schema help for a query tracking system

I'm designing a system to track query statistics from a variety of sources. Each source queries the system with a tag. I do not need to record information about each individual query - I need only track stats by {date, source, tag}. Assume, that within a given day, there could be 100 sources, 500k

Re: native vs protocol buffers

The new non-local Erlang client now uses protocol buffers internally, so in a sense you are using it, unless you're running your application in the same node as Riak. Sean Cribbs Developer Advocate Basho Technologies, Inc. http://basho.com/ On Apr 25, 2010, at 11:13 PM, David Weldon wrote: >

Re: avoid records?

Yes, the primary weakness of records would be upgrading them. You could do it with a map-reduce job, but it would be better in general to use a more fluid data structure. Whether you choose proplists or dicts will depend on how many properties you need. Dicts become more efficient when the nu

Re: Building rel on Debian 2.6.26

Yeah, that fixed it. Odd... Maybe hg mangled something when pulling the dependencies... Anyway, thanks for your patience! --Matthew On Fri, Apr 23, 2010 at 16:06, Ryan Tilder wrote: > I can't manage to duplicate the problem you're having with the inotify.sock. >  Will the tarball build afte

auto-generating keys in riak

When doing a POST against a bucket without indicating a key, riak auto-generates a 27 characted mixedcase alphanum (with possibly + 2 other chars for radix(64) ) unique ID How does it do that? What's the seed? What guarantees of uniqueness are there? I take it even if there was a conflict ri

Re: auto-generating keys in riak

Alexander- Check out the function in riak_core:riak_core_util http://github.com/basho/riak/blob/master/apps/riak_core/src/riak_core_util.erl#L126 I think it's something like 2^42 at that moment in time (now() is

Re: avoid records?

I've started storing data encoded as JSON in order to allow access through the REST API. This adds a bit of overhead in Erlang but allows the data to be accessed from other clients such as http://github.com/johnthethird/Briak . On Mon, Apr 26, 2010 at 6:10 AM, Sean Cribbs wrote: > Yes, the pri

Re: avoid records?

Le 26 avr. 2010 à 15:10, Sean Cribbs a écrit : > Yes, the primary weakness of records would be upgrading them. You could do > it with a map-reduce job, but it would be better in general to use a more > fluid data structure. > In the defense of records : Records can be pattern matched whereas

Re: avoid records?

Usually I'm all for records because of pattern matching and compile-time checking. IMHO, broken upgrades are reason enough not to use them directly for storage. I have yet to design a system where the data structures never changed after the initial release. I hate to say it but, for me, the answer

[ANN] Riak version 0.10.1

Hello, again, Riak users. We fixed a couple of small issues over the weekend, and decided to tag and release them as 0.10.1. Downloads are here: http://downloads.basho.com/ Release notes here (and below): http://downloads.basho.com/riak/riak-0.10/riak-0.10.1.txt Cheers, The Basho Team ---

Riak Recap for 4/24 - 4/25

Hey All - Hope everyone had a great weekend. Here's a short and sweet recap for the last several days. Best, Mark Community Manager wiki.basho.com twitter.com/pharkmillups -- Riak Recap for 4/24 - 4/25 1) @roder updated the Homebrew recipe for Riak to bring it up to date with the 0.10

DETS vs Innostore

Hi, I did some testing between dets and innostore for storage backend which store 200k of data with same structure. Using default configuration for both storage backend, running on singgle node and bucket's allow_multi set to false. Data example : [{field, "value"}, {field, "value"}, {field, "val