მიკროსერვისის არქიტექტურას, ისევე როგორც ყველაფერს ამ სამყაროში, აქვს თავისი დადებითი და უარყოფითი მხარეები. ზოგიერთი პროცესი უფრო ადვილი ხდება, ზოგი უფრო რთული. და ცვლილების სიჩქარისა და უკეთესი მასშტაბურობისთვის, თქვენ უნდა გაიღოთ მსხვერპლი. ერთ-ერთი მათგანია ანალიტიკის სირთულე. თუ მონოლითში ყველა ოპერაციული ანალიტიკა შეიძლება შემცირდეს SQL მოთხოვნებზე ანალიტიკურ რეპლიკამდე, მაშინ მულტისერვისის არქიტექტურაში თითოეულ სერვისს აქვს საკუთარი მონაცემთა ბაზა და, როგორც ჩანს, ერთი შეკითხვა არ არის საკმარისი (ან იქნებ ეს იყოს?). ვისაც აინტერესებს, როგორ გადავწყვიტეთ ოპერაციული ანალიტიკის პრობლემა ჩვენს კომპანიაში და როგორ ვისწავლეთ ამ გადაწყვეტით ცხოვრება - მოგესალმებით.

მე მქვია პაველ სივაში, DomClick-ში ვმუშაობ გუნდში, რომელიც პასუხისმგებელია ანალიტიკური მონაცემთა საწყობის შენარჩუნებაზე. პირობითად, ჩვენი საქმიანობა შეიძლება მივაწეროთ მონაცემთა ინჟინერიას, მაგრამ, ფაქტობრივად, ამოცანების სპექტრი გაცილებით ფართოა. არსებობს სტანდარტული მონაცემთა საინჟინრო ETL / ELT, მონაცემთა ანალიზის ხელსაწყოების მხარდაჭერა და ადაპტაცია და საკუთარი ხელსაწყოების შემუშავება. კერძოდ, ოპერაციული ანგარიშგებისთვის, ჩვენ გადავწყვიტეთ „თავი გამოგვეჩინა“, რომ გვაქვს მონოლითი და ანალიტიკოსებს მივცეთ ერთი მონაცემთა ბაზა, რომელიც შეიცავს ყველა საჭირო მონაცემს.

ზოგადად, განვიხილეთ სხვადასხვა ვარიანტები. შესაძლებელი იყო სრულფასოვანი საცავის აშენება - ჩვენ კი ვცადეთ, მაგრამ, მართალი გითხრათ, ლოგიკის საკმაოდ ხშირი ცვლილებებით ვერ დავმეგობრდით საცავის აგების და მასში ცვლილებების შეტანის საკმაოდ ნელი პროცესით ( თუ ვინმემ მიაღწია წარმატებას, დაწერეთ კომენტარებში როგორ). თქვენ შეგიძლიათ ეთქვათ ანალიტიკოსებს: ”ბიჭებო, ისწავლეთ პითონი და გადადით ანალიტიკურ ხაზებზე”, მაგრამ ეს არის დამატებითი დაქირავების მოთხოვნა და, როგორც ჩანს, ეს თავიდან უნდა იქნას აცილებული, თუ ეს შესაძლებელია. ჩვენ გადავწყვიტეთ FDW (Foreign Data Wrapper) ტექნოლოგიის გამოყენება: სინამდვილეში, ეს არის სტანდარტული dblink, რომელიც არის SQL სტანდარტში, მაგრამ მისი ბევრად უფრო მოსახერხებელი ინტერფეისით. ამის საფუძველზე მივიღეთ გადაწყვეტილება, რომელმაც საბოლოოდ ფესვი გაიდგა, დავთანხმდით. მისი დეტალები ცალკე სტატიის თემაა და შესაძლოა ერთზე მეტიც, რადგან მინდა ვისაუბრო ბევრზე: მონაცემთა ბაზის სქემის სინქრონიზაციისგან დაწყებული პერსონალური მონაცემების კონტროლამდე და დეპერსონალიზაციამდე. აქვე უნდა აღინიშნოს, რომ ეს გამოსავალი არ არის რეალური ანალიტიკური მონაცემთა ბაზებისა და საცავების ჩანაცვლება, ის მხოლოდ კონკრეტულ პრობლემას წყვეტს.

უმაღლეს დონეზე ასე გამოიყურება:

არსებობს PostgreSQL მონაცემთა ბაზა, სადაც მომხმარებლებს შეუძლიათ შეინახონ თავიანთი სამუშაო მონაცემები და რაც მთავარია, ყველა სერვისის ანალიტიკური რეპლიკა დაკავშირებულია ამ მონაცემთა ბაზასთან FDW-ის საშუალებით. ეს შესაძლებელს ხდის შეკითხვის დაწერას რამდენიმე მონაცემთა ბაზაში და არ აქვს მნიშვნელობა რა არის ეს: PostgreSQL, MySQL, MongoDB თუ სხვა რამ (ფაილი, API, თუ მოულოდნელად არ არის შესაფერისი შეფუთვა, შეგიძლიათ დაწეროთ თქვენი საკუთარი). ისე, როგორც ჩანს, ყველაფერი მშვენიერია! დაშორება?

ყველაფერი ასე სწრაფად და მარტივად რომ დამთავრებულიყო, მაშინ, ალბათ, სტატია არ იარსებებდა.

მნიშვნელოვანია იმის გარკვევა, თუ როგორ ამუშავებს პოსტგრესი მოთხოვნებს დისტანციურ სერვერებზე. როგორც ჩანს, ეს ლოგიკურია, მაგრამ ხშირად ადამიანები ამას ყურადღებას არ აქცევენ: 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 string).

მოდით წავიდეთ ცოტა უფრო წინ და დავამატოთ რამდენიმე ფილტრი ჩვენს შეკითხვას: ერთი ლოგიკური ველი, ერთი შესვლით ნიშნულის ინტერვალით და ერთით 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, ხოლო != მართალია დატოვებს მხოლოდ ცრუ მნიშვნელობებს. ამიტომ, ოპერატორის შეცვლისას არ არის თქვენ უნდა გადასცეთ ფილტრს ორი პირობა OR ოპერატორით, მაგალითად, WHERE (col != True) OR (col არის null).

ლოგიკურად გააზრებული, გადადის. იმავდროულად, დავუბრუნდეთ ფილტრს ლოგიკური მნიშვნელობით თავდაპირველ ფორმაში, რათა დამოუკიდებლად განვიხილოთ სხვა ცვლილებების ეფექტი.

timestamptz? ჰც

ზოგადად, ხშირად გიწევთ ექსპერიმენტი იმის შესახებ, თუ როგორ სწორად დაწეროთ მოთხოვნა, რომელიც მოიცავს დისტანციურ სერვერებს და მხოლოდ ამის შემდეგ მოძებნოთ ახსნა, თუ რატომ ხდება ეს. ამის შესახებ ძალიან ცოტა ინფორმაცია მოიძებნება ინტერნეტში. ასე რომ, ექსპერიმენტებში აღმოვაჩინეთ, რომ ფიქსირებული თარიღის ფილტრი აფეთქებით მიფრინავს დისტანციურ სერვერზე, მაგრამ როდესაც გვინდა თარიღის დინამიურად დაყენება, მაგალითად, 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

ზოგადად, ლოგიკური ველები და თარიღები უკვე საკმარისად აჩქარებს ჩვენს შეკითხვას, მაგრამ იყო კიდევ ერთი მონაცემთა ტიპი. მის მიერ ფილტრაციასთან ბრძოლა, მართალი გითხრათ, ჯერ არ დასრულებულა, თუმცა აქაც არის წარმატებები. ასე რომ, აი, როგორ მოვახერხეთ ფილტრის გავლა 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