মাইক্রোসার্ভিস আর্কিটেকচার, এই বিশ্বের সবকিছুর মতো, এর সুবিধা এবং অসুবিধা রয়েছে। কিছু প্রক্রিয়া এটির সাথে সহজ হয়ে যায়, অন্যগুলি আরও কঠিন। এবং পরিবর্তনের গতি এবং আরও ভাল মাপযোগ্যতার জন্য, আপনাকে ত্যাগ স্বীকার করতে হবে। তার মধ্যে একটি হল বিশ্লেষণের ক্রমবর্ধমান জটিলতা। যদি একটি মনোলিথে সমস্ত অপারেশনাল অ্যানালিটিক্সকে এসকিউএল কোয়েরিতে একটি বিশ্লেষণাত্মক প্রতিলিপিতে হ্রাস করা যায়, তাহলে একটি মাল্টিসার্ভিস আর্কিটেকচারে প্রতিটি পরিষেবার নিজস্ব ডাটাবেস থাকে এবং মনে হয় যে একটি প্রশ্ন করা যাবে না (বা হতে পারে?)। আমরা কীভাবে আমাদের কোম্পানির অপারেশনাল অ্যানালিটিক্সের সমস্যা সমাধান করেছি এবং কীভাবে আমরা এই সমাধানের সাথে বাঁচতে শিখেছি তা নিয়ে যারা আগ্রহী তাদের জন্য - স্বাগতম।

আমার নাম পাভেল সিভাশ, DomClick-এ আমি এমন একটি দলে কাজ করি যা বিশ্লেষণমূলক ডেটা গুদাম রক্ষণাবেক্ষণের জন্য দায়ী৷ প্রচলিতভাবে, আমাদের ক্রিয়াকলাপগুলিকে ডেটা ইঞ্জিনিয়ারিং হিসাবে শ্রেণীবদ্ধ করা যেতে পারে, তবে বাস্তবে, কাজের পরিসর অনেক বিস্তৃত। ডেটা ইঞ্জিনিয়ারিংয়ের জন্য ETL/ELT স্ট্যান্ডার্ড রয়েছে, ডেটা বিশ্লেষণ এবং আপনার নিজস্ব সরঞ্জামগুলির বিকাশের জন্য সরঞ্জামগুলির সমর্থন এবং অভিযোজন। বিশেষ করে, অপারেশনাল রিপোর্টিংয়ের জন্য, আমরা "ভান" করার সিদ্ধান্ত নিয়েছি যে আমাদের একটি মনোলিথ আছে এবং বিশ্লেষকদের একটি ডাটাবেস দিতে হবে যাতে তাদের প্রয়োজনীয় সমস্ত ডেটা থাকবে।

সাধারণভাবে, আমরা বিভিন্ন বিকল্প বিবেচনা করেছি। একটি পূর্ণাঙ্গ ভাণ্ডার তৈরি করা সম্ভব ছিল - আমরা এমনকি চেষ্টাও করেছি, কিন্তু, সত্যি কথা বলতে, আমরা একটি সংগ্রহস্থল তৈরি করার এবং এতে পরিবর্তন করার বরং ধীর প্রক্রিয়ার সাথে যুক্তিতে মোটামুটি ঘন ঘন পরিবর্তনগুলিকে একত্রিত করতে পারিনি (যদি কেউ সফল হয় , মন্তব্যে লিখুন কিভাবে)। বিশ্লেষকদের বলা সম্ভব ছিল: "বন্ধুরা, পাইথন শিখুন এবং বিশ্লেষণাত্মক প্রতিলিপিতে যান," তবে এটি নিয়োগের জন্য একটি অতিরিক্ত প্রয়োজনীয়তা, এবং এটি সম্ভব হলে এটি এড়ানো উচিত বলে মনে হচ্ছে। আমরা FDW (ফরেন ডাটা র্যাপার) প্রযুক্তি ব্যবহার করার চেষ্টা করার সিদ্ধান্ত নিয়েছি: মূলত, এটি একটি স্ট্যান্ডার্ড ডিব্লিঙ্ক, যা এসকিউএল স্ট্যান্ডার্ডে রয়েছে, কিন্তু এর নিজস্ব অনেক বেশি সুবিধাজনক ইন্টারফেস রয়েছে। এটির উপর ভিত্তি করে, আমরা একটি সমাধান তৈরি করেছি, যা অবশেষে ধরা পড়ে এবং আমরা এটিতে স্থির হয়েছি। এর বিশদ বিবরণ একটি পৃথক নিবন্ধের বিষয়, এবং হতে পারে একাধিক, যেহেতু আমি অনেক কিছু বলতে চাই: ডাটাবেস স্কিমা সিঙ্ক্রোনাইজ করা থেকে শুরু করে ব্যক্তিগত ডেটা অ্যাক্সেস নিয়ন্ত্রণ এবং ডিপারসোনালাইজেশন পর্যন্ত। এটি একটি রিজার্ভেশন করাও প্রয়োজন যে এই সমাধানটি বাস্তব বিশ্লেষণাত্মক ডেটাবেস এবং সংগ্রহস্থলগুলির প্রতিস্থাপন নয়; এটি শুধুমাত্র একটি নির্দিষ্ট সমস্যার সমাধান করে।

শীর্ষ স্তরে এটি এই মত দেখায়:

একটি PostgreSQL ডাটাবেস রয়েছে যেখানে ব্যবহারকারীরা তাদের কাজের ডেটা সংরক্ষণ করতে পারে এবং সবচেয়ে গুরুত্বপূর্ণভাবে, সমস্ত পরিষেবার বিশ্লেষণাত্মক প্রতিলিপি FDW এর মাধ্যমে এই ডাটাবেসের সাথে সংযুক্ত থাকে। এটি বেশ কয়েকটি ডাটাবেসে একটি ক্যোয়ারী লেখা সম্ভব করে, এবং এটি কী তা বিবেচ্য নয়: PostgreSQL, MySQL, MongoDB বা অন্য কিছু (ফাইল, API, যদি হঠাৎ কোনও উপযুক্ত মোড়ক না থাকে তবে আপনি নিজের লিখতে পারেন)। ভাল, সবকিছু মহান মনে হচ্ছে! আমরা কি ব্রেক আপ করছি?

যদি সবকিছু এত দ্রুত এবং সহজভাবে শেষ হয়, তাহলে, সম্ভবত, একটি নিবন্ধ থাকবে না।

পোস্টগ্রেস কীভাবে রিমোট সার্ভারে অনুরোধগুলি প্রক্রিয়া করে সে সম্পর্কে পরিষ্কার হওয়া গুরুত্বপূর্ণ। এটি যৌক্তিক বলে মনে হয়, তবে প্রায়শই লোকেরা এতে মনোযোগ দেয় না: পোস্টগ্রেস রিমোট সার্ভারে স্বাধীনভাবে চালানো হয় এমন অংশগুলিতে অনুরোধটিকে ভাগ করে, এই ডেটা সংগ্রহ করে এবং চূড়ান্ত গণনা নিজেই করে, তাই কোয়েরি সম্পাদনের গতি অনেকাংশে নির্ভর করবে এটা কিভাবে লেখা হয়। এটিও লক্ষ করা উচিত: যখন কোনও দূরবর্তী সার্ভার থেকে ডেটা আসে, তখন এটির আর সূচক থাকে না, এমন কিছুই নেই যা শিডিউলারকে সাহায্য করবে, তাই, শুধুমাত্র আমরা নিজেরাই তাকে সাহায্য করতে এবং পরামর্শ দিতে পারি। এবং এই আমি আরো বিস্তারিত সম্পর্কে কথা বলতে চান ঠিক কি.

একটি সহজ প্রশ্ন এবং এটি সঙ্গে একটি পরিকল্পনা

পোস্টগ্রেস কীভাবে দূরবর্তী সার্ভারে একটি 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 লাইন) পাব তা দেখতে আমাদের অনুমতি দেয়।

আসুন একটু এগিয়ে যাই এবং আমাদের অনুরোধে বেশ কয়েকটি ফিল্টার যোগ করি: একটির জন্য বুলিয়ান ক্ষেত্র, ঘটনা দ্বারা এক টাইমস্ট্যাম্প ব্যবধানে এবং একটি দ্বারা 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

প্রশ্নগুলি লেখার সময় আপনাকে যে বিন্দুতে মনোযোগ দিতে হবে তা এখানেই রয়েছে। ফিল্টারগুলি রিমোট সার্ভারে স্থানান্তরিত হয়নি, যার অর্থ হল এটি চালানোর জন্য, পোস্টগ্রেস স্থানীয়ভাবে ফিল্টার করার জন্য (ফিল্টার সারি) এবং একত্রীকরণ সম্পাদন করার জন্য সমস্ত 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 অপারেটর থেকে আলাদা = কারণ এটি নাল মান দিয়ে কাজ করতে পারে। এটা মানে সত্য না ফিল্টারে False এবং Null মানগুলি ছেড়ে দেবে, যেখানে != সত্য শুধুমাত্র মিথ্যা মান ছেড়ে যাবে. অতএব, যখন অপারেটর প্রতিস্থাপন এটি না OR অপারেটরের সাথে দুটি শর্ত ফিল্টারে পাস করা উচিত, উদাহরণস্বরূপ, WHERE (col!= True) OR (col is null).

আমরা বুলিয়ানের সাথে মোকাবিলা করেছি, আসুন এগিয়ে যাই। আপাতত, অন্য পরিবর্তনের প্রভাব স্বাধীনভাবে বিবেচনা করার জন্য বুলিয়ান ফিল্টারটিকে তার আসল ফর্মে ফিরিয়ে দেওয়া যাক।

টাইমস্ট্যাম্পটজ? 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 গুণ দ্রুত হয়ে উঠেছে!

আবার, এখানে সতর্কতা অবলম্বন করা গুরুত্বপূর্ণ: সাবকোয়েরিতে ডেটা টাইপ অবশ্যই ফিল্ডের মতই হতে হবে যেটিতে আমরা ফিল্টার করছি, অন্যথায় পরিকল্পনাকারী সিদ্ধান্ত নেবে যে প্রকারগুলি ভিন্ন, তাই প্রথমে সবগুলি পেতে হবে ডেটা এবং স্থানীয়ভাবে ফিল্টার করুন।

তারিখ ফিল্টারটিকে তার আসল মান ফিরিয়ে দেওয়া যাক।

ফ্রেডি বনাম জসনব

সাধারণভাবে, বুলিয়ান ক্ষেত্র এবং তারিখগুলি ইতিমধ্যেই আমাদের ক্যোয়ারীকে যথেষ্ট গতিশীল করেছে, কিন্তু আরও একটি ডেটা টাইপ বাকি ছিল৷ এটি দ্বারা ফিল্টারিংয়ের সাথে যুদ্ধ, সত্যি বলতে, এখনও শেষ হয়নি, যদিও এখানেও সাফল্য রয়েছে। সুতরাং, এইভাবে আমরা ফিল্টারটি পাস করতে পেরেছি 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 আচরণ, push down (সংস্করণ 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 গুণেরও বেশি দ্রুত! এবং আমরা তুলনামূলকভাবে ছোট ডেটা সেটের বিরুদ্ধে একটি সাধারণ প্রশ্নের কথা বলছি। প্রকৃত অনুরোধে, আমরা কয়েকশ গুণ পর্যন্ত বৃদ্ধি পেয়েছি।

সংক্ষেপে: আপনি যদি FDW-এর সাথে PostgreSQL ব্যবহার করেন, সর্বদা পরীক্ষা করে দেখুন যে সমস্ত ফিল্টার রিমোট সার্ভারে পাঠানো হয়েছে, এবং আপনি খুশি হবেন... অন্তত যতক্ষণ না আপনি বিভিন্ন সার্ভার থেকে টেবিলের মধ্যে যোগদান করছেন। কিন্তু এটি অন্য নিবন্ধের জন্য একটি গল্প।

আপনার মনোযোগের জন্য আপনাকে ধন্যবাদ! আমি মন্তব্যে আপনার অভিজ্ঞতা সম্পর্কে প্রশ্ন, মন্তব্য এবং গল্প শুনতে চাই।

উত্স: www.habr.com