
<p>Here at Sisense, we love a challenge, so when a client comes to us and tells us they need to find a way to run queries on billions of records without this slowing them down, our ears perk up and we leap at the chance to find a solution.</p>



<p>In fact, that’s how we recently found ourselves <a href="https://support.sisense.com/hc/en-us/articles/115007184947-Sisense-Performance-A-Billion-Records-in-a-Single-Server">testing a billion transactional records and three million dimensional records</a> &#8211; totaling a whopping 500GB of data – with 100 concurrent users and up to 38 concurrent queries, with a total setup time of just two hours… <i>and an average query time of 0.1 seconds!</i></p>



<p>But wait! I’m getting ahead of myself. Let’s start by talking through some of the issues that affect how fast you can query data.</p>



<h2>How Are You Storing Your Data?</h2>



<h3>Let’s start with the obvious: data warehousing.</h3>



<p>Typically, working with masses of data means you also need <a href="https://www.sisense.com/blog/demystifying-data-warehouses-data-lakes-data-marts/">extensive data warehousing in place to handle it</a>, alongside Extract-Transform-Load tools that uploads data from the original source on a regular basis (Extract), adjusts formats and resolve conflicts to make the datasets compatible (Transform), and then delivers all of this data into the analytical repository where it’s ready for you to run queries, calculations, and trend analysis (Load).</p>



<p>This creates a single version of the truth – a source of data that brings together all your disparate pieces into one place. While this is great, there are also some drawbacks to data warehousing.</p>



<p>First of all, data warehouses are highly structured, and the row-and-column schema can be overly restrictive for some forms of data. Also, the sheer volume of data quickly overloads most systems, grinding to a halt if you run queries that attempt to tap into the entire data pool.</p>



<h3>Then, there are data marts.</h3>



<p>To help tackle the issues that come with working with huge data sets, many IT teams deploy data marts alongside their databases. These essentially siphon off access to a smaller chunk of the data – and then you select which data marts each department or user has access to. The outcome of this is that you put less pressure on your hardware, as your computer is tapping into smaller pools of data, but the flipside is that you have vastly reduced access to the organization’s total data assets in the first place.</p>



<h3>At the other end of the scale, you have data lakes.<p></p>
</h3>



<p>These are used to store massive amounts of unstructured data, helping to bypass some of the issues that come with using conventional data warehouses. They also make sandboxing easier, allowing you to try out different data models and transformations before you settle on a final schema for your data warehouse – to avoid getting trapped into something that doesn’t work for you.</p>



<p>The trouble with data lakes is that, while the offer formidable capacity for storing data, you do need to have all kinds of tools in place to interface between the data lake and your data warehouse, or with your end data analytics tool if you want to skip the need for warehousing on top. Systems like this that use data lakes aren’t exactly agile, so your IT team will need to be pretty heavily involved in order to extract the insights you want.</p>



<p>Alternatively, you might deal with unstructured data using an unconventional data storage option.</p>



<h3>For example, you might use a NoSQL database like MongoDB.<p></p>
</h3>



<p><a href="https://www.sisense.com/whitepapers/streamline-your-data-project-with-mongodb-and-sisense/">This gives you tons of freedom</a> in terms of the kind of data you add and store, and the way that you choose to store it. MongoDB also makes use of sharding techniques to avoid piling the pressure on your IT infrastructure, allowing for (pretty much) infinite scaling.</p>



<p>The downside, of course, is that the thing that makes this so great – the unstructured, NoSQL architecture – also makes it tricky to feed this data straight into a reporting tool or analytics platform. You need a way to clean up and reconcile the data first.</p>



<h2>What About Tools Used for Analysis?</h2>



<h3>Dynamic DBMS tools like PostgreSQL can open doors.<p></p>
</h3>



<p><a href="https://www.sisense.com/blog/decide-postgresql-reporting-right/">PostgreSQL is an analytics and reporting tool that allows you to work with an enormous variety of data types</a> – including native data types that give you much more freedom as you come to build and manipulate a BI solution, and “array” types, which help you to aggregate query results rapidly on an ad hoc basis.</p>



<p>Introducing PostgreSQL into the mix can be massively helpful in bringing together your disparate strands – but again, it can’t do everything. It can’t help much with qualitative data, and as a non-<a href="/glossary/relational-database/">relational database</a> (which wasn’t built to handle Big Data) it will buckle under huge volumes of information.</p>



<h3>You can also use R for high end predictive analytics.<p></p>
</h3>



<p>Lastly, once you have a solid BI system in place, you can add another layer of awesomeness by <a href="https://www.sisense.com/blog/supercharge-business-analytics-using-r/">using R to build working models for statistical analysis</a>, quickly and easily. R is incredibly versatile, and allows you to move away from static reporting by programming a system for analysis that you can adapt and improve as you go.</p>



<p>The thing is, though, this is an add-on: it doesn’t replace your current BI or data analytics system. R is an excellent programming language that can help you generate predictive analytics fast, but you need to have a rock-solid system in place for handling and preparing data in the first place.</p>



<h2>How to Streamline Everything</h2>



<p>I know what you’re thinking: I said I was going to explain how to streamline your data queries to help you generate results faster, but so far, all I’ve done is dangle some potential solutions and then show you how they fall short!</p>



<p>That’s because I haven’t revealed the secret sauce that binds all these pieces together in perfect harmony.</p>



<p>As you can see, each of the tools we’ve discussed are used to fix one problem in the storage, flow and use of data within your organization, but they don’t help with the big picture.</p>



<h3>That’s where Sisense’s Elasticube comes in.</h3>



<p>The <a href="https://documentation.sisense.com/latest/managing-data/ElastiCubeManager.htm">Elasticube allows you to store data or drag it in directly from your existing stores</a> at lightning speed, giving users unfettered access to their entire pool of data, whatever format it’s kept in (unless you choose to stagger permissions). Thanks to clever use of <a href="https://www.sisense.com/product/mash-up/elasticube/">In-Chip Processing</a> and a <a href="https://www.sisense.com/blog/leveraging-cpu-cache-columnar-storage-high-speed-bi/">Columnar Database structure</a>, you tap into only the data you need for the query, without restricting yourself permanently, as you would with a data mart.</p>



<p>You can then reconcile and harmonize this data with minimal hassle to treat all these strands as a single data source for the purpose of analysis and reporting.</p>



<p>Still within the Elasticube, you can map and manipulate these data sources to build your own dashboards and run your own queries at incredible speed.</p>



<p>Plus, using our range of custom-built connectors, you can link your Sisense Elasticube directly to MongoDB, PostgreSQL and other DMBS tools, <i>and</i> you can integrate Sisense with R for even more in-depth predictive analytics.</p>



<h3>Where the Magic Happens</h3>



<p>So that’s the big secret. Using the Sisense Elasticube, I was able to set up a system in 120 minutes that could run concurrent queries on data representing one billion online purchases, from three million origins/ destinations, with an average query time of 0.1 seconds and a maximum query time of just 3 seconds.</p>



<p>Pretty impressive, huh? Here’s what it looked like:</p>



<div class="wp-block-image"><figure class="aligncenter"><img src="https://cdn.sisense.com/wp-content/uploads/Sisense_performance_4-770x415.png" alt="Elasticube"/></figure></div>



<p>And here’s an example dashboard that we used to display the results in real time:</p>



<div class="wp-block-image"><figure class="aligncenter"><img src="https://cdn.sisense.com/wp-content/uploads/Sisense_performance_5-770x401.png" alt="Dashboard"/></figure></div>



<p>How’s that for streamlined?</p>



<p><strong><i>Want to see exactly how I built this super-streamlined query model for yourself? <a href="https://support.sisense.com/hc/en-us/articles/115007184947-Sisense-Performance-A-Billion-Records-in-a-Single-Server">Click here for the detailed tutorial.</a></i></strong><strong><i>
</i></strong></p>



<i></i>


How to Streamline Query Times to Handle Billions of Records

curve-image-unique-image-unique