Minimize your ecommerce data TCO with Local SSD and Isima’s bi(OS)

In today’s ecommerce marketplace, consumers want customized experiences, but the costs of acquisition, personalization, fulfillment, and operations are exploding. Data is one way for ecommerce and retail providers to delight consumers cost-effectively. Unfortunately, this valuable data is often spread across marketing channels, in-house IT systems, third-party fulfillment systems, and bespoke operational systems.

Inspired by Google’s BigTable, unified analytics provider Isima’s flagship product, bi(OS), is a lean modern data stack that accelerates analytics outcomes for organizations by onboarding, processing, consuming, and operating on data using a self-service UI (Clicks), Python, and SQL. Together, Google Cloud and Isima offer a three-legged data stack that encourages agility, innovation, and efficiency for builders. In this blog post, we describe how Isima’s bi(OS) uses Google Compute Engine instances and Local SSD to deliver a competitive offering for ecommerce and retail.

bi(OS) as the differentiating component of the ecommerce data stack

bi(OS) acts as a data hub between online transaction processing (OLTP), online analytical processing (OLAP), and third-party software-as-a-service (SaaS) systems. bi(OS) includes no-code connectors to ingest data from OLTP systems (Cloud SQL), OLAP systems (Cloud Storage, BigQuery), and third-party SaaS systems (for example, Google/Facebook Ads, Clevertap, and Google Tag Manager). Low latency microservices, near-real-time analytics jobs, and ad-hoc queries can interface with bi(OS) via SQL-friendly Python, Java, and JavaScript SDKs.

bi(OS) on Google Cloud

Isima’s benchmarking of ecommerce and retail use cases on Google Cloud covered various aspects of marketing technology (martech), personalization, fulfillment, and operations. The team set up a bi(OS) cluster utilizing  n2-highmem-16 instances with 16x375GB Local SSD that was three-way resilient across three zones (a,b, and c) in the us-east-4 region. Isima engineers collected metrics after the system ran for five-plus days with five nines reliability.  During this time, all writes and reads were done with QUORUM consistency across the three zones.

At 70%+ utilization of compute, memory, and storage, the system sustained ~5,500 ops/sec.

Further, bi(OS) includes a turbo mode that reduces tail latencies for customer-facing ML micro-services. The graph below shows the distribution of these latencies measured over four-plus hours with and without turbo mode.

While bi(OS) and bi(OS) Turbo are comparable until p99, bi(OS) Turbo brought down p99.9 latencies by 8X.

The Google Cloud Local SSD touch

While bi(OS) is a multi-cloud offering, Google Cloud offers the following unique I/O benefits: 

• Fine-tuning of storage: Google Cloud is the only cloud provider within the “big three” that allows you to fine-tune the amount of ephemeral block storage — in Google Cloud’s case, Local SSD. This allows Isima to offer up to one year of raw data retention, which is 40% higher than other cloud providers.

• Multiple small(er) locally attached SSDs: Google Cloud’s Local SSD comes in 375GiB partitions. These multiple, smaller, Local SSD partitions allow applications like bi(OS) to use the same storage type for both write-ahead logs and data.

• Stable I/O latencies: bi(OS) can only meet its QoS guarantees if the underlying infrastructure operates smoothly. Even after filling the Local SSDs by over 70%, Cloud Storage delivered good read and write I/O latencies during benchmarking.

Conclusion

Isima chose Google Cloud for its ability to run a lean, cost-effective, innovative three-tier data stack for all ecommerce and retail use cases. Isima, as a cloud-first company, loves Google Cloud’s simplicity and cloud-first approach to deploying and managing resources. bi(OS) is in the process of being listed on the Google Cloud Marketplace. To learn more, read about bi(OS), and watch a two-minute video about how ecommerce pioneers use bi(OS).

^{1. Each select retrieved ~10 rows.  In other words this system processed ~20K+ rows/sec.
*As measured in number of rows read + written per second.}