8 ms·
In my opinion, the major reason to leave behind ACID databases is if you have reached the point where they can't scale up any more. If you have reached this poi
by kpmah 10y ago
In my opinion, the major reason to leave behind ACID databases is if you have reached the point where they can't scale up any more. If you have reached this point, you're probably a company with 20+ developers. There might also be very specific use cases where specialised databases are useful, such as a search index.
ACID gives you a lot of nice guarantees and it's silly to give it up if you have the choice.
As for MongoDB in particular, I would never use it for anything. It doesn't seem to do anything particularly well. There are better specialist 'NoSQL' databases that have actual benefits to fit your problem.
- ralfd 10y agoI thought about trying out MongoDB. Which NoSQL are better in your opinion?
- Fannon 10y agohttps://www.rethinkdb.com/ https://www.rethinkdb.com/ looks very promising and also introduces some very interesting concepts and ideas.
- h1d 10y agoRethinkDB got me interested some time ago and I took a look how they differ from SQL and found this page. https://www.rethinkdb.com/docs/sql-to-reql/javascript/ https://www.rethinkdb.com/docs/sql-to-reql/javascript/ Frankly, I cannot understand to write queries that verbose and complex when SQL looks clear and concise. If I'm missing on how good RethinkDB is, I will gladly like to know. One part SQL is notorious for is you don't know where it could fail until you send the whole query and receive the error unlike these NoSQL where operations can happen progressively. While ORM can sort of mimic that behavior, I don't like that it hides SQL which makes crappy SQL alot easier to write and harder to debug.
- kpmah 10y agoIt depends on the use case you want it for. Unless you're at massive scale, I don't think non-ACID databases are ever really appropriate as a general purpose store. There are niches though. Graph databases, search indexes, databases for logging, time series databases, mapreduce, etc.
- ActsJuvenile 10y agoWhat is a good database for massive-scale logging and task queuing? I am thinking of experimenting with RethinkDB or Redis, and would love to hear your thoughts.
- ranyefet 10y agoDo yourself a favour and use RethinkDB, its so much better then MongoDB, just try it
- ActsJuvenile 10y agoWhat are your thoughts on using RethinkDB for massive-scale logging and task queuing? Trying to select between that and Redis.
- ddorian43 10y agoMassive-scale (searchable?) logging is done with elastic-search. Redis is ok for task-queueing but is in-memory. ~best in that case (most features) would be rabbitmq (based on "python celery") though it ~should be enough in your usecase hell, you can even use your favorite (postgresql) rdbms to queue tasks
- Animats 10y agoAre you bigger than Wikipedia? Wikipedia's technology is quite conventional, yet they're the 6th busiest site by traffic. It's MariaDB with memcache, basically. If you're a mostly-read operation, you can have lots of slave databases and caches as you scale. By the time you need exotic database technology for a web site, you probably have hundreds or thousands of employees. Most of the real use cases for NoSQL involve systems where writes dominate. These are data collection systems where, later, someone searches the data. Surveillance, geophysical data, that sort of thing.
- amirouche 10y agoRDBMS might be to good database for the wiki data model. I read they also use cassandra (for serving the API) and a graphdb (for wikidata)
- greenleafjacob 10y agoRead-your-writes consistency is not preserved with read slaves which can show up in lots of ways. Create a document, get redirected to the URL for the document, document is missing.
- crgwbr 10y agoThat's sovable in numerous other, simpler ways than exotic DBs. For example, a project I worked on for a few years had a read-your-write issue. Our solution was to keep track of the timestamp of the last write each user made in an encrypted cookie. Then, we used the timestamp to control which slave (or even possibly the master) was used for queries. The result was that a user would always see their own writes, even if other users lagged a couple seconds behind.
- Animats 10y agoHacker News has that problem. Post a comment, refresh the page, and the comment may not be up yet. If you have cache front ends, it's expensive to avoid. You could probably do something with Javascript where the page checks if the cache has changed after N seconds, where N is the cache expiration time, and reloads the page if necessary. Then you're eventually consistent.