Author

Eric Hanson

Director of Product Management

The Power of SQL for Vector Database Operations, Part 1

Here’s how to use one SQL query to get the top K vector matches in each category.At SingleStore, our position on vector database processing is that you should have all the benefits of a modern, full-featured DBMS available to you when working with vectors [Han23]. This includes full SQL support.We're working with a prospective user of SingleStoreDB for vector database operations related to an application with a semantic search component. He asked how we could do the following easily: find the top K items in each category. This is something he didn't have an easy time with in Milvus, a specialty vector database.With Milvus, he was finding the categories in one query, looping through them and finding the top K elements for one category at a time with a separate query. This is not easily parallelizable, and requires more work from the application side than many would prefer.Here's how you can do this in a single SQL query in SingleStoreDB:/* Make some items in multiple categories, with associated vector embeddings. */create table items(id int, category varchar(50), vector blob);insert into items values (1, "food", json_array_pack('[0,0,0,1]')), (2, "food", json_array_pack('[0,0.5,0.3,0.05]')), (3, "food", json_array_pack('[0,0.5,0.2,0]')), (4, "facilities", json_array_pack('[0,0,1,0]')), (5, "facilities", json_array_pack('[0,0.6,0.1,0.05]')), (6, "facilities", json_array_pack('[0,0.4,0.3,0]'));-- query vectorset @qv = json_array_pack('[0,0.4,0.3,0]');-- get top 2 in each category using rankingwith scored as( select id, category, dot_product(vector, @qv) as score from items),ranked as (select row_number() over(partition by category order by score desc) as rank, * from scored)select *from rankedwhere rank &lt;= 2order by category, rank;These are the results:+------+------+------------+---------------------+| rank | id | category | score |+------+------+------------+---------------------+| 1 | 4 | facilities | 0.30000001192092896 || 2 | 5 | facilities | 0.27000001072883606 || 1 | 2 | food | 0.2900000214576721 || 2 | 3 | food | 0.25999999046325684 |+------+------+------------+---------------------+It’s important to note we're just focusing on ease of expression here, not performance. For this particular application, the scope is usually a few million vectors at most — so a full-scan, exact-nearest-neighbor approach is plenty fast.When you choose a tool for vector processing for nearest-neighbor search applications like semantic search, chatbots, other LLM applications, face matching, object matching and more, we think it's a good idea to consider the power of the query language — and having full SQL available just makes things easier.References[Han23] E. Hanson and A. Comet, Why Your Vector Database Should Not be a Vector Database, SingleStoreDB blog, April 24, 2023.Explore more vector database-related resourcesSingleStoreDB VectorseBook: Selecting the Optimal Database for Generative AI

Read Post

Product

Why Your Vector Database Should Not be a Vector Database

The database market is seeing a proliferation of specialty vector databases.People who buy these products and plumb them into their data architectures may find initial excitement with what they can do with them to query for vector similarity. But eventually, they will regret bringing yet another component into their application environment.Vectors and vector search are a data type and query processing approach, not a foundation for a new way of processing data. Using a specialty vector database (SVDB) will lead to the usual problems we see (and solve) again and again with our customers who use multiple specialty systems: redundant data, excessive data movement, lack of agreement on data values among distributed components, extra labor expense for specialized skills, extra licensing costs, limited query language power, programmability and extensibility, limited tool integration, and poor data integrity and availability compared with a true DBMS.Instead of using a SVDB, we believe that application developers using vector similarity search will be better served by building their applications on a general, modern data platform that meets all their database requirements, not just one. SingleStoreDB is such a platform.SingleStoreDBSingleStoreDB is a high-performance, scalable, modern SQL DBMS and cloud service that supports multiple data models including structured data, semi-structured data based on JSON, time-series, full text, spatial, key-value and vector data. Our vector database subsystem, first made available in 2017 and subsequently enhanced, allows extremely fast nearest-neighbor search to find objects that are semantically similar, easily using SQL. Moreover, so-called "metadata filtering" (which is billed as a virtue by SVDB providers) is available in SingleStoreDB in far more powerful and general form than they provide — simply by using SQL filters, joins and all other SQL capabilities.The beauty of SingleStoreDB for vector database management is that it excels at vector-based operations and it is truly a modern database management system. It has all the benefits one expects from a DBMS including ANSI SQL, ACID transactions, high availability, disaster recovery, point-in-time recovery, programmability, extensibility and more. Plus, it is fast and scalable, supporting both high-performance transaction processing and analytics in one distributed system.SingleStoreDB Support for VectorsSingleStoreDB supports vectors and vector similarity search using dot_product (for cosine similarity) and euclidean_distance functions. These functions are used by our customers for applications including face recognition, visual product photo1 search and text-based semantic search [Aur23]. With the explosion of generative AI technology, these capabilities form a firm foundation for text-based AI chatbots.The SingleStore vector database engine implements vector similarity matching extremely efficiently using Intel SIMD instructions.

Read Post

SingleStore Recognized In

[r]evolution Summer 2022: Bring Application Logic to Your Data With SingleStoreDB Code Engine for Wasm

SingleStoreDB Cloud now supports user-defined functions written in C, C++ and Rust with our new Code Engine — Powered by Wasm. Application developers can now use libraries of existing code, or code from their applications, in database functions and call them from SQL. That can tremendously reduce the need to move data from the database to the application to analyze it, speeding things up and simplifying development. We illustrate the power of Code Engine for Wasm with a story about a developer who finds a new way to create an important sentiment analysis report — easier and faster. You're an application developer for an eCommerce company, and you've been asked several times to produce reports that do sentiment analysis on the review comments for products your company has sold. It is getting mighty tedious because your sentiment analysis code lives in a Rust program, so every report requires you to export data to the app and score it there. Then, you have to write query processing-style logic in your app to create the report. It's honestly kind of fun, but you — and your boss — think your time would be better spent elsewhere. That's when you learn from your DBA that your database, SingleStoreDB, has a new feature called Code Engine — Powered by Wasm that lets you extend the database engine with user-defined functions (UDFs) in C, C++ or Rust, and other languages soon. It dawns on you that you can take the sentiment analysis code from your application and move it into the database as a Wasm UDF. That means those reports people have been asking for can be created using a pretty straightforward SQL SELECT statement. Better yet, you can teach the analysts to write the queries themselves. Then, you don't even need to hear about it! We'll hear more of this story later!

Read Post

Product

Toys for Developers in SingleStoreDB: Spring 2022 Release

I used to pump gas at a Shell station in Oregon, where they still fill your tank for you. I patched the occasional tire and changed some belts and hoses too, taught by two great mechanics who could fix anything. Those guys were pros — tough and skillful men. But there was one thing that always turned them into little kids: the arrival of the Snap-on tool truck — the mechanics' toy store on wheels! You database application developers are makers and fixers too. You're grown up. But what grown-up builder doesn't like their toys? We're proud to announce the arrival of the SingleStoreDB tool truck for Spring 2022!

Read Post

Product

Flexible Parallelism in SingleStoreDB

Veteran SingleStoreDB users take our elasticity for granted. SingleStoreDB is a true distributed database. It's easy to scale up, so you can handle increasing demands to process queries concurrently — for both transactions and analytics. Many application developers are still using single-box database systems and sharding data manually at the application level. That's not necessary with SingleStoreDB, which can save you many person-years of development time — letting you focus on the app, and not the data platform. Although we can stretch and grow with your workload, we're pushing to make our elastic scale easier and more powerful. With the latest release of SingleStoreDB, we've taken a big step toward our ultimate goal of transparent elasticity with our flexible parallelism (FP) feature. FP is the premier feature in this release, and is part of our long-term strategy to make SingleStoreDB the ultimate elastic relational database for modern, data-intensive applications. Flexible parallelism SingleStoreDB uses a partitioned storage model. Every database has a fixed number of partitions, defined when you create the database. Historically, SingleStoreDB has done parallel query processing with one thread per partition. This works great when you have an appropriate partitioning level compared to the number of cores, such as one core for every one or two partitions. With prior releases, when you scaled up, you couldn't use the extra cores to run one query faster. You could only benefit from them by running more queries concurrently. FP changes that. Flexible parallelism works by internally adding a sub-partition id to each columnstore table row. Then, query execution decides a set of sub-partitions for each thread to scan on the fly. The use of sub-partitions allows shard key matching queries to work. To make this efficient, the sub-partition id is added internally to the beginning of the sort key.

Read Post

Engineering

Table Range Partitioning Is a Crutch. Here’s Why SingleStore Doesn’t Need It

While antiquated legacy databases rely on table range partitioning to manage data lifecycles, modern databases built for data-intensive applications — like SingleStore — have functionalities that eliminate the need for unnecessary, outdated processes (like range partitioning).Table range partitioning is a crutch that legacy databases use to help them handle the lifecycle of bulk data additions and removal. SingleStore doesn't need range partitioning, mainly because it can delete data so fast. Using bulk loading (SingleStore's LOAD DATA or PIPELINES) plus SQL INSERT and DELETE to manage the lifecycle of data is much easier than using range-partitioned tables and partitioning switching operations. SingleStore's speed at adding and removing data makes it a joy to work with, compared to partitioning operations in legacy database systems.You can stop reading now.But seriously, you may be thinking that you'd like to see some of the reasoning behind this, and some proof that we're as fast as I'm saying. Here goes.Range partitioning exists for these reasons in legacy systems:It allows you to swap out a range of data fast, from an existing table to a target table with a metadata-only operation. Then you can truncate the resulting target table to remove the data. Truncating in the legacy systems is the only way to quickly delete data.It allows you to swap in a range of data fast, from a staging table to a target table. This allows you to prepare data in a staging table before putting it into a table where it will be queried.It provides a coarse form of indexing, since data is in strictly ascending order from earlier to later ranges. That means you can partition three years of data into 36 one-month ranges.Different partitions can be stored on different storage devices, allowing you to add new devices as your data grows to hold the increasing volume of data.Let's look at why SingleStore can address the above requirements without range partitioning — and why it's much easier to use SingleStore to manage the data lifecycle than it is with legacy range partitioning.First; It allows you to swap out a range of data fast: SingleStore does not need to be able to swap out a range of data fast because it can delete data phenomenally fast. Stay tuned for proof of that below.Second; It allows you to swap in a range of data fast: There's no need to swap data into a SingleStore table because we can load millions of records per second using INSERT operations (say, several threads inserting data in 100-row batches) or SingleStore PIPELINES.Third; It provides a coarse form of indexing: SingleStore doesn't need partitioning to coarsely index data because columnstore sort keys can be used to order the data by what you would have used as the partitioning key in a legacy system (e.g., the date_key or a datetime column).Finally; Different partitions can be stored on different storage devices: SingleStore allows you to add more storage via a partitioned (sharded) storage model, where you can add more nodes to a cluster (of course, these nodes have their own additional storage) and rebalance your data. So there's no need to be concerned about keeping specific ranges of data on specific devices.SingleStore DELETE SpeedA common bulk operation that people do on large tables that is related to lifecycle management is to remove old data.Here's an example of how fast SingleStore can remove old data. I created the following table on a SingleStore S8-size cluster on our managed service:Table: lineitem2Columns: 17Data size: 1,254,492,160 rowsAn S8 has 8 units, which is 64 total cores and 512 GB RAM.Then, I deleted the oldest 116,325,376 rows (about 9.3% of the data). This is similar to deleting the oldest month from a table with a year of data.This took 0.2081 seconds.Yes, you read that right — 0.2081 seconds. Not minutes, not hours, not days.With delete speeds like this, who needs the complexity of partitioning? Not SingleStore users.SummaryIf you think you need table partitioning and you're using SingleStore, ask yourself why. If it's to speed up bulk removal of old data, we think you'll be happy if you just use DELETE instead because it's fast and easy. If it's to speed up query processing by keeping the data in order, you can just use a SORT key. There's really no need for range partitioning in SingleStore.Want to test this out for yourself? Get started with your free trial of SingleStore today — and say goodbye to table range partitioning for good.Appendix: Script for Delete TestIf you want to reproduce this yourself, you can run this script on a size S8 cluster. Or, choose a different sizer cluster, modify the script, and experiment with it.RESTORE DATABASE memsql_demo FROM s3 "s3://memsql-demo/" CONFIG '{"region":"us-west-2"} ';use memsql_demo;-- verify size of lineitem is 1,225,090 rowsselect format(count(*),0) from lineitem;-- create a columnstore version of the lineitem table, calling it lineitem2CREATE TABLE `lineitem2` ( `orderkey` bigint(20) NOT NULL DEFAULT '0',`partkey` int(11) DEFAULT NULL, `suppkey` int(11) DEFAULT NULL,`linenumber` int(11) NOT NULL DEFAULT '0', `quantity` decimal(20,2) DEFAULT NULL,`extendedprice` decimal(20,2) DEFAULT NULL,`discount` decimal(3,2) DEFAULT NULL, `tax` decimal(3,2) DEFAULT NULL,`returnflag` char(1) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,`linestatus` char(1) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,`shipdate` date DEFAULT NULL, `commitdate` date DEFAULT NULL,`receiptdate` date DEFAULT NULL,`shipinstruct` varchar(25) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,`shipmode` varchar(10) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,`comment` varchar(44) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,`created` timestamp NULL DEFAULT CURRENT_TIMESTAMP,SHARD KEY (`orderkey`,`linenumber`),SORT KEY(created));-- seed some data from lineitem into lineitem2insert into lineitem2select * from lineitem;-- append lineitem2 to itself until it has more than a billion rowsdelimiter //dodeclare c bigint;beginselect count(*) into c from lineitem2;while c < 1000*1000*1000 loop insert into lineitem2 select * from lineitem2; select count(*) into c from lineitem2;end loop;echo select format(count(*),0) from lineitem2;end //delimiter ;-- verify row countselect format(count(*),0) from lineitem2;-- flush table to make it all in columnstore format-- (not strictly necessary, but for-- demonstration purposes it makes sure we are only observing columnstore-- delete speed)optimize table lineitem2 flush;-- There are about 40 different "created" times. This query shows-- total rows for each, and running total, ordered by "created"with t as(select created, count(*) cfrom lineitem2group by created)select row_number() over (order by created), t.created, c, sum(c) over (order by created) as cumfrom t order by created;-- Now, copy out the timestamp for about 116 million rows,-- which is: 2021-08-23 18:37:33-- Use this in the DELETE statement to remove around 9.3% of the rows.-- Run an equivalent delete command to what we want to measure,-- so the plan gets compiled,-- and thus we won't be measuring compile time. The time chosen is-- to be before all the data, so this doesn't delete any rows.delete from lineitem2 where created <= "2020-08-23 18:37:33";-- run the DELETE and get the before & after times and subtract, and scale-- to show total time in secondsselect now(6) into @ts1;delete from lineitem2 where created <= "2021-08-23 18:37:33";select now(6) into @ts2;select timestampdiff(microsecond,@ts1, @ts2)/1000000.0 as secs;

Read Post

Product

SingleStore Adds Mission-Critical Capabilities for Enterprise Applications

You won’t believe the technology that goes into making SingleStore the fastest modern cloud database. And our latest features bring mission-critical capabilities to developers of all kinds, from enterprise database engineers to SaaS application developers. In this post, Micah Bhatki and Eric Hanson from SingleStore’s Product Management team reveal what’s new.SingleStore’s Mission-Critical Capabilities for Enterprise ApplicationsEric Hanson / Micah BhaktiSingleStore’s newest capabilities allow us to take on new mission-critical workloads. As a developer, you will have the control you need to feel confident running your mission-critical, data-intensive applications on SingleStore. And SingleStore can be deployed anywhere you run your applications, on AWS, Azure, and GCP, or self-hosted on your own infrastructure with unmatched performance, scalability, and durability.SingleStore’s unique patented Universal Storage delivers the separation of storage and compute, and has enabled the following features in a new product edition, SingleStore Premium, to complement the existing SingleStore Standard. SingleStore Premium is designed for mission-critical applications that have stringent requirements for availability, auditability, and recovery.Key Mission-Critical Features included in Premium:Point-In-Time RecoveryMulti-AZ FailoverResource GovernanceAudit LoggingHIPAA Compliance99.99% AvailabilitySilver SupportThese capabilities allow enterprises running mission-critical internal and customer-facing applications with the most stringent requirements to guarantee availability, durability, and auditability of all of their information, while delivering the performance and scalability SingleStore is known for.This article explains these and other performance and usability improvements now available in SingleStore.Point-in-Time RecoveryFor years, SingleStore has supported transactions via log-based recovery, multi-version concurrency control, lock-based write/write synchronization, built-in high-availability, and disaster recovery. But customers and prospects have asked for one feature in particular to help them recover to a consistent database state in the event of data corruption—Point-in-time recovery, or PITR.PITR is now generally available after previously debuting as a preview. It allows you to recover a database to a transaction-consistent state at any point in time, down to datetime(6) resolution, or to any named milestone you created in the past.For example, suppose you deployed an application change at 2:00 am and discovered at 2:30 am that it corrupted the database. You can detach the database, and reattach it as of 2:00 am, to get the data back to the consistent state it was in before you deployed the application change.Moreover, even though SingleStore is a distributed database, with separate transaction logs for each partition, PITR uses a new technology called global versioning that allows the system to bring the database to a transaction-consistent state after recovery.Point-in-time recovery works by:recovering the latest snapshots taken just before the point in time desired, which contain rowstore data and metadata that references columnstore blob files,playing back the log files to the desired point in time or milestone.This is illustrated in the following diagram:

Read Post

Product

SingleStore’s Patented Universal Storage - Part 4

Read Post

Data Intensity

Why You Should Use a Scale-out SQL DBMS Even When You Don't Need One

Everybody has heard of the KISS principle -- Keep It Simple, Stupid. When applied to data management technology, it implies that you should use a simple solution when it works. Developers often believe that means using a single-node DBMS like MySQL, PostgreSQL, or SQL Server. So, what is a “single-node” database? Essentially, it’s a database designed for a single machine. The capacity of a single machine dictates the resource constraints of processing power, connections, and storage. If you need more processing power or storage, you can vertically scale, meaning you upgrade to a more powerful machine. This can work, up to the scale limits of the largest available machine. By contrast, scale-out databases are built as distributed databases from the start, that is, designed to be run across machines. Sometimes people see scale-out relational database technology, like SingleStore, as strictly for high-end applications, beyond what one single-node DBMSs can handle. The thinking goes that they are inherently more complex to use than a single-node DBMS. I'm here to tell you that the KISS principle is right. But people who think it means you should only use scale-out for "extreme" apps are dead wrong. Let's look at the arguments for why scale out is not "simple," and address them one by one. We'll see that in many cases, scale out actually makes things simpler. It's hard to get and set up and manage the hardware and software. First, database platform-as-a-service (PaaS) offerings like SingleStoreDB Cloud handle all that for you. You can choose a size and dial up and down whenever you need to. For self-hosting, using the public cloud or a well-organized enterprise data center with a range of hardware SKUs means you can pick out and provision machines fairly easily. My single-node database is fast enough. For some problems with small data, a single-node DBMS may be fast enough. But there are thousands of applications out there with medium-to-large data on a single node system. The people who built them may think they are fast enough, but what if they could run queries instantaneously? Research shows that response time under ¼ second feels instantaneous, and that generates incredible user satisfaction. This drives users to explore more freely, learning more about the data, which helps them make better decisions. Your single-node DBMS might be able to provide near-instant responses for a few users, but what if there are many users? Enterprises are pursuing digital transformation initiatives to get more out of the data they have, not just scale to handle bigger data sets. The levels of speed and concurrency you can get from scale-out enable new applications that unlock data's value, enabling digital transformation. If my problem gets big, I can just add more nodes of my regular RDBMS. A common pattern for scaling applications is to create multiple databases on multiple nodes using a single-node DBMS. This could be done in a number of ways, such as\ (a) putting each customer's data in a different database with the same schema, and spreading those databases across multiple nodes or\ (b) creating replicas of the same database to scale out the workload.\ Either way, this is anything but simple because you have to decide at the application level how to split up your data. Moreover, there might be a situation where you need more than one node to handle the workload for a single database. At that point, your single-node database runs out of steam. My problem is not big enough to benefit from scale out. You'd be surprised about how small an application can be and still benefit from scale out. Here are a couple of examples. First, SingleStore has a customer with a few billion rows of data in a data mart that would easily fit on a single-node database. But they are extending quarter-second response time for dashboard refreshes to several hundred concurrent users, with intra-day updates, enabling a complete digital transformation in how the data is consumed. It's sort of a real-time data mart. As a second example, we have customers that have less than a million rows of data but are using brute-force searches of vector data for AI image-matching applications using DOT_PRODUCT and EUCLIDEAN_DISTANCE functions in SQL. This brute force approach gives them better match fidelity than multi-dimensional vector indexing that's not available in SQL DBMSs to date, and still let's them integrate their match queries with other SQL query constructs. And see the later discussion about using brute-force scale out to simplify away the need for complex solutions like pre-calculated aggregate tables. Plenty of people with only a few hundred thousand rows of data can benefit from that. It's hard to design my scale-out database to get it to perform. Yes, there are a couple of new concepts to learn with a scale-out database, mainly sharding (for partitioning data across nodes) and reference tables (for duplicating small dimension tables onto each node). But the horsepower you get from a good, high-performance scale-out database actually simplifies things. E.g. you may need materialized views or pre-calculated summary aggregate tables with a single-node database but not with a scale-out database. Pre-calculated aggregates and materialized views are tricky to use and introduce design problems that are conceptually harder than deciding how to shard your data. If you know when to use an index, you can learn how to shard your data and use reference tables in a few minutes. And you don't have to get it right the first time; it's easy to reconfigure (create a new table with the configuration you want, INSERT...SELECT... data into it, drop the old one, rename the new one, and you're done). I can't find people with the skills to use a scale-out DBMS. Modern SQL-based scale-out databases are based on standard SQL, and are often compatible with MySQL or Postgres. SingleStore is largely compatible with MySQL, for example. So hundreds of languages and tools can connect to these SQL-based scale-out databases. And almost all of the SQL skills people have from working with SQL databases like MySQL and Postgres are transferable. I want to use a general-purpose database and there are no general-purpose databases with scale out that work for me. A general purpose tool simplifies life, that's true, by making skill sets applicable to multiple problems, and reducing the effort to search for the right tool. Fortunately, there is a general-purpose SQL database that scales out and runs anywhere. I think you know what database that is. I could go on, but you get the idea -- the spartan simplicity of relational databases and SQL carries its benefits over to scale-out SQL systems. And scale out simplifies lots of things, and enables digital transformation opportunities that can be valuable to your business and your career. There's a corollary to the KISS principle that applies here also, often attributed to Albert Einstein: "Everything should be made as simple as possible, but no simpler." In this context, that means you shouldn't give up on really valuable application innovations made possible by the performance you can get from scale out, due to perceived complexity. Finally, scale out is to improve speed and scalability. SingleStore scales out, but it also has other important technologies to make things faster, including in-memory row store tables, columnstores, compilation of queries to machine code, vectorization, and a high-performance plan cache. All of these things squeeze the most out of each processor core in your system. So, next time you are about to reach for your trusty single-node DBMS, ask yourself, can I reach higher, and do more, and keep it simple at the same time?

Read Post

Product

SingleStore’s Patented Universal Storage - Part 3

SingleStore Universal Storage technology is a dramatic evolution of our columnstore data format that allows it to support both operational and analytical workloads with low total cost of ownership (TCO). People love our rowstores for OLTP-style access patterns because of our great performance based on memory-optimized data structures and compilation of queries to machine code. But for users with large data sets, the cost of providing servers with enough RAM to hold all the data started to be significant. Universal Storage solves this cost problem, while also providing even better analytical performance via query execution that takes advantage of columnar storage formats, vectorized execution, and single-instruction multiple-data (SIMD) instructions.This is the third in a series of four articles that describe SingleStore's unique, patented Universal Storage feature. Read Part 1, Part 2 and Part 4 in the series to learn the whole story.Our 7.0 release introduced universal storage and the 7.1 release enhanced it. Now, we’re delivering Episode 3 of universal storage in our 7.3 release. In this installment, we’ve added:Columnstore can be made the default table type by setting a new engine variable default_table_type to ‘columnstore’UPSERT support for columnstore tables with single-column unique keys, includingINSERT ON DUPLICATE KEY UPDATEINSERT IGNOREREPLACEAnalogous capabilities for Pipelines and LOAD DATASupport for unique key enforcement for very large INSERTs and UPDATEsNow, arbitrary INSERTs and UPDATEs, regardless of the number of rows updated, will succeed. In 7.1, if more than, say, 20-30 million rows were updated in a single statement on a small node, the operation could fail, due to an out-of-memory condition.Please see this video to learn more about our universal storage update in SingleStore 7.3:

Read Post

Product

SingleStore’s Patented Universal Storage - Part 2

Read Post

Product

SingleStoreDB Self-Managed 7.1 Now Generally Available

SingleStore is proud to announce the general availability of SingleStoreDB Self-Managed 7.1 for immediate download. SingleStoreDB Self-Managed 7.1 is also available today on SingleStoreDB Cloud, the company’s elastic cloud database, available on public cloud providers around the world.With the availability of SingleStoreDB Self-Managed 7.1, SingleStore further cements itself as the leading NewSQL platform for real-time analytics and augmented transaction processing [Ron19], delivering superb transactional and analytical performance in one system. The release also delivers improved resilience features to further strengthen SingleStore for mission-critical applications providing transaction processing, operational analytics, and more.

Read Post

Data Intensity

What SingleStore Can Do for Time-Series Applications

In earlier blog posts we described what time series data is and key characteristics of a time series database. In this blog post, which originally appeared in The New Stack, Eric Hanson, principal product manager at SingleStore, shows you how to use SingleStore for time series applications. At SingleStore we’ve seen strong interest in using our database for time series data. This is especially the case when an organization needs to accommodate the following: (1) a high rate of event ingestion, (2) low-latency queries, and (3) a high rate of concurrent queries. In what follows, I show how SingleStore can be used as a powerful time-series database and illustrate this with simple queries and user-defined functions (UDFs) that show how to do time series-frequency conversion, smoothing, and more. I also cover how to load time series-data points fast, with no scale limits. Note: This blog post was originally published in March 2019. It has been updated to reflect the new time series functions in SingleStoreDB Self-Managed 7.0. Please see the Addendum at the end of this article for specifics on using the information herein. – Ed. Manipulating Time Series with SQL Unlike most time series-specific databases, SingleStore supports standard SQL, including inner and outer joins, subqueries, common table expressions (CTEs), views, rich scalar functions for date and time manipulation, grouping, aggregation, and window functions. We support all the common SQL data types, including a datetime(6) type with microsecond accuracy that’s perfect as a time series timestamp. A common type of time-series analysis in financial trading systems is to manipulate stock ticks. Here’s a simple example of using standard SQL to do this kind of calculation. We use a table with a time series of ticks for multiple stocks, and produce high, low, open, and close for each stock: CREATE TABLE tick(ts datetime(6), symbol varchar(5), price numeric(18,4)); INSERT INTO tick VALUES ('2019-02-18 10:55:36.179760', 'ABC', 100.00), ('2019-02-18 10:57:26.179761', 'ABC', 101.00), ('2019-02-18 10:59:16.178763', 'ABC', 102.50), ('2019-02-18 11:00:56.179769', 'ABC', 102.00), ('2019-02-18 11:01:37.179769', 'ABC', 103.00), ('2019-02-18 11:02:46.179769', 'ABC', 103.00), ('2019-02-18 11:02:59.179769', 'ABC', 102.60), ('2019-02-18 11:02:46.179769', 'XYZ', 103.00), ('2019-02-18 11:02:59.179769', 'XYZ', 102.60), ('2019-02-18 11:03:59.179769', 'XYZ', 102.50); This query uses standard SQL window functions to produce high, low, open and close values for each symbol in the table, assuming that “ticks” contains data for the most recent trading day. WITH ranked AS (SELECT symbol, RANK() OVER w as r, MIN(price) OVER w as min_pr, MAX(price) OVER w as max_pr, FIRST_VALUE(price) OVER w as first, LAST_VALUE(price) OVER w as last FROM tick WINDOW w AS (PARTITION BY symbol ORDER BY ts ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)) SELECT symbol, min_pr, max_pr, first, last FROM ranked WHERE r = 1; Results: +--------+----------+----------+----------+----------+ | symbol | min_pr | max_pr | first | last | +--------+----------+----------+----------+----------+ | XYZ | 102.5000 | 103.0000 | 103.0000 | 102.5000 | | ABC | 100.0000 | 103.0000 | 100.0000 | 102.6000 | +--------+----------+----------+----------+----------+ Similar queries can be used to create “candlestick charts,” a popular report style for financial time series that looks like the image below. A candlestick chart shows open, high, low, and close prices for a security over successive time intervals:

Read Post

Product

It’s About Time: Getting More from Your Time-Series Data With SingleStoreDB Self-Managed 7.0

SingleStore is uniquely suited to real-time analytics, where data is being ingested, updated, and queried concurrently with aggregate queries. Real-time analytics use cases often are based on event data, where each separate event has a timestamp. It’s natural to interpret such a sequence of events as a time series.Prior to the 7.0 release, SingleStore delivered many capabilities that make it well-suited to time-series data management [Han19]. These include:a scaled-out, shared-nothing architecture that supports transactional and analytical workloads with a standard SQL interface,fast query execution via compilation and vectorization, combined with scale out,ability to load data phenomenally fast using the Pipelines feature, which supports distributed, parallel ingestion,non-blocking concurrency control so readers and writers never make each other wait,window functions for ranking, moving averages, and so on,a highly-compressed columnstore data format suitable for large historical data sets.Hence, many of our customers are using SingleStore to manage time series data today.For the SingleStoreDB Self-Managed 7.0 release, we decided to build some special-purpose features to make it even easier to manage time-series data. These include FIRST(), LAST(), TIME_BUCKET(), and the ability to designate a table column as the SERIES TIMESTAMP [Mem19a-d]. Taken together, these allow specification of queries to summarize time series data with far fewer lines of code and fewer complex concepts. This makes expert SQL developers more productive, and opens up the ability to query time series data to less expert developers.We were motivated to add special time series capability in SingleStoreDB Self-Managed 7.0 for the following reasons:Many customers were using SingleStore for time series data already, as described above.Customers were asking for additional time series capability.Bucketing by time, a common time series operation, was not trivial to do.Use of window functions, while powerful for time-based operations, can be complex and verbose.We’ve seen brief syntax for time bucketing in event-logging data management platforms like Splunk [Mil14] and Azure Data Explorer (Kusto) [Kus19] be enthusiastically used by developers.We believe we can provide better overall data management support for customers who manage time series data than the time series-specific database vendors can. We offer time series-specific capability and also outstanding performance, scalability, reliability, SQL support, extensibility, rich data type support, and so much more.Designating a Time Attribute in MetadataTo enable simple, brief SQL operations on time series data, we recognized that all our new time series functions would have a time argument. Normally, a table has a single, well-known time attribute. Why not make this attribute explicit in metadata, and an implicit argument of time-based functions, so you don’t have to reference it in every query expression related to time?So, in SingleStoreDB Self-Managed 7.0 we introduced a special column designation, SERIES TIMESTAMP, that indicates a default time column of a table. This column is then used as an implicit attribute in time series functions. For example, consider this table definition:CREATE TABLE tick( ts datetime(6) **series timestamp**, symbol varchar(5), price numeric(18,4));It defines a table, `tick`, containing hypothetical stock trade data. The `ts` column has been designated as the series timestamp. In examples to follow, we’ll show how you can use it to make queries shorter and easier to write.The Old Way of Querying Time SeriesBefore we show the new way to write queries briefly using time series functions and the SERIES TIMESTAMP designation in 7.0, consider an example of how SingleStore could process time series data before 7.0. We’ll use the following data for examples:INSERT INTO tick VALUES ('2020-02-18 10:55:36.179760', 'ABC', 100.00), ('2020-02-18 10:57:26.179761', 'ABC', 101.00), ('2020-02-18 10:59:16.178763', 'ABC', 102.50), ('2020-02-18 11:00:56.179769', 'ABC', 102.00), ('2020-02-18 11:01:37.179769', 'ABC', 103.00), ('2020-02-18 11:02:46.179769', 'ABC', 103.00), ('2020-02-18 11:02:59.179769', 'ABC', 102.60), ('2020-02-18 11:02:46.179769', 'XYZ', 103.00), ('2020-02-18 11:02:59.179769', 'XYZ', 102.60), ('2020-02-18 11:03:59.179769', 'XYZ', 102.50);The following query works in SingleStoreDB Self-Managed 6.8 and earlier. As output, it produces a separate row, for each stock, for each hour it was traded at least once. (So if a stock is traded ten or more times, in ten separate hours, ten rows are produced for that stock. A row will contain either a single trade, if only one trade occurred in that hour, or a summary of the trades – two or more – that occurred during the hour.) Each row shows the time bucket, stock symbol, and the high, low, open, and close for the bucket period. (If only one trade occurred in that hour, the high, low, open, and close will all be the same – the price the stock traded at in that hour.)WITH ranked AS(SELECT symbol, RANK() OVER w as r, MIN(price) OVER w as min_pr, MAX(price) OVER w as max_pr, FIRST_VALUE(price) OVER w as first, LAST_VALUE(price) OVER w as last, from_unixtime(unix_timestamp(ts) div (60*60) * (60*60)) as ts FROM tick WINDOW w AS (PARTITION BY symbol, from_unixtime(unix_timestamp(ts) div (60*60) * (60*60)) ORDER BY ts ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING))SELECT ts, symbol, min_pr, max_pr, first, lastFROM rankedWHERE r = 1ORDER BY symbol, ts;This query produces the following output, which can be used to render a candlestick chart [Inv19], a common type of stock chart.+---------------------+--------+----------+----------+----------+----------+| ts | symbol | min_pr | max_pr | first | last |+---------------------+--------+----------+----------+----------+----------+| 2020-02-18 10:00:00 | ABC | 100.0000 | 102.5000 | 100.0000 | 102.5000 || 2020-02-18 11:00:00 | ABC | 102.0000 | 103.0000 | 102.0000 | 102.6000 || 2020-02-18 11:00:00 | XYZ | 102.5000 | 103.0000 | 103.0000 | 102.5000 |+---------------------+--------+----------+----------+----------+----------+The query text, while understandable, is challenging to write because it uses a common table expression (CTE), window functions with a non-trivial window definition, a subtle use of ranking to pick one row per group, and a non-obvious divide/multiply trick to group time to a 60*60 second bucket.New Time-Series Functions in SingleStoreDB Self-Managed 7.0Here I’ll introduce the new time series functions, and then show an example where we write an equivalent query to the “candlestick” query above using the new functions. I think you’ll be impressed by how concise it is!Also see the latest documentation for analyzing time series data and for the new time series functions.FIRST()The FIRST() function is an aggregate function that takes two arguments, as follows:FIRST (value[, time]);Given a set of input rows, it returns the value for the smallest associated time.The second argument is optional. If it is not specified, it is implicitly the SERIES TIMESTAMP column of the table being queried. It’s an error if there is no SERIES TIMESTAMP available, or if there is more than one available in the context of the query where FIRST is used; in that case, you should specify the time explicitly.For example, this query gives the symbol of the first stock traded among all stocks in the tick table:SELECT first(symbol) FROM tick;The result is ABC, which you can see is the first one traded at 10:55:36.179760 in the rows inserted above.LAST()LAST is just like FIRST except it gives the value associated with the latest time.TIME_BUCKET()TIME_BUCKET takes a time value and buckets it to a specified width. You can use very brief descriptions of bucket width, like ‘1d’ for one day, ‘5m’ for five minutes, and so on. The function takes these arguments:TIME_BUCKET (bucket_width [, time [,origin]])The only required argument is bucket_width. As with FIRST and LAST, the time argument is inferred to be the SERIES TIMESTAMP if it is not specified. The origin argument is used if you want your buckets to start at a non-standard boundary – say, if you want day buckets that begin at 8am every day.Putting It All TogetherNow that we’ve seen FIRST, LAST, TIME_BUCKET, and SERIES TIMESTAMP, let’s see how to use all of them to write the candlestick chart query from above. A new version of the same query is simply:SELECT time_bucket('1h') as ts, symbol, min(price) as min_pr, max(price) as max_pr, first(price) as first, last(price) as lastFROM tickgroup by 2, 1order by 2, 1;The new version of the query produces this output, which is essentially the same as the output of the original query.+----------------------------+--------+----------+----------+----------+----------+| ts | symbol | min_pr | max_pr | first | last |+----------------------------+--------+----------+----------+----------+----------+| 2020-02-18 10:00:00.000000 | ABC | 100.0000 | 102.5000 | 100.0000 | 102.5000 || 2020-02-18 11:00:00.000000 | ABC | 102.0000 | 103.0000 | 102.0000 | 102.6000 || 2020-02-18 11:00:00.000000 | XYZ | 102.5000 | 103.0000 | 103.0000 | 102.5000 |+----------------------------+--------+----------+----------+----------+----------+Look how short this query is! It is 5 lines long vs. 18 lines for the previous version. Moreover, it doesn’t use window functions or CTEs, nor require the divide/multiply trick to bucket time. It just uses standard aggregate functions and scalar functions.ConclusionSingleStoreDB Self-Managed 7.0 makes it much simpler to specify many time-series queries using special functions and the SERIES TIMESTAMP column designation. For a realistic example, we reduced lines of code by more than three-fold, and eliminated the need to use some more advanced SQL concepts.Given the high performance, unlimited scalability, and full SQL support of SingleStore, it was a strong platform for time series data in earlier releases. Now, in SingleStoreDB Self-Managed 7.0, we’ve taken that power and added greater simplicity with these new built-in capabilities. How can you apply SingleStoreDB Self-Managed 7.0 to your time-oriented data?References[Han19] Eric Hanson, What SingleStore Can Do For Time Series Applications, https://www.singlestore.com/blog/what-memsql-can-do-for-time-series-applications/, March 2019.[Inv19] Understanding Basic Candlestick Charts, Investopedia, https://www.investopedia.com/trading/candlestick-charting-what-is-it/, 2019.[Kus19] Summarize By Scalar Values, Azure Data Explorer Documentation, https://docs.microsoft.com/en-us/azure/kusto/query/tutorial#summarize-by-scalar-values, 2019.[Mem19a] FIRST, SingleStore Documentation, https://archived.docs.singlestore.com/v7.0/reference/sql-reference/time-series-functions/first/, 2019.[Mem19b] LAST, SingleStore Documentation, https://archived.docs.singlestore.com/v7.0/reference/sql-reference/time-series-functions/last/, 2019.[Mem19c] TIME_BUCKET, SingleStore Documentation, https://archived.docs.singlestore.com/v7.0/reference/sql-reference/time-series-functions/time_bucket/, 2019.[Mem19d] CREATE TABLE Topic, SERIES TIMESTAMP, https://archived.docs.singlestore.com/v7.0/reference/sql-reference/data-definition-language-ddl/create-table/, 2019.[Mil14] James Miller, Splunk Bucketing, Mastering Splunk, O’Reilly, https://www.oreilly.com/library/view/mastering-splunk/9781782173830/ch03s02.html, 2014.

Read Post

Engineering

The Beauty of a Shared-Nothing SQL DBMS for Skewed Database Sizes

The limitations of a typical, traditional relational database management system (RDBMS) have forced all sorts of compromises on data processing systems: from limitations on database size, to the separation of transaction processing from analytics. One such compromise has been the “sharding” of various customer data sets into separate database instances, partly so each customer could fit on a single computer server – but, in a typical power law, or Zipf, distribution, the larger databases don’t fit. In response, database application developers have had to implement semi-custom sharding schemes. Here, we describe these schemes, discuss their limitations, and show how an alternative, SingleStore, makes them unnecessary. What follows are tales of two different database application architects who face the same problem—high skew of database size for different customer data sets, meaning a few are much larger than others—and address this problem in two different ways. One tries to deal with it via a legacy single-box database and through the use of “clever” application software. The other uses a scalable database that can handle both transactions and analytics—SingleStore. Judge for yourself who’s really the clever one. The Story of the Hero Database Application Architect Once there was a database application architect. His company managed a separate database for each customer. They had thousands of customers. They came up with what seemed like a great idea. Each customer’s data would be placed in its own database. Then they would allocate one or more databases to a single-node database server. Each server would handle operational queries and the occasional big analytical query. When a server filled up, they’d just allocate additional databases to a different server. Everything was going great during development. The application code only had to be written once, for one scenario — all data for a customer fitting one DBMS server. If a database was big, no problem, just provision a larger server and put that database alone on that server. Easy. Then they went into production. Everything was good. Success brought in bigger customers with more data. Data grew over time. The big customer data grew and grew. The biggest one would barely fit on a server. The architect started losing sleep. He kept the Xanax his doctor prescribed for anxiety in the top drawer and found himself dipping into it too often. Then it happened. The biggest customer’s data would not fit on one machine anymore. A production outage happened. The architect proposed trimming the data to have less history, but the customers screamed. They needed 13 months minimum or else. He bought time by trimming to exactly 13 months. They only had two months of runway before they hit the wall again. He got his top six developers together for an emergency meeting. They’d solve this problem by sharding the data for the biggest customer across several DBMS servers. Most queries in the app could be directed to one of the servers. The app developers would figure out where to connect and send the query. Not too hard. They could do it. But some of the queries had aggregations over all the data. They could deal with this. They’d just send the query to every server, bring it back to the app, and combine the data in the app layer. His best developers actually thought this was super cool. It was way more fun than writing application software. They started to feel really proud of what they’d built. Then they started having performance problems. Moving data from one machine to the other was hard. There were several ways they could do things. Which way should they do it? Then someone had the great idea to write an optimizer that would figure out how to run the query. This was so fun. Around this time, the VP from the business side called the architect. She said the pace of application changes had slowed way down. What was going on? He proudly but at the same time sheepishly said that his top six app developers had now made the leap to be database systems software developers. Somehow, she did not care. She left his office, but it was clear she was not ready to let this lie. He checked the bug count. Could it be this high? What were his people doing? He’d have to fix some of the bugs himself. He started to sweat. A nervous lump formed in the pit of his stomach. The clock struck 7. His wife called and said dinner was ready. The kids wanted to see him. He said he’d leave by 8. The Story of the Disciplined Database Application Architect Once there was a database application architect. His company managed a separate database for each customer. They had thousands of customers. They at first considered what seemed like a great idea. Each customer’s data would be placed in its own database on a single-node database server. But, asked the architect, what happens when there’s more data than will fit on one machine? One of the devs on his team said he’d heard of this scale-out database called SingleStore that runs standard SQL and can do both operational and analytical workloads on the same system. If you run out of capacity, you can add more nodes and spread the data across them. The system handles it all automatically. The dev had actually tried the free version of SingleStore for a temporary data mart and it worked great. It was really fast. And running it took half the work of running their old single-box DBMS. All their tools could connect to it too. They decided to run just a couple of SingleStore clusters and put each customer’s data in one database on one cluster. They got into production. Things were going great; business was booming. Their biggest customer got really big really fast. It started to crowd out work for other customers on the same cluster. They could see a problem coming. How could they head it off? They had planned for this. They just added a few nodes to the cluster and rebalanced the biggest database. It was all done online. It took an hour, running in the background. No downtime. The VP from the business side walked in. She had a new business use case that would make millions if they could pull it off before the holidays. He called a meeting the next day with the business team and a few of his top developers. They rolled up their sleeves and sketched out the application requirements. Yeah, they could do this. Annual review time came around. His boss showed him his numbers. Wow, that is a good bonus. He felt like he hadn’t worked too hard this year, but he kept it to himself. His golf score was down, and his pants still fit just like in college. He left the office at 5:30. His kids welcomed him at the door. The Issue of Skewed Database Sizes The architects in our stories are facing a common issue. They are building services for many clients, where each client’s data is to be kept in a separate database for simplicity, performance and security reasons. The database sizes needed by different customers vary dramatically, following what’s known as a Zipf distribution [Ada02]. In this distribution, the largest databases have orders of magnitude more data than the average ones, and there is a long tail of average and smaller-sized databases. In a Zipf distribution of database sizes, the size y of a database follows a pattern like size(r) = C r^(-b)* with b close to one, where r is the rank, and C is a constant, with the largest database having rank one, the second-largest rank two, and so on. The following figure shows a hypothetical, yet realistic Zipf distribution of database size for b = 1.3 and C = 10 terabytes (TB). Because of the strong variation among database sizes, the distribution is considered highly skewed.

Read Post

Product

SingleStore’s Patented Universal Storage - Part 1

SingleStore Universal Storage is a new vision for how databases can work – first blurring and then, for most use cases, erasing any apparent difference between today’s rowstore and columnstore tables. In SingleStore Universal Storage™ Phase 1, shipping as part of SingleStoreDB Self-Managed 7.0 (currently in beta), rowstore tables get null compression, lowering TCO in many cases by 50%. Columnstore tables get seekable columnstores, which support fast seeks and updates, giving columnstore tables many of the performance and usability features of rowstore tables. The hard choices developers have faced up to now between rowstore and columnstore tables – or between separate rowstore and columnstore database software offerings – are significantly reduced, cutting costs and improving performance. With the new system of record improvements, also offered in SingleStoreDB Self-Managed 7.0, our vision of “one database to rule them all” begins to be realized. This is the first in a series of four articles that describe SingleStore's unique, patented Universal Storage feature. Read Part 2, Part 3 and Part 4 in the series to learn the whole story. Introducing SingleStore Universal Storage SingleStore Universal Storage is a breakthrough in database storage architecture to allow operational and analytical workloads to be processed using a single table type. This will simplify the developer’s job while providing tremendous scalability and performance, and minimizing costs. As a significant first step, in SingleStoreDB Self-Managed 7.0, Universal Storage Phase 1 allows OLTP applications to use columnstore tables to run operational transactions on data much bigger than RAM. This is supported via new hash indexes and related speed and concurrency improvements for disk-based columnstore tables, delivering seeks and updates at in-memory speeds. Universal Storage Phase 1 also now supports transactional applications on larger data sets more economically, via in-memory compression for null values in fast, memory-based rowstore tables, with memory savings of roughly 50% for many use cases. Together, these improvements give SingleStore customers better performance at lower cost, the flexibility to get the most from computing resources, and the ability to tackle the largest data management problems economically. Our Vision for the Ultimate Table Format SingleStore supports two types of data tables in the same database: in-memory rowstores, which are ideal for online transaction processing (OLTP) and hybrid transactional/analytical (HTAP) applications, and disk-based columnstores, which are the best choice for purely analytical applications. Customers love the speed and predictability of rowstores for OLTP and HTAP. They also love the truly incredible analytical performance of columnstores, plus their ability to store far more data than will fit in RAM economically. But customers have been asking for us to improve the total cost of ownership (TCO) of rowstores, because they have to provision servers with large amounts of RAM when tables get big, which can be costly. They’ve also asked for us to add OLTP-like features to columnstores, such as fast UPSERTS and unique constraints. In response, we’ve developed a vision of the future in which one table type can be used for OLTP, HTAP, and analytics on arbitrarily large data sets, much bigger than the available RAM, all with optimal performance and TCO. We call this SingleStore Universal Storage. Our ultimate goal for Universal Storage is that performance for OLTP and HTAP is the same as for a rowstore table, if the amount of RAM that would have been required for an explicitly defined rowstore table is available, and that OLTP performance degrades gracefully if less RAM than that is available. For analytics, utilizing large scans, joins, aggregates, etc., the goal is to provide performance similar to that of a columnstore table. The old-fashioned way to support OLTP on tables bigger than RAM would be to use a legacy storage structure like a B-tree. But that could lead to big performance losses; we need to do better. In the Universal Storage vision, we preserve the performance and predictability of our current storage structures and compiled, vectorized query execution capability, and even improve on it. All while reducing the complexity and cost of database design, development, and operations by putting more capability into the database software. In the 7.0 release, we are driving toward solving the customer requirements outlined above, and ultimately realizing our vision for a “Universal Storage” in two different ways. One is to allow sparse rowstores to store much more data in the same amount of RAM, thus improving TCO while maintaining great performance, with low variance, for seeks. We do this through sparse in-memory compression. The other is to support seekable columnstores that allow highly concurrent read/write access. Yes, you read that right, seekable columnstores. It’s not an oxymoron. We achieve this using hash indexes and a new row-level locking scheme for columnstores, plus subsegment access, a method for reading small parts of columnstore columns independently and efficiently. In what follows, we’ll explain how we achieve a critical first step in achieving our vision for a Universal Storage in SingleStoreDB Self-Managed 7.0. And this is just the beginning. Sparse Rowstore Compression To address the TCO concerns of our customers with wide tables that have a high proportion of NULL values – a situation often found in the financial sector – we’ve developed a method of compressing in-memory rowstore data. This relies on a bitmap to indicate which fields are NULL. But we’ve put our own twist on this well-established method of storing less data for NULL values by maintaining a portion of the record as a structure of fixed-width fields. This allows our compiled query execution and index seeking to continue to perform at the highest levels. We essentially split the record into two parts: a fixed-width portion containing non-sparse fields and index keys, and a variable-width portion containing the fields which have been designated as sparse. Our NULL bitmap makes use of four bits per field instead of one, to enable room for future growth. We’ve created a pathway where we can add the ability to compress out default values like blanks and zeros, and also store normally fixed fields as variable-width fields – e.g., storing small integers in a few bytes, rather than 8 bytes, if they are declared as bigints. The following figure illustrates how sparse compression works for a table with four columns, the last three of which are designated as SPARSE. (Assume that the first one is a unique NOT NULL column, so is not designated as SPARSE). The fact that the first column is not sparse and the last three columns may be sparse is recorded in table-level metadata.

Read Post

Data Intensity

Query Processing Improvements in SingleStoreDB Self-Managed 6.8

In this blog post, I’ll focus on new query processing capabilities in SingleStoreDB Self-Managed 6.8. The marquee query feature is just-in-time (JIT) compilation, which speeds up query runtimes on the first run of a query – now turned on by default. We have also improved performance of certain right and left outer joins and related operations, and Rollup and Cube. In addition, we add convenience features, including sub-select without an alias, and extended Oracle compatibility for date and time handling functions. Finally, new array functions for splitting strings and converting JSON data are added. Other improvements in 6.8 are covered elsewhere. These include: secured HDFS pipelinesimproved pipelines performanceLOAD DATA null column handling extensionsinformation schema and management views enhancements Now, let’s examine how just in time queries can work in a database. Speeding up First Query Runtimes SingleStore compiles queries to machine code, which allows us to get amazing performance, particularly when querying our in-memory rowstore tables. By spending a bit more time compiling than most databases – which interpret all queries, not compiling them – we get high performance during execution. This works great for repetitive query workloads, such as real-time dashboards with a fixed set of queries and transactional applications. But our customers have been asking for better performance the first time a query is run, which is especially applicable for ad hoc queries – when slower performance can be especially noticeable. In SingleStoreDB Self-Managed 6.7, we first documented a JIT feature for SQL queries, enabled by running ‘set interpretermode = interpret_first’. Under this setting, SingleStore starts out interpreting a query, compiles its operators in the background, then dynamically switches from interpretation to execution of compiled code for the query _as the query runs the first time. The interpret_first setting was classified as experimental in 6.7, and was off by default. In 6.8, we’re pleased to say that interpret_first is now fully supported and is on by default. This setting can greatly improve the user’s experience running ad hoc queries, or when using any application that causes a lot of new SQL statements to be run, as when a user explores data through a graphical interface. The interpret_first setting can speed up the first run of a large and complex query – say, a query with more than seven joins – several times by reducing compile overhead, with no loss of performance on longer-running queries for their first run. Rollup and Cube Performance Improvements Cube and Rollup operator performance has been improved in SingleStoreDB Self-Managed 6.8 by pushing more work to the leaf nodes. In prior releases, Cube and Rollup were done on the aggregator, requiring more data to be gathered from the leaves to the aggregator, which can take more time. For example, consider the following query from the Cube and Rollup documentation: SELECT state, product_id, SUM(quantity) FROM sales GROUP BY CUBE(state, product_id) ORDER BY state, product_id; The graphical query plan for this in 6.8, obtained using SingleStore Studio, is the following:

Read Post

Product

How to Use SingleStore with Intel’s Optane Persistent Memory

Intel’s new Optane DC persistent memory adds a new performance option for SingleStore users. After careful analysis, we’ve identified one area in which SingleStore customers and others can solve a potentially urgent problem using Optane today, and we describe that opportunity in this blog post. We also point out other areas where SingleStore customers and others should keep an eye on Optane-related developments for the future. If you need broader information than what’s offered here, there are many sources for more comprehensive information about Optane and what it can do for you, beginning with Intel itself.

Read Post

Data Intensity

DZone Webinar – SingleStore for Time Series, Real Time, and Beyond

Eric Hanson, Principal Product Manager at SingleStore, is an accomplished data professional with decades of relevant experience. This is an edited transcript of a webinar on time series data that he recently delivered for developer website DZone. Eric provided an architect’s view on how the legacy database limits of the past can be solved with scalable SQL. He shows how challenging workloads like time series and big data analytics are addressed by SingleStore, without sacrificing the familiarity of ANSI SQL. You can view the webinar on DZone. Time series data is getting more and more interest as companies seek to get more value out of the data they have – and the data they can get in the future. SingleStore is the world’s fastest database – typically 10 times faster, and three times more cost effective, than competing databases. SingleStore is a fully scalable relational database that supports structured and semi-structured data, with schema and ANSI SQL compatibility. SingleStore has features that support time series use cases. For time series data, key strengths of SingleStore include a very high rate of data ingest, with processing on ingest as needed; very fast queries; and high concurrency on queries. Key industries with intensive time series requirements that are using SingleStore today include energy and utilities; financial services; media and telecommunications; and high technology. These are not all the industries that are using SingleStore, but these four in particular, we have a lot of customers in these industries and these industries use time series data. Editor’s Note: Also see our blog posts on time series data, choosing a time series database, and implementing time series functions with SingleStore. We also have an additional recorded webinar (from us here at SingleStore) and an O’Reilly ebook download covering these topics. Introduction to SingleStore SingleStore has a very wide range of attributes that make it a strong candidate for time series workloads. You can see from the chart that SingleStore connects to a very wide range of other data technologies; supports applications, business intelligence (BI) tools, and ad hoc queries; and runs everywhere – on bare metal or in the cloud, in virtual machines or containers, or as a service. No matter where you run it, SingleStore is highly scalable. It has a scale-out, shared-nothing architecture.

Read Post

Engineering

SingleStoreDB Self-Managed 6.7 Performance Improvements

Performance is in SingleStore’s DNA. Last March, we shattered the trillion-rows-per-second scan barrier for processing a single SQL query on industry-standard Intel servers. That query processed data from a single table, and of course, lots of analytical queries use multiple tables, particularly star schemas. So we’ve broadened our vectorized, single instruction, multiple data (SIMD) query execution technology beyond single-table, group-by aggregate queries to star join group-by aggregate queries. A star join is a common kind of query that operates on what’s known as a star schema, used in most data warehouses and data marts, and some operational analytics applications as well. In a star schema, a single large table called a fact table is linked to several smaller tables called dimension tables. Star join queries typically join these tables together, aggregate numeric “measure” columns from the fact table, and group by descriptive fields from the dimension tables. Our star join performance was already excellent. This improvement makes it ludicrously good. In addition to star join performance improvements, we’ve made many other improvements to query and load speed, as I’ll describe in this blog post. When combined with SingleStore’s existing high performance, what this improvement means for application developers building real-time analytics systems, data warehouses, and data marts is that they can use SingleStore to get stunning performance at concurrency levels they couldn’t have dreamed of before. And they can do it with a database that supports mixed workloads and runs ANSI SQL. Star Join Performance Improvements We’ve added proprietary, patent-pending new algorithms for star join that make use of vectorization and SIMD. These algorithms operate directly on our compressed columnstore data formats, which we call encoded data. Instead of doing a hash join in the traditional way, where each row of the “probe-side” table is used to do a function call to search into a hash table created from the “build-side” table, we now have a special implementation of hash join that doesn’t do function calls in the inner loop. Instead, it uses generated, templatized code to process part of the work for multiple probes at once in a single SIMD instruction, operating directly on encoded data. To demonstrate this, I created a basic star schema data set. Since we have quite a few customers in the media market, I made a media-oriented example with one fact table and three dimensions, like so: Table Number of rows Description `media_view_fact` 1,310,720,000 Fact table describing a view event for a media object (e.g., a web page) `date_dim` 2,556 One row with descriptive properties for each day for 7 years `user_dim` 1,000 One row for each system user `item_dim` 10,000 One row for each media item being tracked I created a basic, but realistic, star join query that forces processing of every single row from the fact table, does a join, and groups by columns from a dimension, as follows: select d_daynuminweek, d_dayofweek, count(*) as c from media_view_fact f, date_dim d where f_datekey = d_datekey group by 1, 2 order by 1 asc; The hardware I used was a single Intel Skylake server with two 2.6Ghz processors and 56 total cores. Data was partitioned evenly with one partition per core. I configured the system with one SingleStore aggregator node and two SingleStore leaf nodes, one leaf for each processor. The system had non-uniform memory access (NUMA) enabled and each leaf was on a separate NUMA node. I ran this query twice – once with, and once without, the new encoded join capability enabled. The results are summarized below: Encoded joins enabled? Average runtime 30 runs no 3.01s yes 0.0297s speedup (times) 101 No, this is not a typo. This is a 101 times speedup! The data is not pre-aggregated. The speedup is due to operating directly on encoded data, using SIMD and the enhanced join algorithm. What does this mean? Now, all existing applications can get far faster response times and concurrent throughput. Even more exciting is that you can create new applications that allow interactive analytics on large data sets with rapidly changing data, without resorting to the complexity of pre-aggregating data. More complex queries also show substantial speedups. For example, here’s a four-way star join with filters. select d_dayofweek, count(*) from media_view_fact, date_dim, user_dim, item_dim where f_datekey = d_datekey and f_userkey = u_userkey and f_itemkey = i_itemkey and i_itemuri regexp 'http://www.c000[0-5].*' and u_zipcode like '002%' and d_year = 1997 and d_month = "January" group by d_dayofweek; The results are as follows: Encoded joins enabled? Runtime no 0.09s yes 0.03s speedup (times) 3 The fact table is sorted (keyed) by f_datekey, and we’ve supported range (segment) elimination via join since our 6.0 release. So the date range filter implied by this join requires us to only read one year of data, not all seven years. And the filter effects of the join are employed during the scan of the fact table both with and without encoded joins enabled, via Bloom filters or a related approach we use in SingleStoreDB Self-Managed 6.7. So the speedup is not as dramatic as the 101X speedup for the previous query. But a 3X speedup, on top of SingleStore’s generally high performance, is amazing nevertheless! Star Schema Benchmark Release-to-Release Gains The well-known star schema benchmark (SSB) was already performing very well in SingleStoreDB Self-Managed 6.5, mainly because the joins in the queries in SSB are highly selective. That means that most rows in the fact table are filtered out by joins with the dimension tables. So vectorized testing of Bloom filters, available in 6.5, worked well to speed up these queries. Still, the new star join query execution technology in 6.7 has further improved this workload. The hardware for this test used four AWS m4.2xlarge leaf nodes (8 logical cores, 32GB RAM each). The primary fact table has 600 million rows. There are no precomputed aggregates. Query results are computed from scratch. This chart illustrates the gains:

Read Post

Product

Performance Improvements in SingleStoreDB Self-Managed 6.5

Read Post

Product

Shattering the Trillion-Rows-Per-Second Barrier With SingleStore

Last week at the Strata Data Conference in San Jose, I had the privilege of demonstrating SingleStore processing over a trillion rows per second on the latest Intel Skylake servers. It’s well known that having an interactive response time of under a quarter of a second gives people incredible satisfaction. When you deliver response time that drops down to about a quarter of a second, results seem to be instantaneous to users. But with large data sets and concurrency needs, giving all customers that level of speed can seem beyond reach. So developers sometimes take shortcuts, such as precomputing summary aggregates. That can lead to a rigid user experience where if you tweak your query a little, for example adding an extra grouping column, suddenly it runs orders of magnitude slower. And it also means your answers are not real time, i.e. not on the latest data. SingleStore gives you the interactive response time your users want, on huge data sets, with concurrent access, without resorting to precomputing results. Running at a Trillion Rows Per Second SingleStoreDB Self-Managed 6, which shipped in late 2017, contains new technology for executing single-table group-by/aggregate queries on columnstore data incredibly fast. The implementation is based on these methods: (1) operations done directly on encoded (compressed) data in the columnstore, (2) compilation of queries to machine code, (3) vectorized execution, and (4) use of Intel AVX2 single instruction, multiple data (SIMD) enhancements. When the group-by columns are encoded with dictionary, integer value, or run-length encoding, SingleStore runs a one-table group-by/aggregate at rates exceeding three billion rows per second per core at its peak. The fewer the number of groups and the simpler the aggregate functions, the faster SingleStore goes. This incredible per-core speed gave us the idea to shoot for the trillion-rows-per-second mark. To accomplish this, with a realistic query, I wrote a data generator to build a data set that simulates stock trades on the NASDAQ. Then we talked to our partners at Intel, and they generously gave us access to servers in their lab with the latest Skylake processors. These machines have two Intel® Xeon® Platinum 8180 processors each, which have 28 cores, for a total of 56 cores per server. I created a SingleStore cluster with one aggregator node and eight leaf nodes, with one server for each node, as shown in Figure 1. This cluster had 2 * 28 * 8 = 448 total cores on the leaves — the most important number that determined the overall rows-per-second rate we could get.

Read Post

Data Intensity

Delivering Scalable Self-Service Analytics

Within 48 hours of launching Google Analytics as a free product, virtually all of Google’s servers crashed. Eric Schmidt called this Google’s “most successful disaster.” Why would a free product, whose hardware requirements melted down a datacenter, be worth it? Wesley Chan, the creator of Google Analytics, later said that, “Google Analytics generates about three billion dollars in extra revenue,” as noted in Steven Levy’s book, In The Plex. Google Analytics allowed Google’s customers to measure how good AdWords actually were, and showed them, with their own data, exactly how high they could increase bids and still make money. As Chan said, “know more, spend more.” The full potential of such an offering comes when customers are allowed to arbitrarily segment and calculate flexible aggregates. To do that, they need to be able to query raw unaggregated data. This way your company does not have to guess what the customer wants to aggregate, as all choices remain available. If raw data access is not provided, then data must be precomputed, at least on some dimensions, which limits flexibility and the extent of the insights users can get from data. Cost and technology constraints have led most companies to build analytics with this precompute approach for customers, because they need to serve analytics to many customers concurrently. The scale required to offer raw data access remained untenable. It was unthinkable to perform computations on raw data points on the scale of billions of rows per request concurrently for thousands of customers. Today, SingleStore is changing that conventional wisdom and offering companies the ability to serve raw unaggregated data performance to a range of customers. To explain this capability further, there are three major pieces of technology in this use case: Scale-outColumnstore query executionEfficient data isolation Scale-Out Knowing system performance characteristics on a per-core basis, users can calculate how much compute and storage is needed to serve analytics at scale. Once that calculation is done, the key is to utilize a distributed system allowing enough dedicated compute power to meet demand. SingleStore can be used to run one to hundreds of nodes, which lets users scale the performance appropriately. For example, if you have a million customers with one million data points each, you can say that you have one trillion data points. Imagine that at the peak, one thousand of those customers are looking at the dashboard simultaneously – essentially firing off one thousand concurrent queries against the database. Columnstore compression can store these trillion rows on a relatively small SingleStore cluster with approximately 20 nodes. Conservatively, SingleStore can scan 100 million rows per second per core, which mean that just one core can service 100 concurrent queries scanning one million rows each, and deliver sub-second results for analytical queries over raw data – below we will provide a benchmark for a columnstore query execution performance. Columnstore Query Execution A simple query over a columnstore table, such as a `GROUP BY`, can run at a rate of hundreds of millions to over a billion data points per second per core. To demonstrate this, we loaded a public dataset about every airline flight in the United States from 1987 until 2015. As the goal was to understand performance per core, we loaded this into a single node SingleStore cluster running on a 4 core, 8 thread Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz. To repeat this experiment, download the data using the following bash script: mkdir csv for s in `seq 1987 2015` do for m in `seq 1 12` do wget http://www.transtats.bts.gov/Download/On_Time_On_Time_Performance_${s} _${m} .zip done done Create this table: CREATE TABLE ontime ( Year INT, Quarter INT, Month INT, DayofMonth INT, DayOfWeek INT, FlightDate Date, UniqueCarrier Varchar(100), AirlineID INT, Carrier Varchar(100), TailNum Varchar(100), FlightNum Varchar(100), OriginAirportID INT, OriginAirportSeqID INT, OriginCityMarketID INT, Origin Varchar(100), OriginCityName Varchar(100), OriginState Varchar(100), OriginStateFips Varchar(100), OriginStateName Varchar(100), OriginWac INT, DestAirportID INT, DestAirportSeqID INT, DestCityMarketID INT, Dest Varchar(100), DestCityName Varchar(100), DestState Varchar(100), DestStateFips Varchar(100), DestStateName Varchar(100), DestWac INT, CRSDepTime INT, DepTime INT, DepDelay INT, DepDelayMinutes INT, DepDel15 INT, DepartureDelayGroups Varchar(100), DepTimeBlk Varchar(100), TaxiOut INT, WheelsOff INT, WheelsOn INT, TaxiIn INT, CRSArrTime INT, ArrTime INT, ArrDelay INT, ArrDelayMinutes INT, ArrDel15 INT, ArrivalDelayGroups INT, ArrTimeBlk Varchar(100), Cancelled INT, CancellationCode Varchar(100), Diverted INT, CRSElapsedTime INT, ActualElapsedTime INT, AirTime INT, Flights INT, Distance INT, DistanceGroup INT, CarrierDelay INT, WeatherDelay INT, NASDelay INT, SecurityDelay INT, LateAircraftDelay INT, FirstDepTime Varchar(100), TotalAddGTime Varchar(100), LongestAddGTime Varchar(100), DivAirportLandings Varchar(100), DivReachedDest Varchar(100), DivActualElapsedTime Varchar(100), DivArrDelay Varchar(100), DivDistance Varchar(100), Div1Airport Varchar(100), Div1AirportID INT, Div1AirportSeqID INT, Div1WheelsOn Varchar(100), Div1TotalGTime Varchar(100), Div1LongestGTime Varchar(100), Div1WheelsOff Varchar(100), Div1TailNum Varchar(100), Div2Airport Varchar(100), Div2AirportID INT, Div2AirportSeqID INT, Div2WheelsOn Varchar(100), Div2TotalGTime Varchar(100), Div2LongestGTime Varchar(100), Div2WheelsOff Varchar(100), Div2TailNum Varchar(100), Div3Airport Varchar(100), Div3AirportID INT, Div3AirportSeqID INT, Div3WheelsOn Varchar(100), Div3TotalGTime Varchar(100), Div3LongestGTime Varchar(100), Div3WheelsOff Varchar(100), Div3TailNum Varchar(100), Div4Airport Varchar(100), Div4AirportID INT, Div4AirportSeqID INT, Div4WheelsOn Varchar(100), Div4TotalGTime Varchar(100), Div4LongestGTime Varchar(100), Div4WheelsOff Varchar(100), Div4TailNum Varchar(100), Div5Airport Varchar(100), Div5AirportID INT, Div5AirportSeqID INT, Div5WheelsOn Varchar(100), Div5TotalGTime Varchar(100), Div5LongestGTime Varchar(100), Div5WheelsOff Varchar(100), Div5TailNum Varchar(100), key (AirlineID) using clustered columnstore ); Then load data into the table: `load data infile '/home/memsql/csv/*' into table ontime fields terminated by ',' enclosed by '"' lines terminated by ',\n' ignore 1 lines;` Once the data is loaded, run a simple group by command. The following query performs a full table scan: SELECT OriginCityName, count(*) AS flights FROM ontime GROUP BY OriginCityName ORDER BY flights DESC LIMIT 20; On a machine with 4 cores, a 164 million row dataset query runs in 0.04 seconds which is 1 billion rows per second per core. No, that’s not a typo. That’s a billion rows per second per core. More complex queries will consume more CPU cycles, but with this level of baseline performance there is a lot of room across a cluster of 8, 16, or even hundreds of machines to handle multi-billion row datasets with response times under a quarter of a second. At that speed, queries appear to be instantaneous to users, leading to great user satisfaction. Try this example using SingleStoreDB Self-Managed 6. New vectorized query execution techniques in SingleStoreDB Self-Managed 6, using SIMD and operations directly on encoded (compressed) data, make this speed possible. Efficient Data Isolation Per Customer Data warehouses such as Redshift and Big Query support large scale, but may not sufficiently isolate different queries in highly concurrent workloads. On top of that, both have a substantial fixed overhead on a per query basis. Redshift in particular does not support many concurrent queries: http://docs.aws.amazon.com/redshift/latest/dg/cm-c-defining-query-queues.html. Depending on the analytical requirements, SingleStore allows for an ordered and partitioned physical data layout to ensure only scanned data belongs to a single customer. In our example, the columnstore was clustered on AirlineID. SingleStore supports clustered columnstore keys that allow global sorting of columnstore tables. In this case, if you have a predicate on AirlineID a user will only scan the subset of data belonging to that airline. This allows SingleStore to deliver on very high concurrency (in the thousands of concurrent queries) with each query scanning and aggregating millions of data points. More on Query Execution At SingleStore, we are continuously innovating with new query processing capabilities. This is a list of recent innovations in our shipping product: https://archived.docs.singlestore.com/v6.0/release-notes/memsql/60-release-notes/. Bringing it All Together Going back to our original example, though our dataset is one trillion rows, because of the clustered columnstore key, each customer only needs to scan through one million rows. For a simple query like the above, scanning 500 million rows per second per core means that a single CPU core could support 500 concurrent queries and deliver sub-second performance. To recreate the work mentioned in this blog, try out SingleStoreDB Self-Managed 6: singlestore.com/free.

Read Post

Engineering

Arrays – A Hidden Gem in SingleStore

Read Post

Back to All Articles

Eric Hanson

The Power of SQL for Vector Database Operations, Part 1

Why Your Vector Database Should Not be a Vector Database

The Forrester Wave^TM

Translytical Data
Platforms Q4 2022

AI-Powered Semantic Search in SingleStoreDB

Image Matching in SQL With SingleStoreDB

Winter 2022 Release: Toys for Developers in SingleStoreDB

Winter 2022 Release: SingleStoreDB Universal Storage, Part 5

[r]evolution Summer 2022: Bring Application Logic to Your Data With SingleStoreDB Code Engine for Wasm

Toys for Developers in SingleStoreDB: Spring 2022 Release

Flexible Parallelism in SingleStoreDB

Table Range Partitioning Is a Crutch. Here’s Why SingleStore Doesn’t Need It

SingleStore Adds Mission-Critical Capabilities for Enterprise Applications

SingleStore’s Patented Universal Storage - Part 4

Why You Should Use a Scale-out SQL DBMS Even When You Don't Need One

SingleStore’s Patented Universal Storage - Part 3

SingleStore’s Patented Universal Storage - Part 2

SingleStoreDB Self-Managed 7.1 Now Generally Available

What SingleStore Can Do for Time-Series Applications

It’s About Time: Getting More from Your Time-Series Data With SingleStoreDB Self-Managed 7.0

The Beauty of a Shared-Nothing SQL DBMS for Skewed Database Sizes

SingleStore’s Patented Universal Storage - Part 1

Query Processing Improvements in SingleStoreDB Self-Managed 6.8

How to Use SingleStore with Intel’s Optane Persistent Memory

DZone Webinar – SingleStore for Time Series, Real Time, and Beyond

SingleStoreDB Self-Managed 6.7 Performance Improvements

Performance Improvements in SingleStoreDB Self-Managed 6.5

Shattering the Trillion-Rows-Per-Second Barrier With SingleStore

Delivering Scalable Self-Service Analytics

Arrays – A Hidden Gem in SingleStore

The Forrester Wave:^TM
Translytical Data
Platforms, Q4 2022

as a ‘Strong Performer’

Eric Hanson

The Power of SQL for Vector Database Operations, Part 1

Why Your Vector Database Should Not be a Vector Database

The Forrester WaveTM

Translytical DataPlatforms Q4 2022

AI-Powered Semantic Search in SingleStoreDB

Image Matching in SQL With SingleStoreDB

Winter 2022 Release: Toys for Developers in SingleStoreDB

Winter 2022 Release: SingleStoreDB Universal Storage, Part 5

[r]evolution Summer 2022: Bring Application Logic to Your Data With SingleStoreDB Code Engine for Wasm

Toys for Developers in SingleStoreDB: Spring 2022 Release

Flexible Parallelism in SingleStoreDB

Table Range Partitioning Is a Crutch. Here’s Why SingleStore Doesn’t Need It

SingleStore Adds Mission-Critical Capabilities for Enterprise Applications

SingleStore’s Patented Universal Storage - Part 4

Why You Should Use a Scale-out SQL DBMS Even When You Don't Need One

SingleStore’s Patented Universal Storage - Part 3

SingleStore’s Patented Universal Storage - Part 2

SingleStoreDB Self-Managed 7.1 Now Generally Available

What SingleStore Can Do for Time-Series Applications

It’s About Time: Getting More from Your Time-Series Data With SingleStoreDB Self-Managed 7.0

The Beauty of a Shared-Nothing SQL DBMS for Skewed Database Sizes

SingleStore’s Patented Universal Storage - Part 1

Query Processing Improvements in SingleStoreDB Self-Managed 6.8

How to Use SingleStore with Intel’s Optane Persistent Memory

DZone Webinar – SingleStore for Time Series, Real Time, and Beyond

SingleStoreDB Self-Managed 6.7 Performance Improvements

Performance Improvements in SingleStoreDB Self-Managed 6.5

Shattering the Trillion-Rows-Per-Second Barrier With SingleStore

Delivering Scalable Self-Service Analytics

Arrays – A Hidden Gem in SingleStore

The Forrester Wave:TMTranslytical DataPlatforms, Q4 2022

as a ‘Strong Performer’

The Forrester Wave^TM

Translytical Data
Platforms Q4 2022

The Forrester Wave:^TM
Translytical Data
Platforms, Q4 2022