Hi Mike,
perhaps you can try to upgrade the protocol buffers library to at least
version 2.3.0. This is from the changelog for that version:
Python
* 10-25 times faster than 2.2.0, still pure-Python.
Cheers,
Nico
Am Montag, den 14.02.2011, 19:35 -0500 schrieb Mike Stoddart:
> Will do when I
python-riak-client already uses version 2.3.0. Adventurous types might want to
check out https://github.com/Greplin/fast-python-pb, which wraps the C/C++
protocol buffers library.
--
Andy Gross
Principal Architect
Basho Technologies, Inc.
On Tuesday, February 15, 2011 at 1:46 AM, Nico Meyer wr
Hi Andy.
I am not quite sure what you mean, is the protobuf library included with
riak-python-client? Or are you talking about the version of the protobuf
compiler that was used to create riakclient_pb2.py from
riakclient.proto?
Cheers,
Nico
Am Dienstag, den 15.02.2011, 02:23 -0800 schrieb Andy
Sorry, I should have been more clear. The Python client depends on
"protobuf>=2.3.0" in setup.py, so people are already most likely using
protobufs-2.3.0.
- Andy
On Tuesday, February 15, 2011 at 3:09 AM, Nico Meyer wrote:
> Hi Andy.
>
> I am not quite sure what you mean, is the protobuf lib
Is riak suitable as a very reliable store where you have multiple feeds
of streaming data that are at least theoretically identical? That is,
can you count on writing multiple copies with the same keys at the same
time to do something reasonable regardless of cluster partitioning? And
is this
Riak maintains a single value per key and provides mechanisms (vector
clocks) to detect/resolve conflicting values. In the proposed use case the
multiple copies would overwrite each other and Riak, by default, would
return a single value for a requested key.
Behind the scenes Riak determines the a
What about siblings? http://wiki.basho.com/REST-API.html (seach for sibling)
On Tue, Feb 15, 2011 at 14:57, Dan Reverri wrote:
> Riak maintains a single value per key and provides mechanisms (vector
> clocks) to detect/resolve conflicting values. In the proposed use case the
> multiple copies wou
In this scenario, the behavior I would want would be to only see one
copy for each unique key, but to always have one even if one of the
feeds or writers fails or the cluster is partitioned, then re-joined.
This sounds good in theory, but what about the details? Is there likely
to be a big perf
Les,
This is pretty much Dynamo 101 territory at this point and one of the
tradeoffs with a distributed model.
If you aren't familiar with Dynamo, Andy Gross (from Basho) gives an
AWESOME walkthrough in an episode of TheNoSQLTapes:
http://nosqltapes.com/video/understanding-dynamo-with-andy-gross
Hi,
does somebody have some figures on Riak memory usage? I consider using
it in a highly memory constrained environment (< 32 MiB), but I'm not
sure whether Riak can handle low workloads under such tight constrains
(it consumed > 20 MiB idle). Performance is not relevant to me, I just
need partit
Gday
Been messing around on some personal projects which use riak with Java and
was interested to know if their was a roadmap or task list of the java
client.
Just wanted to know if there was any plans to build a new version in the
future as I would be interested in contributing.
I am currently
You'll be constrained in the number of keys that you can store (using the
bitcask backend). There's a good spreadsheet for capacity planning:
https://spreadsheets.google.com/ccc?key=0Ak4OBkABJPsxdEowYXc2akxnYU9xNkJmbmZscnhaTFE&hl=en&authkey=CMHw8tYO
I don't know how well Riak would behave otherw
On Tue, Feb 15, 2011 at 04:44:58PM -0800, Jeremiah Peschka wrote:
> You'll be constrained in the number of keys that you can store (using the
> bitcask backend). There's a good spreadsheet for capacity planning:
> https://spreadsheets.google.com/ccc?key=0Ak4OBkABJPsxdEowYXc2akxnYU9xNkJmbmZscnhaTF
I'm not sure. I think it would depend on the number of JavaScript MR engines
you have running, the operations you're performing, and the amount of data that
is being read into memory.
--
Jeremiah Peschka
Microsoft SQL Server MVP
MCITP: Database Developer, DBA
On Tuesday, February 15, 2011 at 5:
Lately I've noticed the increased demand for a higher-level, abstract querying
API in the Ripple document-mapper library -- something analogous to
ActiveRecord + arel. At the current time, I'm preparing a strawman proposal for
the feature that we can debate.
I'd like to discuss this feature in-
15 matches
Mail list logo
