Training Guide - GPARTS EU Profit Analyzer

The Ford GPARTS Profit Analyzer (PA) is a tool that the FCSD business uses for analyzing revenue and profitability of the different product lines and also for identifying profitability and pricing improvement opportunities. This document is an extensive training reference for the Profit Analyzer. This document is written for pricing analysts, pricing managers, and any business user who conducts or engages in analytical pricing processes through use of the Profit Analyzer. It explains how the Profit Analyzer module helps analysts rapidly identify margin improvement opportunities, the distinctive features of system, and the instructions to use these features.

First, Do No Harm: Four Things You Should Never Do with Elasticsearch

Here's a twist on the old adage: A ounce of prevention is worth a kiloton of user satisfaction. It's no secret that we're big fans of Elasticsearch. But we've seen more than a few customers crash their clusters—in a variety of ways. Most of those failures are quite preventable. It's often a matter of a simple misunderstanding, and the remedy is usually fairly easy to apply. As we did in our recent article on field data, we invite you to think through a number of other potential problems. With little effort, you can apply several key practices that will improve stability and improve performance for your ES cluster.

Announcing Replicated Elasticsearch Clusters on AWS

It will always remain important for us to offer the standard cluster type to accommodate users who are running write-heavy configurations. As we consider our own experience and that of our customers, however, it's become crystal clear that most users add nodes because they need to improve performance and throughput. So, from now on, users who run read-intensive apps against Elasticsearch have the option for a convenient, high-performance, highly resilient solution: replicated clusters. With automatic shard replication on a three-node cluster—along with click-to-increment additional replicas—you get extremely high-availability and blistering read-intensive search performance.

Parent-Child Relationships in Elasticsearch

Have you ever spent some time grappling with indexing, querying, or aggregating when dealing with an existing parent/child relationship? Maybe you've tried to cope with translating foreign key relationships or simulating database joins in Elasticsearch. We frequently hear about these issues here at Qbox, and many of our staff have lent a hand to developers who need to update elements of a list property—or nested property—without updating the entire document. We've come to realize that many developers are unaware of the parent-child construct, the native capability that is already present in Elasticsearch. It gives you the ability to: - Update the parent document without reindexing the children. - Get child documents in search request results. - Add, change, or delete child documents without affecting the parent—or other children. This is especially useful for large collections of child documents that require frequent changes.

Load Balancing Elasticsearch Clusters

Load balancing an Elasticsearch cluster is a good practice because a primary goal in ES configuration is a fault-tolerant system that's resilient to single node failures. All of us here at Qbox know that the load-balancing features of Elasticsearch are a big part of what makes it such a great distributed computing platform. We also know that you'll get the best performance when you take a bit more time to properly size your Elasticsearch cluster and optimize your computing resources to correspond well with your expected load. In this article, we bring to mind some considerations that can help you optimize your cluster by improving distribution, performance, and reliability. We're also aware that various notions about "load balancing" are heard throughout the community, so we also explore various meanings and applications of load balancing with respect to ES clusters.