0

I am looking for someone who likes PHP, Javascript (JSON), REST and MySQL to tell me which NoSQL database will be a better option for LAMP developers.

The specific application is creating a NoSQL database that will have a small amount of key-value objects, allowing the app to respond quickly to users with only the most important and time sensitive data. The only real time NoSQL updating would be logging user access timestamps.

High Level Process:

  1. User interacts with desktop or web application to handle major data entry transactions stored in MySQL
  2. Application copies subset of data into NoSQL as an object with the user's UUID as the key. Only the user's most recent transaction is stored in NoSQL.
  3. User connects to NoSQL data with a mobile device or voice to check on status of transaction

Question: Which NoSQL database is better for the above process for a LAMP developer and why?

Community
  • 1
  • 1
Dylan Valade
  • 5,565
  • 6
  • 42
  • 56
  • 1
    Why can't you just store this stuff in MySQL again? – NullUserException Nov 08 '11 at 15:02
  • I can and we've all been doing it for years but it sounds like using NoSQL backed by something ultra quick like node.js (server Javascript) would make the app's response that much faster for users even at peak traffic times. I want to run the complex SQL queries and tables joins once when the data is entered and not require it again every time someone needs a quick read-only look at their data. – Dylan Valade Nov 08 '11 at 15:06
  • Then why not just drop MySQL altogether? – NullUserException Nov 08 '11 at 15:07
  • I am happy with MySQL. Tons of developers know it well, the security is well defined and it works. Now I'm looking for ways to improve the end user experience. – Dylan Valade Nov 08 '11 at 15:10
  • 1
    Whether or not this was closed due to "civil warfare", it should also be closed because you couldn't be bothered to go [read the tutorial](http://www.php.net/manual/en/mongo.tutorial.php). It's like three lines. – ceejayoz Nov 08 '11 at 17:10
  • @Dylan your edit changes the question completely. Don't take it personally if the question has been closed! Is just how SO works, a new question with the current text. – stivlo Nov 08 '11 at 17:11
  • @DylanValade, rolled back to the original question, otherwise my answer and all the discussion wouldn't make any sense. – stivlo Nov 09 '11 at 03:26

1 Answers1

4

MongoDb and CouchDb are quite similar. Anyway, MySQL is also quite responsive, and to increase performance, maybe you can look at Memcached.

MongoDb

  • Document oriented Database, based on BSON (JSON-like) documents
  • Key value database, but values can be BSON documents
  • High performance in both read and write operations
  • Scalable (Master-Slave replication)
  • Custom protocol
  • Not suited for applications that require data integrity (banking, ecommerce, accounting) -

CouchDb

  • Document oriented Database, based on JSON documents
  • Key value database, but values can be JSON documents
  • High performance in both read and write operations
  • Scalable (Master-Master replication with conflict resolutions)
  • REST protocol
  • Not suited for applications that require data integrity (banking, ecommerce, accounting) -- see the comment of Robert Newson - he's arguing that a document update is fully acid compliant and while it doesn't support transactions on multiple document update is still suited for this kind of applications. Also to consider that a "document" can contain structured information, it's more rich than a relational DB record. I'm going to think about it, before updating again this question.
stivlo
  • 83,644
  • 31
  • 142
  • 199
  • Thanks for your help stivlo. What would be the implications of choosing `master-slave` versus `master-master` for replication? – Dylan Valade Nov 08 '11 at 15:17
  • 2
    master-slave is the traditional replication, the writes are done to a server, and all other servers replicate it, and work read only. master-master is a more complex scenario, where writes are allowed on more than one server. I think however, that for your use case, you can make your site fly with memcached, which works as an in-memory key/store cache mechanism. You can keep all your data in MySQL and use memcached to cache public queries, or even ready made objects. – stivlo Nov 08 '11 at 15:27
  • That is very helpful! I didn't realize memcached was that effective – Dylan Valade Nov 08 '11 at 15:36
  • 1
    "Not suited for applications that require data integrity (banking, ecommerce, accounting)" -- This is completely false (for CouchDB). – Robert Newson Nov 08 '11 at 16:20
  • @RobertNewson happy to fix mistakes and learn. Can you point me to some relevant documentation about this? thank you – stivlo Nov 08 '11 at 16:37
  • 1
    @RobertNewson can you please look at the accepted answer: http://stackoverflow.com/questions/299723/can-i-do-transactions-and-locks-in-couchdb are the arguments still valid or obsoleted by new couchdb developments? thank you – stivlo Nov 08 '11 at 16:46
  • Recent versions of Mongo have better data integrity with journaling, replica sets, the ability to ensure a certain threshold of replication, etc. – ceejayoz Nov 08 '11 at 17:11
  • @stivlo the question of transactions and locks is unrelated to whether you can use couchdb for accounting. A CouchDB document update is a fully ACID transaction. The only kind of transaction missing from CouchDB is the kind that don't scale well; multiple-operation transactions. Banking is the canonical example of eventual consistency in the real world (Do you *really* believe that every commercial transaction is a distributed transaction between all the involved parties? No, it is done lazily, often offline. Banks converge. – Robert Newson Nov 08 '11 at 18:48
  • @RobertNewson ok, I understand what you mean. Let me think about it, I've already updated the answer with your comment, and going to update again once I've understood the implications. – stivlo Nov 09 '11 at 02:55