Подход, который вы изложили, достаточно хорош. HBase является столбчатым и может использовать префиксное сжатие, которое в сочетании со сжатием блоков gzip гарантирует, что размер на диске не будет вдвое больше вашего полезного размера данных.
На самом деле, даже если бы у вас был способ сохранить одну строку с двумя разными столбцами (и выполнить запрос, который вы хотите сделать), HBase все равно будет хранить ключ строки дважды для каждого столбца внутри. Посмотрите на мой ответ здесь для примера того, как HBase хранит данные в HFile. Короче говоря, HBase хранит ключ полной строки с каждым отдельным значением (хотя сжатие префикса заботится об амортизации этой стоимости). Вы найдете похожую модель хранения в большинстве столбцовых баз данных, главным образом, из-за того, что они столбчатые и должны хранить ключ строки с каждым столбцом.
Итак, чтобы ответить на ваш вопрос, ваш подход идеально подходит. Хотя я бы добавил исходные идентификаторы столбцов, разделенные разделителем (вместо случайной строки), в ключ строки на случай, если в будущем вам потребуется выбрать значение только для одного из столбцов. Более того, поместите идентификаторы столбцов в качестве префикса (а не суффикса) ключа строки, а затем вы можете передать фильтры ключа строки (разделенные ИЛИ) и ваши шкалы настройки для любого числа столбцов, где вы можете выбрать подмножество столбцов и при этом сохранить производительность.
Альтернативный подход к его просмотру - использование мощности HBase для выполнения миллионов записей в секунду, но при этом сохраняется исходное реляционное представление при запросе данных. По сути, это означает, что вам нужны вторичные индексы по интересующим столбцам. Apache Phoenix предоставляет все это вам поверх HBase; Это очень активный проект, который обеспечивает лучшее из обоих миров (интенсивная запись HBase и SQL-подобных фильтров) с добавленной стоимостью хранения вторичных индексов (которые вы в любом случае платите в любой реляционной базе данных).