Denis Magda

Hi Nathan, thanks for stopping by the presentation and I'm glad you liked it!

The upstream version of Kine improved since the time I posted this article and this is the reason why I decided to use the last upstream version during the talk. However, I would still encourage to merge the YugabyteDB-specific changes from the fork into to the upstream version. Those changes make the solution much more performant and let utilize given resources better.

Unfortunately, I don't have time to maintain the fork. But I can connect you to the YugabyteDB team. Who knows they might be interested in partnering with you if you need to do a PoC with YugabyteDB. Just find me on LinkedIn and I'll make an intro ;)

Hey, here is a complete application that uses Spring AI, Postgres pgvector, and OpenaAI:
https://github.com/YugabyteDB-Samples/YugaPlus

One note, the article shows how to use both ChatClient and EmbeddingClient in the article. The app uses only the latter.

Let me know if you have any questions.

> BTW OLTP applications should not fetch 1000s of records at once!

I meant 1000s of user requests per second that fetch 1000s or more records via an app and database instance.

Imagine, that your entity has 10 fields of variable size while an API call needs only 3 of them. The app will be wasting database, network, and backend resources by fetching and transferring 7 fields that nobody needs. If those 7 fields consume 40 bytes, then every second 40KB of garbage (1000 requests X 40 bytes = 40KB) will be fetched and transferred over the network. If those fields' size is 100 bytes, then the app fetches 1000 requests X 100 bytes = 100KB of garbage every second. And that's just for a single API call. While there are usually many more API calls of this kind.

So, IMO, it's not about micro-optimization but about a scalable and efficient architecture that is especially important for the public cloud where you pay for every transferred byte of data and CPU cycle.

Hey Sergio,

It depends on the application load - how many entities per second an app needs to fetch from a database. For instance, if it's just 10 entities per second, then certainly, the suggested optimizations might be overkill. But if the app needs to fetch 100s or 1000s of records per second, then the less you retrieve from the database, the better.

Also, consider another example when you need to get a list of items from the database - getting a list of Entities and then converting it to a list of DTOs/Records might have a noticeable performance impact (again, depends on the app load).

Yeap, the check constraint is one of the alternate solutions here. Both the constraints and enums are used in the wild for various reasons. And this article is solely for those who went forward with enums.

I do see the method used frequently, especially by beginners. Probably, because it is used in many getting-started tutorials and learning materials.

The more skillful you become, the more you turn to various optimization techniques like the one mentioned by you (findById()->managed entity->update it in place and it will get persisted), or @DynamicUpdate, or native queries, etc. Personally, I'm a big fan of native queries.

Various use cases and various options.

For big enterprises or apps/services with a global customer base, multi-region deployments are crucial, fully agree - latency, fault-tolerance, and data residency requirements.

At the same time, small and mid-size companies will always be out there. Those might not need distributed databases at the beginning of their journey. They can comfortably seat on Amazon Aurora, Google AlloyDB or Neon that function across multiple AZs, boost reads via read replicas, and can withstand AZ-level outages. For such companies, 65ms roundtrip latency from the West to East cost is not usually a big deal.

And it's fair to mention that relational databases evolved in the last decade. There is a class of distributed SQL databases (distributed RBDMS - Google Spanner, CockroachDB, YugabyteDB) that are architected to function across multiple availability zones and regions. So, it's no longer the territory just of NoSQL. SQL and NoSQL are merging: https://dzone.com/articles/exploring-multi-region-database-deployment-options

Hi Rabi, sorry for a delayed reply. Feel free to send messages to Apache Ignite user list regarding the post or directly to me at dmagda@apache.org.

The request will be forwarded to the other service instance that is still alive.

For those who are interested. The second part has been published. Enjoy:

https://dzone.com/articles/running-microservices-on-top-of-in-memory-data-gri-1

Added to Apache Ignite blog posts list, thanks!

https://ignite.apache.org/blogs.html

Let us know when you write something new about Ignite and wants your work to be added to Apache Ignite site.

Alexander, sorry for the delay. Too tough schedule before the holidays. Will do all my best to complete the second part this year.

Truly useful blog post. Don't you mind it will be added to the blogs list of Apache Ignite community?

https://ignite.apache.org/blogs.html

It would be great if you write a message to Apache Ignite community regarding this or I can add a reference to the post there.

Thanks, I'll be working on the next part in the nearest time.