Greetings Justin, IMHO, AFAIK, IANAL, etc. "is it ok?" really boils down to whatever you're ok with, can program, can understand, is within you're budget, can implement and/or do all of the above within your own timeline. I think it is always true that the number of opinions you will get is more than the number of participants in the conversation. Ergo, filter all contributions through the lense of: Go with what you know. Coming here for advice is fine but like preventing wildfires, only you know your use case.
That said, you may want to check out using a message queue to control the asynchronous, eventually consistent data model I feel you feel you are leaning towards. Cheers, Alexander Opinionista, 1st class President Emeritus of the Order of Very Opinionated People, NYC Chapter Recipient of the Opinionbel Prize for Lifetime Contributions in Rabble Rousing and Salt Mining @siculars http://siculars.posterous.com Sent from my rotary phone. On Oct 29, 2011 4:13 PM, "Justin Karneges" <[email protected]> wrote: > Thanks, those were very good reads. > > Eventual consistency I'm okay with. I understand that with a distributed > system, clients are generally going to have to cope with not always having > the > latest data. I'm just trying to avoid littering the database with orphan > keys > in the event I fail to make a Link. > > Is it common to run repair methods periodically on a Riak database? The > only > decent solution I can think of is to have a background task running that > reconciles inconsistency (and by this I mean inconsistencies that will > never > be made eventually consistent :)). > > On Saturday, October 29, 2011 11:18:10 AM Reid Draper wrote: > > Justin, > > > > It sounds like your specific needs _might_ be possible with application > > logic, but be aware that Riak is an eventually consistent database. There > > are many subtleties to this type of coordination. You will need > > read-your-writes consistency, which means R + W > N. I would recommend > the > > following resources: > > > > http://wiki.basho.com/Eventual-Consistency.html > > http://www.allthingsdistributed.com/2008/12/eventually_consistent.html > > > > Terminology-wise, you should also know that there is no way to atomically > > update more than one replica (much less multiple keys) in Riak. This is > one > > of the tradeoffs for high availability in a distributed system. > > > > On Sat, Oct 29, 2011 at 1:46 PM, Jeremiah Peschka < > > > > [email protected]> wrote: > > > I'm just assuming that my implementation might be naive. > > > > > > As far as the tedious label goes, as your application's functionality > > > grows in complexity, you may find it tedious to manage the complexity > of > > > manually handling transactional rollback in a distributed system. > > > > > > Managing relationships using links has some maintenance overhead in > Riak > > > because of the nature of handling this sort of situation. > > > > > > But, all in all, it's probably not terrible as long as you decrease the > > > number of relationships in the application by saving related objects > > > within the same collection. > > > --- > > > Jeremiah Peschka - Founder, Brent Ozar PLF, LLC > > > Microsoft SQL Server MVP > > > > > > On Oct 29, 2011, at 10:32 AM, Justin Karneges wrote: > > > > On Saturday, October 29, 2011 08:42:52 AM Jeremiah Peschka wrote: > > > >> 1) Use an RDBMS. Since you're here, I'm guessing that you're already > > > > > > using > > > > > > >> Riak or else that Riak has qualities that you want for your > > > >> application. > > > > > > > > Right. This is early on in the app's lifetime and the data storage > is > > > > > > not > > > > > > > terribly complicated. I just need some parent/child relationships > and > > > > > > when I > > > > > > > saw the Links feature I figured this was an expected usage of Riak. > > > > > > > >> 2) As Alex suggests, you can implement this in your application. > > > > > > > > Yes, this I am ready for. As I understand it, using Riak > successfully > > > > generally means designing your application with its limitations in > > > > mind. > > > > > > So, > > > > > > > let's go write some funky app code! > > > > > > > >> This could also be difficult: the application must be aware of > > > >> activity > > > > > > going > > > > > > >> on with objects in your database AND be able to roll them back. In > > > >> pseudocode you'd do this: > > > >> > > > >> orig = Riak.get('whatevs') > > > >> child = new Child(orig) > > > >> > > > >> > > > >> if Riak.put(child) > > > >> > > > >> if !Riak.link(orig, child) > > > >> > > > >> Riak.delete(child) > > > >> // error up the stack > > > >> > > > >> else > > > >> > > > >> // we don't care, the child didn't save. error up the stack > > > >> > > > >> This is probably naive and is definitely tedious, even if you do > > > > > > implement > > > > > > >> your own application layer to handle read/write operations. > > > > > > > > See, to me, this looks exactly like what you're supposed to do. How > is > > > > > > it > > > > > > > naive and tedious? I would assume that everyone writing a serious > app > > > > > > with > > > > > > > Riak has to do things like this. > > > > > > > > Justin > > > > > > > > _______________________________________________ > > > > riak-users mailing list > > > > [email protected] > > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > > _______________________________________________ > > > riak-users mailing list > > > [email protected] > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > _______________________________________________ > riak-users mailing list > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
