SQL Server-ден PostgreSQL-ге көшу: үйлеспеушіліктер және жоспар

Қандай жайттар көшіруді қиындатады

Компаниялар SQL Server-ден PostgreSQL-ге әртүрлі себептермен көшеді: лицензиялық шығындарды азайту, импорт алмастыру талаптары, бір вендорға тәуелділіктен арылу, инфрақұрылымды өзгерту (облақ, контейнерлер, қолдау командасының ауысуы) және т.б.

Бірақ миграция сирек 1:1 көшіріле береді. Тіпті «кестелер бірдей» болса да, деректер типтері, функциялардың мінез-құлқы, жолдарды салыстыру, транзакциялар, блокировкалау ережелері және орындау жоспарлары әртүрлі болуы мүмкін. Сондықтан бұл көбінесе схеманы ғана емес, қосымшаны және операцияларды бейімдеу жобасы болып шығады.

Әдетте «өздігінен түсінікті» болып келген нәрселер жиі бұзылады: T-SQL сұраулары, сақталған процедуралар мен триггерлер, динамикалық SQL және индекстер — бір СУБД-де жұмыс жасаған нәрсе басқа жүйеде күтпеген жоспарлар береді. Одан бөлек сюрприз тудыратын нәрселер: күн/уақыт, GUID, money/decimal, NVARCHAR пен коллация, NULL-пен жұмыс істеу.

Бастамас бұрын тәуекелді тез бағалау үшін қарапайым чек-лист пайдалы:

• Дерекқорда қанша логика жинақталған (процедуралар, триггерлер, SQL Agent джобтары).
• Қосымша T-SQL және платформалық функцияларға қаншалықты тәуелді.
• Деректер көлемі және рұқсат етілген тоқтату терезесі.
• Уақыт бойынша маңызды критикалық есептер және «ауыр» сұраулар.
• Сенімділік, бэкап және қалпына келтіру талаптары.

Мемлекеттік және қаржылық ұйымдарда тәуекел жиі «кестелерді көшіруде» емес, ауысқаннан кейін барлық регламенттер, есептер және түнгі жүктемелер болжалғандай жұмыс істеуінде болады.

Инвентаризация: не тасымалдайсыз және кім оған тәуелді

Миграция жоспарын жасағанда нақты не көшірілетінін түсіну маңызды. Көрінгендей "бір дерекқор" көп жағдайда бірнеше дерекқор, бірнеше схема, жылдар бойы жиналған тарих және соңғы сәтке дейін ескерілмейтін ондай интеграциялардан тұрады.

Бастысы — ағымдағы жүйенің қысқаша паспорты: дерекқорлар мен схемалар тізімі, негізгі кестелер және олардың көлемі, өсу қарқыны, критикалық есептер мен витриналар. Сонымен қатар күрделі қайта жасауға келмейтін объектілерді бөліп көрсетіңіз: күрделі көріністер (views), функциялар, процедуралар, триггерлер.

Содан кейін тәуелділіктерді тіркеңіз. Негізгі қосымшадан бөлек бұл әдетте ETL-трансферттер, BI-есептер, алмасу сервистері (очередь, API), фондық жұмыстар, файлға шығару, бухгалтериямен интеграция және мониторинг. Әрбір тәуелділікке иесін тағайындау жөн болады — өзгерістер тез келісіліп отыруы үшін.

Өнімділікке байланысты қателеспеу үшін алдын ала «жүктеме профилін» таңдаңыз: қандай операциялар ең көп оқиды, қайсы жазулар басым. Практикада 10–20 сұрау және 3–5 жазу сценарийі негізгі көріністі береді.

Минимум жинау керек нәрселер:

• объектілер мен деректер көлемдері (айлық өсімімен)
• критикалық есептер мен жауап уақыттарына қатысты SLA
• тәуелді жүйелер мен байланыс тұлғаларының тізімі
• жүктеме бойынша ең жиі сұраулар мен жазу сценарийлері
• рұқсат етілген тоқтату және қызмет көрсету терезелері

Мысалы, өндірісте есеп беру сменаны жауып тастайтын болса және тоқтату тек түнгі уақытта ғана мүмкін болса — бұл миграция жоспарына, кері қайту сценариіне және кештердің жаңару уақытына әсер етеді.

Деректер типтерінің үйлеспеушілігі: жиі қателіктер қайда

Ең жағымсыз багтар көбінесе «дұрыс тип емес» туралы емес, мінез-құлықтың өзгеруінде: дөңгелектеу, дата салыстыру, жолдардың сұрыпталуы, автовозрастание. Сыртынан схема ұқсас көрінеді, бірақ продакшнде есептер сәйкес келмеуі немесе уникалдық кілттердің бұзылуы мүмкін.

Сандар жай сияқты көрінеді доғейін бірінші «ақша» өрісі шыққанша. INT мен BIGINT әдетте тура көшеді, ал MONEY-ді сол күйінде көшіру ұсынылмайды. PostgreSQL-де толық аналог жоқ, сондықтан қауіпсізрек — нақты дәлдікпен NUMERIC(precision, scale) қолдану; әйтпесе сомалар мен салықтарда күтпеген дөңгелектеулер болуы мүмкін.

Идентификаторлар да сұрсорлар ұнатады. UNIQUEIDENTIFIER көбінесе UUID-ға айналады. UUID қайда генерацияланғанын тексеріңіз: SQL Server-де оны қосымша немесе әдепкі мән дайындаған болуы мүмкін, ал PostgreSQL-де генерацияны нақтылап, біріздендіру жақсы.

Күндер мен уақыт — ең көп қателер шығатын жер. DATETIME2 көбіне timestamp-қа көшіріледі, бірақ таңдау керек: сағат белдеуінсіз (timestamp) немесе timestamptz. Егер жүйенің бір бөлігі локальды уақытты, екіншісі UTC-ді есептесе, миграциядан кейін салыстырулар мен дата бойынша топтастыру басқа нәтижелерді береді, әсіресе күннің ауысуы кезінде.

Жолдарда басты тұзақ — сұрыптау мен регистр. NVARCHAR PostgreSQL-де бөлек қажет емес: Unicode әдепкі қолдау бар. Бірақ collation және салыстыру ережелері өзгеше, сондықтан "A"-дан басталатындарды табу сұрауы SQL Server-дегідей нәтиже бермеуі мүмкін.

Бинарлы деректер үшін VARBINARY әдетте bytea-ға ауысады. Егер FILESTREAM қолданылған болса, файлдарды объектілік сақтау немесе файл серверіне аудару жеңілірек, ал дерекқорда тек метадеректер мен сілтемелер қалдыру ыңғайлы.

Тағы бір тақырып — IDENTITY пен секвенциялар. PostgreSQL-де бұл GENERATED ... AS IDENTITY немесе SEQUENCE, және қолмен кіргізулер кезінде есептегіштен өтіп кетіп, кілт қайшылықтарын алу қаупі бар — бұл мінезді алдын ала тексеріңіз.

Кестені көшіру алдында қысқа чек:

• MONEY бар ма және NUMERIC үшін нақты дәлдік қойылған ба
• GUID бар ма және қай жерде генерацияланады
• Қай өрістер UTC-де сақталатындығы анықталған ба
• Іздеуде сұрыптау/регистрге тәуелділік бар ма
• Автонумерация қалай ұйымдастырылған және қолмен жасалатын кірістер бар ма

Простой мысал: өтініштер кестесінде created_at SQL Server-де локальды уақыт ретінде сақталған, ал есептер "күн бойынша" тұрса — timestamptz-ке көшіруде кейбір жазбалар көршілес күнге түсіп, күндік жиындар сәйкес келмеуі мүмкін.

SQL мінезі және шектеулер: өндірісте байқалатын нәзік жайттар

Сюрприздер көбіне деректер типтерінде емес, нақты сұраулар мен транзакциялардың қалай жұмыс істейтіні туралы болады. Бұл айырмашылықтар көбіне релизден кейін, деректер ‘‘орман сияқты лас’’ болғанда және жүктеме жоғарылаған кезде көрінеді.

Жасырып тұрған қателіктердің бір себебі — NULL пен бос жолдардың қатып қап қоюы. SQL Server-да кей қосымшалар «бос» мәнді "" деп қабылдауға үйреніп қалады. PostgreSQL-де NULL және "" әрқашан бөлек, және = '', <> '', LIKE '%' немесе жолдар конкатенациясы басқа нәтиже беруі мүмкін. Нені «мән жоқ» деп санауға болатынын алдын ала келісіп, кодта (COALESCE арқылы) және шектеулерде айқындаған жөн.

Екінші проблема — тырнақшалар мен атаулардың регистрі. SQL Server-де атаулар көбіне тырнақшасыз және регистрге тәуелді емес сияқты жұмыс істейді (collation-ға байланысты). PostgreSQL-де тырнақшасыз атаулар төменгі регистрге айналады, ал екі тырнақшаға алынғандар регистрге сезімтал болады. Егер схемада "CamelCase" кестелер немесе бағандар болса, бұл тез "табылмады" қатесіне әкеледі.

Шектеулерді (CHECK, FOREIGN KEY) нақты сценарийлермен қайта тексеру керек. PostgreSQL-де шектеулер жазылуы мүмкін (DEFERRABLE) және транзакция соңында тексеріледі, бұл күрделі жүктеулерде көмектесуі мүмкін. Бірақ каскадтар (ON DELETE CASCADE, ON UPDATE) және RESTRICT/NO ACTION тәрізді ережелерді жеке тексеріп алу керек — әйтпесе күтпеген деректер жойылуы немесе операцияға тосқауыл пайда болуы мүмкін.

Транзакциялар мен блокировкаларды бөлек тексеріңіз. PostgreSQL MVCC қолданады, сондықтан "кімді кім блоктайды" деген күтулер SQL Server-дегіден өзгеше болуы мүмкін. Бұрын кешікпей өткен операциялар енді ұзақ транзакциялар мен күту кезегімен қиналуы мүмкін.

Продқа дейінгі қысқа тексеру пайдалы:

• ''-пен салыстыратын жерлер мен NULL логикасын табыңыз
• тырнақшалы және аралас регистрлі атаулар тізімін жинаңыз
• каскадтар мен FK мінезін сәйкестендіріңіз
• типтік бәсекелес операцияларды тексеріңіз (екі ағыннан бір жазбаны жаңарту)
• үлкен кестелердегі жаппай UPDATE/DELETE уақыты мен блокировкаларын бағалаңыз

Көптеген ақаулар тест деректерінде емес, нақты өндірістік деректер мен параллель сұрауларда шығады.

Тіркелген T-SQL сұраулары: қайсысын бірінші қайта жазу керек

Ең жиі айырмашылықтар қолданбалы сұрауларда шығады. Ең жиі қолданылатындарды бастап жіберіңіз: тізімдер, іздеу, есептер, жазу операциялары.

Ең жиі болатын түзету — жолдар шегін шектеу. SQL Server-де бұл TOP (N) немесе OFFSET ... FETCH. PostgreSQL-де LIMIT пен OFFSET пайдаланылады. Және көбіне ORDER BY міндетті: онсыз нәтиже ауысып тұруы мүмкін.

Жиі кездесетін ауыстырулар:

• SELECT TOP (10) ... ORDER BY ... -> SELECT ... ORDER BY ... LIMIT 10
• OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY -> OFFSET 20 LIMIT 10
• Жолдарды біріктіру: a + b -> a || b (NULL-пен мінезін ойластырыңыз)
• ISNULL(x, y) -> COALESCE(x, y) (нәтиже типі өзгеше болуы ықтимал)
• IIF(cond, a, b) -> CASE WHEN cond THEN a ELSE b END

«Ақылды» жазулармен әдетте күрделі. SQL Server-де MERGE жиі қолданылады. PostgreSQL-де көбінесе INSERT ... ON CONFLICT (...) DO UPDATE (UPSERT) пайдаланылады. Мұнда конфликтіге негіз болатын уникалды индекс немесе шектеу болуы маңызды.

Күн және жол функциялары көбіне қолмен тексеруді талап етеді: GETDATE() -> now(), DATEADD(day, 7, dt) -> dt + interval '7 days', форматтау үшін to_char(...). Тіпті аналог болғанда формат пен дөңгелектеу өзгеше болуы мүмкін.

TRY_CONVERT сияқты «жұмсақ» түрлендірулер қауіпті бөлік. PostgreSQL-де жарамсыз CAST әдетте қате тастайды, сондықтан алдымен регулярлы өрнекпен тексеру немесе деректерді миграциядан бұрын қалыпқа келтіру қауіпсіз.

Окондық функциялар ұқсас: ROW_NUMBER() OVER (...), SUM(...) OVER (...) сияқты жұмыс істейді. Бірақ егер сіз SQL Server-де окондық функцияға фильтр қолдансаңыз, PostgreSQL-де жиі алдымен подзапроспен есептеп, содан кейін сүзу керек болады.

Дерекқор ішіндегі T-SQL: процедуралар, триггерлер, динамикалық SQL

Ең күрделісі — кестелер емес, дерекқор ішіндегі код: процедуралар, триггерлер, функциялар. SQL Server-де T-SQL арқылы процедуралық стиль кең тараған: көптеген бүйірлік әсерлермен. PostgreSQL-де ұқсас тапсырмаларды PL/pgSQL-пен шешеді, бірақ синтаксис пен конструкциялары әртүрлі.

Қай жерден бастау керек: ақшамен және деректермен байланысты логиканы бірінші өткізіңіз: есептеулер, жазбаларды алу/шығару, кезеңді жабу, валидация ережелері. Жұмыс тактикасы: алдымен «таза» сұрауларды (SELECT/INSERT/UPDATE) көшіріп, содан кейін қаптау қабатын (қателерді өңдеу, транзакциялар, тармақтау) аудару.

Триггерлер мен уақытша құрылымдар

PostgreSQL-де триггерлер BEFORE/AFTER және FOR EACH ROW/STATEMENT түрінде болады, бұл жүктемеге тікелей әсер етеді. Егер SQL Server-де бір триггер барлық логиканы орындаса, PostgreSQL-де оны бірнеше триггерге бөліп, дизайнды бекіту оңайырақ болуы мүмкін. Триггерлердің орындау реті де алдын ала тексеруді талап етеді.

Уақытша кестелер мен кестелік айнымалыларды қайта қарау керек. Кестелік айнымалылардың орнына жиі уақытша кестелер (TEMP) немесе CTE пайдалану ыңғайлы. Кей жағдайларда деректер бірнеше қадамға қажет болса, транзакция ішінде тазартылатын тұрақты кестелер жақсы шешім болуы мүмкін.

Динамикалық SQL, қауіпсіздік және құқықтар

Динамикалық SQL EXECUTE арқылы көшіріледі, бірақ маңыздысы — параметрлер мен қауіпсіздік. Пайдаланушы енгізуін жолдар арқылы бірқалыпты қосу PostgreSQL-де де қауіпті, сондықтан параметризация мен идентификаторларды қауіпсіз құрастыру қажет.

Жүгініп-көру алдында тексеріңіз:

• EXEC/sp_executesql қолданылатын жерлер және оларға қандай параметрлер түседі
• қандай процедуралар үшін иенің құқықтары керек, ал қайсысы шақырушының атымен жұмыс істеуі тиіс
• рөлдер үйлесімділігі: логиндер, схемалар, GRANT-тар, функциялар мен секвенцияларға қолжетімділік
• код контекстке тәуелді жерлер (CURRENT_USER, схема бойынша объектіні іздеу)
• ең жиі қолданылатын динамикалық сұраулар үшін орындау жоспарлары (олар тұрақсыз болуы мүмкін)

Егер ұйымда қатаң қолжетімділік талаптары болса, мақсатты рөл моделін алдын ала бекітіп, оны тесттік ортада іске қосып көру пайдалы.

Индекстер мен өнімділік: жылдамдыққа әсер ететін айырмашылықтар

SQL Server-де көп жағдайда кластерленген индекске сүйенеді: деректер дискіде кілтке қарай физикалық сұрыпталған және бұл оқу операциясына әсер етеді. PostgreSQL-де негізгі индекс — btree, бірақ әдепкі бойынша «кластерлену» жоқ: жолдар жазылу тәртібімен орналасады, ал индекс сілтемелерді сақтайды. CLUSTER командасы бар, бірақ ол бір рет қолданылатын операция және уақыт өте деректер қайта «таралады».

Қамтитын (covering) индекстер де өзгешелеу. SQL Server-де INCLUDE кең тараған. PostgreSQL-де INCLUDE бар, бірақ жиі маңыздысы — SELECT-та артық бағандарды алмау және сүзгіні есептеуге айналдырмайтын индексті ұстау.

PostgreSQL-дің күшті жағы — арнайы индекстер: GIN массивтер, JSONB және толық мәтіндік іздеуге пайдалы. GiST геодеректер үшін және кейбір «ұқсас» іздеулер үшін ыңғайлы. BRIN өте үлкен кестелерде, уақытша түрде шамамен сұрыпталған кестелерде пайдалы: кішкентай индекс, әсері кейде едәуір болады.

Неліктен миграциядан кейін сұрау баяулауы мүмкін? Көбіне себептер: басқа статистика, басқа оптимизатор және ол басқа жоспарды таңдайды. Мысалы, тапсырыстар бойынша есеп нақты іздеуден толық сканға ауысуы мүмкін, егер селективтілік дұрыс бағаланбаса.

Миграциядан кейін бақылауда ұстау керек заттар:

• Ірі жүктемелерден кейін ANALYZE орындау
• VACUUM (және autovacuum баптаулары), bloat-тың жиналмауын қадағалау
• Нақты қолданылатын фильтрлер мен JOIN-дарға арналған индекстер, «барлығына» емес
• Орындау жоспарларын тексеру: күтпеген скан орын алып жатқан жоқ па
• Массалық жаңартулар: кестелер мен индекстердің өсуін қадағалау

Схеманы көшіру жоспары: кезең-кезеңімен және ауыртпалықсыз

DDL схемасын көшіру дәстүрлі түрде келісілген ережелер болса оңайырақ өтеді. Жиі проблема — аттармен хаос (dbo, әртүрлі иелер, регистр) және «жасырын» тәуелділіктер: сыртқы кілттер, әдепкі мәндер, функциялар.

Жұмыс тәртібі, ол әдетте сәтті

Алдымен мақсатты құрылымды бекітіңіз: PostgreSQL-де қандай схемалар болады (мысалы, dbo орнына app), кестелер қалай аталады, иесі кім, қандай құқықтар қажет. Бұл бірінші жүктеу кейінгі түзетулерге кететін уақытты үнемдейді.

Сосын мынадай ретпен жүріңіз:

• Кестелерге арналған DDL-ды көшіру және типтерді сәйкестендіру (мысалы, NVARCHAR -> TEXT/VARCHAR, DATETIME -> TIMESTAMP, BIT -> BOOLEAN). Бұл кезеңде сыртқы кілттерді уақытша қоспау дұрыс.
• Бірінші ретті кілттер (PK) мен уникалдық шектеулерді қосыңыз. Сосын "ата-ана" кестелерден бастап сыртқы кілттерді қосыңыз, осылайша жасалу тәртібімен қақтығыстар азаяды.
• Кілт генерациясын орнату: SQL Server-дегі IDENTITY әдетте identity бағандарына немесе sequence-ге ауысады. Бастапқы мәндерді бірден орнатыңыз, әйтпесе жаңа жазбалар кілт дауларын туғызуы мүмкін.
• CHECK шектеулері мен DEFAULT мәндерді көшіріңіз, бірақ өрнектерді қайта қарап шығыңыз: T-SQL-де жұмыс істеген нәрсе PostgreSQL-де өзгеруді талап етуі мүмкін.
• Негізгі тесттер үшін бастапқы баптаулармен индекстерді DDL аяқталғаннан кейін құрыңыз.

Кішкентай практикалық мысал

Егер көптеген кестелер dbo схемасында өзара сілтенсе, барлық сыртқы кілтті бірден жасауға тырыспаңыз. Алдымен кестелер мен PK-ды жасап, содан соң FK-ті бөлек сценариймен қосыңыз. Осылайша қай жерде үйлеспеушілік барын анықтау оңай.

Деректерді көшіру жоспары: жүктеу, тексерістер және қайтару

Қай режимге баратыныңызды алдын ала шешіңіз: толық көшіру мен белгілі бір кезеңдегі тоқтату, инкременттік көшіру (екі жақты жазу немесе репликация) немесе аралас тәсіл — алдымен көп деректерді алдын ала жүктеп, соңында өзгерістерді «догоняқтап» алу. Тәжірибеде қысқа финалдық тоқтату басқару жағынан жеңілірек және қайтаруы оңай.

Жүктеу тәртібі жылдамдықтан гөрі маңызды. Егер "факт" кестелерімен бастасаңыз, сыртқы кілттерге тап болып, лас деректерге соқтығасыз. Практикалық тәртібі:

• анықтамалық кестелер (ұйымдар, пайдаланушылар, статустар)
• негізгі объектілер (тапсырыстар, шоттар, пациент карталары және т.б.)
• қатынастық кестелер (many-to-many)
• тарихи және архив кестелері
• қызметтік кезектер мен уақытша деректер (егер қажет болса)

Әр қадамда тексерістер жүргізіңіз. Минимум: жолдар санын, негізгі сандық өрістер бойынша сомаларды және кейбір үлкен кестелер үшін хэш немесе контрольді соманы салыстырыңыз. Таңдап тексеру үшін 50–100 жиі ашылатын құжаттарды қарау пайдалы.

Үлкен кестелерге батчинг және параллель жүктеу жоспарын құрыңыз, бірақ прогресті логтап және қайталанатын етіп жасаңыз. Мысалы, 200 млн жазбалы транзакциялар кестесін күн диапазоны бойынша бөліп жүктеңіз және әр диапазонның аяқталғанын тіркеңіз.

Қайту шынайы болуы тиіс, қағаздағы емес. SQL Server-ді оқуға/жазуға ашық күйде ұстаңыз, миграция журналын сақтаңыз, қайтару критерийлерін алдын ала анықтаңыз (целостность бұзылса, өнімділік критикалық төмендесе, күнді жабу мүмкін болмаса).

Мысал сценарий: экзотикасы жоқ қолданбалы жүйені көшіру

Қарапайым өтініштер есептеу жүйесін елестетейік: қызметкерлер өтініштер жасайды, басшылар статустарды қарайды, бухгалтерия мен ИТ апта сайын есептер алады. Дерекқор шағын, бірақ оған бекітілген есептер мен күнделікті тізімдер бар.

Негізгі кестелерді екі мысалға қысқартуға болады. tickets — идентификатор, жасалған күні, статус, бөлім және орындаушы; ticket_events — өтініш бойынша өзгерістер: кім қашан статус өзгертті. Осыдан типтік мәселелер көрінеді.

Критикалық жиі емес, ең жиі қолданылатындар:

• статус бойынша өтініштер тізімі, дата бойынша сұрыптау (оператор үшін)
• нөмір немесе тақырып бөлігі бойынша іздеу (қоңырау орталығы үшін)
• бөлім және даталар бойынша сүзгілер (басшы үшін)
• агрегаттар: күн/апта бойынша қанша жабылған, орташа өңдеу уақыты

Бұл мысалда жиі қателіктер дата/уақыттан шығады. SQL Server-де GETDATE() және неявный түрлендірулер қолдануға әдеттенген болса, PostgreSQL-де CURRENT_TIMESTAMP пен timestamp/date типтерімен нақты жұмыс керек. GUID uniqueidentifier көбіне uuid-ға ауысады, бірақ формат пен генерацияны тексеріңіз. Пагинация: TOP пен OFFSET/FETCH -> LIMIT/OFFSET. UPSERT: MERGE орнына INSERT ... ON CONFLICT.

-- Пагинация
SELECT ... ORDER BY created_at DESC LIMIT 50 OFFSET 100;

-- UPSERT
INSERT INTO tickets(id, status, updated_at)
VALUES ($1, $2, CURRENT_TIMESTAMP)
ON CONFLICT (id) DO UPDATE
SET status = EXCLUDED.status, updated_at = EXCLUDED.updated_at;

Миграция “көзге көрінбейтін” болмауы үшін көшіруден бұрын базалық линиясын бекітіңіз: 5–10 ең жиі сұрауды, олардың орташа уақытын және p95 көрсеткішін, күтілетін жол санын тіркеңіз. Көшіруден кейін дұрыстықты (сандар, шамалар, мерзімдік таңдамаларды салыстыру) және жылдамдықты салыстырыңыз. Егер бір ғана көрсеткіш өзгерсе, нақты сандар мен сұраулар болғанда себепті табу оңайырақ.

Продқа шығудан бұрынғы минималды нагрузкалық тесттер

Продқа шығудан бұрын бәрін тексеруге тырыспай, басты міндетті растау маңызды: жүйе нақты жүктемені қателерсіз және уақыт бойынша күтпеген салмақсыз ұстайтынын көрсету. 1–2 күнде нақты сұраулар мен параметрлерді қолдана отырып минималды жиын жинауға болады.

Ең көп сигнал беретін үш тест

Көбіне осы үш прогон көп проблемаларды көрсетеді:

• Оқу бәсекелестігі: логтардан алынған 10 ең жиі сұрауды параллель параметрлермен (мысалы, 10–50 бір уақытта) іске қосыңыз. Орташа уақыттан басқа баяу жауаптардың «қойрығын» (tail) бақылаңыз.
• Жазу және жаппай өзгерістер: қосымша қолданатын INSERT, UPDATE және upsert үлгілерін параллель орындаңыз. Блокировкаларды өлшеуді міндетті қосыңыз — миграциядан кейін жиі пайда болатын мәселе — транзакциялар мен күту.
• Аралас жүктеме және есептер: фондық есептер мен агрегаттарды типтік мерзімге (мысалы, соңғы 30 күн) қосып, параллель пайдаланушыларды имитациялаңыз. Бұл әлсіз индексілер мен нашар жоспарларды тез көрсетеді.

Тесттер адал болуы үшін оларды өндірістік көлемге жақын деректер көшірмесінде өткізіп, өлшеулер алдында кэшті қысқаша прогрейт етіңіз.

Қабылдау критерийлері

Алдын ала не жарамды екенін келісіп алыңыз:

• Жауап уақыты: кілт сұраулар үшін p95 және p99 келіскен шектен төмен немесе тең.
• Қателер: драйвер мен қосымша қатесі болмау (таймаут, deadlock, serialization failure) мақсатты бәсекелестік режимінде.
• Блокировкалар: бәсекелестік кезінде блокировкалар күшеймей тұрақты болуы.
• Диск пен WAL өсуі: болжамға сай, кенетті секірістер жоқ.
• Тұрақтылық: 2–3 рет қайталағанда ұқсас нәтижелер.

Мысалы, егер "Айлық сатылым" есептемесі SQL Server-де 3–5 секундта ашылатын болса, PostgreSQL-де 4–6 секундқа дейін қабылдануы мүмкін, бірақ p99 минуттарға шықпау керек. Мұндай ауытқу индекс, сұрауды қайта жазу немесе транзакциялық тәсілді өзгерту қажеттігін көрсетуі мүмкін.

Көшіруде жиі кездесетін қателіктер мен тұзақтар

Ең жағымсызсы — жіңішке айырмашылықтар, олар жүйенің мінезін өзгертіп жібереді. Барлығы жұмыс істеп тұрғандай көрінеді, бірақ есептер бірте-бірте айырылып, кешігулер пайда болып немесе құқықтар бұзылып кетеді.

Бір жиі тұзақ — жолдарды сұрыптау мен салыстыру. SQL Server-де көп нәрсе collation-ға байланысты, ал PostgreSQL-де locale/ICU және баған бойынша collation әсер етеді. Нәтижесінде фамилиялар мен іздеулер әріптік тәртіпке немесе регистрге басқаша қарайтын болады.

Екінші тұзақ — индекстерді "сол күйінде" көшіру. PostgreSQL-де басқа оптимизатор және жазуларға кеткен шығындар болуы мүмкін. Қосымша индекстер жазу жылдамдығын бәсеңдетіп, вакуум пен блаутті көбейтеді. Сондықтан көшіруден кейін индекстерді нақты сұрауларға қарай қайта қарастырған жөн.

Триггер логикасын да тексеріңіз: SQL Server-тегі бір триггер «сиқыр жасаса», PostgreSQL-де бұл блокировкалар мен ұзын транзакцияларға әкелуі мүмкін, әсіресе пакетпен жүктегенде.

Құқықтар мен рөлдер де жиі бұзылады. Қызметтер бір логинмен жұмыс істесе, PostgreSQL-де оған схемаға, секвенцияларға немесе функцияларға қажетті құқықтар берілмеген болуы мүмкін. Қате «permission denied» сияқты көрінеді, бірақ себебі рөлдер карталанбағандығында.

Бірқатар тез тексерістер:

• 10–20 негізгі есеп пен анықтамада сұрыптауды салыстырыңыз
• Индекстерді нақты сұрауларға сәйкес қайта құрыңыз, әдетте емес дәстүр бойынша емес
• Типтік INSERT/UPDATE операцияларының уақытын өлшеңіз
• Қызметтік аккаунттардың схемаларға, секвенцияларға және функцияларға құқықтары бар-жоғын тексеріңіз
• Базалық мониторингті қосыңыз: баяу сұраулар, блокировкалар, кестелердің өсуі

Чек-лист және келесі қадамдар

Миграцияның алдын ала көріністі өтуі үшін бірінші тесттік жүктеуге және өндірістік іске қосуға дейін не дайын болуы қажет екенін анықтап алыңыз.

Схема мен деректер бойынша тексеріңіз:

• Инвентаризация: қандай базалар, схемалар, кестелер, джобтар, процедуралар, триггерлер, есептер және қосымшалар дерекқорға байланған; иелері кім және критикалық жол қалай жұмыс істейді.
• DDL және типтер: типтердің сәйкестігі, NULL/DEFAULT ережелері, identity/sequence, коллациялар және регистрге сезімталдық.
• T-SQL-ді ауыстыру: ең жиі қолданылатын сұраулар мен ауыр нүктелер (TOP/OFFSET, MERGE, дата өңдеу, TRY...CATCH) және олардың қайта жазу жоспары.
• Индекстер мен шектеулер: нақты қолданылатын индекстер, құрама/бөлек индекстер қажет жерлері, қай UNIQUE/FK дерек сапасын қамтамасыз етеді.
• Деректер тексерістері: салыстырулар, контрольды сомалар, таңдамалы верификациялар, лас мәндермен жұмыс сценарийлері.

Эксплуатация және іске қосу бойынша:

• Дұрыстық: негізгі есептер мен операциялар бақылау деректерінде бірдей нәтижелер береді.
• Жүктеме: 3–5 типтік сценарий (іздеу, жазу, пакет өңдеу) нақты көлем мен уақыт өлшемдерімен.
• Қалпына келтіру: бэкап пен қалпына келтіруді бөлек стендте тексеру.
• Қайту жоспары: тоқтату критерийі, шешім қабылдаушылар, қайтып аудару алгоритмі.
• Іске қосу: шектеулі трафикпен пилот, содан кейін кеңейту және толық ауысу.

Инфрақұрылымның иесін бөлек белгілеңіз: серверлер, сақтау, бэкаптар, мониторинг және 24/7 қолдау. Егер мақсатты архитектура мен ресурстарды есептеу қажет болса, GSE.kz интеграция командасымен талқылау ыңғайлы болады, және серверлерді (мысалы, S200 Series) жүктемеге сәйкес таңдаймыз.