title

text

Александр Спирин
Александр Спирин Лига Цифровой Экономики
Кирилл Калистратов
Кирилл Калистратов InCountry
17:30 04 February
22 мин

PostgreSQL Citus vs MongoDB sharded

We would like to share our test results (including performance testing) of PostgreSQL/Citrus and MongoDB for our company's data. It has been a very exciting process with unexpected turns and a somewhat controversial outcome.

слайды

Видео

Другие доклады

  • Alicja Kucharczyk
    Alicja Kucharczyk Microsoft
    45 мин

    Architecting petabyte-scale analytics by scaling out Postgres on Azure with Citus

    The story about powering a 1.5 petabyte analytics application with 2816 cores and 18.7 TB of memory in the Citus cluster at the Microsoft. The Windows team measures the quality of new software builds by scrutinizing 20,000 diagnostic metrics based on data flowing in from 800 million Windows devices. At the same time, the team evaluates feedback from Microsoft engineers who are using pre-release versions of Windows updates. At Microsoft, the Windows diagnostic metrics are displayed on a real-time analytics dashboard called “Release Quality View” (RQV), which helps the internal “ship-room” team assess the quality of the customer experience before each new Windows update is released. Given the importance of Windows for Microsoft’s customers, the RQV analytics dashboard is a critical tool for Windows engineers, program managers, and execs.

  • Sangwook (Shawn) Kim
    Sangwook (Shawn) Kim Apposha
    45 мин

    Make Your PostgreSQL 10x Faster on Cloud in Minutes

    Cloud storage has some unique characteristics compared to traditional storage mainly because it is virtualized and controlled by software. One example is that AWS EBS shows higher throughput with larger I/O size up to 256 KiB without hurting latency. Hence, a user can get only about 4 MiB/sec with 1,000 IOPS EBS volume if the I/O request size is 4 KiB, whereas a user can get about 250 MiB/sec if the I/O request size is 256 KiB. This is because EBS consumes one I/O in a given IOPS budget for every I/O request regardless of the I/O size (up to 256 KiB). Unfortunately, PostgreSQL cannot exploit the full potential of cloud storage because PostgreSQL has designed without considering the unique characteristics of cloud storage.

    In this talk, I will introduce the AppOS extension that improves the throughput of a write-intensive workload by 10x by transparently making PostgreSQL cloud storage-native. AppOS works like a storage driver that efficiently exploits the characteristics of cloud storage, such as I/O size dependency to storage throughput and latency, atomic write support in cloud block storage, and fast, but non-durable local SSDs. To do this, AppOS comprises a Linux-compatible file I/O stack including virtual file system, page cache, block I/O layer, cloud storage driver. On top of the file I/O stack, syscall module supports registering pre- and post-handler for file I/O-related system calls in order to transparently work without modifying PostgreSQL codes.

    I will focus on presenting key use cases and performance results of the AppOS extension after explaining the internals. Specifically, I will show the performance results of OLTP and some batch workloads using standard benchmarking tools like pgbench and sysbench. I will also present performance results and implications on multiple clouds including AWS, GCP, and Azure.

  • Dmitry Vasilyev
    Dmitry Vasilyev Postgres Professional
    45 мин

    Using PostgreSQL in AWS RDS: problems, recipes and tools.

    Everyone has probably heard about such a service as AWS RDS. I will talk about my experience by using the AWS RDS PostgreSQL Engine: the positive and negative aspects of the DBA work. This talk will focus on the tools that helped me create a comfortable environment in RDS. https://www.dropbox.com/s/v7udx5x96as5gbd/pgconf2020.pdf

  • Pavel Stehule
    Pavel Stehule freelancer
    90 мин

    The possibilities of profiling plpgsql code - available tools

    I like stored procedures - it is great technology. But like any other technologies it allows to write not well optimized code. It is not easy to write optimized code, sql statements in complex large applications. On second hand, there are some tools, that can be used very easily, that can help. Postgres has built-in tracking functions possibility. There are PLProfiler and plpgsql_check. With these tools is easy work to detect slow part of applications.With this knowledge, the fix of performance issue is less magic.