4 ms·

He missed my favorite: http://www.persvr.org/ http://www.persvr.org/ CouchDB requires custom views for each field you want to optimally query. Persevere (using

by chime 17y ago

He missed my favorite: http://www.persvr.org/ http://www.persvr.org/ CouchDB requires custom views for each field you want to optimally query. Persevere (using the JavaScriptDB) does that natively and smartly for all fields: http://www.sitepen.com/blog/2009/04/20/javascriptdb-perseveres-new-high-performance-storage-engine/ http://www.sitepen.com/blog/2009/04/20/javascriptdb-persever... (see section: Adaptive On-Demand Concurrent Indexing) The biggest benefit of NoSQL dbs is the ability to add properties (i.e. columns) on the fly. Querying these properties should not be an O(n) operation. Unless I am completely mistaken, it is in CouchDB unless you write a custom view. Persevere doesn't require that and supports most common methods of querying ( http://docs.persvr.org/documentation/jsonquery http://docs.persvr.org/documentation/jsonquery ) If you query a field, it will index it and if you query it often it will maintain the index and update it regularly. I'm just starting on a project that uses Persevere and already I'm quite impressed by it. It may not be as famous as CouchDB/Cassandra yet but it offers a lot of very interesting features including transaction support and nested objects with referencing.

gaius 17y ago
The biggest benefit of NoSQL dbs is the ability to add properties (i.e. columns) on the fly Are you claiming that you can't add a column on the fly to a table in a relational database? Because that my friend is complete gibberish.
- req2 17y ago
  I think he's saying that if you have a large database in an rdb, adding the new column 'live' can take a prohibitively long time and kill access to the server, whereas a NoSQL db can add the new column without any large initial expensive operations on the db. (Disclaimer: not a db guy.)
  - gaius 17y ago
    Once again, it is shown that the NoSQL crowd's complaints about relational databases in general are in fact only complaints about MySQL in particular.
    - sailormoon 17y ago
      Generalise much? I agree that what the parent complains about is a MySQL problem but it's pretty disingenuous to just dismiss the whole "NoSQL" idea based on one misinformed comment on HN.
      - gaius 17y ago
        Nah, this keeps coming up on HN, and 99% of the time, the thing that "SQL databases" just can't do is something that DB2, Oracle, Sybase, Informix et al have done for 15 years or more.
        sailormoon 17y ago
        Well, I don't know what you've been reading here, but there are plenty of things you can do with one of the systems listed in that article that you can't do, or can't do well/easily/cheaply, with any conventional RDBMS. The listed systems are very disparate, but here's a couple of examples: In Redis you can read or write ~100k operations a second. You can do set operations, add, rem, member, list .. way cool if you can stomach the memory use. Lazy sync to disk. Hard to think of anything that could beat it for collecting stats or totals etc for high volume data streams. In CouchDB you can do M/R style indexed views, like word counts. You can access the DB directly from HTTP, no special drivers - the DB is implemented as a web server. You can authorise via OAuth (soon), secure via TLS and proxy through squid. You can access, and replicate, from the other side of the world. Tokyo Cabinet is over 10 times faster than MySQL as a simple hashtable, like, say, a session store, which is the first place most sites start having trouble with their DB. Tiny, bare bones, drivers for all major languages, network accessible. A no-brainer for simple storage IMO. And all of these are completely free, unlike the cripplingly expensive commercial alternatives you mentioned - especially important for startups. So .. basically I completely disagree, there's a lot of good things about these alternative DBs. Don't discount them just because you heard a few dumb ill-informed comments on sites like this, most people involved in non-RDBMS DB implementations know exactly what they're doing.
  - russell 17y ago
    This should be a constant time operation on most databases, because existing rows are not touched. However, if you have lots of properties that are not indexed or directly queried, I suggest having a single JSON field for them.
  - req2 17y ago
    Oops, that's what I get for repeating a single complaint I'd seen voiced in some other thread... Apologies.
- chime 17y ago
  Sorry for the confusion. I only mentioned properties=>columns to differentiate from the concept of rows/tables/values etc. What I meant was that different properties can be added to each object in the store without having to worry about the effect of the same properties on other objects in the same store. If you add "cellphone#" property to an object, it doesn't mean all objects in the store will now have a "cellphone#" property (defaulted to NULL). It means other objects will not even have a property "cellphone#" unless you go back to those objects and edit them. This has nothing to do with the length of time it takes to add a column in whichever SQL database you use.
- blasdel 17y ago
  You can't let your users do things that add arbitrary 'columns' whenever, or grow to 10,000+ on every 'table' to model attributes. That kind of usage works really well when the DB is a Entity-Attribute-Value tuplestore underneath. It's not so hot with tables, much less relational ones.
  - dagheti 17y ago
    The fact that a system requiring ad-hoc attributes wouldn't work so "hot" in a relation isn't a problem with the relational model. This difficulty comes from the application of the relational model bringing to light that such a situation is necessarily more complex than one without ad-hoc attributes, and you cannot treat such data the same way as you can treat data in a relation. The important lesson is that you cannot abstract this added complexity away without losing something else of value (data integrity and simplicity of reasoning). This gives you more power when your situation isn't ad-hoc attributes (by providing more guarantees) and lets you model the ad-hoc situation with a EAV model if you must. SQL maybe should provide some more sugar for accessing that EAV, but it's not a fundamental relational model issue.
extension 17y ago
CouchDB requires explicit indexes, but they can be arbitrarily complex, which is the right approach for a database focussed on scalability. They are also fun to write (javascript + map/reduce). It appears that JavaScriptDB just maintains indexes of everything, until you have over 2000 objects of a class and then it only updates the indexes of fields when you search on them. This saves you the trouble of initially specifying indexes, but by the time your DB gets big enough that they become important, you'll have to manage them explicitly anyway, and you don't get anything besides plain old lexical sort. Persevere looks great for rapidly developing small projects, but not particularly scalable. The automatic index thing might be handy for a multi-faceted search, which is a pain to do in CouchDB.

by chime 17y ago

gaius 17y ago

The biggest benefit of NoSQL dbs is the ability to add properties (i.e. columns) on the fly Are you claiming that you can't add a column on the fly to a table in a relational database? Because that my friend is complete gibberish.

req2 17y ago
I think he's saying that if you have a large database in an rdb, adding the new column 'live' can take a prohibitively long time and kill access to the server, whereas a NoSQL db can add the new column without any large initial expensive operations on the db. (Disclaimer: not a db guy.)
- gaius 17y ago
  Once again, it is shown that the NoSQL crowd's complaints about relational databases in general are in fact only complaints about MySQL in particular.
  - sailormoon 17y ago
    Generalise much? I agree that what the parent complains about is a MySQL problem but it's pretty disingenuous to just dismiss the whole "NoSQL" idea based on one misinformed comment on HN.
    - gaius 17y ago
      Nah, this keeps coming up on HN, and 99% of the time, the thing that "SQL databases" just can't do is something that DB2, Oracle, Sybase, Informix et al have done for 15 years or more.
      - sailormoon 17y ago
        Well, I don't know what you've been reading here, but there are plenty of things you can do with one of the systems listed in that article that you can't do, or can't do well/easily/cheaply, with any conventional RDBMS. The listed systems are very disparate, but here's a couple of examples: In Redis you can read or write ~100k operations a second. You can do set operations, add, rem, member, list .. way cool if you can stomach the memory use. Lazy sync to disk. Hard to think of anything that could beat it for collecting stats or totals etc for high volume data streams. In CouchDB you can do M/R style indexed views, like word counts. You can access the DB directly from HTTP, no special drivers - the DB is implemented as a web server. You can authorise via OAuth (soon), secure via TLS and proxy through squid. You can access, and replicate, from the other side of the world. Tokyo Cabinet is over 10 times faster than MySQL as a simple hashtable, like, say, a session store, which is the first place most sites start having trouble with their DB. Tiny, bare bones, drivers for all major languages, network accessible. A no-brainer for simple storage IMO. And all of these are completely free, unlike the cripplingly expensive commercial alternatives you mentioned - especially important for startups. So .. basically I completely disagree, there's a lot of good things about these alternative DBs. Don't discount them just because you heard a few dumb ill-informed comments on sites like this, most people involved in non-RDBMS DB implementations know exactly what they're doing.
- russell 17y ago
  This should be a constant time operation on most databases, because existing rows are not touched. However, if you have lots of properties that are not indexed or directly queried, I suggest having a single JSON field for them.
- req2 17y ago
  Oops, that's what I get for repeating a single complaint I'd seen voiced in some other thread... Apologies.
chime 17y ago
Sorry for the confusion. I only mentioned properties=>columns to differentiate from the concept of rows/tables/values etc. What I meant was that different properties can be added to each object in the store without having to worry about the effect of the same properties on other objects in the same store. If you add "cellphone#" property to an object, it doesn't mean all objects in the store will now have a "cellphone#" property (defaulted to NULL). It means other objects will not even have a property "cellphone#" unless you go back to those objects and edit them. This has nothing to do with the length of time it takes to add a column in whichever SQL database you use.
blasdel 17y ago
You can't let your users do things that add arbitrary 'columns' whenever, or grow to 10,000+ on every 'table' to model attributes. That kind of usage works really well when the DB is a Entity-Attribute-Value tuplestore underneath. It's not so hot with tables, much less relational ones.
- dagheti 17y ago
  The fact that a system requiring ad-hoc attributes wouldn't work so "hot" in a relation isn't a problem with the relational model. This difficulty comes from the application of the relational model bringing to light that such a situation is necessarily more complex than one without ad-hoc attributes, and you cannot treat such data the same way as you can treat data in a relation. The important lesson is that you cannot abstract this added complexity away without losing something else of value (data integrity and simplicity of reasoning). This gives you more power when your situation isn't ad-hoc attributes (by providing more guarantees) and lets you model the ad-hoc situation with a EAV model if you must. SQL maybe should provide some more sugar for accessing that EAV, but it's not a fundamental relational model issue.

extension 17y ago

CouchDB requires explicit indexes, but they can be arbitrarily complex, which is the right approach for a database focussed on scalability. They are also fun to write (javascript + map/reduce). It appears that JavaScriptDB just maintains indexes of everything, until you have over 2000 objects of a class and then it only updates the indexes of fields when you search on them. This saves you the trouble of initially specifying indexes, but by the time your DB gets big enough that they become important, you'll have to manage them explicitly anyway, and you don't get anything besides plain old lexical sort. Persevere looks great for rapidly developing small projects, but not particularly scalable. The automatic index thing might be handy for a multi-faceted search, which is a pain to do in CouchDB.