All Products
Search
Document Center

Serverless wide table engine

Last Updated: Jul 22, 2021

This topic describes the serverless wide table engine provided by ApsaraDB for Lindorm (Lindorm).

Overview

If you use the serverless wide table engine, you do not need to plan or purchase hardware resources, such as CPU and memory resources. You can subscribe to a specific number of capacity units (CUs) as needed. For more information about the billing items, see Billing items. The CUs are available upon subscription. You can also select the pay-as-you-go billing method. This indicates that you pay only for the used resources. The serverless wide table engine enables high scalability. If your business requests change, Lindorm schedules physical resources in the background to meet your business needs. This way, resources can be temporarily allocated to your Lindorm cluster. This reduces operations and maintenance (O&M) costs and system risks.

If you use the serverless wide table engine, you pay only for the used resources. This provides a more cost-effective solution for your business than the traditional mode.

Scenarios

Lightweight configuration for small and medium-sized enterprises

The serverless wide table engine is suitable for small and medium-sized enterprises. In serverless mode, you pay only for the used resources and do not need to purchase a whole cluster. If you use the wide table engine for a short period of time, we recommend that you use the serverless wide table engine because it reduces costs by 10 percent. You can also start or release the serverless wide table engine within seconds. This allows you to use this service in a flexible way.

Business requirements for scheduled tasks

If you process scheduled tasks, the high scalability of the serverless wide table engine meets your business needs. If you process scheduled tasks on a daily basis or analyze and process data at night, you can select the pay-as-you-go billing method. This way, you are charged only when you use the serverless wide table engine to process tasks.

Business that experiences large fluctuations

If your business experiences large fluctuations, you need to prepare a large number of node resources or estimate the required CUs in advance. This consumes time and energy, and increases costs. In this case, you can select the serverless wide table engine. In this mode, Lindorm automatically schedules and increases the number of CUs within seconds during peak hours. Then, Lindorm automatically reduces the number of CUs during off-peak hours. This saves costs.

Business that requires zero O&M

The O&M team for the serverless wide table engine accumulates years of technical expertise. This enables professional O&M for Lindorm clusters. In this case, you can upgrade, tune, and troubleshoot Lindorm clusters in an efficient way. You do not need to worry about resource usage or software versions. This enables zero O&M for your clusters.

Enable the serverless wide table engine

Prerequisites

  • A virtual private cloud (VPC) is created. If no VPC is available, log on to the VPC console to create a VPC.

  • The Lindorm console is logged on to.

Create a Lindorm cluster in serverless mode

  1. On the Instance list page in the Lindorm console, click Create to go to the ApsaraDB for Lindorm (Subscription) page.

  2. Set Product Type to LindormServerless (Subscription).

  3. Configure other parameters. For more information about the parameters, see Create a Lindorm cluster.

  4. After you configure the parameters, click Buy Now to go to the Confirm Order page. Confirm the parameter settings and read and agree to Terms of Service. Then, click Pay to complete the payment.

Use the serverless wide table engine

You can use the serverless wide table engine in the same way as that you use a standard Lindorm cluster. You can use an HBase client or a Cassandra client driver to connect to the wide table engine.

Pricing

Billable items

Request billing

In the serverless wide table engine, resources that are consumed by read and write requests are measured in CUs. Lindorm calculates the number of CUs based on the following rules:

  1. If you read a single row and the data size returned is greater than 4 KB, Lindorm divides the actual data size by 4 KB and returns a value that is rounded up to the nearest integer. This value indicates the actual number of CUs that you consume.

  2. If you read rows in a batch, Lindorm adds the number of CUs consumed by each single-row read request and returns a total value. The number of CUs consumed by a single-row read request is calculated based on rule 1.

  3. If you scan and read multiple rows, Lindorm totals the data size of all rowkeys and the data size of attribute columns in each row. Then, Lindorm divides the total value by 4 KB and returns a value that is rounded up to the nearest integer. If you scan data based on filters, the number of CUs that you consume is determined by the number of rows that Lindorm scans. For example, if Lindorm scans 100 rows of data and returns 1 row of data, the number of CUs that you consume is calculated based on 100 rows of data.

    Example: You read data in a single row 10 times in a second.

    In five of the read operations, each operation reads row data of 3.78 KB. In this case, the system divides 3.78 KB by 4 KB, rounds the quotient up, and then multiplies the result by 5.

    In the other five read operations, each operation reads row data of 4.26 KB. In this case, the system divides 4.26 KB by 4 KB, rounds the quotient up, and then multiplies the result by 5.

    Therefore, the number of CUs consumed by 10 single-row read requests in a second is calculated based on the following equation: (5 x 1) + (5 x 2) = 15. The system rounds 3.78 KB up as 1 read CU, and rounds 4.26 KB up as 2 read CUs.

Storage billing

In the serverless wide table engine, the used storage is calculated based on the size of each KeyValue that you write to a table instead of the compressed table size. You can call the org.apache.hadoop.hbase.CellUtil.estimatedSerializedSizeOf() function to estimate the size of each KeyValue.

Lindorm adopts a log-structured merge-tree (LSM tree). This indicates that the system does not delete the data that expires until the data is compacted. The storage is released only after the data is deleted.

Billing method

The serverless wide table engine provides the following two billing methods:

  • Subscription: You prepay for compute resources and storage resources. If the number of compute resources that you use exceeds that you purchase, QuotaExceededException is reported. If the number of storage resources that you use exceeds that you purchase, the serverless wide table engine is locked. You can adjust the number of CUs and disks as needed on the cluster details page.

  • Pay-as-you-go: You do not need to prepay for compute resources or storage resources. You pay only for the used resources.

Subscription

If you select the subscription billing method, you prepay for compute resources and storage resources. If the number of compute resources that you use exceeds that you purchase, QuotaExceededException is reported. If the number of storage resources that you use exceeds that you purchase, the serverless wide table engine is locked. You can adjust the number of CUs and disks as needed on the cluster details page. For more information, see the following examples.

  1. If you purchase 10 CUs of compute resources, you can consume a maximum of 10 CUs each second. If more than 10 CUs are requested, the system triggers throttling. If you consume less than 10 CUs each second, the idle CUs cannot be reserved for future use.

  2. If you purchase 10 GB storage and the used storage exceeds 10 GB, the serverless wide table engine is locked. If you consume less than 10 GB storage, you still need to pay for 10 GB storage each month.

Pay-as-you-go

The pay-as-you-go billing method will be available soon.

If you select the pay-as-you-go billing method, you do not need to prepay for compute resources or storage resources. You pay only for the used resources.

If you select the pay-as-you-go billing method, a maximum of 20,000 CUs are available for each cluster per second. If your cluster requires more than 20,000 CUs per second, submit a ticket.

The system generates a bill on an hourly basis. If you consume 30,000 CUs and use up to 20 GB storage in an hour, you are charged for 30,000 CUs and 20 GB storage. If you do not handle requests within the next hour, you pay only for storage. The used storage is still 20 GB.

Select a billing method as needed

If you handle a specific number of requests, you can select the subscription billing method. This is cost-effective. If your business experiences large fluctuations, you can select the pay-as-you-go billing method. This way, you pay only for the used resources. If you do not handle requests during a period of time, you pay only for the used storage.

Limits

  • The maximum data size for a request cannot exceed 2 MB.

  • The maximum data size for a scan request cannot exceed 4 MB.

  • The maximum number of batch operations cannot exceed 100.

  • The maximum length of a table name cannot exceed 128 bytes.

  • The maximum length of a namespace name cannot exceed 128 bytes.

  • The maximum length of a column family name cannot exceed 32 bytes.

  • The maximum number of partitions that you can create for a table cannot exceed 64.

  • The maximum number of global tables in a single cluster cannot exceed 64.

  • The maximum number of namespaces in a single cluster cannot exceed 5.