Thanks (and Sorry!) for reporting this Will.
This was a bug in the underlying Protocol Buffers RiakClient where Socket
objects were not being closed when IOExceptions were received from their
streams. This is now fixed in the 1.0.5 release, available today.
Thanks again,
Brian Roach
On Mar 28
Greetings Riak Users!
We are pleased to announce the release of the Riak Java Client v1.0.5
This is a bug fix release that addresses two issues:
* PBClusterClient not reconnecting when nodes come back online.
* HTTPClusterClient.addHosts() methods not working correctly.
The 1.0.5 Java Client i
Oops! Accidentally send empty email :)
Thanks, Alexander. The metaphor was above my poor English, but I feel I got
the point. :)
-- buriwoy
On Thu, Mar 29, 2012 at 1:21 PM, Buri Arslon wrote:
>
>
>
> On Thu, Mar 29, 2012 at 1:03 PM, Alexander Sicular wrote:
>
>> Fat data is a dirty little secr
On Thu, Mar 29, 2012 at 1:21 PM, Buri Arslon wrote:
> Thanks, Alexander. The metaphor was above my poor English, but I feel I
> got the point. :)
>
> -- buriwoy
>
>
> On Thu, Mar 29, 2012 at 1:03 PM, Alexander Sicular wrote:
>
>> Fat data is a dirty little secret amongst system architects. "nosql
Thanks, Jeremiah. I didn't think about cache. I think cache is the way to
go in production.
-- buriwoy
On Thu, Mar 29, 2012 at 10:22 AM, Jeremiah Peschka <
jeremiah.pesc...@gmail.com> wrote:
> Cache everything you can, even if you're persisting that cache in the
> database. Data duplication is i
Fat data is a dirty little secret amongst system architects. "nosql"
solutions are practically based on the concept. Denormalization leads to
data duplication all over the place. Disk is cheap. Like the kid at dunken
donuts handing munchkins out at closing time. Eat that shit up. Yes, you
might hat
Guys,
Any updates on the issue?!
-Matthew
On Tue, Mar 13, 2012 at 18:29, Matthew Tovbin wrote:
> Here is a log from one of the servers:
>
> ==> /mnt/dataraid/log/crash.log <==
> 2012-03-13 18:24:44 =CRASH REPORT
> crasher:
> initial call: riak_pipe_builder:init/1
> pid: <0.2094
Cache everything you can, even if you're persisting that cache in the database.
Data duplication is important when you want to make queries faster. Doing a
simple GET is going to be much faster than a MapReduce.
---
Jeremiah Peschka, Managing Director, Brent Ozar PLF, LLC
Microsoft SQL Server MV
Kresten, Jeffrey: Thanks a lot for enlightenment!
This link was very helpful to understand what to use when.
http://wiki.basho.com/MapReduce-Search-2i-Comparison.html
The information I obtained pushed me to another question :) .
Q: Is it a good (or at least 'ok') practice to duplicate informatio
Buriwoy,
Neither is better (or worse) for "storing" those bits of information. The
question is how you expect to use that data once it is stored. Let's take a
look at friend relationships (note: I don't use Facebook, so I might be missing
a subtle feature with this example)...
Do you merely pl
It all depends on how you use it. At scale, the number of disk accesses and
round trips may be quite different from what you'd expect.
If you "usually" would want to follow the links, then you're probably better
off denormalizing the data in Riak so you can get the information you need in
fewer
Hi,
While developing my pet project few questions came to my mind and I decided
to consult with you.
Which of them are more effective for recording relationships: Link or
Secondary Indexes?
1. Friend relationships: like Facebook friends?
2. Followed/follower relationships like in Twitter?
3. Mem
12 matches
Mail list logo
