In part 1 of this series we had an introduction to indexing in MongoDB. we saw how to create, use, and analyze queries with indexes giving us a good foundation to build on. In this part, we'll take a look at a few more small but important concepts, like indexing on sub-documents and embedded fields, covered queries, and index direction.

They use the same "posts" collection from the previous article, showing you how to index it based on a "location" sub document and "embedded fields" inside of it. They also touch on complex sorting with a multi-field index and the idea of "covered queries." These are queries that all fields queried are part of an index as well as all returned. They finish up the article by showing you how to remove indexes too.

Indexing is one of the more important concepts of working with MongoDB. A proper understanding is critical because indexing can dramatically increase performance and throughput by reducing the number of full documents to be read, thereby increasing the performance of our application. Because indexes can be bit difficult to understand, this two-part series will take a closer look at them.

They look at the default "_id" index, secondary, compound, multikey and multikey compound indexes. Example documents and results are included as well as some of the options that can be set on the index types to tweak performance. They finish up the article with a look at some of the limitations and considerations to think about when using indexing, including that they cannot be used with regex queries.

A few years ago I released a MongoDB library for the CodeIgniter PHP framework which has become quite popular thanks to it's likeness to CodeIgniter's query builder library. I've just spent the last week travelling and to keep myself occupied I spent some time re-architecting the library's code; removing the framework dependancy, making it Composer friendly and adding a full suite of unit tests. Check out the code on Github - https://github.com/alexbilbie/MongoQB.

The library makes it simpler to do most of the usual CRUD (Create, Read, Update, Delete) operations with your Mongo data. Example code is included in the post. This is a nice lightweight alternative to things like the Doctrine query builder.

The last couple of months I have been playing around with elasticsearch, an open source, distributed, RESTful search engine built on top of Apache Lucene. To interact with elasticsearch in PHP I have been using a client called Elastica. This was all fun and games until I needed to do actual queries, which is what our users will be doing most of the time. Elastica's documentation does not (yet) say anything about how to search using the client, so I needed to dig through the code to see if I could find some solutions.

He includes a sample mapping structure and shows how to take both a simple, single-term query and turn it into a request and how to make a more complex request with filters, facets, sorting and a few other things thrown in. He also shows how you can manually create a query (define the JSON structure yourself) and push that into the "query builder" for handling.

Obviously you can already access query parameters today already but it could be easier. Essentially what I want is a way for developers to easily configure what query parameters they expect and what values they expect. This is useful for several things like easier reading and validating of query parameters, self documenting API both for API docs for humans but also for machines.

He's asking for feedback and ideas from the community on a proposed solution that could make things more flexible. He also briefly mentions the route matching and how qurey parameters could cause them not to match:

For one I don't think that a mismatch on a route requirement of a query parameter cause the route to not match. However then it can quickly become confusing for the end user or it would require adding more and more syntax to handle all the different cases.

New in the PHP manual: a quickstart for the mysqlnd query cache plugin. PECL/mysqlnd_qc, the mysqlnd query cache plugin, is transparent and ease to use. But, how? Some pointers have been given in assorted presentations, here on my blog and in some, few examples from the manual. Fixed. You can now browse a quickstart to gain a quick overview.

The query cache plugin can replace the query caching MySQL does and can help with things like multiple storage options (memory, APC, Memcache, etc) and almost no changes to your application. There's also a method (mysqlnd_qc_get_query_trace_log) that comes with the plugin that gives you a "stack trace" of every query run through the MySQL interface.

In my previous article Introduction to MongoDB I discussed installing Mongo, its PHP extension, and how to perform simple insert and find operations. Of course there are many, many more features than what I mentioned so I wanted to write another article to show you some of them.

Other topics mentioned include queries on arrays of data and running queries with indexes to improve their performance. Code is also included for each example.

When running a PHP-based application with MySQL it is often quite interesting to see what actually happens on the database sever. Besides monitoring of the system load etc. it is often interesting to see what queries are actually executed and which of them are expensive. A part of MySQL Enterprise Monitor is the MySQL Query Analyzer which helps answering these questions.

This was handled via a proxy that sat between the database and app server and ran through the queries looking for improvements. This new plugin keeps it closer to PHP itself without having to hit against the proxy. You can see the result in these two screenshots from inside the Manager application. You also have the side benefit of getting a stack trace of it running through the app to help you identify the spots most needing improvement in the code too.

I've been working with the Basecamp API to plugin our IRC bot that we use for time tracking and I'm astounded to learn that escaping single and/or double quotes for XPath queries in PHP does not have a well documented, best practices solution. In fact, it seems as though this is not peculiar to PHP. I took a look around and found this excellent article by "Kushal": http://kushalm.com/the-perils-of-xpath-expressions-specifically-escaping-quotes.

He's put together his own (PHP) solution to the problem - running the entire XPath query through a filtering method that splits it up, replaces the quote characters and combines it back down to a single string.

Quite a while ago I looked at using the filter_var() function to validate URL's using the FILTER_VALIDATE_URL flag and someone pointed out recently that this function has not only changed since the initial release, but that a number of flags can be added to change the way that this function works.

He lists some of the other flags that are now available that can be used in conjunction with FILTER_VALIDATE_URL to get more fine-grained in your filtering - checks on things like a required scheme, hostname and query string. He includes some code with a set of URLs to run through some tests and output as a table with the pass/fail rank of each URL value. You can see the resulting output here.