jm + peter-bailis   6

[no title]
'For decades, the transaction concept has played a central role in
database research and development. Despite this prominence, transactional
databases today often surface much weaker models than the
classic serializable isolation guarantee—and, by default, far weaker
models than alternative,“strong but not serializable” models such as
Snapshot Isolation. Moreover, the transaction concept requires the
programmer’s involvement: should an application programmer fail
to correctly use transactions by appropriately encapsulating functionality,
even serializable transactions will expose programmers
to errors. While many errors arising from these practices may be
masked by low concurrency during normal operation, they are susceptible
to occur during periods of abnormally high concurrency. By
triggering these errors via concurrent access in a deliberate attack, a
determined adversary could systematically exploit them for gain.
In this work, we defined the problem of ACIDRain attacks and
introduced 2AD, a lightweight dynamic analysis tool that uses traces
of normal database activity to detect possible anomalous behavior
in applications. To enable 2AD, we extended Adya’s theory of weak
isolation to allow efficient reasoning over the space of all possible
concurrent executions of a set of transactions based on a concrete
history, via a new concept called an abstract history, which also
applies to API calls. We then applied 2AD analysis to twelve popular
self-hosted eCommerce applications, finding 22 vulnerabilities
spread across all but one application we tested, affecting over 50%
of eCommerce sites on the Internet today.

We believe that the magnitude and the prevalence of these vulnerabilities
to ACIDRain attacks merits a broader reconsideration of
the success of the transaction concept as employed by programmers
today, in addition to further pursuit of research in this direction.
Based on our early experiences both performing ACIDRain attacks
on self-hosted applications as well as engaging with developers, we
believe there is considerable work to be done in raising awareness
of these attacks—for example, via improved analyses and additional
2AD refinement rules (including analysis of source code to
better highlight sources of error)—and in automated methods for defending
against these attacks—for example, by synthesizing repairs
such as automated isolation level tuning and selective application
of SELECT FOR UPDATE mechanisms. Our results here—as well as
existing instances of ACIDRain attacks in the wild—suggest there
is considerable value at stake.'
databases  transactions  vulnerability  security  acidrain  peter-bailis  storage  isolation  acid 
4 weeks ago by jm
ASAP: Automatic Smoothing for Attention Prioritization in Streaming Time Series Visualization
Peter Bailis strikes again.

'Time series visualization of streaming telemetry (i.e., charting of
key metrics such as server load over time) is increasingly prevalent
in recent application deployments. Existing systems simply plot the
raw data streams as they arrive, potentially obscuring large-scale
deviations due to local variance and noise. We propose an alternative:
to better prioritize attention in time series exploration and
monitoring visualizations, smooth the time series as much as possible
to remove noise while still retaining large-scale structure. We
develop a new technique for automatically smoothing streaming
time series that adaptively optimizes this trade-off between noise
reduction (i.e., variance) and outlier retention (i.e., kurtosis). We
introduce metrics to quantitatively assess the quality of the choice
of smoothing parameter and provide an efficient streaming analytics
operator, ASAP, that optimizes these metrics by combining techniques
from stream processing, user interface design, and signal
processing via a novel autocorrelation-based pruning strategy and
pixel-aware preaggregation. We demonstrate that ASAP is able to
improve users’ accuracy in identifying significant deviations in time
series by up to 38.4% while reducing response times by up to 44.3%.
Moreover, ASAP delivers these results several orders of magnitude
faster than alternative optimization strategies.'
dataviz  graphs  metrics  peter-bailis  asap  smoothing  aggregation  time-series  tsd 
6 weeks ago by jm
Understanding weak isolation is a serious problem
Peter Bailis complaining about the horrors of modern transactional databases and their unserializability, which noone seems to be paying attention to:

'As you’re probably aware, there’s an ongoing and often lively debate between transactional adherents and more recent “NoSQL” upstarts about related issues of usability, data corruption, and performance. But, in contrast, many of these transactional inherents and the research community as a whole have effectively ignored weak isolation — even in a single server setting and despite the fact that literally millions of businesses today depend on weak isolation and that many of these isolation levels have been around for almost three decades.'

'Despite the ubiquity of weak isolation, I haven’t found a database architect, researcher, or user who’s been able to offer an explanation of when, and, probably more importantly, why isolation models such as Read Committed are sufficient for correct execution. It’s reasonably well known that these weak isolation models represent “ACID in practice,” but I don’t think we have any real understanding of how so many applications are seemingly (!?) okay running under them. (If you haven’t seen these models before, they’re a little weird. For example, Read Committed isolation generally prevents users from reading uncommitted or non-final writes but allows a number of bad things to happen, like lost updates during concurrent read-modify-write operations. Why is this apparently okay for many applications?)'
acid  consistency  databases  peter-bailis  transactional  corruption  serializability  isolation  reliability 
september 2014 by jm
Scalable Atomic Visibility with RAMP Transactions
Great new distcomp protocol work from Peter Bailis et al:
We’ve developed three new algorithms—called Read Atomic Multi-Partition (RAMP) Transactions—for ensuring atomic visibility in partitioned (sharded) databases: either all of a transaction’s updates are observed, or none are. [...]

How they work: RAMP transactions allow readers and writers to proceed concurrently. Operations race, but readers autonomously detect the races and repair any non-atomic reads. The write protocol ensures readers never stall waiting for writes to arrive.

Why they scale: Clients can’t cause other clients to stall (via synchronization independence) and clients only have to contact the servers responsible for items in their transactions (via partition independence). As a consequence, there’s no mutual exclusion or synchronous coordination across servers.

The end result: RAMP transactions outperform existing approaches across a variety of workloads, and, for a workload of 95% reads, RAMP transactions scale to over 7 million ops/second on 100 servers at less than 5% overhead.
scale  synchronization  databases  distcomp  distributed  ramp  transactions  scalability  peter-bailis  protocols  sharding  concurrency  atomic  partitions 
april 2014 by jm
Non-blocking transactional atomicity
interesting new distributed atomic transaction algorithm from Peter Bailis
algorithms  database  distributed  scalability  storage  peter-bailis  distcomp 
october 2013 by jm
_Bolt-On Causal Consistency_ [slides]
SIGMOD 2013 presentation from Peter Bailis, Ali Ghodsi, Joseph M. Hellerstein, Ion Stoica -- adding consistency to an eventually-consistent store by tracking dependencies
eventual-consistency  state  cap-theorem  storage  peter-bailis 
june 2013 by jm

Copy this bookmark: