Skip to content

Start of main content

Talks

  • Making a desktop IDE distributed and collaborative

    LanguageEN

    In the year 2021, two particular features landed in the IntelliJ family of JetBrains IDEs. Code With Me – the ability to invite and collaborate with others on the same project. Remote development is the feature that allows launching the IDE as a backend on a remote machine or a cloud that users can get access to instead of setting up and developing code locally. While the product-wise and usage differences are clear, they have a lot in common from the IDE synchronization perspective and are created using the same technologies.

    In this talk, we’ll be exploring the way such synchronization is performed, how one can separate an extremely big and complex system with tons of plugins into several parts; and what it takes to transform a single-user desktop application into a server capable of handling multiple clients.

    • #remote-development
    • #collaborative-editng,
    • #splitting-up-big-project

  • Thread pools: variety of algorithms and features

    LanguageRU

    This talk will help you dive into the various algorithms that have been implemented in Java, .NET, and other runtimes. We will consider the tasks they solve and learn to understand problem areas. Also, solving certain tasks, we will create our own thread pool, after which we will achieve its maximum performance.

    • #concurrency
    • #scheduling

  • Exploring Traffic Jams in Your Data Flows

    LanguageRU

    In the real world, there's a phenomenon called a “phantom traffic jam” or a “traffic wave.” This is when there is a standing compression wave in automobile traffic, even though there is no accident, lane closure, or other incident that would cause the traffic jam. A similar phenomenon is possible in computer networking or storage I/O, where your data can slow down for no apparent reason. In this talk, Pavel is going to describe when and how this effect can arise and what can be done to discover it.

    • #performance
    • #IO
    • #simulation
    • #queuing theory
    • #seastar
    • #dispatching
    • #queues
    • #QoS

  • A sledgehammer to crack a nut: why blockchain is not (always) a good idea

    LanguageEN

    In this short talk, we are going to discuss two somewhat provocative claims. First, cryptocurrency, the most popular application of blockchain technology, can be implemented in a much simpler and more efficient way. Second, the permissionless setting with mutual distrust, assumed by conventional blockchain implementations, is way too pessimistic in most cases. We then show how the two observations can help in designing efficient and robust replicated services.

    • #blockchain
    • #consensus
    • #cryptocurrency
    • #asynchrony

  • OK S3

    LanguageRU

    Vadim will describe implementation of S3 compatible storage service based on blob and NewSQL storages at Odnoklassniki. The talk will cover the architecture and data model, features and trade-offs, performance and optimization, some intricacies and surprises. The ideas and experience presented in the talk might be useful to designers and developers of distributed storage services, especially S3-compatible and/or Cassandra-based ones.

    • How ScyllaDB makes LSM-tree compaction state-of-art by leveraging RUM conjecture and controller theory

      LanguageEN

      LSM-tree storage engines are known for providing very fast write throughput, as they allow new data to be flushed into immutable files called Sorted String Table, a.k.a. SSTable. But there's no such thing as a free lunch. This append-only nature of the LSM tree generates read amplification over time, because a given key can be redundantly stored across multiple immutable files. That's the reason storage engines have to employ a background compaction process, to reduce both read and space amplification.

      • #database
      • #LSM
      • #internals
      • #storage

    • Self-stabilizing Population Protocols

      LanguageEN

      Focusing on resources of memory and time, we will discuss how efficiently tasks can be solved when facing transient faults modeled by means of self-stabilization. The talk will give an overview of the related work and focus on several fundamental tasks like counting, naming, and leader election.

      • #distributed
      • #communication
      • #protocols

    • Opening

      LanguageRU

      We will talk about the schedule, sessions, and share the information. Join the broadcast to find out what's on the air soon!

      • Distributed transactions implementation trade-offs

        LanguageRU

        This is educational first speech. Let's see why ACID transaction properties are important and how they are implemented in distributed databases with sharding and replication. What about geo-distributed databases? Is it possible to achieve fault tolerance (high availability) and support strong consistency in such databases. What are trade offs for performance. discuss famous CAP theorem and what it means for data indexing and DB transactions.

         

        • #transactions
        • #consistency
        • #timeoracles

      • Parallel Asynchronous Replication between YDB Database Instances

        LanguageEN

        Asynchronous replication is a well-known technique to provide an independent replica of a database for different purposes including disaster recovery, geo-replication or scaling read workload. Traditionally, a log of changes from source replica is treated as an input for target replica database. If source and target replicas are distributed databases that handle high workload, putting all updates to a single log of changes could be nearly impossible. 

        • #distributed
        • #database
        • #replication
        • #change-data-capture
        • #open-source
        • Andrey Fomichev
        • Ilnaz Nizametdinov
        • Aleksei Nikolaevskii

      • HTAP Workloads: Challenges and Solutions

        LanguageEN

        In this talk, we consider challenges posed to modern DMBS by so-called HTAP workloads. HTAP (Hybrid Transactional & Analytical Processing) combines:

        1. Fast OLTP-style requests that should be executed with maximal throughput and reasonably low latency.
        2. OLAP-style analytical queries that require reading a lot of rows to be executed.

        As a solution to this question, we consider several approaches: persistent-parallel trees, fork+COW approach (from HyPer), MVCC, and HTAP-aware LSM tree (from LASER).

        • #databases
        • #concurrency
        • #algorithms

      • What about Binary Search Trees?

        LanguageEN

        In this talk, we cover how to design concurrent Binary Search Trees starting from the simplest ones. Hopefully, after this talk, the attendee will understand the standard tricks necessary for the implementation of Binary Search Trees. These tricks are important and can help to implement other more complex data structures.

        • #theory
        • #data-structures

      • Scaling Raft

        LanguageEN

        In this talk, Konstantin will discuss the challenges of supporting hundreds of instances of the Raft protocol on a single node and how we were able to significantly reduce the static burden on the network and disk each Raft group creates by sharing the work of failure detection and persistence between multiple groups.

        • #consensus
        • #consistency
        • #databases
        • #CAP

      • Solving Raft's practical problems in Tarantool. What, how and why

        LanguageRU

        Speakers began implementing Raft in Tarantool with somewhat inflated expectations:

        • expected the leader to be persistent, as long as it was alive and connected to most nodes;
        • expected that it would be impossible to get an "I am the leader" message from multiple nodes at the same time;
        • wanted a new leader to show up as quickly as possible if the leader failed;
          wanted to be able to go into "crash mode" where the cluster was writable even after more than half of the nodes had been lost.

        In fact, Raft promises none of these things. And to get it, it is necessary to implement some add-ons, about which we will talk.

        • #consensus
        • #consistency
        • #databases
        • #CAP