|
Управляваните от данни приложения обхващат широк спектър от сложност, от прости микроуслуги до системи, управлявани от събития в реално време при значително натоварване. Въпреки това, както всеки екип за разработка и/или DevOps, натоварен с подобрения в производителността, ще потвърди, бързите приложения, управлявани от данни в световен мащаб, е „нетривиално“.
Модерните архитектури на приложения като JAMstack налагат разделянето на проблемите чрез преместване на данните и изискванията за постоянство към API. Чистото разделяне на статично съдържание, бизнес логика и постоянство на данните позволяват всеки да бъде мащабиран и управляван независимо.
Много предприятия също са фокусирани върху отделянето на своите монолитни приложения, за да използват микроуслуги и често се внедряват в среди без сървър. Тази промяна към повече отделяне за по-добра екологична изолация може също да осигури по-добра регионална гъвкавост по отношение на това къде се разгръща бизнес логиката и как се мащабира. Приложенията вече могат да се разгръщат глобално с едно действие на CI/CD.
Нивото данни обаче представлява по-голяма сложност. Съществуват практически предизвикателства като последователност на транзакциите, висока наличност и производителност на заявки при натоварване. Съществуват ограничения като спазването на PII и изискванията за съответствие. И има непреодолими граници като тези, които законите на физиката налагат на латентността.
Кеширане на приложения
Много екипи за разработка се стремят към кеширане, за да решат тези проблеми на слоя на приложението, подкрепено от постоянни слоеве като Redis или собствени системи. Концепцията е проста:съхранявайте данните, поискани от клиента за определен период от време и ако ги видим отново, ние сме готови да обслужим следващата заявка, без да прибягваме до базата данни за произход. Създаването на добра стратегия за кеширане носи собствен набор от предизвикателства:какви данни да се кешират, как да се кешират и кога. И може би по-важното е какво, как и кога да извадим данните от кеша. Стратегията за кеширане трябва да бъде добре дефинирана, разбрана и използвана за всеки нов набор от функции, добавен към приложението, между разработчици и потенциално отделни екипи. Времето за разработка и сложността са цената.
Реплика за четене на база данни
Алтернативно, много предприятия решават проблемите със забавянето и мащабирането с реплики за четене на база данни. Репликата за четене са екземпляри на първичната база данни само за четене и се поддържат автоматично синхронизирани (асинхронно), когато се правят актуализации на основната. Създаването на солидна стратегия за четене-реплика е трудна задача, пълна със собствени фини и не толкова фини разходи и сложност.
Голяма част от тази сложност може да бъде укротена с ScaleGrid. Напълно управляваните реплики за четене могат да бъдат разгърнати с натискане на бутон от ScaleGrid (с поддръжка на HA) във всички основни облаци и региони, като основното предимство е, че данните се поддържат автоматично в синхрон с основната база данни.
Въпреки това, репликите за четене не могат да избегнат необходимостта от стартиране на множество, може би много множество сървъри на бази данни и свързаните с тях разходи.
Различен подход:PolyScale.ai Edge Cache
PolyScale е кеш на ръба на базата данни, който използва различен подход. Кешът на PolyScale осигурява две основни предимства:подобрено забавяне на заявката и намалено натоварване на базата данни. Нека го разбием малко:
Регионално забавяне се решава подобно на CDN; PolyScale осигурява глобална крайна мрежа от точки на присъствие (PoP) и съхранява отговорите на заявка към базата данни близо до първоначалния клиент, което значително ускорява отговорите.
Прочетете ефективността на заявката е значително подобрен, тъй като PolyScale ще обслужва всяка заявка за кеширана база данни за <10ms, независимо от сложността на заявката. Освен това, като се има предвид, че заявките за четене се обслужват от PolyScale, това натоварване никога не оказва влияние върху базата данни за произход.
Внедряване
PolyScale може да бъде внедрен без писане на код или инсталиране на сървъри за няколко минути. Просто актуализирайте низа за връзка на клиента на базата данни (било то уеб приложение, микросервиз или BI инструмент, като Tableau) с името на хост PolyScale. След това трафикът на базата данни ще премине през граничната мрежа и е готов за кеширане.
Тъй като е съвместим с MySQL и Postgres, PolyScale е напълно прозрачен за клиентите на базата данни, следователно нищо не се променя с текущата ви архитектура. Без миграции, без промени в транзакционността и без промени в текущия ви език на заявка. Наистина включи и играй.
Как работи?
Глобалните мрежови прокси сървъри на PolyScale и кешират собствените кабелни протоколи на базата данни, така че да е прозрачен за всеки клиент на база данни. Заявките се проверяват и четат (SQL SELECT ) може да се кешира географски близо до източника на заявката за ускорена производителност. Целият друг трафик (INSERT , UPDATE и DELETE ) безпроблемно преминава към изходната база данни.
ИИ на PolyScale е на път към пълна автоматизация. Вместо да конфигурира кеша според нуждите, платформата ще измерва потока на трафика и непрекъснато ще коригира свойствата на кеша, за да осигури оптимална производителност. Можете да прочетете повече за модела за кеширане на PolyScale AI тук.
Заключения
PolyScale.ai предоставя модерен, plug and play подход за производителност и мащабиране на ниво данни. Платформата PolyScale е на път към пълна автоматизация, като веднъж свързана, ще управлява интелигентно кеширането на данните за оптимална производителност.
Като се има предвид, че PolyScale е съвместим с текущата ви база данни, не са необходими промени за мащабиране на четенията глобално за минути. Опитайте!
