Микросервисната архитектура, како и сè на овој свет, има свои добрите и лошите страни. Некои процеси стануваат полесни со него, други потешки. А заради брзината на промените и подобрата приспособливост, треба да се жртвувате. Еден од нив е зголемената сложеност на аналитиката. Ако во монолит целата оперативна аналитика може да се сведе на SQL барања до аналитичка реплика, тогаш во мултисервисната архитектура секоја услуга има своја база на податоци и се чини дека едно барање не може да се направи (или можеби може?). За оние кои се заинтересирани како го решивме проблемот со оперативната аналитика во нашата компанија и како научивме да живееме со ова решение - добредојде.

Јас се викам Павел Сиваш, во DomClick работам во тим кој е одговорен за одржување на складиштето за аналитички податоци. Конвенционално, нашите активности може да се класифицираат како инженерство на податоци, но, всушност, опсегот на задачи е многу поширок. Постојат ETL/ELT стандард за инженерство на податоци, поддршка и адаптација на алатки за анализа на податоци и развој на сопствени алатки. Конкретно, за оперативното известување, решивме да се „преправаме“ дека имаме монолит и да им дадеме на аналитичарите една база на податоци што ќе ги содржи сите податоци што им се потребни.

Во принцип, разгледавме различни опции. Беше можно да се изгради полноправно складиште - дури и се обидовме, но, да бидам искрен, не успеавме да комбинираме прилично чести промени во логиката со прилично бавниот процес на градење складиште и правење промени во него (ако некој успее , пишете во коментар како). На аналитичарите можеше да им се каже: „Момци, научете питон и одете на аналитички реплики“, но ова е дополнителен услов за регрутирање и се чинеше дека ова треба да се избегне ако е можно. Решивме да се обидеме да ја користиме технологијата FDW (Foreign Data Wrapper): во суштина, ова е стандарден dblink, кој е во стандардот SQL, но со свој многу поудобен интерфејс. Врз основа на тоа, направивме решение, кое на крајот фати и се решивме на него. Нејзините детали се тема на посебна статија, а можеби и повеќе од една, бидејќи сакам да зборувам за многу: од синхронизирање шеми на бази на податоци до контрола на пристап и обезличување на личните податоци. Исто така, неопходно е да се направи резервација дека ова решение не е замена за вистински аналитички бази на податоци и складишта, туку решава само конкретен проблем.

На највисоко ниво изгледа вака:

Постои база на податоци PostgreSQL каде што корисниците можат да ги складираат своите работни податоци, а најважно е што аналитичките реплики на сите услуги се поврзани со оваа база преку FDW. Ова овозможува да се напише барање во неколку бази на податоци и не е важно што е тоа: PostgreSQL, MySQL, MongoDB или нешто друго (датотека, API, ако одеднаш нема соодветна обвивка, можете да напишете своја). Па, сè изгледа одлично! Дали раскинуваме?

Ако сè заврши толку брзо и едноставно, тогаш, веројатно, нема да има статија.

Важно е да се биде јасно како Postgres ги обработува барањата до оддалечените сервери. Ова изгледа логично, но често луѓето не обрнуваат внимание на тоа: Postgres го дели барањето на делови кои се извршуваат независно на оддалечените сервери, ги собира овие податоци и самиот ги извршува конечните пресметки, така што брзината на извршување на барањето во голема мера ќе зависи од како е напишано. Исто така, треба да се забележи: кога податоците пристигнуваат од оддалечен сервер, тие веќе немаат индекси, нема ништо што ќе му помогне на распоредувачот, затоа, само ние самите можеме да му помогнеме и да го советуваме. И токму за ова сакам да зборувам подетално.

Едноставно барање и план со него

За да покажеме како Postgres бара табела од 6 милиони редови на оддалечен сервер, ајде да погледнеме едноставен план.

explain analyze verbose  
SELECT count(1)
FROM fdw_schema.table;

Aggregate  (cost=418383.23..418383.24 rows=1 width=8) (actual time=3857.198..3857.198 rows=1 loops=1)
  Output: count(1)
  ->  Foreign Scan on fdw_schema."table"  (cost=100.00..402376.14 rows=6402838 width=0) (actual time=4.874..3256.511 rows=6406868 loops=1)
        Output: "table".id, "table".is_active, "table".meta, "table".created_dt
        Remote SQL: SELECT NULL FROM fdw_schema.table
Planning time: 0.986 ms
Execution time: 3857.436 ms

Користењето на изјавата VERBOSE ни овозможува да го видиме барањето што ќе биде испратено до оддалечениот сервер и чии резултати ќе ги добиеме за понатамошна обработка (линија RemoteSQL).

Ајде да одиме малку подалеку и да додадеме неколку филтри на нашето барање: еден за boolean поле, еден по појава временската ознака во интервалот и еден од jsonb.

explain analyze verbose
SELECT count(1)
FROM fdw_schema.table 
WHERE is_active is True
AND created_dt BETWEEN CURRENT_DATE - INTERVAL '7 month' 
AND CURRENT_DATE - INTERVAL '6 month'
AND meta->>'source' = 'test';

Aggregate  (cost=577487.69..577487.70 rows=1 width=8) (actual time=27473.818..25473.819 rows=1 loops=1)
  Output: count(1)
  ->  Foreign Scan on fdw_schema."table"  (cost=100.00..577469.21 rows=7390 width=0) (actual time=31.369..25372.466 rows=1360025 loops=1)
        Output: "table".id, "table".is_active, "table".meta, "table".created_dt
        Filter: (("table".is_active IS TRUE) AND (("table".meta ->> 'source'::text) = 'test'::text) AND ("table".created_dt >= (('now'::cstring)::date - '7 mons'::interval)) AND ("table".created_dt <= ((('now'::cstring)::date)::timestamp with time zone - '6 mons'::interval)))
        Rows Removed by Filter: 5046843
        Remote SQL: SELECT created_dt, is_active, meta FROM fdw_schema.table
Planning time: 0.665 ms
Execution time: 27474.118 ms

Тука лежи поентата на која треба да обрнете внимание кога пишувате прашања. Филтрите не беа префрлени на оддалечениот сервер, што значи дека за да го изврши, Postgres ги повлекува сите 6 милиони редови за потоа да се филтрира локално (Редот на филтер) и да изврши агрегација. Клучот за успехот е да се напише барање, така што филтрите се префрлаат на оддалечената машина, а ние ги примаме и собираме само потребните редови.

Тоа е некоја глупост

Со булова полиња сè е едноставно. Во првобитното барање проблемот се должи на операторот is. Ако го замените со =, тогаш го добиваме следниот резултат:

explain analyze verbose
SELECT count(1)
FROM fdw_schema.table
WHERE is_active = True
AND created_dt BETWEEN CURRENT_DATE - INTERVAL '7 month' 
AND CURRENT_DATE - INTERVAL '6 month'
AND meta->>'source' = 'test';

Aggregate  (cost=508010.14..508010.15 rows=1 width=8) (actual time=19064.314..19064.314 rows=1 loops=1)
  Output: count(1)
  ->  Foreign Scan on fdw_schema."table"  (cost=100.00..507988.44 rows=8679 width=0) (actual time=33.035..18951.278 rows=1360025 loops=1)
        Output: "table".id, "table".is_active, "table".meta, "table".created_dt
        Filter: ((("table".meta ->> 'source'::text) = 'test'::text) AND ("table".created_dt >= (('now'::cstring)::date - '7 mons'::interval)) AND ("table".created_dt <= ((('now'::cstring)::date)::timestamp with time zone - '6 mons'::interval)))
        Rows Removed by Filter: 3567989
        Remote SQL: SELECT created_dt, meta FROM fdw_schema.table WHERE (is_active)
Planning time: 0.834 ms
Execution time: 19064.534 ms

Како што можете да видите, филтерот полета до оддалечен сервер, а времето на извршување беше намалено од 27 на 19 секунди.

Вреди да се напомене дека операторот is различен од операторот = бидејќи може да работи со Null вредноста. Тоа значи дека не е Вистина ќе ги остави вредностите False и Null во филтерот, додека != Точно ќе остави само Лажни вредности. Затоа, при замена на операторот не два услови со операторот ИЛИ треба да се пренесат на филтерот, на пример, WHERE (кол != Точно) ИЛИ (колката е нула).

Се занимававме со бул, ајде да продолжиме понатаму. Засега, да го вратиме Буловиот филтер во неговата оригинална форма со цел самостојно да го разгледаме ефектот од другите промени.

timestamptz? hz

Во принцип, честопати треба да експериментирате како правилно да напишете барање што вклучува оддалечени сервери и дури потоа да барате објаснување зошто тоа се случува. Многу малку информации за ова може да се најдат на Интернет. Така, во експериментите откривме дека филтерот за фиксен датум лета до оддалечениот сервер со тресок, но кога сакаме динамички да го поставиме датумот, на пример, now() или CURRENT_DATE, тоа не се случува. Во нашиот пример, додадовме филтер така што колоната create_at содржи податоци за точно 1 месец во минатото (BETWEEN CURRENT_DATE - INTERVAL „7 месец“ И CURRENT_DATE - INTERVAL „6 месец“). Што направивме во овој случај?

explain analyze verbose
SELECT count(1)
FROM fdw_schema.table 
WHERE is_active is True
AND created_dt >= (SELECT CURRENT_DATE::timestamptz - INTERVAL '7 month') 
AND created_dt <(SELECT CURRENT_DATE::timestamptz - INTERVAL '6 month')
AND meta->>'source' = 'test';

Aggregate  (cost=306875.17..306875.18 rows=1 width=8) (actual time=4789.114..4789.115 rows=1 loops=1)
  Output: count(1)
  InitPlan 1 (returns $0)
    ->  Result  (cost=0.00..0.02 rows=1 width=8) (actual time=0.007..0.008 rows=1 loops=1)
          Output: ((('now'::cstring)::date)::timestamp with time zone - '7 mons'::interval)
  InitPlan 2 (returns $1)
    ->  Result  (cost=0.00..0.02 rows=1 width=8) (actual time=0.002..0.002 rows=1 loops=1)
          Output: ((('now'::cstring)::date)::timestamp with time zone - '6 mons'::interval)
  ->  Foreign Scan on fdw_schema."table"  (cost=100.02..306874.86 rows=105 width=0) (actual time=23.475..4681.419 rows=1360025 loops=1)
        Output: "table".id, "table".is_active, "table".meta, "table".created_dt
        Filter: (("table".is_active IS TRUE) AND (("table".meta ->> 'source'::text) = 'test'::text))
        Rows Removed by Filter: 76934
        Remote SQL: SELECT is_active, meta FROM fdw_schema.table WHERE ((created_dt >= $1::timestamp with time zone)) AND ((created_dt < $2::timestamp with time zone))
Planning time: 0.703 ms
Execution time: 4789.379 ms

Му кажавме на планерот однапред да го пресмета датумот во подпрашањето и да ја пренесе готовата променлива на филтерот. И овој навестување ни даде одличен резултат, барањето стана скоро 6 пати побрзо!

Повторно, важно е да се биде внимателен овде: типот на податоци во подпрашањето мора да биде ист како оној на полето на кое филтрираме, инаку планерот ќе одлучи дека бидејќи типовите се различни, потребно е прво да се добијат сите податоците и филтрирајте ги локално.

Да го вратиме филтерот за датум на неговата оригинална вредност.

Фреди vs. Јсонб

Општо земено, Буловите полиња и датуми веќе доволно го забрзаа нашето барање, но остана уште еден тип на податоци. Битката со филтрирањето по него, да бидам искрен, сè уште не е завршена, иако и тука има успех. Така, вака успеавме да го поминеме филтерот jsonb поле до далечинскиот сервер.

explain analyze verbose
SELECT count(1)
FROM fdw_schema.table 
WHERE is_active is True
AND created_dt BETWEEN CURRENT_DATE - INTERVAL '7 month' 
AND CURRENT_DATE - INTERVAL '6 month'
AND meta @> '{"source":"test"}'::jsonb;

Aggregate  (cost=245463.60..245463.61 rows=1 width=8) (actual time=6727.589..6727.590 rows=1 loops=1)
  Output: count(1)
  ->  Foreign Scan on fdw_schema."table"  (cost=1100.00..245459.90 rows=1478 width=0) (actual time=16.213..6634.794 rows=1360025 loops=1)
        Output: "table".id, "table".is_active, "table".meta, "table".created_dt
        Filter: (("table".is_active IS TRUE) AND ("table".created_dt >= (('now'::cstring)::date - '7 mons'::interval)) AND ("table".created_dt <= ((('now'::cstring)::date)::timestamp with time zone - '6 mons'::interval)))
        Rows Removed by Filter: 619961
        Remote SQL: SELECT created_dt, is_active FROM fdw_schema.table WHERE ((meta @> '{"source": "test"}'::jsonb))
Planning time: 0.747 ms
Execution time: 6727.815 ms

Наместо да филтрирате оператори, мора да користите присуство на еден оператор jsonb во една поинаква. 7 секунди наместо оригиналните 29. Засега ова е единствената успешна опција за пренос на филтри преку jsonb на оддалечен сервер, но тука е важно да се земе предвид едно ограничување: ја користиме верзијата 9.6 од базата на податоци, но до крајот на април планираме да ги завршиме последните тестови и да преминеме на верзијата 12. Откако ќе се ажурираме, ќе пишуваме за тоа како тоа влијаело, бидејќи има доста промени за кои има многу надеж: json_path, ново однесување на CTE, притисни надолу (постои од верзијата 10). Навистина сакам да го пробам наскоро.

Заврши го

Тестиравме како секоја промена влијае на брзината на барањето поединечно. Ајде сега да видиме што се случува кога сите три филтри се напишани правилно.

explain analyze verbose
SELECT count(1)
FROM fdw_schema.table 
WHERE is_active = True
AND created_dt >= (SELECT CURRENT_DATE::timestamptz - INTERVAL '7 month') 
AND created_dt <(SELECT CURRENT_DATE::timestamptz - INTERVAL '6 month')
AND meta @> '{"source":"test"}'::jsonb;

Aggregate  (cost=322041.51..322041.52 rows=1 width=8) (actual time=2278.867..2278.867 rows=1 loops=1)
  Output: count(1)
  InitPlan 1 (returns $0)
    ->  Result  (cost=0.00..0.02 rows=1 width=8) (actual time=0.010..0.010 rows=1 loops=1)
          Output: ((('now'::cstring)::date)::timestamp with time zone - '7 mons'::interval)
  InitPlan 2 (returns $1)
    ->  Result  (cost=0.00..0.02 rows=1 width=8) (actual time=0.003..0.003 rows=1 loops=1)
          Output: ((('now'::cstring)::date)::timestamp with time zone - '6 mons'::interval)
  ->  Foreign Scan on fdw_schema."table"  (cost=100.02..322041.41 rows=25 width=0) (actual time=8.597..2153.809 rows=1360025 loops=1)
        Output: "table".id, "table".is_active, "table".meta, "table".created_dt
        Remote SQL: SELECT NULL FROM fdw_schema.table WHERE (is_active) AND ((created_dt >= $1::timestamp with time zone)) AND ((created_dt < $2::timestamp with time zone)) AND ((meta @> '{"source": "test"}'::jsonb))
Planning time: 0.820 ms
Execution time: 2279.087 ms

Да, барањето изгледа покомплицирано, ова е принудна такса, но брзината на извршување е 2 секунди, што е повеќе од 10 пати побрзо! И ние зборуваме за едноставно барање против релативно мал сет на податоци. На реални барања добивме зголемување и до неколку стотици пати.

Да резимираме: ако користите PostgreSQL со FDW, секогаш проверувајте дали сите филтри се испраќаат до далечинскиот сервер и ќе бидете среќни... Барем додека не стигнете да се приклучите помеѓу табелите од различни сервери. Но, тоа е приказна за друга статија.

Ви благодариме за вниманието! Би сакал да слушнам прашања, коментари и приказни за вашите искуства во коментарите.

Извор: www.habr.com