Изходният код на MongoDB mongot и бъдещето на търсенето и RAG

Начало » Python » Изходният код на MongoDB mongot и бъдещето на търсенето и RAG

MongoDB направи голяма крачка напред за разработчиците, работещи с изкуствен интелект, търсене и съвременни приложения, като направи публично достъпен изходния код на своя engine mongot . Този компонент, който доскоро работеше само зад кулисите в MongoDB Atlas, вече е достъпен под Server Side Public License (SSPL), което дава на екипите много по-задълбочен поглед върху това как текстовите и векторните заявки се индексират, изпълняват и класират, и улеснява изграждането на надеждни системи за генериране на добавени данни (RAG).

Чрез отваряне на вътрешните компоненти на Mongot, MongoDB по същество разрушава функционалната стена между управляваната си облачна услуга и самоуправляемите или Community Edition внедрявания . Разработчиците, които използват MongoDB локално или в собствените си облачни среди, вече могат да използват същата търсачка и търсачка за вектор, използвана в Atlas, като същевременно могат да я инспектират, отстраняват грешки и дори да персонализират начина, по който се държи, без да се налага да превключват бази данни или да инсталират отделно хранилище за векторни данни.

Какво точно е монгот и защо е важно?

Mongot е специализирана услуга за индексиране и изпълнение на заявки, създадена специално за захранване на MongoDB Search и Vector Search . Вместо да влагат цялата логика на търсене в основния процес на базата данни, архитектите на MongoDB разделят отговорностите: mongod остава фокусиран върху транзакционните натоварвания, докато mongot се грижи за тежката работа, необходима за търсене на пълен текст и векторно търсене.

Дизайнът на Mongot се върти около три основни принципа: осигуряване на безпроблемно изживяване за разработчиците, разчитане на доказана технология за търсене и защита на транзакционната производителност.От гледна точка на разработчика, това означава, че все още пишете заявки чрез познатия MongoDB Query API и агрегационен конвейер, използвайки етапи като $search, $searchMeta, и $vectorSearch, без да се налага да изучавате напълно различен език за заявки или да управлявате отделен стек за търсене.

В основата си, mongot разчита на Apache Lucene, за да предостави специализирани индексни структури и алгоритми, които правят разширеното търсене и векторното търсене бързи и богати на функции . Lucene предлага инвертирани индекси, модели за оценяване и векторно-базирано търсене на сходство, докато MongoDB свързва това с оперативната си база данни, така че разработчиците да могат да третират търсенето като естествено продължение на съществуващите си колекции, а не като отделна система.

Ключово архитектурно решение е, че mongot изгражда и поддържа индекси с интензивни изчисления асинхронно, извън прозореца за запис на транзакциите . Той използва потоци от промени на MongoDB, за да репликира актуализации от първичните колекции от данни, така че вмъкванията, актуализациите и изтриванията се приемат от mongot, без да се блокират транзакционните операции. Този дизайн избягва забавянето на основната ви база данни, като същевременно запазва резултатите от търсенето и векторните данни тясно съобразени с вашите данни.

Когато приложение изпрати заявка, съдържаща $search, $searchMeta или $vectorSearch, основният процес mongod действа като пълномощник и препраща съответната част от заявката към mongotСлед това Mongot изпълнява търсенето, използвайки своите индекси, подкрепени от Lucene, изчислява резултати и съвпадения и връща резултатите на mongod, който продължава обработката на останалата част от агрегационния конвейер както обикновено, преди да изпрати окончателния отговор на клиента.

Как се вписва mongot в различни топологии на внедряване на MongoDB

От гледна точка на внедряването, mongot е достатъчно гъвкав, за да се побере както в прости, така и в сложни конфигурации.В по-малки среди или сценарии за разработка, може да се изпълнява като страничен процес на същата машина като mongod, споделяне на процесор и памет и опростяване на операциите, защото всичко се намира на един хост.

За по-големи или по-чувствителни към ресурсите внедрявания, можете да стартирате множество mongot процеси като отделна услуга зад балансьор на натоварването . В този модел mongot може да се мащабира независимо от основните сървъри на бази данни, което ви осигурява изолация за натоварени с големи изчисления задачи за търсене и ви позволява да настройвате фино разпределението на ресурсите, ако например векторното търсене се превърне в основното пречка за производителността.

В шардираните клъстери на MongoDB, mongot се интегрира със съществуващата шардинг топология, вместо да измисля нов модел на разпределение . Всеки шард поддържа свои собствени индекси за локално търсене и векторно търсене асинхронно, като по същество действа като локално копие на търсенето за частта от данните на този шард.

Когато процесът на маршрутизиране mongos получава агрегиращ тръбопровод, съдържащ $search, $searchMeta или $vectorSearch, той разпръсква заявката за търсене в съответните шардовеВсеки фрагмент е mongod препраща етапа на търсене към съответния му екземпляр на mongot, който изпълнява заявката и връща обратно резултатите, сортирани по $searchScore (обикновено в низходящ ред на уместност).

След като всички участващи шардове върнат резултатите си, mongos сортиране чрез сливане, базирано на $searchScore и връща унифициран отговор на клиентаЗа разработчиците, цялото шардиране и координация на търсенето остават прозрачни: вие задавате една заявка и получавате глобално релевантни резултати, докато системата тихо се разделя, разпръсква и рекомбинира зад кулисите.

Лицензиране на SSPL и какво всъщност означава „инспектируемо“

Изходният код на Mongot е издаден под същия Server Side Public License (SSPL), който управлява MongoDB Community Edition . Този лиценз често се описва като „достъпен с изходния код“, а не като класически отворен код: можете да преглеждате, използвате, променяте и споделяте кода, но има допълнителни условия, ако го предлагате като услуга.

Анализатори от индустрията подчертават, че SSPL формално не отговаря на определението за лиценз с отворен код на Инициативата за отворен код . Въпреки че се държи подобно на отворения код, тъй като можете да изучавате и променяте изходния код, той добавя изисквания, насочени към доставчиците на облачни услуги и доставчиците на услуги, които иначе биха могли да вземат кода на MongoDB, да го стартират като управлявана услуга и да го монетизират, без да допринасят обратно.

Този дизайн е много целенасочен: SSPL има за цел да попречи на конкурентите просто да преопаковат безплатния код на MongoDB като свой собствен платен DBaaS . На практика, ако сте организация с краен потребител, която внедрява MongoDB и mongot за вашите вътрешни или насочени към клиента приложения, можете да се възползвате напълно от прозрачността и персонализирането, като същевременно спазвате лицензионните условия, стига да не се опитвате да стартирате облачна услуга, съвместима с MongoDB.

За разработчиците и архитектите, важният извод е, че вече можете да одитирате как Mongot обработва създаването на индекси, парсинга на заявки, оценяването и сходството на векторите, без да го третирате като черна кутия . Получавате способността да разсъждавате за характеристиките на производителността, да изследвате гранични случаи и да потвърждавате, че системата се държи по начин, който отговаря на вашите изисквания за сигурност, съответствие и качество.

Защо отварянето на Mongot е от голямо значение за RAG и AI натоварванията

Пускането на изходния код на mongot е особено важно за екипи, изграждащи системи за генериране на добавени данни (RAG) и приложения, задвижвани от изкуствен интелект . В RAG архитектурите висококачественото търсене върху вграждания и текстово съдържание е от решаващо значение: ако търсенето е слабо или непрозрачно, големите езикови модели в крайна сметка халюцинират или дават непълни отговори.

Като разкрива как се индексират и класират текстовите и векторните заявки, MongoDB дава на специалистите по изкуствен интелект по-голяма увереност в надеждността и повторяемостта на техните процеси и помага за справяне с капана на зависимостта от LLM . Можете да разгледате как се изчисляват оценките за релевантност, как се сравняват векторите и как филтрите и агрегациите взаимодействат с етапите на търсене, което е жизненоважно, когато вашата система с изкуствен интелект трябва да отговаря на SLA от производствено ниво.

MongoDB също така въведе автоматизирани възможности за вграждане на вектори в Community Edition . Това означава, че базата данни може да генерира вграждания за вашето съдържание като част от конвейера, вместо да ви принуждава да управлявате отделна услуга за вграждане и след това да изпращате вектори в хранилище на трета страна. За много проекти, наличието на базата данни, която обработва както суровите документи, така и техните векторни представяния, значително опростява RAG архитектурата.

Този ход оказва конкурентен натиск върху специализирани векторни бази данни, които предоставят само съхранение и търсене по сходство . Ако основното ви хранилище за транзакции (MongoDB) вече може да управлява ефективно и вгражданията и векторното търсене, оправданието за въвеждане на отделна, специализирана векторна база данни често отслабва, особено в малки до средни внедрявания, където оперативната простота е от значение.

Коментаторите посочват, че тази стратегия е насочена директно към самостоятелни векторни платформи . Ако MongoDB може да предостави цялостен конвейер за вграждане и търсене, интегриран със съществуващи модели данни, много екипи ще предпочетат да се придържат към една позната система, вместо да жонглират с отделни доставчици и интеграционни слоеве.

Унифицирано търсене в Atlas, Community и Enterprise

В исторически план, пълното търсене в MongoDB беше тясно свързано с Atlas, напълно управляваното облачно предложение от MongoDB . Ако искате разширени функции за търсене, очакването беше да използвате Atlas, вместо самостоятелно хостване.

Чрез пускането на mongot под SSPL, MongoDB ефективно елиминира функционалното разделение между облачните и самостоятелно управляваните внедрявания . Независимо дали използвате Community Edition, Enterprise Server или Atlas, вече е налична една и съща базова търсачка и търсачка за векторни данни, което ви позволява да синхронизирате по-тясно вашите среди за разработка и производство.

Това обединение носи голямо предимство за хибридните и мултиоблачните стратегии . Организациите могат да използват MongoDB и mongot локално за чувствителни натоварвания, които изискват пълен контрол, като същевременно използват Atlas за други части от своя стек, без да се налага да правят компромиси с възможностите за търсене или да поддържат две различни имплементации.

MongoDB подчертава, че отвореният модел на разработка около Mongot би трябвало да доведе до по-стабилен и сигурен софтуер с течение на времето . С по-широка общност, способна да чете и експериментира с кода, проблемите могат да бъдат открити по-рано, най-добрите практики могат да се разпространяват по-бързо, а приносът – независимо дали е директен или косвен чрез обратна връзка – може да помогне за усъвършенстване на продукта.

Настоящата версия на Mongot все още се описва като публичен преглед . Този статус сигнализира, че MongoDB търси обратна връзка от реалния свят относно моделите на внедряване, характеристиките на производителността и пропуските във функциите, като същевременно полага основите за пълен паритет между внедряванията в Общността и търсенето в Atlas през следващите итерации.

Практически ползи за разработчици и инженерни екипи

С вече достъпния за инспектиране mongot, инженерните екипи получават няколко конкретни предимства, които надхвърлят чистото любопитство . Първото е напълно унифицирана платформа: можете да изпълнявате една и съща функция за търсене и векторно търсене в Atlas, локални клъстери и хибридни конфигурации, което опростява стратегиите за тестване, отстраняване на грешки и миграция.

Дълбоките възможности за одит и отстраняване на грешки са друга голяма печалба . За регулирани индустрии или области с високи залози, възможността за проследяване точно как се интерпретира заявката, как се изчисляват резултатите и как се прилагат филтрите е изискване, а не лукс. Достъпът до изходния код позволява на архитектите и екипите по сигурността да преглеждат имплементацията, вместо да се налага да разчитат единствено на документацията на доставчика.

Съществува и възможност за персонализиране по време на изграждане и изпълнение . Тъй като mongot може да бъде изграден от изходния код, екипи с много специфични ограничения на средата – като например защитени образи на операционната система, специфични инструменти за компилиране или специализирани хардуерни настройки – могат да коригират процеса на изграждане, за да отговаря на техните стандарти, като същевременно останат в съответствие с upstream.

Разработчиците на приложения могат също да използват кодовата база на Mongot като ориентир, за да се научат как да проектират високо мащабируеми системи с интензивно използване на данни върху MongoDB . Източникът предлага реални примери за контрол на паралелизма, поддръжка на индекси, потребление на поток от промени и оркестрация на шардирани заявки, които са ценни модели при проектирането на ваши собствени услуги.

И накрая, тъй като mongot вече е част от същата екосистема, управлявана от SSPL, като MongoDB Community Edition, оперативните екипи могат да прилагат съществуващите политики, инструменти и подходи за управление последователно както в основната база данни, така и в търсачката . Това намалява трудностите при внедряването на разширени функции за търсене в среди, където съответствието и управлението на промените са строго контролирани.

MongoDB, mongod, mongos и изграждане от изходния код

Разбирането на мястото на Mongot спрямо останалата част от стека на MongoDB помага да се изясни по-голямата картина.В основата на всяко внедряване е mongod, основният сървър за бази данни, който съхранява документи във формат, подобен на JSON, с активирана схема, и обработва CRUD операции, транзакции и по-голямата част от логиката на агрегиране.

В шардирани среди, mongos действа като рутер на заявки, координирайки кои шардове трябва да обработват кои заявки и обединявайки резултатите от тяхMongot се интегрира и с двата компонента, като получава проксирани етапи на търсене от mongod екземпляри на всеки шард и участващи в по-широкия работен процес за разпръскване и събиране, воден от mongos.

MongoDB се разпространява в различни издания: Community Edition е безплатно и с достъпен изходен код, докато Enterprise Server добавя търговски функции . За облачно хоствани натоварвания, MongoDB Atlas предоставя напълно управлявана услуга, абстрахирайки инсталирането, надстройките, архивирането и известна оперативна сложност.

За организации, които се нуждаят или предпочитат да компилират MongoDB от изходния код, има официални инструкции за компилиране, които варират в зависимост от основната версия . Когато правите това, е изключително важно да се съпоставят препоръчителните версии на C++ компилатора, Python, SCons и свързаните зависимости, тъй като отклоненията в инструментариума могат да доведат до фини грешки или проблеми с производителността, които не се появяват в предоставените от производителя двоични файлове.

Инженерите на MongoDB често съветват, че ако не променяте активно изходния код, разчитането на официалните пакети е като цяло по-безопасно и по-ефективно . Тези двоични файлове се валидират непрекъснато чрез отворената система Evergreen CI и са подписани за целостност, което осигурява по-силни гаранции за сигурност и стабилност, отколкото ad-hoc компилациите, създадени в персонализирани среди.

Съображения за сигурност, LDAP интеграция и SSPL

Проблемите със сигурността често карат организациите да обмислят изграждане от изходния код или да упражняват по-строг контрол върху своите MongoDB внедрявания . Въпреки че компилирането на собствени двоични файлове може да изглежда по-сигурно, MongoDB посочва, че официалните пакети вече преминават през обширни тестове и подписване и включват най-новите корекции – включително важни корекции в малки издания, които клиентите понякога пренебрегват.

За удостоверяване и оторизация, MongoDB Enterprise въвежда разширени интеграции, включително поддръжка на LDAP, която може да съпоставя външни потребители на директории с идентичности на базата данни.Една забележителна характеристика е --ldapUserToDNMapping конфигурационен параметър, който ви позволява да преобразувате входящите потребителски имена в пълни LDAP отличителни имена (DN), използвайки JSON-кодиран набор от правила за съпоставяне.

Конфигурацията на картографирането е подреден масив от документи, всеки от които предоставя регулярен израз match и или a substitution or ldapQuery шаблонКогато потребителят се удостовери, mongod оценява потребителското име спрямо тези правила последователно, прилага първото съвпадение и използва полученото DN или LDAP заявка, за да търси потребителя в директорията.

Само един от substitution or ldapQuery може да бъде посочено за всеки документ за съпоставяне и ако трансформацията е неуспешна или LDAP сървърът не може да бъде достигнат, MongoDB връща грешка и отхвърля връзкатаТова стриктно поведение гарантира, че удостоверяването няма да се връща тихомълком към опасни настройки по подразбиране, когато търсенето в директорията е неуспешно.

Започвайки с MongoDB 5.0, --ldapUserToDNMapping Настройката приема и празен низ или празен масив, за да сигнализира, че удостовереното потребителско име трябва да се третира директно като LDAP DN.В по-ранни версии, празно съпоставяне би довело до неуспех на трансформацията, така че тази промяна опростява конфигурации, където потребителските имена вече съвпадат точно с LDAP DN имената.

От гледна точка на лицензирането и управлението, комбинирането на SSPL за основната база данни и mongot с опции за удостоверяване от корпоративен клас позволява на организациите да обединят оперативния контрол, сигурността и прозрачността на кода в един стек . Екипите могат да инспектират търсачката, да се интегрират с LDAP или други системи за идентичност и все пак да се възползват от последователна рамка за лицензиране на всички компоненти.

Като цяло, решението за отваряне на Mongot съгласува оперативната база данни, търсачката и възможностите на изкуствения интелект на MongoDB по начин, който дава на разработчиците повече мощност, без да ги принуждава да се придържат към фрагментирана архитектура . С търсене по налични източници и търсене на вектори, автоматизирани вграждания в Community Edition, гъвкави модели на внедряване и дълбока интеграция в съществуващия модел на шардинг и маршрутизация, екипите вече могат да изграждат усъвършенствани RAG и AI изживявания, като същевременно остават в рамките на една единствена, добре разбираема платформа.