Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: regionserver
    • Labels:
      None

      Description

      For tracking serving timeranged reads portion of HBASE-6752.

        Activity

        Hide
        Nicolas Liochon added a comment -

        If we want to do this while keeping consistency, an option it to add set a configurable time barrier, to make impossible to send a put with an older timestamp than this barrier. This would be either a fixed one updated by the client, or a mobile one (ex: 15 minutes ago). This barrier could only be incremented.

        So:

        • on a put, the region server would check than the put does not contain a timestamp older than the barrier.

        This would allow:

        • coupled with HBASE-5930 (Periodically flush the Memstore), to do reads directly on the HFiles without compromising consistency;
        • during recovery (or if recovery is slowed down because some blocks are corrupted) to continue to read, once the region is allocated again.

        As a consequence, we would be able to continue to write and to read when there is a crash.

        This is in the same area as HBASE-2357, but simpler as we address only a subset of reads (the timeranged ones).

        Show
        Nicolas Liochon added a comment - If we want to do this while keeping consistency, an option it to add set a configurable time barrier, to make impossible to send a put with an older timestamp than this barrier. This would be either a fixed one updated by the client, or a mobile one (ex: 15 minutes ago). This barrier could only be incremented. So: on a put, the region server would check than the put does not contain a timestamp older than the barrier. This would allow: coupled with HBASE-5930 (Periodically flush the Memstore), to do reads directly on the HFiles without compromising consistency; during recovery (or if recovery is slowed down because some blocks are corrupted) to continue to read, once the region is allocated again. As a consequence, we would be able to continue to write and to read when there is a crash. This is in the same area as HBASE-2357 , but simpler as we address only a subset of reads (the timeranged ones).
        Hide
        Devaraj Das added a comment -

        Interesting.. Just to clarify - would the barrier be older than or equal to the minimum time between flushes (as in HBASE-5930)? That is, I should be able to read data older than or equal to data that was last flushed..

        Show
        Devaraj Das added a comment - Interesting.. Just to clarify - would the barrier be older than or equal to the minimum time between flushes (as in HBASE-5930 )? That is, I should be able to read data older than or equal to data that was last flushed..
        Hide
        Nicolas Liochon added a comment -

        Devaraj Das
        Yes, if we want to take full advantage of this. I don't think it has to be mandatory, it just has to be a best effort (I.e. we can see the date of the last flush, and if it's compatible, allows the timeranged read).

        Show
        Nicolas Liochon added a comment - Devaraj Das Yes, if we want to take full advantage of this. I don't think it has to be mandatory, it just has to be a best effort (I.e. we can see the date of the last flush, and if it's compatible, allows the timeranged read).

          People

          • Assignee:
            Unassigned
            Reporter:
            Gregory Chanan
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development