I think a document database would be a good choice for a lot of poker apps so that seems like a cool place to start.

I just sped-read the section of '7 Databases' on MongoDB. I think Mongo has a nice clean syntax. The big issue with Mongo is that there is no type-checking, but then again, it doesn't make a ton of sense to be doing ad-hoc inserts on it either, so it would be best to do all of that programmically.

I can certainly see how it'd be much better than a RDMS for poker-related stuff, especially for quick hand-history analysis with mapreduce / emit(), which looks pretty clean with Mongo. I'll do a more invovled read on this section later on, but it looks about as perfect for poker stuff as we have available right now.

I also looked at the CouchDB section, but Mongo seems a bit cleaner and easier to use.

Dave, have you messed around with hstore on postgres? If you want to go on an adventure look at elasticsearch's facet module. They are shipping an aggregation module soon too http://chrissimpson.co.uk/elasticsea...-overview.html.

mongo users: do you all use an ORM when you use mongo?

Nope. I can see a few places, especially in Java, where it would be nice but our Objects in the clients map pretty much exactly to the documents in Mongo so its not particularly cumbersome going back and forth.

Edit: All of us have pretty extensive SQL backgrounds so I suspect we undervalue ORMs more than we should since they were always annoying to someone that knows SQL well (at least they're annoying in the short-medium term while you learn how to use the ORM well).

Random stupid question for today: I'm contracting to hire at a place that has today off. I get some PTO days from the contracting place that I probably won't use before I get hired. Can I take a PTO day today?

An AI that is scraping relevant sites and comments and a supersecret algorithm...it's tricky software because it self modifies to be written in the language with the highest hipster-value. It's still in Ruby though so there must be some bug somewhere. Well beyond the 8-ball. Gophers are on it to fix the issue.

Why would you chose hstore over JSON?

That article does look interesting. Any benefit to using it with Mongo -vs- Postgres?

I'm thinking that JSON is a decent way to store hand-history. I mean, there are tons of things that change from hand to hand.

Just spent $111 on this intro to java book. I forgot how expensive college books are.

daveT, I guess it depends on what you're storing. I think hstore is going to become a lot more viable in many more situations soon though with 9.4. It will support booleans and ints, and it's already much much faster than json.

As for elastic search, I see no benefit in using it with mongo vs postgres directly but in both cases I would likely choose to use along side either of them. In addition to its aggregation capabilities it also does full text search and many more things. It's a document store at heart with persistence.

It's great for feeding an autocomplete/suggester, searching arbitrary data structures, doing facet based navigation and analyzing logs.

One nice thing about json is that you have a common data representation throughout your app. This is especially nice in Python where we really don't have to do any data transformation between Mongo->Python->Web. It all just happens seamlessly for us.

On the Java side its a bit uglier but still not too bad.

That's about how much money I paid to teach myself the entirety of my web development knowledge.

Well let's hope your time is worth more now ;P

marginally :P

I am sure this was required for your class, but it's such a scam. There is so much free info available for Java on the internet, and even if you wanted a book, buying one thats a few years old will probably cost $5 and you won't be that out of date considering it's an intro class and how long Java has been around.

This is pretty much the point - from what I can tell from the noise, MongoDB is no easier to scale out and there are some design issues when it comes to large clusters and such. Either way, I'm finding that Postgres JSON is a nice hedge - with some work up front, it's just as flexible as MongoDB and you're not out of luck later if you end up needing relational or other standard DB features.

Yea I'll get the book tomorrow but I won't unwrap it until the first day of class. I know it comes with an access code to online content but the slyabus doesn't mention anything about it being mandatory. However the professor is pretty old school so wouldn't surprised me if she makes it mandatory.

Worst case scenario, I'll sell this book after class is done for 80$

Amazon's sell back option is a godsend

candybar,

Yeah the netflix guys mentioned that too. Sure with Cassandra you can set things up to be self healing, auto balance and do all of that great stuff to get no single points of failure but it's not just a magic button that you press.

It was way beyond trivial to get it all working (according to them).

I'd still horizontally scale Mongo or Cassandra long before a traditional RDMS.

Cassandra and Mongo are not even remotely close to the same thing here though. Cassandra was built for horizontal scalability from day 1. MongoDB had instance-level global write locks until not long ago and I think still has database-level locks which to me indicates that their product has almost never been used successfully for anything needs scale. Why would it work better at scale than something like MySQL or Postgres or Oracle, all of which have a long history of use at scale?

I've been to their office, talked to their sales people, program manager, etc, and it seems their focus at this point seems to be in replacing Oracle and SQL Server for enterprise space, using the grassroots, our stuff is easy to prototype with, sales pitch.

Mongo has removed most of the irritating locks - and I'm pretty sure those locks were only at the shard level so they didn't affect scaling horizontally. Mongo has most definitely always been built to scale horizontally.

I'm about 2-3 years out of date with MySQL/Postgres/Oracle, but Oracle at least, most definitely, did NOT have a good horizontal scaling solution even as much as 5 years ago. I suspect they still don't and at best have some ridiculously expensive feature that you can pay for to get basic horizontal scaling.

I was curious about Oracle's horizontal scaling support. Looks like they recommend "Real Application Clusters" which according to http://www.oracle.com/us/corporate/p...ist-070617.pdf will only set you back ~$25,000 per processor (which I believe is usually the same as per core).

Edit: And don't forget that's on top of the $50,000-$60,000 you're already spending PER CORE for Enterprise edition.

Edit2: And don't forget that this is your annual cost.

I looked a bit into Elastic Search. I sort of need it for something I'm working on. I tried using Postgres's modules such as tsearch, dict_xsyn, fuzzystrmatch for search and cube for facet search. It isn't that bad, really, but certainly could be more powerful and unified. Certainly not mature and it appears that the only way to get full power or search is to do a union of all the searches then DISTINCT. Not a happy place, really. Elastic Search looked a bit overwhelming, but I think it will be much better than trying to merge all these items together.

I've been looking more into this hstore. I probably have to find a more explicit tutorial on it or something. There is certainly some interesting stuff there, though. The main crux is that I don't know if a) I want a full-blown database running in the background and b) I can't quite conceive how to represent a fully-played poker hand in hstore. This doesn't mean it's not possible, but it appears a bit easier to do this in JSON.

As I was pondering this more last night, it occurred to me that I was thinking about the whole problem completely wrong. I was trying to figure out how to represent some "knowledge" of hand-strength, counting outs, bluffing frequencies. As I writing out plans and algorithms for starting-hand selection, I wasn't able to figure out any satisfactory solution.

This whole MongoDB / hstore / NoSQL thing got me reconsidering the plan. It isn't necessary to give the bot this kind of "intelligence." In fact, there is no reason at all to consider hand-strength in any of this. If I can update the data then run mapreduce on each stage of the hand along with the result, I can simply calculate EV on the fly then press towards neutral EV, I can get the correct response to the player's actions. Of course, this will take a decent grip of hands to get appropriate staging data, but this is why simulations exist. The trick is to keep the initial data small enough so that it isn't cast in stone yet large enough that it is meaningful.

Map/Reduce is sort of 'broken' in Mongo. Or maybe 'crippled' is a better way of saying it. Its performance isn't great even with the latest js engine Mongo's using and its just kind of awkward to use.

I've heard good things about the Aggregation framework, but I'm not sure it'll do what you want.