 Hello, everyone. So today, let's talk about how to create a distributed and encrypted database solution based on your PostgreSQL cluster. That's something about myself. I'm the SVES co-founder and the CTO. So my area, it's about the distributed database and about the database AI management platform developing something about that. But apart from that, actually, I get involved a lot in open source. So I'm an Apache member, Apache incubator mentor, and now gave some guidance and helps to straight incubator projects to help them create their open source community and project. And about today's slides, if you have any questions or want to learn more about myself, about this project, you can follow me on my Twitter or connect me on the linking. And it's in any way you can contact me. Yeah, so that's the background about our talk. That means you and me are fans of the PostgreSQL. It's very powerful. And when we put it in our production environment, we will consider use the primary and start back, stand by nodes or a cluster of the PostgreSQL to improve the availability and make the performance become wild. But today, the topic is about how to make your PostgreSQL cluster become distributed database and make your data stored in your PostgreSQL instance become the encrypted data. I mean, cipher text, that will help us to protect the user's information and privacy, right? Yeah, so that's the solution of today. And then I need to introduce about the Shirting Sophia project because by leveraging this project, it can help us to reach that goal I introduced before. Apache Shirting Sophia, it's the Apache top level project. And actually it's a large and active project and the community because there are a lot of the statistic and number can tell us about that. Choose over like 200 million lines of this coding, this project. And on GitHub, get 315,000 plus stars and 5,000 folks and also have more than 300 contributors of this community. And it actually has been open-forced for more than five years. So all of the state data will tell us that if you want to use it in your production environment, that will be safe. That will be okay because it's open-forced for five years. We receive 117 plus listed corporations or other cases. And it's the function about this project or around about database. So if you have any questions and you can receive the feedback or the help from this community, that's the charming of this active and large community. So the slogan for the definition of this project, it's an ecosystem to transfer any database. That's the goal we're striving into a distributed database system and enhance this distributed system or shorting system with many useful features like skilling, skill out, elastic skill out or skilling or encryption or SQL audit and more in future. So if you have some like the interest about this database, these features and you also want to join this community, you can just like go to the GitHub and try some good first issue. Okay, so that's the overview or that's the function list of this community, this project. Well, I have no time to introduce one of, every one of them to you today with the limited time, but I want to point out here is an architecture here. That means at the beginning or before using it, your application or the end, you're just your CLI to visit your PostgreSQL instance, right? But now when you use shorting Sophia, it's like a proxy or agent and your application statement from your application or a query is from your CLI will first reach to Apache shorting Sophia, this project. And then the actually this product named shorting Sophia proxy, yeah, this proxy will do some like an improvement or do some calculation and then recent your statement into one of your distributed database and cluster. Yeah, so that's that I want to say it's like a proxy or agent so it can pass your SQL, understand what you want and do some modification and recent that the SQL or statement into the target PostgreSQL instance. Yeah, so that's the, how do you deploy it? How do you use it? It's like a mechanism, right? So today we just use this project to help all users to like create, build, set up a distributed encrypted database. Yeah, so in this solution, this is like a yellow, yellow part, this one. And in this area, you can regard it, all of them as a distributed database, a new database. In this new database, the shorting Sophia proxy, it's like computing node, the function of this node, it just do some calculation or do some analysis and like receive user statement or request and then connect to your storage node. Storage node means your actual PostgreSQL instance or cluster. Maybe the storage nodes have many of your PostgreSQL instance. Like here I can give an example, like in this new distributed database and your shorting Sophia proxy, I mean your like the entrance there is a table named t underlying user. That's the means the logic table name. And this logic table actually it's made of one, two, three, four, four sub-tables or the shards because it's a shorting architecture, right? And t underlying user zero, t underlying user one, one in demo, ds, zero, PostgreSQL instance, and the same here, right? And so when your application send the request to the shorting Sophia proxy, the proxy will calculate which PostgreSQL or which table is the target for this statement, right? That's the shorting part. Because our solution also include encryption, encryption part, then our shorting Sophia proxy, it's a calculation computing nodes. It also has the ability to encrypted your information or data and decrypt the information, the data and all of them are automatically. That means your application don't care about the process of its computing part or processing. And just to be to the shorting proxy and shorting proxy will help you shard your database and encrypt your data, decrypt your data automatically. So now your duty or what you need to do is to light your shorting Sophia proxy, know more about what you want it to do and the metadata of your storage nodes about your rules or your metadata about this part. So you need to write some configuration or use the distributed SQL to drive the shorting Sophia proxy to let you know about your PostgreSQL instance, the table, your shorting algorithm, shorting column, shorting rule, and about encrypted rule, encrypted table, encrypted mapping between your logic column, and your cypher column. So all of the configurations or metadata or rules, you need to tell the shorting Sophia proxy and how. There are two ways to help you to drive the shorting Sophia proxy. First, it's like a YAML file. Here right now, that's the actual configuration. The second way or approach is use or distributed SQL. Distributed SQL actually it's born for Apache shorting Sophia, this ecosystem. You can use the SQL like language to tell the shorting Sophia proxy what you want it do for yourself. Yeah, you can see here, like various logic table, maybe here is the T user and what this logic table made of and the shorting column and algorithm and something about that. And the thing here, if we want to use the SQL to give the input about your needs about the metadata. We can just write the specific SQL and to let your shorting Sophia proxy know about about your needs. Yeah, so you can learn more about this part by the following links because today I really have no enough time to tell you all about this part. But you will know that by configuration or distributed SQL, you can like the shorting Sophia proxy works well with your shorting and encrypted database needs. Yeah. So here is a specific example I show you and let you quickly know about this process of how to use this distributed and encrypted PostgreSQL database. First, before that, you also need to deploy each shorting Sophia proxy and then log in shorting Sophia proxy. See here, it's the same as your PostgreSQL instance logging way, right? Second, tell the shorting Sophia proxy about your PostgreSQL instance. That means your storage nodes or metadata and here is the introduction about what's the distributed SQL. And then create rules and tables. Here you need to create a shorting rule and encrypt. Shorting will help you short your PostgreSQL instance. The encrypt will help you encrypt and decrypt your data into your PostgreSQL instance. Yeah. So create table and insert. And then you can select the data from this new database here, the telephone number just the plain text, right? But when you log in the actual your storage PostgreSQL instance, you will find the content of the telephone number will decrypt it into a string, right? That's the magic of shorting Sophia proxy. Yeah. So, okay, I just finished my part. And if you have any questions, just like content me on my Twitter linking or this project on Twitter. Yeah. So see you next time. Bye.