If you've been reading our documentation, chances are you've already learned a bit about New Relic and the many tools and capabilities we offer.
We're very proud of the utility and design of our dashboards, alerts, and versatile programmability, but none of it would be possible without the computing power needed to make it all run smoothly.
Just like a finely calibrated race car, what you see on the outside may be the most exciting features, and these are the parts you interact with to “drive.” But without an engine designed to win, elegant instrument panels, a responsive clutch, and a great paint job won't get you anywhere.
Under the hood of New Relic lies the engine powering it all: the New Relic Database (NRDB). In this resource, we explain how NRDB helps you succeed in your observability goals.
Billions of data points per minute
New Relic ingests billions of telemetry data points every minute, serving more than 180,000 accounts simultaneously.
To run such a high-volume platform, the underlying database and query capabilities need to be fast, flexible, and scalable. They must also be equally effective for organizations of all sizes, supporting a wide spectrum of telemetry needs and business goals.
NRDB provides the power, speed, and scalability you need to monitor your performance across your entire landscape quickly and effectively.
Scale, purpose, and equal access to resources
To meet the challenging demands for speed, efficiency, scalability, and reliability, we built NRDB with three key objectives.
- Unlimited scalability: Hosted in the cloud, NRDB's distributed architecture has the capacity for virtually unlimited scale.
- Monitoring and analysis: With this dual purpose in mind, NRDB handles operational monitoring and data analytics equally well. This means that NRDB can ingest massive amounts of data while also giving you real-time alerting, lightning-fast queries, and charting — all without sacrificing speed.
- Resources when you need them: As a multi-tenant system supporting tens of thousands of customers, NRDB gives you the resources you need when you need them (which single-tenant systems cannot match).
The lifecycle of a query
NRDB returns results for queries of all sizes astonishingly fast. To do this, we use parallel processing at massive scale. This architectural approach is equally effective for accelerating a single large query and for allowing numerous users to run small queries simultaneously without impacting speed.
It works like this:
- A user enters a query using one of our tools, such as the query builder, or a dashboard or other type of instrumentation sends an automated query.
- NRDB starts by sending the query to a router, which in turn sends the query components to hundreds or even thousands of query workers.
- The query workers find the data, and the process is repeated in reverse, with data returning to populate dashboards, create alerts, or answer discrete queries, among other things.
This process yields complete query results in a fraction of the time that other methods would require. To further improve efficiency, NRDB also caches recent queries, allowing it to send those results back to users nearly instantaneously.
The result: flexibility, speed, accuracy, and efficiency
How big is the difference? Because of NRDB's raw power and purposeful design, New Relic's telemetry products are able to analyze tens of billions of events per second while maintaining a median query response time of 45 milliseconds. We would say, “Your query results are just a heartbeat away,” but mathematically that's more like a tenth of a heartbeat (unless you're a mouse).
What do these statistics mean for our customers? At the end of the day, NRDB's speed and unique capabilities enable you to identify, analyze, and fix performance problems much faster, reducing downtime so you can get back to business.
To start reporting data to New Relic, see Install New Relic.
If you need to report data that our agents and integrations don't provide, we have tools that help you bring in any type of data you need. To learn more, see Intro to custom and third-party data.
Want to know more? Here are some recommendations: