Dumb question: the author talks about not having to use caching because Mongo has built-in caching. Don't most RDBMSes also have built-in caching?
12 Months with MongoDB
41–50 of 75 posts
Re: 12 Months with MongoDB
#42Has anyone had experience comparing MongoDB and HiveDB from apache? I briefly considered both of them over a year ago before realizing that they weren't quite yet prime time for my application, and I've not had time to look at them since. I'm curious to see how they've evolved in practice.
Re: 12 Months with MongoDB
#43Earlier quoted context omitted.
My only exposure to NoSQL in production is using document oriented databases for data that, if put in an SQL database, would require schema alterations over time. This might fall under scalability, but I've worked on a few projects where we just continually added new tables because applying an alter on the existing table in production would take an unknown amount of time. Another thing we sometimes did would be to ha…
Database servers like PostgreSQL can do the most common updates (add, delete, rename columns) instantly, S they Re abstracting over the underlying data storage. Only changing the type of a column should require reading and writing it, and you can do that change using a new temporary column and renaming it around, rather than using a whole new table. Even the alterations that take time can often be run with MVCC seman…
It must be a MySQL thing then. At least when using InnoDB, it doesn't do column adds or deletes instantly. If your table is large enough it can take hours - we have several where this is the case. During this time writes to the table are blocked.
Re: 12 Months with MongoDB
#44Earlier quoted context omitted.
You could run mysql with the memory storage engine and with our schema--which would require multiple outer joins OR subqueries--mongodb will still be much faster. So I think it's much more than an fsync issue.
If the multiple outer joins or subqueries are too slow you can always denormalise a bit, you don't have to give up on your SQL database if you don't want to.
I still think it is amazing the the free SQL databases don't have materialized views yet.
MySQL's deficiencies aren't inherent to SQL databases. Other databases have faster query parsers and better query planners. It seems that with all the time and money invested into NoSQL solutions, Postgres could be improved to the level of Oracle or DB2.
Re: 12 Months with MongoDB
#45Earlier quoted context omitted.
>you will see a few financial and ecommerce sites Could you provide some examples? Scanning the list I see a couple that have a very periphery relation to financials, but the actual applications have very little financial applicability (and the implementations are trivial). Though the person you responded to didn't actually say that `"anything that deals with money" has no use for MongoDB"', so you're setting up a st…
Thanks, ergo98. I definitely think MongoDB can be used in money applications. But there's almost always some ACID requirement when you're dealing with accounting, e.g, crediting payment or billing fees. I would use something that could handle transactional ACID processing in combination with MongoDB depending on the application.
In that case, I apologize. I have seen people using the same argument to claim that MongoDB is unsuitable for use in ecommerce and assumed you were doing the same.
Re: 12 Months with MongoDB
#46Alright, so, I fully understand the scalability reasons for using MongoDB, but I need someone to clearly explain to me when NoSQL would be a better solution than SQL from a development standpoint . Because like someone pointed out, Postgres without fsync can be just as fast. What is the advantage of giving up the ability to use SQL and the associated relational algebra that has long been established in that query lan…
I use it for player levels and leaderboards - I have a set of fixed fields that all scores or levels have, and then developers can attach whatever additional data they need and filter by it, and it's just effortless.
Re: 12 Months with MongoDB
#47Dumb question: the author talks about not having to use caching because Mongo has built-in caching. Don't most RDBMSes also have built-in caching?
They might be referring to Mongo writing data into memory rather than requiring that it be written to disk before responding success (in its default configuration) or that Mongo uses memory mapped files (and tries to uses as much memory as it can) to hold the active records in memory.
Re: 12 Months with MongoDB
#48Earlier quoted context omitted.
You usually want to query and update subtrees, often concurrently. Storing the entire tree is a horrible way to think about this problem. While some NoSQL databases try to help with this, they are not in any better position to solve the problem than a simple library over an SQL database.
Kinda depends on the use case. Let's say you have a caching layer and update a subtree in your RDBMS. Then you need to go find all values referencing that object and invalidate them. That's potentially a lot of complexity. Of course you could cache only parent objects and fetch the subtree on demand (cache or db). Hello slow. So I prefer to not use words like "usually" as it truly depends on your application and use…
I do not see how the caching comment here applies, and I think it is telling that this example still includes updating a subtree. I am wondering if you think by "library" I mean "cache layer": I don't.
So, either the NoSQL solution you are using is incredibly dumb (and your schema is pretty much "id->blob") or it is internally going to have to do just as many joins against separately stored data objects in order to rebuild a concurrently-modifiable tree.
In the former case your NoSQL solution is a really fancy object serialization framework (and probably one that is not optimal for your app) and in the second case it is implementing a database and has a library on top to help you store and index trees.
To be clear, and to go back to my argument: I feel the former provides no real value and the latter could be implemented as a library over a normal SQL solution without having also had to reinvent the storage layer, the transactional semantics, etc..
Re: 12 Months with MongoDB
#49Earlier quoted context omitted.
My only exposure to NoSQL in production is using document oriented databases for data that, if put in an SQL database, would require schema alterations over time. This might fall under scalability, but I've worked on a few projects where we just continually added new tables because applying an alter on the existing table in production would take an unknown amount of time. Another thing we sometimes did would be to ha…
Database servers like PostgreSQL can do the most common updates (add, delete, rename columns) instantly, S they Re abstracting over the underlying data storage. Only changing the type of a column should require reading and writing it, and you can do that change using a new temporary column and renaming it around, rather than using a whole new table. Even the alterations that take time can often be run with MVCC seman…
(I was on an iPhone, btw, and accidentally hit the shift key instead of "a" a couple times, causing the "S they Re".)
Re: 12 Months with MongoDB
#50Earlier quoted context omitted.
Funny, I've been using MongoDB for well over a year, and I use it not for scalability/durability, but because it's so nice to develop on top of. Simply put: it gives you a much more natural way to persist the objects you work with in the OO language of your choice. It's a joy to use. Until I used it, I didn't realize how unnatural it was to map OO programming to an RDBMS. We work with objects in our languages. We don…
It's a joy to use. We work with objects in our languages. We don't work with rows of data. And I totally get that, I really do, but to me, that's more of an issue of personal preference, and less of an issue of a clear advantage. There's nothing wrong with personal preferences. For instance, I like schemas that aren't easily changed, and a clear separation of logic and data, and I prefer to think of data as rows, not…
You can still think of data as 'rows' with MongoDB - objects belong to a collection, which is analogous to a table - and you can query and select only specific fields.
The advantage is that you aren't nearly as restricted in the kinds of data you can build. SQL often forces you to split logically related data across several tables and wrestle with complicated joins, simply because a row can't contain sub-arrays or hashes.
Of course, there's no silver bullet - some times you DO want to group together logically different data in a same query. But I've found that in general, I'm not fighting the DB as much when building stuff using MongoDB.