Важно, чтобы ваши типы данных были правильными.
То, что вы описываете, является многочастным ключом. Поэтому используйте многочастный ключ. Не пытайтесь закодировать все в волшебное целое, вы будете отравлять остальную часть вашего кода.
Если запись идентифицирована (entity_id,version_number)
, тогда обнимайте это описание и используйте его напрямую, вместо того, чтобы изменять значение ваших ключей. Вам придется писать запросы, которые ограничивают номер версии, но это нормально. Базы данных хороши в этом.
version_number
может быть временной меткой, как предлагает a_horse_with_no_name. Это неплохая идея. Не существует значимого недостатка производительности для использования временных меток вместо простых целых чисел. Вы получаете значение , что более важно.
Вы могли бы поддерживать таблицу «последней версии», которая содержит для каждого entity_id
только запись с самым большим количеством файлов, недавний version_number
. Это будет больше для вас, так что сделайте это, только если вам действительно нужна производительность.
Да, проблема решена.
Моя проблема заключалась в том, что у меня было слишком мало данных, и спарк ждал, когда будет больше данных для записи файла паркета.
Чтобы сделать эту работу, я использую комментарий @AlexandrosBiratsis (измените размер блока)
Еще раз все благодарю @AlexandrosBiratsis большое спасибо