Hello, this is Tokai handsome feed, which provides the core knowledge of Texts. In-memory NoSQL, Redis, does not completely replace the existing RDB, but is first introduced and used in the field where fast data processing is of top priority. I will explain the transition process in detail. If there was an SQL database before, now we cache the result set of that and burn the caching layer, and then reduce the waist a bit and now, use less computing power, creating a structure like that. I think it's the right direction. So, connecting it to streaming, there is a structure that moves. As users use it, in fact, now we even need to connect to the cloud, connect various types of services like DW, create things like lakes, and it keeps growing, right?

This could become a silo. In a way, this also increases complexity as a silo. The complexity is increasing tremendously in the form we are heading now. However, in fact, Enje now uses all services with just one app. So, satisfaction should be good now. We invested a lot of money to improve the IT infrastructure and put good components in place. However, now we need to consider whether the experience is continuously improving. Recently, with cases like GPT, we need to think about the question of why we are talking about GPT. This is because of data governance models, data ownership, compliance issues, and the need to create internal L-only systems without using external resources like OpenAI vectors or Hugging Face. In such cases, even graphics cards need to be purchased.

Yes, it is necessary to purchase a very expensive server with a graphics card and build it because the existing service needs to be integrated. The complexity of this situation is actually increasing much more. So, if we now move various data types to a Redis-based Redis Enterprise-based cluster, we can greatly simplify the entire delivery architecture. Therefore, we believe that application developers can simplify the architecture by using Redis. So, it's not about taking out simple SQL data types from Redis, but by putting enough data into SQL Redis, we can reduce the form to be more efficient. For example, in the case of AWS, it reduces the cost of RDS services and makes RDS less burdensome, allowing for the maintenance of small instances.

In such a form, services can also be used, and by linking services together through the cloud, searching by context, it is possible to increase customer satisfaction. Therefore, in this way, we recommend that you reorganize the architecture a bit. Mr. Bong-an, are you this type of architecture engineer? Yes, that's right. Will you consult a lot on solutions and architectures? How to create a TO-BE model from the existing AS-IS model most effectively is the key, right? Yes, that's right. One of the frequent requests we receive is to reduce the licenses in the database and move them to Redis.

You write a lot about it, and when you query with the existing DV, SQL, which is commonly referred to as a database, throws all the computing power to run and operate, right? It has a structure where it converts data types, meaning type casting, but if you eliminate those parts and use Redis, will it really become a faster query? And can aggregation be possible now? However, for DV users, the question is whether it will be mainly used for querying or aggregation. Redis Enterprise supports all those things, but anyway, they will verify it. How long does it usually take for verification? When you enter the Redis Cloud and provision instances, it happens in real-time, so actually creating the infrastructure environment.

In the development, it is implemented in a very short time, and then, because Redis is a form of developer, for developers, many sample codes, reference codes, etc., are created on the internet. For example, there are many publicly available Python codes, Java codes, etc., that track trends in stock prices, allowing you to take them and actually run them to get a sense of application development. You can quickly see how Redis works at the back end, making it easier for them to get a sense of it. We are making a lot of efforts to recommend such things to help them grasp it easily. However, the problem with customers is not just a simple problem that we, as a solution vendor, think. So, there are various problems, so in fact, they contact us.

If you could try it once to see if there is anything we can help you with, I think it would be good. We hope to be able to help improve the performance of individual customers even a little bit. If there is anything we can help with in that direction, we would appreciate it. If you are curious about various Redis use cases including AI for water, you can click on the card link at the top right to watch related videos. For Redis-related inquiries, you can contact us via email here. On the Tech Specialist Channel, there is a space for data storage, analysis, protection, and various experts to consult and communicate. You can click on the link at the top right to talk in Korean on Google Talk IT 70. Your likes and subscriptions will be greatly appreciated for content production.

RDB에서 인메모리 NoSQL Redis로 전환하기 [세미남419@토크아이티, 김봉환 Solution Architect / Redis]

토크아이티는 "기업의 문제를 해결하는 기술과 신제품의 동향, 활용사례" 관련 콘텐츠와 생방송토크 웨비나를 2006년 부터 제공하고 있습니다.

아래 사이트에서 언제라도 편하게 전문가 생방송토크 웨비나를 무료로 시청하면서, 실시간으로 궁금한 점에 대한 답변을 들을 수 있습니다.
▶ 토크아이티 사이트: https://talkit.tv/

테크 전문기업의 웨비나와 콘텐츠 제작 상담 연락처
▶02-565-0012
▶yryoo@talkit.tv



RDB에서 인메모리 NoSQL Redis로 전환하기 [세미남419@토크아이티, 김봉환 Solution Architect / Redis]

RDB에서 인메모리 NoSQL Redis로 전환하기 [세미남419@토크아이티, 김봉환 Solution Architect / Redis]

스크립트