- Taschenbuch: 174 Seiten
- Verlag: O'Reilly and Associates; Auflage: 1 (19. März 2013)
- Sprache: Englisch
- ISBN-10: 1449340040
- ISBN-13: 978-1449340049
- Größe und/oder Gewicht: 17,8 x 1 x 23,3 cm
- Durchschnittliche Kundenbewertung: 3 Kundenrezensionen
- Amazon Bestseller-Rang: Nr. 210.922 in Fremdsprachige Bücher (Siehe Top 100 in Fremdsprachige Bücher)
MongoDB Applied Design Patterns (Englisch) Taschenbuch – 19. März 2013
|Neu ab||Gebraucht ab|
Wird oft zusammen gekauft
Kunden, die diesen Artikel gekauft haben, kauften auch
Es wird kein Kindle Gerät benötigt. Laden Sie eine der kostenlosen Kindle Apps herunter und beginnen Sie, Kindle-Bücher auf Ihrem Smartphone, Tablet und Computer zu lesen.
Geben Sie Ihre Mobiltelefonnummer ein, um die kostenfreie App zu beziehen.
Wenn Sie dieses Produkt verkaufen, möchten Sie über Seller Support Updates vorschlagen?
Über den Autor und weitere Mitwirkende
Rick Copeland is the Principal Consultant and Founder at Arborian Consulting, a business focusing on MongoDB and Python custom development and training. Rick is a frequent speaker at MongoDB events, an avid MongoDB enthusiast, and is a charter member of 10gen's "Masters of MongoDB." In the non-MongoDB side of things, Rick is also a well-known Python developer and member of the Python Software Foundation, having contributed to a number of open-source projects and spoken at various evens and user groups.
Rick is also the author of Essential SQLAlchemy, a book published by O'Reilly that introduces the reader to the excellent SQLAlchemy Python database toolkit.
Welche anderen Artikel kaufen Kunden, nachdem sie diesen Artikel angesehen haben?
Derzeit tritt ein Problem beim Filtern der Rezensionen auf. Bitte versuchen Sie es später noch einmal.
unknown. But you can understand the logic.
Example with Java would have been better.
Online documentation is however the best source.
Die hilfreichsten Kundenrezensionen auf Amazon.com
I started working on MongoDB about 8 months ago and have been working on it since then.
1. The questions on which technique(embedding, referencing) to choose and why!! have been bogging me. This book explains in detail different decisions and approach the Developer need to make while designing Collections in MongoDB.
2. All the patterns are explained with code.
3. Case Study to apply the patterns.
In total this book is excellent for those who are looking for the answers to questions like which design decision, how to compensate the lack of transaction .
A must by for the developers.
There's a lot of bad advice out there regarding MongoDB. Even smart sources can encourage risky methods. Soon, I hope, there will be as much good MongoDB instruction from experts outside 10gen as there is good third-party SQL instruction. For now, know that you can trust Rick Copeland.
Copeland's intended audience has basic MongoDB competence and wants application examples that optimize either for scalability or maintainability, plus the principles to guide new designs. Copeland also assumes basic SQL knowledge, and presents most examples in contrast to conventional SQL solutions, a method I find distracting and irrelevant. He identifies some common application types (product catalog, CMS, analytics, etc.) and provides for each a schema and application logic. He goes far beyond prior works when he discusses performance, consistency guarantees, and sharding considerations for every application.
Copeland discusses the basic questions about MongoDB schemas. MongoDB requires optimization up front, more often than SQL schema design does. Most often the question is whether to embed or to link, and what data should be normalized or denormalized. Copeland uses an extensive description of disk seek times to explain the motivations for embedding and denormalization, better than prior MongoDB schema-design materials have. Many presentations have claimed that you can migrate your schema lazily with MongoDB: your application can start writing data in a new format, and read data in both new and old formats, while a batch job slowly migrates old data. *MongoDB Applied Design Patterns* finally presents a complete example of lazy migration, including example code (in Python) for reading data in both formats while the migration is in progress.
Without general-purpose transactions, MongoDB requires new techniques to guarantee that a series of changes is atomic: that is, to guarantee that in the long run your data either reflects all the changes or none of them. If there's no way to restrict your atomic operation to one document, your next best bet is optimistic concurrency control: try to complete the operation, check if another process overwrote your changes, and if so retry them. There are a number of examples of this in the wild; Copeland's contribution is unusually complete, with example code for handling every case that can arise.
Part 2 of the book is much longer, and covers six kinds of application in depth, both conventional (a social network) and unusual (a role-playing game). Here Copeland excels. Where he covers well-tread ground his designs are more detailed and better thought out than prior authors', and where he innovates he chooses interesting problems to solve. In the Operational Intelligence chapter he explains compound indexes clearly and correctly. He presents a complete design for an analytics application using the MongoDB aggregation framework, and covers the interactions between aggregation, indexes, and sharding.
The final example of the book is an online Zork-style game. This is less widely applicable than E-Commerce or content management, but way more fun. Copeland chooses to radically denormalize his schema: when a player enters a room, the room's entire data structure is copied into the player's document so the game can display the player's state without querying for the room again. As with the other examples, this application is considered in depth: each query is carefully indexed, and when a player picks up an item, Copeland's code prevents another player from picking it up concurrently. Most of the game's intelligence is expressed in Python code rather than in MongoDB queries. Developers using Oracle or Microsoft SQL Server tend to push all the logic and complexity into their schema, their queries, and stored procedures. With MongoDB's simpler feature-set, coders have to move more logic out of the database and into their application. If a SQL refugee hasn't yet learned this lesson, the gaming chapter will drive it home.