Posts tagged:

mongodb

MongoDB Text Search: Experimental Feature in MongoDB 2.4

Jan 14 • Posted 1 year ago

Text search (SERVER-380) is one of the most requested features for MongoDB 10gen is working on an experimental text-search feature, to be released in v2.4, and we’re already seeing some talk in the community about the native implementation within the server. We view this as an important step towards fulfilling a community need. 

MongoDB text search is still in its infancy and we encourage you to try it out on your datasets. Many applications use both MongoDB and Solr/Lucene, but realize that there is still a feature gap. For some applications, the basic text search that we are introducing may be sufficient. As you get to know text search, you can determine when MongoDB has crossed the threshold for what you need.

Setting up Text Search


You can configure text search in the mongo shell:

db.adminCommand( { setParameter : 1, textSearchEnabled : true } )


Or set a command:

mongod --setParameter textSearchEnabled=true

 

Read more

3D Repo Runs MongoDB

Dec 12 • Posted 1 year ago

If you’re an architectural or engineering firm, you’ve undoubtedly confronted the difficulty of managing and collaborating on 3D assets like CAD drawings.  The act of sharing massive files is hard but feasible, but it is significantly complicated by the inability to determine that you’re using the latest version.  For the CAD-inclined, there’s hope. Jozef Dobos, a doctoral student at University College London (UCL), has applied the geospatial indexing capabilities of MongoDB a version control system for 3D assets called 3D Repo.  Sponsored by Arup Foresight, the built environment innovation division of Arup Group Limited, a global design and business consulting firm with offices in over 30 countries, 3D Repo leverages the flexibility of MongoDB’s data model, not to mention its geospatial capabilities, to make collaboration on 3D assets easy.

Read more

November Driver Releases

Dec 10 • Posted 1 year ago

On November 27, all 10gen supported drivers were updated with new error checking and reporting defaults. Each driver now has a MongoClient connection class to handle the error checking. On the same day there was also a server release with fixes on 2.2

Interview with Joe Devon, Organizer of the Los Angeles MongoDB User Group

Nov 12 • Posted 1 year ago

The Los Angeles MongoDB User Group was founded in the summer of 2011 and, thanks to the leadership of Joe Devon, has grown to over 400 members in the past year. Joe Devon, a long-time member of the Silicon Beach tech community, shares his insights from a year of working with the MongoDB community in Los Angeles. 

You’re a User Group Veteran. How did you get started organizing user groups?

I was living in NY, with several meetups to choose from every night. Then moved to Los Angeles, where there were none. In the words of Cal Evans, if you don’t know who your local organizer is, you’re looking at him :) 

So I started a bunch of meetups, told people to gather at Panera Bread once a month in one big, joint set of meetups…. And couldn’t get 10 people to show. But after awhile, there were some regulars. Some of whom agreed to take over a group here, a group there. Fast forward to today and there’s a ton of tech meetups in Los Angeles, with sometimes 100-200 people showing up on good nights. 

Read more

MongoDB for the PHP Mind, Part 3

Nov 6 • Posted 1 year ago

This is part 3 in a series, which will focus on the data modeling aspect of working with document databases. The previous parts are also available for reading: Part 1: Getting Started, and Part 2: Queries and Indexes.

The Usual Suspects

Although there are plenty of existing articles, presentations and webcasts about modeling your data to take advantage of a document database, this post is taking a slightly PHP-centric position as a part of this series. This information is useful to anyone though, regardless of their chosen programming language.

We’re going to use two different scenarios to look at data modeling in the document world, chosen as common examples to illustrate differences in implementation between relational and document databases:

  • Blog. Your garden variety of data, covering posts, comments and tags
  • Private Sale / E-Commerce. Taking a look at needs for orders, users and products

Read more

October MongoDB Blogroll and Releases

Nov 5 • Posted 1 year ago

Password Authentication with Mongoose (Part 2): Account Locking

Oct 24 • Posted 1 year ago

This post is Part 2 (of 2) on implementing secure username/password authentication for your Mongoose User models. In Part 1 we implemented one-way password encryption and verification using bcrypt. Here in Part 2 we’ll discuss how to prevent brute-force attacks by enforcing a maximum number of failed login attempts. This was originally posted on the DevSmash Blog 

Quick Review

If you haven’t done so already, I recommend you start with reading Part 1. However, if you’re like me and usually gloss over the paragraph text looking for code, here’s what our User model looked like when we left off:

As can be seen, there’s not much too it - we hash passwords before documents are saved to MongoDB, and we provide a basic convenience method for comparing passwords later on.

Why do we Need Account Locking?

While our code from Part 1 is functional, it can definitely be improved upon. Hashing passwords will save your bacon if a hacker gains access to your database, but it does nothing to prevent brute-force attacks against your site’s login form. This is where account locking comes in: after a specific number of failed login attempts, we simply ignore subsequent attempts, thereby putting the kibosh on the brute-force attack.

Unfortunately, this still isn’t perfect. As stated by OWASP:

Password lockout mechanisms have a logical weakness. An attacker that undertakes a large numbers of authentication attempts on known account names can produce a result that locks out entire blocks of application users accounts.

The prescribed solution, then, is to continue to lock accounts when a likely attack is encountered, but then unlock the account after some time has passed. Given that a sensible password policy puts the password search space into the hundreds of trillions (or better), we don’t need to be too worried about allowing another five guesses every couple of hours or so.

Read more

Online MongoDB Classes Start Today

Oct 23 • Posted 1 year ago

A guest post from Andrew Erlichson, 10gen’s VP of Education

Free, Online MongoDB classes start this week and there is still time to join one of the two courses: MongoDB for Developers and MongoDB for DBAs.

I am teaching the developer course along with Richard Kreuter. Richard is a lead consulting engineer and has significant experience with MongoDB users around the world. Dwight Merriman, founder of 10gen and one of the creators of MongoDB, will be teaching the MongoDB for Administrators course.


Right now we over 20,000 registrations for the classes. Lots of folks have contacted us asking what they should expect from these courses, so we thought we’d share some information on what we’re planning. 

Read more

ReactiveMongo for Scala: Unleashing MongoDB Streaming capabilities for Realtime Web

Oct 18 • Posted 1 year ago

This is a guest post by Stéphane Godbillon, software architect at Zenexity _ I am very excited to introduce ReactiveMongo, a brand new Scala driver for MongoDB. More than just yet-another-async-driver, it’s a _reactive driver that allows you to design very scalable applications unleashing MongoDB capabilities like streaming infinite live collections and files for modern Realtime Web applications.

What does reactive mean?

I/O operations may be handled in the following ways: * synchronously: each time a request is sent, the running thread is blocked, waiting for the response to arrive. When the response is received, the execution flow resumes. * asynchronously: the code handling the response may be not run simultaneously (often in a closure). Still, a thread may be blocked, but it may not be the same thread that did the request. * non-blocking: sending a request does not block any thread.

Read more

Planet MongoDB

Oct 17 • Posted 1 year ago

To read up on the most up-to-date blog posts on MongoDB check out Planet MongoDB, a newly-released aggregator of the best blogs on MongoDB. MongoDB community members share tips, ticks and best practices on using MongoDB on a regular basis, and Planet MongoDB will bring that expertise into a single feed.

If you have a blog you would like to see added to the aggregator let us know so we can add you in.

How MongoDB’s Journaling Works

Oct 16 • Posted 1 year ago

This was originally posted to Kristina Chodorow’s blog, Snail in a Turtleneck

I was working on a section on the gooey innards of journaling for The Definitive Guide, but then I realized it’s an implementation detail that most people won’t care about. However, I had all of these nice diagrams just laying around.

image

 Good idea, Patrick! So, how does journaling work? Your disk has your data files and your journal files, which we’ll represent like this:

image

 

Read more

Password Authentication with Mongoose Part 1

Oct 4 • Posted 1 year ago

This post is Part 1 (of 2) on implementing secure username/password authentication for your Mongoose User models, originally posted on Jeremy Martin’s DevSmash Blog. In this first installment, we will discuss how to implement one-way encryption of user passwords with bcrypt, and how to subsequently use the encrypted password for login verification.

Update: Password Authentication with Mongoose (Part 2): Account Locking is now live!

Read more

September Blog, Release and 2.2 Roundup

Oct 2 • Posted 1 year ago

Fast datetimes in MongoDB

Oct 1 • Posted 1 year ago

This was originally posted to Mike Friedman’s blog. Mike is a Perl Evangelist at 10gen, working on the Perl Driver for MongoDB One of the most common complaints about the Perl MongoDB driver is that it tries to be a little too clever. In the current production release of MongoDB.pm (version 0.46.2 as of this writing), all datetime values retrieved by a query are automatically instantiated as DateTime objects. DateTime is a remarkable CPAN distribution. In fact, I would say that DateTime and its related distributions on CPAN comprise one of the best date and time manipulation libraries in any programming language. But that power comes with a cost. The DateTime codebase is large, and instantiating DateTime objects is expensive. The constructor performs a great deal of validation, and creates a large amouunt of metadata which is stored inside the object. Upcoming changes to the Perl MongoDB driver solve this problem. Read more below. If you need to perform a series of complex arithmetic operations with dates, then the cost of DateTime is justified. But frequently, all you want is a simple read-only value that is sufficient for displaying to a user or saving elsewhere. If you are running queries involving a large number of documents, the automatic instantiation of thousands of complex objects becomes barrier to performance.

Read more

How MongoDB makes custom e-commerce easy

Sep 17 • Posted 1 year ago

The market for open source e-commerce software has gone through a lot of stages already, as you might know it by popular platforms like osCommerce, Magento, Zen Cart, PrestaShop, Spree, just to name a few. These platforms are frequently used as a basis for custom e-commerce apps, and they all require a SQL database. Given the inherent challenge in adapting open source software to custom features, it would seem that MongoDB is poised to play an important role in the next wave of e-commerce innovation.

Kyle Banker was one of the first to blog about MongoDB and e-commerce in April 2010, and there’s been surprisingly little written about it since then. In his blog, Kyle writes about Magento and other SQL based platforms: “What you’ll see is a flurry of tables working together to provide a flexible schema on top of a fundamentally inflexible style of database system.”

To this we must ask, why is a flexible schema so important in e-commerce?

Open source platforms are meant to be adapted to many different designs, conversion flows, and business processes. A flexible schema helps by giving developers a way to relate custom data structures to the platform’s existing model. Without a flexible schema, the developer has to get over high hurdles to make a particular feature possible. When the cost of creating and maintaining a custom feature is too high, the options are: give up the feature, start over with a different platform, or build a platform from scratch. That’s an expensive proposition.

There is a better way

For the past year we’ve been developing Forward, a new open source e-commerce platform combined with MongoDB. It’s been in production use since March 2012, and finally reached a point where we can demonstrate the benefits that MongoDB’s schema-less design brings to custom feature development.

The following examples demonstrate Forward’s REST-like ORM conventions, which are only available in the platform itself, but the underlying concepts map directly to MongoDB’s document structure. In this case, think of get() as db.collection.find() — put() as insert/update() — post() as insert() — and delete() as… delete().

Prototype faster

The majority of e-commerce sites represent small businesses, where moving fast can be the most important aspect of a web platform. When the flexible document structure of MongoDB is carried through the platform’s model interface, adding custom fields becomes easier than ever.

For example, let’s say you need a simple administrative view for adding a couple custom attributes to a product. Here’s a basic example for that purpose, written in Forward’s template syntax:

{args $product_id}

{if $request.post}
    {$product = put("/products/$product_id", [
        spec => $params.spec,
        usage => $params.usage
    ])}
    {flash notice="Saved" refresh=true}
{else}
    {$product = get("/products/$product_id")}
{/if}

<for method="post">
    <div class="field">
        <label>Product specification</label>
        <textarea name="spec">{$product.spec|escape}</textarea>
    </div>
    <div class="field">
        <label>Product usage instructions</label>
        <textarea name="usage">{$product.usage|escape}</textarea>
    </div>
    <button type="submit">Save product</button>
</form>

It might be obvious what this template does, but what might be less obvious is that the platform knows nothing about the “spec” or “usage” fields, and yet they are treated as if the e-commerce data model was designed for them. No database migration necessary, just code.

You may argue this can be accomplished with a fuzzy SQL database structure, and you would be correct, but it’s not pretty, or readable with standard database tools. Ad-hoc queries on custom fields would become difficult.

Query on custom fields

If all we needed were custom key/value storage, you might not benefit that much from of a flexible schema. Where MongoDB really shines is in its ability to query on any document field, even embedded documents.

{get $oversized_products from "/products" [
    oversized => true,
    active => true
]}

There are {$oversized_products.count} active oversized products

These fields may or may not be known by the e-commerce API, but in this case MongoDB’s query syntax finds only the documents with matching fields.

No more relational complexity

For those who spent years writing relational SQL queries, this is a big change. How do we create data relationships without joins? There are many different strategies, but Forward defines a field as either a static value or a callback method. This allows a field to return another document or collection based on a query. The result is a data model that can walk through relationships without joins. For example (PHP):

// class Accounts extends AppModel
...
$this->fields => array(
    ...
    'orders' => function ($order) {
        return get("/orders", array('account_id' => $account['id']));
    }
);

This relationship can be used in a template like this:

{get $account from "/accounts/$session.account_id"}

You’ve placed

<table>
    {foreach $account.orders as $order}
        <tr>
            <td>#{$order.id}</td>
            <td>${$order.sub_total}</td>
            <td>${$order.grand_total}</td>
            <td>{$order.items|count} item(s)</td>
        </tr>
    {/foreach}
</table>

Relationships can be defined by simple or complex queries. Results are lazy-loaded, making this example possible:

{get $order from "/orders/123"}

{$order.account.name} placed {$order.account.orders.count} orders since {$order.account.orders.first.date_created|date_format}

// Output: John Smith placed 3 orders since Jun 14, 2012

What about transactions?

Many people bring up MongoDB’s lack of atomic transactions across collections as evidence that it’s not suitable for e-commerce applications. This has not been a significant barrier in our experience so far.

There are other ways to approach data integrity. In systems with low-moderate data contention, optimistic locking is sufficient. We’ll share more details about these strategies as things progress.

In conclusion

The future of e-commerce software looks bright with MongoDB. It’s time to blaze new trails where convoluted schemas, complex relational queries, and hair raising database migrations are a thing of the past. If you’re interested in working with Forward before public release, please consider joining the private beta and help us reinvent open source e-commerce as the world knows it.

A guest post from Eric Ingram, developer/founder @getfwd

blog comments powered by Disqus