hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Rodionov <vladrodio...@gmail.com>
Subject Re: Snapshot performance and helper script
Date Wed, 18 May 2016 18:29:03 GMT
Snapshots are light when you take them, but not that light when you export
them. If you do not do export and only need to protect against
user errors - fine, otherwise, bear in mind that export snapshot is M/R job
and it materializes (copies) all your data to another location

Another possible problem with snapshot is eventual data duplication.
Snapshots store references to store files, store files, usually, get
compacted quite often, new files are created, old files get archived and
later deleted. If you have snapshot, all store files it refers to will be
kept in archive until you delete this snapshot.


On Wed, May 18, 2016 at 3:45 AM, thib <thibault.godouet@gresearch.co.uk>

> Hi,
> I am thinking to implement regular snapshots on HBase to protect against
> user mistakes, e.g. if something bad happens go back to the previous
> snapshot.
> I am thinking to keep something as one snapshot per week for four weeks,
> and
> one snapshot a day for 7 days, so always have about 11 snapshots.  Then
> each
> time a new snapshot is created, an old one would be deleted.
> From reading the doc I get the impression that snapshots are quite light to
> take, and have zero on-going performance impact, i.e. HBase will be just as
> fast with 11 snapshots than with none.
> Is that right?
> Am I also right to believe that the extra disk usage be very low in our
> setup where we never deleted any data, just add more?
> Finally, is anyone aware of a tool / helper script to implement such a
> snapshot strategy, before I spend time writing my own?
> Thank you,
> Thibault.
> --
> View this message in context:
> http://apache-hbase.679495.n3.nabble.com/Snapshot-performance-and-helper-script-tp4080073.html
> Sent from the HBase User mailing list archive at Nabble.com.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message