The only nosql databases I've used so far are key/value oriented(mostly riak). You've convinced me that there might be some benefits to documented oriented storage I haven't considered, so thank you for that.
On 02/09/2011 02:39 PM, Martin Holst Swende wrote: > I also disagree that they are "usually fast because they are in-memory > systems". They are usually fast because they basically let the 'C' in > Brewers CAP-theorem suffer, that is to say that they do not enforce > consistency across all nodes. I still must stick by my guns on this part. I think understanding the place performance wins comes from is important. Performance wins come from breaking consistency across nodes, but not only that. They (usually) also break every part of ACID, often even on each node. Most "nosql" databases don't support transactions, and the defaults don't sync in memory results with the filesystem. For example, mongodb only syncs data with permanent storage once a minute. Most relational databases sync every transaction. If you're willing to forgo that requirement, relational databases can be much faster too. http://www.mongodb.org/display/DOCS/Durability+and+Repair#DurabilityandRepair-%7B%7B%5Csyncdelay%7D%7DCommandLineOption This non-syncing behaviour is why I say its performace is from acting like an in-memory database. Because, quite frankly, it is ;-). Most "nosql" databases act like this, depending on the syncing of multiple servers to maintain data instead of permanent storage syncing. Yes, some "nosql" databases (including mongodb) are adding more advanced durability and transactional features as time goes on. I don't wish to argue against "nosql" as non-useful, just to say that you won't necessarily get better performance in the same memory space and data integrity requirements. There's no magic pixy dust in "nosql" (just like there is none in Ruby. ;-) "Nosql" is a buzzword, and I admit most of my response came from an adverse reaction to that. If the message was "we should explore document-oriented storage"(which is what mongoDB is) or "maybe key value stores are all we need" I'm much less hostile ;-) -- | Steven Pinkham, Security Consultant | | http://www.mavensecurity.com | | GPG public key ID CD31CAFB |
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop
