The use of database in Cloud Native Application

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください
【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

Recently, ”Cloud Native Application” is getting very popular.The definition of Cloud Native Application varies on case by case,but here it is defined that Cloud Native Application is one developing by FaaS(Functions as a Service) like Lambda(AWS), Azure Functions(Azure) and so on.

When using FaaS,we have to consider a database for FaaS to use.

Generally, Connection-Less and Schema-Less database like CosmosDB(Azure), DynamoDB are suitable for FaaS.

FaaS is “Stateless” which means that one function can not use values other functions use.(“Durable Functions” makes it possible for FaaS to be Stateful)

In other words, Stateless prevent us from using Connection Pooling.A relational Database like MySQL, PostgreSQL and so on is required to establish a connection per executing SQL.It is said that to establish a connection needs high computer resource.The combination of RDB and Connection Pooling is very popular.I’ve heard that Using RDB with FaaS is anti-pattern of Serverless.

In addition, using RDB with FaaS has a problem that RDB reaches the limit of max connections as the result of scaling out of instances caused by increase of requests.

Despite that, I’d like to use RDB with FaaS!!

CosmosDB and DynamoDB is so great product.It is very useful to store data the schema of which is highly likely to be changed and which has very simple structure.But RDB is more suitable for joining some tables to meet the customer’s complicated demand.

I did some investigations as below.

I executed a quite simple SQL “select 1” for 10000 times in the two following cases:

  • establish a connection per executing SQL
  • pool connections and reuse ones

The following code is one establishing a connection per executing SQL.

The following code is one using connection pooling.

The result is as follows:

  • establish a connection per executing SQL:22,497 ms
  • pool connections and reuse ones:2,380 ms

The difference is large, but in the aspect of connection per execution of SQL, it is small difference of only 2 ms.

In case of developing small applications customer’s demand of which is significantly complicated, I guess that RDB is more suitable.

I said that using RDB with FaaS has a problem that RDB reaches the limit of connections as the result of scaling out of instances caused by increase of requests,but in case of Azure Functions, it is likely to be solved by adjusting batchSize and using SIngletionAttributes as following link.

https://github.com/Azure/azure-webjobs-sdk/wiki/Singleton

アバター画像
About 武井 宜行 269 Articles
Microsoft MVP for Azure🌟「最新の技術を楽しくわかりやすく」をモットーにブログtech-lab.sios.jp)で情報を発信🎤得意分野はAzureによるクラウドネイティブな開発(Javaなど)💻「世界一わかりみの深いクラウドネイティブ on Azure」の動画を配信中📹 https://t.co/OMaJYb3pRN
ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。


ご覧いただきありがとうございます。
ブログの最新情報はSNSでも発信しております。
ぜひTwitterのフォロー&Facebookページにいいねをお願い致します!



>> 雑誌等の執筆依頼を受付しております。
   ご希望の方はお気軽にお問い合わせください!

Be the first to comment

Leave a Reply

Your email address will not be published.


*


質問はこちら 閉じる