Pith. sign in

REVIEW 4 major objections 5 minor 41 references

WiSer: A Highly Available HTAP DBMS for IoT Applications

T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read WiSer claims that splitting commit into a coordinator-free PROMISE and a consensus-based SERIALIZE delivers consistency with availability in an unsharded HTAP system.

desk verdict A clever PROMISE/SERIALIZE split for HTAP without sharding, but the 'highly available' claim is not backed by failure or partition experiments and sits awkwardly with Section 2.3's admission that node departures are not directly supported. read the letter →

arxiv 1908.01908 v1 pith:EV55WXWF submitted 2019-08-06 cs.DB

Ronald Barber , Christian Garcia-Arellano , Ronen Grosman , Guy Lohman , C. Mohan , Rene Muller , Hamid Pirahesh , Vijayshankar Raman
show 5 more authors
Richard Sidle Adam Storm Yuanyuan Tian Pinar Tozun Yingjun Wu
This is my paper · ORCID
classification cs.DB
keywords distributedtransactionsHTAPconsensusserializablecommitaggregationconstraintsavailabilityread-writeconflictsRaft
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that the traditional requirement that write transactions synchronize with a coordinator before commit is what forces distributed databases to choose between consistency and availability. WiSer instead splits commit into PROMISE, a durable local acknowledgment that needs no coordinator, and SERIALIZE, a consensus step that fixes the transaction's position in the serial order. This split, the paper claims, gives applications the fast local response they need while still delivering serializability, and it lets a single unsharded system enforce aggregation constraints by resolving conflicts and constraint violations lazily on the serialized state. If the design holds up, IoT applications would no longer need escrow logic or sharding to keep global invariants such as non-negative inventory.

What carries the argument

The load-bearing mechanism is the symbolic commit: a delta that carries three unresolved placeholders—its position in the serial order, its read-write conflict status, and its aggregation-constraint status—all of which are settled after SERIALIZE. Supporting that mechanism is a data representation in which transaction deltas, including read-sets, are appended to node-local logs, rows are stamped with their serialization sequence number at publish time, and the only consensus log in the system tracks serializer elections rather than data changes. That separation is what turns ordering into a consensus problem while keeping data movement out of the consensus path, and it is what makes lazy, parallel conflict and constraint resolution possible.

What would settle it

Run WiSer under a network partition that separates a transaction node from the current SERIALIZER but not from its own replicas: if no transaction on the partitioned side can ever complete SERIALIZE while the partition persists, then the PROMISE step alone does not deliver availability under the partition, and the availability claim is refuted.

Watch

Extended reading notes

Core claim

In WiSer's own terms, a transaction is durably recorded at PROMISE without any global coordination, and its delta is later assigned a serialization sequence number by a lightweight Raft log that records only serializer elections, not user data. Because each delta embeds the transaction's read-set and each published row carries its serialization sequence number, the state at the serialization frontier is deterministic; read-write conflicts and aggregation constraint violations can therefore be checked in background, on a non-changing state, and the system need not lock or escrow anything at transaction time. The result is meant to be consistency with availability: strict serializability is available to applications that wait for SERIALIZE, while the PROMISE step provides the fast acknowledgment that interactive and IoT-facing applications expect.

Load-bearing premise

The load-bearing premise is that a PROMISE acknowledgment from a quorum of replicas, made without contacting the coordinator, provides meaningful availability even though the transaction's true outcome remains undecided until the later SERIALIZE step.

Editorial extensions

If this is right

  • Applications can acknowledge a transaction's durability locally at PROMISE and still receive full serializability if they wait for SERIALIZE.
  • Aggregation constraints like non-negative inventory can be enforced by the DBMS in the background, removing the need for escrow mechanisms and compensating application code.
  • Because conflict resolution runs on a deterministic, non-changing state after SERIALIZE, it can be parallelized across nodes and can keep up with transaction rates using streaming queries.
  • Read-write conflicts, including phantoms from range predicates, are handled by comparing embedded read-sets against writes after ordering, avoiding lock-table scans of the database.
  • Serialization cost is independent of transaction load, so throughput scales by adding transaction nodes, subject to the publish bottleneck the paper reports.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The availability delivered by PROMISE is narrower than a classic commit: the client knows the delta is durably stored but cannot act on the outcome until SERIALIZE, so the practical gain is reduced blocking rather than early knowledge of commit.
  • The same split could be adapted to geo-replicated settings by letting multiple serializers order batches by timestamps, but the paper only sketches a single elected serializer and does not analyze such configurations.
  • The paper's own experiments show publish is the throughput bottleneck; a natural test is whether batching or columnar reorganization at publish, rather than consensus, dominates end-to-end latency as nodes scale.
  • Read-sets stored as 64-bit hashes will cause some false-positive rollbacks, so measuring that rate against exact key sets would quantify the cost of the approximate representation the paper acknowledges.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents WiSer, a distributed HTAP DBMS that splits transaction commit into a PROMISE stage, during which a transaction's delta is durably replicated to a quorum of nodes without contacting a global coordinator, and a SERIALIZE stage, during which a small Raft-log-based consensus procedure fixes the transaction's position in the serial order. The system embeds read-sets and snapshots into transaction deltas, stores all system and database state in tables, and resolves read-write conflicts and aggregation constraints lazily after serialization. The paper claims that this design provides consistency with high availability, avoids sharding, and enforces aggregation constraints efficiently, and it reports throughput and latency experiments on a healthy 28-node cluster.

Significance. The PROMISE/SERIALIZE decomposition is a genuinely interesting architectural idea that separates client-visible acknowledgment from final serializable commitment, and the 'all state in tables' principle is a clean way to reason about metadata and failure. The work targets a real and current problem—HTAP with aggregation constraints in distributed settings—and the healthy-cluster experiments show good scaling. However, the central availability claim is not demonstrated: node departures are explicitly unsupported, no failure or partition experiments are reported, and the lazy constraint-resolution protocol has a potential correctness gap involving transactions that read data later removed by constraint rollbacks. If these issues are resolved, the work would be a solid contribution to HTAP and transaction-processing design.

major comments (4)
  1. [Section 2.3 and Abstract] The abstract states that WiSer 'covers node joins and departures as database tables,' but Section 2.3 says 'Node departures from the network are not supported directly' and describes no mechanism for replicas to advance the subchain of an unresponsive node or to deliver a final status to clients. Because PROMISE can return to a client before SERIALIZE, a transaction acknowledged at PROMISE on a node that subsequently fails may never be serialized or rolled back. The paper therefore does not establish the liveness of PROMISE-completed transactions under node failure, which directly undermines the central 'high availability' claim. This must be addressed either by adding a concrete recovery protocol or by substantially softening the availability claim.
  2. [Section 5] None of the experiments in Section 5 exercise node failure, network partition, or node departure; all measurements in Figures 4–8 are taken on healthy clusters. The abstract and introduction promise availability benefits from PROMISE, but the paper provides no experimental evidence that PROMISE completes in scenarios where a coordinator-based system would block, nor does it analyze the quorum requirement: PROMISE still needs a quorum of replicas, so under a majority partition it cannot complete for at least some nodes. A microbenchmark with injected partitions, and an explicit statement of the partition behavior, are needed to make the HA claim credible.
  3. [Section 4.1 and Section 2.1 Stage 5] Constraint resolution can roll back transactions after SERIALIZE, but the paper does not describe how this interacts with already-resolved read-write conflicts. A transaction T2 that is serialized after a constraint-violating transaction T1 may have read T1's writes and have been marked conflict-free at CONFLICT RESOLVE time. If T1 is later removed via the ConstraintFailures table, T2's read result changes, yet T2 is not re-examined. The statement in Section 4.1 that removing violating transactions 'only moves the running aggregate in a beneficial direction, so it is safe for other nodes to ignore this effect' addresses only the aggregate value, not the correctness of previously published transactions that depend on the removed writes. This is a load-bearing correctness gap: the paper needs either a cascading rollback protocol, a re-evaluation of conflict status after constraint resolution, or a proof that such dependencies cannot occur in the proposed execution model.
  4. [Section 2.1 Stage 1 and Section 1.2.1] The paper's terminology conflates 'commit' with 'PROMISE.' A transaction that completes PROMISE is acknowledged durably, but its final outcome is not known until SERIALIZE, and it may later roll back due to conflicts or constraint violations. The claim that 'the semantics upon such a time-out is identical to that of time-out at commit in a classical DBMS' is not argued: in a classical DBMS, an acknowledged commit implies that the transaction is committed and durable, whereas here a PROMISE-acknowledged transaction can later be aborted. The paper should either introduce a clearer term for this intermediate state or provide a precise statement of what the client is guaranteed at each stage, including under a subsequent node failure.
minor comments (5)
  1. [Section 5.2] The text says 'Figure 5 and Figure 5 show...'; the second reference should likely be to Figure 6, which is the plot for the UpdatePrice transaction size of 20.
  2. [Section 1.2.1] The sentence 'Applications requiring strict serializability can stop at SERIALIZE stage' is confusing because the next paragraphs state that the system waits for publish and constraint resolution before returning a status to the client; clarify what 'stop' means for such applications.
  3. [Section 2.1] The sentence 'PROMISE needs no global cluster communication; AP applications stop at this stage' is ambiguous and potentially misleading, because PROMISE still requires a quorum of replicas and the transaction may later roll back. Please rephrase to state exactly what an AP application that 'stops' at PROMISE can rely on.
  4. [Figures 4–8] The figures do not include error bars or any measure of variance. For reproducibility, at least a brief statement of run-to-run variability would be helpful, even if error bars are omitted for readability.
  5. [References] Reference [14] is a vendor white paper; consider citing a peer-reviewed description of FaunaDB if one exists, and ensure all references are complete (for example, [32] and [33] are both listed as SIGMOD 2019 entries but with different formatting).

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation; the availability claim is under-supported but not definitionally forced.

full rationale

The paper contains no fitted-parameter-as-prediction, no load-bearing self-citation chain, and no equation-level reduction of a result to its own inputs. The rollback-rate calculation in Section 5.2 is a transparent probabilistic prediction from stated workload parameters (10/10,000 per-product update probability and 10 reads per NewOrder), matching observed rates without fitting. The design's core mechanisms—embedded read-sets, SSN-stamped rows, lazy conflict and constraint resolvers, and reliance on Raft for serialization—are independent content; Raft is an external consensus protocol with its own liveness properties. The closest concern is that the headline 'consistency with availability' depends on treating PROMISE as the commit step: PROMISE is defined as needing no coordinator, so the availability benefit is a property of the protocol's definition rather than a measured end-to-end guarantee. But the paper is explicit that PROMISE is only a symbolic commit, that final status is fixed only at SERIALIZE, and that transactions may subsequently roll back; Section 2.3 further admits 'Node departures from the network are not supported directly.' These are real gaps in the support for the HA claim and are correctness/scope concerns, not circular derivations. No step reduces by construction to its own input, so no circularity is established.

Assumptions & free parameters 0 free parameters · 5 assumptions · 5 invented entities

The central claims rest on several domain assumptions about consensus, query shape, quorum availability, and commit semantics. There are no free parameters in the traditional sense, since the system design is not a fitted model. The invented entities are all components of the proposed architecture, each lacking independent evidence beyond the paper itself.

assumptions (5)
  • domain assumption Raft consensus produces a correct total order of SERIALIZE events.
    The SERIALIZE stage relies entirely on Raft; the paper cites [23] for its guarantees, but does not prove them in this context or handle leader reconfiguration edge cases.
  • domain assumption Aggregation constraints are algebraic and incrementally maintainable.
    Section 4 limits constraint resolution to algebraic aggregates (sums, counts, averages), so the claim about aggregation constraints only applies to that class.
  • domain assumption Read-sets can be represented as equality/range predicates over key columns or escalated to full table.
    Section 3.1 assumes this representation for conflict detection; queries with arbitrary predicates are outside the design and could produce false negatives.
  • domain assumption PROMISE can always reach a quorum of replicas to harden the delta.
    The availability claim depends on this reachability, but the paper does not analyze partition or node failure cases where no quorum is available.
  • domain assumption Applications accept 'symbolic' commit with possible later rollback and compensation.
    Section 1.1 argues that real-world commits have contingencies, but formalizing this changes the semantics of commit, which may not be acceptable to all applications.
invented entities (5)
  • SerializeFrontiers table
    purpose: Stores the serial order of transaction deltas as batches; used by queries to determine the serialization frontier.
    A new system component with no independent evidence outside the paper's design.
  • ReadWriteSet table
    purpose: Stores transaction read-sets and write primary keys so conflicts can be resolved lazily.
    A new table-based representation for read information; no external validation.
  • PROMISE/SERIALIZE stages
    purpose: Split commit into a local durable promise and a consensus-based serialization to avoid coordinators at commit.
    The central mechanism of the paper, but not a verifiable entity independent of the design.
  • SSN (serialization sequence number)
    purpose: Timestamps each row with its transaction's position in serial order to support antijoins and visibility.
    A novel timestamp concept in this system; no independent evidence.
  • Constraint resolver
    purpose: Runs streaming aggregation queries to enforce constraints lazily after serialization.
    A background process introduced by the paper; efficiency is not independently measured under constraint violations.

how reviews work

0 comments
Cite this review

Pith. "Pith review of WiSer: A Highly Available HTAP DBMS for IoT Applications." pith.science (2026). https://pith.science/paper/EV55WXWF

@misc{pith2026190801908,
  author       = {Pith},
  title        = {Pith review of: WiSer: A Highly Available HTAP DBMS for IoT Applications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EV55WXWF}},
  note         = {Machine review of arXiv:1908.01908}
}
read the original abstract

In a classic transactional distributed database management system (DBMS), write transactions invariably synchronize with a coordinator before final commitment. While enforcing serializability, this model has long been criticized for not satisfying the applications' availability requirements. When entering the era of Internet of Things (IoT), this problem has become more severe, as an increasing number of applications call for the capability of hybrid transactional and analytical processing (HTAP), where aggregation constraints need to be enforced as part of transactions. Current systems work around this by creating escrows, allowing occasional overshoots of constraints, which are handled via compensating application logic. The WiSer DBMS targets consistency with availability, by splitting the database commit into two steps. First, a PROMISE step that corresponds to what humans are used to as commitment, and runs without talking to a coordinator. Second, a SERIALIZE step, that fixes transactions' positions in the serializable order, via a consensus procedure. We achieve this split via a novel data representation that embeds read-sets into transaction deltas, and serialization sequence numbers into table rows. WiSer does no sharding (all nodes can run transactions that modify the entire database), and yet enforces aggregation constraints. Both readwrite conflicts and aggregation constraint violations are resolved lazily in the serialized data. WiSer also covers node joins and departures as database tables, thus simplifying correctness and failure handling. We present the design of WiSer as well as experiments suggesting this approach has promise.

Figures

Figures reproduced from arXiv: 1908.01908 by the authors.

Figure 1
Figure 1. If all state changes (database and system) are in a durable, consis￾tent, HA consensus log, we have a serializable system [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. WiSer puts only the history of state changes in a Raft log, and stores all other information in database tables. consensus operation, whose cost is independent of the transaction load. We have an elected SERIALIZER (or leader), who appends the log-sequence number (LSN) ranges to a broadcasted file every N time intervals, where N is chosen based on the desired latency. Each serialization picks the serial order for al… view at source ↗
Figure 4
Figure 4. NewOrder transaction throughput as a function of nodes, with and without serialization. with no think-time, and no aggregation constraints. Products ta￾ble has 10,000 items, with an index on productId column. Each transaction looks up the current price of 10 products and inserts an order containing those 10 products into Orders table. The values in OrderId column are generated as sequential numbers, and there are no… view at source ↗
Figures from the paper (3 more)
Figure 6
Figure 6. Figure 6: NewOrder transaction throughput as a function of nodes, with UpdatePrice transaction size set to 20. the snapshot that the NewOrder sees will be behind its serialization point by about one UpdatePrice transaction). This expected behavior matches the rollback rate well.…
Figure 7
Figure 7. Figure 7: NewOrder transaction throughput ratio as a function of nodes, with and without publish. 1 10 100 1000 10000 1 2 4 6 8 10 12 Latency (ms) Number of NewOrder Transaction Nodes w/ publish w/o publish [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 8
Figure 8. Figure 8: NewOrder transaction latency as a function of nodes, with and without publish. log). Going to publish pushes the latency to about one second, this is due to overheads in forming Parquet blocks. 6. RELATED WORK WiSer builds on and borrows hugely from the large volume of…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

41 extracted references · 41 canonical work pages

  1. [1]

    WiSer: A Highly Available HTAP DBMS for IoT Applications

    INTRODUCTION For decades, database management systems (DBMSs) have sepa- rated on-line transaction processing (OLTP) from on-line analytics processing (OLAP) in distinct systems. This has been more an engineering compromise than a desirable feature: OLTP systems typically modified small portions of the database and demanded low latency, whereas OLAP system...

    work page Pith review arXiv 1908

  2. [2]

    The chain is in time order, that is, smaller prefixes of the chain correspond to earlier states of the database

    DESIGN We model a database as a logical chain of state modifications, called deltas. The chain is in time order, that is, smaller prefixes of the chain correspond to earlier states of the database. These state modifications are made by programs called transactions that logically read the current database state (the chain prefix up to that modification), and ac...

    work page

  3. [3]

    all state is in tables

    CONFLICT RESOLUTION Conflicts in WiSer are resolved after we have determined a serial order. Thus the resolution problem is simple: the reads in a transac- tion X saw a snapshot that is earlier than where its delta fits in the serial order. X’s delta includesX’s read-set andX’s snapshot (seen SSN). So the CONFLICT RESOLVER needs to traverse the database cha...

    work page

  4. [4]

    These constraints are checked after conflict resolution and after publish, who has stamped each row with the SSN (its position in the serial order)

    CONSTRAINT RESOLUTION We have now built up enough machinery to discuss how aggre- gation constraints are checked. These constraints are checked after conflict resolution and after publish, who has stamped each row with the SSN (its position in the serial order). Logically, constraint resolution is a walk through the published data in SSN order, from the pr...

    work page

  5. [5]

    PERFORMANCE EV ALUATION WiSer is the next version of the Wildfire research prototype [5]. It is a HTAP DBMS that currently supports ingest, via Apache Spark and via a custom API; queries, directly via a SQL dialect, as well as ones pushed-down from Spark, and now multi-statement trans- actions. The last feature is the focus of this section. Transactional c...

    work page

  6. [6]

    RELATED WORK WiSer builds on and borrows hugely from the large volume of literature on transaction processing, where both shared-nothing and shared-storage models have been heavily studied [9, 11]. After many efforts on NoSQL databases that downplayed the importance of consistency, the last decade has seen a renewed in- terest in systems that provide stro...

    work page 2016

  7. [7]

    mission-critical

    CONCLUSIONS AND FUTURE WORK The distributed systems community has developed consensus protocols mostly independently from the database community’s struggles with distributed transactions. We have described one ap- proach to exploiting consensus as the underlying mechanism for transaction serialization, and shown it provides two key benefits: higher availab...

    work page

  8. [8]

    https://parquet.apache.org/

    Apache Paquet. https://parquet.apache.org/

    work page

Show all 41 references
  1. [9]

    Appuswamy, M

    R. Appuswamy, M. Karpathiotakis, D. Porobic, and A. Ailamaki. The Case For Heterogeneous HTAP. In CIDR, 2017

    2017

  2. [10]

    Arulraj, A

    J. Arulraj, A. Pavlo, and P. Menon. Bridging the Archipelago between Row-Stores and Column-Stores for Hybrid Workloads. In SIGMOD, 2016

    2016

  3. [11]

    Barber, C

    R. Barber, C. Garcia-Arellano, R. Grosman, R. Mueller, V . Raman, R. Sidle, M. Spilchen, A. Storm, Y . Tian, P. Tozun, et al. Wildfire: Fast HTAP on a Loosely-Coupled System. In HTPS, 2017

    2017

  4. [12]

    Barber, M

    R. Barber, M. Huras, G. Lohman, C. Mohan, R. Mueller, F. Özcan, H. Pirahesh, V . Raman, R. Sidle, O. Sidorkin, et al. Wildfire: Concurrent Blazing Data Ingest and Analytics. In CIDR, 2016

    2016

  5. [13]

    P. A. Bernstein, C. W. Reid, and S. Das. Hyder-A Transactional Record Manager for Shared Flash. In CIDR, 2011

    2011

  6. [14]

    E. Brewer. CAP 12 years Later: How the rules have changed. IEEE Computer, 45, 2012

    2012

  7. [15]

    E. Brewer. NoSQL: Past, Present, and Future. In QCon SF, 2012

    2012

  8. [16]

    Mohan and B

    C. Mohan and B. Lindsay and R. Obermarck. Transaction management in the R* distributed database management system. In TODS, volume 11

  9. [17]

    J. C. Corbett, J. Dean, M. Epstein, A. Fikes, C. Frost, J. J. Furman, S. Ghemawat, A. Gubarev, C. Heiser, P. Hochschild, et al. Spanner: Google’s globally distributed database.TOCS, 31(3), 2013

    2013

  10. [18]

    Parallel Database Systems: The Future of High Performance Database Systems

    David DeWitt and Jim Gray. Parallel Database Systems: The Future of High Performance Database Systems. In CACM, volume 35

  11. [19]

    Dragojevi ´c, D

    A. Dragojevi ´c, D. Narayanan, E. B. Nightingale, M. Renzelmann, A. Shamis, A. Badam, and M. Castro. No Compromises: Distributed Transactions with Consistency, Availability, and Performance. In SOSP, 2015

    2015

  12. [20]

    Farber, N

    F. Farber, N. May, W. Lehner, P. Grobe, I. Muller, H. Rauhe, and J. Dees. The SAP HANA Database â ˘A¸ S An Architecture Overview

  13. [21]

    M. Freels. FaunaDB: An Architectural Overview. 2018

    2018

  14. [22]

    Harding, D

    R. Harding, D. Van Aken, A. Pavlo, and M. Stonebraker. An Evaluation of Distributed Concurrency Control. PVLDB, 10(5), 2017

    2017

  15. [23]

    Kallman, H

    R. Kallman, H. Kimura, J. Natkins, A. Pavlo, A. Rasin, S. Zdonik, E. P. Jones, S. Madden, M. Stonebraker, Y . Zhang, et al. H-Store: A High-Performance, Distributed Main Memory Transaction Processing System. PVLDB, 1(2), 2008

    2008

  16. [24]

    Kemper and T

    A. Kemper and T. Neumann. Hyper: A hybrid oltp&olap main memory database system based on virtual memory snapshots. In ICDE, 2011

    2011

  17. [25]

    L. Lamport. The Part-Time Parliament. TOCS, 16(2), 1998

    1998

  18. [26]

    Larson, A

    P.-Å. Larson, A. Birka, E. N. Hanson, W. Huang, M. Nowakiewicz, and V . Papadimos. Real-Time Analytical Processing with SQL Server. PVLDB, 8(12), 2015

    2015

  19. [27]

    C. Mohan. ARIES/KVL: A Key-Value Locking Method for Concurrency Control of Multiaction Transactions Operating on B-Tree Indexes. In VLDB, 1990

    1990

  20. [28]

    S. Mu, Y . Cui, Y . Zhang, W. Lloyd, and J. Li. Extracting More Concurrency from Distributed Transactions. In OSDI, 2014

    2014

  21. [29]

    O’Neil, E

    P. O’Neil, E. Cheng, D. Gawlick, and E. O’Neil. The Log-Structured Merge-Tree (LSM-Tree). Acta Informatica, 33(4), 1996

    1996

  22. [30]

    Ongaro and J

    D. Ongaro and J. K. Ousterhout. In Search of an Understandable Consensus Algorithm. In USENIX ATC, 2014

    2014

  23. [31]

    Özcan, Y

    F. Özcan, Y . Tian, and P. Tözün. Hybrid Transactional/Analytical Processing: A Survey. In SIGMOD, 2017

    2017

  24. [32]

    Pavlo, G

    A. Pavlo, G. Angulo, J. Arulraj, H. Lin, J. Lin, L. Ma, P. Menon, T. C. Mowry, M. Perron, I. Quah, et al. Self-Driving Database Management Systems. In CIDR, 2017

    2017

  25. [33]

    Pezzini, D

    M. Pezzini, D. Feinberg, N. Rayner, and R. Edjlali. Hybrid Transaction/Analytical Processing Will Foster Opportunities for Dramatic Business Innovation. https://www.gartner.com/doc/2657815/hybrid-transactionanalytical- processing-foster-opportunities, 2014

    2014

  26. [34]

    J. Rao, E. J. Shekita, and S. Tata. Using Paxos to Build a Scalable, Consistent, and Highly Available Datastore. PVLDB, 4(4), 2011

    2011

  27. [35]

    Stonebraker and A

    M. Stonebraker and A. Weisberg. The V oltDB Main Memory DBMS. IEEE Data Eng. Bull., 36(2), 2013

    2013

  28. [36]

    Thomson, T

    A. Thomson, T. Diamond, S.-C. Weng, K. Ren, P. Shao, and D. J. Abadi. Calvin: Fast Distributed Transactions for Partitioned Database Systems. In SIGMOD, 2012

    2012

  29. [37]

    Y . Wu, J. Arulraj, J. Lin, R. Xian, and A. Pavlo. An Empirical Evaluation of In-Memory Multi-Version Concurrency Control. PVLDB, 10(7), 2017

    2017

  30. [38]

    Y . Wu, W. Guo, C.-Y . Chan, and K.-L. Tan. Fast failure recovery for main-memory dbmss on multicores. In SIGMOD. ACM, 2017

    2017

  31. [39]

    Y . Wu, J. Yu, Y . Tian, R. Sidle, and R. Barber. Designing Succinct Secondary Indexing Mechanism by Exploiting Column Correlations. In SIGMOD, 2019

    2019

  32. [40]

    Y . Wu, J. Yu, Y . Tian, R. Sidle, and R. Barber. HERMIT in Action: Succinct Secondary Indexing Mechanism via Correlation Exploration. volume 12, 2019

    2019

  33. [41]

    Zhang, R

    Y . Zhang, R. Power, S. Zhou, Y . Sovran, M. K. Aguilera, and J. Li. Transaction Chains: Achieving Serializability with Low Latency in Geo-Distributed Storage Systems. In SOSP, 2013

    2013

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.