Slashdot Mirror

Now I know nothing about mongodb but I installed 4.0.1 in CentOS 7 and changed the user of /var/run/mongodb/ to root:root and when I launched mongo from the console with the mongod user (I could find no lock file, don't know if that is used in prior versions only or if that is something that have to be configured) but the error from mongod could be seen in the journal:

[root@localhost ~]# systemctl status mongod.service
mongod.service - MongoDB Database Server
Loaded: loaded (/usr/lib/systemd/system/mongod.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since tis 2018-08-21 13:55:22 CEST; 5s ago
Docs: https://docs.mongodb.org/manua...
Process: 11630 ExecStart=/usr/bin/mongod $OPTIONS (code=exited, status=1/FAILURE)
Main PID: 11279 (code=exited, status=0/SUCCESS)

aug 21 13:55:22 localhost.localdomain systemd[1]: Starting MongoDB Database Server...
aug 21 13:55:22 localhost.localdomain mongod[11630]: 2018-08-21T13:55:22.792+0200 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
aug 21 13:55:22 localhost.localdomain mongod[11630]: about to fork child process, waiting until server is ready for connections.
aug 21 13:55:22 localhost.localdomain mongod[11630]: forked process: 11632
aug 21 13:55:22 localhost.localdomain mongod[11630]: ERROR: child process failed, exited with error number 1
aug 21 13:55:22 localhost.localdomain mongod[11630]: To see additional information in this output, start without the "--fork" option.
aug 21 13:55:22 localhost.localdomain systemd[1]: mongod.service: control process exited, code=exited status=1
aug 21 13:55:22 localhost.localdomain systemd[1]: Failed to start MongoDB Database Server.
aug 21 13:55:22 localhost.localdomain systemd[1]: Unit mongod.service entered failed state.
aug 21 13:55:22 localhost.localdomain systemd[1]: mongod.service failed.

Which is the same error it gave on the console:

[root@localhost ~]# su mongod -p --session-command '/usr/bin/mongod --config /etc/mongod.conf'
2018-08-21T13:55:13.168+0200 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
about to fork child process, waiting until server is ready for connections.
forked process: 11622
ERROR: child process failed, exited with error number 1
To see additional information in this output, start without the "--fork" option.

So looks like the problem with the unit file have been solved, atleast in the 4.0.1 version

Looking for default ports used by the problem software probably isnt a bad start. https://docs.mongodb.org/v3.0/...

They should have just used MongoDB. I hear it's web scale.

Web scale or not, I have no idea. But I do think they've got the best bug report ever in their tracker.

Look at that, MongoDB write concerns have been improved since I last checked. Thanks for usefully pointing to that as a reference, instead of, say, quoting yourself just to be smug.

The MongoDB core is AGPL. Its drivers are all Apache license, as explained here, therefore not polluting your web application code and forcing it under the AGPL.

BerkeleyDB, on the other hand, is linked in directly, and would force anything using it to be under the AGPL.

would anything limit you from making that part separate though? the performance hit wouldn't be that bad.

you could of course just use sqlite or something else..

The MongoDB core is AGPL. Its drivers are all Apache license, as explained here, therefore not polluting your web application code and forcing it under the AGPL.

BerkeleyDB, on the other hand, is linked in directly, and would force anything using it to be under the AGPL.

I've just gotten my NoSQL feet wet by playing around a weekend with python + mongodb. I am pretty used to SQL, and generally had the same thinking you (and most other SQL people) had.

But, many people liked it, so I figured out I should at least have a look at it. I made a small webapp for tracking my movies, with query to imdb and with users. I was surprised to see that most of the problems I anticipated wasn't a problem at all, and things mostly just worked naturally. For a quick get-started intro to python + mongodb : Part 1 and Part 2. If you got the spare time and some interest, poking around with it is a great little weekend project.

Anyway, back to your question. MongoDB store data in a format very similar to JSON (technically BSON, a JSON superset), if you're familar with that. Unordered key->value and ordered lists. For the python driver, it translates the data to and from native python dict/list structures. I started with three fields; filename, added and imdb. The imdb field was more or less the raw data from imdb (json format, decoded to python native and encoded to mongodb's BSON format again.)

Later on I added option for users to mark movies as favorites and seen (by adding two new fields to movie list, "seenby" and "favoriteof" - both lists - these were added to a movie entry the first time someone marked one as seen or favorite). To add a new user I just did movie["seenby"].append(user_id) and movies.save(movie)

When I wanted to query the db, I created a data structure of what I wanted, and sent that to the server. The server would then return all documents that matched that example structure. So, to find the entry for file "/bla/test.mp4" I would do movies.find( {'filepath': '/bla/test.mp4} ).

For finding by imdb Title value : {'imdb.Title': '300'}. For finding all favorites by user: {"favoriteof": user_id} (yes, it would handle the list of users as you'd expect, and find all that the list of "favoriteof" had user in it. It would also of course skip all entries without that field).

mongodb also support some special keywords for searching. Let's say I have a list of 3 users, and want to have all movies that any of them have favorited. {"favoriteof" : {"$in": users} } would fix that - for movies that all of them have as favorite, {"favoriteof" : {"$all": users} }. Sorting was done using sort_by( field_n_direction_list )

You have a full list of modifiers here. And all could of course be combined to quickly and easily create powerful queries. And you of course have options for indexes. You might notice that you do lose something from normal SQL's here, if you wanted both movie and user info, you'd have to make two queries (well, from what I've understood) so highly relational data is not fitted for this. Also, you don't have the type constraints any more.

In the app I also wanted to list all movie genres (I did one preprocessing of the imdb data, splitting up comma seperated genres string to a list of genres) and number of times each genre was used. This led me to mapreduce, which was the thing I both anticipated most, and feared most. Well, I kinda chickened out, since the pymongo doc had an excellent example which was exactly what I wanted doing, but I did get a look at it at least :) And it was fast enough to not making a noticeable dent in load time for a few hundred movie entries.

*Cough* well, that was a long post.. I hope it helped you at least a bit in answering your question, and maybe inspire you to take a closer look at it when you get some spare time. I've only used it over a weekend, so I've probably just scratched the surface, and I probably have missed some neat features or horrible gotchas here and

I've just gotten my NoSQL feet wet by playing around a weekend with python + mongodb. I am pretty used to SQL, and generally had the same thinking you (and most other SQL people) had.

But, many people liked it, so I figured out I should at least have a look at it. I made a small webapp for tracking my movies, with query to imdb and with users. I was surprised to see that most of the problems I anticipated wasn't a problem at all, and things mostly just worked naturally. For a quick get-started intro to python + mongodb : Part 1 and Part 2. If you got the spare time and some interest, poking around with it is a great little weekend project.

Anyway, back to your question. MongoDB store data in a format very similar to JSON (technically BSON, a JSON superset), if you're familar with that. Unordered key->value and ordered lists. For the python driver, it translates the data to and from native python dict/list structures. I started with three fields; filename, added and imdb. The imdb field was more or less the raw data from imdb (json format, decoded to python native and encoded to mongodb's BSON format again.)

Later on I added option for users to mark movies as favorites and seen (by adding two new fields to movie list, "seenby" and "favoriteof" - both lists - these were added to a movie entry the first time someone marked one as seen or favorite). To add a new user I just did movie["seenby"].append(user_id) and movies.save(movie)

When I wanted to query the db, I created a data structure of what I wanted, and sent that to the server. The server would then return all documents that matched that example structure. So, to find the entry for file "/bla/test.mp4" I would do movies.find( {'filepath': '/bla/test.mp4} ).

For finding by imdb Title value : {'imdb.Title': '300'}. For finding all favorites by user: {"favoriteof": user_id} (yes, it would handle the list of users as you'd expect, and find all that the list of "favoriteof" had user in it. It would also of course skip all entries without that field).

mongodb also support some special keywords for searching. Let's say I have a list of 3 users, and want to have all movies that any of them have favorited. {"favoriteof" : {"$in": users} } would fix that - for movies that all of them have as favorite, {"favoriteof" : {"$all": users} }. Sorting was done using sort_by( field_n_direction_list )

You have a full list of modifiers here. And all could of course be combined to quickly and easily create powerful queries. And you of course have options for indexes. You might notice that you do lose something from normal SQL's here, if you wanted both movie and user info, you'd have to make two queries (well, from what I've understood) so highly relational data is not fitted for this. Also, you don't have the type constraints any more.

In the app I also wanted to list all movie genres (I did one preprocessing of the imdb data, splitting up comma seperated genres string to a list of genres) and number of times each genre was used. This led me to mapreduce, which was the thing I both anticipated most, and feared most. Well, I kinda chickened out, since the pymongo doc had an excellent example which was exactly what I wanted doing, but I did get a look at it at least :) And it was fast enough to not making a noticeable dent in load time for a few hundred movie entries.

*Cough* well, that was a long post.. I hope it helped you at least a bit in answering your question, and maybe inspire you to take a closer look at it when you get some spare time. I've only used it over a weekend, so I've probably just scratched the surface, and I probably have missed some neat features or horrible gotchas here and

Many of the key-value pair DBs supply a Perl library...

Did somebody say MongoDB + PERL?

Well, mongodb is being used by a lot of "cloudy" web 2.0 companies (Shutterfly, Foursquare, Bitly, and others).

It doesn't use XML or YAML, but you can build hierarchical structures with JSON because it's basically a free-form database.

What sort of application would need thousands of nodes (other than Facebook)?

It does automatic sharding (horizontal partitioning), with eventual consistency.

Well, mongodb is being used by a lot of "cloudy" web 2.0 companies (Shutterfly, Foursquare, Bitly, and others).

It doesn't use XML or YAML, but you can build hierarchical structures with JSON because it's basically a free-form database.

What sort of application would need thousands of nodes (other than Facebook)?

It does automatic sharding (horizontal partitioning), with eventual consistency.

Sadly, GonorrheaDB isn't really that much worse of a name than MongoDB.

I know that Mongo DB is not durable, and they (recommend using replication for reliability ), that sounds like a substantial sacrifice. Do these DBs have equivalents to referential integrity and joins?

So, remember, NoSQL means that's anything but SQL. It's not a standard; rather, it's an honest effort to try to experiment with different database techniques where traditional SQL just isn't meeting an industry need. Key-value databases aren't going to satisfy the "give me how many widgets we sold in June to evil inventors in the tri-state area" need; but they do satisfy the scalability need for sites that have millions of concurrent users.

Regarding Mongo, the NoSQL database that I use, it can answer the "give me how many widgets we sold in June to evil inventors in the tri-state area." Basically, instead of having 100 tables with foreign key relationships, you'll have 10 collections of "documents," which are really just data structures. You can query deeply into data structures and return partial data structures.

Let's assume I have an "invoices" collection. Each invoice has an array of "line items", and each item has a count. I can do the following in Mongo:

• Give me all of the documents from the invoices collection that are for companies in the tri-state area and have widgets X, Y, and Z: http://www.mongodb.org/display/DOCS/Dot+Notation+(Reaching+into+Objects)
• (Use the above query,) but instead of returning full documents, just return the parts of the documents that represent the "line items" that match widgets X, Y, and Z: http://www.mongodb.org/display/DOCS/Retrieving+a+Subset+of+Fields
• (Use the above query,) but just return the counts of widgets sold: http://www.mongodb.org/display/DOCS/Aggregation

Again, NoSQL isn't a standard. It's basically experimenting with different ways of having a database with the hopes of finding one that's easier to work with. Mongo is a lot closer to SQL then things like Key-Value databases.

So, remember, NoSQL means that's anything but SQL. It's not a standard; rather, it's an honest effort to try to experiment with different database techniques where traditional SQL just isn't meeting an industry need. Key-value databases aren't going to satisfy the "give me how many widgets we sold in June to evil inventors in the tri-state area" need; but they do satisfy the scalability need for sites that have millions of concurrent users.

Regarding Mongo, the NoSQL database that I use, it can answer the "give me how many widgets we sold in June to evil inventors in the tri-state area." Basically, instead of having 100 tables with foreign key relationships, you'll have 10 collections of "documents," which are really just data structures. You can query deeply into data structures and return partial data structures.

Let's assume I have an "invoices" collection. Each invoice has an array of "line items", and each item has a count. I can do the following in Mongo:

• Give me all of the documents from the invoices collection that are for companies in the tri-state area and have widgets X, Y, and Z: http://www.mongodb.org/display/DOCS/Dot+Notation+(Reaching+into+Objects)
• (Use the above query,) but instead of returning full documents, just return the parts of the documents that represent the "line items" that match widgets X, Y, and Z: http://www.mongodb.org/display/DOCS/Retrieving+a+Subset+of+Fields
• (Use the above query,) but just return the counts of widgets sold: http://www.mongodb.org/display/DOCS/Aggregation

Again, NoSQL isn't a standard. It's basically experimenting with different ways of having a database with the hopes of finding one that's easier to work with. Mongo is a lot closer to SQL then things like Key-Value databases.

So, remember, NoSQL means that's anything but SQL. It's not a standard; rather, it's an honest effort to try to experiment with different database techniques where traditional SQL just isn't meeting an industry need. Key-value databases aren't going to satisfy the "give me how many widgets we sold in June to evil inventors in the tri-state area" need; but they do satisfy the scalability need for sites that have millions of concurrent users.

Regarding Mongo, the NoSQL database that I use, it can answer the "give me how many widgets we sold in June to evil inventors in the tri-state area." Basically, instead of having 100 tables with foreign key relationships, you'll have 10 collections of "documents," which are really just data structures. You can query deeply into data structures and return partial data structures.

Let's assume I have an "invoices" collection. Each invoice has an array of "line items", and each item has a count. I can do the following in Mongo:

• Give me all of the documents from the invoices collection that are for companies in the tri-state area and have widgets X, Y, and Z: http://www.mongodb.org/display/DOCS/Dot+Notation+(Reaching+into+Objects)
• (Use the above query,) but instead of returning full documents, just return the parts of the documents that represent the "line items" that match widgets X, Y, and Z: http://www.mongodb.org/display/DOCS/Retrieving+a+Subset+of+Fields
• (Use the above query,) but just return the counts of widgets sold: http://www.mongodb.org/display/DOCS/Aggregation

Again, NoSQL isn't a standard. It's basically experimenting with different ways of having a database with the hopes of finding one that's easier to work with. Mongo is a lot closer to SQL then things like Key-Value databases.

Yes, agreed, a combination is good (SQL + NoSQL + filesystem).

There is no one-size-fits-all scenario, here.

However, there is utility in a NoSQL database over a raw filesystem. One feature is indexed search. Another is versioning. Another is the fact that it is extremely multiuser (proper record locking, even if there are multiple writes to the same record). Also, many NoSQL databases (especially MongoDB) have built-in replication, sharding, Map-Reduce, and horizontal scaling.

MongoDB's GridFS (especially with FUSE support) marries many of these features together. MongoDB does have some SQL DB features (such as indexing/searching and transactions) but not others.

Check out the whole stack here:
    http://www.mongodb.org/
    http://www.mongodb.org/display/DOCS/GridFS
    http://github.com/mikejs/gridfs-fuse

Yes, agreed, a combination is good (SQL + NoSQL + filesystem).

There is no one-size-fits-all scenario, here.

However, there is utility in a NoSQL database over a raw filesystem. One feature is indexed search. Another is versioning. Another is the fact that it is extremely multiuser (proper record locking, even if there are multiple writes to the same record). Also, many NoSQL databases (especially MongoDB) have built-in replication, sharding, Map-Reduce, and horizontal scaling.

MongoDB's GridFS (especially with FUSE support) marries many of these features together. MongoDB does have some SQL DB features (such as indexing/searching and transactions) but not others.

Check out the whole stack here:
    http://www.mongodb.org/
    http://www.mongodb.org/display/DOCS/GridFS
    http://github.com/mikejs/gridfs-fuse

Mongodb has a nice mongodb tutorial. In one of their examples the following javascript statement "db.things.find({x:4}, {j:true}).forEach(function(x) { print(tojson(x));});" performs the equivalent of the following SQL statement "SELECT j FROM things WHERE x=4" http://www.mongodb.org/display/DOCS/Tutorial

Marschaling is still required, but you don't need to think about being restricted to a schema, columns, types, to define identifiers for everything, to do explicit joins, etc. Just store your objects as they are in memory.
Look at MongoDB: http://www.mongodb.org/