CobbleDB: Төмен кідіріс пен құн үшін ЖИ іздеу қоймасын қайта құру

Жасанды интеллектке негізделген іздеу веб-контентті өңдеу, сақтау және ұсыну тәсілдеріне әртүрлі талаптар қояды. Ол талаптарды масштабта қанағаттандыру үшін біз өнімділікті жақсарту және құнды азайту үшін бүкіл стекті нөлден бастап қайта құрып жатырмыз.

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

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

Жаңа ішкі кодтау агенттері тобының көмегімен біз бұл қабатты CobbleDB (кілт-мәні ыстық дереқоры), тұрақты құжат күйі мен жариялауға арналған Pillar және топтамалық жаңартуларға арналған Lorry көмегімен қайта құрдық. Қайта жобалау құжатты өңдеуді ыстық дерекқорға қабылдаудан бөліп алады және қызмет көрсетуді жұмыс жүктемемізге бейімдеуге мүмкіндік береді. Өндіріске дейінгі және кейінгі өлшемдер шамамен 5× төмен топтамалық оқу кідірісін көрсетеді, ал ішкі шығындар моделі DynamoDB-ке қатысты кем дегенде 20% үнемдеуді бағалайды.

Жасанды интеллектке негізделген іздеуге арналған сақтау инфрақұрылымы

Классикалық іздеу стегі тілдік модель үшін емес, адам оқырманы үшін жасалған. Бұл айырмашылық жүйе веб-контентті дайындау, сақтау және ұсыну қажет болатын гранулярлықты өзгертеді.

Шикі HTML форматын модельге дайын контентке айналдыру үшін біздің өңдеу конвейері әр бетті тазартады, оны семантикалық тұрғыдан үйлесімді үзінділерге бөледі, олардың ендірулерін есептейді және үзінділер мен ендірулерді дерекқорда бірге сақтайды. Сұрау кезінде қызмет көрсету конвейері сұрауға ең сәйкес келетін мәтінді таңдап, оны модельге жібереді.

Екі бөлек жұмыс процесі

Сондықтан сақтау қабаты әртүрлі талаптары бар екі жұмыс процесін қолдауы керек: өңдеу конвейерінен жаңартуларды қабылдау және төмен кідіріспен оқуға қызмет көрсету.

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

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

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

Басқарылатын дерекқордың қай жерде жетіспейтіні

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

Біріншіден, пайдалануға негізделген баға белгілеу оқылған немесе жазылған әрбір байт үшін ақы алады. Бір Іздеу API сұрауы біз алуымыз керек беттерге сәйкес келетін 100-120 кілтті қамтиды. Деректерді алу процесі сұрауды әр элементтің орташа өлшемі шамамен 50 КБ болатын 10-20 бет кілттерінен тұратын кішірек топтамаларға бөледі. Бұл жазбаларды қайталап оқу айтарлықтай сыйымдылықты тұтынды, ал үздіксіз сканерлеулер мен кесу немесе ендіру модельдеріндегі өзгерістер көбірек жазуларды тудырды. Экономикалық көрсеткіштер API шақыруларының санына ғана емес, сонымен қатар жазбалардың өлшемі мен жиілігіне де байланысты болды.

Екіншіден, басқарылатын қызметте өнімділікті баптау үшін бізге қажет икемділік жоқ. Бізге қажет операция ауқымы тар болды: бет идентификаторларының топтамасы берілгенде, олардың дайындалған мазмұнын жылдам қайтару. Біз қай машина бөлімді ұстайтынын, оның кэшіне қанша жад бөлінетінін және қай реплика сұрауды өңдейтінін бақылағымыз келді. Бұл басқару элементтері маңызды, өйткені кэштелмеген оқу, кросс-зоналық өту немесе баяу реплика бүкіл топтаманы кешіктіруі мүмкін. DynamoDB API артында өз сақтау орны мен реплика әрекетін басқарады. Біз қызметті конфигурациялай алдық, бірақ оның ішкі орналасуын, сақтау қозғалтқышының кэштерін немесе жұмыс жүктемеміздің төңірегіндегі репликаны таңдау саясатын баптай алмадық.

Үшіншіден, өңдеу жұмыстары тікелей ыстық дерекқорға жазумен байланысты болды. Біздің бұрынғы өңдеу конвейері әрбір дайындалған бетті тікелей DynamoDB-ке жазды. Сондықтан үлкен қайта өңдеу тапсырмасы жеке ыстық дерекқор жаңартуларының толқынына айналды және өңдеу жұмыстары ыстық дерекқордың өткізу қабілетінің шектеулері мен қайталау әрекетінің тәртібіне бейімделуге мәжбүр болды. Жаңа кесу әдісін қолданып көру, ендіру моделін өзгерту немесе жаңа өріс қосу үшін біз MapReduce операциясын барлық дерекқор бойынша 1-2 күн ішінде іске қоса алмадық. Бөлек қызмет топтамаға біріктіріп, ыстық дерекқорға өзінің қарқынымен жеткізе алатын сақталған бет жаңартуларының тәуелсіз ағыны болған жоқ.

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

Құжат күйін, жаңартуды жеткізуді және қызмет көрсетуді бөлектеңіз

Жаңа архитектура әрбір жауапкершілікті әртүрлі компонентке тағайындайды. Pillar тұрақты құжат күйін сақтайды және нені жариялау керектігін шешеді. Lorry бұл экспорттарды бөлімделген топтамаларға айналдырады. CobbleDB топтамаларды қабылдайды және бет кілті бойынша дайындалған жазбаларға қызмет көрсетеді.

Ұлғайту

CobbleDB: баптауға болатын оқу жолы

CobbleDB — бұл сұрау кезінде дайындалған жазбаларға қызмет көрсету үшін оңтайландырылған ыстық дереқорымыз. Бұл таратылған кілт-мәні сақтау орны: кілттер — бет идентификаторлары (хэштелген URL мекенжайлары), ал мәндер — беттің өңделген көрінісі (олардың алдын ала бөліктерге бөлінген үзінділері және әр бөліктің векторлық ендірулері).

Маңызды өзгеріс – сақтау конфигурациясын біздің басқара алуымыз.

Деректер бөлініп, деректер түйіндері арасында таратылады. Бұл таратылған формат дерекқори өңделген беттердің орасан зор жиынтығын сыйғызу үшін көлденеңінен масштабтала алатынын қамтамасыз етеді. Әрбір бөлімнің үш түрлі түйінде үш репликасы бар; егер бір көшірме қолжетімсіз болып қалса, қалғандары оқу әрекеттеріне қызмет көрсетуді жалғастыра алады.

Әрбір деректер түйініне бөлімдердің ішкі жиынтығы тағайындалады. Түйін өз деректерін пакеттік енгізу арқылы келетін оқуға бағытталған жүктемелерге өте қолайлы ашық бастапқы кодты ендірілген кілт-мәні сақтау қозғалтқышы RocksDB көмегімен сақтайды.

Кэштелген деректер жадтан ұсынылуы мүмкін, ал кэштелмеген оқулар жергілікті NVMe сақтау орнын пайдаланады. Бұл бізге басқарылатын қызметтің ішкі кэш саясатын қабылдаудың орнына, байқалған жұмыс жүктемесі үшін жад пен диск балансын баптаудың тікелей жолын береді.

Күйсіз сұрау роутері кілттерді бөлімдерге хэштейді және сұрауларды түйіндерге параллель түрде бағыттайды. Сондай-ақ архитектураға PostgreSQL көмегімен жұмыс істейтін метадеректер қызметі мен тұрақты объектілік сақтау орны кіреді.

Бұл дизайн жұмыс жүктемесі талап ететін оқу үлгілерін қолдайды. Сұрау тиісті беттердің кандидаттар жиынтығын алу үшін іздеу мен рейтингтен өткеннен кейін, ыстық дерекқорға сол беттердің мазмұны үшін жаппай сұрау жасалады. Бұл оқу сұраулары роутерге келіп түседі және тиісті деректер түйініне бағытталады. Мүмкіндігінше, роутер кросс-зоналық кідірісті азайту үшін сұрауларды сол қолжетімділік аймағындағы түйінге жіберуді бірінші орынға қояды. Әрбір деректер түйіні бірнеше кілттерді бір уақытта төмен кідіріспен алуға арналған RocksDB топтамалық оқу API интерфейсі MultiGet көмегімен бет мазмұнын ала алады. Егер түйін жауап беруге баяу болса, жүйе басқа түйінгі басқа бөлім репликасына да сұрау жібере алады, бұл шекті кідірісті жақсартады.

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

Ұлғайту

Pillar және Lorry: тұрақты жазу жолы

Жеке сақтау қабаты біз сканерлейтін және өңдейтін барлық нәрсені қадағалап отырады, жаңартуларды нұсқалары бар құжат күйіне біріктіреді және қажетті көріністерді CobbleDB пен іздеу индексіне жариялайды. Біз осы мақсат үшін өз құжаттарымыздың күйі мен жариялау қабаты Pillar-ды жасадық.

Pillar YTsaurus арқылы жұмыс істейді. Ол бет компоненттерін (мысалы, метадеректер, бөліктер және ендірулер) жеке YTsaurus кесте отбасыларында сақтайды. Ол сондай-ақ бөліктер мен ендірулердің нұсқаларын қадағалайды, бұл негізгі модельдердің өзгеруі үшін бірнеше көріністердің бір-бірін өшірмей қатар өмір сүруіне мүмкіндік береді. Pillar пен YTsaurus арзан HDD жадын пайдаланатындықтан, біз бұрын DynamoDB-те сақтағаннан әлдеқайда көп құжаттарды сақтай аламыз.

Pillar ішкі жиындарды немесе жаңа беттер немесе жоғары құнды беттер сияқты саясат арқылы анықталған беттер топтарын қадағалайды. Ішкі жиынға мүшелік CobbleDB сияқты төменгі ағындағы компоненттерге қандай жаңартуларды жіберу керектігін анықтайды. CobbleDB қымбатырақ NVMe сақтау орнын пайдаланады, сондықтан біз іздеу нәтижелерінде шынымен пайдаланғымыз келетін құжаттарды ғана экспорттаймыз. Беттің мазмұны жаңартылғанда немесе ол ішкі жиынға қосылған немесе одан жойылған кезде, Pillar тиісті экспорт жұмысын кезекке қоюға жауапты болады.

Дұрыстықты қамтамасыз ету үшін Atomic YTsaurus транзакциялары күйді, экспорттау ниеттерін және тұтынылған енгізуді қамтиды. Транзакция сәтті аяқталуы үшін жүйе тұрақты күйді жаңартып, енгізуді есепке алынды деп белгілеп, барлық қажетті экспорттарды кезекке қоюы керек; егер транзакция тоқтатылса, ешбір қабатта ешқандай өзгеріс жасалмайды.

CobbleDB жаңартулар бөлімге сәйкес топталуын күтеді. Pillar экспорттары Lorry деп атайтын күйсіз қызмет арқылы осы форматқа түрлендіріледі. Оның жалғыз міндеті – тұрақты бөлімге сәйкес келетін кезектен экспорт жазбаларын оқу, оларды әр бөлімнің топтамалық файлдарына жинақтау және CobbleDB-ке беру.

Lorry мен Cobble арасында қосымша хаттама деректер жазықтығын (S3) басқару жазықтығынан бөледі. Lorry топтаманы бірегей идентификатор астында S3-ке жазады және топтаманы Cobble ішінде тіркейді. Cobble бөлімінің репликалары қабылдайтын келесі S3 топтамасы үшін топтамаға немесе басқару жазықтығының API интерфейсіне дербес сұрау жасайды және топтама жаңартуларын хронологиялық тәртіппен асинхронды түрде қолданады. Бұл баяу немесе қалпына келіп жатқан түйін жүйенің қалған бөлігін баяулатпай, өз қарқынымен үлгеріп кете алатынын білдіреді.

Ұлғайту

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

Тексеру

5x жылдамырақ

Ыстық дерекқорды көшіргеннен кейін, топтамалық оқудың орташа кідірісі 31.4 мс-тен 5.60 мс-ке дейін төмендеді. p90 көрсеткіші 56.7 мс-тен 9.77 мс-ке дейін, ал p99 көрсеткіші 123 мс-тен 24.2 мс-ке дейін төмендеді. Көрсеткіштер арақатынасы 5.08× пен 5.80× аралығында, бұл әдеттегі сұрауларда да, шекті жағдайларда да жақсаруды көрсетеді.

Ұлғайту

Бұл сан әрбір сұрау шамамен 10-15 кілтті сұрайтын топтамалық оқулардан алынған. Орташа пайдалы жүктеме элементінің өлшемі – 50КБ. Екі жүйеге де шамамен 200 мың rps жылдамдықпен сұрау жасалды, дегенмен біз ешқандай нашарлаусыз 500 мың rps дейінгі жүктеме сынақтарын да өткіздік.

CobbleDB үлесін бөліп көрсету үшін орнатудың барлық басқа аспектілері өзгеріссіз қалдырылды. Дегенмен, бұл әлі де бақылауға негізделген «дейін және кейін» салыстыру болып қала береді; жүйелер бірдей сұрауларды басқарылатын жағдайларда емес, әртүрлі уақытта тікелей өндірістік трафикке қызмет көрсетті. Сондықтан біз синтетикалық бенчмаркта екі жүйе мүмкіндігін де өлшедық. Өндірістегі сұрауларға ұқсату үшін біз екі жүйеге де 10-15 кілттен тұратын топтамалармен және 100B-тан 100 KiB-қа дейінгі мәндермен сұрау жасадық.

Ұлғайту

DynamoDB бұл контексте қиналады, өйткені оның басқарылатын оқу жолын осындай көлемдегі топтамалық оқулар үшін баптау мүмкін емес. Керісінше, CobbleDB дәл осы жағдай үшін оңтайландырылған, өйткені орналасуды, кэштеуді және реплика басқару элементтерін өзіміз басқарамыз. Ол кілттерді бөлімдер бойынша топтастырады, бөлім репликаларына қарсы оқу әрекеттерін параллель орындайды және баяу оқуларды басқа репликаларға қарсы сақтандыра алады. Біздің нәтижелеріміз бұл дизайн таңдаулары өндірістік ортада жылдамырақ оқуға әкелетінін көрсетеді.

20%-ға арзан

CobbleDB сонымен қатар DynamoDB-ке қарағанда айтарлықтай арзан. Сақтау орнынан басқа, DynamoDB сонымен қатар оқылған немесе жазылған әрбір байт үшін ақы алады. Корпусымыздың және қызмет көрсету трафигінің масштабында бұл пайдалануға негізделген төлемдер жалпы құнның маңызды бөлігіне айналады. Үздіксіз жаңартулар жазу сыйымдылығын тұтынса, сұрау үшін алынған дайындалған беттердің әрбір топтамасы оқу сыйымдылығын тұтынады.

Біз шығындарды үнемдеуді сақтау көлемінің, жазу сыйымдылығы бірліктерінің және оқу сыйымдылығы бірліктерінің ішкі бағалаулары негізінде есептедік. Әрбір міндеттеме деңгейінде CobbleDB DynamoDB-ке қарағанда кем дегенде 20%-ға арзан. Нақты үнемдеу бұдан да жоғары болуы мүмкін, өйткені бұл нәтижелер сығымдау арқылы сақтық көшірме жасауда ықтимал үнемдеуді ескермейді.

ЖИ агенттерінің тобы оны құруға қалай көмектеседі

CobbleDB мен айналасындағы инфрақұрылымды құру мүлде оңай болған жоқ. CobbleDB-дің тек негізгі дерекқорының өзі шамамен 40 000 жол Rust кодынан тұрады, ал көшіру жұмысы өндірістік ауқымда дұрыстығы мен ақау кезіндегі мінез-құлқын тексеруге, CobbleDB-ді өңдеу және қызмет көрсету жолдарымен біріктіруге, сондай-ақ тірі трафикті қауіпсіз көшіруге ауқымды күш жұмсауды талап етті.

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

Біз CobbleDB жобасына осындай белсенді, әрқашан қосулы агенттер ұжымын тағайындадық. Олардың бірінші міндеті – орындалып жатқан жұмыстың дәл моделін жасау. Олар жоба каналын және белсенді тредтерді тексеріп, орындалмаған элементтерді олардың pull request-терімен және иелерімен байланыстырды, сондай-ақ жүйе денсаулығы мен келесі әрекеттердің ағымдағы есебін дайындады. Осыдан кейін олар инженерлік циклдің бірнеше бөлігінде жұмыс істеді:

• Код пен инфрақұрылым өзгерістері қарап шығылды.
• Қауіпсіз емес қалпына келтіру болжамдары, ескірген құрастыру сілтемелері және орындалу уақытында сәтсіз болатын конфигурациялар сияқты байқамай қалу оңай болатын блоктар анықталды.
• Мақсатты түзетулер, сынақтар, мониторинг өзгерістері және операциялық құжаттама дайындалды.
• Өндірістік әрекеттердің нақты түрде адам иелігінде қалуын қамтамасыз ете отырып, CI, шолу және инфрақұрылымдық шектеулер қадағаланды.
• Бақыланатын шығарылымдар және сақтық көшірме жасау немесе қалпына келтіру жаттығулары, содан кейін жүйенің байқалған күйі шығарылымның сәттілік критерийлерімен салыстырылды.
• Инженерлер не шыққанын, не әлі де блокталғанын және қай жерде әлі де адамның пікірі қажет екенін көре алуы үшін жоба есептері жүргізілді.

Инженерлер әлі де архитектураны анықтады, маңызды өзгерістерді қарап шықты және өндірістік операцияларды рұқсат етті. Агенттер осы шешімдер арасындағы үздіксіз тексеру мен орындау жұмыстарының көбін өзіне алды. Бұл шағын командаға жобаны тиімді жүргізуге мүмкіндік берді — негізгі CobbleDB инфрақұрылымын екі адам-инженер және жүздеген ЖИ агенттері екі ай ішінде салды.

Қорытынды

CobbleDB — бұл жалпы мақсаттағы дерекқор емес; ол асинхронды өңдеу конвейері арқылы жұмыс істейтін дайындалған бет жазбаларын қайталанатын топтамалық оқудың біздің нақты жұмыс жүктемемізге арнайы жасалған. Тұрақты күйді, жаңартуды жеткізуді және сұрау кезінде қызмет көрсетуді бөлу арқылы біз бір дерекқор интерфейсін олардың барлығын сыйлауға мәжбүрлемей немесе техникалық қызмет көрсету жұмыстарын тікелей сұрау жолына ығыстырмай, әрбір жауапкершілікті тәуелсіз түрде оңтайландыра аламыз. CobbleDB-ке көшу инфрақұрылымдық шығындарды азайта отырып, орташа және шекті кідірістерді айтарлықтай жақсартты.

Жасанды интеллектке негізделген инфрақұрылымды өз бетімізше дамытуды жалғастыра отырып, біз үшінші тараптың іске асырулары мен баға белгілеу модельдеріне тәуелді болған кезде қол жеткізу мүмкін емес өнімділік пен құнды оңтайландыра аламыз. Қуатты ЖИ агенттері есептеулерді сатып алудан гөрі құру пайдасына қарай тағы да бұрыды.

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

Дәйексөз

@online{perplexity2026Cobbledb,
  author = {{Perplexity} and Alexandr Yarats and Marco Montagna and Aleksei Bykov and Alexey Gusev and Ali Abdullaev and Amir Mokhammed-Ali and Andrey Zosimov and Denis Kremko and Gleb Vishnevsky and Micah Zirn and Phi Hoang and Claire Beamer and Jeremy Yang and Jerry Ma and Denis Yarats},
  title = {{CobbleDB: Rebuilding AI search storage for lower latency and cost}},
  date = {2026-09-14},
  url = {https://www.perplexity.ai/hub/blog/cobbledb}
}