"51CTO classic" I like MongoDB mainly because it is so simple and natural to use it in dynamic languages. So far, I've used it in two projects (Encode and SPARRW), although I'm very happy with the choice, but there are some problems I haven't noticed, and these problems have kept me scratching my scalp for hours. If you have multiple machines, and then allocate several more machines to the database, then some problems can be solved, but my project is a low flow Web application running on a single (virtual) server.
(For MongoDB, you can refer to: http://www.mongodb.org/)
(for the authors of the two projects encode and SPARRW, respectively, refer to: http://en.co.de/and http://sparrw.com/)
All of these questions are simple, documented things, not bugs (which, of course, depends on who you ask). If you've read all the documents, you've probably seen the basics. Me too, but after that, when I met them again, I forgot the contents of the document and then I had to fix them again.
Use a 64-bit version
A 32-bit version can store only 2.5GB of data. Of course, it might be enough if you just play. But when you start to configure your production (or demo) system, remember to choose the 64-bit version, because you won't be able to fix the problem in the future, you can only reinstall it.
On another machine, create a database
If your MongoDB instance crashes (or because the oom hangs, or the entire system crashes), no one can guarantee your data. You can fix it, but it's kind of like running fsck or buying a lottery ticket-you never know what you're going to get. So you should create one from the database (or make a "replica set"), and you should put this from the database onto another server. If a VPS (Virtual Private server VPN) just satisfies your (or someone else's) needs, it's a real hassle, but it's inevitable if you value your data.
Make it safer.
By default, MongoDB does not authenticate, and it listens to all the network interfaces (this is true for the version you get directly from their official site; Linux distributions (for example, Debian and Ubuntu), by default, are only bound to 127.0.0.1, which is very sensible), which means that anyone can access your database anywhere in the world. If you're using it on a public-facing server, that's a problem. You can set it to be authenticated, or you can let MongoDB only monitor localhost. I prefer the latter because I am the only user on my server.
Always use GetLastError
If you don't need lightning speed, take a moment to make sure that your changes are OK for the database, and that it is definitely worthwhile to modify the data without causing any problems-if there are any problems, write them down in your application to let you know that there is something wrong with the database. Or, if you're sure you need to use Getlasteror (), then at least don't mix it up or use it on the same set. MongoDB cannot ensure that commands are executed in the order specified. In my test code, I made an "asynchronous" remove () call (i.e., I don't have to wait for this function to finish, and then I'm happy to remove them (I may have removed them all, maybe just remove a part of them, and maybe nothing else, This depends largely on competition) before I inserted some new entries. It puzzled me for several hours.
There are many online documents, in various forums, you can also find a lot of this information, if you can get this information in a more concise way, that would be good. For this, I've found that the mongodb:the definitive Guide book and 10gen videos are very helpful-for example, deployment strategies video is an excellent tutorial for getting started.
(about "mongodb:the definitive Guide book", Specific Reference: http://oreilly.com/catalog/0636920001096)
(For 10gen videos, you can refer to: Http://www.10gen.com/video)
(For deployment strategies, refer to: http://www.10gen.com/video/mongosv2010/deployment)
I hope my summary of these tips will help you avoid the mistakes I made in using MongoDB:-)
Original title: 4 Tips for MongoDB Beginners
MONGO is a high-performance, open source, modeless document database that can be used to replace traditional relational databases or key/value storage in many scenarios. MONGO uses C + + development to provide the following features:
Collection-oriented storage: data that is appropriate for storing objects and JSON forms.
Dynamic query: MONGO supports rich query expressions. Query directives use JSON-form tags to easily query objects and arrays embedded in the document.
Full index support: Includes document inline objects and arrays. The MONGO query optimizer analyzes query expressions and generates an efficient query plan.
Query monitoring: MONGO contains a monitoring tool for analyzing the performance of database operations.
Replication and automatic failover: The MONGO database supports data replication between servers, supporting master-from-mode and server replication. The primary goal of replication is to provide redundancy and automatic failover.
Efficient traditional storage: supports binary data and large objects such as photos or pictures.
Automatic fragmentation to support cloud-level scalability (in the early alpha phase): Automatic fragmentation supports a level of database clustering that can dynamically add additional machines.
The main goal of MongoDB is to set up a bridge between key/value storage (high performance and high scalability) and traditional RDBMS systems (rich functionality), combining the advantages of both. According to the official website description, MONGO is suitable for the following scenarios:
Site data: MONGO is ideal for real-time inserts, updates, and queries, as well as the replication and high scalability required for real-time data storage on the Web site.
Caching: Because of its high performance, MONGO is also suitable as a caching layer for the information infrastructure. After the system restarts, the persistent cache layer built by MONGO can avoid overloading the underlying data source.
Large size, low value data: It may be expensive to store some data using a traditional relational database, before which programmers often choose traditional files for storage.
Highly scalable scenario: MONGO is ideal for databases composed of dozens of or hundreds of servers. The MONGO roadmap already contains built-in support for the MapReduce engine.
Storage for objects and JSON data: MONGO's Bson data format is ideal for storing and querying in a documented format.
Naturally, the use of MongoDB can also have some limitations, such as it does not fit:
Highly transactional system: such as a bank or accounting system. Traditional relational databases are now more suitable for applications that require a large number of atomic complex transactions.
Traditional business intelligence applications: The BI database for a particular problem is a highly optimized query. For such applications, the Data warehouse may be a more appropriate choice.
Problems requiring SQL
MongoDB supports operating systems such as OS X, Linux, and Windows and provides drivers for Python,php,ruby,java and C + + languages, as well as drivers for Erlang and. NET platforms in the community.
MongoDB CEO talking about NoSQL's large data processing ability Discard relational database PHP programmers should know about the MongoDB five things MongoDB, modeless document database Introduction The end of the relational database has come to throw away the sunk cost Try relational database substitutes Oodbms "responsible editor: Pengfan TEL: (010) 68476606"
Original: Getting Started MongoDB, you need to pay attention to the 4 tips to return to the database home
share to: Favorites | printing | copying