4 ms·
> Amazon's correlations aren't done in real time, and I don't get why it would be an issue using MySql for it. Many of the algorithms for recommender systems a
by strlen 17y ago
> Amazon's correlations aren't done in real time, and I don't get why it would be an issue using MySql for it.
Many of the algorithms for recommender systems are especially known for being parallelizable and would be extremely difficult to reliably and quickly implement on top of MySQL (or Postgres or Oracle). I can't even think of a way to do so without making a fairly complex ETL cycle with a separate DWH and a main serving DB (with points at which the site becomes degraded and possibly unavailable). As I've mentioned earlier, with a system like Hadoop, you could start off by implementing these algorithms in Perl or Python (making use extensive libraries already available in the language).
Recommendations may not be real time, but there's a huge time difference between doing an even fairly simple "market basket"-type analysis for a data set orders of magnitude difference smaller than Amazon's in MySQL and doing this on top of Hadoop + HBase/Voldemort/Cassandra (i.e., compute in Hadoop, serve from a NoSQL db which offers Hadoop integration). You could even start by doing the computation in Hadoop and loading the data into MySQL (while, perhaps, serving the data from a slave db).
> Maybe it is for Amazon which got plenty of data to analyze, but not for a startup.
Your start-up doesn't need to have tons of users to have tons of data. This is especially true if you're building a start-up to make sense of the data that's already out there (some YC examples are Flightcaster, Directed Edge). For a consumer start-up, ability to have cheap and scalable storage means you can record data much more frequently.
> The other problem I've had with Nosql is that capabilities vary from implementation to implementation, and my software really evolves a lot ... I don't know what my needs are from the start.
Isn't this the point of separating your data model from your presentation layer? Begin with MySQL (or even simpler, with BerkeleyDB) -- change it to whatever else suits your needs.