You need to enable JavaScript to run this app.
最新活动
大模型
产品
解决方案
定价
生态与合作
支持与服务
开发者
了解我们

关于GridDB STRING列最大容量及插入10MB字符串触发60079错误的咨询

GridDB STRING列最大容量及插入10MB字符串触发60079错误的解析

Hey there! Let's break down exactly what's happening here and how to fix this issue.

First, why are you getting the 60079 error?

This error is totally expected—you've hit GridDB's default length limit for STRING columns in version 5.x. By default, a STRING column in GridDB 5.x is capped at 1,048,576 bytes (1MB). That's exactly why your 1MB test string worked without a hitch, but the 10MB one threw the DS_TIM_ROW_DATA_INVALID error.

What are the official limits for STRING columns in GridDB 5.x?

  • Default max length: 1MB (1,048,576 bytes)
  • Maximum configurable length: 32,767,000 bytes (roughly 32MB) — this is a hard cap, you can't set a STRING column to be larger than this value.

How to fix your issue

You have two solid options depending on your long-term needs:

1. Explicitly increase the STRING column's max length

When defining your column info, use the overloaded constructor that lets you set a custom max length. For your 10MB use case, this would work perfectly:

containerInfo.setColumnInfoList(Arrays.asList(
    new ColumnInfo("id", GSType.STRING),
    new ColumnInfo("payload", GSType.STRING, 10 * 1024 * 1024) // 配置10MB的上限
));

Just remember not to exceed the 32MB hard cap for STRING columns.

2. Switch to BLOB type for larger content

If you might need to store content bigger than 32MB later on, use the BLOB type instead. BLOB is purpose-built for large binary data and supports up to 1GB (1024MB) per value. Here's how to adjust your code:
First, update the column definition:

containerInfo.setColumnInfoList(Arrays.asList(
    new ColumnInfo("id", GSType.STRING),
    new ColumnInfo("payload", GSType.BLOB)
));

Then, convert your string to a byte array when inserting:

Row row = container.createRow();
row.setString(0, "device-1");
// 用统一的字符集将字符串转成字节数组
row.setBlob(1, payload.getBytes(StandardCharsets.UTF_8));
container.put(row);

A few quick notes to keep in mind

  • Even if you bump up the STRING limit, keep in mind that large strings can slow down read/write performance and take up more cluster storage. Try to keep content as lean as possible if performance is a top priority.
  • The row key limit isn't an issue here (your "device-1" is way under the cap), but just a heads-up: row keys for COLLECTION containers have their own 1MB default limit too.

That should clear up the confusion and get your large content into GridDB smoothly!

火山引擎 最新活动