Archive Digger: Love is in the Air…and in the Vault!

The Vault™ is a web-based tool that provides Perfect Market publishers with full access to and control over all their content that is optimized, served, and/or packaged by Perfect Market. We consider The Vault™ to be the face of everything Perfect Market.

Each month, our friend ArchiveDigger goes through the Vault™ to find top-performing articles around a relevant subject. To celebrate Valentine’s Day, ArchiveDigger has “dug up” some interesting articles related to love and romance from our Vault™ archives:

Handmade Valentine’s Day gifts are from the heart- Baltimore Sun

Scam Watch: consumers conned by would-be lovers - LA Times

Valentine ideas for long distance lovers - Times of India

Top 20 Valentine songs of Bollywood - Times Of India

Sexy foods that put you in the mood - CNN

10 great places to pop the question - Chicago Tribune

Just Saying No To the Dating Industry - NY Times

An unforgettable valentine - Philadelphia Inquirer

In time for Valentine’s Day, four books about love - Boston Globe

Who picks up the check on Valentine’s Day? - NY Daily News

By ArchiveDigger

Perfect Market Celebrates the Year of the Dragon

Perfect Market recently had our Chinese New Year’s celebration here at Perfect Market to honor Year of the Black Water Dragon. We are particularly excited about the Year of the Dragon because the we feel that Perfect Market has a lot in common with the Dragon:

1. The Dragon is the mightiest of the signs.

2. Dragons are driven, unafraid of challenges, free thinking and willing to take risks.

3. Dragons are passionate in all they do.

4. Dragons can always be trusted. If you engage in a financial transaction with a Dragon, rest

assured it will be above-board and honest.

5. Dragons are gifted with innate courage, tenacity and intelligence.

Every day, I am amazed at what our team accomplishes and the obstacles we overcome. The drive and passion that each and every person of our A Team brings to each project is truly amazing. I feel lucky to be able to come to work with such creative and intelligent co-workers. Being a part of Perfect Market is a great way to honor the Year of the Dragon.

“Everybody knows who dragons are. They are intelligent and educated creatures who lead enthralling lives.”~ H.G. Ciruelo Cabral

By Kim Muller, Executive Assistant at Perfect Market

NoSQL Comes of Age: Why Perfect Market Likes MongoDB and Why You Should, Too

No SQL databases are no longer a joke, shrouded in the corner of hype terms and prototype implementers. More specifically, MongoDB is one such NoSQL database leading the way; by moving from the hobbyist space to running production systems for the world’s largest infrastructures. This year at the MongoDB 2012 conference in Los Angeles, the Perfect Market engineers got the run down on what’s new, what’s coming and how it’s being used today. If you haven’t yet evaluated a NoSQL database solution to solve performance and scaling problems of your current infrastructure, now is the time.

Note: For more great insights into the NoSQL solution, check out “NoSQL Solution: Evaluation and Comparison: MongoDB vs Redis, Tokyo Cabinet and Berkeley DB” where Perfect Market’s Jun Xu compared NoSQL solutions to find the best one to fit our requirements for high speed reads/writes and scaling.

Why NoSQL?

If you’re new to MongoDB and have only used Relational Databases such as MySQL, Postgress, Oracle or Microsoft SQL Server in the past, then this will be a big paradigm shift for you. First and foremost NoSQL databases aren’t a direct replacement for relational databases. They fill a gap by replacing the common need for a high performance data store that would often require many slow joins and a caching layer such as memcache to implement on a typical relational database. With NoSQL databases, you won’t find a schema conversion tool because that would be missing the point. Instead, the idea is to store data in a de-normalized fashion all-together in what MongoDB refers to as “Documents,” which are full JSON data structures. These “Documents” are stored in “Collections” which are formally known as tables to relational databases. MongoDB provides all the useful functionality to insert, update and search for these JSON Documents by using JSON itself in a very flexible manner. These “Collections” are then stored in memory along with any indexes created for performance, usually greatly surpassing the performance of relational databases.

In MongoDB there are no joins, no transactions, no schema and yeah, you guessed it, no SQL:

No Joins: Since there are no joins, you won’t have a performance penalty for piecing together normalized data like you do in a typical relational database when serving to clients. De-normalized schema design (aka best practice in designing your Document JSON structure) allows you to keep all the data you need in one collection, thus no joins are required. That statement right there probably makes you shudder when thinking back to the days of database design class where you were penalized for not normalizing your schema design correctly, but there’s a very good reason. The benefit here is performance. No joins means higher performance which is one of the biggest reasons to use MongoDB over conventional relational databases. (Note: This does not mean you cannot join data. In Mongo, the concept is referred to as “linking.” In reality, this is just the best practice of adding a value in your dataset (aka a foreign key) and then handling the lookups at your program level using a find query with indexes.)

No Transactions: Mongo provides necessary indexing routines that are similar to relational databases. It even self-evaluates which index is faster in a learning process so that when you look up a Document in a Collection, it will be backed by the right index and lookups are speedy. Embedding is another way to solve this problem by taking data that is normally joined and embedding it in its parent document to form just one document. Performance is increased because a query can return back a single document that encapsulates all data versus having to do several joins. We can see this in the schema example above of a traditional relational database of comment posts on a blog, which would require 3 joins for users, blogs and comments to produce the output. When compared the similiar simple example of a MongoDB document would encapsulate the entire data required with a single fetch. However the con to this approach is if there are fields of data that need to be updated at some point (i.e. an author name on a comment), then a scan or index lookup and replace on all documents would be required. Depending on the likelihood of updates such as this, taking this approach may be beneficial for the performance benefit alone.

No Schema: Mongo has no concept of a schema. In other words, it has dynamic schema. What this means is that whatever you save as the JSON structure in your Document is going to be your schema. It’s not locked in or enforced, and it does not require extensive altering commands to upgrade when new fields (relational database columns) are required. Instead, you can just start including or excluding data in a de-normalized fashion during saves on an as needed basis. When we compare the relational database schema to the MongoDB document example above, we can see that at any point, new fields can be added to the JSON document (i.e. a commenter’s email address), whereas tradtional relational databases require you to issue an alter command and migrate older recorders over. Obviously, this does mean you will have to take proper care in checking for certain data back from Mongo while coding for example when you decide to add those extra flag fields to your user collection. But it means incredible flexibility. Once again it is important to design your document model around your queries to optimize the usefulness of Mongo.

New Features Available Today

MongoDB just released version 2.0 (formerly known as v1.10) with some new improvements under the hood that I’d like to highlight:

1. For performance there are increases in concurrency throughput thanks to yielding around page faults. (Note: This is scheduled to be enhanced even further in 2.2.)

2. Journaling has been enabled by default on 64bit setups and compression now yields for faster commits to disk.

3. MapReduce performance is about 2x faster over version 1.8 thanks to integration of V8 JavaScript engine over SpiderMonkey.

4. For those close to reaching their hardware RAM limits, upgrading to version 2 will save you 25% in index sizes thanks to the indexes B-Tree compression. Some users will even see 25% improvement in performance for indexes, we are told. But we were also warned that you are not able to migrate back so it’s a one way upgrade. Some new cool geospatial features include multi-location documents and polygon searches for those storing location information.

For a complete list of new features and performance enhancements, click here.

Coming Soon

While at the conference we had some insights into what’s also coming down the line for MongoDB. One of their new features, an Aggregation framework that let you perform aggregation functions on collections will be introduced shortly. This will fill the gap for those accustomed to being able to perform group by sums and averages using straight sql on a relational database. Instead of utilizing JavaScript like their MapReduce functionality, it is based on straight declaration and powered by a C++ implementation for higher performance. The aggregation framework will support pipelining, a common fundamental feature that UNIX users are used to where data is handled in series with a chain of commands. Some examples of operations will include grouping (min/max/sum/avg), sorting, limiting, skipping and date arithmetic. In the meantime, check out Pentaho’s “Kettle” which is a ETL tool that can extract data from MongoDB and perform similar aggregation tasks.

Mongo is also working on full text search, which will make its way out the door within the year or so. No word yet on exactly when, but we can probably expect to here more about it in the upcoming months. Although, we all know, search is never perfect. In the meantime, those performing full text searching would have to bolt on a Solr implementation or other third party tool, or just build search indexes on your own using MongoDB as the inverted index data store.

MongoDB 2012 Los Angeles

The MongoDB 2012 Los Angeles conference showed us that not just one industry vertical or niche of companies is utilizing MongoDB, but that it’s a vast and diverse group. We met developers from major online ticket retailers, global text message platforms and even providers of extremely high traffic web sites all looking to jump onto or already on the Mongo ship. MongoDB takes NoSQL to a new level by solving fundamental problems and simplifying deployments, which makes it highly attractive for many different types of implementations. For example, some people just use MongoDB as a replacement to memcache, while others design their entire stack around it. The general attitude at the conference was it’s here, it’s now and it’s ready. For many of the users we talked to it made sense to incorporate MongoDB in their web stacks in a hybrid relational model where data accessed infrequently and by adhoc tools that require more flexibility (like BI) sticks to the relational side, and data that can be normalized and served at high speed is put into MongoDB. It’s obvious MongoDB has picked up steam and without question will be one of the fundamental building blocks for highly scalable application stacks in the near future much like MySQL.

But There’s Still Room For Improvement…

Although we are optimistic about the future of MongoDB, there are fundamentals that MongoDB could improve upon. Here’s what world-renowned NoSQL database authority Jun Xu, a colleague of mine at Perfect Market had to say:

From our experience of using MongoDB we can emphasize the features we are looking for: (More hands indicates more importance to Perfect Market.)

1.  More granular locking. This probably is not a big deal for read-heavy applications, but it will provide huge performance improvement for applications that are both read- and write -heavy. I think that the global locking mechanism is by far our biggest concern in using MongoDB. They said that a more granular locking mechanism will be implemented in the 2.2 release, and I hope that they will follow through on their word. For our applications, it does not really matter that much whether Mongo adds more high-level features in future releases, but more granular locking is a fundamental feature in database software, so it does matter. We look forward to MongoDB releasing this feature.

2.  Make data smaller without sacrificing performance. Using the 1.8 version, we feel that the mapped memory is more than what we expected due to the amount of information we save in MongoDB. In 2.0, indexes can be compressed, which reduces memory footprint by 25%. This is a great move!

3.  TTL collection. They promised this feature will be included in the 2.2 release. TTL collection will be a very useful feature for many web applications. If they can implement this right, (e.g., no data fragmentation or no performance degradation over time) this would be a great new feature, as well.

For a NoSQL database to be successful, it needs to focus on the fundamentals of NoSQL databases, which are performance (extremely important), scalability and stability. The richness of primary operations is also important, but other higher level features, like more advanced query language and framework support, are definitely less important. Without performance and scalability, nobody would even consider NoSQL databases.

By Chris Germano, Principal Software Engineer at Perfect Market, with Jun Xu, Principal Software Engineer at Perfect Market

Simplifying the Display Ad LUMAscape

Terry Kawaja’s LUMAscape attempted to map the infrastructure of companies participating in the space between Marketers and Publishers. Perfect Market CEO Julie Schoenfeld presents a simplified version of the LUMAscape by focusing on the 6 major functions involved in the display ad value chain. Watch the video to learn more about these functions and how this perspective explains the strategies of leading Internet companies such as Google, Yahoo!, Microsoft, AOL and Facebook.

Simplifying the Display Ad LUMAscape

Source: perfectmarket.com

Google Search Plus your [Favorite Author]

If you’ve followed any tech news outlets this week, you’ve probably seen that Google released a new product called Search, Plus Your World. If you haven’t seen it yet, the short version is that Google began mixing more pages into your search results that were shared (or +1’ed) by people you’re connected with.  Google has shown some customized results for years, but they were the exception rather than the rule – the majority of search results were picked by the almighty Algorithm. 

The media response has been fairly caustic, with fingers being pointed at everything from privacy complaints to the foretelling of antitrust investigations.  Two of the more salient objections to this product seem to be:

•  Danny Sullivan over at searchengineland.com seemed most concerned that Google+ suggests people to follow on Google+ for a variety of searches, even when it’s not clear that a user is even looking for a person.  This feature is pretty aggressive – you can see in this screenshot that the Google+ information for our CEO Julie Schoenfeld pops up for me even before I finish typing her first name:

Perfect Market CEO Julie Schoenfeld

•  Techcrunch seems to have really locked onto the Google+ vs Twitter battle, covering several different angles of the fact that Google+ results are included but tweets aren’t.  A twitter employee (a former Googler, no less) even jumped into the fray, youguessed it, with a tweet:

I think it’s fair to say that there haven’t been a ton of positive posts about the change, and there may end up being something to all of these concerns.  Googler Matt Cutts, however, showed some example searches that had very useful social results, and I can see some features (like the social image search) being really useful.  It’s still too early to see how this feature will turn out, but I’m really excited for one aspect that is particularly important for news publishers: 

This change will further promote individual authors and publishers of news articles rather than just the Title/URL combo usually seen in search results.  Authors who really connect with their online audience and work to build out their network are going to be rewarded – not just in the passive consumption like twitter and RSS feeds, but in active consumption modes like search!

You’ll still be able to be able to follow publications and news sources like you have been, and the effects of doing so increase every day, but I’m really excited to see individual bloggers and authors highlighted in the same way!

If you haven’t implemented Google+ buttons on your site or hooked up your author bio page with your Google+ account, now’s the time.  Don’t worry if you don’t see an immediate traffic firehose – it took a while for Twitter to really catch on and drive traffic as well.  While you’re at it, go ahead and add the Perfect Market Google+ account to one of your circles so you can see more posts like this in your search results.

- Chris Muller, Advisor at Perfect Market

Source: perfectmarket.com