Another post about the upcoming MongoDB full text search, this one adds some more details about supported languages and queries:

• Support for Latin based languages initially, with plans for other character sets later. Initially this will be: Danish, Dutch, English, Finnish, French, German, Hungarian, Italian, Norwegian, Portuguese, Romanian, Russian, Spanish, Swedish and Turkish.
• Support for advanced queries, similar to the Google search syntax e.g. negation and phrase matching.

It’s worth emphasizing that the post refers to character sets when speaking about supported languages, but not about stemming which differs for many of those.

Original title and link: Full Text Search in MongoDB: Details About Languages and Queries (NoSQL database©myNoSQL)

via: http://blog.serverdensity.com/full-text-search-in-mongodb/

Tobias Trelle explains the features planned for the full text support coming in MongoDB 2.4: stop words, (basic) stemming, full text indexes, and API:

The upcoming release 2.4 of MongoDB will include a first, experimental support for full text search (FTS). This feature was requested early in the history of MongoDB as you can see from this JIRA ticket: SERVER-380. FTS is first available with the developer release 2.3.2.

Couple of reasons for MongoDB including full text search:

1. highly requested feature (239 votes, 193 watchers, 42 participants)
2. (high level) feature parity with MySQL
3. NIH

The majority of databases support full text indexing, but almost everyone needing good full text search ends up using Lucene or Solr or Elastic Search or Sphinx.

Original title and link: MongoDB Full Text Search Explained (NoSQL database©myNoSQL)

via: http://blog.codecentric.de/en/2013/01/text-search-mongodb-stemming/

MongoMem, a Python tool, by Wish Tech team:

Today, we’re releasing the first of these tools, MongoMem. MongoMem solves the age-old problem of figuring out how much memory each collection is using. In MongoDB, keeping your working set in memory is pretty important for most apps. The problem is, there’s not really a way to get visibility into the working set or what’s in memory beyond looking at resident set size or page faults rate.

Original title and link: MongoMem: Memory Usage by Collection in MongoDB (NoSQL database©myNoSQL)

via: http://eng.wish.com/mongomem-memory-usage-by-collection-in-mongodb/

Vyacheslav Voronenko expands a bit on the Model tree structures in MongoDB article and provides some code snippets for common operations:

In a real life almost any project deals with the tree structures. Different kinds of taxonomies, site structures etc require modelling of hierarhy relations. In this article I will illustrate using first three of five typical approaches of operateting with hierarchy data on example of the MongoDB database. Those approaches are:

• Model Tree Structures with Child References
• Model Tree Structures with Parent References
• Model Tree Structures with an Array of Ancestors
• Model Tree Structures with Materialized Paths
• Model Tree Structures with Nested Sets

The 2nd part of the article is available here and all the code is on GitHub

Original title and link: Storing Tree Like Hierarchy Structures With MongoDB (NoSQL database©myNoSQL)

via: http://www.codeproject.com/Articles/521713/Storing-Tree-like-Hierarchy-Structures-With-MongoD

MongoDB isn’t a write-to-disk application unlike SQL. So it writes to a fsync queue first which actually gets managed by the OS (this is fundamentally NoSQL here to not write straight to disk, “Eventually Consistent”), since MongoDB does no memory management of its own.

The OS itself will then decide when paged in data should be removed using the LRU algorithm: http://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used

Added ontop of this is that you must load a part of the _id btree each time you insert as well which is ever growing due to insertions. This means that actually if you do mass inserts in a short period of time you could end up loading more of the btree than you need to because the older section of the btree have not been seen as stale yet.

How many “strange” explanations have you counted in the above answer?

Original title and link: A SO Answer About MongoDB Memory Usage (NoSQL database©myNoSQL)

via: http://stackoverflow.com/questions/14134109/mongodb-memory-usage-is-going-high-even-if-only-insertions-are-made

Put together by the team at Altoros Systems Inc., this time run in the Amazon EC2 and including Cassandra, HBase, MongoDB, MySQL Cluster, sharded MySQL and Riak:

After some of the results had been presented to the public, some observers said MongoDB should not be compared to other NoSQL databases because it is more targeted at working with memory directly. We certainly understand this, but the aim of this investigation is to determine the best use cases for different NoSQL products. Therefore, the databases were tested under the same conditions, regardless of their specifics.

Teaser: HBase got the best results in most of the benchmarks (with flush turned off though). And I’m not sure the setup included the latest HBase read improvements from Facebook.

Original title and link: YCSB Benchmark Results for Cassandra, HBase, MongoDB, MySQL Cluster, and Riak (NoSQL database©myNoSQL)

via: http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/news/tech/2012/102212-nosql-263595.html&pagename=/news/tech/2012/102212-nosql-263595.html&pageurl=http://www.networkworld.com/news/tech/2012/102212-nosql-263595.html&site=printpage&nsdr=n

Alex Williams for TechCrunch:

MongoHQ has raised $6 million from Trinity Ventures and a host of investors for its database service for developers. The company will use the funds to expand its public cloud offering and improve its management tools for MongoDB, the popular NoSQL database.

Undeniably there’s a lot of demand for MongoDB. 10gen is also growing fast.

But how safe is to build a business around a product that is not in your control?

Original title and link: MongoHQ Raises More Funding for MongoDB as Service Engine (NoSQL database©myNoSQL)

via: http://techcrunch.com/2012/10/18/mongohq-raises-6-million-for-database-as-service-engine/

In his “what I’ve learned while using MongoDB for an year” post, Simon Maynard recommends 5 metrics to always monitor:

1. index sizes
2. current ops
3. index misses
4. replication lag
5. I/O performance

The 1st and the 3rd are about making sure all your MongoDB working set (including indexes) fits in RAM.

Original title and link: 5 Things to Monitor in MongoDB (NoSQL database©myNoSQL)

via: http://snmaynard.com/2012/10/17/things-i-wish-i-knew-about-mongodb-a-year-ago/