3 ms·

I'd only consider NoSQL if you expect a very heavy load and one of these: - You have live data that is changing very regularly - You have a large quantit

by gridspy 17y ago

I'd only consider NoSQL if you expect a very heavy load and one of these: - You have live data that is changing very regularly - You have a large quantity of flat data (think column-oriented databases) - You don't need to index / find data and it is very flat (perhaps simple files on disk will allow you to store more) Plus : - You cannot possibly put off going NoSQL until you have further established yourself in the marketplace For Gridspy, we have live data and I expect large quantities of pretty flat data. It makes sense to stream the data directly to the user via messaging rather than polling through a database. Plus, I plan to store large quantities of high resolution data in a specialised database or dumped to disk - it will be much smaller and simpler without the indexing information since I don't need to search it, only slice it. See http://blog.gridspy.co.nz/2009/09/database-meet-realtime-data-logging.html http://blog.gridspy.co.nz/2009/09/database-meet-realtime-dat...

m0th87 17y ago
To be fair, I think there are a lot more use cases than that. My last project and my current one both used NoSQL solutions. The former because graph walking is painful in SQL and the latter because schemaless documents enable so many new scenarios (in my case, the automatic mapping of user-created forms to the backend). For me, the performance ramifications of NoSQL is way overplayed compared to its usability improvements. It is certainly not a successor or replacement to SQL, but for applications that handle a lot of unstructured or semi-structured data, NoSQL makes code tighter, simpler and easier to reason about. Which means less bugs and faster deployments. EDIT: I should qualify this argument by stating that I'm talking about datastores that support custom queries (like MongoDB and CouchDB) rather than ginormous k/v stores (like Tokyo Cabinet). I've found limited usefulness for the latter.
- gridspy 17y ago
  You know when you have a special case. If you don't - just the most convenient off the shelf database and get back to adding core functionality. It sounds like you do, however I think that there are a lot of people who have no real reason to move away from SQL other than fashion. The database choice should be just like any other engineering decision - often your familiarity with the new tool is very important.
JulianMorrison 17y ago
MongoDB is good for non-flat data if you can live with "transactions" that operate only within one "document". (You can do a surprising amount with this, using complicated select-and-alter primitives.) And it has indexes. The "mmap and update in place" design has upsides and down. Up: it's very fast and it doesn't allocate any new space for simple updates. Down: data will be trashed if the DB is shut down rudely, so you need a replica of each node just to keep ACID.

by gridspy 17y ago

m0th87 17y ago

To be fair, I think there are a lot more use cases than that. My last project and my current one both used NoSQL solutions. The former because graph walking is painful in SQL and the latter because schemaless documents enable so many new scenarios (in my case, the automatic mapping of user-created forms to the backend). For me, the performance ramifications of NoSQL is way overplayed compared to its usability improvements. It is certainly not a successor or replacement to SQL, but for applications that handle a lot of unstructured or semi-structured data, NoSQL makes code tighter, simpler and easier to reason about. Which means less bugs and faster deployments. EDIT: I should qualify this argument by stating that I'm talking about datastores that support custom queries (like MongoDB and CouchDB) rather than ginormous k/v stores (like Tokyo Cabinet). I've found limited usefulness for the latter.

gridspy 17y ago
You know when you have a special case. If you don't - just the most convenient off the shelf database and get back to adding core functionality. It sounds like you do, however I think that there are a lot of people who have no real reason to move away from SQL other than fashion. The database choice should be just like any other engineering decision - often your familiarity with the new tool is very important.

JulianMorrison 17y ago

MongoDB is good for non-flat data if you can live with "transactions" that operate only within one "document". (You can do a surprising amount with this, using complicated select-and-alter primitives.) And it has indexes. The "mmap and update in place" design has upsides and down. Up: it's very fast and it doesn't allocate any new space for simple updates. Down: data will be trashed if the DB is shut down rudely, so you need a replica of each node just to keep ACID.