Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upload to GCS performance improvement for large parts #1028

Open
Vytenis-Valutkevicius opened this issue Oct 18, 2024 · 2 comments
Open

Upload to GCS performance improvement for large parts #1028

Vytenis-Valutkevicius opened this issue Oct 18, 2024 · 2 comments
Milestone

Comments

@Vytenis-Valutkevicius
Copy link

Background:
In our ClickHouse cluster we have several larger tables with rather small number of parts.
For example table of approximately 400GB size and around 20 parts. This means that some parts might have a size of around 150GB. For backup uploads to GCS Buckets this means that these larger parts currently are uploaded as a single stream and these uploads might take a multiple hours to complete (backup process sometimes takes over 12 hours).

Suggestion:
To improve upload to GCS performance I would suggest to implement multipart parallel uploads to GSS buckets. This should be possible to accomplish with Google XML API - https://cloud.google.com/storage/docs/xml-api/post-object-multipart
However, Google storage SDK used for uploads has this open issue googleapis/google-cloud-go#3219. Suggesting that parallel multipart upload should be implemented into storage SDK Transfer Manager class. This would simplify the parallel multipart implementation for large table parts.

In general my questions in this would be as follows:

  • Is this something you are aware about?
  • Could this be a future candidate for improvement?
  • If needed we could provide some possible workarounds we are looking into.
@eidmantas
Copy link

Also to mention. We started investigating this due to running out of disk space. For that we recommend to look at the --delete-source flag if that suits your application. Non the less a huge performance boost would be very beneficial without working around reorganising the sizing and structure of our table/part strategy.

@Slach
Copy link
Collaborator

Slach commented Oct 18, 2024

@Vytenis-Valutkevicius

Is this something you are aware about?

yes, we are aware about upload speed.
and yes, we watch to googleapis/google-cloud-go#3219, unfortunately no progress from Google for a long time,
maybe I understand SDK behavior wrong, in any case,

Could this be a future candidate for improvement?

yes, we are welcome to pull requests

If needed we could provide some possible workarounds we are looking into.

As possible workaround, you could use remote_storage: custom and gcloud as transfer utility
Look examples for rsync in https://github.com/Altinity/clickhouse-backup/tree/master/test/integration/rsync/ and https://github.com/Altinity/clickhouse-backup/blob/master/test/integration/config-custom-rsync.yml

you need write list.sh, download.sh, upload.sh, delete.sh for using gcloud

@Slach Slach added this to the 2.7.0 milestone Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants