Database Reference
In-Depth Information
MongoDB succeeds at all these goals, and this is why using MongoDB (at least for us)
is somewhat dream-like. You don't have to worry about squeezing your data into a
table—just put the data together, and then pass it to MongoDB for handling.Consider this
real-world example. A recent application co-author Peter Membrey worked on needed
to store a set of eBay search results. There could be any number of results (up to 100 of
them), and he needed an easy way to associate the results with the users in his database.
Had Peter been using MySQL, he would have had to design a table to store the data,
write the code to store his results, and then write more code to piece it all back together
again. This is a fairly common scenario and one most developers face on a regular basis.
Normally, we just get on with it; however, for this project, he was using MongoDB, and so
things went a bit differently.
Specifically, he added this line of code:
request['ebay_results'] = ebay_results_array
collection.save(request)
In this example, request is Peter's document, ebay_results is the key, and ebay_
result_array contains the results from eBay. The second line saves the changes. When
he accesses this document in the future, he will have the eBay results in exactly the same
format as before. He doesn't need any SQL; he doesn't need to perform any conversions;
nor does he need to create any new tables or write any special code—MongoDB just
worked. It got out of the way, he finished his work early, and he got to go home on time.
Lacking Innate Support for Transactions
Here's another important design decision by MongoDB developers: The database does
not include transactional semantics (the element that offers guarantees about data
consistency and storage). This is a solid tradeoff based on MongoDB's goal of being
simple, fast, and scalable. Once you leave those heavyweight features at the door, it
becomes much easier to scale horizontally.
Normally with a traditional RDBMS, you improve performance by buying a
bigger, more powerful machine. This is scaling vertically, but you can only take it so
far. With horizontal scaling, rather than having one big machine, you have lots of less
powerful small machines. Historically, clusters of servers like this were excellent for
load-balancing websites, but databases had always been a problem because of internal
design limitations.
You might think this missing support constitutes a deal-breaker; however, many
people forget that one of the most popular table types in MySQL ( MYISAM —which also
happens to be the default) doesn't support transactions, either. This fact hasn't stopped
MySQL from becoming and remaining the dominant open source database for well
over a decade. As with most choices when developing solutions, using MongoDB is
going to be a matter of personal preference and whether the tradeoffs fit your project.
 
Search WWH ::




Custom Search