Demo Data from EDBT 2026 / reviewers in the wild / expert
Mark Marchukov
dblp:62/3504
· DBLP profile ↗
4ranked-venue papers
0as first author
0since 2021 · last 2013
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2Systems, architecture and hardware · 1Databases, data management, data science and information retrieval · 1
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Databases, data mining, and information retrieval
2 papers |
Graph data management · 62% Distributed and cloud data management · 29% Data models and query languages · 9% | |
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Storage systems · 77% Cloud and datacenter computing · 23% | |
| Software engineering, system software, and programming languages
2 papers |
Requirements engineering and software design · 100% |
Topics — the 4 heaviest of 8, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Storage systems
distributed storage |
0.2 | 1 | 2013 | TAO: Facebook's Distributed Data Store for the Social Graph · USENIX ATC 2013 |
Cloud and datacenter computing
datacenter storage |
0.0 | 1 | 2013 | TAO: Facebook's Distributed Data Store for the Social Graph · USENIX ATC 2013 |
Requirements engineering and software design
software architecture |
0.0 | 2 | 1999 | Analysis of a Conflict between Aggregation and Interface Negotiation in Microsoft's Component Object Model · IEEE Trans. Software Eng. 1999 Using Formal Methods to Reason about Architectural Standards · ICSE 1997 |
Requirements engineering and software design › software architecture › component-based software engineering
component integration |
0.0 | 1 | 1999 | Analysis of a Conflict between Aggregation and Interface Negotiation in Microsoft's Component Object Model · IEEE Trans. Software Eng. 1999 |
Methods — techniques the papers use, named apart from their topics
distributed implementation · 0.1formal analysis · 0.0review validation · 0.0formal theory · 0.0formal methods · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2013 | TAO: Facebook's Distributed Data Store for the Social Graph
Nathan Bronson, Zach Amsden, George Cabrera, Prasad Chakka, Peter Dimov, Jack Ferris, Anthony Giardullo, Sachin Kulkarni, Harry C. Li, Mark Marchukov, Dmitri Petrov, Lovro Puzar, Yee Jiun Song, Venkateshwaran Venkataramani |
USENIX ATC | 11 |
| 2012 | TAO: how facebook serves the social graphabstractOver 800 million people around the world share their social interactions with friends on Facebook, providing a rich body of information referred to as the social graph. In this talk, I describe how we model and serve this graph. Our model uses typed nodes (fbobjects) and edges (associations) to express the relationships and actions that happen on Facebook. We access the graph via a simple API that provides queries over the set of same-typed associations leaving an object. We have found this API to be both sufficiently expressive and amenable to a scalable implementation. In the last segment of the talk I describe the design of TAO, our graph data store. TAO is a distributed implementation of the fbobject and association API that has been serving production traffic at Facebook for more than 2 years. Venkateshwaran Venkataramani, Zach Amsden, Nathan Bronson, George Cabrera, Prasad Chakka, Peter Dimov, Jack Ferris, Anthony Giardullo, Jeremy Hoon, Sachin Kulkarni, Nathan Lawrence, Mark Marchukov, Dmitri Petrov, Lovro Puzar |
SIGMOD Conference | 13 |
| 1999 | Analysis of a Conflict between Aggregation and Interface Negotiation in Microsoft's Component Object ModelabstractMany software projects today are based on the integration of independently designed software components that are acquired on the market, rather than developed within the projects themselves. A component standard, or integration architecture, is a set of design rules meant to ensure that such components can be integrated in defined ways without undue effort. The rules of a component standard define, among other things, component interoperability and composition mechanisms. Understanding the properties of such mechanisms and interactions between them is important for the successful development and integration of software components, as well as for the evolution of component standards. The paper presents a rigorous analysis of two such mechanisms: component aggregation and dynamic interface negotiation, which were first introduced in Microsoft's Component Object Model (COM). We show that interface negotiation does not function properly within COM aggregation boundaries. In particular, interface negotiation generally cannot be used to determine the identity and set of interfaces of aggregated components. This complicates integration within aggregates. We provide a mediator-based example, and show that the problem is in the sharing of interfaces inherent in COM aggregation. Kevin J. Sullivan, Mark Marchukov, John Socha |
IEEE Trans. Software Eng. | 2 |
| 1997 | Using Formal Methods to Reason about Architectural StandardsabstractWe present a study in which we used formal methods to reason precisely about aspects of a widely used software architectural standard, namely Microsoft's Component Object Model (COM).We developed a formal theory of COM to help us reason about a proposed compositional architectural style based on COM, intended for use in a novel commercial multimedia authoring system.The style combined COM objects, integration mediators, and the COM reuse mechanism of aggregation.Our use of formal methods averted an architectural disaster by revealing essential but subtle and counterintuitive properties of COM.We partially validated our theory by subjecting it to review by the designers of COM and by testing it against other available data.The theory has good evidential support. Kevin J. Sullivan, John Socha, Mark Marchukov |
ICSE | 3 |