Btw, all that stuff is available (http://pgfoundry.org/projects/skytools) - this is like saying MongoDB's Scala driver is an extra custom tool I have to use to use MongoDB.

Remember too that not being able to do cross-partition joins for Postgres can be a massive change for an application that previously couldn't make that assumption.

Mongo has a different design philosophy that means you're not doing (can't do) those joins in the first place. So going from one instance to a sharded cluster doesn't require an application rewrite.

No its not. But I'll assume this is just you being purposefully obtuse again.

I conceded that a long ago:

Great, then can we can consider this discussion done.

The problem here is that you seem to care about, easy for jjshabado to figure out and set up and I care about actual effectiveness under heavy workload once it's set up. I've long ago conceded that you're right - MongoDB is easier for you to set stuff up. But this doesn't mean anything to me - I'm talking about which technology is more likely to work effectively under loads that require horizontal scaling in the first place. I don't know how many times I have to say I agree with you that MongoDB is easier before you get the point.

I mean, I made it pretty clear that it depends on the use case. Not only on read/write volumes but what types of read/writes you're doing and the data you're using.

I'm quite confident there's not a definitive winner on what "works best under load". And that's why we have major companies with very well paid and talented people choosing very different solutions.

Edit: This whole derail started with me saying something about what was easiest for me, jjshabado, to set up. So, yes, in that context that is all I cared about.

lol, wow, I almost missed this, does Weblogic actually do anything above and beyond Tomcat/JBoss/Wildfly?

Ok dude, let's be nicer to each other next time.

I long ago accepted that my tone on the internet doesn't really reflect my actual feelings. I get passionate about arguments but rarely actually care about them.

And in the end it was an enlightening discussion (the second part more so than the first).

This seems like a good time to point out that I set you guys up with this line:

and was sad that nobody responded with a joke about joins.

Yeah, easy get worked up over a faceless medium and hard to read sarcasm/jokes, all that stuff - no hard feelings, always nice to talk to people who care about stuff

But how much does Oracle charge for joins?

This is one of my worries about my current company. I work remote and we're about 10 people. I've worked in real life and for a number of years with half of my co-workers and the other people joined slowly enough that it was easy to meet them and get to know them. But once we start growing at a faster rate I'm not sure how well the remote thing will work.

I've done this on both ends - at the office working with remote people and work remotely with people working at the office - and I find that it makes all of us a little too careful in terms of not offending others and stuff. Hard to joke around when you don't really feel like you know them because of the distance. I guess it depends on the working relationship but the larger it grows, the more I'm sure it will be that way. You don't really have reason to chit-chat and make small talk, so all you talk is business, which creates a bit of distance.

I forget, are you based around NYC or is your company based around NYC and you're elsewhere?

My company is NYC and I'm elsewhere. I make semi-regular trips there though so that helps.

+1 sense plugin for elasticsearch. daveT feel free to ask any elasticsearch questions about the mappings and queries types that you need to get started.

will do. I won't be able to get back to it until next month sometime, but I'll probably be presenting the baseline ideas and ugly implementation in the Lizzie thread.

jj, you asked what I was attempting to achieve. Hopefully, I can explain the idea without getting into novella territory.

The basic issue is figuring out how to make decent decisions. I tried a few approaches, but all of them are unsatisfactory. The LUT can't work because it is too large for working on the web. I could run it in the background and perhaps get okay results, but I also need something a tad more flexible. Even with a LUT analyzer, and really any analyzer, I run into a few issues I don't feel like enumerating here, but mostly, this is too rigid and assumes things that aren't exactly true.

Suppose instead I hard-code a few concepts. The easiest would be starting hands and counting outs.

I'm not going to chase down statistics, but anyone with HU experience knows that you want to play about 60% of your hands. The problem is that no matter how much math or programming I tossed at it, I was not able to come up with a satisfactory solution that described more than the to 40% of the hands.

For counting outs, yes, that is easy enough on its face. Clearly, you have 8 outs to a straight, 9 outs to a flush, etc etc, but it gets more complicated because... how many "outs" do you need to win a hand when you wiffed a dry flop while holding AK? What about QQ on a King-high flop.

The point is that basic "knowledge" would require a ton of programming and it would never work out. This whole NoSQL thing got me thinking about something different and I think a much better approach. The bot doesn't have to be aware of hand-strength at all, and in fact, when I really thought about it, I realized that I don't think about hand-strength much at all when I play.

So, suppose there is a JSON / hstore / ?? record of hand histories. From this history, one can derive +EV hands, which will, by proxy of folds, be higher than 50%. The next level is then considering the EV of a hand + a flop. Then there can be more sophisticated queries, like "bot bet on this flop tends to be a player fold, thus bet."

I don't exactly need M/R or elastic search, but I would need something that is far more flexible and faster than a relational database to run this, I think. I also don't have to do a full M/R on each hand.

Developers don't choose it.

The DBA chooses it, and the developers are told to integrate with it.

Good DBAs and having good relations to them as a developer is worth A LOT so if that would be the true reason I could almost live with it. The reality is managers buy Oracle because Oracle has a very good sales team.

For the sake of my PhD I hope you're wrong on this. Unfortunately this is probably the biggest danger I face...I have coded up my beautifull bot generator and it turns out they are just too slow to play :P

nice little mind blow:

http://www.scottaaronson.com/writings/bignumbers.html

Very interesting

I mean programming a brute force solution, not the good stuff you mist have mastered by now.

What about some sort of two step process?

Like you have a massive collection of hand histories. From that you run a map reduce job (or similar processing) to convert that into data that you'll use for playing. Maybe its something like coming up with a set of hand types (flush draw, second pair+, ...) that will do each action for each flop.

Looking up that information and doing processing on that should be fast enough to work real time.

Edit: That might still be too much data to store easily for your technical resources but you can probably condense the data in different ways by grouping flop possibilities.

It certainly doesn't need to be real time. I could just run the process once a week or something. The main idea is creating the final equation.

It also depends on how everything is represented. I considered a fairly simple approach that removes most of the complexity to creating the data maps that works pretty decent on paper, but I honestly don't want to think about it right now.